* Re: [PATCH V5 7/7] arm/dts: am33xx: Add CPSW and MDIO module nodes for AM33XX
From: Peter Korsgaard @ 2012-11-19 20:24 UTC (permalink / raw)
To: Mugunthan V N
Cc: netdev, davem, devicetree-discuss, linux-arm-kernel, linux-omap,
b-cousson, paul, Vaibhav Hiremath
In-Reply-To: <1352920080-6179-8-git-send-email-mugunthanvnm@ti.com>
>>>>> "M" == Mugunthan V N <mugunthanvnm@ti.com> writes:
M> Add CPSW and MDIO related device tree data for AM33XX.
M> Also enable them into board/evm dts files by providing
M> respective phy-id.
M> Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com>
M> Signed-off-by: Vaibhav Hiremath <hvaibhav@ti.com>
M> Cc: Benoit Cousson <b-cousson@ti.com>
M> Acked-by: Peter Korsgaard <jacmet@sunsite.dk>
M> Acked-by: Richard Cochran <richardcochran@gmail.com>
M> +++ b/arch/arm/boot/dts/am335x-bone.dts
M> @@ -78,3 +78,11 @@
M> };
M> };
M> };
M> +
M> +&cpsw_emac0 {
M> + phy_id = <&davinci_mdio>, <0>;
M> +};
M> +
M> +&cpsw_emac1 {
M> + phy_id = <&davinci_mdio>, <1>;
M> +};
I already acked this and the problem isn't caused by this patch itself,
but it isn't really nice that you have to add a dummy emac1 even though
only the first port is used on the bone.
It would imho be nicer to get rid of the 'slaves' property in cpsw (just
let the driver count available slave children), mark both slaves in
am33xx.dtsi with status = 'disabled' and only loop over the available
slaves in cpsw_probe_dt(), similar to E.G. how the uarts/i2c are handled.
Then am335x-bone.dts would just need to add:
&cpsw_emac0 {
status = 'ok';
phy_id = <&davinci_mdio>, <0>;
};
I'll send a patch shortly to implement this.
M> diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
M> index bb31bff..a4615b4 100644
M> --- a/arch/arm/boot/dts/am33xx.dtsi
M> +++ b/arch/arm/boot/dts/am33xx.dtsi
M> @@ -210,5 +210,53 @@
M> interrupt-parent = <&intc>;
M> interrupts = <91>;
M> };
M> +
M> + mac: ethernet@4a100000 {
M> + compatible = "ti,cpsw";
M> + ti,hwmods = "cpgmac0";
M> + cpdma_channels = <8>;
M> + ale_entries = <1024>;
M> + bd_ram_size = <0x2000>;
M> + no_bd_ram = <0>;
M> + rx_descs = <64>;
M> + mac_control = <0x20>;
M> + slaves = <2>;
M> + cpts_active_slave = <0>;
M> + cpts_clock_mult = <0x80000000>;
M> + cpts_clock_shift = <29>;
M> + reg = <0x4a100000 0x800
M> + 0x4a101200 0x100>;
M> + #address-cells = <1>;
M> + #size-cells = <1>;
M> + interrupt-parent = <&intc>;
M> + /*
M> + * c0_rx_thresh_pend
M> + * c0_rx_pend
M> + * c0_tx_pend
M> + * c0_misc_pend
M> + */
M> + interrupts = <40 41 42 43>;
M> + ranges;
M> +
M> + davinci_mdio: mdio@4a101000 {
M> + compatible = "ti,davinci_mdio";
M> + #address-cells = <1>;
M> + #size-cells = <0>;
M> + ti,hwmods = "davinci_mdio";
M> + bus_freq = <1000000>;
M> + reg = <0x4a101000 0x100>;
M> + };
M> +
M> + cpsw_emac0: slave@4a100200 {
M> + /* Filled in by U-Boot */
M> + mac-address = [ 00 00 00 00 00 00 ];
M> + };
M> +
M> + cpsw_emac1: slave@4a100300 {
M> + /* Filled in by U-Boot */
M> + mac-address = [ 00 00 00 00 00 00 ];
M> + };
M> +
M> + };
--
Bye, Peter Korsgaard
^ permalink raw reply
* Re: Re: [B.A.T.M.A.N.] [PATCH 04/10] batman-adv: export compatibility version via debugfs
From: Sven Eckelmann @ 2012-11-19 20:25 UTC (permalink / raw)
To: Ben Hutchings
Cc: b.a.t.m.a.n, Antonio Quartulli, netdev, Marek Lindner, davem
In-Reply-To: <1353354018.4156.13.camel@bwh-desktop.uk.solarflarecom.com>
[-- Attachment #1: Type: text/plain, Size: 1197 bytes --]
On Monday 19 November 2012 19:40:18 Ben Hutchings wrote:
[...]
> > > I do hope that you're not planning to use unstable debugfs interfaces
> > > indefinitely.
> >
> > Why are you refering to the adding of an file as "incompatible" debugfs
> > interface? I would call it additional information. And the rest of the
> > commit message is talking about *possible* protocol incompatibilies of
> > the network protocol (which caused this uncontrolled erruption of anger
> > in a network maintainer).
>
> I didn't say that. But debugfs tends to be exempted from expectations
> of interface stability or cleanliness (as it's for development, not
> production... right?). It's also an optional feature that might not be
> enabled at compile time or run-time. If BATMAN is ever going to be
> ready for general use it will need stable interfaces that are updated in
> a backward-compatible way and don't depend on debugfs.
Ok, I thought this file was meant for an optional developer information (the
interface to work with batman-adv is in /sys) and concluded too fast that you
are questioning this change because it makes something "unstable" (sry, for
using the wrong term before).
Thanks,
Sven
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH 200/493] irda: remove use of __devinit
From: Stephen Hemminger @ 2012-11-19 20:25 UTC (permalink / raw)
To: Greg KH; +Cc: David Miller, wfp5p, samuel, netdev
In-Reply-To: <20121119192121.GA16694@kroah.com>
On Mon, 19 Nov 2012 11:21:21 -0800
Greg KH <gregkh@linuxfoundation.org> wrote:
> On Mon, Nov 19, 2012 at 02:06:54PM -0500, David Miller wrote:
> >
> > It is absolutely not reasonable to post nearly 500 patches all
> > at the same time.
> >
> > Do not do this ever again.
>
> Bill did this with the assumption that I would take them through my
> driver-core tree, as I asked that he do this work. The 000 message said
> that, but that wasn't sent out to all of the recipients, so I can
> understand how you didn't see this.
>
> Also, I was the only one that got all 500 emails, everyone else should
> have only seen a small quantity.
>
> As you object to these, that's fine, I'll not apply anything to my
> treethat touches the drivers/net/ or net/ tree at this point in time, is
> that ok?
>
> But the end goal is to drop CONFIG_HOTPLUG entirely, and these __dev*
> markings, as they don't do anything anymore.
>
> thanks,
>
> greg k-h
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
This seems like a case where a pull-request should have been used,
rather spamming everyone and every mailing list.
^ permalink raw reply
* Re: [PATCH 085/493] net/wireless: remove use of __devexit_p
From: Arend van Spriel @ 2012-11-19 20:56 UTC (permalink / raw)
To: Bill Pemberton
Cc: gregkh, John W. Linville, Jiri Slaby, Nick Kossifidis,
Luis R. Rodriguez, Simon Kelley, Stefano Brivio,
Stanislav Yakovlev, Dan Williams, Christian Lamparter,
Ivo van Doorn, Gertjan van Wingerde, Helmut Schaa,
Herton Ronaldo Krzesinski, Hin-Tak Leung, Larry Finger,
Luciano Coelho, linux-wireless, netdev, ath5k-devel, b43-dev,
brcm80211-dev-list, libertas-
In-Reply-To: <1353349642-3677-85-git-send-email-wfp5p@virginia.edu>
On 11/19/2012 07:20 PM, Bill Pemberton wrote:
> CONFIG_HOTPLUG is going away as an option so __devexit_p is no longer
> needed.
Acked-by: Arend van Spriel <arend@broadcom.com>
> Signed-off-by: Bill Pemberton <wfp5p@virginia.edu>
> Cc: brcm80211-dev-list@broadcom.com
>
> drivers/net/wireless/brcm80211/brcmsmac/mac80211_if.c | 2 +-
For this part of the patch obviously.
Gr. AvS
^ permalink raw reply
* Re: [PATCH 196/493] net/wireless: remove use of __devinit
From: Arend van Spriel @ 2012-11-19 20:57 UTC (permalink / raw)
To: Bill Pemberton
Cc: gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r, John W. Linville,
Jiri Slaby, Nick Kossifidis, Luis R. Rodriguez, Simon Kelley,
Stefano Brivio, Stanislav Yakovlev, Dan Williams,
Christian Lamparter, Herton Ronaldo Krzesinski, Hin-Tak Leung,
Larry Finger, Chaoming Li, Luciano Coelho,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA, ath5k-devel-xDcbHBWguxEUs3QNXV6qNA,
b43-dev-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
brcm80211-dev-list-dY08KVG/lbpWk0Htik3J/w,
libertas-dev-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <1353349642-3677-196-git-send-email-wfp5p-4Ng6DfrEGID2fBVCVOL8/A@public.gmane.org>
On 11/19/2012 07:22 PM, Bill Pemberton wrote:
> CONFIG_HOTPLUG is going away as an option so __devinit is no longer
> needed.
Acked-by: Arend van Spriel <arend-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
> Signed-off-by: Bill Pemberton <wfp5p-4Ng6DfrEGID2fBVCVOL8/A@public.gmane.org>
> Cc: brcm80211-dev-list-dY08KVG/lbpWk0Htik3J/w@public.gmane.org
> ---
> drivers/net/wireless/brcm80211/brcmsmac/mac80211_if.c | 2 +-
For brcm80211 driver change.
Gr. AvS
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" 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 04/10] batman-adv: export compatibility version via debugfs
From: Antonio Quartulli @ 2012-11-19 21:09 UTC (permalink / raw)
To: David Miller
Cc: bhutchings-s/n/eUQHGBpZroRs9YW3xA, netdev-u79uwXL29TY76Z2rM5mHXA,
b.a.t.m.a.n-ZwoEplunGu2X36UT3dwllkB+6BGkLq7r,
lindner_marek-LWAfsSFWpa4
In-Reply-To: <20121119.144745.1093556126398582629.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 2378 bytes --]
On Mon, Nov 19, 2012 at 02:47:45PM -0500, David Miller wrote:
> From: Sven Eckelmann <sven-KaDOiPu9UxWEi8DpZVb4nw@public.gmane.org>
> Date: Mon, 19 Nov 2012 20:29:07 +0100
>
> > On Monday 19 November 2012 18:52:30 Ben Hutchings wrote:
> >> On Mon, 2012-11-19 at 09:24 +0100, Antonio Quartulli wrote:
> >> > Different versions of the batman-adv module may use the same compatibility
> >> > version, but this is not understandable at runtime (the only way is to
> >> > parse the kernel log and fetch the batman-adv advertisement message on
> >> > loading). The user may want to know whether two nodes using different
> >> > versions can communicate or not. For this purpose the module has to
> >> > export this value through debugfs.
> >> [...]
> >>
> >> I do hope that you're not planning to use unstable debugfs interfaces
> >> indefinitely.
> >
> > Why are you refering to the adding of an file as "incompatible" debugfs
> > interface? I would call it additional information. And the rest of the commit
> > message is talking about *possible* protocol incompatibilies of the network
> > protocol (which caused this uncontrolled erruption of anger in a network
> > maintainer).
>
> Debugfs files aren't where you store information that userspace actually
> uses in normal situations.
>
> It's for developer debug, to expose internals that otherwise have no
> business being part of the user visible interfaces.
Ok, you are right. As you already stated, I do see two problems here:
1) debugfs not used properly (this information is not really for "devs")
2) this compatibility version export is like the claim: "compatibility is broken
everyday". But actually this is not what we really wanted.
This patch simply came from a feature request raised by a user of ours. As Sven
pointed out, we have seen it just as "more information available for network
debugging" and we (in particular me) didn't think about the fact that having
such a patch was against the "stabilisation" process that we are following (we
discussed about this process during the last pull request, so you already know
that we are already going towards this direction).
David, Ben, if you agree I would remove this patch and repost the pull request.
Regards,
--
Antonio Quartulli
..each of us alone is worth nothing..
Ernesto "Che" Guevara
[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: unable to handle paging request, arm, at aio/tcp code, only 3.6
From: Lluís Batlle i Rossell @ 2012-11-19 21:10 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev
In-Reply-To: <1353354095.10798.76.camel@edumazet-glaptop>
On Mon, Nov 19, 2012 at 11:41:35AM -0800, Eric Dumazet wrote:
> On Mon, 2012-11-19 at 19:32 +0100, Lluís Batlle i Rossell wrote:
> > (crosspost from lkml)
> > Hello,
> >
> > in a Sheevaplug (armv5tel), if I run the kernels 3.6.3 or 3.6.6, they crash in
> > less than 48h. Kernel 3.5.3 runs perfect, as most previous kernels I've been
> > running until 2.6.36.
> >
> > Can anyone suggest what change can be the cause of that?
> > Or how could I debug this to fix it?
> >
> > Here is the panic:
> > unable to handle kernel paging request at virtual address ffffffab
> > pgd = d864c000
> > [ffffffab] *pgd=1fffe831, *pte=00000000, *ppte=00000000
> > Internal error: Oops: 1 [#1] PREEMPT ARM
> > Modules linked in: netconsole cbc sg cryptodev(O) fuse ipv6 ums_cypress dm_mod btrfs ext4 jb
> > d2 reiserfs [last unloaded: netconsole]
> > CPU: 0 Tainted: G O (3.6.6 #1)
> > PC is at tcp_v6_mtu_reduced+0x40/0x80 [ipv6]
> > LR is at ip6_dst_lookup_tail+0xd8/0xfc [ipv6]
> > pc : [<bf2b02f8>] lr : [<bf28a67c>] psr: a0000013
> > ...
> Thanks for the report.
>
> I believe this is a regression of commit
> 35ad9b9cf7d8a2e6259a0d24022e910adb6f3489
> (ipv6: Add helper inet6_csk_update_pmtu().)
>
> I'll prepare a patch to fix this.
If it can help, I keep the vmlinux kernel with debug info.
Regards,
Lluís.
^ permalink raw reply
* Re: [PATCH 080/493] fddi: remove use of __devexit_p
From: Jan Engelhardt @ 2012-11-19 21:22 UTC (permalink / raw)
To: Greg KH; +Cc: Maciej W. Rozycki, Bill Pemberton, netdev
In-Reply-To: <20121119192949.GA16976@kroah.com>
On Monday 2012-11-19 20:29, Greg KH wrote:
>
>CONFIG_HOTPLUG is always enabled now, so that's not an option anymore.
>And again, a user can "hot unbind" a driver from a device from
>userspace, no matter if the bus physically supports it or not.
Which mailing list was this originally posted on? (I only have
subscribed to netdev, and google has not indexed 000/493--001/493 yet.)
^ permalink raw reply
* Re: [PATCH 080/493] fddi: remove use of __devexit_p
From: Bill Pemberton @ 2012-11-19 21:30 UTC (permalink / raw)
To: Jan Engelhardt; +Cc: Greg KH, Maciej W. Rozycki, netdev
In-Reply-To: <alpine.LNX.2.01.1211192222160.12904@nerf07.vanv.qr>
Jan Engelhardt writes:
>
> On Monday 2012-11-19 20:29, Greg KH wrote:
> >
> >CONFIG_HOTPLUG is always enabled now, so that's not an option anymore.
> >And again, a user can "hot unbind" a driver from a device from
> >userspace, no matter if the bus physically supports it or not.
>
> Which mailing list was this originally posted on? (I only have
> subscribed to netdev, and google has not indexed 000/493--001/493 yet.)
>
The announcement for this patchset was sent to lkml on Friday. I
originally didn't have the patches themselves Cc'd to the various
subsystems, so no one other than Greg got the patches themselves on
Friday. I resent them with Cc's today.
--
Bill
^ permalink raw reply
* Re: unable to handle paging request, arm, at aio/tcp code, only 3.6
From: Eric Dumazet @ 2012-11-19 21:34 UTC (permalink / raw)
To: Lluís Batlle i Rossell, David Miller; +Cc: netdev
In-Reply-To: <1353354095.10798.76.camel@edumazet-glaptop>
From: Eric Dumazet <edumazet@google.com>
> Thanks for the report.
>
> I believe this is a regression of commit
> 35ad9b9cf7d8a2e6259a0d24022e910adb6f3489
> (ipv6: Add helper inet6_csk_update_pmtu().)
>
> I'll prepare a patch to fix this.
Please try the following fix.
Thanks !
[PATCH] ipv6: fix inet6_csk_update_pmtu() return value
In case of error, inet6_csk_update_pmtu() should consistently
return NULL.
Bug added in commit 35ad9b9cf7d8a
(ipv6: Add helper inet6_csk_update_pmtu().)
Reported-by: Lluís Batlle i Rossell <viric@viric.name>
Signed-off-by: Eric Dumazet <edumazet@google.com>
---
net/ipv6/inet6_connection_sock.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/net/ipv6/inet6_connection_sock.c b/net/ipv6/inet6_connection_sock.c
index c4f9341..3064785 100644
--- a/net/ipv6/inet6_connection_sock.c
+++ b/net/ipv6/inet6_connection_sock.c
@@ -252,6 +252,7 @@ struct dst_entry *inet6_csk_update_pmtu(struct sock *sk, u32 mtu)
return NULL;
dst->ops->update_pmtu(dst, sk, NULL, mtu);
- return inet6_csk_route_socket(sk, &fl6);
+ dst = inet6_csk_route_socket(sk, &fl6);
+ return IS_ERR(dst) ? NULL : dst;
}
EXPORT_SYMBOL_GPL(inet6_csk_update_pmtu);
^ permalink raw reply related
* Re: unable to handle paging request, arm, at aio/tcp code, only 3.6
From: Eric Dumazet @ 2012-11-19 21:36 UTC (permalink / raw)
To: Lluís Batlle i Rossell; +Cc: netdev
In-Reply-To: <20121119211020.GL2068@vicerveza.homeunix.net>
On Mon, 2012-11-19 at 22:10 +0100, Lluís Batlle i Rossell wrote:
> If it can help, I keep the vmlinux kernel with debug info.
Well, it would be better if you could try the patch ;)
Anyway bug seems pretty obvious to me.
Thanks
^ permalink raw reply
* Re: [PATCH] net, batman: don't crash on zero length strings in routing_algo
From: Antonio Quartulli @ 2012-11-19 22:07 UTC (permalink / raw)
To: Sasha Levin; +Cc: lindner_marek, siwu, davem, b.a.t.m.a.n, netdev, linux-kernel
In-Reply-To: <1353355695-23252-1-git-send-email-sasha.levin@oracle.com>
[-- Attachment #1: Type: text/plain, Size: 1246 bytes --]
On Mon, Nov 19, 2012 at 03:08:15PM -0500, Sasha Levin wrote:
> The code that works with routing_algo assumes that the string passed is non
> empty, this assumption is wrong:
>
> sh-4.2# echo -ne '\0' > /sys/module/batman_adv/parameters/routing_algo
> [ 34.531340] BUG: unable to handle kernel paging request at ffff880015142fff
[CUT]
> [ 34.550025] ---[ end trace 6c53b662c574774b ]---
>
> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Hello Sasha,
thank you very much for fixing this bug!
However, any patch sent against the B.A.T.M.A.N.-Advanced code should have a
subject starting with "batman-adv:".
Other than that I think this kind of patch
doesn't really need to report the entire kernel message: a more exhaustive
commit message is enough (e.g. use function names). I personally needed to read
the patch before understanding what you were trying to explain in the message.
Then, we usually pick this patches up in our repo and then we send them as batch
to the networking tree via pull request, therefore you can also skip the netdev
ml when sending the fixes.
Thank you very much!
Regards,
--
Antonio Quartulli
..each of us alone is worth nothing..
Ernesto "Che" Guevara
[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: [PATCH] vxlan: Fix error that was resulting in VXLAN MTU size being 10 bytes too large
From: Joseph Glanville @ 2012-11-19 23:37 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: David Miller, alexander.h.duyck, netdev
In-Reply-To: <20121119080351.477525b3@nehalam.linuxnetplumber.net>
On 20 November 2012 03:03, Stephen Hemminger <shemminger@vyatta.com> wrote:
> On Mon, 19 Nov 2012 22:33:50 +1100
> Joseph Glanville <joseph.glanville@orionvm.com.au> wrote:
>
>> On 14 November 2012 08:33, Stephen Hemminger <shemminger@vyatta.com> wrote:
>> > On Tue, 13 Nov 2012 14:37:19 -0500 (EST)
>> > David Miller <davem@davemloft.net> wrote:
>> >
>> >> From: Alexander Duyck <alexander.h.duyck@intel.com>
>> >> Date: Fri, 09 Nov 2012 15:35:24 -0800
>> >>
>> >> > This change fixes an issue I found where VXLAN frames were fragmented when
>> >> > they were up to the VXLAN MTU size. I root caused the issue to the fact that
>> >> > the headroom was 4 + 20 + 8 + 8. This math doesn't appear to be correct
>> >> > because we are not inserting a VLAN header, but instead a 2nd Ethernet header.
>> >> > As such the math for the overhead should be 20 + 8 + 8 + 14 to account for the
>> >> > extra headers that are inserted for VXLAN.
>> >> >
>> >> > Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
>> >>
>> >> Applied, thanks for the detailed commit message.
>> >
>> > Probably need smarter code there to look at header length requirement
>> > of underlying device as well, maybe someone will be perverse and runn
>> > vxlan over a tunnel or IPoIB.
>>
>> Forgive my ignorance but why would running VXLAN on IPoIB require
>> special header handling? (and would it work or behave strangely?)
>>
>> I was planning on giving this a go when 3.7 is released but I might do
>> that sooner if problems are anticipated.
>>
>> > --
>> > To unsubscribe from this list: send the line "unsubscribe netdev" in
>> > the body of a message to majordomo@vger.kernel.org
>> > More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
>> Joseph.
>>
>
> Some lower layers require bigger (or smaller headers). As it was, vxlan
> was only allocating skb with a fixed amount of headroom. This would lead to
> lower layers having to copy the skb.
>
> My suggestion has already been addressed by a later patch.
Thankyou for the clarification, I found the patch about the lower_dev
hard_header_len!
--
CTO | Orion Virtualisation Solutions | www.orionvm.com.au
Phone: 1300 56 99 52 | Mobile: 0428 754 846
^ permalink raw reply
* Re: [PATCH] pkt_sched: QFQ Plus: fair-queueing service at DRR cost
From: David Miller @ 2012-11-19 23:48 UTC (permalink / raw)
To: paolo.valente; +Cc: jhs, shemminger, linux-kernel, netdev, rizzo, fchecconi
In-Reply-To: <20121112164833.GA12970@paolo-ThinkPad-W520>
From: Paolo Valente <paolo.valente@unimore.it>
Date: Mon, 12 Nov 2012 17:48:33 +0100
> [This patch received positive feedback from Stephen Hemminger ("put in
> net-next"), but no further feedback or decision. So I am (re)sending
> an updated version of it. The only differences with respect to the
> previous version are the support for TSO/GSO (taken from QFQ), and a
> hopefully improved description.]
Can you rearrange the logic so that the compiler doesn't emit this
warning?
In file included from net/sched/sch_qfq.c:18:0:
net/sched/sch_qfq.c: In function ‘qfq_dequeue’:
include/net/sch_generic.h:480:15: warning: ‘skb’ may be used uninitialized in this function [-Wmaybe-uninitialized]
net/sched/sch_qfq.c:1007:18: note: ‘skb’ was declared here
You and I both know that SKB will be initialized at this point, but
the compiler can't see it clearly enough.
Thanks.
^ permalink raw reply
* Re: [PATCH] bonding: rlb mode of bond should not alter ARP originating via bridge
From: David Miller @ 2012-11-19 23:49 UTC (permalink / raw)
To: zheng.x.li; +Cc: netdev, fubar, andy, linux-kernel, joe.jin
In-Reply-To: <1352972861-17577-1-git-send-email-zheng.x.li@oracle.com>
From: Zheng Li <zheng.x.li@oracle.com>
Date: Thu, 15 Nov 2012 17:47:41 +0800
> ARP traffic passing through a bridge and out via the bond (when the bond is a
> port of the bridge) should not have its source MAC address adjusted by the
> receive load balance code in rlb_arp_xmit.
>
> Signed-off-by: Zheng Li <zheng.x.li@oracle.com>
Can I please get a review from some bonding experts on this one?
Thanks!
^ permalink raw reply
* Re: [PATCHv2 net-next] add DOVE extensions for VXLAN
From: David Miller @ 2012-11-19 23:55 UTC (permalink / raw)
To: dlstevens; +Cc: shemminger, netdev
In-Reply-To: <201211151347.qAFDkR8G023134@lab1.dls>
From: David L Stevens <dlstevens@us.ibm.com>
Date: Thu, 15 Nov 2012 08:46:27 -0500
> @@ -111,6 +113,10 @@ struct vxlan_dev {
> __u8 tos; /* TOS override */
> __u8 ttl;
> bool learn;
> + bool proxy; /* ARP reduction */
> + bool rsc; /* route short-circuit */
> + bool l2miss; /* L2 miss notifications */
> + bool l3miss; /* L3 miss notifications */
>
> unsigned long age_interval;
> struct timer_list age_timer;
Perhaps we've accumulated enough boolean states that a "u32 flags" are
in order?
> + for (i=0; i<ETH_ALEN; ++i)
> + send_eth |= !!fdb->eth_addr[i];
Please use is_zero_ether_addr().
Otherwise these changes look fine to me, thanks.
^ permalink raw reply
* Re: [PATCH v2 3.7.0-rc4] of/net/mdio-gpio: Fix pdev->id issue when using devicetrees.
From: David Miller @ 2012-11-19 23:58 UTC (permalink / raw)
To: srinivas.kandagatla; +Cc: netdev, devicetree-discuss
In-Reply-To: <1353062039-31336-1-git-send-email-srinivas.kandagatla@st.com>
From: Srinivas KANDAGATLA <srinivas.kandagatla@st.com>
Date: Fri, 16 Nov 2012 10:33:59 +0000
> From: Srinivas Kandagatla <srinivas.kandagatla@st.com>
>
> When the mdio-gpio driver is probed via device trees, the platform
> device id is set as -1, However the pdev->id is re-used as bus-id for
> while creating mdio gpio bus.
> So
> For device tree case the mdio-gpio bus name appears as "gpio-ffffffff"
> where as
> for non-device tree case the bus name appears as "gpio-<bus-num>"
>
> Which means the bus_id is fixed in device tree case, so we can't have
> two mdio gpio buses via device trees. Assigning a logical bus number
> via device tree solves the problem and the bus name is much consistent
> with non-device tree bus name.
>
> Without this patch
> 1. we can't support two mdio-gpio buses via device trees.
> 2. we should always pass gpio-ffffffff as bus name to phy_connect, very
> different to non-device tree bus name.
>
> So, setting up the bus_id via aliases from device tree is the right
> solution and other drivers do similar thing.
>
> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@st.com>
Applied, thank you.
^ permalink raw reply
* Re: [PATCH v4 1/9] net: core: use this_cpu_ptr per-cpu helper
From: David Miller @ 2012-11-20 0:00 UTC (permalink / raw)
To: shanwei88; +Cc: timo.teras, steffen.klassert, netdev, linux-kernel, cl, htejun
In-Reply-To: <50A5FB69.8000907@gmail.com>
From: Shan Wei <shanwei88@gmail.com>
Date: Fri, 16 Nov 2012 16:38:01 +0800
> Shan Wei said, at 2012/11/13 9:51:
>> From: Shan Wei <davidshan@tencent.com>
>>
>> flush_tasklet is a struct, not a pointer in percpu var.
>> so use this_cpu_ptr to get the member pointer.
>>
>> Signed-off-by: Shan Wei <davidshan@tencent.com>
>> Reviewed-by: Christoph Lameter <cl@linux.com>
>
> David Miller, would you like to pick it up to your net-next tree?
Applied.
^ permalink raw reply
* Re: [PATCH v4 2/9] net: rds: use this_cpu_* per-cpu helper
From: David Miller @ 2012-11-20 0:00 UTC (permalink / raw)
To: shanwei88
Cc: venkat.x.venkatsubra, rds-devel, netdev, linux-kernel, cl, htejun
In-Reply-To: <50A5FB89.4000400@gmail.com>
From: Shan Wei <shanwei88@gmail.com>
Date: Fri, 16 Nov 2012 16:38:33 +0800
> Shan Wei said, at 2012/11/13 9:52:
>> From: Shan Wei <davidshan@tencent.com>
>>
>>
>> Signed-off-by: Shan Wei <davidshan@tencent.com>
>> Reviewed-by: Christoph Lameter <cl@linux.com>
>
> David Miller, would you like to pick it up to your net-next tree?
Applied.
^ permalink raw reply
* Re: [net-next PATCH v2] net/ethernet: remove useless is_valid_ether_addr from drivers ndo_open
From: David Miller @ 2012-11-20 0:03 UTC (permalink / raw)
To: manabian
Cc: nicolas.ferre, shemminger, steve.glendinning, stigge, msink,
netdev
In-Reply-To: <1353077235-342-1-git-send-email-manabian@gmail.com>
From: Joachim Eastwood <manabian@gmail.com>
Date: Fri, 16 Nov 2012 15:47:15 +0100
> If ndo_validate_addr is set to the generic eth_validate_addr
> function there is no point in calling is_valid_ether_addr
> from driver ndo_open if ndo_open is not used elsewhere in
> the driver.
>
> With this change is_valid_ether_addr will be called from the
> generic eth_validate_addr function. So there should be no change
> in the actual behavior.
>
> Signed-off-by: Joachim Eastwood <manabian@gmail.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next 1/4] ipip: allow to deactivate the creation of fb dev
From: David Miller @ 2012-11-20 0:06 UTC (permalink / raw)
To: nicolas.dichtel; +Cc: netdev
In-Reply-To: <1353082456-21234-2-git-send-email-nicolas.dichtel@6wind.com>
From: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Date: Fri, 16 Nov 2012 17:14:13 +0100
> Now that tunnels can be configured via rtnetlink, this device is not mandatory.
> The default is conservative.
>
> Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
I'm not too thrilled about this change, mostly because of my dislike of
module parameters in general.
But in this case there appears to be real bugs in the two sets of changes
where you add this setup_fb thing.
> @@ -1057,7 +1066,8 @@ static void __net_exit ipip_exit_net(struct net *net)
>
> rtnl_lock();
> ipip_destroy_tunnels(ipn, &list);
> - unregister_netdevice_queue(ipn->fb_tunnel_dev, &list);
> + if (setup_fb)
> + unregister_netdevice_queue(ipn->fb_tunnel_dev, &list);
> unregister_netdevice_many(&list);
> rtnl_unlock();
> }
Users can modify module parameter values via sysfs after the module
is loaded, so you need a more internal and protected state to use
to decide whether you really need to unregister the thing or not.
But to me it's just symptomatic of what a bad idea this is in the
first place.
^ permalink raw reply
* Re: [PATCH] netfilter: Remove the spurious \ in __ip_vs_lblc_init
From: Simon Horman @ 2012-11-20 0:06 UTC (permalink / raw)
To: Eric W. Biederman; +Cc: David Miller, netdev, Pablo Neira Ayuso
In-Reply-To: <87zk2d7gwp.fsf@xmission.com>
On Mon, Nov 19, 2012 at 07:26:30AM -0800, Eric W. Biederman wrote:
>
> In (464dc801c76a net: Don't export sysctls to unprivileged users)
> I typoed and introduced a spurious backslash. Delete it.
>
> Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
Pablo, can you take this directly through your tree?
> ---
> net/netfilter/ipvs/ip_vs_lblc.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/net/netfilter/ipvs/ip_vs_lblc.c b/net/netfilter/ipvs/ip_vs_lblc.c
> index d742aa9..fdd89b9 100644
> --- a/net/netfilter/ipvs/ip_vs_lblc.c
> +++ b/net/netfilter/ipvs/ip_vs_lblc.c
> @@ -574,7 +574,7 @@ static int __net_init __ip_vs_lblc_init(struct net *net)
> register_net_sysctl(net, "net/ipv4/vs", ipvs->lblc_ctl_table);
> if (!ipvs->lblc_ctl_header) {
> if (!net_eq(net, &init_net))
> - kfree(ipvs->lblc_ctl_table);\
> + kfree(ipvs->lblc_ctl_table);
> return -ENOMEM;
> }
>
> --
> 1.7.5.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: [PATCH net-next 1/4] ipip: allow to deactivate the creation of fb dev
From: David Miller @ 2012-11-20 0:07 UTC (permalink / raw)
To: nicolas.dichtel; +Cc: shemminger, netdev
In-Reply-To: <50A66DD3.20807@6wind.com>
From: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Date: Fri, 16 Nov 2012 17:46:11 +0100
> By default, the fb device is created, so there is no change if you
> don't set explicitly setup_fb to 0.
Nicolas, this idea is contentous to me too.
Why not put this aside and submit the other parts of your
patch set on their own, since those looked fine to me?
Thanks.
^ permalink raw reply
* Re: [PATCH net-next] gro: Handle inline VLAN tags
From: David Miller @ 2012-11-20 0:10 UTC (permalink / raw)
To: eric.dumazet; +Cc: bhutchings, netdev, linux-net-drivers, gallatin, herbert
In-Reply-To: <1353114559.10798.66.camel@edumazet-glaptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Fri, 16 Nov 2012 17:09:19 -0800
> On Sat, 2012-11-17 at 00:32 +0000, Ben Hutchings wrote:
>> On Fri, 2012-11-16 at 16:16 -0800, Eric Dumazet wrote:
>> > On Sat, 2012-11-17 at 00:00 +0000, Ben Hutchings wrote:
>> >
>> > > I'm not sure what you mean by this. Is your point that the
>> > > copy-on-write is never needed? It is still possible for pskb_may_pull()
>> > > to fail.
>> > >
>> >
>> > A packet sniffer should have a copy of bad frames, even if dropped later
>> > in our stacks.
>> >
>> > GRO layer is not allowed to drop a frame, even if not 'correct'.
>>
>> What do you think the accelerated hardware does with frames that have a
>> truncated VLAN tag?
>
> The hardware should send us the frame, exactly like when RX checksum is
> wrong.
I agree with Eric, and therefore will not apply this patch.
^ permalink raw reply
* Re: [PATCH] net: remove unnecessary wireless includes
From: David Miller @ 2012-11-20 0:10 UTC (permalink / raw)
To: johannes; +Cc: linux-wireless, netdev, johannes.berg
In-Reply-To: <1353099561-14339-1-git-send-email-johannes@sipsolutions.net>
From: Johannes Berg <johannes@sipsolutions.net>
Date: Fri, 16 Nov 2012 21:59:21 +0100
> From: Johannes Berg <johannes.berg@intel.com>
>
> The wireless and wext includes in net-sysfs.c aren't
> needed, so remove them.
>
> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Applied, thanks Johannes.
^ permalink raw reply
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