* Re: [PATCH bpf-next v10 2/4] bpf: new helper to obtain namespace data from current task New bpf helper bpf_get_current_pidns_info.
From: Carlos Antonio Neira Bustos @ 2019-09-09 17:45 UTC (permalink / raw)
To: Yonghong Song
Cc: Al Viro, netdev@vger.kernel.org, ebiederm@xmission.com,
brouer@redhat.com, bpf@vger.kernel.org
In-Reply-To: <7d196a64-cf36-c2d5-7328-154aaeb929eb@fb.com>
Thanks a lot, Al Viro and Yonghong for taking the time to review this patch and
provide technical insights needed on this one.
But how do we move this forward?
Al Viro's review is clear that this will not work and we should strip the name
resolution code (thanks for your detailed analysis).
As there is currently only one instance of the nsfs device on the system,
I think we could leave out the retrieval of the pidns device number and address it
when the situation changes.
What do you think?
On Sat, Sep 07, 2019 at 06:34:39AM +0000, Yonghong Song wrote:
>
>
> On 9/6/19 5:10 PM, Al Viro wrote:
> > On Fri, Sep 06, 2019 at 11:21:14PM +0000, Yonghong Song wrote:
> >
> >> -bash-4.4$ readlink /proc/self/ns/pid
> >> pid:[4026531836]
> >> -bash-4.4$ stat /proc/self/ns/pid
> >> File: ‘/proc/self/ns/pid’ -> ‘pid:[4026531836]’
> >> Size: 0 Blocks: 0 IO Block: 1024 symbolic link
> >> Device: 4h/4d Inode: 344795989 Links: 1
> >> Access: (0777/lrwxrwxrwx) Uid: (128203/ yhs) Gid: ( 100/ users)
> >> Context: user_u:base_r:base_t
> >> Access: 2019-09-06 16:06:09.431616380 -0700
> >> Modify: 2019-09-06 16:06:09.431616380 -0700
> >> Change: 2019-09-06 16:06:09.431616380 -0700
> >> Birth: -
> >> -bash-4.4$
> >>
> >> Based on a discussion with Eric Biederman back in 2019 Linux
> >> Plumbers, Eric suggested that to uniquely identify a
> >> namespace, device id (major/minor) number should also
> >> be included. Although today's kernel implementation
> >> has the same device for all namespace pseudo files,
> >> but from uapi perspective, device id should be included.
> >>
> >> That is the reason why we try to get device id which holds
> >> pid namespace pseudo file.
> >>
> >> Do you have a better suggestion on how to get
> >> the device id for 'current' pid namespace? Or from design, we
> >> really should not care about device id at all?
> >
> > What the hell is "device id for pid namespace"? This is the
> > first time I've heard about that mystery object, so it's
> > hard to tell where it could be found.
> >
> > I can tell you what device numbers are involved in the areas
> > you seem to be looking in.
> >
> > 1) there's whatever device number that gets assigned to
> > (this) procfs instance. That, ironically, _is_ per-pidns, but
> > that of the procfs instance, not that of your process (and
> > those can be different). That's what you get in ->st_dev
> > when doing lstat() of anything in /proc (assuming that
> > procfs is mounted there, in the first place). NOTE:
> > that's lstat(2), not stat(2). stat(1) uses lstat(2),
> > unless given -L (in which case it's stat(2) time). The
> > difference:
> >
> > root@kvm1:~# stat /proc/self/ns/pid
> > File: /proc/self/ns/pid -> pid:[4026531836]
> > Size: 0 Blocks: 0 IO Block: 1024 symbolic link
> > Device: 4h/4d Inode: 17396 Links: 1
> > Access: (0777/lrwxrwxrwx) Uid: ( 0/ root) Gid: ( 0/ root)
> > Access: 2019-09-06 19:43:11.871312319 -0400
> > Modify: 2019-09-06 19:43:11.871312319 -0400
> > Change: 2019-09-06 19:43:11.871312319 -0400
> > Birth: -
> > root@kvm1:~# stat -L /proc/self/ns/pid
> > File: /proc/self/ns/pid
> > Size: 0 Blocks: 0 IO Block: 4096 regular empty file
> > Device: 3h/3d Inode: 4026531836 Links: 1
> > Access: (0444/-r--r--r--) Uid: ( 0/ root) Gid: ( 0/ root)
> > Access: 2019-09-06 19:43:15.955313293 -0400
> > Modify: 2019-09-06 19:43:15.955313293 -0400
> > Change: 2019-09-06 19:43:15.955313293 -0400
> > Birth: -
> >
> > The former is lstat, the latter - stat.
> >
> > 2) device number of the filesystem where the symlink target lives.
> > In this case, it's nsfs and there's only one instance on the entire
> > system. _That_ would be obtained by looking at st_dev in stat(2) on
> > /proc/self/ns/pid (0:3 above).
> >
> > 3) device number *OF* the symlink. That would be st_rdev in lstat(2).
> > There's none - it's a symlink, not a character or block device. It's
> > always zero and always will be zero.
> >
> > 4) the same for the target; st_rdev in stat(2) results and again,
> > there's no such beast - it's neither character nor block device.
> >
> > Your code is looking at (3). Please, reread any textbook on Unix
> > in the section that would cover stat(2) and discussion of the
> > difference between st_dev and st_rdev.
> >
> > I have no idea what Eric had been talking about - it's hard to
> > reconstruct by what you said so far. Making nsfs per-userns,
> > perhaps? But that makes no sense whatsoever, not that userns
> > ever had... Cheap shots aside, I really can't guess what that's
> > about. Sorry.
>
> Thanks for the detailed information. The device number we want
> is nsfs. Indeed, currently, there is only one instance
> on the entire system. But not exactly sure what is the possibility
> to have more than one nsfs device in the future. Maybe per-userns
> or any other criteria?
>
> >
> > In any case, pathname resolution is *NOT* for the situations where
> > you can't block. Even if it's procfs (and from the same pidns as
> > the process) mounted there, there is no promise that the target
> > of /proc/self has already been looked up and not evicted from
> > memory since then. And in case of cache miss pathwalk will
> > have to call ->lookup(), which requires locking the directory
> > (rw_sem, shared). You can't do that in such context.
> >
> > And that doesn't even go into the possibility that process has
> > something very different mounted on /proc.
> >
> > Again, I don't know what it is that you want to get to, but
> > I would strongly recommend finding a way to get to that data
> > that would not involve going anywhere near pathname resolution.
> >
> > How would you expect the userland to work with that value,
> > whatever it might be? If it's just a 32bit field that will
> > never be read, you might as well store there the same value
> > you store now (0, that is) in much cheaper and safer way ;-)
>
> Suppose inside pid namespace, user can pass the device number,
> say n1, (`stat -L /proc/self/ns/pid`) to bpf program (through map
> or JIT). At runtime, bpf program will try to get device number,
> say n2, for the 'current' process. If n1 is not the same as
> n2, that means they are not in the same namespace. 'current'
> is in the same pid namespace as the user iff
> n1 == n2 and also pidns id is the same for 'current' and
> the one with `lsns -t pid`.
>
> Are you aware of any way to get the pidns device number
> for 'current' without going through the pathname
> lookup?
>
^ permalink raw reply
* Re: [PATCH v4 2/2] net: phy: dp83867: Add SGMII mode type switching
From: Trent Piepho @ 2019-09-09 17:40 UTC (permalink / raw)
To: vitaly.gaiduk@cloudbear.ru, davem@davemloft.net,
f.fainelli@gmail.com, robh+dt@kernel.org
Cc: mark.rutland@arm.com, hkallweit1@gmail.com,
netdev@vger.kernel.org, andrew@lunn.ch,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <1568049566-16708-1-git-send-email-vitaly.gaiduk@cloudbear.ru>
On Mon, 2019-09-09 at 20:19 +0300, Vitaly Gaiduk wrote:
> This patch adds ability to switch beetween two PHY SGMII modes.
> Some hardware, for example, FPGA IP designs may use 6-wire mode
> which enables differential SGMII clock to MAC.
>
> +
> + val = phy_read_mmd(phydev, DP83867_DEVADDR, DP83867_SGMIICTL);
> + /* SGMII type is set to 4-wire mode by default.
> + * If we place appropriate property in dts (see above)
> + * switch on 6-wire mode.
> + */
> + if (dp83867->sgmii_ref_clk_en)
> + val |= DP83867_SGMII_TYPE;
> + else
> + val &= ~DP83867_SGMII_TYPE;
> + phy_write_mmd(phydev, DP83867_DEVADDR, DP83867_SGMIICTL, val);
Should use phy_modify_mmd().
^ permalink raw reply
* [PATCH v4 2/2] net: phy: dp83867: Add SGMII mode type switching
From: Vitaly Gaiduk @ 2019-09-09 17:19 UTC (permalink / raw)
To: davem, robh+dt, f.fainelli
Cc: Vitaly Gaiduk, Mark Rutland, Andrew Lunn, Heiner Kallweit,
Trent Piepho, netdev, devicetree, linux-kernel
In-Reply-To: <1568047940-14490-2-git-send-email-vitaly.gaiduk@cloudbear.ru>
This patch adds ability to switch beetween two PHY SGMII modes.
Some hardware, for example, FPGA IP designs may use 6-wire mode
which enables differential SGMII clock to MAC.
Signed-off-by: Vitaly Gaiduk <vitaly.gaiduk@cloudbear.ru>
---
drivers/net/phy/dp83867.c | 19 +++++++++++++++++++
1 file changed, 19 insertions(+)
diff --git a/drivers/net/phy/dp83867.c b/drivers/net/phy/dp83867.c
index 1f1ecee..37fceaf 100644
--- a/drivers/net/phy/dp83867.c
+++ b/drivers/net/phy/dp83867.c
@@ -37,6 +37,7 @@
#define DP83867_STRAP_STS2 0x006f
#define DP83867_RGMIIDCTL 0x0086
#define DP83867_IO_MUX_CFG 0x0170
+#define DP83867_SGMIICTL 0x00D3
#define DP83867_10M_SGMII_CFG 0x016F
#define DP83867_10M_SGMII_RATE_ADAPT_MASK BIT(7)
@@ -61,6 +62,9 @@
#define DP83867_RGMII_TX_CLK_DELAY_EN BIT(1)
#define DP83867_RGMII_RX_CLK_DELAY_EN BIT(0)
+/* SGMIICTL bits */
+#define DP83867_SGMII_TYPE BIT(14)
+
/* STRAP_STS1 bits */
#define DP83867_STRAP_STS1_RESERVED BIT(11)
@@ -109,6 +113,7 @@ struct dp83867_private {
bool rxctrl_strap_quirk;
bool set_clk_output;
u32 clk_output_sel;
+ bool sgmii_ref_clk_en;
};
static int dp83867_ack_interrupt(struct phy_device *phydev)
@@ -197,6 +202,9 @@ static int dp83867_of_init(struct phy_device *phydev)
dp83867->rxctrl_strap_quirk = of_property_read_bool(of_node,
"ti,dp83867-rxctrl-strap-quirk");
+ dp83867->sgmii_ref_clk_en = of_property_read_bool(of_node,
+ "ti,sgmii-ref-clock-output-enable");
+
/* Existing behavior was to use default pin strapping delay in rgmii
* mode, but rgmii should have meant no delay. Warn existing users.
*/
@@ -389,6 +397,17 @@ static int dp83867_config_init(struct phy_device *phydev)
if (ret)
return ret;
+
+ val = phy_read_mmd(phydev, DP83867_DEVADDR, DP83867_SGMIICTL);
+ /* SGMII type is set to 4-wire mode by default.
+ * If we place appropriate property in dts (see above)
+ * switch on 6-wire mode.
+ */
+ if (dp83867->sgmii_ref_clk_en)
+ val |= DP83867_SGMII_TYPE;
+ else
+ val &= ~DP83867_SGMII_TYPE;
+ phy_write_mmd(phydev, DP83867_DEVADDR, DP83867_SGMIICTL, val);
}
/* Enable Interrupt output INT_OE in CFG3 register */
--
2.7.4
^ permalink raw reply related
* [PATCH v4 1/2] net: phy: dp83867: Add documentation for SGMII mode type
From: Vitaly Gaiduk @ 2019-09-09 17:19 UTC (permalink / raw)
To: davem, robh+dt, f.fainelli
Cc: Vitaly Gaiduk, Mark Rutland, Andrew Lunn, Trent Piepho, netdev,
devicetree, linux-kernel
In-Reply-To: <1568049566-16708-1-git-send-email-vitaly.gaiduk@cloudbear.ru>
Add documentation of ti,sgmii-ref-clock-output-enable
which can be used to select SGMII mode type (4 or 6-wire).
Signed-off-by: Vitaly Gaiduk <vitaly.gaiduk@cloudbear.ru>
---
Changes in v4:
- Fixed the wording of property
Documentation/devicetree/bindings/net/ti,dp83867.txt | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/Documentation/devicetree/bindings/net/ti,dp83867.txt b/Documentation/devicetree/bindings/net/ti,dp83867.txt
index db6aa3f..388ff48 100644
--- a/Documentation/devicetree/bindings/net/ti,dp83867.txt
+++ b/Documentation/devicetree/bindings/net/ti,dp83867.txt
@@ -37,6 +37,10 @@ Optional property:
for applicable values. The CLK_OUT pin can also
be disabled by this property. When omitted, the
PHY's default will be left as is.
+ - ti,sgmii-ref-clock-output-enable - This denotes which
+ SGMII configuration is used (4 or 6-wire modes).
+ Some MACs work with differential SGMII clock.
+ See data manual for details.
Note: ti,min-output-impedance and ti,max-output-impedance are mutually
exclusive. When both properties are present ti,max-output-impedance
--
2.7.4
^ permalink raw reply related
* [PATCH v3 2/2] net: phy: dp83867: Add SGMII mode type switching
From: Vitaly Gaiduk @ 2019-09-09 16:52 UTC (permalink / raw)
To: davem, robh+dt, f.fainelli
Cc: Vitaly Gaiduk, Mark Rutland, Andrew Lunn, Heiner Kallweit,
Trent Piepho, netdev, devicetree, linux-kernel
In-Reply-To: <1568026945-3857-1-git-send-email-vitaly.gaiduk@cloudbear.ru>
This patch adds ability to switch beetween two PHY SGMII modes.
Some hardware, for example, FPGA IP designs may use 6-wire mode
which enables differential SGMII clock to MAC.
Signed-off-by: Vitaly Gaiduk <vitaly.gaiduk@cloudbear.ru>
---
Changes in v3:
- Fixed retaining DP83867_SGMII_TYPE bit
drivers/net/phy/dp83867.c | 19 +++++++++++++++++++
1 file changed, 19 insertions(+)
diff --git a/drivers/net/phy/dp83867.c b/drivers/net/phy/dp83867.c
index 1f1ecee..37fceaf 100644
--- a/drivers/net/phy/dp83867.c
+++ b/drivers/net/phy/dp83867.c
@@ -37,6 +37,7 @@
#define DP83867_STRAP_STS2 0x006f
#define DP83867_RGMIIDCTL 0x0086
#define DP83867_IO_MUX_CFG 0x0170
+#define DP83867_SGMIICTL 0x00D3
#define DP83867_10M_SGMII_CFG 0x016F
#define DP83867_10M_SGMII_RATE_ADAPT_MASK BIT(7)
@@ -61,6 +62,9 @@
#define DP83867_RGMII_TX_CLK_DELAY_EN BIT(1)
#define DP83867_RGMII_RX_CLK_DELAY_EN BIT(0)
+/* SGMIICTL bits */
+#define DP83867_SGMII_TYPE BIT(14)
+
/* STRAP_STS1 bits */
#define DP83867_STRAP_STS1_RESERVED BIT(11)
@@ -109,6 +113,7 @@ struct dp83867_private {
bool rxctrl_strap_quirk;
bool set_clk_output;
u32 clk_output_sel;
+ bool sgmii_ref_clk_en;
};
static int dp83867_ack_interrupt(struct phy_device *phydev)
@@ -197,6 +202,9 @@ static int dp83867_of_init(struct phy_device *phydev)
dp83867->rxctrl_strap_quirk = of_property_read_bool(of_node,
"ti,dp83867-rxctrl-strap-quirk");
+ dp83867->sgmii_ref_clk_en = of_property_read_bool(of_node,
+ "ti,sgmii-ref-clock-output-enable");
+
/* Existing behavior was to use default pin strapping delay in rgmii
* mode, but rgmii should have meant no delay. Warn existing users.
*/
@@ -389,6 +397,17 @@ static int dp83867_config_init(struct phy_device *phydev)
if (ret)
return ret;
+
+ val = phy_read_mmd(phydev, DP83867_DEVADDR, DP83867_SGMIICTL);
+ /* SGMII type is set to 4-wire mode by default.
+ * If we place appropriate property in dts (see above)
+ * switch on 6-wire mode.
+ */
+ if (dp83867->sgmii_ref_clk_en)
+ val |= DP83867_SGMII_TYPE;
+ else
+ val &= ~DP83867_SGMII_TYPE;
+ phy_write_mmd(phydev, DP83867_DEVADDR, DP83867_SGMIICTL, val);
}
/* Enable Interrupt output INT_OE in CFG3 register */
--
2.7.4
^ permalink raw reply related
* Re: [PATCH v3 1/2] net: phy: dp83867: Add documentation for SGMII mode type
From: Florian Fainelli @ 2019-09-09 16:56 UTC (permalink / raw)
To: Vitaly Gaiduk, davem, robh+dt
Cc: Mark Rutland, Trent Piepho, Andrew Lunn, netdev, devicetree,
linux-kernel
In-Reply-To: <1568047940-14490-2-git-send-email-vitaly.gaiduk@cloudbear.ru>
On 9/9/19 9:52 AM, Vitaly Gaiduk wrote:
> Add documentation of ti,sgmii-ref-clock-output-enable
> which can be used to select SGMII mode type (4 or 6-wire).
>
> Signed-off-by: Vitaly Gaiduk <vitaly.gaiduk@cloudbear.ru>
> ---
> Documentation/devicetree/bindings/net/ti,dp83867.txt | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/net/ti,dp83867.txt b/Documentation/devicetree/bindings/net/ti,dp83867.txt
> index db6aa3f..c98c682 100644
> --- a/Documentation/devicetree/bindings/net/ti,dp83867.txt
> +++ b/Documentation/devicetree/bindings/net/ti,dp83867.txt
> @@ -37,6 +37,10 @@ Optional property:
> for applicable values. The CLK_OUT pin can also
> be disabled by this property. When omitted, the
> PHY's default will be left as is.
> + - ti,sgmii-ref-clock-output-enable - This denotes the fact which
> + SGMII configuration is used (4 or 6-wire modes).
> + Some MACs work with differential SGMII clock.
> + See data manual for details.
The wording is a bit odd here, I would just omit "the fact" to make the
sentence more readable. With that:
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
--
Florian
^ permalink raw reply
* Re: [PATCH v3 2/2] net: phy: dp83867: Add SGMII mode type switching
From: Florian Fainelli @ 2019-09-09 16:56 UTC (permalink / raw)
To: Vitaly Gaiduk, davem, robh+dt
Cc: Mark Rutland, Andrew Lunn, Heiner Kallweit, Trent Piepho, netdev,
devicetree, linux-kernel
In-Reply-To: <1568047940-14490-1-git-send-email-vitaly.gaiduk@cloudbear.ru>
On 9/9/19 9:52 AM, Vitaly Gaiduk wrote:
> This patch adds ability to switch beetween two PHY SGMII modes.
> Some hardware, for example, FPGA IP designs may use 6-wire mode
> which enables differential SGMII clock to MAC.
>
> Signed-off-by: Vitaly Gaiduk <vitaly.gaiduk@cloudbear.ru>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
--
Florian
^ permalink raw reply
* [PATCH net-next] net: stmmac: pci: Add HAPS support using GMAC5
From: Jose Abreu @ 2019-09-09 16:54 UTC (permalink / raw)
To: netdev
Cc: Joao Pinto, Jose Abreu, Giuseppe Cavallaro, Alexandre Torgue,
David S. Miller, Maxime Coquelin, linux-stm32, linux-arm-kernel,
linux-kernel
Add the support for Synopsys HAPS board that uses GMAC5.
Signed-off-by: Jose Abreu <joabreu@synopsys.com>
---
Cc: Giuseppe Cavallaro <peppe.cavallaro@st.com>
Cc: Alexandre Torgue <alexandre.torgue@st.com>
Cc: Jose Abreu <joabreu@synopsys.com>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Maxime Coquelin <mcoquelin.stm32@gmail.com>
Cc: netdev@vger.kernel.org
Cc: linux-stm32@st-md-mailman.stormreply.com
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
---
drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c | 71 ++++++++++++++++++++++++
1 file changed, 71 insertions(+)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c
index 20906287b6d4..292045f4581f 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c
@@ -375,6 +375,75 @@ static const struct stmmac_pci_info quark_pci_info = {
.setup = quark_default_data,
};
+static int snps_gmac5_default_data(struct pci_dev *pdev,
+ struct plat_stmmacenet_data *plat)
+{
+ int i;
+
+ plat->clk_csr = 5;
+ plat->has_gmac4 = 1;
+ plat->force_sf_dma_mode = 1;
+ plat->tso_en = 1;
+ plat->pmt = 1;
+
+ plat->mdio_bus_data->phy_mask = 0;
+
+ /* Set default value for multicast hash bins */
+ plat->multicast_filter_bins = HASH_TABLE_SIZE;
+
+ /* Set default value for unicast filter entries */
+ plat->unicast_filter_entries = 1;
+
+ /* Set the maxmtu to a default of JUMBO_LEN */
+ plat->maxmtu = JUMBO_LEN;
+
+ /* Set default number of RX and TX queues to use */
+ plat->tx_queues_to_use = 4;
+ plat->rx_queues_to_use = 4;
+
+ plat->tx_sched_algorithm = MTL_TX_ALGORITHM_WRR;
+ for (i = 0; i < plat->tx_queues_to_use; i++) {
+ plat->tx_queues_cfg[i].use_prio = false;
+ plat->tx_queues_cfg[i].mode_to_use = MTL_QUEUE_DCB;
+ plat->tx_queues_cfg[i].weight = 25;
+ }
+
+ plat->rx_sched_algorithm = MTL_RX_ALGORITHM_SP;
+ for (i = 0; i < plat->rx_queues_to_use; i++) {
+ plat->rx_queues_cfg[i].use_prio = false;
+ plat->rx_queues_cfg[i].mode_to_use = MTL_QUEUE_DCB;
+ plat->rx_queues_cfg[i].pkt_route = 0x0;
+ plat->rx_queues_cfg[i].chan = i;
+ }
+
+ plat->bus_id = 1;
+ plat->phy_addr = -1;
+ plat->interface = PHY_INTERFACE_MODE_GMII;
+
+ plat->dma_cfg->pbl = 32;
+ plat->dma_cfg->pblx8 = true;
+
+ /* Axi Configuration */
+ plat->axi = devm_kzalloc(&pdev->dev, sizeof(*plat->axi), GFP_KERNEL);
+ if (!plat->axi)
+ return -ENOMEM;
+
+ plat->axi->axi_wr_osr_lmt = 31;
+ plat->axi->axi_rd_osr_lmt = 31;
+
+ plat->axi->axi_fb = false;
+ plat->axi->axi_blen[0] = 4;
+ plat->axi->axi_blen[1] = 8;
+ plat->axi->axi_blen[2] = 16;
+ plat->axi->axi_blen[3] = 32;
+
+ return 0;
+}
+
+static const struct stmmac_pci_info snps_gmac5_pci_info = {
+ .setup = snps_gmac5_default_data,
+};
+
/**
* stmmac_pci_probe
*
@@ -518,6 +587,7 @@ static SIMPLE_DEV_PM_OPS(stmmac_pm_ops, stmmac_pci_suspend, stmmac_pci_resume);
#define STMMAC_EHL_RGMII1G_ID 0x4b30
#define STMMAC_EHL_SGMII1G_ID 0x4b31
#define STMMAC_TGL_SGMII1G_ID 0xa0ac
+#define STMMAC_GMAC5_ID 0x7102
#define STMMAC_DEVICE(vendor_id, dev_id, info) { \
PCI_VDEVICE(vendor_id, dev_id), \
@@ -531,6 +601,7 @@ static const struct pci_device_id stmmac_id_table[] = {
STMMAC_DEVICE(INTEL, STMMAC_EHL_RGMII1G_ID, ehl_rgmii1g_pci_info),
STMMAC_DEVICE(INTEL, STMMAC_EHL_SGMII1G_ID, ehl_sgmii1g_pci_info),
STMMAC_DEVICE(INTEL, STMMAC_TGL_SGMII1G_ID, tgl_sgmii1g_pci_info),
+ STMMAC_DEVICE(SYNOPSYS, STMMAC_GMAC5_ID, snps_gmac5_pci_info),
{}
};
--
2.7.4
^ permalink raw reply related
* [PATCH v3 1/2] net: phy: dp83867: Add documentation for SGMII mode type
From: Vitaly Gaiduk @ 2019-09-09 16:52 UTC (permalink / raw)
To: davem, robh+dt, f.fainelli
Cc: Vitaly Gaiduk, Mark Rutland, Trent Piepho, Andrew Lunn, netdev,
devicetree, linux-kernel
In-Reply-To: <1568047940-14490-1-git-send-email-vitaly.gaiduk@cloudbear.ru>
Add documentation of ti,sgmii-ref-clock-output-enable
which can be used to select SGMII mode type (4 or 6-wire).
Signed-off-by: Vitaly Gaiduk <vitaly.gaiduk@cloudbear.ru>
---
Documentation/devicetree/bindings/net/ti,dp83867.txt | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/Documentation/devicetree/bindings/net/ti,dp83867.txt b/Documentation/devicetree/bindings/net/ti,dp83867.txt
index db6aa3f..c98c682 100644
--- a/Documentation/devicetree/bindings/net/ti,dp83867.txt
+++ b/Documentation/devicetree/bindings/net/ti,dp83867.txt
@@ -37,6 +37,10 @@ Optional property:
for applicable values. The CLK_OUT pin can also
be disabled by this property. When omitted, the
PHY's default will be left as is.
+ - ti,sgmii-ref-clock-output-enable - This denotes the fact which
+ SGMII configuration is used (4 or 6-wire modes).
+ Some MACs work with differential SGMII clock.
+ See data manual for details.
Note: ti,min-output-impedance and ti,max-output-impedance are mutually
exclusive. When both properties are present ti,max-output-impedance
--
2.7.4
^ permalink raw reply related
* Re: [PATCH v3] net: phy: dp83867: Add SGMII mode type switching
From: Florian Fainelli @ 2019-09-09 16:40 UTC (permalink / raw)
To: Vitaly Gaiduk, davem, robh+dt
Cc: Andrew Lunn, Heiner Kallweit, netdev, linux-kernel
In-Reply-To: <1568044937-12526-1-git-send-email-vitaly.gaiduk@cloudbear.ru>
On 9/9/19 9:02 AM, Vitaly Gaiduk wrote:
> This patch adds ability to switch beetween two PHY SGMII modes.
> Some hardware, for example, FPGA IP designs may use 6-wire mode
> which enables differential SGMII clock to MAC.
>
> Signed-off-by: Vitaly Gaiduk <vitaly.gaiduk@cloudbear.ru>
Thanks for addressing my comments, please re-post the entire patch
series per:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/networking/netdev-FAQ.rst#n134
Thanks!
--
Florian
^ permalink raw reply
* RE: [PATCH net-next 1/5] enetc: Fix if_mode extraction
From: Claudiu Manoil @ 2019-09-09 16:24 UTC (permalink / raw)
To: Andrew Lunn; +Cc: David S . Miller, Alexandru Marginean, netdev@vger.kernel.org
In-Reply-To: <20190906195743.GD2339@lunn.ch>
>-----Original Message-----
>From: Andrew Lunn <andrew@lunn.ch>
>Sent: Friday, September 6, 2019 10:58 PM
>To: Claudiu Manoil <claudiu.manoil@nxp.com>
>Cc: David S . Miller <davem@davemloft.net>; Alexandru Marginean
><alexandru.marginean@nxp.com>; netdev@vger.kernel.org
>Subject: Re: [PATCH net-next 1/5] enetc: Fix if_mode extraction
>
>On Fri, Sep 06, 2019 at 05:15:40PM +0300, Claudiu Manoil wrote:
>> Fix handling of error return code. Before this fix,
>> the error code was handled as unsigned type.
>> Also, on this path if if_mode not found then just handle
>> it as fixed link (i.e mac2mac connection).
>>
>> Signed-off-by: Claudiu Manoil <claudiu.manoil@nxp.com>
>> ---
>> drivers/net/ethernet/freescale/enetc/enetc_pf.c | 17 ++++++-----------
>> 1 file changed, 6 insertions(+), 11 deletions(-)
>>
>> diff --git a/drivers/net/ethernet/freescale/enetc/enetc_pf.c
>b/drivers/net/ethernet/freescale/enetc/enetc_pf.c
>> index 7d6513ff8507..3a556646a2fb 100644
>> --- a/drivers/net/ethernet/freescale/enetc/enetc_pf.c
>> +++ b/drivers/net/ethernet/freescale/enetc/enetc_pf.c
>> @@ -751,6 +751,7 @@ static int enetc_of_get_phy(struct enetc_ndev_priv
>*priv)
>> struct enetc_pf *pf = enetc_si_priv(priv->si);
>> struct device_node *np = priv->dev->of_node;
>> struct device_node *mdio_np;
>> + int phy_mode;
>> int err;
>>
>> if (!np) {
>> @@ -784,17 +785,11 @@ static int enetc_of_get_phy(struct enetc_ndev_priv
>*priv)
>> }
>> }
>>
>> - priv->if_mode = of_get_phy_mode(np);
>> - if (priv->if_mode < 0) {
>> - dev_err(priv->dev, "missing phy type\n");
>> - of_node_put(priv->phy_node);
>> - if (of_phy_is_fixed_link(np))
>> - of_phy_deregister_fixed_link(np);
>> - else
>> - enetc_mdio_remove(pf);
>> -
>> - return -EINVAL;
>> - }
>
>Hi Claudiu
>
>It is not clear to me why it is no longer necessary to deregister the
>fixed link, or remove the mdio bus?
>
>> + phy_mode = of_get_phy_mode(np);
>> + if (phy_mode < 0)
>> + priv->if_mode = PHY_INTERFACE_MODE_NA; /* fixed link */
>> + else
>> + priv->if_mode = phy_mode;
>
Hi Andrew,
The MAC2MAC connections are defined as fixed-link too, but without
phy-mode/phy-connection-type properties. We don't want to de-register
these links. Initial code was bogus in this regard. So this MODE_NA interface
mode is reserved for the current representation of enetc ethernet ports
that are MAC2MAC connected with switch ports. Also true that the current
upstream driver does not have the MAC2MAC connections enabled.
Your question however leads to the following discussion 😊. The LS1028 SoC
has internal MAC2MAC connections between enetc eth ports and switch ports.
However the switch driver for LS1028a is not available upstream yet, it needs
to be re-worked as a DSA driver as you know (if you remember the discussions
we had on switchdev vs DSA for the Felix driver). Now that we're at it, how
would you like to represent these MAC2MAC connections?
Current proposal is:
ethernet@0,2 { /* SoC internal, connected to switch port 4 */
compatible = "fsl,enetc";
reg = <0x000200 0 0 0 0>;
fixed-link {
speed = <1000>;
full-duplex;
};
};
switch@0,5 {
compatible = "mscc,felix-switch";
[...]
ports {
#address-cells = <1>;
#size-cells = <0>;
/* external ports */
[...]
/* internal SoC ports */
port@4 { /* connected to ENETC port2 */
reg = <4>;
fixed-link {
speed = <1000>;
full-duplex;
};
};
port@5 { /* CPU port, connected to ENETC port3 */
reg = <5>;
ethernet = <&enetc_port3>;
fixed-link {
speed = <1000>;
full-duplex;
};
};
};
};
enetc_port3: ethernet@0,6 { /* SoC internal connected to switch port 5 */
compatible = "fsl,enetc";
reg = <0x000600 0 0 0 0>;
fixed-link {
speed = <1000>;
full-duplex;
};
};
};
Thanks.
Claudiu
^ permalink raw reply
* RE: [PATCH net-next v2 1/2] net: stmmac: Only enable enhanced addressing mode when needed
From: Jose Abreu @ 2019-09-09 16:07 UTC (permalink / raw)
To: Thierry Reding, David S . Miller
Cc: Giuseppe Cavallaro, Alexandre Torgue, Jon Hunter, Bitan Biswas,
netdev@vger.kernel.org, linux-tegra@vger.kernel.org
In-Reply-To: <20190909152546.383-1-thierry.reding@gmail.com>
From: Thierry Reding <thierry.reding@gmail.com>
Date: Sep/09/2019, 16:25:45 (UTC+00:00)
> @@ -92,6 +92,7 @@ struct stmmac_dma_cfg {
> int fixed_burst;
> int mixed_burst;
> bool aal;
> + bool eame;
bools should not be used in struct's, please change to int.
---
Thanks,
Jose Miguel Abreu
^ permalink raw reply
* RE: [PATCH net-next v2 2/2] net: stmmac: Support enhanced addressing mode for DWMAC 4.10
From: Jose Abreu @ 2019-09-09 16:05 UTC (permalink / raw)
To: Thierry Reding, David S . Miller
Cc: Giuseppe Cavallaro, Alexandre Torgue, Jon Hunter, Bitan Biswas,
netdev@vger.kernel.org, linux-tegra@vger.kernel.org
In-Reply-To: <20190909152546.383-2-thierry.reding@gmail.com>
From: Thierry Reding <thierry.reding@gmail.com>
Date: Sep/09/2019, 16:25:46 (UTC+00:00)
> @@ -79,6 +79,10 @@ static void dwmac4_dma_init_rx_chan(void __iomem *ioaddr,
> value = value | (rxpbl << DMA_BUS_MODE_RPBL_SHIFT);
> writel(value, ioaddr + DMA_CHAN_RX_CONTROL(chan));
>
> + if (dma_cfg->eame)
There is no need for this check. If EAME is not enabled then upper 32
bits will be zero.
> + writel(upper_32_bits(dma_rx_phy),
> + ioaddr + DMA_CHAN_RX_BASE_ADDR_HI(chan));
> +
> writel(lower_32_bits(dma_rx_phy), ioaddr + DMA_CHAN_RX_BASE_ADDR(chan));
> }
> @@ -97,6 +101,10 @@ static void dwmac4_dma_init_tx_chan(void __iomem *ioaddr,
>
> writel(value, ioaddr + DMA_CHAN_TX_CONTROL(chan));
>
> + if (dma_cfg->eame)
Same here.
> + writel(upper_32_bits(dma_tx_phy),
> + ioaddr + DMA_CHAN_TX_BASE_ADDR_HI(chan));
> +
> writel(lower_32_bits(dma_tx_phy), ioaddr + DMA_CHAN_TX_BASE_ADDR(chan));
> }
Also, please provide a cover letter in next submission.
---
Thanks,
Jose Miguel Abreu
^ permalink raw reply
* [PATCH v3] net: phy: dp83867: Add SGMII mode type switching
From: Vitaly Gaiduk @ 2019-09-09 16:02 UTC (permalink / raw)
To: davem, robh+dt, f.fainelli
Cc: Vitaly Gaiduk, Andrew Lunn, Heiner Kallweit, netdev, linux-kernel
In-Reply-To: <1568026945-3857-1-git-send-email-vitaly.gaiduk@cloudbear.ru>
This patch adds ability to switch beetween two PHY SGMII modes.
Some hardware, for example, FPGA IP designs may use 6-wire mode
which enables differential SGMII clock to MAC.
Signed-off-by: Vitaly Gaiduk <vitaly.gaiduk@cloudbear.ru>
---
Changes in v3:
- Fixed retaining DP83867_SGMII_TYPE bit
drivers/net/phy/dp83867.c | 19 +++++++++++++++++++
1 file changed, 19 insertions(+)
diff --git a/drivers/net/phy/dp83867.c b/drivers/net/phy/dp83867.c
index 1f1ecee..37fceaf 100644
--- a/drivers/net/phy/dp83867.c
+++ b/drivers/net/phy/dp83867.c
@@ -37,6 +37,7 @@
#define DP83867_STRAP_STS2 0x006f
#define DP83867_RGMIIDCTL 0x0086
#define DP83867_IO_MUX_CFG 0x0170
+#define DP83867_SGMIICTL 0x00D3
#define DP83867_10M_SGMII_CFG 0x016F
#define DP83867_10M_SGMII_RATE_ADAPT_MASK BIT(7)
@@ -61,6 +62,9 @@
#define DP83867_RGMII_TX_CLK_DELAY_EN BIT(1)
#define DP83867_RGMII_RX_CLK_DELAY_EN BIT(0)
+/* SGMIICTL bits */
+#define DP83867_SGMII_TYPE BIT(14)
+
/* STRAP_STS1 bits */
#define DP83867_STRAP_STS1_RESERVED BIT(11)
@@ -109,6 +113,7 @@ struct dp83867_private {
bool rxctrl_strap_quirk;
bool set_clk_output;
u32 clk_output_sel;
+ bool sgmii_ref_clk_en;
};
static int dp83867_ack_interrupt(struct phy_device *phydev)
@@ -197,6 +202,9 @@ static int dp83867_of_init(struct phy_device *phydev)
dp83867->rxctrl_strap_quirk = of_property_read_bool(of_node,
"ti,dp83867-rxctrl-strap-quirk");
+ dp83867->sgmii_ref_clk_en = of_property_read_bool(of_node,
+ "ti,sgmii-ref-clock-output-enable");
+
/* Existing behavior was to use default pin strapping delay in rgmii
* mode, but rgmii should have meant no delay. Warn existing users.
*/
@@ -389,6 +397,17 @@ static int dp83867_config_init(struct phy_device *phydev)
if (ret)
return ret;
+
+ val = phy_read_mmd(phydev, DP83867_DEVADDR, DP83867_SGMIICTL);
+ /* SGMII type is set to 4-wire mode by default.
+ * If we place appropriate property in dts (see above)
+ * switch on 6-wire mode.
+ */
+ if (dp83867->sgmii_ref_clk_en)
+ val |= DP83867_SGMII_TYPE;
+ else
+ val &= ~DP83867_SGMII_TYPE;
+ phy_write_mmd(phydev, DP83867_DEVADDR, DP83867_SGMIICTL, val);
}
/* Enable Interrupt output INT_OE in CFG3 register */
--
2.7.4
^ permalink raw reply related
* [PATCH iproute2-next] bpf: replace snprintf with asprintf when dealing with long buffers
From: Andrea Claudi @ 2019-09-09 16:05 UTC (permalink / raw)
To: netdev; +Cc: stephen, dsahern
This reduces stack usage, as asprintf allocates memory on the heap.
This indirectly fixes a snprintf truncation warning (from gcc v9.2.1):
bpf.c: In function ‘bpf_get_work_dir’:
bpf.c:784:49: warning: ‘snprintf’ output may be truncated before the last format character [-Wformat-truncation=]
784 | snprintf(bpf_wrk_dir, sizeof(bpf_wrk_dir), "%s/", mnt);
| ^
bpf.c:784:2: note: ‘snprintf’ output between 2 and 4097 bytes into a destination of size 4096
784 | snprintf(bpf_wrk_dir, sizeof(bpf_wrk_dir), "%s/", mnt);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Fixes: e42256699cac ("bpf: make tc's bpf loader generic and move into lib")
Signed-off-by: Andrea Claudi <aclaudi@redhat.com>
---
lib/bpf.c | 95 +++++++++++++++++++++++++++++++++----------------------
1 file changed, 57 insertions(+), 38 deletions(-)
diff --git a/lib/bpf.c b/lib/bpf.c
index 7d2a322ffbaec..18e0334d3f11b 100644
--- a/lib/bpf.c
+++ b/lib/bpf.c
@@ -406,13 +406,14 @@ static int bpf_derive_elf_map_from_fdinfo(int fd, struct bpf_elf_map *map,
struct bpf_map_ext *ext)
{
unsigned int val, owner_type = 0, owner_jited = 0;
- char file[PATH_MAX], buff[4096];
+ char *file, buff[4096];
FILE *fp;
- snprintf(file, sizeof(file), "/proc/%d/fdinfo/%d", getpid(), fd);
+ asprintf(&file, "/proc/%d/fdinfo/%d", getpid(), fd);
memset(map, 0, sizeof(*map));
fp = fopen(file, "r");
+ free(file);
if (!fp) {
fprintf(stderr, "No procfs support?!\n");
return -EIO;
@@ -600,7 +601,7 @@ int bpf_trace_pipe(void)
0,
};
int fd_in, fd_out = STDERR_FILENO;
- char tpipe[PATH_MAX];
+ char *tpipe;
const char *mnt;
mnt = bpf_find_mntpt("tracefs", TRACEFS_MAGIC, tracefs_mnt,
@@ -610,9 +611,10 @@ int bpf_trace_pipe(void)
return -1;
}
- snprintf(tpipe, sizeof(tpipe), "%s/trace_pipe", mnt);
+ asprintf(&tpipe, "%s/trace_pipe", mnt);
fd_in = open(tpipe, O_RDONLY);
+ free(tpipe);
if (fd_in < 0)
return -1;
@@ -633,37 +635,42 @@ int bpf_trace_pipe(void)
static int bpf_gen_global(const char *bpf_sub_dir)
{
- char bpf_glo_dir[PATH_MAX];
+ char *bpf_glo_dir;
int ret;
- snprintf(bpf_glo_dir, sizeof(bpf_glo_dir), "%s/%s/",
- bpf_sub_dir, BPF_DIR_GLOBALS);
+ asprintf(&bpf_glo_dir, "%s/%s/", bpf_sub_dir, BPF_DIR_GLOBALS);
ret = mkdir(bpf_glo_dir, S_IRWXU);
if (ret && errno != EEXIST) {
fprintf(stderr, "mkdir %s failed: %s\n", bpf_glo_dir,
strerror(errno));
- return ret;
+ goto out;
}
- return 0;
+ ret = 0;
+out:
+ free(bpf_glo_dir);
+ return ret;
}
static int bpf_gen_master(const char *base, const char *name)
{
- char bpf_sub_dir[PATH_MAX + NAME_MAX + 1];
+ char *bpf_sub_dir;
int ret;
- snprintf(bpf_sub_dir, sizeof(bpf_sub_dir), "%s%s/", base, name);
+ asprintf(&bpf_sub_dir, "%s%s/", base, name);
ret = mkdir(bpf_sub_dir, S_IRWXU);
if (ret && errno != EEXIST) {
fprintf(stderr, "mkdir %s failed: %s\n", bpf_sub_dir,
strerror(errno));
- return ret;
+ goto out;
}
- return bpf_gen_global(bpf_sub_dir);
+ ret = bpf_gen_global(bpf_sub_dir);
+out:
+ free(bpf_sub_dir);
+ return ret;
}
static int bpf_slave_via_bind_mnt(const char *full_name,
@@ -692,13 +699,13 @@ static int bpf_slave_via_bind_mnt(const char *full_name,
static int bpf_gen_slave(const char *base, const char *name,
const char *link)
{
- char bpf_lnk_dir[PATH_MAX + NAME_MAX + 1];
- char bpf_sub_dir[PATH_MAX + NAME_MAX];
+ char *bpf_lnk_dir;
+ char *bpf_sub_dir;
struct stat sb = {};
int ret;
- snprintf(bpf_lnk_dir, sizeof(bpf_lnk_dir), "%s%s/", base, link);
- snprintf(bpf_sub_dir, sizeof(bpf_sub_dir), "%s%s", base, name);
+ asprintf(&bpf_lnk_dir, "%s%s/", base, link);
+ asprintf(&bpf_sub_dir, "%s%s", base, name);
ret = symlink(bpf_lnk_dir, bpf_sub_dir);
if (ret) {
@@ -706,25 +713,30 @@ static int bpf_gen_slave(const char *base, const char *name,
if (errno != EPERM) {
fprintf(stderr, "symlink %s failed: %s\n",
bpf_sub_dir, strerror(errno));
- return ret;
+ goto out;
}
- return bpf_slave_via_bind_mnt(bpf_sub_dir,
- bpf_lnk_dir);
+ ret = bpf_slave_via_bind_mnt(bpf_sub_dir, bpf_lnk_dir);
+ goto out;
}
ret = lstat(bpf_sub_dir, &sb);
if (ret) {
fprintf(stderr, "lstat %s failed: %s\n",
bpf_sub_dir, strerror(errno));
- return ret;
+ goto out;
}
- if ((sb.st_mode & S_IFMT) != S_IFLNK)
- return bpf_gen_global(bpf_sub_dir);
+ if ((sb.st_mode & S_IFMT) != S_IFLNK) {
+ ret = bpf_gen_global(bpf_sub_dir);
+ goto out;
+ }
}
- return 0;
+out:
+ free(bpf_lnk_dir);
+ free(bpf_sub_dir);
+ return ret;
}
static int bpf_gen_hierarchy(const char *base)
@@ -742,7 +754,7 @@ static int bpf_gen_hierarchy(const char *base)
static const char *bpf_get_work_dir(enum bpf_prog_type type)
{
static char bpf_tmp[PATH_MAX] = BPF_DIR_MNT;
- static char bpf_wrk_dir[PATH_MAX];
+ static char *bpf_wrk_dir;
static const char *mnt;
static bool bpf_mnt_cached;
const char *mnt_env = getenv(BPF_ENV_MNT);
@@ -781,7 +793,7 @@ static const char *bpf_get_work_dir(enum bpf_prog_type type)
}
}
- snprintf(bpf_wrk_dir, sizeof(bpf_wrk_dir), "%s/", mnt);
+ asprintf(&bpf_wrk_dir, "%s/", mnt);
ret = bpf_gen_hierarchy(bpf_wrk_dir);
if (ret) {
@@ -1438,29 +1450,31 @@ static int bpf_probe_pinned(const char *name, const struct bpf_elf_ctx *ctx,
static int bpf_make_obj_path(const struct bpf_elf_ctx *ctx)
{
- char tmp[PATH_MAX];
+ char *tmp;
int ret;
- snprintf(tmp, sizeof(tmp), "%s/%s", bpf_get_work_dir(ctx->type),
- ctx->obj_uid);
+ asprintf(&tmp, "%s/%s", bpf_get_work_dir(ctx->type), ctx->obj_uid);
ret = mkdir(tmp, S_IRWXU);
if (ret && errno != EEXIST) {
fprintf(stderr, "mkdir %s failed: %s\n", tmp, strerror(errno));
- return ret;
+ goto out;
}
- return 0;
+ ret = 0;
+out:
+ free(tmp);
+ return ret;
}
static int bpf_make_custom_path(const struct bpf_elf_ctx *ctx,
const char *todo)
{
- char tmp[PATH_MAX], rem[PATH_MAX], *sub;
+ char *tmp, *rem, *sub;
int ret;
- snprintf(tmp, sizeof(tmp), "%s/../", bpf_get_work_dir(ctx->type));
- snprintf(rem, sizeof(rem), "%s/", todo);
+ asprintf(&tmp, "%s/../", bpf_get_work_dir(ctx->type));
+ asprintf(&rem, "%s/", todo);
sub = strtok(rem, "/");
while (sub) {
@@ -1474,13 +1488,17 @@ static int bpf_make_custom_path(const struct bpf_elf_ctx *ctx,
if (ret && errno != EEXIST) {
fprintf(stderr, "mkdir %s failed: %s\n", tmp,
strerror(errno));
- return ret;
+ goto out;
}
sub = strtok(NULL, "/");
}
- return 0;
+ ret = 0;
+out:
+ free(rem);
+ free(tmp);
+ return ret;
}
static int bpf_place_pinned(int fd, const char *name,
@@ -2581,14 +2599,15 @@ struct bpf_jited_aux {
static int bpf_derive_prog_from_fdinfo(int fd, struct bpf_prog_data *prog)
{
- char file[PATH_MAX], buff[4096];
+ char *file, buff[4096];
unsigned int val;
FILE *fp;
- snprintf(file, sizeof(file), "/proc/%d/fdinfo/%d", getpid(), fd);
+ asprintf(&file, "/proc/%d/fdinfo/%d", getpid(), fd);
memset(prog, 0, sizeof(*prog));
fp = fopen(file, "r");
+ free(file);
if (!fp) {
fprintf(stderr, "No procfs support?!\n");
return -EIO;
--
2.21.0
^ permalink raw reply related
* Re: [PATCH v2] net: enable wireless core features with LEGACY_WEXT_ALLCONFIG
From: Johannes Berg @ 2019-09-09 15:44 UTC (permalink / raw)
To: Mark Salyzyn, Greg KH
Cc: linux-kernel, kernel-team, David S. Miller, Marcel Holtmann,
linux-wireless, netdev, stable
In-Reply-To: <b7027a5d-5d75-677b-0e9b-cd70e5e30092@android.com>
On Mon, 2019-09-09 at 07:24 -0700, Mark Salyzyn wrote:
>
> > How is this patch applicable to stable kernels???
I'm not sure I even buy the arguments to get it into the regular kernel.
> B) there is a shortcoming in _all_ kernel versions with respect to
> hidden configurations options like this, hoping to set one precedent in
> how to handle them if acceptable to the community.
This really is the only argument, I think, but I don't really see it as
a shortcoming. The kernel is handling this properly, after all, with
respect to itself. You just have issues with out-of-tree modules.
And while it is true, setting that precedent might ultimately mean we'll
end up with ~80 (**) new Kconfig options in net/ alone ... That's
certainly *NOT* a precedent I want to set nor the way I want to see this
handled, when we already get complaints that we're adding too many
Kconfig options (and those are ones we really do need).
Obviously, nothing stops you from putting this into your kernel (and I
guess you already are), but I don't really see how it benefits us as a
kernel community.
> E) Timely discussion item for LPC?
Perhaps you should indeed drive that discussion there, this really is
bigger than this particular wireless feature. At the very least, to
avoid Kconfig complexity explosion, add a single new
config OPTIONS_FOR_OUT_OF_TREE_MODULES
bool "..."
depends on EXPERT
help
...
and make LEGACY_WEXT_ALLCONFIG depend on that.
But if you're honest and obvious about it like that, I have a hard time
seeing you get that into the tree past Greg or Linus...
Also, you probably know this, but in this particular case you really
should just get rid of your wext dependencies ... this stuff is
literally decades old, and while that isn't necessarily a bad thing, it
also has issues that have been known for a decade or so that simply
cannot be solved.
(**) git grep "bool$" and "tristate$" in Kconfig files under net/ yields
a bit more, but here you already set 5, who knows. Still, even if it's
only 20 in the end that's too much.
johannes
^ permalink raw reply
* [PATCH net-next v2 2/2] net: stmmac: Support enhanced addressing mode for DWMAC 4.10
From: Thierry Reding @ 2019-09-09 15:25 UTC (permalink / raw)
To: David S . Miller
Cc: Giuseppe Cavallaro, Alexandre Torgue, Jose Abreu, Jon Hunter,
Bitan Biswas, netdev, linux-tegra
In-Reply-To: <20190909152546.383-1-thierry.reding@gmail.com>
From: Thierry Reding <treding@nvidia.com>
The address width of the controller can be read from hardware feature
registers much like on XGMAC. Add support for parsing the ADDR64 field
so that the DMA mask can be set accordingly.
This avoids getting swiotlb involved for DMA on Tegra186 and later.
Also make sure that the upper 32 bits of the DMA address are written to
the DMA descriptors when enhanced addressing mode is used. Similarily,
for each channel, the upper 32 bits of the DMA descriptor ring's base
address also need to be programmed to make sure the correct memory can
be fetched when the DMA descriptor ring is located beyond the 32-bit
boundary.
Signed-off-by: Thierry Reding <treding@nvidia.com>
---
Changes in v2:
- also program the upper 32 bits of the DMA descriptor base address for
each channel
drivers/net/ethernet/stmicro/stmmac/dwmac4.h | 1 +
.../ethernet/stmicro/stmmac/dwmac4_descs.c | 4 +--
.../net/ethernet/stmicro/stmmac/dwmac4_dma.c | 28 +++++++++++++++++++
.../net/ethernet/stmicro/stmmac/dwmac4_dma.h | 3 ++
4 files changed, 34 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac4.h b/drivers/net/ethernet/stmicro/stmmac/dwmac4.h
index 2ed11a581d80..f634fa09dffc 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac4.h
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac4.h
@@ -183,6 +183,7 @@ enum power_event {
#define GMAC_HW_HASH_TB_SZ GENMASK(25, 24)
#define GMAC_HW_FEAT_AVSEL BIT(20)
#define GMAC_HW_TSOEN BIT(18)
+#define GMAC_HW_ADDR64 GENMASK(15, 14)
#define GMAC_HW_TXFIFOSIZE GENMASK(10, 6)
#define GMAC_HW_RXFIFOSIZE GENMASK(4, 0)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac4_descs.c b/drivers/net/ethernet/stmicro/stmmac/dwmac4_descs.c
index dbde23e7e169..d546041d2fcd 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac4_descs.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac4_descs.c
@@ -431,8 +431,8 @@ static void dwmac4_get_addr(struct dma_desc *p, unsigned int *addr)
static void dwmac4_set_addr(struct dma_desc *p, dma_addr_t addr)
{
- p->des0 = cpu_to_le32(addr);
- p->des1 = 0;
+ p->des0 = cpu_to_le32(lower_32_bits(addr));
+ p->des1 = cpu_to_le32(upper_32_bits(addr));
}
static void dwmac4_clear(struct dma_desc *p)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac4_dma.c b/drivers/net/ethernet/stmicro/stmmac/dwmac4_dma.c
index 3ed5508586ef..e77410f21d7d 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac4_dma.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac4_dma.c
@@ -79,6 +79,10 @@ static void dwmac4_dma_init_rx_chan(void __iomem *ioaddr,
value = value | (rxpbl << DMA_BUS_MODE_RPBL_SHIFT);
writel(value, ioaddr + DMA_CHAN_RX_CONTROL(chan));
+ if (dma_cfg->eame)
+ writel(upper_32_bits(dma_rx_phy),
+ ioaddr + DMA_CHAN_RX_BASE_ADDR_HI(chan));
+
writel(lower_32_bits(dma_rx_phy), ioaddr + DMA_CHAN_RX_BASE_ADDR(chan));
}
@@ -97,6 +101,10 @@ static void dwmac4_dma_init_tx_chan(void __iomem *ioaddr,
writel(value, ioaddr + DMA_CHAN_TX_CONTROL(chan));
+ if (dma_cfg->eame)
+ writel(upper_32_bits(dma_tx_phy),
+ ioaddr + DMA_CHAN_TX_BASE_ADDR_HI(chan));
+
writel(lower_32_bits(dma_tx_phy), ioaddr + DMA_CHAN_TX_BASE_ADDR(chan));
}
@@ -132,6 +140,9 @@ static void dwmac4_dma_init(void __iomem *ioaddr,
if (dma_cfg->aal)
value |= DMA_SYS_BUS_AAL;
+ if (dma_cfg->eame)
+ value |= DMA_SYS_BUS_EAME;
+
writel(value, ioaddr + DMA_SYS_BUS_MODE);
}
@@ -354,6 +365,23 @@ static void dwmac4_get_hw_feature(void __iomem *ioaddr,
dma_cap->hash_tb_sz = (hw_cap & GMAC_HW_HASH_TB_SZ) >> 24;
dma_cap->av = (hw_cap & GMAC_HW_FEAT_AVSEL) >> 20;
dma_cap->tsoen = (hw_cap & GMAC_HW_TSOEN) >> 18;
+
+ dma_cap->addr64 = (hw_cap & GMAC_HW_ADDR64) >> 14;
+ switch (dma_cap->addr64) {
+ case 0:
+ dma_cap->addr64 = 32;
+ break;
+ case 1:
+ dma_cap->addr64 = 40;
+ break;
+ case 2:
+ dma_cap->addr64 = 48;
+ break;
+ default:
+ dma_cap->addr64 = 32;
+ break;
+ }
+
/* RX and TX FIFO sizes are encoded as log2(n / 128). Undo that by
* shifting and store the sizes in bytes.
*/
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac4_dma.h b/drivers/net/ethernet/stmicro/stmmac/dwmac4_dma.h
index b66da0237d2a..5299fa1001a3 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac4_dma.h
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac4_dma.h
@@ -65,6 +65,7 @@
#define DMA_SYS_BUS_MB BIT(14)
#define DMA_AXI_1KBBE BIT(13)
#define DMA_SYS_BUS_AAL BIT(12)
+#define DMA_SYS_BUS_EAME BIT(11)
#define DMA_AXI_BLEN256 BIT(7)
#define DMA_AXI_BLEN128 BIT(6)
#define DMA_AXI_BLEN64 BIT(5)
@@ -91,7 +92,9 @@
#define DMA_CHAN_CONTROL(x) DMA_CHANX_BASE_ADDR(x)
#define DMA_CHAN_TX_CONTROL(x) (DMA_CHANX_BASE_ADDR(x) + 0x4)
#define DMA_CHAN_RX_CONTROL(x) (DMA_CHANX_BASE_ADDR(x) + 0x8)
+#define DMA_CHAN_TX_BASE_ADDR_HI(x) (DMA_CHANX_BASE_ADDR(x) + 0x10)
#define DMA_CHAN_TX_BASE_ADDR(x) (DMA_CHANX_BASE_ADDR(x) + 0x14)
+#define DMA_CHAN_RX_BASE_ADDR_HI(x) (DMA_CHANX_BASE_ADDR(x) + 0x18)
#define DMA_CHAN_RX_BASE_ADDR(x) (DMA_CHANX_BASE_ADDR(x) + 0x1c)
#define DMA_CHAN_TX_END_ADDR(x) (DMA_CHANX_BASE_ADDR(x) + 0x20)
#define DMA_CHAN_RX_END_ADDR(x) (DMA_CHANX_BASE_ADDR(x) + 0x28)
--
2.23.0
^ permalink raw reply related
* [PATCH net-next v2 1/2] net: stmmac: Only enable enhanced addressing mode when needed
From: Thierry Reding @ 2019-09-09 15:25 UTC (permalink / raw)
To: David S . Miller
Cc: Giuseppe Cavallaro, Alexandre Torgue, Jose Abreu, Jon Hunter,
Bitan Biswas, netdev, linux-tegra
From: Thierry Reding <treding@nvidia.com>
Enhanced addressing mode is only required when more than 32 bits need to
be addressed. Add a DMA configuration parameter to enable this mode only
when needed.
Signed-off-by: Thierry Reding <treding@nvidia.com>
---
drivers/net/ethernet/stmicro/stmmac/dwxgmac2_dma.c | 5 ++++-
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 6 ++++++
include/linux/stmmac.h | 1 +
3 files changed, 11 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_dma.c b/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_dma.c
index 64956465c030..3e00fd8befcf 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_dma.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_dma.c
@@ -27,7 +27,10 @@ static void dwxgmac2_dma_init(void __iomem *ioaddr,
if (dma_cfg->aal)
value |= XGMAC_AAL;
- writel(value | XGMAC_EAME, ioaddr + XGMAC_DMA_SYSBUS_MODE);
+ if (dma_cfg->eame)
+ value |= XGMAC_EAME;
+
+ writel(value, ioaddr + XGMAC_DMA_SYSBUS_MODE);
}
static void dwxgmac2_dma_init_chan(void __iomem *ioaddr,
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 06ccd216ae90..ecd461207dbc 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -4497,6 +4497,12 @@ int stmmac_dvr_probe(struct device *device,
if (!ret) {
dev_info(priv->device, "Using %d bits DMA width\n",
priv->dma_cap.addr64);
+
+ /*
+ * If more than 32 bits can be addressed, make sure to
+ * enable enhanced addressing mode.
+ */
+ priv->plat->dma_cfg->eame = true;
} else {
ret = dma_set_mask_and_coherent(device, DMA_BIT_MASK(32));
if (ret) {
diff --git a/include/linux/stmmac.h b/include/linux/stmmac.h
index 7ad7ae35cf88..d300ac907c76 100644
--- a/include/linux/stmmac.h
+++ b/include/linux/stmmac.h
@@ -92,6 +92,7 @@ struct stmmac_dma_cfg {
int fixed_burst;
int mixed_burst;
bool aal;
+ bool eame;
};
#define AXI_BLEN 7
--
2.23.0
^ permalink raw reply related
* Re: [PATCH net-next 2/2] net: stmmac: Support enhanced addressing mode for DWMAC 4.10
From: Thierry Reding @ 2019-09-09 15:08 UTC (permalink / raw)
To: David S . Miller
Cc: Giuseppe Cavallaro, Alexandre Torgue, Jose Abreu, Jon Hunter,
Bitan Biswas, netdev, linux-tegra
In-Reply-To: <20190909123627.29928-2-thierry.reding@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1230 bytes --]
On Mon, Sep 09, 2019 at 02:36:27PM +0200, Thierry Reding wrote:
> From: Thierry Reding <treding@nvidia.com>
>
> The address width of the controller can be read from hardware feature
> registers much like on XGMAC. Add support for parsing the ADDR64 field
> so that the DMA mask can be set accordingly.
>
> This avoids getting swiotlb involved for DMA on Tegra186 and later.
>
> Also make sure that the upper 32 bits of the DMA address are written to
> the DMA descriptors when enhanced addressing mode is used.
>
> Signed-off-by: Thierry Reding <treding@nvidia.com>
> ---
> drivers/net/ethernet/stmicro/stmmac/dwmac4.h | 1 +
> .../ethernet/stmicro/stmmac/dwmac4_descs.c | 4 ++--
> .../net/ethernet/stmicro/stmmac/dwmac4_dma.c | 20 +++++++++++++++++++
> .../net/ethernet/stmicro/stmmac/dwmac4_dma.h | 1 +
> 4 files changed, 24 insertions(+), 2 deletions(-)
I just ran into a case where this is not enough. The problem is that the
driver not only doesn't fill in the upper 32 bits of the DMA address in
the descriptors, it also doesn't program the upper 32 bits of the DMA
address of the descriptors when initializing the channels. I'll update
the patch for that case as well.
Thierry
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH] tcp: Add TCP_INFO counter for packets received out-of-order
From: Eric Dumazet @ 2019-09-09 15:01 UTC (permalink / raw)
To: Thomas Higdon; +Cc: netdev, Jonathan Lemon, Dave Jones
In-Reply-To: <20190909142844.347495-1-tph@fb.com>
On Mon, Sep 9, 2019 at 4:30 PM Thomas Higdon <tph@fb.com> wrote:
>
> For receive-heavy cases on the server-side, we want to track the
> connection quality for individual client IPs. This counter, similar to
> the existing system-wide TCPOFOQueue counter in /proc/net/netstat,
> tracks out-of-order packet reception. By providing this counter in
> TCP_INFO, it will allow understanding to what degree receive-heavy
> sockets are experiencing out-of-order delivery and packet drops
> indicating congestion.
>
> Please note that this is similar to the counter in NetBSD TCP_INFO, and
> has the same name.
>
> Signed-off-by: Thomas Higdon <tph@fb.com>
> ---
> include/linux/tcp.h | 2 ++
> include/uapi/linux/tcp.h | 2 ++
> net/ipv4/tcp.c | 1 +
> net/ipv4/tcp_input.c | 1 +
> 4 files changed, 6 insertions(+)
>
> diff --git a/include/linux/tcp.h b/include/linux/tcp.h
> index f3a85a7fb4b1..a01dc78218f1 100644
> --- a/include/linux/tcp.h
> +++ b/include/linux/tcp.h
> @@ -393,6 +393,8 @@ struct tcp_sock {
> */
> struct request_sock *fastopen_rsk;
> u32 *saved_syn;
> +
> + u32 rcv_ooopack; /* Received out-of-order packets, for tcpinfo */
> };
>
> enum tsq_enum {
> diff --git a/include/uapi/linux/tcp.h b/include/uapi/linux/tcp.h
> index b3564f85a762..20237987ccc8 100644
> --- a/include/uapi/linux/tcp.h
> +++ b/include/uapi/linux/tcp.h
> @@ -270,6 +270,8 @@ struct tcp_info {
> __u64 tcpi_bytes_retrans; /* RFC4898 tcpEStatsPerfOctetsRetrans */
> __u32 tcpi_dsack_dups; /* RFC4898 tcpEStatsStackDSACKDups */
> __u32 tcpi_reord_seen; /* reordering events seen */
> +
> + __u32 tcpi_rcv_ooopack; /* Out-of-order packets received */
This is problematic : you create a 32bit hole in this structure that
we will never be able to fill.
We need to add another metric here so that the whole 64bit space is used.
> };
>
> /* netlink attributes types for SCM_TIMESTAMPING_OPT_STATS */
> diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c
> index 94df48bcecc2..d4386f054f18 100644
> --- a/net/ipv4/tcp.c
> +++ b/net/ipv4/tcp.c
> @@ -3295,6 +3295,7 @@ void tcp_get_info(struct sock *sk, struct tcp_info *info)
> info->tcpi_bytes_retrans = tp->bytes_retrans;
> info->tcpi_dsack_dups = tp->dsack_dups;
> info->tcpi_reord_seen = tp->reord_seen;
> + info->tcpi_rcv_ooopack = tp->rcv_ooopack;
> unlock_sock_fast(sk, slow);
> }
> EXPORT_SYMBOL_GPL(tcp_get_info);
> diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
> index 706cbb3b2986..2774680c5d05 100644
> --- a/net/ipv4/tcp_input.c
> +++ b/net/ipv4/tcp_input.c
> @@ -4555,6 +4555,7 @@ static void tcp_data_queue_ofo(struct sock *sk, struct sk_buff *skb)
> tp->pred_flags = 0;
> inet_csk_schedule_ack(sk);
>
> + tp->rcv_ooopack++;
We count skbs or we count segments ?
(GRO might have aggregated multiple segments)
> NET_INC_STATS(sock_net(sk), LINUX_MIB_TCPOFOQUEUE);
> seq = TCP_SKB_CB(skb)->seq;
> end_seq = TCP_SKB_CB(skb)->end_seq;
You forgot to clear the field in tcp_disconnect()
^ permalink raw reply
* Re: [RFC PATCH untested] vhost: block speculation of translated descriptors
From: Michael S. Tsirkin @ 2019-09-09 14:45 UTC (permalink / raw)
To: Jason Wang; +Cc: linux-kernel, kvm, virtualization, netdev
In-Reply-To: <db4d77d7-c467-935d-b4ae-1da7635e9b6b@redhat.com>
On Mon, Sep 09, 2019 at 03:19:55PM +0800, Jason Wang wrote:
>
> On 2019/9/8 下午7:05, Michael S. Tsirkin wrote:
> > iovec addresses coming from vhost are assumed to be
> > pre-validated, but in fact can be speculated to a value
> > out of range.
> >
> > Userspace address are later validated with array_index_nospec so we can
> > be sure kernel info does not leak through these addresses, but vhost
> > must also not leak userspace info outside the allowed memory table to
> > guests.
> >
> > Following the defence in depth principle, make sure
> > the address is not validated out of node range.
> >
> > Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
> > ---
> > drivers/vhost/vhost.c | 4 +++-
> > 1 file changed, 3 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
> > index 5dc174ac8cac..0ee375fb7145 100644
> > --- a/drivers/vhost/vhost.c
> > +++ b/drivers/vhost/vhost.c
> > @@ -2072,7 +2072,9 @@ static int translate_desc(struct vhost_virtqueue *vq, u64 addr, u32 len,
> > size = node->size - addr + node->start;
> > _iov->iov_len = min((u64)len - s, size);
> > _iov->iov_base = (void __user *)(unsigned long)
> > - (node->userspace_addr + addr - node->start);
> > + (node->userspace_addr +
> > + array_index_nospec(addr - node->start,
> > + node->size));
> > s += size;
> > addr += size;
> > ++ret;
>
>
> I've tried this on Kaby Lake smap off metadata acceleration off using
> testpmd (virtio-user) + vhost_net. I don't see obvious performance
> difference with TX PPS.
>
> Thanks
Should I push this to Linus right now then? It's a security thing so
maybe we better do it ASAP ... what's your opinion?
--
MST
^ permalink raw reply
* Re: [PATCH v2] net: enable wireless core features with LEGACY_WEXT_ALLCONFIG
From: Mark Salyzyn @ 2019-09-09 14:24 UTC (permalink / raw)
To: Greg KH
Cc: linux-kernel, kernel-team, Johannes Berg, David S. Miller,
Marcel Holtmann, linux-wireless, netdev, stable
In-Reply-To: <20190906233045.GB9478@kroah.com>
On 9/6/19 4:30 PM, Greg KH wrote:
> On Fri, Sep 06, 2019 at 12:24:00PM -0700, Mark Salyzyn wrote:
>> In embedded environments the requirements are to be able to pick and
>> chose which features one requires built into the kernel. If an
>> embedded environment wants to supports loading modules that have been
>> kbuilt out of tree, there is a need to enable hidden configurations
>> for legacy wireless core features to provide the API surface for
>> them to load.
>>
>> Introduce CONFIG_LEGACY_WEXT_ALLCONFIG to select all legacy wireless
>> extension core features by activating in turn all the associated
>> hidden configuration options, without having to specifically select
>> any wireless module(s).
>>
>> Signed-off-by: Mark Salyzyn <salyzyn@android.com>
>> Cc: kernel-team@android.com
>> Cc: Johannes Berg <johannes@sipsolutions.net>
>> Cc: "David S. Miller" <davem@davemloft.net>
>> Cc: Marcel Holtmann <marcel@holtmann.org>
>> Cc: linux-wireless@vger.kernel.org
>> Cc: netdev@vger.kernel.org
>> Cc: linux-kernel@vger.kernel.org
>> Cc: stable@vger.kernel.org # 4.19
>> ---
>> v2: change name and documentation to CONFIG_LEGACY_WEXT_ALLCONFIG
>> ---
>> net/wireless/Kconfig | 14 ++++++++++++++
>> 1 file changed, 14 insertions(+)
>>
>> diff --git a/net/wireless/Kconfig b/net/wireless/Kconfig
>> index 67f8360dfcee..0d646cf28de5 100644
>> --- a/net/wireless/Kconfig
>> +++ b/net/wireless/Kconfig
>> @@ -17,6 +17,20 @@ config WEXT_SPY
>> config WEXT_PRIV
>> bool
>>
>> +config LEGACY_WEXT_ALLCONFIG
>> + bool "allconfig for legacy wireless extensions"
>> + select WIRELESS_EXT
>> + select WEXT_CORE
>> + select WEXT_PROC
>> + select WEXT_SPY
>> + select WEXT_PRIV
>> + help
>> + Config option used to enable all the legacy wireless extensions to
>> + the core functionality used by add-in modules.
>> +
>> + If you are not building a kernel to be used for a variety of
>> + out-of-kernel built wireless modules, say N here.
>> +
>> config CFG80211
>> tristate "cfg80211 - wireless configuration API"
>> depends on RFKILL || !RFKILL
>> --
>> 2.23.0.187.g17f5b7556c-goog
>>
> How is this patch applicable to stable kernels???
A) worth a shot ;-}
B) there is a shortcoming in _all_ kernel versions with respect to
hidden configurations options like this, hoping to set one precedent in
how to handle them if acceptable to the community.
C) [AGENDA ALERT] Android _will_ be back-porting this to android-4.19
kernel anyway, would help maintenance if via stable. <holding hat in hand>
D) Not an ABI or interface break, does not introduce instability, but
rather keeps downstream kernels of any distributions from having to hack
in their own alternate means of dealing with this problem leading to
further fragmentation.
E) Timely discussion item for LPC?
Sincerely -- Mark Salyzyn
^ permalink raw reply
* Re: [PATCH v2 2/2] net: phy: dp83867: Add SGMII mode type switching
From: Florian Fainelli @ 2019-09-09 14:23 UTC (permalink / raw)
To: Vitaly Gaiduk, davem, robh+dt
Cc: Mark Rutland, Andrew Lunn, Heiner Kallweit, Trent Piepho, netdev,
devicetree, linux-kernel
In-Reply-To: <1568026945-3857-1-git-send-email-vitaly.gaiduk@cloudbear.ru>
On 9/9/2019 4:02 AM, Vitaly Gaiduk wrote:
> This patch adds ability to switch beetween two PHY SGMII modes.
> Some hardware, for example, FPGA IP designs may use 6-wire mode
> which enables differential SGMII clock to MAC.
>
> Signed-off-by: Vitaly Gaiduk <vitaly.gaiduk@cloudbear.ru>
> ---
> Changes in v2:
> - changed variable sgmii_type name to sgmii_ref_clk_en
>
> drivers/net/phy/dp83867.c | 16 ++++++++++++++++
> 1 file changed, 16 insertions(+)
>
> diff --git a/drivers/net/phy/dp83867.c b/drivers/net/phy/dp83867.c
> index 1f1ecee..cd6260e 100644
> --- a/drivers/net/phy/dp83867.c
> +++ b/drivers/net/phy/dp83867.c
> @@ -37,6 +37,7 @@
> #define DP83867_STRAP_STS2 0x006f
> #define DP83867_RGMIIDCTL 0x0086
> #define DP83867_IO_MUX_CFG 0x0170
> +#define DP83867_SGMIICTL 0x00D3
> #define DP83867_10M_SGMII_CFG 0x016F
> #define DP83867_10M_SGMII_RATE_ADAPT_MASK BIT(7)
>
> @@ -61,6 +62,9 @@
> #define DP83867_RGMII_TX_CLK_DELAY_EN BIT(1)
> #define DP83867_RGMII_RX_CLK_DELAY_EN BIT(0)
>
> +/* SGMIICTL bits */
> +#define DP83867_SGMII_TYPE BIT(14)
> +
> /* STRAP_STS1 bits */
> #define DP83867_STRAP_STS1_RESERVED BIT(11)
>
> @@ -109,6 +113,7 @@ struct dp83867_private {
> bool rxctrl_strap_quirk;
> bool set_clk_output;
> u32 clk_output_sel;
> + bool sgmii_ref_clk_en;
> };
>
> static int dp83867_ack_interrupt(struct phy_device *phydev)
> @@ -197,6 +202,9 @@ static int dp83867_of_init(struct phy_device *phydev)
> dp83867->rxctrl_strap_quirk = of_property_read_bool(of_node,
> "ti,dp83867-rxctrl-strap-quirk");
>
> + dp83867->sgmii_ref_clk_en = of_property_read_bool(of_node,
> + "ti,sgmii-ref-clock-output-enable");
> +
> /* Existing behavior was to use default pin strapping delay in rgmii
> * mode, but rgmii should have meant no delay. Warn existing users.
> */
> @@ -389,6 +397,14 @@ static int dp83867_config_init(struct phy_device *phydev)
>
> if (ret)
> return ret;
> +
> + /* SGMII type is set to 4-wire mode by default */
> + if (dp83867->sgmii_ref_clk_en) {
> + /* Switch on 6-wire mode */
> + val = phy_read_mmd(phydev, DP83867_DEVADDR, DP83867_SGMIICTL);
> + val |= DP83867_SGMII_TYPE;
> + phy_write_mmd(phydev, DP83867_DEVADDR, DP83867_SGMIICTL, val);
> + }
Is there a case where the value could be retained across a power
on/reset cycle and you would want to make sure you do write the intended
"wire mode" here? What I am suggesting is just changing this into a:
val = phy_read_mmd(phydev, DP83867_DEVADDR, DP83867_SGMIICTL);
if (dp83867->sgmii_ref_clk_en)
val |= DP83867_SGMII_TYPE;
else
val &= ~DP83867_SGMII_TYPE;
phy_write_mmd(phydev, DP83867_DEVADDR, DP83867_SGMIICTL, val);
Other than that, LGTM
--
Florian
^ permalink raw reply
* [PATCH v2] igb: add rx drop enable attribute
From: Robert Beckett @ 2019-09-09 14:21 UTC (permalink / raw)
To: intel-wired-lan; +Cc: Robert Beckett, Jeff Kirsher, David S. Miller, netdev
To allow userland to enable or disable dropping packets when descriptor
ring is exhausted, add RX_DROP_EN private flag.
This can be used in conjunction with flow control to mitigate packet storms
(e.g. due to network loop or DoS) by forcing the network adapter to send
pause frames whenever the ring is close to exhaustion.
By default this will maintain previous behaviour of enabling dropping of
packets during ring buffer exhaustion.
Some use cases prefer to not drop packets upon exhaustion, but instead
use flow control to limit ingress rates and ensure no dropped packets.
This is useful when the host CPU cannot keep up with packet delivery,
but data delivery is more important than throughput via multiple queues.
Userland can set this flag to 0 via ethtool to disable packet dropping.
Signed-off-by: Robert Beckett <bob.beckett@collabora.com>
---
Notes:
Changes since v1: re-written to use ethtool priv flags instead of sysfs attribute
drivers/net/ethernet/intel/igb/igb.h | 1 +
drivers/net/ethernet/intel/igb/igb_ethtool.c | 8 ++++++++
drivers/net/ethernet/intel/igb/igb_main.c | 11 +++++++++--
3 files changed, 18 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/intel/igb/igb.h b/drivers/net/ethernet/intel/igb/igb.h
index ca54e268d157..ff4a61218e3e 100644
--- a/drivers/net/ethernet/intel/igb/igb.h
+++ b/drivers/net/ethernet/intel/igb/igb.h
@@ -617,6 +617,7 @@ struct igb_adapter {
#define IGB_FLAG_VLAN_PROMISC BIT(15)
#define IGB_FLAG_RX_LEGACY BIT(16)
#define IGB_FLAG_FQTSS BIT(17)
+#define IGB_FLAG_RX_DROP_EN BIT(18)
/* Media Auto Sense */
#define IGB_MAS_ENABLE_0 0X0001
diff --git a/drivers/net/ethernet/intel/igb/igb_ethtool.c b/drivers/net/ethernet/intel/igb/igb_ethtool.c
index 3182b059bf55..b584fa1f0e14 100644
--- a/drivers/net/ethernet/intel/igb/igb_ethtool.c
+++ b/drivers/net/ethernet/intel/igb/igb_ethtool.c
@@ -128,6 +128,8 @@ static const char igb_gstrings_test[][ETH_GSTRING_LEN] = {
static const char igb_priv_flags_strings[][ETH_GSTRING_LEN] = {
#define IGB_PRIV_FLAGS_LEGACY_RX BIT(0)
"legacy-rx",
+#define IGB_PRIV_FLAGS_RX_DROP_EN BIT(1)
+ "rx-drop-en",
};
#define IGB_PRIV_FLAGS_STR_LEN ARRAY_SIZE(igb_priv_flags_strings)
@@ -3444,6 +3446,8 @@ static u32 igb_get_priv_flags(struct net_device *netdev)
if (adapter->flags & IGB_FLAG_RX_LEGACY)
priv_flags |= IGB_PRIV_FLAGS_LEGACY_RX;
+ if (adapter->flags & IGB_FLAG_RX_DROP_EN)
+ priv_flags |= IGB_PRIV_FLAGS_RX_DROP_EN;
return priv_flags;
}
@@ -3457,6 +3461,10 @@ static int igb_set_priv_flags(struct net_device *netdev, u32 priv_flags)
if (priv_flags & IGB_PRIV_FLAGS_LEGACY_RX)
flags |= IGB_FLAG_RX_LEGACY;
+ flags &= ~IGB_FLAG_RX_DROP_EN;
+ if (priv_flags & IGB_PRIV_FLAGS_RX_DROP_EN)
+ flags |= IGB_FLAG_RX_DROP_EN;
+
if (flags != adapter->flags) {
adapter->flags = flags;
diff --git a/drivers/net/ethernet/intel/igb/igb_main.c b/drivers/net/ethernet/intel/igb/igb_main.c
index 105b0624081a..51a8010dbe59 100644
--- a/drivers/net/ethernet/intel/igb/igb_main.c
+++ b/drivers/net/ethernet/intel/igb/igb_main.c
@@ -3236,6 +3236,9 @@ static int igb_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
igb_validate_mdi_setting(hw);
+ /* By default, support dropping packets due to ring exhaustion */
+ adapter->flags |= IGB_FLAG_RX_DROP_EN;
+
/* By default, support wake on port A */
if (hw->bus.func == 0)
adapter->flags |= IGB_FLAG_WOL_SUPPORTED;
@@ -4503,8 +4506,12 @@ void igb_configure_rx_ring(struct igb_adapter *adapter,
srrctl |= E1000_SRRCTL_DESCTYPE_ADV_ONEBUF;
if (hw->mac.type >= e1000_82580)
srrctl |= E1000_SRRCTL_TIMESTAMP;
- /* Only set Drop Enable if we are supporting multiple queues */
- if (adapter->vfs_allocated_count || adapter->num_rx_queues > 1)
+ /*
+ * Only set Drop Enable if we are supporting multiple queues and
+ * allowed by flags
+ */
+ if ((adapter->flags & IGB_FLAG_RX_DROP_EN) &&
+ (adapter->vfs_allocated_count || adapter->num_rx_queues > 1))
srrctl |= E1000_SRRCTL_DROP_EN;
wr32(E1000_SRRCTL(reg_idx), srrctl);
--
2.18.0
^ permalink raw reply related
* Re: [PATCH v2 0/4] Deterministic SPI latency with NXP DSPI driver
From: Vladimir Oltean @ 2019-09-09 14:08 UTC (permalink / raw)
To: Mark Brown
Cc: h.feurstein, mlichvar, richardcochran, andrew, f.fainelli,
linux-spi, netdev
In-Reply-To: <20190909100618.GC2036@sirena.org.uk>
Hi Mark,
On 09/09/2019, Mark Brown <broonie@kernel.org> wrote:
> On Thu, Sep 05, 2019 at 04:01:10AM +0300, Vladimir Oltean wrote:
>
>> This patchset proposes an interface from the SPI subsystem for
>> software timestamping SPI transfers. There is a default implementation
>> provided in the core, as well as a mechanism for SPI slave drivers to
>> check which byte was in fact timestamped post-facto. The patchset also
>> adds the first user of this interface (the NXP DSPI driver in TCFQ mode).
>
> I think this is about as good as we're going to get but we're
> very near the merge window now so I'll leave this until after the
> merge window is done in case there's more review comments before
> applying. I need to reread the implementation code a bit as
> well, it looked fine on a first scan through but it's possible I
> might spot something later.
>
There's one thing I still don't like, and that is the fact that the
delay for sending one SPI word is so low, I can't actually capture it
precisely with a "pre" and a "post" system clock timestamp. What
actually happens is that I'm actually measuring the timing of the (too
loose) CPU loop. Normally that's not bad, because the guarantee that
the transfer happened between "pre" and "post" is still kept. But I'm
introducing a false jitter in the delays I'm reporting ("post" -
"pre") that does not actually depend upon the hardware phenomenon, but
on the CPU frequency :) At maximum CPU frequency (performance
governor) the reported latency is always constant, but still larger
than the SPI transfer time. In fact it's constant exactly _because_
the CPU frequency is constant. When the CPU goes at lower frequencies,
user space gets confused about the varying delay and my control loop
doesn't keep lock as well.
So in fact I wonder whether I'm using the PTP system timestamping API
properly. One idea I had was to just timestamp the write to the TX
FIFO, and add a constant delay based on bytes_per_word * (NSEC_PER_SEC
/ speed_hz). IMHO that correction should logically be applied to both
"pre" and "post". Then say that the "post" is equal to the "pre". But
that would mean I'm reporting a delay of zero, and losing the
guarantee that the transfer actually happens between the reported
"pre" and "post". On the other hand, introducing a static correction
option could potentially help with the drivers that just get notified
of a DMA completion.
The other idea was to just push the PTP system timestamping all the
way into regmap_write, and just minimize the governor effect by making
sure the timestamped area of code is really short. I don't really
know.
^ 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