Re: [PATCH 01/10] GPIO: gpio-generic: Move initialization up to postcore

Re: [PATCH 01/10] GPIO: gpio-generic: Move initialization up to postcore

[Janusz Krzysztofik]

(adding Greg Kroah-Hartman and linux-serial@vger.kernel.org to Cc:)

On Monday 12 of December 2011 at 19:04:56, Tony Lindgren wrote:
> * Janusz Krzysztofik <jkrzyszt@tis.icnet.pl> [111211 11:41]:
> > This will allow boards with custom memory mapped GPIO ports to set up
> > and use those port pins while initializing devices from arch init.
> 
> Care to explain a bit more why you need to initialize those devices
> early on?

Let me try.

>From patch 2/10 "ARM: OMAP1: ams-delta: Convert latches to 
basic_mmio_gpio":

> @@ -307,8 +487,8 @@ static void __init ams_delta_init(void)
>  	omap_serial_init();
>  	omap_register_i2c_bus(1, 100, NULL, 0);
>  
> -	/* Clear latch2 (NAND, LCD, modem enable) */
> -	ams_delta_latch2_write(~0, 0);
> +	platform_add_devices(_latch_devices, ARRAY_SIZE(_latch_devices));
> +	BUG_ON(gpio_request_array(_latch_gpios, ARRAY_SIZE(_latch_gpios)));
>  
>  	omap1_usb_init(&ams_delta_usb_config);
>  	omap1_set_camera_info(&ams_delta_camera_platform_data);

Here I'm accessing the latches from ams_delta_init() (.init_machine 
hook) with gpio_request_array() in order to:
a) clear their contents,
b) avoid accessing them, from ams_delta_latch_write(), never requested.

I could imagine clearing their contents with something like

	*(volatile __u8 *) AMS_DELTA_LATCH2_VIRT = 0;
	*(volatile __u16 *) AMS_DELTA_LATCH2_VIRT = 0;

instead, i.e., the way the old code used to, than accessing those GPIO 
pins not requested, until they are finally requested by drivers updated 
to use gpiolib with successive patche. Would this be acceptable?

However,
>From patch 6/10 "ARM: OMAP1: ams-delta: Use GPIO API in modem setup":

> @@ -482,6 +472,12 @@ static void __init ams_delta_init(void)
>  	omap_writew(omap_readw(ARM_RSTCT1) | 0x0004, ARM_RSTCT1);
>  }
>  
> +static void _modem_pm(struct uart_port *port, unsigned int state, unsigned old)
> +{
> +	if (state != old)
> +		gpio_set_value(AMS_DELTA_GPIO_PIN_MODEM_NRESET, state == 0);
> +}
> +
>  static struct plat_serial8250_port ams_delta_modem_ports[] = {
>  	{
>  		.membase	= IOMEM(_MODEM_VIRT),
> @@ -492,6 +488,7 @@ static struct plat_serial8250_port ams_delta_modem_ports[] = {
>  		.iotype		= UPIO_MEM,
>  		.regshift	= 1,
>  		.uartclk	= BASE_BAUD * 16,
> +		.pm		= _modem_pm,
>  	},
>  	{ },
>  };
> @@ -504,6 +501,24 @@ static struct platform_device ams_delta_modem_device = {
>  	},
>  };
>  
> +static struct gpio _modem_gpios[] __initconst = {
> +	{
> +		.gpio	= AMS_DELTA_GPIO_PIN_MODEM_IRQ,
> +		.flags	= GPIOF_DIR_IN,
> +		.label	= "modem_irq",
> +	},
> +	{
> +		.gpio	= AMS_DELTA_GPIO_PIN_MODEM_NRESET,
> +		.flags	= GPIOF_OUT_INIT_HIGH,
> +		.label	= "modem_nreset",
> +	},
> +	{
> +		.gpio	= AMS_DELTA_GPIO_PIN_MODEM_CODEC,
> +		.flags	= GPIOF_OUT_INIT_HIGH,
> +		.label	= "modem_codec",
> +	},
> +};
> +
>  static int __init ams_delta_modem_init(void)
>  {
>  	int err;
> @@ -515,16 +530,11 @@ static int __init ams_delta_modem_init(void)
>  	ams_delta_modem_ports[0].irq =
>  			gpio_to_irq(AMS_DELTA_GPIO_PIN_MODEM_IRQ);
>  
> -	err = gpio_request(AMS_DELTA_GPIO_PIN_MODEM_IRQ, "modem");
> +	err = gpio_request_array(_modem_gpios, ARRAY_SIZE(_modem_gpios));
>  	if (err) {
> -		pr_err("Couldn't request gpio pin for modem\n");
> +		pr_err("Couldn't request gpio pins for modem\n");
>  		return err;
>  	}
> -	gpio_direction_input(AMS_DELTA_GPIO_PIN_MODEM_IRQ);
> -
> -	ams_delta_latch2_write(
> -		AMS_DELTA_LATCH2_MODEM_NRESET | AMS_DELTA_LATCH2_MODEM_CODEC,
> -		AMS_DELTA_LATCH2_MODEM_NRESET | AMS_DELTA_LATCH2_MODEM_CODEC);
>  
>  	return platform_device_register(&ams_delta_modem_device);
>  }

