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 for Android: free password hash cracker in your pocket

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

Date:	Thu, 30 Jun 2016 09:47:32 +0200
From:	Michal Suchanek <hramrach@...il.com>
To:	Mark Brown <broonie@...nel.org>
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 29 June 2016 at 20:02, Mark Brown <broonie@...nel.org> wrote:
> On Wed, Jun 29, 2016 at 05:32:48AM +0200, Michal Suchanek wrote:
>
>> The other is to get a generic expansion board and jumper wires. Of
>> course, you will not use all pins of your expansion connector this
>> way. On the other hand using the remaining pins becomes challenging
>> because of the jumper wires you just added. You can use some of the
>> remaining pins as GPIO or add more jumper wires and use some of the
>> remaining functions of the connector for another expansion board.
>
> I'm more than familiar with flying wire systems.  They just aren't a big
> deal here, this is a very technical audience making systems that aren't
> going to have their software meaningfully distributed.  Users making
> flying wire systems really ought to be capable of making the trivial DT
> changes required for them, and if they just hack something not great up
> locally that's not really a problem so long as it works for them.

No. Arduino tutorials made flying wire systems accessible to
non-technical audience. There are similar tutorials for boards running
vendor kernels.

Of course somebody with technical skill has to write the tutorial but
following it requires only understanding of written text - which is
becoming increasingly rare but is still not uncommon skill.

So to write such tutorial you have to give some steps to follow which
are reasonably likely to succeed on wide variety of boards and require
smallest possible changes to the board software.

For mainline this would currently entail

a) loading an overlay that lists spidev directly as compatible and
joke about obtuseness of the kernel developers that force you to read
the log spam

b) failing a) decompile your board devicetree, add the spidev
compatible - apply the overlay manually offline, recompile, and reboot

Adding new_id to spi bus does not simplify the thing at all. You still
have to modify your devicetree. It will at most remove the log spam.

I can even imagine people listing *all* their devices as compatible on
single dt node when the board does not ship with kernel patched for
loading overlays.

Thanks

Michal