* Re: [PATCH v3 7/8] net: phy: Add support to configure clock in Broadcom iProc mdio mux
From: Russell King - ARM Linux @ 2018-08-01 18:46 UTC (permalink / raw)
To: Florian Fainelli
Cc: Arun Parameswaran, David S. Miller, Andrew Lunn, Rob Herring,
Mark Rutland, Ray Jui, Scott Branden, Catalin Marinas,
Will Deacon, netdev, bcm-kernel-feedback-list, linux-kernel,
linux-arm-kernel, devicetree
In-Reply-To: <0cc6db4f-7008-0ad3-58d7-9e93060f152f@gmail.com>
On Wed, Aug 01, 2018 at 11:40:33AM -0700, Florian Fainelli wrote:
> On 08/01/2018 10:56 AM, Arun Parameswaran wrote:
> > static int iproc_mdio_wait_for_idle(void __iomem *base, bool result)
> > @@ -204,6 +225,20 @@ static int mdio_mux_iproc_probe(struct platform_device *pdev)
> > return -ENOMEM;
> > }
> >
> > + md->core_clk = devm_clk_get(&pdev->dev, NULL);
> > + if (IS_ERR(md->core_clk)) {
> > + if (PTR_ERR(md->core_clk) == -EPROBE_DEFER)
> > + return -EPROBE_DEFER;
> > +
> > + md->core_clk = NULL;
>
> I would simplify this a bit:
>
> if (IS_ERR(md->core_clk) && PTR_ERR(md->core_clk) == -EPROBE_DEFER)
Even better is:
if (md->core_clk == ERR_PTR(-EPROBE_DEFER))
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 13.8Mbps down 630kbps up
According to speedtest.net: 13Mbps down 490kbps up
^ permalink raw reply
* Re: KASAN: use-after-free Read in rtnetlink_put_metrics
From: David Miller @ 2018-08-01 18:46 UTC (permalink / raw)
To: xiyou.wangcong
Cc: sd, eric.dumazet, syzbot+41f9c04b50ef70c66947, christian.brauner,
dsahern, fw, jbenc, ktkhai, linux-kernel, lucien.xin, netdev,
syzkaller-bugs
In-Reply-To: <CAM_iQpURKOMAaPfs9v7FzhqqQPzj71sQD2LS0eU8cuqTML-YoA@mail.gmail.com>
From: Cong Wang <xiyou.wangcong@gmail.com>
Date: Tue, 31 Jul 2018 16:03:13 -0700
> Looks like this commit is completely unnecessary,
> fib6_drop_pcpu_from() calls fib6_info_release()
> which calls fib6_info_destroy_rcu(), so this metrics
> will be released twice...
And even if there was a leak here, it's illegal to free this
metrics memory synchronously since it is RCU protected.
That's why it normally goes through fib6_info_destroy_rcu().
Sabrina, I'm going to revert your changes unless I see some
progress here by the end of today.
^ permalink raw reply
* Re: [PATCH v3 8/8] net: phy: Add pm support to Broadcom iProc mdio mux driver
From: Florian Fainelli @ 2018-08-01 18:39 UTC (permalink / raw)
To: Arun Parameswaran, David S. Miller, Florian Fainelli, Andrew Lunn,
Rob Herring, Mark Rutland, Ray Jui, Scott Branden,
Catalin Marinas, Will Deacon
Cc: netdev, devicetree, linux-arm-kernel, linux-kernel,
bcm-kernel-feedback-list
In-Reply-To: <1533146186-8374-9-git-send-email-arun.parameswaran@broadcom.com>
On 08/01/2018 10:56 AM, Arun Parameswaran wrote:
> Add support for suspend and resume to the Broadcom iProc mdio
> mux driver.
>
> Signed-off-by: Arun Parameswaran <arun.parameswaran@broadcom.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
--
Florian
^ permalink raw reply
* Re: [PATCH v3 5/8] net: phy: Use devm api for mdio bus allocation in bcm iproc mdio mux
From: Florian Fainelli @ 2018-08-01 18:37 UTC (permalink / raw)
To: Arun Parameswaran, David S. Miller, Florian Fainelli, Andrew Lunn,
Rob Herring, Mark Rutland, Ray Jui, Scott Branden,
Catalin Marinas, Will Deacon
Cc: netdev, devicetree, linux-arm-kernel, linux-kernel,
bcm-kernel-feedback-list
In-Reply-To: <1533146186-8374-6-git-send-email-arun.parameswaran@broadcom.com>
On 08/01/2018 10:56 AM, Arun Parameswaran wrote:
> Use devm_mdiobus_alloc() instead of mdiobus_alloc() in the Broadcom
> iProc mdio mux driver.
>
> Also, clear the driver data on error from probe or when remove() is
> called.
>
> Signed-off-by: Arun Parameswaran <arun.parameswaran@broadcom.com>
> ---
> drivers/net/phy/mdio-mux-bcm-iproc.c | 9 ++++-----
> 1 file changed, 4 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/net/phy/mdio-mux-bcm-iproc.c b/drivers/net/phy/mdio-mux-bcm-iproc.c
> index c36ce4b..5640d78 100644
> --- a/drivers/net/phy/mdio-mux-bcm-iproc.c
> +++ b/drivers/net/phy/mdio-mux-bcm-iproc.c
> @@ -198,7 +198,7 @@ static int mdio_mux_iproc_probe(struct platform_device *pdev)
> return PTR_ERR(md->base);
> }
>
> - md->mii_bus = mdiobus_alloc();
> + md->mii_bus = devm_mdiobus_alloc(&pdev->dev);
> if (!md->mii_bus) {
> dev_err(&pdev->dev, "mdiomux bus alloc failed\n");
> return -ENOMEM;
> @@ -217,7 +217,7 @@ static int mdio_mux_iproc_probe(struct platform_device *pdev)
> rc = mdiobus_register(bus);
> if (rc) {
> dev_err(&pdev->dev, "mdiomux registration failed\n");
> - goto out;
> + return rc;
> }
>
> platform_set_drvdata(pdev, md);
> @@ -226,6 +226,7 @@ static int mdio_mux_iproc_probe(struct platform_device *pdev)
> &md->mux_handle, md, md->mii_bus);
> if (rc) {
> dev_info(md->dev, "mdiomux initialization failed\n");
> + platform_set_drvdata(pdev, NULL);
This is minor, but I don't think this is necessary, the core device
driver layer does that already.
> goto out_register;
> }
>
> @@ -236,8 +237,6 @@ static int mdio_mux_iproc_probe(struct platform_device *pdev)
>
> out_register:
> mdiobus_unregister(bus);
> -out:
> - mdiobus_free(bus);
> return rc;
> }
>
> @@ -247,7 +246,7 @@ static int mdio_mux_iproc_remove(struct platform_device *pdev)
>
> mdio_mux_uninit(md->mux_handle);
> mdiobus_unregister(md->mii_bus);
> - mdiobus_free(md->mii_bus);
> + platform_set_drvdata(pdev, NULL);
Likewise.
>
> return 0;
> }
>
--
Florian
^ permalink raw reply
* RE: linux-next: manual merge of the net-next tree with the rdma tree
From: Parav Pandit @ 2018-08-01 18:30 UTC (permalink / raw)
To: Jason Gunthorpe, Stephen Rothwell
Cc: David Miller, Networking, Doug Ledford, Linux-Next Mailing List,
Linux Kernel Mailing List, Ursula Braun, Leon Romanovsky,
linux-rdma@vger.kernel.org
In-Reply-To: <20180801171346.GC10824@ziepe.ca>
> -----Original Message-----
> From: Jason Gunthorpe <jgg@ziepe.ca>
> Sent: Wednesday, August 1, 2018 12:14 PM
> To: Stephen Rothwell <sfr@canb.auug.org.au>
> Cc: Parav Pandit <parav@mellanox.com>; David Miller
> <davem@davemloft.net>; Networking <netdev@vger.kernel.org>; Doug
> Ledford <dledford@redhat.com>; Linux-Next Mailing List <linux-
> next@vger.kernel.org>; Linux Kernel Mailing List <linux-
> kernel@vger.kernel.org>; Ursula Braun <ubraun@linux.ibm.com>; Leon
> Romanovsky <leonro@mellanox.com>; linux-rdma@vger.kernel.org
> Subject: Re: linux-next: manual merge of the net-next tree with the rdma tree
>
> On Wed, Aug 01, 2018 at 03:33:45PM +1000, Stephen Rothwell wrote:
> > Hi Parav,
> >
> > On Tue, 31 Jul 2018 21:12:00 +0000 Parav Pandit <parav@mellanox.com>
> wrote:
> > >
> > > You might want to consider this compatibility patch in Linux-rdma
> > > tree to avoid a merge conflict of smc.
> > >
> > > https://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma.git/commit
> > > /?h=for-next&id=7aaa1807e698f73094b78f0ef25b1a37a4409a55
> >
> > Ok, since commit that is now in the rdma tree, my resolution of the
> > original conflicts comes down to dropping all the changes to
> > net/smc/smc_core.c net/smc/smc_ib.c that come from the rdma tree and
> > adding
> >
> > #include <rdma/ib_cache.h>
> >
> > to net/smc/smc_ib.c.
>
> Oh, that means I put the compat inline in the wrong header? Sigh.
>
It was in wrong place originally in ib_verbs.h because lately it returned all the entries from the cache.
So ib_cache.h was/is correct place.
But devel happened at pace where we eventually deprecated it.
So from pure compat perspective, yeah, it should be in wrong file i.e. ib_verbs.h but otherwise its correct in ib_cache.h.
^ permalink raw reply
* Re: [PATCH V2 net-next 0/2] be2net: patch-set
From: David Miller @ 2018-08-01 16:39 UTC (permalink / raw)
To: suresh.reddy; +Cc: netdev
In-Reply-To: <20180731153943.19522-1-suresh.reddy@broadcom.com>
From: Suresh Reddy <suresh.reddy@broadcom.com>
Date: Tue, 31 Jul 2018 11:39:41 -0400
> v1->v2 : Modified the subject line and commit log.
>
> Please consider applying these two patches to net-next.
Series applied, thanks.
^ permalink raw reply
* Re: [PATCH net] net: stmmac: Fix WoL for PCI-based setups
From: David Miller @ 2018-08-01 16:36 UTC (permalink / raw)
To: Jose.Abreu; +Cc: netdev, Joao.Pinto, peppe.cavallaro, alexandre.torgue
In-Reply-To: <2a47502239c0f5867d4dcebb2140849c40c5967f.1533046004.git.joabreu@synopsys.com>
From: Jose Abreu <Jose.Abreu@synopsys.com>
Date: Tue, 31 Jul 2018 15:08:20 +0100
> WoL won't work in PCI-based setups because we are not saving the PCI EP
> state before entering suspend state and not allowing D3 wake.
>
> Fix this by using a wrapper around stmmac_{suspend/resume} which
> correctly sets the PCI EP state.
>
> Signed-off-by: Jose Abreu <joabreu@synopsys.com>
Applied and queued up for -stable, thanks.
^ permalink raw reply
* Re: [PATCH v2 net] bonding: avoid lockdep confusion in bond_get_stats()
From: David Miller @ 2018-08-01 16:36 UTC (permalink / raw)
To: edumazet; +Cc: netdev, eric.dumazet, j.vosburgh, vfalico, andy
In-Reply-To: <20180731133054.68474-1-edumazet@google.com>
From: Eric Dumazet <edumazet@google.com>
Date: Tue, 31 Jul 2018 06:30:54 -0700
> syzbot found that the following sequence produces a LOCKDEP splat [1]
...
> To fix this, we can use the already provided nest_level.
>
> This patch also provides correct nesting for dev->addr_list_lock
...
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Applied, thanks Eric.
^ permalink raw reply
* Re: [PATCH net-next 2/2] rds: Remove IPv6 dependency
From: David Miller @ 2018-08-01 16:32 UTC (permalink / raw)
To: ka-cheong.poon; +Cc: netdev, santosh.shilimkar, rds-devel
In-Reply-To: <1533016122-12654-2-git-send-email-ka-cheong.poon@oracle.com>
From: Ka-Cheong Poon <ka-cheong.poon@oracle.com>
Date: Mon, 30 Jul 2018 22:48:42 -0700
> This patch removes the IPv6 dependency from RDS.
>
> Signed-off-by: Ka-Cheong Poon <ka-cheong.poon@oracle.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next 1/2] rds: rds_ib_recv_alloc_cache() should call alloc_percpu_gfp() instead
From: David Miller @ 2018-08-01 16:32 UTC (permalink / raw)
To: ka-cheong.poon; +Cc: netdev, santosh.shilimkar, rds-devel
In-Reply-To: <1533016122-12654-1-git-send-email-ka-cheong.poon@oracle.com>
From: Ka-Cheong Poon <ka-cheong.poon@oracle.com>
Date: Mon, 30 Jul 2018 22:48:41 -0700
> Currently, rds_ib_conn_alloc() calls rds_ib_recv_alloc_caches()
> without passing along the gfp_t flag. But rds_ib_recv_alloc_caches()
> and rds_ib_recv_alloc_cache() should take a gfp_t parameter so that
> rds_ib_recv_alloc_cache() can call alloc_percpu_gfp() using the
> correct flag instead of calling alloc_percpu().
>
> Signed-off-by: Ka-Cheong Poon <ka-cheong.poon@oracle.com>
Applied.
^ permalink raw reply
* Re: [PATCH ethtool] ethtool: Add support for WAKE_FILTER
From: David Miller @ 2018-08-01 16:32 UTC (permalink / raw)
To: f.fainelli; +Cc: netdev, linville, andrew, vivien.didelot
In-Reply-To: <47f52797-1540-5eeb-5ea8-3c0984fdfb11@gmail.com>
From: Florian Fainelli <f.fainelli@gmail.com>
Date: Mon, 30 Jul 2018 15:26:24 -0700
> On 07/17/2018 08:36 AM, Florian Fainelli wrote:
>> Allow re-purposing the wol->sopass storage area to specify a bitmask of filters
>> (programmed previously via ethtool::rxnfc) to be used as wake-up patterns.
>
> John, David, can you provide some feedback if the approach is
> acceptable? I will address Andrew's comment about the user friendliness
> and allow providing a comma separate list of filter identifiers.
>
> One usability issue with this approach is that one cannot specify
> wake-on-LAN using WAKE_MAGICSECURE *and* WAKE_FILTER at the same time,
> since it uses the same location in the ioctl() structure that is being
> passed. Do you see this as a problem?
Once again we are stuck in this weird situation, a sort of limbo.
On the one hand, I don't want to block your work on the ethtool
netlink stuff being done.
However it is clear that by using netlink attributes, it would
be so much cleaner.
I honestly don't know what to say at this time. I wish I had
a clear piece of advice and a way for everyone to move forward,
and usually I do, but this time I really don't :-/
^ permalink raw reply
* Re: SLAB_TYPESAFE_BY_RCU without constructors (was Re: [PATCH v4 13/17] khwasan: add hooks implementation)
From: Christopher Lameter @ 2018-08-01 16:22 UTC (permalink / raw)
To: Eric Dumazet
Cc: Dmitry Vyukov, Eric Dumazet, Andrey Ryabinin, Linus Torvalds,
Theodore Ts'o, jack, linux-ext4, Greg Kroah-Hartman,
Pablo Neira Ayuso, Jozsef Kadlecsik, Florian Westphal,
David Miller, netfilter-devel, coreteam, netdev, Gerrit Renker,
dccp, jani.nikula, joonas.lahtinen, rodrigo.vivi, airlied,
intel-gfx, dri-devel
In-Reply-To: <CANn89i+KtwtLvSw1c=Ux8okKP+XyMxzYbuKhYb2qhYeMw=NTzg@mail.gmail.com>
On Wed, 1 Aug 2018, Eric Dumazet wrote:
> The idea of having a ctor() would only be a win if all the fields that
> can be initialized in the ctor are contiguous and fill an integral
> number of cache lines.
Ok. Its reducing code size and makes the object status more consistent.
Isn't that enough?
^ permalink raw reply
* [PATCH v3 8/8] net: phy: Add pm support to Broadcom iProc mdio mux driver
From: Arun Parameswaran @ 2018-08-01 17:56 UTC (permalink / raw)
To: David S. Miller, Florian Fainelli, Andrew Lunn, Rob Herring,
Mark Rutland, Ray Jui, Scott Branden, Catalin Marinas,
Will Deacon
Cc: netdev, devicetree, linux-arm-kernel, linux-kernel,
bcm-kernel-feedback-list, Arun Parameswaran
In-Reply-To: <1533146186-8374-1-git-send-email-arun.parameswaran@broadcom.com>
Add support for suspend and resume to the Broadcom iProc mdio
mux driver.
Signed-off-by: Arun Parameswaran <arun.parameswaran@broadcom.com>
---
drivers/net/phy/mdio-mux-bcm-iproc.c | 27 +++++++++++++++++++++++++++
1 file changed, 27 insertions(+)
diff --git a/drivers/net/phy/mdio-mux-bcm-iproc.c b/drivers/net/phy/mdio-mux-bcm-iproc.c
index 5127010..4e2c51b 100644
--- a/drivers/net/phy/mdio-mux-bcm-iproc.c
+++ b/drivers/net/phy/mdio-mux-bcm-iproc.c
@@ -289,6 +289,32 @@ static int mdio_mux_iproc_remove(struct platform_device *pdev)
return 0;
}
+#ifdef CONFIG_PM_SLEEP
+static int mdio_mux_iproc_suspend(struct device *dev)
+{
+ struct platform_device *pdev = to_platform_device(dev);
+ struct iproc_mdiomux_desc *md = platform_get_drvdata(pdev);
+
+ clk_disable_unprepare(md->core_clk);
+
+ return 0;
+}
+
+static int mdio_mux_iproc_resume(struct device *dev)
+{
+ struct platform_device *pdev = to_platform_device(dev);
+ struct iproc_mdiomux_desc *md = platform_get_drvdata(pdev);
+
+ clk_prepare_enable(md->core_clk);
+ mdio_mux_iproc_config(md);
+
+ return 0;
+}
+#endif
+
+static SIMPLE_DEV_PM_OPS(mdio_mux_iproc_pm_ops,
+ mdio_mux_iproc_suspend, mdio_mux_iproc_resume);
+
static const struct of_device_id mdio_mux_iproc_match[] = {
{
.compatible = "brcm,mdio-mux-iproc",
@@ -301,6 +327,7 @@ static int mdio_mux_iproc_remove(struct platform_device *pdev)
.driver = {
.name = "mdio-mux-iproc",
.of_match_table = mdio_mux_iproc_match,
+ .pm = &mdio_mux_iproc_pm_ops,
},
.probe = mdio_mux_iproc_probe,
.remove = mdio_mux_iproc_remove,
--
1.9.1
^ permalink raw reply related
* [PATCH v3 7/8] net: phy: Add support to configure clock in Broadcom iProc mdio mux
From: Arun Parameswaran @ 2018-08-01 17:56 UTC (permalink / raw)
To: David S. Miller, Florian Fainelli, Andrew Lunn, Rob Herring,
Mark Rutland, Ray Jui, Scott Branden, Catalin Marinas,
Will Deacon
Cc: netdev, devicetree, linux-arm-kernel, linux-kernel,
bcm-kernel-feedback-list, Arun Parameswaran
In-Reply-To: <1533146186-8374-1-git-send-email-arun.parameswaran@broadcom.com>
Add support to configure the internal rate adjust register based on the
core clock supplied through device tree in the Broadcom iProc mdio mux.
The operating frequency of the mdio mux block is 11MHz. This is derrived
by dividing the clock to the mdio mux with the rate adjust register.
In some SoC's the default values of the rate adjust register do not yield
11MHz. These SoC's are required to specify the clock via the device tree
for proper operation.
Signed-off-by: Arun Parameswaran <arun.parameswaran@broadcom.com>
---
drivers/net/phy/mdio-mux-bcm-iproc.c | 42 ++++++++++++++++++++++++++++++++++--
1 file changed, 40 insertions(+), 2 deletions(-)
diff --git a/drivers/net/phy/mdio-mux-bcm-iproc.c b/drivers/net/phy/mdio-mux-bcm-iproc.c
index 5640d78..5127010 100644
--- a/drivers/net/phy/mdio-mux-bcm-iproc.c
+++ b/drivers/net/phy/mdio-mux-bcm-iproc.c
@@ -13,7 +13,7 @@
* You should have received a copy of the GNU General Public License
* version 2 (GPLv2) along with this source code.
*/
-
+#include <linux/clk.h>
#include <linux/platform_device.h>
#include <linux/device.h>
#include <linux/of_mdio.h>
@@ -22,6 +22,10 @@
#include <linux/mdio-mux.h>
#include <linux/delay.h>
+#define MDIO_RATE_ADJ_EXT_OFFSET 0x000
+#define MDIO_RATE_ADJ_INT_OFFSET 0x004
+#define MDIO_RATE_ADJ_DIVIDENT_SHIFT 16
+
#define MDIO_SCAN_CTRL_OFFSET 0x008
#define MDIO_SCAN_CTRL_OVRIDE_EXT_MSTR 28
@@ -49,21 +53,38 @@
#define MDIO_REG_ADDR_SPACE_SIZE 0x250
+#define MDIO_OPERATING_FREQUENCY 11000000
+#define MDIO_RATE_ADJ_DIVIDENT 1
+
struct iproc_mdiomux_desc {
void *mux_handle;
void __iomem *base;
struct device *dev;
struct mii_bus *mii_bus;
+ struct clk *core_clk;
};
static void mdio_mux_iproc_config(struct iproc_mdiomux_desc *md)
{
+ u32 divisor;
u32 val;
/* Disable external mdio master access */
val = readl(md->base + MDIO_SCAN_CTRL_OFFSET);
val |= BIT(MDIO_SCAN_CTRL_OVRIDE_EXT_MSTR);
writel(val, md->base + MDIO_SCAN_CTRL_OFFSET);
+
+ if (md->core_clk) {
+ /* use rate adjust regs to derrive the mdio's operating
+ * frequency from the specified core clock
+ */
+ divisor = clk_get_rate(md->core_clk) / MDIO_OPERATING_FREQUENCY;
+ divisor = divisor / (MDIO_RATE_ADJ_DIVIDENT + 1);
+ val = divisor;
+ val |= MDIO_RATE_ADJ_DIVIDENT << MDIO_RATE_ADJ_DIVIDENT_SHIFT;
+ writel(val, md->base + MDIO_RATE_ADJ_EXT_OFFSET);
+ writel(val, md->base + MDIO_RATE_ADJ_INT_OFFSET);
+ }
}
static int iproc_mdio_wait_for_idle(void __iomem *base, bool result)
@@ -204,6 +225,20 @@ static int mdio_mux_iproc_probe(struct platform_device *pdev)
return -ENOMEM;
}
+ md->core_clk = devm_clk_get(&pdev->dev, NULL);
+ if (IS_ERR(md->core_clk)) {
+ if (PTR_ERR(md->core_clk) == -EPROBE_DEFER)
+ return -EPROBE_DEFER;
+
+ md->core_clk = NULL;
+ } else {
+ rc = clk_prepare_enable(md->core_clk);
+ if (rc) {
+ dev_err(&pdev->dev, "failed to enable core clk\n");
+ return rc;
+ }
+ }
+
bus = md->mii_bus;
bus->priv = md;
bus->name = "iProc MDIO mux bus";
@@ -217,7 +252,7 @@ static int mdio_mux_iproc_probe(struct platform_device *pdev)
rc = mdiobus_register(bus);
if (rc) {
dev_err(&pdev->dev, "mdiomux registration failed\n");
- return rc;
+ goto out_clk;
}
platform_set_drvdata(pdev, md);
@@ -237,6 +272,8 @@ static int mdio_mux_iproc_probe(struct platform_device *pdev)
out_register:
mdiobus_unregister(bus);
+out_clk:
+ clk_disable_unprepare(md->core_clk);
return rc;
}
@@ -246,6 +283,7 @@ static int mdio_mux_iproc_remove(struct platform_device *pdev)
mdio_mux_uninit(md->mux_handle);
mdiobus_unregister(md->mii_bus);
+ clk_disable_unprepare(md->core_clk);
platform_set_drvdata(pdev, NULL);
return 0;
--
1.9.1
^ permalink raw reply related
* [PATCH v3 6/8] dt-bindings: net: Add clock handle to Broadcom iProc mdio mux
From: Arun Parameswaran @ 2018-08-01 17:56 UTC (permalink / raw)
To: David S. Miller, Florian Fainelli, Andrew Lunn, Rob Herring,
Mark Rutland, Ray Jui, Scott Branden, Catalin Marinas,
Will Deacon
Cc: netdev, devicetree, linux-arm-kernel, linux-kernel,
bcm-kernel-feedback-list, Arun Parameswaran
In-Reply-To: <1533146186-8374-1-git-send-email-arun.parameswaran@broadcom.com>
Add clock phandle, of the core clock driving the mdio block, as an
optional property to the Broadcom iProc mdio mux.
The clock, when specified, will be used to setup the rate adjust registers
in the mdio to derrive the mdio's operating frequency.
Signed-off-by: Arun Parameswaran <arun.parameswaran@broadcom.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Reviewed-by: Rob Herring <robh@kernel.org>
---
Documentation/devicetree/bindings/net/brcm,mdio-mux-iproc.txt | 3 +++
1 file changed, 3 insertions(+)
diff --git a/Documentation/devicetree/bindings/net/brcm,mdio-mux-iproc.txt b/Documentation/devicetree/bindings/net/brcm,mdio-mux-iproc.txt
index dc8aa68..b58843f 100644
--- a/Documentation/devicetree/bindings/net/brcm,mdio-mux-iproc.txt
+++ b/Documentation/devicetree/bindings/net/brcm,mdio-mux-iproc.txt
@@ -13,6 +13,9 @@ MDIO multiplexer node:
Every non-ethernet PHY requires a compatible so that it could be probed based
on this compatible string.
+Optional properties:
+- clocks: phandle of the core clock which drives the mdio block.
+
Additional information regarding generic multiplexer properties can be found
at- Documentation/devicetree/bindings/net/mdio-mux.txt
--
1.9.1
^ permalink raw reply related
* [PATCH v3 5/8] net: phy: Use devm api for mdio bus allocation in bcm iproc mdio mux
From: Arun Parameswaran @ 2018-08-01 17:56 UTC (permalink / raw)
To: David S. Miller, Florian Fainelli, Andrew Lunn, Rob Herring,
Mark Rutland, Ray Jui, Scott Branden, Catalin Marinas,
Will Deacon
Cc: netdev, devicetree, linux-arm-kernel, linux-kernel,
bcm-kernel-feedback-list, Arun Parameswaran
In-Reply-To: <1533146186-8374-1-git-send-email-arun.parameswaran@broadcom.com>
Use devm_mdiobus_alloc() instead of mdiobus_alloc() in the Broadcom
iProc mdio mux driver.
Also, clear the driver data on error from probe or when remove() is
called.
Signed-off-by: Arun Parameswaran <arun.parameswaran@broadcom.com>
---
drivers/net/phy/mdio-mux-bcm-iproc.c | 9 ++++-----
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/drivers/net/phy/mdio-mux-bcm-iproc.c b/drivers/net/phy/mdio-mux-bcm-iproc.c
index c36ce4b..5640d78 100644
--- a/drivers/net/phy/mdio-mux-bcm-iproc.c
+++ b/drivers/net/phy/mdio-mux-bcm-iproc.c
@@ -198,7 +198,7 @@ static int mdio_mux_iproc_probe(struct platform_device *pdev)
return PTR_ERR(md->base);
}
- md->mii_bus = mdiobus_alloc();
+ md->mii_bus = devm_mdiobus_alloc(&pdev->dev);
if (!md->mii_bus) {
dev_err(&pdev->dev, "mdiomux bus alloc failed\n");
return -ENOMEM;
@@ -217,7 +217,7 @@ static int mdio_mux_iproc_probe(struct platform_device *pdev)
rc = mdiobus_register(bus);
if (rc) {
dev_err(&pdev->dev, "mdiomux registration failed\n");
- goto out;
+ return rc;
}
platform_set_drvdata(pdev, md);
@@ -226,6 +226,7 @@ static int mdio_mux_iproc_probe(struct platform_device *pdev)
&md->mux_handle, md, md->mii_bus);
if (rc) {
dev_info(md->dev, "mdiomux initialization failed\n");
+ platform_set_drvdata(pdev, NULL);
goto out_register;
}
@@ -236,8 +237,6 @@ static int mdio_mux_iproc_probe(struct platform_device *pdev)
out_register:
mdiobus_unregister(bus);
-out:
- mdiobus_free(bus);
return rc;
}
@@ -247,7 +246,7 @@ static int mdio_mux_iproc_remove(struct platform_device *pdev)
mdio_mux_uninit(md->mux_handle);
mdiobus_unregister(md->mii_bus);
- mdiobus_free(md->mii_bus);
+ platform_set_drvdata(pdev, NULL);
return 0;
}
--
1.9.1
^ permalink raw reply related
* [PATCH v3 3/8] arm64: dts: Fix the base address of the Broadcom iProc mdio mux
From: Arun Parameswaran @ 2018-08-01 17:56 UTC (permalink / raw)
To: David S. Miller, Florian Fainelli, Andrew Lunn, Rob Herring,
Mark Rutland, Ray Jui, Scott Branden, Catalin Marinas,
Will Deacon
Cc: netdev, devicetree, linux-arm-kernel, linux-kernel,
bcm-kernel-feedback-list, Arun Parameswaran
In-Reply-To: <1533146186-8374-1-git-send-email-arun.parameswaran@broadcom.com>
Modify the base address of the mdio mux driver to point to the
start of the mdio mux block's register address space.
Signed-off-by: Arun Parameswaran <arun.parameswaran@broadcom.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
---
arch/arm64/boot/dts/broadcom/northstar2/ns2.dtsi | 4 ++--
arch/arm64/boot/dts/broadcom/stingray/stingray.dtsi | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/boot/dts/broadcom/northstar2/ns2.dtsi b/arch/arm64/boot/dts/broadcom/northstar2/ns2.dtsi
index 4057197..1a406a7 100644
--- a/arch/arm64/boot/dts/broadcom/northstar2/ns2.dtsi
+++ b/arch/arm64/boot/dts/broadcom/northstar2/ns2.dtsi
@@ -482,9 +482,9 @@
status = "disabled";
};
- mdio_mux_iproc: mdio-mux@6602023c {
+ mdio_mux_iproc: mdio-mux@66020000 {
compatible = "brcm,mdio-mux-iproc";
- reg = <0x6602023c 0x14>;
+ reg = <0x66020000 0x250>;
#address-cells = <1>;
#size-cells = <0>;
diff --git a/arch/arm64/boot/dts/broadcom/stingray/stingray.dtsi b/arch/arm64/boot/dts/broadcom/stingray/stingray.dtsi
index b203152..a70e8dd 100644
--- a/arch/arm64/boot/dts/broadcom/stingray/stingray.dtsi
+++ b/arch/arm64/boot/dts/broadcom/stingray/stingray.dtsi
@@ -278,9 +278,9 @@
#include "stingray-pinctrl.dtsi"
- mdio_mux_iproc: mdio-mux@2023c {
+ mdio_mux_iproc: mdio-mux@20000 {
compatible = "brcm,mdio-mux-iproc";
- reg = <0x0002023c 0x14>;
+ reg = <0x00020000 0x250>;
#address-cells = <1>;
#size-cells = <0>;
--
1.9.1
^ permalink raw reply related
* [PATCH v3 0/8] Add clock config and pm support to bcm iProc mdio mux
From: Arun Parameswaran @ 2018-08-01 17:56 UTC (permalink / raw)
To: David S. Miller, Florian Fainelli, Andrew Lunn, Rob Herring,
Mark Rutland, Ray Jui, Scott Branden, Catalin Marinas,
Will Deacon
Cc: netdev, devicetree, linux-arm-kernel, linux-kernel,
bcm-kernel-feedback-list, Arun Parameswaran
Hi,
The patchset is based on David Miller's "net-next" repo.
The patchset extends the Broadcom iProc mdio mux to add support for
suspend/resume and the ability to configure the internal clock
divider. The patchset also sets the scan control register to
disable external master access.
The base address of the mdio-mux-bcm-iproc is modified to point to the
start of the mdio block's address space, to be able to access all the
mdio's registers. The missing registers are required to configure the
internal clock divider registers in some of the Broadcom SoC's.
Changes from v2:
- Addressed Andrew's comments:
- Moved to using devm_mdiobus_alloc. Added this as a separate patch.
- Changed to reverse christmas tree order for variable declaration in
the clock patch
- Addressed Florian's comments:
- Removed null checks for the clock before calling unprepare in
both clock and pm patches.
- Added check for EPROBE_DEFER when fetching the clock in the clock
patch.
- The patch to use the devm API has been added before the clock & pm
patches. This patch is now patch '5' in the series.
- Added reviewed-by tags to commit messages of patches which remain
unmodified from v2.
- Modified PM patch to use platform_get_drvdata() in suspend/resume
API's, similar to the recent fix that went in for the remove()
api.
Changes from v1:
- Addressed Andrew's comments.
- Reworked the patches to be based on 'net-next'
- Removed 'fixes' from the commit messages, the changes are related
to the new features being added.
- Maintained backward compatibility to older dt-blob's specifying
base addresse with an offset. The correction is applied in the
driver and a message is printed to update the dt-blob.
- Re-worked and re-ordered the last four patches (4-7).
- Added setting of the scan control register as a new patch
- Added a call to 'clk_prepare_enable()' in the patch that adds
the clock config support, removed the debug message when clock
is not passed.
- Simplified the pm support patch (removed the array used for the
save/restore logic).
Thanks
Arun Parameswaran (8):
dt-bindings: net: Fix Broadcom iProc mdio mux driver base address
net: phy: Fix the register offsets in Broadcom iProc mdio mux driver
arm64: dts: Fix the base address of the Broadcom iProc mdio mux
net: phy: Disable external master access in bcm mdio mux driver
net: phy: Use devm api for mdio bus allocation in bcm iproc mdio mux
dt-bindings: net: Add clock handle to Broadcom iProc mdio mux
net: phy: Add support to configure clock in Broadcom iProc mdio mux
net: phy: Add pm support to Broadcom iProc mdio mux driver
.../bindings/net/brcm,mdio-mux-iproc.txt | 7 +-
arch/arm64/boot/dts/broadcom/northstar2/ns2.dtsi | 4 +-
.../arm64/boot/dts/broadcom/stingray/stingray.dtsi | 4 +-
drivers/net/phy/mdio-mux-bcm-iproc.c | 111 +++++++++++++++++++--
4 files changed, 109 insertions(+), 17 deletions(-)
--
1.9.1
^ permalink raw reply
* Re: [PATCH net-next] virtio_net: force_napi_tx module param.
From: Willem de Bruijn @ 2018-08-01 15:56 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: David Miller, caleb.raitto, Jason Wang, Network Development,
Caleb Raitto
In-Reply-To: <CAF=yD-JVj9SLNBftB=ut2-duhi4HQdLBByOHJaZDdavLabD+OA@mail.gmail.com>
> > > > Just distribute across the available cpus evenly, and be done with it.
> > >
> > > Sounds good to me.
> >
> > So e.g. we could set an affinity hint to a group of CPUs that
> > might transmit to this queue.
>
> We also want to set the xps mask for all cpus in the group to this queue.
>
> Is there a benefit over explicitly choosing one cpu from the set, btw?
> I assumed striping. Something along the lines of
>
> int stripe = max_t(int, num_online_cpus() / vi->curr_queue_pairs, 1);
> int vq = 0;
>
> cpumask_clear(xps_mask);
>
> for_each_online_cpu(cpu) {
> cpumask_set_cpu(cpu, xps_mask);
>
> if ((i + 1) % stripe == 0) {
> virtqueue_set_affinity(vi->rq[vq].vq, cpu);
> virtqueue_set_affinity(vi->sq[vq].vq, cpu);
> netif_set_xps_queue(vi->dev, xps_mask, vq);
> cpumask_clear(xps_mask);
> vq++;
> }
> i++;
> }
.. but handling edge cases correctly, such as #cpu not being a perfect
multiple of #vq.
^ permalink raw reply
* Re: [PATCH net-next] virtio_net: force_napi_tx module param.
From: Willem de Bruijn @ 2018-08-01 15:46 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: David Miller, caleb.raitto, Jason Wang, Network Development,
Caleb Raitto
In-Reply-To: <20180731153204-mutt-send-email-mst@kernel.org>
On Tue, Jul 31, 2018 at 8:34 AM Michael S. Tsirkin <mst@redhat.com> wrote:
>
> On Sun, Jul 29, 2018 at 05:32:56PM -0400, Willem de Bruijn wrote:
> > On Sun, Jul 29, 2018 at 12:01 PM David Miller <davem@davemloft.net> wrote:
> > >
> > > From: Caleb Raitto <caleb.raitto@gmail.com>
> > > Date: Mon, 23 Jul 2018 16:11:19 -0700
> > >
> > > > From: Caleb Raitto <caraitto@google.com>
> > > >
> > > > The driver disables tx napi if it's not certain that completions will
> > > > be processed affine with tx service.
> > > >
> > > > Its heuristic doesn't account for some scenarios where it is, such as
> > > > when the queue pair count matches the core but not hyperthread count.
> > > >
> > > > Allow userspace to override the heuristic. This is an alternative
> > > > solution to that in the linked patch. That added more logic in the
> > > > kernel for these cases, but the agreement was that this was better left
> > > > to user control.
> > > >
> > > > Do not expand the existing napi_tx variable to a ternary value,
> > > > because doing so can break user applications that expect
> > > > boolean ('Y'/'N') instead of integer output. Add a new param instead.
> > > >
> > > > Link: https://patchwork.ozlabs.org/patch/725249/
> > > > Acked-by: Willem de Bruijn <willemb@google.com>
> > > > Acked-by: Jon Olson <jonolson@google.com>
> > > > Signed-off-by: Caleb Raitto <caraitto@google.com>
> > >
> > > So I looked into the history surrounding these issues.
> > >
> > > First of all, it's always ends up turning out crummy when drivers start
> > > to set affinities themselves. The worst possible case is to do it
> > > _conditionally_, and that is exactly what virtio_net is doing.
> > >
> > > From the user's perspective, this provides a really bad experience.
> > >
> > > So if I have a 32-queue device and there are 32 cpus, you'll do all
> > > the affinity settings, stopping Irqbalanced from doing anything
> > > right?
> > >
> > > So if I add one more cpu, you'll say "oops, no idea what to do in
> > > this situation" and not touch the affinities at all?
> > >
> > > That makes no sense at all.
> > >
> > > If the driver is going to set affinities at all, OWN that decision
> > > and set it all the time to something reasonable.
> > >
> > > Or accept that you shouldn't be touching this stuff in the first place
> > > and leave the affinities alone.
> > >
> > > Right now we're kinda in a situation where the driver has been setting
> > > affinities in the ncpus==nqueues cases for some time, so we can't stop
> > > doing it.
> > >
> > > Which means we have to set them in all cases to make the user
> > > experience sane again.
> > >
> > > I looked at the linked to patch again:
> > >
> > > https://patchwork.ozlabs.org/patch/725249/
> > >
> > > And I think the strategy should be made more generic, to get rid of
> > > the hyperthreading assumptions. I also agree that the "assign
> > > to first N cpus" logic doesn't make much sense either.
> > >
> > > Just distribute across the available cpus evenly, and be done with it.
> >
> > Sounds good to me.
>
> So e.g. we could set an affinity hint to a group of CPUs that
> might transmit to this queue.
We also want to set the xps mask for all cpus in the group to this queue.
Is there a benefit over explicitly choosing one cpu from the set, btw?
I assumed striping. Something along the lines of
int stripe = max_t(int, num_online_cpus() / vi->curr_queue_pairs, 1);
int vq = 0;
cpumask_clear(xps_mask);
for_each_online_cpu(cpu) {
cpumask_set_cpu(cpu, xps_mask);
if ((i + 1) % stripe == 0) {
virtqueue_set_affinity(vi->rq[vq].vq, cpu);
virtqueue_set_affinity(vi->sq[vq].vq, cpu);
netif_set_xps_queue(vi->dev, xps_mask, vq);
cpumask_clear(xps_mask);
vq++;
}
i++;
}
^ permalink raw reply
* Re: SLAB_TYPESAFE_BY_RCU without constructors (was Re: [PATCH v4 13/17] khwasan: add hooks implementation)
From: Eric Dumazet @ 2018-08-01 15:37 UTC (permalink / raw)
To: Christoph Lameter
Cc: Dmitry Vyukov, Eric Dumazet, Andrey Ryabinin, Linus Torvalds,
Theodore Ts'o, jack, linux-ext4, Greg Kroah-Hartman,
Pablo Neira Ayuso, Jozsef Kadlecsik, Florian Westphal,
David Miller, netfilter-devel, coreteam, netdev, Gerrit Renker,
dccp, jani.nikula, joonas.lahtinen, rodrigo.vivi, airlied,
intel-gfx, dri-devel
In-Reply-To: <01000164f60f3f12-b1253c6e-ee57-49fc-aed8-0944ab4fd7a2-000000@email.amazonses.com>
On Wed, Aug 1, 2018 at 8:15 AM Christopher Lameter <cl@linux.com> wrote:
>
> On Wed, 1 Aug 2018, Dmitry Vyukov wrote:
>
> > But we are trading 1 indirect call for comparable overhead removed
> > from much more common path. The path that does ctors is also calling
> > into page alloc, which is much more expensive.
> > So ctor should be a net win on performance front, no?
>
> ctor would make it esier to review the flow and guarantee that the object
> always has certain fields set as required before any use by the subsystem.
>
> ctors are run once on allocation of the slab page for all objects in it.
>
> ctors are not called duiring allocation and freeing of objects from the
> slab page. So we could avoid the intialization of the spinlock on each
> object allocation which actually should be faster.
This strategy might have been a win 30 years ago when cpu had no
caches (or too small anyway)
What probability is that the 60 bytes around the spinlock are not
touched after the object is freshly allocated ?
-> None
Writing 60 bytes in one cache line instead of 64 has really the same
cost. The cache line miss is the real killer.
Feel free to write the patches, test them, but I doubt you will have any gain.
Remember btw that TCP sockets can be either completely fresh
(socket() call, using memset() to clear the whole object),
or clones (accept() thus copying the parent socket)
The idea of having a ctor() would only be a win if all the fields that
can be initialized in the ctor are contiguous and fill an integral
number of cache lines.
^ permalink raw reply
* [PATCH] drivers: net: lmc: fix case value for target abort error
From: Colin King @ 2018-08-01 17:22 UTC (permalink / raw)
To: David S . Miller, Vasyl Gomonovych, netdev; +Cc: kernel-janitors, linux-kernel
From: Colin Ian King <colin.king@canonical.com>
Current value for a target abort error is 0x010, however, this value
should in fact be 0x002. As it stands, the range of error is 0..7 so
it is currently never being detected. This bug has been in the driver
since the early 2.6.12 days (or before).
Detected by CoverityScan, CID#744290 ("Logically dead code")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
---
drivers/net/wan/lmc/lmc_main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wan/lmc/lmc_main.c b/drivers/net/wan/lmc/lmc_main.c
index 093bd21f574d..4907453f17f5 100644
--- a/drivers/net/wan/lmc/lmc_main.c
+++ b/drivers/net/wan/lmc/lmc_main.c
@@ -1362,7 +1362,7 @@ static irqreturn_t lmc_interrupt (int irq, void *dev_instance) /*fold00*/
case 0x001:
printk(KERN_WARNING "%s: Master Abort (naughty)\n", dev->name);
break;
- case 0x010:
+ case 0x002:
printk(KERN_WARNING "%s: Target Abort (not so naughty)\n", dev->name);
break;
default:
--
2.17.1
^ permalink raw reply related
* Re: SLAB_TYPESAFE_BY_RCU without constructors (was Re: [PATCH v4 13/17] khwasan: add hooks implementation)
From: Eric Dumazet @ 2018-08-01 17:18 UTC (permalink / raw)
To: Dmitry Vyukov
Cc: Eric Dumazet, Christoph Lameter, Andrey Ryabinin, Linus Torvalds,
Theodore Ts'o, jack, linux-ext4, Greg Kroah-Hartman,
Pablo Neira Ayuso, Jozsef Kadlecsik, Florian Westphal,
David Miller, netfilter-devel, coreteam, netdev, Gerrit Renker,
dccp, jani.nikula, joonas.lahtinen, rodrigo.vivi, airlied,
intel-gfx, dri-devel
In-Reply-To: <CACT4Y+akncPCAZ2pUX3xEpUPELQAei1XzYByB8Dohfz-Ve0k5w@mail.gmail.com>
On Wed, Aug 1, 2018 at 9:47 AM Dmitry Vyukov <dvyukov@google.com> wrote:
>
> Proving with numbers is required for a claimed performance improvement
> at the cost of code degradation/increase. For a win-win change there
> is really nothing to prove.
You have to _prove_ it is a win-win.
It is not sufficient to claim it is a win-win.
Sorry, but I do have bugs to take care of.
^ permalink raw reply
* Re: [PATCH net-next 7/9] net: stmmac: Integrate XGMAC into main driver flow
From: Andrew Lunn @ 2018-08-01 15:23 UTC (permalink / raw)
To: Jose Abreu
Cc: netdev, David S. Miller, Joao Pinto, Giuseppe Cavallaro,
Alexandre Torgue
In-Reply-To: <39b57ee542fc20a1c457c12e6011dc239dda8725.1533125016.git.joabreu@synopsys.com>
> @@ -842,6 +863,12 @@ static void stmmac_adjust_link(struct net_device *dev)
> new_state = true;
> ctrl &= ~priv->hw->link.speed_mask;
> switch (phydev->speed) {
> + case SPEED_10000:
> + ctrl |= priv->hw->link.speed10000;
> + break;
> + case SPEED_2500:
> + ctrl |= priv->hw->link.speed2500;
> + break;
> case SPEED_1000:
> ctrl |= priv->hw->link.speed1000;
> break;
Hi Jose
What PHY did you test this with?
10G phys change the interface mode when the speed change. In general,
10/100/1000G copper uses SGMII. A 1G SFP optical module generally
wants 1000Base-X. 2.5G wants 2500Base-X, 10G copper wants 10GKR, etc.
So your adjust link callback needs to look at phydev->interface and
reconfigure the MAC as requested.
You might also want to consider moving from phylib to phylink. It has
a better interface for things like this, and makes support for SFP
interfaces much easier. A MAC which supports 10G is likely to be used
with SFPs...
Andrew
^ permalink raw reply
* Re: [PATCH] HID: Bluetooth: hidp: buffer overflow in hidp_process_report
From: Greg KH @ 2018-08-01 17:09 UTC (permalink / raw)
To: Mark Salyzyn
Cc: linux-kernel, Marcel Holtmann, Johan Hedberg, David S. Miller,
Kees Cook, Benjamin Tissoires, linux-bluetooth, netdev, stable,
kernel-team, Jiri Kosina
In-Reply-To: <6f6c3e63-0847-b0b6-98a3-7ad62fd2697c@android.com>
On Wed, Aug 01, 2018 at 09:41:04AM -0700, Mark Salyzyn wrote:
> On 08/01/2018 09:37 AM, Greg KH wrote:
> > On Tue, Jul 31, 2018 at 03:02:13PM -0700, Mark Salyzyn wrote:
> > > CVE-2018-9363
> > >
> > > The buffer length is unsigned at all layers, but gets cast to int and
> > > checked in hidp_process_report and can lead to a buffer overflow.
> > > Switch len parameter to unsigned int to resolve issue.
> > >
> > > This affects 3.18 and newer kernels.
> > >
> > > Signed-off-by: Mark Salyzyn <salyzyn@android.com>
> > > Fixes: a4b1b5877b514b276f0f31efe02388a9c2836728 ("HID: Bluetooth: hidp: make sure input buffers are big enough")
> > > Cc: Marcel Holtmann <marcel@holtmann.org>
> > > Cc: Johan Hedberg <johan.hedberg@gmail.com>
> > > Cc: "David S. Miller" <davem@davemloft.net>
> > > Cc: Kees Cook <keescook@chromium.org>
> > > Cc: Benjamin Tissoires <benjamin.tissoires@redhat.com>
> > > Cc: linux-bluetooth@vger.kernel.org
> > > Cc: netdev@vger.kernel.org
> > > Cc: linux-kernel@vger.kernel.org
> > > Cc: security@kernel.org
> > > Cc: kernel-team@android.com
> > Nit, you only need to bother security@ if you do not have a fix and need
> > to figure out one.
>
> Thanks, I thought anything with a CVE was to go there according to netdev
> FAQ (dropped security from response list).
> > Also, you forgot to cc: stable@vger.kernel.org to be included in older
> > kernel releases :(
> netdev FAQ said to _not_ copy stable, I am so confused ;-{ (added stable to
> response list b/c patch is now taken into bluetooth-next)
Ah, well, bluetooth is a bit not normal here, usually stuff that ends up
in a subsystem tree before netdev needs to have a cc: stable on it for
me to catch it. Hopefully the bluetooth maintainers are on it :)
thanks,
greg k-h
^ 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