Re: [RFC 7/7] B43N: Add the tx gain table of different version.
On Thu, 2009-01-15 at 09:48 +0800, YanBo wrote:
I think you should give these different names, rather than sub-indexing
in that array.
Yes, they has been assigned difference names. like below
+enum b43_nphy_txgain_type {
+ REV_LE2 = 0,/* rev = 2 */
+ REV_GE3_2G, /* rev = 3 (2.4 GHz) */
+ REV_E3_5G, /* rev 3 (5 GHz) */
+ REV_GE4_5G, /* rev = 4 (5 GHz) */
+};
But above code was split into patch 4/7 by my mistake.
Yes, but I think you should give them names, not just named array
indexes.
johannes
signature.asc
Description: This is a digitally signed message part
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [b43] opensource firmware
Pardon me, but those filenames are identical and contain no numbers. Did those get stripped off somewhere? I did a mistake. The correct name are b0g0bsinitvals5.fw and b0g0initvals5.fw for revision 5. Sorry Cheers Lorenzo ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [b43] opensource firmware
Lorenzo Nava wrote: Yes, you're right. Actually there are 2 ways to make firmware works: 1) Disable hw crypto with module parameter 2) Remove pcm5.fw from your /lib/firmware/b43 directory When I run the firmware I never include pcm5.fw file. The only initvals really necessary are b0g0bsinitvals.fw and b0g0bsinitvals.fw. Pardon me, but those filenames are identical and contain no numbers. Did those get stripped off somewhere? cheers Lorenzo Larry Finger had written: Great job. Larry Absolutely Ehud -- Legal Disclaimer that you are now contractually bound to under all laws with no recourse: http://attrition.org/security/rants/z/disclaimers.html ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [b43] opensource firmware
On Wednesday 14 January 2009 21:45:22 Johannes Berg wrote: Initvals and new firmware version can be found at http://www.ing.unibs.it/openfwwf I suggest that before this is packaged, we change it so b43 can recognise it and automatically disable qos and hwcrypto. Yes, please introduce a feature-bitfield at some location in SHM that's unused by the proprietary firmware. This bitfields would contain a bit for QoS and a bit for hwcrypto. Also change your firmware so the driver detects it as open-source firmware. I think that's done by writing 0x to the date/time field in SHM. I don't quite remember, but it's something like that. Note that this might mean that the firmware watchdog in the driver will trigger, as that's enabled by the open-source-firmware-flag. We might want to temporarly disable the watchdog in the driver for the time being. -- Greetings, Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Support for 16 bit PCMCIA 0x02d0, 0x042d?
On Thursday 15 January 2009 00:22:33 Stefan Lippers-Hollmann wrote: Is there a chance to add support for this kind of device? I think you're on your own. Nobody else does have such a device and remote-debugging is basically impossible for this. -- Greetings, Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [b43] opensource firmware
On Thursday 15 January 2009 16:37:57 Michael Buesch wrote: On Wednesday 14 January 2009 21:45:22 Johannes Berg wrote: Initvals and new firmware version can be found at http://www.ing.unibs.it/openfwwf I suggest that before this is packaged, we change it so b43 can recognise it and automatically disable qos and hwcrypto. Yes, please introduce a feature-bitfield at some location in SHM that's unused by the proprietary firmware. This bitfields would contain a bit for QoS and a bit for hwcrypto. Also change your firmware so the driver detects it as open-source firmware. I think that's done by writing 0x to the date/time field in SHM. I don't quite remember, but it's something like that. Note that this might mean that the firmware watchdog in the driver will trigger, as that's enabled by the open-source-firmware-flag. We might want to temporarly disable the watchdog in the driver for the time being. Ah and also note that hwcrypto is already automagically disabled, if the driver detects an opensource-firmware. To make the driver detect the firmware as opensource, write 0x to SHM_UCODEDATE You need to disable the watchdog in b43_periodic_every15sec(), if you don't implement the watchdog mechanism in your firmware. But it's pretty easy to implement. It just has to write 0 to some register in the MAC loop. Of course, the register has to be unused in the rest of the code. -- Greetings, Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [b43] opensource firmware
Michael Buesch wrote: Yes, please introduce a feature-bitfield at some location in SHM that's unused by the proprietary firmware. This bitfields would contain a bit for QoS and a bit for hwcrypto. Also change your firmware so the driver detects it as open-source firmware. I think that's done by writing 0x to the date/time field in SHM. I don't quite remember, but it's something like that. Note that this might mean that the firmware watchdog in the driver will trigger, as that's enabled by the open-source-firmware-flag. We might want to temporarly disable the watchdog in the driver for the time being. I like the idea of encoding the capabilities in the firmware as it would be a self-documenting method as the firmware evolves. Is using the Broadcom names for the firmware the best course of action? What if the opensource firmware files were named something like os-ucode5.fw, etc. and b43 were coded to check for those files first? It would then fall back to the standard firmware if the opensource version is not found. Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [b43] opensource firmware
On Thursday 15 January 2009 16:59:11 Larry Finger wrote: Michael Buesch wrote: Yes, please introduce a feature-bitfield at some location in SHM that's unused by the proprietary firmware. This bitfields would contain a bit for QoS and a bit for hwcrypto. Also change your firmware so the driver detects it as open-source firmware. I think that's done by writing 0x to the date/time field in SHM. I don't quite remember, but it's something like that. Note that this might mean that the firmware watchdog in the driver will trigger, as that's enabled by the open-source-firmware-flag. We might want to temporarly disable the watchdog in the driver for the time being. I like the idea of encoding the capabilities in the firmware as it would be a self-documenting method as the firmware evolves. Is using the Broadcom names for the firmware the best course of action? What if the opensource firmware files were named something like os-ucode5.fw, etc. and b43 were coded to check for those files first? It would then fall back to the standard firmware if the opensource version is not found. Already implemented here: http://bu3sch.de/patches/wireless-testing/20081227-1821/patches/008-b43-probe-open-fw.patch I just need to fix a leak in an error path before pushing that upstream. -- Greetings, Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Support for 16 bit PCMCIA 0x02d0, 0x042d?
Hi On Donnerstag, 15. Januar 2009, Michael Buesch wrote: On Thursday 15 January 2009 00:22:33 Stefan Lippers-Hollmann wrote: Is there a chance to add support for this kind of device? I think you're on your own. Nobody else does have such a device and remote-debugging is basically impossible for this. Thanks, I just hoped to have missed anything obvious in regards to the ID registration and ssb. I'll see what (or if) I can do (anything) about it. Regards Stefan Lippers-Hollmann ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Support for 16 bit PCMCIA 0x02d0, 0x042d?
On Thursday 15 January 2009 18:59:46 Stefan Lippers-Hollmann wrote: Hi On Donnerstag, 15. Januar 2009, Michael Buesch wrote: On Thursday 15 January 2009 00:22:33 Stefan Lippers-Hollmann wrote: Is there a chance to add support for this kind of device? I think you're on your own. Nobody else does have such a device and remote-debugging is basically impossible for this. Thanks, I just hoped to have missed anything obvious in regards to the ID registration and ssb. Well, no. There's no known bug. But the PCMCIA core API is just crap. I had to fight with all those undocumented flags for a long time to get my card working. There might be some flag needed (or not) by your card that we don't set/clear, yet. SSB failing to switch the core indicates a very basic problem with the PCMCIA setup, because the coreswitch is the most basic and very first operation we do on the device. It's also done through PCMCIA config space registers, so it indicates your config space is not accessible. Which is a core failure. So I _guess_ it could probably be a bug somewhere in drivers/net/wireless/b43/pcmcia.c. However, of course, it can be everywhere. This file is just where I had the major problems to get the thing running. -- Greetings, Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [b43] opensource firmware
On Jan 15, 2009, at 4:59 PM, Larry Finger wrote: Michael Buesch wrote: Yes, please introduce a feature-bitfield at some location in SHM that's unused by the proprietary firmware. This bitfields would contain a bit for QoS and a bit for hwcrypto. Also change your firmware so the driver detects it as open-source firmware. I think that's done by writing 0x to the date/time field in SHM. I don't quite remember, but it's something like that. Note that this might mean that the firmware watchdog in the driver will trigger, as that's enabled by the open-source-firmware-flag. We might want to temporarly disable the watchdog in the driver for the time being. I like the idea of encoding the capabilities in the firmware as it would be a self-documenting method as the firmware evolves. Is using the Broadcom names for the firmware the best course of action? What if the opensource firmware files were named something like os-ucode5.fw, etc. and b43 were coded to check for those files first? It would then fall back to the standard firmware if the opensource version is not found. Larry It could be interesting to also not separate the initvalues in two different files, everything could be coded in a single file. Never understood why original init values are split in two files. Michael: SHM(0x0014) (16bit) is not used by the open source firmware, I know the b43 reads core revision from SHM(0x0016). Normally SHM(0x0014) is set to zero. We can put fw capabilities here (0x0014), e.g.: - bit 0: [0 state that encryption should be handled by b43] - bit 1: [0 state that qos is not supported] We can prepare a firmware image with such feature + watchdog. Posting ASAP with new initvals (less values). A question: is the standard kernel aware that date set to indicates an opensource firmware or some define should be activated on compilation? Cheers, -FG ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: LED on BCM4311 on Acer Extensa 5220
On Jan 15, 2009, at 4:35 AM, _...@list.ru wrote: (Previous message failed) The Wi-Fi status LED on Acer Extensa 5220 works incorrectly. When using b43, it is turned on only if radio is disabled. When using ndiswrapper, it is blinking when disconnected, on when connected and rapidly flashes when information is being sent or received. When /sys/class/leds/b43-phy0::radio/brightness is set to 0, the LED is turned on. When it is 1 to 255, the LED is off. vi-notebook:/sys/class/leds/b43-phy0::radio# cat trigger none ide-disk rfkill0 ADP1-online BAT0-charging-or-full BAT0-charging BAT0-full mmc0 phy0rx phy0tx phy0assoc phy0radio [rfkill4] [cut] I was wondering if offloading led handling to firmware could be a positive feature or it is better practice to handle blinking on the host side. Really I do not know: however if needed, the feature can be easily added. Cheers, -FG ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
