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

[Geert Stappers]

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