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

[Tom Rini]

On Mon, Jun 25, 2018 at 09:58:39PM +0200, Boris Brezillon wrote:
> 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?

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20180625/58f2d972/attachment.sig>