linux-kernel - Re: [PATCH][WAS:bcmai,axi] bcma: add Broadcom specific AMBA bus driver

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <BANLkTik9FWgzpNWuMXXRjOj-rDvPNY_nCA@mail.gmail.com>
Date:	Sat, 7 May 2011 21:21:46 +0200
From:	Rafał Miłecki <zajec5@...il.com>
To:	George Kashperko <george@...u.edu.ua>
Cc:	Arnd Bergmann <arnd@...db.de>, linux-wireless@...r.kernel.org,
	"John W. Linville" <linville@...driver.com>,
	b43-dev@...ts.infradead.org, Greg KH <greg@...ah.com>,
	Michael Büsch <mb@...sch.de>,
	Larry Finger <Larry.Finger@...inger.net>,
	Arend van Spriel <arend@...adcom.com>,
	linux-arm-kernel@...ts.infradead.org,
	Russell King <rmk@....linux.org.uk>,
	Andy Botting <andy@...ybotting.com>,
	linuxdriverproject <devel@...uxdriverproject.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH][WAS:bcmai,axi] bcma: add Broadcom specific AMBA bus driver

2011/5/7 George Kashperko <george@...u.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ł
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/