Florian Fainelli wrote:
The larger issue is that the emac_sgmii node in the form you posted
is going to be backed by a platform device in Linux while you want a
PHY device with a reg property that describes a MDIO address
(#address-cells = 1, #size-cells = 0).
But how do I get the platform device for the emac_sgmii node? If I
create an of_device_id ID for it, like this:
static const struct of_device_id emac_dt_match[] = {
{
.compatible = "qcom,fsm9900-emac",
},
{}
};
static const struct of_device_id emac_sgmii_dt_match[] = {
{
.compatible = "qcom,fsm9900-emac-sgmii",
},
{}
};
Then the probe function will be called for qcom,fsm9900-emac-sgmii
separately from qcom,fsm9900-emac, which just confuses things. So I
can't create emac_sgmii_dt_match.
I know this is standard DT stuff, and I used to do a lot of work on DT
so maybe I should know this already. But it seems to me that I need to
manually create the platform_device for qcom,fsm9900-emac-sgmii.
IIRC the amd xgbe driver mainline had a similar design but still
implemented a PHY device anyway although it may not have been using
Device Tree. It should still be possible to implement a PHY driver
that you manually register and bind to its device_node pointer such
that of_phy_find_device and friends still work. You would do this
from the emac_sgmii platform device driver and parent devices in a
way that satisfy the PHY device driver lifecycle as well.
Hope this helps.
It doesn't, sorry. The emac_sgmii is really just another register block
for the driver to program. Creating another PHY driver for it doesn't
really make sense. It's not on an MDIO bus.
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the
Code Aurora Forum, hosted by The Linux Foundation.
