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

[Simon Glass]

Hi Tom,

On 25 August 2016 at 16:01, Tom Rini <trini at konsulko.com> wrote:
> 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.

So do you mean squash all 30 patches into one, or just the GPIO updates?

I'm also going to see if I can use buildman -K to make sure there are
no effective config changes.

>
> 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!

Yes, that seems to be needed a lot these days :-)

Regards,
Simon