From: "Michael Walle" <mwalle@kernel.org>
To: "Ayush Singh" <ayushdevel1325@gmail.com>,
"Krzysztof Kozlowski" <krzysztof.kozlowski@linaro.org>,
"open list" <linux-kernel@vger.kernel.org>
Cc: <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>,
"Vaishnav M A" <vaishnav.a@ti.com>,
"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: Tue, 19 Mar 2024 13:08:33 +0100 [thread overview]
Message-ID: <CZXPQZY8PUGE.QZM8XSOUNMT4@kernel.org> (raw)
In-Reply-To: <5a9b1cd9-05ec-4606-92b6-eadbc7af6202@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3046 bytes --]
On Tue Mar 19, 2024 at 12:36 PM CET, Ayush Singh wrote:
> >> Regardless, this patch actually does not contain any code for EEPROM
> >> support I have just mentioned it to give more context on why mikroBUS
> >> manifest is the focus of this patch instead of DT overlay or something
> >> else.
> > Right, and I think this is the crux here. Why can't you use DT
> > overlays? The manifest files, seem to be yet another hardware
> > description (method) and we already have DT. Can't we have some kind
> > of userspace helper that could translate them to DT overlays? That
> > way, you could also handle the EEPROM vs non-EEPROM case, or have
> > some other kind of method to load a DT overlay.
> >
> > Admittedly, I've never worked with in-kernel overlays, but AFAIK
> > they work with some subsystems.
> >
> > -michael
>
>
> So let me 1st go over 3 cases that the driver needs to support:
>
> 1. Non EEPROM boards:
>
> Using overlays should be pretty similar to current solution. If the
> manifest is converted to overlay in userspace, then we do not even need
> to do manifest parsing, setting up spi, i2c etc in the kernel driver.
>
>
> 2. EEPROM boards
>
> How do you propose handling these. If you are proposing storing dt
> overlay in EEPROM, then this raises some questions regarding support
> outside of Linux.
>
> The other option would be generating overlay from manifest in the kernel
> driver, which I'm not sure is significantly better than registering the
> i2c, spi, etc. interfaces separately using standard kernel APIs.
You did answer that yourself in (1): you could use a user space
helper to translate it to a DT overlay, I don't think this has to be
done in the kernel. Also how do you know whether there is an EEPROM
or not?
> 3. Over Greybus
>
> It is quite important to have mikroBUS over greybus for BeagleConnect.
> This is one of the major reasons why greybus manifest was chosen for the
> manifest format.
>
> Also, it is important to note that mikroBUS manifest is being used since
> 2020 now and thus manifests for a lot of boards (both supporting clickID
> and not supporting it exist). So I would prefer using it, unless of
> course there are strong reasons not to.
And also here, I'm not really familiar with greybus. Could you give
a more complex example? My concern is that some driver might need
additional properties from DT (or software nodes) to function
properly. It might not only be a node with a compatible string but
also more advanced bindings. How would that play together with this?
My gut feeling is that you can handle any missing properties
easier/better (eg. for existing modules) in user space. But maybe
that is already solved in/with greybus?
Here's a random one: the manifest [1] just lists the compatible
string apparently, but the actual DT binding has also reset-gpios,
some -supply and interrupt properties.
-michael
[1] https://github.com/MikroElektronika/click_id/blob/main/manifests/WEATHER-CLICK.mnfs
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 252 bytes --]
next prev parent reply other threads:[~2024-03-19 12:08 UTC|newest]
Thread overview: 53+ 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 ` [PATCH v4 1/5] dt-bindings: misc: Add mikrobus-connector Ayush Singh
2024-03-18 12:22 ` Michael Walle
2024-03-18 17:20 ` Ayush Singh
2024-03-19 5:58 ` Krzysztof Kozlowski
2024-03-19 7:36 ` Ayush Singh
2024-03-19 9:38 ` Michael Walle
2024-03-19 11:36 ` Ayush Singh
2024-03-19 12:08 ` Michael Walle [this message]
2024-03-19 13:03 ` Ayush Singh
2024-03-19 14:21 ` Michael Walle
2024-03-19 17:19 ` Vaishnav Achath
2024-03-19 17:35 ` Ayush Singh
2024-03-19 19:32 ` Andrew Lunn
2024-03-20 16:39 ` Ayush Singh
2024-03-20 18:44 ` Andrew Lunn
2024-03-21 7:35 ` Vaishnav Achath
2024-03-21 12:31 ` Andrew Lunn
2024-03-19 12:25 ` Andrew Lunn
2024-03-19 17:35 ` Vaishnav Achath
2024-03-19 18:19 ` Conor Dooley
2024-03-21 6:30 ` Vaishnav Achath
2024-03-19 19:23 ` Andrew Lunn
2024-03-21 7:07 ` Vaishnav Achath
2024-03-21 9:38 ` Michael Walle
2024-03-21 11:55 ` Vaishnav Achath
2024-03-21 12:44 ` Michael Walle
2024-03-21 12:55 ` Andrew Lunn
2024-03-19 6:03 ` Krzysztof Kozlowski
2024-03-19 6:42 ` Ayush Singh
2024-03-19 19:37 ` Conor Dooley
2024-03-22 18:15 ` Ayush Singh
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-19 8:16 ` Markus Elfring
2024-03-17 19:37 ` [PATCH v4 3/5] greybus: Add mikroBUS manifest types Ayush Singh
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:59 ` Randy Dunlap
2024-03-18 17:34 ` Markus Elfring
2024-03-18 17:58 ` Markus Elfring
2024-03-18 18:41 ` Alex Elder
2024-03-18 18:55 ` Greg Kroah-Hartman
2024-03-18 18:12 ` Markus Elfring
2024-03-19 6:04 ` Krzysztof Kozlowski
2024-03-19 6:47 ` Ayush Singh
2024-03-19 8:00 ` Vaishnav Achath
2024-03-20 7:33 ` Krzysztof Kozlowski
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-19 5:59 ` Krzysztof Kozlowski
2024-03-19 6:34 ` Ayush Singh
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=CZXPQZY8PUGE.QZM8XSOUNMT4@kernel.org \
--to=mwalle@kernel.org \
--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=krzysztof.kozlowski@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-spi@vger.kernel.org \
--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: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).