Before the change, only one GPIO pin, that IRQ, driven with omap_gpio 
driver which is registered from postcore, was gpio_request()ed. Now, two 
more, gpio-generic driven pins, are also requested _and_ initialized in 
order to make the modem accessible. The ams_delta_modem_init() is 
installed with arch_initcall().

I could imagine initializing those modem pins the old way I've suggested 
above, but I can see no good solution to delegate calling of that 
gpio_request*() to the 8250 driver. For me, the only hook passed to the 
driver with platform_data that can be suitable is the .pm hook. However, 
when I tried to remove powering up the modem (rising up 
AMS_DELTA_GPIO_PIN_MODEM_NRESET) from the arch init and do this only 
from that .pm hook, the device was not detected, so I wonder if and when 
that hook is called, and if it is before probe, then perhaps powering 
up the modem chip from there is too late for the device to get up before 
being examined. But then, maybe if we initialize the pin the old way 
from arch init, it would be enough for the device to be detected, while 
consecutive open() response times may not be so critical. Perhaps Greg 
or another serial guru can shed some more light on this.

But this way or another, we are talking about dirty hacks here IMHO.

Thanks,
Janusz

Re: [PATCH 01/10] GPIO: gpio-generic: Move initialization up to postcore

[Tony Lindgren]

* Janusz Krzysztofik <jkrzyszt@tis.icnet.pl> [111212 14:36]:
> (adding Greg Kroah-Hartman and linux-serial@vger.kernel.org to Cc:)
> 
> On Monday 12 of December 2011 at 19:04:56, Tony Lindgren wrote:
> > * Janusz Krzysztofik <jkrzyszt@tis.icnet.pl> [111211 11:41]:
> > > This will allow boards with custom memory mapped GPIO ports to set up
> > > and use those port pins while initializing devices from arch init.
> > 
> > Care to explain a bit more why you need to initialize those devices
> > early on?
> 
> Let me try.
> 
> From patch 2/10 "ARM: OMAP1: ams-delta: Convert latches to 
> basic_mmio_gpio":
> 
> > @@ -307,8 +487,8 @@ static void __init ams_delta_init(void)
> >  	omap_serial_init();
> >  	omap_register_i2c_bus(1, 100, NULL, 0);
> >  
> > -	/* Clear latch2 (NAND, LCD, modem enable) */
> > -	ams_delta_latch2_write(~0, 0);
> > +	platform_add_devices(_latch_devices, ARRAY_SIZE(_latch_devices));
> > +	BUG_ON(gpio_request_array(_latch_gpios, ARRAY_SIZE(_latch_gpios)));
> >  
> >  	omap1_usb_init(&ams_delta_usb_config);
> >  	omap1_set_camera_info(&ams_delta_camera_platform_data);
> 
> Here I'm accessing the latches from ams_delta_init() (.init_machine 
> hook) with gpio_request_array() in order to:
> a) clear their contents,
> b) avoid accessing them, from ams_delta_latch_write(), never requested.
> 
> I could imagine clearing their contents with something like
> 
> 	*(volatile __u8 *) AMS_DELTA_LATCH2_VIRT = 0;
> 	*(volatile __u16 *) AMS_DELTA_LATCH2_VIRT = 0;
> 
> instead, i.e., the way the old code used to, than accessing those GPIO 
> pins not requested, until they are finally requested by drivers updated 
> to use gpiolib with successive patche. Would this be acceptable?

Thanks for explaining, it's best to use gpio calls instead :)

How about just add some __initcall into your board-*.c file to
do the required setups a bit later? Just make sure you exit
early if (!machine_is...) fails.

