On Tue, Mar 17, 2020 at 07:43:11PM +0100, Marek Vasut wrote:
On 3/17/20 7:42 PM, Tom Rini wrote:
On Tue, Mar 17, 2020 at 07:39:49PM +0100, Marek Vasut wrote:
On 3/17/20 7:30 PM, Tom Rini wrote:
On Tue, Mar 17, 2020 at 07:23:07PM +0100, Marek Vasut wrote:
On 3/17/20 7:10 PM, Masahiro Yamada wrote:
On Sun, Mar 15, 2020 at 8:19 AM Marek Vasut marek.vasut@gmail.com wrote: > > Drop the example, for two reasons. First, it is tapping directly into > the IO accessors of the SMC911x, while it should instead go through > the net device API. Second, this makes conversion of the SMC911x driver > to DM real hard. > > Signed-off-by: Marek Vasut marek.vasut+renesas@gmail.com > Cc: Joe Hershberger joe.hershberger@ni.com > Cc: Tom Rini trini@konsulko.com > --- > examples/standalone/Makefile | 1 - > examples/standalone/smc911x_eeprom.c | 379 --------------------------- > 2 files changed, 380 deletions(-) > delete mode 100644 examples/standalone/smc911x_eeprom.c
Yeah, I was disturbed by this example code.
I agree we should drop it.
Reviewed-by: Masahiro Yamada yamada.masahiro@socionext.com
Well I dunno. Can this be rewritten on top of DM somehow ? Do we even have U-Boot application API to access DM EEPROM ?
We should just drop it I think. The biggest surface we have today for external application is EFI application now, not U-Boot specific API. We can't drop the API but we don't expand it without very good reason.
But this drops the ability to access the SMC911x EEPROM too. So maybe we need some DM EEPROM implementation in the SMC911x driver ? Does anyone have SMC911x with an external EEPROM ?
All this does is drop an example. I don't see anything removing API code itself.
Where did I say anything about API code ?
Nowhere, which is my point. You're just dropping an example, not the ability to do $X.