> On Sat, 2011-05-07 at 22:35 +0300, George Kashperko wrote:
> > dbg_bcma_device_name
> > {
> > #ifdef DEBUG
> > case/switch/if/else stuff
> > #endif
> > return NULL;
> > }
> > But I don't see here much sense to hardcode names other than those of
> > buscommons/buscores for debugging purposes.
>
> Would you please read and understand the code before discussing this?
> That would help the discussion on the technical side.
>
> Those names are hardcoded by definition. And just like 14e4 is the PCI
> ID for Broadcom devices, 800 is the AXI ID for Broadcom Chipcommon.
>
> And building an #ifdef mess around this stuff is not better than having
> a few bytes of _helpful_ information messages.
> You are absolutely right that those messages only help 1% of the people.
> Just as _any_ other kernel message.
>
Following is first part of my comment with "case/switch/if/else stuff"
which you didn't quoted and which I was actually commented at:
> > How do you see relation between bcma_device_name and:
> > int zd_ioread32v_locked(...) {
> > if (r) {
> > dev_dbg_f(zd_chip_dev(chip),
> > "error: zd_ioread16v_locked. Error number %d\n", r);
> > return r;
> > }
> }
> No relation at all. It like comparing warm and soft. It will be if you
> do something like
Original discussion on the bcma_device_name was started by Arend
pointing that there can be cores with same id but different vendor code.
As one among ways to deal with this I've proposed to remove
bcma_device_name and let drivers supply core name.
Have nice day,
George
--
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
