linux-kernel - Re: [PATCH v4 1/5] dt-bindings: misc: Add mikrobus-connector

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <5a9b1cd9-05ec-4606-92b6-eadbc7af6202@gmail.com>
Date: Tue, 19 Mar 2024 17:06:36 +0530
From: Ayush Singh <ayushdevel1325@...il.com>
To: Michael Walle <mwalle@...nel.org>,
 Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>,
 open list <linux-kernel@...r.kernel.org>
Cc: jkridner@...gleboard.org, robertcnelson@...gleboard.org,
 lorforlinux@...gleboard.org, Rob Herring <robh@...nel.org>,
 Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
 Conor Dooley <conor+dt@...nel.org>, Nishanth Menon <nm@...com>,
 Vignesh Raghavendra <vigneshr@...com>, Tero Kristo <kristo@...nel.org>,
 Derek Kiernan <derek.kiernan@....com>, Dragan Cvetic
 <dragan.cvetic@....com>, Arnd Bergmann <arnd@...db.de>,
 Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
 Vaishnav M A <vaishnav.a@...com>, Mark Brown <broonie@...nel.org>,
 Johan Hovold <johan@...nel.org>, Alex Elder <elder@...nel.org>,
 "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS"
 <devicetree@...r.kernel.org>,
 "moderated list:ARM/TEXAS INSTRUMENTS K3 ARCHITECTURE"
 <linux-arm-kernel@...ts.infradead.org>,
 "open list:SPI SUBSYSTEM" <linux-spi@...r.kernel.org>,
 "moderated list:GREYBUS SUBSYSTEM" <greybus-dev@...ts.linaro.org>,
 Vaishnav M A <vaishnav@...gleboard.org>
Subject: Re: [PATCH v4 1/5] dt-bindings: misc: Add mikrobus-connector

On 3/19/24 15:08, Michael Walle wrote:

> Hi,
>
>> 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.

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.

Ayush Singh

CorrectBasicCloseSpellingPossible spelling mistake found.GrabsGrey 
busIgnore