Message ID | 20210526135535.2515123-1-vladimir.oltean@nxp.com |
---|---|
Headers | show |
Series | Add NXP SJA1110 support to the sja1105 DSA driver | expand |
On Wed, May 26, 2021 at 8:56 AM Vladimir Oltean <olteanv@gmail.com> wrote: > > There are 4 variations of the SJA1110 switch which have a different set > of MII protocols supported per port. Document the compatible strings. > > Also, the SJA1110 optionally supports 2 internal MDIO buses for 2 > different types of Ethernet PHYs. Document a container node called > "mdios" which has 2 subnodes "mdio@0" and "mdio@1", identifiable via > compatible string, under which the driver finds the internal PHYs. > > Cc: Rob Herring <robh@kernel.org> > Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> > --- > Changes in v2: > Patch is new. > > .../bindings/net/dsa/nxp,sja1105.yaml | 43 +++++++++++++++++++ > 1 file changed, 43 insertions(+) Please use get_maintainers.pl and resend to the right lists. Specifically, the DT list in this case. > diff --git a/Documentation/devicetree/bindings/net/dsa/nxp,sja1105.yaml b/Documentation/devicetree/bindings/net/dsa/nxp,sja1105.yaml > index c1f18849a54a..640da65b0f59 100644 > --- a/Documentation/devicetree/bindings/net/dsa/nxp,sja1105.yaml > +++ b/Documentation/devicetree/bindings/net/dsa/nxp,sja1105.yaml > @@ -28,10 +28,53 @@ properties: > - nxp,sja1105q > - nxp,sja1105r > - nxp,sja1105s > + - nxp,sja1110a > + - nxp,sja1110b > + - nxp,sja1110c > + - nxp,sja1110d > > reg: > maxItems: 1 > > + # Optional container node for the 2 internal MDIO buses of the SJA1110 > + # (one for the internal 100base-T1 PHYs and the other for the single > + # 100base-TX PHY). The "reg" property does not have physical significance. > + # The PHY addresses to port correspondence is as follows: for 100base-T1, > + # port 5 has PHY 1, port 6 has PHY 2 etc, while for 100base-TX, port 1 has > + # PHY 1. > + mdios: > + type: object > + > + properties: > + '#address-cells': > + const: 1 > + '#size-cells': > + const: 0 > + > + patternProperties: > + "^mdio@[0-1]$": > + type: object > + > + allOf: > + - $ref: "http://devicetree.org/schemas/net/mdio.yaml#" > + > + properties: > + compatible: > + oneOf: > + - enum: Don't need oneOf when there is only 1 entry. > + - nxp,sja1110-base-t1-mdio > + - nxp,sja1110-base-tx-mdio > + > + reg: > + oneOf: > + - enum: > + - 0 > + - 1 > + > + required: > + - compatible > + - reg > + > patternProperties: > "^(ethernet-)?ports$": > type: object > -- > 2.25.1 >
On Wed, May 26, 2021 at 04:55:24PM +0300, Vladimir Oltean wrote: > - const struct sja1105_regs *regs = priv->info->regs; > + u64 addr = (mmd << 16) | pcs_reg; What is the reason for using "u64" here. pcs_reg is 16-bits, and mmd is five bits, which is well below 32 bits. So, why not u32?
On Wed, May 26, 2021 at 06:34:47PM +0300, Vladimir Oltean wrote: > Hi Russell, > > On Wed, May 26, 2021 at 04:24:54PM +0100, Russell King (Oracle) wrote: > > On Wed, May 26, 2021 at 04:55:24PM +0300, Vladimir Oltean wrote: > > > - const struct sja1105_regs *regs = priv->info->regs; > > > + u64 addr = (mmd << 16) | pcs_reg; > > > > What is the reason for using "u64" here. pcs_reg is 16-bits, and mmd is > > five bits, which is well below 32 bits. So, why not u32? > > The "addr" variable holds a SPI address, and in the sja1105 driver, the > SPI addresses are universally held in u64 variables, mainly because of > the packing() API (Documentation/core-api/packing.rst). As you are passing it into a function, the argument of which is a u64, the compiler will promote the u32 to a u64 by itself. I guess it doesn't actually matter, but the current code just looks really weird.