lkml.org 
[lkml]   [2020]   [Sep]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: [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@plvision.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@plvision.eu>
    > Signed-off-by: Andrii Savka <andrii.savka@plvision.eu>
    > Co-developed-by: Oleksandr Mazur <oleksandr.mazur@plvision.eu>
    > Signed-off-by: Oleksandr Mazur <oleksandr.mazur@plvision.eu>
    > Co-developed-by: Serhiy Boiko <serhiy.boiko@plvision.eu>
    > Signed-off-by: Serhiy Boiko <serhiy.boiko@plvision.eu>
    > Co-developed-by: Serhiy Pshyk <serhiy.pshyk@plvision.eu>
    > Signed-off-by: Serhiy Pshyk <serhiy.pshyk@plvision.eu>
    > Co-developed-by: Taras Chornyi <taras.chornyi@plvision.eu>
    > Signed-off-by: Taras Chornyi <taras.chornyi@plvision.eu>
    > Co-developed-by: Volodymyr Mytnyk <volodymyr.mytnyk@plvision.eu>
    > Signed-off-by: Volodymyr Mytnyk <volodymyr.mytnyk@plvision.eu>
    > Signed-off-by: Vadym Kochan <vadym.kochan@plvision.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

    \
     
     \ /
      Last update: 2020-09-03 17:23    [W:4.387 / U:0.012 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site