> > 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. I think this is a good example of the limitations. For an Ethernet NIC, you often want to describe properties of both the MAC and the PHY. What phy-mode should be used, what delays on the RGMII bus, what LEDs are there etc. This is a pretty much solved problem with DT, we have a well defined sub tree to represent the MAC, the MDIO bus and the PHY on the bus. But we do have two classes of properties here. The MAC address is unique to a board. So that does need to be stored in the EEPROM, and cannot be in a one time converted manifest to DT file stored in /lib/firmware. However, to some extent, this is a solved problem. We have a DT representation of how to look in an EEPROM to find the MAC address. So the DT just needs to point to some bytes in the manifest in the EEPROM. Andrew _______________________________________________ greybus-dev mailing list -- greybus-dev@xxxxxxxxxxxxxxxx To unsubscribe send an email to greybus-dev-leave@xxxxxxxxxxxxxxxx
|