> However,
> From patch 6/10 "ARM: OMAP1: ams-delta: Use GPIO API in modem setup":
> 
> > @@ -482,6 +472,12 @@ static void __init ams_delta_init(void)
> >  	omap_writew(omap_readw(ARM_RSTCT1) | 0x0004, ARM_RSTCT1);
> >  }
> >  
> > +static void _modem_pm(struct uart_port *port, unsigned int state, unsigned old)
> > +{
> > +	if (state != old)
> > +		gpio_set_value(AMS_DELTA_GPIO_PIN_MODEM_NRESET, state == 0);
> > +}
> > +
> >  static struct plat_serial8250_port ams_delta_modem_ports[] = {
> >  	{
> >  		.membase	= IOMEM(_MODEM_VIRT),
> > @@ -492,6 +488,7 @@ static struct plat_serial8250_port ams_delta_modem_ports[] = {
> >  		.iotype		= UPIO_MEM,
> >  		.regshift	= 1,
> >  		.uartclk	= BASE_BAUD * 16,
> > +		.pm		= _modem_pm,
> >  	},
> >  	{ },
> >  };
> > @@ -504,6 +501,24 @@ static struct platform_device ams_delta_modem_device = {
> >  	},
> >  };
> >  
> > +static struct gpio _modem_gpios[] __initconst = {
> > +	{
> > +		.gpio	= AMS_DELTA_GPIO_PIN_MODEM_IRQ,
> > +		.flags	= GPIOF_DIR_IN,
> > +		.label	= "modem_irq",
> > +	},
> > +	{
> > +		.gpio	= AMS_DELTA_GPIO_PIN_MODEM_NRESET,
> > +		.flags	= GPIOF_OUT_INIT_HIGH,
> > +		.label	= "modem_nreset",
> > +	},
> > +	{
> > +		.gpio	= AMS_DELTA_GPIO_PIN_MODEM_CODEC,
> > +		.flags	= GPIOF_OUT_INIT_HIGH,
> > +		.label	= "modem_codec",
> > +	},
> > +};
> > +
> >  static int __init ams_delta_modem_init(void)
> >  {
> >  	int err;
> > @@ -515,16 +530,11 @@ static int __init ams_delta_modem_init(void)
> >  	ams_delta_modem_ports[0].irq =
> >  			gpio_to_irq(AMS_DELTA_GPIO_PIN_MODEM_IRQ);
> >  
> > -	err = gpio_request(AMS_DELTA_GPIO_PIN_MODEM_IRQ, "modem");
> > +	err = gpio_request_array(_modem_gpios, ARRAY_SIZE(_modem_gpios));
> >  	if (err) {
> > -		pr_err("Couldn't request gpio pin for modem\n");
> > +		pr_err("Couldn't request gpio pins for modem\n");
> >  		return err;
> >  	}
> > -	gpio_direction_input(AMS_DELTA_GPIO_PIN_MODEM_IRQ);
> > -
> > -	ams_delta_latch2_write(
> > -		AMS_DELTA_LATCH2_MODEM_NRESET | AMS_DELTA_LATCH2_MODEM_CODEC,
> > -		AMS_DELTA_LATCH2_MODEM_NRESET | AMS_DELTA_LATCH2_MODEM_CODEC);
> >  
> >  	return platform_device_register(&ams_delta_modem_device);
> >  }
> 
> Before the change, only one GPIO pin, that IRQ, driven with omap_gpio 
> driver which is registered from postcore, was gpio_request()ed. Now, two 
> more, gpio-generic driven pins, are also requested _and_ initialized in 
> order to make the modem accessible. The ams_delta_modem_init() is 
> installed with arch_initcall().
> 
> I could imagine initializing those modem pins the old way I've suggested 
> above, but I can see no good solution to delegate calling of that 
> gpio_request*() to the 8250 driver. For me, the only hook passed to the 
> driver with platform_data that can be suitable is the .pm hook. However, 
> when I tried to remove powering up the modem (rising up 
> AMS_DELTA_GPIO_PIN_MODEM_NRESET) from the arch init and do this only 
> from that .pm hook, the device was not detected, so I wonder if and when 
> that hook is called, and if it is before probe, then perhaps powering 
> up the modem chip from there is too late for the device to get up before 
> being examined. But then, maybe if we initialize the pin the old way 
> from arch init, it would be enough for the device to be detected, while 
> consecutive open() response times may not be so critical. Perhaps Greg 
> or another serial guru can shed some more light on this.
> 
> But this way or another, we are talking about dirty hacks here IMHO.

Might be worth checking if some board specific __initcall helps here
too?

Regards,

Tony

