lkml.org 
[lkml]   [2020]   [Sep]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH net v6 1/6] net: marvell: prestera: Add driver for Prestera family ASIC devices
    Hi Willem,

    On Thu, Sep 03, 2020 at 05:22:24PM +0200, Willem de Bruijn wrote:
    > 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.
    >
    Well, initially it was a macro to simplify passing the different kind of
    request structure. But after review I changed it to a function. The
    struct prestera_msg_cmd is a common for all of the fw requests which
    have to include it at the beginning. Eventually __prestera_cmd_ret() is
    called to pass request buffer to the fw and struct prestera_msg_cmd is
    used to check the response from fw. I can use 'void *' and typecast it
    to struct prestera_msg_cmd but I'd like to keep type safety.

    > > +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?
    >
    This is the restriction of the port mac address, it must have base mac
    address part at first 5 bytes.

    > > + 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?

    I will fix it to use ether_addr_copy.

    >
    > > +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.
    >
    I will fix it, thanks.

    > > + 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

    OK.

    Regards,
    Vadym Kochan

    \
     
     \ /
      Last update: 2020-09-04 11:33    [W:4.269 / U:0.652 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site