linux-kernel - Re: [PATCH v2 3/3] drivers core: allow id match override when manually binding 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:	Mon, 27 Jun 2016 21:32:33 +0100
From:	Mark Brown <broonie@...nel.org>
To:	Michal Suchanek <hramrach@...il.com>
Cc:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	linux-spi <linux-spi@...r.kernel.org>
Subject: Re: [PATCH v2 3/3] drivers core: allow id match override when
 manually binding driver

On Mon, Jun 27, 2016 at 09:40:38PM +0200, Michal Suchanek wrote:

> No. It's for buses that have some inherent identification. It's not for

> 1) generate random compatible and stick it in device tree

Don't generate a random compatible, generate one that accurately
describes your hardware.

> also AFAIK new_id is not automagic and not all buses have it.

Yes, this is the bit I've been trying to prompt you to implement rather
than going off doing something broken.

> So it would have to be implemented on SPI. How? On PCI new_id is a PCI
> id. What is it on SPI? ACPI PnP id? DT compatible? How do you tell?

Those sound like sensible ideas.

> And why when the bus does not even have IDs?

Identifiers are just a useful way of describing what the hardware is,
the fact that some of them can be read back from hardware isn't terribly
important here.

Download attachment "signature.asc" of type "application/pgp-signature" (474 bytes)