On Tue, Nov 29, 2016 at 3:40 PM, Simon Glass sjg@chromium.org wrote:
Hi Joe,
On 29 November 2016 at 14:24, Joe Hershberger joe.hershberger@gmail.com wrote:
Hi Simon,
On Thu, Nov 17, 2016 at 7:13 PM, Simon Glass sjg@chromium.org wrote:
Hi Oliver,
On 8 November 2016 at 08:54, Olliver Schinagl oliver@schinagl.nl wrote:
Add the read_rom_hwaddr net_op hook so that it can be called from boards to read the mac from a ROM chip.
Signed-off-by: Olliver Schinagl oliver@schinagl.nl
drivers/net/designware.c | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+)
diff --git a/drivers/net/designware.c b/drivers/net/designware.c index 9e6d726..aa87f30 100644 --- a/drivers/net/designware.c +++ b/drivers/net/designware.c @@ -230,6 +230,23 @@ static int _dw_write_hwaddr(struct dw_eth_dev *priv, u8 *mac_id) return 0; }
+__weak int dw_board_read_rom_hwaddr(unsigned char *enetaddr) +{
return -ENOSYS;+}
Instead of a weak function I think this should use driver model, with a driver supplied by the board to read this value. It should be possible to supply the 'hardware-address reading' device to any Ethernet driver, not just dwmmc.
How do we reconcile something like that with the concern of using the device tree for boards using only Linux bindings, and sharing the device tree with Linux? Linux probably doesn't care about this and so won't have a binding for defining this relationship. This is a fairly generic question. Where have we landed on this?
So far I have not seen something that cannot be solved either as I suggest above or with platform data.
Often you can pass platform data to the driver - e.g. see the end of board_init() in gurnard.c which tells the video driver which LCD to use.
Is there another case? I certainly have ideas but don't want to create something without a solid case.
I hadn't understood what pattern you were referring to when you said "with a driver supplied by the board to read this value." I just reviewed the rockchip series that you referred to and I think that pattern works pretty cleanly.
Thanks, -Joe