On 3/19/24 17:38, Michael Walle wrote:
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.
I do not understand what you mean. For EEPROM supported boards, user
space is not involved. The driver can directly read the manifest from
add-on board and setup everything, so it is plug and play.
The manual involvement of user space is only for non EEPROM boards since
we do not have a way to identify the board without the user needing to
provide the manifest.
Also how do you know whether there is an EEPROM
or not?
Set RST GPIO to low. clickID supported board will enter ID MODE, Then
check if CS line has a w1 gpio bus.
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?
Greybus is a communication protocol designed for modular electronic
devices. It allows different parts of a device to be hot plugged (added
or removed) while the device is still running. Greybus manifest is used
to describe the capabilities of a module in the greybus network. The
host then creates appropriate bidirectional unipro connections with the
module based on the cports described in the manifest. I have added a
link to lwn article that goes into more detail.
BeagleConnect simply allows using greybus over any bidirectional
transport, instead of just Unipro.
I cannot comment much about how greybus handles missing properties.
While greybus also works just in kernel space, greybus protocols are
inherently higher level than kernel driver, so it might have an easier
time with this.
I have also added a link to eLInux page which provides rational for the
mikroBUS manifest. But the crux seems to be that dynamic overlays were
not well-supported back then. Also, the use of mikroBUS using greybus
subsystem was already used. Hence the mikroBUS driver.
Greybus is not a big blocker from my perspective, since it is always
possible to introduce a new protocol for mikroBUS in Greybus spec. I
think as long as both EEPROM and non EEPROM boards can be supported by
mikroBUS driver and dt-bindings, are can be used outside of Linux (eg:
ZephyrRTOS, nuttx, etc), it is fine.
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
Yes, the concern is valid. Support for validating the manifest is
nowhere near as good as devicetree overlays. But I think that would be a
problem with the device rather than the responsibility of the kernel. It
is up to the manufacturer to have valid manifests.
Link: https://lwn.net/Articles/715955/ Greybus
Link https://elinux.org/Mikrobus eLinux article
Ayush Singh
