Hi Tom, On 25 August 2016 at 16:01, Tom Rini <tr...@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 <tr...@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 <s...@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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
