From: Simon Horman <horms@kernel.org>
To: Basharath Hussain Khaja <basharath@couthit.com>
Cc: danishanwar@ti.com, rogerq@kernel.org, andrew+netdev@lunn.ch,
davem@davemloft.net, edumazet@google.com, kuba@kernel.org,
pabeni@redhat.com, robh@kernel.org, krzk+dt@kernel.org,
conor+dt@kernel.org, nm@ti.com, ssantosh@kernel.org,
tony@atomide.com, richardcochran@gmail.com, parvathi@couthit.com,
schnelle@linux.ibm.com, rdunlap@infradead.org,
diogo.ivo@siemens.com, m-karicheri2@ti.com,
jacob.e.keller@intel.com, m-malladi@ti.com,
javier.carrasco.cruz@gmail.com, afd@ti.com, s-anna@ti.com,
linux-arm-kernel@lists.infradead.org, netdev@vger.kernel.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-omap@vger.kernel.org, pratheesh@ti.com, prajith@ti.com,
vigneshr@ti.com, praneeth@ti.com, srk@ti.com, rogerq@ti.com,
krishna@couthit.com, pmohan@couthit.com, mohan@couthit.com
Subject: Re: [RFC v2 PATCH 02/10] net: ti: prueth: Adds ICSSM Ethernet driver
Date: Thu, 30 Jan 2025 11:41:45 +0000 [thread overview]
Message-ID: <20250130114145.GM113107@kernel.org> (raw)
In-Reply-To: <20250124122353.1457174-3-basharath@couthit.com>
On Fri, Jan 24, 2025 at 05:53:45PM +0530, Basharath Hussain Khaja wrote:
> From: Roger Quadros <rogerq@ti.com>
>
> Updates Kernel configuration to enable PRUETH driver and its dependencies
> along with makefile changes to add the new PRUETH driver.
>
> Changes includes init and deinit of ICSSM PRU Ethernet driver including
> net dev registration and firmware loading for DUAL-MAC mode running on
> PRU-ICSS2 instance.
>
> Changes also includes link handling, PRU booting, default firmware loading
> and PRU stopping using existing remoteproc driver APIs.
>
> Signed-off-by: Roger Quadros <rogerq@ti.com>
> Signed-off-by: Andrew F. Davis <afd@ti.com>
> Signed-off-by: Parvathi Pudi <parvathi@couthit.com>
> Signed-off-by: Basharath Hussain Khaja <basharath@couthit.com>
...
> diff --git a/drivers/net/ethernet/ti/icssm/icssm_prueth.c b/drivers/net/ethernet/ti/icssm/icssm_prueth.c
...
> +static int icssm_emac_set_boot_pru(struct prueth_emac *emac,
> + struct net_device *ndev)
> +{
> + const struct prueth_firmware *pru_firmwares;
> + struct prueth *prueth = emac->prueth;
> + const char *fw_name;
> + int ret;
> +
> + pru_firmwares = &prueth->fw_data->fw_pru[emac->port_id - 1];
> + fw_name = pru_firmwares->fw_name[prueth->eth_type];
> + if (!fw_name) {
> + netdev_err(ndev, "eth_type %d not supported\n",
> + prueth->eth_type);
> + return -ENODEV;
> + }
> +
> + ret = rproc_set_firmware(emac->pru, fw_name);
> + if (ret) {
> + netdev_err(ndev, "failed to set PRU0 firmware %s: %d\n",
> + fw_name, ret);
> + return ret;
> + }
> +
> + ret = rproc_boot(emac->pru);
> + if (ret) {
> + netdev_err(ndev, "failed to boot PRU0: %d\n", ret);
> + return ret;
> + }
> +
> + return ret;
> +}
> +
> +/**
> + * icssm_emac_ndo_open - EMAC device open
> + * @ndev: network adapter device
> + *
> + * Called when system wants to start the interface.
> + *
> + * Return: 0 for a successful open, or appropriate error code
> + */
> +static int icssm_emac_ndo_open(struct net_device *ndev)
> +{
> + struct prueth_emac *emac = netdev_priv(ndev);
> + int ret;
> +
> + ret = icssm_emac_set_boot_pru(emac, ndev);
> + if (ret)
> + netdev_err(ndev, "failed to boot PRU: %d\n", ret);
Hi Roger, Basharath, all,
icssm_emac_set_boot_pru() already logs errors, including the one above.
So this log seems unnecessary to me.
Also, should an error be returned here? If so, it looks like
icssm_emac_set_boot_pru() should release resources allocated by
rproc_set_firmware() if rproc_boot() fails.
> +
> + /* start PHY */
> + phy_start(emac->phydev);
> +
> + return 0;
> +}
...
> +static int icssm_prueth_netdev_init(struct prueth *prueth,
> + struct device_node *eth_node)
> +{
> + struct prueth_emac *emac;
> + struct net_device *ndev;
> + enum prueth_port port;
> + enum prueth_mac mac;
> + int ret;
> +
> + port = icssm_prueth_node_port(eth_node);
> + if (port == PRUETH_PORT_INVALID)
> + return -EINVAL;
> +
> + mac = icssm_prueth_node_mac(eth_node);
> + if (mac == PRUETH_MAC_INVALID)
> + return -EINVAL;
> +
> + ndev = devm_alloc_etherdev(prueth->dev, sizeof(*emac));
> + if (!ndev)
> + return -ENOMEM;
> +
> + SET_NETDEV_DEV(ndev, prueth->dev);
> + emac = netdev_priv(ndev);
> + prueth->emac[mac] = emac;
> + emac->prueth = prueth;
> + emac->ndev = ndev;
> + emac->port_id = port;
> +
> + /* by default eth_type is EMAC */
> + switch (port) {
> + case PRUETH_PORT_MII0:
> + emac->pru = prueth->pru0;
> + break;
> + case PRUETH_PORT_MII1:
> + emac->pru = prueth->pru1;
> + break;
> + default:
> + return -EINVAL;
> + }
> + /* get mac address from DT and set private and netdev addr */
> + ret = of_get_ethdev_address(eth_node, ndev);
> + if (!is_valid_ether_addr(ndev->dev_addr)) {
> + eth_hw_addr_random(ndev);
> + dev_warn(prueth->dev, "port %d: using random MAC addr: %pM\n",
> + port, ndev->dev_addr);
> + }
> + ether_addr_copy(emac->mac_addr, ndev->dev_addr);
> +
> + /* connect PHY */
> + emac->phydev = of_phy_get_and_connect(ndev, eth_node,
> + icssm_emac_adjust_link);
> + if (!emac->phydev) {
> + dev_dbg(prueth->dev, "PHY connection failed\n");
> + ret = -EPROBE_DEFER;
Perhaps I misunderstand things, but if this occurs then
presumably icssm_prueth_netdev_init() will be called again.
And for each time this occirs another ndev will be allocated
by devm_alloc_etherdev(), each of which will only be freed
once the device is eventually torn-down.
I wonder if it would be better to free ndev here.
Which I think would imply using a non-mdev allocation for symmetry.
Similarly for resources allocated in the caller icssm_prueth_probe().
> + goto free;
> + }
> +
> + /* remove unsupported modes */
> + phy_remove_link_mode(emac->phydev, ETHTOOL_LINK_MODE_10baseT_Full_BIT);
> +
> + phy_remove_link_mode(emac->phydev, ETHTOOL_LINK_MODE_10baseT_Half_BIT);
> + phy_remove_link_mode(emac->phydev, ETHTOOL_LINK_MODE_100baseT_Half_BIT);
> +
> + phy_remove_link_mode(emac->phydev, ETHTOOL_LINK_MODE_Pause_BIT);
> + phy_remove_link_mode(emac->phydev, ETHTOOL_LINK_MODE_Asym_Pause_BIT);
> +
> + ndev->netdev_ops = &emac_netdev_ops;
> +
> + return 0;
> +free:
nit: This doesn't free anything.
> + prueth->emac[mac] = NULL;
> +
> + return ret;
> +}
...
next prev parent reply other threads:[~2025-01-30 11:41 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-24 12:23 [RFC v2 PATCH 00/10] PRU-ICSSM Ethernet Driver Basharath Hussain Khaja
2025-01-24 12:23 ` [RFC v2 PATCH 01/10] dt-bindings: net: ti: Adds DUAL-EMAC mode support on PRU-ICSS2 for AM57xx SOCs Basharath Hussain Khaja
2025-01-24 16:39 ` Conor Dooley
2025-01-29 5:16 ` Basharath Hussain Khaja
2025-01-29 17:48 ` Conor Dooley
2025-02-03 12:29 ` Basharath Hussain Khaja
2025-02-04 18:16 ` Conor Dooley
2025-01-24 12:23 ` [RFC v2 PATCH 02/10] net: ti: prueth: Adds ICSSM Ethernet driver Basharath Hussain Khaja
2025-01-30 11:41 ` Simon Horman [this message]
2025-02-01 13:25 ` Basharath Hussain Khaja
2025-01-24 12:23 ` [RFC v2 PATCH 03/10] net: ti: prueth: Adds PRUETH HW and SW configuration Basharath Hussain Khaja
2025-01-30 15:47 ` Simon Horman
2025-02-01 13:34 ` Basharath Hussain Khaja
2025-01-24 12:37 ` [RFC v2 PATCH 04/10] net: ti: prueth: Adds link detection, RX and TX support Basharath Hussain Khaja
2025-01-24 23:13 ` Joe Damato
2025-01-29 5:41 ` Basharath Hussain Khaja
2025-01-30 16:45 ` Simon Horman
2025-02-01 13:37 ` Basharath Hussain Khaja
2025-01-24 13:40 ` Basharath Hussain Khaja
2025-01-24 23:20 ` Joe Damato
2025-01-29 5:43 ` Basharath Hussain Khaja
2025-01-24 13:40 ` [RFC v2 PATCH 05/10] net: ti: prueth: Adds ethtool support for ICSSM PRUETH Driver Basharath Hussain Khaja
2025-01-30 17:23 ` Simon Horman
2025-02-01 13:48 ` Basharath Hussain Khaja
2025-01-24 13:40 ` [RFC v2 PATCH 06/10] net: ti: prueth: Adds HW timestamping support for PTP using PRU-ICSS IEP module Basharath Hussain Khaja
2025-01-31 10:33 ` Simon Horman
2025-02-05 12:24 ` Basharath Hussain Khaja
2025-01-24 13:40 ` [RFC v2 PATCH 07/10] net: ti: prueth: Adds support for network filters for traffic control supported by PRU-ICSS Basharath Hussain Khaja
2025-01-24 14:45 ` [RFC v2 PATCH 08/10] net: ti: prueth: Adds support for RX interrupt coalescing/pacing Basharath Hussain Khaja
2025-01-24 14:45 ` [RFC v2 PATCH 09/10] net: ti: prueth: Adds power management support for PRU-ICSS Basharath Hussain Khaja
2025-01-24 14:45 ` [RFC v2 PATCH 10/10] arm: dts: ti: Adds device tree nodes for PRU Cores, IEP and eCAP modules of PRU-ICSS2 Instance Basharath Hussain Khaja
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=20250130114145.GM113107@kernel.org \
--to=horms@kernel.org \
--cc=afd@ti.com \
--cc=andrew+netdev@lunn.ch \
--cc=basharath@couthit.com \
--cc=conor+dt@kernel.org \
--cc=danishanwar@ti.com \
--cc=davem@davemloft.net \
--cc=devicetree@vger.kernel.org \
--cc=diogo.ivo@siemens.com \
--cc=edumazet@google.com \
--cc=jacob.e.keller@intel.com \
--cc=javier.carrasco.cruz@gmail.com \
--cc=krishna@couthit.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-omap@vger.kernel.org \
--cc=m-karicheri2@ti.com \
--cc=m-malladi@ti.com \
--cc=mohan@couthit.com \
--cc=netdev@vger.kernel.org \
--cc=nm@ti.com \
--cc=pabeni@redhat.com \
--cc=parvathi@couthit.com \
--cc=pmohan@couthit.com \
--cc=prajith@ti.com \
--cc=praneeth@ti.com \
--cc=pratheesh@ti.com \
--cc=rdunlap@infradead.org \
--cc=richardcochran@gmail.com \
--cc=robh@kernel.org \
--cc=rogerq@kernel.org \
--cc=rogerq@ti.com \
--cc=s-anna@ti.com \
--cc=schnelle@linux.ibm.com \
--cc=srk@ti.com \
--cc=ssantosh@kernel.org \
--cc=tony@atomide.com \
--cc=vigneshr@ti.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).