[U-Boot] [PATCH 19/42] Convert CONFIG_SPL_GPIO_SUPPORT to Kconfig

[Tom Rini]

On Thu, Aug 25, 2016 at 06:04:47AM -0600, Simon Glass wrote:
> Hi,
> 
> On 24 August 2016 at 13:30, Tom Rini <trini at konsulko.com> wrote:
> > On Wed, Aug 24, 2016 at 08:01:54PM +0200, Maxime Ripard wrote:
> >> Hi Simon,
> >>
> >> On Wed, Aug 24, 2016 at 10:52:03AM -0600, Simon Glass wrote:
> >> > Move this option to Kconfig and tidy up existing uses.
> >> >
> >> > Signed-off-by: Simon Glass <sjg at chromium.org>
> >> > ---
[snip]
> >> >  282 files changed, 392 insertions(+), 235 deletions(-)
> >>
> >> Wouldn't it be better to have a default y in the relevant
> >> architectures?
> >>
> >> That would reduce the duplication of all those symbols, and would be
> >> less error-prone.
> >
> > Yes.  I think the parts of this series that convert from a define to
> > Kconfig need to also in some cases either default y or be selected,
> > depending on what type they are, and we can always come back and move
> > from select to default y too if we get it wrong.  For example, GPIO
> > support is probably an "all SoC of type ... need" thing so should be
> > selected, and that's true (I bet) for sunxi and TI (non-keystone, hence
> > the way it's done today).  Other things like FAT support should be a
> > default y at least for (non-keystone) TI parts.
> 
> Yes that makes sense to me. I'd argue for a separate patch though
> since its hard enough to get things right without making manual
> changes.
> 
> We have this problem in general too. I believe there are quite a few
> options which could benefit from a little bit of karnaugh mapping. I
> wonder if we could have a tool which works out what ARCH... options
> determine what other options....

I think it may be easier for you to develop it as a second series, given
that you have the commits happening automatically as part of the
conversion.  But for review and testing, and since it would need to be
an immediate follow-up, they need to go hand-in-hand.  So, develop as a
follow up, rebase and squash for the rest of us to review?  A 30 part
series that touches 250+ files each time isn't an easy review.

Oh, and feel free to start the series out (or have it near the front) to
savedefconfig everyone as that's also part of the hard part of the
review, the boards that contain very unrelated corrections.  Thanks!

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20160825/6a020146/attachment.sig>