* Re: [PATCH net-next 1/2] net: convert __IPTUNNEL_XMIT() to an inline function
From: David Miller @ 2012-11-15 1:25 UTC (permalink / raw)
To: amwang; +Cc: netdev
In-Reply-To: <1352706754-16594-1-git-send-email-amwang@redhat.com>
From: Cong Wang <amwang@redhat.com>
Date: Mon, 12 Nov 2012 15:52:33 +0800
> __IPTUNNEL_XMIT() is an ugly macro, convert it to a static
> inline function, so make it more readable.
>
> IPTUNNEL_XMIT() is unused, just remove it.
>
> Cc: David S. Miller <davem@davemloft.net>
> Signed-off-by: Cong Wang <amwang@redhat.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next 2/2] net: unify for_each_ip_tunnel_rcu()
From: David Miller @ 2012-11-15 1:25 UTC (permalink / raw)
To: amwang; +Cc: netdev
In-Reply-To: <1352706754-16594-2-git-send-email-amwang@redhat.com>
From: Cong Wang <amwang@redhat.com>
Date: Mon, 12 Nov 2012 15:52:34 +0800
> The defitions of for_each_ip_tunnel_rcu() are same,
> so unify it. Also, don't hide the parameter 't'.
>
> Cc: David S. Miller <davem@davemloft.net>
> Signed-off-by: Cong Wang <amwang@redhat.com>
Applied.
^ permalink raw reply
* Re: question about RT_TABLE_MAX
From: David Miller @ 2012-11-15 1:28 UTC (permalink / raw)
To: dan.carpenter; +Cc: netdev
In-Reply-To: <20121112145135.GA32199@elgon.mountain>
From: Dan Carpenter <dan.carpenter@oracle.com>
Date: Mon, 12 Nov 2012 17:51:35 +0300
> RT_TABLE_MAX is 0xFFFFFFFF. It's always compared against an unsigned
> int so the checks against it don't test anything.
It used to be 256, that's why the spurious tests are there, they
just need to be cleaned up.
This change happened in commit:
commit b801f54917b7c6e8540f877ee562cd0725e62ebd
Author: Patrick McHardy <kaber@trash.net>
Date: Thu Aug 10 23:12:34 2006 -0700
[NET]: Increate RT_TABLE_MAX to 2^32
Signed-off-by: Patrick McHardy <kaber@trash.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
^ permalink raw reply
* [PATCH] ipv4/ip_vti.c: VTI fix post-decryption forwarding
From: Saurabh Mohan @ 2012-11-15 2:08 UTC (permalink / raw)
To: netdev
With the latest kernel there are two things that must be done post decryption
so that the packet are forwarded.
1. Remove the mark from the packet. This will cause the packet to not match
the ipsec-policy again. However doing this causes the post-decryption check to
fail also and the packet will get dropped. (cat /proc/net/xfrm_stat).
2. Remove the sp association in the skbuff so that no policy check is done on
the packet for VTI tunnels.
Due to #2 above we must now do a security-policy check in the vti rcv path
prior to resetting the mark in the skbuff.
Signed-off-by: Saurabh Mohan <saurabh.mohan@vyatta.com>
Reported-by: Ruben Herold <ruben@puettmann.net>
---
diff --git a/net/ipv4/ip_vti.c b/net/ipv4/ip_vti.c
index 1831092..858fddf 100644
--- a/net/ipv4/ip_vti.c
+++ b/net/ipv4/ip_vti.c
@@ -338,12 +338,17 @@ static int vti_rcv(struct sk_buff *skb)
if (tunnel != NULL) {
struct pcpu_tstats *tstats;
+ if (!xfrm4_policy_check(NULL, XFRM_POLICY_IN, skb))
+ return -1;
+
tstats = this_cpu_ptr(tunnel->dev->tstats);
u64_stats_update_begin(&tstats->syncp);
tstats->rx_packets++;
tstats->rx_bytes += skb->len;
u64_stats_update_end(&tstats->syncp);
+ skb->mark = 0;
+ secpath_reset(skb);
skb->dev = tunnel->dev;
return 1;
}
^ permalink raw reply related
* Re: [RFC PATCH 03/13] net: Add net protocol offload registration infrustructure
From: Vlad Yasevich @ 2012-11-15 2:16 UTC (permalink / raw)
To: Francois Romieu; +Cc: netdev, eric.dumazet, davem
In-Reply-To: <20121114231452.GH27068@electric-eye.fr.zoreil.com>
On 11/14/2012 06:14 PM, Francois Romieu wrote:
> Vlad Yasevich <vyasevic@redhat.com> :
> [...]
>> diff --git a/include/net/protocol.h b/include/net/protocol.h
>> index 929528c..d8ecb17 100644
>> --- a/include/net/protocol.h
>> +++ b/include/net/protocol.h
>> @@ -77,6 +77,15 @@ struct inet6_protocol {
>> #define INET6_PROTO_GSO_EXTHDR 0x4
>> #endif
>>
>> +struct net_offload {
>> + int (*gso_send_check)(struct sk_buff *skb);
>> + struct sk_buff *(*gso_segment)(struct sk_buff *skb,
>> + netdev_features_t features);
>> + struct sk_buff **(*gro_receive)(struct sk_buff **head,
>> + struct sk_buff *skb);
>> + int (*gro_complete)(struct sk_buff *skb);
>> +};
>
> Would it be worth adding a #14 where packet_offload and net_offload
> share a common offload struct instead of duplicating (currently) identical
> members ?
>
I'll look... There are some very minor diffs between the structs, so
one could at least be based on another.
What bugs me more actually is the duplication between IPv4 and IPv6
lists. One idea I had before was to have packet_offload be a container
for the array of net_offloads. We would then have a single set of
functions to register tcp/udp callbacks for both ipv4 and ipv6. I might
resurrect that patch and send it for comments as well.
-vlad
^ permalink raw reply
* Re: [Xen-devel] compound skb frag pages appearing in start_xmit
From: ANNIE LI @ 2012-11-15 2:31 UTC (permalink / raw)
To: Ian Campbell
Cc: Eric Dumazet, Sander Eikelenboom, Eric Dumazet,
netdev@vger.kernel.org, Konrad Rzeszutek Wilk, xen-devel,
Marcos E. Matsunaga
In-Reply-To: <1349950494.14806.29.camel@zakaz.uk.xensource.com>
On 2012-10-11 18:14, Ian Campbell wrote:
> On Thu, 2012-10-11 at 11:05 +0100, Eric Dumazet wrote:
>> On Thu, 2012-10-11 at 12:00 +0200, Sander Eikelenboom wrote:
>>
>>> Probably due to the BUG_ON from the patch below, i changed it into a WARN_ON.
>>> And i seem to hit it, but only in one of the guests at the moment and it triggers quite irregularly.
>> xennet_make_frags() is able to split the skb->head in multiple page-size
>> chunks.
>>
>> It should do the same for fragments
> Right, I just want to be reproduce the issue so I can know I've fixed it
> properly ;-)
Hi Ian,
I can reproduce this BUG_ON when running netperf/netserver test between
two domus running on the same dom0. The domu and dom0 all use v3.7-rc1.
When I tried to rebase my persistent grant netfront/netback patch on
latest kernel, netperf/netserver test never succeeded. I did some test
to find out that v3.6-rc7 works fine, but v3.7-rc1, v3.7-rc2 and
v3.7-rc4 does not succeed in netperf/netserver test. So I keep my
persistent grant patch only based on v3.4-rc3 now.
Konrad thought about commit 6a8ed462f16b8455eec5ae00eb6014159a6721f0 in
v3.7-rc1, and suggested me to test your debug patch in netfront. This
BUG_ON happens soon after running the netperf/netserver test case.
Thanks
Annie
>
> Ian.
>
>
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
^ permalink raw reply
* Re: [PATCH] ipv4/ip_vti.c: VTI fix post-decryption forwarding
From: David Miller @ 2012-11-15 2:41 UTC (permalink / raw)
To: saurabh.mohan; +Cc: netdev
In-Reply-To: <20121115020815.GA2732@debian-saurabh-64.vyatta.com>
From: Saurabh Mohan <saurabh.mohan@vyatta.com>
Date: Wed, 14 Nov 2012 18:08:15 -0800
>
>
> With the latest kernel there are two things that must be done post decryption
> so that the packet are forwarded.
> 1. Remove the mark from the packet. This will cause the packet to not match
> the ipsec-policy again. However doing this causes the post-decryption check to
> fail also and the packet will get dropped. (cat /proc/net/xfrm_stat).
> 2. Remove the sp association in the skbuff so that no policy check is done on
> the packet for VTI tunnels.
>
> Due to #2 above we must now do a security-policy check in the vti rcv path
> prior to resetting the mark in the skbuff.
>
> Signed-off-by: Saurabh Mohan <saurabh.mohan@vyatta.com>
> Reported-by: Ruben Herold <ruben@puettmann.net>
Applied, and queued up for -stable, thanks.
^ permalink raw reply
* Re: [PATCH net-next] vmxnet3: fix indentation
From: David Miller @ 2012-11-15 2:48 UTC (permalink / raw)
To: shemminger; +Cc: sbhatewara, netdev
In-Reply-To: <20121113155328.0914d6f1@nehalam.linuxnetplumber.net>
From: Stephen Hemminger <shemminger@vyatta.com>
Date: Tue, 13 Nov 2012 15:53:28 -0800
> Minor indentation out of alignment.
>
> Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] drivers/net: fix tasklet misuse issue
From: David Miller @ 2012-11-15 2:50 UTC (permalink / raw)
To: xtfeng; +Cc: dannyfeng, netdev, linux-kernel
In-Reply-To: <1352872056-5637-1-git-send-email-xtfeng@gmail.com>
From: Xiaotian Feng <xtfeng@gmail.com>
Date: Wed, 14 Nov 2012 13:47:36 +0800
> In commit 175c0dff, drivers uses tasklet_kill to avoid put disabled tasklet
> on the tasklet vec. But some of the drivers uses tasklet_init & tasklet_disable
> in the driver init code, then tasklet_enable when it is opened. This makes
> tasklet_enable on a killed tasklet and make ksoftirqd crazy then. Normally,
> drivers should use tasklet_init/tasklet_kill on device open/remove, and use
> tasklet_disable/tasklet_enable on device suspend/resume.
>
> Reported-by: Peter Wu <lekensteyn@gmail.com>
> Tested-by: Peter Wu <lekensteyn@gmail.com>
> Signed-off-by: Xiaotian Feng <dannyfeng@tencent.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] net/smsc911x: Fix ready check in cases where WORD_SWAP is needed
From: David Miller @ 2012-11-15 2:51 UTC (permalink / raw)
To: kamlakant.patel; +Cc: netdev, steve, linus.walleij, robert.marklund
In-Reply-To: <1352893298-20058-1-git-send-email-kamlakant.patel@broadcom.com>
From: "Kamlakant Patel" <kamlakant.patel@broadcom.com>
Date: Wed, 14 Nov 2012 17:11:38 +0530
> The chip ready check added by the commit 3ac3546e [Always wait for
> the chip to be ready] does not work when the register read/write
> is word swapped. This check has been added before the WORD_SWAP
> register is programmed, so we need to check for swapped register
> value as well.
>
> Bit 16 is marked as RESERVED in SMSC datasheet, Steve Glendinning
> <steve@shawell.net> checked with SMSC and wrote:
>
> The chip architects have concluded we should be reading PMT_CTRL
> until we see any of bits 0, 8, 16 or 24 set. Then we should read
> BYTE_TEST to check the byte order is correct (as we already do).
>
> The rationale behind this is that some of the chip variants have
> word order swapping features too, so the READY bit could actually
> be in any of the 4 possible locations. The architects have confirmed
> that if any of these 4 positions is set the chip is ready. The other
> 3 locations will either never be set or can only go high after READY
> does (so also indicate the device is ready).
>
> This change will check for the READY bit at the 16th position. We do
> not check the other two cases (bit 8 and 24) since the driver does not
> support byte-swapped register read/write.
>
> Signed-off-by: Kamlakant Patel <kamlakant.patel@broadcom.com>
Applied, thank you.
^ permalink raw reply
* Re: [patch net] net: correct check in dev_addr_del()
From: David Miller @ 2012-11-15 2:52 UTC (permalink / raw)
To: jiri; +Cc: netdev, eric.dumazet, shemminger, john.r.fastabend
In-Reply-To: <1352897464-832-1-git-send-email-jiri@resnulli.us>
From: Jiri Pirko <jiri@resnulli.us>
Date: Wed, 14 Nov 2012 13:51:04 +0100
> Check (ha->addr == dev->dev_addr) is always true because dev_addr_init()
> sets this. Correct the check to behave properly on addr removal.
>
> Signed-off-by: Jiri Pirko <jiri@resnulli.us>
I'm pretty sure this is very intentional.
It's trying to prevent deletion of the implicit dev->dev_addr
entry. But it will allow decementing the reference count to
1, but no further.
I'm not applying this.
^ permalink raw reply
* Re: [PATCH v7] Network driver for the Armada 370 and Armada XP ARM Marvell SoCs
From: David Miller @ 2012-11-15 2:59 UTC (permalink / raw)
To: thomas.petazzoni
Cc: romieu, kernel, netdev, linux-arm-kernel, jason, andrew,
gregory.clement, alior, dima
In-Reply-To: <1352905010-24172-1-git-send-email-thomas.petazzoni@free-electrons.com>
From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Date: Wed, 14 Nov 2012 15:56:44 +0100
> The previous versions of this patch set have been sent on September
> 4th (v1), October 11th (v2), October 23rd (v3), October 26th (v4),
> November 12th (v5), November 13th (v6) and now comes the v7 of the
> driver. The number of comments over the last versions have been really
> small, and I would really appreciate if this driver could land into
> the 3.8 kernel release.
I can't apply this patch to net-next, because for one thing there
are missing dependencies. For example, the file:
arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
doesn't exist there, therefore patch #6 won't apply.
^ permalink raw reply
* Re: [PATCH net-next 0/10] Add support of tunnel management via rtnetlink
From: David Miller @ 2012-11-15 3:03 UTC (permalink / raw)
To: nicolas.dichtel; +Cc: netdev, eric.dumazet
In-Reply-To: <1352906047-11604-1-git-send-email-nicolas.dichtel@6wind.com>
From: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Date: Wed, 14 Nov 2012 16:13:57 +0100
> The goal of this serie is to add the support of ipip, sit and ip6tnl tunnels
> via rtnetlink.
>
> The patch against iproute2 will be sent once the patches are included and
> net-next merged. I can send it on demand.
Great work, all applied to net-next.
Thanks Nicolas!
^ permalink raw reply
* Latest 3.6.6 are not compiling due tg3 network driver, hwmon_device_unregister
From: Denys Fedoryshchenko @ 2012-11-15 3:03 UTC (permalink / raw)
To: Matt Carlson, Michael Chan, netdev, linux-kernel
Hi
During compiling i am getting that:
drivers/built-in.o: In function `tg3_close':
tg3.c:(.text+0x12902e): undefined reference to
`hwmon_device_unregister'
drivers/built-in.o: In function `tg3_hwmon_open':
tg3.c:(.text+0x12ae09): undefined reference to `hwmon_device_register'
Kernel config are at http://nuclearcat.com/config-tg3.txt , but i
noticed this error are appearing at x86, x64 kernels, probably also
other 3.6.x series kernels.
Disabling TG3 driver helps, but i believe it is not a solution.
---
Denys Fedoryshchenko, Network Engineer, Virtual ISP S.A.L.
^ permalink raw reply
* Re: [PATCH net-next 1/4] tg3: Set 10_100_ONLY flag for additional 10/100 Mbps devices
From: David Miller @ 2012-11-15 3:05 UTC (permalink / raw)
To: mchan; +Cc: netdev, nsujir
In-Reply-To: <1352940269-23821-1-git-send-email-mchan@broadcom.com>
From: "Michael Chan" <mchan@broadcom.com>
Date: Wed, 14 Nov 2012 16:44:26 -0800
> From: Nithin Nayak Sujir <nsujir@broadcom.com>
>
> - Also refactor the conditional to use the existing tg3_pci_tbl array.
> - Set flags in the driver_data field of the pci_device_id structure to
> identify these devices.
> - Add PCI_DEVICE_SUB() to pci.h to declare PCI 4-part IDs to match these
> devices.
>
> Signed-off-by: Nithin Nayak Sujir <nsujir@broadcom.com>
> Signed-off-by: Michael Chan <mchan@broadcom.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next 2/4] tg3: Prevent spurious tx timeout by setting carrier off before tx disable.
From: David Miller @ 2012-11-15 3:05 UTC (permalink / raw)
To: mchan; +Cc: netdev, nsujir
In-Reply-To: <1352940269-23821-2-git-send-email-mchan@broadcom.com>
From: "Michael Chan" <mchan@broadcom.com>
Date: Wed, 14 Nov 2012 16:44:27 -0800
> From: Nithin Nayak Sujir <nsujir@broadcom.com>
>
> The watchdog will not trigger when the carrier is off when reconfiguring
> the device. Because carrier state is now off during reset, we need to
> introduce a link_up flag to keep track of link state during PHY setup.
>
> Signed-off-by: Nithin Nayak Sujir <nsujir@broadcom.com>
> Signed-off-by: Michael Chan <mchan@broadcom.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next 3/4] tg3: Cleanup hardcoded ethtool test array indexes
From: David Miller @ 2012-11-15 3:05 UTC (permalink / raw)
To: mchan; +Cc: netdev, nsujir
In-Reply-To: <1352940269-23821-3-git-send-email-mchan@broadcom.com>
From: "Michael Chan" <mchan@broadcom.com>
Date: Wed, 14 Nov 2012 16:44:28 -0800
> From: Nithin Nayak Sujir <nsujir@broadcom.com>
>
> Signed-off-by: Nithin Nayak Sujir <nsujir@broadcom.com>
> Signed-off-by: Michael Chan <mchan@broadcom.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next 4/4] tg3: Use tp->rxq_cnt when checking RSS tables.
From: David Miller @ 2012-11-15 3:05 UTC (permalink / raw)
To: mchan; +Cc: netdev, nsujir
In-Reply-To: <1352940269-23821-4-git-send-email-mchan@broadcom.com>
From: "Michael Chan" <mchan@broadcom.com>
Date: Wed, 14 Nov 2012 16:44:29 -0800
> irq_cnt is no longer reliable since rxq_cnt can be independently configured.
>
> Update version to 3.127.
>
> Signed-off-by: Michael Chan <mchan@broadcom.com>
Applied.
^ permalink raw reply
* Re: pull request: wireless-next 2012-11-14
From: David Miller @ 2012-11-15 3:07 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, netdev, linux-kernel
In-Reply-To: <20121114190510.GA6128@tuxdriver.com>
From: "John W. Linville" <linville@tuxdriver.com>
Date: Wed, 14 Nov 2012 14:05:11 -0500
> This pull request is intended for the 3.8 stream...
Pulled, thanks John.
^ permalink raw reply
* Re: [PATCH V5 0/7] ARM: AM33XX: net: Add DT support to CPSW and MDIO driver
From: David Miller @ 2012-11-15 3:09 UTC (permalink / raw)
To: mugunthanvnm
Cc: netdev, devicetree-discuss, linux-arm-kernel, linux-omap,
b-cousson, paul
In-Reply-To: <1352920080-6179-1-git-send-email-mugunthanvnm@ti.com>
From: Mugunthan V N <mugunthanvnm@ti.com>
Date: Thu, 15 Nov 2012 00:37:53 +0530
> This patch-series adds support for,
>
> [1/7]: Typo mistake in CPSW driver while invoking runtime_pm api's
>
> [2/7]: Adds parent<->child relation between CPSW & MDIO module inside cpsw
> driver, as in case of AM33XX, the resources are shared and common
> register bit-field is provided to control module/clock enable/disable,
> makes it difficult to handle common resource.
>
> So the solution here is, to create parent<->child relation between them.
>
> [3/7]: cpsw: simplify the setup of the register pointers
>
> [4/7]: cpsw: Kernel warn fix during suspend
>
> [5/7]: Add hwmod entry for MDIO module, required for MDIO driver.
>
> [6/7]: Enable CPSW support to omap2plus_defconfig
>
> [7/7]: Add DT device nodes for both CPSW and MDIO modules in am33xx.dtsi,
> am335x-evm.dts and am335x-bone.dts file
>
> This patch series has been created on top of net-next/master and tested
> on BeagleBone platform for NFS boot and basic ping test cases.
All applied, thanks.
^ permalink raw reply
* Re: pull request: batman-adv 2012-11-14
From: David Miller @ 2012-11-15 3:11 UTC (permalink / raw)
To: ordex; +Cc: netdev, b.a.t.m.a.n
In-Reply-To: <1352924189-18843-1-git-send-email-ordex@autistici.org>
From: Antonio Quartulli <ordex@autistici.org>
Date: Wed, 14 Nov 2012 21:16:18 +0100
> here is again our new patchset intended for net-next/linux-3.8.
> Patch 1/11 has been modified to address the problems you pointed out last time;
> however hash_bytes has kept its inline tag and it has been moved to hash.h (in
> this way it becomes usable by the rest of the batman-adv code for new changes).
Pulled, thanks.
^ permalink raw reply
* Re: [PATCH v2 0/3] macb add support for phy gpio interrupt
From: David Miller @ 2012-11-15 3:23 UTC (permalink / raw)
To: manabian; +Cc: nicolas.ferre, plagnioj, netdev
In-Reply-To: <1352678188-18647-1-git-send-email-manabian@gmail.com>
From: Joachim Eastwood <manabian@gmail.com>
Date: Mon, 12 Nov 2012 00:56:25 +0100
> Main feature of this patch set is phy gpio interrupt for macb.
...
> Patch series was tested on a custom board with DM9161AEP and AT91RM9200 EMAC.
Applied.
If there are problems found during testing we can fix or revert.
^ permalink raw reply
* Re: Latest 3.6.6 are not compiling due tg3 network driver, hwmon_device_unregister
From: Nithin Nayak Sujir @ 2012-11-15 3:24 UTC (permalink / raw)
To: Denys Fedoryshchenko; +Cc: Michael Chan, netdev, linux-kernel
In-Reply-To: <8b566c4a9ee622737212dc17291ee238@visp.net.lb>
This was fixed by
commit de0a41484c47d783dd4d442914815076aa2caac2
Author: Paul Gortmaker <paul.gortmaker@windriver.com>
Date: Mon Oct 1 11:43:49 2012 -0400
tg3: unconditionally select HWMON support when tg3 is enabled.
Nithin.
On 11/14/2012 07:03 PM, Denys Fedoryshchenko wrote:
> Hi
>
> During compiling i am getting that:
>
> drivers/built-in.o: In function `tg3_close':
> tg3.c:(.text+0x12902e): undefined reference to `hwmon_device_unregister'
> drivers/built-in.o: In function `tg3_hwmon_open':
> tg3.c:(.text+0x12ae09): undefined reference to `hwmon_device_register'
>
> Kernel config are at http://nuclearcat.com/config-tg3.txt , but i noticed this error are
> appearing at x86, x64 kernels, probably also other 3.6.x series kernels.
> Disabling TG3 driver helps, but i believe it is not a solution.
>
> ---
> Denys Fedoryshchenko, Network Engineer, Virtual ISP S.A.L.
> --
> 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: Latest 3.6.6 are not compiling due tg3 network driver, hwmon_device_unregister
From: David Rientjes @ 2012-11-15 3:30 UTC (permalink / raw)
To: Nithin Nayak Sujir, Paul Gortmaker
Cc: Denys Fedoryshchenko, Michael Chan, netdev, linux-kernel
In-Reply-To: <50A4606D.4020402@broadcom.com>
On Wed, 14 Nov 2012, Nithin Nayak Sujir wrote:
> This was fixed by
>
> commit de0a41484c47d783dd4d442914815076aa2caac2
> Author: Paul Gortmaker <paul.gortmaker@windriver.com>
> Date: Mon Oct 1 11:43:49 2012 -0400
>
> tg3: unconditionally select HWMON support when tg3 is enabled.
>
Would you mind submitting this for stable by following the procedure
described in Documentation/stable_kernel_rules.txt?
^ permalink raw reply
* Re: [PATCHES] Networking fixes for -stable.
From: David Miller @ 2012-11-15 3:31 UTC (permalink / raw)
To: ben; +Cc: gregkh, peter.senna, stable, netdev
In-Reply-To: <1352836286.16264.102.camel@deadeye.wl.decadent.org.uk>
From: Ben Hutchings <ben@decadent.org.uk>
Date: Tue, 13 Nov 2012 19:51:26 +0000
> On Mon, 2012-11-12 at 00:25 -0500, David Miller wrote:
>> Please queue up the following networking bug fixes for
>> 3.0.x, 3.2.x, 3.4.x, and 3.6.x, respectively.
> [...]
>> From 2204849a85383fbde75680aa199142abe504adbb Mon Sep 17 00:00:00 2001
>> From: Peter Senna Tschudin <peter.senna@gmail.com>
>> Date: Sun, 28 Oct 2012 06:12:01 +0000
>> Subject: [PATCH 7/9] drivers/net/phy/mdio-bitbang.c: Call mdiobus_unregister
>> before mdiobus_free
>>
>> [ Upstream commit aa731872f7d33dcb8b54dad0cfb82d4e4d195d7e ]
>>
>> Based on commit b27393aecf66199f5ddad37c302d3e0cfadbe6c0
>>
>> Calling mdiobus_free without calling mdiobus_unregister causes
>> BUG_ON(). This patch fixes the issue.
> [...]
>
> This introduces a regresssion, as mdiobus_unregister() is not safe to
> call if the bus isn't registered. Registration is controlled by the
> drivers that use mdio-bitbang, and they should take care of
> unregistration too - and most of them do.
>
> This should be reverted in mainline and not applied to any stable
> series.
Ok, I'll revert.
Greg, please toss it from your -stable queue as well.
Thanks!
^ 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