Re: [PATCH v4 1/5] dt-bindings: misc: Add mikrobus-connector

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





On 21/03/24 15:08, Michael Walle wrote:
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.

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.

Thanks and Regards,
Vaishnav


-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



[Index of Archives]     [Asterisk App Development]     [PJ SIP]     [Gnu Gatekeeper]     [IETF Sipping]     [Info Cyrus]     [ALSA User]     [Fedora Linux Users]     [Linux SCTP]     [DCCP]     [Gimp]     [Yosemite News]     [Deep Creek Hot Springs]     [Yosemite Campsites]     [ISDN Cause Codes]     [Asterisk Books]

  Powered by Linux