Re: [PATCH 8/8] addon_boards: mikrobus: Add GPS3 Click

[Ayush Singh <ayush@beagleboard.org>]

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:
>>>>>
>>>>>> On Wed, Sep 11, 2024 at 07:57:25PM +0530, Ayush Singh wrote:
>>>>>>> - GPS3 Click is a UART MikroBUS addon Board
>>>>>>>
>>>>>>> Link: https://www.mikroe.com/gps-3-click
>>>>>>>
>>>>>>> Signed-off-by: Ayush Singh <ayush@beagleboard.org>
>>>>>>> ---
>>>>>>>     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?
>>>>>>
>>>>>> thanks,
>>>>>>
>>>>>> greg k-h
>>>>>>
>>>>> Well, it is kinda a temporary location, since well, I could not
>>>>> find a good
>>>>> place for board overlays but a top-level location seems better
>>>>> than putting
>>>>> them in any arch specific location. I am open to moving them to a more
>>>>> suitable location if we have one.
>>>> top-level location is not ok for something so tiny and "special".  Just
>>>> put it where all other dtso files go.
>>>>
>>>> thanks,
>>>>
>>>> greg k-h
>>>
>>> So here are the directories where dtso files currently go:
>>>
>>> ❯ find . -type f -name "*.dtso" -printf "%h\n" | sort -u
>>> ./arch/arm64/boot/dts/amlogic
>>> ./arch/arm64/boot/dts/freescale
>>> ./arch/arm64/boot/dts/mediatek
>>> ./arch/arm64/boot/dts/qcom
>>> ./arch/arm64/boot/dts/renesas
>>> ./arch/arm64/boot/dts/rockchip
>>> ./arch/arm64/boot/dts/ti
>>> ./arch/arm64/boot/dts/xilinx
>>> ./arch/arm/boot/dts/nxp/imx
>>> ./arch/arm/boot/dts/ti/omap
>>> ./drivers/clk
>>> ./drivers/of
>>> ./drivers/of/unittest-data
>>>
>>>
>>> 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, 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.


[0]: 
https://devicetree-specification.readthedocs.io/en/v0.3/devicetree-basics.html#nexus-nodes-and-specifier-mapping


Ayush Singh