* Re: [PATCH 09/28] Remove ATHEROS_AR231X
From: Sergey Ryazanov @ 2014-02-10 12:05 UTC (permalink / raw)
To: Richard Weinberger, Oleksij Rempel, Jonathan Bither,
OpenWrt Development List
Cc: Hauke Mehrtens, Jiri Slaby, Nick Kossifidis, Luis R. Rodriguez,
John W. Linville, open list:ATHEROS ATH5K WIR...,
open list:ATHEROS ATH5K WIR..., open,
list@hauke-m.de:NETWORKING DRIVERS, open list
In-Reply-To: <52F7DF21.70207@nod.at>
2014-02-10 0:03 GMT+04:00 Richard Weinberger <richard@nod.at>:
> Am 09.02.2014 20:18, schrieb Hauke Mehrtens:
>> On 02/09/2014 07:47 PM, Richard Weinberger wrote:
>>> The symbol is an orphan, get rid of it.
>>>
>>> Signed-off-by: Richard Weinberger <richard@nod.at>
>>> ---
>>> drivers/net/wireless/ath/ath5k/Kconfig | 10 +++++-----
>>> drivers/net/wireless/ath/ath5k/ath5k.h | 28 ----------------------------
>>> drivers/net/wireless/ath/ath5k/base.c | 14 --------------
>>> drivers/net/wireless/ath/ath5k/led.c | 7 -------
>>> 4 files changed, 5 insertions(+), 54 deletions(-)
>>>
>>
>> This code is used in OpenWrt with an out of tree arch code for the
>> Atheros 231x/531x SoC. [0] I do not think anyone is working on adding
>> this code to mainline Linux kernel, because of lack of time/interest.
>
> Sorry, we don't maintain out of tree code.
>
Oleksij, Jonathan do you still working to make ar231x devices work
with upstream, since your posts [1, 2]? Or may be someone from OpenWRT
team would like to add upstream support?
1. https://lkml.org/lkml/2013/5/13/321
2. https://lkml.org/lkml/2013/5/13/358
--
BR,
Sergey
^ permalink raw reply
* Re: [PATCH 0/2] sctp: fix a problem with net_namespace
From: Neil Horman @ 2014-02-10 12:08 UTC (permalink / raw)
To: Wang Weidong; +Cc: davem, vyasevich, dborkman, netdev
In-Reply-To: <52F83FF3.6010307@huawei.com>
On Mon, Feb 10, 2014 at 10:56:51AM +0800, Wang Weidong wrote:
> On 2014/1/28 19:57, Neil Horman wrote:
> > On Tue, Jan 28, 2014 at 04:13:44PM +0800, Wang Weidong wrote:
> >> On 2014/1/27 19:49, Neil Horman wrote:
> >>> On Mon, Jan 27, 2014 at 11:49:01AM +0800, Wang Weidong wrote:
> >>>> fix a problem with net_namespace, and optimize
> >>>> the sctp_sysctl_net_register.
> >>>>
> >>>> Wang Weidong (2):
> >>>> sctp: fix a missed .data initialization
> >>>> sctp: optimize the sctp_sysctl_net_register
> >>>>
> >>>> net/sctp/sysctl.c | 17 ++++++++++-------
> >>>> 1 file changed, 10 insertions(+), 7 deletions(-)
> >>>>
> >>>> --
> >>>> 1.7.12
> >>>>
> >>>>
> >>>>
> >>> I don't see that either of these patches are needed. In sctp_init_net, the
> >>> sctp_hmac_alg pointer gets initalized before calling sctp_sysctl_net_register,
> >>> and sctp_proc_do_hmac_alg is written to specifically expect NULL values, so this
> >>> code may change behavior regarding default cookie selection.
> >>>
> >> Hi Neil,
> >>
> >> Here, I think the sctp_proc_do_hmac_alg will be called only when we change the
> >> /proc/sys/net/cookie_hmac_alg. So add the .data won't effect the default value.
> >> and the data isn't equal to the "cookie_hmac_alg"?
> >>
> >>> This was coded so that poniters to entires in the string table could be used,
> >>> rather than needing to allocate or maintain character buffers. That said, it
> >>> does look like that for loop in sctp_sysctl_register_table might compute an odd
> >>> offset when cloning the table. I think the right fix for that is likely to just
> >>> move the sysctl value initalization in sctp_init_net to below the sysctl
> >>> register function.
> >>>
> >>> Neil
> >>>
> >>
> >> I found the problem is that:
> >> I use "ip netns add netns1/netns2"
> >> In any netns(netns1 or netns2 or init_net) when I change the value of the entry
> >> such as "addip_enable" "max_autoclose" which after the cookie_hmac_alg (contain it),
> >> and the other netns will be effected.
> >>
> >> In sctp_sysctl_net_register, kmemdup does cloning the table. The offset of netns1 and
> >> init_net's clt_table.data is the same as two netns offset. So the for(){...} would do
> >> add the offset for every clt_table.data.
> >>
> >> The code:
> >> for (i = 0; table[i].data; i++)
> >> table[i].data += (char *)(&net->sctp) - (char *)&init_net.sctp;
> >>
> >> And I add a pr_info into the for(){...} in sctp_sysctl_net_register and only print 7 times for each ns.
> >> 7 is the index of "cookie_preserve_enable" which before the "cookie_hmac_alg".
> >>
> >> As the "cookie_hmac_alg" data is NULL, so we can't add offset to the rest, and all the netns use the same
> >> address of clt_table entry after the "cookie_hmac_alg".
> >>
> >> So I think only "move the sysctl value initalization in sctp_init_net to below the sysctl
> >> register function" won't solve the problem, because the problem is at the for() {...}.
> >>
> > I'm sorry, you're right, the kmemdup duplicates the table, not the structure in
> > which the table points to with its .data pointers. I was looking at it
> > backwards.
> >
>
> Hi Neil,
>
> Should I resend "sctp: fix a problem with net_namespace" series again?
>
Not sure. I agree with your assesment on the table adjustments, but I think the
discussion below is holding things up. You probably want to get to the root
cause of whats causing the lockdep issue before that patch goes in
for 1/2 though
Acked-by: Neil Horman <nhorman@tuxdriver.com>
^ permalink raw reply
* Re: [RFC PATCHv2 0/4] Add DT support for fixed PHYs
From: Thomas Petazzoni @ 2014-02-10 12:09 UTC (permalink / raw)
To: Christian Gmeiner
Cc: David S. Miller, netdev@vger.kernel.org, devicetree,
Florian Fainelli, Lior Amsalem, Gregory Clement, Ezequiel Garcia,
linux-arm-kernel@lists.infradead.org, Mark Rutland
In-Reply-To: <CAH9NwWfutp6MitSuG-LNH=0Y0ffewuSawLXJOe2JUL7=tz7BWQ@mail.gmail.com>
Dear Christian Gmeiner,
On Mon, 10 Feb 2014 11:30:30 +0100, Christian Gmeiner wrote:
> >> +1 for the general idea. This really looks good now. I've not much more
> >> to say. Maybe someone from the devicetree corner has a few words for the
> >> binding?
> >>
> >
> > I tested the whole series with an I.MX6D board with the FEC driver:
> > fec 2188000.ethernet eth0: Freescale FEC PHY driver [Generic PHY]
> > (mii_bus:phy_addr=fixed-0:00, irq=-1)
> >
> > For me binding looks nice and I hope to see this patch series in 3.13.
> >
> > Tested-by: Christian Gmeiner <christian.gmeiner@gmail.com>
>
> Is there any update on this patch series?
I'll try to send a new version in the next few days. It's still part of
my TODO list.
Thanks!
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply
* Re: [PATCH 1/2] mm/vmalloc: export is_vmalloc_or_module_addr
From: Mel Gorman @ 2014-02-10 12:10 UTC (permalink / raw)
To: Linus Torvalds
Cc: Dave Kleikamp, Richard Yao, Andrew Morton, Rik van Riel,
Eric Van Hensbergen, Ron Minnich, Latchesar Ionkov,
David S. Miller, V9FS Develooper Mailing List,
Linux Netdev Mailing List, Linux Kernel Mailing List,
Aneesh Kumar K.V, Will Deacon, Christopher Covington,
Matthew Thode
In-Reply-To: <CA+55aFx8TzOnW9xPFA4Ox-yFiSUo=cEqeQUmgw_JWjDNEZep8Q@mail.gmail.com>
On Sat, Feb 08, 2014 at 11:45:53AM -0800, Linus Torvalds wrote:
> On Sat, Feb 8, 2014 at 11:12 AM, Richard Yao <ryao@gentoo.org> wrote:
> > 9p-virtio needs is_vmalloc_or_module_addr exported before a patch can be
> > merged to prevent the virtio zero-copy routines from triggering a
> > hypervisor page fault when loading kernel modules:
> >
> > https://groups.google.com/forum/#!topic/linux.kernel/eRR7AyLE29Y
> >
> > Without this export, the kernel build breaks with that patch applied and
> > CONFIG_NET_9P_VIRTIO=m. With this export in place, all is well.
>
> I absolutely *detest* this patch.
>
> Not so much because is_vmalloc_or_module_addr() should never be used,
> but because the particular use in question is pure and utter garbage.
>
> There are valid reasons to use "is_vmalloc_or_module_addr()", but
> those are along the lines of drivers/char/mem.c, which says "return
> -ENXIO for this crap".
>
> And btw, that horrid crap called "kmap_to_page()" needs to die too.
> When is it *ever* valid to use a kmap'ed page for IO? Here's a clue:
> never.
>
> <SNIP>
>
> Those *disgusting* get_kernel_page[s]() functions came with a
> commentary about "The initial user is expected to be NFS.." and that
> is still the *only* user. The fact that *everybody* else has been able
> to avoid that crap should tell us something.
kmap_to_page, get_kernel_page and the NFS user for it are already scheduled
for death. Dave Kleikamp has been working on a series "Issue O_DIRECT aio
using bio_vec" that replaces what NFS currently does with something far
more sane. The series does not remove the helpers on top, probably because
of the 9P use of it, but if that was changed then the helpers would finally
die. I'm not sure why Dave's series never got merged so added him to the
cc to find out.
--
Mel Gorman
SUSE Labs
^ permalink raw reply
* Re: [PATCH 09/28] Remove ATHEROS_AR231X
From: Oleksij Rempel @ 2014-02-10 12:17 UTC (permalink / raw)
To: Sergey Ryazanov, Richard Weinberger, Jonathan Bither,
OpenWrt Development List
Cc: Hauke Mehrtens, Jiri Slaby, Nick Kossifidis, Luis R. Rodriguez,
John W. Linville, open list:ATHEROS ATH5K WIR...,
open list:ATHEROS ATH5K WIR..., open,
list@hauke-m.de:NETWORKING DRIVERS, open list,
antonynpavlov@gmail.com
In-Reply-To: <CAHNKnsS7Mv4ZhBWZa53go9L9nZimJ7_FG5HFJ9C3kkGMAEz-mA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1621 bytes --]
Am 10.02.2014 13:05, schrieb Sergey Ryazanov:
> 2014-02-10 0:03 GMT+04:00 Richard Weinberger <richard@nod.at>:
>> Am 09.02.2014 20:18, schrieb Hauke Mehrtens:
>>> On 02/09/2014 07:47 PM, Richard Weinberger wrote:
>>>> The symbol is an orphan, get rid of it.
>>>>
>>>> Signed-off-by: Richard Weinberger <richard@nod.at>
>>>> ---
>>>> drivers/net/wireless/ath/ath5k/Kconfig | 10 +++++-----
>>>> drivers/net/wireless/ath/ath5k/ath5k.h | 28 ----------------------------
>>>> drivers/net/wireless/ath/ath5k/base.c | 14 --------------
>>>> drivers/net/wireless/ath/ath5k/led.c | 7 -------
>>>> 4 files changed, 5 insertions(+), 54 deletions(-)
>>>>
>>>
>>> This code is used in OpenWrt with an out of tree arch code for the
>>> Atheros 231x/531x SoC. [0] I do not think anyone is working on adding
>>> this code to mainline Linux kernel, because of lack of time/interest.
>>
>> Sorry, we don't maintain out of tree code.
>>
>
> Oleksij, Jonathan do you still working to make ar231x devices work
> with upstream, since your posts [1, 2]? Or may be someone from OpenWRT
> team would like to add upstream support?
>
> 1. https://lkml.org/lkml/2013/5/13/321
> 2. https://lkml.org/lkml/2013/5/13/358
>
Hi,
my current target was to provide barebox and openocd support.
- ar2313 is already upstream on barebox.
- ar2315-2318 (barebox) awaiting review by Anthony Pavlov.
- openocd (EJTAG) support is ready and i'll push it ASUP.
I hope Jonathan do kernel part. If not, i can provide some work, since i
have testing boards and expiriance on this hardware.
--
Regards,
Oleksij
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 278 bytes --]
^ permalink raw reply
* Re: [PATCH 1/2 v2] usbnet: fix bad header length bug
From: Oliver Neukum @ 2014-02-10 12:22 UTC (permalink / raw)
To: Emil Goode
Cc: David S. Miller, Ming Lei, Mark Brown, Jeff Kirsher, Glen Turner,
netdev-u79uwXL29TY76Z2rM5mHXA, linux-usb-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20140210115812.GA4278@lianli>
On Mon, 2014-02-10 at 13:00 +0100, Emil Goode wrote:
> On Mon, Feb 10, 2014 at 07:40:58AM +0100, Oliver Neukum wrote:
> > On Mon, 2014-02-10 at 00:06 +0100, Emil Goode wrote:
> > > The AX88772B occasionally send rx packets that cross urb boundaries
> > > and the remaining partial packet is sent with no hardware header.
> > > When the buffer with a partial packet is of less number of octets
> > > than the value of hard_header_len the buffer is discarded by the
> > > usbnet module. This is causing dropped packages and error messages
> > > in dmesg.
> > >
> > > This can be reproduced by using ping with a packet size
> > > between 1965-1976.
> >
> > Well, then how about simply removing the check?
> > It seems to have outlived its usefulness.
> >
> > Regards
> > Oliver
> >
> >
>
> I did consider that and I think it is probably the best thing to do.
> However, I think the removal of the check could have negative effects
> on the other minidrivers, at least the qmi_wwan minidriver explicitly
> states that it is depending on this check to be made in rx_complete().
<censored>. Oh well. But how about merging it with FLAG_MULTI_PACKET?
I really don't want to add more flags. There is a point where enough
flags make absurd having a common code. We are closing in on that point.
Regards
Oliver
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 2/2] net: ip, ipv6: handle gso skbs in forwarding path
From: Florian Westphal @ 2014-02-10 12:23 UTC (permalink / raw)
To: Herbert Xu; +Cc: Eric Dumazet, Florian Westphal, netdev
In-Reply-To: <20140209025504.GB17395@gondor.apana.org.au>
Herbert Xu <herbert@gondor.apana.org.au> wrote:
> > > static void ip_gso_adjust_seglen(struct sk_buff *skb)
> > > {
> > > unsigned int mtu;
> > >
> > > if (!skb_is_gso(skb))
> > > return;
> > >
> > > mtu = ip_dst_mtu_maybe_forward(skb_dst(skb), true);
> > > skb_shinfo(skb)->gso_size = mtu - sizeof(struct iphdr);
> > > }
> > >
> > > But this yields
> > >
> > > [ 28.644776] kernel BUG at net/net/core/skbuff.c:2984!
> >
> > Yep, lets CC Herbert Xu, as he 'owns' skb_segment()
>
> IMHO we should just stop merging ~DF packets altogether, at least
> for TCP.
Eric, you added DF aggregation in db8caf3dbc77599dc90f4ea0a803cd1d97116f30
(gro: should aggregate frames without DF).
I guess you don't want to revert this commit?
Any other ideas?
skb_gso_segment() is already very complex, I don't want to add more code
to it. And that seems unavoidable if we need to de-couple nr_frags and
gso_size.
^ permalink raw reply
* Re: [PATCH 2/2] net: ip, ipv6: handle gso skbs in forwarding path
From: Herbert Xu @ 2014-02-10 12:31 UTC (permalink / raw)
To: Florian Westphal; +Cc: Eric Dumazet, netdev
In-Reply-To: <20140210122331.GA25153@breakpoint.cc>
On Mon, Feb 10, 2014 at 01:23:31PM +0100, Florian Westphal wrote:
> Herbert Xu <herbert@gondor.apana.org.au> wrote:
> > > > static void ip_gso_adjust_seglen(struct sk_buff *skb)
> > > > {
> > > > unsigned int mtu;
> > > >
> > > > if (!skb_is_gso(skb))
> > > > return;
> > > >
> > > > mtu = ip_dst_mtu_maybe_forward(skb_dst(skb), true);
> > > > skb_shinfo(skb)->gso_size = mtu - sizeof(struct iphdr);
> > > > }
> > > >
> > > > But this yields
> > > >
> > > > [ 28.644776] kernel BUG at net/net/core/skbuff.c:2984!
> > >
> > > Yep, lets CC Herbert Xu, as he 'owns' skb_segment()
> >
> > IMHO we should just stop merging ~DF packets altogether, at least
> > for TCP.
>
> Eric, you added DF aggregation in db8caf3dbc77599dc90f4ea0a803cd1d97116f30
> (gro: should aggregate frames without DF).
>
> I guess you don't want to revert this commit?
> Any other ideas?
>
> skb_gso_segment() is already very complex, I don't want to add more code
> to it. And that seems unavoidable if we need to de-couple nr_frags and
> gso_size.
I don't think adding all this complexity just to be able to
aggregate ~DF packets (which are just wrong to begin with) is
worth it.
If aggregating ~DF packets was a one-liner then sure, but there
is a reason why I didn't aggregate them in the first place and
you've found it :)
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH 09/28] Remove ATHEROS_AR231X
From: Sergey Ryazanov @ 2014-02-10 12:38 UTC (permalink / raw)
To: Oleksij Rempel
Cc: Richard Weinberger, Jonathan Bither, OpenWrt Development List,
Hauke Mehrtens, Jiri Slaby, Nick Kossifidis, Luis R. Rodriguez,
John W. Linville, open list:ATHEROS ATH5K WIR...,
open list:ATHEROS ATH5K WIR..., open,
list@hauke-m.de:NETWORKING DRIVERS, open list,
antonynpavlov@gmail.com
In-Reply-To: <52F8C373.9060108@rempel-privat.de>
2014-02-10 16:17 GMT+04:00 Oleksij Rempel <linux@rempel-privat.de>:
> Am 10.02.2014 13:05, schrieb Sergey Ryazanov:
>> 2014-02-10 0:03 GMT+04:00 Richard Weinberger <richard@nod.at>:
>>> Am 09.02.2014 20:18, schrieb Hauke Mehrtens:
>>>> On 02/09/2014 07:47 PM, Richard Weinberger wrote:
>>>>> The symbol is an orphan, get rid of it.
>>>>>
>>>>> Signed-off-by: Richard Weinberger <richard@nod.at>
>>>>> ---
>>>>> drivers/net/wireless/ath/ath5k/Kconfig | 10 +++++-----
>>>>> drivers/net/wireless/ath/ath5k/ath5k.h | 28 ----------------------------
>>>>> drivers/net/wireless/ath/ath5k/base.c | 14 --------------
>>>>> drivers/net/wireless/ath/ath5k/led.c | 7 -------
>>>>> 4 files changed, 5 insertions(+), 54 deletions(-)
>>>>>
>>>>
>>>> This code is used in OpenWrt with an out of tree arch code for the
>>>> Atheros 231x/531x SoC. [0] I do not think anyone is working on adding
>>>> this code to mainline Linux kernel, because of lack of time/interest.
>>>
>>> Sorry, we don't maintain out of tree code.
>>>
>>
>> Oleksij, Jonathan do you still working to make ar231x devices work
>> with upstream, since your posts [1, 2]? Or may be someone from OpenWRT
>> team would like to add upstream support?
>>
>> 1. https://lkml.org/lkml/2013/5/13/321
>> 2. https://lkml.org/lkml/2013/5/13/358
>>
>
> Hi,
> my current target was to provide barebox and openocd support.
> - ar2313 is already upstream on barebox.
> - ar2315-2318 (barebox) awaiting review by Anthony Pavlov.
> - openocd (EJTAG) support is ready and i'll push it ASUP.
>
WOW, Impressive.
> I hope Jonathan do kernel part. If not, i can provide some work, since i
> have testing boards and expiriance on this hardware.
>
If you need, I can test kernel part, or even do some porting work. I
have some AR231x based boards, e.g. Ubnt LS2 and NS2.
--
BR,
Sergey
^ permalink raw reply
* RE: [PATCH 1/2 v2] usbnet: fix bad header length bug
From: David Laight @ 2014-02-10 12:39 UTC (permalink / raw)
To: 'Oliver Neukum', Emil Goode
Cc: David S. Miller, Ming Lei, Mark Brown, Jeff Kirsher, Glen Turner,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <1392034947.2082.30.camel-B2T3B9s34ElbnMAlSieJcQ@public.gmane.org>
From: Oliver Neukum
> <censored>. Oh well. But how about merging it with FLAG_MULTI_PACKET?
> I really don't want to add more flags. There is a point where enough
> flags make absurd having a common code. We are closing in on that point.
Any sub-driver that supports multi-packet either has to use stupidly
long URB and/or set the rx_urb_size to a multiple of the usb transfer
size.
It will also have to detect illegal short headers.
Actually it might be worth double-checking the encapsulations used.
IIRC the ax88179_178a uses different headers for tx and rx.
So there might be some that support multi-packet but still have
a short(ish) limit on the bulk receive size (before the short fragment).
I'm sat at the wrong desk to look at the code...
David
^ permalink raw reply
* Re: [PATCH 2/2] net: ip, ipv6: handle gso skbs in forwarding path
From: Florian Westphal @ 2014-02-10 12:43 UTC (permalink / raw)
To: Herbert Xu; +Cc: Florian Westphal, Eric Dumazet, netdev
In-Reply-To: <20140210123124.GA28752@gondor.apana.org.au>
Herbert Xu <herbert@gondor.apana.org.au> wrote:
> On Mon, Feb 10, 2014 at 01:23:31PM +0100, Florian Westphal wrote:
> > Herbert Xu <herbert@gondor.apana.org.au> wrote:
> > > > > static void ip_gso_adjust_seglen(struct sk_buff *skb)
> > > > > {
> > > > > unsigned int mtu;
> > > > >
> > > > > if (!skb_is_gso(skb))
> > > > > return;
> > > > >
> > > > > mtu = ip_dst_mtu_maybe_forward(skb_dst(skb), true);
> > > > > skb_shinfo(skb)->gso_size = mtu - sizeof(struct iphdr);
> > > > > }
> > > > >
> > > > > But this yields
> > > > >
> > > > > [ 28.644776] kernel BUG at net/net/core/skbuff.c:2984!
> > > >
> > > > Yep, lets CC Herbert Xu, as he 'owns' skb_segment()
> > >
> > > IMHO we should just stop merging ~DF packets altogether, at least
> > > for TCP.
> >
> > Eric, you added DF aggregation in db8caf3dbc77599dc90f4ea0a803cd1d97116f30
> > (gro: should aggregate frames without DF).
> >
> > I guess you don't want to revert this commit?
> > Any other ideas?
> >
> > skb_gso_segment() is already very complex, I don't want to add more code
> > to it. And that seems unavoidable if we need to de-couple nr_frags and
> > gso_size.
>
> I don't think adding all this complexity just to be able to
> aggregate ~DF packets (which are just wrong to begin with) is
> worth it.
>
> If aggregating ~DF packets was a one-liner then sure, but there
> is a reason why I didn't aggregate them in the first place and
> you've found it :)
Well we could go with my original patch that will do software
segmentation on ~DF packets in the forwarding path if the outmtu is too
small for the individual packets. The output path then simply
creates fragments.
Eric suggested to shrink gso_size instead to avoid segmentation+fragments.
I think its nice idea, but skb_gso_segment makes certain assumptions about
nr_frags and gso_size (it can't handle frag size > desired mss).
Hannes pointed out that we'd also need to deal with
SKB_MAX_FRAGS * gso_size exceeding fragments.
Quite frankly, I'd prefer to go with
skb_gso_segment(skb, features & ~NETIF_F_GSO_MASK);
The scenario is rare anyway given the number of bug reports (or lack
thereof) about '~DF tcp doesn't work with gro in fwd path when output
mtu is too small'.
Its not like this could never be improved later on.
Best regards,
Florian
^ permalink raw reply
* Re: [PATCH 2/2] net: ip, ipv6: handle gso skbs in forwarding path
From: Herbert Xu @ 2014-02-10 12:50 UTC (permalink / raw)
To: Florian Westphal; +Cc: Eric Dumazet, netdev
In-Reply-To: <20140210124346.GA6329@breakpoint.cc>
On Mon, Feb 10, 2014 at 01:43:46PM +0100, Florian Westphal wrote:
>
> Eric suggested to shrink gso_size instead to avoid segmentation+fragments.
> I think its nice idea, but skb_gso_segment makes certain assumptions about
> nr_frags and gso_size (it can't handle frag size > desired mss).
This breaks the most important assumption behind GRO which is
to preserve end-to-end connectivity. Resegmenting packets as
suggested on a router/bridge is just wrong.
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH/RESEND] 3c59x: Remove unused pointer in vortex_eisa_cleanup()
From: Steffen Klassert @ 2014-02-10 12:50 UTC (permalink / raw)
To: Christian Engelmayer; +Cc: netdev
In-Reply-To: <20140208201023.731538cf@spike>
On Sat, Feb 08, 2014 at 08:10:23PM +0100, Christian Engelmayer wrote:
> Remove unused network device private data pointer 'vp' in function
> vortex_eisa_cleanup(). Detected by Coverity: CID 139826.
>
> Signed-off-by: Christian Engelmayer <cengelma@gmx.at>
> ---
> Resend using address steffen@klassert.de as retrieved from the mail delivery
> fail notification by tu-chemnitz.de. Information in MAINTAINERS seems to be
> outdated on that point.
Oh yes, it expired at the beginning of the year. I'll do a
patch to update the maintainers entry. Thanks for the info!
^ permalink raw reply
* [PATCH] dp83640: Get gpio and master/slave configuration from DT
From: Stefan Sørensen @ 2014-02-10 13:00 UTC (permalink / raw)
To: richardcochran, grant.likely, robh+dt, netdev, linux-kernel,
devicetree
Cc: Stefan Sørensen
This patch removes the module parameters gpio_tab and chosen_phy in favour of
retrieving the configuration from DT through the properties
dp83640,slave
dp83640,calibrate-gpio
dp83640,perout-gpios
dp83640,extts-gpios
The configuration is now stored for each master clock device, allowing different
gpio setups for each master.
Furthermore the code is enhanced to handle more than one periodic output.
Signed-off-by: Stefan Sørensen <stefan.sorensen@spectralink.com>
---
The slave configuration code is totally untested as I only have access to
boards with a single DP3640.
drivers/net/phy/dp83640.c | 195 ++++++++++++++++++++++++++++++----------------
1 file changed, 128 insertions(+), 67 deletions(-)
diff --git a/drivers/net/phy/dp83640.c b/drivers/net/phy/dp83640.c
index 547725f..118403d 100644
--- a/drivers/net/phy/dp83640.c
+++ b/drivers/net/phy/dp83640.c
@@ -30,6 +30,7 @@
#include <linux/phy.h>
#include <linux/ptp_classify.h>
#include <linux/ptp_clock_kernel.h>
+#include <linux/of_device.h>
#include "dp83640_reg.h"
@@ -38,15 +39,11 @@
#define LAYER4 0x02
#define LAYER2 0x01
#define MAX_RXTS 64
-#define N_EXT_TS 6
+#define N_EXT 8
#define PSF_PTPVER 2
#define PSF_EVNT 0x4000
#define PSF_RX 0x2000
#define PSF_TX 0x1000
-#define EXT_EVENT 1
-#define CAL_EVENT 7
-#define CAL_TRIGGER 7
-#define PER_TRIGGER 6
#define MII_DP83640_MICR 0x11
#define MII_DP83640_MISR 0x12
@@ -123,6 +120,8 @@ struct dp83640_private {
/* queues of incoming and outgoing packets */
struct sk_buff_head rx_queue;
struct sk_buff_head tx_queue;
+ /* is this phyter a slave */
+ bool slave;
};
struct dp83640_clock {
@@ -144,35 +143,9 @@ struct dp83640_clock {
struct list_head phylist;
/* reference to our PTP hardware clock */
struct ptp_clock *ptp_clock;
+ u32 perout_gpios[N_EXT], extts_gpios[N_EXT], calibrate_gpio;
};
-/* globals */
-
-enum {
- CALIBRATE_GPIO,
- PEROUT_GPIO,
- EXTTS0_GPIO,
- EXTTS1_GPIO,
- EXTTS2_GPIO,
- EXTTS3_GPIO,
- EXTTS4_GPIO,
- EXTTS5_GPIO,
- GPIO_TABLE_SIZE
-};
-
-static int chosen_phy = -1;
-static ushort gpio_tab[GPIO_TABLE_SIZE] = {
- 1, 2, 3, 4, 8, 9, 10, 11
-};
-
-module_param(chosen_phy, int, 0444);
-module_param_array(gpio_tab, ushort, NULL, 0444);
-
-MODULE_PARM_DESC(chosen_phy, \
- "The address of the PHY to use for the ancillary clock features");
-MODULE_PARM_DESC(gpio_tab, \
- "Which GPIO line to use for which purpose: cal,perout,extts1,...,extts6");
-
/* a list of clocks and a mutex to protect it */
static LIST_HEAD(phyter_clocks);
static DEFINE_MUTEX(phyter_clocks_lock);
@@ -267,15 +240,16 @@ static u64 phy2txts(struct phy_txts *p)
}
static void periodic_output(struct dp83640_clock *clock,
- struct ptp_clock_request *clkreq, bool on)
+ struct ptp_clock_request *clkreq, int index,
+ bool on)
{
struct dp83640_private *dp83640 = clock->chosen;
struct phy_device *phydev = dp83640->phydev;
u32 sec, nsec, period;
u16 gpio, ptp_trig, trigger, val;
- gpio = on ? gpio_tab[PEROUT_GPIO] : 0;
- trigger = PER_TRIGGER;
+ gpio = on ? clock->perout_gpios[index] : 0;
+ trigger = clock->caps.n_ext_ts + index;
ptp_trig = TRIG_WR |
(trigger & TRIG_CSEL_MASK) << TRIG_CSEL_SHIFT |
@@ -430,12 +404,12 @@ static int ptp_dp83640_enable(struct ptp_clock_info *ptp,
switch (rq->type) {
case PTP_CLK_REQ_EXTTS:
index = rq->extts.index;
- if (index < 0 || index >= N_EXT_TS)
+ if (index < 0 || index >= clock->caps.n_ext_ts)
return -EINVAL;
- event_num = EXT_EVENT + index;
+ event_num = index;
evnt = EVNT_WR | (event_num & EVNT_SEL_MASK) << EVNT_SEL_SHIFT;
if (on) {
- gpio_num = gpio_tab[EXTTS0_GPIO + index];
+ gpio_num = clock->extts_gpios[index];
evnt |= (gpio_num & EVNT_GPIO_MASK) << EVNT_GPIO_SHIFT;
evnt |= EVNT_RISE;
}
@@ -443,9 +417,10 @@ static int ptp_dp83640_enable(struct ptp_clock_info *ptp,
return 0;
case PTP_CLK_REQ_PEROUT:
- if (rq->perout.index != 0)
+ index = rq->perout.index;
+ if (index < 0 || index >= clock->caps.n_per_out)
return -EINVAL;
- periodic_output(clock, rq, on);
+ periodic_output(clock, rq, index, on);
return 0;
default:
@@ -538,10 +513,9 @@ static void recalibrate(struct dp83640_clock *clock)
struct list_head *this;
struct dp83640_private *tmp;
struct phy_device *master = clock->chosen->phydev;
- u16 cal_gpio, cfg0, evnt, ptp_trig, trigger, val;
+ u16 cfg0, evnt, ptp_trig, trigger, val;
- trigger = CAL_TRIGGER;
- cal_gpio = gpio_tab[CALIBRATE_GPIO];
+ trigger = clock->caps.n_ext_ts + clock->caps.n_per_out;
mutex_lock(&clock->extreg_lock);
@@ -564,8 +538,8 @@ static void recalibrate(struct dp83640_clock *clock)
* enable an event timestamp
*/
evnt = EVNT_WR | EVNT_RISE | EVNT_SINGLE;
- evnt |= (CAL_EVENT & EVNT_SEL_MASK) << EVNT_SEL_SHIFT;
- evnt |= (cal_gpio & EVNT_GPIO_MASK) << EVNT_GPIO_SHIFT;
+ evnt |= (trigger & EVNT_SEL_MASK) << EVNT_SEL_SHIFT;
+ evnt |= (clock->calibrate_gpio & EVNT_GPIO_MASK) << EVNT_GPIO_SHIFT;
list_for_each(this, &clock->phylist) {
tmp = list_entry(this, struct dp83640_private, list);
@@ -578,7 +552,7 @@ static void recalibrate(struct dp83640_clock *clock)
*/
ptp_trig = TRIG_WR | TRIG_IF_LATE | TRIG_PULSE;
ptp_trig |= (trigger & TRIG_CSEL_MASK) << TRIG_CSEL_SHIFT;
- ptp_trig |= (cal_gpio & TRIG_GPIO_MASK) << TRIG_GPIO_SHIFT;
+ ptp_trig |= (clock->calibrate_gpio & TRIG_GPIO_MASK) << TRIG_GPIO_SHIFT;
ext_write(0, master, PAGE5, PTP_TRIG, ptp_trig);
/* load trigger */
@@ -642,7 +616,7 @@ static void recalibrate(struct dp83640_clock *clock)
static inline u16 exts_chan_to_edata(int ch)
{
- return 1 << ((ch + EXT_EVENT) * 2);
+ return 1 << ((ch) * 2);
}
static int decode_evnt(struct dp83640_private *dp83640,
@@ -676,14 +650,14 @@ static int decode_evnt(struct dp83640_private *dp83640,
parsed = words + 2;
} else {
parsed = words + 1;
- i = ((ests >> EVNT_NUM_SHIFT) & EVNT_NUM_MASK) - EXT_EVENT;
+ i = ((ests >> EVNT_NUM_SHIFT) & EVNT_NUM_MASK);
ext_status = exts_chan_to_edata(i);
}
event.type = PTP_CLOCK_EXTTS;
event.timestamp = phy2txts(&dp83640->edata);
- for (i = 0; i < N_EXT_TS; i++) {
+ for (i = 0; i < dp83640->clock->caps.n_ext_ts; i++) {
if (ext_status & exts_chan_to_edata(i)) {
event.index = i;
ptp_clock_event(dp83640->clock->ptp_clock, &event);
@@ -889,8 +863,6 @@ static void dp83640_clock_init(struct dp83640_clock *clock, struct mii_bus *bus)
sprintf(clock->caps.name, "dp83640 timer");
clock->caps.max_adj = 1953124;
clock->caps.n_alarm = 0;
- clock->caps.n_ext_ts = N_EXT_TS;
- clock->caps.n_per_out = 1;
clock->caps.pps = 0;
clock->caps.adjfreq = ptp_dp83640_adjfreq;
clock->caps.adjtime = ptp_dp83640_adjtime;
@@ -903,18 +875,6 @@ static void dp83640_clock_init(struct dp83640_clock *clock, struct mii_bus *bus)
get_device(&bus->dev);
}
-static int choose_this_phy(struct dp83640_clock *clock,
- struct phy_device *phydev)
-{
- if (chosen_phy == -1 && !clock->chosen)
- return 1;
-
- if (chosen_phy == phydev->addr)
- return 1;
-
- return 0;
-}
-
static struct dp83640_clock *dp83640_clock_get(struct dp83640_clock *clock)
{
if (clock)
@@ -960,6 +920,100 @@ static void dp83640_clock_put(struct dp83640_clock *clock)
mutex_unlock(&clock->clock_lock);
}
+#ifdef CONFIG_OF
+static int dp83640_probe_dt(struct device_node *node,
+ struct dp83640_private *dp83640)
+{
+ struct dp83640_clock *clock = dp83640->clock;
+ struct property *prop;
+ int err, proplen;
+
+ if (!node)
+ return 0;
+
+ if (of_find_property(node, "dp83640,slave", NULL))
+ dp83640->slave = true;
+ if (!dp83640->slave && clock->chosen) {
+ pr_err("dp83640,slave must be set if more than one device on the same bus");
+ return -EINVAL;
+ }
+
+ prop = of_find_property(node, "dp83640,perout-gpios", &proplen);
+ if (prop) {
+ if (dp83640->slave) {
+ pr_err("dp83640,perout-gpios property can not be set together with dp83640,slave");
+ return -EINVAL;
+ }
+
+ clock->caps.n_per_out = proplen / sizeof(u32);
+ if (clock->caps.n_per_out > N_EXT) {
+ pr_err("dp83640,perout-gpios may not have more than %d entries",
+ N_EXT);
+ return -EINVAL;
+ }
+ err = of_property_read_u32_array(node, "dp83640,perout-gpios",
+ clock->perout_gpios,
+ clock->caps.n_per_out);
+ if (err < 0)
+ return err;
+ }
+
+ prop = of_find_property(node, "dp83640,extts-gpios", &proplen);
+ if (prop) {
+ if (dp83640->slave) {
+ pr_err("dp83640,extts-gpios property can not be set together with dp83640,slave");
+ return -EINVAL;
+ }
+
+ clock->caps.n_ext_ts = proplen / sizeof(u32);
+ if (clock->caps.n_ext_ts > N_EXT) {
+ pr_err("dp83640,extts-gpios may not have more than %d entries",
+ N_EXT);
+ return -EINVAL;
+ }
+ err = of_property_read_u32_array(node, "dp83640,extts-gpios",
+ clock->extts_gpios,
+ clock->caps.n_ext_ts);
+ if (err < 0)
+ return err;
+ }
+
+ prop = of_find_property(node, "dp83640,calibrate-gpio", &proplen);
+ if (prop) {
+ if (dp83640->slave) {
+ pr_err("dp83640,calibrate-gpio property can not be set together with dp83640,slave");
+ return -EINVAL;
+ }
+ clock->calibrate_gpio = -1;
+ of_property_read_u32(node, "dp83640,calibrate-gpio",
+ &clock->calibrate_gpio);
+ }
+
+ if (!dp83640->slave) {
+ if (clock->caps.n_per_out + clock->caps.n_ext_ts +
+ (clock->calibrate_gpio != -1 ? 1 : 0) > N_EXT) {
+ pr_err("Too many gpios configured");
+ return -EINVAL;
+ }
+ }
+
+ return 0;
+}
+
+static const struct of_device_id dp83640_of_match_table[] = {
+ { .compatible = "national,dp83640", },
+ { },
+};
+MODULE_DEVICE_TABLE(of, dp83640_of_match_table);
+#else
+
+static inline int dp83640_probe_dt(struct device_node *node,
+ struct dp83640_private *dp83640)
+{
+ return 0;
+}
+#endif
+
static int dp83640_probe(struct phy_device *phydev)
{
struct dp83640_clock *clock;
@@ -977,7 +1031,13 @@ static int dp83640_probe(struct phy_device *phydev)
if (!dp83640)
goto no_memory;
+ dp83640->clock = clock;
dp83640->phydev = phydev;
+
+ err = dp83640_probe_dt(phydev->dev.of_node, dp83640);
+ if (err)
+ return err;
+
INIT_WORK(&dp83640->ts_work, rx_timestamp_work);
INIT_LIST_HEAD(&dp83640->rxts);
@@ -991,9 +1051,7 @@ static int dp83640_probe(struct phy_device *phydev)
skb_queue_head_init(&dp83640->rx_queue);
skb_queue_head_init(&dp83640->tx_queue);
- dp83640->clock = clock;
-
- if (choose_this_phy(clock, phydev)) {
+ if (!clock->chosen && !dp83640->slave) {
clock->chosen = dp83640;
clock->ptp_clock = ptp_clock_register(&clock->caps, &phydev->dev);
if (IS_ERR(clock->ptp_clock)) {
@@ -1338,7 +1396,10 @@ static struct phy_driver dp83640_driver = {
.hwtstamp = dp83640_hwtstamp,
.rxtstamp = dp83640_rxtstamp,
.txtstamp = dp83640_txtstamp,
- .driver = {.owner = THIS_MODULE,}
+ .driver = {
+ .owner = THIS_MODULE,
+ .of_match_table = of_match_ptr(dp83640_of_match_table),
+ }
};
static int __init dp83640_init(void)
--
1.8.5.3
^ permalink raw reply related
* Re: [PATCH 1/2 v2] usbnet: fix bad header length bug
From: Bjørn Mork @ 2014-02-10 13:05 UTC (permalink / raw)
To: Oliver Neukum
Cc: Emil Goode, David S. Miller, Ming Lei, Mark Brown, Jeff Kirsher,
Glen Turner, netdev, linux-usb, linux-kernel
In-Reply-To: <1392034947.2082.30.camel@linux-fkkt.site>
Oliver Neukum <oliver@neukum.org> writes:
> On Mon, 2014-02-10 at 13:00 +0100, Emil Goode wrote:
>> On Mon, Feb 10, 2014 at 07:40:58AM +0100, Oliver Neukum wrote:
>
>> > Well, then how about simply removing the check?
>> > It seems to have outlived its usefulness.
>> >
>> > Regards
>> > Oliver
>> >
>> >
>>
>> I did consider that and I think it is probably the best thing to do.
>> However, I think the removal of the check could have negative effects
>> on the other minidrivers, at least the qmi_wwan minidriver explicitly
>> states that it is depending on this check to be made in rx_complete().
>
> <censored>.
No need to do that. I had the exact same reaction myself :-)
Anyway, I put that comment there mostly as a note to myself why the
check would be redundant at that point. I don't see any problem with
removing the generic check in usbnet as long as we add similar checks
whereever they are needed, like in qmi_wwan.
Note that usbnet_skb_return will be one of those places. It calls
eth_type_trans() on the skb, so it should verify that the length is at
least ETH_HLEN first.
> Oh well. But how about merging it with FLAG_MULTI_PACKET?
> I really don't want to add more flags. There is a point where enough
> flags make absurd having a common code. We are closing in on that point.
Agreed. I would even say we are past that point...
Bjørn
^ permalink raw reply
* Re: [PATCH 2/2] net: ip, ipv6: handle gso skbs in forwarding path
From: Eric Dumazet @ 2014-02-10 13:08 UTC (permalink / raw)
To: Herbert Xu; +Cc: Florian Westphal, netdev
In-Reply-To: <20140210125049.GB28752@gondor.apana.org.au>
On Mon, 2014-02-10 at 20:50 +0800, Herbert Xu wrote:
> On Mon, Feb 10, 2014 at 01:43:46PM +0100, Florian Westphal wrote:
> >
> > Eric suggested to shrink gso_size instead to avoid segmentation+fragments.
> > I think its nice idea, but skb_gso_segment makes certain assumptions about
> > nr_frags and gso_size (it can't handle frag size > desired mss).
>
> This breaks the most important assumption behind GRO which is
> to preserve end-to-end connectivity. Resegmenting packets as
> suggested on a router/bridge is just wrong.
Yeah, this is the old mantra.
Sending TCP packets without DF means the sender do not care by
definition.
If you disable GRO for such packets, it slows down receivers and
increase packet drops.
I've added the segmentation for these packets for a reason, that you are
free to not understand, but there is absolutely no need reason to not
aggregate TCP packets without DF. This is what you suggested to ignore
the problem on skb_segment() being so limited.
Instead of a router being forced to segment all incoming fragments into
X+Y
X+Y
X+Y
X+Y
Its reasonable to send X+X+X+X+X
And we should be reasonable, not trying to enforce a particular view of
what _should_ the traffic looks like on the Internet.
^ permalink raw reply
* Re: [PATCH 2/2] net: ip, ipv6: handle gso skbs in forwarding path
From: Eric Dumazet @ 2014-02-10 13:12 UTC (permalink / raw)
To: Herbert Xu; +Cc: Florian Westphal, netdev
In-Reply-To: <20140210123124.GA28752@gondor.apana.org.au>
On Mon, 2014-02-10 at 20:31 +0800, Herbert Xu wrote:
> On Mon, Feb 10, 2014 at 01:23:31PM +0100, Florian Westphal wrote:
> > Herbert Xu <herbert@gondor.apana.org.au> wrote:
> > > > > static void ip_gso_adjust_seglen(struct sk_buff *skb)
> > > > > {
> > > > > unsigned int mtu;
> > > > >
> > > > > if (!skb_is_gso(skb))
> > > > > return;
> > > > >
> > > > > mtu = ip_dst_mtu_maybe_forward(skb_dst(skb), true);
> > > > > skb_shinfo(skb)->gso_size = mtu - sizeof(struct iphdr);
> > > > > }
> > > > >
> > > > > But this yields
> > > > >
> > > > > [ 28.644776] kernel BUG at net/net/core/skbuff.c:2984!
> > > >
> > > > Yep, lets CC Herbert Xu, as he 'owns' skb_segment()
> > >
> > > IMHO we should just stop merging ~DF packets altogether, at least
> > > for TCP.
> >
> > Eric, you added DF aggregation in db8caf3dbc77599dc90f4ea0a803cd1d97116f30
> > (gro: should aggregate frames without DF).
> >
> > I guess you don't want to revert this commit?
> > Any other ideas?
> >
> > skb_gso_segment() is already very complex, I don't want to add more code
> > to it. And that seems unavoidable if we need to de-couple nr_frags and
> > gso_size.
>
> I don't think adding all this complexity just to be able to
> aggregate ~DF packets (which are just wrong to begin with) is
> worth it.
Wrong by your standards. Which are not universal.
>
> If aggregating ~DF packets was a one-liner then sure, but there
> is a reason why I didn't aggregate them in the first place and
> you've found it :)
I sent months ago a solution for skb_segment() that you ignored.
I understand you never hit cases where DF was not set, I can tell you
its happening in the real world.
GRO stack already breaks reversibility by definition since day-0
Recent tunneling support breaks it as well.
^ permalink raw reply
* Re: [PATCH 2/2] net: ip, ipv6: handle gso skbs in forwarding path
From: Eric Dumazet @ 2014-02-10 13:15 UTC (permalink / raw)
To: Florian Westphal; +Cc: Herbert Xu, netdev
In-Reply-To: <20140210124346.GA6329@breakpoint.cc>
On Mon, 2014-02-10 at 13:43 +0100, Florian Westphal wrote:
> Well we could go with my original patch that will do software
> segmentation on ~DF packets in the forwarding path if the outmtu is too
> small for the individual packets. The output path then simply
> creates fragments.
Most linux routers disable GRO anyway.
GRO is mostly used on linux hosts to improve performance, so most GRO
packets are consumed on the receiving host.
^ permalink raw reply
* Re: [PATCH net] hyperv: Fix the carrier status setting
From: Sergei Shtylyov @ 2014-02-10 13:28 UTC (permalink / raw)
To: Haiyang Zhang, davem, netdev
Cc: driverdev-devel, olaf, jasowang, linux-kernel
In-Reply-To: <1391994478-25809-1-git-send-email-haiyangz@microsoft.com>
Hello.
On 10-02-2014 5:07, Haiyang Zhang wrote:
> Signed-off-by: Haiyang Zhang <haiyangz@microsoft.com>
> Reviewed-by: K. Y. Srinivasan <kys@microsoft.com>
> ---
> drivers/net/hyperv/netvsc_drv.c | 24 +++++++++++++++---------
> 1 files changed, 15 insertions(+), 9 deletions(-)
> diff --git a/drivers/net/hyperv/netvsc_drv.c b/drivers/net/hyperv/netvsc_drv.c
> index 7756118..836211c 100644
> --- a/drivers/net/hyperv/netvsc_drv.c
> +++ b/drivers/net/hyperv/netvsc_drv.c
[...]
> @@ -229,15 +238,17 @@ void netvsc_linkstatus_callback(struct hv_device *device_obj,
> struct net_device *net;
> struct net_device_context *ndev_ctx;
> struct netvsc_device *net_device;
> + struct rndis_device *rdev;
>
> net_device = hv_get_drvdata(device_obj);
> + rdev = net_device->extension;
> +
> + rdev->link_state = !(status == 1);
Why not just 'status != 1'?
WBR, Sergei
^ permalink raw reply
* Re: [PATCH iproute2 net-next-for-3.13 1/2] iplink: display slave information
From: Sergei Shtylyov @ 2014-02-10 13:34 UTC (permalink / raw)
To: Michal Kubecek, Stephen Hemminger; +Cc: netdev
In-Reply-To: <20140210081146.6F4FEE5697@unicorn.suse.cz>
Hello.
On 10-02-2014 12:11, Michal Kubecek wrote:
> Add print_slave_opt() callback and maxslattr value to struct
> link_util. These are analogous to print_opt() and maxattr but
> relate to slave info (IFLA_INFO_SLAVE_{KIND,DATA}).
> Display the slave specific info in output of "ip -d link show".
> Signed-off-by: Michal Kubecek <mkubecek@suse.cz>
[...]
> diff --git a/ip/ipaddress.c b/ip/ipaddress.c
> index f794fa1..3cb7ee7 100644
> --- a/ip/ipaddress.c
> +++ b/ip/ipaddress.c
[...]
> @@ -221,6 +221,29 @@ static void print_linktype(FILE *fp, struct rtattr *tb)
> lu->print_xstats)
> lu->print_xstats(lu, fp, linkinfo[IFLA_INFO_XSTATS]);
> }
> +
> +no_info:
> + if (!linkinfo[IFLA_INFO_SLAVE_KIND])
> + return;
> + kind = RTA_DATA(linkinfo[IFLA_INFO_SLAVE_KIND]);
> +
> + fprintf(fp, "%s", _SL_);
> + fprintf(fp, " %s_slave ", kind);
> +
> + lu = get_link_kind(kind);
> + if (!lu || !lu->print_slave_opt)
> + return;
> +
> + if (1) {
Why is that?
> + struct rtattr *attr[lu->maxslattr+1], **data = NULL;
> +
> + if (linkinfo[IFLA_INFO_SLAVE_DATA]) {
> + parse_rtattr_nested(attr, lu->maxslattr,
> + linkinfo[IFLA_INFO_SLAVE_DATA]);
> + data = attr;
> + }
> + lu->print_slave_opt(lu, fp, data);
> + }
WBR, Sergei
^ permalink raw reply
* Re: [PATCH] dp83640: Get gpio and master/slave configuration from DT
From: Mark Rutland @ 2014-02-10 13:42 UTC (permalink / raw)
To: Stefan Sørensen
Cc: richardcochran-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org,
grant.likely-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <1392037240-30913-1-git-send-email-stefan.sorensen-usnHOLptxrsHrNJx0XZkJA@public.gmane.org>
On Mon, Feb 10, 2014 at 01:00:40PM +0000, Stefan Sørensen wrote:
> This patch removes the module parameters gpio_tab and chosen_phy in favour of
> retrieving the configuration from DT through the properties
> dp83640,slave
> dp83640,calibrate-gpio
> dp83640,perout-gpios
> dp83640,extts-gpios
> The configuration is now stored for each master clock device, allowing different
> gpio setups for each master.
>
> Furthermore the code is enhanced to handle more than one periodic output.
Binding document please.
I have some basic comments below, but without a description of what the
properties mean, it's difficult to provide any meaningful review.
[...]
> +static int dp83640_probe_dt(struct device_node *node,
> + struct dp83640_private *dp83640)
> +{
> + struct dp83640_clock *clock = dp83640->clock;
> + struct property *prop;
> + int err, proplen;
> +
> + if (!node)
> + return 0;
> +
> + if (of_find_property(node, "dp83640,slave", NULL))
> + dp83640->slave = true;
Use of_property_read_bool.
> + if (!dp83640->slave && clock->chosen) {
> + pr_err("dp83640,slave must be set if more than one device on the same bus");
> + return -EINVAL;
> + }
> +
> + prop = of_find_property(node, "dp83640,perout-gpios", &proplen);
> + if (prop) {
> + if (dp83640->slave) {
> + pr_err("dp83640,perout-gpios property can not be set together with dp83640,slave");
> + return -EINVAL;
> + }
> +
> + clock->caps.n_per_out = proplen / sizeof(u32);
> + if (clock->caps.n_per_out > N_EXT) {
> + pr_err("dp83640,perout-gpios may not have more than %d entries",
> + N_EXT);
> + return -EINVAL;
> + }
> + err = of_property_read_u32_array(node, "dp83640,perout-gpios",
> + clock->perout_gpios,
> + clock->caps.n_per_out);
> + if (err < 0)
> + return err;
> + }
This looks nothing like the standard gpio bindings. What _exactly_ is
this property describing?
If this is not using the standard gpio bindings then this should be
renamed.
Either way this must be documented.
> +
> + prop = of_find_property(node, "dp83640,extts-gpios", &proplen);
> + if (prop) {
> + if (dp83640->slave) {
> + pr_err("dp83640,extts-gpios property can not be set together with dp83640,slave");
> + return -EINVAL;
> + }
> +
> + clock->caps.n_ext_ts = proplen / sizeof(u32);
> + if (clock->caps.n_ext_ts > N_EXT) {
> + pr_err("dp83640,extts-gpios may not have more than %d entries",
> + N_EXT);
> + return -EINVAL;
> + }
> + err = of_property_read_u32_array(node, "dp83640,extts-gpios",
> + clock->extts_gpios,
> + clock->caps.n_ext_ts);
> + if (err < 0)
> + return err;
> + }
Similarly this does not look right for parsing a standard -gpios property.
> +
> + prop = of_find_property(node, "dp83640,calibrate-gpio", &proplen);
> + if (prop) {
> + if (dp83640->slave) {
> + pr_err("dp83640,calibrate-gpio property can not be set together with dp83640,slave");
> + return -EINVAL;
> + }
> + clock->calibrate_gpio = -1;
> + of_property_read_u32(node, "dp83640,calibrate-gpio",
> + &clock->calibrate_gpio);
> + }
And again, this doesn't look right.
Thanks,
Mark.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 1/2] mm/vmalloc: export is_vmalloc_or_module_addr
From: Dave Kleikamp @ 2014-02-10 14:40 UTC (permalink / raw)
To: Mel Gorman, Linus Torvalds
Cc: Richard Yao, Andrew Morton, Rik van Riel, Eric Van Hensbergen,
Ron Minnich, Latchesar Ionkov, David S. Miller,
V9FS Develooper Mailing List, Linux Netdev Mailing List,
Linux Kernel Mailing List, Aneesh Kumar K.V, Will Deacon,
Christopher Covington, Matthew Thode, Al Viro
In-Reply-To: <20140210121020.GC6732@suse.de>
On 02/10/2014 06:10 AM, Mel Gorman wrote:
> On Sat, Feb 08, 2014 at 11:45:53AM -0800, Linus Torvalds wrote:
>> On Sat, Feb 8, 2014 at 11:12 AM, Richard Yao <ryao@gentoo.org> wrote:
>>> 9p-virtio needs is_vmalloc_or_module_addr exported before a patch can be
>>> merged to prevent the virtio zero-copy routines from triggering a
>>> hypervisor page fault when loading kernel modules:
>>>
>>> https://groups.google.com/forum/#!topic/linux.kernel/eRR7AyLE29Y
>>>
>>> Without this export, the kernel build breaks with that patch applied and
>>> CONFIG_NET_9P_VIRTIO=m. With this export in place, all is well.
>>
>> I absolutely *detest* this patch.
>>
>> Not so much because is_vmalloc_or_module_addr() should never be used,
>> but because the particular use in question is pure and utter garbage.
>>
>> There are valid reasons to use "is_vmalloc_or_module_addr()", but
>> those are along the lines of drivers/char/mem.c, which says "return
>> -ENXIO for this crap".
>>
>> And btw, that horrid crap called "kmap_to_page()" needs to die too.
>> When is it *ever* valid to use a kmap'ed page for IO? Here's a clue:
>> never.
>>
>> <SNIP>
>>
>> Those *disgusting* get_kernel_page[s]() functions came with a
>> commentary about "The initial user is expected to be NFS.." and that
>> is still the *only* user. The fact that *everybody* else has been able
>> to avoid that crap should tell us something.
>
> kmap_to_page, get_kernel_page and the NFS user for it are already scheduled
> for death. Dave Kleikamp has been working on a series "Issue O_DIRECT aio
> using bio_vec" that replaces what NFS currently does with something far
> more sane. The series does not remove the helpers on top, probably because
> of the 9P use of it, but if that was changed then the helpers would finally
> die. I'm not sure why Dave's series never got merged so added him to the
> cc to find out.
The patchset I submitted was too ugly to live. Linus and Al Viro both
had numerous issues with the implementation, but not the overall concept.
Al has the same idea for a io-vector container that can hold either an
iovec or a kernel vector and is starting to work on his own
implementation. Once he settles on the particulars of new
aio_write/aio_read methods, I should be able to get the rest of my
patchset to fall into line with it.
http://www.spinics.net/lists/linux-fsdevel/msg71938.html
Shaggy
^ permalink raw reply
* [PATCH net-next 0/9] bnx2x: Enhancements & semantic changes series
From: Yuval Mintz @ 2014-02-10 15:16 UTC (permalink / raw)
To: davem, netdev; +Cc: ariele
Hi Dave,
This patch series contains several semantic (or mostly semantic) patches,
as well as adding support for packet aggregations on the receive path
of windows VMs and updating bnx2x to the new FW recently accepted upstream.
Please consider applying these patches to `net-next'.
Thanks,
Yuval Mintz
^ permalink raw reply
* [PATCH net-next 1/9] bnx2x: [Debug] change verbosity of some prints
From: Yuval Mintz @ 2014-02-10 15:16 UTC (permalink / raw)
To: davem, netdev; +Cc: ariele, Yuval Mintz
In-Reply-To: <1392045422-5437-1-git-send-email-yuvalmin@broadcom.com>
There are some debug prints (mostly iov/statistics related) which clobber
system logs whenever their verbosity level is set for an interface.
This patch puts harsher verbosity requirements for such debug prints to be
printed.
Signed-off-by: Yuval Mintz <yuvalmin@broadcom.com>
Signed-off-by: Ariel Elior <ariele@broadcom.com>
---
drivers/net/ethernet/broadcom/bnx2x/bnx2x.h | 17 +++++++++++++----
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c | 6 +++---
drivers/net/ethernet/broadcom/bnx2x/bnx2x_sriov.c | 17 +++++++++--------
3 files changed, 25 insertions(+), 15 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x.h b/drivers/net/ethernet/broadcom/bnx2x/bnx2x.h
index 391f29e..ae91e8f 100644
--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x.h
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x.h
@@ -75,13 +75,22 @@ enum bnx2x_int_mode {
#define BNX2X_MSG_DCB 0x8000000
/* regular debug print */
+#define DP_INNER(fmt, ...) \
+ pr_notice("[%s:%d(%s)]" fmt, \
+ __func__, __LINE__, \
+ bp->dev ? (bp->dev->name) : "?", \
+ ##__VA_ARGS__);
+
#define DP(__mask, fmt, ...) \
do { \
if (unlikely(bp->msg_enable & (__mask))) \
- pr_notice("[%s:%d(%s)]" fmt, \
- __func__, __LINE__, \
- bp->dev ? (bp->dev->name) : "?", \
- ##__VA_ARGS__); \
+ DP_INNER(fmt, ##__VA_ARGS__); \
+} while (0)
+
+#define DP_AND(__mask, fmt, ...) \
+do { \
+ if (unlikely((bp->msg_enable & (__mask)) == __mask)) \
+ DP_INNER(fmt, ##__VA_ARGS__); \
} while (0)
#define DP_CONT(__mask, fmt, ...) \
diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
index e118a3e..72ff5d2 100644
--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
@@ -5221,9 +5221,9 @@ static void bnx2x_eq_int(struct bnx2x *bp)
continue;
case EVENT_RING_OPCODE_STAT_QUERY:
- DP(BNX2X_MSG_SP | BNX2X_MSG_STATS,
- "got statistics comp event %d\n",
- bp->stats_comp++);
+ DP_AND((BNX2X_MSG_SP | BNX2X_MSG_STATS),
+ "got statistics comp event %d\n",
+ bp->stats_comp++);
/* nothing to do with stats comp */
goto next_spqe;
diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_sriov.c b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_sriov.c
index aec5ef2..04805b6 100644
--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_sriov.c
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_sriov.c
@@ -2527,10 +2527,10 @@ void bnx2x_iov_adjust_stats_req(struct bnx2x *bp)
first_queue_query_index = BNX2X_FIRST_QUEUE_QUERY_IDX -
(is_fcoe ? 0 : 1);
- DP(BNX2X_MSG_IOV,
- "BNX2X_NUM_ETH_QUEUES %d, is_fcoe %d, first_queue_query_index %d => determined the last non virtual statistics query index is %d. Will add queries on top of that\n",
- BNX2X_NUM_ETH_QUEUES(bp), is_fcoe, first_queue_query_index,
- first_queue_query_index + num_queues_req);
+ DP_AND((BNX2X_MSG_IOV | BNX2X_MSG_STATS),
+ "BNX2X_NUM_ETH_QUEUES %d, is_fcoe %d, first_queue_query_index %d => determined the last non virtual statistics query index is %d. Will add queries on top of that\n",
+ BNX2X_NUM_ETH_QUEUES(bp), is_fcoe, first_queue_query_index,
+ first_queue_query_index + num_queues_req);
cur_data_offset = bp->fw_stats_data_mapping +
offsetof(struct bnx2x_fw_stats_data, queue_stats) +
@@ -2544,9 +2544,9 @@ void bnx2x_iov_adjust_stats_req(struct bnx2x *bp)
struct bnx2x_virtf *vf = BP_VF(bp, i);
if (vf->state != VF_ENABLED) {
- DP(BNX2X_MSG_IOV,
- "vf %d not enabled so no stats for it\n",
- vf->abs_vfid);
+ DP_AND((BNX2X_MSG_IOV | BNX2X_MSG_STATS),
+ "vf %d not enabled so no stats for it\n",
+ vf->abs_vfid);
continue;
}
@@ -2597,7 +2597,8 @@ void bnx2x_iov_sp_task(struct bnx2x *bp)
/* Iterate over all VFs and invoke state transition for VFs with
* 'in-progress' slow-path operations
*/
- DP(BNX2X_MSG_IOV, "searching for pending vf operations\n");
+ DP_AND((BNX2X_MSG_IOV | BNX2X_MSG_SP),
+ "searching for pending vf operations\n");
for_each_vf(bp, i) {
struct bnx2x_virtf *vf = BP_VF(bp, i);
--
1.8.1.227.g44fe835
^ permalink raw reply related
* [PATCH net-next 2/9] bnx2x: Remove unused iov code
From: Yuval Mintz @ 2014-02-10 15:16 UTC (permalink / raw)
To: davem, netdev; +Cc: ariele, Yuval Mintz
In-Reply-To: <1392045422-5437-1-git-send-email-yuvalmin@broadcom.com>
Signed-off-by: Yuval Mintz <yuvalmin@broadcom.com>
Signed-off-by: Ariel Elior <ariele@broadcom.com>
---
drivers/net/ethernet/broadcom/bnx2x/bnx2x_sriov.c | 10 ----------
1 file changed, 10 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_sriov.c b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_sriov.c
index 04805b6..c98edb0 100644
--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_sriov.c
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_sriov.c
@@ -3075,16 +3075,6 @@ static inline void bnx2x_vf_get_sbdf(struct bnx2x *bp,
*sbdf = vf->devfn | (vf->bus << 8);
}
-static inline void bnx2x_vf_get_bars(struct bnx2x *bp, struct bnx2x_virtf *vf,
- struct bnx2x_vf_bar_info *bar_info)
-{
- int n;
-
- bar_info->nr_bars = bp->vfdb->sriov.nres;
- for (n = 0; n < bar_info->nr_bars; n++)
- bar_info->bars[n] = vf->bars[n];
-}
-
void bnx2x_lock_vf_pf_channel(struct bnx2x *bp, struct bnx2x_virtf *vf,
enum channel_tlvs tlv)
{
--
1.8.1.227.g44fe835
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox