All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vadym Kochan <vadym.kochan@plvision.eu>
To: Andy Shevchenko <andy.shevchenko@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>,
	netdev <netdev@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Mickey Rachamim <mickeyr@marvell.com>
Subject: Re: [net-next v4 1/6] net: marvell: prestera: Add driver for Prestera family ASIC devices
Date: Fri, 31 Jul 2020 18:22:01 +0300	[thread overview]
Message-ID: <20200731152201.GB10391@plvision.eu> (raw)
In-Reply-To: <CAHp75Ve-MyFg5QqHjywGk6X+v_F77HkRBuQsJ0Cx3WLJ5ZV43w@mail.gmail.com>

Hi Andy,

On Mon, Jul 27, 2020 at 03:59:13PM +0300, Andy Shevchenko wrote:
> On Mon, Jul 27, 2020 at 3:23 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.
> 
> ...
> 
> > Signed-off-by: Andrii Savka <andrii.savka@plvision.eu>
> > Signed-off-by: Oleksandr Mazur <oleksandr.mazur@plvision.eu>
> > Signed-off-by: Serhiy Boiko <serhiy.boiko@plvision.eu>
> > Signed-off-by: Serhiy Pshyk <serhiy.pshyk@plvision.eu>
> > Signed-off-by: Taras Chornyi <taras.chornyi@plvision.eu>
> > Signed-off-by: Volodymyr Mytnyk <volodymyr.mytnyk@plvision.eu>
> > Signed-off-by: Vadym Kochan <vadym.kochan@plvision.eu>
> 
> This needs more work. You have to really understand the role of each
> person in the above list.
> I highly recommend (re-)read sections 11-13 of Submitting Patches.
> 
At least looks like I need to add these persons as Co-author's.

> ...
> 
> > +/* SPDX-License-Identifier: BSD-3-Clause OR GPL-2.0
> 
> The idea of SPDX is to have it as a separate (standalone) comment.
OK, thanks.

> 
> ...
> 
> > +enum prestera_event_type {
> > +       PRESTERA_EVENT_TYPE_UNSPEC,
> > +
> > +       PRESTERA_EVENT_TYPE_PORT,
> > +       PRESTERA_EVENT_TYPE_RXTX,
> > +
> > +       PRESTERA_EVENT_TYPE_MAX,
> 
> Commas in the terminators are not good.
> 
OK

> > +};
> 
> ...
> 
> > +#include "prestera_dsa.h"
> 
> The idea that you include more generic headers earlier than more custom ones.
> 
Thanks

> > +#include <linux/string.h>
> > +#include <linux/bitops.h>
> > +#include <linux/bitfield.h>
> > +#include <linux/errno.h>
> 
> Perhaps ordered?
> 
alphabetical ?

> ...
> 
> > +/* TrgDev[4:0] = {Word0[28:24]} */
> 
> > + * SrcPort/TrgPort[7:0] = {Word2[20], Word1[11:10], Word0[23:19]}
> 
> > +/* bits 13:15 -- UP */
> 
> > +/* bits 0:11 -- VID */
> 
> These are examples of useless comments.
> 
OK, removed.

> ...
> 
> > +       dsa->vlan.is_tagged = (bool)FIELD_GET(PRESTERA_W0_IS_TAGGED, words[0]);
> > +       dsa->vlan.cfi_bit = (u8)FIELD_GET(PRESTERA_W1_CFI_BIT, words[1]);
> > +       dsa->vlan.vpt = (u8)FIELD_GET(PRESTERA_W0_VPT, words[0]);
> > +       dsa->vlan.vid = (u16)FIELD_GET(PRESTERA_W0_VID, words[0]);
> 
> Do you need those castings?
> 
Looks like not, because the struct fields are same type as cast'ed ones.

> ...
> 
> > +       struct prestera_msg_event_port *hw_evt;
> > +
> > +       hw_evt = (struct prestera_msg_event_port *)msg;
> 
> Can be one line I suppose.
> 
Yes, but I am trying to avoid line-breaking because of 80 chars
limitation.

> ...
> 
> > +       if (evt->id == PRESTERA_PORT_EVENT_STATE_CHANGED)
> > +               evt->port_evt.data.oper_state = hw_evt->param.oper_state;
> > +       else
> > +               return -EINVAL;
> > +
> > +       return 0;
> 
> Perhaps traditional pattern, i.e.
> 
>   if (...)
>     return -EINVAL;
>   ...
>   return 0;
> 
I am not sure if it is applicable here, because the error state here
is if 'evt->id' did not matched after all checks. Actually this is
simply a 'switch', but I use 'if' to have shorter code.

> ...
> 
> > +       err = fw_event_parsers[msg->type].func(buf, &evt);
> > +       if (!err)
> > +               eh.func(sw, &evt, eh.arg);
> 
> Ditto.
Makes sense.

