From: Srinivas Kandagatla <redacted>
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 <redacted>
---
.../devicetree/bindings/net/mdio-gpio.txt | 9 ++++++++-
drivers/net/phy/mdio-gpio.c | 1 +
2 files changed, 9 insertions(+), 1 deletions(-)
@@ -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>;
From: Srinivas Kandagatla <redacted>
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 <redacted>
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.
From: Grant Likely <hidden> Date: 2012-11-15 16:59:49
On Tue, 13 Nov 2012 14:26:13 +0000, Srinivas KANDAGATLA [off-list ref] wrote:
quoted hunk
From: Srinivas Kandagatla <redacted>
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 <redacted>
---
.../devicetree/bindings/net/mdio-gpio.txt | 9 ++++++++-
drivers/net/phy/mdio-gpio.c | 1 +
2 files changed, 9 insertions(+), 1 deletions(-)
@@ -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>;
From: Srinivas Kandagatla <redacted>
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 <redacted>
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