[0/4,v1] Mezzanine Low Speed connector bus

Message ID 20180823103332.32047-1-linus.walleij@linaro.org
Headers show
Series
  • Mezzanine Low Speed connector bus
Related show

Message

Linus Walleij Aug. 23, 2018, 10:33 a.m.
I have been a bit hesitant to reiterate the series, but this is
anyways a v1 of the 96Boards Mezzanine Low Speed connector
driver framework.

I know the boards have a high speed connector as well, just
trying to work stepwise and do the simple things first.

What convinced me to continue was very real usecases that exist
today, as this makes the secure96 Mezzanine work:

- Get something upstream that makes it possible to without
  any trouble or extensive ugly hacking probe and use the
  secure96 mezzanine. This is motivated by the IoT design
  space which needs a way to plug in proper security and the
  secure96 offers a TPM chip for root of trust and key
  handling.

- A clear indication that the same approach will work just
  as fine with ACPI without reinventing the universe. I do
  not have a definitive proof of this, but it is more
  plausible that this will be reusable for ACPI than any of
  the DT-centric ideas I've seen for populating
  daughterboards. There are 96boards using ACPI today.
  A secure96 TPM is desireable for things like the ARM
  developer box which has this LS connector:
  https://www.96boards.org/product/developerbox/

- Some indication that binding the connector like this will
  not implicate or screw things up for the DT-overlays
  idea, i.e. a both/and and not either/or approach.

The idea is for this to go upstream through ARM SoC the day
noone actively NACK it and someone actively ACK it. Expect
some more iterations.

Linus Walleij (4):
  eeprom: at24: Allow passing gpiodesc from pdata
  spi: Make of_find_spi_device_by_node() available
  bus: Add DT bindings for 96Boards low speed connector
  bus: 96boards Low-Speed Connector

 .../bus/96boards,low-speed-connector.txt      |  50 +++
 drivers/bus/Kconfig                           |   2 +
 drivers/bus/Makefile                          |   4 +-
 drivers/bus/daughterboards/96boards-ls-bus.c  |  39 ++
 .../daughterboards/96boards-ls-connector.c    | 367 ++++++++++++++++++
 .../bus/daughterboards/96boards-mezzanines.h  |  77 ++++
 .../bus/daughterboards/96boards-secure96.c    | 265 +++++++++++++
 drivers/bus/daughterboards/Kconfig            |  50 +++
 drivers/bus/daughterboards/Makefile           |   6 +
 drivers/misc/eeprom/at24.c                    |   6 +-
 drivers/spi/spi.c                             |  33 +-
 include/linux/platform_data/at24.h            |   2 +
 include/linux/spi/spi.h                       |   4 +
 13 files changed, 888 insertions(+), 17 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/bus/96boards,low-speed-connector.txt
 create mode 100644 drivers/bus/daughterboards/96boards-ls-bus.c
 create mode 100644 drivers/bus/daughterboards/96boards-ls-connector.c
 create mode 100644 drivers/bus/daughterboards/96boards-mezzanines.h
 create mode 100644 drivers/bus/daughterboards/96boards-secure96.c
 create mode 100644 drivers/bus/daughterboards/Kconfig
 create mode 100644 drivers/bus/daughterboards/Makefile

-- 
2.17.0

Comments

Frank Rowand Aug. 23, 2018, 11:06 p.m. | #1
On 08/23/18 03:33, Linus Walleij wrote:
> I have been a bit hesitant to reiterate the series, but this is

> anyways a v1 of the 96Boards Mezzanine Low Speed connector

> driver framework.

> 

> I know the boards have a high speed connector as well, just

> trying to work stepwise and do the simple things first.

> 

> What convinced me to continue was very real usecases that exist

> today, as this makes the secure96 Mezzanine work:

> 

> - Get something upstream that makes it possible to without

>   any trouble or extensive ugly hacking probe and use the

>   secure96 mezzanine. This is motivated by the IoT design

>   space which needs a way to plug in proper security and the

>   secure96 offers a TPM chip for root of trust and key

>   handling.

> 

> - A clear indication that the same approach will work just

>   as fine with ACPI without reinventing the universe. I do

