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. > > > > Agreed, this is a limitation, unless the corresponding > drivers/subsystems use device_property_read_* helper to fetch > properties, it will not work and net/core/of_net.c only implements > of_get_* helpers even though the underlying functions can be implemented > with equivalent device_property_read_* equivalent as well. And I don't think this is a good idea given that the alternative is just working. > > 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. > > Agreed, there is nothing preventing us to convert the binding and update > the driver to follow the above proposed format and will be done in next > revision. Click is brand name of MikroElektronika and they don't allow > custom boards to use that branding, however clickid can be used in the > case where EEPROM is present/enable the socket to be probeable. Thinking about this again. I'm not sure this additional compatible really helps the discovery. It's a chicken egg problem. Only the modules knows if it has an EEPROM, but then, we already have to know it's in the socket. So while it might help for a static configuration, it does not for the discovery. -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-CLICK.mnfs _______________________________________________ greybus-dev mailing list -- greybus-dev@xxxxxxxxxxxxxxxx To unsubscribe send an email to greybus-dev-leave@xxxxxxxxxxxxxxxx