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:
signature.asc
Description: PGP signature