>   not have a definitive proof of this, but it is more

>   plausible that this will be reusable for ACPI than any of

>   the DT-centric ideas I've seen for populating

>   daughterboards. There are 96boards using ACPI today.

>   A secure96 TPM is desireable for things like the ARM

>   developer box which has this LS connector:

>   https://www.96boards.org/product/developerbox/

> 

> - Some indication that binding the connector like this will

>   not implicate or screw things up for the DT-overlays

>   idea, i.e. a both/and and not either/or approach.

> 

> The idea is for this to go upstream through ARM SoC the day

> noone actively NACK it and someone actively ACK it. Expect

> some more iterations.

> 

> Linus Walleij (4):

>   eeprom: at24: Allow passing gpiodesc from pdata

>   spi: Make of_find_spi_device_by_node() available

>   bus: Add DT bindings for 96Boards low speed connector

>   bus: 96boards Low-Speed Connector


For the moment, NACK since there is not a substantive change
from before.  This is without having read beyond this
introduction.

I will read through the rest of the series and revisit my
previous conclusions, but most likely not for a few days.

-Frank

> 

>  .../bus/96boards,low-speed-connector.txt      |  50 +++

>  drivers/bus/Kconfig                           |   2 +

>  drivers/bus/Makefile                          |   4 +-

>  drivers/bus/daughterboards/96boards-ls-bus.c  |  39 ++

>  .../daughterboards/96boards-ls-connector.c    | 367 ++++++++++++++++++

>  .../bus/daughterboards/96boards-mezzanines.h  |  77 ++++

>  .../bus/daughterboards/96boards-secure96.c    | 265 +++++++++++++

>  drivers/bus/daughterboards/Kconfig            |  50 +++

>  drivers/bus/daughterboards/Makefile           |   6 +

>  drivers/misc/eeprom/at24.c                    |   6 +-

>  drivers/spi/spi.c                             |  33 +-

>  include/linux/platform_data/at24.h            |   2 +

>  include/linux/spi/spi.h                       |   4 +

>  13 files changed, 888 insertions(+), 17 deletions(-)

>  create mode 100644 Documentation/devicetree/bindings/bus/96boards,low-speed-connector.txt

>  create mode 100644 drivers/bus/daughterboards/96boards-ls-bus.c

>  create mode 100644 drivers/bus/daughterboards/96boards-ls-connector.c

>  create mode 100644 drivers/bus/daughterboards/96boards-mezzanines.h

>  create mode 100644 drivers/bus/daughterboards/96boards-secure96.c

>  create mode 100644 drivers/bus/daughterboards/Kconfig

>  create mode 100644 drivers/bus/daughterboards/Makefile

>
Linus Walleij Aug. 24, 2018, 7:28 a.m. | #2
On Fri, Aug 24, 2018 at 1:06 AM Frank Rowand <frowand.list@gmail.com> wrote:
> On 08/23/18 03:33, Linus Walleij wrote:


> > - Some indication that binding the connector like this will

> >   not implicate or screw things up for the DT-overlays

> >   idea, i.e. a both/and and not either/or approach.

(...)
>

> For the moment, NACK since there is not a substantive change

> from before.  This is without having read beyond this

> introduction.


So I guess you disagree with the previous statement, and
I need some elaboration to understand exactly what in this
approach works counter to the goals of DT overlays.

It's not like I'm overly infatuated with my own approach, but
I want to get to a point where people can start to use these
daughterboards no matter whether they use DT or ACPI.

I'm missing ACPI input though, the DT people are more
responsive :/

> I will read through the rest of the series and revisit my

> previous conclusions, but most likely not for a few days.


OK no problem there is no immediate hurry.

Yours,
Linus Walleij
Frank Rowand Nov. 15, 2018, 4:26 p.m. | #3
Hi Linus,

On 8/23/18 4:06 PM, Frank Rowand wrote:
> On 08/23/18 03:33, Linus Walleij wrote:

>> I have been a bit hesitant to reiterate the series, but this is

>> anyways a v1 of the 96Boards Mezzanine Low Speed connector

>> driver framework.


< snip >

> I will read through the rest of the series and revisit my

> previous conclusions, but most likely not for a few days.

