[U-Boot] [RFC PATCH 00/20] SPI-NAND support

[Boris Brezillon]

On Tue, 26 Jun 2018 00:07:10 +0530
Jagan Teki <jagan at 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?