[PATCH 2/4] dt-bindings: net: dsa: document internal MDIO bus
Arınç ÜNAL
arinc.unal at arinc9.com
Sat Sep 9 07:35:27 PDT 2023
On 9.09.2023 11:53, Arınç ÜNAL wrote:
> On 4.09.2023 14:33, Arınç ÜNAL wrote:
>> Hey Vladimir,
>>
>> On 27.08.2023 15:12, Vladimir Oltean wrote:
>>> Hi Arınç,
>>>
>>> I am on vacation and I will just reply with some clarification aspects,
>>> without having done any further research on the topic since my last reply.
>>>
>>> On Sun, Aug 27, 2023 at 11:33:16AM +0300, Arınç ÜNAL wrote:
>>>> Before I continue commenting, I'd like to state my understanding so we can
>>>> make sure we're on the same page. If a driver doesn't use
>>>> ds->slave_mii_bus, the switch it controls must not have any internal MDIO
>>>> buses. Otherwise the PHYs on these buses couldn't function, and an improper
>>>> driver like this would not be on the official Linux source code.
>>>
>>> A DSA switch port, like any OF-based ethernet-controller which uses
>>> phylink, will use one of the phy-handle, fixed-link or managed properties
>>> to describe the interface connecting the MAC/MAC-side PCS to the PHY.
>>>
>>> At its core, ds->slave_mii_bus is nothing more than a mechanism to make
>>> sense of device trees where the above 3 phylink properties are not present.
>>>
>>> It is completely false to say that if a driver doesn't have ds->slave_mii_bus,
>>> it must not have an internal MDIO bus. Because you could still describe
>>> that internal MDIO bus like below, without making any use of the sole property
>>> that makes ds->slave_mii_bus useful from a dt-bindings perspective.
>>>
>>> ethernet-switch {
>>> ethernet-ports {
>>> port at 0 {
>>> reg = <0>;
>>> phy-handle = <&port0_phy>;
>>> phy-mode = "internal";
>>> };
>>> };
>>>
>>> mdio {
>>> port0_phy: ethernet-phy at 0 {
>>> reg = <0>;
>>> };
>>> };
>>> };
>>>
>>> This is the more universal way of describing the port setup in an
>>> OF-based way. There is also the DSA-specific (and old-style, before phylink)
>>> way of describing the same thing, which relies on the non-OF-based
>>> ds->slave_mii_bus, with bindings that look like this:
>>>
>>> ethernet-switch {
>>> ethernet-ports {
>>> port at 0 {
>>> reg = <0>;
>>> };
>>> };
>>> };
>>>
>>> But, I would say that the first variant of the binding is preferable,
>>> since it is more universal.
>>>
>>> Not all switches that have an internal MDIO bus support the second
>>> variant of the dt-binding (the ones that don't have ds->slave_mii_bus don't).
>>> But, they support the same configuration through the first form.
>>
>> Understood.
>>
>>>
>>> Furthermore, on the U-Boot mailing lists, I have been suggesting that
>>> the DM_DSA driver for mv88e6xxx should not bother to support the second
>>> version of the binding, since it is just more code to be added to handle
>>> a case which can already be described with the more universal first binding.
>>
>> That makes sense.
>>
>>>
>>>> I've checked mscc,vsc7514-switch. What I see is, the architecture is an SoC
>>>> with a switch component. Since the switch component is not designed to be a
>>>> standalone IC, the MDIO bus of the SoC could just as well be used without
>>>> the need to design an MDIO controller specific to the switch component, to
>>>> manage the PHYs. So I see this switch as just another case of a switch
>>>> without an internal MDIO bus.
>>>
>>> Well, we need to clarify the semantics of an "internal" MDIO bus.
>>>
>>> I would say most discrete chips with DSA switches have this SoC-style
>>> architecture, with separate address spaces for the switching IP, MDIO
>>> bus, GPIO controller, IRQ controllers, temperature sensors etc (see
>>> "mscc,vsc7512-switch" which is like "mscc,vsc7514-switch", but it is
>>> controlled over SPIO instead of MMIO). The dt-bindings of most DSA
>>> switches may or may not reflect that discrete chip organization. Those
>>> drivers and dt-bindings could be reimagined so that DSA is not the
>>> top-level driver.
>>>
>>> Yet, I would argue that it's wrong to say that because it isn't an OF
>>> child of the switch, the MDIO bus of the VSC7514 is not internal in the
>>> same way that the Realtek MDIO bus is internal. The switch ports are
>>> connected to internal PHYs on this MDIO bus, and there aren't PHYs on
>>> this MDIO bus that go to other MACs than the switch ports. So, the
>>> VSC7514 MDIO bus could legally be called the internal MDIO bus of the
>>> switch, even if there isn't a parent/child relationship between them.
>>
>> Good point, I had believed that the management interface of all of the PHYs
>> being connected to the MDIO bus - which is not part of the switching IP
>> address space - would be enough to classify the MDIO bus as non-internal.
>>
>> However, the architecture of separate address spaces for the switching IP
>> and MDIO bus is used on any type of IC with the switching feature.
>> Therefore, this characteristic cannot be used to distinguish whether an
>> MDIO bus is of a switch.
>>
>> What we can refer to to classify an internal MDIO bus is by confirming the
>> data interface of all PHYs on the MDIO bus is connected to the switch port
>> MACs, as you have pointed out here.
>>
>> Because the architecture of separate address spaces for the switching IP
>> and MDIO bus is used on any type of IC with the switching feature, it can
>> differ by driver how the MDIO bus is defined on the dt-bindings. So we
>> can't make universal bindings of an internal MDIO bus of a switch that
>> apply to every switch.
>>
>> So, the correct approach is to define things under the switch-specific
>> schema which is affine to the driver, as you have already pointed out.
>> Which schemas to define what will of course differ.
>>
>>>
>>> So, what I'm disagreeing with is your insistence to correlate your
>>> problem with internal MDIO buses. The way in which the problem is
>>> formulated dictates what problem gets solved, and the problem is not
>>> correctly formulated here. It is purely about ds->slave_mii_bus and its
>>> driver-defined OF presence/absence. It is a DSA-specific binding aspect
>>> which not even all DSA switches inherit, let alone bindings outside DSA.
>>
>> Got it.
>>
>>>
>>>>> For switches in the second category, it all depends on the way in which
>>>>> the driver finds the node for of_mdiobus_register().
>>>>
>>>> Ok, so some drivers require the mdio child node. Some require it and the
>>>> compatible property with a certain string.
>>>>
>>>> MDIO controlled Realtek switches do not need the compatible property under
>>>> the mdio child node. There're no compatible strings to make a distinction
>>>> between the SMI and MDIO controlled switches so the best we can do is keep
>>>> it the way it currently is. Define realtek,smi-mdio as a compatible string
>>>> but keep the compatible property optional. I did state this on my reply to
>>>> patch 3 but still received reviewed-bys regardless.
>>>
>>> Yes, because.... [1]
>>>
>>>>> Having identified all switches which make some sort of use of
>>>>> ds->slave_mii_bus, the rule would sound like this:
>>>>>
>>>>> 1. If the schema is that of (need to replace this with compatible
>>>>> strings, I'm too lazy for that):
>>>>>
>>>>> - ksz_switch_ops
>>>>> - mv88e6060_switch_ops
>>>>> - lan9303_switch_ops
>>>>> - rtl8365mb_switch_ops_mdio
>>>>> - b53_switch_ops
>>>>> - vsc73xx_ds_ops
>>>>> - mv88e6xxx
>>>>> - qca8k
>>>>>
>>>>> and we have an "mdio" child, then phylink bindings are mandatory on user ports.
>>>>>
>>>>> 2. If the schema is that of gswip_mdio and we have a child node of "lantiq,xrx200-mdio",
>>>>> then phylink bindings are mandatory on user ports (I haven't checked,
>>>>> but it might be that the "lantiq,xrx200-mdio" child is mandatory, and
>>>>> in that case, this goes to category 4 below).
>>>>>
>>>>> 3. If the schema is that of realtek_smi_setup_mdio and we have a child node of
>>>>> "realtek,smi-mdio", then phylink bindings are mandatory on user ports
>>>>> (same comment about the child MDIO note maybe being mandatory).
>>>>>
>>>>> 4. If the switch didn't appear in the above set of rules, then phylink
>>>>> bindings are unconditionally mandatory on user ports.
>>>>>
>>>>> We don't care at all what the drivers that don't use ds->slave_mii_bus
>>>>> do with the "mdio" child node. It doesn't change the fact that their
>>>>> user ports can't have missing phylink bindings.
>>>>
>>>> I partially agree. I say, for the switches without an internal MDIO bus,
>>>> invalidate the mdio child node, and enforce the phylink bindings on the
>>>> user ports. Such as mscc,vsc7514-switch and nxp,sja1105x. For nxp,sja1110x,
>>>> invalidate the mdio child node, and enforce the phylink bindings on the
>>>> user ports if the mdios property is used.
>>>
>>> Why "if the mdios property is used" and not "always"? :-/
>>>
>>> To say it again: because the sja1105 driver does not use ds->slave_mii_bus,
>>> it can make no sense of dt-bindings on user ports which lack phylink properties.
>>> So they are *always* needed. The "mdios" property changes nothing in that regard.
>>
>> Got it.
>>
>>>
>>>>
>>>> I'd like to add this before I conclude. The way I understand dt-bindings is
>>>> that a binding does not have to translate to an action on the driver.
>>>> Documenting bindings for the sole purpose of describing hardware is a valid
>>>> case.
>>>
>>> [1] ...this. The SMI-controlled and MDIO-controlled Realtek switches are
>>> otherwise the same, right? So why would they have different dt-bindings?
>>
>> Honestly, I'm wondering the answer to this as well. For some reason, when
>> probing the SMI controlled Realtek switches, instead of just letting
>> dsa_switch_setup() populate ds->slave_mii_bus, on realtek_smi_setup_mdio()
>> on realtek-smi.c:
>>
>> - priv->slave_mii_bus is allocated.
>> - mdio_np = of_get_compatible_child(priv->dev->of_node, "realtek,smi-mdio");
>> - priv->slave_mii_bus->dev.of_node = mdio_np;
>> - ds->slave_mii_bus = priv->slave_mii_bus;
>>
>>>
>>>> For example, currently, the MT753X DSA subdriver won't, in any way,
>>>> register the bus OF-based. Still, the mdio property for the switches which
>>>> this driver controls can be documented because the internal mdio bus does
>>>> exist on the hardware.
>>>
>>> It can, but the whole point is: if ds->slave_mii_bus gains an OF presence,
>>> then it loses its core functionality (that user ports can lack phylink
>>> bindings). This is the entire essence of what this discussion should capture.
>>
>> Understood.
>>
>>>
>>>>
>>>> So I'd like to keep the mdio property valid for the switches which their
>>>> drivers can only register non-OF-based ds->slave_mii_bus.
>>>>
>>>> In conclusion, what to do:
>>>>
>>>> - Define "the mdio property" and "the enforcement of phylink bindings for
>>>> user ports if mdio property is used" on ethernet-switch.yaml.
>>>> - Invalidate the mdio property on the switches without an internal MDIO
>>>> bus.
>>>> - Define "the enforcement of phylink bindings for user ports" on the
>>>> switches without an internal MDIO bus.
>>>> - Require "the mdio property" for the switches which their driver requires
>>>> it to function.
>>>> - Require "the mdio property" and "the compatible string of the mdio
>>>> property" for the switches which their driver requires them to function.
>>>>
>>>> There's no 1:1 switch to switch compatible string relation, as seen on
>>>> Realtek switches so I'll have to figure that out as I go.
>>>>
>>>> I'm open to your comments to this mail but the gap between discussion and
>>>> end result has widened a lot on this patch series so I'd like to first
>>>> offload this conversation by preparing v2 with what I said here and discuss
>>>> further there.
>>>
>>> Honestly, from my side, a verbal comment in the dt-bindings document
>>> would have been just fine, as long as it is truthful to the reality it
>>> describes.
>>>
>>> You wanted to over-complicate things with an actual schema validation,
>>> and then hooking onto things that are unrelated with the phenomenon that
>>> needs to be captured (like the "mdio" child node, without explicit
>>> regard to whether it is the ds->slave_mii_bus or not).
>>>
>>> It's not about internal MDIO buses in general, it's about whether those
>>> internal MDIO buses are used in ds->slave_mii_bus, and their OF
>>> presence/absence! That is absolutely driver-specific and I would only
>>> expect a driver-specific way of enforcing it. I didn't say it's not
>>> hard, and I didn't ask to enforce it, either.
>>
>> OK, I believe we're on the same page now, I will start working on properly
>> enforcing this.
>
> I'm writing below as a mix of patch log and discussion.
>
> Phylink bindings are required for ports that are controlled by OF-based
> buses. DSA, like any other driver utilising the Linux MDIO infrastructure,
> can register a bus. If I understand correctly, non-OF-based registration of
> OpenFirmware MDIO buses is a feature specific to DSA which certain DSA
> subdrivers make use of.
>
> There's no way to distinguish which port is controlled by which driver's
> MDIO bus on the bindings so we can't enforce phylink bindings for all user
> ports as this would also enforce phylink bindings on user ports controlled
> by a non-OF-based bus.
>
> But we can know when DSA won't create a non-OF-based bus. That leaves us
> with only OF-based buses in which case we can enforce phylink bindings for
> all user ports. So we need to check each DSA subdriver to see when all
> buses will be OF-based.
>
> A DSA subdriver can either let the main DSA driver register the bus or it
> can register a bus or buses itself.
>
> The attributes of a DSA subdriver that lets the DSA driver register the
> bus:
> - ds->ops->phy_read() and ds->ops->phy_write() are present.
> - ds->slave_mii_bus is not populated by the DSA subdriver.
> - The bus is registered non-OF-based or OF-based. Registered OF-based if
> "mdio" child node is defined.
>
> How each DSA subdriver behaves is documented below.
>
> ---
>
> - mscc,vsc7514-switch.yaml
> - mscc,vsc7514-switch
> - mscc,vsc7512-switch
>
> drivers/net/ethernet/mscc/ocelot_vsc7514.c:
> - Not a DSA subdriver.
> - MDIO_MSCC_MIIM, a driver utilising the Linux MDIO infrastructure is used
> to register a bus.
>
> drivers/net/dsa/ocelot/ocelot_ext.c:
> - The DSA subdriver won't let the DSA driver register the bus.
> - No ds->ops->phy_read() or ds->ops->phy_write().
> - MDIO_MSCC_MIIM, a driver utilising the Linux MDIO infrastructure is used
> to register a bus.
>
> What to do:
> - For mscc,vsc7514-switch, enforce phylink bindings for ports.
> - For mscc,vsc7512-switch, enforce phylink bindings for user ports.
>
> ---
>
> - renesas,rzn1-a5psw.yaml
> - renesas,r9a06g032-a5psw, renesas,rzn1-a5psw
>
> drivers/net/dsa/rzn1_a5psw.c:
> - The DSA subdriver won't let the DSA driver register the bus.
> - No ds->ops->phy_read() or ds->ops->phy_write().
> - Registers the bus OF-based only. Registers the bus when "mdio" child node
> is defined.
> - mdio = of_get_child_by_name(dev->of_node, "mdio");
> if (of_device_is_available(mdio))
> ret = a5psw_probe_mdio(a5psw, mdio);
>
> What to do:
> - Document "mdio".
> - Enforce phylink bindings for user ports.
>
> ---
>
> - realtek.yaml
> - realtek,rtl8365mb
> - realtek,rtl8366rb
>
> drivers/net/dsa/realtek/realtek-smi.c:
> - The DSA subdriver won't let the DSA driver register the bus. Registers
> the bus OF-based only. Registering the bus is mandatory. Registers the
> bus when compatible string "realtek,smi-mdio" on a child node is defined.
> - mdio_np = of_get_compatible_child(priv->dev->of_node, "realtek,smi-mdio");
> if (!mdio_np)
> return -ENODEV;
> ds->slave_mii_bus = priv->slave_mii_bus;
>
> drivers/net/dsa/realtek/realtek-mdio.c:
> - The DSA subdriver lets the DSA driver register the bus.
>
> What to do:
> - Document "mdio".
> - Require "mdio". (Can't do because it's not required for MDIO controlled
> switches that share the compatible string with SMI controlled switches.
> This is why I would like Luiz to unify the bus registeration process.)
> - Document compatible string "realtek,smi-mdio" on "mdio" child node.
> - Require compatible. (Can't do because the same as above.)
> - Enforce phylink bindings for user ports. (Can't do because the same as
> above.)
> - Enforce phylink bindings for user ports if "mdio" is defined.
I rediscovered that the reg property can be used to distinguish the SMI and
MDIO controlled Realtek switches. So I can indeed write a proper schema.
I'd still like the bus registration to be unified to eliminate unnecessary
complexity.
>
> ---
>
> - qca8k.yaml
> - qca,qca8327
> - qca,qca8328
> - qca,qca8334
> - qca,qca8337
>
> drivers/net/dsa/qca/qca8k-8xxx.c:
> - The DSA subdriver won't let the DSA driver register the bus.
> - No ds->ops->phy_read() or ds->ops->phy_write().
> - Registers the bus non-OF-based or OF-based. Registers OF-based if "mdio"
> child node is defined.
> - mdio = of_get_child_by_name(priv->dev->of_node, "mdio");
>
> What to do:
> - Document "mdio".
> - Enforce phylink bindings for user ports if "mdio" is defined.
>
> ---
>
> - nxp,sja1105.yaml
> - nxp,sja1105e
> - nxp,sja1105t
> - nxp,sja1105p
> - nxp,sja1105q
> - nxp,sja1105r
> - nxp,sja1105s
> - nxp,sja1110a
> - nxp,sja1110b
> - nxp,sja1110c
> - nxp,sja1110d
>
> drivers/net/dsa/sja1105/sja1105_mdio.c:
> - The DSA subdriver won't let the DSA driver register the bus.
> - No ds->ops->phy_read() or ds->ops->phy_write().
> - Registers multiple buses OF-based only. Registers the buses when "mdios"
> child node and "nxp,sja1110-base-tx-mdio" and "nxp,sja1110-base-t1-mdio"
> compatible strings per child node under "mdios" is defined.
> - mdio_node = of_get_child_by_name(switch_node, "mdios");
> if (!mdio_node)
> return 0;
> - np = of_get_compatible_child(mdio_node, "nxp,sja1110-base-tx-mdio");
> if (!np)
> return 0;
> - np = of_get_compatible_child(mdio_node, "nxp,sja1110-base-t1-mdio");
> if (!np)
> return 0;
>
> What to do:
> - Document "mdios".
> - Document child node pattern property under "mdios".
> - Document "nxp,sja1110-base-tx-mdio" and "nxp,sja1110-base-t1-mdio"
> compatible strings.
> - Enforce phylink bindings for user ports.
>
> ---
>
> - mscc,ocelot.yaml
> - mscc,vsc9953-switch
> - pci1957,eef0
>
> drivers/net/dsa/ocelot/seville_vsc9953.c:
> - The DSA subdriver won't let the DSA driver register the bus.
> - No ds->ops->phy_read() or ds->ops->phy_write().
> - MDIO_MSCC_MIIM, a driver utilising the Linux MDIO infrastructure is used
> to register a bus.
>
> drivers/net/dsa/ocelot/felix_vsc9959.c:
> - The DSA subdriver won't let the DSA driver register the bus.
> - No ds->ops->phy_read() or ds->ops->phy_write().
> - FSL_ENETC_MDIO, a driver utilising the Linux MDIO infrastructure is used
> to register a bus.
>
> What to do:
> - Enforce phylink bindings for user ports.
>
> ---
>
> - microchip,lan937x.yaml
> - microchip,lan9370
> - microchip,lan9371
> - microchip,lan9372
> - microchip,lan9373
> - microchip,lan9374
> - microchip,ksz.yaml
> - microchip,ksz8765
> - microchip,ksz8794
> - microchip,ksz8795
> - microchip,ksz8863
> - microchip,ksz8873
> - microchip,ksz9477
> - microchip,ksz9897
> - microchip,ksz9896
> - microchip,ksz9567
> - microchip,ksz8565
> - microchip,ksz9893
> - microchip,ksz9563
> - microchip,ksz8563
>
> drivers/net/dsa/microchip/ksz_common.c:
> - The DSA subdriver won't let the DSA driver register the bus when "mdio"
> child node is defined. Registers the bus OF-based only. Registers the bus
> when "mdio" child node is defined.
> - mdio_np = of_get_child_by_name(dev->dev->of_node, "mdio");
> if (!mdio_np)
> return 0;
> ds->slave_mii_bus = bus;
>
> What to do:
> - Document "mdio".
> - Enforce phylink bindings for user ports if "mdio" is defined.
>
> ---
>
> - hirschmann,hellcreek.yaml
> - hirschmann,hellcreek-de1soc-r1
>
> drivers/net/dsa/hirschmann/hellcreek.c:
> - The DSA subdriver won't let the DSA driver register the bus.
> - No ds->ops->phy_read() or ds->ops->phy_write().
>
> What to do:
> - Enforce phylink bindings for user ports.
>
> ---
>
> - mediatek,mt7530.yaml
> - mediatek,mt7530
> - mediatek,mt7531
> - mediatek,mt7621
> - mediatek,mt7988-switch
>
> drivers/net/dsa/mt7530.c:
> - The DSA subdriver won't let the DSA driver register the bus.
> - No ds->ops->phy_read() or ds->ops->phy_write().
> - Registers the bus non-OF-based or OF-based. Registers OF-based if "mdio"
> child node is defined. (This is after the patch for the MT7530 DSA
> subdriver is applied.)
>
> What to do:
> - Document "mdio".
> - Enforce phylink bindings for user ports if "mdio" is defined.
>
> ---
>
> - brcm,sf2.yaml
> - brcm,bcm4908-switch
> - brcm,bcm7278-switch-v4.0
> - brcm,bcm7278-switch-v4.8
> - brcm,bcm7445-switch-v4.0
>
> drivers/net/dsa/bcm_sf2.c:
> - The DSA subdriver won't let the DSA driver register the bus.
> - No ds->ops->phy_read() or ds->ops->phy_write().
> - Requires MDIO_BCM_UNIMAC, a driver utilising the Linux MDIO
> infrastructure to register a bus.
> - dn = of_find_compatible_node(NULL, NULL, "brcm,unimac-mdio");
> priv->master_mii_bus = of_mdio_find_bus(dn);
> if (!priv->master_mii_bus) {
> of_node_put(dn);
> return -EPROBE_DEFER;
> }
>
> What to do:
> - Enforce phylink bindings for user ports.
>
> ---
>
> - brcm,b53.yaml
> - brcm,bcm5325
> - brcm,bcm53115
> - brcm,bcm53125
> - brcm,bcm53128
> - brcm,bcm53134
> - brcm,bcm5365
> - brcm,bcm5395
> - brcm,bcm5389
> - brcm,bcm5397
> - brcm,bcm5398
> - brcm,bcm11360-srab, brcm,cygnus-srab
> - brcm,bcm53010-srab, brcm,bcm5301x-srab
> - brcm,bcm53011-srab, brcm,bcm5301x-srab
> - brcm,bcm53012-srab, brcm,bcm5301x-srab
> - brcm,bcm53018-srab, brcm,bcm5301x-srab
> - brcm,bcm53019-srab, brcm,bcm5301x-srab
> - brcm,bcm11404-srab, brcm,omega-srab
> - brcm,bcm11407-srab, brcm,omega-srab
> - brcm,bcm11409-srab, brcm,omega-srab
> - brcm,bcm58310-srab, brcm,omega-srab
> - brcm,bcm58311-srab, brcm,omega-srab
> - brcm,bcm58313-srab, brcm,omega-srab
> - brcm,bcm58522-srab, brcm,nsp-srab
> - brcm,bcm58523-srab, brcm,nsp-srab
> - brcm,bcm58525-srab, brcm,nsp-srab
> - brcm,bcm58622-srab, brcm,nsp-srab
> - brcm,bcm58623-srab, brcm,nsp-srab
> - brcm,bcm58625-srab, brcm,nsp-srab
> - brcm,bcm88312-srab, brcm,nsp-srab
> - brcm,bcm3384-switch, brcm,bcm63xx-switch
> - brcm,bcm6318-switch, brcm,bcm63xx-switch
> - brcm,bcm6328-switch, brcm,bcm63xx-switch
> - brcm,bcm6362-switch, brcm,bcm63xx-switch
> - brcm,bcm6368-switch, brcm,bcm63xx-switch
> - brcm,bcm63268-switch, brcm,bcm63xx-switch
>
> drivers/net/dsa/b53/b53_common.c:
> - The DSA subdriver lets the DSA driver register the bus.
>
> What to do:
> - Document "mdio".
> - Enforce phylink bindings for user ports if "mdio" is defined.
>
> ---
>
> - arrow,xrs700x.yaml
> - arrow,xrs7003e
> - arrow,xrs7003f
> - arrow,xrs7004e
> - arrow,xrs7004f
>
> drivers/net/dsa/xrs700x/xrs700x.c:
> - The DSA subdriver won't let the DSA driver register the bus.
> - No ds->ops->phy_read() or ds->ops->phy_write().
>
> What to do:
> - Enforce phylink bindings for user ports.
>
> ---
>
> Text documents. I will handle these when I replace them with json-schema
> documents.
>
> - ar9331.txt
> - qca,ar9331-switch
>
> drivers/net/dsa/qca/ar9331.c:
> - The DSA subdriver won't let the DSA driver register the bus.
> - No ds->ops->phy_read() or ds->ops->phy_write().
> - Registers the bus OF-based only. Registering the bus is mandatory.
> Registers the bus when "mdio" child node is defined.
> - mnp = of_get_child_by_name(np, "mdio");
> if (!mnp)
> return -ENODEV;
>
> What to do:
> - Document "mdio".
> - Require "mdio".
> - Enforce phylink bindings for user ports.
>
> ---
>
> - lan9303.txt
> - smsc,lan9303-i2c
> - smsc,lan9303-mdio
>
> drivers/net/dsa/lan9303-core.c:
> - The DSA subdriver lets the DSA driver register the bus.
>
> What to do:
> - Document "mdio".
> - Enforce phylink bindings for user ports if "mdio" is defined.
>
> ---
>
> - lantiq-gswip.txt
> - lantiq,xrx200-gswip
> - lantiq,xrx300-gswip
> - lantiq,xrx330-gswip
>
> drivers/net/dsa/lantiq_gswip.c:
> - The DSA subdriver won't let the DSA driver register the bus.
> - No ds->ops->phy_read() or ds->ops->phy_write().
> - Registers the bus OF-based only. Registers the bus when compatible string
> "lantiq,xrx200-mdio" on a child node is defined.
> - mdio_np = of_get_compatible_child(dev->of_node, "lantiq,xrx200-mdio");
> if (mdio_np)
> err = gswip_mdio(priv, mdio_np);
>
> What to do:
> - Document "mdio".
> - Document compatible string "realtek,smi-mdio" on "mdio" child node.
This should be "lantiq,xrx200-mdio" instead.
Arınç
> - Require compatible.
> - Enforce phylink bindings for user ports.
>
> ---
>
> - marvell.txt
> - marvell,mv88e6085
> - marvell,mv88e6190
> - marvell,mv88e6250
>
> drivers/net/dsa/mv88e6xxx/chip.c:
> - The DSA subdriver won't let the DSA driver register the bus.
> - ds->slave_mii_bus = mv88e6xxx_default_mdio_bus(chip);
> - Registers the bus non-OF-based or OF-based. Registers OF-based if "mdio"
> child node is defined.
>
> What to do:
> - Document "mdio".
> - Enforce phylink bindings for user ports if "mdio" is defined.
>
> ---
>
> - vitesse,vsc73xx.txt
> - vitesse,vsc7385
> - vitesse,vsc7388
> - vitesse,vsc7395
> - vitesse,vsc7398
>
> drivers/net/dsa/vitesse-vsc73xx-core.c:
> - The DSA subdriver lets the DSA driver register the bus.
>
> What to do:
> - Document "mdio".
> - Enforce phylink bindings for user ports if "mdio" is defined.
>
> Arınç
More information about the linux-arm-kernel
mailing list