Hi,
On Fri, 14 Dec 2018 at 03:00, Jagan Teki jagan@amarulasolutions.com wrote:
On Thu, Dec 13, 2018 at 5:25 AM Boris Brezillon boris.brezillon@bootlin.com wrote:
On Thu, 13 Dec 2018 04:40:30 +0530 Jagan Teki jagan@amarulasolutions.com wrote:
I do really understand your intention about the real question.
- Any code or generic code will add in U-Boot should be driver-model
driven, are you agree this point? Yes- thanks. No - we need to have separate discussion.
Depends on what you mean by driver-model driven. Yes, applying the DM sometimes makes sense, but blindly trying to push it everywhere just for the sake of being "DM compliant" is a huge mistake IMO. One example of the thing you suggested which didn't make sense at all: force MTD users to manipulate udevice objects instead of mtd_info ones.
(+ Simon) ie How we proceed when DM is introduced in U-Boot. May be you can ask Simon or Other DM fellow developers if my statement doesn't make sense to you. ie whole reason of spi-nor changes last for year.
I generally prefer to use DM fully. I am not sure what an mtd_info is if it isn't a device.
Any code that related to spi, or spi-flash should be driver-model driven, ie what my AIM as a Maintainer (ie only reason for my spi-nor changes resist for long time to fit).
You seem to use the term "driver-model" a lot without clearly explaining what you have in mind. The driver-model should be used where it makes sense, but some of your suggestions don't make any sense to me. Like the proposal to add a SPI NOR uclass while we already have an MTD uclass which works just fine for all kind of flash devices.
You better read the thread carefully. read what I'm saying on the thread[1]
" So, if no driver should be part of spi-nor and all can be handle spi-mem even-though they have controller specific features, yes we can skip SPI_NOR_UCLASS otherwise we need spi-nor uclass that can be child uclass of MTD"
Did it state insisting SPI-NOR uclass, I was clearly giving if condition here.
Regards, Simon