All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andy Shevchenko <andy.shevchenko@gmail.com>
To: Vadym Kochan <vadym.kochan@plvision.eu>
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 19:02:47 +0300	[thread overview]
Message-ID: <CAHp75VcS4fEak3z0exODErs5FbDwf+Di1RJmf7JfMgnD8xgXOA@mail.gmail.com> (raw)
In-Reply-To: <20200731152201.GB10391@plvision.eu>

On Fri, Jul 31, 2020 at 6:22 PM Vadym Kochan <vadym.kochan@plvision.eu> wrote:
> 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:

...

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

I don't know, you are!
And I think you meant Co-developer's

...

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

Yes.

...

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

We have 100, but okay.

...

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

Then do it a switch-case. I can see that other reviewers/contributors
may stumble over this.

...

> > > +       /* 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.

But 255 itself is some kind of error value? Perhaps it deserves a definition.

...

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

Yes, and how is it different from here? (consider
fwnode_get_mac_address() if it suits better).

...

> > > +       new_skb = alloc_skb(len, GFP_ATOMIC | GFP_DMA);
> >
> > Atomic? Why?
> >
> TX path might be called from net_tx_action which is softirq.

Okay, but GFP_DMA is quite a limitation to the memory region. Can't  be 32-bit?

...

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

Usually when reviewers tell you about magic it assumes magic numbers
whose meaning is not clear.
(Requires either to be defined or commented)

-- 
With Best Regards,
Andy Shevchenko

  reply	other threads:[~2020-07-31 16:03 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
2020-07-31 16:02       ` Andy Shevchenko [this message]
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=CAHp75VcS4fEak3z0exODErs5FbDwf+Di1RJmf7JfMgnD8xgXOA@mail.gmail.com \
    --to=andy.shevchenko@gmail.com \
    --cc=andrew@lunn.ch \
    --cc=andrii.savka@plvision.eu \
    --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=vadym.kochan@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.