* [PATCH] b43: Clarify logged message after fatal DMA error and switch to PIO mode
From: Larry Finger @ 2010-06-19 13:29 UTC (permalink / raw)
To: John W Linville, Michael Buesch; +Cc: b43-dev, linux-wireless
The message following fatal DMA errors fails to indicate properly that the
driver has switched to PIO mode.
Signed-off-by: Larry Finger <Larry.Finger@wfinger.net>
---
Index: wireless-testing/drivers/net/wireless/b43/main.c
===================================================================
--- wireless-testing.orig/drivers/net/wireless/b43/main.c
+++ wireless-testing/drivers/net/wireless/b43/main.c
@@ -1804,7 +1804,7 @@ static void b43_do_interrupt_thread(stru
dma_reason[2], dma_reason[3],
dma_reason[4], dma_reason[5]);
b43err(dev->wl, "This device does not support DMA "
- "on your system. Please use PIO instead.\n");
+ "on your system. It will now be switched to PIO.\n");
/* Fall back to PIO transfers if we get fatal DMA errors! */
dev->use_pio = 1;
b43_controller_restart(dev, "DMA error");
^ permalink raw reply
* Re: Problems with b43 wirelesss
From: Larry Finger @ 2010-06-19 13:26 UTC (permalink / raw)
To: Magnus Therning; +Cc: Rafał Miłecki, b43-dev, wireless
In-Reply-To: <AANLkTimxOgQySTag7u4DlZugbveWr7csDSAERkewAYhp@mail.gmail.com>
On 06/19/2010 07:35 AM, Magnus Therning wrote:
> 2010/6/19 Rafał Miłecki <zajec5@gmail.com>:
>> You can Google for b43 & DMA errors. Simply try "pio" option for b43
>> module. Or switch to newer kernel, which will pick up pio for you
>> after first DMA error.
>
> Given the following messages in dmesg, I thought this was already happening:
>
> b43-phy0 ERROR: Fatal DMA error: 0x00000800, 0x00000000, 0x00000000,
> 0x00000000, 0x00000000, 0x00000000
> b43-phy0 ERROR: This device does not support DMA on your system.
> Please use PIO instead.
> b43-phy0: Controller RESET (DMA error) ...
> b43-phy0: Loading firmware version 478.104 (2008-07-01 00:50:23)
> b43-phy0: Controller restarted
>
> I'm running the 2.6.33 (latest stable is 2.6.34), but I am using the
> latest daily (2010-06-17) from compat-wireless[1], so unless I'm
> missing something there isn't much to be gained from switching to the
> latest kernel. In any case I will try it to see if that improves the
> situation.
>
> My naive reading of the messages tells me that this *isn't* a DMA
> error... I also don't really understand how I could ever get an
> initial connection, which I do, if that were the problem I'm having.
No, it is a fatal DMA error and your device did switch to PIO mode. The
dmesg output does not make that clear. I'm sending a patch to change the
logged message.
> It looks like the following is more relevant to my problem:
>
> No probe response from AP 00:22:3f:c3:99:a8 after 500ms, disconnecting.
> cfg80211: Calling CRDA to update world regulatory domain
> wlan0: authenticate with 00:22:3f:c3:99:a8 (try 1)
> wlan0: authenticated
> wlan0: associate with 00:22:3f:c3:99:a8 (try 1)
> wlan0: RX AssocResp from 00:22:3f:c3:99:a8 (capab=0x431 status=0 aid=1)
> wlan0: associated
> wlan0: deauthenticated from 00:22:3f:c3:99:a8 (Reason: 15)
>
> Especially since that sequence of messages is repeated over an over.
>
> My next test will be to turn off all security on the wireless, just to
> rule out WPA completley.
I looked for an explanation of Reason 15 deauthentications. Perhaps
someone on the wireless ML will know the answer.
Larry
^ permalink raw reply
* Re: [PATCH v2] ath5k: disable ASPM
From: Maxim Levitsky @ 2010-06-19 13:02 UTC (permalink / raw)
To: Bob Copeland
Cc: Jussi Kivilinna, ath5k-devel, linux-wireless, Luis R. Rodriguez,
linux-kernel
In-Reply-To: <20100619123841.GA31838@hash.localnet>
On Sat, 2010-06-19 at 08:38 -0400, Bob Copeland wrote:
> On Sat, Jun 19, 2010 at 10:49:34AM +0300, Maxim Levitsky wrote:
> > How this patch?
>
> Looks fine to me. Some nitpicking below but feel free to add my
>
> Acked-by: Bob Copeland <me@bobcopeland.com>
>
> to this or a later version.
>
> > Signed-off-by: Jussi Kivilinna <jussi.kivilinna@mbnet.fi>
> > Signed-off-by: Maxim Levitsky <maximlevitsky@gmail.com>
>
> I believe maintaining the s-o-b is usually reserved for the case when the
> patch only has minor edits; here your patch while same in spirit has
> some 30 fewer lines. Maybe should use "From:" or mention Jussi in the
> commit log to maintain attribution instead?
OK
>
> > + /* Disable PCIE ASPM L0S. It is never enabled by windows driver */
> > + pci_disable_link_state(pdev, PCIE_LINK_STATE_L0S);
> > +
>
> Would be good to expand this comment as to why (just copy another
> sentence from the commit log or so).
OK
>
> > ret = pci_enable_device(pdev);
> > if (ret) {
> > dev_err(&pdev->dev, "can't enable device\n");
> > @@ -722,6 +726,8 @@ static int ath5k_pci_resume(struct device *dev)
> > struct ieee80211_hw *hw = pci_get_drvdata(pdev);
> > struct ath5k_softc *sc = hw->priv;
> >
> > + pci_disable_link_state(pdev, PCIE_LINK_STATE_L0S);
> > +
>
> Did you test that it did get lost over suspend/resume? A glance at
> pci_save_pcie_state seems to indicate it's saved.
Will test.
Best regards,
Maxim Levitsky
^ permalink raw reply
* Re: [PATCH v2] ath5k: disable ASPM
From: Bob Copeland @ 2010-06-19 12:38 UTC (permalink / raw)
To: Maxim Levitsky
Cc: Jussi Kivilinna, ath5k-devel, linux-wireless, Luis R. Rodriguez,
linux-kernel
In-Reply-To: <1276933774.16697.11.camel@maxim-laptop>
On Sat, Jun 19, 2010 at 10:49:34AM +0300, Maxim Levitsky wrote:
> How this patch?
Looks fine to me. Some nitpicking below but feel free to add my
Acked-by: Bob Copeland <me@bobcopeland.com>
to this or a later version.
> Signed-off-by: Jussi Kivilinna <jussi.kivilinna@mbnet.fi>
> Signed-off-by: Maxim Levitsky <maximlevitsky@gmail.com>
I believe maintaining the s-o-b is usually reserved for the case when the
patch only has minor edits; here your patch while same in spirit has
some 30 fewer lines. Maybe should use "From:" or mention Jussi in the
commit log to maintain attribution instead?
> + /* Disable PCIE ASPM L0S. It is never enabled by windows driver */
> + pci_disable_link_state(pdev, PCIE_LINK_STATE_L0S);
> +
Would be good to expand this comment as to why (just copy another
sentence from the commit log or so).
> ret = pci_enable_device(pdev);
> if (ret) {
> dev_err(&pdev->dev, "can't enable device\n");
> @@ -722,6 +726,8 @@ static int ath5k_pci_resume(struct device *dev)
> struct ieee80211_hw *hw = pci_get_drvdata(pdev);
> struct ath5k_softc *sc = hw->priv;
>
> + pci_disable_link_state(pdev, PCIE_LINK_STATE_L0S);
> +
Did you test that it did get lost over suspend/resume? A glance at
pci_save_pcie_state seems to indicate it's saved.
--
Bob Copeland %% www.bobcopeland.com
^ permalink raw reply
* [PATCH v2] ath5k: disable ASPM
From: Maxim Levitsky @ 2010-06-19 7:49 UTC (permalink / raw)
To: Bob Copeland
Cc: Jussi Kivilinna, ath5k-devel, linux-wireless, Luis R. Rodriguez,
linux-kernel
In-Reply-To: <1276870309.23783.3.camel@maxim-laptop>
On Fri, 2010-06-18 at 17:11 +0300, Maxim Levitsky wrote:
> On Fri, 2010-06-18 at 09:59 -0400, Bob Copeland wrote:
> > On Fri, Jun 18, 2010 at 7:05 AM, Maxim Levitsky <maximlevitsky@gmail.com> wrote:
> > >> Patch I made uses GPL code from e1000e, but since ath5k is
> > >> dual-licensed so patch can't be accepted. So if I got it right, patch
> > >> has to be remade from scratch by someone who really knows about pci
> > >> registers etc. I don't, and learning this to fix something that is
> > >> already fixed in my point of view is waste of (my) time.
> > > Sure, regardless of licensing, this patch has to be redone (and e1000
> > > with it)
> >
> > At any rate, Jussi, thanks a bundle for tracking it down. I owe you a
> > beer, lots of bugs have been reported on these devices.
> >
> > Maxim, this device was always broken in the same way, right? Just
> > curious if anything made it worse recently.
>
> Always was broken, of course even with madwifi.
>
> Recently I think driver stopped doing reset on RXORN, which sometimes
> helped. This did made things a bit worse.
>
> Anyway, just disable L0S, and card works perfectly.
How this patch?
Its same patch but without open coded ASPM disabler.
Of course to work therefore you need CONFIG_PCIEASPM.
Without it, this reduces to noop.
However I asked at linux-pci, and they said that its not a bad idea to
just remove CONFIG_PCIEASPM and make it default.
I hope there won't be a silly GPL vs BSD debate over one line of code...
commit ac5de416f822917b927958b21186a82141550da7
Author: Maxim Levitsky <maximlevitsky@gmail.com>
Date: Thu Jun 17 23:21:42 2010 +0300
ath5k: disable ASPM
Atheros card on Acer Aspire One (AOA150, Atheros Communications Inc. AR5001
Wireless Network Adapter [168c:001c] (rev 01)) doesn't work well with ASPM
enabled. With ASPM ath5k will eventually stall on heavy traffic with often
'unsupported jumbo' warnings appearing. Disabling ASPM L0s in ath5k fixes
these problems.
Reproduced with pcie_aspm=force and by using 'nc < /dev/zero > /dev/null' at
both ends (usually stalls within seconds).
Signed-off-by: Jussi Kivilinna <jussi.kivilinna@mbnet.fi>
Signed-off-by: Maxim Levitsky <maximlevitsky@gmail.com>
diff --git a/drivers/net/wireless/ath/ath5k/base.c b/drivers/net/wireless/ath/ath5k/base.c
index 3abbe75..e7a189a 100644
--- a/drivers/net/wireless/ath/ath5k/base.c
+++ b/drivers/net/wireless/ath/ath5k/base.c
@@ -48,6 +48,7 @@
#include <linux/netdevice.h>
#include <linux/cache.h>
#include <linux/pci.h>
+#include <linux/pci-aspm.h>
#include <linux/ethtool.h>
#include <linux/uaccess.h>
#include <linux/slab.h>
@@ -469,6 +470,9 @@ ath5k_pci_probe(struct pci_dev *pdev,
int ret;
u8 csz;
+ /* Disable PCIE ASPM L0S. It is never enabled by windows driver */
+ pci_disable_link_state(pdev, PCIE_LINK_STATE_L0S);
+
ret = pci_enable_device(pdev);
if (ret) {
dev_err(&pdev->dev, "can't enable device\n");
@@ -722,6 +726,8 @@ static int ath5k_pci_resume(struct device *dev)
struct ieee80211_hw *hw = pci_get_drvdata(pdev);
struct ath5k_softc *sc = hw->priv;
+ pci_disable_link_state(pdev, PCIE_LINK_STATE_L0S);
+
/*
* Suspend/Resume resets the PCI configuration space, so we have to
* re-disable the RETRY_TIMEOUT register (0x41) to keep
^ permalink raw reply related
* new iwlwifi 6000 uCode available
From: Guy, Wey-Yi @ 2010-06-18 22:51 UTC (permalink / raw)
To: linux-wireless
Hi,
Version 9.221.4.1 of uCode for Intel® 6000 Series Wi-Fi Adapters is now
available for download from http://intellinuxwireless.org/?n=Downloads
Changes:
- Sync firmware with Intel 6200/6300 Wireless Windows 13.2 firmware
release
- Fixed firmware SW NMI_INTERRUP_TRM error which were occurring under
various configurations
Wey-Yi
^ permalink raw reply
* Re: [PATCH] p54usb: Drop duplicate USBID 0xcde:0x0006
From: Ozan Çağlayan @ 2010-06-18 21:20 UTC (permalink / raw)
To: John W. Linville; +Cc: linux-kernel, linux-wireless
In-Reply-To: <20100618185713.GG6282@tuxdriver.com>
John W. Linville wrote:
> On Thu, Jun 17, 2010 at 01:37:29PM +0300, Ozan Çağlayan wrote:
>> Drop the duplicate USB ID 0xcde:0x0006 which is written at two
>> different places in p54usb.c
>>
>> Signed-off-by: Ozan Çağlayan <ozan@pardus.org.tr>
>
> Someone beat you to it already...
Ah, no problem ;)
Regards,
Ozan Caglayan
^ permalink raw reply
* Re: [PATCH 4/5]pci:setup_bus.c Fix warning: variable 'retval' set but not used
From: Justin P. Mattock @ 2010-06-18 21:12 UTC (permalink / raw)
To: Jesse Barnes
Cc: Yinghai Lu, linux-kernel, linux-wireless, linux-pci, linux-scsi
In-Reply-To: <20100618134622.7db9f913@virtuousgeek.org>
On 06/18/2010 01:46 PM, Jesse Barnes wrote:
> On Fri, 18 Jun 2010 13:26:32 -0700
> "Justin P. Mattock"<justinmattock@gmail.com> wrote:
>
>> On 06/18/2010 01:05 PM, Jesse Barnes wrote:
>>> On Fri, 18 Jun 2010 12:59:32 -0700
>>> "Justin P. Mattock"<justinmattock@gmail.com> wrote:
>>>> just added this in(as a test), and the retval warning still shows up.
>>>> with the last post I just added a printk was that legit, and if so what
>>>> else might be added to it to make it complete and proper?
>>>
>>> What's the full warning? Seems like printing the value should have
>>> been enough to shut up gcc...
>>>
>>
>> this is the warning messg after applying yinghai's patch:
>>
>> CC drivers/pci/setup-bus.o
>> drivers/pci/setup-bus.c: In function
>> 'pci_assign_unassigned_bridge_resources':
>> drivers/pci/setup-bus.c:868:6: warning: variable 'retval' set but not used
>
> Right because Yinghai's patch just sets retval but doesn't actually use
> it anywhere.
>
that's what is confusing..(not being used, but is being used, but gcc
says it's not used..) :-)
>> if I add a printk then gcc is content.. patch below, but not the best at
>> creating printk's(the whole % thing messes me up) but here goes:
>>
>> From 48e15b87072c6b4286d943c55bfe2ae26d358795 Mon Sep 17 00:00:00 2001
>> From: Justin P. Mattock<justinmattock@gmail.com>
>> Date: Fri, 18 Jun 2010 13:23:27 -0700
>> Subject: [PATCH 4/4] bus.c_add_print
>> Signed-off-by: Justin P. Mattock<justinmattock@gmail.com>
>>
>> ---
>> drivers/pci/setup-bus.c | 1 +
>> 1 files changed, 1 insertions(+), 0 deletions(-)
>>
>> diff --git a/drivers/pci/setup-bus.c b/drivers/pci/setup-bus.c
>> index 66cb8f4..806b766 100644
>> --- a/drivers/pci/setup-bus.c
>> +++ b/drivers/pci/setup-bus.c
>> @@ -919,6 +919,7 @@ again:
>>
>> enable_all:
>> retval = pci_reenable_device(bridge);
>> + printk(KERN_DEBUG "PCI%d: re-enabling device\n", retval);
>> pci_set_master(bridge);
>> pci_enable_bridges(parent);
>> }
>
> Again, this doesn't have the if (retval) condition around the printk; I
> don't want to see this message everytime regardless. Also the message
> is misleading, it should be something like:
> dev_err(&bridge->dev, "failed to re-enable device: %d\n", retval)
> instead. PCI%d makes it look like we're talking about a specific bus
> or something and not an error code.
>
o.k. I admit I looked at other printk's in this file to get an idea of
what I might do.. saw PCI%d and figured it would print
"PCI: re-enabling device"
but didnt think it was an error... reason for putting KERN_DEBUG.
here is what the new patch looks like:
From f910375438be06497d0524bff146c26cafca272b Mon Sep 17 00:00:00 2001
From: Justin P. Mattock <justinmattock@gmail.com>
Date: Fri, 18 Jun 2010 14:08:37 -0700
Subject: [PATCH 4/4] setup-pci_test
Signed-off-by: Justin P. Mattock <justinmattock@gmail.com>
---
drivers/pci/setup-bus.c | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/drivers/pci/setup-bus.c b/drivers/pci/setup-bus.c
index 66cb8f4..2ab5f1e 100644
--- a/drivers/pci/setup-bus.c
+++ b/drivers/pci/setup-bus.c
@@ -919,6 +919,9 @@ again:
enable_all:
retval = pci_reenable_device(bridge);
+ if (retval) {
+ dev_err(&bridge->dev, "failed to re-enable device: %d\n", retval);
+ }
pci_set_master(bridge);
pci_enable_bridges(parent);
}
--
1.7.1.rc1.21.gf3bd6
should I have put if (!retval) instead
should I put "failed to re-enable bridge device"
is there an exit code needed?
if not and all is good then I can resend this out..
Justin P. Mattock
^ permalink raw reply related
* Re: [PATCH 4/5]pci:setup_bus.c Fix warning: variable 'retval' set but not used
From: Jesse Barnes @ 2010-06-18 20:46 UTC (permalink / raw)
To: Justin P. Mattock
Cc: Yinghai Lu, linux-kernel, linux-wireless, linux-pci, linux-scsi
In-Reply-To: <4C1BD678.1020405@gmail.com>
On Fri, 18 Jun 2010 13:26:32 -0700
"Justin P. Mattock" <justinmattock@gmail.com> wrote:
> On 06/18/2010 01:05 PM, Jesse Barnes wrote:
> > On Fri, 18 Jun 2010 12:59:32 -0700
> > "Justin P. Mattock"<justinmattock@gmail.com> wrote:
> >> just added this in(as a test), and the retval warning still shows up.
> >> with the last post I just added a printk was that legit, and if so what
> >> else might be added to it to make it complete and proper?
> >
> > What's the full warning? Seems like printing the value should have
> > been enough to shut up gcc...
> >
>
> this is the warning messg after applying yinghai's patch:
>
> CC drivers/pci/setup-bus.o
> drivers/pci/setup-bus.c: In function
> 'pci_assign_unassigned_bridge_resources':
> drivers/pci/setup-bus.c:868:6: warning: variable 'retval' set but not used
Right because Yinghai's patch just sets retval but doesn't actually use
it anywhere.
> if I add a printk then gcc is content.. patch below, but not the best at
> creating printk's(the whole % thing messes me up) but here goes:
>
> From 48e15b87072c6b4286d943c55bfe2ae26d358795 Mon Sep 17 00:00:00 2001
> From: Justin P. Mattock <justinmattock@gmail.com>
> Date: Fri, 18 Jun 2010 13:23:27 -0700
> Subject: [PATCH 4/4] bus.c_add_print
> Signed-off-by: Justin P. Mattock <justinmattock@gmail.com>
>
> ---
> drivers/pci/setup-bus.c | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/pci/setup-bus.c b/drivers/pci/setup-bus.c
> index 66cb8f4..806b766 100644
> --- a/drivers/pci/setup-bus.c
> +++ b/drivers/pci/setup-bus.c
> @@ -919,6 +919,7 @@ again:
>
> enable_all:
> retval = pci_reenable_device(bridge);
> + printk(KERN_DEBUG "PCI%d: re-enabling device\n", retval);
> pci_set_master(bridge);
> pci_enable_bridges(parent);
> }
Again, this doesn't have the if (retval) condition around the printk; I
don't want to see this message everytime regardless. Also the message
is misleading, it should be something like:
dev_err(&bridge->dev, "failed to re-enable device: %d\n", retval)
instead. PCI%d makes it look like we're talking about a specific bus
or something and not an error code.
--
Jesse Barnes, Intel Open Source Technology Center
^ permalink raw reply
* Re: [PATCH 4/5]pci:setup_bus.c Fix warning: variable 'retval' set but not used
From: Justin P. Mattock @ 2010-06-18 20:26 UTC (permalink / raw)
To: Jesse Barnes
Cc: Yinghai Lu, linux-kernel, linux-wireless, linux-pci, linux-scsi
In-Reply-To: <20100618130538.0fc562ee@virtuousgeek.org>
On 06/18/2010 01:05 PM, Jesse Barnes wrote:
> On Fri, 18 Jun 2010 12:59:32 -0700
> "Justin P. Mattock"<justinmattock@gmail.com> wrote:
>> just added this in(as a test), and the retval warning still shows up.
>> with the last post I just added a printk was that legit, and if so what
>> else might be added to it to make it complete and proper?
>
> What's the full warning? Seems like printing the value should have
> been enough to shut up gcc...
>
this is the warning messg after applying yinghai's patch:
CC drivers/pci/setup-bus.o
drivers/pci/setup-bus.c: In function
'pci_assign_unassigned_bridge_resources':
drivers/pci/setup-bus.c:868:6: warning: variable 'retval' set but not used
if I add a printk then gcc is content.. patch below, but not the best at
creating printk's(the whole % thing messes me up) but here goes:
From 48e15b87072c6b4286d943c55bfe2ae26d358795 Mon Sep 17 00:00:00 2001
From: Justin P. Mattock <justinmattock@gmail.com>
Date: Fri, 18 Jun 2010 13:23:27 -0700
Subject: [PATCH 4/4] bus.c_add_print
Signed-off-by: Justin P. Mattock <justinmattock@gmail.com>
---
drivers/pci/setup-bus.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/pci/setup-bus.c b/drivers/pci/setup-bus.c
index 66cb8f4..806b766 100644
--- a/drivers/pci/setup-bus.c
+++ b/drivers/pci/setup-bus.c
@@ -919,6 +919,7 @@ again:
enable_all:
retval = pci_reenable_device(bridge);
+ printk(KERN_DEBUG "PCI%d: re-enabling device\n", retval);
pci_set_master(bridge);
pci_enable_bridges(parent);
}
--
1.7.1.rc1.21.gf3bd6
^ permalink raw reply related
* Re: [PATCH 5/5]scsi:hosts.c Fix warning: variable 'rval' set but not used
From: Justin P. Mattock @ 2010-06-18 20:17 UTC (permalink / raw)
To: James Bottomley; +Cc: linux-kernel, linux-wireless, linux-pci, linux-scsi
In-Reply-To: <1276889827.2850.331.camel@mulgrave.site>
Thanks for the help, and info on this..I just tested and sent out the
patch let me know if it's legit or not..
Justin P. Mattock
^ permalink raw reply
* Re: [PATCH 4/5]pci:setup_bus.c Fix warning: variable 'retval' set but not used
From: Jesse Barnes @ 2010-06-18 20:05 UTC (permalink / raw)
To: Justin P. Mattock
Cc: Yinghai Lu, linux-kernel, linux-wireless, linux-pci, linux-scsi
In-Reply-To: <4C1BD024.1030707@gmail.com>
On Fri, 18 Jun 2010 12:59:32 -0700
"Justin P. Mattock" <justinmattock@gmail.com> wrote:
> just added this in(as a test), and the retval warning still shows up.
> with the last post I just added a printk was that legit, and if so what
> else might be added to it to make it complete and proper?
What's the full warning? Seems like printing the value should have
been enough to shut up gcc...
--
Jesse Barnes, Intel Open Source Technology Center
^ permalink raw reply
* Re: [PATCH 4/5]pci:setup_bus.c Fix warning: variable 'retval' set but not used
From: Justin P. Mattock @ 2010-06-18 19:59 UTC (permalink / raw)
To: Jesse Barnes
Cc: Yinghai Lu, linux-kernel, linux-wireless, linux-pci, linux-scsi
In-Reply-To: <20100618124956.40c869a0@virtuousgeek.org>
On 06/18/2010 12:49 PM, Jesse Barnes wrote:
> On Fri, 18 Jun 2010 11:48:29 -0700
> Yinghai Lu<yinghai@kernel.org> wrote:
>
>> On 06/18/2010 10:23 AM, Jesse Barnes wrote:
>>> On Tue, 15 Jun 2010 22:33:53 -0700
>>> "Justin P. Mattock"<justinmattock@gmail.com> wrote:
>>>
>>>> The below patch fixes a warning message when using gcc 4.6.0
>>>> CC drivers/pci/setup-bus.o
>>>> drivers/pci/setup-bus.c: In function 'pci_assign_unassigned_bridge_resources':
>>>> drivers/pci/setup-bus.c:868:6: warning: variable 'retval' set but not used
>>>>
>>>> Signed-off-by: Justin P. Mattock<justinmattock@gmail.com>
>>>>
>>>> ---
>>>> drivers/pci/setup-bus.c | 2 --
>>>> 1 files changed, 0 insertions(+), 2 deletions(-)
>>>>
>>>> diff --git a/drivers/pci/setup-bus.c b/drivers/pci/setup-bus.c
>>>> index 19b1113..215590b 100644
>>>> --- a/drivers/pci/setup-bus.c
>>>> +++ b/drivers/pci/setup-bus.c
>>>> @@ -865,7 +865,6 @@ void pci_assign_unassigned_bridge_resources(struct pci_dev *bridge)
>>>> struct pci_bus *parent = bridge->subordinate;
>>>> int tried_times = 0;
>>>> struct resource_list_x head, *list;
>>>> - int retval;
>>>> unsigned long type_mask = IORESOURCE_IO | IORESOURCE_MEM |
>>>> IORESOURCE_PREFETCH;
>>>>
>>>> @@ -874,7 +873,6 @@ void pci_assign_unassigned_bridge_resources(struct pci_dev *bridge)
>>>> again:
>>>> pci_bus_size_bridges(parent);
>>>> __pci_bridge_assign_resources(bridge,&head);
>>>> - retval = pci_reenable_device(bridge);
>>>> pci_set_master(bridge);
>>>> pci_enable_bridges(parent);
>>>>
>>
>> I sent following patch several weeks ago, can you put that in pci-next?
>>
>> Subject: [PATCH] pciehp: Enable bridges at last for multiple try assigning
>>
>> Found one PCIe Module with several bridges "cold" hotadd doesn't work.
>>
>> the root cause:
>> 1. BIOS assign small range the parent bridges.
>> 2. First try for hotadd only can make some bridges get resource assigned.
>> 3. Second will update parent bridge res, get right sizes for all child bridges
>> and devices, but resource for child bridges are not set to HW register.
>> Because first try already enable those bridges, so __pci_bridge_assign_resource
>> skip the setting step.
>>
>> So try to move enabling of child bridges to last and only do that one time
>>
>> Signed-off-by: Yinghai Lu<yinghai@kernel.org>
>
> Yeah I had a hard time following the changelog, but just looked it
> over. Looks safe, but Justin will still need to check the return value
> on pci_reenable_device.
>
> Justin, we don't want a message on every reenable, just on ones that
> fail. So can you protect your printk with if (retval) instead? You'll
> need to refresh it based on my linux-next branch in a few minutes, as
> I'm pushing Yinghai's patch now.
>
just added this in(as a test), and the retval warning still shows up.
with the last post I just added a printk was that legit, and if so what
else might be added to it to make it complete and proper?
Justin P. Mattock
^ permalink raw reply
* Re: [PATCH 5/5]scsi:hosts.c Fix warning: variable 'rval' set but not used
From: Justin P. Mattock @ 2010-06-18 19:55 UTC (permalink / raw)
To: James Bottomley; +Cc: linux-kernel, linux-wireless, linux-pci, linux-scsi
In-Reply-To: <1276889827.2850.331.camel@mulgrave.site>
On 06/18/2010 12:37 PM, James Bottomley wrote:
> On Thu, 2010-06-17 at 09:16 -0700, Justin P. Mattock wrote:
>>> Erm, well, as I said, error code and the fact that the thread failed to
>>> start, so more
>>>
>>> printk(KERN_WARNING "scsi%d: error handler thread failed to spawn, error
>>> = %d\n", host->host_no, PTR_ERR(shost->ehandler));
>>>
>>> James
>>>
>>
>> o.k. I looked at this a bit more and finally got the thing to build
>> through without a warning, using what you had sent, but keep in mind I
>> still need to add error = %d\n", host->host_no, to the printk
>>
>> here's what I have so far:
>>
>>
>> drivers/scsi/hosts.c | 3 ++-
>> 1 files changed, 2 insertions(+), 1 deletions(-)
>>
>> diff --git a/drivers/scsi/hosts.c b/drivers/scsi/hosts.c
>> index 6660fa9..c1ff708 100644
>> --- a/drivers/scsi/hosts.c
>> +++ b/drivers/scsi/hosts.c
>> @@ -419,8 +419,9 @@ struct Scsi_Host *scsi_host_alloc(struct
>> scsi_host_template *sht, int privsize)
>>
>> shost->ehandler = kthread_run(scsi_error_handler, shost,
>> "scsi_eh_%d", shost->host_no);
>> + rval = PTR_ERR(shost->ehandler);
>> if (IS_ERR(shost->ehandler)) {
>> - rval = PTR_ERR(shost->ehandler);
>> + printk(KERN_WARNING "scsi%d: error handler thread failed to spawn\n",
>> rval);
>
> So this isn't really an improvement over the suggestion. What you
> wanted was shost->host_no, as you deduced, but the %d becomes %ld to
> quiet the type warning.
>
> James
ahh.. was reading the manual but couldn't make sense of the % then
letter to use.
let me add these in, then if good I'll send it out for review etc..
Justin P. Mattock
^ permalink raw reply
* Re: [PATCH 4/5]pci:setup_bus.c Fix warning: variable 'retval' set but not used
From: Jesse Barnes @ 2010-06-18 19:49 UTC (permalink / raw)
To: Yinghai Lu
Cc: Justin P. Mattock, linux-kernel, linux-wireless, linux-pci,
linux-scsi
In-Reply-To: <4C1BBF7D.8090904@kernel.org>
On Fri, 18 Jun 2010 11:48:29 -0700
Yinghai Lu <yinghai@kernel.org> wrote:
> On 06/18/2010 10:23 AM, Jesse Barnes wrote:
> > On Tue, 15 Jun 2010 22:33:53 -0700
> > "Justin P. Mattock" <justinmattock@gmail.com> wrote:
> >
> >> The below patch fixes a warning message when using gcc 4.6.0
> >> CC drivers/pci/setup-bus.o
> >> drivers/pci/setup-bus.c: In function 'pci_assign_unassigned_bridge_resources':
> >> drivers/pci/setup-bus.c:868:6: warning: variable 'retval' set but not used
> >>
> >> Signed-off-by: Justin P. Mattock <justinmattock@gmail.com>
> >>
> >> ---
> >> drivers/pci/setup-bus.c | 2 --
> >> 1 files changed, 0 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/drivers/pci/setup-bus.c b/drivers/pci/setup-bus.c
> >> index 19b1113..215590b 100644
> >> --- a/drivers/pci/setup-bus.c
> >> +++ b/drivers/pci/setup-bus.c
> >> @@ -865,7 +865,6 @@ void pci_assign_unassigned_bridge_resources(struct pci_dev *bridge)
> >> struct pci_bus *parent = bridge->subordinate;
> >> int tried_times = 0;
> >> struct resource_list_x head, *list;
> >> - int retval;
> >> unsigned long type_mask = IORESOURCE_IO | IORESOURCE_MEM |
> >> IORESOURCE_PREFETCH;
> >>
> >> @@ -874,7 +873,6 @@ void pci_assign_unassigned_bridge_resources(struct pci_dev *bridge)
> >> again:
> >> pci_bus_size_bridges(parent);
> >> __pci_bridge_assign_resources(bridge, &head);
> >> - retval = pci_reenable_device(bridge);
> >> pci_set_master(bridge);
> >> pci_enable_bridges(parent);
> >>
>
> I sent following patch several weeks ago, can you put that in pci-next?
>
> Subject: [PATCH] pciehp: Enable bridges at last for multiple try assigning
>
> Found one PCIe Module with several bridges "cold" hotadd doesn't work.
>
> the root cause:
> 1. BIOS assign small range the parent bridges.
> 2. First try for hotadd only can make some bridges get resource assigned.
> 3. Second will update parent bridge res, get right sizes for all child bridges
> and devices, but resource for child bridges are not set to HW register.
> Because first try already enable those bridges, so __pci_bridge_assign_resource
> skip the setting step.
>
> So try to move enabling of child bridges to last and only do that one time
>
> Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Yeah I had a hard time following the changelog, but just looked it
over. Looks safe, but Justin will still need to check the return value
on pci_reenable_device.
Justin, we don't want a message on every reenable, just on ones that
fail. So can you protect your printk with if (retval) instead? You'll
need to refresh it based on my linux-next branch in a few minutes, as
I'm pushing Yinghai's patch now.
--
Jesse Barnes, Intel Open Source Technology Center
^ permalink raw reply
* Re: [PATCH 5/5]scsi:hosts.c Fix warning: variable 'rval' set but not used
From: James Bottomley @ 2010-06-18 19:37 UTC (permalink / raw)
To: Justin P. Mattock; +Cc: linux-kernel, linux-wireless, linux-pci, linux-scsi
In-Reply-To: <4C1A4A69.7060801@gmail.com>
On Thu, 2010-06-17 at 09:16 -0700, Justin P. Mattock wrote:
> > Erm, well, as I said, error code and the fact that the thread failed to
> > start, so more
> >
> > printk(KERN_WARNING "scsi%d: error handler thread failed to spawn, error
> > = %d\n", host->host_no, PTR_ERR(shost->ehandler));
> >
> > James
> >
>
> o.k. I looked at this a bit more and finally got the thing to build
> through without a warning, using what you had sent, but keep in mind I
> still need to add error = %d\n", host->host_no, to the printk
>
> here's what I have so far:
>
>
> drivers/scsi/hosts.c | 3 ++-
> 1 files changed, 2 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/scsi/hosts.c b/drivers/scsi/hosts.c
> index 6660fa9..c1ff708 100644
> --- a/drivers/scsi/hosts.c
> +++ b/drivers/scsi/hosts.c
> @@ -419,8 +419,9 @@ struct Scsi_Host *scsi_host_alloc(struct
> scsi_host_template *sht, int privsize)
>
> shost->ehandler = kthread_run(scsi_error_handler, shost,
> "scsi_eh_%d", shost->host_no);
> + rval = PTR_ERR(shost->ehandler);
> if (IS_ERR(shost->ehandler)) {
> - rval = PTR_ERR(shost->ehandler);
> + printk(KERN_WARNING "scsi%d: error handler thread failed to spawn\n",
> rval);
So this isn't really an improvement over the suggestion. What you
wanted was shost->host_no, as you deduced, but the %d becomes %ld to
quiet the type warning.
James
^ permalink raw reply
* Re: [PATCHv3] mac80211: Add interface for driver to temporarily disable dynamic ps
From: John W. Linville @ 2010-06-18 19:12 UTC (permalink / raw)
To: Juuso Oikarinen; +Cc: linux-wireless
In-Reply-To: <1276753353-30310-1-git-send-email-juuso.oikarinen@nokia.com>
On Thu, Jun 17, 2010 at 08:42:33AM +0300, Juuso Oikarinen wrote:
> This mechanism introduced in this patch applies (at least) for hardware
> designs using a single shared antenna for both WLAN and BT. In these designs,
> the antenna must be toggled between WLAN and BT.
>
> In those hardware, managing WLAN co-existence with Bluetooth requires WLAN
> full power save whenever there is Bluetooth activity in order for WLAN to be
> able to periodically relinquish the antenna to be used for BT. This is because
> BT can only access the shared antenna when WLAN is idle or asleep.
>
> Some hardware, for instance the wl1271, are able to indicate to the host
> whenever there is BT traffic. In essence, the hardware will send an indication
> to the host whenever there is, for example, SCO traffic or A2DP traffic, and
> will send another indication when the traffic is over.
>
> The hardware gets information of Bluetooth traffic via hardware co-existence
> control lines - these lines are used to negotiate the shared antenna
> ownership. The hardware will give the antenna to BT whenever WLAN is sleeping.
>
> This patch adds the interface to mac80211 to facilitate temporarily disabling
> of dynamic power save as per request of the WLAN driver. This interface will
> immediately force WLAN to full powersave, hence allowing BT coexistence as
> described above.
>
> In these kind of shared antenna desings, when WLAN powersave is fully disabled,
> Bluetooth will not work simultaneously with WLAN at all. This patch does not
> address that problem. This interface will not change PSM state, so if PSM is
> disabled it will remain so. Solving this problem requires knowledge about BT
> state, and is best done in user-space.
>
> Signed-off-by: Juuso Oikarinen <juuso.oikarinen@nokia.com>
> ---
> v3: separate ieee80211_dyn_ps_enable/ieee80211_dyn_ps_enable functions
CC [M] net/mac80211/mlme.o
net/mac80211/mlme.c: In function ‘ieee80211_recalc_ps’:
net/mac80211/mlme.c:598: error: ‘struct ieee80211_conf’ has no member named ‘dynamic_ps_forced_timeout’
make[1]: *** [net/mac80211/mlme.o] Error 1
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
* Compat-wireless release for 2010-06-18 is baked
From: Compat-wireless cronjob account @ 2010-06-18 19:03 UTC (permalink / raw)
To: linux-wireless, linux-bluetooth
>From git://git.kernel.org/pub/scm/linux/kernel/git/mcgrof/compat-wireless-2.6
11542b5..75bb510 master -> origin/master
d584ab0..3eaa500 wl -> origin/wl
>From git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next
67eac11..49bc196 history -> origin/history
+ 8668718...d568ec36 master -> origin/master (forced update)
* [new tag] next-20100618 -> next-20100618
compat-wireless code metrics
498472 - Total upstream lines of code being pulled
1410 - backport code changes
1177 - backport code additions
233 - backport code deletions
5748 - backport from compat module
7158 - total backport code
1.4360 - % of code consists of backport work
1218 - Crap changes not yet posted
1179 - Crap additions not yet merged
39 - Crap deletions not yet posted
0.2443 - % of crap code
Base tree: linux-next.git
Base tree version: next-20100618
compat-wireless release: compat-wireless-2010-06-17-1-g75bb510
^ permalink raw reply
* Re: [PATCH] p54usb: Drop duplicate USBID 0xcde:0x0006
From: John W. Linville @ 2010-06-18 18:57 UTC (permalink / raw)
To: Ozan Çağlayan; +Cc: linux-kernel, linux-wireless, flamingice
In-Reply-To: <1276771049-2187-1-git-send-email-ozan@pardus.org.tr>
On Thu, Jun 17, 2010 at 01:37:29PM +0300, Ozan Çağlayan wrote:
> Drop the duplicate USB ID 0xcde:0x0006 which is written at two
> different places in p54usb.c
>
> Signed-off-by: Ozan Çağlayan <ozan@pardus.org.tr>
Someone beat you to it already...
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
* Re: [PATCH 1/2] wireless-regdb: Update the regulatory domain for a few countries.
From: John W. Linville @ 2010-06-18 18:56 UTC (permalink / raw)
To: Vivek Natarajan; +Cc: linux-wireless
In-Reply-To: <1276768074-4366-2-git-send-email-vnatarajan@atheros.com>
On Thu, Jun 17, 2010 at 03:17:53PM +0530, Vivek Natarajan wrote:
> Add Bangladesh(BD) with NULL1_WORLD.
> Add Kenya(KE) with APL1_WORLD.
> Change Honduras(HN) to FCC3_WORLD.
> Change Lebanon(LB) to APL1_WORLD,
> Change Macedonia(MK) to ETSI1_WORLD.
> Change Pakistan(PK) to APL1_WORLD.
> Change Romania(RO) to ETSI1_WORLD.
> Change Russia(RU) to FCC3_WORLD.
> Change Saudi Arabia(SA) to FCC2_WORLD.
> Change UAE(AE) to ETSI1_WORLD.
> Change Venezuela(VE) to FCC1_WORLD.
> Change Vietnam(VN) to ETSI3_WORLD.
>
> Signed-off-by: Vivek Natarajan <vnatarajan@atheros.com>
It would be nice to have some reference for these changes...
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
* Re: [PATCH 2/2] wireless-regdb: Enable 40MHz operation for some countries.
From: John W. Linville @ 2010-06-18 18:56 UTC (permalink / raw)
To: Vivek Natarajan; +Cc: linux-wireless
In-Reply-To: <1276768074-4366-3-git-send-email-vnatarajan@atheros.com>
On Thu, Jun 17, 2010 at 03:17:54PM +0530, Vivek Natarajan wrote:
> Enable 40MHz operation for Argentina, Brazil, Colombia, Algeria,
> India, Malaysia, Peru and South Africa.
>
> Signed-off-by: Vivek Natarajan <vnatarajan@atheros.com>
These too...
--
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: [PATCH 4/5]pci:setup_bus.c Fix warning: variable 'retval' set but not used
From: Yinghai Lu @ 2010-06-18 18:48 UTC (permalink / raw)
To: Jesse Barnes
Cc: Justin P. Mattock, linux-kernel, linux-wireless, linux-pci,
linux-scsi
In-Reply-To: <20100618102330.29eccb5b@virtuousgeek.org>
On 06/18/2010 10:23 AM, Jesse Barnes wrote:
> On Tue, 15 Jun 2010 22:33:53 -0700
> "Justin P. Mattock" <justinmattock@gmail.com> wrote:
>
>> The below patch fixes a warning message when using gcc 4.6.0
>> CC drivers/pci/setup-bus.o
>> drivers/pci/setup-bus.c: In function 'pci_assign_unassigned_bridge_resources':
>> drivers/pci/setup-bus.c:868:6: warning: variable 'retval' set but not used
>>
>> Signed-off-by: Justin P. Mattock <justinmattock@gmail.com>
>>
>> ---
>> drivers/pci/setup-bus.c | 2 --
>> 1 files changed, 0 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/pci/setup-bus.c b/drivers/pci/setup-bus.c
>> index 19b1113..215590b 100644
>> --- a/drivers/pci/setup-bus.c
>> +++ b/drivers/pci/setup-bus.c
>> @@ -865,7 +865,6 @@ void pci_assign_unassigned_bridge_resources(struct pci_dev *bridge)
>> struct pci_bus *parent = bridge->subordinate;
>> int tried_times = 0;
>> struct resource_list_x head, *list;
>> - int retval;
>> unsigned long type_mask = IORESOURCE_IO | IORESOURCE_MEM |
>> IORESOURCE_PREFETCH;
>>
>> @@ -874,7 +873,6 @@ void pci_assign_unassigned_bridge_resources(struct pci_dev *bridge)
>> again:
>> pci_bus_size_bridges(parent);
>> __pci_bridge_assign_resources(bridge, &head);
>> - retval = pci_reenable_device(bridge);
>> pci_set_master(bridge);
>> pci_enable_bridges(parent);
>>
I sent following patch several weeks ago, can you put that in pci-next?
Subject: [PATCH] pciehp: Enable bridges at last for multiple try assigning
Found one PCIe Module with several bridges "cold" hotadd doesn't work.
the root cause:
1. BIOS assign small range the parent bridges.
2. First try for hotadd only can make some bridges get resource assigned.
3. Second will update parent bridge res, get right sizes for all child bridges
and devices, but resource for child bridges are not set to HW register.
Because first try already enable those bridges, so __pci_bridge_assign_resource
skip the setting step.
So try to move enabling of child bridges to last and only do that one time
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
---
drivers/pci/setup-bus.c | 12 +++++++-----
1 file changed, 7 insertions(+), 5 deletions(-)
Index: linux-2.6/drivers/pci/setup-bus.c
===================================================================
--- linux-2.6.orig/drivers/pci/setup-bus.c
+++ linux-2.6/drivers/pci/setup-bus.c
@@ -866,19 +866,16 @@ void pci_assign_unassigned_bridge_resour
again:
pci_bus_size_bridges(parent);
__pci_bridge_assign_resources(bridge, &head);
- retval = pci_reenable_device(bridge);
- pci_set_master(bridge);
- pci_enable_bridges(parent);
tried_times++;
if (!head.next)
- return;
+ goto enable_all;
if (tried_times >= 2) {
/* still fail, don't need to try more */
free_failed_list(&head);
- return;
+ goto enable_all;
}
printk(KERN_DEBUG "PCI: No. %d try to assign unassigned res\n",
@@ -911,5 +908,10 @@ again:
free_failed_list(&head);
goto again;
+
+enable_all:
+ retval = pci_reenable_device(bridge);
+ pci_set_master(bridge);
+ pci_enable_bridges(parent);
}
EXPORT_SYMBOL_GPL(pci_assign_unassigned_bridge_resources);
^ permalink raw reply
* Re: WLAN Regulatory Domain Germany
From: John W. Linville @ 2010-06-18 18:44 UTC (permalink / raw)
To: Kurt Garloff; +Cc: Johannes Berg, linux-wireless, Luis R. Rodriguez
In-Reply-To: <20100525151429.GC6342@tpkurt2.garloff.de>
On Tue, May 25, 2010 at 05:14:29PM +0200, Kurt Garloff wrote:
> OK, new suggestion.
>
> 8<------------------------------------------------------------------------
>
> # Data from "Frequenznutzungsplan" (as published in April 2008), downloaded from
> # http://www.bundesnetzagentur.de/cae/servlet/contentblob/38448/publicationFile/2659/Frequenznutzungsplan2008_Id17448pdf.pdf
> # For the 5GHz range also see
> # http://www.bundesnetzagentur.de/cae/servlet/contentblob/38216/publicationFile/6579/WLAN5GHzVfg7_2010_28042010pdf.pdf
> # The values have been reduced by a factor of 2 (3db) for non TPC devices
> # (in other words: devices with TPC can use twice the tx power of this table).
> # Note that the docs do not require TPC for 5150--5250; the reduction to
> # 100mW thus is not strictly required -- however the conservative 100mW
> # limit is used here as the non-interference with radar and satellite
> # apps relies on the attenuation by the building walls only in the
> # absence of DFS; the neighbour countries have 100mW limit here as well.
>
> country DE:
> # entries 279004 and 280006
> (2400 - 2483.5 @ 40), (N/A, 100 mW)
> # entry 303005
> (5150 - 5250 @ 40), (N/A, 100 mW), NO-OUTDOOR
> # entries 304002 and 305002
> (5250 - 5350 @ 40), (N/A, 100 mW), NO-OUTDOOR, DFS
> # entries 308002, 309001 and 310003
> (5470 - 5725 @ 40), (N/A, 500 mW), DFS
>
> 8<------------------------------------------------------------------------
Is this what we want? Are you going to submit an actual patch?
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
* Re: [RFC] wireless-regdb: Add A band in IL
From: John W. Linville @ 2010-06-18 18:42 UTC (permalink / raw)
To: Emmanuel Grumbach; +Cc: linux-wireless, Michael Green, David Quan
In-Reply-To: <1274856569-13436-1-git-send-email-emmanuel.grumbach@intel.com>
On Wed, May 26, 2010 at 09:49:29AM +0300, Emmanuel Grumbach wrote:
> A band in allowed in IL, according to official document issued by the Ministry
> of Communications: http://www.moc.gov.il/sip_storage/FILES/1/1061.pdf.
>
> 5150 - 5250 200mW e.i.r.p. OUTDOOR forbidden
> 5250 - 5350 200mW e.i.r.p. OUTDOOR forbidden DFS mandatory
>
> 40Mhz is allowed in A band for every WiFi-Alliance certified equipment.
>
> ***************************************************************
> Not to be merged for the moment
> ***************************************************************
>
> CC: Michael Green <Michael.Green@atheros.com>
> CC: David Quan <David.Quan@atheros.com>
> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
> ---
> db.txt | 2 ++
> 1 files changed, 2 insertions(+), 0 deletions(-)
>
> diff --git a/db.txt b/db.txt
> index e63a43e..d49c397 100644
> --- a/db.txt
> +++ b/db.txt
> @@ -319,6 +319,8 @@ country IE:
>
> country IL:
> (2402 - 2482 @ 40), (N/A, 20)
> + (5150 - 5250 @ 40). (N/A, 200 mW), NO-OUTDOOR
> + (5250 - 5350 @ 40). (N/A, 200 mW), NO-OUTDOOR, DFS
>
> country IN:
> (2402 - 2482 @ 40), (N/A, 20)
Is this issue now settled?
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
* Re: wireless-regdb: FI/CZ updates
From: John W. Linville @ 2010-06-18 18:43 UTC (permalink / raw)
To: Pekka Pietikainen
Cc: Luis R. Rodriguez, Michael Green, David Quan, linux-wireless
In-Reply-To: <20100528124258.GA27491@ee.oulu.fi>
On Fri, May 28, 2010 at 03:42:58PM +0300, Pekka Pietikainen wrote:
> On Wed, May 26, 2010 at 11:30:37AM -0700, Luis R. Rodriguez wrote:
> > Pekka, please remove these changes from this patch, you want to make
> > your patches atomic, with only one purpose to help the review process
> > easier. You stashed changes to CZ & FI on one... You also switched
> > from dBm to mW and note how you actually did change the EIRP here for
> > only one for FI. Please provide a separate set of patches for that for
> > FI. If you want to switch to mW for all of the entries for FI first do
> > that, and then on a separate patch make the actual regulatory changes
> > so this is crystal clear for the review process.
> Okie
>
> Looking at it a bit more probably makes sense to codify the current
> harmonized EU rules, and then just for each country note that they've
> actually implemented it in their local legislation (I checked FI, SE and
> CZ). Everyone should have, but some are pretty slow at this, or
> have some special national interests...
>
> The legislation uses mW, so that's the reason I switched them.
>
> For review (first hit on google for the decision number
> should find the official text), I can do patches once someone
> has verified, that this is what the legalese actually says:
>
> # EU Commission Decision 2009/381/EC
> (2400 - 2483.5 @ 40), (N/A, 100mW)
> # 2005/513/EC and 2007/90/EC, 5250 and 5470 can be doubled if TPC is in use
> (5150 - 5250 @ 40), (N/A, 200mW), NO-OUTDOOR
> (5250 - 5350 @ 40), (N/A, 100mW), NO-OUTDOOR, DFS
> (5470 - 5725 @ 40), (N/A, 500mW), DFS
Ping?
--
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
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