[PATCH][WAS:bcmai, axi] bcma: add Broadcom specific AMBA bus driver

Rafał Miłecki zajec5 at gmail.com
Sat May 7 15:21:46 EDT 2011


2011/5/7 George Kashperko <george at znau.edu.ua>:
>> >>
>> >> The purpose is ridiculously trivial. Print user-friendly names on
>> >> scanning. Why not do that?
>> > Output like
>> > Core 0: ChipCommon (id 0x800, rev 18, vendor 0x14e4)
>> > and
>> > Core 0: id 0x800, rev 18, vendor 0x14e4
>> > both give to 99% of linux systems' end-users exactly the same consistent
>> > information. Its more than enough for diagnostic purposes (I guess
>> > scanning code does outputs this for diagnostic purposes by those less
>> > than 1% of people who are aware wth is actually that ChipCommon is, not
>> > to be just user friendly?).
>>
>> Really, what's wrong with that? Does it kill anyone's pet we print
>> this? We also do:
>> pr_err("Scanning failed because of wrong CID\n");
>> return -1;
>> While we could drop pr_err. Why to do this? Advanced used can always
>> check what -1 means.
>>
>> I just like this. I find situations when it's useful, while I don't
>> see real negatives. I want to keep this. Can we leave this that way?
>> Unless someone finds some really bad effects of this?
> Nothing wrong except it makes kernel larger while gives _absolutely_ no
> benefit to end users. Regardless bus code prints core name or not it
> (core name) have absolutely no impact on driver matching.
>
> Imagine yourself an end-user who haven't got his 80211 core matched with
> driver and therefore he haven't got WiFi working.
> If bus driver code outputs
> Core X: id 0x812, rev. 8, vendor 0x4BF
> you (as end user) will look where is 0x4BF/0x812 driver supporting
> rev.8.
> But if bus driver code outputs
> Core X: MAC 802.11 (core id 0x812, rev. 8, vendor 0x4BF)
> you (as end user) empowered with MAC 802.11 name knowledge will still
> look where is 0x4BF/0x812 driver supporting rev.8.

I'll ask linux-wireless instead of linux-usb or linux-arm.

I didn't expect longer discussion so I got this trivial example of
pr_err. But it appears to be good example/question.

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;
	}
}

I believe according to your theory we should drop thi error message,
right? It eats memory to keep this string while error code can always
be checked in source.

-- 
Rafał



More information about the linux-arm-kernel mailing list