Re: [RFC net-next 1/3] net: marvell: prestera: Add Switchdev driver for Prestera family ASIC device 98DX325x (AC3x)

[Jiri Pirko <jiri@resnulli.us>]

Fri, Feb 28, 2020 at 10:44:53AM CET, vadym.kochan@plvision.eu wrote:
>Hi Jiri,
>
>On Fri, Feb 28, 2020 at 07:34:51AM +0100, Jiri Pirko wrote:
>> Thu, Feb 27, 2020 at 10:32:00PM CET, vadym.kochan@plvision.eu wrote:
>> >Hi Jiri,
>> >
>> >On Wed, Feb 26, 2020 at 04:54:23PM +0100, Jiri Pirko wrote:
>> >> Tue, Feb 25, 2020 at 05:30:54PM CET, 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.
>> >> >
>> >> >This driver implementation includes only L1 & basic L2 support.
>> >> >
>> >> >The core Prestera switching logic is implemented in prestera.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.
>> >> >
>> >> >The following Switchdev features are supported:
>> >> >
>> >> >    - VLAN-aware bridge offloading
>> >> >    - VLAN-unaware bridge offloading
>> >> >    - FDB offloading (learning, ageing)
>> >> >    - Switchport configuration
>> >> >
>> >> >Signed-off-by: Vadym Kochan <vadym.kochan@plvision.eu>
>> >> >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>
>> >> >---
>
>[SNIP]
>
>> >> >+#include <linux/kernel.h>
>> >> >+#include <linux/module.h>
>> >> >+#include <linux/list.h>
>> >> >+#include <linux/netdevice.h>
>> >> >+#include <linux/netdev_features.h>
>> >> >+#include <linux/etherdevice.h>
>> >> >+#include <linux/ethtool.h>
>> >> >+#include <linux/jiffies.h>
>> >> >+#include <net/switchdev.h>
>> >> >+
>> >> >+#include "prestera.h"
>> >> >+#include "prestera_hw.h"
>> >> >+#include "prestera_drv_ver.h"
>> >> >+
>> >> >+#define MVSW_PR_MTU_DEFAULT 1536
>> >> >+
>> >> >+#define PORT_STATS_CACHE_TIMEOUT_MS	(msecs_to_jiffies(1000))
>> >> >+#define PORT_STATS_CNT	(sizeof(struct mvsw_pr_port_stats) / sizeof(u64))
>> >> 
>> >> Keep the prefix for all defines withing the file. "PORT_STATS_CNT"
>> >> looks way to generic on the first look.
>> >> 
>> >> 
>> >> >+#define PORT_STATS_IDX(name) \
>> >> >+	(offsetof(struct mvsw_pr_port_stats, name) / sizeof(u64))
>> >> >+#define PORT_STATS_FIELD(name)	\
>> >> >+	[PORT_STATS_IDX(name)] = __stringify(name)
>> >> >+
>> >> >+static struct list_head switches_registered;
>> >> >+
>> >> >+static const char mvsw_driver_kind[] = "prestera_sw";
>> >> 
>> >> Please be consistent. Make your prefixes, name, filenames the same.
>> >> For example:
>> >> prestera_driver_kind[] = "prestera";
>> >> 
>> >> Applied to the whole code.
>> >> 
>> >So you suggested to use prestera_ as a prefix, I dont see a problem
>> >with that, but why not mvsw_pr_ ? So it has the vendor, device name parts
>> 
>> Because of "sw" in the name. You have the directory named "prestera",
>> the modules are named "prestera_*", for the consistency sake the
>> prefixes should be "prestera_". "mvsw_" looks totally unrelated.
>> 
>> 
>
>I understand. If possible I'd like to get rid of long prefix which is if
>to use prestera_xxx. I looked at mlxsw prefix format, and it looks for

mlxsw is a bad example for naming :) We did went along with existing
drivers mlx4 and mlx5. The device name was "SwitchX-2".
In your case, you have nice name of the device, just use it :)


>me that mvpr_ may be OK in this case ? Also it will make funcs/types

"prestera_" would be my first choice. I don't see why to mangle vendor
name into the prefix. Also, you have to count with a possibility that in
the future, this devices will no longer be "Marvell" (if sold). This
happens all the time :)



>name shorter which makes code read easier.
>
>[SNIP]
>
>> >
>> >Regards,
>> >Vadym Kochan
>
>I am sorry that this naming issue took more discussion than should, I
>just want to define it once an never change it, (it is a bit pain to
>rename the whole code with new naming convention :) ).

Sure.


>
>Regards,
>Vadym Kochan