| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <20220912172109.ezilo6su5w6dihrk@skbuf>
Date: Mon, 12 Sep 2022 17:21:10 +0000
From: Vladimir Oltean <vladimir.oltean@....com>
To: Colin Foster <colin.foster@...advantage.com>
CC: "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Russell King <linux@...linux.org.uk>,
Paolo Abeni <pabeni@...hat.com>,
Jakub Kicinski <kuba@...nel.org>,
Eric Dumazet <edumazet@...gle.com>,
"David S. Miller" <davem@...emloft.net>,
Florian Fainelli <f.fainelli@...il.com>,
Vivien Didelot <vivien.didelot@...il.com>,
Andrew Lunn <andrew@...n.ch>,
"UNGLinuxDriver@...rochip.com" <UNGLinuxDriver@...rochip.com>,
Alexandre Belloni <alexandre.belloni@...tlin.com>,
Claudiu Manoil <claudiu.manoil@....com>,
Lee Jones <lee@...nel.org>
Subject: Re: [RFC v1 net-next 8/8] net: dsa: ocelot: add external ocelot
switch control
On Sun, Sep 11, 2022 at 01:02:44PM -0700, Colin Foster wrote:
> index 08db9cf76818..d8b224f8dc97 100644
> --- a/drivers/net/dsa/ocelot/Kconfig
> +++ b/drivers/net/dsa/ocelot/Kconfig
> @@ -1,4 +1,18 @@
> # SPDX-License-Identifier: GPL-2.0-only
> +config NET_DSA_MSCC_OCELOT_EXT
> + tristate "Ocelot External Ethernet switch support"
> + depends on NET_DSA && SPI
> + depends on NET_VENDOR_MICROSEMI
> + select MDIO_MSCC_MIIM
> + select MFD_OCELOT_CORE
> + select MSCC_OCELOT_SWITCH_LIB
> + select NET_DSA_TAG_OCELOT_8021Q
> + select NET_DSA_TAG_OCELOT
> + help
> + This driver supports the VSC7511, VSC7512, VSC7513 and VSC7514 chips
> + when controlled through SPI. It can be used with the Microsemi dev
> + boards and an external CPU or custom hardware.
I would drop the sentence about Microsemi dev boards or custom hardware.
> diff --git a/drivers/net/dsa/ocelot/ocelot_ext.c b/drivers/net/dsa/ocelot/ocelot_ext.c
> new file mode 100644
> index 000000000000..c821cc963787
> --- /dev/null
> +++ b/drivers/net/dsa/ocelot/ocelot_ext.c
> @@ -0,0 +1,254 @@
> +// SPDX-License-Identifier: (GPL-2.0 OR MIT)
> +/*
> + * Copyright 2021-2022 Innovative Advantage Inc.
> + */
> +
> +#include <linux/iopoll.h>
> +#include <linux/mfd/ocelot.h>
> +#include <linux/phylink.h>
> +#include <linux/platform_device.h>
> +#include <linux/regmap.h>
> +#include <soc/mscc/ocelot_ana.h>
> +#include <soc/mscc/ocelot_dev.h>
> +#include <soc/mscc/ocelot_qsys.h>
> +#include <soc/mscc/ocelot_vcap.h>
> +#include <soc/mscc/ocelot_ptp.h>
> +#include <soc/mscc/ocelot_sys.h>
> +#include <soc/mscc/ocelot.h>
> +#include <soc/mscc/vsc7514_regs.h>
> +#include "felix.h"
> +
> +#define VSC7512_NUM_PORTS 11
> +
> +#define OCELOT_EXT_MEM_INIT_SLEEP_US 1000
> +#define OCELOT_EXT_MEM_INIT_TIMEOUT_US 100000
> +
> +#define OCELOT_EXT_PORT_MODE_SERDES (OCELOT_PORT_MODE_SGMII | \
> + OCELOT_PORT_MODE_QSGMII)
There are places where OCELOT_EXT doesn't make too much sense, like here.
The capabilities of the SERDES ports do not change depending on whether
the switch is controlled externally or not. Same for the memory init
delays. Maybe OCELOT_MEM_INIT_*, OCELOT_PORT_MODE_SERDES etc?
There are more places as well below in function names, I'll let you be
the judge if whether ocelot is controlled externally is relevant to what
they do in any way.
> +static int ocelot_ext_reset(struct ocelot *ocelot)
> +{
> + int err, val;
> +
> + ocelot_ext_reset_phys(ocelot);
> +
> + /* Initialize chip memories */
> + err = regmap_field_write(ocelot->regfields[SYS_RESET_CFG_MEM_ENA], 1);
> + if (err)
> + return err;
> +
> + err = regmap_field_write(ocelot->regfields[SYS_RESET_CFG_MEM_INIT], 1);
> + if (err)
> + return err;
> +
> + /* MEM_INIT is a self-clearing bit. Wait for it to be clear (should be
> + * 100us) before enabling the switch core
> + */
> + err = readx_poll_timeout(ocelot_ext_mem_init_status, ocelot, val, !val,
> + OCELOT_EXT_MEM_INIT_SLEEP_US,
> + OCELOT_EXT_MEM_INIT_TIMEOUT_US);
> +
I think you can eliminate the newline between the err assignment and
checking for it.
> + if (IS_ERR_VALUE(err))
> + return err;
> +
> + return regmap_field_write(ocelot->regfields[SYS_RESET_CFG_CORE_ENA], 1);
> +}
> +
> +static void ocelot_ext_phylink_validate(struct ocelot *ocelot, int port,
> + unsigned long *supported,
> + struct phylink_link_state *state)
> +{
> + struct felix *felix = ocelot_to_felix(ocelot);
> + struct dsa_switch *ds = felix->ds;
> + struct phylink_config *pl_config;
> + struct dsa_port *dp;
> +
> + dp = dsa_to_port(ds, port);
> + pl_config = &dp->pl_config;
> +
> + phylink_generic_validate(pl_config, supported, state);
You could save 2 lines here (defining *pl_config and assigning it) if
you would just call phylink_generic_validate(&dp->pl_config, ...);
> +}
> +
> +static struct regmap *ocelot_ext_regmap_init(struct ocelot *ocelot,
> + struct resource *res)
> +{
> + return dev_get_regmap(ocelot->dev->parent, res->name);
> +}
I have more fundamental questions about this one, which I've formulated
on your patch 7/8. If nothing changes, at least I'd expect some comments
here explaining where the resources actually come from, and the regmaps.
> +static const struct of_device_id ocelot_ext_switch_of_match[] = {
> + { .compatible = "mscc,vsc7512-ext-switch" },
I think I've raised this before. How about removing "external" from the
compatible string? You can figure out it's external, because it's on a
SPI bus.
> + { },
> +};
> +MODULE_DEVICE_TABLE(of, ocelot_ext_switch_of_match);
> +
> +static struct platform_driver ocelot_ext_switch_driver = {
> + .driver = {
> + .name = "ocelot-ext-switch",
> + .of_match_table = of_match_ptr(ocelot_ext_switch_of_match),
> + },
> + .probe = ocelot_ext_probe,
> + .remove = ocelot_ext_remove,
> + .shutdown = ocelot_ext_shutdown,
> +};
> +module_platform_driver(ocelot_ext_switch_driver);
Powered by blists - more mailing lists