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:
- 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.
- 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?
- 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-CLI...