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]

Date:	Sat, 07 May 2011 22:02:11 +0300
From:	George Kashperko <george@...u.edu.ua>
To:	Rafał Miłecki <zajec5@...il.com>
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

> >>
> >> 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.

Really, there will be more and more core codes/types/name. Why hardcode
those into kernel for some e. g. memory-constraint system while you
still can (and in most cases also will) have them in dedicated drivers?

Btw, have you ever suffered hardly from PCI naming devices xxxx.xx.xx.x
but not "Network device" ?

Have nice day,
George


--
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/