* Re: [PATCH] ax88796: depend on HAS_IOMEM not on individual ARCHs
From: David Miller @ 2011-02-22 20:37 UTC (permalink / raw)
To: mkl; +Cc: netdev
In-Reply-To: <1298405998-6214-1-git-send-email-mkl@pengutronix.de>
From: Marc Kleine-Budde <mkl@pengutronix.de>
Date: Tue, 22 Feb 2011 21:19:58 +0100
> Reported-by: David Miller <davem@davemloft.net>
> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
> ---
>
> Hello David,
>
> this patch is available in the git repository at:
> git://git.pengutronix.de/git/mkl/linux-2.6.git net/ax88796
>
> based on the patches already merged into net-next.
I would like you to actually build test this.
I know it's going to cause allmodconfig build errors on sparc64,
for example.
^ permalink raw reply
* [PATCH] sis900: use pci_dev->revision
From: Sergei Shtylyov @ 2011-02-22 20:29 UTC (permalink / raw)
To: netdev, venza
This driver uses PCI_CLASS_REVISION instead of PCI_REVISION_ID, so it wasn't
converted by commit 44c10138fd4bbc4b6d6bff0873c24902f2a9da65 (PCI: Change all
drivers to use pci_device->revision).
Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
---
The patch is against the recent Linus' tree.
drivers/net/sis900.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
Index: linux-2.6/drivers/net/sis900.c
===================================================================
--- linux-2.6.orig/drivers/net/sis900.c
+++ linux-2.6/drivers/net/sis900.c
@@ -495,7 +495,7 @@ static int __devinit sis900_probe(struct
sis_priv->mii_info.reg_num_mask = 0x1f;
/* Get Mac address according to the chip revision */
- pci_read_config_byte(pci_dev, PCI_CLASS_REVISION, &(sis_priv->chipset_rev));
+ sis_priv->chipset_rev = pci_dev->revision;
if(netif_msg_probe(sis_priv))
printk(KERN_DEBUG "%s: detected revision %2.2x, "
"trying to get MAC address...\n",
@@ -532,7 +532,7 @@ static int __devinit sis900_probe(struct
/* save our host bridge revision */
dev = pci_get_device(PCI_VENDOR_ID_SI, PCI_DEVICE_ID_SI_630, NULL);
if (dev) {
- pci_read_config_byte(dev, PCI_CLASS_REVISION, &sis_priv->host_bridge_rev);
+ sis_priv->host_bridge_rev = dev->revision;
pci_dev_put(dev);
}
^ permalink raw reply
* [PATCH] ax88796: depend on HAS_IOMEM not on individual ARCHs
From: Marc Kleine-Budde @ 2011-02-22 20:19 UTC (permalink / raw)
To: netdev; +Cc: davem, Marc Kleine-Budde
In-Reply-To: <20110222.111856.102538007.davem@davemloft.net>
Reported-by: David Miller <davem@davemloft.net>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
---
Hello David,
this patch is available in the git repository at:
git://git.pengutronix.de/git/mkl/linux-2.6.git net/ax88796
based on the patches already merged into net-next.
regards, Marc
drivers/net/Kconfig | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index f4b3927..5d7d9e7 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -237,7 +237,7 @@ source "drivers/net/arm/Kconfig"
config AX88796
tristate "ASIX AX88796 NE2000 clone support"
- depends on ARM || MIPS || SUPERH
+ depends on HAS_IOMEM
select PHYLIB
select MDIO_BITBANG
help
--
1.7.2.3
^ permalink raw reply related
* Re: [PATCH] USB 10/100 RJ45 Ethernet Network Adapter
From: Sergei Shtylyov @ 2011-02-22 20:18 UTC (permalink / raw)
To: David Miller
Cc: sshtylyov, shaharh, linux-usb, linux-kernel, jacmet, gregkh,
netdev
In-Reply-To: <20110222.112403.179931392.davem@davemloft.net>
Hello.
David Miller wrote:
>> Shahar Havivi wrote:
>>> The device is very similar to (0x0fe6, 0x8101),
>>> And works well with dm9601 driver.
>> You should sign off your patch in order for it to be merged.
> He did, see the follow-up patch with subject
> [PATCH-v2] Added support for usb ethernet (0x0fe6, 0x9700)
Yeah, I've somewhat hasted with following up.
WBR, Sergei
^ permalink raw reply
* Re: [stable] 2.6.38-rc5-git6: Reported regressions 2.6.36 -> 2.6.37
From: Greg KH @ 2011-02-22 20:07 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Linux SCSI List, Florian Mickler, Network Development,
Linux Wireless List, Linux Kernel Mailing List, DRI, Linux ACPI,
Andrew Morton, Kernel Testers List, Linus Torvalds, Linux PM List,
Maciej Rutecki
In-Reply-To: <JwKd6rET8XO.A._ZC.gbuYNB@chimera>
On Mon, Feb 21, 2011 at 11:29:26PM +0100, Rafael J. Wysocki wrote:
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=24582
> Subject : Kernel Oops at tty_buffer_request_room when using pppd program (2.6.37-rc4)
> Submitter : baoyb <baoyb@avit.org.cn>
> Date : 2010-12-08 13:55 (76 days old)
> Message-ID : <EF6DDE218DB34702B1FA84D6CD7EA771@baoyb>
> References : http://marc.info/?l=linux-kernel&m=129181763525738&w=2
> Handled-By : Jiri Slaby <jslaby@suse.cz>
> Patch : https://bugzilla.kernel.org/attachment.cgi?id=47872
This is queued up already for sending to Linus soon.
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH 2/2] DM9000B: Fix PHY power for network down/up
From: Henry Nestler @ 2011-02-22 19:58 UTC (permalink / raw)
To: David Miller; +Cc: sshtylyov, netdev, linux-arm-kernel, Sergei Shtylyov
In-Reply-To: <20110222.102410.260079835.davem@davemloft.net>
Hello David,
On 22.02.2011 19:24, David Miller wrote:
> From: Henry Nestler <henry.nestler@gmail.com>
> Date: Mon, 21 Feb 2011 22:03:31 +0100
>
>> On 21.02.2011 12:14, Sergei Shtylyov wrote:
>>> On 21-02-2011 0:45, Henry Nestler wrote:
>>>> + udelay(1000); /* delay needs by DM9000B */
>>>
>>> Why not mdelay(1)?
>>
>> Because udelay is the base of mdelay.
>> See include/linux/delay.h:31
>>
>> #define mdelay(n) ... udelay((n)*1000)
>
> He is telling you to use mdelay(1) because it's clearer. Please do
> so.
Thanks, that text explains it better. No problem. I will resend this patch.
--
Henry N.
^ permalink raw reply
* Re: pull request: wireless-2.6 2011-02-22
From: David Miller @ 2011-02-22 19:55 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, netdev, linux-kernel
In-Reply-To: <20110222193757.GF12153@tuxdriver.com>
From: "John W. Linville" <linville@tuxdriver.com>
Date: Tue, 22 Feb 2011 14:37:57 -0500
> Here is the latest round of wireless fixes intended for 2.6.38.
> Included are a DMA API fix for p54, an ath5k channel setting fix
> for AR2317 hardware, a WARNING fix related to conn_mon_timer, a lock
> order fix in cfg80211_wext_siwfreq, a bluetooth locking fix, and a
> few simple hardware-enablement patches.
>
> There are a couple of other notables. There is an ath9k patch that
> reverts some earlier patches that cause a regression in power usage.
> Also, there is a fairly large ath5k patch to address a regression
> related to fast channel switching. The patch seems bigger than it
> really is because it moves some code around. Both of these cite the
> related bugzilla entry.
>
> Please let me know if there are problems!
Pulled, thanks a lot John.
^ permalink raw reply
* Re: [PATCH] rt2x00: Use ops name instead of device name
From: Steven Rostedt @ 2011-02-22 19:52 UTC (permalink / raw)
To: Ivo Van Doorn
Cc: Ben Hutchings, LKML, netdev, Felix Fietkau, John W. Linville,
abogani
In-Reply-To: <AANLkTinNUnq7JQDpTzCv24A7T7fMn9iPFisQEBZGkELr@mail.gmail.com>
On Tue, 2011-02-22 at 20:33 +0100, Ivo Van Doorn wrote:
> Hi,
>
> On Tue, Feb 22, 2011 at 2:44 PM, Steven Rostedt <rostedt@goodmis.org> wrote:
> > On Tue, 2011-02-22 at 13:34 +0000, Ben Hutchings wrote:
> >
> >> > 19: 73474106 0 IO-APIC-fasteoi ata_piix, uhci_hcd:usb6, 0000:05:01.0
> >
> >> > rt2x00dev->irq = pci_dev->irq;
> >> > - rt2x00dev->name = pci_name(pci_dev);
> >> > + rt2x00dev->name = ops->name;
> >
> >
> >> But then how can users distinguish the IRQs for multiple devices handled
> >> by the same driver? (Probably unusual for WLAN devices, but still
> >> possible.)
> >>
> >> I assume you can't use a net device name as there may be multiple net
> >> devices per bus device?
> >
> > Honestly, I do not know this code well enough, but this patch seemed to
> > solve the problem at hand. Hence I sent it out to the experts hoping
> > they either take this patch or come up with a proper solution ;)
> >
> > In any case, just posting the pci address is not a pretty answer.
>
> I just checked the other wireless drivers, and they all seem to use
> the modulename. So I guess your patch is correct. You can add my:
>
> Acked-by: Ivo van Doorn <IvDoorn@gmail.com>
Thanks!
Actually, to answer Ben's question. lspci should give you what you want.
On my local box (not the one mentioned above):
$ lspci -vv
[...]
00:0a.0 Bridge: nVidia Corporation CK804 Ethernet Controller (rev a3)
Subsystem: Tyan Computer Tomcat K8E (S2865)
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 (250ns min, 5000ns max)
Interrupt: pin A routed to IRQ 23
Region 0: Memory at febf9000 (32-bit, non-prefetchable) [size=4K]
Region 1: I/O ports at b400 [size=8]
Capabilities: <access denied>
Kernel driver in use: forcedeth
(spaces added by me)
$ cat /proc/interrupts
[...]
23: 547 648564 IO-APIC-fasteoi ohci_hcd:usb2, eth0
-- Steve
^ permalink raw reply
* Re: [PATCH] rt2x00: Use ops name instead of device name
From: John W. Linville @ 2011-02-22 19:47 UTC (permalink / raw)
To: Ivo Van Doorn
Cc: Steven Rostedt, Ben Hutchings, LKML, netdev, Felix Fietkau,
abogani
In-Reply-To: <AANLkTinNUnq7JQDpTzCv24A7T7fMn9iPFisQEBZGkELr@mail.gmail.com>
On Tue, Feb 22, 2011 at 08:33:45PM +0100, Ivo Van Doorn wrote:
> Hi,
>
> On Tue, Feb 22, 2011 at 2:44 PM, Steven Rostedt <rostedt@goodmis.org> wrote:
> > On Tue, 2011-02-22 at 13:34 +0000, Ben Hutchings wrote:
> >
> >> > 19: 73474106 0 IO-APIC-fasteoi ata_piix, uhci_hcd:usb6, 0000:05:01.0
> >
> >> > rt2x00dev->irq = pci_dev->irq;
> >> > - rt2x00dev->name = pci_name(pci_dev);
> >> > + rt2x00dev->name = ops->name;
> >
> >
> >> But then how can users distinguish the IRQs for multiple devices handled
> >> by the same driver? (Probably unusual for WLAN devices, but still
> >> possible.)
> >>
> >> I assume you can't use a net device name as there may be multiple net
> >> devices per bus device?
> >
> > Honestly, I do not know this code well enough, but this patch seemed to
> > solve the problem at hand. Hence I sent it out to the experts hoping
> > they either take this patch or come up with a proper solution ;)
> >
> > In any case, just posting the pci address is not a pretty answer.
>
> I just checked the other wireless drivers, and they all seem to use
> the modulename. So I guess your patch is correct. You can add my:
>
> Acked-by: Ivo van Doorn <IvDoorn@gmail.com>
I completely missed this series -- please be sure to Cc:
linux-wireless@vger.kernel.org if you resend, and/or resend the series
directly to me?
Thanks!
John
--
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
* pull request: wireless-2.6 2011-02-22
From: John W. Linville @ 2011-02-22 19:37 UTC (permalink / raw)
To: davem; +Cc: linux-wireless, netdev, linux-kernel
Dave,
Here is the latest round of wireless fixes intended for 2.6.38.
Included are a DMA API fix for p54, an ath5k channel setting fix
for AR2317 hardware, a WARNING fix related to conn_mon_timer, a lock
order fix in cfg80211_wext_siwfreq, a bluetooth locking fix, and a
few simple hardware-enablement patches.
There are a couple of other notables. There is an ath9k patch that
reverts some earlier patches that cause a regression in power usage.
Also, there is a fairly large ath5k patch to address a regression
related to fast channel switching. The patch seems bigger than it
really is because it moves some code around. Both of these cite the
related bugzilla entry.
Please let me know if there are problems!
John
---
The following changes since commit c24f691b56107feeba076616982093ee2d3c8fb5:
tcp: undo_retrans counter fixes (2011-02-21 11:31:18 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git master
Cho, Yu-Chen (1):
Bluetooth: Add Atheros BT AR5BBU12 fw supported
Christian Lamparter (1):
p54pci: update receive dma buffers before and after processing
Daniel J Blueman (1):
fix cfg80211_wext_siwfreq lock ordering...
Gertjan van Wingerde (1):
rt2x00: Fix WPA TKIP Michael MIC failures.
John W. Linville (1):
Merge branch 'master' of git://git.kernel.org/.../padovan/bluetooth-2.6
Mohammed Shafi Shajakhan (1):
ath9k: Fix ath9k prevents CPU to enter C3 states
Nick Kossifidis (1):
ath5k: Fix fast channel switching
Nikolay Ledovskikh (1):
ath5k: Correct channel setting for AR2317 chip
Oliver Neukum (1):
Bluetooth: fix crash with quirky dongles doing sound
Stanislaw Gruszka (1):
mac80211: fix conn_mon_timer running after disassociate
Vladislav P (1):
Bluetooth: Release BTM while sleeping to avoid deadlock
Xose Vazquez Perez (1):
wireless: rt2x00: rt2800pci.c: add two ids
drivers/bluetooth/ath3k.c | 3 +
drivers/bluetooth/btusb.c | 7 +-
drivers/net/wireless/ath/ath5k/phy.c | 143 +++++++++++++++++++------------
drivers/net/wireless/ath/ath9k/ath9k.h | 6 --
drivers/net/wireless/ath/ath9k/init.c | 8 --
drivers/net/wireless/ath/ath9k/main.c | 8 --
drivers/net/wireless/p54/p54pci.c | 14 ++-
drivers/net/wireless/rt2x00/rt2800pci.c | 8 ++
drivers/net/wireless/rt2x00/rt2800usb.c | 6 ++
net/bluetooth/rfcomm/tty.c | 2 +
net/mac80211/mlme.c | 6 ++
net/wireless/wext-compat.c | 4 +-
12 files changed, 129 insertions(+), 86 deletions(-)
diff --git a/drivers/bluetooth/ath3k.c b/drivers/bluetooth/ath3k.c
index 333c212..6dcd55a 100644
--- a/drivers/bluetooth/ath3k.c
+++ b/drivers/bluetooth/ath3k.c
@@ -41,6 +41,9 @@ static struct usb_device_id ath3k_table[] = {
/* Atheros AR9285 Malbec with sflash firmware */
{ USB_DEVICE(0x03F0, 0x311D) },
+
+ /* Atheros AR5BBU12 with sflash firmware */
+ { USB_DEVICE(0x0489, 0xE02C) },
{ } /* Terminating entry */
};
diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
index 4cefa91..b7f2f37 100644
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -105,6 +105,9 @@ static struct usb_device_id blacklist_table[] = {
/* Atheros AR9285 Malbec with sflash firmware */
{ USB_DEVICE(0x03f0, 0x311d), .driver_info = BTUSB_IGNORE },
+ /* Atheros AR5BBU12 with sflash firmware */
+ { USB_DEVICE(0x0489, 0xe02c), .driver_info = BTUSB_IGNORE },
+
/* Broadcom BCM2035 */
{ USB_DEVICE(0x0a5c, 0x2035), .driver_info = BTUSB_WRONG_SCO_MTU },
{ USB_DEVICE(0x0a5c, 0x200a), .driver_info = BTUSB_WRONG_SCO_MTU },
@@ -829,7 +832,7 @@ static void btusb_work(struct work_struct *work)
if (hdev->conn_hash.sco_num > 0) {
if (!test_bit(BTUSB_DID_ISO_RESUME, &data->flags)) {
- err = usb_autopm_get_interface(data->isoc);
+ err = usb_autopm_get_interface(data->isoc ? data->isoc : data->intf);
if (err < 0) {
clear_bit(BTUSB_ISOC_RUNNING, &data->flags);
usb_kill_anchored_urbs(&data->isoc_anchor);
@@ -858,7 +861,7 @@ static void btusb_work(struct work_struct *work)
__set_isoc_interface(hdev, 0);
if (test_and_clear_bit(BTUSB_DID_ISO_RESUME, &data->flags))
- usb_autopm_put_interface(data->isoc);
+ usb_autopm_put_interface(data->isoc ? data->isoc : data->intf);
}
}
diff --git a/drivers/net/wireless/ath/ath5k/phy.c b/drivers/net/wireless/ath/ath5k/phy.c
index 78c26fd..62ce2f4 100644
--- a/drivers/net/wireless/ath/ath5k/phy.c
+++ b/drivers/net/wireless/ath/ath5k/phy.c
@@ -282,6 +282,34 @@ int ath5k_hw_phy_disable(struct ath5k_hw *ah)
return 0;
}
+/*
+ * Wait for synth to settle
+ */
+static void ath5k_hw_wait_for_synth(struct ath5k_hw *ah,
+ struct ieee80211_channel *channel)
+{
+ /*
+ * On 5211+ read activation -> rx delay
+ * and use it (100ns steps).
+ */
+ if (ah->ah_version != AR5K_AR5210) {
+ u32 delay;
+ delay = ath5k_hw_reg_read(ah, AR5K_PHY_RX_DELAY) &
+ AR5K_PHY_RX_DELAY_M;
+ delay = (channel->hw_value & CHANNEL_CCK) ?
+ ((delay << 2) / 22) : (delay / 10);
+ if (ah->ah_bwmode == AR5K_BWMODE_10MHZ)
+ delay = delay << 1;
+ if (ah->ah_bwmode == AR5K_BWMODE_5MHZ)
+ delay = delay << 2;
+ /* XXX: /2 on turbo ? Let's be safe
+ * for now */
+ udelay(100 + delay);
+ } else {
+ mdelay(1);
+ }
+}
+
/**********************\
* RF Gain optimization *
@@ -1253,6 +1281,7 @@ static int ath5k_hw_channel(struct ath5k_hw *ah,
case AR5K_RF5111:
ret = ath5k_hw_rf5111_channel(ah, channel);
break;
+ case AR5K_RF2317:
case AR5K_RF2425:
ret = ath5k_hw_rf2425_channel(ah, channel);
break;
@@ -3237,6 +3266,13 @@ int ath5k_hw_phy_init(struct ath5k_hw *ah, struct ieee80211_channel *channel,
/* Failed */
if (i >= 100)
return -EIO;
+
+ /* Set channel and wait for synth */
+ ret = ath5k_hw_channel(ah, channel);
+ if (ret)
+ return ret;
+
+ ath5k_hw_wait_for_synth(ah, channel);
}
/*
@@ -3251,13 +3287,53 @@ int ath5k_hw_phy_init(struct ath5k_hw *ah, struct ieee80211_channel *channel,
if (ret)
return ret;
+ /* Write OFDM timings on 5212*/
+ if (ah->ah_version == AR5K_AR5212 &&
+ channel->hw_value & CHANNEL_OFDM) {
+
+ ret = ath5k_hw_write_ofdm_timings(ah, channel);
+ if (ret)
+ return ret;
+
+ /* Spur info is available only from EEPROM versions
+ * greater than 5.3, but the EEPROM routines will use
+ * static values for older versions */
+ if (ah->ah_mac_srev >= AR5K_SREV_AR5424)
+ ath5k_hw_set_spur_mitigation_filter(ah,
+ channel);
+ }
+
+ /* If we used fast channel switching
+ * we are done, release RF bus and
+ * fire up NF calibration.
+ *
+ * Note: Only NF calibration due to
+ * channel change, not AGC calibration
+ * since AGC is still running !
+ */
+ if (fast) {
+ /*
+ * Release RF Bus grant
+ */
+ AR5K_REG_DISABLE_BITS(ah, AR5K_PHY_RFBUS_REQ,
+ AR5K_PHY_RFBUS_REQ_REQUEST);
+
+ /*
+ * Start NF calibration
+ */
+ AR5K_REG_ENABLE_BITS(ah, AR5K_PHY_AGCCTL,
+ AR5K_PHY_AGCCTL_NF);
+
+ return ret;
+ }
+
/*
* For 5210 we do all initialization using
* initvals, so we don't have to modify
* any settings (5210 also only supports
* a/aturbo modes)
*/
- if ((ah->ah_version != AR5K_AR5210) && !fast) {
+ if (ah->ah_version != AR5K_AR5210) {
/*
* Write initial RF gain settings
@@ -3276,22 +3352,6 @@ int ath5k_hw_phy_init(struct ath5k_hw *ah, struct ieee80211_channel *channel,
if (ret)
return ret;
- /* Write OFDM timings on 5212*/
- if (ah->ah_version == AR5K_AR5212 &&
- channel->hw_value & CHANNEL_OFDM) {
-
- ret = ath5k_hw_write_ofdm_timings(ah, channel);
- if (ret)
- return ret;
-
- /* Spur info is available only from EEPROM versions
- * greater than 5.3, but the EEPROM routines will use
- * static values for older versions */
- if (ah->ah_mac_srev >= AR5K_SREV_AR5424)
- ath5k_hw_set_spur_mitigation_filter(ah,
- channel);
- }
-
/*Enable/disable 802.11b mode on 5111
(enable 2111 frequency converter + CCK)*/
if (ah->ah_radio == AR5K_RF5111) {
@@ -3322,47 +3382,20 @@ int ath5k_hw_phy_init(struct ath5k_hw *ah, struct ieee80211_channel *channel,
*/
ath5k_hw_reg_write(ah, AR5K_PHY_ACT_ENABLE, AR5K_PHY_ACT);
+ ath5k_hw_wait_for_synth(ah, channel);
+
/*
- * On 5211+ read activation -> rx delay
- * and use it.
+ * Perform ADC test to see if baseband is ready
+ * Set tx hold and check adc test register
*/
- if (ah->ah_version != AR5K_AR5210) {
- u32 delay;
- delay = ath5k_hw_reg_read(ah, AR5K_PHY_RX_DELAY) &
- AR5K_PHY_RX_DELAY_M;
- delay = (channel->hw_value & CHANNEL_CCK) ?
- ((delay << 2) / 22) : (delay / 10);
- if (ah->ah_bwmode == AR5K_BWMODE_10MHZ)
- delay = delay << 1;
- if (ah->ah_bwmode == AR5K_BWMODE_5MHZ)
- delay = delay << 2;
- /* XXX: /2 on turbo ? Let's be safe
- * for now */
- udelay(100 + delay);
- } else {
- mdelay(1);
- }
-
- if (fast)
- /*
- * Release RF Bus grant
- */
- AR5K_REG_DISABLE_BITS(ah, AR5K_PHY_RFBUS_REQ,
- AR5K_PHY_RFBUS_REQ_REQUEST);
- else {
- /*
- * Perform ADC test to see if baseband is ready
- * Set tx hold and check adc test register
- */
- phy_tst1 = ath5k_hw_reg_read(ah, AR5K_PHY_TST1);
- ath5k_hw_reg_write(ah, AR5K_PHY_TST1_TXHOLD, AR5K_PHY_TST1);
- for (i = 0; i <= 20; i++) {
- if (!(ath5k_hw_reg_read(ah, AR5K_PHY_ADC_TEST) & 0x10))
- break;
- udelay(200);
- }
- ath5k_hw_reg_write(ah, phy_tst1, AR5K_PHY_TST1);
+ phy_tst1 = ath5k_hw_reg_read(ah, AR5K_PHY_TST1);
+ ath5k_hw_reg_write(ah, AR5K_PHY_TST1_TXHOLD, AR5K_PHY_TST1);
+ for (i = 0; i <= 20; i++) {
+ if (!(ath5k_hw_reg_read(ah, AR5K_PHY_ADC_TEST) & 0x10))
+ break;
+ udelay(200);
}
+ ath5k_hw_reg_write(ah, phy_tst1, AR5K_PHY_TST1);
/*
* Start automatic gain control calibration
diff --git a/drivers/net/wireless/ath/ath9k/ath9k.h b/drivers/net/wireless/ath/ath9k/ath9k.h
index 23838e3..1a7fa6e 100644
--- a/drivers/net/wireless/ath/ath9k/ath9k.h
+++ b/drivers/net/wireless/ath/ath9k/ath9k.h
@@ -21,7 +21,6 @@
#include <linux/device.h>
#include <linux/leds.h>
#include <linux/completion.h>
-#include <linux/pm_qos_params.h>
#include "debug.h"
#include "common.h"
@@ -57,8 +56,6 @@ struct ath_node;
#define A_MAX(a, b) ((a) > (b) ? (a) : (b))
-#define ATH9K_PM_QOS_DEFAULT_VALUE 55
-
#define TSF_TO_TU(_h,_l) \
((((u32)(_h)) << 22) | (((u32)(_l)) >> 10))
@@ -633,8 +630,6 @@ struct ath_softc {
struct ath_descdma txsdma;
struct ath_ant_comb ant_comb;
-
- struct pm_qos_request_list pm_qos_req;
};
struct ath_wiphy {
@@ -666,7 +661,6 @@ static inline void ath_read_cachesize(struct ath_common *common, int *csz)
extern struct ieee80211_ops ath9k_ops;
extern int ath9k_modparam_nohwcrypt;
extern int led_blink;
-extern int ath9k_pm_qos_value;
extern bool is_ath9k_unloaded;
irqreturn_t ath_isr(int irq, void *dev);
diff --git a/drivers/net/wireless/ath/ath9k/init.c b/drivers/net/wireless/ath/ath9k/init.c
index 087a6a9..a033d01 100644
--- a/drivers/net/wireless/ath/ath9k/init.c
+++ b/drivers/net/wireless/ath/ath9k/init.c
@@ -41,10 +41,6 @@ static int ath9k_btcoex_enable;
module_param_named(btcoex_enable, ath9k_btcoex_enable, int, 0444);
MODULE_PARM_DESC(btcoex_enable, "Enable wifi-BT coexistence");
-int ath9k_pm_qos_value = ATH9K_PM_QOS_DEFAULT_VALUE;
-module_param_named(pmqos, ath9k_pm_qos_value, int, S_IRUSR | S_IRGRP | S_IROTH);
-MODULE_PARM_DESC(pmqos, "User specified PM-QOS value");
-
bool is_ath9k_unloaded;
/* We use the hw_value as an index into our private channel structure */
@@ -762,9 +758,6 @@ int ath9k_init_device(u16 devid, struct ath_softc *sc, u16 subsysid,
ath_init_leds(sc);
ath_start_rfkill_poll(sc);
- pm_qos_add_request(&sc->pm_qos_req, PM_QOS_CPU_DMA_LATENCY,
- PM_QOS_DEFAULT_VALUE);
-
return 0;
error_world:
@@ -831,7 +824,6 @@ void ath9k_deinit_device(struct ath_softc *sc)
}
ieee80211_unregister_hw(hw);
- pm_qos_remove_request(&sc->pm_qos_req);
ath_rx_cleanup(sc);
ath_tx_cleanup(sc);
ath9k_deinit_softc(sc);
diff --git a/drivers/net/wireless/ath/ath9k/main.c b/drivers/net/wireless/ath/ath9k/main.c
index da5c645..a09d15f 100644
--- a/drivers/net/wireless/ath/ath9k/main.c
+++ b/drivers/net/wireless/ath/ath9k/main.c
@@ -1173,12 +1173,6 @@ static int ath9k_start(struct ieee80211_hw *hw)
ath9k_btcoex_timer_resume(sc);
}
- /* User has the option to provide pm-qos value as a module
- * parameter rather than using the default value of
- * 'ATH9K_PM_QOS_DEFAULT_VALUE'.
- */
- pm_qos_update_request(&sc->pm_qos_req, ath9k_pm_qos_value);
-
if (ah->caps.pcie_lcr_extsync_en && common->bus_ops->extn_synch_en)
common->bus_ops->extn_synch_en(common);
@@ -1345,8 +1339,6 @@ static void ath9k_stop(struct ieee80211_hw *hw)
sc->sc_flags |= SC_OP_INVALID;
- pm_qos_update_request(&sc->pm_qos_req, PM_QOS_DEFAULT_VALUE);
-
mutex_unlock(&sc->mutex);
ath_dbg(common, ATH_DBG_CONFIG, "Driver halt\n");
diff --git a/drivers/net/wireless/p54/p54pci.c b/drivers/net/wireless/p54/p54pci.c
index 1eacba4..0494d7b 100644
--- a/drivers/net/wireless/p54/p54pci.c
+++ b/drivers/net/wireless/p54/p54pci.c
@@ -199,6 +199,7 @@ static void p54p_check_rx_ring(struct ieee80211_hw *dev, u32 *index,
while (i != idx) {
u16 len;
struct sk_buff *skb;
+ dma_addr_t dma_addr;
desc = &ring[i];
len = le16_to_cpu(desc->len);
skb = rx_buf[i];
@@ -216,17 +217,20 @@ static void p54p_check_rx_ring(struct ieee80211_hw *dev, u32 *index,
len = priv->common.rx_mtu;
}
+ dma_addr = le32_to_cpu(desc->host_addr);
+ pci_dma_sync_single_for_cpu(priv->pdev, dma_addr,
+ priv->common.rx_mtu + 32, PCI_DMA_FROMDEVICE);
skb_put(skb, len);
if (p54_rx(dev, skb)) {
- pci_unmap_single(priv->pdev,
- le32_to_cpu(desc->host_addr),
- priv->common.rx_mtu + 32,
- PCI_DMA_FROMDEVICE);
+ pci_unmap_single(priv->pdev, dma_addr,
+ priv->common.rx_mtu + 32, PCI_DMA_FROMDEVICE);
rx_buf[i] = NULL;
- desc->host_addr = 0;
+ desc->host_addr = cpu_to_le32(0);
} else {
skb_trim(skb, 0);
+ pci_dma_sync_single_for_device(priv->pdev, dma_addr,
+ priv->common.rx_mtu + 32, PCI_DMA_FROMDEVICE);
desc->len = cpu_to_le16(priv->common.rx_mtu + 32);
}
diff --git a/drivers/net/wireless/rt2x00/rt2800pci.c b/drivers/net/wireless/rt2x00/rt2800pci.c
index aa97971..3b3f1e4 100644
--- a/drivers/net/wireless/rt2x00/rt2800pci.c
+++ b/drivers/net/wireless/rt2x00/rt2800pci.c
@@ -652,6 +652,12 @@ static void rt2800pci_fill_rxdone(struct queue_entry *entry,
*/
rxdesc->flags |= RX_FLAG_IV_STRIPPED;
+ /*
+ * The hardware has already checked the Michael Mic and has
+ * stripped it from the frame. Signal this to mac80211.
+ */
+ rxdesc->flags |= RX_FLAG_MMIC_STRIPPED;
+
if (rxdesc->cipher_status == RX_CRYPTO_SUCCESS)
rxdesc->flags |= RX_FLAG_DECRYPTED;
else if (rxdesc->cipher_status == RX_CRYPTO_FAIL_MIC)
@@ -1065,6 +1071,8 @@ static DEFINE_PCI_DEVICE_TABLE(rt2800pci_device_table) = {
{ PCI_DEVICE(0x1814, 0x3390), PCI_DEVICE_DATA(&rt2800pci_ops) },
#endif
#ifdef CONFIG_RT2800PCI_RT35XX
+ { PCI_DEVICE(0x1432, 0x7711), PCI_DEVICE_DATA(&rt2800pci_ops) },
+ { PCI_DEVICE(0x1432, 0x7722), PCI_DEVICE_DATA(&rt2800pci_ops) },
{ PCI_DEVICE(0x1814, 0x3060), PCI_DEVICE_DATA(&rt2800pci_ops) },
{ PCI_DEVICE(0x1814, 0x3062), PCI_DEVICE_DATA(&rt2800pci_ops) },
{ PCI_DEVICE(0x1814, 0x3562), PCI_DEVICE_DATA(&rt2800pci_ops) },
diff --git a/drivers/net/wireless/rt2x00/rt2800usb.c b/drivers/net/wireless/rt2x00/rt2800usb.c
index b97a4a5..197a36c 100644
--- a/drivers/net/wireless/rt2x00/rt2800usb.c
+++ b/drivers/net/wireless/rt2x00/rt2800usb.c
@@ -486,6 +486,12 @@ static void rt2800usb_fill_rxdone(struct queue_entry *entry,
*/
rxdesc->flags |= RX_FLAG_IV_STRIPPED;
+ /*
+ * The hardware has already checked the Michael Mic and has
+ * stripped it from the frame. Signal this to mac80211.
+ */
+ rxdesc->flags |= RX_FLAG_MMIC_STRIPPED;
+
if (rxdesc->cipher_status == RX_CRYPTO_SUCCESS)
rxdesc->flags |= RX_FLAG_DECRYPTED;
else if (rxdesc->cipher_status == RX_CRYPTO_FAIL_MIC)
diff --git a/net/bluetooth/rfcomm/tty.c b/net/bluetooth/rfcomm/tty.c
index 2575c2d..d7b9af4 100644
--- a/net/bluetooth/rfcomm/tty.c
+++ b/net/bluetooth/rfcomm/tty.c
@@ -727,7 +727,9 @@ static int rfcomm_tty_open(struct tty_struct *tty, struct file *filp)
break;
}
+ tty_unlock();
schedule();
+ tty_lock();
}
set_current_state(TASK_RUNNING);
remove_wait_queue(&dev->wait, &wait);
diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
index 45fbb9e..c9ceb4d 100644
--- a/net/mac80211/mlme.c
+++ b/net/mac80211/mlme.c
@@ -1033,6 +1033,12 @@ void ieee80211_sta_rx_notify(struct ieee80211_sub_if_data *sdata,
if (is_multicast_ether_addr(hdr->addr1))
return;
+ /*
+ * In case we receive frames after disassociation.
+ */
+ if (!sdata->u.mgd.associated)
+ return;
+
ieee80211_sta_reset_conn_monitor(sdata);
}
diff --git a/net/wireless/wext-compat.c b/net/wireless/wext-compat.c
index 3e5dbd4..d112f03 100644
--- a/net/wireless/wext-compat.c
+++ b/net/wireless/wext-compat.c
@@ -802,11 +802,11 @@ int cfg80211_wext_siwfreq(struct net_device *dev,
return freq;
if (freq == 0)
return -EINVAL;
- wdev_lock(wdev);
mutex_lock(&rdev->devlist_mtx);
+ wdev_lock(wdev);
err = cfg80211_set_freq(rdev, wdev, freq, NL80211_CHAN_NO_HT);
- mutex_unlock(&rdev->devlist_mtx);
wdev_unlock(wdev);
+ mutex_unlock(&rdev->devlist_mtx);
return err;
default:
return -EOPNOTSUPP;
--
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] rt2x00: Use ops name instead of device name
From: Ivo Van Doorn @ 2011-02-22 19:33 UTC (permalink / raw)
To: Steven Rostedt
Cc: Ben Hutchings, LKML, netdev, Felix Fietkau, John W. Linville,
abogani
In-Reply-To: <1298382263.6140.1196.camel@gandalf.stny.rr.com>
Hi,
On Tue, Feb 22, 2011 at 2:44 PM, Steven Rostedt <rostedt@goodmis.org> wrote:
> On Tue, 2011-02-22 at 13:34 +0000, Ben Hutchings wrote:
>
>> > 19: 73474106 0 IO-APIC-fasteoi ata_piix, uhci_hcd:usb6, 0000:05:01.0
>
>> > rt2x00dev->irq = pci_dev->irq;
>> > - rt2x00dev->name = pci_name(pci_dev);
>> > + rt2x00dev->name = ops->name;
>
>
>> But then how can users distinguish the IRQs for multiple devices handled
>> by the same driver? (Probably unusual for WLAN devices, but still
>> possible.)
>>
>> I assume you can't use a net device name as there may be multiple net
>> devices per bus device?
>
> Honestly, I do not know this code well enough, but this patch seemed to
> solve the problem at hand. Hence I sent it out to the experts hoping
> they either take this patch or come up with a proper solution ;)
>
> In any case, just posting the pci address is not a pretty answer.
I just checked the other wireless drivers, and they all seem to use
the modulename. So I guess your patch is correct. You can add my:
Acked-by: Ivo van Doorn <IvDoorn@gmail.com>
^ permalink raw reply
* Re: [PATCH] USB 10/100 RJ45 Ethernet Network Adapter
From: David Miller @ 2011-02-22 19:24 UTC (permalink / raw)
To: sshtylyov; +Cc: shaharh, linux-usb, linux-kernel, jacmet, gregkh, netdev
In-Reply-To: <4D640C0F.3050703@ru.mvista.com>
From: Sergei Shtylyov <sshtylyov@mvista.com>
Date: Tue, 22 Feb 2011 22:18:39 +0300
> Hello.
>
> Shahar Havivi wrote:
>
>> The device is very similar to (0x0fe6, 0x8101),
>> And works well with dm9601 driver.
>
> You should sign off your patch in order for it to be merged.
He did, see the follow-up patch with subject
[PATCH-v2] Added support for usb ethernet (0x0fe6, 0x9700)
^ permalink raw reply
* Re: [PATCH] USB 10/100 RJ45 Ethernet Network Adapter
From: Sergei Shtylyov @ 2011-02-22 19:18 UTC (permalink / raw)
To: Shahar Havivi
Cc: linux-usb, linux-kernel, Peter Korsgaard, Greg Kroah-Hartman,
netdev
In-Reply-To: <20110222140705.GA6055@redhat.com>
Hello.
Shahar Havivi wrote:
> The device is very similar to (0x0fe6, 0x8101),
> And works well with dm9601 driver.
You should sign off your patch in order for it to be merged.
> ---
> drivers/net/usb/dm9601.c | 5 +++++
> 1 files changed, 5 insertions(+), 0 deletions(-)
> diff --git a/drivers/net/usb/dm9601.c b/drivers/net/usb/dm9601.c
> index 02b622e..2d1c8ae 100644
> --- a/drivers/net/usb/dm9601.c
> +++ b/drivers/net/usb/dm9601.c
> @@ -654,6 +654,11 @@ static const struct usb_device_id products[] = {
> USB_DEVICE(0x0a46, 0x9000), /* DM9000E */
> .driver_info = (unsigned long)&dm9601_info,
> },
> + {
> + USB_DEVICE(0x0fe6, 0x9700), /* DM9601 USB to Fast Ethernet Adapter */
> +
Extra empty line shouldn't be here I guess...
> + .driver_info = (unsigned long)&dm9601_info,
> + },
> {}, // END
> };
WBR, Sergei
^ permalink raw reply
* Re: [PATCH 0/9] ax88796: cleanups and convert to phylib and mdio_bitbang
From: David Miller @ 2011-02-22 19:18 UTC (permalink / raw)
To: mkl; +Cc: netdev, ben, daniel
In-Reply-To: <1298293400-21570-1-git-send-email-mkl@pengutronix.de>
From: Marc Kleine-Budde <mkl@pengutronix.de>
Date: Mon, 21 Feb 2011 14:03:11 +0100
> this patch series fixes the phy-read/write problems of the ax88796
> (see http://www.spinics.net/lists/arm-kernel/msg98982.html).
>
> Patches 1-8 clean verious aspects of the driver. The 9th patch replaces the
> handcrafted mdio bitbang loop with the generic mdio_bitbang driver.
>
> This patch series has been tested on the Toradex colibri-320. With the patch
> mii-diag gives sound data:
>
> root@grabowski:~ mii-diag
> Using the default interface 'eth0'.
> Basic registers of MII PHY #16: 3100 782d 003b 1841 01e1 45e1 0003 0000.
> The autonegotiated capability is 01e0.
> The autonegotiated media type is 100baseTx-FD.
> Basic mode control register 0x3100: Auto-negotiation enabled.
> You have link beat, and everything is working OK.
> Your link partner advertised 45e1: Flow-control 100baseTx-FD 100baseTx 10baseT-FD 10baseT, w/ 802.3X flow control.
> End of basic transceiver information.
>
> please review and consider to appply.
Pulled into net-next-2.6, thanks.
BTW, we could remove the ARM MIPS etc. dependencies this driver has,
and replace it with HAS_IOMEM, as all the interfaces the driver uses
should be provided by every architecture.
^ permalink raw reply
* Oops in cleanup_once - 2.6.37
From: Vlado Drzik @ 2011-02-22 18:09 UTC (permalink / raw)
To: netdev
Hello,
We are recently facing crashes with 2.6.36.1 and also 2.6.37 on our
routers/firewalls (on weekly basis).
Kernels are x86_64. We use igb and e1000e network cards and crashes are
not happening during the peek load (peak is 200kpps).
I have several crashdumps available if that could help someone.
It looks like iptables might be somehow involved... (I always see
reject in there)
I've seen similar thing reported on kernel mailing list but no sadly
resolution. Could someone take a quick look?
Here is one of Oops messages (all look very similiar):
BUG: unable to handle kernel NULL pointer dereference at 0000000000000008
IP: [<ffffffff812e714a>] cleanup_once+0x4a/0x1f0
PGD 0
Oops: 0002 [#1] SMP
last sysfs file: /sys/kernel/kexec_crash_loaded
CPU 4
Modules linked in: act_mirred sch_ingress cls_u32 sch_htb ifb
nf_conntrack_netlink nfnetlink i2c_dev i2c_core bonding 8021q ipt_LOG
xt_comment ipt_REJECT xt_state ipt_REDIRECT x
t_tcpudp xt_CLASSIFY xt_mark iptable_raw ip_set_macipmap dm_mirror
dm_region_hash dm_log dm_mod video output hed battery ac ipt_set ip_set
xt_ACCOUNT compat_xtables nf_nat_ftp n
f_conntrack_ftp iptable_mangle iptable_nat nf_nat nf_conntrack_ipv4
nf_conntrack nf_defrag_ipv4 iptable_filter ip_tables x_tables sg sr_mod
cdrom e1000e bnx2 i5000_edac edac_cor
e igb psmouse serio_raw ata_piix libata shpchp pcspkr dcdbas usb_storage
megaraid_sas sd_mod scsi_mod ehci_hcd ohci_hcd uhci_hcd [last unloaded:
microcode]
Pid: 0, comm: kworker/0:1 Not tainted 2.6.37 #1 0UR033/PowerEdge 1950
RIP: 0010:[<ffffffff812e714a>] [<ffffffff812e714a>] cleanup_once+0x4a/0x1f0
RSP: 0018:ffff8800cfd03710 EFLAGS: 00010206
RAX: ffff88012d49fcc0 RBX: ffff88012ccd6f58 RCX: 0000000000000013
RDX: 0000000000000000 RSI: 0000000000000013 RDI: ffffffff814c5810
RBP: 0000000000000000 R08: ffff88011d796000 R09: ffff88011c37b9c0
R10: 0000000000000014 R11: ffff88011d5bf340 R12: ffff88012ccd6f40
R13: 0000000000000001 R14: 0000000000000000 R15: 0000000000000040
FS: 0000000000000000(0000) GS:ffff8800cfd00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: 0000000000000008 CR3: 00000000b6550000 CR4: 00000000000006e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process kworker/0:1 (pid: 0, threadinfo ffff88012fd72000, task
ffff88012fd616c0)
Stack:
ffff88012b5ac580 ffff88011330d402 ffffc900119111d0 ffffffffa01d677a
ffff88011c12fe00 ffff88012c7ebb00 ffff88012fed4090 ffffffff8105b3ce
ffff88012b5ac000 00008800cfd0dd08 ffff88012b5ac580 ffff88012c7ebb00
Call Trace:
<IRQ>
[<ffffffffa01d677a>] ? e1000_xmit_frame+0x98a/0xc90 [e1000e]
[<ffffffff8105b3ce>] ? hrtimer_interrupt+0xfe/0x1f0
[<ffffffff812b17e0>] ? skb_checksum+0x50/0x2d0
[<ffffffff812bc6b8>] ? dev_hard_start_xmit+0x528/0x750
[<ffffffff810de8c8>] ? __slab_alloc+0x1d8/0x2e0
[<ffffffff812ae092>] ? sock_alloc_send_pskb+0x1a2/0x2f0
[<ffffffff812375b5>] ? secure_ip_id+0x45/0x50
[<ffffffff812e7502>] ? inet_getpeer+0xf2/0x1f0
[<ffffffff813106f2>] ? icmp_glue_bits+0x82/0xa0
[<ffffffff812eae36>] ? ip_append_data+0x896/0xb70
[<ffffffff81310670>] ? icmp_glue_bits+0x0/0xa0
[<ffffffff812e585f>] ? rt_bind_peer+0xf/0x40
[<ffffffff812e597f>] ? __ip_select_ident+0xef/0x130
[<ffffffff812ebebf>] ? ip_push_pending_frames+0x2ff/0x3c0
[<ffffffff8131109e>] ? icmp_send+0x37e/0x630
[<ffffffffa0160077>] ? igb_xmit_frame_ring_adv+0x617/0xc20 [igb]
[<ffffffff81047214>] ? lock_timer_base+0x34/0x70
[<ffffffff812bc6b8>] ? dev_hard_start_xmit+0x528/0x750
[<ffffffffa017bb3d>] ? nf_ct_invert_tuple+0x6d/0x90 [nf_conntrack]
[<ffffffffa02a232d>] ? reject_tg+0x2cd/0x3e0 [ipt_REJECT]
[<ffffffffa0159bec>] ? ipt_do_table+0x34c/0x5d0 [ip_tables]
[<ffffffff8131b084>] ? fib_validate_source+0x104/0x2c0
[<ffffffff812e3fef>] ? rt_intern_hash+0x51f/0x5a0
[<ffffffff812e0e7e>] ? nf_iterate+0x5e/0x90
[<ffffffff812e7e70>] ? ip_local_deliver_finish+0x0/0x1f0
[<ffffffff812e10e6>] ? nf_hook_slow+0x76/0xf0
[<ffffffff812e7e70>] ? ip_local_deliver_finish+0x0/0x1f0
[<ffffffff812e7e58>] ? ip_local_deliver+0x78/0x90
[<ffffffff812ba68d>] ? __netif_receive_skb+0x3cd/0x5e0
[<ffffffff812bec25>] ? process_backlog+0x85/0x160
[<ffffffff812bee0d>] ? net_rx_action+0x10d/0x210
[<ffffffff81040211>] ? __do_softirq+0xb1/0x1d0
[<ffffffff810816b9>] ? handle_IRQ_event+0x49/0x150
[<ffffffff81003b0c>] ? call_softirq+0x1c/0x30
[<ffffffff8100503a>] ? do_softirq+0x4a/0x80
[<ffffffff810045ba>] ? do_IRQ+0x6a/0xe0
[<ffffffff81349b93>] ? ret_from_intr+0x0/0xa
<EOI>
[<ffffffff8100a34c>] ? mwait_idle+0x7c/0xd0
[<ffffffff81001c12>] ? cpu_idle+0x42/0xb0
Code: 1d 00 48 81 fb 00 58 4c 81 0f 84 86 00 00 00 4c 8d 63 e8 48 8b 05
47 17 1f 00 41 2b 44 24 28 48 39 e8 72 71 48 8b 13 48 8b 43 08 <48> 89
42 08 48 89 10 48 89 5b 08 48 89 1
b f0 ff 43 14 48 c7 c7
RIP [<ffffffff812e714a>] cleanup_once+0x4a/0x1f0
RSP <ffff8800cfd03710>
CR2: 0000000000000008
^ permalink raw reply
* Re: [PATCH NEXT 1/2] qlcnic: fix type of module parameters
From: David Miller @ 2011-02-22 18:31 UTC (permalink / raw)
To: amit.salecha; +Cc: netdev, ameen.rahman, anirban.chakraborty
In-Reply-To: <1298289514-15671-2-git-send-email-amit.salecha@qlogic.com>
From: Amit Kumar Salecha <amit.salecha@qlogic.com>
Date: Mon, 21 Feb 2011 03:58:33 -0800
> o Module parameters auto_fw_reset, use_msi, use_msi_x, qlcnic_mac_learn,
> and load_fw_file should be of type bool not int.
> o All module parameters should have qlcnic prefix.
> o Remove unnecessary macro for value "1".
>
> Signed-off-by: Amit Kumar Salecha <amit.salecha@qlogic.com>
You must not change module parameter names on a whim, as this will
break scripts.
When you create a module parameter in your driver, you are creating
something users will use, and therefore an API. You therefore
cannot change it without breaking stuff.
This is yet another reason I scream at anyone who adds module
parameters to network drivers, they are always "the wrong thing
to do".
None of these values you guys have module parameter for in the
qlcnic driver are providing facilities that are really qlcnic
specific at all.
MSI-X enablement, firmware loading controls, etc. All of this
stuff is generic and would be potentially necessary in any device
driver, not just qlcnic's.
Therefore generic facilities are where this stuff should be
implemented, instead of in driver specific module parameters.
I will not apply these patches, sorry.
^ permalink raw reply
* Re: [PATCH net-next 0/6] be2net: patch series
From: David Miller @ 2011-02-22 18:27 UTC (permalink / raw)
To: ajit.khaparde; +Cc: netdev
In-Reply-To: <20110220214242.GA13723@akhaparde-VBox>
From: Ajit Khaparde <ajit.khaparde@emulex.com>
Date: Sun, 20 Feb 2011 15:42:42 -0600
> Patch series for the be2net driver.
>
> [1/6] be2net: add new counters to display via ethtool stats
> [2/6] be2net: fixes in ethtool selftest
> [3/6] be2net: variable name change
> [4/6] be2net: fix to ignore transparent vlan ids wrongly indicated by NIC
> [5/6] be2net: add code to display temperature of ASIC
> [6/6] be2net: use hba_port_num instead of port_num
>
> Please Apply.
All applied, thanks.
^ permalink raw reply
* Re: [PATCH 2/2] DM9000B: Fix PHY power for network down/up
From: David Miller @ 2011-02-22 18:24 UTC (permalink / raw)
To: henry.nestler; +Cc: sshtylyov, netdev, tori, akpm, linux-arm-kernel
In-Reply-To: <4D62D323.7010403@henry.nestler.mail.gmail.com>
From: Henry Nestler <henry.nestler@gmail.com>
Date: Mon, 21 Feb 2011 22:03:31 +0100
> On 21.02.2011 12:14, Sergei Shtylyov wrote:
>> On 21-02-2011 0:45, Henry Nestler wrote:
>>
>>> DM9000 revision B needs 1 ms delay after PHY power on (see spec), and PHY
>>> power must on in register
>>
>> Couldn't parse that.
>
> This can read in manual DM900B-12-DS-F02 from September 2 2010, Page 14:
> "If this Register 1FH bit 0 is updated from '1' to '0', the all
> Registers can not be accessed within 1ms."
>
> The example driver code waits 2 ms.
>
>>> diff --git a/drivers/net/dm9000.c b/drivers/net/dm9000.c
>>> index 2d4c4fc..5925569 100644
>>> --- a/drivers/net/dm9000.c
>>> +++ b/drivers/net/dm9000.c
>> [...]
>>> @@ -1194,6 +1191,10 @@ dm9000_open(struct net_device *dev)
>>> if (request_irq(dev->irq, dm9000_interrupt, irqflags, dev->name, dev))
>>> return -EAGAIN;
>>>
>>> + /* GPIO0 on pre-activate PHY, Reg 1F is not set by reset */
>>> + iow(db, DM9000_GPR, 0); /* REG_1F bit0 activate phyxcer */
>>> + udelay(1000); /* delay needs by DM9000B */
>>
>> Why not mdelay(1)?
>
> Because udelay is the base of mdelay.
> See include/linux/delay.h:31
>
> #define mdelay(n) ... udelay((n)*1000)
He is telling you to use mdelay(1) because it's clearer. Please do
so.
^ permalink raw reply
* Re: pull request: sfc-next-2.6 2011-02-18
From: David Miller @ 2011-02-22 18:22 UTC (permalink / raw)
To: bhutchings; +Cc: netdev, linux-net-drivers, therbert
In-Reply-To: <1298044839.2570.7.camel@bwh-desktop>
From: Ben Hutchings <bhutchings@solarflare.com>
Date: Fri, 18 Feb 2011 16:00:39 +0000
> The following changes since commit f878b995b0f746f5726af9e66940f3bf373dae91:
>
> Merge branch 'for-davem' of git://git.kernel.org/pub/scm/linux/kernel/git/bwh/sfc-next-2.6 (2011-02-15 12:25:19 -0800)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/bwh/sfc-next-2.6.git for-davem
>
> Add support for RFS acceleration in the sfc driver, and allow it to be
> enabled and disabled dynamically using ethtool.
Pulled, thanks Ben.
^ permalink raw reply
* Re: [PATCH net-next-2.6] net: add __rcu annotations to sk_wq and wq
From: David Miller @ 2011-02-22 18:19 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1298035596.6201.54.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Fri, 18 Feb 2011 14:26:36 +0100
> Add proper RCU annotations/verbs to sk_wq and wq members
>
> Fix __sctp_write_space() sk_sleep() abuse (and sock->wq access)
>
> Fix sunrpc sk_sleep() abuse too
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied, thanks Eric.
^ permalink raw reply
* Re: [PATCH 15/14] net/fec: remove unused driver data
From: David Miller @ 2011-02-22 18:16 UTC (permalink / raw)
To: u.kleine-koenig; +Cc: netdev, mkl, kernel
In-Reply-To: <1297981945-28501-1-git-send-email-u.kleine-koenig@pengutronix.de>
From: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Date: Thu, 17 Feb 2011 23:32:25 +0100
> Apart from not being used the first argument isn't even a struct
> platform_device *.
>
> Reported-by: Marc Kleine-Budde <mkl@pengutronix.de>
> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
> ---
> Hello,
>
> this patch is available at
>
> git://git.pengutronix.de/git/ukl/linux-2.6.git fec
>
> based on the patches already merged into net-next.
Pulled, thanks.
^ permalink raw reply
* Re: [PATCH] cxgb{3,4}: streamline Kconfig options
From: David Miller @ 2011-02-22 18:14 UTC (permalink / raw)
To: JBeulich; +Cc: divy, dm, linux-kbuild, netdev
In-Reply-To: <4D5D30CA020000780003263A@vpn.id2.novell.com>
From: "Jan Beulich" <JBeulich@novell.com>
Date: Thu, 17 Feb 2011 13:29:30 +0000
> The CHELSIO_T{3,4}_DEPENDS options are really awkward, and can be
> easily dropped if the reverse dependencies of SCSI_CXGB{3,4}_ISCSI on
> the former get converted to normal (forward) ones referring to
> CHELSIO_T{3,4}.
>
> Signed-off-by: Jan Beulich <jbeulich@novell.com>
I think the goal of these strange rules is not to be complicated
on purpose, but rather to cause the iSCSI drivers to appear without
the user having to know that he needs to enable the networking
driver in order for that to happen.
^ permalink raw reply
* Re: [PATCH] sfc: lower stack usage in efx_ethtool_self_test
From: David Miller @ 2011-02-22 18:12 UTC (permalink / raw)
To: bhutchings; +Cc: eric.dumazet, netdev
In-Reply-To: <1298304561.2608.41.camel@bwh-desktop>
From: Ben Hutchings <bhutchings@solarflare.com>
Date: Mon, 21 Feb 2011 16:09:21 +0000
> On Wed, 2011-02-16 at 14:48 +0100, Eric Dumazet wrote:
>> drivers/net/sfc/ethtool.c: In function ‘efx_ethtool_self_test’:
>> drivers/net/sfc/ethtool.c:613: warning: the frame size of 1200 bytes
>> is larger than 1024 bytes
>
> This also fixes a whopping information leak in case the device is in a
> broken state.
>
>> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
> Acked-by: Ben Hutchings <bhutchings@solarflare.com>
Ok, I'll apply this to net-2.6, thanks!
^ permalink raw reply
* Re: [PATCH v3] sh: sh_eth: Add support ethtool
From: David Miller @ 2011-02-22 18:10 UTC (permalink / raw)
To: nobuhiro.iwamatsu.yj
Cc: netdev, linux-sh, bhutchings, eric.dumazet, yoshihiro.shimoda.uh
In-Reply-To: <1297840652-20883-1-git-send-email-nobuhiro.iwamatsu.yj@renesas.com>
From: Nobuhiro Iwamatsu <nobuhiro.iwamatsu.yj@renesas.com>
Date: Wed, 16 Feb 2011 16:17:32 +0900
> This commit supports following functions.
> - get_settings
> - set_settings
> - nway_reset
> - get_msglevel
> - set_msglevel
> - get_link
> - get_strings
> - get_ethtool_stats
> - get_sset_count
>
> About other function, the device does not support.
>
> Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
> Signed-off-by: Nobuhiro Iwamatsu <nobuhiro.iwamatsu.yj@renesas.com>
Applied to net-next-2.6, thank you.
^ permalink raw reply
* Re: [PATCH 2/2] bridge: Use IPv6 link-local address for multicast listener queries
From: David Miller @ 2011-02-22 18:08 UTC (permalink / raw)
To: linus.luessing
Cc: shemminger, bridge, netdev, linux-kernel, herbert, yoshfuji
In-Reply-To: <1297966672-3457-3-git-send-email-linus.luessing@web.de>
From: Linus Lüssing <linus.luessing@web.de>
Date: Thu, 17 Feb 2011 19:17:52 +0100
> Currently the bridge multicast snooping feature periodically issues
> IPv6 general multicast listener queries to sense the absence of a
> listener.
>
> For this, it uses :: as its source address - however RFC 2710 requires:
> "To be valid, the Query message MUST come from a link-local IPv6 Source
> Address". Current Linux kernel versions seem to follow this requirement
> and ignore our bogus MLD queries.
>
> With this commit a link local address from the bridge interface is being
> used to issue the MLD query, resulting in other Linux devices which are
> multicast listeners in the network to respond with a MLD response (which
> was not the case before).
>
> Signed-off-by: Linus Lüssing <linus.luessing@web.de>
Applied.
^ 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