Hello,
I have a question regarding the following patch:
http://permalink.gmane.org/gmane.linux.kernel.wireless.general/75638
The commit message says:
brcmsmac doesn't yet use bcma, but both drivers attempt to claim the same
device. For now, turn of brcmsmac if bcma is enabled.
I think it's not quite complete: both driver claim the same devices
(actually that's not entirely true since b43/bcma can drive on more
card) but in the case of b43/bcma not all cards are actually working.
For example I'm using BCM4313 card with an unsupported phy
(B43_PHYTYPE_LCN) so it's basically not supported by b43/bcma.
So I'm wondering if b43/bcma should be simply disabled until it got
the same level of support as brcmsmac ?
Thanks
--
Francis
On Tue, Sep 13, 2011 at 3:28 PM, John W. Linville
<[email protected]> wrote:
> On Tue, Sep 13, 2011 at 09:03:13AM +0200, Francis Moreau wrote:
>> 2011/9/12 Rafał Miłecki <[email protected]>:
>
>> > The real solution is to add bcma driver support in brcmsmac and ssb
>> > driver support in brcmfmac. Then you can always use bcma and:
>> > 1) If b43 will load and detect unsupported PHY, it will release the BCMA's core
>> > 2) brcmsmac will be loaded to let it support the core
>> >
>>
>> Thanks for the description.
>>
>> But what should be done for the time being (3.1-rc5) ?
>
> Turn-off CONFIG_B43_BCMA.
>
Does the b43/bcma driver support some cards that the brcmsmac one doesn't ?
--
Francis
2011/9/13 Rafał Miłecki <[email protected]>:
> 2011/9/13 John W. Linville <[email protected]>:
>> On Tue, Sep 13, 2011 at 09:03:13AM +0200, Francis Moreau wrote:
>>> 2011/9/12 Rafał Miłecki <[email protected]>:
>>
>>> > The real solution is to add bcma driver support in brcmsmac and ssb
>>> > driver support in brcmfmac. Then you can always use bcma and:
>>> > 1) If b43 will load and detect unsupported PHY, it will release the BCMA's core
>>> > 2) brcmsmac will be loaded to let it support the core
>>> >
>>>
>>> Thanks for the description.
>>>
>>> But what should be done for the time being (3.1-rc5) ?
>>
>> Turn-off CONFIG_B43_BCMA.
>
> Well, that won't prevent bcma from loading and taking the (PCI)
> device. brcmsmac still won't be able to grab that device.
> CONFIG_B43_BCMA doesn't affect bcma bus driver.
>
> There are 2 drivers requesting for the same PCI ids: bcma and
> brcmsmac. You may want to just blacklist bcma if you're going to use
> brcmsmac.
>
Will it work if bcma is builtin in the kernel (not configured as module) ?
Thanks
--
Francis
On Tue, Sep 13, 2011 at 03:37:12PM +0200, Francis Moreau wrote:
> On Tue, Sep 13, 2011 at 3:28 PM, John W. Linville
> <[email protected]> wrote:
> > On Tue, Sep 13, 2011 at 09:03:13AM +0200, Francis Moreau wrote:
> >> 2011/9/12 Rafał Miłecki <[email protected]>:
> >
> >> > The real solution is to add bcma driver support in brcmsmac and ssb
> >> > driver support in brcmfmac. Then you can always use bcma and:
> >> > 1) If b43 will load and detect unsupported PHY, it will release the BCMA's core
> >> > 2) brcmsmac will be loaded to let it support the core
> >> >
> >>
> >> Thanks for the description.
> >>
> >> But what should be done for the time being (3.1-rc5) ?
> >
> > Turn-off CONFIG_B43_BCMA.
> >
>
> Does the b43/bcma driver support some cards that the brcmsmac one doesn't ?
Not any BCMA-based ones.
--
John W. Linville Someday the world will need a hero, and you
[email protected] might be all we have. Be ready.
W dniu 16 września 2011 13:25 użytkownik Arend van Spriel
<[email protected]> napisał:
> On 09/16/2011 01:20 PM, Rafał Miłecki wrote:
>>
>> W dniu 16 września 2011 13:13 użytkownik Arend van Spriel
>> <[email protected]> napisał:
>>>
>>> On 09/16/2011 12:55 PM, Rafał Miłecki wrote:
>>>>
>>>> 2011/9/16 Arend Van Spriel<[email protected]>:
>>>>>>
>>>>>> From: Rafał Miłecki [mailto:[email protected]]
>>>>>> Sent: vrijdag 16 september 2011 12:43
>>>>>> To: Greg KH; [email protected]; Arend Van Spriel
>>>>>> Cc: John W. Linville; Francis Moreau
>>>>>> Subject: Re: About the patch: "staging: brcm80211: only enable
>>>>>> brcmsmac
>>>>>> if bcma is not set"
>>>>>>
>>>>>>
>>>>>> You're right, it wasn't a good idea.
>>>>>>
>>>>>> Arend: I've just sent patches to John giving you symbols needed by LCN
>>>>>> code. If there is something more missing, I didn't notice it yet, feel
>>>>>> free to report. AFAICS you should be able now to convert brcmsmac to
>>>>>> use bcma, if you wish to.
>>>>>>
>>>>>> --
>>>>>> Rafał
>>>>>
>>>>> Hi Rafał,
>>>>>
>>>>> The last time I refreshed my local wireless-testing repo was a while
>>>>> ago
>>>>> since kernel.org misery. Last commit being:
>>>>>
>>>>> commit b197329717cf054f4dbd8bd86196401bef738978
>>>>> Merge: a7c053d 93ee7a9
>>>>> Author: John W. Linville<[email protected]>
>>>>> Date: Mon Aug 15 14:01:50 2011 -0700
>>>>>
>>>>> Merge branch 'master' of
>>>>> git://git.kernel.org/pub/scm/linux/kernel/git/torva
>>>>>
>>>>> Conflicts:
>>>>> drivers/staging/ath6kl/miscdrv/ar3kps/ar3kpsparser.c
>>>>>
>>>>> Could you indicate what patches I am missing. If you can provide those
>>>>> to
>>>>> me that would be awesome. For BCMA this is the latest I have:
>>>>
>>>> I've *just* sent my patches, they weren't applied yet. I was sure
>>>> you're subscribed to linux-wireless and you received them.
>>>>
>>>> Please take a look at:
>>>> [PATCH 1/6] bcma: cc: export more control functions
>>>> Message-Id:<[email protected]>
>>>
>>> Ok,
>>>
>>> I saw that one. I was just trying to get the other bcma patches in a
>>> quickly
>>> manner, but I will start digging through 2 months of wireless patch
>>> emails
>>> :-(
>>
>> All the other patches were applied to wireless-next. Take a look at
>> git://git.infradead.org/users/linville/wireless-next.git
>
> Ah, noticed wireless-testing is also there. Missed the news about this
> (temporary) move to infradead.
OK. Still, it would be nicer to have you involved in brcmsmac's future
discussion, rather than just getting patches.
You spent *a lot* of time on cleaning brcm8021. You have to spend even
more. A very quick check gives:
> git log drivers/staging/brcm80211/brcmsmac/ | egrep '^commit' | wc -l
301
That doesn't include changes done before brcmsmac was created (when
brcmsmac was brcm80211).
Isn't it at least worth considering getting involved in b43?
--
Rafał
Hello,
2011/9/12 Rafał Miłecki <[email protected]>:
> 2011/9/8 Francis Moreau <[email protected]>:
>> Hello,
>>
>> I have a question regarding the following patch:
>> http://permalink.gmane.org/gmane.linux.kernel.wireless.general/75638
>>
>> The commit message says:
>>
>> brcmsmac doesn't yet use bcma, but both drivers attempt to claim the same
>> device. For now, turn of brcmsmac if bcma is enabled.
>>
>> I think it's not quite complete: both driver claim the same devices
>> (actually that's not entirely true since b43/bcma can drive on more
>> card) but in the case of b43/bcma not all cards are actually working.
>> For example I'm using BCM4313 card with an unsupported phy
>> (B43_PHYTYPE_LCN) so it's basically not supported by b43/bcma.
>>
>> So I'm wondering if b43/bcma should be simply disabled until it got
>> the same level of support as brcmsmac ?
>
> I'm working on LCN support in b43 (BCM4313), static initialization is
> already done. Should see more results soon.
>
> The problem is that brcmsmac duplicates code present in the bcma
> driver. It doesn't use bcma bus architecture.
>
> The real solution is to add bcma driver support in brcmsmac and ssb
> driver support in brcmfmac. Then you can always use bcma and:
> 1) If b43 will load and detect unsupported PHY, it will release the BCMA's core
> 2) brcmsmac will be loaded to let it support the core
>
Thanks for the description.
But what should be done for the time being (3.1-rc5) ?
--
Francis
2011/9/16 Arend Van Spriel <[email protected]>:
>> From: Rafał Miłecki [mailto:[email protected]]
>> Sent: vrijdag 16 september 2011 12:43
>> To: Greg KH; [email protected]; Arend Van Spriel
>> Cc: John W. Linville; Francis Moreau
>> Subject: Re: About the patch: "staging: brcm80211: only enable brcmsmac
>> if bcma is not set"
>>
>>
>> You're right, it wasn't a good idea.
>>
>> Arend: I've just sent patches to John giving you symbols needed by LCN
>> code. If there is something more missing, I didn't notice it yet, feel
>> free to report. AFAICS you should be able now to convert brcmsmac to
>> use bcma, if you wish to.
>>
>> --
>> Rafał
>
> Hi Rafał,
>
> The last time I refreshed my local wireless-testing repo was a while ago since kernel.org misery. Last commit being:
>
> commit b197329717cf054f4dbd8bd86196401bef738978
> Merge: a7c053d 93ee7a9
> Author: John W. Linville <[email protected]>
> Date: Mon Aug 15 14:01:50 2011 -0700
>
> Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/torva
>
> Conflicts:
> drivers/staging/ath6kl/miscdrv/ar3kps/ar3kpsparser.c
>
> Could you indicate what patches I am missing. If you can provide those to me that would be awesome. For BCMA this is the latest I have:
I've *just* sent my patches, they weren't applied yet. I was sure
you're subscribed to linux-wireless and you received them.
Please take a look at:
[PATCH 1/6] bcma: cc: export more control functions
Message-Id: <[email protected]>
--
Rafał
W dniu 14 września 2011 10:42 użytkownik Greg KH <[email protected]> napisał:
> On Tue, Sep 13, 2011 at 10:23:47PM +0200, Rafał Miłecki wrote:
>> W dniu 13 września 2011 19:44 użytkownik John W. Linville
>> <[email protected]> napisał:
>> > On Mon, Sep 12, 2011 at 11:27:20PM +0200, Rafał Miłecki wrote:
>> >
>> >> The problem is that brcmsmac duplicates code present in the bcma
>> >> driver. It doesn't use bcma bus architecture.
>> >>
>> >> The real solution is to add bcma driver support in brcmsmac and ssb
>> >> driver support in brcmfmac. Then you can always use bcma and:
>> >> 1) If b43 will load and detect unsupported PHY, it will release the BCMA's core
>> >> 2) brcmsmac will be loaded to let it support the core
>> >
>> > We are going to have to find a way to get brcmsmac into the
>> > wireless-next tree to make it feasible for the Broadcom guys to get
>> > bcma support into that driver. Do you agree?
>> >
>> > We could move it under the drivers/net/wireless tree. Or, maybe I
>> > could negotiate with Greg to keep it under the drivers/staging tree
>> > but to let me manage it under wireless-next. Or...? Do you have
>> > any thoughts on this?
>>
>> I'll be posting some bcma patches that will allow brcmsmac being
>> converted to bcma support. Currently we don't export few trivial ops
>> in bcma, that are needed by b43/brcmsmac.
>>
>> Could we ask Greg after that, to merge wireless-next into staging?
>
> No.
>
>> That would provide Broadcom guys all the symbols they need.
>
> Yes, or they can wait for the next merge window as that will make things
> easier for everyone involved, right?
>
>> AFAIK git is clever enough to allow Linux easily merge both: Greg's
>> tree and wireless-next tree. Without conflicts coming from
>> "duplicated" patches.
>
> It is, but I really don't want to be dragging around the wireless-next
> tree in staging-next, just like I doubt John would want to drag
> staging-next into wireless-next.
You're right, it wasn't a good idea.
Arend: I've just sent patches to John giving you symbols needed by LCN
code. If there is something more missing, I didn't notice it yet, feel
free to report. AFAICS you should be able now to convert brcmsmac to
use bcma, if you wish to.
--
Rafał
W dniu 14 września 2011 11:23 użytkownik Arend Van Spriel
<[email protected]> napisał:
> For my bcma integration effort (which is already stale due to our brcmsmac cleanup) I simply took "wireless-next" bcma using meld. Was surprised that I also needed to do this for ssb as there are some include dependencies. In early bcma discussions a strong preference was given (by Michael if I am correct) to keep bcma independent from ssb at the cost of some duplication. For include files this preference might be less strong, but I still think it is a good idea to have these chip interconnect bus drivers independent from each other.
The code is independent, if some includes are not, that should be
reported & fixed.
--
Rafał
PiBGcm9tOiBGcmFuY2lzIE1vcmVhdSBbbWFpbHRvOmZyYW5jaXMubW9yb0BnbWFpbC5jb21dIA0K
PiBTZW50OiB3b2Vuc2RhZyAxNCBzZXB0ZW1iZXIgMjAxMSA4OjU0DQo+IFRvOiBSYWZhxYIgTWnF
gmVja2kNCj4gQ2M6IEpvaG4gVy4gTGludmlsbGU7IEFyZW5kIFZhbiBTcHJpZWw7IGxpbnV4LXdp
cmVsZXNzQHZnZXIua2VybmVsLm9yZzsgZ3JlZ2toQHN1c2UuZGUNCj4gU3ViamVjdDogUmU6IEFi
b3V0IHRoZSBwYXRjaDogInN0YWdpbmc6IGJyY204MDIxMTogb25seSBlbmFibGUgYnJjbXNtYWMg
aWYgYmNtYSBpcyBub3Qgc2V0Ig0KPg0KPg0KPiBXaWxsIGl0IHdvcmsgaWYgYmNtYSBpcyBidWls
dGluIGluIHRoZSBrZXJuZWwgKG5vdCBjb25maWd1cmVkIGFzIG1vZHVsZSkgPw0KDQpIaSBGcmFu
Y2lzLA0KDQpOb3BlLiBQZXJoYXBzIGhhdmluZyBicmNtc21hYyBidWlsdC1pbiB3b3VsZCBoZWxw
LiBTdGlsbCB0aGUgZWFzaWVzdCB3YXkgd291bGQgYmUgdG8gYmxhY2tsaXN0IGJjbWEgb24geW91
ciBzeXN0ZW0uIE1heSBkZXBlbmQgb24geW91ciBkaXN0cm8gaG93IHRvIGRvIHRoaXMuDQoNCkdy
LiBBdlMNCg==
2011/9/13 John W. Linville <[email protected]>:
> On Tue, Sep 13, 2011 at 09:03:13AM +0200, Francis Moreau wrote:
>> 2011/9/12 Rafał Miłecki <[email protected]>:
>
>> > The real solution is to add bcma driver support in brcmsmac and ssb
>> > driver support in brcmfmac. Then you can always use bcma and:
>> > 1) If b43 will load and detect unsupported PHY, it will release the BCMA's core
>> > 2) brcmsmac will be loaded to let it support the core
>> >
>>
>> Thanks for the description.
>>
>> But what should be done for the time being (3.1-rc5) ?
>
> Turn-off CONFIG_B43_BCMA.
Well, that won't prevent bcma from loading and taking the (PCI)
device. brcmsmac still won't be able to grab that device.
CONFIG_B43_BCMA doesn't affect bcma bus driver.
There are 2 drivers requesting for the same PCI ids: bcma and
brcmsmac. You may want to just blacklist bcma if you're going to use
brcmsmac.
--
Rafał
On 09/14/2011 10:18 PM, Rafał Miłecki wrote:
> W dniu 14 września 2011 11:23 użytkownik Arend Van Spriel
> <[email protected]> napisał:
>> For my bcma integration effort (which is already stale due to our brcmsmac cleanup) I simply took "wireless-next" bcma using meld. Was surprised that I also needed to do this for ssb as there are some include dependencies. In early bcma discussions a strong preference was given (by Michael if I am correct) to keep bcma independent from ssb at the cost of some duplication. For include files this preference might be less strong, but I still think it is a good idea to have these chip interconnect bus drivers independent from each other.
> The code is independent, if some includes are not, that should be
> reported& fixed.
No problem. Will look into it.
Gr. AvS
W dniu 13 września 2011 19:44 użytkownik John W. Linville
<[email protected]> napisał:
> On Mon, Sep 12, 2011 at 11:27:20PM +0200, Rafał Miłecki wrote:
>
>> The problem is that brcmsmac duplicates code present in the bcma
>> driver. It doesn't use bcma bus architecture.
>>
>> The real solution is to add bcma driver support in brcmsmac and ssb
>> driver support in brcmfmac. Then you can always use bcma and:
>> 1) If b43 will load and detect unsupported PHY, it will release the BCMA's core
>> 2) brcmsmac will be loaded to let it support the core
>
> We are going to have to find a way to get brcmsmac into the
> wireless-next tree to make it feasible for the Broadcom guys to get
> bcma support into that driver. Do you agree?
>
> We could move it under the drivers/net/wireless tree. Or, maybe I
> could negotiate with Greg to keep it under the drivers/staging tree
> but to let me manage it under wireless-next. Or...? Do you have
> any thoughts on this?
I'll be posting some bcma patches that will allow brcmsmac being
converted to bcma support. Currently we don't export few trivial ops
in bcma, that are needed by b43/brcmsmac.
Could we ask Greg after that, to merge wireless-next into staging?
That would provide Broadcom guys all the symbols they need.
AFAIK git is clever enough to allow Linux easily merge both: Greg's
tree and wireless-next tree. Without conflicts coming from
"duplicated" patches.
--
Rafał
On Tue, Sep 13, 2011 at 01:44:16PM -0500, Larry Finger wrote:
> On 09/13/2011 12:44 PM, John W. Linville wrote:
> >
> >We are going to have to find a way to get brcmsmac into the
> >wireless-next tree to make it feasible for the Broadcom guys to get
> >bcma support into that driver. Do you agree?
> >
> >We could move it under the drivers/net/wireless tree. Or, maybe I
> >could negotiate with Greg to keep it under the drivers/staging tree
> >but to let me manage it under wireless-next. Or...? Do you have
> >any thoughts on this?
>
> Based on the earlier comments, I still see lots of problems in
> getting brcmsmac into the drivers/net/wireless tree; however, the
> solution where Greg lets you manage that part of drivers/staging
> does not seem to cause too many problems, as long as he is kept in
> the loop. If you could push those changes through Greg rather than
> DaveM, I don't think he would lose any control.
I don't think there is any reasonable way to push one tree through
two different upstream paths, unless both upstreams want all the tree
has to offer. I don't see a way to both segregate brcmsmac commits
from the rest of the tree and yet have the bcma commits available
to brcmsmac.
John
--
John W. Linville Someday the world will need a hero, and you
[email protected] might be all we have. Be ready.
On 09/13/2011 12:44 PM, John W. Linville wrote:
>
> We are going to have to find a way to get brcmsmac into the
> wireless-next tree to make it feasible for the Broadcom guys to get
> bcma support into that driver. Do you agree?
>
> We could move it under the drivers/net/wireless tree. Or, maybe I
> could negotiate with Greg to keep it under the drivers/staging tree
> but to let me manage it under wireless-next. Or...? Do you have
> any thoughts on this?
Based on the earlier comments, I still see lots of problems in getting brcmsmac
into the drivers/net/wireless tree; however, the solution where Greg lets you
manage that part of drivers/staging does not seem to cause too many problems, as
long as he is kept in the loop. If you could push those changes through Greg
rather than DaveM, I don't think he would lose any control.
Larry
UmFmYWwsDQoNCkZyYW5jaXMgaGFzIGEgNDMxMy4gQXMgc3VwcG9ydCBmb3IgdGhhdCBkZXZpY2Ug
aXMgbm90IHlldCBpbiBiNDMgeW91IGNvdWxkIGNvbnNpZGVyIG5vdCBjbGFpbWluZyBpdCBmb3Ig
bm93IGluIGJjbWEuDQoNCkdyLiBBdlMNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZy
b206IFJhZmHFgiBNacWCZWNraSBbbWFpbHRvOnphamVjNUBnbWFpbC5jb21dIA0KU2VudDogZGlu
c2RhZyAxMyBzZXB0ZW1iZXIgMjAxMSAyMjoyNg0KVG86IEpvaG4gVy4gTGludmlsbGUNCkNjOiBG
cmFuY2lzIE1vcmVhdTsgQXJlbmQgVmFuIFNwcmllbDsgbGludXgtd2lyZWxlc3NAdmdlci5rZXJu
ZWwub3JnOyBncmVna2hAc3VzZS5kZQ0KU3ViamVjdDogUmU6IEFib3V0IHRoZSBwYXRjaDogInN0
YWdpbmc6IGJyY204MDIxMTogb25seSBlbmFibGUgYnJjbXNtYWMgaWYgYmNtYSBpcyBub3Qgc2V0
Ig0KDQoyMDExLzkvMTMgSm9obiBXLiBMaW52aWxsZSA8bGludmlsbGVAdHV4ZHJpdmVyLmNvbT46
DQo+IE9uIFR1ZSwgU2VwIDEzLCAyMDExIGF0IDA5OjAzOjEzQU0gKzAyMDAsIEZyYW5jaXMgTW9y
ZWF1IHdyb3RlOg0KPj4gMjAxMS85LzEyIFJhZmHFgiBNacWCZWNraSA8emFqZWM1QGdtYWlsLmNv
bT46DQo+DQo+PiA+IFRoZSByZWFsIHNvbHV0aW9uIGlzIHRvIGFkZCBiY21hIGRyaXZlciBzdXBw
b3J0IGluIGJyY21zbWFjIGFuZCBzc2INCj4+ID4gZHJpdmVyIHN1cHBvcnQgaW4gYnJjbWZtYWMu
IFRoZW4geW91IGNhbiBhbHdheXMgdXNlIGJjbWEgYW5kOg0KPj4gPiAxKSBJZiBiNDMgd2lsbCBs
b2FkIGFuZCBkZXRlY3QgdW5zdXBwb3J0ZWQgUEhZLCBpdCB3aWxsIHJlbGVhc2UgdGhlIEJDTUEn
cyBjb3JlDQo+PiA+IDIpIGJyY21zbWFjIHdpbGwgYmUgbG9hZGVkIHRvIGxldCBpdCBzdXBwb3J0
IHRoZSBjb3JlDQo+PiA+DQo+Pg0KPj4gVGhhbmtzIGZvciB0aGUgZGVzY3JpcHRpb24uDQo+Pg0K
Pj4gQnV0IHdoYXQgc2hvdWxkIGJlIGRvbmUgZm9yIHRoZSB0aW1lIGJlaW5nICgzLjEtcmM1KSA/
DQo+DQo+IFR1cm4tb2ZmIENPTkZJR19CNDNfQkNNQS4NCg0KV2VsbCwgdGhhdCB3b24ndCBwcmV2
ZW50IGJjbWEgZnJvbSBsb2FkaW5nIGFuZCB0YWtpbmcgdGhlIChQQ0kpDQpkZXZpY2UuIGJyY21z
bWFjIHN0aWxsIHdvbid0IGJlIGFibGUgdG8gZ3JhYiB0aGF0IGRldmljZS4NCkNPTkZJR19CNDNf
QkNNQSBkb2Vzbid0IGFmZmVjdCBiY21hIGJ1cyBkcml2ZXIuDQoNClRoZXJlIGFyZSAyIGRyaXZl
cnMgcmVxdWVzdGluZyBmb3IgdGhlIHNhbWUgUENJIGlkczogYmNtYSBhbmQNCmJyY21zbWFjLiBZ
b3UgbWF5IHdhbnQgdG8ganVzdCBibGFja2xpc3QgYmNtYSBpZiB5b3UncmUgZ29pbmcgdG8gdXNl
DQpicmNtc21hYy4NCg0KLS0gDQpSYWZhxYINCg0K
On Tue, Sep 13, 2011 at 10:23:47PM +0200, Rafał Miłecki wrote:
> W dniu 13 września 2011 19:44 użytkownik John W. Linville
> <[email protected]> napisał:
> > On Mon, Sep 12, 2011 at 11:27:20PM +0200, Rafał Miłecki wrote:
> >
> >> The problem is that brcmsmac duplicates code present in the bcma
> >> driver. It doesn't use bcma bus architecture.
> >>
> >> The real solution is to add bcma driver support in brcmsmac and ssb
> >> driver support in brcmfmac. Then you can always use bcma and:
> >> 1) If b43 will load and detect unsupported PHY, it will release the BCMA's core
> >> 2) brcmsmac will be loaded to let it support the core
> >
> > We are going to have to find a way to get brcmsmac into the
> > wireless-next tree to make it feasible for the Broadcom guys to get
> > bcma support into that driver. Do you agree?
> >
> > We could move it under the drivers/net/wireless tree. Or, maybe I
> > could negotiate with Greg to keep it under the drivers/staging tree
> > but to let me manage it under wireless-next. Or...? Do you have
> > any thoughts on this?
>
> I'll be posting some bcma patches that will allow brcmsmac being
> converted to bcma support. Currently we don't export few trivial ops
> in bcma, that are needed by b43/brcmsmac.
>
> Could we ask Greg after that, to merge wireless-next into staging?
No.
> That would provide Broadcom guys all the symbols they need.
Yes, or they can wait for the next merge window as that will make things
easier for everyone involved, right?
> AFAIK git is clever enough to allow Linux easily merge both: Greg's
> tree and wireless-next tree. Without conflicts coming from
> "duplicated" patches.
It is, but I really don't want to be dragging around the wireless-next
tree in staging-next, just like I doubt John would want to drag
staging-next into wireless-next.
thanks,
greg k-h
On Mon, Sep 12, 2011 at 11:27:20PM +0200, Rafał Miłecki wrote:
> The problem is that brcmsmac duplicates code present in the bcma
> driver. It doesn't use bcma bus architecture.
>
> The real solution is to add bcma driver support in brcmsmac and ssb
> driver support in brcmfmac. Then you can always use bcma and:
> 1) If b43 will load and detect unsupported PHY, it will release the BCMA's core
> 2) brcmsmac will be loaded to let it support the core
We are going to have to find a way to get brcmsmac into the
wireless-next tree to make it feasible for the Broadcom guys to get
bcma support into that driver. Do you agree?
We could move it under the drivers/net/wireless tree. Or, maybe I
could negotiate with Greg to keep it under the drivers/staging tree
but to let me manage it under wireless-next. Or...? Do you have
any thoughts on this?
John
--
John W. Linville Someday the world will need a hero, and you
[email protected] might be all we have. Be ready.
2011/9/8 Francis Moreau <[email protected]>:
> Hello,
>
> I have a question regarding the following patch:
> http://permalink.gmane.org/gmane.linux.kernel.wireless.general/75638
>
> The commit message says:
>
> brcmsmac doesn't yet use bcma, but both drivers attempt to claim the same
> device. For now, turn of brcmsmac if bcma is enabled.
>
> I think it's not quite complete: both driver claim the same devices
> (actually that's not entirely true since b43/bcma can drive on more
> card) but in the case of b43/bcma not all cards are actually working.
> For example I'm using BCM4313 card with an unsupported phy
> (B43_PHYTYPE_LCN) so it's basically not supported by b43/bcma.
>
> So I'm wondering if b43/bcma should be simply disabled until it got
> the same level of support as brcmsmac ?
I'm working on LCN support in b43 (BCM4313), static initialization is
already done. Should see more results soon.
The problem is that brcmsmac duplicates code present in the bcma
driver. It doesn't use bcma bus architecture.
The real solution is to add bcma driver support in brcmsmac and ssb
driver support in brcmfmac. Then you can always use bcma and:
1) If b43 will load and detect unsupported PHY, it will release the BCMA's core
2) brcmsmac will be loaded to let it support the core
--
Rafał
W dniu 14 września 2011 11:11 użytkownik Arend Van Spriel
<[email protected]> napisał:
> Francis has a 4313. As support for that device is not yet in b43 you could consider not claiming it for now in bcma.
There's a little conflict theory vs. practice. Driver bcma supports
14e4:4727 fine, the problem is that there is no additional driver
using bcma bus and having support for LCN-PHY.
So in theory there is not reason to drop 14e4:4727 from bcma.
In practice we could do that to avoid conflict between bcma and brcmsmac.
Support for LCN in b43 is WIP, we already have a lot of code, so the
whole problem will disappear soon anyway.
--
Rafał
2011/9/14 Arend Van Spriel <[email protected]>:
>
> Francis has a 4313. As support for that device is not yet in b43 you could consider not claiming it for now in bcma.
>
yes that's right.
That would be true for all cards depending on those broken phy devs:
drivers/net/wireless/b43/Kconfig:config B43_PHY_HT
drivers/net/wireless/b43/Kconfig: bool "Support for HT-PHY
devices (BROKEN)"
drivers/net/wireless/b43/Kconfig: Support for the HT-PHY.
drivers/net/wireless/b43/Kconfig:config B43_PHY_LCN
drivers/net/wireless/b43/Kconfig: bool "Support for LCN-PHY
devices (BROKEN)"
drivers/net/wireless/b43/Kconfig: Support for the LCN-PHY.
--
Francis
W dniu 16 września 2011 13:13 użytkownik Arend van Spriel
<[email protected]> napisał:
> On 09/16/2011 12:55 PM, Rafał Miłecki wrote:
>>
>> 2011/9/16 Arend Van Spriel<[email protected]>:
>>>>
>>>> From: Rafał Miłecki [mailto:[email protected]]
>>>> Sent: vrijdag 16 september 2011 12:43
>>>> To: Greg KH; [email protected]; Arend Van Spriel
>>>> Cc: John W. Linville; Francis Moreau
>>>> Subject: Re: About the patch: "staging: brcm80211: only enable brcmsmac
>>>> if bcma is not set"
>>>>
>>>>
>>>> You're right, it wasn't a good idea.
>>>>
>>>> Arend: I've just sent patches to John giving you symbols needed by LCN
>>>> code. If there is something more missing, I didn't notice it yet, feel
>>>> free to report. AFAICS you should be able now to convert brcmsmac to
>>>> use bcma, if you wish to.
>>>>
>>>> --
>>>> Rafał
>>>
>>> Hi Rafał,
>>>
>>> The last time I refreshed my local wireless-testing repo was a while ago
>>> since kernel.org misery. Last commit being:
>>>
>>> commit b197329717cf054f4dbd8bd86196401bef738978
>>> Merge: a7c053d 93ee7a9
>>> Author: John W. Linville<[email protected]>
>>> Date: Mon Aug 15 14:01:50 2011 -0700
>>>
>>> Merge branch 'master' of
>>> git://git.kernel.org/pub/scm/linux/kernel/git/torva
>>>
>>> Conflicts:
>>> drivers/staging/ath6kl/miscdrv/ar3kps/ar3kpsparser.c
>>>
>>> Could you indicate what patches I am missing. If you can provide those to
>>> me that would be awesome. For BCMA this is the latest I have:
>>
>> I've *just* sent my patches, they weren't applied yet. I was sure
>> you're subscribed to linux-wireless and you received them.
>>
>> Please take a look at:
>> [PATCH 1/6] bcma: cc: export more control functions
>> Message-Id:<[email protected]>
>
> Ok,
>
> I saw that one. I was just trying to get the other bcma patches in a quickly
> manner, but I will start digging through 2 months of wireless patch emails
> :-(
All the other patches were applied to wireless-next. Take a look at
git://git.infradead.org/users/linville/wireless-next.git
--
Rafał
On 09/16/2011 01:20 PM, Rafał Miłecki wrote:
> W dniu 16 września 2011 13:13 użytkownik Arend van Spriel
> <[email protected]> napisał:
>> On 09/16/2011 12:55 PM, Rafał Miłecki wrote:
>>> 2011/9/16 Arend Van Spriel<[email protected]>:
>>>>> From: Rafał Miłecki [mailto:[email protected]]
>>>>> Sent: vrijdag 16 september 2011 12:43
>>>>> To: Greg KH; [email protected]; Arend Van Spriel
>>>>> Cc: John W. Linville; Francis Moreau
>>>>> Subject: Re: About the patch: "staging: brcm80211: only enable brcmsmac
>>>>> if bcma is not set"
>>>>>
>>>>>
>>>>> You're right, it wasn't a good idea.
>>>>>
>>>>> Arend: I've just sent patches to John giving you symbols needed by LCN
>>>>> code. If there is something more missing, I didn't notice it yet, feel
>>>>> free to report. AFAICS you should be able now to convert brcmsmac to
>>>>> use bcma, if you wish to.
>>>>>
>>>>> --
>>>>> Rafał
>>>> Hi Rafał,
>>>>
>>>> The last time I refreshed my local wireless-testing repo was a while ago
>>>> since kernel.org misery. Last commit being:
>>>>
>>>> commit b197329717cf054f4dbd8bd86196401bef738978
>>>> Merge: a7c053d 93ee7a9
>>>> Author: John W. Linville<[email protected]>
>>>> Date: Mon Aug 15 14:01:50 2011 -0700
>>>>
>>>> Merge branch 'master' of
>>>> git://git.kernel.org/pub/scm/linux/kernel/git/torva
>>>>
>>>> Conflicts:
>>>> drivers/staging/ath6kl/miscdrv/ar3kps/ar3kpsparser.c
>>>>
>>>> Could you indicate what patches I am missing. If you can provide those to
>>>> me that would be awesome. For BCMA this is the latest I have:
>>> I've *just* sent my patches, they weren't applied yet. I was sure
>>> you're subscribed to linux-wireless and you received them.
>>>
>>> Please take a look at:
>>> [PATCH 1/6] bcma: cc: export more control functions
>>> Message-Id:<[email protected]>
>> Ok,
>>
>> I saw that one. I was just trying to get the other bcma patches in a quickly
>> manner, but I will start digging through 2 months of wireless patch emails
>> :-(
> All the other patches were applied to wireless-next. Take a look at
> git://git.infradead.org/users/linville/wireless-next.git
Ah, noticed wireless-testing is also there. Missed the news about this
(temporary) move to infradead.
Thanks,
AvS
On Tue, Sep 13, 2011 at 09:03:13AM +0200, Francis Moreau wrote:
> 2011/9/12 Rafał Miłecki <[email protected]>:
> > The real solution is to add bcma driver support in brcmsmac and ssb
> > driver support in brcmfmac. Then you can always use bcma and:
> > 1) If b43 will load and detect unsupported PHY, it will release the BCMA's core
> > 2) brcmsmac will be loaded to let it support the core
> >
>
> Thanks for the description.
>
> But what should be done for the time being (3.1-rc5) ?
Turn-off CONFIG_B43_BCMA.
--
John W. Linville Someday the world will need a hero, and you
[email protected] might be all we have. Be ready.
PiBGcm9tOiBSYWZhxYIgTWnFgmVja2kgW21haWx0bzp6YWplYzVAZ21haWwuY29tXQ0KPiBTZW50
OiB2cmlqZGFnIDE2IHNlcHRlbWJlciAyMDExIDEyOjQzDQo+IFRvOiBHcmVnIEtIOyBsaW51eC13
aXJlbGVzc0B2Z2VyLmtlcm5lbC5vcmc7IEFyZW5kIFZhbiBTcHJpZWwNCj4gQ2M6IEpvaG4gVy4g
TGludmlsbGU7IEZyYW5jaXMgTW9yZWF1DQo+IFN1YmplY3Q6IFJlOiBBYm91dCB0aGUgcGF0Y2g6
ICJzdGFnaW5nOiBicmNtODAyMTE6IG9ubHkgZW5hYmxlIGJyY21zbWFjDQo+IGlmIGJjbWEgaXMg
bm90IHNldCINCj4gDQo+IA0KPiBZb3UncmUgcmlnaHQsIGl0IHdhc24ndCBhIGdvb2QgaWRlYS4N
Cj4gDQo+IEFyZW5kOiBJJ3ZlIGp1c3Qgc2VudCBwYXRjaGVzIHRvIEpvaG4gZ2l2aW5nIHlvdSBz
eW1ib2xzIG5lZWRlZCBieSBMQ04NCj4gY29kZS4gSWYgdGhlcmUgaXMgc29tZXRoaW5nIG1vcmUg
bWlzc2luZywgSSBkaWRuJ3Qgbm90aWNlIGl0IHlldCwgZmVlbA0KPiBmcmVlIHRvIHJlcG9ydC4g
QUZBSUNTIHlvdSBzaG91bGQgYmUgYWJsZSBub3cgdG8gY29udmVydCBicmNtc21hYyB0bw0KPiB1
c2UgYmNtYSwgaWYgeW91IHdpc2ggdG8uDQo+IA0KPiAtLQ0KPiBSYWZhxYINCg0KSGkgUmFmYcWC
LA0KDQpUaGUgbGFzdCB0aW1lIEkgcmVmcmVzaGVkIG15IGxvY2FsIHdpcmVsZXNzLXRlc3Rpbmcg
cmVwbyB3YXMgYSB3aGlsZSBhZ28gc2luY2Uga2VybmVsLm9yZyBtaXNlcnkuIExhc3QgY29tbWl0
IGJlaW5nOg0KDQpjb21taXQgYjE5NzMyOTcxN2NmMDU0ZjRkYmQ4YmQ4NjE5NjQwMWJlZjczODk3
OA0KTWVyZ2U6IGE3YzA1M2QgOTNlZTdhOQ0KQXV0aG9yOiBKb2huIFcuIExpbnZpbGxlIDxsaW52
aWxsZUB0dXhkcml2ZXIuY29tPg0KRGF0ZTogICBNb24gQXVnIDE1IDE0OjAxOjUwIDIwMTEgLTA3
MDANCg0KICAgIE1lcmdlIGJyYW5jaCAnbWFzdGVyJyBvZiBnaXQ6Ly9naXQua2VybmVsLm9yZy9w
dWIvc2NtL2xpbnV4L2tlcm5lbC9naXQvdG9ydmENCiAgICANCiAgICBDb25mbGljdHM6DQogICAg
ICAgIGRyaXZlcnMvc3RhZ2luZy9hdGg2a2wvbWlzY2Rydi9hcjNrcHMvYXIza3BzcGFyc2VyLmMN
Cg0KQ291bGQgeW91IGluZGljYXRlIHdoYXQgcGF0Y2hlcyBJIGFtIG1pc3NpbmcuIElmIHlvdSBj
YW4gcHJvdmlkZSB0aG9zZSB0byBtZSB0aGF0IHdvdWxkIGJlIGF3ZXNvbWUuIEZvciBCQ01BIHRo
aXMgaXMgdGhlIGxhdGVzdCBJIGhhdmU6DQoNCiQgZ2l0IGxvZyAtMSAtLSBkcml2ZXJzL2JjbWEN
CmNvbW1pdCBkM2VjNDg0NGQ0NDljZjdhZjllNzQ5ZjczYmEyMDUyZmI3YjcyZmMyDQpNZXJnZTog
MDAwMzIzMCBkZjJlMzAxDQpBdXRob3I6IExpbnVzIFRvcnZhbGRzIDx0b3J2YWxkc0BsaW51eC1m
b3VuZGF0aW9uLm9yZz4NCkRhdGU6ICAgTW9uIEp1bCAyNSAxMzo1NjozOSAyMDExIC0wNzAwDQoN
CiAgICBNZXJnZSBicmFuY2ggJ2Zvci1saW51cycgb2YgZ2l0Oi8vZ2l0Lmtlcm5lbC5vcmcvcHVi
L3NjbS9saW51eC9rZXJuZWwvZ2l0L2ppDQogICAgDQogICAgKiAnZm9yLWxpbnVzJyBvZiBnaXQ6
Ly9naXQua2VybmVsLm9yZy9wdWIvc2NtL2xpbnV4L2tlcm5lbC9naXQvamlrb3MvdHJpdmlhbA0K
ICAgICAgZnM6IE1lcmdlIHNwbGl0IHN0cmluZ3MNCiAgICAgIHRyZWV3aWRlOiBmaXggcG90ZW50
aWFsbHkgZGFuZ2Vyb3VzIHRyYWlsaW5nICc7JyBpbiAjZGVmaW5lZCB2YWx1ZXMvZXhwcmVzDQog
ICAgICB1d2I6IEZpeCBtaXNzcGVsbGluZyBvZiBuZWlnaGJvdXJob29kIGluIGNvbW1lbnQNCiAg
ICAgIG5ldCwgbmV0ZmlsdGVyOiBSZW1vdmUgcmVkdW5kYW50IGdvdG8gaW4gZWJ0X3Vsb2dfcGFj
a2V0DQogICAgICB0cml2aWFsOiBkb24ndCB0b3VjaCBmaWxlcyB0aGF0IGFyZSByZW1vdmVkIGlu
IHRoZSBzdGFnaW5nIHRyZWUNCiAgICAgIGxpYi92c3ByaW50ZjogcmVwbGFjZSBsaW5rIHRvIERy
YWZ0IGJ5IGZpbmFsIFJGQyBudW1iZXINCg0KR3IuIEF2Uw0K
On 09/16/2011 12:55 PM, Rafał Miłecki wrote:
> 2011/9/16 Arend Van Spriel<[email protected]>:
>>> From: Rafał Miłecki [mailto:[email protected]]
>>> Sent: vrijdag 16 september 2011 12:43
>>> To: Greg KH; [email protected]; Arend Van Spriel
>>> Cc: John W. Linville; Francis Moreau
>>> Subject: Re: About the patch: "staging: brcm80211: only enable brcmsmac
>>> if bcma is not set"
>>>
>>>
>>> You're right, it wasn't a good idea.
>>>
>>> Arend: I've just sent patches to John giving you symbols needed by LCN
>>> code. If there is something more missing, I didn't notice it yet, feel
>>> free to report. AFAICS you should be able now to convert brcmsmac to
>>> use bcma, if you wish to.
>>>
>>> --
>>> Rafał
>> Hi Rafał,
>>
>> The last time I refreshed my local wireless-testing repo was a while ago since kernel.org misery. Last commit being:
>>
>> commit b197329717cf054f4dbd8bd86196401bef738978
>> Merge: a7c053d 93ee7a9
>> Author: John W. Linville<[email protected]>
>> Date: Mon Aug 15 14:01:50 2011 -0700
>>
>> Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/torva
>>
>> Conflicts:
>> drivers/staging/ath6kl/miscdrv/ar3kps/ar3kpsparser.c
>>
>> Could you indicate what patches I am missing. If you can provide those to me that would be awesome. For BCMA this is the latest I have:
> I've *just* sent my patches, they weren't applied yet. I was sure
> you're subscribed to linux-wireless and you received them.
>
> Please take a look at:
> [PATCH 1/6] bcma: cc: export more control functions
> Message-Id:<[email protected]>
Ok,
I saw that one. I was just trying to get the other bcma patches in a
quickly manner, but I will start digging through 2 months of wireless
patch emails :-(
Gr. AvS
SGkgUmFmYWwsDQoNCkZvciBteSBiY21hIGludGVncmF0aW9uIGVmZm9ydCAod2hpY2ggaXMgYWxy
ZWFkeSBzdGFsZSBkdWUgdG8gb3VyIGJyY21zbWFjIGNsZWFudXApIEkgc2ltcGx5IHRvb2sgIndp
cmVsZXNzLW5leHQiIGJjbWEgdXNpbmcgbWVsZC4gV2FzIHN1cnByaXNlZCB0aGF0IEkgYWxzbyBu
ZWVkZWQgdG8gZG8gdGhpcyBmb3Igc3NiIGFzIHRoZXJlIGFyZSBzb21lIGluY2x1ZGUgZGVwZW5k
ZW5jaWVzLiBJbiBlYXJseSBiY21hIGRpc2N1c3Npb25zIGEgc3Ryb25nIHByZWZlcmVuY2Ugd2Fz
IGdpdmVuIChieSBNaWNoYWVsIGlmIEkgYW0gY29ycmVjdCkgdG8ga2VlcCBiY21hIGluZGVwZW5k
ZW50IGZyb20gc3NiIGF0IHRoZSBjb3N0IG9mIHNvbWUgZHVwbGljYXRpb24uIEZvciBpbmNsdWRl
IGZpbGVzIHRoaXMgcHJlZmVyZW5jZSBtaWdodCBiZSBsZXNzIHN0cm9uZywgYnV0IEkgc3RpbGwg
dGhpbmsgaXQgaXMgYSBnb29kIGlkZWEgdG8gaGF2ZSB0aGVzZSBjaGlwIGludGVyY29ubmVjdCBi
dXMgZHJpdmVycyBpbmRlcGVuZGVudCBmcm9tIGVhY2ggb3RoZXIuDQoNCkdyLiBBdlMNCg0KLS0t
LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IFJhZmHFgiBNacWCZWNraSBbbWFpbHRvOnph
amVjNUBnbWFpbC5jb21dIA0KU2VudDogZGluc2RhZyAxMyBzZXB0ZW1iZXIgMjAxMSAyMjoyNA0K
VG86IEpvaG4gVy4gTGludmlsbGU7IEdyZWcgS0g7IEdyZWcgS0gNCkNjOiBGcmFuY2lzIE1vcmVh
dTsgQXJlbmQgVmFuIFNwcmllbDsgbGludXgtd2lyZWxlc3NAdmdlci5rZXJuZWwub3JnDQpTdWJq
ZWN0OiBSZTogQWJvdXQgdGhlIHBhdGNoOiAic3RhZ2luZzogYnJjbTgwMjExOiBvbmx5IGVuYWJs
ZSBicmNtc21hYyBpZiBiY21hIGlzIG5vdCBzZXQiDQoNClcgZG5pdSAxMyB3cnplxZtuaWEgMjAx
MSAxOTo0NCB1xbx5dGtvd25payBKb2huIFcuIExpbnZpbGxlDQo8bGludmlsbGVAdHV4ZHJpdmVy
LmNvbT4gbmFwaXNhxYI6DQo+IE9uIE1vbiwgU2VwIDEyLCAyMDExIGF0IDExOjI3OjIwUE0gKzAy
MDAsIFJhZmHFgiBNacWCZWNraSB3cm90ZToNCj4NCj4+IFRoZSBwcm9ibGVtIGlzIHRoYXQgYnJj
bXNtYWMgZHVwbGljYXRlcyBjb2RlIHByZXNlbnQgaW4gdGhlIGJjbWENCj4+IGRyaXZlci4gSXQg
ZG9lc24ndCB1c2UgYmNtYSBidXMgYXJjaGl0ZWN0dXJlLg0KPj4NCj4+IFRoZSByZWFsIHNvbHV0
aW9uIGlzIHRvIGFkZCBiY21hIGRyaXZlciBzdXBwb3J0IGluIGJyY21zbWFjIGFuZCBzc2INCj4+
IGRyaXZlciBzdXBwb3J0IGluIGJyY21mbWFjLiBUaGVuIHlvdSBjYW4gYWx3YXlzIHVzZSBiY21h
IGFuZDoNCj4+IDEpIElmIGI0MyB3aWxsIGxvYWQgYW5kIGRldGVjdCB1bnN1cHBvcnRlZCBQSFks
IGl0IHdpbGwgcmVsZWFzZSB0aGUgQkNNQSdzIGNvcmUNCj4+IDIpIGJyY21zbWFjIHdpbGwgYmUg
bG9hZGVkIHRvIGxldCBpdCBzdXBwb3J0IHRoZSBjb3JlDQo+DQo+IFdlIGFyZSBnb2luZyB0byBo
YXZlIHRvIGZpbmQgYSB3YXkgdG8gZ2V0IGJyY21zbWFjIGludG8gdGhlDQo+IHdpcmVsZXNzLW5l
eHQgdHJlZSB0byBtYWtlIGl0IGZlYXNpYmxlIGZvciB0aGUgQnJvYWRjb20gZ3V5cyB0byBnZXQN
Cj4gYmNtYSBzdXBwb3J0IGludG8gdGhhdCBkcml2ZXIuIMKgRG8geW91IGFncmVlPw0KPg0KPiBX
ZSBjb3VsZCBtb3ZlIGl0IHVuZGVyIHRoZSBkcml2ZXJzL25ldC93aXJlbGVzcyB0cmVlLiDCoE9y
LCBtYXliZSBJDQo+IGNvdWxkIG5lZ290aWF0ZSB3aXRoIEdyZWcgdG8ga2VlcCBpdCB1bmRlciB0
aGUgZHJpdmVycy9zdGFnaW5nIHRyZWUNCj4gYnV0IHRvIGxldCBtZSBtYW5hZ2UgaXQgdW5kZXIg
d2lyZWxlc3MtbmV4dC4gwqBPci4uLj8gwqBEbyB5b3UgaGF2ZQ0KPiBhbnkgdGhvdWdodHMgb24g
dGhpcz8NCg0KSSdsbCBiZSBwb3N0aW5nIHNvbWUgYmNtYSBwYXRjaGVzIHRoYXQgd2lsbCBhbGxv
dyBicmNtc21hYyBiZWluZw0KY29udmVydGVkIHRvIGJjbWEgc3VwcG9ydC4gQ3VycmVudGx5IHdl
IGRvbid0IGV4cG9ydCBmZXcgdHJpdmlhbCBvcHMNCmluIGJjbWEsIHRoYXQgYXJlIG5lZWRlZCBi
eSBiNDMvYnJjbXNtYWMuDQoNCkNvdWxkIHdlIGFzayBHcmVnIGFmdGVyIHRoYXQsIHRvIG1lcmdl
IHdpcmVsZXNzLW5leHQgaW50byBzdGFnaW5nPw0KVGhhdCB3b3VsZCBwcm92aWRlIEJyb2FkY29t
IGd1eXMgYWxsIHRoZSBzeW1ib2xzIHRoZXkgbmVlZC4NCg0KQUZBSUsgZ2l0IGlzIGNsZXZlciBl
bm91Z2ggdG8gYWxsb3cgTGludXggZWFzaWx5IG1lcmdlIGJvdGg6IEdyZWcncw0KdHJlZSBhbmQg
d2lyZWxlc3MtbmV4dCB0cmVlLiBXaXRob3V0IGNvbmZsaWN0cyBjb21pbmcgZnJvbQ0KImR1cGxp
Y2F0ZWQiIHBhdGNoZXMuDQoNCi0tIA0KUmFmYcWCDQoNCg==
On Wed, Jan 11, 2012 at 3:26 PM, Arend van Spriel <[email protected]> wrote:
> On 01/11/2012 02:13 PM, Francis Moreau wrote:
>> On Wed, Jan 11, 2012 at 1:24 PM, Arend van Spriel <[email protected]> wrote:
>>> On 01/11/2012 12:40 PM, Francis Moreau wrote:
>>>> Hi,
>>>>
>>>> This has finally been merged and is part of the 3.2 release.
>>>>
>>>> So now distros don't ship the brcmsmac driver anymore which is
>>>> basically the only driver which can handle my card.
>>>
>>> I am not sure why you come to that conclusion,
>>
>> I checked on both OpenSuse and Mandriva, and they both have CONFIG_BCMA=m.
>>
>>> For kernel v3.3 the brcmsmac driver will be using bcma.
>>
>> Great.
>>
>> But v3.2...
>>
>
> Given the configuration BCMA=m I agree that brcmsmac is probably not in
> the distro in binary form. However, you can probably install the kernel
> source package and rebuilt the kernel with BCMA=n and BRCMSMAC=m.
Sure but it's not really nice for all users in the same case,
specially since we could have done otherwise that would have make
happy the poor user I am until the b43 has support for bcma (next
release if I understood correctly).
Users are unlikely to know/will to recompile his kernel, I think.
--
Francis
On 01/11/2012 02:13 PM, Francis Moreau wrote:
> On Wed, Jan 11, 2012 at 1:24 PM, Arend van Spriel <[email protected]> wrote:
>> On 01/11/2012 12:40 PM, Francis Moreau wrote:
>>> Hi,
>>>
>>> This has finally been merged and is part of the 3.2 release.
>>>
>>> So now distros don't ship the brcmsmac driver anymore which is
>>> basically the only driver which can handle my card.
>>
>> I am not sure why you come to that conclusion,
>
> I checked on both OpenSuse and Mandriva, and they both have CONFIG_BCMA=m.
>
>> For kernel v3.3 the brcmsmac driver will be using bcma.
>
> Great.
>
> But v3.2...
>
Given the configuration BCMA=m I agree that brcmsmac is probably not in
the distro in binary form. However, you can probably install the kernel
source package and rebuilt the kernel with BCMA=n and BRCMSMAC=m.
Gr. AvS
On 01/11/2012 12:40 PM, Francis Moreau wrote:
> Hi,
>
> This has finally been merged and is part of the 3.2 release.
>
> So now distros don't ship the brcmsmac driver anymore which is
> basically the only driver which can handle my card.
I am not sure why you come to that conclusion, but I don't know the
criteria that distros use. In hindsight maybe this patch was not needed
because you could use module blacklist instead.
> did you really intend to do that ?
>
> Thanks
For kernel v3.3 the brcmsmac driver will be using bcma. I had a look and
it turns out b43 is claiming the same bcma cores that brcmsmac claims.
So there you probably need to blacklist b43.
Gr. AvS
On Wed, Jan 11, 2012 at 1:24 PM, Arend van Spriel <[email protected]> wrote:
> On 01/11/2012 12:40 PM, Francis Moreau wrote:
>> Hi,
>>
>> This has finally been merged and is part of the 3.2 release.
>>
>> So now distros don't ship the brcmsmac driver anymore which is
>> basically the only driver which can handle my card.
>
> I am not sure why you come to that conclusion,
I checked on both OpenSuse and Mandriva, and they both have CONFIG_BCMA=m.
> For kernel v3.3 the brcmsmac driver will be using bcma.
Great.
But v3.2...
> I had a look and
> it turns out b43 is claiming the same bcma cores that brcmsmac claims.
> So there you probably need to blacklist b43.
That means that brcmsmac is still provided which is no more true with
this patch.
Why not having let brcmsmac handles the devices that are currently not
supported by b43 ? and why b43 claims some devices that it doesn't
drive correctly ?
--
Francis
Hi,
On Thu, Sep 8, 2011 at 10:46 AM, Francis Moreau <[email protected]> wrote:
> Hello,
>
> I have a question regarding the following patch:
> http://permalink.gmane.org/gmane.linux.kernel.wireless.general/75638
>
> The commit message says:
>
> ? brcmsmac doesn't yet use bcma, but both drivers attempt to claim the same
> ? device. ?For now, turn of brcmsmac if bcma is enabled.
>
> I think it's not quite complete: ?both driver claim the same devices
> (actually that's not entirely true since b43/bcma can drive on more
> card) but in the case of b43/bcma not all cards are actually working.
> For example I'm using BCM4313 card with an unsupported phy
> (B43_PHYTYPE_LCN) so it's basically not supported by b43/bcma.
>
> So I'm wondering if b43/bcma should be simply disabled until it got
> the same level of support as brcmsmac ?
This has finally been merged and is part of the 3.2 release.
So now distros don't ship the brcmsmac driver anymore which is
basically the only driver which can handle my card.
did you really intend to do that ?
Thanks
--
Francis
On Wed, Jan 11, 2012 at 3:26 PM, Arend van Spriel <[email protected]> wrote:
> On 01/11/2012 02:13 PM, Francis Moreau wrote:
>> On Wed, Jan 11, 2012 at 1:24 PM, Arend van Spriel <[email protected]> wrote:
>>> On 01/11/2012 12:40 PM, Francis Moreau wrote:
>>>> Hi,
>>>>
>>>> This has finally been merged and is part of the 3.2 release.
>>>>
>>>> So now distros don't ship the brcmsmac driver anymore which is
>>>> basically the only driver which can handle my card.
>>>
>>> I am not sure why you come to that conclusion,
>>
>> I checked on both OpenSuse and Mandriva, and they both have CONFIG_BCMA=m.
>>
>>> For kernel v3.3 the brcmsmac driver will be using bcma.
>>
>> Great.
>>
>> But v3.2...
>>
>
> Given the configuration BCMA=m I agree that brcmsmac is probably not in
> the distro in binary form. However, you can probably install the kernel
> source package and rebuilt the kernel with BCMA=n and BRCMSMAC=m.
>
> Gr. AvS
>
and now using the brcmsmac gives the following WARN:
[ 98.406709] ------------[ cut here ]------------
[ 98.406743] WARNING: at net/mac80211/rx.c:2979
ieee80211_rx+0x91b/0x9e0 [mac80211]()
[ 98.406747] Hardware name: Vostro 3500
[ 98.406749] Modules linked in: rfcomm bridge stp bnep btusb
bluetooth nfsd nfs lockd fscache auth_rpcgss nfs_acl sunrpc fuse
af_packet ipv6 arc4 brcmsmac mac80211 brcmutil snd_hda_codec_hdmi
snd_hda_codec_idt cfg80211 uvcvideo snd_hda_intel dell_laptop
snd_hda_codec rfkill videodev snd_hwdep sg snd_seq_dummy snd_seq_oss
snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_pcm
snd_timer snd_mixer_oss snd mei(C) r8169 mii media v4l2_compat_ioctl32
soundcore snd_page_alloc sr_mod iTCO_wdt iTCO_vendor_support intel_ips
crc8 cordic dcdbas i2c_i801 i915 drm_kms_helper drm i2c_algo_bit
i2c_core coretemp binfmt_misc cpufreq_ondemand cpufreq_conservative
cpufreq_powersave acpi_cpufreq freq_table mperf nvram dm_mod joydev
dell_wmi sparse_keymap evdev kvm_intel wmi kvm video battery ata_piix
ahci libahci libata sd_mod scsi_mod crc_t10dif ext4 jbd2 crc16
uhci_hcd ohci_hcd ehci_hcd usbhid hid usbcore usb_common
[ 98.406857] Pid: 0, comm: swapper/0 Tainted: G WC 3.2+ #1
[ 98.406861] Call Trace:
[ 98.406864] <IRQ> [<ffffffff8106809f>] warn_slowpath_common+0x7f/0xc0
[ 98.406880] [<ffffffff810680fa>] warn_slowpath_null+0x1a/0x20
[ 98.406896] [<ffffffffa050d2bb>] ieee80211_rx+0x91b/0x9e0 [mac80211]
[ 98.406902] [<ffffffff8105776d>] ? update_curr+0x1cd/0x220
[ 98.406913] [<ffffffffa04f0dd9>]
ieee80211_tasklet_handler+0xb9/0x160 [mac80211]
[ 98.406919] [<ffffffff8106f43d>] tasklet_action+0xcd/0x110
[ 98.406924] [<ffffffff8106efda>] __do_softirq+0xaa/0x1e0
[ 98.406931] [<ffffffff8146792c>] call_softirq+0x1c/0x30
[ 98.406938] [<ffffffff81015255>] do_softirq+0x65/0xa0
[ 98.406942] [<ffffffff8106edde>] irq_exit+0x8e/0xc0
[ 98.406948] [<ffffffff814681e6>] do_IRQ+0x66/0xe0
[ 98.406954] [<ffffffff8145da2e>] common_interrupt+0x6e/0x6e
[ 98.406957] <EOI> [<ffffffff8129e2e0>] ? intel_idle+0xe0/0x150
[ 98.406968] [<ffffffff8129e2c6>] ? intel_idle+0xc6/0x150
[ 98.406975] [<ffffffff8136e678>] cpuidle_idle_call+0xd8/0x1b0
[ 98.406980] [<ffffffff8101302b>] cpu_idle+0xcb/0x120
[ 98.406987] [<ffffffff814410c2>] rest_init+0x72/0x80
[ 98.406994] [<ffffffff81ac7cd9>] start_kernel+0x3c5/0x3d0
[ 98.406999] [<ffffffff81ac7346>] x86_64_start_reservations+0x131/0x135
[ 98.407004] [<ffffffff81ac744d>] x86_64_start_kernel+0x103/0x112
[ 98.407009] ---[ end trace 4b7390abe635c92a ]---
Could anybody tell me what's wrong ?
Thanks
--
Francis