Message ID | 20201124120330.32445-1-l.stelmach@samsung.com |
---|---|
Headers | show |
Series | AX88796C SPI Ethernet Adapter | expand |
On Tue, Nov 24, 2020 at 01:03:30PM +0100, Łukasz Stelmach wrote: > ASIX AX88796[1] is a versatile ethernet adapter chip, that can be > connected to a CPU with a 8/16-bit bus or with an SPI. This driver > supports SPI connection. > > The driver has been ported from the vendor kernel for ARTIK5[2] > boards. Several changes were made to adapt it to the current kernel > which include: > > + updated DT configuration, > + clock configuration moved to DT, > + new timer, ethtool and gpio APIs, > + dev_* instead of pr_* and custom printk() wrappers, > + removed awkward vendor power managemtn. > + introduced ethtool tunable to control SPI compression > > [1] https://www.asix.com.tw/products.php?op=pItemdetail&PItemID=104;65;86&PLine=65 > [2] https://git.tizen.org/cgit/profile/common/platform/kernel/linux-3.10-artik/ > > The other ax88796 driver is for NE2000 compatible AX88796L chip. These > chips are not compatible. Hence, two separate drivers are required. > > Signed-off-by: Łukasz Stelmach <l.stelmach@samsung.com> > --- > MAINTAINERS | 6 + > drivers/net/ethernet/Kconfig | 1 + > drivers/net/ethernet/Makefile | 1 + > drivers/net/ethernet/asix/Kconfig | 35 + > drivers/net/ethernet/asix/Makefile | 6 + > drivers/net/ethernet/asix/ax88796c_ioctl.c | 221 ++++ > drivers/net/ethernet/asix/ax88796c_ioctl.h | 26 + > drivers/net/ethernet/asix/ax88796c_main.c | 1132 ++++++++++++++++++++ > drivers/net/ethernet/asix/ax88796c_main.h | 561 ++++++++++ > drivers/net/ethernet/asix/ax88796c_spi.c | 112 ++ > drivers/net/ethernet/asix/ax88796c_spi.h | 69 ++ > include/uapi/linux/ethtool.h | 1 + > net/ethtool/common.c | 1 + > 13 files changed, 2172 insertions(+) > create mode 100644 drivers/net/ethernet/asix/Kconfig > create mode 100644 drivers/net/ethernet/asix/Makefile > create mode 100644 drivers/net/ethernet/asix/ax88796c_ioctl.c > create mode 100644 drivers/net/ethernet/asix/ax88796c_ioctl.h > create mode 100644 drivers/net/ethernet/asix/ax88796c_main.c > create mode 100644 drivers/net/ethernet/asix/ax88796c_main.h > create mode 100644 drivers/net/ethernet/asix/ax88796c_spi.c > create mode 100644 drivers/net/ethernet/asix/ax88796c_spi.h > > diff --git a/MAINTAINERS b/MAINTAINERS > index 14b8ec0bb58b..930dc859d4f7 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -2812,6 +2812,12 @@ S: Maintained > F: Documentation/hwmon/asc7621.rst > F: drivers/hwmon/asc7621.c > > +ASIX AX88796C SPI ETHERNET ADAPTER > +M: Łukasz Stelmach <l.stelmach@samsung.com> > +S: Maintained > +F: Documentation/devicetree/bindings/net/asix,ax99706c-spi.yaml Wrong file name. Best regards, Krzysztof > +F: drivers/net/ethernet/asix/ax88796c_* > +
On Tue, 24 Nov 2020 13:03:30 +0100 Łukasz Stelmach wrote: > +static int > +ax88796c_start_xmit(struct sk_buff *skb, struct net_device *ndev) > +{ > + struct ax88796c_device *ax_local = to_ax88796c_device(ndev); > + > + skb_queue_tail(&ax_local->tx_wait_q, skb); > + if (skb_queue_len(&ax_local->tx_wait_q) > TX_QUEUE_HIGH_WATER) { > + netif_err(ax_local, tx_queued, ndev, > + "Too many TX packets in queue %d\n", > + skb_queue_len(&ax_local->tx_wait_q)); This will probably happen under heavy traffic. No need to print errors, it's normal to back pressure. > + netif_stop_queue(ndev); > + } > + > + set_bit(EVENT_TX, &ax_local->flags); > + schedule_work(&ax_local->ax_work); > + > + return NETDEV_TX_OK; > +} > + > +static void > +ax88796c_skb_return(struct ax88796c_device *ax_local, struct sk_buff *skb, > + struct rx_header *rxhdr) > +{ > + struct net_device *ndev = ax_local->ndev; > + int status; > + > + do { > + if (!(ndev->features & NETIF_F_RXCSUM)) > + break; > + > + /* checksum error bit is set */ > + if ((rxhdr->flags & RX_HDR3_L3_ERR) || > + (rxhdr->flags & RX_HDR3_L4_ERR)) > + break; > + > + /* Other types may be indicated by more than one bit. */ > + if ((rxhdr->flags & RX_HDR3_L4_TYPE_TCP) || > + (rxhdr->flags & RX_HDR3_L4_TYPE_UDP)) > + skb->ip_summed = CHECKSUM_UNNECESSARY; > + } while (0); > + > + ax_local->stats.rx_packets++; > + ax_local->stats.rx_bytes += skb->len; > + skb->dev = ndev; > + > + skb->truesize = skb->len + sizeof(struct sk_buff); > + skb->protocol = eth_type_trans(skb, ax_local->ndev); > + > + netif_info(ax_local, rx_status, ndev, "< rx, len %zu, type 0x%x\n", > + skb->len + sizeof(struct ethhdr), skb->protocol); > + > + status = netif_rx(skb); If I'm reading things right this is in process context, so netif_rx_ni() > + if (status != NET_RX_SUCCESS) > + netif_info(ax_local, rx_err, ndev, > + "netif_rx status %d\n", status); Again, it's inadvisable to put per packet prints without any rate limiting in the data path.
On Wed, 02 Dec 2020 11:46:28 +0100 Lukasz Stelmach wrote: > >> + status = netif_rx(skb); > > > > If I'm reading things right this is in process context, so netif_rx_ni() > > > > Is it? The stack looks as follows > > ax88796c_skb_return() > ax88796c_rx_fixup() > ax88796c_receive() > ax88796c_process_isr() > ax88796c_work() > > and ax88796c_work() is a scheduled in the system_wq. Are you asking if work queue gets run in process context? It does. > >> + if (status != NET_RX_SUCCESS) > >> + netif_info(ax_local, rx_err, ndev, > >> + "netif_rx status %d\n", status); > > > > Again, it's inadvisable to put per packet prints without any rate > > limiting in the data path. > > Even if limmited by the msglvl flag, which is off by default? I'd err on the side of caution, but up to you.
It was <2020-12-02 śro 09:18>, when Jakub Kicinski wrote: > On Wed, 02 Dec 2020 11:46:28 +0100 Lukasz Stelmach wrote: >> >> + status = netif_rx(skb); >> > >> > If I'm reading things right this is in process context, so netif_rx_ni() >> > >> >> Is it? The stack looks as follows >> >> ax88796c_skb_return() >> ax88796c_rx_fixup() >> ax88796c_receive() >> ax88796c_process_isr() >> ax88796c_work() >> >> and ax88796c_work() is a scheduled in the system_wq. > > Are you asking if work queue gets run in process context? It does. > Thanks. Changed. >> >> + if (status != NET_RX_SUCCESS) >> >> + netif_info(ax_local, rx_err, ndev, >> >> + "netif_rx status %d\n", status); >> > >> > Again, it's inadvisable to put per packet prints without any rate >> > limiting in the data path. >> >> Even if limmited by the msglvl flag, which is off by default? > > I'd err on the side of caution, but up to you. > It isn't very common, but a few drivers do this. Thank you.