[3.7.0-rc4] of/net/mdio-gpio: Fix pdev->id issue when using devicetrees.

From: Srinivas Kandagatla <srinivas.kandagatla@st.com>

When the mdio-gpio driver is probed via device trees, the platform
device id is set as -1, However the id is re-used in the code while
creating an mdio bus.
So, setting up the id via aliases from device tree is a sensible
solution to fix this issue.

Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@st.com>
---
 .../devicetree/bindings/net/mdio-gpio.txt          |    9 ++++++++-
 drivers/net/phy/mdio-gpio.c                        |    1 +
 2 files changed, 9 insertions(+), 1 deletions(-)

From: Srinivas KANDAGATLA <srinivas.kandagatla@st.com>
Date: Tue, 13 Nov 2012 14:26:13 +0000

> From: Srinivas Kandagatla <srinivas.kandagatla@st.com>
> 
> When the mdio-gpio driver is probed via device trees, the platform
> device id is set as -1, However the id is re-used in the code while
> creating an mdio bus.
> So, setting up the id via aliases from device tree is a sensible
> solution to fix this issue.
> 
> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@st.com>

This seems rather pointless unless you also update every single device
tree out there.

Also you need to describe what are the ramifications of this problem
otherwise it is impossible to figure out how serious this change is.

Does it prevent probing?  Does it cause a crash?

Basically, what I'm saying is that this is a very poor submission and
you need to substantially improve it and communicate better.

If the problem is basically benign, then you should target this change
to net-next instead of the net tree, along with the necessary dt file
updates.

Thanks.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

On Tue, 13 Nov 2012 14:26:13 +0000, Srinivas KANDAGATLA <srinivas.kandagatla@st.com> wrote:
> From: Srinivas Kandagatla <srinivas.kandagatla@st.com>
> 
> When the mdio-gpio driver is probed via device trees, the platform
> device id is set as -1, However the id is re-used in the code while
> creating an mdio bus.
> So, setting up the id via aliases from device tree is a sensible
> solution to fix this issue.
> 
> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@st.com>
> ---
>  .../devicetree/bindings/net/mdio-gpio.txt          |    9 ++++++++-
>  drivers/net/phy/mdio-gpio.c                        |    1 +
>  2 files changed, 9 insertions(+), 1 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/net/mdio-gpio.txt b/Documentation/devicetree/bindings/net/mdio-gpio.txt
> index bc95495..c79bab0 100644
> --- a/Documentation/devicetree/bindings/net/mdio-gpio.txt
> +++ b/Documentation/devicetree/bindings/net/mdio-gpio.txt
> @@ -8,9 +8,16 @@ gpios property as described in section VIII.1 in the following order:
>  
>  MDC, MDIO.
>  
> +Note: Each gpio-mdio bus should have an alias correctly numbered in "aliases"
> +node.
> +
>  Example:
>  
> -mdio {
> +aliases {
> +	mdio-gpio0 = <&mdio0>;
> +};
> +
> +mdio0: mdio {
>  	compatible = "virtual,mdio-gpio";
>  	#address-cells = <1>;
>  	#size-cells = <0>;
> diff --git a/drivers/net/phy/mdio-gpio.c b/drivers/net/phy/mdio-gpio.c
> index 899274f..e3f3115 100644
> --- a/drivers/net/phy/mdio-gpio.c
> +++ b/drivers/net/phy/mdio-gpio.c
> @@ -56,6 +56,7 @@ static void *mdio_gpio_of_get_data(struct platform_device *pdev)
>  	if (ret < 0)
>  		return NULL;
>  	pdata->mdio = ret;
> +	pdev->id = of_alias_get_id(np, "mdio-gpio");

This is actually illegal. Once a device is registered, pdev->id must not
be changed. Same goes for pdev->name and pdev->dev.platform_data.

g.

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

On 14/11/12 23:59, David Miller wrote:
> From: Srinivas KANDAGATLA <srinivas.kandagatla@st.com>
> Date: Tue, 13 Nov 2012 14:26:13 +0000
>
>> From: Srinivas Kandagatla <srinivas.kandagatla@st.com>
>>
>> When the mdio-gpio driver is probed via device trees, the platform
>> device id is set as -1, However the id is re-used in the code while
>> creating an mdio bus.
>> So, setting up the id via aliases from device tree is a sensible
>> solution to fix this issue.
>>
>> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@st.com>
> This seems rather pointless unless you also update every single device
> tree out there.
>
> Also you need to describe what are the ramifications of this problem
> otherwise it is impossible to figure out how serious this change is.
>
> Does it prevent probing?  Does it cause a crash?
I apologies, I should have explained the full use-case.

use-case is if the mac driver want to connect via phy_connect() to
mdio-gpio phy it would use bus name to do so.

mdio-gpio phy bus name is formated as "gpio-<bus-number>:<phy-addr>.
In the existing code the bus number for mdio-gpio if probed from device
trees will be set to -1 which results in bus name set to
"gpio-ffffffff:<phy-addr>" which is the problem here.
fffffff is result of pdev->id set to -1 which should be set to a logical
number, and this is only possible via aliases.

Having fffffff as bus-id also means that we can't have two mdio-gpio
buses via device trees as it will result in same bus-id.
This patch attempts to fix this issue.
So getting the id from alias would be a right choice.

I also agree with Grant's comments about setting up pdev->id.

Will send v2 patch with considering Grant's comments.

>
> Basically, what I'm saying is that this is a very poor submission and
> you need to substantially improve it and communicate better.
>
> If the problem is basically benign, then you should target this change
> to net-next instead of the net tree, along with the necessary dt file
> updates.
I have looked in net-next and there are no dt files which use this driver.

Thanks,
srini
> Thanks.
>
>

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html