Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
From:   <Jerry.Ray@microchip.com>
To:     <olteanv@gmail.com>
CC:     <andrew@lunn.ch>, <f.fainelli@gmail.com>, <davem@davemloft.net>,
        <edumazet@google.com>, <kuba@kernel.org>, <pabeni@redhat.com>,
        <jbe@pengutronix.de>, <netdev@vger.kernel.org>,
        <linux-kernel@vger.kernel.org>, <linux@armlinux.org.uk>
Subject: RE: [PATCH net-next v5 5/6] dsa: lan9303: Determine CPU port based on
 dsa_switch ptr
Thread-Topic: [PATCH net-next v5 5/6] dsa: lan9303: Determine CPU port based
 on dsa_switch ptr
Thread-Index: AQHZDCA8SY/y7YUH1UWHZfSqu6V8O65pTHcAgAE9BTA=
Date:   Mon, 12 Dec 2022 17:42:01 +0000
Message-ID: <MWHPR11MB1693284A37657C11F91ADFD0EFE29@MWHPR11MB1693.namprd11.prod.outlook.com>
References: <20221209224713.19980-1-jerry.ray@microchip.com>
 <20221209224713.19980-6-jerry.ray@microchip.com>
 <20221211224608.rdlcuqg4d37f7z66@skbuf>
In-Reply-To: <20221211224608.rdlcuqg4d37f7z66@skbuf>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?G0E26VaDz5z3kbZWqzfBL8Pz3WvcRWQsjfSnTYOwyXiqbQu1mlUjE4Ui1Ccu?=
 =?us-ascii?Q?o1BqtOiYcPRo5OvM2tLJmKIg7ePFQJC5XgaC4+coUTI6qjiwmh/ssCeqRTrb?=
 =?us-ascii?Q?z8dTN0LPTYk/4A3TW+MX2i+TQpHfowYqhha9xO8Gv5quCSvku/4RIq1wrk8W?=
 =?us-ascii?Q?K/jbLEwJ7kpS5nenjU63npfsN7oV/yLU+uhekkiiusenmTJRmO/n+hqBd3zA?=
 =?us-ascii?Q?Lugvdq3bRZR+TfbsMj1HnMf3oQ747LJhaGHRLH00VR5oL+7V5jjRRkpC7hkb?=
 =?us-ascii?Q?HyMEDVcdiSU7PkvVRJFXmNc0LpToBORHavgeINPRerMU3oGOmMMhcfH/vMNp?=
 =?us-ascii?Q?0ehelIi9ZV1mRkzrp0Co4Y1R+z8+anctMya4djjvQkrhfZpAgqaK+HSA2Gkp?=
 =?us-ascii?Q?rU0KQPnLoXmJ6nB1fHlrQTW5u8gL2fai32cRJ5pno07edQerM5a7htaK/E0R?=
 =?us-ascii?Q?5Qz/rixpkcrHwDdI4H7N6V+PPywC2qUvshxdLmtCeVGpHDEF2m9Dod2RujTy?=
 =?us-ascii?Q?Q021GtudI+JbsvpmrleZbhOoE31gTPEtc8eFd046O1qSkhb/Jh5cbfKkInHU?=
 =?us-ascii?Q?hkD8SkeT+4bjjoh7Jt6wq1OK4uswS51VTCl6Nicjv8wEvAgHDAj86dF1RLeZ?=
 =?us-ascii?Q?op5qwL+i9Aw5pIhPgPB+ilf3YG7Wj91AWEytJe9nhOdnfBpCBrdyNBrYnQKK?=
 =?us-ascii?Q?UG8l+QLrJdVQqJPkU2Dhst4v86xqi6g4R4ENFdkkrtJy/rrY8HBXaxgRlspe?=
 =?us-ascii?Q?bIIvbVnY+bn14GMq3NhYgCTpdKLpgXS7rqQYu4ER6/LFYAQ7jnXmV/+Zh+5Q?=
 =?us-ascii?Q?lbv7fn0wQumdoRiGUjDBdnQGPfozqm2E7w7J6cnSnGgctacF336o5jnUa4ge?=
 =?us-ascii?Q?dlr1Oi0Ovet+ReeMLym3gPow9MlpGdVlUUu8Rnq2ZyHWgXXr0o8QhHFcXj8F?=
 =?us-ascii?Q?oyjc5N/9HKpPPFnpbPtZCmqiLkWdU0Qy60J6/q/ape9t4Qf/0exeOPSGZZUJ?=
 =?us-ascii?Q?cPIYDALWJQ8SC9cIVntD+0DW7RVntI+FR4Rd6Kj9ZZymfJc8yWQxDfGBrjrH?=
 =?us-ascii?Q?dJbqo2I/p7FT8BYU6F0PszD1VQCXWW/qnd9sXOHeSf1dk5nuFYrwx1yCzG2s?=
 =?us-ascii?Q?k3651TshtDZMzHO4eMcQL34nD4ayD4cOVcbDAKoGPvgWnIfbKgA1GUbmRuCe?=
 =?us-ascii?Q?+sP/TS3w+JMdpZ+9dyCqoSYzwijI5Mk9gU53wX2fh8yI5nNKQx/SPpy6EXZU?=
 =?us-ascii?Q?teRrL+U7g0kpiejq0BXK1TG5pUyEEExblYDha+UchwuHV7VUFT3dw+e//cxm?=
 =?us-ascii?Q?RK3hZ5LE8IGehVrhiZ7cLVXJrNLYby8OdWOfTygxe+uTXcWYjzF04rNArKd3?=
 =?us-ascii?Q?nEgR1Q1CTzJu6vdMdmLIR66gTK4Uzf7COckYY1Nc0h+/+FtyYZm4OkQYolLY?=
 =?us-ascii?Q?DVomFDupZ1+4yBIJaleYpJtpNZCY4R9JAbre55+24+AIeN86ddssRH1V6uju?=
 =?us-ascii?Q?bAzu+LUOL1rdRR7HhhiQsIe+P6mDVa2IpbLmYSrIi0kfLKtkShUh0IM+aid6?=
 =?us-ascii?Q?DwubAqgz8mJayeP1VrxBXJId9tGo9THV/Bntm7km?=
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: MWHPR11MB1693.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 86aabcce-f8f8-4eca-0550-08dadc682d3f
X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Dec 2022 17:42:01.9848
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 3f4057f3-b418-4d4e-ba84-d55b4e897d88
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: pxi5yFD41Zuz+DVGu1Rc0iW2N0jo6tG+vI969Zx9VDu0lfgin9wg6UuDEN60RwlaghB5G48BGL+yLs7u3HarZQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW3PR11MB4730
X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIM_SIGNED,
        DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED,
        RCVD_IN_MSPIKE_H2,SPF_HELO_PASS,SPF_PASS autolearn=ham
        autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
        lindbergh.monkeyblade.net
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

