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
---
v2:
* Check phy_intterupt_is_valid before calling conf
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
---
drivers/net/phy/micrel.c | 2 ++
1 file changed, 2 in
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
Acked-by: Xander Huff
Acked-by: Kyle Roeschley
---
ers_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
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
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 with
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
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
---
drivers/net/ethernet/cadence/macb.c | 59 +
1 file changed, 59 insertions(+)
diff --git
respective
replacements.
Signed-off-by: Zach Brown
---
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/macb.c
b/drivers/net/ethernet
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
>
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
---
drivers/net/phy/phy.c | 21 +
1 file changed, 13 insertions(+), 8 deletions(-)
diff --git a/drivers/net/phy/phy.c b/drivers/net/phy/ph
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
Signed-off-by: Nathan Sullivan
Signed-off-by: Zach Brown
---
drivers/net/phy/Kconfig| 13
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
changed LED_ON to LED_REG_ON to avoid possible future conflict and
for consistency.
Signed-off-by: Zach Brown
---
drivers/net/ethernet/marvell/skge.c | 6 +++---
drivers/net/ethernet/marvell/skge.h | 4 ++--
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ethernet
phy_supported_speeds provides a means to get a list of all the speeds a
phy device currently supports.
Signed-off-by: Zach Brown
---
drivers/net/phy/phy.c | 35 +++
include/linux/phy.h | 15 +++
2 files changed, 50 insertions(+)
diff --git a
On Thu, Oct 13, 2016 at 10:46:34AM -0400, David Miller wrote:
> From: Zach Brown
> Date: Tue, 11 Oct 2016 15:26:20 -0500
>
> > From: Josh Cartwright
> >
> > Create an option CONFIG_LED_TRIGGER_PHY (default n), which will
> > create a set of led triggers for eac
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)
>
> This
On Tue, Oct 11, 2016 at 02:14:07PM -0700, Stephen Hemminger wrote:
> On Tue, 11 Oct 2016 15:26:18 -0500
> Zach Brown wrote:
>
> > Adding led support for phy causes namespace conflicts for some
> > phy drivers.
> >
> > The marvel skge driver declared an enum for re
changed LED_ON to LED_REG_ON to avoid possible future conflict and
for consistency.
Signed-off-by: Zach Brown
---
drivers/net/ethernet/marvell/skge.c | 6 +++---
drivers/net/ethernet/marvell/skge.h | 4 ++--
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ethernet
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 with
changes on the phy.
Signed-off-by: Josh Cartwright
Signed-off-by: Nathan Sullivan
Signed-off-by: Zach Brown
---
drivers/net/phy/Kconfig| 13 +++-
drivers/net/phy/Makefile | 1 +
drivers/net/phy/phy.c | 1 +
drivers/net/phy/phy_device.c | 4
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
---
drivers/net/phy/phy.c | 21 +
1 file changed, 13 insertions(+), 8 deletions(-)
diff --git a/drivers/net/phy/phy.c b/drivers/net/phy/ph
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
---
drivers/net/phy/phy.c | 21 +
1 file changed, 13 insertions(+), 8 deletions(-)
diff --git a/drivers/net/phy/phy.c b/drivers/net/phy/ph
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
changes on the phy.
Signed-off-by: Josh Cartwright
Signed-off-by: Nathan Sullivan
Signed-off-by: Zach Brown
---
drivers/net/phy/Kconfig| 13 +++-
drivers/net/phy/Makefile | 1 +
drivers/net/phy/phy.c | 1 +
drivers/net/phy/phy_device.c | 4
changed LED_ON to LED_REG_ON to avoid possible future conflict and
for consistency.
Signed-off-by: Zach Brown
---
drivers/net/ethernet/marvell/skge.c | 6 +++---
drivers/net/ethernet/marvell/skge.h | 4 ++--
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ethernet
Signed-off-by: Zach Brown
---
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..ff5a087 100644
--- a/drivers
future collision LED_ON was changed to
LED_STATE_ON as well.
Signed-off-by: Zach Brown
---
drivers/staging/rtl8712/rtl8712_led.c | 388 +-
1 file changed, 194 insertions(+), 194 deletions(-)
diff --git a/drivers/staging/rtl8712/rtl8712_led.c
b/drivers/staging
changes on the phy.
Signed-off-by: Josh Cartwright
Signed-off-by: Nathan Sullivan
Signed-off-by: Zach Brown
---
drivers/net/phy/Kconfig| 13 +++-
drivers/net/phy/Makefile | 1 +
drivers/net/phy/phy.c | 1 +
drivers/net/phy/phy_device.c | 4
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
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
---
drivers/net/phy/phy.c | 21 +
1 file changed, 13 insertions(+), 8 deletions(-)
diff --git a/drivers/net/phy/phy.c b/drivers/net/phy/ph
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
> >
> > Create an option CONFIG_LED_TRIGGER_PHY (default n), which will
> > create a set of led triggers for each instantiated PHY de
Signed-off-by: Zach Brown
---
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..ff5a087 100644
--- a/drivers
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
changes on the phy.
Signed-off-by: Josh Cartwright
Signed-off-by: Nathan Sullivan
Signed-off-by: Zach Brown
---
drivers/net/phy/Kconfig| 12
drivers/net/phy/Makefile | 1 +
drivers/net/phy/phy.c | 8 +++
drivers/net/phy/phy_device.c | 4
if is important 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 avoi
link state changes on the phy.
Signed-off-by: Josh Cartwright
Signed-off-by: Nathan Sullivan
Signed-off-by: Zach Brown
---
drivers/net/phy/Kconfig| 12 +
drivers/net/phy/Makefile | 1 +
drivers/net/phy/phy.c | 8 +++
drivers/net/phy/phy_device.c
tp]
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
@@ -6084,8 +6
> 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
-
T
>>> + for (i=0; ikevent_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 to [
> +++ 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
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
> a
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
> 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 s
> Ok, let's do it in the following way:
> I present new version of kevent with new syscalls and fixed issues mentioned
> before, while people look at it we can end up with mapped buffer design.
> Is it ok?
Yeah, that sounds good. I'm looking forward to seeing the next set of
patches :).
- z
-
T
>>> 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 http://vger.kernel.org/maj
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 h
> 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 *c
> 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 cl
> 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
>> 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 t
>> 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 diff
> 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 net
> 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 an
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 thi
David Miller wrote:
> Bringing back up this old topic:
>
> http://marc.theaimsgroup.com/?l=linux-netdev&m=114564962420171&w=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
>> 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
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 transmission
Herbert Xu wrote:
> On Wed, Apr 05, 2006 at 05:51:02PM +0000, 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 y
ad_lock they'd have 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
==
> 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
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 frag
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 up
> 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 o
> 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
> + /* 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
t
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 t
> 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,
> 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 unsu
Hi guys,
I'm hearing noise about the 'Extended Sockets' API in Oracle. It's an
extension to the socket API put together by an industry group that calls
itself the Interconnect Software Consortium and is working in
partnership with the open group. The API adds support for things like
memory regis
> @@ -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 th
71 matches
Mail list logo
