Hi Dave,
Here's the last bluetooth-next pull request for the 4.6 kernel.
- New USB ID for AR3012 in btusb
- New BCM2E55 ACPI ID
- Buffer overflow fix for the Add Advertising command
- Support for a new Bluetooth LE limited privacy mode
- Fix for firmware activation in btmrvl_sdio
- Cleanups
This patch not enable/disable bus mastering when is enabled on BIOS..
pci_disable_device function also disable bus mastering for, disable bus
mastering
is dedicate function.
Signed-off-by: Corcodel Marian
---
drivers/net/ethernet/realtek/r8169.c | 29 ++---
1 file ch
On Fri, Mar 11, 2016 at 2:55 PM, Tom Herbert wrote:
> On Fri, Mar 11, 2016 at 2:31 PM, Alexander Duyck
> wrote:
>> On Fri, Mar 11, 2016 at 1:29 PM, Edward Cree wrote:
>>> On 11/03/16 21:09, Alexander Duyck wrote:
The only real issue with the "generic" TSO is that it isn't going to
be s
On Friday 04 March 2016 03:50 AM, David Miller wrote:
> From: Lada Trimasova
> Date: Thu, 3 Mar 2016 17:07:46 +0300
>
>> Since ezchip network driver is written with big endian EZChip platform it
>> is necessary to add support for little endian architecture.
>>
>> The first issue is that the orde
On (03/11/16 20:07), Tom Herbert wrote:
> You are describing your deployment of RDS, not kernel implementation.
> What I see is a very rigid implementation that would make it hard for
> many us to ever even consider deploying. The abilities of applications
> to tune TCP connections is well underst
On Fri, Mar 11, 2016 at 7:44 PM, Sowmini Varadhan
wrote:
> On (03/11/16 19:21), Tom Herbert wrote:
>> You could consider and alternate model where connection management
>> (connect, listen, etc.) is performed in a userspace daemon and the
>> attached to the kernel (pretty much like KCM does). This
On (03/11/16 19:21), Tom Herbert wrote:
> You could consider and alternate model where connection management
> (connect, listen, etc.) is performed in a userspace daemon and the
> attached to the kernel (pretty much like KCM does). This moves
You have to remember that, like it or not, RDS has some
On Fri, Mar 11, 2016 at 6:43 PM, Sowmini Varadhan
wrote:
> On (03/11/16 11:09), Stephen Hemminger wrote:
>> Module parameters are a problem for distributions and should only be used
>> as a last resort.
>
> I dont know the history of what the distibution problem is, but I
> did try to use sysctl a
On (03/11/16 11:09), Stephen Hemminger wrote:
> Module parameters are a problem for distributions and should only be used
> as a last resort.
I dont know the history of what the distibution problem is, but I
did try to use sysctl as an alternative for this. I'm starting to
believe that this is on
> >> Humm, if that's the problem we want to solve, we could introduce a
> >> helper function which tries to locate the phy using a 'phy-handle'
> >> property
> >
> > I don't follow you. Where do you get a phandle from to use with
> > phy-handle?
>
> >From the caller of the function: the consumer
I am going to send a new version of this set.
David Daney
On 03/11/2016 09:53 AM, David Daney wrote:
From: David Daney
Changes from v1:
- In 1/3 Add back check for non-OF objects in bgx_init_of_phy(). It
is probably not necessary, but better safe than sorry...
The firmware on many C
> > +Child nodes represent PHYs on this mdio bus. Standard properties for
> > +fixed links, 'speed', 'full-duplex', 'pause', 'asym-pause',
> > +'link-gpios', as defined above are used. Additionally a 'reg' property
> > +is required for the address of the PHY on the bus. This should be of
> > +value
On 28/02/16 08:41, Andrew Lunn wrote:
> Create a dsa_switch_finish() which does the opposite of dsa_switch_setup().
> Create a dsa_finish_dst() which does the opposite of dsa_setup_dst().
>
> Signed-off-by: Andrew Lunn
Reviewed-by: Florian Fainelli
--
Florian
On 28/02/16 08:41, Andrew Lunn wrote:
> Rename and reposition dsa_switch_destroy() to dsa_switch_finish_one()
> to make it clear it is the opposite of dsa_switch_setup_one().
>
> Signed-off-by: Andrew Lunn
Reviewed-by: Florian Fainelli
--
Florian
On 03/03/16 12:27, Andrew Lunn wrote:
>> - first of all, the original design around the special platform device
>> did not allow multiple switch trees within the same system to coexist
>> (dsa platform device were not numbered (id = -1)), but such a thing
>> could exist and is desirable, you could
On 11/03/16 15:36, Andrew Lunn wrote:
> On Fri, Mar 11, 2016 at 03:26:42PM -0800, Florian Fainelli wrote:
>> On 11/03/16 15:08, Andrew Lunn wrote:
>>> Currently, supporting a fixed-phy in a MAC driver is a bit messy. It
>>> needs to be explicit supported, since a fixed phy is somewhat
>>> different
On Fri, Mar 11, 2016 at 03:26:42PM -0800, Florian Fainelli wrote:
> On 11/03/16 15:08, Andrew Lunn wrote:
> > Currently, supporting a fixed-phy in a MAC driver is a bit messy. It
> > needs to be explicit supported, since a fixed phy is somewhat
> > different from a normal phy.
> >
> > These two pa
On 11/03/16 15:08, Andrew Lunn wrote:
> Not all MACs are connected to PHYs. They can for example be connected
> to a switch. Using the fixed PHY properties with the MAC is possible,
> but requires support in the MAC. It is however simpler to make use of
> the phy-handle property to point to a PHY.
On 11/03/16 15:08, Andrew Lunn wrote:
> Currently, supporting a fixed-phy in a MAC driver is a bit messy. It
> needs to be explicit supported, since a fixed phy is somewhat
> different from a normal phy.
>
> These two patches solve this by making fixed-phys appear as normal
> PHYs within device tr
On 11/03/16 15:01, Andrew Lunn wrote:
> The fixed phys delete function simply removed the fixed phy from the
> internal linked list and freed the memory. It however did not
> unregister the associated phy device. This meant it was still possible
> to find the phy device on the mdio bus.
>
> Make f
On Fri, Mar 11, 2016 at 11:41:42AM -0800, Shrikrishna Khare wrote:
>
>
> On Fri, 11 Mar 2016, Tetsuo Handa wrote:
>
> > Neil Horman wrote:
> > > On Mon, Mar 07, 2016 at 03:16:14PM -0500, David Miller wrote:
> > > > From: Neil Horman
> > > > Date: Fri, 4 Mar 2016 13:40:48 -0500
> >
> > This pa
Currently, supporting a fixed-phy in a MAC driver is a bit messy. It
needs to be explicit supported, since a fixed phy is somewhat
different from a normal phy.
These two patches solve this by making fixed-phys appear as normal
PHYs within device tree, allowing them to be referenced by a phandle.
A
Turn the parsing of the fixed link properties into a helper function,
and export it for others to use.
Signed-off-by: Andrew Lunn
---
drivers/of/of_mdio.c| 34 +-
include/linux/of_mdio.h | 11 ++-
2 files changed, 31 insertions(+), 14 deletions(-)
dif
Not all MACs are connected to PHYs. They can for example be connected
to a switch. Using the fixed PHY properties with the MAC is possible,
but requires support in the MAC. It is however simpler to make use of
the phy-handle property to point to a PHY. To achieve this, the PHY
must be in the device
On 11/03/16 14:53, Vladimir Zapolskiy wrote:
> Hello Sergei,
>
> On 12.03.2016 00:12, Sergei Shtylyov wrote:
>> IS_ERR_OR_NULL() is open coded in of_mdiobus_register_{phy|device}(), so
>> just call it directly...
>>
>> Signed-off-by: Sergei Shtylyov
>>
>> ---
>> drivers/of/of_mdio.c |4 ++--
All ports types can have a fixed PHY associated with it. Remove the
check which limits removal to only CPU and DSA ports.
Signed-off-by: Andrew Lunn
---
net/dsa/dsa.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/net/dsa/dsa.c b/net/dsa/dsa.c
index 1018e7dcfcc9..f100f340d93f 100644
--- a
The phy is disconnected from the slave in dsa_slave_destroy(). Don't
destroy fixed link phys until after this, since there can be fixed
linked phys connected to ports.
Signed-off-by: Andrew Lunn
---
net/dsa/dsa.c | 24
1 file changed, 12 insertions(+), 12 deletions(-)
d
When the phy is disconnected, the parent pointer to the netdev it was
attached to is set to NULL. The code then tries to suspend the phy,
but dsa_slave_fixed_link_update needs the parent pointer to determine
which switch the phy is connected to. So it dereferenced a NULL
pointer. Check for this con
The RFC patchset for re-architecturing DSA probing contains a few
standalone patches, either clean up or fixes. This pulls them out for
submission.
Andrew Lunn (5):
dsa: Rename mv88e6123_61_65 to mv88e6123 to be consistent
dsa: slave: Don't reference NULL pointer during phy_disconnect
dsa: D
Hello Sergei,
On 12.03.2016 00:13, Sergei Shtylyov wrote:
> PTR_ERR_OR_ZERO() is open coded in of_phy_register_fixed_link(), so just
> call it directly...
>
> Signed-off-by: Sergei Shtylyov
>
> ---
> drivers/of/of_mdio.c |6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> Ind
All the drivers support multiple chips, but mv88e6123_61_65 is the
only one that reflects this in its naming. Change it to be consistent
with the other drivers.
Signed-off-by: Andrew Lunn
---
arch/arm/configs/multi_v5_defconfig | 2 +-
arch/arm/configs/mvebu_v5_defconfig | 2 +-
arch/arm/con
The fixed phys delete function simply removed the fixed phy from the
internal linked list and freed the memory. It however did not
unregister the associated phy device. This meant it was still possible
to find the phy device on the mdio bus.
Make fixed_phy_del() an internal function and add a
fixe
On Fri, Mar 11, 2016 at 2:31 PM, Alexander Duyck
wrote:
> On Fri, Mar 11, 2016 at 1:29 PM, Edward Cree wrote:
>> On 11/03/16 21:09, Alexander Duyck wrote:
>>> The only real issue with the "generic" TSO is that it isn't going to
>>> be so generic. We have different devices that will support diffe
Hello Sergei,
On 12.03.2016 00:12, Sergei Shtylyov wrote:
> IS_ERR_OR_NULL() is open coded in of_mdiobus_register_{phy|device}(), so
> just call it directly...
>
> Signed-off-by: Sergei Shtylyov
>
> ---
> drivers/of/of_mdio.c |4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
>
On 11/03/16 14:13, Sergei Shtylyov wrote:
> PTR_ERR_OR_ZERO() is open coded in of_phy_register_fixed_link(), so just
> call it directly...
>
> Signed-off-by: Sergei Shtylyov
Reviewed-by: Florian Fainelli
--
Florian
On 11/03/16 14:12, Sergei Shtylyov wrote:
> IS_ERR_OR_NULL() is open coded in of_mdiobus_register_{phy|device}(), so
> just call it directly...
>
> Signed-off-by: Sergei Shtylyov
Reviewed-by: Florian Fainelli
--
Florian
On Fri, Mar 11, 2016 at 1:29 PM, Edward Cree wrote:
> On 11/03/16 21:09, Alexander Duyck wrote:
>> The only real issue with the "generic" TSO is that it isn't going to
>> be so generic. We have different devices that will support different
>> levels of stuff. For example the ixgbe drivers will n
IS_ERR_OR_NULL() is open coded in of_mdiobus_register_{phy|device}(), so
just call it directly...
Signed-off-by: Sergei Shtylyov
---
drivers/of/of_mdio.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
Index: net-next/drivers/of/of_mdio.c
==
PTR_ERR_OR_ZERO() is open coded in of_phy_register_fixed_link(), so just
call it directly...
Signed-off-by: Sergei Shtylyov
---
drivers/of/of_mdio.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
Index: net-next/drivers/of/of_mdio.c
=
Hello.
Here's the set of 2 patches against DaveM's 'net-next.git' repo. They
replace the patch posted earlier today which was clearly insufficient...
[1/2] of_mdio: use IS_ERR_OR_NULL()
[2/2] of_mdio: use PTR_ERR_OR_ZERO()
MBR, Sergei
This patch updates csum_ipv6_magic so that it correctly recognizes that
protocol is a unsigned 8 bit value.
This will allow us to better understand what limitations may or may not be
present in how we handle the data. For example there are a number of
places that call htonl on the protocol value.
This patch updates all instances of csum_tcpudp_magic and
csum_tcpudp_nofold to reflect the types that are usually used as the source
inputs. For example the protocol field is populated based on nexthdr which
is actually an unsigned 8 bit value. The length is usually populated based
on skb->len w
This patch series is meant to address the differences that exist between
IPv4 and IPv6 in terms of checksum calculation. Specifically the IPv6
function csum_ipv6_magic treated length as a value that could be greater
than 64K, while csum_tcpudp_magic was truncating the length at 16 bits.
After look
It is possible for tunnels to end up generating IP or IPv6 datagrams that
are larger than 64K and expecting to be segmented. As such we need to deal
with length values greater than 64K. In order to accommodate this we need
to update the code to work with a 32b length value instead of a 16b one.
Sergei Shtylyov :
[...]
> >@@ -7083,8 +7084,11 @@ rtl_init_one(struct pci_dev *pdev, const struct
> >pci_device_id *ent)
> > }
> > tp->mmio_addr = ioaddr;
> >
> >-if (!pci_is_pcie(pdev))
> >+if (!pci_is_pcie(pdev)) {
> > netif_info(tp, probe, dev, "not PCI Express\n");
On Sat, Mar 12, 2016 at 12:22:47AM +0300, Cyrill Gorcunov wrote:
> On Fri, Mar 11, 2016 at 03:40:46PM -0500, David Miller wrote:
> > > Thanks a lot, David!
> >
> > Cyrill please retest this final patch and let me know if it still works
> > properly.
> >
> > I looked at ipv6, and it's more complic
On 03/11/2016 01:35 PM, Andrew Lunn wrote:
[...]
How usable is the hardware without a PHY driver?
The hardware has always in the past, still does, and probably always
will work fine without a PHY driver. Link up/down are correctly handled.
Is a better solution
that your write a very minima
> For this phy, we have:
>
> compatible = "cortina,cs4223-slice";
That actually means something else is happening, i think.
of_mdiobus_register() looks at the children, and decides if each child
is a phy or an mdio device, by calling of_mdiobus_child_is_phy().
Since this compatible string is n
On 11/03/16 21:09, Alexander Duyck wrote:
> The only real issue with the "generic" TSO is that it isn't going to
> be so generic. We have different devices that will support different
> levels of stuff. For example the ixgbe drivers will need to treat the
> outer tunnel header as one giant L2 hea
don't pass uninitialized flags to spin_unlock_irqrestore.
Reported-by: Tetsuo Handa
Signed-off-by: Shrikrishna Khare
Signed-off-by: Guolin Yang
---
drivers/net/vmxnet3/vmxnet3_drv.c | 9 -
drivers/net/vmxnet3/vmxnet3_int.h | 4 ++--
2 files changed, 6 insertions(+), 7 deletions(-)
dif
On 03/12/2016 12:12 AM, Sergei Shtylyov wrote:
IS_ERR_OR_NULL() is basically open coded in of_mdiobus_register_phy(), so
just call it directly...
I found one more place where this change is needed, will recast.
Signed-off-by: Sergei Shtylyov
MBR, Sergei
On Fri, Mar 11, 2016 at 03:40:46PM -0500, David Miller wrote:
> > Thanks a lot, David!
>
> Cyrill please retest this final patch and let me know if it still works
> properly.
>
> I looked at ipv6, and it's more complicated. The problem is that ipv6
> doesn't mark the inet6dev object as dead in t
IS_ERR_OR_NULL() is basically open coded in of_mdiobus_register_phy(), so
just call it directly...
Signed-off-by: Sergei Shtylyov
---
The patch is against DaveM's 'net-next.git' repo.
drivers/of/of_mdio.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: net-next/drivers/of/of_m
On Fri, Mar 11, 2016 at 12:24 PM, Edward Cree wrote:
> On 11/03/16 20:16, Tom Herbert wrote:
>> On Fri, Mar 11, 2016 at 11:59 AM, Edward Cree wrote:
>>> On 11/03/16 19:57, Tom Herbert wrote:
On Fri, Mar 11, 2016 at 11:20 AM, Edward Cree wrote:
> Tom,
>
> Are you planning to / wo
On Fri, Mar 11, 2016 at 03:40:46PM -0500, David Miller wrote:
> >
> > Thanks a lot, David!
>
> Cyrill please retest this final patch and let me know if it still works
> properly.
...
Thanks David! Give me some time, gonna build and run test.
Cyrill
Add two new NLAs to support configuration of Infiniband node or port
GUIDs. New applications can choose to use this interface to configure
GUIDs with iproute2 with commands such as:
ip link set dev ib0 vf 0 node_guid 00:02:c9:03:00:21:6e:70
ip link set dev ib0 vf 0 port_guid 00:02:c9:03:00:21:6e:7
David Miller wrote:
> From: Cyrill Gorcunov
> Date: Fri, 11 Mar 2016 01:40:56 +0300
>
> > On Thu, Mar 10, 2016 at 05:36:30PM -0500, David Miller wrote:
> >> >
> >> > Works like a charm! So David, what are the next steps then?
> >> > Mind to gather all your patches into one (maybe)?
> >>
> >> I
On 03/11/2016 11:37 AM, Florian Fainelli wrote:
On 11/03/16 11:06, Andrew Lunn wrote:
I don't see why it should wait around forever. I have boards with
Marvell PHYs, yet if i don't build the Marvell driver, the Ethernet
driver still loads, because the generic PHY driver is used instead.
Why does
Hi David,
This is a very small one this time, with only 5 patches.
There are a couple of big items that could not be merged/finished
on time.
We have:
- 2 LLCP fixes for a race and a potential OOM.
- 2 cleanups for the pn544 and microread drivers.
- 1 Maintainer addition for the s3fwrn5 driver.
Thank you very much for the review. I'll make the requested changes
and resubmit the series...
-Aaron Young
On 03/11/16 11:30, David Miller wrote:
From: Aaron Young
Date: Tue, 8 Mar 2016 07:02:35 -0800
+static struct vnet *vsw_get_vnet(struct mdesc_handle *hp,
+
From: Cyrill Gorcunov
Date: Fri, 11 Mar 2016 01:40:56 +0300
> On Thu, Mar 10, 2016 at 05:36:30PM -0500, David Miller wrote:
>> >
>> > Works like a charm! So David, what are the next steps then?
>> > Mind to gather all your patches into one (maybe)?
>>
>> I'll re-review all of the changes tomorr
On 11/03/16 20:16, Tom Herbert wrote:
> On Fri, Mar 11, 2016 at 11:59 AM, Edward Cree wrote:
>> On 11/03/16 19:57, Tom Herbert wrote:
>>> On Fri, Mar 11, 2016 at 11:20 AM, Edward Cree wrote:
Tom,
Are you planning to / working on implementing this? If not, I might have a
crack
From: Edward Cree
Date: Fri, 11 Mar 2016 19:20:41 +
> Are you planning to / working on implementing this? If not, I might have a
> crack at it; I've talked to our firmware guys and (provisionally) we think
> we can support it in current sfc hardware.
> Or were there any blocking problems rai
From: Yuval Mintz
Date: Wed, 9 Mar 2016 09:16:22 +0200
> This series contains several changes to driver interaction with the
> management fw.
> The biggest [& most significant] change here is a change in the locking
> scheme and re-definition of the 'critical section' when accessing shared
> reso
On Fri, Mar 11, 2016 at 11:59 AM, Edward Cree wrote:
> On 11/03/16 19:57, Tom Herbert wrote:
>> On Fri, Mar 11, 2016 at 11:20 AM, Edward Cree wrote:
>>> Tom,
>>>
>>> Are you planning to / working on implementing this? If not, I might have a
>>> crack at it; I've talked to our firmware guys and (
From: Daniel Borkmann
Date: Wed, 9 Mar 2016 03:00:01 +0100
> This set adds support for tunnel key flow labels for vxlan
> and geneve devices in collect meta data mode and eBPF support
> for managing these. For details please see individual patches.
Series applied, although I agree with the call
On 11/03/16 19:57, Tom Herbert wrote:
> On Fri, Mar 11, 2016 at 11:20 AM, Edward Cree wrote:
>> Tom,
>>
>> Are you planning to / working on implementing this? If not, I might have a
>> crack at it; I've talked to our firmware guys and (provisionally) we think
>> we can support it in current sfc h
From: Joe Perches
Date: Tue, 8 Mar 2016 13:54:56 -0800
> Don't hide varibles used by the logging macros.
>
> Miscellanea:
>
> o Use the more common ##__VA_ARGS__ extension
> o Add missing newlines to formats
> o Realign arguments
>
> Signed-off-by: Joe Perches
Applied, thanks Joe.
From: Stephen Hemminger
Date: Tue, 8 Mar 2016 12:59:32 -0800
> This fixes regression in how ageing timer is managed.
> Backing out the change required fixing switch drivers as well.
Series applied, thanks.
Jiri, since I applied this to net-next, I had to deal with the conflicts
created by your
Am 10.03.2016 um 17:41 schrieb i...@linux-pingi.de:
> Am 10.03.2016 um 13:58 schrieb Paul Bolle:
>> On do, 2016-03-10 at 11:53 +0100, i...@linux-pingi.de wrote:
>>> mISDN with CAPI support works just fine with pppd and pppdcapiplugin
>>> and the CAPI works for all mISDN HW.
>>
>> In the mainline tr
On ven., 2016-03-11 at 21:25 +0200, Saeed Mahameed wrote:
> >> -void mlx5e_handle_rx_cqe_mpwrq(struct mlx5e_rq *rq, struct mlx5_cqe64
> >> *cqe)
> >> +static void mlx5e_add_skb_frag(struct sk_buff *skb, int len, struct page
> >> *page,
> >> +int page_offset)
> >> +{
>
On Fri, Mar 11, 2016 at 11:20 AM, Edward Cree wrote:
> On 20/02/16 19:51, Tom Herbert wrote:
>> Right. To use LCO with TSO we would need to ensure that all packets
>> are the same size so that the UDP length field and thus checksum are
>> constant for all created segments. But this property this w
On 11/03/16 10:31, Murali Karicheri wrote:
> On 03/10/2016 02:38 PM, Murali Karicheri wrote:
>> On 03/10/2016 01:05 PM, Florian Fainelli wrote:
>>> On 10/03/16 08:48, Murali Karicheri wrote:
On 03/03/2016 07:16 PM, Florian Fainelli wrote:
> On 03/03/16 14:18, Murali Karicheri wrote:
>>
On 03/11/2016 11:06 AM, Andrew Lunn wrote:
I don't see why it should wait around forever. I have boards with
Marvell PHYs, yet if i don't build the Marvell driver, the Ethernet
driver still loads, because the generic PHY driver is used instead.
Why does this not work here?
As I said before, the
From: Willem de Bruijn
Date: Tue, 8 Mar 2016 15:18:54 -0500
> From: Willem de Bruijn
>
> The stack expects link layer headers in the skb linear section.
> Macvtap can create skbs with llheader in frags in edge cases:
> when (IFF_VNET_HDR is off or vnet_hdr.hdr_len < ETH_HLEN) and
> prepad + le
From: Guillaume Nault
Date: Tue, 8 Mar 2016 20:14:30 +0100
> Lock ppp_mutex and check that file->private_data is NULL before
> executing any action in ppp_unattached_ioctl().
> The test done by ppp_ioctl() can't be relied upon, because
> file->private_data may have been updated meanwhile. In whic
On Fri, 11 Mar 2016, Tetsuo Handa wrote:
> Neil Horman wrote:
> > On Mon, Mar 07, 2016 at 03:16:14PM -0500, David Miller wrote:
> > > From: Neil Horman
> > > Date: Fri, 4 Mar 2016 13:40:48 -0500
>
> This patch is calling spin_unlock_irqrestore() without spin_lock_irqsave().
>
> In file inclu
On 11/03/16 11:06, Andrew Lunn wrote:
>>> I don't see why it should wait around forever. I have boards with
>>> Marvell PHYs, yet if i don't build the Marvell driver, the Ethernet
>>> driver still loads, because the generic PHY driver is used instead.
>>> Why does this not work here?
>>
>> As I sai
From: Aaron Young
Date: Tue, 8 Mar 2016 07:02:35 -0800
> +static struct vnet *vsw_get_vnet(struct mdesc_handle *hp,
> + u64 port_node,
> + u64 *handle)
> +{
> + struct vnet *vp;
> + struct vnet *iter;
> + const u64 *local_mac
On Fri, Mar 11, 2016 at 4:08 PM, Sergei Shtylyov
wrote:
> Hello.
>
> On 3/11/2016 4:39 PM, Saeed Mahameed wrote:
>
>> From: Tariq Toukan
>>
>> Distribute default RSS table uniformely over the rings of the
>
>
>Uniformly.
Indeed :), will fix this
Thank you.
From: Aaron Young
Date: Tue, 8 Mar 2016 07:02:34 -0800
> @@ -719,12 +720,13 @@ static void maybe_tx_wakeup(struct vnet_port *port)
> __netif_tx_unlock(txq);
> }
>
> -static inline bool port_is_up(struct vnet_port *vnet)
> +inline bool port_is_up_common(struct vnet_port *vnet)
All of th
From: Aaron Young
Date: Tue, 8 Mar 2016 07:02:33 -0800
> +EXPORT_SYMBOL(vnet_send_attr_common);
All of these need to be EXPORT_SYMBOL_GPL()
>> -void mlx5e_handle_rx_cqe_mpwrq(struct mlx5e_rq *rq, struct mlx5_cqe64 *cqe)
>> +static void mlx5e_add_skb_frag(struct sk_buff *skb, int len, struct page
>> *page,
>> +int page_offset)
>> +{
>> + int f = skb_shinfo(skb)->nr_frags++;
>> + skb_frag_t *fr = &skb
On 03/11/2016 01:55 PM, Caesar Wang wrote:
This patch adds to support the emac phy reset.
1) phy-reset-gpios:
The phy-reset-gpios is an optional property for arc emac device tree boot.
Change the binding document to match the driver code.
2) phy-reset-duration:
Different boards may require dif
From: Gregory CLEMENT
Date: Tue, 8 Mar 2016 13:57:06 +0100
> From: Dmitri Epshtein
>
> This commit corrects error printing when shutting down the port. Also
> magic numbers are replaced by existing macros.
>
> Signed-off-by: Dmitri Epshtein
> Signed-off-by: Gregory CLEMENT
Individual patch
On 20/02/16 19:51, Tom Herbert wrote:
> Right. To use LCO with TSO we would need to ensure that all packets
> are the same size so that the UDP length field and thus checksum are
> constant for all created segments. But this property this would also
> make any payload lengths in headers constant fo
From: Sowmini Varadhan
Date: Fri, 11 Mar 2016 13:29:49 -0500
> Some payload sizes/patterns stand to gain performance benefits by
> tuning the size of the TCP socket buffers, so this commit adds
> module parameters to customize those values when desired.
>
> Signed-off-by: Sowmini Varadhan
No m
On (03/11/16 11:09), Stephen Hemminger wrote:
>
> Module parameters are a problem for distributions and should only be used
> as a last resort.
I was not aware of that- out of curiosity, what is the associated problem?
What would be the alternative recommendation in this case?
--Sowmini
Hello.
On 03/11/2016 06:06 PM, Corcodel Marian wrote:
On pci express not support latency timer.For more info read file
/drivers/pci/pci.c
on pcibios_set_master function.
Signed-off-by: Corcodel Marian
---
drivers/net/ethernet/realtek/r8169.c | 10 +++---
1 file changed, 7 insertio
On Fri, 11 Mar 2016 13:29:49 -0500
Sowmini Varadhan wrote:
>
> -#define RDS_TCP_DEFAULT_BUFSIZE (128 * 1024)
> +static int sndbuf_size = 16384;
> +module_param(sndbuf_size, int, 0444);
> +MODULE_PARM_DESC(sndbuf_size, "SO_SNDBUF size of kernel tcp socket");
> +
> +static int rcvbuf_size = 87380
> >I don't see why it should wait around forever. I have boards with
> >Marvell PHYs, yet if i don't build the Marvell driver, the Ethernet
> >driver still loads, because the generic PHY driver is used instead.
> >Why does this not work here?
>
> As I said before, there is no driver for the device
Hello.
On 03/11/2016 05:48 PM, Caesar Wang wrote:
[...]
Hi Rob, David:
PATCH[1/6-2/6]: >
net: arc_emac: make the rockchip emac document more compatible
net: arc_emac: add phy-reset-* are optional for device tree
The patches change the rockchip emac document for more compatible and
Add the
On 03/11/2016 10:00 AM, Andrew Lunn wrote:
On Fri, Mar 11, 2016 at 09:41:06AM -0800, David Daney wrote:
On 03/11/2016 09:31 AM, Andrew Lunn wrote:
+ phy_np = of_parse_phandle(node, "phy-handle", 0);
+ /* If there is no phy or defective firmware presents
+
On 03/11/2016 01:55 PM, Caesar Wang wrote:
This patch adds to support the emac phy reset.
1) phy-reset-gpios:
The phy-reset-gpios is an optional property for arc emac device tree boot.
Change the binding document to match the driver code.
The binding document is apparently changed in anoth
On 3/11/16 10:02 AM, Daniel Borkmann wrote:
Would strscpy() help in this case (see 30035e45753b ("string: provide
strscpy()"))?
I've looked at it too, but 990486c8af04 scared me a little,
it's not easily backport-able and mainly I don't think
it's faster than strlcpy for small strings like comm
On 03/10/2016 02:38 PM, Murali Karicheri wrote:
> On 03/10/2016 01:05 PM, Florian Fainelli wrote:
>> On 10/03/16 08:48, Murali Karicheri wrote:
>>> On 03/03/2016 07:16 PM, Florian Fainelli wrote:
On 03/03/16 14:18, Murali Karicheri wrote:
> Hi,
>
> We are using Micrel Phy in one of
Some payload sizes/patterns stand to gain performance benefits by
tuning the size of the TCP socket buffers, so this commit adds
module parameters to customize those values when desired.
Signed-off-by: Sowmini Varadhan
---
net/rds/tcp.c | 16 +++-
1 files changed, 15 insertions(+)
On 03/11/2016 06:20 PM, Alexei Starovoitov wrote:
On 3/11/16 2:24 AM, Daniel Borkmann wrote:
On 03/10/2016 05:02 AM, Alexei Starovoitov wrote:
Lots of places in the kernel use memcpy(buf, comm, TASK_COMM_LEN); but
the result is typically passed to print("%s", buf) and extra bytes
after zero don
On Fri, Mar 11, 2016 at 09:41:06AM -0800, David Daney wrote:
> On 03/11/2016 09:31 AM, Andrew Lunn wrote:
> >>+ phy_np = of_parse_phandle(node, "phy-handle", 0);
> >>+ /* If there is no phy or defective firmware presents
> >>+* this cortina phy, for which there is no
From: David Decotigny
Tested:
On qemu e1000:
$ dd if=/dev/zero bs=2 count=5 | /mnt/ethtool -E eth0 length 9
too much data from stdin
$ dd if=/dev/zero bs=2 count=5 | /mnt/ethtool -E eth0 length 11
not enough data from stdin
$ dd if=/dev/zero bs=2 count=5 | /mnt/ethtool -E eth0 length
1 - 100 of 218 matches
Mail list logo