> > In preparing to move the adjust_link logic into the phylink_mac_link_up
> > api, change the macro used to check for the cpu port.
>=20
> No justification given for why this change is made.
>

The phydev parameter being passed into phylink_mac_link_up for the CPU port
was NULL, so I have to move to something else.
=20
> As a counter argument, I could point out that DSA can support configurati=
ons
> where the CPU port is one of the 100BASE-TX PHY ports, and the MII port
> can be used as a regular user port where a PHY has been connected. Some
> people are already doing this, for example connecting a Beaglebone Black
> (can also be Raspberry Pi or what have you) over SPI to a VSC7512 switch
> evaluation board.
>=20
> The LAN9303 documentation makes it rather clear to me that such a
> configuration would be possible, because the Switch Engine Ingress Port
> Type Register allows any of the 3 switch ports to expect DSA tags. It's
> lan9303_setup_tagging() the one who hardcodes the driver configuration
> to be that where port 0 is the only acceptable CPU port (as well as the
> early check from lan9303_setup()).
>=20
> DSA's understanding of a CPU port is only that - a port which carries
> DSA-tagged traffic, and is not exposed as a net_device to user space.
> Nothing about MII vs internal PHY ports - that is a separate classificati=
on,
> and a dsa_is_cpu_port() test is simply not something relevant from
> phylink's perspective, to put it simply.
>=20
> What we see in other device drivers for phylink handling is that there
> is driver-level knowledge as to which ports have internal PHYs and which
> have xMII pins. See priv->info->supports_mii[] in sja1105, dev->info->sup=
ports_mii[]
> in the ksz drivers, mv88e6xxx_phy_is_internal() in mv88e6xxx,
> felix->info->port_modes[] in the ocelot drivers, etc etc. Hardcoding
> port number 0 is also better from my perspective than looking for the
> CPU port. That's because the switch IP was built with the idea in mind
> that port 0 is MII.
>=20
> I would very much appreciate if this driver did not make any assumptions
> that the internal PHY ports cannot carry DSA-tagged traffic. This
> assumption was true when the driver was introduced, but it changed with
> commit 0e27921816ad ("net: dsa: Use PHYLINK for the CPU/DSA ports").
> Coincidentally, that is also the commit which started prompting the
> lan9303 driver for an update, via the dmesg warnings you are seeing.
>=20
> It looks like there is potentially more code to unlock than this simple
> API change, which is something you could look at.
>

I understand your point. The LAN9303 is very flexible, supporting an I2C
method for managing the switch and allowing the xMII to operate as either
MAC or PHY.

The original driver was written targeting the primary configuration most
widely used by our customers. The host CPU has an xMII interface and the
MDIO bus is used for control. Adding in the flexibility to support other
configurations is something I will investigate as I expand the driver to
support LAN9353/LAN9354/LAN9355 devices. Adding the
private->info->supports_mii[] as was done in the ksz drivers is the most
likely approach. I see this as a separate patch series.  Would you agree?

I will hardcode for port 0 at this point rather than looking at CPU port.

Regards,
Jerry.

> >
> > Signed-off-by: Jerry Ray <jerry.ray@microchip.com>
> > ---
> >  drivers/net/dsa/lan9303-core.c | 6 +++++-
> >  1 file changed, 5 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/net/dsa/lan9303-core.c b/drivers/net/dsa/lan9303-c=
ore.c
> > index 694249aa1f19..1d22e4b74308 100644
> > --- a/drivers/net/dsa/lan9303-core.c
> > +++ b/drivers/net/dsa/lan9303-core.c
> > @@ -1064,7 +1064,11 @@ static void lan9303_adjust_link(struct dsa_switc=
h *ds, int port,
> >       struct lan9303 *chip =3D ds->priv;
> >       int ctl;
> >
> > -     if (!phy_is_pseudo_fixed_link(phydev))
> > +     /* On this device, we are only interested in doing something here=
 if
> > +      * this is the CPU port. All other ports are 10/100 phys using MD=
IO
> > +      * to control there link settings.
> > +      */
> > +     if (!dsa_is_cpu_port(ds, port))
> >               return;
> >
> >       ctl =3D lan9303_phy_read(ds, port, MII_BMCR);
> > --
> > 2.17.1
> >
>