On Mon, Aug 03, 2020 at 11:12:59PM +0200, Sascha Hauer wrote: > On Thu, Jul 23, 2020 at 12:33:26PM +0200, Oleksij Rempel wrote: > > Add serial node provider > > > > Signed-off-by: Oleksij Rempel > > --- > > arch/arm/dts/imx6q-prti6q.dts | 5 +++++ > > 1 file changed, 5 insertions(+) > > > > diff --git a/arch/arm/dts/imx6q-prti6q.dts b/arch/arm/dts/imx6q-prti6q.dts > > index 76bb4d53d3..67e7f63979 100644 > > --- a/arch/arm/dts/imx6q-prti6q.dts > > +++ b/arch/arm/dts/imx6q-prti6q.dts > > @@ -18,6 +18,11 @@ > > compatible = "barebox,environment"; > > device-path = &ecspi1, "partname:env"; > > }; > > + serial { > > + compatible = "barebox,serial"; > > + nvmem-cell-names = "serial-number"; > > + /* nvmem-cells will added board code */ > > You probably mean "nvmem-cells will be added by board code". > > You need board code to fully describe the device which triggers a > freshly written driver which puts the found serial number as > /serial-number into dt. Is this really worth it? I'd just read the > serial number in board code and put it into dt, maybe add some helper > function to set the right property from a given string. If eeprom should only be used to read serial-number - yes. But this RFID-eeprom provides more space and functionality. Why not make it available for barebox and linux to be able to do more things with it? > BTW you seem to be lucky that the i2c eeprom driver probes before the > barebox,serial driver, otherwise I think this doesn't work. We would have the same issue with the board code. It seems to work just for this particular barebox version and i2c controller was accidentally probed before board code. I think it is time to talk about deferred probe patches made by Lucas ;) Regards, Oleksij -- Pengutronix e.K. | | Steuerwalder Str. 21 | http://www.pengutronix.de/ | 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |