Date:   Thu, 3 Sep 2020 17:22:24 +0200
From:   Willem de Bruijn <willemdebruijn.kernel@...il.com>
To:     Vadym Kochan <vadym.kochan@...ision.eu>
Cc:     "David S. Miller" <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>,
        Jiri Pirko <jiri@...lanox.com>,
        Ido Schimmel <idosch@...lanox.com>,
        Andrew Lunn <andrew@...n.ch>,
        Oleksandr Mazur <oleksandr.mazur@...ision.eu>,
        Serhiy Boiko <serhiy.boiko@...ision.eu>,
        Serhiy Pshyk <serhiy.pshyk@...ision.eu>,
        Volodymyr Mytnyk <volodymyr.mytnyk@...ision.eu>,
        Taras Chornyi <taras.chornyi@...ision.eu>,
        Andrii Savka <andrii.savka@...ision.eu>,
        Network Development <netdev@...r.kernel.org>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        Andy Shevchenko <andy.shevchenko@...il.com>,
        Mickey Rachamim <mickeyr@...vell.com>
Subject: Re: [PATCH net v6 1/6] net: marvell: prestera: Add driver for
 Prestera family ASIC devices

On Wed, Sep 2, 2020 at 5:37 PM Vadym Kochan <vadym.kochan@...ision.eu> wrote:
>
> Marvell Prestera 98DX326x integrates up to 24 ports of 1GbE with 8
> ports of 10GbE uplinks or 2 ports of 40Gbps stacking for a largely
> wireless SMB deployment.
>
> The current implementation supports only boards designed for the Marvell
> Switchdev solution and requires special firmware.
>
> The core Prestera switching logic is implemented in prestera_main.c,
> there is an intermediate hw layer between core logic and firmware. It is
> implemented in prestera_hw.c, the purpose of it is to encapsulate hw
> related logic, in future there is a plan to support more devices with
> different HW related configurations.
>
> This patch contains only basic switch initialization and RX/TX support
> over SDMA mechanism.
>
> Currently supported devices have DMA access range <= 32bit and require
> ZONE_DMA to be enabled, for such cases SDMA driver checks if the skb
> allocated in proper range supported by the Prestera device.
>
> Also meanwhile there is no TX interrupt support in current firmware
> version so recycling work is scheduled on each xmit.
>
> Port's mac address is generated from the switch base mac which may be
> provided via device-tree (static one or as nvme cell), or randomly
> generated.
>
> Co-developed-by: Andrii Savka <andrii.savka@...ision.eu>
> Signed-off-by: Andrii Savka <andrii.savka@...ision.eu>
> Co-developed-by: Oleksandr Mazur <oleksandr.mazur@...ision.eu>
> Signed-off-by: Oleksandr Mazur <oleksandr.mazur@...ision.eu>
> Co-developed-by: Serhiy Boiko <serhiy.boiko@...ision.eu>
> Signed-off-by: Serhiy Boiko <serhiy.boiko@...ision.eu>
> Co-developed-by: Serhiy Pshyk <serhiy.pshyk@...ision.eu>
> Signed-off-by: Serhiy Pshyk <serhiy.pshyk@...ision.eu>
> Co-developed-by: Taras Chornyi <taras.chornyi@...ision.eu>
> Signed-off-by: Taras Chornyi <taras.chornyi@...ision.eu>
> Co-developed-by: Volodymyr Mytnyk <volodymyr.mytnyk@...ision.eu>
> Signed-off-by: Volodymyr Mytnyk <volodymyr.mytnyk@...ision.eu>
> Signed-off-by: Vadym Kochan <vadym.kochan@...ision.eu>

> +int prestera_hw_port_cap_get(const struct prestera_port *port,
> +                            struct prestera_port_caps *caps)
> +{
> +       struct prestera_msg_port_attr_resp resp;
> +       struct prestera_msg_port_attr_req req = {
> +               .attr = PRESTERA_CMD_PORT_ATTR_CAPABILITY,
> +               .port = port->hw_id,
> +               .dev = port->dev_id
> +       };
> +       int err;
> +
> +       err = prestera_cmd_ret(port->sw, PRESTERA_CMD_TYPE_PORT_ATTR_GET,
> +                              &req.cmd, sizeof(req), &resp.ret, sizeof(resp));

Here and elsewhere, why use a pointer to the first field in the struct
vs the struct itself?

They are the same address, so it's fine, just a bit confusing as the
size argument makes clear that the entire struct is to be copied.

> +static int prestera_is_valid_mac_addr(struct prestera_port *port, u8 *addr)
> +{
> +       if (!is_valid_ether_addr(addr))
> +               return -EADDRNOTAVAIL;
> +
> +       if (memcmp(port->sw->base_mac, addr, ETH_ALEN - 1))

Why ETH_ALEN - 1?

> +               return -EINVAL;
> +
> +       return 0;
> +}
> +
> +static int prestera_port_set_mac_address(struct net_device *dev, void *p)
> +{
> +       struct prestera_port *port = netdev_priv(dev);
> +       struct sockaddr *addr = p;
> +       int err;
> +
> +       err = prestera_is_valid_mac_addr(port, addr->sa_data);
> +       if (err)
> +               return err;
> +
> +       err = prestera_hw_port_mac_set(port, addr->sa_data);
> +       if (err)
> +               return err;
> +
> +       memcpy(dev->dev_addr, addr->sa_data, dev->addr_len);

Is addr_len ever not ETH_ALEN for this device?

> +static int prestera_sdma_buf_init(struct prestera_sdma *sdma,
> +                                 struct prestera_sdma_buf *buf)
> +{
> +       struct device *dma_dev = sdma->sw->dev->dev;
> +       struct prestera_sdma_desc *desc;
> +       dma_addr_t dma;
> +
> +       desc = dma_pool_alloc(sdma->desc_pool, GFP_DMA | GFP_KERNEL, &dma);
> +       if (!desc)
> +               return -ENOMEM;
> +
> +       if (dma + sizeof(struct prestera_sdma_desc) > sdma->dma_mask) {

Can this happen? The DMA API should take care of dev->dma_mask constraints.

> +               dma_pool_free(sdma->desc_pool, desc, dma);
> +               dev_err(dma_dev, "failed to alloc desc\n");
> +               return -ENOMEM;
> +       }

> +static int prestera_sdma_rx_skb_alloc(struct prestera_sdma *sdma,
> +                                     struct prestera_sdma_buf *buf)
> +{
> +       struct device *dev = sdma->sw->dev->dev;
> +       struct sk_buff *skb;
> +       dma_addr_t dma;
> +
> +       skb = alloc_skb(PRESTERA_SDMA_BUFF_SIZE_MAX, GFP_DMA | GFP_ATOMIC);
> +       if (!skb)
> +               return -ENOMEM;
> +
> +       dma = dma_map_single(dev, skb->data, skb->len, DMA_FROM_DEVICE);
> +       if (dma_mapping_error(dev, dma))
> +               goto err_dma_map;
> +       if (dma + skb->len > sdma->dma_mask)
> +               goto err_dma_range;

Same here

Powered by blists - more mailing lists