From: "Michael Walle" <mwalle@kernel.org> To: "Vaishnav Achath" <vaishnav.a@ti.com>, "Andrew Lunn" <andrew@lunn.ch> Cc: "Russell King (Oracle)" <linux@armlinux.org.uk>, "Ayush Singh" <ayushdevel1325@gmail.com>, "open list" <linux-kernel@vger.kernel.org>, <jkridner@beagleboard.org>, <robertcnelson@beagleboard.org>, <lorforlinux@beagleboard.org>, "Rob Herring" <robh@kernel.org>, "Krzysztof Kozlowski" <krzysztof.kozlowski+dt@linaro.org>, "Conor Dooley" <conor+dt@kernel.org>, "Nishanth Menon" <nm@ti.com>, "Vignesh Raghavendra" <vigneshr@ti.com>, "Tero Kristo" <kristo@kernel.org>, "Derek Kiernan" <derek.kiernan@amd.com>, "Dragan Cvetic" <dragan.cvetic@amd.com>, "Arnd Bergmann" <arnd@arndb.de>, "Greg Kroah-Hartman" <gregkh@linuxfoundation.org>, "Mark Brown" <broonie@kernel.org>, "Johan Hovold" <johan@kernel.org>, "Alex Elder" <elder@kernel.org>, "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" <devicetree@vger.kernel.org>, "moderated list:ARM/TEXAS INSTRUMENTS K3 ARCHITECTURE" <linux-arm-kernel@lists.infradead.org>, "open list:SPI SUBSYSTEM" <linux-spi@vger.kernel.org>, "moderated list:GREYBUS SUBSYSTEM" <greybus-dev@lists.linaro.org>, "Vaishnav M A" <vaishnav@beagleboard.org> Subject: Re: [PATCH v4 1/5] dt-bindings: misc: Add mikrobus-connector Date: Thu, 21 Mar 2024 13:44:29 +0100 [thread overview] Message-ID: <CZZFRLRP6RKE.299OFG59KCK9L@kernel.org> (raw) In-Reply-To: <ef6a1c28-70dc-4077-b644-2704ac3cf30f@ti.com> Hi, > >>> Is that because the current software support is too limited? Are there > >>> manufactures who want to create more complex designed, but are limited > >>> by what can be described in the manifest? > >>> > >> > >> most mikroBUS add-on boards in production lies in the category of > >> sensors, displays, connectivity, mixed signal (ADC/DAC .etc) and if you > >> look at the existing bindings under bindings/iio/ , most devices need > >> only simple descriptions and the properties are mainly standard bus > >> properties (SPI/I2C properties), IRQ, named-gpios, named properties, > >> regulators, clocks the extension to manifest was made taking this into > >> account and the named property description interface just maps the > >> manifest entries to the unified device property interface under > >> include/linux/property.h > > > > How will the ethernet boards ([1], [2]) work? Where do they get > > their MAC address from, for example. The DT has some nice properties > > for that, but I doubt that will be possible with the manifest files. > > I've looked at the manifest file for the w5500 board [3] and to me > > it looks like that board will come up with a random MAC address on > > each start. Thus, even today, you have some boards which require > > a more complex description. > > > > Agreed, this is a limitation, unless the corresponding > drivers/subsystems use device_property_read_* helper to fetch > properties, it will not work and net/core/of_net.c only implements > of_get_* helpers even though the underlying functions can be implemented > with equivalent device_property_read_* equivalent as well. And I don't think this is a good idea given that the alternative is just working. > > Apart from the discussion whether the manifest is a suitable or > > sufficient mechanism to describe the hardware, I think the main > > problem with the proposed binding, is that it doesn't follow the > > binding Rob was proposing for a socket. If I want to use DT > > overlays, how would you describe an add-on board? > > > > The proposal was that the base board has something like > > > > mikrobus: socket { > > compatible = "mikrobus-socket"; > > i2c-parent = <&i2c0>; > > spi-parent = <&spi0>; > > > > i2c {}; > > spi {}; > > }; > > > > an add-on board can then have a DT snippet/overlay like the > > following: > > > > &mikrobus { > > i2c { > > eeprom@52: { > > reg = <52>; > > compatible = <atmel,at24..>; > > } > > }; > > > > spi { > > sensor@0: { > > reg = <0>; > > compatible = <foobar>; > > }; > > }; > > }; > > > > That should be possible with a binding for the mikrobus, which > > in fact it is just a pin header with a standard pinout. Also as > > Russell pointed out in v3, the EEPROM/manifest is not part of the > > mikrobus standard. So maybe that deserves an own compatible, like > > > > compatible = "mikroe,click", "mikrobus-socket"; > > > > Or maybe click-eeprom? Although click seems to be the brand name of > > MikroElektronika. > > Agreed, there is nothing preventing us to convert the binding and update > the driver to follow the above proposed format and will be done in next > revision. Click is brand name of MikroElektronika and they don't allow > custom boards to use that branding, however clickid can be used in the > case where EEPROM is present/enable the socket to be probeable. Thinking about this again. I'm not sure this additional compatible really helps the discovery. It's a chicken egg problem. Only the modules knows if it has an EEPROM, but then, we already have to know it's in the socket. So while it might help for a static configuration, it does not for the discovery. -michael > > [1] https://www.mikroe.com/eth-3-click > > [2] https://www.mikroe.com/eth-wiz-click > > [3] https://github.com/MikroElektronika/click_id/blob/main/manifests/ETH-WIZ-CLICK.mnfs
WARNING: multiple messages have this Message-ID (diff)
From: "Michael Walle" <mwalle@kernel.org> To: "Vaishnav Achath" <vaishnav.a@ti.com>, "Andrew Lunn" <andrew@lunn.ch> Cc: "Russell King (Oracle)" <linux@armlinux.org.uk>, "Ayush Singh" <ayushdevel1325@gmail.com>, "open list" <linux-kernel@vger.kernel.org>, <jkridner@beagleboard.org>, <robertcnelson@beagleboard.org>, <lorforlinux@beagleboard.org>, "Rob Herring" <robh@kernel.org>, "Krzysztof Kozlowski" <krzysztof.kozlowski+dt@linaro.org>, "Conor Dooley" <conor+dt@kernel.org>, "Nishanth Menon" <nm@ti.com>, "Vignesh Raghavendra" <vigneshr@ti.com>, "Tero Kristo" <kristo@kernel.org>, "Derek Kiernan" <derek.kiernan@amd.com>, "Dragan Cvetic" <dragan.cvetic@amd.com>, "Arnd Bergmann" <arnd@arndb.de>, "Greg Kroah-Hartman" <gregkh@linuxfoundation.org>, "Mark Brown" <broonie@kernel.org>, "Johan Hovold" <johan@kernel.org>, "Alex Elder" <elder@kernel.org>, "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" <devicetree@vger.kernel.org>, "moderated list:ARM/TEXAS INSTRUMENTS K3 ARCHITECTURE" <linux-arm-kernel@lists.infradead.org>, "open list:SPI SUBSYSTEM" <linux-spi@vger.kernel.org>, "moderated list:GREYBUS SUBSYSTEM" <greybus-dev@lists.linaro.org>, "Vaishnav M A" <vaishnav@beagleboard.org> Subject: Re: [PATCH v4 1/5] dt-bindings: misc: Add mikrobus-connector Date: Thu, 21 Mar 2024 13:44:29 +0100 [thread overview] Message-ID: <CZZFRLRP6RKE.299OFG59KCK9L@kernel.org> (raw) In-Reply-To: <ef6a1c28-70dc-4077-b644-2704ac3cf30f@ti.com> Hi, > >>> Is that because the current software support is too limited? Are there > >>> manufactures who want to create more complex designed, but are limited > >>> by what can be described in the manifest? > >>> > >> > >> most mikroBUS add-on boards in production lies in the category of > >> sensors, displays, connectivity, mixed signal (ADC/DAC .etc) and if you > >> look at the existing bindings under bindings/iio/ , most devices need > >> only simple descriptions and the properties are mainly standard bus > >> properties (SPI/I2C properties), IRQ, named-gpios, named properties, > >> regulators, clocks the extension to manifest was made taking this into > >> account and the named property description interface just maps the > >> manifest entries to the unified device property interface under > >> include/linux/property.h > > > > How will the ethernet boards ([1], [2]) work? Where do they get > > their MAC address from, for example. The DT has some nice properties > > for that, but I doubt that will be possible with the manifest files. > > I've looked at the manifest file for the w5500 board [3] and to me > > it looks like that board will come up with a random MAC address on > > each start. Thus, even today, you have some boards which require > > a more complex description. > > > > Agreed, this is a limitation, unless the corresponding > drivers/subsystems use device_property_read_* helper to fetch > properties, it will not work and net/core/of_net.c only implements > of_get_* helpers even though the underlying functions can be implemented > with equivalent device_property_read_* equivalent as well. And I don't think this is a good idea given that the alternative is just working. > > Apart from the discussion whether the manifest is a suitable or > > sufficient mechanism to describe the hardware, I think the main > > problem with the proposed binding, is that it doesn't follow the > > binding Rob was proposing for a socket. If I want to use DT > > overlays, how would you describe an add-on board? > > > > The proposal was that the base board has something like > > > > mikrobus: socket { > > compatible = "mikrobus-socket"; > > i2c-parent = <&i2c0>; > > spi-parent = <&spi0>; > > > > i2c {}; > > spi {}; > > }; > > > > an add-on board can then have a DT snippet/overlay like the > > following: > > > > &mikrobus { > > i2c { > > eeprom@52: { > > reg = <52>; > > compatible = <atmel,at24..>; > > } > > }; > > > > spi { > > sensor@0: { > > reg = <0>; > > compatible = <foobar>; > > }; > > }; > > }; > > > > That should be possible with a binding for the mikrobus, which > > in fact it is just a pin header with a standard pinout. Also as > > Russell pointed out in v3, the EEPROM/manifest is not part of the > > mikrobus standard. So maybe that deserves an own compatible, like > > > > compatible = "mikroe,click", "mikrobus-socket"; > > > > Or maybe click-eeprom? Although click seems to be the brand name of > > MikroElektronika. > > Agreed, there is nothing preventing us to convert the binding and update > the driver to follow the above proposed format and will be done in next > revision. Click is brand name of MikroElektronika and they don't allow > custom boards to use that branding, however clickid can be used in the > case where EEPROM is present/enable the socket to be probeable. Thinking about this again. I'm not sure this additional compatible really helps the discovery. It's a chicken egg problem. Only the modules knows if it has an EEPROM, but then, we already have to know it's in the socket. So while it might help for a static configuration, it does not for the discovery. -michael > > [1] https://www.mikroe.com/eth-3-click > > [2] https://www.mikroe.com/eth-wiz-click > > [3] https://github.com/MikroElektronika/click_id/blob/main/manifests/ETH-WIZ-CLICK.mnfs _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2024-03-21 12:44 UTC|newest] Thread overview: 106+ messages / expand[flat|nested] mbox.gz Atom feed top 2024-03-17 19:37 [PATCH v4 0/5] misc: Add mikroBUS driver Ayush Singh 2024-03-17 19:37 ` Ayush Singh 2024-03-17 19:37 ` [PATCH v4 1/5] dt-bindings: misc: Add mikrobus-connector Ayush Singh 2024-03-17 19:37 ` Ayush Singh 2024-03-18 12:22 ` Michael Walle 2024-03-18 12:22 ` Michael Walle 2024-03-18 17:20 ` Ayush Singh 2024-03-18 17:20 ` Ayush Singh 2024-03-19 5:58 ` Krzysztof Kozlowski 2024-03-19 5:58 ` Krzysztof Kozlowski 2024-03-19 7:36 ` Ayush Singh 2024-03-19 7:36 ` Ayush Singh 2024-03-19 9:38 ` Michael Walle 2024-03-19 9:38 ` Michael Walle 2024-03-19 11:36 ` Ayush Singh 2024-03-19 11:36 ` Ayush Singh 2024-03-19 12:08 ` Michael Walle 2024-03-19 12:08 ` Michael Walle 2024-03-19 13:03 ` Ayush Singh 2024-03-19 13:03 ` Ayush Singh 2024-03-19 14:21 ` Michael Walle 2024-03-19 14:21 ` Michael Walle 2024-03-19 17:19 ` Vaishnav Achath 2024-03-19 17:19 ` Vaishnav Achath 2024-03-19 17:35 ` Ayush Singh 2024-03-19 17:35 ` Ayush Singh 2024-03-19 19:32 ` Andrew Lunn 2024-03-19 19:32 ` Andrew Lunn 2024-03-20 16:39 ` Ayush Singh 2024-03-20 16:39 ` Ayush Singh 2024-03-20 18:44 ` Andrew Lunn 2024-03-20 18:44 ` Andrew Lunn 2024-03-21 7:35 ` Vaishnav Achath 2024-03-21 7:35 ` Vaishnav Achath 2024-03-21 12:31 ` Andrew Lunn 2024-03-21 12:31 ` Andrew Lunn 2024-03-19 12:25 ` Andrew Lunn 2024-03-19 12:25 ` Andrew Lunn 2024-03-19 17:35 ` Vaishnav Achath 2024-03-19 17:35 ` Vaishnav Achath 2024-03-19 18:19 ` Conor Dooley 2024-03-19 18:19 ` Conor Dooley 2024-03-21 6:30 ` Vaishnav Achath 2024-03-21 6:30 ` Vaishnav Achath 2024-03-19 19:23 ` Andrew Lunn 2024-03-19 19:23 ` Andrew Lunn 2024-03-21 7:07 ` Vaishnav Achath 2024-03-21 7:07 ` Vaishnav Achath 2024-03-21 9:38 ` Michael Walle 2024-03-21 9:38 ` Michael Walle 2024-03-21 11:55 ` Vaishnav Achath 2024-03-21 11:55 ` Vaishnav Achath 2024-03-21 12:44 ` Michael Walle [this message] 2024-03-21 12:44 ` Michael Walle 2024-03-21 12:55 ` Andrew Lunn 2024-03-21 12:55 ` Andrew Lunn 2024-03-19 6:03 ` Krzysztof Kozlowski 2024-03-19 6:03 ` Krzysztof Kozlowski 2024-03-19 6:42 ` Ayush Singh 2024-03-19 6:42 ` Ayush Singh 2024-03-19 19:37 ` Conor Dooley 2024-03-19 19:37 ` Conor Dooley 2024-03-22 18:15 ` Ayush Singh 2024-03-22 18:15 ` Ayush Singh 2024-03-22 18:51 ` Andrew Lunn 2024-03-22 18:51 ` Andrew Lunn 2024-03-17 19:37 ` [PATCH v4 2/5] spi: Make of_find_spi_controller_by_node() available Ayush Singh 2024-03-17 19:37 ` Ayush Singh 2024-03-19 8:16 ` Markus Elfring 2024-03-19 8:16 ` Markus Elfring 2024-03-17 19:37 ` [PATCH v4 3/5] greybus: Add mikroBUS manifest types Ayush Singh 2024-03-17 19:37 ` Ayush Singh 2024-03-19 8:26 ` Vaishnav Achath 2024-03-19 8:26 ` Vaishnav Achath 2024-03-17 19:37 ` [PATCH v4 4/5] mikrobus: Add mikroBUS driver Ayush Singh 2024-03-17 19:37 ` Ayush Singh 2024-03-17 19:59 ` Randy Dunlap 2024-03-17 19:59 ` Randy Dunlap 2024-03-18 17:34 ` Markus Elfring 2024-03-18 17:34 ` Markus Elfring 2024-03-18 17:58 ` Markus Elfring 2024-03-18 17:58 ` Markus Elfring 2024-03-18 18:41 ` Alex Elder 2024-03-18 18:41 ` Alex Elder 2024-03-18 18:55 ` Greg Kroah-Hartman 2024-03-18 18:55 ` Greg Kroah-Hartman 2024-03-18 18:12 ` Markus Elfring 2024-03-18 18:12 ` Markus Elfring 2024-03-19 6:04 ` Krzysztof Kozlowski 2024-03-19 6:04 ` Krzysztof Kozlowski 2024-03-19 6:47 ` Ayush Singh 2024-03-19 6:47 ` Ayush Singh 2024-03-19 8:00 ` Vaishnav Achath 2024-03-19 8:00 ` Vaishnav Achath 2024-03-20 7:33 ` Krzysztof Kozlowski 2024-03-20 7:33 ` Krzysztof Kozlowski 2024-03-19 8:49 ` Vaishnav Achath 2024-03-19 8:49 ` Vaishnav Achath 2024-03-17 19:37 ` [PATCH v4 5/5] dts: ti: k3-am625-beagleplay: Add mikroBUS Ayush Singh 2024-03-17 19:37 ` Ayush Singh 2024-03-19 5:59 ` Krzysztof Kozlowski 2024-03-19 5:59 ` Krzysztof Kozlowski 2024-03-19 6:34 ` Ayush Singh 2024-03-19 6:34 ` Ayush Singh 2024-03-20 7:31 ` Krzysztof Kozlowski 2024-03-20 7:31 ` Krzysztof Kozlowski
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=CZZFRLRP6RKE.299OFG59KCK9L@kernel.org \ --to=mwalle@kernel.org \ --cc=andrew@lunn.ch \ --cc=arnd@arndb.de \ --cc=ayushdevel1325@gmail.com \ --cc=broonie@kernel.org \ --cc=conor+dt@kernel.org \ --cc=derek.kiernan@amd.com \ --cc=devicetree@vger.kernel.org \ --cc=dragan.cvetic@amd.com \ --cc=elder@kernel.org \ --cc=gregkh@linuxfoundation.org \ --cc=greybus-dev@lists.linaro.org \ --cc=jkridner@beagleboard.org \ --cc=johan@kernel.org \ --cc=kristo@kernel.org \ --cc=krzysztof.kozlowski+dt@linaro.org \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-spi@vger.kernel.org \ --cc=linux@armlinux.org.uk \ --cc=lorforlinux@beagleboard.org \ --cc=nm@ti.com \ --cc=robertcnelson@beagleboard.org \ --cc=robh@kernel.org \ --cc=vaishnav.a@ti.com \ --cc=vaishnav@beagleboard.org \ --cc=vigneshr@ti.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.