edma driver accessing private data of mdio-ipq40xx driver to get access to the mii_bus created by the mdio driver.

See comments on line 163 of original mdio-ipq40xx.c:
https://chromium-review.googlesource.com/#/c/361201/1..6/drivers/net/phy/mdio-ipq40xx.c@163

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).