[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAOMqctTf16DDs1j+pL47xBJt2BVdCdHPFUEwaZ6ak_vFtrKBOQ@mail.gmail.com>
Date: Sun, 26 Jun 2016 14:39:20 +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 13:58, Mark Brown <broonie@...nel.org> wrote:
> On Sun, Jun 26, 2016 at 01:35:46PM +0200, Michal Suchanek wrote:
>> On 26 June 2016 at 13:21, Mark Brown <broonie@...nel.org> wrote:
>
>> > You can just add the entire slave node in the overlay, it's not clear
>> > that this buys us anything useful
>
>> You have to target the master node and specify the CS in the overlay
>> if you create the whole node. If you target the slave node you have
>> the CS specified in the board devicetree and the overlay can apply to
>> multiple boards without change.
>
> No, there's a lot more to having overlays to board-neutral connectors...
If you are fine with using only the SPI pins then this is all it takes.
If you want to know that i2c2 pins happen to be next to the SPI pins
on the connector and use them as GPIO pins for your SPI device reset
and irq lines then you will need a lot more infrastructure for that to
happen.
>
>> > and this needs to be joined up with the work going on to allow
>> > expansion connector overlays to be loaded in the first place.
>
>> The overlays work equally well before and after this patch. I don't
>> see any problem with them other than part of the infrastructure
>> missing in mainline kernel.
>
> ...you're missing all this stuff here - currently the active work on
> this is being done by Patelis. It's not at all clear to me that
> referring to a slave rather than a master would be any easier in a board
> neutral overlay.
I cherry-picked one of his branches to try overlay loading. Anyhow,
most of the kernel support is already there. The missing part which
blocks any progress for a very long time already is importing DTC with
overlay support into the kernel and building the devicetree blobs with
overlay support.
Thanks
Michal
Powered by blists - more mailing lists