On Wed, May 25, 2016 at 01:56:20AM +0200, Lino Sanfilippo wrote:
> Francois, Shuyu,
>
> this is the patch with the discussed changes.
>
> Shuyu it would be great if you could test this one. If it passes
> and there are no further objections I will resend it as a regular patch
> (including commit
On Fri, May 27, 2016 at 11:21 AM, Alexander Duyck
wrote:
> I started out this morning by trying to run DevStack on the latest
> "net' kernel and it looks like I am hanging on some sort of locking
> problem with RabbitMQ. Specifically I am seeing one CPU jump to 100%
> with perf showing that I am
From: Roopa Prabhu
This patch series adds json support for a few bridge show commands.
We plan to follow up with json support for additional commands soon.
Anuradha Karuppiah (3):
json_writer: allow base json data type to be array or object
bridge: add json support for bridge fdb show
brid
From: Roopa Prabhu
$bridge -c vlan show
portvlan ids
swp1 1 PVID Egress Untagged
10-13
swp2 1 PVID Egress Untagged
10-13
br0 1 PVID Egress Untagged
$bridge -j vlan show
{
"swp1": [{
"vlan": 1,
"flags": "PVID Egress Untagged"
From: Roopa Prabhu
Signed-off-by: Roopa Prabhu
---
man/man8/bridge.8 | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/man/man8/bridge.8 b/man/man8/bridge.8
index 08e8a5b..abaee63 100644
--- a/man/man8/bridge.8
+++ b/man/man8/bridge.8
@@ -20,8 +20,9 @@ bridge \- show
From: Anuradha Karuppiah
Sample output:
$bridge -j fdb show
[{
"mac": "44:38:39:00:69:88",
"dev": "swp2s0",
"vlan": 2,
"master": "br0",
"state": "permanent"
},{
"mac": "00:02:00:00:00:01",
"dev": "swp2s0",
"vlan": 2,
"mas
From: Anuradha Karuppiah
we think storing the schema file for the json
format will be useful.
Signed-off-by: Anuradha Karuppiah
---
schema/bridge_fdb_schema.json | 62 +++
1 file changed, 62 insertions(+)
create mode 100644 schema/bridge_fdb_schema.json
From: Anuradha Karuppiah
This patch adds a type qualifier to json_writer. Type can be a
json object or array. This can be extended to other types like
json-string, json-number etc in the future.
Signed-off-by: Anuradha Karuppiah
---
include/json_writer.h | 5 +++--
lib/json_writer.c | 39
Dear friend,
My name is Mr Kamal Ali Mohamed . I am working with one of the prime banks here
in Burkina Faso. Here in this bank existed a dormant account for many years,
which belong to one of our late foreign customer.
When I discovered that there had been neither deposits nor withdrawals fr
On Fri, May 27, 2016 at 2:23 PM, Arnd Bergmann wrote:
>
> This patch changes all users of IS_ERR_VALUE() that I could find
> on 32-bit ARM randconfig builds and x86 allmodconfig. For the
> moment, this doesn't change the definition of IS_ERR_VALUE()
> because there are probably still architecture
On Fri, May 27, 2016 at 09:19:48AM -0700, Cong Wang wrote:
>
> This one looks different though, this time the bug is
> triggered in netlink_sock_destruct(), where all the sock
> ref should be gone, which means it is impossible to refer
> nlk->cb anywhere else. Hmm... I have no idea how
> could this
On Fri, May 27, 2016 at 11:23:25PM +0200, Arnd Bergmann wrote:
> @@ -837,7 +837,7 @@ static int load_flat_shared_library(int id, struct
> lib_info *libs)
>
> res = prepare_binprm(&bprm);
>
> - if (!IS_ERR_VALUE(res))
> + if (res >= 0)
if (res == 0), please - prepare_bin
On 27/05/16 22:23, Arnd Bergmann wrote:
drivers/acpi/acpi_dbg.c | 22 +++---
drivers/ata/sata_highbank.c | 2 +-
drivers/clk/tegra/clk-tegra210.c | 2 +-
drivers/cpufreq/omap-cpufreq.c | 2 +-
On Fri, May 27, 2016 at 2:46 PM, Andrew Morton
wrote:
>
> So you do plan to add some sort of typechecking into IS_ERR_VALUE()?
The easiest way to do it is to just turn the (x) into (unsigned
long)(void *)(x), which then complains about casting an integer to a
pointer if the integer has the wrong
On Fri, 27 May 2016 23:23:25 +0200 Arnd Bergmann wrote:
> Most users of IS_ERR_VALUE() in the kernel are wrong, as they
> pass an 'int' into a function that takes an 'unsigned long'
> argument. This happens to work because the type is sign-extended
> on 64-bit architectures before it gets convert
Most users of IS_ERR_VALUE() in the kernel are wrong, as they
pass an 'int' into a function that takes an 'unsigned long'
argument. This happens to work because the type is sign-extended
on 64-bit architectures before it gets converted into an
unsigned type.
However, anything that passes an 'unsig
On 05/27/2016 01:57 PM, Andrew Lunn wrote:
> On Fri, May 27, 2016 at 04:39:05PM -0400, Vivien Didelot wrote:
>>
>> Hi Andrew, Florian,
>>
>> Here again, I'd suggested an implicit namespace for functions taking a
>> dsa_switch_tree structure as first argument, i.e. dsa_tree_do_foo().
>
> Using tree
On 05/27/2016 11:45 AM, Vivien Didelot wrote:
> Hi Andrew, Florian,
>
> We are inconsistent on commit titles and messages. Some of them use
> "net: " prefix, some others don't, sometimes lower or upper case titles.
>
> I'd suggest we stick with the "net: dsa: " prefix and lowercase titles.
>
> W
On Fri, May 27, 2016 at 04:39:05PM -0400, Vivien Didelot wrote:
>
> Hi Andrew, Florian,
>
> Here again, I'd suggested an implicit namespace for functions taking a
> dsa_switch_tree structure as first argument, i.e. dsa_tree_do_foo().
Using tree actually makes things worse, since tree is never us
Hi Andrew, Florian,
Here again, I'd suggested an implicit namespace for functions taking a
dsa_switch_tree structure as first argument, i.e. dsa_tree_do_foo().
Since we are likely to spend some time in net/dsa, it'd be great to
introduce the new bindings and an intuitive API at the same time ;-)
If dirty_tx isn't updated, then dma_unmap_single
can be called twice.
This fixes a
[ 58.420980] [ cut here ]
[ 58.425667] WARNING: CPU: 0 PID: 377 at
/home/schurig/d/mkarm/linux-4.5/lib/dma-debug.c:1096 check_unmap+0x9d0/0xab8()
[ 58.436405] fec 2188000.ethernet: DMA
> dsa_cpu_dsa_setups is not really meaningful and doesn't add much
> value.
I would disagree. Quoting Documentation/CodingStyle
Chapter 6: Functions
Functions should be short and sweet, and do just one thing. They should
fit on one or two screenfuls of text (the ISO/ANSI screen
On Fri, May 27, 2016 at 03:35:57PM -0400, Vivien Didelot wrote:
> Hi Andrew,
>
> Andrew Lunn writes:
>
> > @@ -26,6 +26,7 @@ enum dsa_tag_protocol {
> > DSA_TAG_PROTO_TRAILER,
> > DSA_TAG_PROTO_EDSA,
> > DSA_TAG_PROTO_BRCM,
> > + _DSA_TAG_LAST,
> > };
>
> I would avoid _ prefixed
On Fri, May 27, 2016 at 03:25:47PM -0400, Vivien Didelot wrote:
> Hi Andrew, Florian,
>
> I suggest to use this RFC to agree on a consistent and robust API for
> the DSA layer. Some functions have non-intuitive names or signatures.
Nope.
What is important is getting this patchset accepted and me
Removing P2P interface is handled by sending a proper request to the
firmware. On success firmware triggers an event and driver's handler
removes a matching interface.
However on event timeout we remove interface directly from the cfg80211
callback. Current code doesn't handle this case correctly
Hi Andrew,
I like the s/phy/mdio/ renaming, but please move it in its own
non-functional patch for easier reviewing.
Also, we may want to use this opportunity to get rid of some _ prefixed
functions. It is hard to following the distinction between these two
following signatures:
int _mv88e6x
Hi Andrew,
Andrew Lunn writes:
> @@ -26,6 +26,7 @@ enum dsa_tag_protocol {
> DSA_TAG_PROTO_TRAILER,
> DSA_TAG_PROTO_EDSA,
> DSA_TAG_PROTO_BRCM,
> + _DSA_TAG_LAST,
> };
I would avoid _ prefixed functions or symbols, we've seen in mv88e6xxx
that it doesn't make the code rea
Hi Andrew, Florian,
I suggest to use this RFC to agree on a consistent and robust API for
the DSA layer. Some functions have non-intuitive names or signatures.
What about:
_[_]
where matches the first argument. So instead of
dsa_cpu_dsa_setup, we would have:
dsa_switch_setup_cpu_dsa_p
Firmware for new chipsets is based on a new major version of code
internally maintained at Broadcom. E.g. brcmfmac4366b-pcie.bin (used for
BCM4366B1) is based on 10.10.69.3309 while brcmfmac43602-pcie.ap.bin was
based on 7.35.177.56.
Currently setting AP 5 GHz channel doesn't work reliably with BC
Hi Andrew,
Andrew Lunn writes:
> /*
> - * An array (with nr_chips elements) of which element [a]
> - * indicates which port on this switch should be used to
> - * send packets to that are destined for switch a. Can be
> - * NULL if there is only one switch chip.
> +
Hi Hannes,
On 05/27/2016 06:56 PM, Hannes Frederic Sowa wrote:
> On 25.05.2016 07:15, YOSHIFUJI Hideaki wrote:
>>
>>
>> Alexander Aring wrote:
>>> This patch removes the net_device parameter from ndisc_opt_addr_space
>>> function. This can be useful for calling such functionality which
>>> doesn'
Hi Andrew, Florian,
We are inconsistent on commit titles and messages. Some of them use
"net: " prefix, some others don't, sometimes lower or upper case titles.
I'd suggest we stick with the "net: dsa: " prefix and lowercase titles.
When possible, let's try to respect the 50/72 Git rule.
So we'
Hi Andrew,
I tested this RFC and it works fine for me, looks good overall.
I'll do a second pass for nit-picking.
Thanks for this work,
Vivien
I started out this morning by trying to run DevStack on the latest
"net' kernel and it looks like I am hanging on some sort of locking
problem with RabbitMQ. Specifically I am seeing one CPU jump to 100%
with perf showing that I am spinning on a lock.
I'm working to bisect it now, but just though
On Fri, May 27, 2016 at 10:56:44AM -0700, Cong Wang wrote:
> > Commit 412ca1550cbecb2c ("macvlan: Move broadcasts into a work queue")
> > moved processing of all macvlan multicasts into a work queue. This
> > causes a noticable performance regression when there is heavy multicast
> > traffic on t
On Thu, May 26, 2016 at 4:44 PM, Lennert Buytenhek
wrote:
> Commit 412ca1550cbecb2c ("macvlan: Move broadcasts into a work queue")
> moved processing of all macvlan multicasts into a work queue. This
> causes a noticable performance regression when there is heavy multicast
> traffic on the underl
Did something change in Netfilter on the 4.4.6 kernel that would affect my
Netfilter hook driver? I have a driver that works in 2.6.38, 3.10.49 and
3.15.3. I started porting the driver to the 4.4.6 kernel and
can't get it to work. Specifically, apply_eip_snat() in the driver never gets
call
On Fri, May 27, 2016 at 10:14 AM, Hannes Frederic Sowa
wrote:
> Hi,
>
> On 27.05.2016 18:59, Tom Herbert wrote:
>> On Fri, May 27, 2016 at 8:03 AM, Sowmini Varadhan
>> wrote:
>>> On (05/27/16 11:53), Hannes Frederic Sowa wrote:
> Thinking about this some more, the per option white list is a b
On 27/05/16 09:22, Iyappan Subramanian wrote:
This patch fixes MAC configuration to support 10/100GbE for SGMII and
link_state call back. It also sets pdata->mdio_driver flag based on
ethernet mdio subnode and prepare for MDIO driver support.
In summary, following are the changes,
- Added set_s
Hi,
On 27.05.2016 18:59, Tom Herbert wrote:
> On Fri, May 27, 2016 at 8:03 AM, Sowmini Varadhan
> wrote:
>> On (05/27/16 11:53), Hannes Frederic Sowa wrote:
Thinking about this some more, the per option white list is a better
approach. If we allow an open ended mechanism for application
On 27/05/16 09:22, Iyappan Subramanian wrote:
This patchset addresses the following issues,
1. hot-plug issue on the SGMII 1G interface
- by adding a driver for MDIO management
2. fixes the kernel crash when the driver loaded as an kernel module
- by fixing hardware cleanups and
On Fri, May 27, 2016 at 9:46 AM, Hannes Frederic Sowa
wrote:
> On Thu, May 26, 2016, at 20:42, Tom Herbert wrote:
>> Thinking about this some more, the per option white list is a better
>> approach. If we allow an open ended mechanism for applications to
>> signal the network with arbitrary data (
On Fri, May 27, 2016 at 8:03 AM, Sowmini Varadhan
wrote:
> On (05/27/16 11:53), Hannes Frederic Sowa wrote:
>> > Thinking about this some more, the per option white list is a better
>> > approach. If we allow an open ended mechanism for applications to
>> > signal the network with arbitrary data (
On 25.05.2016 07:15, YOSHIFUJI Hideaki wrote:
>
>
> Alexander Aring wrote:
>> This patch removes the net_device parameter from ndisc_opt_addr_space
>> function. This can be useful for calling such functionality which
>> doesn't depends on dev parameter. For current existing functionality
>> which
On Thu, May 26, 2016, at 20:42, Tom Herbert wrote:
> Thinking about this some more, the per option white list is a better
> approach. If we allow an open ended mechanism for applications to
> signal the network with arbitrary data (like user specified hbp
> options would be), then use of that mecha
The MAC address of the physical interface is only copied to the VLAN
when it is first created, resulting in an inconsistency after MAC
address changes of only newly created VLANs having an up-to-date MAC.
The VLANs should continue inheriting the MAC address of the physical
interface until the VLAN
Hi Andrew,
Andrew Lunn writes:
> On Fri, May 27, 2016 at 10:33:49AM -0400, Vivien Didelot wrote:
>> Hi Andrew,
>>
>> Andrew Lunn writes:
>>
>> > -static void dsa_switch_destroy(struct dsa_switch *ds)
>> > +void dsa_cpu_dsa_destroy(struct device_node *port_dn)
>> > {
>> > - struct device_nod
Hi Andrew,
Andrew Lunn writes:
> On Fri, May 27, 2016 at 10:55:45AM -0400, Vivien Didelot wrote:
>> Hi Andrew,
>>
>> Andrew Lunn writes:
>>
>> > - mdiobus_unregister(ds->slave_mii_bus);
>> > + if (ds->slave_mii_bus && ds->drv->phy_read)
>> > + mdiobus_unregister(ds->slave_mii_bus);
On Thu, May 26, 2016 at 8:06 AM, Eric Dumazet wrote:
> On Thu, 2016-05-26 at 22:48 +0800, Baozeng Ding wrote:
>> Hi all,
>> I've got the following report use-after-free in netlink_sock_destruct while
>> running syzkaller.
>> Unfortunately no reproducer.The kernel version is 4.6 (May 15, on commit
On Thu, May 26, 2016 at 7:49 PM, Chen Haiquan wrote:
> When create a new vxlan link, example:
> ip link add vtap mtu 1440 type vxlan vni 1 dev eth0
>
> The argument "mtu" has no effect, because it is not set to conf->mtu. The
> default value is used in vxlan_dev_configure function.
>
> This prob
On Thu, May 26, 2016 at 4:21 AM, Eric Dumazet wrote:
> On Thu, 2016-05-26 at 03:14 +0800, Xin Long wrote:
>> Now we cannot distinguish that one sk is a udp or sctp style when
>> we use ss to dump sctp_info. it's necessary to dump it as well.
>>
>> For sctp_diag, ss support is not officially availa
On Thu, May 26, 2016 at 3:24 AM, David Miller wrote:
> From: Xin Long
> Date: Thu, 26 May 2016 03:14:28 +0800
>
>> For sctp_diag, ss support is not officially available, thus there
>> are no official users of this yet, so we can add this field in the
>> middle of sctp_info without breaking user A
On Fri, May 27, 2016 at 10:55:45AM -0400, Vivien Didelot wrote:
> Hi Andrew,
>
> Andrew Lunn writes:
>
> > - mdiobus_unregister(ds->slave_mii_bus);
> > + if (ds->slave_mii_bus && ds->drv->phy_read)
> > + mdiobus_unregister(ds->slave_mii_bus);
>
> So if a driver registered the slav
gcc-6 on x86 started warning about wl3501_get_encode when building
with -O2:
drivers/net/wireless/wl3501_cs.c: In function ‘wl3501_get_encode’:
drivers/net/wireless/wl3501_cs.c:1769:5: warning: ‘implemented’ may be used
uninitialized in this function
drivers/net/wireless/wl3501_cs.c:1686:19: warn
On Fri, May 27, 2016 at 10:33:49AM -0400, Vivien Didelot wrote:
> Hi Andrew,
>
> Andrew Lunn writes:
>
> > -static void dsa_switch_destroy(struct dsa_switch *ds)
> > +void dsa_cpu_dsa_destroy(struct device_node *port_dn)
> > {
> > - struct device_node *port_dn;
> > struct phy_device *phyd
On (05/27/16 11:53), Hannes Frederic Sowa wrote:
> > Thinking about this some more, the per option white list is a better
> > approach. If we allow an open ended mechanism for applications to
> > signal the network with arbitrary data (like user specified hbp
> > options would be), then use of that
On Thu, May 26, 2016 at 07:15:49AM -0700, Eric Dumazet wrote:
> On Thu, 2016-05-26 at 16:59 +0300, Vladimir Davydov wrote:
> > On Thu, May 26, 2016 at 04:04:55PM +0900, Minchan Kim wrote:
> > > On Wed, May 25, 2016 at 01:30:11PM +0300, Vladimir Davydov wrote:
> > > > On Tue, May 24, 2016 at 01:04:3
Fri, May 27, 2016 at 04:25:29AM CEST, zyjzyj2...@gmail.com wrote:
>Hi, Jiri
>
>I delved into the source code of team. And I found that the function
>team_add_slave actually works in the protection of rtnl lock. So in my
>humble opinion, it is not necessary to use the mutex lock to protect
>team_por
Hi Andrew,
Andrew Lunn writes:
> - mdiobus_unregister(ds->slave_mii_bus);
> + if (ds->slave_mii_bus && ds->drv->phy_read)
> + mdiobus_unregister(ds->slave_mii_bus);
So if a driver registered the slave MII bus itself, it may have
unregistered it itself as well, so checking ds
Hi Andrew,
Andrew Lunn writes:
> -static void dsa_switch_destroy(struct dsa_switch *ds)
> +void dsa_cpu_dsa_destroy(struct device_node *port_dn)
> {
> - struct device_node *port_dn;
> struct phy_device *phydev;
> +
> + if (of_phy_is_fixed_link(port_dn)) {
> + phydev =
If the sdio_enable_func() function fails on .probe, the -EIO errno code
is always returned but that could make more difficult to debug and find
the cause of why the function actually failed.
Since the driver/device core prints the value returned by .probe in its
error message propagate what was re
There's only a check if mwifiex_add_card() returned a nonzero value, but
the actual error code is neither stored nor propagated to the caller. So
instead of always returning -1 (which is -EPERM and not a suitable errno
code in this case), propagate the value returned by mwifiex_add_card().
Patch a
SDIO is an auto enumerable bus so the SDIO devices are matched using the
sdio_device_id table and not using compatible strings from a OF id table.
However, commit ce4f6f0c353b ("mwifiex: add platform specific wakeup
interrupt support") allowed to match nodes defined as child of the SDIO
host contr
Hello,
While booting a system with a mwifiex WiFi card, I noticed the following
missleading error message:
[ 12.480042] mwifiex_sdio mmc2:0001:1: sdio platform data not available
This error only applies to platforms that define a child node for the SDIO
device, but it's currently shown even in
Instead of duplicating part of the cleanups needed in case of an error
in .probe callback, have a single error path and use goto labels as is
common practice in the kernel.
This also has the nice side effect that the cleanup operations are made
in the inverse order of their counterparts, which was
The Documentation/devicetree/bindings/net/wireless/marvell-sd8xxx.txt DT
binding document lists the possible compatible strings that a SDIO child
node can have, so the driver checks if the defined in the node matches.
But the error message when that's not the case is misleading, so change
for one
It's better to have the device name prefixed in the error message.
Signed-off-by: Javier Martinez Canillas
---
drivers/net/wireless/marvell/mwifiex/sdio.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/marvell/mwifiex/sdio.c
b/drivers/net/wireless/
The Documentation/devicetree/bindings/net/wireless/marvell-sd8xxx.txt DT
binding document say that the "interrupts" property in the child node is
optional. So the property being missed shouldn't be treated as an error.
Signed-off-by: Javier Martinez Canillas
---
drivers/net/wireless/marvell/mwi
The function can fail so the returned value should be checked
and the error propagated to the caller in case of a failure.
Signed-off-by: Javier Martinez Canillas
---
drivers/net/wireless/marvell/mwifiex/sdio.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers
Hello.
On 27/05/16 13:03, Alexander Aring wrote:
Hi,
On 05/27/2016 12:05 PM, Stefan Schmidt wrote:
Hello.
On 23/05/16 21:22, Alexander Aring wrote:
In case of sending RA messages we need some way to get the short address
from an 802.15.4 6LoWPAN interface. This patch will add a temporary
deb
Hello.
On 27/05/16 13:41, Alexander Aring wrote:
Hi,
On 05/27/2016 11:45 AM, Stefan Schmidt wrote:
Hello.
sorry, again I will change something on this patch which is buggy.
On 23/05/16 21:22, Alexander Aring wrote:
This patch moves the functionality to add a RA PIO prefix generated
addres
gcc is apparently unablel to track the state of the local 'resp_v2'
variable across the kzalloc() function, and warns about the response
variable being used without an initialization:
drivers/net/wireless/intel/iwlwifi/mvm/nvm.c: In function ‘iwl_mvm_update_mcc’:
drivers/net/wireless/intel/iwlwifi
Hi,
On 05/27/2016 11:45 AM, Stefan Schmidt wrote:
> Hello.
>
sorry, again I will change something on this patch which is buggy.
> On 23/05/16 21:22, Alexander Aring wrote:
>> This patch moves the functionality to add a RA PIO prefix generated
>> address in an own function. This move prepares t
Hi,
On 05/27/2016 12:05 PM, Stefan Schmidt wrote:
> Hello.
>
> On 23/05/16 21:22, Alexander Aring wrote:
>> In case of sending RA messages we need some way to get the short address
>> from an 802.15.4 6LoWPAN interface. This patch will add a temporary
>> debugfs entry for experimental userspace
Hello,
I'm sorry to repost that, but after one month, I need a answer to continue to
imrpove my patch in the right direction. :)
Thank you in advance.
Regards.
Charles-Antoine Couret
Le 29/04/2016 à 10:28, Charles-Antoine Couret a écrit :
> Le 11/04/2016 à 21:47, Florian Fainelli a écrit :
>>>
The iadev->rx_open[] array holds "iadev->num_vc" pointers (this code
assumes that pointers are 32 bits). So the > here should be >= or else
we could end up reading a garbage pointer from one element beyond the
end of the array.
Signed-off-by: Dan Carpenter
diff --git a/drivers/atm/iphase.c b/dr
This bug was there when the driver was first added in back in year 2000.
It causes a Smatch warning:
drivers/atm/firestream.c:849 process_incoming()
error: buffer overflow 'res_strings' 60 <= 63
There are supposed to be 64 entries in this array and the missing
strings are clearly in the 3
Hello.
On 26/05/16 15:07, Baozeng Ding wrote:
Fix a logic error to avoid potential null pointer dereference.
Signed-off-by: Baozeng Ding
---
net/ieee802154/nl802154.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/ieee802154/nl802154.c b/net/ieee802154/nl802154.c
Hello.
On 23/05/16 21:22, Alexander Aring wrote:
This patch introduce different 6lowpan handling for receive and transmit
NS/NA messages for the ipv6 neighbour discovery. The first use-case is
for supporting 802.15.4 short addresses inside the option fields and
handling for RFC6775 6CO option fi
Hello.
On 23/05/16 21:22, Alexander Aring wrote:
In case of sending RA messages we need some way to get the short address
from an 802.15.4 6LoWPAN interface. This patch will add a temporary
debugfs entry for experimental userspace api.
Signed-off-by: Alexander Aring
---
net/6lowpan/debugfs.c
Hello.
On 23/05/16 21:22, Alexander Aring wrote:
This patch exports some neighbour discovery functions which can be used
by 6lowpan neighbour discovery ops functionality then.
Cc: David S. Miller
Cc: Alexey Kuznetsov
Cc: James Morris
Cc: Hideaki YOSHIFUJI
Cc: Patrick McHardy
Signed-off-by: Alex
On 26.05.2016 20:42, Tom Herbert wrote:
> On Mon, May 23, 2016 at 11:11 AM, Tom Herbert wrote:
>> On Sun, May 22, 2016 at 4:56 AM, Sowmini Varadhan
>> wrote:
>>>
> Tom Herbert wrote:
> If you don't mind I'll change this to make specific options are
> privileged and not all hbh
Hello.
On 23/05/16 21:22, Alexander Aring wrote:
This patch moves the functionality to add a RA PIO prefix generated
address in an own function. This move prepares to add a hook for
adding a second address for a second link-layer address. E.g. short
address for 802.15.4 6LoWPAN.
Cc: David S. Mi
Since the MDIO will be responsible for clock reset, removing the clock
nodes from shadowcat xge0 and storm sgenet1.
Signed-off-by: Iyappan Subramanian
Tested-by: Fushen Chen
Tested-by: Toan Le
---
arch/arm64/boot/dts/apm/apm-shadowcat.dtsi | 12
arch/arm64/boot/dts/apm/apm-storm.d
This patch fixes MAC configuration to support 10/100GbE for SGMII and
link_state call back. It also sets pdata->mdio_driver flag based on
ethernet mdio subnode and prepare for MDIO driver support.
In summary, following are the changes,
- Added set_speed function pointer in mac_ops
- Changed link_
Added mdio node for mdio driver. Also added phy-handle
reference to the ethernet nodes. Removed unused mdio
subnode within ethernet node.
Signed-off-by: Iyappan Subramanian
Tested-by: Fushen Chen
Tested-by: Toan Le
---
arch/arm64/boot/dts/apm/apm-merlin.dts | 10 ++
arch/arm64/bo
When the driver is configured as kernel module and when it gets unloaded
and reloaded, kernel crash was observed, due to incomplete hardware
cleanup. This patch addresses this issue with the following changes,
- Reordered mac enable and disable
- Added hardware prefetch buffer cleanup
- Added Tx
Currently, SGMII based 1G rely on the hardware registers for link state
and sometimes it's not reliable. To get most accurate link state, this
interface has to use the MDIO bus to poll the PHY.
In X-Gene SoC, MDIO bus is shared across RGMII and SGMII based 1G
interfaces, so adding this driver to
This patch looks for CONFIG_MDIO_XGENE and based on phy-handle DT/ACPI
fields, sets the mdio_driver flag. The rest of the driver uses the
this flag for any MDIO management, in the case of backward compatibility.
Also, some code clean up done around mdio configuration/remove.
Signed-off-by: Iyappa
This patchset addresses the following issues,
1. hot-plug issue on the SGMII 1G interface
- by adding a driver for MDIO management
2. fixes the kernel crash when the driver loaded as an kernel module
- by fixing hardware cleanups and rearrange kernel API calls
Signed-off-by: Iyapp
90 matches
Mail list logo
