From: Vadym Kochan <vadym.kochan@plvision.eu>
To: Willem de Bruijn <willemdebruijn.kernel@gmail.com>
Cc: "David S. Miller" <davem@davemloft.net>,
Jakub Kicinski <kuba@kernel.org>, Jiri Pirko <jiri@mellanox.com>,
Ido Schimmel <idosch@mellanox.com>, Andrew Lunn <andrew@lunn.ch>,
Oleksandr Mazur <oleksandr.mazur@plvision.eu>,
Serhiy Boiko <serhiy.boiko@plvision.eu>,
Serhiy Pshyk <serhiy.pshyk@plvision.eu>,
Volodymyr Mytnyk <volodymyr.mytnyk@plvision.eu>,
Taras Chornyi <taras.chornyi@plvision.eu>,
Andrii Savka <andrii.savka@plvision.eu>,
Network Development <netdev@vger.kernel.org>,
linux-kernel <linux-kernel@vger.kernel.org>,
Andy Shevchenko <andy.shevchenko@gmail.com>,
Mickey Rachamim <mickeyr@marvell.com>
Subject: Re: [PATCH net v6 1/6] net: marvell: prestera: Add driver for Prestera family ASIC devices
Date: Fri, 4 Sep 2020 12:32:52 +0300 [thread overview]
Message-ID: <20200904093252.GA10654@plvision.eu> (raw)
In-Reply-To: <CA+FuTSfMRhEZ5c2CWaN_F3ASDgvV7eQ4q6zVuY-FvgLqsqYecw@mail.gmail.com>
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
next prev parent reply other threads:[~2020-09-04 9:33 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-02 15:04 [PATCH net v6 0/6] net: marvell: prestera: Add Switchdev driver for Prestera family ASIC device 98DX3255 (AC3x) Vadym Kochan
2020-09-02 15:04 ` [PATCH net v6 1/6] net: marvell: prestera: Add driver for Prestera family ASIC devices Vadym Kochan
2020-09-03 15:22 ` Willem de Bruijn
2020-09-03 15:35 ` Andy Shevchenko
2020-09-04 9:34 ` Vadym Kochan
2020-09-04 9:32 ` Vadym Kochan [this message]
2020-09-04 13:32 ` Andrew Lunn
2020-09-04 15:54 ` Vadym Kochan
2020-09-02 15:04 ` [PATCH net v6 2/6] net: marvell: prestera: Add PCI interface support Vadym Kochan
2020-09-02 15:04 ` [PATCH net v6 3/6] net: marvell: prestera: Add basic devlink support Vadym Kochan
2020-09-02 15:04 ` [PATCH net v6 4/6] net: marvell: prestera: Add ethtool interface support Vadym Kochan
2020-09-02 15:04 ` [PATCH net v6 5/6] net: marvell: prestera: Add Switchdev driver implementation Vadym Kochan
2020-09-03 17:18 ` Willem de Bruijn
2020-09-04 9:34 ` Vadym Kochan
2020-09-02 15:04 ` [PATCH net v6 6/6] dt-bindings: marvell,prestera: Add description for device-tree bindings Vadym Kochan
2020-09-02 20:57 ` [PATCH net v6 0/6] net: marvell: prestera: Add Switchdev driver for Prestera family ASIC device 98DX3255 (AC3x) Vadym Kochan
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=20200904093252.GA10654@plvision.eu \
--to=vadym.kochan@plvision.eu \
--cc=andrew@lunn.ch \
--cc=andrii.savka@plvision.eu \
--cc=andy.shevchenko@gmail.com \
--cc=davem@davemloft.net \
--cc=idosch@mellanox.com \
--cc=jiri@mellanox.com \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mickeyr@marvell.com \
--cc=netdev@vger.kernel.org \
--cc=oleksandr.mazur@plvision.eu \
--cc=serhiy.boiko@plvision.eu \
--cc=serhiy.pshyk@plvision.eu \
--cc=taras.chornyi@plvision.eu \
--cc=volodymyr.mytnyk@plvision.eu \
--cc=willemdebruijn.kernel@gmail.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).