From: Vladimir Oltean <vladimir.oltean@nxp.com>
To: Xiaoliang Yang <xiaoliang.yang_1@nxp.com>
Cc: "davem@davemloft.net" <davem@davemloft.net>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
"allan.nielsen@microchip.com" <allan.nielsen@microchip.com>,
"joergen.andreasen@microchip.com"
<joergen.andreasen@microchip.com>,
"UNGLinuxDriver@microchip.com" <UNGLinuxDriver@microchip.com>,
"vinicius.gomes@intel.com" <vinicius.gomes@intel.com>,
"michael.chan@broadcom.com" <michael.chan@broadcom.com>,
"vishal@chelsio.com" <vishal@chelsio.com>,
"saeedm@mellanox.com" <saeedm@mellanox.com>,
"jiri@mellanox.com" <jiri@mellanox.com>,
"idosch@mellanox.com" <idosch@mellanox.com>,
"alexandre.belloni@bootlin.com" <alexandre.belloni@bootlin.com>,
"kuba@kernel.org" <kuba@kernel.org>, Po Liu <po.liu@nxp.com>,
Leo Li <leoyang.li@nxp.com>,
"f.fainelli@gmail.com" <f.fainelli@gmail.com>,
"andrew@lunn.ch" <andrew@lunn.ch>,
"vivien.didelot@gmail.com" <vivien.didelot@gmail.com>,
Claudiu Manoil <claudiu.manoil@nxp.com>,
"linux-mediatek@lists.infradead.org"
<linux-mediatek@lists.infradead.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"matthias.bgg@gmail.com" <matthias.bgg@gmail.com>,
"horatiu.vultur@microchip.com" <horatiu.vultur@microchip.com>
Subject: Re: [PATCH v5 net-next 3/9] net: mscc: ocelot: add MAC table stream learn and lookup operations
Date: Sat, 25 Sep 2021 19:26:59 +0000 [thread overview]
Message-ID: <20210925192658.2wi6egpufqut5hsf@skbuf> (raw)
In-Reply-To: <20210924095226.38079-4-xiaoliang.yang_1@nxp.com>
On Fri, Sep 24, 2021 at 05:52:20PM +0800, Xiaoliang Yang wrote:
> From: Vladimir Oltean <vladimir.oltean@nxp.com>
>
> ocelot_mact_learn_streamdata() can be used in VSC9959 to overwrite an
> FDB entry with stream data. The stream data includes SFID and SSID which
> can be used for PSFP and FRER set.
>
> ocelot_mact_lookup() can be used to check if the given {DMAC, VID} FDB
> entry is exist, and also can retrieve the DEST_IDX and entry type for
> the FDB entry.
>
> Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
> Signed-off-by: Xiaoliang Yang <xiaoliang.yang_1@nxp.com>
This is most certainly not my patch either, so you can drop my name from it.
> ---
> drivers/net/ethernet/mscc/ocelot.c | 50 ++++++++++++++++++++++++++++++
> include/soc/mscc/ocelot.h | 5 +++
> 2 files changed, 55 insertions(+)
>
> diff --git a/drivers/net/ethernet/mscc/ocelot.c b/drivers/net/ethernet/mscc/ocelot.c
> index 35006b0fb963..dc65247b91be 100644
> --- a/drivers/net/ethernet/mscc/ocelot.c
> +++ b/drivers/net/ethernet/mscc/ocelot.c
> @@ -114,6 +114,56 @@ int ocelot_mact_forget(struct ocelot *ocelot,
> }
> EXPORT_SYMBOL(ocelot_mact_forget);
>
> +int ocelot_mact_lookup(struct ocelot *ocelot, int *dst_idx,
> + struct ocelot_mact_entry *entry)
I think the arguments of this function can be improved.
Currently, "entry" is an inout argument: entry->mac and entry->vid are
input, and entry->type is output.
I think it would be better if the argument list looked like this:
int ocelot_mact_lookup(struct ocelot *ocelot, const unsigned char *addr,
u16 vid, enum macaccess_entry_type *type, int *dst_idx)
I think it's clearer this way which arguments are input and which are output.
Additionally, you can stop exporting struct ocelot_mact_entry, if this
is the only reason you needed it.
> +{
> + int val;
> +
> + mutex_lock(&ocelot->mact_lock);
> +
> + ocelot_mact_select(ocelot, entry->mac, entry->vid);
> +
> + /* Issue a read command with MACACCESS_VALID=1. */
> + ocelot_write(ocelot, ANA_TABLES_MACACCESS_VALID |
> + ANA_TABLES_MACACCESS_MAC_TABLE_CMD(MACACCESS_CMD_READ),
> + ANA_TABLES_MACACCESS);
> +
> + if (ocelot_mact_wait_for_completion(ocelot)) {
> + mutex_unlock(&ocelot->mact_lock);
> + return -ETIMEDOUT;
> + }
> +
> + /* Read back the entry flags */
> + val = ocelot_read(ocelot, ANA_TABLES_MACACCESS);
> +
> + mutex_unlock(&ocelot->mact_lock);
> +
> + if (!(val & ANA_TABLES_MACACCESS_VALID))
> + return -ENOENT;
> +
> + *dst_idx = ANA_TABLES_MACACCESS_DEST_IDX_X(val);
> + entry->type = ANA_TABLES_MACACCESS_ENTRYTYPE_X(val);
> +
> + return 0;
> +}
> +EXPORT_SYMBOL(ocelot_mact_lookup);
> +
> +int ocelot_mact_learn_streamdata(struct ocelot *ocelot, int dst_idx,
> + struct ocelot_mact_entry *entry, u32 data)
It would be nice if ocelot_mact_learn_streamdata would follow the basic
prototype of ocelot_mact_learn:
int ocelot_mact_learn(struct ocelot *ocelot, int port,
const unsigned char mac[ETH_ALEN],
unsigned int vid, enum macaccess_entry_type type)
just with the extra STREAMDATA argument at the end.
Also, could we format the STREAMDATA nicer than a raw u32?
> +{
> + int ret;
> +
> + mutex_lock(&ocelot->mact_lock);
> + ocelot_write(ocelot, data, ANA_TABLES_STREAMDATA);
> + mutex_unlock(&ocelot->mact_lock);
> +
> + ret = ocelot_mact_learn(ocelot, dst_idx, entry->mac, entry->vid,
> + entry->type);
Hm, if you temporarily drop the lock just for ocelot_mact_learn to take
it again, you allow somebody else to sneak in and learn another MAC
table entry, and the STREAMDATA will get associated with that other guy
and not with you, no?
> +
> + return ret;
> +}
> +EXPORT_SYMBOL(ocelot_mact_learn_streamdata);
> +
> static void ocelot_mact_init(struct ocelot *ocelot)
> {
> /* Configure the learning mode entries attributes:
> diff --git a/include/soc/mscc/ocelot.h b/include/soc/mscc/ocelot.h
> index e6773f4d09ce..455293652257 100644
> --- a/include/soc/mscc/ocelot.h
> +++ b/include/soc/mscc/ocelot.h
> @@ -926,6 +926,11 @@ void ocelot_phylink_mac_link_up(struct ocelot *ocelot, int port,
> bool tx_pause, bool rx_pause,
> unsigned long quirks);
>
> +int ocelot_mact_lookup(struct ocelot *ocelot, int *dst_idx,
> + struct ocelot_mact_entry *entry);
> +int ocelot_mact_learn_streamdata(struct ocelot *ocelot, int dst_idx,
> + struct ocelot_mact_entry *entry, u32 data);
> +
> #if IS_ENABLED(CONFIG_BRIDGE_MRP)
> int ocelot_mrp_add(struct ocelot *ocelot, int port,
> const struct switchdev_obj_mrp *mrp);
> --
> 2.17.1
>
next prev parent reply other threads:[~2021-09-25 19:27 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-09-24 9:52 [PATCH v5 net-next 0/9] net: dsa: felix: psfp support on vsc9959 Xiaoliang Yang
2021-09-24 9:52 ` [PATCH v5 net-next 1/9] net: mscc: ocelot: serialize access to the MAC table Xiaoliang Yang
2021-09-25 19:13 ` Vladimir Oltean
2021-09-24 9:52 ` [PATCH v5 net-next 2/9] net: mscc: ocelot: export struct ocelot_mact_entry Xiaoliang Yang
2021-09-25 19:19 ` Vladimir Oltean
2021-09-24 9:52 ` [PATCH v5 net-next 3/9] net: mscc: ocelot: add MAC table stream learn and lookup operations Xiaoliang Yang
2021-09-25 19:26 ` Vladimir Oltean [this message]
2021-09-24 9:52 ` [PATCH v5 net-next 4/9] net: mscc: ocelot: set vcap IS2 chain to goto PSFP chain Xiaoliang Yang
2021-09-25 19:29 ` Vladimir Oltean
2021-09-24 9:52 ` [PATCH v5 net-next 5/9] net: mscc: ocelot: add gate and police action offload to PSFP Xiaoliang Yang
2021-09-24 9:52 ` [PATCH v5 net-next 6/9] net: dsa: felix: support psfp filter on vsc9959 Xiaoliang Yang
2021-09-24 9:52 ` [PATCH v5 net-next 7/9] net: dsa: felix: add stream gate settings for psfp Xiaoliang Yang
2021-09-24 9:52 ` [PATCH v5 net-next 8/9] net: mscc: ocelot: use index to set vcap policer Xiaoliang Yang
2021-09-24 9:52 ` [PATCH v5 net-next 9/9] net: dsa: felix: use vcap policer to set flow meter for psfp Xiaoliang Yang
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=20210925192658.2wi6egpufqut5hsf@skbuf \
--to=vladimir.oltean@nxp.com \
--cc=UNGLinuxDriver@microchip.com \
--cc=alexandre.belloni@bootlin.com \
--cc=allan.nielsen@microchip.com \
--cc=andrew@lunn.ch \
--cc=claudiu.manoil@nxp.com \
--cc=davem@davemloft.net \
--cc=f.fainelli@gmail.com \
--cc=horatiu.vultur@microchip.com \
--cc=idosch@mellanox.com \
--cc=jiri@mellanox.com \
--cc=joergen.andreasen@microchip.com \
--cc=kuba@kernel.org \
--cc=leoyang.li@nxp.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mediatek@lists.infradead.org \
--cc=matthias.bgg@gmail.com \
--cc=michael.chan@broadcom.com \
--cc=netdev@vger.kernel.org \
--cc=po.liu@nxp.com \
--cc=saeedm@mellanox.com \
--cc=vinicius.gomes@intel.com \
--cc=vishal@chelsio.com \
--cc=vivien.didelot@gmail.com \
--cc=xiaoliang.yang_1@nxp.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).