2011/5/7 George Kashperko <[email protected]>: > >> 2011/5/6 Rafał Miłecki <[email protected]>: >> > 2011/5/6 Arnd Bergmann <[email protected]>: >> >>> +const char *bcma_device_name(u16 coreid) >> >>> +{ >> >>> + switch (coreid) { >> >>> + case BCMA_CORE_OOB_ROUTER: >> >>> + return "OOB Router"; >> >>> + case BCMA_CORE_INVALID: >> >>> + return "Invalid"; >> >>> + case BCMA_CORE_CHIPCOMMON: >> >>> + return "ChipCommon"; >> >>> + case BCMA_CORE_ILINE20: >> >>> + return "ILine 20"; >> >> >> >> It's better to make that a data structure than a switch() statement, >> >> both from readability and efficiency aspects. >> > >> > Well, maybe. We call it only once, at init time. In any case we're >> > still waiting for Broadcom to clarify which cores are really used for >> > BCMA. >> >> 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 >> >> Oh and there is still: >> #define BCMA_CORE_DEFAULT 0xFFF >> we could want to include. Then we would loose additional (0xFFF - >> 0x837) u16 entries in array. > What is the purpose for bcma_device_name in bus driver code ? Why not > define const char *name in struct bcma_driver and let driver writers > supply kernel with knowledge on new cores' names rather than hard type > those into the bus code ?
The purpose is ridiculously trivial. Print user-friendly names on scanning. Why not do that? Let's allow user understand what his bus contains without looking info defines in .h. > Also this will close the question Arend asked > you regarding same core ids with different manufacturer ids. I don't know what was Arend's question. I asked but it was few minutes ago. I guess he just wanted to point there can be other manufacturer's cores. -- Rafał _______________________________________________ devel mailing list [email protected] http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
