Hi Lukasz, On 21 June 2017 at 01:33, Lukasz Majewski <lu...@denx.de> wrote: > Hi Vignesh, > >> Hi Lukasz, >> >> On Thursday 15 June 2017 10:28 PM, Marek Vasut wrote: >> > On 06/14/2017 02:24 PM, Vignesh R wrote: >> >> >> >> >> >> On Tuesday 13 June 2017 07:36 PM, Marek Vasut wrote: >> >>> On 06/13/2017 02:10 PM, Vignesh R wrote: >> >>>> Provide a way to read MAC address for usb_ether device from board >> >>>> function. Board files can override board_set_usbnet_devaddr() to >> >>>> populate MAC address to be used by usb_ether as device address. >> >>>> >> >>>> Signed-off-by: Vignesh R <vigne...@ti.com> >> >>> >> >>> This patch is totally unrelated to this series. >> >> >> >> This series converts dwc3 peripheral to device model and the best >> >> way to test this on TI platform to use it on ether gadget and test >> >> RNDIS boot. Hence, I had to do patches 8 to 13. Therefore I posted >> >> them together for completeness, if somebody wanted to test this >> >> out. >> > >> > Testing is great, but this is probably a fix and it's unrelated to >> > the series anyway. >> > >> >>> Moreover, just set eth*addr using setenv() to achieve the same >> >>> iirc . >> >>> >> >> >> >> eth*addr is used for regular ethernet interface and usually set by >> >> regular ethernet driver, but I could not find a way to set MAC >> >> address for usb ethernet interface >> >> Board file will now override board_set_usbnet_devaddr() to read >> >> MAC and then call setenv() >> > >> > Lukasz should be able to jump in and help. >> > >> >> Any preference on how to handle this? >> Basically, I need a way to pass MAC address to usb_ether driver. MAC >> address is available in specific efuse registers. > > It seems to me like we need to read some board specific code anyway > (because the efused data can be placed at different addresses for > different SoC - e.g. am4xx or dra7).
If it is just a different address then that could be described in the device tree. > > The __weak function could check if e.g. "ethusbaddr" is set and read eth > addr (if one would like to override it from envs). > > And as far as I remember TI even for "ordinary" ETH driver reads data > (MAC addr) in board file, so there should be no problem for also > reading ETH data from there. Rather than a weak function could we provide a misc 'driver' which other drivers can call when they need information? We could use an ioctl-like interface perhaps, if it is not worth adding a new uclass methods for this. Or perhaps we could have a UCLASS_BOARD with methods like get_mac_addr(). The the board could provide a driver. We should not be needing weak functions with driver model - it tends to create a sloppy API IMO and makes it hard to know what code is called. > >> Previously, this was >> handled by board_eth_init(), this is no longer available when using DM >> based ethernet driver. >> >> > > > > > Best regards, > > Lukasz Majewski > > -- > > DENX Software Engineering GmbH, Managing Director: Wolfgang Denk > HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany > Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Regards, Simon _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
