From: Zeng Zhaoxiu
Signed-off-by: Zeng Zhaoxiu
---
net/sunrpc/auth_gss/gss_krb5_keys.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/net/sunrpc/auth_gss/gss_krb5_keys.c
b/net/sunrpc/auth_gss/gss_krb5_keys.c
index 8701331..c41b389 100644
--- a/net/sunrpc/auth_gss/gss_
On Sat, 2016-03-26 at 20:42 -0700, Bhaskar Jupudi wrote:
> Explicit void pointer conversion is unnecessary
> because the conversions to and from a void pointer
> are always implicit in 'C'. Changed two instances
> of such conversions.
Your patch subject is incorrect, this is for fman
not all of d
Explicit void pointer conversion is unnecessary
because the conversions to and from a void pointer
are always implicit in 'C'. Changed two instances
of such conversions.
Signed-off-by: Bhaskar Jupudi
---
This patch is based on Kernel Janitors To-Do list
drivers/net/ethernet/freescale/fman/fma
On Sat, Mar 26, 2016 at 09:59:40PM -0400, Vivien Didelot wrote:
> The 6185 family does not have a ATU FID register. It splits it in the
> ATU Control register and the ATU Operation.
Looking at the reference code, the following devices have a FID
register:
( DEV_88E6097_FAMILY | DEV_88E6165_FAMILY
On Sat, Mar 26, 2016 at 09:59:38PM -0400, Vivien Didelot wrote:
> The 6185 family has only 256 indexable address databases, while the
> others (such as 6352) have 4095. Explicit and use these maximum values
> in the _mv88e6xxx_fid_new function.
Hi Vivien
I've been looking at the Marvell reference
hola
ordenador portátil, cámara, televisión, gultar, bicicleta. ... Te ofrecemos un
50% de descuento y envío gratis
iphone 6s,388euro
s ite: slooone . com
All packets passing through a switch of the 6185 family are currently all
directed to the CPU port. This means that port bridging is software driven.
To enable hardware bridging for this switch family, we need to implement the
port mapping operations, the FDB operations, and optionally the VLAN op
In the 6352 family, FIDs are 12-bit. In the 6185 family, they are 8-bit.
Fix the upper mask, which was overlapping on the port Trunk ID (even
though it is not used yet).
Signed-off-by: Vivien Didelot
---
drivers/net/dsa/mv88e6xxx.c | 10 +++---
drivers/net/dsa/mv88e6xxx.h | 3 ++-
2 files
The 88E6185 switch also has a MapDA bit in its Port Control 2 register.
When this bit is cleared, all frames are sent out to the CPU port.
Set this bit to rely on address databases (ATU) hits and direct frames
out of the correct ports, and thus allow hardware bridging.
Signed-off-by: Vivien Didel
The 6352 family has an entire register for its 12-bit FID used by the
VTU operations. The 6185 family has no such register. Its 8-bit FID
(called DBNum) is split in the VTU Operation register.
Modify the VTU read and write access to support this switch family.
Signed-off-by: Vivien Didelot
---
Some switch models don't have a separate ATU FID register, but bury it
in the ATU Operation register.
Factorize the write of the FID and opcode in the ATU command function.
Signed-off-by: Vivien Didelot
---
drivers/net/dsa/mv88e6xxx.c | 31 ++-
1 file changed, 14 ins
The 6185 family has only 256 indexable address databases, while the
others (such as 6352) have 4095. Explicit and use these maximum values
in the _mv88e6xxx_fid_new function.
Signed-off-by: Vivien Didelot
---
drivers/net/dsa/mv88e6xxx.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
By adding support for bridge operations, FDB operations, and optionally
VLAN operations (for 802.1Q and VLAN filtering aware systems), the
switch bridges ports correctly, the CPU is able to populate the hardware
address databases, and thus hardware bridging becomes functional within
the 88E6185 fam
The 6185 family does not have a ATU FID register. It splits it in the
ATU Control register and the ATU Operation.
Add 6185 support for FID (a.k.a. DBNum) in ATU commands.
Signed-off-by: Vivien Didelot
---
drivers/net/dsa/mv88e6xxx.c | 14 ++
drivers/net/dsa/mv88e6xxx.h | 2 +-
2 fi
Hi Guenter,
Guenter Roeck writes:
> Is there some good reason for changing the name of those labels ?
Vivien suggested to rename this since it makes more clear that this write
is
meant to return to page 0 to make sure that phylib doesn't get confused
about the curre
We need to use post-decrement to ensure that irq_dispose_mapping is
also called on priv->rxq[0]->irq_no; moreover, if one of the above for
loops failed already at i==0 (so we reach one of these labels with
that value of i), we'll enter an essentially infinite loop of
out-of-bounds accesses.
Signed
On 03/26/2016 11:32 AM, Vivien Didelot wrote:
Hi Guenter,
Guenter Roeck writes:
Is there some good reason for changing the name of those labels ?
Vivien suggested to rename this since it makes more clear that this write is
meant to return to page 0 to make sure that phylib doesn't get confu
Andrew Lunn writes:
>> page_0 is fine. What about an even more explicit "clear_page_0" label?
>
> We are not clearing anything. We are changing to page 0. So
>
> restore_page_0?
+1
> page_0 is fine. What about an even more explicit "clear_page_0" label?
We are not clearing anything. We are changing to page 0. So
restore_page_0?
Andrew
On Sat, Mar 19, 2016 at 9:32 AM, Jesse Gross wrote:
> When drivers express support for TSO of encapsulated packets, they
> only mean that they can do it for one layer of encapsulation.
> Supporting additional levels would mean updating, at a minimum,
> more IP length fields and they are unaware of
Hi Andrew,
Andrew Lunn writes:
>> "error" definitely doesn't make sense, especially in case of success. If
>> one has a better suggestion that "clear" for the label, I don't really
>> mind.
>
> Hi Vivien, Guenter
>
> page_0 ?
For some unjustified reasons I prefered single word labels, but multi
> "error" definitely doesn't make sense, especially in case of success. If
> one has a better suggestion that "clear" for the label, I don't really
> mind.
Hi Vivien, Guenter
page_0 ?
Andrew
Patrick Uiterwijk writes:
> Some of the vendor-specific bootloaders set up this part
> of the initialization for us, so this was never added.
> However, since upstream bootloaders don't initialize the
> chip specifically, they leave the fiber MII's PDOWN flag
> set, which means that the CPU port
Hi Guenter,
Guenter Roeck writes:
>>> Is there some good reason for changing the name of those labels ?
>>
>> Vivien suggested to rename this since it makes more clear that this write is
>> meant to return to page 0 to make sure that phylib doesn't get confused
>> about the currently active page
On Sat, 2016-03-26 at 13:21 +0200, Corcodel Marian wrote:
> Set one line space extra delay on set_rx_mode for starting
>on full duplex and full speed.
>
> Signed-off-by: Corcodel Marian
> ---
> drivers/net/ethernet/realtek/r8169.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/d
On Sat, 2016-03-26 at 12:57 +0200, Corcodel Marian wrote:
> This patch correct set bit multicast enable only once per set_rx_mode
> invocation.
>
> Signed-off-by: Corcodel Marian
> ---
> drivers/net/ethernet/realtek/r8169.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --
This patch add searching for needed registers on set_rx_mode function
and add delay to bee ready.This is for starting on full duplex on full
speed.
Signed-off-by: Corcodel Marian
---
drivers/net/ethernet/realtek/r8169.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/net/ethern
This patch correct set bit multicast enable only once per set_rx_mode
invocation.
Signed-off-by: Corcodel Marian
---
drivers/net/ethernet/realtek/r8169.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/realtek/r8169.c
b/drivers/net/ethernet/realtek/r
Set one line space extra delay on set_rx_mode for starting
on full duplex and full speed.
Signed-off-by: Corcodel Marian
---
drivers/net/ethernet/realtek/r8169.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/ethernet/realtek/r8169.c
b/drivers/net/ethernet/realtek/r8169.c
Hi, all
I used kernel-3.4 and applied patch
"6e9e16e6143b72 ipv6: replacing a rt6_info needs to purge possible
propagated rt6_infos too",
I'm not sure which opertion triggered the BUG_ON, from vmcore, I got that
rt6i_ref's counter is 0x2 and rt6i_dst is ff02::02
Until now ,the BUG_ON
30 matches
Mail list logo
