From: Mohd Ayaan Anwar <mohd.anwar@oss.qualcomm.com>
To: Alex Elder <elder@riscstar.com>
Cc: maxime.chevallier@bootlin.com, andrew+netdev@lunn.ch,
davem@davemloft.net, edumazet@kernel.org, kuba@kernel.org,
pabeni@redhat.com, robh@kernel.org, krzk+dt@kernel.org,
conor+dt@kernel.org, Daniel Thompson <daniel@riscstar.com>,
mcoquelin.stm32@gmail.com, alexandre.torgue@foss.st.com,
hkallweit1@gmail.com, linux@armlinux.org.uk,
richardcochran@gmail.com, p.zabel@pengutronix.de,
peppe.cavallaro@st.com, joabreu@synopsys.com,
lorenzo.bianconi@oss.qualcomm.com, netdev@vger.kernel.org,
devicetree@vger.kernel.org,
linux-stm32@st-md-mailman.stormreply.com,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH net-next 5/5] net: stmmac: support the TC9564 SoC
Date: Mon, 19 Oct 2026 14:44:21 +0530 [thread overview]
Message-ID: <atXfbcsXo0d2Z7yc@oss.qualcomm.com> (raw)
In-Reply-To: <20261019030129.1470307-6-elder@riscstar.com>
Hi Alex,
On Sun, Oct 18, 2026 at 10:01:28PM -0500, Alex Elder wrote:
> From: Daniel Thompson <daniel@riscstar.com>
>
> Add support for the Ethernet XGMAC functionality present in the
> Toshiba TC9564 SoC.
>
> The TC9564 is a fairly complex chip that attaches to a host via
> the upstream port of a PCIe switch it implements. That switch
> has three downstream ports, and one of those has an embedded PCI
> endpoint. The PCI endpoint implements two PCI functions, and a
> 10 Gbps-capable XGMAC interface is attached to each.
>
> The TC9564 implements additional peripherals, and access to them
> is provided by a PCI endpoint bus associated with BAR 4 of the
> first PCI function. A PCI driver sets up the PCI function for
> use, and peripherals using the bus use platform drivers, matched
> by compatible string.
>
> We use the pci-ep-bus approach for the stmmac driver as well, with
> each PCI function exposing access to its BAR 4 via an endpoint bus.
> The XGMAC device is defined within a pci-ep-bus node, and is bound
> to the platform driver based on its compatible string.
>
> Signed-off-by: Daniel Thompson <daniel@riscstar.com>
> Co-developed-by: Alex Elder <elder@riscstar.com>
> Signed-off-by: Alex Elder <elder@riscstar.com>
> ---
> ...
> +/* Fields and values for the EMACTL registers */
> +#define EMAC_SP_SEL_MASK GENMASK(3, 0)
> +#define SP_SEL_2500BASEX 4
> +#define SP_SEL_SGMII_1000M 5
> +#define SP_SEL_SGMII_100M 6
> +#define SP_SEL_SGMII_10M 7
> +#define EMAC_PHY_INF_SEL_MASK GENMASK(5, 4)
> +#define PCS_CLK_PHY 1 /* Clock from PHY */
> +#define EMAC_INV_SGM_SIG_DET BIT(6) /* 1 = polarity inverted */
> +#define EMAC_LPIHWCLKEN BIT(8) /* 1 = low power mode */
> +#define EMAC_INIT_DONE BIT(21)
> +
Nit: extra tab before BIT(8) and BIT(21).
> +
> +#define PMA_HWT_REFCK_R_EN 0x1080
> +#define PMA_HWT_REFCK_TERM_EN 0x1090
> +#define PMA_HWT_REFCK_STRIDE 0x0014
> +
> +#define PMA_COMM_CFG_0_1 0x1888
> +#define PMA_COMM_CFG_0_1_STRIDE 0x0008
Nit: extra tab before 0x1090 and 0x0008.
> +
> +static int tc9564_probe_config_dt(struct tc9564_data *td)
> +{
> + struct platform_device *pdev = to_platform_device(td->dev);
> + struct device_node *np = td->dev->of_node;
> + struct plat_stmmacenet_data *plat;
> + phy_interface_t phy_interface;
> + struct device *dev = td->dev;
> + int ret;
> +
> + ret = device_get_phy_mode(dev);
> + if (ret < 0)
> + return -ENODEV;
> + phy_interface = ret;
> +
Nit: I think the call to devm_stmmac_probe_config_dt() will get the PHY
mode from firmware and store it in plat_dat->phy_interface so this is
probably redundant.
> + /* The platform structure is allocated with devm_kzalloc() */
> + plat = devm_stmmac_probe_config_dt(pdev, td->res.mac);
> + if (IS_ERR(plat))
> + return PTR_ERR(plat);
> +
> +static int tc9564_dwmac_probe(struct platform_device *pdev)
> +{
> + struct device *dev = &pdev->dev;
> + struct tc9564_data *td;
> + struct device_node *np;
> + struct regmap *regmap;
> + int ret;
> +
> + td = devm_kzalloc(dev, sizeof(*td), GFP_KERNEL);
> + if (!td)
> + return -ENOMEM;
> +
> + td->dev = dev;
> +
> + np = dev_of_node(dev);
> + regmap = syscon_regmap_lookup_by_phandle_args(np,
> + "toshiba,config-syscon",
> + 1, &td->emac_ctl_offset);
> + if (IS_ERR(regmap))
> + return dev_err_probe(dev, PTR_ERR(regmap),
> + "failed to get config regmap\n");
> + td->config_regmap = regmap;
> +
> + ret = tc9564_reset_init(td);
> + if (ret)
> + return dev_err_probe(dev, ret, "failed to initialize resets\n");
> +
> + ret = tc9564_clock_init(td);
> + if (ret)
> + return dev_err_probe(dev, ret, "failed to initialize clocks\n");
> +
> + ret = tc9564_probe_config_dt(td);
> + if (ret)
> + return ret;
> +
> + ret = stmmac_get_platform_resources(pdev, &td->res);
> + if (ret)
> + return dev_err_probe(dev, ret,
> + "failed to initialize stmmac resources\n");
> +
> + tc9564_mac_enable(td);
> +
> + ret = stmmac_dvr_probe(dev, td->plat, &td->res);
> + if (ret) {
> + ret = dev_err_probe(dev, ret, "failed stmmac probe\n");
> + goto err_disable_mac;
> + }
Nit: Could this use devm_stmmac_pltfr_probe() and drop
tc9564_dwmac_remove()?
tc9564_mac_disable() could be registered as the priv->plat->exit
callback.
> +
> + return 0;
> +
> +err_disable_mac:
> + tc9564_mac_disable(td);
> +
> + return ret;
> +}
> +
Ayaan
next prev parent reply other threads:[~2026-10-19 9:14 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-19 3:01 [PATCH net-next 0/5] net: stmmac: enable Toshiba TC9564 Alex Elder
2026-10-19 3:01 ` [PATCH net-next 1/5] dt-bindings: net: add support for " Alex Elder
2026-10-19 12:41 ` Andrew Lunn
2026-10-20 3:01 ` sashiko-bot
2026-10-20 15:12 ` Rob Herring (Arm)
2026-10-19 3:01 ` [PATCH net-next 2/5] net: pcs: pcs-xpcs-regmap: support XPCS memory-mapped MDIO bus via regmap Alex Elder
2026-10-20 3:01 ` sashiko-bot
2026-10-19 3:01 ` [PATCH net-next 3/5] net: stmmac: dwxgmac2: Add XGMAC 3.01a support Alex Elder
2026-10-19 7:58 ` Maxime Chevallier
2026-10-19 3:01 ` [PATCH net-next 4/5] net: stmmac: dwxgmac2: export symbols for XGMAC 3.01a DMA Alex Elder
2026-10-19 3:01 ` [PATCH net-next 5/5] net: stmmac: support the TC9564 SoC Alex Elder
2026-10-19 7:52 ` Maxime Chevallier
2026-10-19 9:14 ` Mohd Ayaan Anwar [this message]
2026-10-20 3:01 ` sashiko-bot
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=atXfbcsXo0d2Z7yc@oss.qualcomm.com \
--to=mohd.anwar@oss.qualcomm.com \
--cc=alexandre.torgue@foss.st.com \
--cc=andrew+netdev@lunn.ch \
--cc=conor+dt@kernel.org \
--cc=daniel@riscstar.com \
--cc=davem@davemloft.net \
--cc=devicetree@vger.kernel.org \
--cc=edumazet@kernel.org \
--cc=elder@riscstar.com \
--cc=hkallweit1@gmail.com \
--cc=joabreu@synopsys.com \
--cc=krzk+dt@kernel.org \
--cc=kuba@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-stm32@st-md-mailman.stormreply.com \
--cc=linux@armlinux.org.uk \
--cc=lorenzo.bianconi@oss.qualcomm.com \
--cc=maxime.chevallier@bootlin.com \
--cc=mcoquelin.stm32@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=p.zabel@pengutronix.de \
--cc=pabeni@redhat.com \
--cc=peppe.cavallaro@st.com \
--cc=richardcochran@gmail.com \
--cc=robh@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.