| Message ID | 20180823103332.32047-1-linus.walleij@linaro.org |
|---|---|
| Headers | show |
| Series | Mezzanine Low Speed connector bus | expand |
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 >
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
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
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
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 >