Re: [PATCH 01/10] GPIO: gpio-generic: Move initialization up to postcore

[Janusz Krzysztofik]

On Tuesday 13 of December 2011 at 00:15:20, Tony Lindgren wrote:
> 
> Might be worth checking if some board specific __initcall helps here
> too?

If I only knew how I could insert a board specific __initcall between 
two points from where the generic-gpio first, then the 8250 driver, are 
called.

Any hints?

Thanks,
Janusz

Re: [PATCH 01/10] GPIO: gpio-generic: Move initialization up to postcore

[Tony Lindgren]

* Janusz Krzysztofik <jkrzyszt@tis.icnet.pl> [111212 15:13]:
> On Tuesday 13 of December 2011 at 00:15:20, Tony Lindgren wrote:
> > 
> > Might be worth checking if some board specific __initcall helps here
> > too?
> 
> If I only knew how I could insert a board specific __initcall between 
> two points from where the generic-gpio first, then the 8250 driver, are 
> called.
> 
> Any hints?

Hmm, can't you do all that in the order you want in
ams_delta_modem_init()?  Or make that into a late_initcall so
you have generic-gpio available?

It seems that the pieces of code you're talking about don't need
to be initialized early, just needs to be done in the right
order to get things working.

Regards,

Tony

Re: [PATCH 01/10] GPIO: gpio-generic: Move initialization up to postcore

[Janusz Krzysztofik]

On Tuesday 13 of December 2011 at 00:55:44, Tony Lindgren wrote:
> * Janusz Krzysztofik <jkrzyszt@tis.icnet.pl> [111212 15:13]:
> > On Tuesday 13 of December 2011 at 00:15:20, Tony Lindgren wrote:
> > > 
> > > Might be worth checking if some board specific __initcall helps here
> > > too?
> > 
> > If I only knew how I could insert a board specific __initcall between 
> > two points from where the generic-gpio first, then the 8250 driver, are 
> > called.
> > 
> > Any hints?
> 
> Hmm, can't you do all that in the order you want in
> ams_delta_modem_init()?  Or make that into a late_initcall so
> you have generic-gpio available?
> 
> It seems that the pieces of code you're talking about don't need
> to be initialized early, just needs to be done in the right
> order to get things working.

I think I've got it, thanks!
Janusz

Re: [PATCH 01/10] GPIO: gpio-generic: Move initialization up to postcore

[Janusz Krzysztofik]

On Tuesday 13 of December 2011 at 00:55:44, Tony Lindgren wrote:
> * Janusz Krzysztofik <jkrzyszt@tis.icnet.pl> [111212 15:13]:
> > On Tuesday 13 of December 2011 at 00:15:20, Tony Lindgren wrote:
> > > 
> > > Might be worth checking if some board specific __initcall helps here
> > > too?
> > 
> > If I only knew how I could insert a board specific __initcall between 
> > two points from where the generic-gpio first, then the 8250 driver, are 
> > called.
> > 
> > Any hints?
> 
> Hmm, can't you do all that in the order you want in
> ams_delta_modem_init()?  Or make that into a late_initcall so
> you have generic-gpio available?
> 
> It seems that the pieces of code you're talking about don't need
> to be initialized early, just needs to be done in the right
> order to get things working.

Hi,
I'm almost done with moving registration of all latch dependent devices 
down to a late_initcall hook, however while working on this, I've found 
still another arrangement, yet better in my opinion:
1) generic-gpio driver registration moved from device_initcall up to 
   subsys_initcall,
2) latch dependent device registration left at arch_initcall, as it is 
   now,
3) a temporary hack, removed with the last patch in the series, that 
   requests GPIO pins on behalf of device drivers before those are 
   updated, placed between subsys_initcall and device_initcall, i.e., at 
   fs_initcall or rootfs_initcall; both look ugly, but this is only for 
   a while, in order to keep things working while in the transition,
4) the modem init hook, once updated with extra GPIO setup that must be 
   done on behalf of the 8250 driver, which is not prepared for 
   accepting any extra init hooks passed with the device platform data, 
   moved down to late_initcall, as suggested,
5) once all drivers are updated, the hack is removed, and an 
   initialization of unused pins added to that late_initcall modem hook, 
   perhaps renamed in order to not suggest it is still modem only 
   related.

What do you think?

Thanks,
Janusz

Re: [PATCH 01/10] GPIO: gpio-generic: Move initialization up to postcore

[Tony Lindgren]

* Janusz Krzysztofik <jkrzyszt@tis.icnet.pl> [111214 04:40]:
> On Tuesday 13 of December 2011 at 00:55:44, Tony Lindgren wrote:
> > * Janusz Krzysztofik <jkrzyszt@tis.icnet.pl> [111212 15:13]:
> > > On Tuesday 13 of December 2011 at 00:15:20, Tony Lindgren wrote:
> > > > 
> > > > Might be worth checking if some board specific __initcall helps here
> > > > too?
> > > 
> > > If I only knew how I could insert a board specific __initcall between 
> > > two points from where the generic-gpio first, then the 8250 driver, are 
> > > called.
> > > 
> > > Any hints?
> > 
> > Hmm, can't you do all that in the order you want in
> > ams_delta_modem_init()?  Or make that into a late_initcall so
> > you have generic-gpio available?
> > 
> > It seems that the pieces of code you're talking about don't need
> > to be initialized early, just needs to be done in the right
> > order to get things working.
> 
> Hi,
> I'm almost done with moving registration of all latch dependent devices 
> down to a late_initcall hook, however while working on this, I've found 
> still another arrangement, yet better in my opinion:
> 1) generic-gpio driver registration moved from device_initcall up to 
>    subsys_initcall,
> 2) latch dependent device registration left at arch_initcall, as it is 
>    now,
> 3) a temporary hack, removed with the last patch in the series, that 
>    requests GPIO pins on behalf of device drivers before those are 
>    updated, placed between subsys_initcall and device_initcall, i.e., at 
>    fs_initcall or rootfs_initcall; both look ugly, but this is only for 
>    a while, in order to keep things working while in the transition,
> 4) the modem init hook, once updated with extra GPIO setup that must be 
>    done on behalf of the 8250 driver, which is not prepared for 
>    accepting any extra init hooks passed with the device platform data, 
>    moved down to late_initcall, as suggested,
> 5) once all drivers are updated, the hack is removed, and an 
>    initialization of unused pins added to that late_initcall modem hook, 
>    perhaps renamed in order to not suggest it is still modem only 
>    related.
> 
> What do you think?

Sounds better for sure than what we currently have :)

Tony

Re: [PATCH 01/10] GPIO: gpio-generic: Move initialization up to postcore

[Janusz Krzysztofik]

(adding Mark Brown and Liam Girdwood - regulator experts - to Cc:)

On Wednesday 14 of December 2011 at 19:21:49, Tony Lindgren wrote:
> * Janusz Krzysztofik <jkrzyszt@tis.icnet.pl> [111214 04:40]:
> > On Tuesday 13 of December 2011 at 00:55:44, Tony Lindgren wrote:
> > > * Janusz Krzysztofik <jkrzyszt@tis.icnet.pl> [111212 15:13]:
> > > > On Tuesday 13 of December 2011 at 00:15:20, Tony Lindgren wrote:
> > > > > 
> > > > > Might be worth checking if some board specific __initcall helps here
> > > > > too?
> > > > 
> > > > If I only knew how I could insert a board specific __initcall between 
> > > > two points from where the generic-gpio first, then the 8250 driver, are 
> > > > called.
> > > > 
> > > > Any hints?
> > > 
> > > Hmm, can't you do all that in the order you want in
> > > ams_delta_modem_init()?  Or make that into a late_initcall so
> > > you have generic-gpio available?
> > > 
> > > It seems that the pieces of code you're talking about don't need
> > > to be initialized early, just needs to be done in the right
> > > order to get things working.
> > 
> > Hi,
> > I'm almost done with moving registration of all latch dependent devices 
> > down to a late_initcall hook, however while working on this, I've found 
> > still another arrangement, yet better in my opinion:
> > 1) generic-gpio driver registration moved from device_initcall up to 
> >    subsys_initcall,
> > 2) latch dependent device registration left at arch_initcall, as it is 
> >    now,
> > 3) a temporary hack, removed with the last patch in the series, that 
> >    requests GPIO pins on behalf of device drivers before those are 
> >    updated, placed between subsys_initcall and device_initcall, i.e., at 
> >    fs_initcall or rootfs_initcall; both look ugly, but this is only for 
> >    a while, in order to keep things working while in the transition,
> > 4) the modem init hook, once updated with extra GPIO setup that must be 
> >    done on behalf of the 8250 driver, which is not prepared for 
> >    accepting any extra init hooks passed with the device platform data, 
> >    moved down to late_initcall, as suggested,
> > 5) once all drivers are updated, the hack is removed, and an 
> >    initialization of unused pins added to that late_initcall modem hook, 
> >    perhaps renamed in order to not suggest it is still modem only 
> >    related.
> > 
> > What do you think?
> 
> Sounds better for sure than what we currently have :)

Hmm, better doesn't necessarily mean good enough...

I forgot about the sound device, which shares its latch based GPIO pins 
with the modem, so should be registered after the modem.

To make things still more complicated, one of those GPIO pins provides 
power to both devices, so a still better solution I'd like to introduce 
would be a GPIO controlled regulator device which feeds both the modem 
and the sound card with power.

I've had a look at both generic regulator drivers, fixed.c and gpio-
regulator.c, both controlling devices over GPIO pins, and found those 
drivers registered at subsys_initcall level, calling gpio_request*() at 
probe time. Then again, we would need that base_mmio_gpio driver already 
registered before subsys_initcall.

Any suggestions?

Thanks,
Janusz

Re: [PATCH 01/10] GPIO: gpio-generic: Move initialization up to postcore

[Tony Lindgren]

* Janusz Krzysztofik <jkrzyszt@tis.icnet.pl> [111214 11:36]:
> (adding Mark Brown and Liam Girdwood - regulator experts - to Cc:)
> 
> On Wednesday 14 of December 2011 at 19:21:49, Tony Lindgren wrote:
> > * Janusz Krzysztofik <jkrzyszt@tis.icnet.pl> [111214 04:40]:
> > > On Tuesday 13 of December 2011 at 00:55:44, Tony Lindgren wrote:
> > > > * Janusz Krzysztofik <jkrzyszt@tis.icnet.pl> [111212 15:13]:
> > > > > On Tuesday 13 of December 2011 at 00:15:20, Tony Lindgren wrote:
> > > > > > 
> > > > > > Might be worth checking if some board specific __initcall helps here
> > > > > > too?
> > > > > 
> > > > > If I only knew how I could insert a board specific __initcall between 
> > > > > two points from where the generic-gpio first, then the 8250 driver, are 
> > > > > called.
> > > > > 
> > > > > Any hints?
> > > > 
> > > > Hmm, can't you do all that in the order you want in
> > > > ams_delta_modem_init()?  Or make that into a late_initcall so
> > > > you have generic-gpio available?
> > > > 
> > > > It seems that the pieces of code you're talking about don't need
> > > > to be initialized early, just needs to be done in the right
> > > > order to get things working.
> > > 
> > > Hi,
> > > I'm almost done with moving registration of all latch dependent devices 
> > > down to a late_initcall hook, however while working on this, I've found 
> > > still another arrangement, yet better in my opinion:
> > > 1) generic-gpio driver registration moved from device_initcall up to 
> > >    subsys_initcall,
> > > 2) latch dependent device registration left at arch_initcall, as it is 
> > >    now,
> > > 3) a temporary hack, removed with the last patch in the series, that 
> > >    requests GPIO pins on behalf of device drivers before those are 
> > >    updated, placed between subsys_initcall and device_initcall, i.e., at 
> > >    fs_initcall or rootfs_initcall; both look ugly, but this is only for 
> > >    a while, in order to keep things working while in the transition,
> > > 4) the modem init hook, once updated with extra GPIO setup that must be 
> > >    done on behalf of the 8250 driver, which is not prepared for 
> > >    accepting any extra init hooks passed with the device platform data, 
> > >    moved down to late_initcall, as suggested,
> > > 5) once all drivers are updated, the hack is removed, and an 
> > >    initialization of unused pins added to that late_initcall modem hook, 
> > >    perhaps renamed in order to not suggest it is still modem only 
> > >    related.
> > > 
> > > What do you think?
> > 
> > Sounds better for sure than what we currently have :)
> 
> Hmm, better doesn't necessarily mean good enough...
> 
> I forgot about the sound device, which shares its latch based GPIO pins 
> with the modem, so should be registered after the modem.
> 
> To make things still more complicated, one of those GPIO pins provides 
> power to both devices, so a still better solution I'd like to introduce 
> would be a GPIO controlled regulator device which feeds both the modem 
> and the sound card with power.
> 
> I've had a look at both generic regulator drivers, fixed.c and gpio-
> regulator.c, both controlling devices over GPIO pins, and found those 
> drivers registered at subsys_initcall level, calling gpio_request*() at 
> probe time. Then again, we would need that base_mmio_gpio driver already 
> registered before subsys_initcall.
> 
> Any suggestions?

Sounds like yet another case for the deferred probe patches posted
few weeks ago?

Regards,

Tony