From: Andrew Lunn <andrew@lunn.ch>
To: Steen Hegelund <steen.hegelund@microchip.com>
Cc: Bjarni Jonasson <bjarni.jonasson@microchip.com>,
Alexandre Belloni <alexandre.belloni@bootlin.com>,
linux-kernel@vger.kernel.org, Arnd Bergmann <arnd@arndb.de>,
Madalin Bucur <madalin.bucur@oss.nxp.com>,
netdev@vger.kernel.org, Masahiro Yamada <masahiroy@kernel.org>,
Russell King <linux@armlinux.org.uk>,
Microchip Linux Driver Support <UNGLinuxDriver@microchip.com>,
linux-arm-kernel@lists.infradead.org,
Mark Einon <mark.einon@gmail.com>,
Jakub Kicinski <kuba@kernel.org>,
"David S. Miller" <davem@davemloft.net>,
Lars Povlsen <lars.povlsen@microchip.com>
Subject: Re: [RFC PATCH v2 3/8] net: sparx5: add hostmode with phylink support
Date: Sat, 19 Dec 2020 20:51:33 +0100 [thread overview]
Message-ID: <20201219195133.GD3026679@lunn.ch> (raw)
In-Reply-To: <20201217075134.919699-4-steen.hegelund@microchip.com>
> + /* Create a phylink for PHY management. Also handles SFPs */
> + spx5_port->phylink_config.dev = &spx5_port->ndev->dev;
> + spx5_port->phylink_config.type = PHYLINK_NETDEV;
> + spx5_port->phylink_config.pcs_poll = true;
> +
> + /* phylink needs a valid interface mode to parse dt node */
> + if (phy_mode == PHY_INTERFACE_MODE_NA)
> + phy_mode = PHY_INTERFACE_MODE_10GBASER;
Maybe just enforce a valid value in DT?
> +/* Configuration */
> +static inline bool sparx5_use_cu_phy(struct sparx5_port *port)
> +{
> + return port->conf.phy_mode != PHY_INTERFACE_MODE_NA;
> +}
That is a rather odd definition of copper.
> diff --git a/drivers/net/ethernet/microchip/sparx5/sparx5_netdev.c b/drivers/net/ethernet/microchip/sparx5/sparx5_netdev.c
> new file mode 100644
> index 000000000000..6f9282e9d3f4
> --- /dev/null
> +++ b/drivers/net/ethernet/microchip/sparx5/sparx5_netdev.c
> @@ -0,0 +1,203 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/* Microchip Sparx5 Switch driver
> + *
> + * Copyright (c) 2020 Microchip Technology Inc. and its subsidiaries.
> + */
> +
> +#include "sparx5_main.h"
I don't actually know what is preferred here, but very few drivers
i've reviewed put all the required headers into another header
file. They normally list them in each .c file.
> +static int sparx5_port_open(struct net_device *ndev)
> +{
> + struct sparx5_port *port = netdev_priv(ndev);
> + int err = 0;
> +
> + err = phylink_of_phy_connect(port->phylink, port->of_node, 0);
> + if (err) {
> + netdev_err(ndev, "Could not attach to PHY\n");
> + return err;
> + }
> +
> + phylink_start(port->phylink);
> +
> + if (!ndev->phydev) {
Humm. When is ndev->phydev set? I don't think phylink ever sets it.
> + /* power up serdes */
> + port->conf.power_down = false;
> + err = phy_power_on(port->serdes);
> + if (err)
> + netdev_err(ndev, "%s failed\n", __func__);
> + }
> +
> + return err;
> +}
> +struct net_device *sparx5_create_netdev(struct sparx5 *sparx5, u32 portno)
> +{
> + struct net_device *ndev;
> + struct sparx5_port *spx5_port;
> +
> + ndev = devm_alloc_etherdev(sparx5->dev, sizeof(struct sparx5_port));
> + if (!ndev)
> + return ERR_PTR(-ENOMEM);
> +
> + SET_NETDEV_DEV(ndev, sparx5->dev);
> + spx5_port = netdev_priv(ndev);
> + spx5_port->ndev = ndev;
> + spx5_port->sparx5 = sparx5;
> + spx5_port->portno = portno;
> + sparx5_set_port_ifh(spx5_port->ifh, portno);
> + snprintf(ndev->name, IFNAMSIZ, "eth%d", portno);
> +
> + ether_setup(ndev);
devm_alloc_etherdev() should of already called ether_setup().
> + ndev->netdev_ops = &sparx5_port_netdev_ops;
> + ndev->features |= NETIF_F_LLTX; /* software tx */
> +
> + ether_addr_copy(ndev->dev_addr, sparx5->base_mac);
> + ndev->dev_addr[ETH_ALEN - 1] += portno + 1;
That will cause some surprises with wrap around. Use eth_addr_inc()
> +static void sparx5_xtr_grp(struct sparx5 *sparx5, u8 grp, bool byte_swap)
> +{
> + int i, byte_cnt = 0;
> + bool eof_flag = false, pruned_flag = false, abort_flag = false;
> + u32 ifh[IFH_LEN];
> + struct sk_buff *skb;
> + struct frame_info fi;
> + struct sparx5_port *port;
> + struct net_device *netdev;
> + u32 *rxbuf;
> +
> + /* Get IFH */
> + for (i = 0; i < IFH_LEN; i++)
> + ifh[i] = spx5_rd(sparx5, QS_XTR_RD(grp));
> +
> + /* Decode IFH (whats needed) */
> + sparx5_ifh_parse(ifh, &fi);
> +
> + /* Map to port netdev */
> + port = fi.src_port < SPX5_PORTS ?
> + sparx5->ports[fi.src_port] : NULL;
> + if (!port || !port->ndev) {
> + dev_err(sparx5->dev, "Data on inactive port %d\n", fi.src_port);
> + sparx5_xtr_flush(sparx5, grp);
> + return;
> + }
> +
> + /* Have netdev, get skb */
> + netdev = port->ndev;
> + skb = netdev_alloc_skb(netdev, netdev->mtu + ETH_HLEN);
> + if (!skb) {
> + sparx5_xtr_flush(sparx5, grp);
> + dev_err(sparx5->dev, "No skb allocated\n");
> + return;
> + }
> + rxbuf = (u32 *)skb->data;
> +
> + /* Now, pull frame data */
> + while (!eof_flag) {
> + u32 val = spx5_rd(sparx5, QS_XTR_RD(grp));
> + u32 cmp = val;
> +
> + if (byte_swap)
> + cmp = ntohl((__force __be32)val);
> +
> + switch (cmp) {
> + case XTR_NOT_READY:
> + break;
> + case XTR_ABORT:
> + /* No accompanying data */
> + abort_flag = true;
> + eof_flag = true;
> + break;
> + case XTR_EOF_0:
> + case XTR_EOF_1:
> + case XTR_EOF_2:
> + case XTR_EOF_3:
> + /* This assumes STATUS_WORD_POS == 1, Status
> + * just after last data
> + */
> + byte_cnt -= (4 - XTR_VALID_BYTES(val));
> + eof_flag = true;
> + break;
> + case XTR_PRUNED:
> + /* But get the last 4 bytes as well */
> + eof_flag = true;
> + pruned_flag = true;
> + fallthrough;
> + case XTR_ESCAPE:
> + *rxbuf = spx5_rd(sparx5, QS_XTR_RD(grp));
> + byte_cnt += 4;
> + rxbuf++;
> + break;
> + default:
> + *rxbuf = val;
> + byte_cnt += 4;
> + rxbuf++;
> + }
> + }
> +
> + if (abort_flag || pruned_flag || !eof_flag) {
> + netdev_err(netdev, "Discarded frame: abort:%d pruned:%d eof:%d\n",
> + abort_flag, pruned_flag, eof_flag);
> + kfree_skb(skb);
> + return;
> + }
> +
> + if (!netif_oper_up(netdev)) {
> + netdev_err(netdev, "Discarded frame: Interface not up\n");
> + kfree_skb(skb);
> + return;
> + }
Why is it sending frames when it is not up?
> +static int sparx5_inject(struct sparx5 *sparx5,
> + u32 *ifh,
> + struct sk_buff *skb)
> +{
> + u32 val, w, count;
> + int grp = INJ_QUEUE;
> + u8 *buf;
> +
> + val = spx5_rd(sparx5, QS_INJ_STATUS);
> + if (!(QS_INJ_STATUS_FIFO_RDY_GET(val) & BIT(grp))) {
> + pr_err("Injection: Queue not ready: 0x%lx\n",
> + QS_INJ_STATUS_FIFO_RDY_GET(val));
> + return -1;
Always use -ESOMETHING.
> + }
> +
> + if (QS_INJ_STATUS_WMARK_REACHED_GET(val) & BIT(grp)) {
> + pr_err("Injection: Watermark reached: 0x%lx\n",
> + QS_INJ_STATUS_WMARK_REACHED_GET(val));
> + return -1;
> + }
> +
> + /* Indicate SOF */
> + spx5_wr(QS_INJ_CTRL_SOF_SET(1) |
> + QS_INJ_CTRL_GAP_SIZE_SET(1),
> + sparx5, QS_INJ_CTRL(grp));
> +
> + // Write the IFH to the chip.
> + for (w = 0; w < IFH_LEN; w++)
> + spx5_wr(ifh[w], sparx5, QS_INJ_WR(grp));
> +
> + /* Write words, round up */
> + count = ((skb->len + 3) / 4);
> + buf = skb->data;
> + for (w = 0; w < count; w++, buf += 4) {
> + val = get_unaligned((const u32 *)buf);
> + spx5_wr(val, sparx5, QS_INJ_WR(grp));
> + }
No DMA? What sort of performance do you get? Enough for the odd BPDU,
IGMP frame etc, but i guess you don't want any real bulk data to be
sent this way?
> +irqreturn_t sparx5_xtr_handler(int irq, void *_sparx5)
> +{
> + struct sparx5 *sparx5 = _sparx5;
> +
> + /* Check data in queue */
> + while (spx5_rd(sparx5, QS_XTR_DATA_PRESENT) & BIT(XTR_QUEUE))
> + sparx5_xtr_grp(sparx5, XTR_QUEUE, false);
> +
> + return IRQ_HANDLED;
> +}
Is there any sort of limit how many times this will loop? If somebody
is blasting 10Gbps at the CPU, will it ever get out of this loop?
Andrew
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2020-12-19 19:53 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-12-17 7:51 [RFC PATCH v2 0/8] Adding the Sparx5 Switch Driver Steen Hegelund
2020-12-17 7:51 ` [RFC PATCH v2 1/8] dt-bindings: net: sparx5: Add sparx5-switch bindings Steen Hegelund
2020-12-19 17:54 ` Andrew Lunn
2020-12-21 0:55 ` Florian Fainelli
2020-12-21 10:00 ` Steen Hegelund
2020-12-21 21:40 ` Rob Herring
2020-12-22 7:30 ` Steen Hegelund
2020-12-17 7:51 ` [RFC PATCH v2 3/8] net: sparx5: add hostmode with phylink support Steen Hegelund
2020-12-19 19:51 ` Andrew Lunn [this message]
2020-12-22 9:46 ` Steen Hegelund
2020-12-22 14:41 ` Andrew Lunn
2020-12-23 13:29 ` Steen Hegelund
2020-12-23 20:58 ` Alexandre Belloni
2020-12-23 21:05 ` Andrew Lunn
2020-12-17 7:51 ` [RFC PATCH v2 4/8] net: sparx5: add port module support Steen Hegelund
2020-12-20 23:35 ` Andrew Lunn
2020-12-22 14:55 ` Bjarni Jonasson
2020-12-22 15:08 ` Andrew Lunn
2020-12-17 7:51 ` [RFC PATCH v2 5/8] net: sparx5: add switching, vlan and mactable support Steen Hegelund
2020-12-21 0:25 ` Andrew Lunn
2020-12-23 13:54 ` Steen Hegelund
2020-12-17 7:51 ` [RFC PATCH v2 6/8] net: sparx5: add calendar bandwidth allocation support Steen Hegelund
2020-12-17 7:51 ` [RFC PATCH v2 7/8] net: sparx5: add ethtool configuration and statistics support Steen Hegelund
2020-12-19 23:31 ` Andrew Lunn
2020-12-17 7:51 ` [RFC PATCH v2 8/8] arm64: dts: sparx5: Add the Sparx5 switch node Steen Hegelund
2020-12-19 20:24 ` Andrew Lunn
2020-12-23 14:31 ` Steen Hegelund
2020-12-23 15:49 ` Andrew Lunn
[not found] ` <20201217075134.919699-3-steen.hegelund@microchip.com>
2020-12-19 19:11 ` [RFC PATCH v2 2/8] net: sparx5: add the basic sparx5 driver Andrew Lunn
2020-12-22 13:50 ` Steen Hegelund
2020-12-22 15:01 ` Andrew Lunn
2020-12-22 16:56 ` Alexandre Belloni
2020-12-23 9:03 ` Lars Povlsen
2020-12-23 8:52 ` Steen Hegelund
2020-12-21 0:58 ` [RFC PATCH v2 0/8] Adding the Sparx5 Switch Driver Florian Fainelli
2020-12-21 14:31 ` Steen Hegelund
2020-12-22 11:29 ` Lars Povlsen
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=20201219195133.GD3026679@lunn.ch \
--to=andrew@lunn.ch \
--cc=UNGLinuxDriver@microchip.com \
--cc=alexandre.belloni@bootlin.com \
--cc=arnd@arndb.de \
--cc=bjarni.jonasson@microchip.com \
--cc=davem@davemloft.net \
--cc=kuba@kernel.org \
--cc=lars.povlsen@microchip.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@armlinux.org.uk \
--cc=madalin.bucur@oss.nxp.com \
--cc=mark.einon@gmail.com \
--cc=masahiroy@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=steen.hegelund@microchip.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).