* Re: [ath5k-devel] [PATCH 2/2] ath5k: don't use PCI ID to find the chip revision
From: Nick Kossifidis @ 2009-08-27 13:10 UTC (permalink / raw)
To: Pavel Roskin; +Cc: ath5k-devel, linux-wireless, John W. Linville
In-Reply-To: <20090827023009.21926.49329.stgit@mj.roinet.com>
2009/8/27 Pavel Roskin <proski@gnu.org>:
> AR5K_SREV is available even if the chip has been put to sleep. Relying
> on the chip register allows binding non-standard PCI IDs by
>
> echo VENDOR_ID PRODUCT_ID >/sys/bus/pci/drivers/ath5k/new_id
>
> without having to specify the driver data as well.
>
> Signed-off-by: Pavel Roskin <proski@gnu.org>
> ---
> drivers/net/wireless/ath/ath5k/ath5k.h | 2 +-
> drivers/net/wireless/ath/ath5k/attach.c | 14 +++++++----
> drivers/net/wireless/ath/ath5k/base.c | 38 ++++++++++++++++---------------
> 3 files changed, 29 insertions(+), 25 deletions(-)
>
> diff --git a/drivers/net/wireless/ath/ath5k/ath5k.h b/drivers/net/wireless/ath/ath5k/ath5k.h
> index cdc79cd..c2d4c6a 100644
> --- a/drivers/net/wireless/ath/ath5k/ath5k.h
> +++ b/drivers/net/wireless/ath/ath5k/ath5k.h
> @@ -1159,7 +1159,7 @@ struct ath5k_hw {
> */
>
> /* Attach/Detach Functions */
> -extern struct ath5k_hw *ath5k_hw_attach(struct ath5k_softc *sc, u8 mac_version);
> +extern struct ath5k_hw *ath5k_hw_attach(struct ath5k_softc *sc);
> extern void ath5k_hw_detach(struct ath5k_hw *ah);
>
> /* LED functions */
> diff --git a/drivers/net/wireless/ath/ath5k/attach.c b/drivers/net/wireless/ath/ath5k/attach.c
> index 109ab7b..0d789ef 100644
> --- a/drivers/net/wireless/ath/ath5k/attach.c
> +++ b/drivers/net/wireless/ath/ath5k/attach.c
> @@ -95,14 +95,13 @@ static int ath5k_hw_post(struct ath5k_hw *ah)
> * ath5k_hw_attach - Check if hw is supported and init the needed structs
> *
> * @sc: The &struct ath5k_softc we got from the driver's attach function
> - * @mac_version: The mac version id (check out ath5k.h) based on pci id
> *
> * Check if the device is supported, perform a POST and initialize the needed
> * structs. Returns -ENOMEM if we don't have memory for the needed structs,
> * -ENODEV if the device is not supported or prints an error msg if something
> * else went wrong.
> */
> -struct ath5k_hw *ath5k_hw_attach(struct ath5k_softc *sc, u8 mac_version)
> +struct ath5k_hw *ath5k_hw_attach(struct ath5k_softc *sc)
> {
> struct ath5k_hw *ah;
> struct pci_dev *pdev = sc->pdev;
> @@ -136,9 +135,15 @@ struct ath5k_hw *ath5k_hw_attach(struct ath5k_softc *sc, u8 mac_version)
> ah->ah_software_retry = false;
>
> /*
> - * Set the mac version based on the pci id
> + * Find the mac version
> */
> - ah->ah_version = mac_version;
> + srev = ath5k_hw_reg_read(ah, AR5K_SREV);
> + if (srev < AR5K_SREV_AR5311)
> + ah->ah_version = AR5K_AR5210;
> + else if (srev < AR5K_SREV_AR5212)
> + ah->ah_version = AR5K_AR5211;
> + else
> + ah->ah_version = AR5K_AR5212;
>
> /*Fill the ath5k_hw struct with the needed functions*/
> ret = ath5k_hw_init_desc_functions(ah);
> @@ -151,7 +156,6 @@ struct ath5k_hw *ath5k_hw_attach(struct ath5k_softc *sc, u8 mac_version)
> goto err_free;
>
> /* Get MAC, PHY and RADIO revisions */
> - srev = ath5k_hw_reg_read(ah, AR5K_SREV);
> ah->ah_mac_srev = srev;
> ah->ah_mac_version = AR5K_REG_MS(srev, AR5K_SREV_VER);
> ah->ah_mac_revision = AR5K_REG_MS(srev, AR5K_SREV_REV);
> diff --git a/drivers/net/wireless/ath/ath5k/base.c b/drivers/net/wireless/ath/ath5k/base.c
> index 94d46fd..9c6ab53 100644
> --- a/drivers/net/wireless/ath/ath5k/base.c
> +++ b/drivers/net/wireless/ath/ath5k/base.c
> @@ -84,24 +84,24 @@ MODULE_VERSION("0.6.0 (EXPERIMENTAL)");
>
> /* Known PCI ids */
> static const struct pci_device_id ath5k_pci_id_table[] = {
> - { PCI_VDEVICE(ATHEROS, 0x0207), .driver_data = AR5K_AR5210 }, /* 5210 early */
> - { PCI_VDEVICE(ATHEROS, 0x0007), .driver_data = AR5K_AR5210 }, /* 5210 */
> - { PCI_VDEVICE(ATHEROS, 0x0011), .driver_data = AR5K_AR5211 }, /* 5311 - this is on AHB bus !*/
> - { PCI_VDEVICE(ATHEROS, 0x0012), .driver_data = AR5K_AR5211 }, /* 5211 */
> - { PCI_VDEVICE(ATHEROS, 0x0013), .driver_data = AR5K_AR5212 }, /* 5212 */
> - { PCI_VDEVICE(3COM_2, 0x0013), .driver_data = AR5K_AR5212 }, /* 3com 5212 */
> - { PCI_VDEVICE(3COM, 0x0013), .driver_data = AR5K_AR5212 }, /* 3com 3CRDAG675 5212 */
> - { PCI_VDEVICE(ATHEROS, 0x1014), .driver_data = AR5K_AR5212 }, /* IBM minipci 5212 */
> - { PCI_VDEVICE(ATHEROS, 0x0014), .driver_data = AR5K_AR5212 }, /* 5212 combatible */
> - { PCI_VDEVICE(ATHEROS, 0x0015), .driver_data = AR5K_AR5212 }, /* 5212 combatible */
> - { PCI_VDEVICE(ATHEROS, 0x0016), .driver_data = AR5K_AR5212 }, /* 5212 combatible */
> - { PCI_VDEVICE(ATHEROS, 0x0017), .driver_data = AR5K_AR5212 }, /* 5212 combatible */
> - { PCI_VDEVICE(ATHEROS, 0x0018), .driver_data = AR5K_AR5212 }, /* 5212 combatible */
> - { PCI_VDEVICE(ATHEROS, 0x0019), .driver_data = AR5K_AR5212 }, /* 5212 combatible */
> - { PCI_VDEVICE(ATHEROS, 0x001a), .driver_data = AR5K_AR5212 }, /* 2413 Griffin-lite */
> - { PCI_VDEVICE(ATHEROS, 0x001b), .driver_data = AR5K_AR5212 }, /* 5413 Eagle */
> - { PCI_VDEVICE(ATHEROS, 0x001c), .driver_data = AR5K_AR5212 }, /* PCI-E cards */
> - { PCI_VDEVICE(ATHEROS, 0x001d), .driver_data = AR5K_AR5212 }, /* 2417 Nala */
> + { PCI_VDEVICE(ATHEROS, 0x0207) }, /* 5210 early */
> + { PCI_VDEVICE(ATHEROS, 0x0007) }, /* 5210 */
> + { PCI_VDEVICE(ATHEROS, 0x0011) }, /* 5311 - this is on AHB bus !*/
> + { PCI_VDEVICE(ATHEROS, 0x0012) }, /* 5211 */
> + { PCI_VDEVICE(ATHEROS, 0x0013) }, /* 5212 */
> + { PCI_VDEVICE(3COM_2, 0x0013) }, /* 3com 5212 */
> + { PCI_VDEVICE(3COM, 0x0013) }, /* 3com 3CRDAG675 5212 */
> + { PCI_VDEVICE(ATHEROS, 0x1014) }, /* IBM minipci 5212 */
> + { PCI_VDEVICE(ATHEROS, 0x0014) }, /* 5212 combatible */
> + { PCI_VDEVICE(ATHEROS, 0x0015) }, /* 5212 combatible */
> + { PCI_VDEVICE(ATHEROS, 0x0016) }, /* 5212 combatible */
> + { PCI_VDEVICE(ATHEROS, 0x0017) }, /* 5212 combatible */
> + { PCI_VDEVICE(ATHEROS, 0x0018) }, /* 5212 combatible */
> + { PCI_VDEVICE(ATHEROS, 0x0019) }, /* 5212 combatible */
> + { PCI_VDEVICE(ATHEROS, 0x001a) }, /* 2413 Griffin-lite */
> + { PCI_VDEVICE(ATHEROS, 0x001b) }, /* 5413 Eagle */
> + { PCI_VDEVICE(ATHEROS, 0x001c) }, /* PCI-E cards */
> + { PCI_VDEVICE(ATHEROS, 0x001d) }, /* 2417 Nala */
> { 0 }
> };
> MODULE_DEVICE_TABLE(pci, ath5k_pci_id_table);
> @@ -566,7 +566,7 @@ ath5k_pci_probe(struct pci_dev *pdev,
> }
>
> /* Initialize device */
> - sc->ah = ath5k_hw_attach(sc, id->driver_data);
> + sc->ah = ath5k_hw_attach(sc);
> if (IS_ERR(sc->ah)) {
> ret = PTR_ERR(sc->ah);
> goto err_irq;
Acked-by: Nick Kossifidis <mickflemm@gmail.com>
--
GPG ID: 0xD21DB2DB
As you read this post global entropy rises. Have Fun ;-)
Nick
^ permalink raw reply
* Re: [ath5k-devel] [PATCH 1/2] ath5k: fix uninitialized value use in ath5k_eeprom_read_turbo_modes()
From: Nick Kossifidis @ 2009-08-27 12:58 UTC (permalink / raw)
To: Pavel Roskin; +Cc: ath5k-devel, linux-wireless, John W. Linville
In-Reply-To: <20090827023000.21926.90867.stgit@mj.roinet.com>
2009/8/27 Pavel Roskin <proski@gnu.org>:
> The `val' variable in ath5k_eeprom_read_turbo_modes() is used
> uninitialized. gcc 4.4.1 with -fno-inline-functions-called-once reports
> it:
>
> eeprom.c: In function 'ath5k_eeprom_read_turbo_modes':
> eeprom.c:441: warning: 'val' may be used uninitialized in this function
>
> Comparing the code to the Atheros HAL, it's clear that the split between
> ath5k_eeprom_read_modes() and ath5k_eeprom_read_turbo_modes() was
> incorrect.
>
> The Atheros HAL reads both turbo and non-turbo data from EEPROM in one
> function. Some turbo mode parameters are derived from the same EEPROM
> values as non-turbo parameters, just from different bits.
>
> Merge ath5k_eeprom_read_turbo_modes() into ath5k_eeprom_read_modes() to
> fix the warning. The actual values and offsets have been cross-checked
> against Atheros HAL.
>
> Signed-off-by: Pavel Roskin <proski@gnu.org>
Current code works fine (i 've checked it against various cards),
there is nothing wrong
with having another function for reading turbo modes, i find it's
cleaner that way.
Just change
u16 val;
to
u16 val = 0;
and it should be fine.
--
GPG ID: 0xD21DB2DB
As you read this post global entropy rises. Have Fun ;-)
Nick
^ permalink raw reply
* Re: [PATCH] b43: Remove scary message from LP-PHY's Kconfig
From: Kalle Valo @ 2009-08-27 12:22 UTC (permalink / raw)
To: Gábor Stefanik
Cc: John Linville, Michael Buesch, Larry Finger, Mark Huijgen,
Broadcom Wireless, linux-wireless
In-Reply-To: <1251316132-392-1-git-send-email-netrolller.3d@gmail.com>
Gábor Stefanik <netrolller.3d@gmail.com> writes:
> From: root Gábor Stefanik <netrolller.3d@gmail.com>
You have extra "root" word here. You really like sudo ;)
--
Kalle Valo
^ permalink raw reply
* Nokia N900 running mac80211
From: Kalle Valo @ 2009-08-27 11:55 UTC (permalink / raw)
To: linux-wireless
Hello,
wanted to tell you that just released Nokia N900 is using mac80211 and
wl1251 driver. The kernel is 2.6.28 with few wireless related patches
backported from newer releases and some hacks related to roaming.
http://www.nokia.com/press/press-releases/showpressrelease?newsid=1337594
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH] rndis_wlan: increase scan timer delay
From: Jussi Kivilinna @ 2009-08-27 10:43 UTC (permalink / raw)
To: Jussi Kivilinna; +Cc: linux-wireless, John W. Linville
In-Reply-To: <20090827073854.27662.68095.stgit@fate.lan>
Please, don't merge this after all. Blocks scan too long and breaks
NetworkManager/wpa_supplicant.
Quoting "Jussi Kivilinna" <jussi.kivilinna@mbnet.fi>:
> Increase scan delay from 1 sec to 6 sec. Spec says that scan by
> OID_802_11_BSSID_LIST_SCAN completes in 6 seconds.
> Before rfkill patch too short delay was not problem as device was
> always active (radio on) and performing background scanning.
>
> Signed-off-by: Jussi Kivilinna <jussi.kivilinna@mbnet.fi>
^ permalink raw reply
* Re: Abour linux driver supports BCM4325
From: Michael Buesch @ 2009-08-27 10:40 UTC (permalink / raw)
To: feng tian; +Cc: Johannes Berg, Larry Finger, linux-wireless
In-Reply-To: <f42a38140908270233r3c1aef6ne900fd3426465158@mail.gmail.com>
On Thursday 27 August 2009 11:33:12 feng tian wrote:
> Hi Michael,
> We found that broadcom drops some BCM codes which support SDIO
> interface on following url:
> "http://android.git.kernel.org/?p=platform/system/wlan/broadcom.git;a=summary"
> Just FYI.
> Hope this can help.
No, it's fullmac.
--
Greetings, Michael.
^ permalink raw reply
* Re: [Bug #14016] mm/ipw2200 regression
From: Mel Gorman @ 2009-08-27 9:45 UTC (permalink / raw)
To: Zhu Yi
Cc: Andrew Morton, Johannes Weiner, Pekka Enberg, Rafael J. Wysocki,
Linux Kernel Mailing List, Kernel Testers List,
Bartlomiej Zolnierkiewicz, Mel Gorman, netdev@vger.kernel.org,
linux-mm@kvack.org, James Ketrenos, Chatre, Reinette,
linux-wireless@vger.kernel.org,
ipw2100-devel@lists.sourceforge.net
In-Reply-To: <1251364289.3704.176.camel@debian>
On Thu, Aug 27, 2009 at 05:11:29PM +0800, Zhu Yi wrote:
> On Wed, 2009-08-26 at 22:44 +0800, Andrew Morton wrote:
> >
> > It is perhaps pretty simple to make the second (GFP_ATOMIC) allocation
> > go away. The code is already conveniently structured to do this:
> >
> > do {
> > chunk = (struct fw_chunk *)(data + offset);
> > offset += sizeof(struct fw_chunk);
> > /* build DMA packet and queue up for sending */
> > /* dma to chunk->address, the chunk->length bytes from
> > data +
> > * offeset*/
> > /* Dma loading */
> > rc = ipw_fw_dma_add_buffer(priv, shared_phys + offset,
> >
> > le32_to_cpu(chunk->address),
> >
> > le32_to_cpu(chunk->length));
> > if (rc) {
> > IPW_DEBUG_INFO("dmaAddBuffer Failed\n");
> > goto out;
> > }
> >
> > offset += le32_to_cpu(chunk->length);
> > } while (offset < len);
> >
> > what is the typical/expected value of chunk->length here? If it's
> > significantly less than 4096*(2^6), could we convert this function to
> > use a separate DMAable allocation per fw_chunk?
>
> Unfortunately, the largest chunk size for the latest 3.1 firmware is
> 0x20040, which also requires order 6 page allocation. I'll try to use
> the firmware DMA command block (64 slots) to handle the image (each for
> 4k, totally 256k).
>
That would be preferable as trying to make alloc-6 atomic allocations isn't
going to pan out. As I noted, doing it as GFP_KERNEL is possible but it'll
manifest as weird stalls periodically when the driver is loaded due to
reclaim and if the system is swapless, it might not work at all if memory
is mostly anonymous.
If the DMA command block doesn't work out, what is the feasibility of holding
onto the order-6 allocation once the module is loaded instead of allocing
for the duration of the firmware loading and then freeing it again?
--
Mel Gorman
Part-time Phd Student Linux Technology Center
University of Limerick IBM Dublin Software Lab
^ permalink raw reply
* Re: hal, rfkill and compat-wireless (Re: [RFC/RFT] rtl8187: Implement rfkill support)
From: Hin-Tak Leung @ 2009-08-27 9:43 UTC (permalink / raw)
To: Johannes Berg
Cc: Luis R. Rodriguez, hal, htl10, Larry Finger,
Herton Ronaldo Krzesinski, linux-wireless
In-Reply-To: <1251357267.20531.4.camel@johannes.local>
On Thu, Aug 27, 2009 at 8:14 AM, Johannes Berg<johannes@sipsolutions.net> wrote:
> On Wed, 2009-08-26 at 16:45 -0700, Luis R. Rodriguez wrote:
>
>> Johannes, did kernels < 2.6.31 have /sys/class/rfkill ?
>
> Yes, but I never understood why that matters. If you've got
> compat-wireless "rfkill" loaded then the original rfkill can't be loaded
> anyway. And their symbols would probably clash anyway if the original is
> built in, in which case you can't use compat.
>
> You haven't renamed cfg80211's sysfs either, so why rfkill?
>
> johannes
>
There are a couple of wimax drivers which depends on rfkill... or
bluetooth drivers? I think one likely reason is that there are valid
situations or hardware combinations which requires having both of them
loaded. (but that's a whole can of worms )
^ permalink raw reply
* Re: Abour linux driver supports BCM4325
From: feng tian @ 2009-08-27 9:33 UTC (permalink / raw)
To: Michael Buesch; +Cc: Johannes Berg, Larry Finger, linux-wireless
In-Reply-To: <200908251253.48176.mb@bu3sch.de>
Hi Michael,
We found that broadcom drops some BCM codes which support SDIO
interface on following url:
"http://android.git.kernel.org/?p=platform/system/wlan/broadcom.git;a=summary"
Just FYI.
Hope this can help.
BR, Feng.
2009/8/25 Michael Buesch <mb@bu3sch.de>:
> On Tuesday 25 August 2009 09:16:36 feng tian wrote:
>> Dear Michael,
>>
>> Another question:
>> We can't get the actual "datasheet" of BCM 4325. The pdf from broadcom
>> is so rough, and we also sent email to ask more detailed spec, but no
>> feedback.
>> What kind of datasheet of BCM4325 are you using now?
>> Could you please share this with us?
>>
>> Thank you very much.
>>
>> BR, Feng
>>
>>
>
> http://bcm-v4.sipsolutions.net/
>
> --
> Greetings, Michael.
>
^ permalink raw reply
* Re: [Bug #14016] mm/ipw2200 regression
From: Zhu Yi @ 2009-08-27 9:11 UTC (permalink / raw)
To: Andrew Morton
Cc: Mel Gorman, Johannes Weiner, Pekka Enberg, Rafael J. Wysocki,
Linux Kernel Mailing List, Kernel Testers List,
Bartlomiej Zolnierkiewicz, Mel Gorman, netdev@vger.kernel.org,
linux-mm@kvack.org, James Ketrenos, Chatre, Reinette,
linux-wireless@vger.kernel.org,
ipw2100-devel@lists.sourceforge.net
In-Reply-To: <20090826074409.606b5124.akpm@linux-foundation.org>
On Wed, 2009-08-26 at 22:44 +0800, Andrew Morton wrote:
>
> It is perhaps pretty simple to make the second (GFP_ATOMIC) allocation
> go away. The code is already conveniently structured to do this:
>
> do {
> chunk = (struct fw_chunk *)(data + offset);
> offset += sizeof(struct fw_chunk);
> /* build DMA packet and queue up for sending */
> /* dma to chunk->address, the chunk->length bytes from
> data +
> * offeset*/
> /* Dma loading */
> rc = ipw_fw_dma_add_buffer(priv, shared_phys + offset,
>
> le32_to_cpu(chunk->address),
>
> le32_to_cpu(chunk->length));
> if (rc) {
> IPW_DEBUG_INFO("dmaAddBuffer Failed\n");
> goto out;
> }
>
> offset += le32_to_cpu(chunk->length);
> } while (offset < len);
>
> what is the typical/expected value of chunk->length here? If it's
> significantly less than 4096*(2^6), could we convert this function to
> use a separate DMAable allocation per fw_chunk?
Unfortunately, the largest chunk size for the latest 3.1 firmware is
0x20040, which also requires order 6 page allocation. I'll try to use
the firmware DMA command block (64 slots) to handle the image (each for
4k, totally 256k).
Thanks,
-yi
^ permalink raw reply
* Re: [PATCH] rt2x00: Cleanup rt2x00mac_bss_info_changed()
From: Johannes Berg @ 2009-08-27 7:40 UTC (permalink / raw)
To: Ivo van Doorn; +Cc: John Linville, linux-wireless
In-Reply-To: <200908262104.09230.IvDoorn@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 439 bytes --]
On Wed, 2009-08-26 at 21:04 +0200, Ivo van Doorn wrote:
> Since patch "rt2x00: bss_info_changed() callback is allowed to sleep" the
> variable delayed wasn't used anymore. This means it can be removed
> along with the call to schedule_work which depended on that variable.
I just wanted to say thanks for doing all the cleanups. It's really nice
to see all my work on making callbacks non-atomic pay off in that way :)
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* [PATCH] rndis_wlan: increase scan timer delay
From: Jussi Kivilinna @ 2009-08-27 7:38 UTC (permalink / raw)
To: linux-wireless; +Cc: John W. Linville
Increase scan delay from 1 sec to 6 sec. Spec says that scan by
OID_802_11_BSSID_LIST_SCAN completes in 6 seconds.
Before rfkill patch too short delay was not problem as device was
always active (radio on) and performing background scanning.
Signed-off-by: Jussi Kivilinna <jussi.kivilinna@mbnet.fi>
---
drivers/net/wireless/rndis_wlan.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/wireless/rndis_wlan.c b/drivers/net/wireless/rndis_wlan.c
index f181b00..6d49e80 100644
--- a/drivers/net/wireless/rndis_wlan.c
+++ b/drivers/net/wireless/rndis_wlan.c
@@ -1599,7 +1599,7 @@ static int rndis_get_tx_power(struct wiphy *wiphy, int *dbm)
}
-#define SCAN_DELAY_JIFFIES (HZ)
+#define SCAN_DELAY_JIFFIES (HZ * 6)
static int rndis_scan(struct wiphy *wiphy, struct net_device *dev,
struct cfg80211_scan_request *request)
{
^ permalink raw reply related
* Re: hal, rfkill and compat-wireless (Re: [RFC/RFT] rtl8187: Implement rfkill support)
From: Johannes Berg @ 2009-08-27 7:14 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: Hin-Tak Leung, hal, htl10, Larry Finger,
Herton Ronaldo Krzesinski, linux-wireless
In-Reply-To: <43e72e890908261645n24a040cds84f012095a40c15b@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 455 bytes --]
On Wed, 2009-08-26 at 16:45 -0700, Luis R. Rodriguez wrote:
> Johannes, did kernels < 2.6.31 have /sys/class/rfkill ?
Yes, but I never understood why that matters. If you've got
compat-wireless "rfkill" loaded then the original rfkill can't be loaded
anyway. And their symbols would probably clash anyway if the original is
built in, in which case you can't use compat.
You haven't renamed cfg80211's sysfs either, so why rfkill?
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH] rndis_wlan: set cipher suites for cfg80211
From: Holger Schurig @ 2009-08-27 6:52 UTC (permalink / raw)
To: Jussi Kivilinna; +Cc: linux-wireless, John W. Linville
In-Reply-To: <20090826211551.14002pzogxthwfk0@hayate.sektori.org>
On Wednesday 26 August 2009 20:15:51 Jussi Kivilinna wrote:
> Reason is that rndis_wlan should really check device
> capabilities and set cipher suites
> depending by theim
Ahh. I was under the impression that chips since two or three
year always support WEP, WPA and WPA2. And that only the orinoco
driver (or drivers for similar old chips) need to check the
firmware/chip to see what is available.
--
http://www.holgerschurig.de
^ permalink raw reply
* Re: [PATCH 2/2] ath5k: don't use PCI ID to find the chip revision
From: Bob Copeland @ 2009-08-27 3:45 UTC (permalink / raw)
To: Pavel Roskin; +Cc: ath5k-devel, linux-wireless, John W. Linville
In-Reply-To: <20090827023009.21926.49329.stgit@mj.roinet.com>
On Wed, Aug 26, 2009 at 10:30 PM, Pavel Roskin<proski@gnu.org> wrote:
> AR5K_SREV is available even if the chip has been put to sleep. Relying
> on the chip register allows binding non-standard PCI IDs by
>
> echo VENDOR_ID PRODUCT_ID >/sys/bus/pci/drivers/ath5k/new_id
>
> without having to specify the driver data as well.
>
> Signed-off-by: Pavel Roskin <proski@gnu.org>
Looks good, thanks!
Acked-by: Bob Copeland <me@bobcopeland.com>
--
Bob Copeland %% www.bobcopeland.com
^ permalink raw reply
* Re: [PATCH 1/2] ath5k: fix uninitialized value use in ath5k_eeprom_read_turbo_modes()
From: Bob Copeland @ 2009-08-27 3:43 UTC (permalink / raw)
To: Pavel Roskin; +Cc: ath5k-devel, linux-wireless, John W. Linville
In-Reply-To: <20090827023000.21926.90867.stgit@mj.roinet.com>
On Wed, Aug 26, 2009 at 10:30 PM, Pavel Roskin<proski@gnu.org> wrote:
> The `val' variable in ath5k_eeprom_read_turbo_modes() is used
> uninitialized. gcc 4.4.1 with -fno-inline-functions-called-once reports
> it:
>
> eeprom.c: In function 'ath5k_eeprom_read_turbo_modes':
> eeprom.c:441: warning: 'val' may be used uninitialized in this function
Thanks!
Acked-by: Bob Copeland <me@bobcopeland.com>
--
Bob Copeland %% www.bobcopeland.com
^ permalink raw reply
* Re: [PATCH 4/4] ath5k: add hardware CCMP encyption support
From: Bob Copeland @ 2009-08-27 3:27 UTC (permalink / raw)
To: Pavel Roskin
Cc: linville, jirislaby, mickflemm, lrodriguez, linux-wireless,
ath5k-devel
In-Reply-To: <1251338971.17295.17.camel@mj>
On Wed, Aug 26, 2009 at 10:09:31PM -0400, Pavel Roskin wrote:
> On Mon, 2009-08-24 at 23:00 -0400, Bob Copeland wrote:
> > + ah->ah_aes_support =
> > + (ee->ee_version >= AR5K_EEPROM_VERSION_5_0 &&
> > + !AR5K_EEPROM_AES_DIS(ee->ee_misc5) &&
> > + (ah->ah_mac_version > (AR5K_SREV_AR5212 >> 4) ||
> > + (ah->ah_mac_version == (AR5K_SREV_AR5212 >> 4) &&
> > + ah->ah_mac_revision >= (AR5K_SREV_AR5211 >> 4))));
>
> The above use of ah->ah_mac_revision is clearly incorrect. You are
> comparing a revision with a symbol for a version.
Well, this is exactly what legacy-hal does... so blame atheros :)
But yeah, we can just change it to look directly at the mac srev
since the revision check is confusing and the whole thing is needlessly
complex.
--
Bob Copeland %% www.bobcopeland.com
^ permalink raw reply
* Re: Congratulations
From: Larry Finger @ 2009-08-27 2:55 UTC (permalink / raw)
To: Gábor Stefanik
Cc: John Linville, Michael Buesch, Mark Huijgen, Broadcom Wireless,
linux-wireless
In-Reply-To: <69e28c910908261922p5ee551aeobd535fc2ceb2a814@mail.gmail.com>
Gábor Stefanik wrote:
> 2009/8/27 Larry Finger <Larry.Finger@lwfinger.net>:
>> Gábor,
>>
>> Congratulations on your progress. With today's patches my BCM4312
>> 802.11b/g card with PCI ID 14e4:4315 works - I'm using it at the
>> moment. I'm using WPA2 encryption and have connected to APs on
>> channels 1 and 11. My logs are clean.
>
> That's good to hear!
>
>> As you noted, performance is a little weak, but I get transmits of
>> 9-11 Mb/s and receive rates up to 18 Mb/s - eminently usable.
>
> What is your actual RX throughput? For me, it's usable up to 24Mb/s,
> but the actual throughput is limited to 1.2Mb/s.
That 18 Mb/s receive rate was observed data transfer from my server
that is wired to the router/AP and over the air to the BCM4312, just
as the 11 Mb/s was observed transfer from the BCM4312 to the server. I
have no idea what bit rate was set into the interface. Every time I
looked, it was at 1 Mb/s, but the throughput is better than that.
--snip--
>> For those of you with N PHYs, the RE of those devices will be my next
>> step.
>
> My next step will be calibration. :-)
>
> (However, calibration specs are still not complete - there are 2 wlc_*
> calls in PR41573. But that only matters for rev.0, and apparently all
> 4312s are rev.1.)
I missed those (obviously). Are there any other places in the LP PHY
that need work?
Larry
^ permalink raw reply
* [PATCH 2/2] ath5k: don't use PCI ID to find the chip revision
From: Pavel Roskin @ 2009-08-27 2:30 UTC (permalink / raw)
To: ath5k-devel, linux-wireless, John W. Linville
In-Reply-To: <20090827023000.21926.90867.stgit@mj.roinet.com>
AR5K_SREV is available even if the chip has been put to sleep. Relying
on the chip register allows binding non-standard PCI IDs by
echo VENDOR_ID PRODUCT_ID >/sys/bus/pci/drivers/ath5k/new_id
without having to specify the driver data as well.
Signed-off-by: Pavel Roskin <proski@gnu.org>
---
drivers/net/wireless/ath/ath5k/ath5k.h | 2 +-
drivers/net/wireless/ath/ath5k/attach.c | 14 +++++++----
drivers/net/wireless/ath/ath5k/base.c | 38 ++++++++++++++++---------------
3 files changed, 29 insertions(+), 25 deletions(-)
diff --git a/drivers/net/wireless/ath/ath5k/ath5k.h b/drivers/net/wireless/ath/ath5k/ath5k.h
index cdc79cd..c2d4c6a 100644
--- a/drivers/net/wireless/ath/ath5k/ath5k.h
+++ b/drivers/net/wireless/ath/ath5k/ath5k.h
@@ -1159,7 +1159,7 @@ struct ath5k_hw {
*/
/* Attach/Detach Functions */
-extern struct ath5k_hw *ath5k_hw_attach(struct ath5k_softc *sc, u8 mac_version);
+extern struct ath5k_hw *ath5k_hw_attach(struct ath5k_softc *sc);
extern void ath5k_hw_detach(struct ath5k_hw *ah);
/* LED functions */
diff --git a/drivers/net/wireless/ath/ath5k/attach.c b/drivers/net/wireless/ath/ath5k/attach.c
index 109ab7b..0d789ef 100644
--- a/drivers/net/wireless/ath/ath5k/attach.c
+++ b/drivers/net/wireless/ath/ath5k/attach.c
@@ -95,14 +95,13 @@ static int ath5k_hw_post(struct ath5k_hw *ah)
* ath5k_hw_attach - Check if hw is supported and init the needed structs
*
* @sc: The &struct ath5k_softc we got from the driver's attach function
- * @mac_version: The mac version id (check out ath5k.h) based on pci id
*
* Check if the device is supported, perform a POST and initialize the needed
* structs. Returns -ENOMEM if we don't have memory for the needed structs,
* -ENODEV if the device is not supported or prints an error msg if something
* else went wrong.
*/
-struct ath5k_hw *ath5k_hw_attach(struct ath5k_softc *sc, u8 mac_version)
+struct ath5k_hw *ath5k_hw_attach(struct ath5k_softc *sc)
{
struct ath5k_hw *ah;
struct pci_dev *pdev = sc->pdev;
@@ -136,9 +135,15 @@ struct ath5k_hw *ath5k_hw_attach(struct ath5k_softc *sc, u8 mac_version)
ah->ah_software_retry = false;
/*
- * Set the mac version based on the pci id
+ * Find the mac version
*/
- ah->ah_version = mac_version;
+ srev = ath5k_hw_reg_read(ah, AR5K_SREV);
+ if (srev < AR5K_SREV_AR5311)
+ ah->ah_version = AR5K_AR5210;
+ else if (srev < AR5K_SREV_AR5212)
+ ah->ah_version = AR5K_AR5211;
+ else
+ ah->ah_version = AR5K_AR5212;
/*Fill the ath5k_hw struct with the needed functions*/
ret = ath5k_hw_init_desc_functions(ah);
@@ -151,7 +156,6 @@ struct ath5k_hw *ath5k_hw_attach(struct ath5k_softc *sc, u8 mac_version)
goto err_free;
/* Get MAC, PHY and RADIO revisions */
- srev = ath5k_hw_reg_read(ah, AR5K_SREV);
ah->ah_mac_srev = srev;
ah->ah_mac_version = AR5K_REG_MS(srev, AR5K_SREV_VER);
ah->ah_mac_revision = AR5K_REG_MS(srev, AR5K_SREV_REV);
diff --git a/drivers/net/wireless/ath/ath5k/base.c b/drivers/net/wireless/ath/ath5k/base.c
index 94d46fd..9c6ab53 100644
--- a/drivers/net/wireless/ath/ath5k/base.c
+++ b/drivers/net/wireless/ath/ath5k/base.c
@@ -84,24 +84,24 @@ MODULE_VERSION("0.6.0 (EXPERIMENTAL)");
/* Known PCI ids */
static const struct pci_device_id ath5k_pci_id_table[] = {
- { PCI_VDEVICE(ATHEROS, 0x0207), .driver_data = AR5K_AR5210 }, /* 5210 early */
- { PCI_VDEVICE(ATHEROS, 0x0007), .driver_data = AR5K_AR5210 }, /* 5210 */
- { PCI_VDEVICE(ATHEROS, 0x0011), .driver_data = AR5K_AR5211 }, /* 5311 - this is on AHB bus !*/
- { PCI_VDEVICE(ATHEROS, 0x0012), .driver_data = AR5K_AR5211 }, /* 5211 */
- { PCI_VDEVICE(ATHEROS, 0x0013), .driver_data = AR5K_AR5212 }, /* 5212 */
- { PCI_VDEVICE(3COM_2, 0x0013), .driver_data = AR5K_AR5212 }, /* 3com 5212 */
- { PCI_VDEVICE(3COM, 0x0013), .driver_data = AR5K_AR5212 }, /* 3com 3CRDAG675 5212 */
- { PCI_VDEVICE(ATHEROS, 0x1014), .driver_data = AR5K_AR5212 }, /* IBM minipci 5212 */
- { PCI_VDEVICE(ATHEROS, 0x0014), .driver_data = AR5K_AR5212 }, /* 5212 combatible */
- { PCI_VDEVICE(ATHEROS, 0x0015), .driver_data = AR5K_AR5212 }, /* 5212 combatible */
- { PCI_VDEVICE(ATHEROS, 0x0016), .driver_data = AR5K_AR5212 }, /* 5212 combatible */
- { PCI_VDEVICE(ATHEROS, 0x0017), .driver_data = AR5K_AR5212 }, /* 5212 combatible */
- { PCI_VDEVICE(ATHEROS, 0x0018), .driver_data = AR5K_AR5212 }, /* 5212 combatible */
- { PCI_VDEVICE(ATHEROS, 0x0019), .driver_data = AR5K_AR5212 }, /* 5212 combatible */
- { PCI_VDEVICE(ATHEROS, 0x001a), .driver_data = AR5K_AR5212 }, /* 2413 Griffin-lite */
- { PCI_VDEVICE(ATHEROS, 0x001b), .driver_data = AR5K_AR5212 }, /* 5413 Eagle */
- { PCI_VDEVICE(ATHEROS, 0x001c), .driver_data = AR5K_AR5212 }, /* PCI-E cards */
- { PCI_VDEVICE(ATHEROS, 0x001d), .driver_data = AR5K_AR5212 }, /* 2417 Nala */
+ { PCI_VDEVICE(ATHEROS, 0x0207) }, /* 5210 early */
+ { PCI_VDEVICE(ATHEROS, 0x0007) }, /* 5210 */
+ { PCI_VDEVICE(ATHEROS, 0x0011) }, /* 5311 - this is on AHB bus !*/
+ { PCI_VDEVICE(ATHEROS, 0x0012) }, /* 5211 */
+ { PCI_VDEVICE(ATHEROS, 0x0013) }, /* 5212 */
+ { PCI_VDEVICE(3COM_2, 0x0013) }, /* 3com 5212 */
+ { PCI_VDEVICE(3COM, 0x0013) }, /* 3com 3CRDAG675 5212 */
+ { PCI_VDEVICE(ATHEROS, 0x1014) }, /* IBM minipci 5212 */
+ { PCI_VDEVICE(ATHEROS, 0x0014) }, /* 5212 combatible */
+ { PCI_VDEVICE(ATHEROS, 0x0015) }, /* 5212 combatible */
+ { PCI_VDEVICE(ATHEROS, 0x0016) }, /* 5212 combatible */
+ { PCI_VDEVICE(ATHEROS, 0x0017) }, /* 5212 combatible */
+ { PCI_VDEVICE(ATHEROS, 0x0018) }, /* 5212 combatible */
+ { PCI_VDEVICE(ATHEROS, 0x0019) }, /* 5212 combatible */
+ { PCI_VDEVICE(ATHEROS, 0x001a) }, /* 2413 Griffin-lite */
+ { PCI_VDEVICE(ATHEROS, 0x001b) }, /* 5413 Eagle */
+ { PCI_VDEVICE(ATHEROS, 0x001c) }, /* PCI-E cards */
+ { PCI_VDEVICE(ATHEROS, 0x001d) }, /* 2417 Nala */
{ 0 }
};
MODULE_DEVICE_TABLE(pci, ath5k_pci_id_table);
@@ -566,7 +566,7 @@ ath5k_pci_probe(struct pci_dev *pdev,
}
/* Initialize device */
- sc->ah = ath5k_hw_attach(sc, id->driver_data);
+ sc->ah = ath5k_hw_attach(sc);
if (IS_ERR(sc->ah)) {
ret = PTR_ERR(sc->ah);
goto err_irq;
^ permalink raw reply related
* Re: [PATCH] rtl8187: Fix for kernel oops when unloading with LEDs enabled
From: Gábor Stefanik @ 2009-08-27 2:29 UTC (permalink / raw)
To: Andrey Yurovsky
Cc: Richard Farina, Hin-Tak Leung, Larry Finger, John W Linville,
Herton Ronaldo Krzesinski, Hin-Tak Leung, linux-wireless
In-Reply-To: <45e8e6c40908261903r1e495ee6tb69277d99aa83e2b@mail.gmail.com>
On Thu, Aug 27, 2009 at 4:03 AM, Andrey Yurovsky<andrey@cozybit.com> wrote:
> Hi Richard,
>
> On Wed, Aug 26, 2009 at 4:11 PM, Richard Farina<sidhayn@gmail.com> wrote:
>> Again, I'm not trying to point my finger blaming someone, I'm trying to help
>> fix a problem. I am traveling for the next few days, when I get home to my
>> camera I hope you are all calm enough to help me troubleshoot this bug so we
>> can find a solution instead of accusing each other of accusing each other.
>
> you may want to try kexec in place of having to take photos of the
> kernel panic output. This will enable you to load a crash-recovery
> kernel, which will be booted automatically once you've successfully
> reproduced the problem. From there you can use gdb together with
> /proc/vmcore and your kernel image to reconstruct what you'd see in
> dmesg and paste the entire oops. Please see
> Documentation/kdump/kdump.txt for more details and use
> Documentation/kdump/gdbmacros.txt to give gdb a "dmesg" macro.
Or use the "crash" utility (a wrapper for gdb), which can directly
extract the kernel log from vmcore.
>
> -Andrey
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)
^ permalink raw reply
* [PATCH 1/2] ath5k: fix uninitialized value use in ath5k_eeprom_read_turbo_modes()
From: Pavel Roskin @ 2009-08-27 2:30 UTC (permalink / raw)
To: ath5k-devel, linux-wireless, John W. Linville
The `val' variable in ath5k_eeprom_read_turbo_modes() is used
uninitialized. gcc 4.4.1 with -fno-inline-functions-called-once reports
it:
eeprom.c: In function 'ath5k_eeprom_read_turbo_modes':
eeprom.c:441: warning: 'val' may be used uninitialized in this function
Comparing the code to the Atheros HAL, it's clear that the split between
ath5k_eeprom_read_modes() and ath5k_eeprom_read_turbo_modes() was
incorrect.
The Atheros HAL reads both turbo and non-turbo data from EEPROM in one
function. Some turbo mode parameters are derived from the same EEPROM
values as non-turbo parameters, just from different bits.
Merge ath5k_eeprom_read_turbo_modes() into ath5k_eeprom_read_modes() to
fix the warning. The actual values and offsets have been cross-checked
against Atheros HAL.
Signed-off-by: Pavel Roskin <proski@gnu.org>
---
drivers/net/wireless/ath/ath5k/eeprom.c | 29 +++++------------------------
1 files changed, 5 insertions(+), 24 deletions(-)
diff --git a/drivers/net/wireless/ath/ath5k/eeprom.c b/drivers/net/wireless/ath/ath5k/eeprom.c
index 8af477d..644962a 100644
--- a/drivers/net/wireless/ath/ath5k/eeprom.c
+++ b/drivers/net/wireless/ath/ath5k/eeprom.c
@@ -414,27 +414,11 @@ static int ath5k_eeprom_read_modes(struct ath5k_hw *ah, u32 *offset,
break;
}
-done:
- /* return new offset */
- *offset = o;
-
- return 0;
-}
-
-/*
- * Read turbo mode information on newer EEPROM versions
- */
-static int
-ath5k_eeprom_read_turbo_modes(struct ath5k_hw *ah,
- u32 *offset, unsigned int mode)
-{
- struct ath5k_eeprom_info *ee = &ah->ah_capabilities.cap_eeprom;
- u32 o = *offset;
- u16 val;
- int ret;
-
+ /*
+ * Read turbo mode information on newer EEPROM versions
+ */
if (ee->ee_version < AR5K_EEPROM_VERSION_5_0)
- return 0;
+ goto done;
switch (mode){
case AR5K_EEPROM_MODE_11A:
@@ -468,6 +452,7 @@ ath5k_eeprom_read_turbo_modes(struct ath5k_hw *ah,
break;
}
+done:
/* return new offset */
*offset = o;
@@ -504,10 +489,6 @@ ath5k_eeprom_init_modes(struct ath5k_hw *ah)
ret = ath5k_eeprom_read_modes(ah, &offset, mode);
if (ret)
return ret;
-
- ret = ath5k_eeprom_read_turbo_modes(ah, &offset, mode);
- if (ret)
- return ret;
}
/* override for older eeprom versions for better performance */
^ permalink raw reply related
* Re: Congratulations
From: Gábor Stefanik @ 2009-08-27 2:22 UTC (permalink / raw)
To: Larry Finger
Cc: John Linville, Michael Buesch, Mark Huijgen, Broadcom Wireless,
linux-wireless
In-Reply-To: <4A95D2A8.9090208@lwfinger.net>
2009/8/27 Larry Finger <Larry.Finger@lwfinger.net>:
> Gábor,
>
> Congratulations on your progress. With today's patches my BCM4312
> 802.11b/g card with PCI ID 14e4:4315 works - I'm using it at the
> moment. I'm using WPA2 encryption and have connected to APs on
> channels 1 and 11. My logs are clean.
That's good to hear!
>
> As you noted, performance is a little weak, but I get transmits of
> 9-11 Mb/s and receive rates up to 18 Mb/s - eminently usable.
What is your actual RX throughput? For me, it's usable up to 24Mb/s,
but the actual throughput is limited to 1.2Mb/s.
>
> I certainly hope that you get the patches approved so that these
> changes will be in the 2.6.32 kernel.
The patches are already in the tree, actually.
>
> Once again, congratulations to you, Michael, and the others members of
> the reverse engineering team. Seeing the device comes to life makes
> all those hours of staring at MIPS binary code seem very worthwhile.
>
> For those of you with N PHYs, the RE of those devices will be my next
> step.
My next step will be calibration. :-)
(However, calibration specs are still not complete - there are 2 wlc_*
calls in PR41573. But that only matters for rev.0, and apparently all
4312s are rev.1.)
>
> Larry
>
--
Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)
^ permalink raw reply
* Re: [PATCH 4/4] ath5k: add hardware CCMP encyption support
From: Pavel Roskin @ 2009-08-27 2:09 UTC (permalink / raw)
To: Bob Copeland
Cc: linville, jirislaby, mickflemm, lrodriguez, linux-wireless,
ath5k-devel
In-Reply-To: <1251169233-24169-5-git-send-email-me@bobcopeland.com>
On Mon, 2009-08-24 at 23:00 -0400, Bob Copeland wrote:
> + ah->ah_aes_support =
> + (ee->ee_version >= AR5K_EEPROM_VERSION_5_0 &&
> + !AR5K_EEPROM_AES_DIS(ee->ee_misc5) &&
> + (ah->ah_mac_version > (AR5K_SREV_AR5212 >> 4) ||
> + (ah->ah_mac_version == (AR5K_SREV_AR5212 >> 4) &&
> + ah->ah_mac_revision >= (AR5K_SREV_AR5211 >> 4))));
The above use of ah->ah_mac_revision is clearly incorrect. You are
comparing a revision with a symbol for a version.
I suggest that you use ah_mac_srev instead. Before this patch,
ah_mac_revision was a write-only variable and was a good candidate for
removal.
The last three quoted lines are equivalent to (ah->ah_mac_srev >= 0x54)
--
Regards,
Pavel Roskin
^ permalink raw reply
* Re: [PATCH] rtl8187: Fix for kernel oops when unloading with LEDs enabled
From: Andrey Yurovsky @ 2009-08-27 2:03 UTC (permalink / raw)
To: Richard Farina
Cc: Hin-Tak Leung, Larry Finger, John W Linville,
Herton Ronaldo Krzesinski, Hin-Tak Leung, linux-wireless
In-Reply-To: <4A95C128.5000405@gmail.com>
Hi Richard,
On Wed, Aug 26, 2009 at 4:11 PM, Richard Farina<sidhayn@gmail.com> wrote:
> Again, I'm not trying to point my finger blaming someone, I'm trying to help
> fix a problem. I am traveling for the next few days, when I get home to my
> camera I hope you are all calm enough to help me troubleshoot this bug so we
> can find a solution instead of accusing each other of accusing each other.
you may want to try kexec in place of having to take photos of the
kernel panic output. This will enable you to load a crash-recovery
kernel, which will be booted automatically once you've successfully
reproduced the problem. From there you can use gdb together with
/proc/vmcore and your kernel image to reconstruct what you'd see in
dmesg and paste the entire oops. Please see
Documentation/kdump/kdump.txt for more details and use
Documentation/kdump/gdbmacros.txt to give gdb a "dmesg" macro.
-Andrey
^ permalink raw reply
* Congratulations
From: Larry Finger @ 2009-08-27 0:26 UTC (permalink / raw)
To: Gábor Stefanik
Cc: John Linville, Michael Buesch, Mark Huijgen, Broadcom Wireless,
linux-wireless
In-Reply-To: <1251323178-7173-1-git-send-email-netrolller.3d@gmail.com>
Gábor,
Congratulations on your progress. With today's patches my BCM4312
802.11b/g card with PCI ID 14e4:4315 works - I'm using it at the
moment. I'm using WPA2 encryption and have connected to APs on
channels 1 and 11. My logs are clean.
As you noted, performance is a little weak, but I get transmits of
9-11 Mb/s and receive rates up to 18 Mb/s - eminently usable.
I certainly hope that you get the patches approved so that these
changes will be in the 2.6.32 kernel.
Once again, congratulations to you, Michael, and the others members of
the reverse engineering team. Seeing the device comes to life makes
all those hours of staring at MIPS binary code seem very worthwhile.
For those of you with N PHYs, the RE of those devices will be my next
step.
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