* Re: sky2 still badly broken
From: Niccolò Belli @ 2012-05-03 19:36 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev
In-Reply-To: <20120503082352.771acab3@nehalam.linuxnetplumber.net>
Il 03/05/2012 17:23, Stephen Hemminger ha scritto:
> The receiver on some versions of the chip can't keep up with full speed
> of 1G bit/sec. The receive FIFO has hardware issues, and since I don't
> work for Marvell, working around the problem is guesswork.
Just one question: if that is true why don't I have any problem with a
point to point gigabit link? I did transfer 3GB from ram to ram (ramfs)
at 100+MB/s without any issue in a point to point setup, as soon as I
attach it to the switch I have problems (very low transfer rate and tons
of rx errors).
Niccolò
^ permalink raw reply
* Re: [net-next PATCH v4 0/8] Managing the forwarding database(FDB)
From: John Fastabend @ 2012-05-03 19:26 UTC (permalink / raw)
To: shemminger
Cc: Michael S. Tsirkin, bhutchings, sri, hadi, jeffrey.t.kirsher,
netdev, gregory.v.rose, krkumar2, roprabhu
In-Reply-To: <20120503054859.GH8266@redhat.com>
On 5/2/2012 10:48 PM, Michael S. Tsirkin wrote:
> On Wed, May 02, 2012 at 02:52:33PM -0700, John Fastabend wrote:
>> On 5/2/2012 8:08 AM, Michael S. Tsirkin wrote:
>>> On Sun, Apr 15, 2012 at 01:06:37PM -0400, David Miller wrote:
>>>> From: John Fastabend <john.r.fastabend@intel.com>
>>>> Date: Sun, 15 Apr 2012 09:43:51 -0700
>>>>
>>>>> The following series is a submission for net-next to allow
>>>>> embedded switches and other stacked devices other then the
>>>>> Linux bridge to manage a forwarding database.
>>>>>
>>>>> Previously discussed here,
>>>>>
>>>>> http://lists.openwall.net/netdev/2012/03/19/26
>>>>>
>>>>> v4: propagate return codes correctly for ndo_dflt_Fdb_dump()
>>>>>
>>>>> v3: resolve the macvlan patch 8/8 to fix a dev_set_promiscuity()
>>>>> error and add the flags field to change and get link routines.
>>>>>
>>>>> v2: addressed feedback from Ben Hutchings resolving a typo in the
>>>>> multicast add/del routines and improving the error handling
>>>>> when both NTF_SELF and NTF_MASTER are set.
>>>>>
>>>>> I've tested this with 'br' tool published by Stephen Hemminger
>>>>> soon to be renamed 'bridge' I believe and various traffic
>>>>> generators mostly pktgen, ping, and netperf.
>>>>
>>>> All applied, if we need any more tweaks we can just add them
>>>> on top of this work.
>>>>
>>>> Thanks John.
>>>
>>> John, do you plan to update kvm userspace to use this interface?
>>>
>>
>> No immediate plans. I would really appreciate it if you or one
>> of the IBM developers working in this space took it on. Of course
>> if no one steps up I guess I can eventually get at it but it will
>> be sometime. For now I've been doing this manually with the bridge
>> tool yet to be published.
>>
>> .John
>
> It'll be easier once you publish the tool, qemu can just run
> scripts like it does for ifup/ifdown now.
>
Agreed.
Stephen when do you think you will be able to submit 'br' renamed
'bridge' for the iproute2 package? I've been using it now for sometime
without any issues and it seems to be working great for me.
Thanks,
John
^ permalink raw reply
* RE: [PATCH] net: davinci_emac: Add pre_open, post_stop platform callbacks
From: Bedia, Vaibhav @ 2012-05-03 19:25 UTC (permalink / raw)
To: Mark A. Greer
Cc: netdev@vger.kernel.org, linux-omap@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20120503184632.GA28089@animalcreek.com>
On Fri, May 04, 2012 at 00:16:32, Mark A. Greer wrote:
[...]
> >
> > So, if I understood this correctly, it's effectively like blocking a low power
> > state transition (here wfi execution) when EMAC is active?
>
> Assuming "it" is my patch, correct.
>
Recently I was thinking about how to get certain drivers to disallow some or all
low power states and to me this also seems to fall in a similar category.
One of the suggestions that I got was to check if the 'wakeup' entry associated with
the device under sysfs could be leveraged for this. The PM code could maintain
a whitelist (or blacklist) of devices and it decides the low power state to enter
based on the 'wakeup' entries associated with these devices. In this particular case,
maybe the driver could simply set this entry to non-wakeup capable when necessary and
then let the PM code take care of skipping the wfi execution.
Thoughts/brickbats welcome :)
Regards,
Vaibhav
^ permalink raw reply
* Re: sky2 still badly broken
From: Niccolò Belli @ 2012-05-03 19:26 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev
In-Reply-To: <20120503111536.269490e3@nehalam.linuxnetplumber.net>
Il 03/05/2012 20:15, Stephen Hemminger ha scritto:
> Maybe ethtool registers have some info?
>
> # ethtool -S eth0
After:
64 bytes from 8.8.8.8: icmp_req=592 ttl=47 time=61.0 ms
64 bytes from 8.8.8.8: icmp_req=593 ttl=47 time=64.9 ms
64 bytes from 8.8.8.8: icmp_req=594 ttl=47 time=61.8 ms
ping: sendmsg: Network is unreachable
ping: sendmsg: Network is unreachable
ping: sendmsg: Network is unreachable
[...]
I get:
laptop ~ # ethtool eth0
Settings for eth0:
Supported ports: [ TP ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Half 1000baseT/Full
Supported pause frame use: No
Supports auto-negotiation: Yes
Advertised link modes: 100baseT/Full
Advertised pause frame use: No
Advertised auto-negotiation: Yes
Speed: 100Mb/s
Duplex: Full
Port: Twisted Pair
PHYAD: 0
Transceiver: internal
Auto-negotiation: on
MDI-X: Unknown
Supports Wake-on: pg
Wake-on: g
Current message level: 0x000000ff (255)
drv probe link timer ifdown ifup rx_err
tx_err
Link detected: yes
laptop ~ # ethtool -S eth0
NIC statistics:
tx_bytes: 118170
rx_bytes: 891033
tx_broadcast: 36
rx_broadcast: 346
tx_multicast: 4
rx_multicast: 332
tx_unicast: 1131
rx_unicast: 1235
tx_mac_pause: 0
rx_mac_pause: 0
collisions: 0
late_collision: 0
aborted: 0
single_collisions: 0
multi_collisions: 0
rx_short: 0
rx_runt: 0
rx_64_byte_packets: 344
rx_65_to_127_byte_packets: 654
rx_128_to_255_byte_packets: 362
rx_256_to_511_byte_packets: 50
rx_512_to_1023_byte_packets: 11
rx_1024_to_1518_byte_packets: 492
rx_1518_to_max_byte_packets: 0
rx_too_long: 0
rx_fifo_overflow: 0
rx_jabber: 0
rx_fcs_error: 0
tx_64_byte_packets: 45
tx_65_to_127_byte_packets: 1074
tx_128_to_255_byte_packets: 0
tx_256_to_511_byte_packets: 52
tx_512_to_1023_byte_packets: 0
tx_1024_to_1518_byte_packets: 0
tx_1519_to_max_byte_packets: 0
tx_fifo_underrun: 0
> And if you enable the debugfs option there is more info
> hidden there.
>
> # mount -t debugfs debugfs /sys/kernel/debug
> # cat /sys/kernel/debug/sky2/eth0
There is no sky2 directory, maybe I don't have enough debug options in
my kernel config.
Niccolò
^ permalink raw reply
* Re: [PATCH] net/niu: remove one superfluous dma mask check
From: David Miller @ 2012-05-03 18:55 UTC (permalink / raw)
To: bigeasy; +Cc: netdev
In-Reply-To: <1336069320-23639-1-git-send-email-bigeasy@linutronix.de>
From: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Date: Thu, 3 May 2012 20:22:00 +0200
> The idea here seems to be to get a 44bit DMA mask working and if this
> fails it should fallback to a 32bit DMA mask. The dma_mask variable is
> assigned once to 44bit and never updated. pci_set_dma_mask() and
> pci_set_consistent_dma_mask() are both implemented as functions so there
> is no evil macro which might update dma_mask. Looking at the assembly, I
> see a call to dma_set_mask() followed by dma_supported() and then a jump
> passed the second dma_set_mask(). The only way to get to second
> dma_set_mask() call is by an error code in the first one.
>
> So I hereby remove the check since it looks superfluous. Please ignore
> the path if there is black magic involved.
>
> Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
It looks like it's been this way since day one. :-)
Applied, thanks.
^ permalink raw reply
* Re: 3.4-rc: NETDEV WATCHDOG: eth0 (r8169): transmit queue 0 timed out
From: Stefan Richter @ 2012-05-03 18:48 UTC (permalink / raw)
To: Francois Romieu; +Cc: netdev
In-Reply-To: <20120501200403.GA20763@electric-eye.fr.zoreil.com>
On May 01 Francois Romieu wrote:
[...]
> Can you apply the patch below on top of current ethtool
> (git://git.kernel.org/pub/scm/network/ethtool/ethtool.git) and see
> if it is enough to compare the register dumps (ethtool -d eth0).
[...]
> This is a firmware free chipset anyway. Nothing strange in the interface
> stats (ethtool -S eth0) ?
>
> You may have to narrow things. Can you check if the r8169.c at
> 036dafa28da1e2565a8529de2ae663c37b7a0060 behaves the same ?
I will follow up on this eventually, but it may take quite some time due
to interfering work.
Thank you for looking into it and giving directions,
--
Stefan Richter
-=====-===-- -=-= ---==
http://arcgraph.de/sr/
^ permalink raw reply
* Re: [PATCH] net: davinci_emac: Add pre_open, post_stop platform callbacks
From: Mark A. Greer @ 2012-05-03 18:46 UTC (permalink / raw)
To: Bedia, Vaibhav
Cc: netdev@vger.kernel.org, linux-omap@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <B5906170F1614E41A8A28DE3B8D121433EA73591@DBDE01.ent.ti.com>
On Thu, May 03, 2012 at 06:21:27PM +0000, Bedia, Vaibhav wrote:
> On Thu, May 03, 2012 at 21:39:18, Mark A. Greer wrote:
> > On Thu, May 03, 2012 at 10:44:44AM +0000, Bedia, Vaibhav wrote:
> > > On Thu, May 03, 2012 at 05:17:18, Mark A. Greer wrote:
> > > > From: "Mark A. Greer" <mgreer@animalcreek.com>
> > > >
> > > > The davinci EMAC driver has been incorporated into the am35x
> > > > family of SoC's which is OMAP-based. The incorporation is
> > > > incomplete in that the EMAC cannot unblock the [ARM] core if
> > > > its blocked on a 'wfi' instruction. This is an issue with
> > > > the cpu_idle code because it has the core execute a 'wfi'
> > > > instruction.
> > > >
> > > > To work around this issue, add platform data callbacks which
> > > > are called at the beginning of the open routine and at the
> > > > end of the stop routine of the davinci_emac driver. The
> > > > callbacks allow the platform code to issue disable_hlt() and
> > > > enable_hlt() calls appropriately. Calling disable_hlt()
> > > > prevents cpu_idle from issuing the 'wfi' instruction.
> > > >
> > > > It is not sufficient to simply call disable_hlt() when
> > > > there is an EMAC present because it could be present but
> > > > not actually used in which case, we do want the 'wfi' to
> > > > be executed.
> > > >
> > >
> > > Are you trying to say that if ARM executes _just_ wfi and _absolutely
> > > nothing else_ is done in the OMAP PM code, EMAC stops working?
> >
> > No, I'm saying the EMAC can't wake the core from the wfi so if nothing
> > else happens in the system, its effectively hung. If something else
> > does happen in the system (e.g., a timer expires), the the system is
> > extremely slow because because its only waking up when a timer (or
> > something else wakes it up--but not net traffic). This is very apparent
> > when using an nfs-mounted rootfs. It doesn't hang but its extremely
> > slow because occasionally something else wakes up the core but it
> > spends most of its time stuck in the wfi when it should be handling
> > net/nfs traffic.
> >
>
> So, if I understood this correctly, it's effectively like blocking a low power
> state transition (here wfi execution) when EMAC is active?
Assuming "it" is my patch, correct.
Mark
^ permalink raw reply
* RE: [PATCH] net: davinci_emac: Add pre_open, post_stop platform callbacks
From: Bedia, Vaibhav @ 2012-05-03 18:21 UTC (permalink / raw)
To: Mark A. Greer
Cc: netdev@vger.kernel.org, linux-omap@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20120503160917.GA11310@animalcreek.com>
On Thu, May 03, 2012 at 21:39:18, Mark A. Greer wrote:
> On Thu, May 03, 2012 at 10:44:44AM +0000, Bedia, Vaibhav wrote:
> > On Thu, May 03, 2012 at 05:17:18, Mark A. Greer wrote:
> > > From: "Mark A. Greer" <mgreer@animalcreek.com>
> > >
> > > The davinci EMAC driver has been incorporated into the am35x
> > > family of SoC's which is OMAP-based. The incorporation is
> > > incomplete in that the EMAC cannot unblock the [ARM] core if
> > > its blocked on a 'wfi' instruction. This is an issue with
> > > the cpu_idle code because it has the core execute a 'wfi'
> > > instruction.
> > >
> > > To work around this issue, add platform data callbacks which
> > > are called at the beginning of the open routine and at the
> > > end of the stop routine of the davinci_emac driver. The
> > > callbacks allow the platform code to issue disable_hlt() and
> > > enable_hlt() calls appropriately. Calling disable_hlt()
> > > prevents cpu_idle from issuing the 'wfi' instruction.
> > >
> > > It is not sufficient to simply call disable_hlt() when
> > > there is an EMAC present because it could be present but
> > > not actually used in which case, we do want the 'wfi' to
> > > be executed.
> > >
> >
> > Are you trying to say that if ARM executes _just_ wfi and _absolutely
> > nothing else_ is done in the OMAP PM code, EMAC stops working?
>
> No, I'm saying the EMAC can't wake the core from the wfi so if nothing
> else happens in the system, its effectively hung. If something else
> does happen in the system (e.g., a timer expires), the the system is
> extremely slow because because its only waking up when a timer (or
> something else wakes it up--but not net traffic). This is very apparent
> when using an nfs-mounted rootfs. It doesn't hang but its extremely
> slow because occasionally something else wakes up the core but it
> spends most of its time stuck in the wfi when it should be handling
> net/nfs traffic.
>
So, if I understood this correctly, it's effectively like blocking a low power
state transition (here wfi execution) when EMAC is active?
^ permalink raw reply
* [PATCH] net/niu: remove one superfluous dma mask check
From: Sebastian Andrzej Siewior @ 2012-05-03 18:22 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev, Sebastian Andrzej Siewior
The idea here seems to be to get a 44bit DMA mask working and if this
fails it should fallback to a 32bit DMA mask. The dma_mask variable is
assigned once to 44bit and never updated. pci_set_dma_mask() and
pci_set_consistent_dma_mask() are both implemented as functions so there
is no evil macro which might update dma_mask. Looking at the assembly, I
see a call to dma_set_mask() followed by dma_supported() and then a jump
passed the second dma_set_mask(). The only way to get to second
dma_set_mask() call is by an error code in the first one.
So I hereby remove the check since it looks superfluous. Please ignore
the path if there is black magic involved.
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
---
drivers/net/ethernet/sun/niu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/sun/niu.c b/drivers/net/ethernet/sun/niu.c
index c99b3b0..703c8cc 100644
--- a/drivers/net/ethernet/sun/niu.c
+++ b/drivers/net/ethernet/sun/niu.c
@@ -9838,7 +9838,7 @@ static int __devinit niu_pci_init_one(struct pci_dev *pdev,
goto err_out_release_parent;
}
}
- if (err || dma_mask == DMA_BIT_MASK(32)) {
+ if (err) {
err = pci_set_dma_mask(pdev, DMA_BIT_MASK(32));
if (err) {
dev_err(&pdev->dev, "No usable DMA configuration, aborting\n");
--
1.7.10
^ permalink raw reply related
* Re: sky2 still badly broken
From: Stephen Hemminger @ 2012-05-03 18:15 UTC (permalink / raw)
To: Niccolò Belli; +Cc: netdev
In-Reply-To: <4FA2C913.4080504@linuxsystems.it>
On Thu, 03 May 2012 20:06:11 +0200
Niccolò Belli <darkbasic@linuxsystems.it> wrote:
> Il 03/05/2012 17:23, Stephen Hemminger ha scritto:
> > The receiver on some versions of the chip can't keep up with full speed
> > of 1G bit/sec. The receive FIFO has hardware issues, and since I don't
> > work for Marvell, working around the problem is guesswork. Without exact
> > information all that can be done is have a timeout and blunt force reset
> > logic. The vendor driver sk98lin has the same brute force logic, but may
> > just not print the message.
>
> If I lower the speed to 100Mb/s I don't have rx errors anymore *BUT*
> when using dhcp after a while the network doesn't work anymore:
>
> 64 bytes from 8.8.8.8: icmp_req=590 ttl=47 time=61.7 ms
> 64 bytes from 8.8.8.8: icmp_req=591 ttl=47 time=62.0 ms
> 64 bytes from 8.8.8.8: icmp_req=592 ttl=47 time=62.0 ms
> ping: sendmsg: Network is unreachable
> ping: sendmsg: Network is unreachable
> ping: sendmsg: Network is unreachable
>
>
> I have no problems with dhcp using wifi or other NICs.
>
> Niccolò
Maybe ethtool registers have some info?
# ethtool -S eth0
NIC statistics:
tx_bytes: 3640274
rx_bytes: 61588953
tx_broadcast: 641
rx_broadcast: 9964
tx_multicast: 126
rx_multicast: 1501
tx_unicast: 32683
rx_unicast: 50415
tx_mac_pause: 0
rx_mac_pause: 0
collisions: 0
late_collision: 0
aborted: 0
single_collisions: 0
multi_collisions: 0
rx_short: 0
rx_runt: 0
rx_64_byte_packets: 8704
rx_65_to_127_byte_packets: 4414
rx_128_to_255_byte_packets: 6218
rx_256_to_511_byte_packets: 1289
rx_512_to_1023_byte_packets: 1777
rx_1024_to_1518_byte_packets: 39478
rx_1518_to_max_byte_packets: 0
rx_too_long: 0
rx_fifo_overflow: 0
rx_jabber: 0
rx_fcs_error: 0
tx_64_byte_packets: 1628
tx_65_to_127_byte_packets: 27483
tx_128_to_255_byte_packets: 2885
tx_256_to_511_byte_packets: 637
tx_512_to_1023_byte_packets: 429
tx_1024_to_1518_byte_packets: 388
tx_1519_to_max_byte_packets: 0
tx_fifo_underrun: 0
And if you enable the debugfs option there is more info
hidden there.
# mount -t debugfs debugfs /sys/kernel/debug
# cat /sys/kernel/debug/sky2/eth0
^ permalink raw reply
* Re: sky2 still badly broken
From: Niccolò Belli @ 2012-05-03 18:06 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev
In-Reply-To: <20120503082352.771acab3@nehalam.linuxnetplumber.net>
Il 03/05/2012 17:23, Stephen Hemminger ha scritto:
> The receiver on some versions of the chip can't keep up with full speed
> of 1G bit/sec. The receive FIFO has hardware issues, and since I don't
> work for Marvell, working around the problem is guesswork. Without exact
> information all that can be done is have a timeout and blunt force reset
> logic. The vendor driver sk98lin has the same brute force logic, but may
> just not print the message.
If I lower the speed to 100Mb/s I don't have rx errors anymore *BUT*
when using dhcp after a while the network doesn't work anymore:
64 bytes from 8.8.8.8: icmp_req=590 ttl=47 time=61.7 ms
64 bytes from 8.8.8.8: icmp_req=591 ttl=47 time=62.0 ms
64 bytes from 8.8.8.8: icmp_req=592 ttl=47 time=62.0 ms
ping: sendmsg: Network is unreachable
ping: sendmsg: Network is unreachable
ping: sendmsg: Network is unreachable
I have no problems with dhcp using wifi or other NICs.
Niccolò
^ permalink raw reply
* pull request: wireless 2012-05-03
From: John W. Linville @ 2012-05-03 17:37 UTC (permalink / raw)
To: davem; +Cc: linux-wireless, netdev, linux-kernel
commit 3c3052eac295678fd2765552c6a86d5441306cb4
Dave,
Here is another trio of fixes intended for 3.4. The fix from Eric
Dumazet corrects skb truesize reporting in iwlwifi, avoiding a
potential exhaustion of kernel memory due to differet socket memory
accounting for these skb allocations. The fix from Franky Lin avoids
a double unlock on a spinlock in brcmfmac. Finally, Rajkumar Manoharan
reverts an earlier patch that created a minor regression in ath9k.
Please let me know if there are problems!
John
---
The following changes since commit 5a8887d39e1ba5ee2d4ccb94b14d6f2dce5ddfca:
sungem: Fix WakeOnLan (2012-05-03 01:42:55 -0400)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless.git for-davem
Eric Dumazet (1):
iwlwifi: fix skb truesize underestimation
Franky Lin (1):
brcmfmac: fix a double spin_unlock_irqrestore issue in dpc
John W. Linville (1):
Merge branch 'master' of git://git.kernel.org/.../linville/wireless into for-davem
Rajkumar Manoharan (1):
Revert "ath9k_hw: Fix incorrect spur_freq_sd for AR9003"
drivers/net/wireless/ath/ath9k/ar9003_phy.c | 4 +-
drivers/net/wireless/brcm80211/brcmfmac/dhd_sdio.c | 1 +
drivers/net/wireless/iwlwifi/iwl-agn-rx.c | 21 +++++++++++++------
drivers/net/wireless/iwlwifi/iwl-trans-pcie-rx.c | 3 +-
drivers/net/wireless/iwlwifi/iwl-trans.h | 1 +
5 files changed, 20 insertions(+), 10 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/ar9003_phy.c b/drivers/net/wireless/ath/ath9k/ar9003_phy.c
index deb6cfb..600aca9 100644
--- a/drivers/net/wireless/ath/ath9k/ar9003_phy.c
+++ b/drivers/net/wireless/ath/ath9k/ar9003_phy.c
@@ -373,7 +373,7 @@ static void ar9003_hw_spur_ofdm_work(struct ath_hw *ah,
else
spur_subchannel_sd = 0;
- spur_freq_sd = (freq_offset << 9) / 11;
+ spur_freq_sd = ((freq_offset + 10) << 9) / 11;
} else {
if (REG_READ_FIELD(ah, AR_PHY_GEN_CTRL,
@@ -382,7 +382,7 @@ static void ar9003_hw_spur_ofdm_work(struct ath_hw *ah,
else
spur_subchannel_sd = 1;
- spur_freq_sd = (freq_offset << 9) / 11;
+ spur_freq_sd = ((freq_offset - 10) << 9) / 11;
}
diff --git a/drivers/net/wireless/brcm80211/brcmfmac/dhd_sdio.c b/drivers/net/wireless/brcm80211/brcmfmac/dhd_sdio.c
index eb3829b..e2b34e1 100644
--- a/drivers/net/wireless/brcm80211/brcmfmac/dhd_sdio.c
+++ b/drivers/net/wireless/brcm80211/brcmfmac/dhd_sdio.c
@@ -2637,6 +2637,7 @@ static int brcmf_sdbrcm_dpc_thread(void *data)
/* after stopping the bus, exit thread */
brcmf_sdbrcm_bus_stop(bus->sdiodev->dev);
bus->dpc_tsk = NULL;
+ spin_lock_irqsave(&bus->dpc_tl_lock, flags);
break;
}
diff --git a/drivers/net/wireless/iwlwifi/iwl-agn-rx.c b/drivers/net/wireless/iwlwifi/iwl-agn-rx.c
index f4b84d1..2247460 100644
--- a/drivers/net/wireless/iwlwifi/iwl-agn-rx.c
+++ b/drivers/net/wireless/iwlwifi/iwl-agn-rx.c
@@ -773,8 +773,7 @@ static void iwlagn_pass_packet_to_mac80211(struct iwl_priv *priv,
struct sk_buff *skb;
__le16 fc = hdr->frame_control;
struct iwl_rxon_context *ctx;
- struct page *p;
- int offset;
+ unsigned int hdrlen, fraglen;
/* We only process data packets if the interface is open */
if (unlikely(!priv->is_open)) {
@@ -788,16 +787,24 @@ static void iwlagn_pass_packet_to_mac80211(struct iwl_priv *priv,
iwlagn_set_decrypted_flag(priv, hdr, ampdu_status, stats))
return;
- skb = dev_alloc_skb(128);
+ /* Dont use dev_alloc_skb(), we'll have enough headroom once
+ * ieee80211_hdr pulled.
+ */
+ skb = alloc_skb(128, GFP_ATOMIC);
if (!skb) {
- IWL_ERR(priv, "dev_alloc_skb failed\n");
+ IWL_ERR(priv, "alloc_skb failed\n");
return;
}
+ hdrlen = min_t(unsigned int, len, skb_tailroom(skb));
+ memcpy(skb_put(skb, hdrlen), hdr, hdrlen);
+ fraglen = len - hdrlen;
- offset = (void *)hdr - rxb_addr(rxb);
- p = rxb_steal_page(rxb);
- skb_add_rx_frag(skb, 0, p, offset, len, len);
+ if (fraglen) {
+ int offset = (void *)hdr + hdrlen - rxb_addr(rxb);
+ skb_add_rx_frag(skb, 0, rxb_steal_page(rxb), offset,
+ fraglen, rxb->truesize);
+ }
iwl_update_stats(priv, false, fc, len);
/*
diff --git a/drivers/net/wireless/iwlwifi/iwl-trans-pcie-rx.c b/drivers/net/wireless/iwlwifi/iwl-trans-pcie-rx.c
index 8b1a798..aa7aea1 100644
--- a/drivers/net/wireless/iwlwifi/iwl-trans-pcie-rx.c
+++ b/drivers/net/wireless/iwlwifi/iwl-trans-pcie-rx.c
@@ -374,8 +374,9 @@ static void iwl_rx_handle_rxbuf(struct iwl_trans *trans,
if (WARN_ON(!rxb))
return;
+ rxcb.truesize = PAGE_SIZE << hw_params(trans).rx_page_order;
dma_unmap_page(trans->dev, rxb->page_dma,
- PAGE_SIZE << hw_params(trans).rx_page_order,
+ rxcb.truesize,
DMA_FROM_DEVICE);
rxcb._page = rxb->page;
diff --git a/drivers/net/wireless/iwlwifi/iwl-trans.h b/drivers/net/wireless/iwlwifi/iwl-trans.h
index 0c81cba..fdf9788 100644
--- a/drivers/net/wireless/iwlwifi/iwl-trans.h
+++ b/drivers/net/wireless/iwlwifi/iwl-trans.h
@@ -260,6 +260,7 @@ static inline void iwl_free_resp(struct iwl_host_cmd *cmd)
struct iwl_rx_cmd_buffer {
struct page *_page;
+ unsigned int truesize;
};
static inline void *rxb_addr(struct iwl_rx_cmd_buffer *r)
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply related
* Re: [PATCH 7/9] net: add skb_orphan_frags to copy aside frags with destructors
From: David Miller @ 2012-05-03 17:55 UTC (permalink / raw)
To: mst; +Cc: ian.campbell, netdev, eric.dumazet
In-Reply-To: <20120503154142.GB27671@redhat.com>
From: "Michael S. Tsirkin" <mst@redhat.com>
Date: Thu, 3 May 2012 18:41:43 +0300
> On Thu, May 03, 2012 at 03:56:09PM +0100, Ian Campbell wrote:
>> This should be used by drivers which need to hold on to an skb for an extended
>> (perhaps unbounded) period of time. e.g. the tun driver which relies on
>> userspace consuming the skb.
>>
>> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
>> Cc: mst@redhat.com
>
>
> Right. But local sockets queue at socket forever as well.
> I think this should be called in skb_set_owner_r?
>
> This might somewhat penalize speed for local clients in the name
> of correctness but these are rare so being correct is
> more important I think.
But, on the other hand, putting the check into skb_set_owner_r() is a
not so nice test to have in the fast path of every socket receive.
^ permalink raw reply
* Re: [net-next 0/9][pull request] Intel Wired LAN Dirver Updates
From: David Miller @ 2012-05-03 17:30 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, gospo, sassmann
In-Reply-To: <1336038992-3144-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Thu, 3 May 2012 02:56:23 -0700
> This series of patches contains updates for e1000e and ixgbevf.
>
> The following are changes since commit af94bf6db1d58d26f1cdab145b6312ad363254a6:
> ixgbe: Fix use after free on module remove
> and are available in the git repository at:
> git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/net-next master
Pulled, thanks Jeff.
^ permalink raw reply
* Re: pull request: wireless-next 2012-05-03
From: Joe Perches @ 2012-05-03 17:29 UTC (permalink / raw)
To: David Miller; +Cc: linville, linux-wireless, netdev
In-Reply-To: <20120503.131707.112550136096227430.davem@davemloft.net>
On Thu, 2012-05-03 at 13:17 -0400, David Miller wrote:
> ...
> - if (hdev->discovery.type == DISCOV_TYPE_INTERLEAVED) {
> + if (hdev->discovery.type == DISCOV_TYPE_INTERLEAVED &&
> + hdev->discovery.state == DISCOVERY_FINDING) {
>
> Really, we went through this a million times very recently and I'm
> not pulling anything into my tree that has garbage like this in it.
Perhaps the bluetooth folk can adopt using
scripts/checkpatch.pl --strict
or maybe checkpatch could be changed to use
--strict on patches in net and drivers/net
automatically.
^ permalink raw reply
* Re: pull request: wireless-next 2012-05-03
From: John W. Linville @ 2012-05-03 17:28 UTC (permalink / raw)
To: David Miller
Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20120503.131707.112550136096227430.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
On Thu, May 03, 2012 at 01:17:07PM -0400, David Miller wrote:
> From: David Miller <davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
> Date: Thu, 03 May 2012 13:05:16 -0400 (EDT)
>
> > Pulled, thanks John.
>
> Actually, I un-pulled. The bluetooth guys are sending crap code
> formatting again.
>
> From 74e05692c9599866d5c8743764544cf77cd1af87 Mon Sep 17 00:00:00 2001
> From: Andre Guedes <andre.guedes-430g2QfJUUCGglJvpFV4uA@public.gmane.org>
> Date: Tue, 6 Mar 2012 19:37:06 -0300
> Subject: [PATCH 007/160] Bluetooth: Check FINDING state in interleaved
> discovery
>
> In order to do interleaved discovery we should be in DISCOVERY_
> FINDING state. Otherwise, discovery should be stopped.
>
> Signed-off-by: Andre Guedes <andre.guedes-430g2QfJUUCGglJvpFV4uA@public.gmane.org>
> Signed-off-by: Gustavo F. Padovan <padovan-Y3ZbgMPKUGA34EUeqzHoZw@public.gmane.org>
> ...
> - if (hdev->discovery.type == DISCOV_TYPE_INTERLEAVED) {
> + if (hdev->discovery.type == DISCOV_TYPE_INTERLEAVED &&
> + hdev->discovery.state == DISCOVERY_FINDING) {
>
> Really, we went through this a million times very recently and I'm
> not pulling anything into my tree that has garbage like this in it.
>
> Sorry.
No, I'm sorry. I thought we had this worked-out.
John
--
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 v3] tilegx network driver: initial support
From: Chris Metcalf @ 2012-05-03 17:25 UTC (permalink / raw)
To: David Miller; +Cc: arnd, linux-kernel, netdev
In-Reply-To: <20120503.130738.203857602354001769.davem@davemloft.net>
On 5/3/2012 1:07 PM, David Miller wrote:
> From: Chris Metcalf <cmetcalf@tilera.com>
> Date: Thu, 3 May 2012 11:45:32 -0400
>
>> Thanks, I've removed it from my branch. (Since it's a trivial update, I
>> won't repost the change on LKML unless I get any more feedback that needs
>> addressing.)
> Sorry, this approach doesn't work, you should post a new version
> more expediently.
>
> When I see something so terrible like I saw this time, I just provide
> feedback on that major issue and stop reviewing.
Thanks, good to know. Will do.
--
Chris Metcalf, Tilera Corp.
http://www.tilera.com
^ permalink raw reply
* Re: [PATCH] skb: Add skb_head_is_locked helper function
From: David Miller @ 2012-05-03 17:23 UTC (permalink / raw)
To: alexander.h.duyck; +Cc: netdev, jeffrey.t.kirsher, edumazet
In-Reply-To: <20120503110942.18281.27820.stgit@gitlad.jf.intel.com>
From: Alexander Duyck <alexander.h.duyck@intel.com>
Date: Thu, 03 May 2012 04:09:42 -0700
> This patch adds support for a skb_head_is_locked helper function. It is
> meant to be used any time we are considering transferring the head from
> skb->head to a paged frag. If the head is locked it means we cannot remove
> the head from the skb so it must be copied or we must take the skb as a
> whole.
>
> Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
Thanks for following up on this instead of going to sleep :-)
Applied.
^ permalink raw reply
* Re: [PATCH net-next] net: Fix truesize accounting in skb_gro_receive()
From: David Miller @ 2012-05-03 17:22 UTC (permalink / raw)
To: eric.dumazet; +Cc: alexander.h.duyck, netdev, jeffrey.t.kirsher
In-Reply-To: <1336037601.3752.8.camel@edumazet-glaptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Thu, 03 May 2012 11:33:21 +0200
> From: Eric Dumazet <edumazet@google.com>
>
> GRO is very optimistic in skb truesize estimates, only taking into
> account the used part of fragments.
>
> Be conservative, and use more precise computation, so that bloated GRO
> skbs can be collapsed eventually.
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Applied.
^ permalink raw reply
* Re: pull request: wireless-next 2012-05-03
From: David Miller @ 2012-05-03 17:21 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, netdev
In-Reply-To: <20120503.131707.112550136096227430.davem@davemloft.net>
From: David Miller <davem@davemloft.net>
Date: Thu, 03 May 2012 13:17:07 -0400 (EDT)
> Really, we went through this a million times very recently and I'm
> not pulling anything into my tree that has garbage like this in it.
BTW, the bluetooth guys owe John Linville a serious apology.
Because of the crap situation they've created, I can no longer
trust John's pulls.
That means I have to baby-sit every pull request he sends me and
go through every single patch in it looking for these kinds of
problems.
This is _NOT_ how this is supposed to work.
John should be sending me things that are fully vetted and I can
basically trust to be in good shape. But because of the bluetooth
guys that is not the case.
^ permalink raw reply
* Re: [PATCH 2/2] tcp: cleanup tcp_try_coalesce
From: John W. Linville @ 2012-05-03 17:07 UTC (permalink / raw)
To: Guy, Wey-Yi
Cc: David Miller, eric.dumazet, alexander.duyck, alexander.h.duyck,
netdev, edumazet, jeffrey.t.kirsher, linux-wireless,
Stephen Rothwell
In-Reply-To: <1336058659.27487.80.camel@wwguy-huron>
On Thu, May 03, 2012 at 08:24:19AM -0700, Guy, Wey-Yi wrote:
> Hi John,
>
> On Thu, 2012-05-03 at 11:14 -0400, John W. Linville wrote:
> > On Thu, May 03, 2012 at 01:25:02AM -0400, David Miller wrote:
> > > From: Eric Dumazet <eric.dumazet@gmail.com>
> > > Date: Thu, 03 May 2012 07:19:33 +0200
> > >
> > > > My last patch against iwlwifi is still waiting to make its way into
> > > > official tree.
> > > >
> > > > http://www.spinics.net/lists/netdev/msg192629.html
> > >
> > > John, please rectify this situation.
> > >
> > > The Intel Wireless folks said they would test it, but that was more
> > > than a month ago.
> > >
> > > It's not acceptable to let bug fixes rot for that long, I don't care
> > > what their special internal testing procedure is.
> > >
> > > If they give you further pushback, please just ignore them and apply
> > > Eric's fix directly.
> > >
> > > Thank you.
> >
> > I imagine that this somehow got lost in the shuffle during the
> > merge window. That doesn't excuse it, of course.
> >
> > It has waited long enough already, so I'll just go ahead and take it.
> >
> it is my mistake to lost this patch during the iwlwifi re-factor work,
> the patch is no longer apply and I ask Eric to rebase the patch.
>
> Sorry again for the mistake
Well, it seems like a fix needed for 3.4. And, the patch applies there.
It does cause some merge breakage in wireless-testing (and presumably
in linux-next). I'll attach the commit diff for the wireless-testing
merge fixup I did, for review and/or as a peace offering to sfr... :-)
Please take a look at the result in wireless-testing and let me know
if it is broken...thanks!
John
---
commit 22a101d22ad3296b55d87e92c4a94548aaf6f595
Merge: 20ef730 ed90542
Author: John W. Linville <linville@tuxdriver.com>
Date: Thu May 3 12:58:38 2012 -0400
Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless
Conflicts:
drivers/net/wireless/iwlwifi/iwl-agn-rx.c
drivers/net/wireless/iwlwifi/iwl-trans-pcie-rx.c
drivers/net/wireless/iwlwifi/iwl-trans.h
diff --cc drivers/net/wireless/iwlwifi/iwl-agn-rx.c
index f941223,2247460..ff758fe
--- a/drivers/net/wireless/iwlwifi/iwl-agn-rx.c
+++ b/drivers/net/wireless/iwlwifi/iwl-agn-rx.c
@@@ -752,15 -787,25 +751,25 @@@ static void iwlagn_pass_packet_to_mac80
iwlagn_set_decrypted_flag(priv, hdr, ampdu_status, stats))
return;
- skb = dev_alloc_skb(128);
+ /* Dont use dev_alloc_skb(), we'll have enough headroom once
+ * ieee80211_hdr pulled.
+ */
+ skb = alloc_skb(128, GFP_ATOMIC);
if (!skb) {
- IWL_ERR(priv, "dev_alloc_skb failed\n");
+ IWL_ERR(priv, "alloc_skb failed\n");
return;
}
+ hdrlen = min_t(unsigned int, len, skb_tailroom(skb));
+ memcpy(skb_put(skb, hdrlen), hdr, hdrlen);
+ fraglen = len - hdrlen;
+
+ if (fraglen) {
- int offset = (void *)hdr + hdrlen - rxb_addr(rxb);
++ int offset = (void *)hdr + hdrlen - rxb_addr(rxb)
++ + rxb_offset(rxb);
- offset = (void *)hdr - rxb_addr(rxb) + rxb_offset(rxb);
- p = rxb_steal_page(rxb);
- skb_add_rx_frag(skb, 0, p, offset, len, len);
+ skb_add_rx_frag(skb, 0, rxb_steal_page(rxb), offset,
+ fraglen, rxb->truesize);
+ }
- iwl_update_stats(priv, false, fc, len);
/*
* Wake any queues that were stopped due to a passive channel tx
diff --cc drivers/net/wireless/iwlwifi/iwl-trans-pcie-rx.c
index d2239aa,aa7aea1..08517d3
--- a/drivers/net/wireless/iwlwifi/iwl-trans-pcie-rx.c
+++ b/drivers/net/wireless/iwlwifi/iwl-trans-pcie-rx.c
@@@ -373,89 -374,72 +373,90 @@@ static void iwl_rx_handle_rxbuf(struct
if (WARN_ON(!rxb))
return;
- rxcb.truesize = PAGE_SIZE << hw_params(trans).rx_page_order;
- dma_unmap_page(trans->dev, rxb->page_dma,
- rxcb.truesize,
- DMA_FROM_DEVICE);
-
- rxcb._page = rxb->page;
- pkt = rxb_addr(&rxcb);
-
- IWL_DEBUG_RX(trans, "%s, 0x%02x\n",
- get_cmd_string(pkt->hdr.cmd), pkt->hdr.cmd);
+ dma_unmap_page(trans->dev, rxb->page_dma, max_len, DMA_FROM_DEVICE);
+ while (offset + sizeof(u32) + sizeof(struct iwl_cmd_header) < max_len) {
+ struct iwl_rx_packet *pkt;
+ struct iwl_device_cmd *cmd;
+ u16 sequence;
+ bool reclaim;
+ int index, cmd_index, err, len;
+ struct iwl_rx_cmd_buffer rxcb = {
+ ._offset = offset,
+ ._page = rxb->page,
+ ._page_stolen = false,
++ .truesize = max_len,
+ };
- len = le32_to_cpu(pkt->len_n_flags) & FH_RSCSR_FRAME_SIZE_MSK;
- len += sizeof(u32); /* account for status word */
- trace_iwlwifi_dev_rx(trans->dev, pkt, len);
+ pkt = rxb_addr(&rxcb);
- /* Reclaim a command buffer only if this packet is a response
- * to a (driver-originated) command.
- * If the packet (e.g. Rx frame) originated from uCode,
- * there is no command buffer to reclaim.
- * Ucode should set SEQ_RX_FRAME bit if ucode-originated,
- * but apparently a few don't get set; catch them here. */
- reclaim = !(pkt->hdr.sequence & SEQ_RX_FRAME);
- if (reclaim) {
- int i;
+ if (pkt->len_n_flags == cpu_to_le32(FH_RSCSR_FRAME_INVALID))
+ break;
- for (i = 0; i < trans_pcie->n_no_reclaim_cmds; i++) {
- if (trans_pcie->no_reclaim_cmds[i] == pkt->hdr.cmd) {
- reclaim = false;
- break;
+ IWL_DEBUG_RX(trans, "cmd at offset %d: %s (0x%.2x)\n",
+ rxcb._offset,
+ trans_pcie_get_cmd_string(trans_pcie, pkt->hdr.cmd),
+ pkt->hdr.cmd);
+
+ len = le32_to_cpu(pkt->len_n_flags) & FH_RSCSR_FRAME_SIZE_MSK;
+ len += sizeof(u32); /* account for status word */
+ trace_iwlwifi_dev_rx(trans->dev, pkt, len);
+
+ /* Reclaim a command buffer only if this packet is a response
+ * to a (driver-originated) command.
+ * If the packet (e.g. Rx frame) originated from uCode,
+ * there is no command buffer to reclaim.
+ * Ucode should set SEQ_RX_FRAME bit if ucode-originated,
+ * but apparently a few don't get set; catch them here. */
+ reclaim = !(pkt->hdr.sequence & SEQ_RX_FRAME);
+ if (reclaim) {
+ int i;
+
+ for (i = 0; i < trans_pcie->n_no_reclaim_cmds; i++) {
+ if (trans_pcie->no_reclaim_cmds[i] ==
+ pkt->hdr.cmd) {
+ reclaim = false;
+ break;
+ }
}
}
- }
- sequence = le16_to_cpu(pkt->hdr.sequence);
- index = SEQ_TO_INDEX(sequence);
- cmd_index = get_cmd_index(&txq->q, index);
+ sequence = le16_to_cpu(pkt->hdr.sequence);
+ index = SEQ_TO_INDEX(sequence);
+ cmd_index = get_cmd_index(&txq->q, index);
- if (reclaim)
- cmd = txq->cmd[cmd_index];
- else
- cmd = NULL;
+ if (reclaim)
+ cmd = txq->entries[cmd_index].cmd;
+ else
+ cmd = NULL;
- err = iwl_op_mode_rx(trans->op_mode, &rxcb, cmd);
+ err = iwl_op_mode_rx(trans->op_mode, &rxcb, cmd);
- /*
- * XXX: After here, we should always check rxcb._page
- * against NULL before touching it or its virtual
- * memory (pkt). Because some rx_handler might have
- * already taken or freed the pages.
- */
+ /*
+ * After here, we should always check rxcb._page_stolen,
+ * if it is true then one of the handlers took the page.
+ */
- if (reclaim) {
- /* Invoke any callbacks, transfer the buffer to caller,
- * and fire off the (possibly) blocking
- * iwl_trans_send_cmd()
- * as we reclaim the driver command queue */
- if (rxcb._page)
- iwl_tx_cmd_complete(trans, &rxcb, err);
- else
- IWL_WARN(trans, "Claim null rxb?\n");
+ if (reclaim) {
+ /* Invoke any callbacks, transfer the buffer to caller,
+ * and fire off the (possibly) blocking
+ * iwl_trans_send_cmd()
+ * as we reclaim the driver command queue */
+ if (!rxcb._page_stolen)
+ iwl_tx_cmd_complete(trans, &rxcb, err);
+ else
+ IWL_WARN(trans, "Claim null rxb?\n");
+ }
+
+ page_stolen |= rxcb._page_stolen;
+ offset += ALIGN(len, FH_RSCSR_FRAME_ALIGN);
}
- /* page was stolen from us */
- if (rxcb._page == NULL)
+ /* page was stolen from us -- free our reference */
+ if (page_stolen) {
+ __free_pages(rxb->page, trans_pcie->rx_page_order);
rxb->page = NULL;
+ }
/* Reuse the page if possible. For notification packets and
* SKBs that fail to Rx correctly, add them back into the
diff --cc drivers/net/wireless/iwlwifi/iwl-trans.h
index 7018d31,fdf9788..79a1e7a
--- a/drivers/net/wireless/iwlwifi/iwl-trans.h
+++ b/drivers/net/wireless/iwlwifi/iwl-trans.h
@@@ -256,8 -260,7 +256,9 @@@ static inline void iwl_free_resp(struc
struct iwl_rx_cmd_buffer {
struct page *_page;
+ int _offset;
+ bool _page_stolen;
+ unsigned int truesize;
};
static inline void *rxb_addr(struct iwl_rx_cmd_buffer *r)
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* Re: pull request: wireless-next 2012-05-03
From: David Miller @ 2012-05-03 17:17 UTC (permalink / raw)
To: linville-2XuSBdqkA4R54TAoqtyWWQ
Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20120503.130516.1008806127286088740.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
From: David Miller <davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
Date: Thu, 03 May 2012 13:05:16 -0400 (EDT)
> Pulled, thanks John.
Actually, I un-pulled. The bluetooth guys are sending crap code
formatting again.
>From 74e05692c9599866d5c8743764544cf77cd1af87 Mon Sep 17 00:00:00 2001
From: Andre Guedes <andre.guedes-430g2QfJUUCGglJvpFV4uA@public.gmane.org>
Date: Tue, 6 Mar 2012 19:37:06 -0300
Subject: [PATCH 007/160] Bluetooth: Check FINDING state in interleaved
discovery
In order to do interleaved discovery we should be in DISCOVERY_
FINDING state. Otherwise, discovery should be stopped.
Signed-off-by: Andre Guedes <andre.guedes-430g2QfJUUCGglJvpFV4uA@public.gmane.org>
Signed-off-by: Gustavo F. Padovan <padovan-Y3ZbgMPKUGA34EUeqzHoZw@public.gmane.org>
...
- if (hdev->discovery.type == DISCOV_TYPE_INTERLEAVED) {
+ if (hdev->discovery.type == DISCOV_TYPE_INTERLEAVED &&
+ hdev->discovery.state == DISCOVERY_FINDING) {
Really, we went through this a million times very recently and I'm
not pulling anything into my tree that has garbage like this in it.
Sorry.
--
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 v3] tilegx network driver: initial support
From: David Miller @ 2012-05-03 17:07 UTC (permalink / raw)
To: cmetcalf; +Cc: arnd, linux-kernel, netdev
In-Reply-To: <4FA2A81C.8020402@tilera.com>
From: Chris Metcalf <cmetcalf@tilera.com>
Date: Thu, 3 May 2012 11:45:32 -0400
> Thanks, I've removed it from my branch. (Since it's a trivial update, I
> won't repost the change on LKML unless I get any more feedback that needs
> addressing.)
Sorry, this approach doesn't work, you should post a new version
more expediently.
When I see something so terrible like I saw this time, I just provide
feedback on that major issue and stop reviewing.
^ permalink raw reply
* Re: [PATCH 00/16] Swap-over-NBD without deadlocking V9
From: David Miller @ 2012-05-03 17:06 UTC (permalink / raw)
To: mgorman
Cc: akpm, linux-mm, netdev, linux-kernel, neilb, a.p.zijlstra,
michaelc, emunson
In-Reply-To: <20120503150048.GI11435@suse.de>
From: Mel Gorman <mgorman@suse.de>
Date: Thu, 3 May 2012 16:00:48 +0100
> Any of the networking people care to comment?
Post another series with any lingering feedback you've received and
I'll make sure it gets queued up in patchwork so that it gets properly
reviewed by us.
Thanks.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: pull request: wireless-next 2012-05-03
From: David Miller @ 2012-05-03 17:05 UTC (permalink / raw)
To: linville-2XuSBdqkA4R54TAoqtyWWQ
Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20120503152206.GL9285-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org>
From: "John W. Linville" <linville-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org>
Date: Thu, 3 May 2012 11:22:06 -0400
> This is a batch of updates intended for 3.5. It also includes a pull
> from the wireless tree which resolved some build dependencies.
>
> Highlights of this pull request include some refactoring in the
> bluetooth directories, some HT enhancements for mac80211, an expansion
> of the ethtool support for cfg80211- and mac80211-based drivers,
> and some more iwlwifi refactoring.
>
> It looks like some of the bluetooth device ID patches got committed
> on both the bluetooth and the bluetooth-next trees. I'll ask them to
> be more careful about that, but I didn't think it was worth asking
> for rebases since that would be disruptive to the downstream trees
> and since git handles the situation reasonably well already.
Pulled, thanks John.
--
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
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