On 05/07/2011 06:49 PM, RafaÅ MiÅecki wrote:
2011/5/7 Arend van Spriel<arend@xxxxxxxxxxxx>:
On 05/07/2011 03:55 PM, Michael BÃsch wrote:
Arnd: did you have a look at defines at all?
Most of the defines have values in range 0x800 â 0x837. Converting
this to array means loosing 0x800 u16 entries. We can not use 0x800
offset, because there are also some defined between 0x000 and 0x800:
#define BCMA_CORE_OOB_ROUTER 0x367 /* Out of band */
#define BCMA_CORE_INVALID 0x700
Please be aware that the core identifier itself is not unique (in the
current list they are). In the scan the BCMA_CORE_OOB_ROUTER will always
show BCMA_MANUF_ARM (did not look up the proper manufacturer define but you
get the idea, i hope).
Unfortunately, I don't. Could you explain this? How core identified
can be not unique? Can 0x800 mean ChipCommon but also SuperPCIeX?
Yes, if ChipCommon is Broadcom core and SuperPCIeX is ARM core (or some
other). The core identifiers are chosen by a chip manufacturer (eg.
Broadcom ;-) ). They are not unique by itself so that is why the
bcma_device_id consists of manufacturer, id, rev, and class. Providing a
device table with ANY_MANUF would be a bad idea.
Gr. AvS
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
