On Thu, 13 Dec 2018 04:40:30 +0530 Jagan Teki <ja...@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. > > 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. Oh, and this strict rule that says "don't provide wrappers to handle non-DM compliant cases" is just wrong. As I said, none of these dummy wrappers prevent you from enforcing DM_SPI conversion, and it allows us to support existing HW while getting rid of the old code base. Plus, I suggested to declare the spi-nor driver as an MTD uclass so it's not like we're completely ignoring your comments :P. _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
