Re: [PATCH 3.7.0-rc4] of/net/mdio-gpio: Fix pdev->id issue when using devicetrees.
From: Srinivas KANDAGATLA <hidden>
Date: 2012-11-16 09:54:47
Also in:
linux-devicetree
On 14/11/12 23:59, David Miller wrote:
From: Srinivas KANDAGATLA <redacted> Date: Tue, 13 Nov 2012 14:26:13 +0000quoted
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
Thanks.