Forest Bond wrote:
> On Wed, Aug 15, 2007 at 07:59:51AM +0200, Ulrich Kunitz wrote:
> >> Vendor: Shuttle
> >> Model: PN18G (although it doesn't seem to be marked as such)
> >> USB Device ID: 07b8:6001
> >> Chip: ZD1211B
> >> RF: AL2230S
> >> Anyway, it looks like this is a re-use of a previously existing device ID.
> >> I had to modify the driver to get it working (patch attached).
> > We have seen this now several times. Zydas/Atheros told us that
> > this shouldn't happen, because this was the only method, we have
> > been aware to distinguish between both products.
> I see. So, the only apparent solution is to notify Atheros of the problem,
> hope that they chastise the module manufacturer appropriately?
I would not call that a solution because the devices are out
> >> I hope this is enough info to get this working in mainline.
> > Not really, we need to find another way to identify the chip.
> It wouldn't be something you could find in /proc/bus/usb/devices, would it?
I don't think so, I'm thinking more specific entries in the
EEPROM. We would need a debug version that dumps the EEPROM before
we load the firmware. We will have to find data at some offset,
which reliably would tell us, whether we deal with a ZD1211B
instead of a ZD1211. Just classical reverse engineering. If I have
such code ready I would send it to you and I would need your dump. I
happened to own the old PN18 and so we could compare the EEPROM
contents and do something with this. But don't expect any working
code before the weekend.
> Ah, so you can't use a EAFP/trial-and-error approach (and LBYL is not an
> due to the chip not making any mechanism available by which it can be
I don't want to try it, we had several problems with reloading
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
Zd1211-devs mailing list - http://zd1211.wiki.sourceforge.net/