> 
> > +       return err;
> 
> ...
> 
> > +       memcpy(&req.param.mac, mac, sizeof(req.param.mac));
> 
> Consider to use ether_addr_*() APIs instead of open-coded mem*() ones.
> 
> ...
> 
> > +#define PRESTERA_MTU_DEFAULT 1536
> 
> Don't we have global default for this?
> 
> ...
> 
> > +#define PRESTERA_STATS_DELAY_MS        msecs_to_jiffies(1000)
> 
> It's not _MS.
> 
> ...
> 
> > +       if (!is_up)
> > +               netif_stop_queue(dev);
> > +
> > +       err = prestera_hw_port_state_set(port, is_up);
> > +
> > +       if (is_up && !err)
> > +               netif_start_queue(dev);
> 
> Much better if will look lke
> 
>   if (is_up) {
>   ...
>   err  = ...(..., true);
>   if (err)
>     return err;
>   ...
>   } else {
>     return prestera_*(..., false);
>   }
>   return 0;
> 
> > +       return err;
> 
> ...
> 
> > +       /* Only 0xFF mac addrs are supported */
> > +       if (port->fp_id >= 0xFF)
> > +               goto err_port_init;
> 
> You meant 255, right?
> Otherwise you have to mentioned is it byte limitation or what?
> 
> ...
Yes, 255 is a limitation because of max byte value.

> 
> > +static int prestera_switch_set_base_mac_addr(struct prestera_switch *sw)
> > +{
> > +       struct device_node *base_mac_np;
> > +       struct device_node *np;
> 
> > +       np = of_find_compatible_node(NULL, NULL, "marvell,prestera");
> > +       if (np) {
> > +               base_mac_np = of_parse_phandle(np, "base-mac-provider", 0);
> > +               if (base_mac_np) {
> > +                       const char *base_mac;
> > +
> > +                       base_mac = of_get_mac_address(base_mac_np);
> > +                       of_node_put(base_mac_np);
> > +                       if (!IS_ERR(base_mac))
> > +                               ether_addr_copy(sw->base_mac, base_mac);
> > +               }
> > +       }
> > +
> > +       if (!is_valid_ether_addr(sw->base_mac)) {
> > +               eth_random_addr(sw->base_mac);
> > +               dev_info(sw->dev->dev, "using random base mac address\n");
> > +       }
> 
> Isn't it device_get_mac_address() reimplementation?
> 
device_get_mac_address() just tries to get mac via fwnode.

> > +
> > +       return prestera_hw_switch_mac_set(sw, sw->base_mac);
> > +}
> 
> ...
> 
> > +       err = prestera_switch_init(sw);
> > +       if (err) {
> > +               kfree(sw);
> > +               return err;
> > +       }
> > +
> > +       return 0;
> 
> if (err)
>  kfree(...);
> return err;
> 
> Also, check reference counting.
> 
> ...
> 
> > +#define PRESTERA_SDMA_RX_DESC_PKT_LEN(desc) \
> 
> > +       ((le32_to_cpu((desc)->word2) >> 16) & 0x3FFF)
> 
> Why not GENMASK() ?
Yes, GENMASK is right way to go, thanks.

> 
> ...
> 
> > +       if (dma + sizeof(struct prestera_sdma_desc) > sdma->dma_mask) {
> > +               dev_err(dma_dev, "failed to alloc desc\n");
> > +               dma_pool_free(sdma->desc_pool, desc, dma);
> 
> Better first undo something *then* print a message.
> 
> > +               return -ENOMEM;
> > +       }
> 
> ...
> 
> > +static void prestera_sdma_rx_desc_set_len(struct prestera_sdma_desc *desc,
> > +                                         size_t val)
> > +{
> > +       u32 word = le32_to_cpu(desc->word2);
> > +
> > +       word = (word & ~GENMASK(15, 0)) | val;
> 
> Shouldn't you do traditional pattern?
> 
> word = (word & ~mask) | (val & mask);
Looks like this is safer form.

> 
> > +       desc->word2 = cpu_to_le32(word);
> > +}
> 
> ...
> 
> > +       dma = dma_map_single(dev, skb->data, skb->len, DMA_FROM_DEVICE);
> 
> > +
> 
> Redundant blank line.
> 
> > +       if (dma_mapping_error(dev, dma))
> > +               goto err_dma_map;
> 
> ...
> 
> > +               pr_warn_ratelimited("received pkt for non-existent port(%u, %u)\n",
> > +                                   dev_id, hw_port);
> 
> netdev_warn_ratelimited() ? Or something closer to that?
> 
> ...
> 
> > +       qmask = GENMASK(qnum - 1, 0);
> 
> BIT(qnum) - 1 will produce much better code I suppose.
> 
> ...
> 
> > +       if (pkts_done < budget && napi_complete_done(napi, pkts_done))
> > +               prestera_write(sdma->sw, PRESTERA_SDMA_RX_INTR_MASK_REG,
> > +                              0xff << 2);
> 
> GENMASK() ?
> 
> ...
> 
> > +       word = (word & ~GENMASK(30, 16)) | ((len + ETH_FCS_LEN) << 16);
> 
> Consider traditional pattern.
> 
> ...
> 
> > +       word |= PRESTERA_SDMA_TX_DESC_DMA_OWN << 31;
> 
> I hope that was defined with U. Otherwise it's UB.
> 
> ...
> 
> > +       new_skb = alloc_skb(len, GFP_ATOMIC | GFP_DMA);
> 
> Atomic? Why?
> 
TX path might be called from net_tx_action which is softirq.

