Hi Eric, On 11 April 2016 at 11:17, Eric Nelson <e...@nelint.com> wrote: > On 04/11/2016 09:53 AM, Simon Glass wrote: >> Hi, >> >> On 11 April 2016 at 10:10, Stephen Warren <swar...@wwwdotorg.org> wrote: >>> On 04/11/2016 09:12 AM, Simon Glass wrote: >>>> >>>> Hi Eric, >>>> >>>> On 11 April 2016 at 09:10, Eric Nelson <e...@nelint.com> wrote: >>>>> > > <snip> > >>>>>> I don't think you need __maybe_unused >>>>>> >>>>>> static int gpio_find_and_xlate(...) >>>>>> { >>>>>> get ops... >>>>>> >>>>>> if (ops->xlate) >>>>>> return ops->xlate(....) >>>>>> else >>>>>> return gpio_default_xlate()... >>>>>> } >>>>>> >>>>>> gpio_default_xlate() (or whatever name you use) should be exported so >>>>>> drivers can use it. >>>>>> >>>>> >>>>> This will leak gpio_default_xlate (locally named gpio_xlate_offs_flags) >>>>> into machines that don't need it. >>>>> >>>>> I can go the route you suggest above, but it will cost the tegra >>>>> and sandbox builds ~64 bytes ;) >>>>> >>>> >>>> Sure, but we can live with that. >>> >>> >>> You can avoid that by requiring that ops->xlate always be non-NULL, and >>> simply referencing the default function from drivers that want to use it. >>> Not a big deal either way though. >> >> I'd prefer not to do that. It just adds cruft, the removal of which is >> the purpose of Eric's series. >> > > We must be close to the goal now, since we're picking apart stuff like > this! > > Since I've done it both ways locally, I'll try to recap. > > Requiring an xlate puts a greater demand on the drivers, and requires > an extra patch to get Vybrid working (adding xlate to vybrid_gpio.c) > but does make it clearer which drivers need updates to handle DT > parsing. > > There are a lot of them: > altera_pio > at91_gpio > atmel_pio4 > axp_gpio > bcm2835_gpio > dwapb_gpio > gpio-uniphier > hi6220_gpio > intel_ich6_gpio > lpc32xx_gpio > msm_gpio > mvebu_gpio > pm8916_gpio > > None of these have dts files in either U-Boot or the kernel, so this > doesn't appear to be a problem. > > Calling gpio_xlate_offs_flags as done in the V2 I just sent adds 64 > bytes of code to the output for all machines, but transparently adds > support for machines like vybrid and mxc.
Yes that seems OK to me. Can you please send a new version of the series? Regards, Simon _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot