On Mon, Jun 25, 2018 at 09:58:39PM +0200, Boris Brezillon wrote: > On Tue, 26 Jun 2018 00:07:10 +0530 > Jagan Teki <ja...@amarulasolutions.com> wrote: > > > >> I think I have to repeat my previous statement here. It would be very > > >> unfortunate if u-boot decides to take this direction (see Richard's > > >> reply), especially since I see absolutely no benefit in doing what you > > >> suggest. Having MTD devices registered to the uboot DM is something I > > >> can understand, deciding to no longer support the standard MTD API is > > >> something I don't. > > > > > I agree. We want U-Boot to be able to leverage as much as possible from > > > the Linux kernel with as little re-working as possible. > > > > I'm not denying that, but the basic design flow must follow u-boot > > driver model. this is what everyone told from the beginning when I > > started spi-nor work. Initially I did the design like this and > > leverage with existing MTD, everyone NAK and suggested to use > > driver-model on each stage with MTD dm abstraction. > > So > > - After 2 years of work > > - With nearly 10 versions [4] > > - Adding MIGRATION expire date for spi drivers dm conversion > > - Simon Reviewed-by and > > - Planning to apply after v2018.09. > > > > but now all want the existing MTD, I don't understand what I can do > > further on this? > > I didn't follow the initial discussion, but I can understand your > frustration. Still, I think there's a misunderstanding here. I recommend > that you have a second look at the different patches in this series. > You'll see that everything Miquel did complies with the DM, and that > the thing you're complaining about (MTD API not using udevice and not > prefixed with dm_) is just a tiny detail compared to the rest. > > Keeping the MTD API is not incompatible with the conversion of > all MTD provider drivers to the DM. I think we all agree on that MTD > providers should be converted to the DM progressively, and the work > Miquel did allows such a smooth transition because both non-DM drivers > and DM-compliant drivers can co-exist without impacting MTD users. > > Sorry to say that, but your approach based on full-conversion is just an > utopia. There's no way we can do that in a single step. > > So the question here is more, should we block all developments until we > have a perfect solution (I don't think perfection can be achieved > without trying things and making mistake), or should we move forward, > one step after the other and keep the "conversion of all MTD > drivers to the DM" as a long term goal?
And furthermore, we _really_ need to get this area un-blocked. I feel bad that Jagan's series went on for so long, but I think it also highlights the problem with a convert-everything-at-once-try-and-be-perfect approach. -- Tom
signature.asc
Description: PGP signature
_______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
