On Thu, Sep 12, 2024 at 01:47:18PM +0530, Ayush Singh wrote: > On 9/12/24 13:09, Greg Kroah-Hartman wrote: > > On Thu, Sep 12, 2024 at 09:29:01AM +0200, Dirk Behme wrote: > > > On 12.09.2024 09:16, Ayush Singh wrote: > > > > On 9/12/24 01:34, Greg Kroah-Hartman wrote: > > > > > On Wed, Sep 11, 2024 at 09:26:06PM +0530, Ayush Singh wrote: > > > > > > On 9/11/24 20:28, Greg Kroah-Hartman wrote: > > > > > > > > addon_boards/mikrobus/Makefile | 1 + > > > > > > > > addon_boards/mikrobus/mikroe-1714.dtso | 28 > > > > > > > > ++++++++++++++++++++++++++++ > > > > > > > Odd top-level directory for the kernel, are you sure this is correct? > > > > > > I am open to moving them to a more suitable location if we have one. > > > > > > > > So here are the directories where dtso files currently go: > > > > ❯ find . -type f -name "*.dtso" -printf "%h\n" | sort -u > > > > > > > > > > > > Out of these, `drivers/of` and `drivers/of/unittest-data` contain > > > > unittest dtso, so probably not the place. > > > > > > > > And the `arch/arm` and `arch/arm64` are for arch specific stuff. > > > > MikroBUS is supported in RISC-V boards as well (BeagleV-Ahead). So > > > > probably not the correct location either. > > > > > > > > Maybe something like `arch/common/addon_boards` would be better? > > > Whats about > > > > > > drivers/misc/mikrobus/mikrobus.rs > > > drivers/misc/mikrobus/mikroe-1714.dtso > > > drivers/misc/mikrobus/mikroe-5761-i2c.dtso > > > > Exactly, put them where the drivers are, like clk and of does. > > > > thanks, > > greg k-h > > > So I am writing a more thorough reply in the driver questions, As I did read it, is it not "driver questions" but about "location of new files" and "bus versus device" > but essentially, the driver is not actually required for using the > overlay based approach for mikroBUS addon boards. Initially, the driver > was not supposed to be included in the patch series at all. But I was > not able to find a way to use a GPIO nexus node [0] without having a > platform driver attached to the node. > > In fact, if the GPIO nexus node is not required (like in the case of > weather click), there is no need to even have a mikrobus-connector > node in dt, let alone a driver. > > So to answer why it probably should not go in the driver directory, > the driver for the connector, actually does not register the mikrobus > addon board. And if there is a way to have GPIO nexus node without > having a platform driver attached to the node, then it should probably > be removed. > > The reason why the overlay based approach was suggested was because > previous approaches could not do board stacking (having chain of > mikrobus connector -> grove connector addon board -> grove board). So > as you can see, it is beneficial to have grove board overlays compiled > even in a board without any grove connectors because of stacking. Please be explicite about file location. And please elaborate on "bus" in mikrobus. Make it possible that your audience gets a completere picture. And for plan B: How important is this patch to the patch serie? Groeten Geert Stappers [0]: https://devicetree-specification.readthedocs.io/en/v0.3/devicetree-basics.html#nexus-nodes-and-specifier-mapping -- Silence is hard to parse
