headers
Johannes Berg | 1 Mar 01:09
Favicon

Re: FIF_ filter flags

Hi,

> For example rt2x00 devices only have one promiscuous mode that covers traffic 
> in the same and other BSSes therefore if either of FIF_PROMISC_IN_BSS or 
> FIF_OTHER_BSS are set then the driver will set both of them in the returned 
> flags value.
> 
> It will also for some devices set the FIF_ALLMULTI flag if mc_count is non 
> zero.
> 
> If this behaviour is considered desirable then I'll keep it working when 
> making the change but if not I'll remove it.

Interesting. I don't think I have an opinion right now. I wanted to be
strict about clearing the flags so that you don't end up with a flag
that we never get traffic for, but I can't imagine any check where you'd
want to know "do I get traffic XY".

How do you keep track of that anyway? Say somebody enables
FIF_PROMISC_IN_BSS and you also set FIF_OTHER_BSS, then when
FIF_PROMISC_IN_BSS is disabled again FIF_OTHER_BSS should be disabled
too but how know that it wasn't set in the meantime? I think that says
that you shouldn't do that...

johannes
Permalink | Reply | 2 comments |
headers
Greg KH | 1 Mar 01:29
Gravatar

Re: [PATCH stable] b43: Backport bcm4311 fix

On Fri, Feb 29, 2008 at 12:55:41PM +0100, Michael Buesch wrote:
>     The changes include the following:
>     
>     (1) Add the 802.11 rev 13 device to the ssb_device_id table to load b43.
>     (2) Add PHY revision 9 to the supported list.
>     (3) Change the 2-bit routing code for address extensions to 0b10 rather
>         than the 0b01 used for the 32-bit case.
>     (4) Remove some magic numbers in the DMA setup.
>     
>     The DMA implementation for this chip supports full 64-bit addressing with
>     one exception. Whenever the Descriptor Ring Buffer is in high memory, a
>     fatal DMA error occurs. This problem was not present in 2.6.24-rc2 due
>     to code to "Bias the placement of kernel pages at lower PFNs". When
>     commit 44048d70 reverted that code, the DMA error appeared. As a "fix",
>     use the GFP_DMA flag when allocating the buffer for 64-bit DMA. At present,
>     this problem is thought to arise from a hardware error.

Is this logic upstream in 2.6.25-rcX already?  If so, do you have a git
id for it so that I can match them up?

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@...
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 0 comments |
headers
Luis Carlos Cobo | 1 Mar 02:31

Re: [PATCH 01/13 v2] o11s: (nl80211/cfg80211) support for mesh interfaces and mesh paths

On Mon, 2008-02-25 at 17:03 +0100, Johannes Berg wrote:
> Can you do that in both nl80211 and mac80211 for both STAs and paths?
> Look at net/netlink/genetlink.c ctrl_dumpfamily() for an example.

I'm not sure I completely get what changes are necessary.

What I understand is that I should acquire (if idx == 0) and release
(just before returning -ENOENT) the rtnl_lock() from within (mac80211 or
equivalent) dump_station function instead of from nl80211_dump_station.
Is this the whole idea?

--

-- 
Luis Carlos Cobo Rus       GnuPG ID: 44019B60
cozybit Inc.

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@...
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 3 comments |
headers
Alexey Zaytsev | 1 Mar 02:39
Picon
Gravatar

Re: [PATCH stable] b43: Backport bcm4311 fix

On Sat, Mar 1, 2008 at 3:29 AM, Greg KH <greg@...> wrote:
> On Fri, Feb 29, 2008 at 12:55:41PM +0100, Michael Buesch wrote:
>  >     The changes include the following:
>  >
>  >     (1) Add the 802.11 rev 13 device to the ssb_device_id table to load b43.
>  >     (2) Add PHY revision 9 to the supported list.
>  >     (3) Change the 2-bit routing code for address extensions to 0b10 rather
>  >         than the 0b01 used for the 32-bit case.
>  >     (4) Remove some magic numbers in the DMA setup.
>  >
>  >     The DMA implementation for this chip supports full 64-bit addressing with
>  >     one exception. Whenever the Descriptor Ring Buffer is in high memory, a
>  >     fatal DMA error occurs. This problem was not present in 2.6.24-rc2 due
>  >     to code to "Bias the placement of kernel pages at lower PFNs". When
>  >     commit 44048d70 reverted that code, the DMA error appeared. As a "fix",
>  >     use the GFP_DMA flag when allocating the buffer for 64-bit DMA. At present,
>  >     this problem is thought to arise from a hardware error.
>
>  Is this logic upstream in 2.6.25-rcX already?  If so, do you have a git
>  id for it so that I can match them up?
>

