Hi,
Is that because the current software support is too limited? Are there manufactures who want to create more complex designed, but are limited by what can be described in the manifest?
most mikroBUS add-on boards in production lies in the category of sensors, displays, connectivity, mixed signal (ADC/DAC .etc) and if you look at the existing bindings under bindings/iio/ , most devices need only simple descriptions and the properties are mainly standard bus properties (SPI/I2C properties), IRQ, named-gpios, named properties, regulators, clocks the extension to manifest was made taking this into account and the named property description interface just maps the manifest entries to the unified device property interface under include/linux/property.h
How will the ethernet boards ([1], [2]) work? Where do they get their MAC address from, for example. The DT has some nice properties for that, but I doubt that will be possible with the manifest files. I've looked at the manifest file for the w5500 board [3] and to me it looks like that board will come up with a random MAC address on each start. Thus, even today, you have some boards which require a more complex description.
Apart from the discussion whether the manifest is a suitable or sufficient mechanism to describe the hardware, I think the main problem with the proposed binding, is that it doesn't follow the binding Rob was proposing for a socket. If I want to use DT overlays, how would you describe an add-on board?
The proposal was that the base board has something like
mikrobus: socket { compatible = "mikrobus-socket"; i2c-parent = <&i2c0>; spi-parent = <&spi0>;
i2c {}; spi {}; };
an add-on board can then have a DT snippet/overlay like the following:
&mikrobus { i2c { eeprom@52: { reg = <52>; compatible = <atmel,at24..>; } };
spi { sensor@0: { reg = <0>; compatible = <foobar>; }; }; };
That should be possible with a binding for the mikrobus, which in fact it is just a pin header with a standard pinout. Also as Russell pointed out in v3, the EEPROM/manifest is not part of the mikrobus standard. So maybe that deserves an own compatible, like
compatible = "mikroe,click", "mikrobus-socket";
Or maybe click-eeprom? Although click seems to be the brand name of MikroElektronika.
-michael
[1] https://www.mikroe.com/eth-3-click [2] https://www.mikroe.com/eth-wiz-click [3] https://github.com/MikroElektronika/click_id/blob/main/manifests/ETH-WIZ-CLI...