On 04/11/2016 09:53 AM, Simon Glass wrote:
Hi,
On 11 April 2016 at 10:10, Stephen Warren swarren@wwwdotorg.org wrote:
On 04/11/2016 09:12 AM, Simon Glass wrote:
Hi Eric,
On 11 April 2016 at 09:10, Eric Nelson eric@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.
Regards,
Eric