| 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
| ||
|
Message-ID: <20240628172729.GD3143032-robh@kernel.org>
Date: Fri, 28 Jun 2024 11:27:29 -0600
From: Rob Herring <robh@...nel.org>
To: Ayush Singh <ayush@...gleboard.org>
Cc: Andrew Davis <afd@...com>, Mark Brown <broonie@...nel.org>,
Vaishnav M A <vaishnav@...gleboard.org>,
Krzysztof Kozlowski <krzk+dt@...nel.org>,
Conor Dooley <conor+dt@...nel.org>,
Derek Kiernan <derek.kiernan@....com>,
Dragan Cvetic <dragan.cvetic@....com>,
Arnd Bergmann <arnd@...db.de>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Nishanth Menon <nm@...com>, Vignesh Raghavendra <vigneshr@...com>,
Tero Kristo <kristo@...nel.org>, Michael Walle <mwalle@...nel.org>,
Andrew Lunn <andrew@...n.ch>, jkridner@...gleboard.org,
robertcnelson@...gleboard.org, linux-spi@...r.kernel.org,
linux-kernel@...r.kernel.org, devicetree@...r.kernel.org,
linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH v5 7/7] dts: ti: k3-am625-beagleplay: Add mikroBUS
On Thu, Jun 27, 2024 at 11:46:31PM +0530, Ayush Singh wrote:
>
> On 6/27/24 23:20, Andrew Davis wrote:
> > On 6/27/24 12:16 PM, Ayush Singh wrote:
> > >
> > > On 6/27/24 22:37, Andrew Davis wrote:
> > > > On 6/27/24 11:26 AM, Ayush Singh wrote:
> > > > > DONOTMERGE
> > > > >
> > > > > Add mikroBUS connector and some mikroBUS boards support for
> > > > > Beagleplay.
> > > > > The mikroBUS boards node should probably be moved to a more
> > > > > appropriate
> > > > > location but I am not quite sure where it should go since it is not
> > > > > dependent on specific arch.
> > > > >
> > > > > Signed-off-by: Ayush Singh <ayush@...gleboard.org>
> > > > > ---
> > > > > arch/arm64/boot/dts/ti/k3-am625-beagleplay.dts | 94
> > > > > +++++++++++++++++++++++---
> > > > > 1 file changed, 86 insertions(+), 8 deletions(-)
> > > > >
> > > > > diff --git a/arch/arm64/boot/dts/ti/k3-am625-beagleplay.dts
> > > > > b/arch/arm64/boot/dts/ti/k3-am625-beagleplay.dts
> > > > > index 70de288d728e..3f3cd70345c4 100644
> > > > > --- a/arch/arm64/boot/dts/ti/k3-am625-beagleplay.dts
> > > > > +++ b/arch/arm64/boot/dts/ti/k3-am625-beagleplay.dts
> > > > > @@ -38,6 +38,7 @@ aliases {
> > > > > serial2 = &main_uart0;
> > > > > usb0 = &usb0;
> > > > > usb1 = &usb1;
> > > > > + mikrobus0 = &mikrobus0;
> > > > > };
> > > > > chosen {
> > > > > @@ -227,6 +228,56 @@ simple-audio-card,codec {
> > > > > };
> > > > > };
> > > > > + mikrobus0: mikrobus-connector {
> > > > > + compatible = "mikrobus-connector";
> > > > > + pinctrl-names = "default", "pwm_default", "pwm_gpio",
> > > > > + "uart_default", "uart_gpio", "i2c_default",
> > > > > + "i2c_gpio", "spi_default", "spi_gpio";
> > > > > + pinctrl-0 = <&mikrobus_gpio_pins_default>;
> > > > > + pinctrl-1 = <&mikrobus_pwm_pins_default>;
> > > > > + pinctrl-2 = <&mikrobus_pwm_pins_gpio>;
> > > > > + pinctrl-3 = <&mikrobus_uart_pins_default>;
> > > > > + pinctrl-4 = <&mikrobus_uart_pins_gpio>;
> > > > > + pinctrl-5 = <&mikrobus_i2c_pins_default>;
> > > > > + pinctrl-6 = <&mikrobus_i2c_pins_gpio>;
> > > > > + pinctrl-7 = <&mikrobus_spi_pins_default>;
> > > > > + pinctrl-8 = <&mikrobus_spi_pins_gpio>;
> > > > > +
> > > > > + mikrobus-gpio-names = "pwm", "int", "rx", "tx", "scl", "sda",
> > > > > + "mosi", "miso", "sck", "cs", "rst", "an";
> > > > > + mikrobus-gpios = <&main_gpio1 11 GPIO_ACTIVE_HIGH>,
> > > > > + <&main_gpio1 9 GPIO_ACTIVE_HIGH>,
> > > > > + <&main_gpio1 24 GPIO_ACTIVE_HIGH>,
> > > > > + <&main_gpio1 25 GPIO_ACTIVE_HIGH>,
> > > > > + <&main_gpio1 22 GPIO_ACTIVE_HIGH>,
> > > > > + <&main_gpio1 23 GPIO_ACTIVE_HIGH>,
> > > > > + <&main_gpio1 7 GPIO_ACTIVE_HIGH>,
> > > > > + <&main_gpio1 8 GPIO_ACTIVE_HIGH>,
> > > > > + <&main_gpio1 14 GPIO_ACTIVE_HIGH>,
> > > > > + <&main_gpio1 13 GPIO_ACTIVE_HIGH>,
> > > > > + <&main_gpio1 12 GPIO_ACTIVE_HIGH>,
> > > > > + <&main_gpio1 10 GPIO_ACTIVE_HIGH>;
> > > > > +
> > > > > + spi-controller = <&main_spi2>;
> > > > > + spi-cs = <0>;
> > > > > + spi-cs-names = "default";
> > > > > +
> > > > > + board = <&lsm6dsl_click>;
> > > > > + };
> > > > > +
> > > > > + mikrobus_boards {
> > > > > + thermo_click: thermo-click {
> > > > > + compatible = "maxim,max31855k", "mikrobus-spi";
> > > >
> > > > I might be missing something, but your solution cannot possibly be
> > > > to list every click board that could be connected (all 1500+ of them)
> > > > to every mikroBUS connector on every device's DT file..
> > >
> > >
> > > I think you missed something. `mikrobus-boards` is not a child node
> > > of `mikrobus0`. See the `board` property in `mikrobus0`. That is
> > > what selects the board attached to the connector.
> > >
> >
> > That seems even worse.. That means the board file needs to know about the
> > attached board, which is not how DT works. It describes hardware in a
> > hierarchical/acyclic graph. For instance, take an I2C device, its node
> > is a child of the I2C bus, and has phandle pointers to the IRQ it uses
> > (or whatever else provider it needs). What you have here is like the
> > I2C bus node phandle pointing to the connected child devices.
> >
> > > The `mikcrobus-boards` node itself should be moved to some
> > > independent location and included from a system that wants to
> > > support mikrobus boards. The connector will only have a phandle to
> > > the board (or boards in case a single mikroBUS board has 1 i2c and 1
> > > spi sensor or some combination).
> > >
> >
> > How about providing the full/final example then (this series should be
> > marked
> > as RFC as it is now has missing parts). Move the click board node into a
> > DTSO
> > file and put that in a common location (click boards are common to all
> > boards
> > right, so lets say in drivers/of/click for now just for the RFC).
> >
> > >
> > > >
> > > > Each click board should have a single DTSO overlay file to describe the
> > > > click board, one per click board total. And then that overlay should
> > > > apply cleanly to any device that has a mikroBUS interface.
> > >
> > >
> > > Yes, that is the goal.
> > >
> > >
> > > >
> > > > Which means you have not completely solved the fundamental problem of
> > > > abstracting the mikroBUS connector in DT. Each of these click
> > > > device child
> > > > nodes has to be under the parent connector node. Which means a phandle
> > > > to the parent node, which is not generically named. For instance
> > > > if my board has 2 connectors, I would have mikrobus0 and mikrobus1,
> > > > the click board's overlay would look like this:
> > > >
> > > > /dts-v1/;
> > > > /plugin/;
> > > >
> > > > &mikrobus0 {
> > > > status = "okay";
> > > >
> > > > mikrobus_board {
> > > > thermo-click {
> > > > compatible = "maxim,max31855k", "mikrobus-spi";
> > > > spi-max-frequency = <1000000>;
> > > > pinctrl-apply = "spi_default";
> > > > };
> > > > };
> > > > };
> > >
> > >
> > > No, it will look as follows:
> > >
> > > ```
> > >
> > > &mikrobus0 {
> >
> > ^^^
> > So same issue, what if I want to attach this click board
> > to the second mikrobus connector on my board (i.e. mikrobus1),
> > I'd have to modify the overlay.. Or have an overlay for every
> > possible connector instance number.
>
>
> The plan is to have a sysfs `new_device` and `delete_device` entry like I2C
> has where the board name is passed. The driver can then create a dt
> changeset apply to live tree. In the current dt, the changeset is to add a
> `board` property with the phandle of a board (if found).
>
> Can you suggest how something similar will be possible if the board node is
> a child of the connector node? Maybe it is possible to take a generic dt
> overlay and change the name of parent node on it or something?
You need to describe the problem(s) to solve first, and then a solution.
You're just giving us a solution to review.
Let's start with you have an add-on board and an overlay for that board.
No one wants N overlays for N base board for a single physical board.
One board, one overlay. Any solution must provide that.
Who knows when a board is connected and what board it is? Each one
could be the OS or the user. Worst case is nothing is detected and it is
just the user knows "I've connected board X to connector A" and has to
tell the OS that. Or the OS can detect a board and figure out what board
via EEPROM with no user intervention. In between is OS detects a board,
but needs the user to say which one. The detecting everything case is
easy. The connector driver knows which connector it is and which
overlay. You just need to define how you select the overlay file based
on EEPROM data. The others will need some sort of interface for
the user to provide the information.
Rob
Powered by blists - more mailing lists