Commit 013978b688d2a27af3ab55ca739e8c8ac7254870

>  thanks,
>
>  greg k-h
>
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
(Continue reading)

Permalink | Reply | 0 comments |
headers
Johannes Berg | 1 Mar 10:26
Favicon

Re: [PATCH 01/13 v2] o11s: (nl80211/cfg80211) support for mesh interfaces and mesh paths


On Fri, 2008-02-29 at 17:31 -0800, Luis Carlos Cobo wrote:
> On Mon, 2008-02-25 at 17:03 +0100, Johannes Berg wrote:
> > Can you do that in both nl80211 and mac80211 for both STAs and paths?
> > Look at net/netlink/genetlink.c ctrl_dumpfamily() for an example.
> 
> I'm not sure I completely get what changes are necessary.
> 
> What I understand is that I should acquire (if idx == 0) and release
> (just before returning -ENOENT) the rtnl_lock() from within (mac80211 or
> equivalent) dump_station function instead of from nl80211_dump_station.
> Is this the whole idea?

I think it's a bit more complicated because nl80211's dump_station() can
also be invoked multiple times.

To guarantee the cfg80211 rtnl_lock() promise, dump_station() should
acquire the rtnl and all locks it needs when it first enters the
function (oh. that's actually a bug in the other functions too, they
should acquire the mutex conditionally, will fix).

mac80211 also needs to acquire the sta_lock because otherwise stations
can be added or removed while dumping.

I suppose the struct netlink_callback needs to be passed through to
mac80211's dump function with the limitation that the first two entries
are already used by nl80211...

johannes
(Continue reading)

Permalink | Reply | 0 comments |
headers
Johannes Berg | 1 Mar 11:06
Favicon

Re: [PATCH 01/13 v2] o11s: (nl80211/cfg80211) support for mesh interfaces and mesh paths


On Fri, 2008-02-29 at 17:31 -0800, Luis Carlos Cobo wrote:
> On Mon, 2008-02-25 at 17:03 +0100, Johannes Berg wrote:
> > Can you do that in both nl80211 and mac80211 for both STAs and paths?
> > Look at net/netlink/genetlink.c ctrl_dumpfamily() for an example.
> 
> I'm not sure I completely get what changes are necessary.
> 
> What I understand is that I should acquire (if idx == 0) and release
> (just before returning -ENOENT) the rtnl_lock() from within (mac80211 or
> equivalent) dump_station function instead of from nl80211_dump_station.
> Is this the whole idea?

Actually. This is a bit weird, I think I'm misunderstanding how it is
supposed to work. I'll dig a bit and let you know.

johannes
Permalink | Reply | 0 comments |
headers
Johannes Berg | 1 Mar 11:16
Favicon

Re: [PATCH 01/13 v2] o11s: (nl80211/cfg80211) support for mesh interfaces and mesh paths


On Fri, 2008-02-29 at 17:31 -0800, Luis Carlos Cobo wrote:
> On Mon, 2008-02-25 at 17:03 +0100, Johannes Berg wrote:
> > Can you do that in both nl80211 and mac80211 for both STAs and paths?
> > Look at net/netlink/genetlink.c ctrl_dumpfamily() for an example.
> 
> I'm not sure I completely get what changes are necessary.

Actually, none are. I was totally wrong about all the stuff. Sorry.

> What I understand is that I should acquire (if idx == 0) and release
> (just before returning -ENOENT) the rtnl_lock() from within (mac80211 or
> equivalent) dump_station function instead of from nl80211_dump_station.
> Is this the whole idea?

That was completely wrong, I was trying to guarantee a consistent dump
but that is impossible.

