* Re: compat-wireless and minstrel
From: Christian Lamparter @ 2009-11-04 22:31 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: Luis R. Rodriguez, Adam Wozniak, linux-wireless
In-Reply-To: <20091104222007.GB2599@bombadil.infradead.org>
On Wednesday 04 November 2009 23:20:07 Luis R. Rodriguez wrote:
> On Wed, Nov 04, 2009 at 11:18:13PM +0100, Christian Lamparter wrote:
> > On Wednesday 04 November 2009 22:50:46 Luis R. Rodriguez wrote:
> > > On Wed, Nov 4, 2009 at 1:46 PM, Adam Wozniak <awozniak@irobot.com> wrote:
> > > >
> > > > $ ls -la /lib/firmware/ar9170*
> > > > -rw-r--r-- 1 root root 83968 2009-10-17 15:55 /lib/firmware/ar9170-1.fw
> > > > -rw-r--r-- 1 root root 3508 2009-10-17 15:55 /lib/firmware/ar9170-2.fw
> > > > -rw-r--r-- 1 root root 15960 2009-10-17 15:55 /lib/firmware/ar9170.fw
> > > >
> > > > It is unclear to me which are actually used.
> > >
> > > By default the ar9170.fw is tried first, if that fails then the others
> > > are tried. The 2-stage firmware will not be tried if your device
> > > cannot handle it but right now only the AVM Fritz devices can't handle
> > > the 2-stage firmware.
> > >
> > > Christian should we just remove 2-stage fw support?
> >
> > I've moved the two-stage fw into the legacy section some time ago :)
> > Maybe a add printk?
>
> Oh sorry didn't notice, I meant complete removal of its support on the
> driver though :)
Oh, I've no problem removing two-stage fw support.
But then, I don't know much about usability :-D and I've enough of
people banging their heads against each other.
Regards,
Chr
^ permalink raw reply
* Re: compat-wireless and minstrel
From: Luis R. Rodriguez @ 2009-11-04 22:34 UTC (permalink / raw)
To: Christian Lamparter; +Cc: Luis R. Rodriguez, Adam Wozniak, linux-wireless
In-Reply-To: <200911042331.56052.chunkeey@googlemail.com>
On Wed, Nov 4, 2009 at 2:31 PM, Christian Lamparter
<chunkeey@googlemail.com> wrote:
> On Wednesday 04 November 2009 23:20:07 Luis R. Rodriguez wrote:
>> On Wed, Nov 04, 2009 at 11:18:13PM +0100, Christian Lamparter wrote:
>> > On Wednesday 04 November 2009 22:50:46 Luis R. Rodriguez wrote:
>> > > On Wed, Nov 4, 2009 at 1:46 PM, Adam Wozniak <awozniak@irobot.com> wrote:
>> > > >
>> > > > $ ls -la /lib/firmware/ar9170*
>> > > > -rw-r--r-- 1 root root 83968 2009-10-17 15:55 /lib/firmware/ar9170-1.fw
>> > > > -rw-r--r-- 1 root root 3508 2009-10-17 15:55 /lib/firmware/ar9170-2.fw
>> > > > -rw-r--r-- 1 root root 15960 2009-10-17 15:55 /lib/firmware/ar9170.fw
>> > > >
>> > > > It is unclear to me which are actually used.
>> > >
>> > > By default the ar9170.fw is tried first, if that fails then the others
>> > > are tried. The 2-stage firmware will not be tried if your device
>> > > cannot handle it but right now only the AVM Fritz devices can't handle
>> > > the 2-stage firmware.
>> > >
>> > > Christian should we just remove 2-stage fw support?
>> >
>> > I've moved the two-stage fw into the legacy section some time ago :)
>> > Maybe a add printk?
>>
>> Oh sorry didn't notice, I meant complete removal of its support on the
>> driver though :)
> Oh, I've no problem removing two-stage fw support.
Ok cool.
> But then, I don't know much about usability :-D and I've enough of
> people banging their heads against each other.
Not sure I got this part.
Luis
^ permalink raw reply
* Re: Marvell 88w8385 Support
From: Julian Calaby @ 2009-11-04 22:35 UTC (permalink / raw)
To: Dan Williams; +Cc: Holger Schurig, tsr, linux-wireless, mangoo
In-Reply-To: <1257366885.15872.0.camel@localhost.localdomain>
On Thu, Nov 5, 2009 at 07:34, Dan Williams <dcbw@redhat.com> wrote:
> On Wed, 2009-11-04 at 16:29 +0100, Holger Schurig wrote:
>> > From what I can tell there was a patch (referenced here:
>> > http://marc.info/?l=linux-wireless&m=123782768023390&w=2) to fix this
>> > but I also get indications that this is not the case since there is both
>> > a USB and miniPCI version of the 88w8385.
>>
>> This patch is only for the CF/PCMCIA versions of this those chips.
>>
>> There is no if_pci.c yet inside drivers/net/wireless/libertas/, if you
>> are certain you've a PCI card you're welcome to write one, should be
>> pretty easy. You can get help by looking at the other if_*.c files for
>> other physical interfaces.
>>
>>
>> > You write something
>> > (http://marc.info/?l=linux-wireless&m=124334594302472&w=2) that is
>> > cryptic to me.
>>
>> Can you elaborate? What exactly here is cryptic?
>>
>> CF/SDIO/GSPO/USB ?
>> 8015/8385 ?
>>
>>
>> > Also searching the kernel gittree I found
>> > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=drivers/net/wireless/libertas/if_spi.c;h=06a46d7b3d6c2460aecd793d2827033c7c0348f6;hb=cadeba315cc91ae1b57632e61b0cec3a4ed7088d
>> > which seems to include a driver for the miniPCI libertas 88w8385.
>>
>> No, if_spi.c is an indicator that this is for an SPI or GSPI.
>>
>> There's to my knowledge no such thing as a PCI-based Marvell 8385
>> chip/card/whatever.
>
> I'm fairly sure 8385 is only CF and SDIO.
>
> Perhaps he means 8335 instead? That was available in both USB and PCI,
> but it's a softmac part that doesn't have mwl8k support yet afaik.
Looking through the first half of this thread, he does seem to mean that.
You mentioned that you were working on building support for 8335s into
mwl8k, have you made any progress?
Thanks,
--
Julian Calaby
Email: julian.calaby@gmail.com
.Plan: http://sites.google.com/site/juliancalaby/
^ permalink raw reply
* Re: pci_set_mwi() and ath5k
From: Luis R. Rodriguez @ 2009-11-04 22:39 UTC (permalink / raw)
To: Matthew Wilcox
Cc: Luis R. Rodriguez, Nick Kossifidis, linux-wireless, ath5k-devel,
Stephen Hemminger, Kyle McMartin
In-Reply-To: <20091104222904.GJ10555@parisc-linux.org>
On Wed, Nov 4, 2009 at 2:29 PM, Matthew Wilcox <matthew@wil.cx> wrote:
> On Wed, Nov 04, 2009 at 05:14:26PM -0500, Luis R. Rodriguez wrote:
>> On Wed, Nov 04, 2009 at 02:04:11PM -0800, Luis R. Rodriguez wrote:
>> > On Wed, Nov 4, 2009 at 2:00 PM, Matthew Wilcox <matthew@wil.cx> wrote:
>> > > On Wed, Nov 04, 2009 at 01:52:30PM -0800, Luis R. Rodriguez wrote:
>> > >> > Even better: I just confirmation from our systems team that our legacy
>> > >> > devices and 11n PCI devices don't support MWR so I'll remove all that
>> > >> > cruft crap.
>> > >>
>> > >> I meant MWI of course.
>> > >
>> > > Yes, but they don't necessarily just use cacheline size for MWI ... some
>> > > devices use cacheline size for setting up data structures. ?Might be
>> > > worth just checking explicitly that they don't use the cacheline size
>> > > register for anything.
>> >
>> > Oh right -- so the typical Atheros hack for this is to check the cache
>> > line size, and if its 0 set it to L1_CACHE_BYTES. Then eventually read
>> > from PCI_CACHE_LINE_SIZE pci config to align the skb data. So what I
>> > was doing now is removing all this cruft and replacing it with a
>> > generic allocator for atheros drivers that aligns simply to the
>> > L1_CACHE_BYTES. Sound kosher?
>>
>> Something like this:
>
> Doesn't look kosher to me. You're not programming the CLS register
> now at all, which means you're relying on something else having set
> it up for you. If you could EXPORT_SYMBOL(pci_set_cacheline_size)
> and include a call to it somewhere, that would be good. You can rely
> on pci_cache_line_size not changing after the system has booted.
I see what you mean but the concern would be *if the hw does use it
for some internal stuff* right?
>> /*
>> - * Cache line size is used to size and align various
>> - * structures used to communicate with the hardware.
>> - */
>> - pci_read_config_byte(pdev, PCI_CACHE_LINE_SIZE, &csz);
>> - if (csz == 0) {
>> - /*
>> - * Linux 2.4.18 (at least) writes the cache line size
>> - * register as a 16-bit wide register which is wrong.
>> - * We must have this setup properly for rx buffer
>> - * DMA to work so force a reasonable value here if it
>> - * comes up zero.
>> - */
>> - csz = L1_CACHE_BYTES >> 2;
>> - pci_write_config_byte(pdev, PCI_CACHE_LINE_SIZE, csz);
>> - }
>
> These comments are what give me pause.
I see -- OK well I believe the above is in reference to driver code
which uses the written to value on the PCI_CACHE_LINE_SIZE to later
align the skb->data for our RX buffers.
At least our systems team does not believe we rely on the
PCI_CACHE_LINE_SIZE internally on the hardware for anything.
But if there is concern over the doubt of old hardware probably
relying it for some obscure things no one remembers then yeah its best
to leave it huh.
Luis
^ permalink raw reply
* Re: pci_set_mwi() and ath5k
From: Luis R. Rodriguez @ 2009-11-04 22:45 UTC (permalink / raw)
To: Nick Kossifidis
Cc: Luis R. Rodriguez, Matthew Wilcox, linux-wireless, ath5k-devel,
Stephen Hemminger, Kyle McMartin
In-Reply-To: <40f31dec0911041431i6f718bf1x1e52d9e12ab22060@mail.gmail.com>
On Wed, Nov 4, 2009 at 2:31 PM, Nick Kossifidis <mickflemm@gmail.com> wrote:
> 2009/11/5 Luis R. Rodriguez <mcgrof@bombadil.infradead.org>:
>> On Wed, Nov 04, 2009 at 02:04:11PM -0800, Luis R. Rodriguez wrote:
>>> On Wed, Nov 4, 2009 at 2:00 PM, Matthew Wilcox <matthew@wil.cx> wrote:
>>> > On Wed, Nov 04, 2009 at 01:52:30PM -0800, Luis R. Rodriguez wrote:
>>> >> > Even better: I just confirmation from our systems team that our legacy
>>> >> > devices and 11n PCI devices don't support MWR so I'll remove all that
>>> >> > cruft crap.
>>> >>
>>> >> I meant MWI of course.
>>> >
>>> > Yes, but they don't necessarily just use cacheline size for MWI ... some
>>> > devices use cacheline size for setting up data structures. Might be
>>> > worth just checking explicitly that they don't use the cacheline size
>>> > register for anything.
>>>
>>> Oh right -- so the typical Atheros hack for this is to check the cache
>>> line size, and if its 0 set it to L1_CACHE_BYTES. Then eventually read
>>> from PCI_CACHE_LINE_SIZE pci config to align the skb data. So what I
>>> was doing now is removing all this cruft and replacing it with a
>>> generic allocator for atheros drivers that aligns simply to the
>>> L1_CACHE_BYTES. Sound kosher?
>>
>> Something like this:
>>
>
> According to comments inside MadWiFi AR5210 needs cache line align
> else we get corruptions.
For what though?
> I don't know if this is correct for all
> platforms or later cards but since we (plan to) support AR5210 i guess
> we should leave it there. We need to test this a lot on various
> archs/cards before applying it.
There are two cases where we can use the PCI_CACHE_LINE_SIZE:
1) Hardware has been designed to use it on some block to align some data somehow
2) Software uses it to align skb->data for performance/hw purposes
I believe the second case can be handled by using L1_CACHE_BYTES
instead and I'd at least like to change our common skb allocator to
use that.
The first case is where it seems there may be some skepticism as to
whether or not hw really did not rely on it and I agree its safer to
keep the programming of the PCI_CACHE_LINE_SIZE in case it has a
bogus value.
Does this seem reasonable?
Luis
^ permalink raw reply
* Re: pci_set_mwi() and ath5k
From: Luis R. Rodriguez @ 2009-11-04 22:47 UTC (permalink / raw)
To: Nick Kossifidis
Cc: Luis R. Rodriguez, Matthew Wilcox, linux-wireless, ath5k-devel,
Stephen Hemminger, Kyle McMartin
In-Reply-To: <43e72e890911041445s4e69aa46nda01d423c1bd8f7d@mail.gmail.com>
On Wed, Nov 4, 2009 at 2:45 PM, Luis R. Rodriguez <mcgrof@gmail.com> wrote:
> On Wed, Nov 4, 2009 at 2:31 PM, Nick Kossifidis <mickflemm@gmail.com> wrote:
>> 2009/11/5 Luis R. Rodriguez <mcgrof@bombadil.infradead.org>:
>>> On Wed, Nov 04, 2009 at 02:04:11PM -0800, Luis R. Rodriguez wrote:
>>>> On Wed, Nov 4, 2009 at 2:00 PM, Matthew Wilcox <matthew@wil.cx> wrote:
>>>> > On Wed, Nov 04, 2009 at 01:52:30PM -0800, Luis R. Rodriguez wrote:
>>>> >> > Even better: I just confirmation from our systems team that our legacy
>>>> >> > devices and 11n PCI devices don't support MWR so I'll remove all that
>>>> >> > cruft crap.
>>>> >>
>>>> >> I meant MWI of course.
>>>> >
>>>> > Yes, but they don't necessarily just use cacheline size for MWI ... some
>>>> > devices use cacheline size for setting up data structures. Might be
>>>> > worth just checking explicitly that they don't use the cacheline size
>>>> > register for anything.
>>>>
>>>> Oh right -- so the typical Atheros hack for this is to check the cache
>>>> line size, and if its 0 set it to L1_CACHE_BYTES. Then eventually read
>>>> from PCI_CACHE_LINE_SIZE pci config to align the skb data. So what I
>>>> was doing now is removing all this cruft and replacing it with a
>>>> generic allocator for atheros drivers that aligns simply to the
>>>> L1_CACHE_BYTES. Sound kosher?
>>>
>>> Something like this:
>>>
>>
>> According to comments inside MadWiFi AR5210 needs cache line align
>> else we get corruptions.
>
> For what though?
>
>> I don't know if this is correct for all
>> platforms or later cards but since we (plan to) support AR5210 i guess
>> we should leave it there. We need to test this a lot on various
>> archs/cards before applying it.
>
> There are two cases where we can use the PCI_CACHE_LINE_SIZE:
>
> 1) Hardware has been designed to use it on some block to align some data somehow
> 2) Software uses it to align skb->data for performance/hw purposes
>
> I believe the second case can be handled by using L1_CACHE_BYTES
> instead and I'd at least like to change our common skb allocator to
> use that.
>
> The first case is where it seems there may be some skepticism as to
> whether or not hw really did not rely on it and I agree its safer to
> keep the programming of the PCI_CACHE_LINE_SIZE in case it has a
> bogus value.
>
> Does this seem reasonable?
I guess we can keep the second case allocator which relies on
PCI_CACHE_LINE_SIZE, but if so then USB will just define its own csz
statically always to L1_CACHE_BYTES which is fine too -- I was just
hoping we could remove the PCI_CACHE_LINE_SIZE programming completely
too and use a simple L1_CACHE_BYTES aligned allocator.
Luis
^ permalink raw reply
* Re: [PATCH 00/41] rewritten rt2800 drivers
From: Julian Calaby @ 2009-11-04 22:55 UTC (permalink / raw)
To: Gertjan van Wingerde
Cc: Bartlomiej Zolnierkiewicz, linux-wireless, Ivo van Doorn,
linux-kernel, John W. Linville
In-Reply-To: <14add3d10911041219j6ab25282re4f98d14029b1f68@mail.gmail.com>
Bart,
FWIW, this all looks good to me, except for these comments:
1. When you introduce struct rt2800_ops, it may telegraph your
intentions more clearly if you introduce rt2800lib.h at the same time
- this also means that we don't have (if only for a single patch)
duplicate versions of this structure and it's associated code.
2. Patches #26-28 should arguably come before the conversions to use
the struct rt2800_ops methods.
3. I don't get the reasoning behind patch #37 (remove useless ifdefs
from rt2x00leds.h) but I'm going to assume that it's all right.
4. Patch #39 should arguably come earlier in the patch set as it's a
general cleanup.
Other than that, good work!
Thanks,
--
Julian Calaby
Email: julian.calaby@gmail.com
.Plan: http://sites.google.com/site/juliancalaby/
^ permalink raw reply
* Re: pci_set_mwi() and ath5k
From: Luis R. Rodriguez @ 2009-11-04 23:14 UTC (permalink / raw)
To: Nick Kossifidis
Cc: Luis R. Rodriguez, Matthew Wilcox, linux-wireless, ath5k-devel,
Stephen Hemminger, Kyle McMartin
In-Reply-To: <43e72e890911041447w24a6e149xddea0fb30abddddc@mail.gmail.com>
On Wed, Nov 4, 2009 at 2:47 PM, Luis R. Rodriguez <mcgrof@gmail.com> wrote:
> On Wed, Nov 4, 2009 at 2:45 PM, Luis R. Rodriguez <mcgrof@gmail.com> wrote:
>> On Wed, Nov 4, 2009 at 2:31 PM, Nick Kossifidis <mickflemm@gmail.com> wrote:
>>> 2009/11/5 Luis R. Rodriguez <mcgrof@bombadil.infradead.org>:
>>>> On Wed, Nov 04, 2009 at 02:04:11PM -0800, Luis R. Rodriguez wrote:
>>>>> On Wed, Nov 4, 2009 at 2:00 PM, Matthew Wilcox <matthew@wil.cx> wrote:
>>>>> > On Wed, Nov 04, 2009 at 01:52:30PM -0800, Luis R. Rodriguez wrote:
>>>>> >> > Even better: I just confirmation from our systems team that our legacy
>>>>> >> > devices and 11n PCI devices don't support MWR so I'll remove all that
>>>>> >> > cruft crap.
>>>>> >>
>>>>> >> I meant MWI of course.
>>>>> >
>>>>> > Yes, but they don't necessarily just use cacheline size for MWI ... some
>>>>> > devices use cacheline size for setting up data structures. Might be
>>>>> > worth just checking explicitly that they don't use the cacheline size
>>>>> > register for anything.
>>>>>
>>>>> Oh right -- so the typical Atheros hack for this is to check the cache
>>>>> line size, and if its 0 set it to L1_CACHE_BYTES. Then eventually read
>>>>> from PCI_CACHE_LINE_SIZE pci config to align the skb data. So what I
>>>>> was doing now is removing all this cruft and replacing it with a
>>>>> generic allocator for atheros drivers that aligns simply to the
>>>>> L1_CACHE_BYTES. Sound kosher?
>>>>
>>>> Something like this:
>>>>
>>>
>>> According to comments inside MadWiFi AR5210 needs cache line align
>>> else we get corruptions.
>>
>> For what though?
>>
>>> I don't know if this is correct for all
>>> platforms or later cards but since we (plan to) support AR5210 i guess
>>> we should leave it there. We need to test this a lot on various
>>> archs/cards before applying it.
>>
>> There are two cases where we can use the PCI_CACHE_LINE_SIZE:
>>
>> 1) Hardware has been designed to use it on some block to align some data somehow
>> 2) Software uses it to align skb->data for performance/hw purposes
>>
>> I believe the second case can be handled by using L1_CACHE_BYTES
>> instead and I'd at least like to change our common skb allocator to
>> use that.
>>
>> The first case is where it seems there may be some skepticism as to
>> whether or not hw really did not rely on it and I agree its safer to
>> keep the programming of the PCI_CACHE_LINE_SIZE in case it has a
>> bogus value.
>>
>> Does this seem reasonable?
>
> I guess we can keep the second case allocator which relies on
> PCI_CACHE_LINE_SIZE, but if so then USB will just define its own csz
> statically always to L1_CACHE_BYTES which is fine too -- I was just
> hoping we could remove the PCI_CACHE_LINE_SIZE programming completely
> too and use a simple L1_CACHE_BYTES aligned allocator.
OK I'll leave all this crap and just annotate why its there. Right now
its just voodoo.
Luis
^ permalink raw reply
* Reverting 5d423 fixes loading of ath9k on Acer Extensa 7630EZ
From: Luis R. Rodriguez @ 2009-11-04 23:40 UTC (permalink / raw)
To: Ingo Molnar, linux-kernel, linux-wireless
Cc: Linus Torvalds, Yannick Roehlly, Yinghai Lu, Jesse Barnes,
Ivan Kokshaysky, Andrew Morton, John W. Linville, berndl81,
Greg KH
Ingo,
reverting the commit 5d423, titled "x86/pci: remove rounding quirk
from e820_setup_gap()" fixes loading of ath9k on an Acer Extensa
7630EZ. We've troubleshooted the issue with the user, Bernhard, who
eventually did a full bisect between 2.6.30 and 2.6.31 and found 5d423
was the culprit. For details please feel free to check:
http://bugzilla.kernel.org/show_bug.cgi?id=14402
Can you please consider reviewing this issue and help determine if
this indeed needs to be reverted for 2.6.32 and the next 2.6.31.y.
I am curious if other devices would work by reverting this as well.
Luis
^ permalink raw reply
* [PATCH] Libertas: Fix issues while configuring host sleep
From: Bing Zhao @ 2009-11-05 1:06 UTC (permalink / raw)
To: libertas-dev; +Cc: linux-wireless, Bing Zhao, Amitkumar Karwar
From: Amitkumar Karwar <akarwar@marvell.com>
Configuration of wake-on-lan for unicast, multicast, broadcast, physical
activity was not working. Kernel panic issue was there when user tries to
disable WOL. Fixed them.
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
---
drivers/net/wireless/libertas/ethtool.c | 16 +++++++++++-----
1 files changed, 11 insertions(+), 5 deletions(-)
diff --git a/drivers/net/wireless/libertas/ethtool.c b/drivers/net/wireless/libertas/ethtool.c
index 039b555..eeda6d7 100644
--- a/drivers/net/wireless/libertas/ethtool.c
+++ b/drivers/net/wireless/libertas/ethtool.c
@@ -169,16 +169,22 @@ static int lbs_ethtool_set_wol(struct net_device *dev,
struct lbs_private *priv = dev->ml_priv;
uint32_t criteria = 0;
- if (priv->wol_criteria == 0xffffffff && wol->wolopts)
+ if (priv->wol_criteria != 0xffffffff && wol->wolopts)
return -EOPNOTSUPP;
if (wol->wolopts & ~(WAKE_UCAST|WAKE_MCAST|WAKE_BCAST|WAKE_PHY))
return -EOPNOTSUPP;
- if (wol->wolopts & WAKE_UCAST) criteria |= EHS_WAKE_ON_UNICAST_DATA;
- if (wol->wolopts & WAKE_MCAST) criteria |= EHS_WAKE_ON_MULTICAST_DATA;
- if (wol->wolopts & WAKE_BCAST) criteria |= EHS_WAKE_ON_BROADCAST_DATA;
- if (wol->wolopts & WAKE_PHY) criteria |= EHS_WAKE_ON_MAC_EVENT;
+ if (wol->wolopts & WAKE_UCAST)
+ criteria |= EHS_WAKE_ON_UNICAST_DATA;
+ if (wol->wolopts & WAKE_MCAST)
+ criteria |= EHS_WAKE_ON_MULTICAST_DATA;
+ if (wol->wolopts & WAKE_BCAST)
+ criteria |= EHS_WAKE_ON_BROADCAST_DATA;
+ if (wol->wolopts & WAKE_PHY)
+ criteria |= EHS_WAKE_ON_MAC_EVENT;
+ if (wol->wolopts == 0)
+ criteria |= EHS_REMOVE_WAKEUP;
return lbs_host_sleep_cfg(priv, criteria, (struct wol_config *)NULL);
}
--
1.5.4.3
^ permalink raw reply related
* Re: Reverting 5d423 fixes loading of ath9k on Acer Extensa 7630EZ
From: Linus Torvalds @ 2009-11-04 23:57 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: Ingo Molnar, linux-kernel, linux-wireless, Yannick Roehlly,
Yinghai Lu, Jesse Barnes, Ivan Kokshaysky, Andrew Morton,
John W. Linville, berndl81, Greg KH
In-Reply-To: <43e72e890911041540hd1e5f87u8d282d9c95857504@mail.gmail.com>
On Wed, 4 Nov 2009, Luis R. Rodriguez wrote:
>
> Can you please consider reviewing this issue and help determine if
> this indeed needs to be reverted for 2.6.32 and the next 2.6.31.y.
>
> I am curious if other devices would work by reverting this as well.
> [ ... ] For details please feel free to check:
>
> http://bugzilla.kernel.org/show_bug.cgi?id=14402
That same commit was the cause for
http://bugzilla.kernel.org/show_bug.cgi?id=13940
and we just increased the rounding to make it go away (see commit
15b812f1). But that was a hack.
And if that didn't help the ath9k case, then we should just revert
entirely.
Linus
^ permalink raw reply
* Re: [PATCH] rtl8187: Fix kernel oops when device is removed when LEDS enabled (Bugzilla #14539)
From: Herton Ronaldo Krzesinski @ 2009-11-05 0:14 UTC (permalink / raw)
To: John W. Linville
Cc: Christian Lamparter, Larry Finger, Hin-Tak Leung, sidhayn,
linux-wireless
In-Reply-To: <20091104164938.GG12965@tuxdriver.com>
Em Qua 04 Nov 2009, às 14:49:38, John W. Linville escreveu:
> On Wed, Nov 04, 2009 at 04:30:19PM +0100, Christian Lamparter wrote:
> > On Wednesday 04 November 2009 16:11:33 John W. Linville wrote:
>
> > > This seems like a band-aid. If anything, the original order would
> > > seem to make more sense.
> >
> > really?
> >
> > take this code from led-class.c
> >
> > void led_classdev_unregister(struct led_classdev *led_cdev)
> > {
> > device_remove_file(led_cdev->dev, &dev_attr_max_brightness);
> > device_remove_file(led_cdev->dev, &dev_attr_brightness);
> > #ifdef CONFIG_LEDS_TRIGGERS
> > device_remove_file(led_cdev->dev, &dev_attr_trigger);
> > down_write(&led_cdev->trigger_lock);
> > if (led_cdev->trigger)
> > led_trigger_set(led_cdev, NULL);
> > up_write(&led_cdev->trigger_lock);
> > #endif
> >
> > device_unregister(led_cdev->dev);
> >
> > down_write(&leds_list_lock);
> > list_del(&led_cdev->node);
> > up_write(&leds_list_lock);
> > }
> >
> > as you can see the led is switched-off right before the device is unregistered.
> > but rtl8187, p54 & ar9170 led-triggers are timed & asynchronous. So
> > we really need a cancel_delayed_work_sync after the unregister routine
> > finished... else the timed trigger might fire when the device/module
> > is _faded_ from memory.
>
> OK, I got it...the unregister can queue-up more work. Thanks for
> the explanation.
Hi, I checked here and the code above in led_classdev_unregister is the same in
2.6.31, so I think the patch from Larry should also be applied/sent to 2.6.31.x
stable, as the bug could happen there too.
>
> John
>
--
[]'s
Herton
^ permalink raw reply
* Re: Reverting 5d423 fixes loading of ath9k on Acer Extensa 7630EZ
From: Luis R. Rodriguez @ 2009-11-05 0:16 UTC (permalink / raw)
To: Linus Torvalds
Cc: Ingo Molnar, linux-kernel, linux-wireless, Yannick Roehlly,
Yinghai Lu, Jesse Barnes, Ivan Kokshaysky, Andrew Morton,
John W. Linville, berndl81, Greg KH
In-Reply-To: <alpine.LFD.2.01.0911041551220.31845@localhost.localdomain>
On Wed, Nov 4, 2009 at 3:57 PM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
>
> On Wed, 4 Nov 2009, Luis R. Rodriguez wrote:
>>
>> Can you please consider reviewing this issue and help determine if
>> this indeed needs to be reverted for 2.6.32 and the next 2.6.31.y.
>>
>> I am curious if other devices would work by reverting this as well.
>> [ ... ] For details please feel free to check:
>>
>> http://bugzilla.kernel.org/show_bug.cgi?id=14402
>
> That same commit was the cause for
>
> http://bugzilla.kernel.org/show_bug.cgi?id=13940
>
> and we just increased the rounding to make it go away (see commit
> 15b812f1). But that was a hack.
>
> And if that didn't help the ath9k case, then we should just revert
> entirely.
Alright, will see if Bernhard is up for testing the 15b812f1 hack and
report back.
Luis
^ permalink raw reply
* Re: pci_set_mwi() and ath5k
From: Nick Kossifidis @ 2009-11-05 0:16 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: Luis R. Rodriguez, Matthew Wilcox, linux-wireless, ath5k-devel,
Stephen Hemminger, Kyle McMartin
In-Reply-To: <43e72e890911041445s4e69aa46nda01d423c1bd8f7d@mail.gmail.com>
2009/11/5 Luis R. Rodriguez <mcgrof@gmail.com>:
>
> There are two cases where we can use the PCI_CACHE_LINE_SIZE:
>
> 1) Hardware has been designed to use it on some block to align some data somehow
> 2) Software uses it to align skb->data for performance/hw purposes
>
> I believe the second case can be handled by using L1_CACHE_BYTES
> instead and I'd at least like to change our common skb allocator to
> use that.
>
> The first case is where it seems there may be some skepticism as to
> whether or not hw really did not rely on it and I agree its safer to
> keep the programming of the PCI_CACHE_LINE_SIZE in case it has a
> bogus value.
>
> Does this seem reasonable?
>
> Luis
>
Yup, i believe 2 is the case, from what i've read the problem is that
we get corrupted data so i guess we can just use the L1_CACHE_BYTES to
align skb->data and not write anything to PCI_CACHE_LINE_SIZE if you
think that will work. Just be sure to test on some ath5k cards (don't
have time for anything right now ;-( ). I believe having cleaner code
is better than supporting an ancient chip anyway, if this is really
necessary for AR5210 -writing PCI_CACHE_LINE_SIZE- we can deal with it
later.
--
GPG ID: 0xD21DB2DB
As you read this post global entropy rises. Have Fun ;-)
Nick
^ permalink raw reply
* Re: Reverting 5d423 fixes loading of ath9k on Acer Extensa 7630EZ
From: Yinghai Lu @ 2009-11-05 1:30 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: Linus Torvalds, Ingo Molnar, linux-kernel, linux-wireless,
Yannick Roehlly, Jesse Barnes, Ivan Kokshaysky, Andrew Morton,
John W. Linville, berndl81, Greg KH
In-Reply-To: <43e72e890911041616w547fc9e4t34915827f65c2682@mail.gmail.com>
Luis R. Rodriguez wrote:
> On Wed, Nov 4, 2009 at 3:57 PM, Linus Torvalds
> <torvalds@linux-foundation.org> wrote:
>>
>> On Wed, 4 Nov 2009, Luis R. Rodriguez wrote:
>>> Can you please consider reviewing this issue and help determine if
>>> this indeed needs to be reverted for 2.6.32 and the next 2.6.31.y.
>>>
>>> I am curious if other devices would work by reverting this as well.
>>> [ ... ] For details please feel free to check:
>>>
>>> http://bugzilla.kernel.org/show_bug.cgi?id=14402
>> That same commit was the cause for
>>
>> http://bugzilla.kernel.org/show_bug.cgi?id=13940
>>
>> and we just increased the rounding to make it go away (see commit
>> 15b812f1). But that was a hack.
>>
>> And if that didn't help the ath9k case, then we should just revert
>> entirely.
>
> Alright, will see if Bernhard is up for testing the 15b812f1 hack and
> report back.
can you post whole boot log with debug?
YH
^ permalink raw reply
* Re: Reverting 5d423 fixes loading of ath9k on Acer Extensa 7630EZ
From: Luis R. Rodriguez @ 2009-11-05 1:40 UTC (permalink / raw)
To: Yinghai Lu
Cc: Linus Torvalds, Ingo Molnar, linux-kernel, linux-wireless,
Yannick Roehlly, Jesse Barnes, Ivan Kokshaysky, Andrew Morton,
John W. Linville, berndl81, Greg KH
In-Reply-To: <4AF22A99.7050407@kernel.org>
On Wed, Nov 4, 2009 at 5:30 PM, Yinghai Lu <yinghai@kernel.org> wrote:
> Luis R. Rodriguez wrote:
>> On Wed, Nov 4, 2009 at 3:57 PM, Linus Torvalds
>> <torvalds@linux-foundation.org> wrote:
>>>
>>> On Wed, 4 Nov 2009, Luis R. Rodriguez wrote:
>>>> Can you please consider reviewing this issue and help determine if
>>>> this indeed needs to be reverted for 2.6.32 and the next 2.6.31.y.
>>>>
>>>> I am curious if other devices would work by reverting this as well.
>>>> [ ... ] For details please feel free to check:
>>>>
>>>> http://bugzilla.kernel.org/show_bug.cgi?id=14402
>>> That same commit was the cause for
>>>
>>> http://bugzilla.kernel.org/show_bug.cgi?id=13940
>>>
>>> and we just increased the rounding to make it go away (see commit
>>> 15b812f1). But that was a hack.
>>>
>>> And if that didn't help the ath9k case, then we should just revert
>>> entirely.
>>
>> Alright, will see if Bernhard is up for testing the 15b812f1 hack and
>> report back.
>
> can you post whole boot log with debug?
You can find the logs without 15b812f1 on the bug report. I'll poke
Bernhard to poke logs with 15b812f1 applied.
Luis
^ permalink raw reply
* Re: [PATCH] rtl8187: Fix kernel oops when device is removed when LEDS enabled (Bugzilla #14539)
From: Larry Finger @ 2009-11-05 2:34 UTC (permalink / raw)
To: Herton Ronaldo Krzesinski
Cc: John W. Linville, Christian Lamparter, Hin-Tak Leung, sidhayn,
linux-wireless
In-Reply-To: <200911042214.54230.herton@mandriva.com.br>
On 11/04/2009 06:14 PM, Herton Ronaldo Krzesinski wrote:
>
> Hi, I checked here and the code above in led_classdev_unregister is the same in
> 2.6.31, so I think the patch from Larry should also be applied/sent to 2.6.31.x
> stable, as the bug could happen there too.
Herton,
Technically you are correct; however, I did extensive testing of
2.6.31 and _NEVER_ got the failure. The sequencing is a bug waiting to
happen, but something in the post 2.6.31 merge actually enabled the
bug to happen. I tried bisection to determine which change actully did
that, but was not successful.
My feeling is that stable can be left alone. Of course, if bug reports
of kernel panics on unload of rtl8187 start occurring, we will know
how to fix it.
Larry
^ permalink raw reply
* Re: [RFC] usb: Check results of dma_map_single
From: Larry Finger @ 2009-11-05 2:41 UTC (permalink / raw)
To: Christian Lamparter; +Cc: Greg Kroah-Hartman, linux-wireless, linux-usb
In-Reply-To: <200911042049.02761.chunkeey@googlemail.com>
On 11/04/2009 01:49 PM, Christian Lamparter wrote:
> On Wednesday 04 November 2009 06:48:51 Larry Finger wrote:
>> At http://marc.info/?l=linux-wireless&m=125695331205062&w=2, a problem
>> with DMA buffer processing was corrected for the libertas driver. Because
>> routine usb_fill_bulk_urb() does not check that DMA is possible when
> ^^^
> hmm, usb_fill_bulk_urb? No, that should be usb_submit_urb :)
Thanks. The actual routine modified is map_urb_for_dma.
Larry
^ permalink raw reply
* [PATCH] ath5k: add LED support for Acer Aspire One AO751h/AO531h
From: Keng-Yu Lin @ 2009-11-05 2:55 UTC (permalink / raw)
To: linux-wireless; +Cc: Keng-Yu Lin
Add LED support for a Foxconn AR242X module, found on
the Acer Aspire One models AO751h/AO531h
Signed-off-by: Keng-Yu Lin <keng-yu.lin@canonical.com>
---
drivers/net/wireless/ath/ath5k/led.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/net/wireless/ath/ath5k/led.c b/drivers/net/wireless/ath/ath5k/led.c
index b767c3b..21a42a1 100644
--- a/drivers/net/wireless/ath/ath5k/led.c
+++ b/drivers/net/wireless/ath/ath5k/led.c
@@ -59,6 +59,8 @@ static const struct pci_device_id ath5k_led_devices[] = {
{ ATH_SDEVICE(PCI_VENDOR_ID_COMPAQ, PCI_ANY_ID), ATH_LED(1, 1) },
/* Acer Aspire One A150 (maximlevitsky@gmail.com) */
{ ATH_SDEVICE(PCI_VENDOR_ID_FOXCONN, 0xe008), ATH_LED(3, 0) },
+ /* Acer Aspire One AO531h AO751h */
+ { ATH_SDEVICE(PCI_VENDOR_ID_FOXCONN, 0xe00d), ATH_LED(3, 0) },
/* Acer Ferrari 5000 (russ.dill@gmail.com) */
{ ATH_SDEVICE(PCI_VENDOR_ID_AMBIT, 0x0422), ATH_LED(1, 1) },
/* E-machines E510 (tuliom@gmail.com) */
--
1.6.3.3
^ permalink raw reply related
* Re: pci_set_mwi() and ath5k
From: Bob Copeland @ 2009-11-05 2:55 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: Luis R. Rodriguez, Matthew Wilcox, Nick Kossifidis,
linux-wireless, ath5k-devel, Stephen Hemminger, Kyle McMartin
In-Reply-To: <20091104221426.GA2599@bombadil.infradead.org>
On Wed, Nov 4, 2009 at 5:14 PM, Luis R. Rodriguez
<mcgrof@bombadil.infradead.org> wrote:
> - off = ((unsigned long) skb->data) % common->cachelsz;
> + off = ((unsigned long) skb->data) % L1_CACHE_BYTES;
> if (off != 0)
Side note, at least this needs to use PTR_ALIGN :)
I have a patch somewhere to do that but if you're in there anyway...
--
Bob Copeland %% www.bobcopeland.com
^ permalink raw reply
* Re: [PATCH] ath5k: add LED support for Acer Aspire One AO751h/AO531h
From: Bob Copeland @ 2009-11-05 2:59 UTC (permalink / raw)
To: Keng-Yu Lin; +Cc: linux-wireless
In-Reply-To: <1257389729-26491-1-git-send-email-keng-yu.lin@canonical.com>
On Wed, Nov 4, 2009 at 9:55 PM, Keng-Yu Lin <keng-yu.lin@canonical.com> wrote:
> Add LED support for a Foxconn AR242X module, found on
> the Acer Aspire One models AO751h/AO531h
>
> Signed-off-by: Keng-Yu Lin <keng-yu.lin@canonical.com>
> ---
> drivers/net/wireless/ath/ath5k/led.c | 2 ++
> 1 files changed, 2 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/net/wireless/ath/ath5k/led.c b/drivers/net/wireless/ath/ath5k/led.c
> index b767c3b..21a42a1 100644
> --- a/drivers/net/wireless/ath/ath5k/led.c
> +++ b/drivers/net/wireless/ath/ath5k/led.c
> @@ -59,6 +59,8 @@ static const struct pci_device_id ath5k_led_devices[] = {
> { ATH_SDEVICE(PCI_VENDOR_ID_COMPAQ, PCI_ANY_ID), ATH_LED(1, 1) },
> /* Acer Aspire One A150 (maximlevitsky@gmail.com) */
> { ATH_SDEVICE(PCI_VENDOR_ID_FOXCONN, 0xe008), ATH_LED(3, 0) },
> + /* Acer Aspire One AO531h AO751h */
> + { ATH_SDEVICE(PCI_VENDOR_ID_FOXCONN, 0xe00d), ATH_LED(3, 0) },
Acked-by: Bob Copeland <me@bobcopeland.com>
... but can you by chance put a contact address in the comment? I've been
collecting them in case we one day figure out a better way to do this so it's
easy to find the people to retest.
--
Bob Copeland %% www.bobcopeland.com
^ permalink raw reply
* [PATCH] ath5k: add LED support for Acer Aspire One AO751h/AO531h
From: Keng-Yu Lin @ 2009-11-05 3:21 UTC (permalink / raw)
To: linux-wireless; +Cc: Keng-Yu Lin
In-Reply-To: <b6c5339f0911041859v762f90f4u1b369a80841ea756@mail.gmail.com>
Add LED support for a Foxconn AR242X module, found on
the Acer Aspire One models AO751h/AO531h
Signed-off-by: Keng-Yu Lin <keng-yu.lin@canonical.com>
---
drivers/net/wireless/ath/ath5k/led.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/net/wireless/ath/ath5k/led.c b/drivers/net/wireless/ath/ath5k/led.c
index b767c3b..7ce98bd 100644
--- a/drivers/net/wireless/ath/ath5k/led.c
+++ b/drivers/net/wireless/ath/ath5k/led.c
@@ -59,6 +59,8 @@ static const struct pci_device_id ath5k_led_devices[] = {
{ ATH_SDEVICE(PCI_VENDOR_ID_COMPAQ, PCI_ANY_ID), ATH_LED(1, 1) },
/* Acer Aspire One A150 (maximlevitsky@gmail.com) */
{ ATH_SDEVICE(PCI_VENDOR_ID_FOXCONN, 0xe008), ATH_LED(3, 0) },
+ /* Acer Aspire One AO531h AO751h (keng-yu.lin@canonical.com) */
+ { ATH_SDEVICE(PCI_VENDOR_ID_FOXCONN, 0xe00d), ATH_LED(3, 0) },
/* Acer Ferrari 5000 (russ.dill@gmail.com) */
{ ATH_SDEVICE(PCI_VENDOR_ID_AMBIT, 0x0422), ATH_LED(1, 1) },
/* E-machines E510 (tuliom@gmail.com) */
--
1.6.3.3
^ permalink raw reply related
* Re: [PATCH] rtl8187: Fix kernel oops when device is removed when LEDS enabled (Bugzilla #14539)
From: Richard Farina @ 2009-11-05 4:55 UTC (permalink / raw)
To: Larry Finger
Cc: Herton Ronaldo Krzesinski, John W. Linville, Christian Lamparter,
Hin-Tak Leung, linux-wireless
In-Reply-To: <4AF239A6.5050406@lwfinger.net>
Larry Finger wrote:
> On 11/04/2009 06:14 PM, Herton Ronaldo Krzesinski wrote:
>
>> Hi, I checked here and the code above in led_classdev_unregister is the same in
>> 2.6.31, so I think the patch from Larry should also be applied/sent to 2.6.31.x
>> stable, as the bug could happen there too.
>>
>
> Herton,
>
> Technically you are correct; however, I did extensive testing of
> 2.6.31 and _NEVER_ got the failure. The sequencing is a bug waiting to
> happen, but something in the post 2.6.31 merge actually enabled the
> bug to happen. I tried bisection to determine which change actully did
> that, but was not successful.
>
>
Using kernel 2.6.29 and compat-wireless-stable 2.6.31* I am able to make
it flake. I may be the only one lucky enough to make this explode with
a high degree of accuracy but I can't see why we wouldn't fix what we
know is a bug waiting to happen. My vote is to add this patch to
2.6.31.x as well.
Thanks,
Rick Farina
> My feeling is that stable can be left alone. Of course, if bug reports
> of kernel panics on unload of rtl8187 start occurring, we will know
> how to fix it.
>
> Larry
>
>
^ permalink raw reply
* Re: [PATCH] rtl8187: Fix kernel oops when device is removed when LEDS enabled (Bugzilla #14539)
From: Richard Farina @ 2009-11-05 4:57 UTC (permalink / raw)
To: John W. Linville
Cc: Larry Finger, Herton Ronaldo Krzesinski, Hin-Tak Leung,
linux-wireless, mcgrof, johannes
In-Reply-To: <20091104184700.GK12965@tuxdriver.com>
John W. Linville wrote:
> On Wed, Nov 04, 2009 at 12:13:02PM -0600, Larry Finger wrote:
>
>> On 11/04/2009 10:54 AM, John W. Linville wrote:
>>
>>> On Wed, Nov 04, 2009 at 09:54:37AM -0600, Larry Finger wrote:
>>>
>>>
>>>> I will try once more to get netconsole working to capture the backtrace.
>>>>
>>> No need, I think I understand it now. The new order still sorta
>>> looks/feels "wrong", but it seems fine. Maybe an alternative would
>>> be to make the brightness_set routine aware of the shutdown and not
>>> queue the work? Maybe even ieee80211_queue_delayed_work could be
>>> made a bit smarter here?
>>>
>> Are either of these questions a request, or are they musings?
>>
>
> They are musings -- but feel free to be inspired! :-)
>
>
I can't speak for "proper coding style" or "preferred fixes" or whatever
you awesome coders call things, but I can say that myself and a few
others have extensively test _this_ fix and can no longer crash the
kernel. As the original reporter I am more than satisfied that this is
fixed. Just my 0.02$
Thanks,
Rick Farina
^ permalink raw reply
* Re: [PATCH] rtl8187: Fix kernel oops when device is removed when LEDS enabled (Bugzilla #14539)
From: Larry Finger @ 2009-11-05 5:16 UTC (permalink / raw)
To: Richard Farina
Cc: Herton Ronaldo Krzesinski, John W. Linville, Christian Lamparter,
Hin-Tak Leung, linux-wireless
In-Reply-To: <4AF25AA6.60606@gmail.com>
On 11/04/2009 10:55 PM, Richard Farina wrote:
> Using kernel 2.6.29 and compat-wireless-stable 2.6.31* I am able to make
> it flake. I may be the only one lucky enough to make this explode with
> a high degree of accuracy but I can't see why we wouldn't fix what we
> know is a bug waiting to happen. My vote is to add this patch to
> 2.6.31.x as well.
With compat-wireless-stable 2.6.31, you essentially have the wireless
drivers of 2.6.32, which does have the problem. I could not make the
problem happen with vanilla 2.6.31, which is why I do not think we
need to send the fix to 2.6.31.Y. Of course, your system is much more
sensitive than mine. If you get the kernel panic with 2.6.31, then we
will need to reconsider. As openSUSE 11.2 will be out in a little over
a week using the 2.6.31 kernel, the problem may show up there.
Larry
^ 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