* Re: [PATCH net-next 2/5] net: phy: mscc: Add EEE init sequence
From: Quentin Schulz @ 2018-10-01 8:51 UTC (permalink / raw)
To: Florian Fainelli
Cc: davem, andrew, allan.nielsen, linux-kernel, netdev,
thomas.petazzoni, Raju Lakkaraju
In-Reply-To: <1321f1a0-57af-a059-f78a-a699da94c064@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1160 bytes --]
Hi Florian,
On Fri, Sep 14, 2018 at 07:21:09PM -0700, Florian Fainelli wrote:
>
>
> On 09/14/18 01:33, Quentin Schulz wrote:
> > From: Raju Lakkaraju <Raju.Lakkaraju@microchip.com>
> >
> > Microsemi PHYs (VSC 8530/31/40/41) need to update the Energy Efficient
> > Ethernet initialization sequence.
> > In order to avoid certain link state errors that could result in link
> > drops and packet loss, the physical coding sublayer (PCS) must be
> > updated with settings related to EEE in order to improve performance.
> >
> > Signed-off-by: Raju Lakkaraju <Raju.Lakkaraju@microchip.com>
> > Signed-off-by: Quentin Schulz <quentin.schulz@bootlin.com>
> > ---
>
> [snip]
>
> > + vsc85xx_tr_write(phydev, 0x0f82, 0x0012b00a);
>
> Can you just make this an array of register + value pair? That would be
Sure, I'll.
> less error prone in case you need to update that sequence in the future.
>
I'm curious about the kind of errors you're worrying about or have
experienced. Do you have any particular example or thought in mind?
> With that:
>
> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Thanks,
Quentin
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH 5/7] MIPS: mscc: ocelot: add GPIO4 pinmuxing DT node
From: Quentin Schulz @ 2018-10-01 9:01 UTC (permalink / raw)
To: Andrew Lunn
Cc: Alexandre Belloni, ralf, paul.burton, jhogan, robh+dt,
mark.rutland, davem, f.fainelli, allan.nielsen, linux-mips,
devicetree, linux-kernel, netdev, thomas.petazzoni,
antoine.tenart
In-Reply-To: <20180914170221.GB3811@lunn.ch>
[-- Attachment #1: Type: text/plain, Size: 1550 bytes --]
Hi Andrew,
On Fri, Sep 14, 2018 at 07:02:21PM +0200, Andrew Lunn wrote:
> On Fri, Sep 14, 2018 at 06:26:38PM +0200, Quentin Schulz wrote:
> > Hi Alexandre,
> >
> > On Fri, Sep 14, 2018 at 04:54:46PM +0200, Alexandre Belloni wrote:
> > > Hi,
> > >
> > > On 14/09/2018 11:44:26+0200, Quentin Schulz wrote:
> > > > In order to use GPIO4 as a GPIO, we need to mux it in this mode so let's
> > > > declare a new pinctrl DT node for it.
> > > >
> > > > Signed-off-by: Quentin Schulz <quentin.schulz@bootlin.com>
> > > > ---
> > > > arch/mips/boot/dts/mscc/ocelot.dtsi | 5 +++++
> > > > 1 file changed, 5 insertions(+)
> > > >
> > > > diff --git a/arch/mips/boot/dts/mscc/ocelot.dtsi b/arch/mips/boot/dts/mscc/ocelot.dtsi
> > > > index 8ce317c..b5c4c74 100644
> > > > --- a/arch/mips/boot/dts/mscc/ocelot.dtsi
> > > > +++ b/arch/mips/boot/dts/mscc/ocelot.dtsi
> > > > @@ -182,6 +182,11 @@
> > > > interrupts = <13>;
> > > > #interrupt-cells = <2>;
> > > >
> > > > + gpio4: gpio4 {
> > > > + pins = "GPIO_4";
> > > > + function = "gpio";
> > > > + };
> > > > +
> > >
> > > For a GPIO, I would do that in the board dts because it is not used
> > > directly in the dtsi.
> > >
> >
> > And the day we've two boards using this pinctrl we move it to a dtsi. Is
> > that the plan?
>
> Hi Quentin
>
> gpio4 appears to be pretty arbitrary. Could a different design use a
> different gpio? It me, this seems like a board property.
>
Right now, I don't see why it couldn't be.
Quentin
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH net-next 3/7] net: phy: mscc: split config_init in two functions for VSC8584
From: Quentin Schulz @ 2018-10-01 9:07 UTC (permalink / raw)
To: Florian Fainelli
Cc: alexandre.belloni, ralf, paul.burton, jhogan, robh+dt,
mark.rutland, davem, andrew, allan.nielsen, linux-mips,
devicetree, linux-kernel, netdev, thomas.petazzoni,
antoine.tenart
In-Reply-To: <bc31175f-52eb-cb7d-669e-192aec79ac5c@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1519 bytes --]
Hi Florian,
On Fri, Sep 14, 2018 at 10:57:08AM -0700, Florian Fainelli wrote:
> On 09/14/2018 02:44 AM, Quentin Schulz wrote:
> > Part of the config init is common between the VSC8584 and the VSC8574,
> > so to prepare the upcoming support for VSC8574, separate config_init
> > PHY-specific code to config_pre_init function which is set in the probe
> > function of the PHY and used in config_init.
> >
> > Signed-off-by: Quentin Schulz <quentin.schulz@bootlin.com>
> > ---
> > drivers/net/phy/mscc.c | 4 +++-
> > 1 file changed, 3 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/net/phy/mscc.c b/drivers/net/phy/mscc.c
> > index b450489..69cc3cf 100644
> > --- a/drivers/net/phy/mscc.c
> > +++ b/drivers/net/phy/mscc.c
> > @@ -355,6 +355,7 @@ struct vsc8531_private {
> > u64 *stats;
> > int nstats;
> > bool pkg_init;
> > + int (*config_pre_init)(struct mii_bus *bus, int phy);
>
> Is not this overkill given that you have a reference to the phy_device,
> you could check for the for phy_id to know which exact type you have and
> call the appropriate pre_init function?
>
Agreed. It just seemed "cleaner" to me to set config_pre_init in
separate probe functions which are pretty straightforward and short.
Thus not complexifying an already-not-so-straightforward config_init
function.
Anyway, I'll use the phy_id as suggested so that we don't overload the
vsc8531_private structure (since it's also only called once, in
config_init).
Thanks,
Quentin
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH net v2] r8169: always autoneg on resume
From: Andrew Lunn @ 2018-10-01 2:39 UTC (permalink / raw)
To: Alex Xu; +Cc: Daan Wendelen, netdev, hkallweit1, nic_swsd, davem, linux-kernel
In-Reply-To: <153834665886.421.6376790866713055481@pink.alxu.ca>
On Sun, Sep 30, 2018 at 10:30:58PM +0000, Alex Xu wrote:
> Quoting Daan Wendelen (2018-09-30 22:17:51)
> > Hi Alex,
> >
> > I randomly opened your patch even though I have absolutely no idea what this patch is about, but I
> > found a mistake in one of the comments:
> >
> > On Sun, Sep 30, 2018 at 11:06:39AM -0400, Alex Xu (Hello71) wrote:
> > > This affects at least versions 25 and 33, so assume all cards are broken
> > ...
> > > * 1GBit link after resuming from S3. For whatever reason the PHY on
> > > - * this chip doesn't properly start a renegotiation when soft-reset.
> > > + * these chips doesn't properly start a renegotiation when soft-reset.
> > ~~~~~~~
> > I believe it should be "these chips don't"
> >
> > With kind regards,
> > Daan
>
> The grammar is correct as is. The subject of the sentence is "the PHY",
> which is singular. However, I think it should be "the PHYs" instead,
> assuming that they are different.
I keep reading the patch wrong, so here is the end state:
/* It was reported that several chips end up with 10MBit/Half on a
* 1GBit link after resuming from S3. For whatever reason the PHY on
* these chips doesn't properly start a renegotiation when soft-reset.
* Explicitly requesting a renegotiation fixes this.
*/
I would also say 'don't'. For me the subject is 'PHY on these chips',
which is plural.
However:
For whatever reason the PHY, on these chips, doesn't properly start a
renegotiation when soft-reset.
Now just 'the PHY' is the subject, so singular.
But i'm just a native speaker who never actually learnt the rules of
grammar, it just sounds right or wrong, and i have no idea why.
Andrew
^ permalink raw reply
* Re: [PATCH net-next 2/7] net: phy: mscc: add support for VSC8584 PHY
From: Quentin Schulz @ 2018-10-01 9:15 UTC (permalink / raw)
To: Andrew Lunn
Cc: alexandre.belloni, ralf, paul.burton, jhogan, robh+dt,
mark.rutland, davem, f.fainelli, allan.nielsen, linux-mips,
devicetree, linux-kernel, netdev, thomas.petazzoni,
antoine.tenart
In-Reply-To: <20180914172754.GC3811@lunn.ch>
[-- Attachment #1: Type: text/plain, Size: 1275 bytes --]
Hi Andrew,
On Fri, Sep 14, 2018 at 07:27:54PM +0200, Andrew Lunn wrote:
>
> > struct vsc8531_private {
> > int rate_magic;
> > u16 supp_led_modes;
> > @@ -181,6 +354,7 @@ struct vsc8531_private {
> > struct vsc85xx_hw_stat *hw_stats;
> > u64 *stats;
> > int nstats;
> > + bool pkg_init;
>
> > +/* bus->mdio_lock should be locked when using this function */
> > +static int vsc8584_cmd(struct mii_bus *bus, int phy, u16 val)
> > +{
> > + unsigned long deadline;
> > + u16 reg_val;
> > +
> > + __mdiobus_write(bus, phy, MSCC_EXT_PAGE_ACCESS,
> > + MSCC_PHY_PAGE_EXTENDED_GPIO);
> > +
> > + __mdiobus_write(bus, phy, MSCC_PHY_PROC_CMD, PROC_CMD_NCOMPLETED | val);
>
> Hi Quentin
>
> All the __mdiobus_write() look a bit ugly.
I agree :)
> Maybe add bus and base_addr
> to the vsc8531_private structure. Then add helpers
> phy_write_base_phy(priv, reg, val) and phy_read_base_phy(priv, reg).
>
ACK.
> You could also add in:
>
> if (unlikely(!mutex_is_locked(&priv->bus->mdio_lock))) {
> dev_err(bus->dev, "MDIO bus lock not held!\n");
> dump_stack();
> }
>
> Having such code in the mv88e6xxx driver has found a few bugs for me.
>
ACK.
Thanks,
Quentin
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH net-next v3 11/11] net: mscc: ocelot: make use of SerDes PHYs for handling their configuration
From: Quentin Schulz @ 2018-10-01 9:42 UTC (permalink / raw)
To: Florian Fainelli
Cc: alexandre.belloni, ralf, paul.burton, jhogan, robh+dt,
mark.rutland, davem, kishon, andrew, allan.nielsen, linux-mips,
devicetree, linux-kernel, netdev, thomas.petazzoni
In-Reply-To: <0f762d63-a392-d2fe-a121-a013a13a8584@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2479 bytes --]
Hi Florian,
On Sat, Sep 15, 2018 at 02:25:05PM -0700, Florian Fainelli wrote:
>
>
> On 09/14/18 01:16, Quentin Schulz wrote:
> > Previously, the SerDes muxing was hardcoded to a given mode in the MAC
> > controller driver. Now, the SerDes muxing is configured within the
> > Device Tree and is enforced in the MAC controller driver so we can have
> > a lot of different SerDes configurations.
> >
> > Make use of the SerDes PHYs in the MAC controller to set up the SerDes
> > according to the SerDes<->switch port mapping and the communication mode
> > with the Ethernet PHY.
>
> This looks good, just a few comments below:
>
> [snip]
>
> > + err = of_get_phy_mode(portnp);
> > + if (err < 0)
> > + ocelot->ports[port]->phy_mode = PHY_INTERFACE_MODE_NA;
> > + else
> > + ocelot->ports[port]->phy_mode = err;
> > +
> > + switch (ocelot->ports[port]->phy_mode) {
> > + case PHY_INTERFACE_MODE_NA:
> > + continue;
>
> Would not you want to issue a message indicating that the Device Tree
> must be updated here? AFAICT with your patch series, this should no
> longer be a condition that you will hit unless you kept the old DTB
> around, right?
>
It'll occur for internal PHYs. On the PCB123[1], there are four of them,
so we need to be able to give no mode in the DT for those. For the
upcoming PCB120, there'll be 4 external PHYs that require a mode in the
DT and 4 internal PHYs that do not require any mode. I could put a debug
message that says this or that PHY is configured as an internal PHY but
I wouldn't put a message that is printed with the default log level.
So I think we should keep it, shouldn't we?
[1] https://elixir.bootlin.com/linux/latest/source/arch/mips/boot/dts/mscc/ocelot_pcb123.dts
> > + case PHY_INTERFACE_MODE_SGMII:
> > + phy_mode = PHY_MODE_SGMII;
> > + break;
> > + case PHY_INTERFACE_MODE_QSGMII:
> > + phy_mode = PHY_MODE_QSGMII;
> > + break;
> > + default:
> > + dev_err(ocelot->dev,
> > + "invalid phy mode for port%d, (Q)SGMII only\n",
> > + port);
> > + return -EINVAL;
> > + }
> > +
> > + serdes = devm_of_phy_get(ocelot->dev, portnp, NULL);
> > + if (IS_ERR(serdes)) {
> > + err = PTR_ERR(serdes);
> > + if (err == -EPROBE_DEFER) {
>
> This can be simplified into:
>
> if (err == -EPROBE_DEFER)
> dev_dbg();
> else
> dev_err();
> goto err_probe_ports;
>
Indeed, good catch.
Thanks,
Quentin
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH net] net: mscc: fix the frame extraction into the skb
From: Alexandre Belloni @ 2018-10-01 9:49 UTC (permalink / raw)
To: Antoine Tenart
Cc: davem, netdev, linux-kernel, thomas.petazzoni, quentin.schulz,
allan.nielsen
In-Reply-To: <20180920100854.19044-1-antoine.tenart@bootlin.com>
On 20/09/2018 12:08:54+0200, Antoine Ténart wrote:
> When extracting frames from the Ocelot switch, the frame check sequence
> (FCS) is present at the end of the data extracted. The FCS was put into
> the sk buffer which introduced some issues (as length related ones), as
> the FCS shouldn't be part of an Rx sk buffer.
>
> This patch fixes the Ocelot switch extraction behaviour by discarding
> the FCS.
>
> Fixes: a556c76adc05 ("net: mscc: Add initial Ocelot switch support")
> Signed-off-by: Antoine Tenart <antoine.tenart@bootlin.com>
Reviewed-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
> ---
>
> Hi all,
>
> Once this patch will be accepted and net merged into net-next, I'll
> probably send another patch to fill skb->csum with the FCS based on
> NETIF_F_RXFCS.
>
> Thanks!
> Antoine
>
> drivers/net/ethernet/mscc/ocelot_board.c | 12 +++++++++---
> 1 file changed, 9 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/net/ethernet/mscc/ocelot_board.c b/drivers/net/ethernet/mscc/ocelot_board.c
> index 26bb3b18f3be..3cdf63e35b53 100644
> --- a/drivers/net/ethernet/mscc/ocelot_board.c
> +++ b/drivers/net/ethernet/mscc/ocelot_board.c
> @@ -91,7 +91,7 @@ static irqreturn_t ocelot_xtr_irq_handler(int irq, void *arg)
> struct sk_buff *skb;
> struct net_device *dev;
> u32 *buf;
> - int sz, len;
> + int sz, len, buf_len;
> u32 ifh[4];
> u32 val;
> struct frame_info info;
> @@ -116,14 +116,20 @@ static irqreturn_t ocelot_xtr_irq_handler(int irq, void *arg)
> err = -ENOMEM;
> break;
> }
> - buf = (u32 *)skb_put(skb, info.len);
> + buf_len = info.len - ETH_FCS_LEN;
> + buf = (u32 *)skb_put(skb, buf_len);
>
> len = 0;
> do {
> sz = ocelot_rx_frame_word(ocelot, grp, false, &val);
> *buf++ = val;
> len += sz;
> - } while ((sz == 4) && (len < info.len));
> + } while (len < buf_len);
> +
> + /* Read the FCS and discard it */
> + sz = ocelot_rx_frame_word(ocelot, grp, false, &val);
> + /* Update the statistics if part of the FCS was read before */
> + len -= ETH_FCS_LEN - sz;
>
> if (sz < 0) {
> err = sz;
> --
> 2.17.1
>
--
Alexandre Belloni, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* [PATCH net-next] net: mscc: allow extracting the FCS into the skb
From: Antoine Tenart @ 2018-10-01 9:57 UTC (permalink / raw)
To: davem
Cc: Antoine Tenart, netdev, linux-kernel, thomas.petazzoni,
alexandre.belloni, quentin.schulz, allan.nielsen
This patch adds support for the NETIF_F_RXFCS feature in the Mscc
Ethernet driver. This feature is disabled by default and allow an user
to request the driver not to drop the FCS and to extract it into the skb
for debugging purposes.
Signed-off-by: Antoine Tenart <antoine.tenart@bootlin.com>
---
drivers/net/ethernet/mscc/ocelot.c | 2 +-
drivers/net/ethernet/mscc/ocelot_board.c | 7 ++++++-
2 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/mscc/ocelot.c b/drivers/net/ethernet/mscc/ocelot.c
index 1a4f2bb48ead..eb5119e7e60b 100644
--- a/drivers/net/ethernet/mscc/ocelot.c
+++ b/drivers/net/ethernet/mscc/ocelot.c
@@ -1606,7 +1606,7 @@ int ocelot_probe_port(struct ocelot *ocelot, u8 port,
dev->ethtool_ops = &ocelot_ethtool_ops;
dev->switchdev_ops = &ocelot_port_switchdev_ops;
- dev->hw_features |= NETIF_F_HW_VLAN_CTAG_FILTER;
+ dev->hw_features |= NETIF_F_HW_VLAN_CTAG_FILTER | NETIF_F_RXFCS;
dev->features |= NETIF_F_HW_VLAN_CTAG_FILTER;
memcpy(dev->dev_addr, ocelot->base_mac, ETH_ALEN);
diff --git a/drivers/net/ethernet/mscc/ocelot_board.c b/drivers/net/ethernet/mscc/ocelot_board.c
index 3cdf63e35b53..245452a0f244 100644
--- a/drivers/net/ethernet/mscc/ocelot_board.c
+++ b/drivers/net/ethernet/mscc/ocelot_board.c
@@ -126,11 +126,16 @@ static irqreturn_t ocelot_xtr_irq_handler(int irq, void *arg)
len += sz;
} while (len < buf_len);
- /* Read the FCS and discard it */
+ /* Read the FCS */
sz = ocelot_rx_frame_word(ocelot, grp, false, &val);
/* Update the statistics if part of the FCS was read before */
len -= ETH_FCS_LEN - sz;
+ if (unlikely(dev->features & NETIF_F_RXFCS)) {
+ buf = (u32 *)skb_put(skb, ETH_FCS_LEN);
+ *buf = val;
+ }
+
if (sz < 0) {
err = sz;
break;
--
2.17.1
^ permalink raw reply related
* Re: [PATCH net-next v3 10/11] phy: add driver for Microsemi Ocelot SerDes muxing
From: Quentin Schulz @ 2018-10-01 10:02 UTC (permalink / raw)
To: Florian Fainelli
Cc: alexandre.belloni, ralf, paul.burton, jhogan, robh+dt,
mark.rutland, davem, kishon, andrew, allan.nielsen, linux-mips,
devicetree, linux-kernel, netdev, thomas.petazzoni
In-Reply-To: <1dc66b5d-e60e-dad2-eed9-e283de260dc3@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3475 bytes --]
Hi Florian,
On Sat, Sep 15, 2018 at 02:20:25PM -0700, Florian Fainelli wrote:
>
>
> On 09/14/18 01:16, Quentin Schulz wrote:
> > The Microsemi Ocelot can mux SerDes lanes (aka macros) to different
> > switch ports or even make it act as a PCIe interface.
> >
> > This adds support for the muxing of the SerDes.
> >
> > Signed-off-by: Quentin Schulz <quentin.schulz@bootlin.com>
> > ---
>
> [snip]
>
> > +
> > +struct serdes_macro {
> > + u8 idx;
> > + /* Not used when in QSGMII or PCIe mode */
> > + int port;
>
> u8 port to be consistent with the mux table?
>
Not wanted in the current implementation.
In serdes_phy_create, I put the port to -1. In serdes_simple_xlate, I
make sure that once port is set to anything else than -1, it cannot be
set again (cannot have 2+ PHYs sharing the same SerDes (except for
SERDES6G_0 which is used for QSGMII)).
I cannot use u8 for this simple reason. However, I'm all ears for a
nicer solution :)
> [snip]
>
> > +#define SERDES_MUX(_idx, _port, _mode, _mask, _mux) { \
> > + .idx = _idx, \
> > + .port = _port, \
> > + .mode = _mode, \
> > + .mask = _mask, \
> > + .mux = _mux, \
> > +}
> > +
> > +static const struct serdes_mux ocelot_serdes_muxes[] = {
> > + SERDES_MUX(SERDES1G_0, 0, PHY_MODE_SGMII, 0, 0),
> > + SERDES_MUX(SERDES1G_1, 1, PHY_MODE_SGMII, HSIO_HW_CFG_DEV1G_5_MODE, 0),
> > + SERDES_MUX(SERDES1G_1, 5, PHY_MODE_SGMII, HSIO_HW_CFG_QSGMII_ENA |
> > + HSIO_HW_CFG_DEV1G_5_MODE, HSIO_HW_CFG_DEV1G_5_MODE),
>
> Why not go one step further and define a SERDES_MUX_SGMII() macro which
> automatically resolves the correct bit definitions to use?
>
> The current macro does not make this particularly easy to read :/
>
I agree on the readability. But SERDES_MUX_SGMII would basically just
abstract the third argument (mode) and that's it, right? That's still
one argument less but do you see something even more intuitive and more
readable?
[...]
> > +
> > + for (i = 0; i < ARRAY_SIZE(ocelot_serdes_muxes); i++) {
> > + if (macro->idx != ocelot_serdes_muxes[i].idx ||
> > + mode != ocelot_serdes_muxes[i].mode)
> > + continue;
> > +
> > + if (mode != PHY_MODE_QSGMII &&
> > + macro->port != ocelot_serdes_muxes[i].port)
> > + continue;
> > +
> > + ret = regmap_update_bits(macro->ctrl->regs, HSIO_HW_CFG,
> > + ocelot_serdes_muxes[i].mask,
> > + ocelot_serdes_muxes[i].mux);
> > + if (ret)
> > + return ret;
> > +
> > + if (macro->idx < SERDES1G_MAX)
> > + return serdes_init_s1g(macro->ctrl->regs, macro->idx);
> > +
> > + /* SERDES6G and PCIe not supported yet */
> > + return 0;
>
> Would not returning -EOPNOTSUPP be more helpful rather than leaving the
> PHY unconfigured (or did the bootloader somehow configure it before for us)?
>
Yup, you're right, if the SerDes needs to be configured by the kernel,
the user of the SerDes mux is "broken" anyway so it makes sense to
return -EOPNOTSUPP.
[...]
> > +
> > + ctrl = devm_kzalloc(&pdev->dev, sizeof(*ctrl), GFP_KERNEL);
> > + if (!ctrl)
> > + return -ENOMEM;
> > +
> > + ctrl->dev = &pdev->dev;
> > + ctrl->regs = syscon_node_to_regmap(pdev->dev.parent->of_node);
> > + if (!ctrl->regs)
> > + return -ENODEV;
> > +
> > + for (i = 0; i <= SERDES_MAX; i++) {
>
> Every other loop you have is using <, is this one off-by-one?
That is an error.
Thanks,
Quentin
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* [PATCH] cxgb4: Use proper enum in IEEE_FAUX_SYNC
From: Nathan Chancellor @ 2018-10-01 3:47 UTC (permalink / raw)
To: Ganesh Goudar, David S. Miller
Cc: netdev, linux-kernel, Nick Desaulniers, Nathan Chancellor
Clang warns when one enumerated type is implicitly converted to another.
drivers/net/ethernet/chelsio/cxgb4/cxgb4_dcb.c:390:4: warning: implicit
conversion from enumeration type 'enum cxgb4_dcb_state' to different
enumeration type 'enum cxgb4_dcb_state_input' [-Wenum-conversion]
IEEE_FAUX_SYNC(dev, dcb);
^~~~~~~~~~~~~~~~~~~~~~~~
drivers/net/ethernet/chelsio/cxgb4/cxgb4_dcb.h:70:10: note: expanded
from macro 'IEEE_FAUX_SYNC'
CXGB4_DCB_STATE_FW_ALLSYNCED);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~
Use the equivalent value of the expected type to silence Clang while
resulting in no functional change.
CXGB4_DCB_STATE_FW_ALLSYNCED = CXGB4_DCB_INPUT_FW_ALLSYNCED = 3
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
---
drivers/net/ethernet/chelsio/cxgb4/cxgb4_dcb.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_dcb.h b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_dcb.h
index 02040b99c78a..484ee8290090 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_dcb.h
+++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_dcb.h
@@ -67,7 +67,7 @@
do { \
if ((__dcb)->dcb_version == FW_PORT_DCB_VER_IEEE) \
cxgb4_dcb_state_fsm((__dev), \
- CXGB4_DCB_STATE_FW_ALLSYNCED); \
+ CXGB4_DCB_INPUT_FW_ALLSYNCED); \
} while (0)
/* States we can be in for a port's Data Center Bridging.
--
2.19.0
^ permalink raw reply related
* Re: [PATCH v3 net-next 9/9] devlink: Add Documentation/networking/devlink-params-bnxt.txt
From: Vasundhara Volam @ 2018-10-01 4:04 UTC (permalink / raw)
To: Jiří Pírko
Cc: David Miller, michael.chan@broadcom.com, Netdev, Jiri Pirko,
jakub.kicinski
In-Reply-To: <20180929125303.GE2209@nanopsycho.orion>
On Sat, Sep 29, 2018 at 6:27 PM Jiri Pirko <jiri@resnulli.us> wrote:
>
> Fri, Sep 28, 2018 at 08:28:23AM CEST, vasundhara-v.volam@broadcom.com wrote:
> >This patch adds a new file to add information about configuration
> >parameters that are supported by bnxt_en driver via devlink.
> >
> >Cc: "David S. Miller" <davem@davemloft.net>
> >Cc: Jonathan Corbet <corbet@lwn.net>
> >Cc: linux-doc@vger.kernel.org
> >Cc: Jiri Pirko <jiri@mellanox.com>
> >Cc: Michael Chan <michael.chan@broadcom.com>
> >Signed-off-by: Vasundhara Volam <vasundhara-v.volam@broadcom.com>
> >---
> > Documentation/networking/devlink-params-bnxt.txt | 22 ++++++++++++++++++++++
> > 1 file changed, 22 insertions(+)
> > create mode 100644 Documentation/networking/devlink-params-bnxt.txt
> >
> >diff --git a/Documentation/networking/devlink-params-bnxt.txt b/Documentation/networking/devlink-params-bnxt.txt
> >new file mode 100644
> >index 0000000..c7bc9d8
> >--- /dev/null
> >+++ b/Documentation/networking/devlink-params-bnxt.txt
> >@@ -0,0 +1,22 @@
> >+enable_sriov [DEVICE, GENERIC]
> >+ Type: Boolean
>
> No need to list "Type" here. You have it in devlink-params.txt for
> generic params already.
Ok, I thought type will give clarity when configuration mode is listed and
when user checks out only driver specific readme file.
I can remove it in next version of patchset.
>
>
> >+ Configuration mode: Permanent
> >+
> >+ignore_ari [DEVICE, GENERIC]
> >+ Type: Boolean
> >+ Configuration mode: Permanent
> >+
> >+msix_vec_per_pf_max [DEVICE, GENERIC]
> >+ Type: u32
> >+ Configuration mode: Permanent
> >+
> >+msix_vec_per_pf_min [DEVICE, GENERIC]
> >+ Type: u32
> >+ Configuration mode: Permanent
> >+
> >+gre_ver_check [DEVICE, DRIVER-SPECIFIC]
> >+ Generic Routing Encapsulation (GRE) version check will
> >+ be enabled in the device. If disabled, device skips
> >+ version checking for incoming packets.
> >+ Type: Boolean
> >+ Configuration mode: Permanent
> >--
> >1.8.3.1
> >
^ permalink raw reply
* Re: [PATCH v3 net-next 4/9] bnxt_en: Use ignore_ari devlink parameter
From: Vasundhara Volam @ 2018-10-01 4:09 UTC (permalink / raw)
To: gerlitz.or
Cc: David Miller, michael.chan@broadcom.com, Netdev, Jiri Pirko,
jakub.kicinski
In-Reply-To: <CAJ3xEMiYTCUOBhteUG9qZ_SJvPZnJc7q-3UHUqb30nf+Y+XVAw@mail.gmail.com>
On Sun, Sep 30, 2018 at 2:53 AM Or Gerlitz <gerlitz.or@gmail.com> wrote:
>
> On Fri, Sep 28, 2018 at 9:30 AM Vasundhara Volam
> <vasundhara-v.volam@broadcom.com> wrote:
> > This patch adds support for ignore_ari generic permanent mode
> > devlink parameter. This parameter is disabled by default. It can be
> > enabled using devlink param commands.
> >
> > ignore_ari - If enabled, device ignores ARI(Alternate Routing ID)
> > capability, even when platforms has the support and creates same number
> > of partitions when platform does not support ARI capability.
>
> why you want to ignore that?
In some Dell platforms, we don't want our adapter to create more number of
functions even when ARI is enabled.
>
>
> >
> > Cc: Michael Chan <michael.chan@broadcom.com>
> > Signed-off-by: Vasundhara Volam <vasundhara-v.volam@broadcom.com>
> > ---
> > drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.c | 6 ++++++
> > drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.h | 2 ++
> > 2 files changed, 8 insertions(+)
> >
> > diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.c b/drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.c
> > index 790c684..5173881 100644
> > --- a/drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.c
> > +++ b/drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.c
> > @@ -24,6 +24,8 @@
> > static const struct bnxt_dl_nvm_param nvm_params[] = {
> > {DEVLINK_PARAM_GENERIC_ID_ENABLE_SRIOV, NVM_OFF_ENABLE_SRIOV,
> > BNXT_NVM_SHARED_CFG, 1},
> > + {DEVLINK_PARAM_GENERIC_ID_IGNORE_ARI, NVM_OFF_IGNORE_ARI,
> > + BNXT_NVM_SHARED_CFG, 1},
> > };
> >
> > static int bnxt_hwrm_nvm_req(struct bnxt *bp, u32 param_id, void *msg,
> > @@ -108,6 +110,10 @@ static int bnxt_dl_nvm_param_set(struct devlink *dl, u32 id,
> > BIT(DEVLINK_PARAM_CMODE_PERMANENT),
> > bnxt_dl_nvm_param_get, bnxt_dl_nvm_param_set,
> > NULL),
> > + DEVLINK_PARAM_GENERIC(IGNORE_ARI,
> > + BIT(DEVLINK_PARAM_CMODE_PERMANENT),
> > + bnxt_dl_nvm_param_get, bnxt_dl_nvm_param_set,
> > + NULL),
> > };
> >
> > int bnxt_dl_register(struct bnxt *bp)
> > diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.h b/drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.h
> > index 2f68dc0..da146492 100644
> > --- a/drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.h
> > +++ b/drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.h
> > @@ -33,6 +33,8 @@ static inline void bnxt_link_bp_to_dl(struct bnxt *bp, struct devlink *dl)
> > }
> > }
> >
> > +#define NVM_OFF_IGNORE_ARI 164
>
> > +#define NVM_OFF_HW_TC_OFFLOAD 170
>
> what is this (on/off for TC offloads?) and how it's related to ARI?
This was a mistake carried, I will remove it in next version. Thanks
>
> > #define NVM_OFF_ENABLE_SRIOV 401
^ permalink raw reply
* Re: [PATCH] net: arp, ipv6: handle special case of tap device
From: Vladis Dronov @ 2018-10-01 11:32 UTC (permalink / raw)
To: David Miller; +Cc: kuznet, yoshfuji, netdev, syzkaller, linux-kernel
In-Reply-To: <20180929.114023.1370133506922372520.davem@davemloft.net>
Hello, David, all,
> This is insanely ugly.
> I'm not applying this, sorry.
It is ugly, I agree.
> dev->type determines the link layer header layout and size.
Yes, unfortunately, TUNSETLINK ioctl handler does not adjust all the needed
fields after the tun->dev->type:
[drivers/net/tun.c]
case TUNSETLINK:
...
tun->dev->type = (int) arg; //<--- that's all
Let me share what I see and let me hope to get an advise for a better fix.
(also another related thread: https://marc.info/?t=153797194500007&r=1&w=2)
- So setting just the tun->dev->type makes the dev struct inconsistent.
- There are more field to adjust, at least dev->addr_len and dev->broadcast.
- There is no get_addr_len_by_link_type() or a simple way to get link layer
properties by dev->type. Such settings are scattered in *_setup and
*_init functions, like ipgre_tunnel_init() { ... dev->addr_len = 4; ...}
> I think tun/tap should be prevented from
> allowing the dev->type to be changed, unless it will make those changes
> adjust the link layer headers properly as well.
Probably, this functionality is already used by some userspace, so I believe,
I cannot just remove TUNSETLINK ioctl. Let me try to suggest a patch that
sets dev->addr_len and dev->broadcast (and probably other link-level-related)
fields according to the dev->type.
Best regards,
Vladis Dronov | Red Hat, Inc. | Product Security Engineer
^ permalink raw reply
* [PATCH net-next 1/7] net: hns3: Add flow director initialization
From: Salil Mehta @ 2018-10-01 11:46 UTC (permalink / raw)
To: davem
Cc: salil.mehta, yisen.zhuang, lipeng321, mehta.salil, netdev,
linux-kernel, linuxarm, Jian Shen
In-Reply-To: <20181001114647.15504-1-salil.mehta@huawei.com>
From: Jian Shen <shenjian15@huawei.com>
Flow director is a new feature supported by hardware with revision 0x21.
This patch adds flow direcor initialization for each PF. It queries flow
director mode and tcam resource from firmware, selects tuples used for
input key.
Signed-off-by: Jian Shen <shenjian15@huawei.com>
Signed-off-by: Peng Li <lipeng321@huawei.com>
Signed-off-by: Salil Mehta <salil.mehta@huawei.com>
---
drivers/net/ethernet/hisilicon/hns3/hnae3.h | 4 +
drivers/net/ethernet/hisilicon/hns3/hns3_enet.c | 8 ++
.../net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.h | 32 +++++
.../ethernet/hisilicon/hns3/hns3pf/hclge_main.c | 157 +++++++++++++++++++++
.../ethernet/hisilicon/hns3/hns3pf/hclge_main.h | 148 +++++++++++++++++++
5 files changed, 349 insertions(+)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hnae3.h b/drivers/net/ethernet/hisilicon/hns3/hnae3.h
index dea422c..d3e5190 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hnae3.h
+++ b/drivers/net/ethernet/hisilicon/hns3/hnae3.h
@@ -51,6 +51,7 @@
#define HNAE3_KNIC_CLIENT_INITED_B 0x3
#define HNAE3_UNIC_CLIENT_INITED_B 0x4
#define HNAE3_ROCE_CLIENT_INITED_B 0x5
+#define HNAE3_DEV_SUPPORT_FD_B 0x6
#define HNAE3_DEV_SUPPORT_ROCE_DCB_BITS (BIT(HNAE3_DEV_SUPPORT_DCB_B) |\
BIT(HNAE3_DEV_SUPPORT_ROCE_B))
@@ -61,6 +62,9 @@
#define hnae3_dev_dcb_supported(hdev) \
hnae3_get_bit(hdev->ae_dev->flag, HNAE3_DEV_SUPPORT_DCB_B)
+#define hnae3_dev_fd_supported(hdev) \
+ hnae3_get_bit((hdev)->ae_dev->flag, HNAE3_DEV_SUPPORT_FD_B)
+
#define ring_ptr_move_fw(ring, p) \
((ring)->p = ((ring)->p + 1) % (ring)->desc_num)
#define ring_ptr_move_bw(ring, p) \
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
index 10506522..605f029 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
@@ -1622,6 +1622,13 @@ static void hns3_disable_sriov(struct pci_dev *pdev)
pci_disable_sriov(pdev);
}
+static void hns3_get_dev_capability(struct pci_dev *pdev,
+ struct hnae3_ae_dev *ae_dev)
+{
+ if (pdev->revision >= 0x21)
+ hnae3_set_bit(ae_dev->flag, HNAE3_DEV_SUPPORT_FD_B, 1);
+}
+
/* hns3_probe - Device initialization routine
* @pdev: PCI device information struct
* @ent: entry in hns3_pci_tbl
@@ -1647,6 +1654,7 @@ static int hns3_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
ae_dev->pdev = pdev;
ae_dev->flag = ent->driver_data;
ae_dev->dev_type = HNAE3_DEV_KNIC;
+ hns3_get_dev_capability(pdev, ae_dev);
pci_set_drvdata(pdev, ae_dev);
hnae3_register_ae_dev(ae_dev);
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.h b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.h
index 842dc3f..827bc51 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.h
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.h
@@ -190,6 +190,11 @@ enum hclge_opcode_type {
HCLGE_OPC_VLAN_FILTER_PF_CFG = 0x1101,
HCLGE_OPC_VLAN_FILTER_VF_CFG = 0x1102,
+ /* Flow Director commands */
+ HCLGE_OPC_FD_MODE_CTRL = 0x1200,
+ HCLGE_OPC_FD_GET_ALLOCATION = 0x1201,
+ HCLGE_OPC_FD_KEY_CONFIG = 0x1202,
+
/* MDIO command */
HCLGE_OPC_MDIO_CONFIG = 0x1900,
@@ -819,6 +824,33 @@ struct hclge_set_led_state_cmd {
u8 rsv2[20];
};
+struct hclge_get_fd_mode_cmd {
+ u8 mode;
+ u8 enable;
+ u8 rsv[22];
+};
+
+struct hclge_get_fd_allocation_cmd {
+ __le32 stage1_entry_num;
+ __le32 stage2_entry_num;
+ __le16 stage1_counter_num;
+ __le16 stage2_counter_num;
+ u8 rsv[12];
+};
+
+struct hclge_set_fd_key_config_cmd {
+ u8 stage;
+ u8 key_select;
+ u8 inner_sipv6_word_en;
+ u8 inner_dipv6_word_en;
+ u8 outer_sipv6_word_en;
+ u8 outer_dipv6_word_en;
+ u8 rsv1[2];
+ __le32 tuple_mask;
+ __le32 meta_data_mask;
+ u8 rsv2[8];
+};
+
int hclge_cmd_init(struct hclge_dev *hdev);
static inline void hclge_write_reg(void __iomem *base, u32 reg, u32 value)
{
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
index 7c8b686..b02190f 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
@@ -3328,6 +3328,149 @@ static void hclge_set_promisc_mode(struct hnae3_handle *handle, bool en_uc_pmc,
hclge_cmd_set_promisc_mode(hdev, ¶m);
}
+static int hclge_get_fd_mode(struct hclge_dev *hdev, u8 *fd_mode)
+{
+ struct hclge_get_fd_mode_cmd *req;
+ struct hclge_desc desc;
+ int ret;
+
+ hclge_cmd_setup_basic_desc(&desc, HCLGE_OPC_FD_MODE_CTRL, true);
+
+ req = (struct hclge_get_fd_mode_cmd *)desc.data;
+
+ ret = hclge_cmd_send(&hdev->hw, &desc, 1);
+ if (ret) {
+ dev_err(&hdev->pdev->dev, "get fd mode fail, ret=%d\n", ret);
+ return ret;
+ }
+
+ *fd_mode = req->mode;
+
+ return ret;
+}
+
+static int hclge_get_fd_allocation(struct hclge_dev *hdev,
+ u32 *stage1_entry_num,
+ u32 *stage2_entry_num,
+ u16 *stage1_counter_num,
+ u16 *stage2_counter_num)
+{
+ struct hclge_get_fd_allocation_cmd *req;
+ struct hclge_desc desc;
+ int ret;
+
+ hclge_cmd_setup_basic_desc(&desc, HCLGE_OPC_FD_GET_ALLOCATION, true);
+
+ req = (struct hclge_get_fd_allocation_cmd *)desc.data;
+
+ ret = hclge_cmd_send(&hdev->hw, &desc, 1);
+ if (ret) {
+ dev_err(&hdev->pdev->dev, "query fd allocation fail, ret=%d\n",
+ ret);
+ return ret;
+ }
+
+ *stage1_entry_num = le32_to_cpu(req->stage1_entry_num);
+ *stage2_entry_num = le32_to_cpu(req->stage2_entry_num);
+ *stage1_counter_num = le16_to_cpu(req->stage1_counter_num);
+ *stage2_counter_num = le16_to_cpu(req->stage2_counter_num);
+
+ return ret;
+}
+
+static int hclge_set_fd_key_config(struct hclge_dev *hdev, int stage_num)
+{
+ struct hclge_set_fd_key_config_cmd *req;
+ struct hclge_fd_key_cfg *stage;
+ struct hclge_desc desc;
+ int ret;
+
+ hclge_cmd_setup_basic_desc(&desc, HCLGE_OPC_FD_KEY_CONFIG, false);
+
+ req = (struct hclge_set_fd_key_config_cmd *)desc.data;
+ stage = &hdev->fd_cfg.key_cfg[stage_num];
+ req->stage = stage_num;
+ req->key_select = stage->key_sel;
+ req->inner_sipv6_word_en = stage->inner_sipv6_word_en;
+ req->inner_dipv6_word_en = stage->inner_dipv6_word_en;
+ req->outer_sipv6_word_en = stage->outer_sipv6_word_en;
+ req->outer_dipv6_word_en = stage->outer_dipv6_word_en;
+ req->tuple_mask = cpu_to_le32(~stage->tuple_active);
+ req->meta_data_mask = cpu_to_le32(~stage->meta_data_active);
+
+ ret = hclge_cmd_send(&hdev->hw, &desc, 1);
+ if (ret)
+ dev_err(&hdev->pdev->dev, "set fd key fail, ret=%d\n", ret);
+
+ return ret;
+}
+
+static int hclge_init_fd_config(struct hclge_dev *hdev)
+{
+#define LOW_2_WORDS 0x03
+ struct hclge_fd_key_cfg *key_cfg;
+ int ret;
+
+ if (!hnae3_dev_fd_supported(hdev))
+ return 0;
+
+ ret = hclge_get_fd_mode(hdev, &hdev->fd_cfg.fd_mode);
+ if (ret)
+ return ret;
+
+ switch (hdev->fd_cfg.fd_mode) {
+ case HCLGE_FD_MODE_DEPTH_2K_WIDTH_400B_STAGE_1:
+ hdev->fd_cfg.max_key_length = MAX_KEY_LENGTH;
+ break;
+ case HCLGE_FD_MODE_DEPTH_4K_WIDTH_200B_STAGE_1:
+ hdev->fd_cfg.max_key_length = MAX_KEY_LENGTH / 2;
+ break;
+ default:
+ dev_err(&hdev->pdev->dev,
+ "Unsupported flow director mode %d\n",
+ hdev->fd_cfg.fd_mode);
+ return -EOPNOTSUPP;
+ }
+
+ hdev->fd_cfg.fd_en = true;
+ hdev->fd_cfg.proto_support =
+ TCP_V4_FLOW | UDP_V4_FLOW | SCTP_V4_FLOW | TCP_V6_FLOW |
+ UDP_V6_FLOW | SCTP_V6_FLOW | IPV4_USER_FLOW | IPV6_USER_FLOW;
+ key_cfg = &hdev->fd_cfg.key_cfg[HCLGE_FD_STAGE_1];
+ key_cfg->key_sel = HCLGE_FD_KEY_BASE_ON_TUPLE,
+ key_cfg->inner_sipv6_word_en = LOW_2_WORDS;
+ key_cfg->inner_dipv6_word_en = LOW_2_WORDS;
+ key_cfg->outer_sipv6_word_en = 0;
+ key_cfg->outer_dipv6_word_en = 0;
+
+ key_cfg->tuple_active = BIT(INNER_VLAN_TAG_FST) | BIT(INNER_ETH_TYPE) |
+ BIT(INNER_IP_PROTO) | BIT(INNER_IP_TOS) |
+ BIT(INNER_SRC_IP) | BIT(INNER_DST_IP) |
+ BIT(INNER_SRC_PORT) | BIT(INNER_DST_PORT);
+
+ /* If use max 400bit key, we can support tuples for ether type */
+ if (hdev->fd_cfg.max_key_length == MAX_KEY_LENGTH) {
+ hdev->fd_cfg.proto_support |= ETHER_FLOW;
+ key_cfg->tuple_active |=
+ BIT(INNER_DST_MAC) | BIT(INNER_SRC_MAC);
+ }
+
+ /* roce_type is used to filter roce frames
+ * dst_vport is used to specify the rule
+ */
+ key_cfg->meta_data_active = BIT(ROCE_TYPE) | BIT(DST_VPORT);
+
+ ret = hclge_get_fd_allocation(hdev,
+ &hdev->fd_cfg.rule_num[HCLGE_FD_STAGE_1],
+ &hdev->fd_cfg.rule_num[HCLGE_FD_STAGE_2],
+ &hdev->fd_cfg.cnt_num[HCLGE_FD_STAGE_1],
+ &hdev->fd_cfg.cnt_num[HCLGE_FD_STAGE_2]);
+ if (ret)
+ return ret;
+
+ return hclge_set_fd_key_config(hdev, HCLGE_FD_STAGE_1);
+}
+
static void hclge_cfg_mac_mode(struct hclge_dev *hdev, bool enable)
{
struct hclge_desc desc;
@@ -5506,6 +5649,13 @@ static int hclge_init_ae_dev(struct hnae3_ae_dev *ae_dev)
goto err_mdiobus_unreg;
}
+ ret = hclge_init_fd_config(hdev);
+ if (ret) {
+ dev_err(&pdev->dev,
+ "fd table init fail, ret=%d\n", ret);
+ goto err_mdiobus_unreg;
+ }
+
hclge_dcb_ops_set(hdev);
timer_setup(&hdev->service_timer, hclge_service_timer, 0);
@@ -5612,6 +5762,13 @@ static int hclge_reset_ae_dev(struct hnae3_ae_dev *ae_dev)
return ret;
}
+ ret = hclge_init_fd_config(hdev);
+ if (ret) {
+ dev_err(&pdev->dev,
+ "fd table init fail, ret=%d\n", ret);
+ return ret;
+ }
+
dev_info(&pdev->dev, "Reset done, %s driver initialization finished.\n",
HCLGE_DRIVER_NAME);
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.h b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.h
index 7841b83..1e7ad5a 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.h
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.h
@@ -359,6 +359,152 @@ struct hclge_vlan_type_cfg {
u16 tx_in_vlan_type;
};
+enum HCLGE_FD_MODE {
+ HCLGE_FD_MODE_DEPTH_2K_WIDTH_400B_STAGE_1,
+ HCLGE_FD_MODE_DEPTH_1K_WIDTH_400B_STAGE_2,
+ HCLGE_FD_MODE_DEPTH_4K_WIDTH_200B_STAGE_1,
+ HCLGE_FD_MODE_DEPTH_2K_WIDTH_200B_STAGE_2,
+};
+
+enum HCLGE_FD_KEY_TYPE {
+ HCLGE_FD_KEY_BASE_ON_PTYPE,
+ HCLGE_FD_KEY_BASE_ON_TUPLE,
+};
+
+enum HCLGE_FD_STAGE {
+ HCLGE_FD_STAGE_1,
+ HCLGE_FD_STAGE_2,
+};
+
+/* OUTER_XXX indicates tuples in tunnel header of tunnel packet
+ * INNER_XXX indicate tuples in tunneled header of tunnel packet or
+ * tuples of non-tunnel packet
+ */
+enum HCLGE_FD_TUPLE {
+ OUTER_DST_MAC,
+ OUTER_SRC_MAC,
+ OUTER_VLAN_TAG_FST,
+ OUTER_VLAN_TAG_SEC,
+ OUTER_ETH_TYPE,
+ OUTER_L2_RSV,
+ OUTER_IP_TOS,
+ OUTER_IP_PROTO,
+ OUTER_SRC_IP,
+ OUTER_DST_IP,
+ OUTER_L3_RSV,
+ OUTER_SRC_PORT,
+ OUTER_DST_PORT,
+ OUTER_L4_RSV,
+ OUTER_TUN_VNI,
+ OUTER_TUN_FLOW_ID,
+ INNER_DST_MAC,
+ INNER_SRC_MAC,
+ INNER_VLAN_TAG_FST,
+ INNER_VLAN_TAG_SEC,
+ INNER_ETH_TYPE,
+ INNER_L2_RSV,
+ INNER_IP_TOS,
+ INNER_IP_PROTO,
+ INNER_SRC_IP,
+ INNER_DST_IP,
+ INNER_L3_RSV,
+ INNER_SRC_PORT,
+ INNER_DST_PORT,
+ INNER_L4_RSV,
+ MAX_TUPLE,
+};
+
+enum HCLGE_FD_META_DATA {
+ PACKET_TYPE_ID,
+ IP_FRAGEMENT,
+ ROCE_TYPE,
+ NEXT_KEY,
+ VLAN_NUMBER,
+ SRC_VPORT,
+ DST_VPORT,
+ TUNNEL_PACKET,
+ MAX_META_DATA,
+};
+
+struct key_info {
+ u8 key_type;
+ u8 key_length;
+};
+
+static const struct key_info meta_data_key_info[] = {
+ { PACKET_TYPE_ID, 6},
+ { IP_FRAGEMENT, 1},
+ { ROCE_TYPE, 1},
+ { NEXT_KEY, 5},
+ { VLAN_NUMBER, 2},
+ { SRC_VPORT, 12},
+ { DST_VPORT, 12},
+ { TUNNEL_PACKET, 1},
+};
+
+static const struct key_info tuple_key_info[] = {
+ { OUTER_DST_MAC, 48},
+ { OUTER_SRC_MAC, 48},
+ { OUTER_VLAN_TAG_FST, 16},
+ { OUTER_VLAN_TAG_SEC, 16},
+ { OUTER_ETH_TYPE, 16},
+ { OUTER_L2_RSV, 16},
+ { OUTER_IP_TOS, 8},
+ { OUTER_IP_PROTO, 8},
+ { OUTER_SRC_IP, 32},
+ { OUTER_DST_IP, 32},
+ { OUTER_L3_RSV, 16},
+ { OUTER_SRC_PORT, 16},
+ { OUTER_DST_PORT, 16},
+ { OUTER_L4_RSV, 32},
+ { OUTER_TUN_VNI, 24},
+ { OUTER_TUN_FLOW_ID, 8},
+ { INNER_DST_MAC, 48},
+ { INNER_SRC_MAC, 48},
+ { INNER_VLAN_TAG_FST, 16},
+ { INNER_VLAN_TAG_SEC, 16},
+ { INNER_ETH_TYPE, 16},
+ { INNER_L2_RSV, 16},
+ { INNER_IP_TOS, 8},
+ { INNER_IP_PROTO, 8},
+ { INNER_SRC_IP, 32},
+ { INNER_DST_IP, 32},
+ { INNER_L3_RSV, 16},
+ { INNER_SRC_PORT, 16},
+ { INNER_DST_PORT, 16},
+ { INNER_L4_RSV, 32},
+};
+
+#define MAX_KEY_LENGTH 400
+#define MAX_KEY_DWORDS DIV_ROUND_UP(MAX_KEY_LENGTH / 8, 4)
+#define MAX_KEY_BYTES (MAX_KEY_DWORDS * 4)
+#define MAX_META_DATA_LENGTH 32
+
+enum HCLGE_FD_PACKET_TYPE {
+ NIC_PACKET,
+ ROCE_PACKET,
+};
+
+struct hclge_fd_key_cfg {
+ u8 key_sel;
+ u8 inner_sipv6_word_en;
+ u8 inner_dipv6_word_en;
+ u8 outer_sipv6_word_en;
+ u8 outer_dipv6_word_en;
+ u32 tuple_active;
+ u32 meta_data_active;
+};
+
+struct hclge_fd_cfg {
+ u8 fd_mode;
+ u8 fd_en;
+ u16 max_key_length;
+ u32 proto_support;
+ u32 rule_num[2]; /* rule entry number */
+ u16 cnt_num[2]; /* rule hit counter number */
+ struct hclge_fd_key_cfg key_cfg[2];
+};
+
#define HCLGE_VPORT_NUM 256
struct hclge_dev {
struct pci_dev *pdev;
@@ -448,6 +594,8 @@ struct hclge_dev {
struct hclge_vlan_type_cfg vlan_type_cfg;
unsigned long vlan_table[VLAN_N_VID][BITS_TO_LONGS(HCLGE_VPORT_NUM)];
+
+ struct hclge_fd_cfg fd_cfg;
};
/* VPort level vlan tag configuration for TX direction */
--
2.7.4
^ permalink raw reply related
* [PATCH net-next 2/7] net: hns3: Add input key and action config support for flow director
From: Salil Mehta @ 2018-10-01 11:46 UTC (permalink / raw)
To: davem
Cc: salil.mehta, yisen.zhuang, lipeng321, mehta.salil, netdev,
linux-kernel, linuxarm, Jian Shen
In-Reply-To: <20181001114647.15504-1-salil.mehta@huawei.com>
From: Jian Shen <shenjian15@huawei.com>
Each flow director rule consists of input key and action. The input key
is the condition for matching, includes tuples of L2/L3/L4 header.
Action is the behaviour when a packet matches with the input key, such
as drop the packet, or forward to a specified queue.
The input key is stored in the tcam blocks, Each bit of input key can
be masked.
Signed-off-by: Jian Shen <shenjian15@huawei.com>
Signed-off-by: Peng Li <lipeng321@huawei.com>
Signed-off-by: Salil Mehta <salil.mehta@huawei.com>
---
.../net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.h | 45 +++
.../ethernet/hisilicon/hns3/hns3pf/hclge_main.c | 329 +++++++++++++++++++++
.../ethernet/hisilicon/hns3/hns3pf/hclge_main.h | 82 +++++
3 files changed, 456 insertions(+)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.h b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.h
index 827bc51..e5e66b2 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.h
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.h
@@ -194,6 +194,8 @@ enum hclge_opcode_type {
HCLGE_OPC_FD_MODE_CTRL = 0x1200,
HCLGE_OPC_FD_GET_ALLOCATION = 0x1201,
HCLGE_OPC_FD_KEY_CONFIG = 0x1202,
+ HCLGE_OPC_FD_TCAM_OP = 0x1203,
+ HCLGE_OPC_FD_AD_OP = 0x1204,
/* MDIO command */
HCLGE_OPC_MDIO_CONFIG = 0x1900,
@@ -851,6 +853,49 @@ struct hclge_set_fd_key_config_cmd {
u8 rsv2[8];
};
+#define HCLGE_FD_EPORT_SW_EN_B 0
+struct hclge_fd_tcam_config_1_cmd {
+ u8 stage;
+ u8 xy_sel;
+ u8 port_info;
+ u8 rsv1[1];
+ __le32 index;
+ u8 entry_vld;
+ u8 rsv2[7];
+ u8 tcam_data[8];
+};
+
+struct hclge_fd_tcam_config_2_cmd {
+ u8 tcam_data[24];
+};
+
+struct hclge_fd_tcam_config_3_cmd {
+ u8 tcam_data[20];
+ u8 rsv[4];
+};
+
+#define HCLGE_FD_AD_DROP_B 0
+#define HCLGE_FD_AD_DIRECT_QID_B 1
+#define HCLGE_FD_AD_QID_S 2
+#define HCLGE_FD_AD_QID_M GENMASK(12, 2)
+#define HCLGE_FD_AD_USE_COUNTER_B 12
+#define HCLGE_FD_AD_COUNTER_NUM_S 13
+#define HCLGE_FD_AD_COUNTER_NUM_M GENMASK(20, 13)
+#define HCLGE_FD_AD_NXT_STEP_B 20
+#define HCLGE_FD_AD_NXT_KEY_S 21
+#define HCLGE_FD_AD_NXT_KEY_M GENMASK(26, 21)
+#define HCLGE_FD_AD_WR_RULE_ID_B 0
+#define HCLGE_FD_AD_RULE_ID_S 1
+#define HCLGE_FD_AD_RULE_ID_M GENMASK(13, 1)
+
+struct hclge_fd_ad_config_cmd {
+ u8 stage;
+ u8 rsv1[3];
+ __le32 index;
+ __le64 ad_data;
+ u8 rsv2[8];
+};
+
int hclge_cmd_init(struct hclge_dev *hdev);
static inline void hclge_write_reg(void __iomem *base, u32 reg, u32 value)
{
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
index b02190f..030898d 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
@@ -3471,6 +3471,335 @@ static int hclge_init_fd_config(struct hclge_dev *hdev)
return hclge_set_fd_key_config(hdev, HCLGE_FD_STAGE_1);
}
+static int hclge_fd_tcam_config(struct hclge_dev *hdev, u8 stage, bool sel_x,
+ int loc, u8 *key, bool is_add)
+{
+ struct hclge_fd_tcam_config_1_cmd *req1;
+ struct hclge_fd_tcam_config_2_cmd *req2;
+ struct hclge_fd_tcam_config_3_cmd *req3;
+ struct hclge_desc desc[3];
+ int ret;
+
+ hclge_cmd_setup_basic_desc(&desc[0], HCLGE_OPC_FD_TCAM_OP, false);
+ desc[0].flag |= cpu_to_le16(HCLGE_CMD_FLAG_NEXT);
+ hclge_cmd_setup_basic_desc(&desc[1], HCLGE_OPC_FD_TCAM_OP, false);
+ desc[1].flag |= cpu_to_le16(HCLGE_CMD_FLAG_NEXT);
+ hclge_cmd_setup_basic_desc(&desc[2], HCLGE_OPC_FD_TCAM_OP, false);
+
+ req1 = (struct hclge_fd_tcam_config_1_cmd *)desc[0].data;
+ req2 = (struct hclge_fd_tcam_config_2_cmd *)desc[1].data;
+ req3 = (struct hclge_fd_tcam_config_3_cmd *)desc[2].data;
+
+ req1->stage = stage;
+ req1->xy_sel = sel_x ? 1 : 0;
+ hnae3_set_bit(req1->port_info, HCLGE_FD_EPORT_SW_EN_B, 0);
+ req1->index = cpu_to_le32(loc);
+ req1->entry_vld = sel_x ? is_add : 0;
+
+ if (key) {
+ memcpy(req1->tcam_data, &key[0], sizeof(req1->tcam_data));
+ memcpy(req2->tcam_data, &key[sizeof(req1->tcam_data)],
+ sizeof(req2->tcam_data));
+ memcpy(req3->tcam_data, &key[sizeof(req1->tcam_data) +
+ sizeof(req2->tcam_data)], sizeof(req3->tcam_data));
+ }
+
+ ret = hclge_cmd_send(&hdev->hw, desc, 3);
+ if (ret)
+ dev_err(&hdev->pdev->dev,
+ "config tcam key fail, ret=%d\n",
+ ret);
+
+ return ret;
+}
+
+static int hclge_fd_ad_config(struct hclge_dev *hdev, u8 stage, int loc,
+ struct hclge_fd_ad_data *action)
+{
+ struct hclge_fd_ad_config_cmd *req;
+ struct hclge_desc desc;
+ u64 ad_data = 0;
+ int ret;
+
+ hclge_cmd_setup_basic_desc(&desc, HCLGE_OPC_FD_AD_OP, false);
+
+ req = (struct hclge_fd_ad_config_cmd *)desc.data;
+ req->index = cpu_to_le32(loc);
+ req->stage = stage;
+
+ hnae3_set_bit(ad_data, HCLGE_FD_AD_WR_RULE_ID_B,
+ action->write_rule_id_to_bd);
+ hnae3_set_field(ad_data, HCLGE_FD_AD_RULE_ID_M, HCLGE_FD_AD_RULE_ID_S,
+ action->rule_id);
+ ad_data <<= 32;
+ hnae3_set_bit(ad_data, HCLGE_FD_AD_DROP_B, action->drop_packet);
+ hnae3_set_bit(ad_data, HCLGE_FD_AD_DIRECT_QID_B,
+ action->forward_to_direct_queue);
+ hnae3_set_field(ad_data, HCLGE_FD_AD_QID_M, HCLGE_FD_AD_QID_S,
+ action->queue_id);
+ hnae3_set_bit(ad_data, HCLGE_FD_AD_USE_COUNTER_B, action->use_counter);
+ hnae3_set_field(ad_data, HCLGE_FD_AD_COUNTER_NUM_M,
+ HCLGE_FD_AD_COUNTER_NUM_S, action->counter_id);
+ hnae3_set_bit(ad_data, HCLGE_FD_AD_NXT_STEP_B, action->use_next_stage);
+ hnae3_set_field(ad_data, HCLGE_FD_AD_NXT_KEY_M, HCLGE_FD_AD_NXT_KEY_S,
+ action->counter_id);
+
+ req->ad_data = cpu_to_le64(ad_data);
+ ret = hclge_cmd_send(&hdev->hw, &desc, 1);
+ if (ret)
+ dev_err(&hdev->pdev->dev, "fd ad config fail, ret=%d\n", ret);
+
+ return ret;
+}
+
+static bool hclge_fd_convert_tuple(u32 tuple_bit, u8 *key_x, u8 *key_y,
+ struct hclge_fd_rule *rule)
+{
+ u16 tmp_x_s, tmp_y_s;
+ u32 tmp_x_l, tmp_y_l;
+ int i;
+
+ if (rule->unused_tuple & tuple_bit)
+ return true;
+
+ switch (tuple_bit) {
+ case 0:
+ return false;
+ case BIT(INNER_DST_MAC):
+ for (i = 0; i < 6; i++) {
+ calc_x(key_x[5 - i], rule->tuples.dst_mac[i],
+ rule->tuples_mask.dst_mac[i]);
+ calc_y(key_y[5 - i], rule->tuples.dst_mac[i],
+ rule->tuples_mask.dst_mac[i]);
+ }
+
+ return true;
+ case BIT(INNER_SRC_MAC):
+ for (i = 0; i < 6; i++) {
+ calc_x(key_x[5 - i], rule->tuples.src_mac[i],
+ rule->tuples.src_mac[i]);
+ calc_y(key_y[5 - i], rule->tuples.src_mac[i],
+ rule->tuples.src_mac[i]);
+ }
+
+ return true;
+ case BIT(INNER_VLAN_TAG_FST):
+ calc_x(tmp_x_s, rule->tuples.vlan_tag1,
+ rule->tuples_mask.vlan_tag1);
+ calc_y(tmp_y_s, rule->tuples.vlan_tag1,
+ rule->tuples_mask.vlan_tag1);
+ *(__le16 *)key_x = cpu_to_le16(tmp_x_s);
+ *(__le16 *)key_y = cpu_to_le16(tmp_y_s);
+
+ return true;
+ case BIT(INNER_ETH_TYPE):
+ calc_x(tmp_x_s, rule->tuples.ether_proto,
+ rule->tuples_mask.ether_proto);
+ calc_y(tmp_y_s, rule->tuples.ether_proto,
+ rule->tuples_mask.ether_proto);
+ *(__le16 *)key_x = cpu_to_le16(tmp_x_s);
+ *(__le16 *)key_y = cpu_to_le16(tmp_y_s);
+
+ return true;
+ case BIT(INNER_IP_TOS):
+ calc_x(*key_x, rule->tuples.ip_tos, rule->tuples_mask.ip_tos);
+ calc_y(*key_y, rule->tuples.ip_tos, rule->tuples_mask.ip_tos);
+
+ return true;
+ case BIT(INNER_IP_PROTO):
+ calc_x(*key_x, rule->tuples.ip_proto,
+ rule->tuples_mask.ip_proto);
+ calc_y(*key_y, rule->tuples.ip_proto,
+ rule->tuples_mask.ip_proto);
+
+ return true;
+ case BIT(INNER_SRC_IP):
+ calc_x(tmp_x_l, rule->tuples.src_ip[3],
+ rule->tuples_mask.src_ip[3]);
+ calc_y(tmp_y_l, rule->tuples.src_ip[3],
+ rule->tuples_mask.src_ip[3]);
+ *(__le32 *)key_x = cpu_to_le32(tmp_x_l);
+ *(__le32 *)key_y = cpu_to_le32(tmp_y_l);
+
+ return true;
+ case BIT(INNER_DST_IP):
+ calc_x(tmp_x_l, rule->tuples.dst_ip[3],
+ rule->tuples_mask.dst_ip[3]);
+ calc_y(tmp_y_l, rule->tuples.dst_ip[3],
+ rule->tuples_mask.dst_ip[3]);
+ *(__le32 *)key_x = cpu_to_le32(tmp_x_l);
+ *(__le32 *)key_y = cpu_to_le32(tmp_y_l);
+
+ return true;
+ case BIT(INNER_SRC_PORT):
+ calc_x(tmp_x_s, rule->tuples.src_port,
+ rule->tuples_mask.src_port);
+ calc_y(tmp_y_s, rule->tuples.src_port,
+ rule->tuples_mask.src_port);
+ *(__le16 *)key_x = cpu_to_le16(tmp_x_s);
+ *(__le16 *)key_y = cpu_to_le16(tmp_y_s);
+
+ return true;
+ case BIT(INNER_DST_PORT):
+ calc_x(tmp_x_s, rule->tuples.dst_port,
+ rule->tuples_mask.dst_port);
+ calc_y(tmp_y_s, rule->tuples.dst_port,
+ rule->tuples_mask.dst_port);
+ *(__le16 *)key_x = cpu_to_le16(tmp_x_s);
+ *(__le16 *)key_y = cpu_to_le16(tmp_y_s);
+
+ return true;
+ default:
+ return false;
+ }
+}
+
+static u32 hclge_get_port_number(enum HLCGE_PORT_TYPE port_type, u8 pf_id,
+ u8 vf_id, u8 network_port_id)
+{
+ u32 port_number = 0;
+
+ if (port_type == HOST_PORT) {
+ hnae3_set_field(port_number, HCLGE_PF_ID_M, HCLGE_PF_ID_S,
+ pf_id);
+ hnae3_set_field(port_number, HCLGE_VF_ID_M, HCLGE_VF_ID_S,
+ vf_id);
+ hnae3_set_bit(port_number, HCLGE_PORT_TYPE_B, HOST_PORT);
+ } else {
+ hnae3_set_field(port_number, HCLGE_NETWORK_PORT_ID_M,
+ HCLGE_NETWORK_PORT_ID_S, network_port_id);
+ hnae3_set_bit(port_number, HCLGE_PORT_TYPE_B, NETWORK_PORT);
+ }
+
+ return port_number;
+}
+
+static void hclge_fd_convert_meta_data(struct hclge_fd_key_cfg *key_cfg,
+ __le32 *key_x, __le32 *key_y,
+ struct hclge_fd_rule *rule)
+{
+ u32 tuple_bit, meta_data = 0, tmp_x, tmp_y, port_number;
+ u8 cur_pos = 0, tuple_size, shift_bits;
+ int i;
+
+ for (i = 0; i < MAX_META_DATA; i++) {
+ tuple_size = meta_data_key_info[i].key_length;
+ tuple_bit = key_cfg->meta_data_active & BIT(i);
+
+ switch (tuple_bit) {
+ case BIT(ROCE_TYPE):
+ hnae3_set_bit(meta_data, cur_pos, NIC_PACKET);
+ cur_pos += tuple_size;
+ break;
+ case BIT(DST_VPORT):
+ port_number = hclge_get_port_number(HOST_PORT, 0,
+ rule->vf_id, 0);
+ hnae3_set_field(meta_data,
+ GENMASK(cur_pos + tuple_size, cur_pos),
+ cur_pos, port_number);
+ cur_pos += tuple_size;
+ break;
+ default:
+ break;
+ }
+ }
+
+ calc_x(tmp_x, meta_data, 0xFFFFFFFF);
+ calc_y(tmp_y, meta_data, 0xFFFFFFFF);
+ shift_bits = sizeof(meta_data) * 8 - cur_pos;
+
+ *key_x = cpu_to_le32(tmp_x << shift_bits);
+ *key_y = cpu_to_le32(tmp_y << shift_bits);
+}
+
+/* A complete key is combined with meta data key and tuple key.
+ * Meta data key is stored at the MSB region, and tuple key is stored at
+ * the LSB region, unused bits will be filled 0.
+ */
+static int hclge_config_key(struct hclge_dev *hdev, u8 stage,
+ struct hclge_fd_rule *rule)
+{
+ struct hclge_fd_key_cfg *key_cfg = &hdev->fd_cfg.key_cfg[stage];
+ u8 key_x[MAX_KEY_BYTES], key_y[MAX_KEY_BYTES];
+ u8 *cur_key_x, *cur_key_y;
+ int i, ret, tuple_size;
+ u8 meta_data_region;
+
+ memset(key_x, 0, sizeof(key_x));
+ memset(key_y, 0, sizeof(key_y));
+ cur_key_x = key_x;
+ cur_key_y = key_y;
+
+ for (i = 0 ; i < MAX_TUPLE; i++) {
+ bool tuple_valid;
+ u32 check_tuple;
+
+ tuple_size = tuple_key_info[i].key_length / 8;
+ check_tuple = key_cfg->tuple_active & BIT(i);
+
+ tuple_valid = hclge_fd_convert_tuple(check_tuple, cur_key_x,
+ cur_key_y, rule);
+ if (tuple_valid) {
+ cur_key_x += tuple_size;
+ cur_key_y += tuple_size;
+ }
+ }
+
+ meta_data_region = hdev->fd_cfg.max_key_length / 8 -
+ MAX_META_DATA_LENGTH / 8;
+
+ hclge_fd_convert_meta_data(key_cfg,
+ (__le32 *)(key_x + meta_data_region),
+ (__le32 *)(key_y + meta_data_region),
+ rule);
+
+ ret = hclge_fd_tcam_config(hdev, stage, false, rule->location, key_y,
+ true);
+ if (ret) {
+ dev_err(&hdev->pdev->dev,
+ "fd key_y config fail, loc=%d, ret=%d\n",
+ rule->queue_id, ret);
+ return ret;
+ }
+
+ ret = hclge_fd_tcam_config(hdev, stage, true, rule->location, key_x,
+ true);
+ if (ret)
+ dev_err(&hdev->pdev->dev,
+ "fd key_x config fail, loc=%d, ret=%d\n",
+ rule->queue_id, ret);
+ return ret;
+}
+
+static int hclge_config_action(struct hclge_dev *hdev, u8 stage,
+ struct hclge_fd_rule *rule)
+{
+ struct hclge_fd_ad_data ad_data;
+
+ ad_data.ad_id = rule->location;
+
+ if (rule->action == HCLGE_FD_ACTION_DROP_PACKET) {
+ ad_data.drop_packet = true;
+ ad_data.forward_to_direct_queue = false;
+ ad_data.queue_id = 0;
+ } else {
+ ad_data.drop_packet = false;
+ ad_data.forward_to_direct_queue = true;
+ ad_data.queue_id = rule->queue_id;
+ }
+
+ ad_data.use_counter = false;
+ ad_data.counter_id = 0;
+
+ ad_data.use_next_stage = false;
+ ad_data.next_input_key = 0;
+
+ ad_data.write_rule_id_to_bd = true;
+ ad_data.rule_id = rule->location;
+
+ return hclge_fd_ad_config(hdev, stage, ad_data.ad_id, &ad_data);
+}
+
static void hclge_cfg_mac_mode(struct hclge_dev *hdev, bool enable)
{
struct hclge_desc desc;
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.h b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.h
index 1e7ad5a..7f5a242 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.h
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.h
@@ -79,6 +79,19 @@
#define HCLGE_VF_NUM_PER_CMD 64
#define HCLGE_VF_NUM_PER_BYTE 8
+enum HLCGE_PORT_TYPE {
+ HOST_PORT,
+ NETWORK_PORT
+};
+
+#define HCLGE_PF_ID_S 0
+#define HCLGE_PF_ID_M GENMASK(2, 0)
+#define HCLGE_VF_ID_S 3
+#define HCLGE_VF_ID_M GENMASK(10, 3)
+#define HCLGE_PORT_TYPE_B 11
+#define HCLGE_NETWORK_PORT_ID_S 0
+#define HCLGE_NETWORK_PORT_ID_M GENMASK(3, 0)
+
/* Reset related Registers */
#define HCLGE_MISC_RESET_STS_REG 0x20700
#define HCLGE_MISC_VECTOR_INT_STS 0x20800
@@ -485,6 +498,11 @@ enum HCLGE_FD_PACKET_TYPE {
ROCE_PACKET,
};
+enum HCLGE_FD_ACTION {
+ HCLGE_FD_ACTION_ACCEPT_PACKET,
+ HCLGE_FD_ACTION_DROP_PACKET,
+};
+
struct hclge_fd_key_cfg {
u8 key_sel;
u8 inner_sipv6_word_en;
@@ -505,6 +523,70 @@ struct hclge_fd_cfg {
struct hclge_fd_key_cfg key_cfg[2];
};
+struct hclge_fd_rule_tuples {
+ u8 src_mac[6];
+ u8 dst_mac[6];
+ u32 src_ip[4];
+ u32 dst_ip[4];
+ u16 src_port;
+ u16 dst_port;
+ u16 vlan_tag1;
+ u16 ether_proto;
+ u8 ip_tos;
+ u8 ip_proto;
+};
+
+struct hclge_fd_rule {
+ struct hlist_node rule_node;
+ struct hclge_fd_rule_tuples tuples;
+ struct hclge_fd_rule_tuples tuples_mask;
+ u32 unused_tuple;
+ u32 flow_type;
+ u8 action;
+ u16 vf_id;
+ u16 queue_id;
+ u16 location;
+};
+
+struct hclge_fd_ad_data {
+ u16 ad_id;
+ u8 drop_packet;
+ u8 forward_to_direct_queue;
+ u16 queue_id;
+ u8 use_counter;
+ u8 counter_id;
+ u8 use_next_stage;
+ u8 write_rule_id_to_bd;
+ u8 next_input_key;
+ u16 rule_id;
+};
+
+/* For each bit of TCAM entry, it uses a pair of 'x' and
+ * 'y' to indicate which value to match, like below:
+ * ----------------------------------
+ * | bit x | bit y | search value |
+ * ----------------------------------
+ * | 0 | 0 | always hit |
+ * ----------------------------------
+ * | 1 | 0 | match '0' |
+ * ----------------------------------
+ * | 0 | 1 | match '1' |
+ * ----------------------------------
+ * | 1 | 1 | invalid |
+ * ----------------------------------
+ * Then for input key(k) and mask(v), we can calculate the value by
+ * the formulae:
+ * x = (~k) & v
+ * y = (k ^ ~v) & k
+ */
+#define calc_x(x, k, v) ((x) = (~(k) & (v)))
+#define calc_y(y, k, v) \
+ do { \
+ const typeof(k) _k_ = (k); \
+ const typeof(v) _v_ = (v); \
+ (y) = (_k_ ^ ~_v_) & (_k_); \
+ } while (0)
+
#define HCLGE_VPORT_NUM 256
struct hclge_dev {
struct pci_dev *pdev;
--
2.7.4
^ permalink raw reply related
* Re: [PATCH] mt76: fix header guard macro define names
From: Felix Fietkau @ 2018-10-01 11:57 UTC (permalink / raw)
To: Colin King, Kalle Valo, David S . Miller, Matthias Brugger,
Lorenzo Bianconi, linux-wireless, netdev, linux-arm-kernel,
linux-mediatek
Cc: kernel-janitors, linux-kernel
In-Reply-To: <20180930225715.18491-1-colin.king@canonical.com>
On 2018-10-01 00:57, Colin King wrote:
> From: Colin Ian King <colin.king@canonical.com>
>
> The header guards that are #defined are different from those being
> checked. Fix this by #defining them to the correct name.
>
> Fixes clang warnings:
> drivers/net/wireless/mediatek/mt76/mt76x02_mcu.h:17:9:
> warning: '__MT76x02_MCU_H' is used as a header guard here, followed
> by #define of a different macro [-Wheader-guard]
>
> drivers/net/wireless/mediatek/mt76/mt76x02_usb.h:17:9:
> warning: '__MT76x02_USB_H' is used as a header guard here, followed
> by #define of a different macro [-Wheader-guard]
>
> Fixes: 905db7470199 ("mt76: usb: move mt76x02 mcu code in mt76x02-usb module")
> Fixes: edaa580bc830 ("mt76: move shared mcu_calibrate routine in mt76x02-lib module")
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
Merged, thanks.
- Felix
^ permalink raw reply
* pull-request: wireless-drivers 2018-10-01
From: Kalle Valo @ 2018-10-01 11:59 UTC (permalink / raw)
To: David Miller; +Cc: linux-wireless, netdev, linux-kernel
Hi Dave,
here's a really small pull request to net tree for 4.19. More info below
and please let me know if there are any problems.
Kalle
The following changes since commit 5b394b2ddf0347bef56e50c69a58773c94343ff3:
Linux 4.19-rc1 (2018-08-26 14:11:59 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers.git tags/wireless-drivers-for-davem-2018-10-01
for you to fetch changes up to 3baafeffa48a12b3cec9a0b6d4049fba02d53cea:
iwlwifi: 1000: set the TFD queue size (2018-09-27 21:20:36 +0300)
----------------------------------------------------------------
wireless-drivers fixes for 4.19
First, and also hopefully the last, set of fixes for 4.19. All small
but still important fixes
mt76x0
* fix a bug when a virtual interface is removed multiple times
b43
* fix DMA error related regression with proprietary firmware
iwlwifi
* fix an oops which was a regression in v4.19-rc1
----------------------------------------------------------------
Larry Finger (1):
b43: fix DMA error related regression with proprietary firmware
Pavel Machek (1):
iwlwifi: 1000: set the TFD queue size
Stanislaw Gruszka (1):
mt76x0: fix remove_interface
drivers/net/wireless/broadcom/b43/dma.c | 6 ++++--
drivers/net/wireless/intel/iwlwifi/cfg/1000.c | 1 +
drivers/net/wireless/mediatek/mt76/mt76x0/main.c | 3 +--
3 files changed, 6 insertions(+), 4 deletions(-)
^ permalink raw reply
* Re: [PATCH net-next v3 07/11] dt-bindings: phy: add DT binding for Microsemi Ocelot SerDes muxing
From: Quentin Schulz @ 2018-10-01 12:46 UTC (permalink / raw)
To: Rob Herring
Cc: alexandre.belloni, ralf, paul.burton, jhogan, mark.rutland, davem,
kishon, andrew, f.fainelli, allan.nielsen, linux-mips, devicetree,
linux-kernel, netdev, thomas.petazzoni
In-Reply-To: <20180926213509.GA7454@bogus>
[-- Attachment #1: Type: text/plain, Size: 3017 bytes --]
Hi Rob,
I'm not sure I've understood the way you wanted me to so let me know if
I'm not on the right path.
On Wed, Sep 26, 2018 at 04:35:09PM -0500, Rob Herring wrote:
> On Fri, Sep 14, 2018 at 10:16:05AM +0200, Quentin Schulz wrote:
> > Signed-off-by: Quentin Schulz <quentin.schulz@bootlin.com>
> > ---
> > Documentation/devicetree/bindings/phy/phy-ocelot-serdes.txt | 40 +++++++-
> > 1 file changed, 40 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/phy/phy-ocelot-serdes.txt
> >
> > diff --git a/Documentation/devicetree/bindings/phy/phy-ocelot-serdes.txt b/Documentation/devicetree/bindings/phy/phy-ocelot-serdes.txt
> > new file mode 100644
> > index 0000000..2a88cc3
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/phy/phy-ocelot-serdes.txt
> > @@ -0,0 +1,40 @@
> > +Microsemi Ocelot SerDes muxing driver
> > +-------------------------------------
> > +
> > +On Microsemi Ocelot, there is a handful of registers in HSIO address
> > +space for setting up the SerDes to switch port muxing.
> > +
> > +A SerDes X can be "muxed" to work with switch port Y or Z for example.
> > +One specific SerDes can also be used as a PCIe interface.
> > +
> > +Hence, a SerDes represents an interface, be it an Ethernet or a PCIe one.
> > +
> > +There are two kinds of SerDes: SERDES1G supports 10/100Mbps in
> > +half/full-duplex and 1000Mbps in full-duplex mode while SERDES6G supports
> > +10/100Mbps in half/full-duplex and 1000/2500Mbps in full-duplex mode.
> > +
> > +Also, SERDES6G number (aka "macro") 0 is the only interface supporting
> > +QSGMII.
> > +
> > +Required properties:
> > +
> > +- compatible: should be "mscc,vsc7514-serdes"
> > +- #phy-cells : from the generic phy bindings, must be 2.
> > + The first number defines the input port to use for a given
> > + SerDes macro. The second defines the macro to use. They are
> > + defined in dt-bindings/phy/phy-ocelot-serdes.h
>
> You need to define what this is a child of.
>
This is a child of the HSIO syscon on the Microsemi Ocelot. I don't
expect all Microsemi SoCs that could use this driver to have the SerDes
node in the HSIO syscon.
Among the latest additions in Documentation/devicetree/bindings/phy I
couldn't find anything close to my understanding of "define what this is
a child of", could you elaborate on what you want exactly?
> > +
> > +Example:
> > +
> > + serdes: serdes {
> > + compatible = "mscc,vsc7514-serdes";
> > + #phy-cells = <2>;
>
> However, if there are no other resources associated with this, then you
> don't even need this child node. The parent can be a phy provider and
> provider of other functions too.
>
The parent is a syscon with multiple features (SerDes, PLL
configuration, temp sensor, SyncE, ...) so I'm not sure it's possible to
do what you're asking me to. For now, there is only a SerDes node but
ultimately there'll be more than one I guess.
Thanks,
Quentin
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH v3 net-next 9/9] devlink: Add Documentation/networking/devlink-params-bnxt.txt
From: Jiri Pirko @ 2018-10-01 6:49 UTC (permalink / raw)
To: Vasundhara Volam
Cc: David Miller, michael.chan@broadcom.com, Netdev, Jiri Pirko,
jakub.kicinski
In-Reply-To: <CAACQVJrEFio6r_miB5yvDp=0RMs=6FsfLXqLkeGTYECWvfXx5A@mail.gmail.com>
Mon, Oct 01, 2018 at 06:04:08AM CEST, vasundhara-v.volam@broadcom.com wrote:
>On Sat, Sep 29, 2018 at 6:27 PM Jiri Pirko <jiri@resnulli.us> wrote:
>>
>> Fri, Sep 28, 2018 at 08:28:23AM CEST, vasundhara-v.volam@broadcom.com wrote:
>> >This patch adds a new file to add information about configuration
>> >parameters that are supported by bnxt_en driver via devlink.
>> >
>> >Cc: "David S. Miller" <davem@davemloft.net>
>> >Cc: Jonathan Corbet <corbet@lwn.net>
>> >Cc: linux-doc@vger.kernel.org
>> >Cc: Jiri Pirko <jiri@mellanox.com>
>> >Cc: Michael Chan <michael.chan@broadcom.com>
>> >Signed-off-by: Vasundhara Volam <vasundhara-v.volam@broadcom.com>
>> >---
>> > Documentation/networking/devlink-params-bnxt.txt | 22 ++++++++++++++++++++++
>> > 1 file changed, 22 insertions(+)
>> > create mode 100644 Documentation/networking/devlink-params-bnxt.txt
>> >
>> >diff --git a/Documentation/networking/devlink-params-bnxt.txt b/Documentation/networking/devlink-params-bnxt.txt
>> >new file mode 100644
>> >index 0000000..c7bc9d8
>> >--- /dev/null
>> >+++ b/Documentation/networking/devlink-params-bnxt.txt
>> >@@ -0,0 +1,22 @@
>> >+enable_sriov [DEVICE, GENERIC]
>> >+ Type: Boolean
>>
>> No need to list "Type" here. You have it in devlink-params.txt for
>> generic params already.
>Ok, I thought type will give clarity when configuration mode is listed and
>when user checks out only driver specific readme file.
>I can remove it in next version of patchset.
Yes please. The thing is, once this info is on 2 places, I'm pretty sure
what eventually there would be different types on different places.
Leaving the type only on one place reduces need for sync.
Thanks.
>>
>>
>> >+ Configuration mode: Permanent
>> >+
>> >+ignore_ari [DEVICE, GENERIC]
>> >+ Type: Boolean
>> >+ Configuration mode: Permanent
>> >+
>> >+msix_vec_per_pf_max [DEVICE, GENERIC]
>> >+ Type: u32
>> >+ Configuration mode: Permanent
>> >+
>> >+msix_vec_per_pf_min [DEVICE, GENERIC]
>> >+ Type: u32
>> >+ Configuration mode: Permanent
>> >+
>> >+gre_ver_check [DEVICE, DRIVER-SPECIFIC]
>> >+ Generic Routing Encapsulation (GRE) version check will
>> >+ be enabled in the device. If disabled, device skips
>> >+ version checking for incoming packets.
>> >+ Type: Boolean
>> >+ Configuration mode: Permanent
>> >--
>> >1.8.3.1
>> >
^ permalink raw reply
* Re: [PATCH v3 net-next 9/9] devlink: Add Documentation/networking/devlink-params-bnxt.txt
From: Vasundhara Volam @ 2018-10-01 6:57 UTC (permalink / raw)
To: Jiří Pírko
Cc: David Miller, michael.chan@broadcom.com, Netdev, Jiri Pirko,
jakub.kicinski
In-Reply-To: <20181001064932.GH2209@nanopsycho.orion>
On Mon, Oct 1, 2018 at 12:24 PM Jiri Pirko <jiri@resnulli.us> wrote:
>
> Mon, Oct 01, 2018 at 06:04:08AM CEST, vasundhara-v.volam@broadcom.com wrote:
> >On Sat, Sep 29, 2018 at 6:27 PM Jiri Pirko <jiri@resnulli.us> wrote:
> >>
> >> Fri, Sep 28, 2018 at 08:28:23AM CEST, vasundhara-v.volam@broadcom.com wrote:
> >> >This patch adds a new file to add information about configuration
> >> >parameters that are supported by bnxt_en driver via devlink.
> >> >
> >> >Cc: "David S. Miller" <davem@davemloft.net>
> >> >Cc: Jonathan Corbet <corbet@lwn.net>
> >> >Cc: linux-doc@vger.kernel.org
> >> >Cc: Jiri Pirko <jiri@mellanox.com>
> >> >Cc: Michael Chan <michael.chan@broadcom.com>
> >> >Signed-off-by: Vasundhara Volam <vasundhara-v.volam@broadcom.com>
> >> >---
> >> > Documentation/networking/devlink-params-bnxt.txt | 22 ++++++++++++++++++++++
> >> > 1 file changed, 22 insertions(+)
> >> > create mode 100644 Documentation/networking/devlink-params-bnxt.txt
> >> >
> >> >diff --git a/Documentation/networking/devlink-params-bnxt.txt b/Documentation/networking/devlink-params-bnxt.txt
> >> >new file mode 100644
> >> >index 0000000..c7bc9d8
> >> >--- /dev/null
> >> >+++ b/Documentation/networking/devlink-params-bnxt.txt
> >> >@@ -0,0 +1,22 @@
> >> >+enable_sriov [DEVICE, GENERIC]
> >> >+ Type: Boolean
> >>
> >> No need to list "Type" here. You have it in devlink-params.txt for
> >> generic params already.
> >Ok, I thought type will give clarity when configuration mode is listed and
> >when user checks out only driver specific readme file.
> >I can remove it in next version of patchset.
>
> Yes please. The thing is, once this info is on 2 places, I'm pretty sure
> what eventually there would be different types on different places.
> Leaving the type only on one place reduces need for sync.
>
> Thanks.
Okay, got it. Thanks, I will remove it.
>
> >>
> >>
> >> >+ Configuration mode: Permanent
> >> >+
> >> >+ignore_ari [DEVICE, GENERIC]
> >> >+ Type: Boolean
> >> >+ Configuration mode: Permanent
> >> >+
> >> >+msix_vec_per_pf_max [DEVICE, GENERIC]
> >> >+ Type: u32
> >> >+ Configuration mode: Permanent
> >> >+
> >> >+msix_vec_per_pf_min [DEVICE, GENERIC]
> >> >+ Type: u32
> >> >+ Configuration mode: Permanent
> >> >+
> >> >+gre_ver_check [DEVICE, DRIVER-SPECIFIC]
> >> >+ Generic Routing Encapsulation (GRE) version check will
> >> >+ be enabled in the device. If disabled, device skips
> >> >+ version checking for incoming packets.
> >> >+ Type: Boolean
> >> >+ Configuration mode: Permanent
> >> >--
> >> >1.8.3.1
> >> >
^ permalink raw reply
* Re: [PATCH iproute2/net-next v2] tc_util: Add support for showing TCA_STATS_BASIC_HW statistics
From: Eelco Chaudron @ 2018-10-01 7:08 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev, davem
In-Reply-To: <52262814-6824-44EF-B10C-C7AD96A0FA57@redhat.com>
On 10 Aug 2018, at 16:48, Eelco Chaudron wrote:
> On 10 Aug 2018, at 16:44, Stephen Hemminger wrote:
>
>> On Fri, 10 Aug 2018 07:59:30 -0400
>> Eelco Chaudron <echaudro@redhat.com> wrote:
>>
>>> + if (bs.bytes >= bs_hw.bytes && bs.packets >= bs_hw.packets) {
>>> + print_string(PRINT_FP, NULL, "%s", _SL_);
>>> + print_string(PRINT_FP, NULL, "%s", prefix);
>>> + print_lluint(PRINT_ANY, "sw_bytes",
>>> + "Sent software %llu bytes",
>>> + bs.bytes - bs_hw.bytes);
>>> + print_uint(PRINT_ANY, "sw_packets", " %u pkt",
>>> + bs.packets - bs_hw.packets);
>>> + }
>>> + }
>>> +
>>> + print_string(PRINT_FP, NULL, "%s", _SL_);
>>> + print_string(PRINT_FP, NULL, "%s", prefix);
>>> + print_lluint(PRINT_ANY, "hw_bytes", "Sent hardware %llu bytes",
>>> + bs_hw.bytes);
>>
>> What does the output look like?
>
> See the two +’es below:
>
> $ tc -s filter show dev enp3s0np0 parent ffff:
> filter protocol ip pref 1 flower chain 0
> filter protocol ip pref 1 flower chain 0 handle 0x1
> eth_type ipv4
> dst_ip 2.0.0.0
> src_ip 1.0.0.0
> ip_flags nofrag
> in_hw
> action order 1: mirred (Egress Redirect to device eth1) stolen
> index 1 ref 1 bind 1 installed 0 sec used 0 sec
> Action statistics:
> Sent 534884742 bytes 8915697 pkt (dropped 0, overlimits 0
> requeues 0)
> + Sent software 187542 bytes 4077 pkt
> + Sent hardware 534697200 bytes 8911620 pkt
> backlog 0b 0p requeues 0
> cookie 89173e6a44447001becfd486bda17e29
Hi Stephen, anything else required for this patch to be accepted?
FYI the kernel side of this patch has been excepted on net-next.
Cheers,
Eelco
^ permalink raw reply
* RE: [PATCH] dpaa_eth: Remove useless declaration
From: Madalin-cristian Bucur @ 2018-10-01 7:11 UTC (permalink / raw)
To: Nathan Chancellor, David S. Miller
Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <20181001041029.2334-1-natechancellor@gmail.com>
> -----Original Message-----
> From: Nathan Chancellor [mailto:natechancellor@gmail.com]
> Sent: Monday, October 1, 2018 7:10 AM
> To: Madalin-cristian Bucur <madalin.bucur@nxp.com>; David S. Miller
> <davem@davemloft.net>
> Cc: netdev@vger.kernel.org; linux-kernel@vger.kernel.org; Nathan
> Chancellor <natechancellor@gmail.com>
> Subject: [PATCH] dpaa_eth: Remove useless declaration
>
> Clang warns:
>
> drivers/net/ethernet/freescale/dpaa/dpaa_eth.c:2734:34: warning:
> tentative array definition assumed to have one element
> static const struct of_device_id dpaa_match[];
> ^
> 1 warning generated.
>
> Turns out that since this driver was introduced in commit 9ad1a3749333
> ("dpaa_eth: add support for DPAA Ethernet"), this declaration has been
> unused. Remove it to silence the warning.
>
> Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
> ---
> drivers/net/ethernet/freescale/dpaa/dpaa_eth.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c
> b/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c
> index 84843de25c7b..6e0f47f2c8a3 100644
> --- a/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c
> +++ b/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c
> @@ -2731,8 +2731,6 @@ static int dpaa_ingress_cgr_init(struct dpaa_priv
> *priv)
> return err;
> }
>
> -static const struct of_device_id dpaa_match[];
> -
> static inline u16 dpaa_get_headroom(struct dpaa_buffer_layout *bl)
> {
> u16 headroom;
> --
> 2.19.0
Acked-by: Madalin Bucur <madalin.bucur@nxp.com>
Thank you
^ permalink raw reply
* Re: [PATCH] ath10k: Remove duplicated includes
From: Kalle Valo @ 2018-10-01 13:57 UTC (permalink / raw)
To: YueHaibing
Cc: ath10k, linux-kernel, netdev, davem, linux-wireless, YueHaibing
In-Reply-To: <20180913140121.23152-1-yuehaibing@huawei.com>
YueHaibing <yuehaibing@huawei.com> wrote:
> remove duplicated include from ath10k driver.
>
> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Patch applied to ath-next branch of ath.git, thanks.
4be3b05e7a83 ath10k: remove duplicated includes
--
https://patchwork.kernel.org/patch/10599605/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH] ath10k: Remove duplicated includes
From: Kalle Valo @ 2018-10-01 13:57 UTC (permalink / raw)
To: YueHaibing
Cc: linux-wireless, netdev, YueHaibing, linux-kernel, ath10k, davem
In-Reply-To: <20180913140121.23152-1-yuehaibing@huawei.com>
YueHaibing <yuehaibing@huawei.com> wrote:
> remove duplicated include from ath10k driver.
>
> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Patch applied to ath-next branch of ath.git, thanks.
4be3b05e7a83 ath10k: remove duplicated includes
--
https://patchwork.kernel.org/patch/10599605/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH] ath9k: debug: remove set but not used variable 'fops_dump_nfcal'
From: Kalle Valo @ 2018-10-01 14:06 UTC (permalink / raw)
To: YueHaibing
Cc: ath9k-devel, linux-kernel, netdev, davem, linux-wireless,
YueHaibing
In-Reply-To: <20180910031128.12164-1-yuehaibing@huawei.com>
YueHaibing <yuehaibing@huawei.com> wrote:
> 'fops_dump_nfcal' is not used since commit 4447d815fd0f ("ath: ath9k: use debugfs_create_devm_seqfile() helper for seq_file entries")
>
> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Patch applied to ath-next branch of ath.git, thanks.
b8f3d1635103 ath9k: debug: remove set but not used variable 'fops_dump_nfcal'
--
https://patchwork.kernel.org/patch/10593539/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox