[PATCH] gpio: gpio-rcar: init at postcore level

[PATCH] gpio: gpio-rcar: init at postcore level

[vladimir.barinov]

From: Vladimir Barinov <vladimir.barinov@cogentembedded.com>

This adds ability to use gpio API at board init_machine level.

F.e. it can be used in the following situation.
Many reference hardware has onboard switches that selects which periferals
to connect to the system. The gpio input state from switches can be used
in choosing platform devices runtime in board code instead of ifdefs/defconfig
changes.

Signed-off-by: <vladimir.barinov@cogentembedded.com>

---
 drivers/gpio/gpio-rcar.c |   12 +++++++++++-
 1 file changed, 11 insertions(+), 1 deletion(-)

Index: build/drivers/gpio/gpio-rcar.c
===================================================================
--- build.orig/drivers/gpio/gpio-rcar.c	2014-02-22 23:21:51.456229152 +0400
+++ build/drivers/gpio/gpio-rcar.c	2014-02-22 23:21:52.320229133 +0400
@@ -485,7 +485,17 @@
 	}
 };
 
-module_platform_driver(gpio_rcar_device_driver);
+static int __init gpio_rcar_init(void)
+{
+	return platform_driver_register(&gpio_rcar_device_driver);
+}
+postcore_initcall(gpio_rcar_init);
+
+static void __exit gpio_rcar_exit(void)
+{
+	platform_driver_unregister(&gpio_rcar_device_driver);
+}
+module_exit(gpio_rcar_exit);
 
 MODULE_AUTHOR("Magnus Damm");
 MODULE_DESCRIPTION("Renesas R-Car GPIO Driver");

[PATCH] gpio: gpio-rcar: init at postcore level

[vladimir.barinov]

From: Vladimir Barinov <vladimir.barinov@cogentembedded.com>

This adds ability to use gpio API at board init_machine level.

F.e. it can be used in the following situation.
Many reference hardware has onboard switches that selects which periferals
to connect to the system. The gpio input state from switches can be used
in choosing platform devices runtime in board code instead of ifdefs/defconfig
changes.

Signed-off-by: <vladimir.barinov@cogentembedded.com>

---
 drivers/gpio/gpio-rcar.c |   12 +++++++++++-
 1 file changed, 11 insertions(+), 1 deletion(-)

Index: build/drivers/gpio/gpio-rcar.c
===================================================================
--- build.orig/drivers/gpio/gpio-rcar.c	2014-02-22 23:21:51.456229152 +0400
+++ build/drivers/gpio/gpio-rcar.c	2014-02-22 23:21:52.320229133 +0400
@@ -485,7 +485,17 @@
 	}
 };
 
-module_platform_driver(gpio_rcar_device_driver);
+static int __init gpio_rcar_init(void)
+{
+	return platform_driver_register(&gpio_rcar_device_driver);
+}
+postcore_initcall(gpio_rcar_init);
+
+static void __exit gpio_rcar_exit(void)
+{
+	platform_driver_unregister(&gpio_rcar_device_driver);
+}
+module_exit(gpio_rcar_exit);
 
 MODULE_AUTHOR("Magnus Damm");
 MODULE_DESCRIPTION("Renesas R-Car GPIO Driver");

[PATCH] gpio: gpio-rcar: init at postcore level

[vladimir.barinov]

From: Vladimir Barinov <vladimir.barinov@cogentembedded.com>

This adds ability to use gpio API at board init_machine level.

F.e. it can be used in the following situation.
Many reference hardware has onboard switches that selects which periferals
to connect to the system. The gpio input state from switches can be used
in choosing platform devices runtime in board code instead of ifdefs/defconfig
changes.

Signed-off-by: <vladimir.barinov@cogentembedded.com>

---
 drivers/gpio/gpio-rcar.c |   12 +++++++++++-
 1 file changed, 11 insertions(+), 1 deletion(-)

Index: build/drivers/gpio/gpio-rcar.c
=================================--- build.orig/drivers/gpio/gpio-rcar.c	2014-02-22 23:21:51.456229152 +0400
+++ build/drivers/gpio/gpio-rcar.c	2014-02-22 23:21:52.320229133 +0400
@@ -485,7 +485,17 @@
 	}
 };
 
-module_platform_driver(gpio_rcar_device_driver);
+static int __init gpio_rcar_init(void)
+{
+	return platform_driver_register(&gpio_rcar_device_driver);
+}
+postcore_initcall(gpio_rcar_init);
+
+static void __exit gpio_rcar_exit(void)
+{
+	platform_driver_unregister(&gpio_rcar_device_driver);
+}
+module_exit(gpio_rcar_exit);
 
 MODULE_AUTHOR("Magnus Damm");
 MODULE_DESCRIPTION("Renesas R-Car GPIO Driver");

Re: [PATCH] gpio: gpio-rcar: init at postcore level

[Ben Dooks]

On 23/02/14 16:37, vladimir.barinov@cogentembedded.com wrote:
> From: Vladimir Barinov <vladimir.barinov@cogentembedded.com>
>
> This adds ability to use gpio API at board init_machine level.
>
> F.e. it can be used in the following situation.
> Many reference hardware has onboard switches that selects which periferals
> to connect to the system. The gpio input state from switches can be used
> in choosing platform devices runtime in board code instead of ifdefs/defconfig
> changes.

Firstly, anyone still using platform_devices to describe their
system needs to be stopped. We cannot go on supporting this when
our primary boot method is supposed to be device-tree. If we keep
doing this then we will not get any of the current issues fixed.

Will it impact the devicetree bindings on rcar?


-- 
Ben Dooks				http://www.codethink.co.uk/
Senior Engineer				Codethink - Providing Genius

Re: [PATCH] gpio: gpio-rcar: init at postcore level

[Ben Dooks]

On 23/02/14 16:37, vladimir.barinov@cogentembedded.com wrote:
> From: Vladimir Barinov <vladimir.barinov@cogentembedded.com>
>
> This adds ability to use gpio API at board init_machine level.
>
> F.e. it can be used in the following situation.
> Many reference hardware has onboard switches that selects which periferals
> to connect to the system. The gpio input state from switches can be used
> in choosing platform devices runtime in board code instead of ifdefs/defconfig
> changes.

Firstly, anyone still using platform_devices to describe their
system needs to be stopped. We cannot go on supporting this when
our primary boot method is supposed to be device-tree. If we keep
doing this then we will not get any of the current issues fixed.

Will it impact the devicetree bindings on rcar?


-- 
Ben Dooks				http://www.codethink.co.uk/
Senior Engineer				Codethink - Providing Genius

Re: [PATCH] gpio: gpio-rcar: init at postcore level

[Vladimir Barinov]

Hello Ben,

On 02/23/2014 11:09 PM, Ben Dooks wrote:
> On 23/02/14 16:37, vladimir.barinov@cogentembedded.com wrote:
>> From: Vladimir Barinov <vladimir.barinov@cogentembedded.com>
>>
>> This adds ability to use gpio API at board init_machine level.
>>
>> F.e. it can be used in the following situation.
>> Many reference hardware has onboard switches that selects which 
>> periferals
>> to connect to the system. The gpio input state from switches can be used
>> in choosing platform devices runtime in board code instead of 
>> ifdefs/defconfig
>> changes.
>
> Firstly, anyone still using platform_devices to describe their
> system needs to be stopped. We cannot go on supporting this when
> our primary boot method is supposed to be device-tree. If we keep
> doing this then we will not get any of the current issues fixed.
Understand. I see that this is not a time for such changes.
Hope that the DT model will take into account such kind of situation in 
the future.
>
> Will it impact the devicetree bindings on rcar?
No

Regards,
Vladimir

Re: [PATCH] gpio: gpio-rcar: init at postcore level

[Vladimir Barinov]

Hello Ben,

On 02/23/2014 11:09 PM, Ben Dooks wrote:
> On 23/02/14 16:37, vladimir.barinov@cogentembedded.com wrote:
>> From: Vladimir Barinov <vladimir.barinov@cogentembedded.com>
>>
>> This adds ability to use gpio API at board init_machine level.
>>
>> F.e. it can be used in the following situation.
>> Many reference hardware has onboard switches that selects which 
>> periferals
>> to connect to the system. The gpio input state from switches can be used
>> in choosing platform devices runtime in board code instead of 
>> ifdefs/defconfig
>> changes.
>
> Firstly, anyone still using platform_devices to describe their
> system needs to be stopped. We cannot go on supporting this when
> our primary boot method is supposed to be device-tree. If we keep
> doing this then we will not get any of the current issues fixed.
Understand. I see that this is not a time for such changes.
Hope that the DT model will take into account such kind of situation in 
the future.
>
> Will it impact the devicetree bindings on rcar?
No

Regards,
Vladimir

Re: [PATCH] gpio: gpio-rcar: init at postcore level

[Magnus Damm]

Hi Vladimir,

On Mon, Feb 24, 2014 at 1:37 AM,  <vladimir.barinov@cogentembedded.com> wrote:
> From: Vladimir Barinov <vladimir.barinov@cogentembedded.com>
>
> This adds ability to use gpio API at board init_machine level.
>
> F.e. it can be used in the following situation.
> Many reference hardware has onboard switches that selects which periferals
> to connect to the system. The gpio input state from switches can be used
> in choosing platform devices runtime in board code instead of ifdefs/defconfig
> changes.
>
> Signed-off-by: <vladimir.barinov@cogentembedded.com>
>
> ---
>  drivers/gpio/gpio-rcar.c |   12 +++++++++++-
>  1 file changed, 11 insertions(+), 1 deletion(-)
>
> Index: build/drivers/gpio/gpio-rcar.c
> ===================================================================
> --- build.orig/drivers/gpio/gpio-rcar.c 2014-02-22 23:21:51.456229152 +0400
> +++ build/drivers/gpio/gpio-rcar.c      2014-02-22 23:21:52.320229133 +0400
> @@ -485,7 +485,17 @@
>         }
>  };
>
> -module_platform_driver(gpio_rcar_device_driver);
> +static int __init gpio_rcar_init(void)
> +{
> +       return platform_driver_register(&gpio_rcar_device_driver);
> +}
> +postcore_initcall(gpio_rcar_init);
> +
> +static void __exit gpio_rcar_exit(void)
> +{
> +       platform_driver_unregister(&gpio_rcar_device_driver);
> +}
> +module_exit(gpio_rcar_exit);
>
>  MODULE_AUTHOR("Magnus Damm");
>  MODULE_DESCRIPTION("Renesas R-Car GPIO Driver");

Hi Vladimir,

Thanks for your help. Good to see that you are working on enabling the
dual role USB port on Koelsch.

Your current board code is checking some DIP switch value during boot,
and that kind of early use of GPIO would require a change in the probe
order like this patch implements. I do however believe that we should
not implement checking during boot like this.

If you for instance check the legacy Lager USBHS DIP switch code that
runs during driver probe() then that can run can use GPIO without the
need for a change like this. So your GPIO user code needs to be
adjusted.

So this patch will receive a NAK from me I'm afraid.

Thanks,

/ magnus

Re: [PATCH] gpio: gpio-rcar: init at postcore level

[Magnus Damm]

Hi Vladimir,

On Mon, Feb 24, 2014 at 1:37 AM,  <vladimir.barinov@cogentembedded.com> wrote:
> From: Vladimir Barinov <vladimir.barinov@cogentembedded.com>
>
> This adds ability to use gpio API at board init_machine level.
>
> F.e. it can be used in the following situation.
> Many reference hardware has onboard switches that selects which periferals
> to connect to the system. The gpio input state from switches can be used
> in choosing platform devices runtime in board code instead of ifdefs/defconfig
> changes.
>
> Signed-off-by: <vladimir.barinov@cogentembedded.com>
>
> ---
>  drivers/gpio/gpio-rcar.c |   12 +++++++++++-
>  1 file changed, 11 insertions(+), 1 deletion(-)
>
> Index: build/drivers/gpio/gpio-rcar.c
> =================================> --- build.orig/drivers/gpio/gpio-rcar.c 2014-02-22 23:21:51.456229152 +0400
> +++ build/drivers/gpio/gpio-rcar.c      2014-02-22 23:21:52.320229133 +0400
> @@ -485,7 +485,17 @@
>         }
>  };
>
> -module_platform_driver(gpio_rcar_device_driver);
> +static int __init gpio_rcar_init(void)
> +{
> +       return platform_driver_register(&gpio_rcar_device_driver);
> +}
> +postcore_initcall(gpio_rcar_init);
> +
> +static void __exit gpio_rcar_exit(void)
> +{
> +       platform_driver_unregister(&gpio_rcar_device_driver);
> +}
> +module_exit(gpio_rcar_exit);
>
>  MODULE_AUTHOR("Magnus Damm");
>  MODULE_DESCRIPTION("Renesas R-Car GPIO Driver");

Hi Vladimir,

Thanks for your help. Good to see that you are working on enabling the
dual role USB port on Koelsch.

Your current board code is checking some DIP switch value during boot,
and that kind of early use of GPIO would require a change in the probe
order like this patch implements. I do however believe that we should
not implement checking during boot like this.

If you for instance check the legacy Lager USBHS DIP switch code that
runs during driver probe() then that can run can use GPIO without the
need for a change like this. So your GPIO user code needs to be
adjusted.

So this patch will receive a NAK from me I'm afraid.

Thanks,

/ magnus

Re: [PATCH] gpio: gpio-rcar: init at postcore level

[Vladimir Barinov]

Hi Magnus,

On 02/24/2014 06:57 AM, Magnus Damm wrote:
> Hi Vladimir,
>
> On Mon, Feb 24, 2014 at 1:37 AM,<vladimir.barinov@cogentembedded.com>  wrote:
>> From: Vladimir Barinov<vladimir.barinov@cogentembedded.com>
>>
>> This adds ability to use gpio API at board init_machine level.
>>
>> F.e. it can be used in the following situation.
>> Many reference hardware has onboard switches that selects which periferals
>> to connect to the system. The gpio input state from switches can be used
>> in choosing platform devices runtime in board code instead of ifdefs/defconfig
>> changes.
>>
>> Signed-off-by:<vladimir.barinov@cogentembedded.com>
>>
>> ---
>>   drivers/gpio/gpio-rcar.c |   12 +++++++++++-
>>   1 file changed, 11 insertions(+), 1 deletion(-)
>>
>> Index: build/drivers/gpio/gpio-rcar.c
>> ===================================================================
>> --- build.orig/drivers/gpio/gpio-rcar.c 2014-02-22 23:21:51.456229152 +0400
>> +++ build/drivers/gpio/gpio-rcar.c      2014-02-22 23:21:52.320229133 +0400
>> @@ -485,7 +485,17 @@
>>          }
>>   };
>>
>> -module_platform_driver(gpio_rcar_device_driver);
>> +static int __init gpio_rcar_init(void)
>> +{
>> +       return platform_driver_register(&gpio_rcar_device_driver);
>> +}
>> +postcore_initcall(gpio_rcar_init);
>> +
>> +static void __exit gpio_rcar_exit(void)
>> +{
>> +       platform_driver_unregister(&gpio_rcar_device_driver);
>> +}
>> +module_exit(gpio_rcar_exit);
>>
>>   MODULE_AUTHOR("Magnus Damm");
>>   MODULE_DESCRIPTION("Renesas R-Car GPIO Driver");
> Hi Vladimir,
>
> Thanks for your help. Good to see that you are working on enabling the
> dual role USB port on Koelsch.
>
> Your current board code is checking some DIP switch value during boot,
> and that kind of early use of GPIO would require a change in the probe
> order like this patch implements. I do however believe that we should
> not implement checking during boot like this.
>
> If you for instance check the legacy Lager USBHS DIP switch code that
> runs during driver probe() then that can run can use GPIO without the
> need for a change like this. So your GPIO user code needs to be
> adjusted.
Yes, this is true for USBHS that has platform callbacks like 
hardware_init/exit.
But this is not acceptable for other devices like EHCI PCI/PHY and others.
So we wouldn't be able to do such fixup for other cases.
>
> So this patch will receive a NAK from me I'm afraid.
>
>
Thank you for review.

Regards,
Vladimir

Re: [PATCH] gpio: gpio-rcar: init at postcore level

[Vladimir Barinov]

Hi Magnus,

On 02/24/2014 06:57 AM, Magnus Damm wrote:
> Hi Vladimir,
>
> On Mon, Feb 24, 2014 at 1:37 AM,<vladimir.barinov@cogentembedded.com>  wrote:
>> From: Vladimir Barinov<vladimir.barinov@cogentembedded.com>
>>
>> This adds ability to use gpio API at board init_machine level.
>>
>> F.e. it can be used in the following situation.
>> Many reference hardware has onboard switches that selects which periferals
>> to connect to the system. The gpio input state from switches can be used
>> in choosing platform devices runtime in board code instead of ifdefs/defconfig
>> changes.
>>
>> Signed-off-by:<vladimir.barinov@cogentembedded.com>
>>
>> ---
>>   drivers/gpio/gpio-rcar.c |   12 +++++++++++-
>>   1 file changed, 11 insertions(+), 1 deletion(-)
>>
>> Index: build/drivers/gpio/gpio-rcar.c
>> =================================>> --- build.orig/drivers/gpio/gpio-rcar.c 2014-02-22 23:21:51.456229152 +0400
>> +++ build/drivers/gpio/gpio-rcar.c      2014-02-22 23:21:52.320229133 +0400
>> @@ -485,7 +485,17 @@
>>          }
>>   };
>>
>> -module_platform_driver(gpio_rcar_device_driver);
>> +static int __init gpio_rcar_init(void)
>> +{
>> +       return platform_driver_register(&gpio_rcar_device_driver);
>> +}
>> +postcore_initcall(gpio_rcar_init);
>> +
>> +static void __exit gpio_rcar_exit(void)
>> +{
>> +       platform_driver_unregister(&gpio_rcar_device_driver);
>> +}
>> +module_exit(gpio_rcar_exit);
>>
>>   MODULE_AUTHOR("Magnus Damm");
>>   MODULE_DESCRIPTION("Renesas R-Car GPIO Driver");
> Hi Vladimir,
>
> Thanks for your help. Good to see that you are working on enabling the
> dual role USB port on Koelsch.
>
> Your current board code is checking some DIP switch value during boot,
> and that kind of early use of GPIO would require a change in the probe
> order like this patch implements. I do however believe that we should
> not implement checking during boot like this.
>
> If you for instance check the legacy Lager USBHS DIP switch code that
> runs during driver probe() then that can run can use GPIO without the
> need for a change like this. So your GPIO user code needs to be
> adjusted.
Yes, this is true for USBHS that has platform callbacks like 
hardware_init/exit.
But this is not acceptable for other devices like EHCI PCI/PHY and others.
So we wouldn't be able to do such fixup for other cases.
>
> So this patch will receive a NAK from me I'm afraid.
>
>
Thank you for review.

Regards,
Vladimir

Re: [PATCH] gpio: gpio-rcar: init at postcore level

[Magnus Damm]

Hi Vladimir,

On Mon, Feb 24, 2014 at 4:42 PM, Vladimir Barinov
<vladimir.barinov@cogentembedded.com> wrote:
> Hi Magnus,
>
>
> On 02/24/2014 06:57 AM, Magnus Damm wrote:
>>
>> Hi Vladimir,
>>
>> On Mon, Feb 24, 2014 at 1:37 AM,<vladimir.barinov@cogentembedded.com>
>> wrote:
>>>
>>> From: Vladimir Barinov<vladimir.barinov@cogentembedded.com>
>>>
>>> This adds ability to use gpio API at board init_machine level.
>>>
>>> F.e. it can be used in the following situation.
>>> Many reference hardware has onboard switches that selects which
>>> periferals
>>> to connect to the system. The gpio input state from switches can be used
>>> in choosing platform devices runtime in board code instead of
>>> ifdefs/defconfig
>>> changes.
>>>
>>> Signed-off-by:<vladimir.barinov@cogentembedded.com>
>>>
>>> ---
>>>   drivers/gpio/gpio-rcar.c |   12 +++++++++++-
>>>   1 file changed, 11 insertions(+), 1 deletion(-)
>>>
>>> Index: build/drivers/gpio/gpio-rcar.c
>>> ===================================================================
>>> --- build.orig/drivers/gpio/gpio-rcar.c 2014-02-22 23:21:51.456229152
>>> +0400
>>> +++ build/drivers/gpio/gpio-rcar.c      2014-02-22 23:21:52.320229133
>>> +0400
>>> @@ -485,7 +485,17 @@
>>>          }
>>>   };
>>>
>>> -module_platform_driver(gpio_rcar_device_driver);
>>> +static int __init gpio_rcar_init(void)
>>> +{
>>> +       return platform_driver_register(&gpio_rcar_device_driver);
>>> +}
>>> +postcore_initcall(gpio_rcar_init);
>>> +
>>> +static void __exit gpio_rcar_exit(void)
>>> +{
>>> +       platform_driver_unregister(&gpio_rcar_device_driver);
>>> +}
>>> +module_exit(gpio_rcar_exit);
>>>
>>>   MODULE_AUTHOR("Magnus Damm");
>>>   MODULE_DESCRIPTION("Renesas R-Car GPIO Driver");
>>
>> Hi Vladimir,
>>
>> Thanks for your help. Good to see that you are working on enabling the
>> dual role USB port on Koelsch.
>>
>> Your current board code is checking some DIP switch value during boot,
>> and that kind of early use of GPIO would require a change in the probe
>> order like this patch implements. I do however believe that we should
>> not implement checking during boot like this.
>>
>> If you for instance check the legacy Lager USBHS DIP switch code that
>> runs during driver probe() then that can run can use GPIO without the
>> need for a change like this. So your GPIO user code needs to be
>> adjusted.
>
> Yes, this is true for USBHS that has platform callbacks like
> hardware_init/exit.
> But this is not acceptable for other devices like EHCI PCI/PHY and others.
> So we wouldn't be able to do such fixup for other cases.

Right, the USBHS driver has callbacks but PCI-based hardrware like
EHCI and OHCI do not have such. But I believe we already have some
kind of USB PHY abstraction level and we also have a R-Car Gen2 PHY
driver that somehow is integrated together with the PCI-based
hardware. Based on that my feeling is that the answer to ID-pin
control is there somewhere, and not just once during the boot! =)

Cheers,

/ magnus

Re: [PATCH] gpio: gpio-rcar: init at postcore level

[Magnus Damm]

Hi Vladimir,

On Mon, Feb 24, 2014 at 4:42 PM, Vladimir Barinov
<vladimir.barinov@cogentembedded.com> wrote:
> Hi Magnus,
>
>
> On 02/24/2014 06:57 AM, Magnus Damm wrote:
>>
>> Hi Vladimir,
>>
>> On Mon, Feb 24, 2014 at 1:37 AM,<vladimir.barinov@cogentembedded.com>
>> wrote:
>>>
>>> From: Vladimir Barinov<vladimir.barinov@cogentembedded.com>
>>>
>>> This adds ability to use gpio API at board init_machine level.
>>>
>>> F.e. it can be used in the following situation.
>>> Many reference hardware has onboard switches that selects which
>>> periferals
>>> to connect to the system. The gpio input state from switches can be used
>>> in choosing platform devices runtime in board code instead of
>>> ifdefs/defconfig
>>> changes.
>>>
>>> Signed-off-by:<vladimir.barinov@cogentembedded.com>
>>>
>>> ---
>>>   drivers/gpio/gpio-rcar.c |   12 +++++++++++-
>>>   1 file changed, 11 insertions(+), 1 deletion(-)
>>>
>>> Index: build/drivers/gpio/gpio-rcar.c
>>> =================================>>> --- build.orig/drivers/gpio/gpio-rcar.c 2014-02-22 23:21:51.456229152
>>> +0400
>>> +++ build/drivers/gpio/gpio-rcar.c      2014-02-22 23:21:52.320229133
>>> +0400
>>> @@ -485,7 +485,17 @@
>>>          }
>>>   };
>>>
>>> -module_platform_driver(gpio_rcar_device_driver);
>>> +static int __init gpio_rcar_init(void)
>>> +{
>>> +       return platform_driver_register(&gpio_rcar_device_driver);
>>> +}
>>> +postcore_initcall(gpio_rcar_init);
>>> +
>>> +static void __exit gpio_rcar_exit(void)
>>> +{
>>> +       platform_driver_unregister(&gpio_rcar_device_driver);
>>> +}
>>> +module_exit(gpio_rcar_exit);
>>>
>>>   MODULE_AUTHOR("Magnus Damm");
>>>   MODULE_DESCRIPTION("Renesas R-Car GPIO Driver");
>>
>> Hi Vladimir,
>>
>> Thanks for your help. Good to see that you are working on enabling the
>> dual role USB port on Koelsch.
>>
>> Your current board code is checking some DIP switch value during boot,
>> and that kind of early use of GPIO would require a change in the probe
>> order like this patch implements. I do however believe that we should
>> not implement checking during boot like this.
>>
>> If you for instance check the legacy Lager USBHS DIP switch code that
>> runs during driver probe() then that can run can use GPIO without the
>> need for a change like this. So your GPIO user code needs to be
>> adjusted.
>
> Yes, this is true for USBHS that has platform callbacks like
> hardware_init/exit.
> But this is not acceptable for other devices like EHCI PCI/PHY and others.
> So we wouldn't be able to do such fixup for other cases.

Right, the USBHS driver has callbacks but PCI-based hardrware like
EHCI and OHCI do not have such. But I believe we already have some
kind of USB PHY abstraction level and we also have a R-Car Gen2 PHY
driver that somehow is integrated together with the PCI-based
hardware. Based on that my feeling is that the answer to ID-pin
control is there somewhere, and not just once during the boot! =)

Cheers,

/ magnus