johannes
Permalink | Reply | 0 comments |
headers
Zbyszek Szmek | 1 Mar 11:27
Picon
Favicon
Gravatar

problem with b43 (bcm43xx works)

Hi,
I have trouble getting b43 to work with my card. The trouble 
seems to be with the transmit/receive power, but I have no 
idea what to try next.

The card is:
lspci -vvnn -s 01:06.0
01:06.0 Network controller [0280]: Broadcom Corporation BCM4318 [AirForce One 54g] 802.11g Wireless
LAN 
Controller [14e4:4318] (rev 02)
	Subsystem: ASUSTeK Computer Inc. Unknown device [1043:100f]
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 32
	Interrupt: pin A routed to IRQ 16
	Region 0: Memory at fdffe000 (32-bit, non-prefetchable) [size=8K]

When I use the old driver, in dmesg I get:
bcm43xx: Chip ID 0x4318, rev 0x2
bcm43xx: Number of cores: 4
bcm43xx: Core 0: ID 0x800, rev 0xd, vendor 0x4243
bcm43xx: Core 1: ID 0x812, rev 0x9, vendor 0x4243
bcm43xx: Core 2: ID 0x804, rev 0xc, vendor 0x4243
bcm43xx: Core 3: ID 0x80d, rev 0x7, vendor 0x4243
bcm43xx: PHY connected
bcm43xx: Detected PHY: Analog: 3, Type 2, Revision 7
bcm43xx: Detected Radio: ID: 8205017f (Manuf: 17f Ver: 2050 Rev: 8)
bcm43xx: Radio initialized
bcm43xx: Radio initialized
bcm43xx: Microcode rev 0x127, pl 0xe (2005-04-18  02:36:27)
(Continue reading)

Permalink | Reply | 0 comments |
headers
Johannes Berg | 1 Mar 12:09
Favicon

Re: [RFC] p54: spi driver


> To build mac80211, I modified compat (patch in separate mail)

patch merged.

> to make it work with 2.6.21 (and not try to build PCI drivers
> all the time!), the resulting modules can be loaded fine on
> my N810 and seem to work. In order to load mac80211 you need
> to have crypto support in the kernel. That isn't enabled in
> the default N810 kernel (sigh), but I managed to build the
> crypto code as an out of tree module in a way that in-kernel
> code assumes crypto is not present while modules can use it
> fine. I guess I should add an "N810" category to my homepage
> and write about all this there.

http://johannes.sipsolutions.net/N810

johannes
Permalink | Reply | 0 comments |
headers
Adam Baker | 1 Mar 12:55
Picon

Re: FIF_ filter flags

On Saturday 01 March 2008 00:09, Johannes Berg wrote:
> Hi,
>
> > For example rt2x00 devices only have one promiscuous mode that covers
> > traffic in the same and other BSSes therefore if either of
> > FIF_PROMISC_IN_BSS or FIF_OTHER_BSS are set then the driver will set both
> > of them in the returned flags value.
> >
> > It will also for some devices set the FIF_ALLMULTI flag if mc_count is
> > non zero.
> >
> > If this behaviour is considered desirable then I'll keep it working when
> > making the change but if not I'll remove it.
>
> Interesting. I don't think I have an opinion right now. I wanted to be
> strict about clearing the flags so that you don't end up with a flag
> that we never get traffic for, but I can't imagine any check where you'd
> want to know "do I get traffic XY".

The only way I think it might be useful is if it allows mac80211 to not bother 
with checks that it would otherwise do, for example if mac80211 didn't want 
to pass multicast packets that were not for us up to the higher stack layers 
it would know that if FIF_ALLMULTI got set it needed to do some filtering but 
if it wasn't set the hardware had a working multicast address filter.

>
> How do you keep track of that anyway? Say somebody enables
> FIF_PROMISC_IN_BSS and you also set FIF_OTHER_BSS, then when
> FIF_PROMISC_IN_BSS is disabled again FIF_OTHER_BSS should be disabled
> too but how know that it wasn't set in the meantime? I think that says
(Continue reading)

Permalink | Reply | 1 comment |

Gmane