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:	Tue, 28 Jun 2016 19:38:25 +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 Tue, Jun 28, 2016 at 06:24:58PM +0200, Michal Suchanek wrote:

> No, no, no!

> This is NOT about loading an overlay. This is about talking on the bus
> without loading an overlay.

This is the solution you want to adopt because you've decided that it's
what you want.  You've said this quite a number of times now.

> > Repeating yourself over and over again is not going to help here, it's
> > just going to make people more annoyed.  Please stop this.

> Then please add something constructive to the debate rather than
> repeating that users have to add compatible for devices used with
> userspace driver. That's ridiculous from usability point of view and
> so will never happen. At best workarounds for kernel obtuseness will
> be used.

It would take a lot less effort for you to just describe your hardware
in DT than it would for you to continue repeating yourself, this is a
trivial task.  If the tooling around this is too hard to use then that
seems like a useful thing to work on, having simple ways for people to
describe modules they build for maker type systems (ideally integrated
with schematic capture software) would be great for example.

Both Greg and myself have provided you with feedback which you appear to
be ignoring entirely.  What you are demanding is not idiomatic for DT or
for the device model, this needs to be taken on board rather than just
shouting at us.  Putting a quick hack in that happens to work for your
very specific use case isn't going to give us a consistent, maintainable
and well designed system if it doesn't fit with anything else we're
doing.

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