From mboxrd@z Thu Jan  1 00:00:00 1970
From: Marek Vasut <marex@denx.de>
Date: Fri, 21 Sep 2012 20:01:27 +0200
Subject: [U-Boot] [PATCH 03/11] DM: add block controller core
In-Reply-To: <2763673.sqrX0osG5t@bloomfield>
References: <1348169867-2917-1-git-send-email-morpheus.ibis@gmail.com>
	<201209211808.14104.marex@denx.de> <2763673.sqrX0osG5t@bloomfield>
Message-ID: <201209212001.27851.marex@denx.de>
List-Id: <u-boot.lists.denx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: u-boot@lists.denx.de

Dear Pavel Herrmann,

> On Friday 21 of September 2012 18:08:13 Marek Vasut wrote:
> > Dear Pavel Herrmann,
> > 
> > > On Friday 21 of September 2012 17:39:21 Marek Vasut wrote:
> > > > Dear Pavel Herrmann,
> > > > 
> > > > [...]
> > > > 
> > > > > > Can't the old driver just have a compat section in them? Like I
> > > > > > did with serial stuff:
> > > > > > 
> > > > > > 1) rename the internal functions to ${driver}_${function_name}
> > > > > > from pure ${function_name} and introduce section which behaves
> > > > > > as a wrapper (implement ${function_name} calling
> > > > > > ${driver}_${function_name} ). 2) Add your DM goo, implement
> > > > > > #ifdef around it so either the compat section or DM section is
> > > > > > enabled.
> > > > > 
> > > > > I actually did something of this sort, see [4/11], with less
> > > > > touching.
> > > > > 
> > > > > the problem is that while SATA drivers are easy to convert, IDE
> > > > > ones are not. I would actually propose to do a ide_legacy driver
> > > > > (mostly out of the code currently in common/cmd_ide.c), and keep
> > > > > it as the only option until IDE dies completely.
> > > > 
> > > > IDE will be around for a LONG time.
> > > > 
> > > > You introduce that CONFIG_SYS_SATA_LEGACY for no reason, if you did
> > > > it as
> > > > said above, simple CONFIG_DM would suffice as the drivers would be
> > > > intacts with DM disabled. Note the compiler will opt-out these proxy
> > > > calls.
> > > > 
> > > > Besides, with this approach of yours, you need to enable SATA_LEGACY
> > > > for every single board now, introducing a lot of churn into the
> > > > patches and if it's not defined, every board using SATA is broken,
> > > > right?
> > > 
> > > No, if you dont define CONFIG_DM, you get the old way of interacting
> > > with disks. only if you define CONFIG_DM you only need
> > > CONFIG_SATA_LEGACY to plug old SATA drivers into DM codepaths
> > 
> > So if you enable DM for a board, you also need to enable this compat
> > layer? My opinion is, that you either enable DM on the board and the
> > board is ready for it or don't enable it.
> 
> if you enable DM on a board, you can either use the compat layer and the
> old driver, or use a ported driver and get rid of the compat layer
> 
> > Would you need the compat layer at all were you to follow my advice?
> 
> if i understand what you meant, i would build this compat layer into every
> one of the drivers currently in tree (with some cleanup). in that case, i
> would not need it

That's correct. You would prepare every driver to be DM-ish and the final 
deployment of DM would be mechanical. So would be the removal of the non-DM part 
later on.

> > The whole idea goes deeper, see if you prepended this patchset with such
> > a conversion as above, you'd already have a readily defined structure of
> > blockdev operations in each driver to use in this patchset. This
> > patchset would then really only be the DM stuff. The DM-part addition to
> > the drivers would be mechanical.
> > 
> > > > > > How does that work? It's much cleaner.
> > > > > > 
> > > > > > > Pavel Herrmann
> > > > > > 
> > > > > > Best regards,
> > > > > > Marek Vasut
> > > > 
> > > > Best regards,
> > > > Marek Vasut
> > 
> > Best regards,
> > Marek Vasut

Best regards,
Marek Vasut