> 

> -Frank


< snip >

My apologies for continuing to not getting to this task.  It
has been in the top grouping of my todo list but has been
pushed aside by a rather busy schedule of conferences and
company internal work.  It remains up at the top of my todo
list, but most likely will still be shunted aside for three
more weeks of other pressing work.

I will get to it, I definitely have not forgotten it.

-Frank
Linus Walleij Nov. 15, 2018, 10:59 p.m. | #4
On Thu, Nov 15, 2018 at 5:27 PM Frank Rowand <frowand.list@gmail.com> wrote:
> On 8/23/18 4:06 PM, Frank Rowand wrote:

> > On 08/23/18 03:33, Linus Walleij wrote:

> >> I have been a bit hesitant to reiterate the series, but this is

> >> anyways a v1 of the 96Boards Mezzanine Low Speed connector

> >> driver framework.

>

> < snip >

>

> > I will read through the rest of the series and revisit my

> > previous conclusions, but most likely not for a few days.

> >

> > -Frank

>

> < snip >

>

> My apologies for continuing to not getting to this task.  It

> has been in the top grouping of my todo list but has been

> pushed aside by a rather busy schedule of conferences and

> company internal work.  It remains up at the top of my todo

> list, but most likely will still be shunted aside for three

> more weeks of other pressing work.

>

> I will get to it, I definitely have not forgotten it.


It's OK, I might get to rebasing the series even.

We discussed it in a session with Linaro in Vancouver
recently (some month ago). What we took away from it
is that there are many precedents of populating devices
ad hoc, what really makes this one special is that it takes
something device tree and ad hoc populates something
on top of it, not defined in the device tree itself.

On a related note, Heikki Krogerus is making a software
FWnode population series. I ran into this when converting
board files to use more abstract descriptions. Check it out:
https://marc.info/?l=linux-kernel&m=154177331200561&w=2

The idea with the series is to expand FWnode so that it
doesn't only populate Linux devices from device tree
or ACPI but also by software, where needed, further
expanding the fwnode abstraction. I will probably look
into using that.

Yours,
Linus Walleij
Frank Rowand Nov. 16, 2018, 12:16 a.m. | #5
On 11/15/18 2:59 PM, Linus Walleij wrote:
> On Thu, Nov 15, 2018 at 5:27 PM Frank Rowand <frowand.list@gmail.com> wrote:

>> On 8/23/18 4:06 PM, Frank Rowand wrote:

>>> On 08/23/18 03:33, Linus Walleij wrote:

>>>> I have been a bit hesitant to reiterate the series, but this is

>>>> anyways a v1 of the 96Boards Mezzanine Low Speed connector

>>>> driver framework.

>>

>> < snip >

>>

>>> I will read through the rest of the series and revisit my

>>> previous conclusions, but most likely not for a few days.

>>>

>>> -Frank

>>

>> < snip >

>>

>> My apologies for continuing to not getting to this task.  It

>> has been in the top grouping of my todo list but has been

>> pushed aside by a rather busy schedule of conferences and

>> company internal work.  It remains up at the top of my todo

>> list, but most likely will still be shunted aside for three

>> more weeks of other pressing work.

>>

>> I will get to it, I definitely have not forgotten it.

> 

> It's OK, I might get to rebasing the series even.

> 

> We discussed it in a session with Linaro in Vancouver

> recently (some month ago). What we took away from it


It would be helpful for me to look at that.  What was the
title of the session, or a pointer to the resource page
for it?

-Frank

> is that there are many precedents of populating devices

> ad hoc, what really makes this one special is that it takes

> something device tree and ad hoc populates something

> on top of it, not defined in the device tree itself.

> 

> On a related note, Heikki Krogerus is making a software

> FWnode population series. I ran into this when converting

> board files to use more abstract descriptions. Check it out:

> https://marc.info/?l=linux-kernel&m=154177331200561&w=2

> 

> The idea with the series is to expand FWnode so that it

> doesn't only populate Linux devices from device tree

> or ACPI but also by software, where needed, further

> expanding the fwnode abstraction. I will probably look

> into using that.

> 

> Yours,

> Linus Walleij

>