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