> ...
> 
> > +static int prestera_sdma_tx_wait(struct prestera_sdma *sdma,
> > +                                struct prestera_tx_ring *tx_ring)
> > +{
> 
> > +       int tx_retry_num = 10 * tx_ring->max_burst;
> 
> Magic!
You mean the code is magic ? Yes, I am trying to relax the
calling of SDMA engine.

> 
> > +       while (--tx_retry_num) {
> > +               if (prestera_sdma_is_ready(sdma))
> > +                       return 0;
> > +
> > +               udelay(1);
> > +       }
> 
> unsigned int counter = ...;
> 
> do { } while (--counter);
> 
> looks better.
> 
> Also, why udelay()? Is it atomic context?
TX path might be called from net_tx_action which is softirq.

> 
> > +       return -EBUSY;
> > +}
> 
> ...
> 
> > +       if (!tx_ring->burst--) {
> 
> Don't do like this. It makes code harder to understand.
> 
>   if (tx_ring->...) {
>     ...->burst--;
>   } else {
>     ...
>   }
I will try.

> 
> > +               tx_ring->burst = tx_ring->max_burst;
> > +
> > +               err = prestera_sdma_tx_wait(sdma, tx_ring);
> > +               if (err)
> > +                       goto drop_skb_unmap;
> > +       }
> 
> -- 
> With Best Regards,
> Andy Shevchenko

  reply	other threads:[~2020-07-31 15:22 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-27 12:22 [net-next v4 0/6] net: marvell: prestera: Add Switchdev driver for Prestera family ASIC device 98DX326x (AC3x) Vadym Kochan
2020-07-27 12:22 ` [net-next v4 1/6] net: marvell: prestera: Add driver for Prestera family ASIC devices Vadym Kochan
2020-07-27 12:59   ` Andy Shevchenko
2020-07-31 15:22     ` Vadym Kochan [this message]
2020-07-31 16:02       ` Andy Shevchenko
2020-07-31 20:55         ` Vadym Kochan
2020-07-27 19:32   ` David Miller
2020-08-13  8:03   ` Jonathan McDowell
2020-08-14  8:20     ` Vadym Kochan
2020-08-14 12:05       ` Jonathan McDowell
2020-08-14 12:27         ` Vadym Kochan
2020-08-14 13:18           ` Andrew Lunn
2020-08-20  8:31             ` Vadym Kochan
2020-08-20 10:00               ` [EXT] " Mickey Rachamim
2020-08-22 16:34                 ` Andrew Lunn
2020-08-25 11:36                   ` Vadym Kochan
2020-07-27 12:22 ` [net-next v4 2/6] net: marvell: prestera: Add PCI interface support Vadym Kochan
2020-07-27 12:32   ` Jiri Pirko
2020-07-27 12:35     ` Vadym Kochan
2020-07-27 13:02       ` Jiri Pirko
2020-07-27 13:29   ` Andy Shevchenko
2020-07-27 14:11     ` Jiri Pirko
2020-07-27 15:33       ` Andy Shevchenko
2020-07-27 12:22 ` [net-next v4 3/6] net: marvell: prestera: Add basic devlink support Vadym Kochan
2020-07-27 13:07   ` Andy Shevchenko
2020-07-28 12:30     ` Vadym Kochan
2020-07-28 13:24       ` Andy Shevchenko
2020-07-27 12:22 ` [net-next v4 4/6] net: marvell: prestera: Add ethtool interface support Vadym Kochan
2020-07-27 13:17   ` Andy Shevchenko
2020-07-27 12:22 ` [net-next v4 5/6] net: marvell: prestera: Add Switchdev driver implementation Vadym Kochan
2020-07-27 12:22 ` [net-next v4 6/6] dt-bindings: marvell,prestera: Add description for device-tree bindings 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=20200731152201.GB10391@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 \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.