* Re: [PATCH] Fix SJA1000 command register writes on SMP systems
From: Oliver Hartkopp @ 2010-05-17 19:47 UTC (permalink / raw)
To: Wolfgang Grandegger
Cc: SocketCAN Core Mailing List, Linux Netdev List, David Miller,
stable-DgEjT+Ai2ygdnm+yROfE0A
In-Reply-To: <4BF152E4.1060306-5Yr1BZd7O62+XT7JhA+gdA@public.gmane.org>
On 17.05.2010 16:29, Wolfgang Grandegger wrote:
> Hi Oliver,
>
> On 05/17/2010 01:06 PM, Oliver Hartkopp wrote:
>> The SJA1000 command register is concurrently written in the rx-path to free
>> the receive buffer _and_ in the tx-path to start the transmission.
>> On SMP systems this leads to a write stall in the tx-path, which can be
>> solved by adding some locking for the command register in the SMP case.
>
> We should explain why a write stall can happen. Here is the relavant
> part from the SJA1000 data sheet, 6.4.4 COMMAND REGISTER (CMR):
>
> "Between two commands at least one internal clock cycle is needed in
> order to proceed. The internal clock is half of the external oscillator
> frequency."
The delay directly after the register access can only be guaranteed when there
is some locking around the command register write access.
In the end it boils down to a SMP issue again as this is (from all known
environments) the only case, where the problem appears in reality.
This was also what i've taken from the discussion on the SocketCAN ML.
I don't stick on the patch description. Would you like to produce a different
one? My Acked-by for the code remains sure :-)
Regards,
Oliver
^ permalink raw reply
* Re: [PATCH net-next-2.6 2/2] bonding: allow user-controlled output slave selection
From: Jay Vosburgh @ 2010-05-17 19:25 UTC (permalink / raw)
To: Neil Horman; +Cc: Andy Gospodarek, netdev
In-Reply-To: <20100517184508.GD17419@hmsreliant.think-freely.org>
Neil Horman <nhorman@tuxdriver.com> wrote:
>Neil Horman <nhorman@tuxdriver.com> wrote:
>> So, its sounding to me like everyone is leaning toward a new mode approach here.
>> Before we go ahead and start coding, I hear the bullet points for this approach
>> as:
>>
>> 1) Implement a new bond mode where queue ids are used to steer frames to output
>> interfaces
>>
>> 2) Use said mode to imply universal frame reception (i.e. remove the keep_all
>> knob, and turn on that behavior when this new mode is selected)
>>
>> 3) use John F.'s skb_should_drop changes to implement the keep_all feature.
>>
>> Does that sound about right?
>>
>> Regards
>> Neil
>>
>Ping, Jay, any feedback on these bullet points. I'd like to keep working on
>this while we have the time, but I'd rather not play guess & check on the list
>here any more than we need to.
I've been thinking on this and trying some variations.
After further discussion with John Fastabend, I don't think a
new mode is warranted for this particular work, largely because the FCOE
case wants to run under essentially any mode (the magic FCOE switches
don't care, they just divert the FC traffic regardless of the switch
port settings). Perhaps some specific multi-queue gizmo will become a
new mode down the road.
Part of my thinking for originally wanting a new mode was that
your changes didn't expose the slave device queues, but after further
discussion, that isn't actually the case.
I thought about removing the whole special case for "deliver to
direct bindings" and have a switch instead to always deliver to
everybody. In the end, I don't think that would end up making things
much simpler, because the special cases have to stay for the "normal"
inactive slave behavior to pass the ARP, ARP-over-VLAN, ETH_P_SLOW, etc
traffic. It also would come at the cost of disabling the duplicate
suppressor for the FCOE case, and I don't think that's what they want.
I'm thinking right now to go with more or less the three patch
series that John Fastabend posted last week, along with a variant of
your patch. As much as I'd like to do both things as a unified patch,
doing so just doesn't seem to simplify the existing code, and ends up
being less than optimal for both cases.
For John's patches, a few minor changes, but that basic idea
(flag in the skb); I'm still chewing on the "VLAN don't copy IFF_MASTER
or SLAVE flag" patch though, just to make sure it won't break anything,
but I don't think it's a critical change.
For your patch, I'm exploring the idea of not setting
IFF_SLAVE_INACTIVE on "inactive" slaves for an "all_slaves_active"
option (I think that's a more descriptive name than "keep_all") instead
of adding a new KEEP_ALL flag bit to priv_flags. Did you consider this
methodology and exclude it for some reason?
Hopefully there won't be any pushback against using a flag bit
in the skb. I haven't thought of a way to do what's desired in an
efficient manner without storing state in the skb somewhere. The
skb->skb_iif does hold the original device receiving the skb, but I have
to believe that converting that to a struct net_device * (for the
"direct bind to original slave" case) in __netif_receive_skb is more
expensive that stashing a flag in the skb.
-J
---
-Jay Vosburgh, IBM Linux Technology Center, fubar@us.ibm.com
^ permalink raw reply
* Kernel crash with sky2
From: Joerg Roedel @ 2010-05-17 18:52 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev
Hi Stephen,
I experience the following crash with 2.6.34 in the sky2 code on my
laptop when I plug off the lan-cable and then plug-off the power cable
and switching to battery. It does not happen with acpi=off.
I havn't tested earlier kernels but I can do that if necessary. I did
some initial research and found that the driver assumes that port[1] is
available when the status bits for it are set on the device. Please let
me know if you need any additional information or want me to test
anything.
The crash message is:
[ 107.010134] sky2 0000:02:00.0: PCI hardware error (0xffff)
[ 107.015614] sky2 0000:02:00.0: PCI Express error (0xffffffff)
[ 107.021355] sky2 0000:02:00.0: eth0: ram data read parity error
[ 107.027249] sky2 0000:02:00.0: eth0: ram data write parity error
[ 107.033253] sky2 0000:02:00.0: eth0: MAC parity error
[ 107.038283] sky2 0000:02:00.0: eth0: RX parity error
[ 107.043259] sky2 0000:02:00.0: eth0: TCP segmentation error
[ 107.048823] BUG: unable to handle kernel NULL pointer dereference at 0000000000000438
[ 107.053238] IP: [<ffffffffa0001713>] sky2_hw_error+0x153/0x310 [sky2]
[ 107.053238] PGD 139600067 PUD 139643067 PMD 0
[ 107.053238] Oops: 0000 [#1] SMP
[ 107.053238] last sysfs file: /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
[ 107.053238] CPU 1
[ 107.053238] Modules linked in: snd_hda_codec_atihdmi snd_hda_codec_idt snd_hda_intel rfcomm snd_pcm_oss snd_hda_2
[ 107.053238]
[ 107.053238] Pid: 7, comm: ksoftirqd/1 Not tainted 2.6.34-default #1 307E/HP ProBook 6545b
[ 107.053238] RIP: 0010:[<ffffffffa0001713>] [<ffffffffa0001713>] sky2_hw_error+0x153/0x310 [sky2]
[ 107.053238] RSP: 0018:ffff880001e83d78 EFLAGS: 00010202
[ 107.053238] RAX: 0000000000000001 RBX: 0000000000ffffff RCX: 00000000000001f4
[ 107.053238] RDX: 000000000000000a RSI: 0000000000000202 RDI: ffffffff81a5dc80
[ 107.053238] RBP: ffff880001e83db8 R08: 00000000ffffffff R09: 0000000000000000
[ 107.053238] R10: 0000000000000000 R11: 0000000000000001 R12: ffff88012862da00
[ 107.053238] R13: 0000000000000001 R14: 0000000000000001 R15: 0000000000000000
[ 107.053238] FS: 00007ff07987b800(0000) GS:ffff880001e80000(0000) knlGS:0000000000000000
[ 107.053238] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[ 107.053238] CR2: 0000000000000438 CR3: 0000000139641000 CR4: 00000000000006e0
[ 107.053238] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 107.053238] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[ 107.053238] Process ksoftirqd/1 (pid: 7, threadinfo ffff88013badc000, task ffff88013bad1700)
[ 107.053238] Stack:
[ 107.053238] ffff88013b488b00 ffff8801284f7000 00000a8800000ad7 00000000ffffffff
[ 107.053238] <0> ffff88012862da00 00000000ffffffff ffff88013b4d1000 ffff88013b488b00
[ 107.053238] <0> ffff880001e83ed8 ffffffffa000720f 0000000000000082 0000000000000000
[ 107.053238] Call Trace:
[ 107.053238] <IRQ>
[ 107.053238] [<ffffffffa000720f>] sky2_poll+0xeef/0x1020 [sky2]
[ 107.053238] [<ffffffff8101e1bb>] ? lapic_timer_broadcast+0x1b/0x20
[ 107.053238] [<ffffffff8106a76f>] ? __queue_work+0x3f/0x50
[ 107.053238] [<ffffffff8106a7b9>] ? delayed_work_timer_fn+0x39/0x50
[ 107.053238] [<ffffffff8142bffd>] net_rx_action+0xed/0x1f0
[ 107.053238] [<ffffffff81057250>] __do_softirq+0xb0/0x1d0
[ 107.053238] [<ffffffff81003e4c>] call_softirq+0x1c/0x30
[ 107.053238] <EOI>
[ 107.053238] [<ffffffff810058b5>] ? do_softirq+0x55/0x90
[ 107.053238] [<ffffffff81056dd0>] run_ksoftirqd+0x80/0x130
[ 107.053238] [<ffffffff81056d50>] ? run_ksoftirqd+0x0/0x130
[ 107.053238] [<ffffffff8106e8e6>] kthread+0x96/0xa0
[ 107.053238] [<ffffffff81003d54>] kernel_thread_helper+0x4/0x10
[ 107.053238] [<ffffffff8106e850>] ? kthread+0x0/0xa0
[ 107.053238] [<ffffffff81003d50>] ? kernel_thread_helper+0x0/0x10
[ 107.053238] Code: e8 d3 a7 43 e1 85 c0 0f 85 f5 00 00 00 44 89 f0 ba 00 02 00 00 c1 e0 06 0d a0 01 00 00 89 c0 4
[ 107.053238] RIP [<ffffffffa0001713>] sky2_hw_error+0x153/0x310 [sky2]
[ 107.053238] RSP <ffff880001e83d78>
[ 107.053238] CR2: 0000000000000438
[ 107.392268] ---[ end trace 8a4d942e73cd8681 ]---
[ 107.396866] Kernel panic - not syncing: Fatal exception in interrupt
[ 107.403214] Pid: 7, comm: ksoftirqd/1 Tainted: G D 2.6.34-default #1
[ 107.410230] Call Trace:
[ 107.412695] <IRQ> [<ffffffff8150d49d>] panic+0x7d/0xf7
[ 107.418004] [<ffffffff81511502>] oops_end+0xe2/0xf0
[ 107.422970] [<ffffffff8102dd6b>] no_context+0xfb/0x260
[ 107.428174] [<ffffffff8102dfdd>] __bad_area_nosemaphore+0x10d/0x1c0
[ 107.434523] [<ffffffff8102e0a3>] bad_area_nosemaphore+0x13/0x20
[ 107.440513] [<ffffffff81513aaf>] do_page_fault+0x26f/0x330
[ 107.446084] [<ffffffff815108df>] page_fault+0x1f/0x30
[ 107.451202] [<ffffffffa0001713>] ? sky2_hw_error+0x153/0x310 [sky2]
[ 107.457554] [<ffffffffa00015f6>] ? sky2_hw_error+0x36/0x310 [sky2]
[ 107.463811] [<ffffffffa000720f>] sky2_poll+0xeef/0x1020 [sky2]
[ 107.469706] [<ffffffff8101e1bb>] ? lapic_timer_broadcast+0x1b/0x20
[ 107.475980] [<ffffffff8106a76f>] ? __queue_work+0x3f/0x50
[ 107.481457] [<ffffffff8106a7b9>] ? delayed_work_timer_fn+0x39/0x50
[ 107.487698] [<ffffffff8142bffd>] net_rx_action+0xed/0x1f0
[ 107.493183] [<ffffffff81057250>] __do_softirq+0xb0/0x1d0
[ 107.498558] [<ffffffff81003e4c>] call_softirq+0x1c/0x30
[ 107.503868] <EOI> [<ffffffff810058b5>] ? do_softirq+0x55/0x90
[ 107.509788] [<ffffffff81056dd0>] run_ksoftirqd+0x80/0x130
[ 107.515275] [<ffffffff81056d50>] ? run_ksoftirqd+0x0/0x130
[ 107.520823] [<ffffffff8106e8e6>] kthread+0x96/0xa0
[ 107.525702] [<ffffffff81003d54>] kernel_thread_helper+0x4/0x10
[ 107.531612] [<ffffffff8106e850>] ? kthread+0x0/0xa0
[ 107.536563] [<ffffffff81003d50>] ? kernel_thread_helper+0x0/0x10
[ 107.542657] [drm:drm_fb_helper_panic] *ERROR* panic occurred, switching back to text console
[ 107.551054] BUG: scheduling while atomic: ksoftirqd/1/7/0x10000100
[ 107.552642] Modules linked in: snd_hda_codec_atihdmi snd_hda_codec_idt snd_hda_intel rfcomm snd_pcm_oss snd_hda_2
[ 107.552642] Pid: 7, comm: ksoftirqd/1 Tainted: G D 2.6.34-default #1
[ 107.552642] Call Trace:
[ 107.552642] <IRQ> [<ffffffff810402d1>] __schedule_bug+0x61/0x70
[ 107.552642] [<ffffffff8150ddec>] schedule+0x6cc/0x800
[ 107.552642] [<ffffffff8104c8ba>] __cond_resched+0x2a/0x40
[ 107.552642] [<ffffffff8150e020>] _cond_resched+0x30/0x40
[ 107.552642] [<ffffffff8111e241>] __kmalloc+0xc1/0x190
[ 107.552642] [<ffffffffa00b5613>] ? T.687+0x13/0x20 [drm_kms_helper]
[ 107.552642] [<ffffffffa00b5613>] T.687+0x13/0x20 [drm_kms_helper]
[ 107.552642] [<ffffffffa00b5707>] drm_crtc_helper_set_config+0xe7/0x880 [drm_kms_helper]
[ 107.552642] [<ffffffffa00b35d4>] drm_fb_helper_force_kernel_mode+0x74/0xa0 [drm_kms_helper]
[ 107.552642] [<ffffffffa00b3663>] drm_fb_helper_panic+0x23/0x30 [drm_kms_helper]
[ 107.552642] [<ffffffff81513bc6>] notifier_call_chain+0x56/0x80
[ 107.552642] [<ffffffff81513c2a>] atomic_notifier_call_chain+0x1a/0x20
[ 107.552642] [<ffffffff8150d4c9>] panic+0xa9/0xf7
[ 107.552642] [<ffffffff81511502>] oops_end+0xe2/0xf0
[ 107.552642] [<ffffffff8102dd6b>] no_context+0xfb/0x260
[ 107.552642] [<ffffffff8102dfdd>] __bad_area_nosemaphore+0x10d/0x1c0
[ 107.552642] [<ffffffff8102e0a3>] bad_area_nosemaphore+0x13/0x20
[ 107.552642] [<ffffffff81513aaf>] do_page_fault+0x26f/0x330
[ 107.552642] [<ffffffff815108df>] page_fault+0x1f/0x30
[ 107.552642] [<ffffffffa0001713>] ? sky2_hw_error+0x153/0x310 [sky2]
[ 107.552642] [<ffffffffa00015f6>] ? sky2_hw_error+0x36/0x310 [sky2]
[ 107.552642] [<ffffffffa000720f>] sky2_poll+0xeef/0x1020 [sky2]
[ 107.552642] [<ffffffff8101e1bb>] ? lapic_timer_broadcast+0x1b/0x20
[ 107.552642] [<ffffffff8106a76f>] ? __queue_work+0x3f/0x50
[ 107.552642] [<ffffffff8106a7b9>] ? delayed_work_timer_fn+0x39/0x50
[ 107.552642] [<ffffffff8142bffd>] net_rx_action+0xed/0x1f0
[ 107.552642] [<ffffffff81057250>] __do_softirq+0xb0/0x1d0
[ 107.552642] [<ffffffff81003e4c>] call_softirq+0x1c/0x30
[ 107.552642] <EOI> [<ffffffff810058b5>] ? do_softirq+0x55/0x90
[ 107.552642] [<ffffffff81056dd0>] run_ksoftirqd+0x80/0x130
[ 107.552642] [<ffffffff81056d50>] ? run_ksoftirqd+0x0/0x130
[ 107.552642] [<ffffffff8106e8e6>] kthread+0x96/0xa0
[ 107.552642] [<ffffffff81003d54>] kernel_thread_helper+0x4/0x10
[ 107.552642] [<ffffffff8106e850>] ? kthread+0x0/0xa0
[ 107.552642] [<ffffffff81003d50>] ? kernel_thread_helper+0x0/0x10
lspci -vvv -n of the device:
02:00.0 0200: 11ab:436c (rev 10)
Subsystem: 103c:3080
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 64 bytes
Interrupt: pin A routed to IRQ 28
Region 0: Memory at d5200000 (64-bit, non-prefetchable) [size=16K]
Region 2: I/O ports at 4000 [size=256]
Expansion ROM at d0000000 [disabled] [size=128K]
Capabilities: [48] Power Management version 3
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold+)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [50] Vital Product Data <?>
Capabilities: [5c] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0 Enable+
Address: 00000000fee0100c Data: 4189
Capabilities: [c0] Express (v2) Legacy Endpoint, MSI 00
DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s unlimited, L1 unlimited
ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset-
DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
MaxPayload 128 bytes, MaxReadReq 512 bytes
DevSta: CorrErr+ UncorrErr- FatalErr- UnsuppReq+ AuxPwr+ TransPend-
LnkCap: Port #1, Speed 2.5GT/s, Width x1, ASPM L0s L1, Latency L0 <256ns, L1 unlimited
ClockPM+ Suprise- LLActRep- BwNot-
LnkCtl: ASPM L0s L1 Enabled; RCB 128 bytes Disabled- Retrain- CommClk+
ExtSynch- ClockPM+ AutWidDis- BWInt- AutBWInt-
LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
Capabilities: [100] Advanced Error Reporting <?>
Capabilities: [130] Device Serial Number 70-5a-b6-ff-ff-97-a6-80
Kernel driver in use: sky2
Kernel modules: sky2
Thanks,
Joerg
^ permalink raw reply
* Re: Kernel crash with sky2
From: Stephen Hemminger @ 2010-05-17 19:22 UTC (permalink / raw)
To: Joerg Roedel; +Cc: netdev
In-Reply-To: <20100517185228.GG9007@amd.com>
On Mon, 17 May 2010 20:52:28 +0200
Joerg Roedel <joerg.roedel@amd.com> wrote:
> Hi Stephen,
>
> I experience the following crash with 2.6.34 in the sky2 code on my
> laptop when I plug off the lan-cable and then plug-off the power cable
> and switching to battery. It does not happen with acpi=off.
So you have a busted BIOS that powers off the device.
> I havn't tested earlier kernels but I can do that if necessary. I did
> some initial research and found that the driver assumes that port[1] is
> available when the status bits for it are set on the device. Please let
> me know if you need any additional information or want me to test
> anything.
The driver assumes that it won't get garbage in NAPI.
> The crash message is:
>
> [ 107.010134] sky2 0000:02:00.0: PCI hardware error (0xffff)
> [ 107.015614] sky2 0000:02:00.0: PCI Express error (0xffffffff)
> [ 107.021355] sky2 0000:02:00.0: eth0: ram data read parity error
> [ 107.027249] sky2 0000:02:00.0: eth0: ram data write parity error
> [ 107.033253] sky2 0000:02:00.0: eth0: MAC parity error
> [ 107.038283] sky2 0000:02:00.0: eth0: RX parity error
> [ 107.043259] sky2 0000:02:00.0: eth0: TCP segmentation error
> [ 107.048823] BUG: unable to handle kernel NULL pointer dereference at 0000000000000438
> [ 107.053238] IP: [<ffffffffa0001713>] sky2_hw_error+0x153/0x310 [sky2]
> [ 107.053238] PGD 139600067 PUD 139643067 PMD 0
> [ 107.053238] Oops: 0000 [#1] SMP
> [ 107.053238] last sysfs file: /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
> [ 107.053238] CPU 1
> [ 107.053238] Modules linked in: snd_hda_codec_atihdmi snd_hda_codec_idt snd_hda_intel rfcomm snd_pcm_oss snd_hda_2
> [ 107.053238]
Something in power management has turned off your device.
The fact that the sky2 driver has decided to die is unintended casulty.
This will stop the crash, but not fix the problem with PM.
As soon as it sees the device off, it will go offline until you reboot.
--- a/drivers/net/sky2.c 2010-05-17 12:09:22.721738360 -0700
+++ b/drivers/net/sky2.c 2010-05-17 12:19:52.845893670 -0700
@@ -2904,6 +2904,16 @@ static int sky2_poll(struct napi_struct
int work_done = 0;
u16 idx;
+ if (unlikely(status == ~0)) {
+ int i;
+ dev_err(&hw->pdev->dev,
+ "device no longer available (powered off?)\n");
+
+ for (i = 0; i < hw->ports; i++)
+ netif_device_detach(hw->dev[i]);
+ goto complete;
+ }
+
if (unlikely(status & Y2_IS_ERROR))
sky2_err_intr(hw, status);
@@ -2922,7 +2932,7 @@ static int sky2_poll(struct napi_struct
if (work_done >= work_limit)
goto done;
}
-
+complete:
napi_complete(napi);
sky2_read32(hw, B0_Y2_SP_LISR);
done:
--
^ permalink raw reply
* iproute2 issue with adding rules.
From: Ben Greear @ 2010-05-17 19:03 UTC (permalink / raw)
To: NetDev
On older releases, you can do this with iproute:
# ip ru add from 9.9.9.2/32 table 226 pref 400
#
But, in latest git, it returns an error:
# ip ru add from 9.9.9.2/32 table 226 pref 400
Error: an inet prefix is expected rather than "9.9.9.2/32".
Is that on purpose?
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [PATCH net-next-2.6 2/2] bonding: allow user-controlled output slave selection
From: Neil Horman @ 2010-05-17 18:45 UTC (permalink / raw)
To: Andy Gospodarek; +Cc: Jay Vosburgh, netdev
In-Reply-To: <20100513171504.GD21535@shamino.rdu.redhat.com>
On Thu, May 13, 2010 at 01:15:04PM -0400, Neil Horman wrote:
> On Wed, May 12, 2010 at 06:14:08PM -0400, Andy Gospodarek wrote:
> > On Wed, May 12, 2010 at 12:41:54PM -0700, Jay Vosburgh wrote:
> > > Neil Horman <nhorman@tuxdriver.com> wrote:
> > >
> > > >On Tue, May 11, 2010 at 01:09:39PM -0700, Jay Vosburgh wrote:
> > > >> Andy Gospodarek <andy@greyhouse.net> wrote:
> > > >>
> > > >> >This patch give the user the ability to control the output slave for
> > > >> >round-robin and active-backup bonding. Similar functionality was
> > > >> >discussed in the past, but Jay Vosburgh indicated he would rather see a
> > > >> >feature like this added to existing modes rather than creating a
> > > >> >completely new mode. Jay's thoughts as well as Neil's input surrounding
> > > >> >some of the issues with the first implementation pushed us toward a
> > > >> >design that relied on the queue_mapping rather than skb marks.
> > > >> >Round-robin and active-backup modes were chosen as the first users of
> > > >> >this slave selection as they seemed like the most logical choices when
> > > >> >considering a multi-switch environment.
> > > >> >
> > > >> >Round-robin mode works without any modification, but active-backup does
> > > >> >require inclusion of the first patch in this series and setting
> > > >> >the 'keep_all' flag. This will allow reception of unicast traffic on
> > > >> >any of the backup interfaces.
> > > >>
> > > >> Yes, I did think that the mark business fit better into existing
> > > >> modes (I thought of it as kind of a new hash for xor and 802.3ad modes).
> > > >> I also didn't expect to see so much new stuff (this, as well as the FCOE
> > > >> special cases being discussed elsewhere) being shoehorned into the
> > > >> active-backup mode. I'm not so sure that adding so many special cases
> > > >> to active-backup is a good thing.
> > > >>
> > > >> Now, I'm starting to wonder if you were right, and it would be
> > > >> better overall to have a "manual" mode that would hopefully satisfy this
> > > >> case as well as the FCOE special case. I don't think either of these is
> > > >> a bad use case, I'm just not sure the right way to handle them is
> > > >> another special knob in active-backup mode (either directly, or
> > > >> implicitly in __netif_receive_skb), which wasn't what I expected to see.
> > > >>
> > > >I honestly don't think a separate mode is warranted here. While I'm not opposed
> > > >to adding a new mode, I really think doing so is no different from overloading
> > > >an existing mode. I say that because to add a new mode in which we explicitly
> > > >expect traffic to be directed to various slaves requires that we implement a
> > > >policy for frames which have no queue mapping determined on egress. Any policy
> > > >I can think of is really an approximation of an existing policy, so we may as
> > > >well reuse the policy code that we already have in place. About the only way a
> > > >separate mode makes sense is in the 'passthrough' queue mode you document below.
> > > >In this model, in which queue ids map to slaves in a 1:1 fashion it doesn't make
> > > >senes.
> > >
> > > One goal I'm hoping to achieve is something that would satisfy
> > > both the queue map stuff that you're looking for, and would meet the
> > > needs of the FCOE people who also want to disable the duplicate
> > > suppression (i.e., permit incoming traffic on the inactive slave) for a
> > > different special case.
> > >
> > > The FCOE proposal revolves around, essentially, active-backup
> > > mode, but permitting incoming traffic on the inactive slave. At the
> > > moment, the patches attempt to special case things such that only
> > > dev_add_pack listeners directly bound to the inactive slave are checked
> > > (to permit the FCOE traffic to pass on the inactive slave, but still
> > > dropping IP, as ip_rcv is a wildcard bind).
> > >
> > > Your keep_all patch is, by and large, the same thing, except
> > > that it permits anything to come in on the "inactive" slave, and it's a
> > > switch that has to be turned on.
> > >
> > > This seems like needless duplication to me; I'd prefer to see a
> > > single solution that handles both cases instead of two special cases
> > > that each do 90% of what the other does.
> > >
> > > As far as a new mode goes, one major reason I think a separate
> > > mode is warranted is the semantics: with either of these changes (to
> > > permit more or less regular use of the "inactive" slaves), the mode
> > > isn't really an "active-backup" mode any longer; there is no "inactive"
> > > or "backup" slave. I think of this as being a major change of
> > > functionality, not simply a minor option.
> > >
> > > Hence my thought that "active-backup" could stay as a "true" hot
> > > standby mode (backup slaves are just that: for backup, only), and this
> > > new mode would be the place to do the special queue-map / FCOE /
> > > whatever that isn't really a hot standby configuration any longer.
> > >
> > > As far as the behavior of the new mode (your concern about its
> > > policy map approximations), in the end, it would probably act pretty
> > > much like active-backup with your patch applied: traffic goes out the
> > > active slave, unless directed otherwise. It's a lot less complicated
> > > than I had feared.
> > >
> >
> > It's beginning to sound like the 'FCoE use-case' and the one Neil and I
> > are proposing are quite similar. The main goal of both is to have the
> > option to have multiple slaves send and receive traffic during the
> > steady-state, but in the event of a failover all traffic would run on a
> > single interface.
> >
> > The implementation proposed with this patch is a bit different that the
> > 'mark-mode' patch you may recall I posted a few months ago. It created
> > a new mode that essentially did exactly what you are describing --
> > transmit on the primary interface unless pushed to another interface via
> > info in the skb and receive on all interfaces. We initially did not
> > create a new mode based on your reservations about the previous
> > mark-mode patch and went the direction of enhancing one or two modes
> > initially (figuring it would be good to run before walking), with the
> > idea that other modes could take care of this output slave selection
> > logic in the future.
>
>
> So, its sounding to me like everyone is leaning toward a new mode approach here.
> Before we go ahead and start coding, I hear the bullet points for this approach
> as:
>
> 1) Implement a new bond mode where queue ids are used to steer frames to output
> interfaces
>
> 2) Use said mode to imply universal frame reception (i.e. remove the keep_all
> knob, and turn on that behavior when this new mode is selected)
>
> 3) use John F.'s skb_should_drop changes to implement the keep_all feature.
>
> Does that sound about right?
>
> Regards
> Neil
>
Ping, Jay, any feedback on these bullet points. I'd like to keep working on
this while we have the time, but I'd rather not play guess & check on the list
here any more than we need to.
> --
> 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
* pull request: wireless-next-2.6 2010-05-17
From: John W. Linville @ 2010-05-17 18:26 UTC (permalink / raw)
To: davem-fT/PcQaiUtIeIZ0/mPfg9Q
Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA
Dave,
One last big batch intended for 2.6.35 -- these have all been in
linux-next for several days. Included are the usual driver updates for
iwlwifi, ath9k, and rt2x00 along with a smattering of other bits
(including some trivial fixups).
Please let me know if there are problems!
Thanks,
John
---
The following changes since commit 278554bd6579206921f5d8a523649a7a57f8850d:
David S. Miller (1):
Merge branch 'master' of master.kernel.org:/.../davem/net-2.6
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-next-2.6.git for-davem
Abhijeet Kolekar (3):
iwl3945: fix scan races
iwl3945: add plcp error checking
mac80211: fix paged defragmentation
Dan Carpenter (3):
wl1271: add missing spin_lock()
wl1271: fix notifier interface supported test
wl1271: remove some unneeded code
Felix Fietkau (4):
ath9k: use debugfs_remove_recursive() instead of keeping pointers to all entries
ath9k: add debugfs files for reading/writing the rx and tx chainmask
ath9k: add debugfs files for reading/writing registers
ath9k_hw: clean up EEPROM endian handling on AR9003
Gertjan van Wingerde (6):
rt2x00: Consistently name skb frame descriptor skbdesc.
rt2x00: Fix beacon descriptor writing for rt61pci.
rt2x00: Re-order tx descriptor writing code in drivers.
rt2x00: Simplify TXD handling of beacons.
rt2x00: Dump beacons under a different identifier than TX frames.
rt2x00: In debugfs frame dumping allow the TX descriptor to be part of the skb.
Johannes Berg (34):
iwlagn: wait for asynchronous firmware loading
iwlwifi: use vif iwl_bss_info_changed
iwl3945: use iwl3945_add_bcast_station
iwlwifi: pass address to iwl_remove_station
iwlwifi: manage IBSS station properly
iwlagn: show and store firmware build number
iwl3945: remove ucode access indirection
iwlwifi: remove ucode virtual functions
iwlwifi: move eeprom version printout to eeprom init
iwlagn: prepare for new firmware file format
iwlagn: implement loading a new firmware file type
iwlwifi: remove rts_threshold
iwlagn: move iwl_get_ra_sta_id to 4965
iwlagn: use vif->type to check station
iwlwifi: apply filter flags directly
iwlwifi: push virtual interface through
iwlagn: use virtual interface in TX aggregation handling
iwlwifi: remove useless priv->vif check
iwlwifi: use vif in iwl_ht_conf
iwlwifi: note that priv->bssid is used only by 3945
iwlwifi: fix iwl_sta_init_lq station ID
iwlwifi: split allocation/sending local station LQ
iwlwifi: rework broadcast station management
iwlwifi: track station IDs
iwlwifi: add iwl_sta_id()
iwlwifi: use iwl_find_station less
iwlagn: use iwl_sta_id() for aggregation
iwlwifi: use iwl_sta_id() for TKIP key update
iwlwifi: move iwl_find_station() to 4965
iwlwifi: rename iwl_add_local_station
iwlwifi: remove pointless HT check
iwlwifi: clear driver stations when going down
mac80211: don't process work item with wrong frame
mac80211: add offload channel switch support
John W. Linville (2):
Merge branch 'master' of git://git.kernel.org/.../linville/wireless-2.6
Merge branch 'master' of git://git.kernel.org/.../linville/wireless-next-2.6 into for-davem
Julia Lawall (1):
drivers/net/wireless/hostap: Drop memory allocation cast
Luis R. Rodriguez (2):
ath5k: drop warning on jumbo frames
ath9k_hw: new initialization values for AR9003
Reinette Chatre (3):
Merge branch 'wireless-2.6' into wireless-next-2.6
iwlwifi: make bcast LQ command available for later restore actions
iwlagn: work around rate scaling reset delay
Shanyu Zhao (2):
iwlwifi: rename 6000 series Gen2 devices to Gen2a
iwlwifi: dump firmware build info in error case
Steve Tanner (1):
ar9170usb: add vendor and device ID for Qwest/Actiontec 802AIN Wireless N USB Network Adapter
Sujith.Manoharan-DlyHzToyqoxBDgjK7y7TUQ@public.gmane.org (5):
ath9k_htc: Lock sta_notify() callback
ath9k_htc: Allocate URBs properly
ath9k_htc: Reorder HTC initialization
ath9k_htc: Fix target ready race condition
ath9k_htc: Fix array overflow
Vasanthakumar Thiagarajan (2):
ath9k: Fix bug in handling rx frames with invalid descriptor content
ath9k: Remove unused rx_edma in ath_rx_addbuffer_edma()
Wey-Yi Guy (11):
iwlwifi: remove powersave debugfs if it is not supported
iwlwifi: rename "tx_power" to "chain_tx_power"
iwlwifi: remove device type checking for tx power in debugfs
iwlwifi: use .cfg to enable/disable continuous ucode trace
iwlwifi: use cfg to configure calibration operation
iwlwifi: give correct return information for tx power debugfs
iwlwifi: wimax co-exist code clean up
iwlwifi: checking for all the possible failure cases
iwlwifi: "tx power per chain" are part of ucode_tx_stats
iwlwifi: provide more comments for cfg structure
mac80211: check channel switch mode for future frames transmit
drivers/net/wireless/ath/ar9170/usb.c | 2 +
drivers/net/wireless/ath/ath5k/base.c | 12 +-
drivers/net/wireless/ath/ath9k/ar9003_eeprom.c | 174 +++----
drivers/net/wireless/ath/ath9k/ar9003_eeprom.h | 10 +-
drivers/net/wireless/ath/ath9k/ar9003_initvals.h | 268 ++++++------
drivers/net/wireless/ath/ath9k/debug.c | 236 ++++++++--
drivers/net/wireless/ath/ath9k/debug.h | 8 +-
drivers/net/wireless/ath/ath9k/hif_usb.c | 58 ++--
drivers/net/wireless/ath/ath9k/htc_drv_init.c | 7 +
drivers/net/wireless/ath/ath9k/htc_drv_main.c | 4 +
drivers/net/wireless/ath/ath9k/htc_hst.c | 51 +-
drivers/net/wireless/ath/ath9k/htc_hst.h | 15 +-
drivers/net/wireless/ath/ath9k/recv.c | 3 +-
drivers/net/wireless/hostap/hostap_80211_rx.c | 3 +-
drivers/net/wireless/hostap/hostap_ioctl.c | 3 +-
drivers/net/wireless/iwlwifi/iwl-1000.c | 9 +-
drivers/net/wireless/iwlwifi/iwl-3945.c | 147 ++++--
drivers/net/wireless/iwlwifi/iwl-3945.h | 22 +-
drivers/net/wireless/iwlwifi/iwl-4965.c | 100 +++--
drivers/net/wireless/iwlwifi/iwl-5000.c | 27 +-
drivers/net/wireless/iwlwifi/iwl-6000.c | 51 ++-
drivers/net/wireless/iwlwifi/iwl-agn-debugfs.c | 16 +
drivers/net/wireless/iwlwifi/iwl-agn-lib.c | 31 +-
drivers/net/wireless/iwlwifi/iwl-agn-tx.c | 29 +-
drivers/net/wireless/iwlwifi/iwl-agn-ucode.c | 109 +++--
drivers/net/wireless/iwlwifi/iwl-agn.c | 556 +++++++++++++++-------
drivers/net/wireless/iwlwifi/iwl-agn.h | 14 +-
drivers/net/wireless/iwlwifi/iwl-commands.h | 6 +-
drivers/net/wireless/iwlwifi/iwl-core.c | 199 +++-----
drivers/net/wireless/iwlwifi/iwl-core.h | 60 ++-
drivers/net/wireless/iwlwifi/iwl-debugfs.c | 66 +--
drivers/net/wireless/iwlwifi/iwl-dev.h | 89 +++-
drivers/net/wireless/iwlwifi/iwl-eeprom.c | 7 +
drivers/net/wireless/iwlwifi/iwl-power.c | 5 +-
drivers/net/wireless/iwlwifi/iwl-rx.c | 9 +-
drivers/net/wireless/iwlwifi/iwl-scan.c | 16 +-
drivers/net/wireless/iwlwifi/iwl-sta.c | 456 ++++++++----------
drivers/net/wireless/iwlwifi/iwl-sta.h | 60 ++-
drivers/net/wireless/iwlwifi/iwl3945-base.c | 163 ++++---
drivers/net/wireless/rt2x00/rt2400pci.c | 26 +-
drivers/net/wireless/rt2x00/rt2500pci.c | 26 +-
drivers/net/wireless/rt2x00/rt2500usb.c | 55 ++-
drivers/net/wireless/rt2x00/rt2800pci.c | 14 +-
drivers/net/wireless/rt2x00/rt2800usb.c | 8 +-
drivers/net/wireless/rt2x00/rt2x00debug.c | 21 +-
drivers/net/wireless/rt2x00/rt2x00dump.h | 3 +
drivers/net/wireless/rt2x00/rt2x00pci.c | 9 -
drivers/net/wireless/rt2x00/rt2x00queue.c | 15 +-
drivers/net/wireless/rt2x00/rt2x00queue.h | 3 +
drivers/net/wireless/rt2x00/rt2x00usb.c | 8 -
drivers/net/wireless/rt2x00/rt61pci.c | 35 +-
drivers/net/wireless/rt2x00/rt73usb.c | 71 ++--
drivers/net/wireless/wl12xx/wl1271_main.c | 5 +-
include/net/mac80211.h | 39 ++
net/mac80211/driver-ops.h | 11 +
net/mac80211/driver-trace.h | 49 ++
net/mac80211/ieee80211_i.h | 3 +-
net/mac80211/mlme.c | 59 +++-
net/mac80211/rx.c | 6 +
net/mac80211/work.c | 27 +-
60 files changed, 2152 insertions(+), 1442 deletions(-)
Omnibus patch available here:
http://www.kernel.org/pub/linux/kernel/people/linville/wireless-next-2.6-2010-05-17.patch.bz2
--
John W. Linville Someday the world will need a hero, and you
linville-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org might be all we have. Be ready.
--
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 0/6] netns support in the kobject layer
From: Greg KH @ 2010-05-17 18:11 UTC (permalink / raw)
To: David Miller
Cc: ebiederm, gregkh, kay.sievers, linux-kernel, tj, cornelia.huck,
eric.dumazet, bcrl, serue, netdev
In-Reply-To: <20100515.232643.212422307.davem@davemloft.net>
On Sat, May 15, 2010 at 11:26:43PM -0700, David Miller wrote:
> From: Greg KH <greg@kroah.com>
> Date: Thu, 6 May 2010 13:04:04 -0700
>
> > On Tue, May 04, 2010 at 05:35:54PM -0700, Eric W. Biederman wrote:
> >>
> >> With the tagged sysfs support finally merged into Greg's tree,
> >> it is time for the last little bits of work to get the kobject
> >> layer and network namespaces to play together properly.
> >>
> >> These patches are roughly evenly divided between network layer work
> >> and sysfs layer work. Last time this conundrum came up I believe
> >> we decided that the easiest way to handle this was for Greg to carry
> >> all of the patches. David, Greg does that still make sense?
> >
> > That's fine, if I get David's ack on these.
>
> Looks good to me:
>
> Acked-by: David S. Miller <davem@davemloft.net>
Ok. Eric, can you resend these to me when .35-rc1 is out so I can queue
them up then to get some testing in linux-next so that they can make it
into .36?
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH v3 3/3] ptp: Added a clock that uses the eTSEC found on the MPC85xx.
From: Scott Wood @ 2010-05-17 18:05 UTC (permalink / raw)
To: Richard Cochran; +Cc: netdev, devicetree-discuss, linuxppc-dev
In-Reply-To: <20100517082757.GA9703@riccoc20.at.omicron.at>
On 05/17/2010 03:27 AM, Richard Cochran wrote:
> On Fri, May 14, 2010 at 12:46:57PM -0500, Scott Wood wrote:
>> On 05/14/2010 11:46 AM, Richard Cochran wrote:
>>> diff --git a/Documentation/powerpc/dts-bindings/fsl/tsec.txt b/Documentation/powerpc/dts-bindings/fsl/tsec.txt
>>
>> Get rid of both device_type and model, and specify a compatible
>> string instead (e.g. "fsl,etsec-ptp").
>
> Okay, will do. I really am at a loss at understanding all the rules in
> the whole device tree world. I just tried to follow
> Documentation/powerpc and what is already present in the kernel.
There's some stuff in there that isn't how we'd do it now, but is slow
to change for compatibility reasons.
>> Or perhaps this should just be some additional properties on the
>> existing gianfar nodes, rather than presenting it as a separate
>> device? How do you associate a given ptp block with the
>> corresponding gianfar node?
>
> There only one PTP clock. Its registers repeat in each port's memory
> space, but you are only supposed to touch the first set of PTP
> registers.
OK. I'm not too familiar with PTP itself, was looking more at the
device tree and similar structural bits.
> There are no differences (that I know of) in how the PTP clocks
> work. I have in house the mpc8313, the mpc8572, and the p2020. The
> mpc8572 appears to lack some of the TMR_CTRL bits, but this is
> probably a documentation bug. I will check it.
If there's any possibility of needing to make a distinction (which
probably can't be ruled out with future chips), the chip name could be
made part of the compatible string, with a secondary compatible showing
a canonical part name for that version of the PTP block. E.g. p2020
might have:
compatble = "fsl,p2020-etsec-ptp", "fsl,mpc8313-etsec-ptp";
The driver would bind only on the mpc8313 version.
There are several examples of this, such as the Freescale i2c driver and
binding (ignore the legacy "fsl-i2c").
>> > >+ - tmr_fiper1 Fixed interval period pulse generator.
>> > >+ - tmr_fiper2 Fixed interval period pulse generator.
>>
MPC8572 and P2020 have fiper3 as well.
>> They should probably have an "fsl,ptp-" prefix as well.
>
> Okay, but must I then change the following code in order to find them?
> Does adding the prefix just mean that I also add it to my search
> strings, or is it preprocessed (stripped) somehow?
It is not stripped; you have to change the code as well.
>> You've got two IRQs, with the same handler, and the same dev_id?
>> From the manual it looks like there's one PTP interrupt per eTSEC
>> (which would explain 3 interrupts on p2020).
>
> Will reduce to just one IRQ.
The device tree should still contain all of the interrupts, in case
they're needed later -- and put a comment in the driver saying why the
first interrupt seems sufficient.
>>> +static struct of_device_id match_table[] = {
>>> + { .type = "ptp_clock" },
>>> + {},
>>> +};
>>
>> This driver controls every possible PTP implementation?
>
> No, I only want to match with the eTSEC clock device. Given the
> compatible string above ("fsl,etsec-ptp"), what is the correct way to
> do this? (pointer to an existing driver to emulate would be enough)
Put .compatible = "fsl,etsec-ptp" (or "fsl,mpc8313-etsec-ptp") where you
have .type = "ptp_clock".
-Scott
^ permalink raw reply
* Re: [PATCH -next] bridge: fix build for CONFIG_SYSFS disabled
From: Randy Dunlap @ 2010-05-17 18:01 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: Stephen Rothwell, linux-next, LKML, netdev, davem
In-Reply-To: <20100517105654.2451e61f@nehalam>
On 05/17/10 10:56, Stephen Hemminger wrote:
> On Mon, 17 May 2010 09:17:56 -0700
> Randy Dunlap <randy.dunlap@oracle.com> wrote:
>
>> From: Randy Dunlap <randy.dunlap@oracle.com>
>>
>> Fix build when CONFIG_SYSFS is not enabled:
>>
>> net/bridge/br_if.c:136: error: 'struct net_bridge_port' has no member named 'sysfs_name'
>>
>> Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
>> ---
>> net/bridge/br_if.c | 2 ++
>> 1 file changed, 2 insertions(+)
>>
>> --- linux-next-20100517.orig/net/bridge/br_if.c
>> +++ linux-next-20100517/net/bridge/br_if.c
>> @@ -133,7 +133,9 @@ static void del_nbp(struct net_bridge_po
>> struct net_bridge *br = p->br;
>> struct net_device *dev = p->dev;
>>
>> +#ifdef CONFIG_SYSFS
>> sysfs_remove_link(br->ifobj, p->sysfs_name);
>> +#endif
>>
>> dev_set_promiscuity(dev, -1);
>>
>
> I don't like peppering code with #ifdef like this.
Thanks. I didn't like it either.
> Turns out that in this place sysfs_name is always the same
> as the device name so instead:
>
>
> --- a/net/bridge/br_if.c 2010-05-17 10:40:49.808031840 -0700
> +++ b/net/bridge/br_if.c 2010-05-17 10:49:47.767669246 -0700
> @@ -133,7 +133,7 @@ static void del_nbp(struct net_bridge_po
> struct net_bridge *br = p->br;
> struct net_device *dev = p->dev;
>
> - sysfs_remove_link(br->ifobj, p->sysfs_name);
> + sysfs_remove_link(br->ifobj, p->dev->name);
>
> dev_set_promiscuity(dev, -1);
>
>
>
--
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
^ permalink raw reply
* Re: [PATCH -next] bridge: fix build for CONFIG_SYSFS disabled
From: Stephen Hemminger @ 2010-05-17 17:56 UTC (permalink / raw)
To: Randy Dunlap; +Cc: Stephen Rothwell, linux-next, LKML, netdev, davem
In-Reply-To: <20100517091756.e232bdc2.randy.dunlap@oracle.com>
On Mon, 17 May 2010 09:17:56 -0700
Randy Dunlap <randy.dunlap@oracle.com> wrote:
> From: Randy Dunlap <randy.dunlap@oracle.com>
>
> Fix build when CONFIG_SYSFS is not enabled:
>
> net/bridge/br_if.c:136: error: 'struct net_bridge_port' has no member named 'sysfs_name'
>
> Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
> ---
> net/bridge/br_if.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> --- linux-next-20100517.orig/net/bridge/br_if.c
> +++ linux-next-20100517/net/bridge/br_if.c
> @@ -133,7 +133,9 @@ static void del_nbp(struct net_bridge_po
> struct net_bridge *br = p->br;
> struct net_device *dev = p->dev;
>
> +#ifdef CONFIG_SYSFS
> sysfs_remove_link(br->ifobj, p->sysfs_name);
> +#endif
>
> dev_set_promiscuity(dev, -1);
>
I don't like peppering code with #ifdef like this.
Turns out that in this place sysfs_name is always the same
as the device name so instead:
--- a/net/bridge/br_if.c 2010-05-17 10:40:49.808031840 -0700
+++ b/net/bridge/br_if.c 2010-05-17 10:49:47.767669246 -0700
@@ -133,7 +133,7 @@ static void del_nbp(struct net_bridge_po
struct net_bridge *br = p->br;
struct net_device *dev = p->dev;
- sysfs_remove_link(br->ifobj, p->sysfs_name);
+ sysfs_remove_link(br->ifobj, p->dev->name);
dev_set_promiscuity(dev, -1);
--
^ permalink raw reply
* Re: [PATCH BUGFIX ] ipv6: fix the bug of address check
From: Stephen Hemminger @ 2010-05-17 17:31 UTC (permalink / raw)
To: Shan Wei; +Cc: David Miller, netdev@vger.kernel.org
In-Reply-To: <4BF1354A.3060003@cn.fujitsu.com>
On Mon, 17 May 2010 20:23:38 +0800
Shan Wei <shanwei@cn.fujitsu.com> wrote:
>
> If there are several IPv6 addresses with same hash value in hashlist,
> and they are all not matched with addr argument.
> In this case, ipv6_chk_addr() should return 0.
>
> This bug is introduced by commit c2e21293c054817c42eb5fa9c613d2ad51954136
> (title: ipv6: convert addrconf list to hlist).
>
> Signed-off-by: Shan Wei <shanwei@cn.fujitsu.com>
> ---
> net/ipv6/addrconf.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
> index 3984f52..d8e5907 100644
> --- a/net/ipv6/addrconf.c
> +++ b/net/ipv6/addrconf.c
> @@ -1291,7 +1291,7 @@ int ipv6_chk_addr(struct net *net, struct in6_addr *addr,
> }
> rcu_read_unlock_bh();
>
> - return ifp != NULL;
> + return node != NULL;
> }
> EXPORT_SYMBOL(ipv6_chk_addr);
>
Why not this instead. I don't like depending on the value of the
loop variable in the hlist_for_each()
--- a/net/ipv6/addrconf.c 2010-05-17 10:27:58.218628126 -0700
+++ b/net/ipv6/addrconf.c 2010-05-17 10:29:46.012198338 -0700
@@ -1274,7 +1274,7 @@ static int ipv6_count_addresses(struct i
int ipv6_chk_addr(struct net *net, struct in6_addr *addr,
struct net_device *dev, int strict)
{
- struct inet6_ifaddr *ifp = NULL;
+ struct inet6_ifaddr *ifp;
struct hlist_node *node;
unsigned int hash = ipv6_addr_hash(addr);
@@ -1283,15 +1283,16 @@ int ipv6_chk_addr(struct net *net, struc
if (!net_eq(dev_net(ifp->idev->dev), net))
continue;
if (ipv6_addr_equal(&ifp->addr, addr) &&
- !(ifp->flags&IFA_F_TENTATIVE)) {
- if (dev == NULL || ifp->idev->dev == dev ||
- !(ifp->scope&(IFA_LINK|IFA_HOST) || strict))
- break;
+ !(ifp->flags&IFA_F_TENTATIVE) &&
+ (dev == NULL || ifp->idev->dev == dev ||
+ !(ifp->scope&(IFA_LINK|IFA_HOST) || strict))) {
+ rcu_read_unlock_bh();
+ return 1;
}
}
- rcu_read_unlock_bh();
- return ifp != NULL;
+ rcu_read_unlock_bh();
+ return 0;
}
EXPORT_SYMBOL(ipv6_chk_addr);
--
^ permalink raw reply
* Re: TCP-MD5 checksum failure on x86_64 SMP
From: Stephen Hemminger @ 2010-05-17 17:22 UTC (permalink / raw)
To: Eric Dumazet
Cc: Bijay Singh, David Miller, <bhaskie@gmail.com>,
<bhutchings@solarflare.com>, netdev, Ilpo Järvinen
In-Reply-To: <1274072629.2299.58.camel@edumazet-laptop>
On Mon, 17 May 2010 07:03:49 +0200
Eric Dumazet <eric.dumazet@gmail.com> wrote:
> Le lundi 17 mai 2010 à 03:49 +0000, Bijay Singh a écrit :
>
> > I am on quite an old kernel 2.6.27 and could not apply your patches.
> >
> > Then i moved on to the kernel 2.6.32.11 however since then I have not been able to bring up my card, this is something i need to fix before i can test you fix. Working on that.
> >
>
> Thanks again for the status report.
>
> I see bug is older than what I stated in my previous mail
>
> I could reproduce it in my lab and confirm following patch fixes it
>
> This is a stable candidate (2.6.27 kernels)
>
> Thanks
>
> [PATCH] tcp: tcp_synack_options() fix
>
> Commit 33ad798c924b4a (tcp: options clean up) introduced a problem
> if MD5+SACK+timestamps were used in initial SYN message.
>
> Some stacks (old linux for example) try to negotiate MD5+SACK+TSTAMP
> sessions, but since 20 bytes of tcp options space are not enough to
> store all the bits needed, we chose to disable timestamps in this case.
>
> We send a SYN-ACK _without_ timestamp option, but socket has timestamps
> enabled and all further outgoing messages contain a TS block, all with
> the initial timestamp of the remote peer.
>
> Fix is to really disable timestamps option for the whole session.
>
> Reported-by: Bijay Singh <Bijay.Singh@guavus.com>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
> ---
> net/ipv4/tcp_output.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
> diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
> index 0dda86e..b8bb226 100644
> --- a/net/ipv4/tcp_output.c
> +++ b/net/ipv4/tcp_output.c
> @@ -667,7 +667,7 @@ static unsigned tcp_synack_options(struct sock *sk,
> u8 cookie_plus = (xvp != NULL && !xvp->cookie_out_never) ?
> xvp->cookie_plus :
> 0;
> - bool doing_ts = ireq->tstamp_ok;
> + bool doing_ts;
>
> #ifdef CONFIG_TCP_MD5SIG
> *md5 = tcp_rsk(req)->af_specific->md5_lookup(sk, req);
> @@ -680,11 +680,12 @@ static unsigned tcp_synack_options(struct sock *sk,
> * rather than TS in order to fit in better with old,
> * buggy kernels, but that was deemed to be unnecessary.
> */
> - doing_ts &= !ireq->sack_ok;
> + ireq->tstamp_ok &= !ireq->sack_ok;
> }
> #else
> *md5 = NULL;
> #endif
> + doing_ts = ireq->tstamp_ok;
>
> /* We always send an MSS option. */
> opts->mss = mss;
>
>
Make this gets back to stable as well.
--
^ permalink raw reply
* Re: [PATCH] rtnetlink: make SR-IOV VF interface symmetric
From: Stephen Hemminger @ 2010-05-17 16:55 UTC (permalink / raw)
To: Chris Wright
Cc: Williams, Mitch A, davem@davemloft.net, kaber@trash.net,
arnd@arndb.de, scofeldm@cisco.com, netdev@vger.kernel.org
In-Reply-To: <20100517160732.GA8301@sequoia.sous-sol.org>
On Mon, 17 May 2010 09:07:32 -0700
Chris Wright <chrisw@sous-sol.org> wrote:
> * Williams, Mitch A (mitch.a.williams@intel.com) wrote:
> > >-----Original Message-----
> > >From: Stephen Hemminger [mailto:shemminger@vyatta.com]
> > >Sent: Monday, May 17, 2010 9:00 AM
> > >To: Chris Wright
> > >Cc: davem@davemloft.net; kaber@trash.net; Williams, Mitch A;
> > >arnd@arndb.de; scofeldm@cisco.com; netdev@vger.kernel.org
> > >Subject: Re: [PATCH] rtnetlink: make SR-IOV VF interface symmetric
> > >
> > >On Fri, 14 May 2010 20:14:16 -0700
> > >Chris Wright <chrisw@sous-sol.org> wrote:
> > >
> > >> Now we have a set of nested attributes:
> > >>
> > >> IFLA_VFINFO_LIST (NESTED)
> > >> IFLA_VF_INFO (NESTED)
> > >> IFLA_VF_MAC
> > >> IFLA_VF_VLAN
> > >> IFLA_VF_TX_RATE
> > >>
> > >> This allows a single set to operate on multiple attributes if desired.
> > >> Among other things, it means a dump can be replayed to set state.
> > >>
> > >> The current interface has yet to be released, so this seems like
> > >> something to consider for 2.6.34.
> > >>
> > >> Signed-off-by: Chris Wright <chrisw@sous-sol.org
> > >> ---
> > >
> > >iproute2 update please?
> > >
> > >Also I would really like documentation on this.
>
> And a pony? ;-)
>
> Docs in what form?
>
The man page for ip.8 already has some pieces from other version.
Just fix them. I just pushed up a couple of changes.
--
^ permalink raw reply
* Re: [PATCH 0/6] sky2: update
From: David Miller @ 2010-05-17 16:55 UTC (permalink / raw)
To: shemminger; +Cc: mikem, netdev
In-Reply-To: <20100514081957.00f342d5@nehalam>
From: Stephen Hemminger <shemminger@vyatta.com>
Date: Fri, 14 May 2010 08:19:57 -0700
> On Fri, 14 May 2010 03:15:01 -0700 (PDT)
> David Miller <davem@davemloft.net> wrote:
>
>> From: Stephen Hemminger <shemminger@vyatta.com>
>> Date: Thu, 13 May 2010 09:12:47 -0700
>>
>> > Bunch of patches from Mike, with some additional comments.
>>
>> All applied to net-next-2.6, thanks.
>
> The first one needs to go to net-2.6 because it a regression:
> Current code will lose multicast addresses when the automatic
> recovery from stuck chip happens. Auto recovery happens a lot
> under load on some configurations.
2.6.34 got released yesterday, so it is a moot point.
Just submit it to -stable.
^ permalink raw reply
* Re: [PATCH 1/37] drivers/net/wireless/libertas: Use kmemdup
From: Dan Williams @ 2010-05-17 16:35 UTC (permalink / raw)
To: Julia Lawall
Cc: John W. Linville, libertas-dev-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
kernel-janitors-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <Pine.LNX.4.64.1005152312060.21345-QfmoRoYWmW9knbxzx/v8hQ@public.gmane.org>
On Sat, 2010-05-15 at 23:12 +0200, Julia Lawall wrote:
> From: Julia Lawall <julia-dAYI7NvHqcQ@public.gmane.org>
>
> Use kmemdup when some other buffer is immediately copied into the
> allocated region.
>
> A simplified version of the semantic patch that makes this change is as
> follows: (http://coccinelle.lip6.fr/)
>
> // <smpl>
> @@
> expression from,to,size,flag;
> statement S;
> @@
>
> - to = \(kmalloc\|kzalloc\)(size,flag);
> + to = kmemdup(from,size,flag);
> if (to==NULL || ...) S
> - memcpy(to, from, size);
> // </smpl>
>
> Signed-off-by: Julia Lawall <julia-dAYI7NvHqcQ@public.gmane.org>
Acked-by: Dan Williams <dcbw-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> ---
> drivers/net/wireless/libertas/if_usb.c | 6 ++----
> 1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff -u -p a/drivers/net/wireless/libertas/if_usb.c b/drivers/net/wireless/libertas/if_usb.c
> --- a/drivers/net/wireless/libertas/if_usb.c
> +++ b/drivers/net/wireless/libertas/if_usb.c
> @@ -618,16 +618,14 @@ static void if_usb_receive_fwload(struct
> return;
> }
>
> - syncfwheader = kmalloc(sizeof(struct fwsyncheader), GFP_ATOMIC);
> + syncfwheader = kmemdup(skb->data + IPFIELD_ALIGN_OFFSET,
> + sizeof(struct fwsyncheader), GFP_ATOMIC);
> if (!syncfwheader) {
> lbs_deb_usbd(&cardp->udev->dev, "Failure to allocate syncfwheader\n");
> kfree_skb(skb);
> return;
> }
>
> - memcpy(syncfwheader, skb->data + IPFIELD_ALIGN_OFFSET,
> - sizeof(struct fwsyncheader));
> -
> if (!syncfwheader->cmd) {
> lbs_deb_usb2(&cardp->udev->dev, "FW received Blk with correct CRC\n");
> lbs_deb_usb2(&cardp->udev->dev, "FW received Blk seqnum = %d\n",
--
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
* [PATCH -next] bridge: fix build for CONFIG_SYSFS disabled
From: Randy Dunlap @ 2010-05-17 16:17 UTC (permalink / raw)
To: Stephen Rothwell, Stephen Hemminger; +Cc: linux-next, LKML, netdev, davem
In-Reply-To: <20100517163521.649526d0.sfr@canb.auug.org.au>
From: Randy Dunlap <randy.dunlap@oracle.com>
Fix build when CONFIG_SYSFS is not enabled:
net/bridge/br_if.c:136: error: 'struct net_bridge_port' has no member named 'sysfs_name'
Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
---
net/bridge/br_if.c | 2 ++
1 file changed, 2 insertions(+)
--- linux-next-20100517.orig/net/bridge/br_if.c
+++ linux-next-20100517/net/bridge/br_if.c
@@ -133,7 +133,9 @@ static void del_nbp(struct net_bridge_po
struct net_bridge *br = p->br;
struct net_device *dev = p->dev;
+#ifdef CONFIG_SYSFS
sysfs_remove_link(br->ifobj, p->sysfs_name);
+#endif
dev_set_promiscuity(dev, -1);
^ permalink raw reply
* Re: [PATCH] rtnetlink: make SR-IOV VF interface symmetric
From: Chris Wright @ 2010-05-17 16:10 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Chris Wright, davem, kaber, mitch.a.williams, scofeldm,
shemminger, netdev
In-Reply-To: <201005151104.41158.arnd@arndb.de>
* Arnd Bergmann (arnd@arndb.de) wrote:
> On Saturday 15 May 2010 05:14:16 Chris Wright wrote:
> > Now we have a set of nested attributes:
> >
> > IFLA_VFINFO_LIST (NESTED)
> > IFLA_VF_INFO (NESTED)
> > IFLA_VF_MAC
> > IFLA_VF_VLAN
> > IFLA_VF_TX_RATE
> >
> > This allows a single set to operate on multiple attributes if desired.
> > Among other things, it means a dump can be replayed to set state.
> >
> > The current interface has yet to be released, so this seems like
> > something to consider for 2.6.34.
> >
> > Signed-off-by: Chris Wright <chrisw@sous-sol.org
>
> Very nice! This would be the minimum change to make the ABI conform
> to the general rules, so it would be really good to have that.
>
> Acked-by: Arnd Bergmann <arnd@arndb.de>
>
> It does make the interface a bit strange (less than before), since the
> new IFLA_VF_INFO now contains three nested attributes that each contain their
> own vf number field, and we don't require that they are identical or that
> each of the nested attributes inside VF_INFO appears only once.
>
> How about a second patch that splits out an IFLA_VF_NUMBER attribute
> and makes do_setvfinfo use nla_parse_nested instead of nla_for_each_nested
> in order to tighten the rules on this some more?
Yes, that's a great idea Arnd. I'll tighten that up.
thanks,
-chris
^ permalink raw reply
* Re: [PATCH] rtnetlink: make SR-IOV VF interface symmetric
From: Chris Wright @ 2010-05-17 16:07 UTC (permalink / raw)
To: Williams, Mitch A
Cc: Stephen Hemminger, Chris Wright, davem@davemloft.net,
kaber@trash.net, arnd@arndb.de, scofeldm@cisco.com,
netdev@vger.kernel.org
In-Reply-To: <EA929A9653AAE14F841771FB1DE5A1365FF3999206@rrsmsx501.amr.corp.intel.com>
* Williams, Mitch A (mitch.a.williams@intel.com) wrote:
> >-----Original Message-----
> >From: Stephen Hemminger [mailto:shemminger@vyatta.com]
> >Sent: Monday, May 17, 2010 9:00 AM
> >To: Chris Wright
> >Cc: davem@davemloft.net; kaber@trash.net; Williams, Mitch A;
> >arnd@arndb.de; scofeldm@cisco.com; netdev@vger.kernel.org
> >Subject: Re: [PATCH] rtnetlink: make SR-IOV VF interface symmetric
> >
> >On Fri, 14 May 2010 20:14:16 -0700
> >Chris Wright <chrisw@sous-sol.org> wrote:
> >
> >> Now we have a set of nested attributes:
> >>
> >> IFLA_VFINFO_LIST (NESTED)
> >> IFLA_VF_INFO (NESTED)
> >> IFLA_VF_MAC
> >> IFLA_VF_VLAN
> >> IFLA_VF_TX_RATE
> >>
> >> This allows a single set to operate on multiple attributes if desired.
> >> Among other things, it means a dump can be replayed to set state.
> >>
> >> The current interface has yet to be released, so this seems like
> >> something to consider for 2.6.34.
> >>
> >> Signed-off-by: Chris Wright <chrisw@sous-sol.org
> >> ---
> >
> >iproute2 update please?
> >
> >Also I would really like documentation on this.
And a pony? ;-)
Docs in what form?
> Chris, have you got the iproute2 parts working, or do I need to pick it up?
>
> Thanks again for your work on this.
I've got those bits, just was waiting until patches merged.
Will send them out this afternoon.
thanks,
-chris
^ permalink raw reply
* RE: [PATCH] rtnetlink: make SR-IOV VF interface symmetric
From: Williams, Mitch A @ 2010-05-17 16:02 UTC (permalink / raw)
To: Stephen Hemminger, Chris Wright
Cc: davem@davemloft.net, kaber@trash.net, arnd@arndb.de,
scofeldm@cisco.com, netdev@vger.kernel.org
In-Reply-To: <20100517085936.39016980@nehalam>
>-----Original Message-----
>From: Stephen Hemminger [mailto:shemminger@vyatta.com]
>Sent: Monday, May 17, 2010 9:00 AM
>To: Chris Wright
>Cc: davem@davemloft.net; kaber@trash.net; Williams, Mitch A;
>arnd@arndb.de; scofeldm@cisco.com; netdev@vger.kernel.org
>Subject: Re: [PATCH] rtnetlink: make SR-IOV VF interface symmetric
>
>On Fri, 14 May 2010 20:14:16 -0700
>Chris Wright <chrisw@sous-sol.org> wrote:
>
>> Now we have a set of nested attributes:
>>
>> IFLA_VFINFO_LIST (NESTED)
>> IFLA_VF_INFO (NESTED)
>> IFLA_VF_MAC
>> IFLA_VF_VLAN
>> IFLA_VF_TX_RATE
>>
>> This allows a single set to operate on multiple attributes if desired.
>> Among other things, it means a dump can be replayed to set state.
>>
>> The current interface has yet to be released, so this seems like
>> something to consider for 2.6.34.
>>
>> Signed-off-by: Chris Wright <chrisw@sous-sol.org
>> ---
>
>iproute2 update please?
>
>Also I would really like documentation on this.
>
>
>--
Chris, have you got the iproute2 parts working, or do I need to pick it up?
Thanks again for your work on this.
-Mitch
^ permalink raw reply
* Re: [PATCH] rtnetlink: make SR-IOV VF interface symmetric
From: Stephen Hemminger @ 2010-05-17 15:59 UTC (permalink / raw)
To: Chris Wright; +Cc: davem, kaber, mitch.a.williams, arnd, scofeldm, netdev
In-Reply-To: <20100515031416.GE15313@sequoia.sous-sol.org>
On Fri, 14 May 2010 20:14:16 -0700
Chris Wright <chrisw@sous-sol.org> wrote:
> Now we have a set of nested attributes:
>
> IFLA_VFINFO_LIST (NESTED)
> IFLA_VF_INFO (NESTED)
> IFLA_VF_MAC
> IFLA_VF_VLAN
> IFLA_VF_TX_RATE
>
> This allows a single set to operate on multiple attributes if desired.
> Among other things, it means a dump can be replayed to set state.
>
> The current interface has yet to be released, so this seems like
> something to consider for 2.6.34.
>
> Signed-off-by: Chris Wright <chrisw@sous-sol.org
> ---
iproute2 update please?
Also I would really like documentation on this.
--
^ permalink raw reply
* Re: [PATCH v3 3/3] ptp: Added a clock that uses the eTSEC found on the MPC85xx.
From: Wolfgang Grandegger @ 2010-05-17 15:41 UTC (permalink / raw)
To: Richard Cochran; +Cc: netdev, linuxppc-dev, devicetree-discuss
In-Reply-To: <ee6c3edca3ee6aa86565e59da999375f79c9de1b.1273855017.git.richard.cochran@omicron.at>
On 05/14/2010 06:46 PM, Richard Cochran wrote:
> The eTSEC includes a PTP clock with quite a few features. This patch adds
> support for the basic clock adjustment functions, plus two external time
> stamps and one alarm.
>
> Signed-off-by: Richard Cochran <richard.cochran@omicron.at>
Tested-by: Wolfgang Grandegger <wg@denx.de>
on my Freescale MPC8313 setup with ptpd and ptpv2d.
FYI: checkplatch.pl reports various errors for this patch series.
Wolfgang.
^ permalink raw reply
* Re: [PATCH v3 1/3] ptp: Added a brand new class driver for ptp clocks.
From: Wolfgang Grandegger @ 2010-05-17 15:41 UTC (permalink / raw)
To: Richard Cochran; +Cc: netdev, linuxppc-dev, devicetree-discuss
In-Reply-To: <aa2a85799677c08001b152c2921d0e55d5693ffa.1273855017.git.richard.cochran@omicron.at>
On 05/14/2010 06:45 PM, Richard Cochran wrote:
> This patch adds an infrastructure for hardware clocks that implement
> IEEE 1588, the Precision Time Protocol (PTP). A class driver offers a
> registration method to particular hardware clock drivers. Each clock is
> exposed to user space as a character device with ioctls that allow tuning
> of the PTP clock.
>
> Signed-off-by: Richard Cochran <richard.cochran@omicron.at>
Tested-by: Wolfgang Grandegger <wg@denx.de>
on my Freescale MPC8313 setup with ptpd and ptpv2d.
Wolfgang.
^ permalink raw reply
* [PATCH net-next-2.6] bonding: move slave MTU handling from sysfs
From: Jiri Pirko @ 2010-05-17 14:47 UTC (permalink / raw)
To: netdev; +Cc: davem, fubar, bonding-devel, monis
For some reason, MTU handling (storing, and restoring) is taking place in
bond_sysfs. The correct place for this code is in bond_enslave, bond_release.
So move it there.
Jirka
Signed-off-by: Jiri Pirko <jpirko@redhat.com>
diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
index 5e12462..2c3f9db 100644
--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/bond_main.c
@@ -1533,6 +1533,14 @@ int bond_enslave(struct net_device *bond_dev, struct net_device *slave_dev)
*/
new_slave->original_flags = slave_dev->flags;
+ /* Save slave's original mtu and then set it to match the bond */
+ new_slave->original_mtu = slave_dev->mtu;
+ res = dev_set_mtu(slave_dev, bond->dev->mtu);
+ if (res) {
+ pr_debug("Error %d calling dev_set_mtu\n", res);
+ goto err_free;
+ }
+
/*
* Save slave's original ("permanent") mac address for modes
* that need it, and for restoring it upon release, and then
@@ -1550,7 +1558,7 @@ int bond_enslave(struct net_device *bond_dev, struct net_device *slave_dev)
res = dev_set_mac_address(slave_dev, &addr);
if (res) {
pr_debug("Error %d calling set_mac_address\n", res);
- goto err_free;
+ goto err_restore_mtu;
}
}
@@ -1785,6 +1793,9 @@ err_restore_mac:
dev_set_mac_address(slave_dev, &addr);
}
+err_restore_mtu:
+ dev_set_mtu(slave_dev, new_slave->original_mtu);
+
err_free:
kfree(new_slave);
@@ -1969,6 +1980,8 @@ int bond_release(struct net_device *bond_dev, struct net_device *slave_dev)
dev_set_mac_address(slave_dev, &addr);
}
+ dev_set_mtu(slave_dev, slave->original_mtu);
+
slave_dev->priv_flags &= ~(IFF_MASTER_8023AD | IFF_MASTER_ALB |
IFF_SLAVE_INACTIVE | IFF_BONDING |
IFF_SLAVE_NEEDARP);
diff --git a/drivers/net/bonding/bond_sysfs.c b/drivers/net/bonding/bond_sysfs.c
index 392e291..4e84cfc 100644
--- a/drivers/net/bonding/bond_sysfs.c
+++ b/drivers/net/bonding/bond_sysfs.c
@@ -220,7 +220,6 @@ static ssize_t bonding_store_slaves(struct device *d,
char command[IFNAMSIZ + 1] = { 0, };
char *ifname;
int i, res, ret = count;
- u32 original_mtu;
struct slave *slave;
struct net_device *dev = NULL;
struct bonding *bond = to_bond(d);
@@ -281,43 +280,22 @@ static ssize_t bonding_store_slaves(struct device *d,
memcpy(bond->dev->dev_addr, dev->dev_addr,
dev->addr_len);
- /* Set the slave's MTU to match the bond */
- original_mtu = dev->mtu;
- res = dev_set_mtu(dev, bond->dev->mtu);
- if (res) {
- ret = res;
- goto out;
- }
-
res = bond_enslave(bond->dev, dev);
- bond_for_each_slave(bond, slave, i)
- if (strnicmp(slave->dev->name, ifname, IFNAMSIZ) == 0)
- slave->original_mtu = original_mtu;
- if (res)
- ret = res;
goto out;
}
if (command[0] == '-') {
dev = NULL;
- original_mtu = 0;
bond_for_each_slave(bond, slave, i)
if (strnicmp(slave->dev->name, ifname, IFNAMSIZ) == 0) {
dev = slave->dev;
- original_mtu = slave->original_mtu;
break;
}
if (dev) {
pr_info("%s: Removing slave %s\n",
bond->dev->name, dev->name);
- res = bond_release(bond->dev, dev);
- if (res) {
- ret = res;
- goto out;
- }
- /* set the slave MTU to the default */
- dev_set_mtu(dev, original_mtu);
+ res = bond_release(bond->dev, dev);
} else {
pr_err("unable to remove non-existent slave %s for bond %s.\n",
ifname, bond->dev->name);
^ permalink raw reply related
* Re: [PATCH net-next-2.6] can: sja1000 platform data fixes
From: Marc Kleine-Budde @ 2010-05-17 14:42 UTC (permalink / raw)
To: Wolfgang Grandegger
Cc: SocketCAN Core Mailing List, Netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <4BF151D2.5030906-5Yr1BZd7O62+XT7JhA+gdA@public.gmane.org>
[-- Attachment #1.1: Type: text/plain, Size: 3446 bytes --]
Wolfgang Grandegger wrote:
> The member "clock" of struct "sja1000_platform_data" is documented as
> "CAN bus oscillator frequency in Hz" but it's actually used as the CAN
> clock frequency, which is half of it. To avoid further confusion, this
> patch fixes it by renaming the member to "osc_freq". That way, also
> non mainline users will notice the change. The platform code for the
> relevant boards is updated accordingly. Furthermore, pre-defined
> values are now used for the members "ocr" and "cdr".
>
> Signed-off-by: Wolfgang Grandegger <wg-5Yr1BZd7O62+XT7JhA+gdA@public.gmane.org>
> CC: Marc Kleine-Budde <mkl-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
Acked-by: Marc Kleine-Budde <mkl-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
Cheers, Marc
>
> diff --git a/arch/arm/mach-mx2/pcm970-baseboard.c b/arch/arm/mach-mx2/pcm970-baseboard.c
> index 4aafd5b..f490a40 100644
> --- a/arch/arm/mach-mx2/pcm970-baseboard.c
> +++ b/arch/arm/mach-mx2/pcm970-baseboard.c
> @@ -201,9 +201,9 @@ static struct resource pcm970_sja1000_resources[] = {
> };
>
> struct sja1000_platform_data pcm970_sja1000_platform_data = {
> - .clock = 16000000 / 2,
> - .ocr = 0x40 | 0x18,
> - .cdr = 0x40,
> + .osc_freq = 16000000,
> + .ocr = OCR_TX1_PULLDOWN | OCR_TX0_PUSHPULL,
> + .cdr = CDR_CBP,
> };
>
> static struct platform_device pcm970_sja1000 = {
> diff --git a/arch/arm/mach-mx3/mach-pcm037.c b/arch/arm/mach-mx3/mach-pcm037.c
> index 2df1ec5..78ecd75 100644
> --- a/arch/arm/mach-mx3/mach-pcm037.c
> +++ b/arch/arm/mach-mx3/mach-pcm037.c
> @@ -530,9 +530,9 @@ static struct resource pcm970_sja1000_resources[] = {
> };
>
> struct sja1000_platform_data pcm970_sja1000_platform_data = {
> - .clock = 16000000 / 2,
> - .ocr = 0x40 | 0x18,
> - .cdr = 0x40,
> + .osc_freq = 16000000,
> + .ocr = OCR_TX1_PULLDOWN | OCR_TX0_PUSHPULL,
> + .cdr = CDR_CBP,
> };
>
> static struct platform_device pcm970_sja1000 = {
> diff --git a/drivers/net/can/sja1000/sja1000_platform.c b/drivers/net/can/sja1000/sja1000_platform.c
> index b65cabb..d9fadc4 100644
> --- a/drivers/net/can/sja1000/sja1000_platform.c
> +++ b/drivers/net/can/sja1000/sja1000_platform.c
> @@ -111,7 +111,8 @@ static int sp_probe(struct platform_device *pdev)
> dev->irq = res_irq->start;
> priv->irq_flags = res_irq->flags & (IRQF_TRIGGER_MASK | IRQF_SHARED);
> priv->reg_base = addr;
> - priv->can.clock.freq = pdata->clock;
> + /* The CAN clock frequency is half the oscillator clock frequency */
> + priv->can.clock.freq = pdata->osc_freq / 2;
> priv->ocr = pdata->ocr;
> priv->cdr = pdata->cdr;
>
> diff --git a/include/linux/can/platform/sja1000.h b/include/linux/can/platform/sja1000.h
> index 01ee2ae..96f8fcc 100644
> --- a/include/linux/can/platform/sja1000.h
> +++ b/include/linux/can/platform/sja1000.h
> @@ -26,7 +26,7 @@
> #define OCR_TX_SHIFT 2
>
> struct sja1000_platform_data {
> - u32 clock; /* CAN bus oscillator frequency in Hz */
> + u32 osc_freq; /* CAN bus oscillator frequency in Hz */
>
> u8 ocr; /* output control register */
> u8 cdr; /* clock divider register */
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 260 bytes --]
[-- Attachment #2: Type: text/plain, Size: 188 bytes --]
_______________________________________________
Socketcan-core mailing list
Socketcan-core-0fE9KPoRgkgATYTw5x5z8w@public.gmane.org
https://lists.berlios.de/mailman/listinfo/socketcan-core
^ 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