New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 635289 link

Starred by 1 user

Issue metadata

Status: Duplicate
Merged: issue 635039
Owner:
Last visit > 30 days ago
Closed: Aug 2016
Cc:
EstimatedDays: ----
NextAction: ----
OS: Chrome
Pri: 1
Type: Bug



Sign in to add a comment

edma/mdio driver sharing private data to access mii_bus

Project Member Reported by grundler@chromium.org, Aug 7 2016

Issue description


ipq40xx_mdio_probe() creates a private am->mii_bus data structure that is accessed by edma driver later in:
drivers/net/ethernet/qualcomm/essedma/edma_axi.c:               mdio_data = dev_get_drvdata(&mdio_plat->dev);

Thus edma_axi driver now has a reference to data that is managed by another driver and thus might change w/o notice later (leading to stale references).
 
Status: Assigned (was: Available)
More comments on this at:
https://chromium-review.googlesource.com/#/c/361201/1/drivers/net/phy/mdio-ipq40xx.c@163

Grant Grundler   Jul 21 2:21 PM
Please add the following comment before this line:
   /* edma_axi_probe() uses "am" drvdata. ipq40xx_mdio_probe() must be called first. */

Xiaofei Shen   Jul 29 4:48 AM
Done.
One question, in edma driver, in order to use am, it also define struct ipq40xx_mdio_data. Do you accept this way.

Grant Grundler   Jul 29 12:42 PM
For now, yes. But I just want it obvious this is an exception to "best practices" for kernel programming.
And honestly, exporting the driver "private" data to another driver is asking for trouble. It's the reason we define abstractions and APIs to avoid one driver from stomping on the data of the other.
My advice is to figure out a better way of controlling the HW that doesn't require sharing "private" data - but this is a longer term problem.

Xiaofei Shen     Jul 31 11:43 PM
ar40xx register phy driver in platform driver probe which is concerned by Dimtry, the purpose I do in this way is to get the mii_bus. That's why I ask this question here. Because I don't want to use the private date of mdio driver in ar400x driver.

Grant Grundler    Aug 4 1:12 PM
I am not sure I understand what you mean with "ar40xx register phy driver in platform driver probe which is concerned by Dimtry". I will ask Dmitry about his concern - we might be concerned about the same thing. :)
I understand edma_axi driver wants access to mii_bus (which this mdio driver sets up). I haven't investigated this enough to fully understand a good solution. My first guess is there needs to leverage of_mdiobus_register() call below so the edma driver can get access to the right mdio "phy device". Can edma driver use of_mdio_find_bus() to get access to mii_bus (or the services mii_bus represents)?
of_mdio_find_bus() doesn't solve the "tell me when this bus is registered" case. initcall mechanism likely solves the init ordering problem already (see usage of __define_initcall() in include/linux/init.h).
Mergedinto: 635039
Status: Duplicate (was: Assigned)

Sign in to add a comment