linux-kernel - Re: [PATCH 2/3] spi: of: allow instantiating slaves without a 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:	Sun, 26 Jun 2016 17:19:54 +0200
From:	Michal Suchanek <hramrach@...il.com>
To:	Mark Brown <broonie@...nel.org>
Cc:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Ingo Molnar <mingo@...nel.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Kees Cook <keescook@...omium.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Dan Williams <dan.j.williams@...el.com>,
	Tejun Heo <tj@...nel.org>,
	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
	Davidlohr Bueso <dave@...olabs.net>,
	Andrey Ryabinin <aryabinin@...tuozzo.com>,
	Nikolay Aleksandrov <nikolay@...ulusnetworks.com>,
	Dmitry Vyukov <dvyukov@...gle.com>,
	Adrien Schildknecht <adrien+dev@...ischi.me>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	linux-spi <linux-spi@...r.kernel.org>
Subject: Re: [PATCH 2/3] spi: of: allow instantiating slaves without a driver

On 26 June 2016 at 14:57, Mark Brown <broonie@...nel.org> wrote:
> On Sun, Jun 26, 2016 at 02:53:31PM +0200, Michal Suchanek wrote:
>> On 26 June 2016 at 14:45, Mark Brown <broonie@...nel.org> wrote:
>
>> > No, there's other things like figuring out which controller to bind to
>> > that need to be taken into consideration.
>
>> Why do you care? So long as you name the CS that is available on
>> connector with the same pinout same on all boards you can target the
>> slave regardless of the controller it's attached to.
>
> That would be a binding for the connector which is the big missing bit
> here - it's not clear that such a limited connector description would be
> a good idea.

It would work for a limited number of devices. Anyway, connectors are
supposed to be transparent so if binding devices has issues now it
will supposedly have same issues once connectors allow renaming
several devices at once from board-specific name to connector-specific
name rather than one at a time as this limited connector binding
allows.

Thanks

Michal