[PATCH v2] net/phy: micrel: configure intterupts after autoneg workaround

s, the phy will stall, since interrupts are off. This patch fixes the issue by calling config_intr after resetting the phy. Fixes: d2fd719bcb0e ("net/phy: micrel: Add workaround for bad autoneg ") Signed-off-by: Zach Brown <zach.br...@ni.com> --- v2: * Check phy_intterupt_is_valid

[PATCH] net/phy: micrel: configure intterupts after autoneg workaround

s, the phy will stall, since interrupts are off. This patch fixes the issue by calling config_intr after resetting the phy. Fixes: d2fd719bcb0e ("net/phy: micrel: Add workaround for bad autoneg ") Signed-off-by: Zach Brown <zach.br...@ni.com> --- drivers/net/phy/micrel.c | 2 ++ 1

[PATCH] net: phy: handle state correctly in phy_stop_machine

From: Nathan Sullivan If the PHY is halted on stop, then do not set the state to PHY_UP. This ensures the phy will be restarted later in phy_start when the machine is started again. Signed-off-by: Nathan Sullivan Signed-off-by: Brad Mouring

Re: [PATCH v2] net: phy: Fix use after free in phy_detach()

hy_led_triggers_unregister(phydev); > - > /* >* The phydev might go away on the put_device() below, so avoid >* a use-after-free bug by reading the underlying bus first. > -- > 1.9.1 > I was able to recreate the issue and confirmed this patch fixes it. Tested-by: Zach Brown <zach.br...@ni.com> --Zach

Re: Pure polling mode for netdevices

On Fri, Oct 21, 2016 at 11:41:46AM -0700, Eric Dumazet wrote: > On Fri, 2016-10-21 at 13:03 -0500, Zach Brown wrote: > > Is there a way to get NAPI to poll all the time? > > Or just any way to get netdevices to use only polling and no interrupts? > > > > We have some

Pure polling mode for netdevices

Is there a way to get NAPI to poll all the time? Or just any way to get netdevices to use only polling and no interrupts? We have some rt targets where the jitter can be improved by disabling interrupts and using just polling. In these cases we're okay with the performance downsides that come

[PATCH 0/2] Add ethtool get_ringparam and set_ringparam to cadence

implements the get_ringparam and set_ringparam fucntions. Zach Brown (2): net: macb: Use variables with defaults for tx/rx ring sizes instead of hardcoded values net: macb: Add ethtool get_ringparam and set_ringparam functionality drivers/net/ethernet/cadence/macb.c | 173

[PATCH 2/2] net: macb: Add ethtool get_ringparam and set_ringparam functionality

Some applications want to tune the size of the macb rx/tx ring buffers. The ethtool set_ringparam function is the standard way of doing it. Signed-off-by: Zach Brown <zach.br...@ni.com> --- drivers/net/ethernet/cadence/macb.c | 59 + 1 file chang

[PATCH 1/2] net: macb: Use variables with defaults for tx/rx ring sizes instead of hardcoded values

to their respective replacements. Signed-off-by: Zach Brown <zach.br...@ni.com> --- drivers/net/ethernet/cadence/macb.c | 114 drivers/net/ethernet/cadence/macb.h | 3 + 2 files changed, 65 insertions(+), 52 deletions(-) diff --git a/drivers/net/ethernet/cadence/mac

Re: [PATCH v5 4/4] net: phy: leds: add support for led triggers on phy link state change

On Tue, Oct 18, 2016 at 09:13:50AM +0200, Andrew Lunn wrote: > On Mon, Oct 17, 2016 at 10:49:55AM -0500, Zach Brown wrote: > > Create an option CONFIG_LED_TRIGGER_PHY (default n), which will create a > > set of led triggers for each instantiated PHY device. There is one LED >

[PATCH v5 2/4] net: phy: Encapsulate actions performed during link state changes into function phy_adjust_link

ore. Actions that should occur whenever the phy link is adjusted can now be added to the phy_adjust_link function. Signed-off-by: Zach Brown <zach.br...@ni.com> --- drivers/net/phy/phy.c | 21 + 1 file changed, 13 insertions(+), 8 deletions(-) diff --git a/drivers/net/phy/phy.c

[PATCH v5 4/4] net: phy: leds: add support for led triggers on phy link state change

by this patch the leds not controlled by the phy can be configured to show the current speed of the ethernet connection. The leds controlled by the phy are unaffected. Signed-off-by: Josh Cartwright <josh.cartwri...@ni.com> Signed-off-by: Nathan Sullivan <nathan.sulli...@ni.com> Signed-off-by

[PATCH v5 0/4] Add support for led triggers on phy link state change

ist of triggers to dynamic list determined by speeds return by phy_supported_speeds. Zach Brown (4): skge: Rename LED_OFF and LED_ON in marvel skge driver to avoid conflicts with leds namespace net: phy: Encapsulate actions performed during link state changes into funct

[PATCH v5 1/4] skge: Rename LED_OFF and LED_ON in marvel skge driver to avoid conflicts with leds namespace

changed LED_ON to LED_REG_ON to avoid possible future conflict and for consistency. Signed-off-by: Zach Brown <zach.br...@ni.com> --- drivers/net/ethernet/marvell/skge.c | 6 +++--- drivers/net/ethernet/marvell/skge.h | 4 ++-- 2 files changed, 5 insertions(+), 5 deletions(-) diff --git a/d

[PATCH v5 3/4] net: phy: Create phy_supported_speeds function which lists speeds currently supported by a phydevice

phy_supported_speeds provides a means to get a list of all the speeds a phy device currently supports. Signed-off-by: Zach Brown <zach.br...@ni.com> --- drivers/net/phy/phy.c | 35 +++ include/linux/phy.h | 15 +++ 2 files changed, 50 inse

Re: [PATCH v4 3/3] net: phy: leds: add support for led triggers on phy link state change

On Thu, Oct 13, 2016 at 10:46:34AM -0400, David Miller wrote: > From: Zach Brown <zach.br...@ni.com> > Date: Tue, 11 Oct 2016 15:26:20 -0500 > > > From: Josh Cartwright <josh.cartwri...@ni.com> > > > > Create an option CONFIG_LED_TRIGGER_PHY (default

Re: [RFC v3 3/3] phy,leds: add support for led triggers on phy link state change

On Mon, Oct 10, 2016 at 02:03:32AM -0700, Florian Fainelli wrote: > > + > > +#ifdef CONFIG_LED_TRIGGER_PHY > > + > > +#include > > +#include > > + > > +#define PHY_LINK_LED_MAX_TRIGGERS 5 > > +#define PHY_LED_TRIGGER_SPEED_SUFFIX_SIZE 7 > > +#define PHY_MII_BUS_ID_SIZE(20 - 3) > >

Re: [PATCH v4 1/3] skge: Rename LED_OFF and LED_ON in marvel skge driver to avoid conflicts with leds namespace

On Tue, Oct 11, 2016 at 02:14:07PM -0700, Stephen Hemminger wrote: > On Tue, 11 Oct 2016 15:26:18 -0500 > Zach Brown <zach.br...@ni.com> wrote: > > > Adding led support for phy causes namespace conflicts for some > > phy drivers. > > > > The marvel skge d

[PATCH v4 1/3] skge: Rename LED_OFF and LED_ON in marvel skge driver to avoid conflicts with leds namespace

changed LED_ON to LED_REG_ON to avoid possible future conflict and for consistency. Signed-off-by: Zach Brown <zach.br...@ni.com> --- drivers/net/ethernet/marvell/skge.c | 6 +++--- drivers/net/ethernet/marvell/skge.h | 4 ++-- 2 files changed, 5 insertions(+), 5 deletions(-) diff --git a/d

[PATCH v4 0/3] Add support for led triggers on phy link state change

and improve consistency. * Dropped rtl8712 patch that was accepted separately. v4: * tweaked commit message Josh Cartwright (1): net: phy: leds: add support for led triggers on phy link state change Zach Brown (2): skge: Rename LED_OFF and LED_ON in marvel skge driver to avoid conflicts

[PATCH v4 3/3] net: phy: leds: add support for led triggers on phy link state change

f LEDs to represent link state changes on the phy. Signed-off-by: Josh Cartwright <josh.cartwri...@ni.com> Signed-off-by: Nathan Sullivan <nathan.sulli...@ni.com> Signed-off-by: Zach Brown <zach.br...@ni.com> --- drivers/net/phy/Kconfig| 13 +++- drivers/net/phy/

[PATCH v4 2/3] net: phy: Encapsulate actions performed during link state changes into function phy_adjust_link

ore. Actions that should occur whenever the phy link is adjusted can now be added to the phy_adjust_link function. Signed-off-by: Zach Brown <zach.br...@ni.com> --- drivers/net/phy/phy.c | 21 + 1 file changed, 13 insertions(+), 8 deletions(-) diff --git a/drivers/net/phy/phy.c

[RFC v3 2/3] phy: Encapsulate actions performed during link state changes into function phy_adjust_link

ore. Actions that should occur whenever the phy link is adjusted can now be added to the phy_adjust_link function. Signed-off-by: Zach Brown <zach.br...@ni.com> --- drivers/net/phy/phy.c | 21 + 1 file changed, 13 insertions(+), 8 deletions(-) diff --git a/drivers/net/phy/phy.c

[RFC v3 1/3] skge: Rename LED_OFF and LED_ON in marvel skge driver to avoid conflicts with leds namespace

changed LED_ON to LED_REG_ON to avoid possible future conflict and for consistency. Signed-off-by: Zach Brown <zach.br...@ni.com> --- drivers/net/ethernet/marvell/skge.c | 6 +++--- drivers/net/ethernet/marvell/skge.h | 4 ++-- 2 files changed, 5 insertions(+), 5 deletions(-) diff --git a/d

[PATCH 0/3] Add support for led triggers on phy link state change

and improve consistency. * Dropped rtl8712 patch that was accepted separately. Josh Cartwright (1): phy,leds: add support for led triggers on phy link state change Zach Brown (2): skge: Change LED_OFF to LED_REG_OFF in marvel skge driver to avoid conflicts with leds namespace phy: Encapsulate

[RFC v3 3/3] phy,leds: add support for led triggers on phy link state change

f LEDs to represent link state changes on the phy. Signed-off-by: Josh Cartwright <josh.cartwri...@ni.com> Signed-off-by: Nathan Sullivan <nathan.sulli...@ni.com> Signed-off-by: Zach Brown <zach.br...@ni.com> --- drivers/net/phy/Kconfig| 13 +++- drivers/net/phy/

[RFC v2 1/4] skge: Change LED_OFF to LED_REG_OFF in marvel skge driver to avoid conflicts with leds namespace

Signed-off-by: Zach Brown <zach.br...@ni.com> --- drivers/net/ethernet/marvell/skge.c | 4 ++-- drivers/net/ethernet/marvell/skge.h | 2 +- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/net/ethernet/marvell/skge.c b/drivers/net/ethernet/marvell/skge.c index 7173836..f

[RFC v2 2/4] staging: rtl8712: Change _LED_STATE enum in rtl871x driver to avoid conflicts with LED namespace

future collision LED_ON was changed to LED_STATE_ON as well. Signed-off-by: Zach Brown <zach.br...@ni.com> --- drivers/staging/rtl8712/rtl8712_led.c | 388 +- 1 file changed, 194 insertions(+), 194 deletions(-) diff --git a/drivers/staging/rtl8712/rtl8712_le

[RFC v2 0/4] Add support for led triggers on phy link state change

Zach Brown (3): skge: Change LED_OFF to LED_REG_OFF in marvel skge driver to avoid conflicts with leds namespace staging: rtl8712: Change _LED_STATE enum in rtl871x driver to avoid conflicts with LED namespace phy: Encapsulate actions performed during link state changes into function

[RFC v2 4/4] phy,leds: add support for led triggers on phy link state change

f LEDs to represent link state changes on the phy. Signed-off-by: Josh Cartwright <josh.cartwri...@ni.com> Signed-off-by: Nathan Sullivan <nathan.sulli...@ni.com> Signed-off-by: Zach Brown <zach.br...@ni.com> --- drivers/net/phy/Kconfig| 13 +++- drivers/net/phy/

[RFC v2 3/4] phy: Encapsulate actions performed during link state changes into function phy_adjust_link

ore. Actions that should occur whenever the phy link is adjusted can now be added to the phy_adjust_link function. Signed-off-by: Zach Brown <zach.br...@ni.com> --- drivers/net/phy/phy.c | 21 + 1 file changed, 13 insertions(+), 8 deletions(-) diff --git a/drivers/net/ph

Re: [RFC 3/3] phy,leds: add support for led triggers on phy link state change

On Wed, Sep 14, 2016 at 04:16:15PM -0700, Florian Fainelli wrote: > On 09/14/2016 02:55 PM, Zach Brown wrote: > > From: Josh Cartwright <josh.cartwri...@ni.com> > > > > Create an option CONFIG_LED_TRIGGER_PHY (default n), which will > > create a set of led t

[RFC 1/3] skge: Change LED_OFF to LED_REG_OFF in marvel skge driver to avoid conflicts with leds namespace

Signed-off-by: Zach Brown <zach.br...@ni.com> --- drivers/net/ethernet/marvell/skge.c | 4 ++-- drivers/net/ethernet/marvell/skge.h | 2 +- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/net/ethernet/marvell/skge.c b/drivers/net/ethernet/marvell/skge.c index 7173836..f

[RFC 2/3] staging: rtl8712: Change _LED_STATE enum in rtl871x driver to avoid conflicts with LED namespace

Adding led support for phy causes namespace conflicts for some phy drivers. The rtl871 driver declared an enum for representing LED states. The enum contains constant LED_OFF which conflicted with declartation found in linux/leds.h. LED_OFF changed to LED_STATE_OFF Signed-off-by: Zach Brown

[RFC 3/3] phy,leds: add support for led triggers on phy link state change

f LEDs to represent link state changes on the phy. Signed-off-by: Josh Cartwright <josh.cartwri...@ni.com> Signed-off-by: Nathan Sullivan <nathan.sulli...@ni.com> Signed-off-by: Zach Brown <zach.br...@ni.com> --- drivers/net/phy/Kconfig| 12 drivers/net/phy/

[RFC 0/3] Add support for led triggers on phy link state change

to do so. Josh Cartwright (1): phy,leds: add support for led triggers on phy link state change Zach Brown (2): skge: Change LED_OFF to LED_REG_OFF in marvel skge driver to avoid conflicts with leds namespace staging: rtl8712: Change _LED_STATE enum in rtl871x driver to avoid conflicts

[PATCH] phy, leds: add support for led triggers on phy link state change

allow a set of LEDs to represent link state changes on the phy. Signed-off-by: Josh Cartwright <josh.cartwri...@ni.com> Signed-off-by: Nathan Sullivan <nathan.sulli...@ni.com> Signed-off-by: Zach Brown <zach.br...@ni.com> --- drivers/net/phy/Kconfig| 12 +

[PATCH] sctp: lock_sock_nested in sctp_sock_migrate

+0xdf/0x1e3 [sctp] This patch tells lockdep that this locking is safe by using lock_sock_nested(). Signed-off-by: Zach Brown [EMAIL PROTECTED] diff -r 8adcfdf2545b net/sctp/socket.c --- a/net/sctp/socket.c Fri Jun 22 11:11:33 2007 -0700 +++ b/net/sctp/socket.c Fri Jun 22 15:05:22 2007 -0700

Re: [take9 1/2] kevent: Core files.

+ for (i=0; iARRAY_SIZE(u-kevent_list); ++i) for (i = 0; i ARRAY_SIZE(u-kevent_list); i++) Ugh, no. It reduces readability due to exessive number of spaces. Ihavetoverystronglydisagree. - z - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message

Re: [take9 0/2] kevent: Generic event handling mechanism.

It is done by scripts using list of files generated by git-diff, but I can reformat them to be in a way: Perhaps you should think about maintaining them as an explicit series of patches, say with quilt or mq, instead of as one repository that you try and cut up into separate patches. - z - To

Re: [take5 0/4] kevent: Generic event handling mechanism.

Evgeniy Polyakov wrote: Generic event handling mechanism. I send this patchset for comments and review, it still contains AIO and aio_sendfile() implementation on top of get_block() abstraction, which was decided to postpone for a while (it is simpler right now to generate patchset as a

Re: [take5 1/4] kevent: Core files.

+++ b/include/linux/kevent.h ... +#ifdef CONFIG_KEVENT_SOCKET + +extern struct file_operations socket_file_ops; This doesn't build because socket_file_ops was left static in net/socket.c. In any case, kevent.h has no business exposing socket_file_ops to users of the kevent api just so

Re: [RFC 1/4] kevent: core files.

I do not think if we do a ring buffer that events should be obtainable via a syscall at all. Rather, I think this system call should be purely sleep until ring is not empty. Mmm, yeah, of course. That's much simpler. I'm looking forward to Evgeniy's next patch set. The ring buffer size,

Re: [take2 1/4] kevent: core files.

OK, here's some of my reactions to the core part. +#define KEVENT_SOCKET0 +#define KEVENT_INODE 1 +#define KEVENT_TIMER 2 +#define KEVENT_POLL 3 +#define KEVENT_NAIO 4 +#define KEVENT_AIO 5 I guess we can't really avoid some form

Re: [RFC 1/4] kevent: core files.

I completely agree that existing kevent interface is not the best, so I'm opened for any suggestions. Should kevent creation/removing/modification be separated too? Yeah, I think so. Hmm, it looks like I'm lost here... Yeah, it seems my description might not have sunk in :). We're giving

Re: [RFC 1/4] kevent: core files.

Things were like that at one point in time, but file descriptors turn out to introduce a huge gaping security hole with SUID programs. The problem is that any event context is closely tied to the address space of the thread issuing the syscalls, and file descriptors do not have this close

Re: [RFC 1/4] kevent: core files.

So, I'm going to create kevent_create/destroy/control and kevent_get_events() Or any better names? Yeah, that sounds good. Some events are impossible to create in userspace (like timer notification, which requires timer start and check when timer completed). We're not talking about

Re: [RFC 1/4] kevent: core files.

Evgeniy Polyakov wrote: On Fri, Jul 28, 2006 at 12:01:28PM -0700, Zach Brown ([EMAIL PROTECTED]) wrote: Clearly we should port httpd to kevents and take some measurements :) One of my main kevent benchmarks (socket notifications for accept/receive) is handmade http server. Yeah, so I

Re: [RFC 1/4] kevent: core files.

Clearly we should port httpd to kevents and take some measurements :) oh, I see, I forgot the 't' in 'thttpd'. My mistake. - z - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at

Re: [3/4] kevent: AIO, aio_sendfile() implementation.

Suparna mentioned at Ulrich wants us to concentrate on kernel-side support, so that he can look at glibc side of things (along with other work he is already doing). So, if we can get an agreement on what kind of kernel support is needed - we can focus our efforts on kernel side first and

Re: [RFC 1/4] kevent: core files.

I like this work a lot, as I've stated before. Yeah, me too. I think we're very close to having a workable system here. A few weeks of some restructuring and we all might be very happy. The data structures look like they will scale well and it takes care of all the limitations that

Re: [RFC 1/4] kevent: core files.

int kevent_getevents(int event_fd, struct ukevent *events, int min_events, int max_events, struct timeval *timeout); I used only one syscall for all operations, above syscall is essentially what kevent_user_wait() does. Essentially, yes, but the differences

Re: [RFC 1/4] kevent: core files.

int kevent_getevents(int event_fd, struct ukevent *events, int min_events, int max_events, struct timeval *timeout); You've just reinvented io_getevents(). Well, that's certainly one inflammatory way to put it. I would describe it as suggesting that the

Re: [PATCHv2] IB/mthca: comment fix

Michael S. Tsirkin wrote: OK, this is fine with both Arjan van de Ven and Roland Dreier, so - Andrew, could you take this into -mm please? Signed-off-by: Michael S. Tsirkin [EMAIL PROTECTED] Acked-by: Zach Brown [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe

Re: tcp_slow_start_after_idle

David Miller wrote: Bringing back up this old topic: http://marc.theaimsgroup.com/?l=linux-netdevm=114564962420171w=2 I've decided to add this tunable to the net-2.6.18 tree, patch below. Nice, thanks for the heads-up. I'll pass the notice on to the guys who were asking about this

Re: tune back idle cwnd closing?

Given that RFC2681 is Experimental (and I'm not aware of any current efforts in the IETF to push it to the standard track), IHMO it would not be inappropriate to make this behavior controlled via sysctl. I have to respectfully disagree. OK, thanks for taking the time to look at it. - z

tune back idle cwnd closing?

My apologies if this is a FAQ, I couldn't find it in the archives. We have some dudes who are syncing large amounts of data across a dedicated long fat pipe at somewhat irregular intervals that are, sadly, longer than the rto. They feel the pain of having to reopen the window between

Re: [RFC][PATCH] Avoid multi-page allocs for large mtu datagram sends

Herbert Xu wrote: On Wed, Apr 05, 2006 at 05:51:02PM +, Zach Brown wrote: 2) I changed the final-frag test to be length + fraggap as the math later on seemed to match that.. is that OK? Yes that's a real bug introduced by a previous rework. Could you please split that off

Re: ipfrag calculating its hash outside lock

a stale hash value and might not find previous fragments of their datagram. This matches the previous patch to IPv4. Signed-off-by: Zach Brown [EMAIL PROTECTED] Index: 2.6.17-rc1-mm1-fraghash/net/ipv6/reassembly.c === --- 2.6.17-rc1-mm1

ipfrag calculating its hash outside lock

I noticed that ip_find() calculates the hash bucket for the incoming fragment using ipfrag_hash_rnd outside the ipfrag_lock. So it can race with ipfrag_secret_rebuild() and end up putting a frag in the previous bucket instead of the new bucket that ipfrag_secret_rebuild() has put the previous

Re: ipfrag calculating its hash outside lock

I think this is the best way to go. Then we don't need to think about it, and frankly I think the recheck hash rnd after getting lock idea would turn out to be more expensive :) OK :). I'll throw that together.. - z - To unsubscribe from this list: send the line unsubscribe netdev in the

[RFC][PATCH] Avoid multi-page allocs for large mtu datagram sends

OK, here's a stronger attempt. I might have gone a little wild with the patch description :). Two questions and a data point: 1) It occurs to me as I write this that I don't know how the trailer_len stuff works if a fragments final data bits are page frags in the skb. Did I screw this

Re: [RFC][PATCH] avoid multi page allocs in ip_append_data

What exactly are you trying to do with that watch out for trailer_len thing where you subtract 2 from datalen? The danger is in chosing a datalen that just fits in a page but then finding that it == length and so we want to add on trailer_len, bringing the alloc back over a page. The logic

Re: [RFC][PATCH] avoid multi page allocs in ip_append_data

For the else clause wouldn't we be counting fragheaderlen twice if the multi page if falls through above despite NETIF_F_SG being true? Looks like, yeah. I'll fix up and resend. Thanks for the sharp eyes. - z - To unsubscribe from this list: send the line unsubscribe netdev in the body of a

[RFC][PATCH] avoid multi page allocs in ip_append_data

We've had reports from customers of boxes with a week's uptime and 32k MTUs getting failed order-3 allocs under: udp_sendmsg .. ip_append_data .. {sock_wmalloc, sock_alloc_send_skb} I came up with the following which seems to do the right thing in a trivial test. It clamps the size of

Re: [RFC][PATCH] avoid multi page allocs in ip_append_data

+ /* watch out for trailer_len */ + if (datalen == length) + datalen -= 2; Hmm, that probably needs to be more careful :/ - z - To unsubscribe from this list: send the line unsubscribe netdev in the

Re: ES-API?

Yes, this is how these standard groups try to force a particular approach to high speed networking down everyone's throats. Yeah, from what I understand there's a lot of RDMA/IB people involved in that ``ICSC'' thing. I think we'll pass on this stuff. OK, so noted. Thanks. - z - To

Re: ES-API?

Also, the following scares me: This specification has not been verified for avoidance of possible third-party proprietary rights. In implementing this specification, usual procedures to ensure the respect of possible third-party intellectual property rights should be followed. Scary,

Re: [PATCH] RP filter support for IPv6, kernel 2.6.15 (fwd)

@@ -151,6 +152,7 @@ /* index values for the variables in ipv6_devconf */ enum { DEVCONF_FORWARDING = 0, + DEVCONF_RPFILTER = 0, DEVCONF_HOPLIMIT, DEVCONF_MTU6, DEVCONF_ACCEPT_RA, That doesn't look quite right :) - z - To unsubscribe from this