From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pf1-f173.google.com (mail-pf1-f173.google.com [209.85.210.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id DACA84C6EEA for ; Fri, 15 May 2026 16:52:52 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.210.173 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778863974; cv=none; b=rsrRDWsvS3pLPW1hqA72DXKftf9iU8JtgaMVZhiB5LIZvaoqmWjhFuViK03aRq7NWiVVEM+VD94Xsa5NcWP68Kny9rFwEEnGgDuPPgKpcZqcAq5UkCl9jQpoK26IshUjcTo76bMyHzIchJLQxcbjTi4nwGI2WtpHnwTSKXh8CoE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778863974; c=relaxed/simple; bh=jqy6pie5NKXVd5lptsDRlT9orMAig9Xp/4v49EmxTXs=; h=Message-ID:Subject:From:To:Cc:Date:In-Reply-To:References: Content-Type:MIME-Version; b=uOj8fDD9j3ykvWqQvk5eoVQMZffzurdgK6tU8wIkioXdVo99f/7TiNBwJVMO3GJlLrztrCmaweqPFNeeGvH+wX3qqROntMmLlwyoYr1UyqXcmxZatXLyOcWIrssWcGHbQZXEiYS2PYguJ7yCC2+hqGMfztCPR3gkBf6yI1BNCPo= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=D5rx6qwb; arc=none smtp.client-ip=209.85.210.173 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="D5rx6qwb" Received: by mail-pf1-f173.google.com with SMTP id d2e1a72fcca58-83ea84df1d0so12966b3a.2 for ; Fri, 15 May 2026 09:52:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1778863972; x=1779468772; darn=vger.kernel.org; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:cc:to:from:subject:message-id:from:to:cc:subject :date:message-id:reply-to; bh=YEaTPZsnfnlCqQjTdEY5h+UhTgui6HNvvTL5mus4tlk=; b=D5rx6qwbyGd+Od+A/n3rbVVHyj8d9Qt8JsPs8r/rKcnVtU6G+7/R0JAa20m6CkQ6nn 0jqNxpBZtK2rJ31MwTP/ytzj8EuZtrVBWkofe335zA7UN1ZoONylFFs9ax+p3P8gFUEG y351laZBJjPXdQGYQ3ZgYPVxGDYyJgeL6CIa9WdQzi3ZXa8fcCm+lzOTRDUlkcMAEwK+ JmfRFi+cAm+YbwkPTaEr+ihzM9JWsj70km7/XoKKhXCrQJ4vkKrcEc+rri4vS7LlbJXP bFI4gNTUIanh5mxMle3ljaTkMDpL/jdyGi5pvnecOz6iTvWLI8bA6g8QJIHerCt+KIaK FExQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1778863972; x=1779468772; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:cc:to:from:subject:message-id:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=YEaTPZsnfnlCqQjTdEY5h+UhTgui6HNvvTL5mus4tlk=; b=WRNUrFdqFCFal/QBjXWFlWeVBsbDqgrAkMCrmJc+P3aqypUD/ih8KDku8aOmNLD0Ji pjXAc74np9pEp3Dg+tFTlwEK6ktI2rq4SwkUC++puEtdSg0Kew/yjidA7O6PgYNH5roF QE3EsOpalIWMChP2A/ctHDqn24dnwswZO42WWcyLHo1Dm2Qt6O+ob1oPt5k4eMlKK3ki 4Am8qQSa+HPct2+aYThsmLGBlwAK2tIgpoZ9wZt+FK8du06FLY/exPKD8B+vSZrEQyLh fYjXyPkeCRhaFjxckNnH+azlgwxmuOGm6T3pAtfX1HzIQ+YI8pPt4b8HEEI5B5oiyrAj iP8w== X-Forwarded-Encrypted: i=1; AFNElJ9QCcm5Q8BS9E52oLVBGqJ7VjkFxvWuOJFuI9h1GhSax/5rc64Rq6X24wXy+mmeRcbBopRbi/wFpXPk9Vs=@vger.kernel.org X-Gm-Message-State: AOJu0Yxd3qR33iHbNrrGQ94dBb+9LZHpBOugeU0eEvxfl4Q3W8EKRxuG 2WXjDv0BNQa2PzAb0Iru4oNbXIiC2F+rpsDxOPQSjYXeSvsHogz9sq/1 X-Gm-Gg: Acq92OEAxaSZ2AGq8N1lZWhYZVkIV1Ms9Pclu8X0O1dA/F9HDn4afThJcJ5DozJNjMy FKFdrdZefYB4Q6D/QO8daKyMkss3Fx/EMRnBOjhsMtvWkB8sSEPEEVQpyfoMmFGkEsdJ623PaUz W7fINlHL0jKdWv8U7wo7Ool82VLX2ycMWbwplBsznkxkIuxRGChusiqKobqfIVBXxIHwvW/uia7 j1PItiSkEdb9FrV0XmzG2L8NuGwGdz/0lkpCfqiL4PUo9kysUf10lK5BFJ8bLLxY/rwUbzIKXVe xuUen85qW3BkACNfDzBYz6SkpvuynFjiDmvxGn9m4XEIC9Z4WRBO3BB54rqq0Gk3YYivCqVhamJ wm6euDpFUsv5pPt4RqGtLgGk5CbeicfrEXmxvR+HaKg0gD+VKs3Zi3lznAmQhft/sMQLkDvBeFL KH1i4MfgqjMAbmh6X3XDTErGXsykbyhZaDD2iGTzo+s9I09nqYqZZeu6La8jhBJ5MfBJBMw/5sK McIJdVF38GrATWZzZ/15RYvZMvt0E7upOBZDdBGd5vLLo0rJMM064x3KspTS9urjLZQzvaJZzaX 0MMbWG9/k4p7Sg== X-Received: by 2002:a05:6a00:39a8:b0:82f:7252:38cf with SMTP id d2e1a72fcca58-83f33cc34bcmr5166201b3a.16.1778863972003; Fri, 15 May 2026 09:52:52 -0700 (PDT) Received: from ?IPv6:2605:59c8:829:4c00:82ee:73ff:fe41:9a02? ([2605:59c8:829:4c00:82ee:73ff:fe41:9a02]) by smtp.googlemail.com with ESMTPSA id d2e1a72fcca58-83f19c78844sm6087063b3a.47.2026.05.15.09.52.50 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 15 May 2026 09:52:51 -0700 (PDT) Message-ID: <922f2ade4ee5f10e5645e3b1a194d024b88f0d76.camel@gmail.com> Subject: Re: [PATCH net-next v2 1/2] net: pcs: xpcs: Add hooks for xpcs configuration of rsfec From: Alexander H Duyck To: mike.marciniszyn@gmail.com, Alexander Duyck , Jakub Kicinski , kernel-team@meta.com, Andrew Lunn , "David S. Miller" , Eric Dumazet , Paolo Abeni , Heiner Kallweit , Russell King , Kees Cook , Andrew Lunn Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org Date: Fri, 15 May 2026 09:52:49 -0700 In-Reply-To: <20260511182604.1338-2-mike.marciniszyn@gmail.com> References: <20260511182604.1338-1-mike.marciniszyn@gmail.com> <20260511182604.1338-2-mike.marciniszyn@gmail.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.56.2 (3.56.2-2.fc42) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 On Mon, 2026-05-11 at 14:26 -0400, mike.marciniszyn@gmail.com wrote: > From: "Mike Marciniszyn (Meta)" >=20 > The DW PCS IP data sheet calls out the need to populate > these vendor registers when operating at speeds above 10Gbps. > This change enables the correct FEC settings to enable RS-FEC > encoding on the link which is the standard used for most links > at these higher speeds. >=20 > Note that the overwriting of the MDIO_PMA_RSFEC_CTRL register > is intentional and consistent DW PCS IP requirements. >=20 > Reviewed-by: Alexander Duyck > Signed-off-by: Mike Marciniszyn (Meta) > --- > v2: > - Allow mdiobus probing for addr 0 and addr 1 > - Add xpcs_find* helpers based on phy_find* to avoid hardcoded addresse= s > - Remove xpcs_bus write and use mdiodev_c45_write instead > - Address comment on use of MDIO_PMA_RSFEC_CTRL > v1: https://lore.kernel.org/all/20260506190904.4029-2-mike.marciniszyn@gm= ail.com/ >=20 > drivers/net/ethernet/meta/fbnic/fbnmdiodev_c45_writeic_mdio.c | 3 +- > drivers/net/pcs/pcs-xpcs.c | 105 +++++++++++++++++++ > drivers/net/pcs/pcs-xpcs.h | 6 ++ > include/uapi/linux/mdio.h | 3 + > 4 files changed, 115 insertions(+), 2 deletions(-) >=20 > diff --git a/drivers/net/ethernet/meta/fbnic/fbnic_mdio.c b/drivers/net/e= thernet/meta/fbnic/fbnic_mdio.c > index fe3a4ce88413..e29534dd1e0c 100644 > --- a/drivers/net/ethernet/meta/fbnic/fbnic_mdio.c > +++ b/drivers/net/ethernet/meta/fbnic/fbnic_mdio.c > @@ -263,8 +263,7 @@ int fbnic_mdiobus_create(struct fbnic_dev *fbd) > bus->read_c45 =3D &fbnic_mdio_read_c45; > bus->write_c45 =3D &fbnic_mdio_write_c45; > =20 > - /* Disable PHY auto probing. We will add PCS manually */ > - bus->phy_mask =3D ~0; > + bus->phy_mask =3D GENMASK(31, 2); > =20 > bus->parent =3D fbd->dev; > bus->priv =3D fbd; Why are you messing with the PHY autoprobing mask? That doesn't make sense to add to this patch. The side effect is that it is going to expose a phydev that won't be used as we access the PMD direcly. [...] > +static struct mdio_device *xpcs_find_first_mdev(struct dw_xpcs *xpcs) > +{ > + struct phy_device *p =3D phy_find_first(xpcs->mdiodev->bus); > + > + if (!p) > + return NULL; > + return &p->mdio; > +} > + > +static struct mdio_device * > +xpcs_find_next_mdev(struct dw_xpcs *xpcs, struct mdio_device *mdev) > +{ > + struct phy_device *p =3D container_of(mdev, struct phy_device, mdio), *= n; > + > + n =3D phy_find_next(xpcs->mdiodev->bus, p); > + if (!n) > + return NULL; > + return &n->mdio; > +} > + Okay, the use of these functions explains the issue. You shouldn't be using phy_find_next. You know the bus will be located on mdio.addr + 1. You should not need to have a phy_device assigned for each of the PMA devices. The general idea is you have mdio_devices you shouldn't be trying to use the phy_device functions in the PCS driver. > +static int > +xpcs_config_rsfec_pma(struct dw_xpcs *xpcs, const struct pma_pcs_values = *v) > +{ > + struct mdio_device *mdev; > + int ret =3D 0, i, pma_mmd; > + > + pma_mmd =3D xpcs_get_pma_mmd(xpcs); > + if (pma_mmd < 1) > + return pma_mmd; > + > + mdev =3D xpcs_find_first_mdev(xpcs); > + if (!mdev) > + return -ENODEV; > + There shouldn't be any need for a special for this. You already have the capabilities to write to the devices you need to write to. The only things you need to change would be to access the nearest PMA to the PCS as that is the one that holds the RSFEC configuration. For that you just need to know what devices are already enabled and you can access them. > + for (i =3D 0; mdev && ret >=3D 0 && i < v->lanes; > + i++, mdev =3D xpcs_find_next_mdev(xpcs, mdev)) { > + ret =3D mdiodev_c45_write(mdev, pma_mmd, MDIO_PMA_RSFEC_CTRL, > + v->rsfec_ctrl); > + } You don't need this "find next" logic. It is just the device on the adjacent bus. Also I am not sure we even need the loop logic since there are only 2 devices you have to configure as currently only 2 lanes are supported. [...] > diff --git a/include/uapi/linux/mdio.h b/include/uapi/linux/mdio.h > index b2541c948fc1..5219c877b2cf 100644 > --- a/include/uapi/linux/mdio.h > +++ b/include/uapi/linux/mdio.h > @@ -317,6 +317,9 @@ > #define MDIO_PMA_10GBR_FECABLE_ABLE 0x0001 /* FEC ability */ > #define MDIO_PMA_10GBR_FECABLE_ERRABLE 0x0002 /* FEC error indic. abilit= y */ > =20 > +/* RSFEC PMA Control register */ > +#define MDIO_PMA_RSFEC_CTRL_4LANE_PMD BIT(3) > + > /* PMA 10GBASE-R Fast Retrain status and control register. */ > #define MDIO_PMA_10GBR_FSRT_ENABLE 0x0001 /* Fast retrain enable */ > =20 The AI review complaint about this bit seems to be based on an outdated version of the IEEE specification. This is called out in 9802.3-2022 as "Four lane PMD indication" so perhaps sashiko needs to be updated.