* [PATCH AUTOSEL 5.4 058/459] net: ethernet: ixp4xx: Standard module init
From: Sasha Levin @ 2020-02-14 15:55 UTC (permalink / raw)
To: linux-kernel, stable; +Cc: Linus Walleij, Jakub Kicinski, Sasha Levin, netdev
In-Reply-To: <20200214160149.11681-1-sashal@kernel.org>
From: Linus Walleij <linus.walleij@linaro.org>
[ Upstream commit c83db9ef5640548631707e8b4a7bcddc115fdbae ]
The IXP4xx driver was initializing the MDIO bus before even
probing, in the callbacks supposed to be used for setting up
the module itself, and with the side effect of trying to
register the MDIO bus as soon as this module was loaded or
compiled into the kernel whether the device was discovered
or not.
This does not work with multiplatform environments.
To get rid of this: set up the MDIO bus from the probe()
callback and remove it in the remove() callback. Rename
the probe() and remove() calls to reflect the most common
conventions.
Since there is a bit of checking for the ethernet feature
to be present in the MDIO registering function, making the
whole module not even be registered if we can't find an
MDIO bus, we need something similar: register the MDIO
bus when the corresponding ethernet is probed, and
return -EPROBE_DEFER on the other interfaces until this
happens. If no MDIO bus is present on any of the
registered interfaces we will eventually bail out.
None of the platforms I've seen has e.g. MDIO on EthB
and only uses EthC, there is always a Ethernet hardware
on the NPE (B, C) that has the MDIO bus, we just might
have to wait for it.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/ethernet/xscale/ixp4xx_eth.c | 96 +++++++++++-------------
1 file changed, 44 insertions(+), 52 deletions(-)
diff --git a/drivers/net/ethernet/xscale/ixp4xx_eth.c b/drivers/net/ethernet/xscale/ixp4xx_eth.c
index 6fc04ffb22c2a..d4e095d0e8f14 100644
--- a/drivers/net/ethernet/xscale/ixp4xx_eth.c
+++ b/drivers/net/ethernet/xscale/ixp4xx_eth.c
@@ -517,25 +517,14 @@ static int ixp4xx_mdio_write(struct mii_bus *bus, int phy_id, int location,
return ret;
}
-static int ixp4xx_mdio_register(void)
+static int ixp4xx_mdio_register(struct eth_regs __iomem *regs)
{
int err;
if (!(mdio_bus = mdiobus_alloc()))
return -ENOMEM;
- if (cpu_is_ixp43x()) {
- /* IXP43x lacks NPE-B and uses NPE-C for MII PHY access */
- if (!(ixp4xx_read_feature_bits() & IXP4XX_FEATURE_NPEC_ETH))
- return -ENODEV;
- mdio_regs = (struct eth_regs __iomem *)IXP4XX_EthC_BASE_VIRT;
- } else {
- /* All MII PHY accesses use NPE-B Ethernet registers */
- if (!(ixp4xx_read_feature_bits() & IXP4XX_FEATURE_NPEB_ETH0))
- return -ENODEV;
- mdio_regs = (struct eth_regs __iomem *)IXP4XX_EthB_BASE_VIRT;
- }
-
+ mdio_regs = regs;
__raw_writel(DEFAULT_CORE_CNTRL, &mdio_regs->core_control);
spin_lock_init(&mdio_lock);
mdio_bus->name = "IXP4xx MII Bus";
@@ -1374,7 +1363,7 @@ static const struct net_device_ops ixp4xx_netdev_ops = {
.ndo_validate_addr = eth_validate_addr,
};
-static int eth_init_one(struct platform_device *pdev)
+static int ixp4xx_eth_probe(struct platform_device *pdev)
{
struct port *port;
struct net_device *dev;
@@ -1384,7 +1373,7 @@ static int eth_init_one(struct platform_device *pdev)
char phy_id[MII_BUS_ID_SIZE + 3];
int err;
- if (!(dev = alloc_etherdev(sizeof(struct port))))
+ if (!(dev = devm_alloc_etherdev(&pdev->dev, sizeof(struct port))))
return -ENOMEM;
SET_NETDEV_DEV(dev, &pdev->dev);
@@ -1394,20 +1383,51 @@ static int eth_init_one(struct platform_device *pdev)
switch (port->id) {
case IXP4XX_ETH_NPEA:
+ /* If the MDIO bus is not up yet, defer probe */
+ if (!mdio_bus)
+ return -EPROBE_DEFER;
port->regs = (struct eth_regs __iomem *)IXP4XX_EthA_BASE_VIRT;
regs_phys = IXP4XX_EthA_BASE_PHYS;
break;
case IXP4XX_ETH_NPEB:
+ /*
+ * On all except IXP43x, NPE-B is used for the MDIO bus.
+ * If there is no NPE-B in the feature set, bail out, else
+ * register the MDIO bus.
+ */
+ if (!cpu_is_ixp43x()) {
+ if (!(ixp4xx_read_feature_bits() &
+ IXP4XX_FEATURE_NPEB_ETH0))
+ return -ENODEV;
+ /* Else register the MDIO bus on NPE-B */
+ if ((err = ixp4xx_mdio_register(IXP4XX_EthC_BASE_VIRT)))
+ return err;
+ }
+ if (!mdio_bus)
+ return -EPROBE_DEFER;
port->regs = (struct eth_regs __iomem *)IXP4XX_EthB_BASE_VIRT;
regs_phys = IXP4XX_EthB_BASE_PHYS;
break;
case IXP4XX_ETH_NPEC:
+ /*
+ * IXP43x lacks NPE-B and uses NPE-C for the MDIO bus access,
+ * of there is no NPE-C, no bus, nothing works, so bail out.
+ */
+ if (cpu_is_ixp43x()) {
+ if (!(ixp4xx_read_feature_bits() &
+ IXP4XX_FEATURE_NPEC_ETH))
+ return -ENODEV;
+ /* Else register the MDIO bus on NPE-C */
+ if ((err = ixp4xx_mdio_register(IXP4XX_EthC_BASE_VIRT)))
+ return err;
+ }
+ if (!mdio_bus)
+ return -EPROBE_DEFER;
port->regs = (struct eth_regs __iomem *)IXP4XX_EthC_BASE_VIRT;
regs_phys = IXP4XX_EthC_BASE_PHYS;
break;
default:
- err = -ENODEV;
- goto err_free;
+ return -ENODEV;
}
dev->netdev_ops = &ixp4xx_netdev_ops;
@@ -1416,10 +1436,8 @@ static int eth_init_one(struct platform_device *pdev)
netif_napi_add(dev, &port->napi, eth_poll, NAPI_WEIGHT);
- if (!(port->npe = npe_request(NPE_ID(port->id)))) {
- err = -EIO;
- goto err_free;
- }
+ if (!(port->npe = npe_request(NPE_ID(port->id))))
+ return -EIO;
port->mem_res = request_mem_region(regs_phys, REGS_SIZE, dev->name);
if (!port->mem_res) {
@@ -1465,12 +1483,10 @@ static int eth_init_one(struct platform_device *pdev)
release_resource(port->mem_res);
err_npe_rel:
npe_release(port->npe);
-err_free:
- free_netdev(dev);
return err;
}
-static int eth_remove_one(struct platform_device *pdev)
+static int ixp4xx_eth_remove(struct platform_device *pdev)
{
struct net_device *dev = platform_get_drvdata(pdev);
struct phy_device *phydev = dev->phydev;
@@ -1478,45 +1494,21 @@ static int eth_remove_one(struct platform_device *pdev)
unregister_netdev(dev);
phy_disconnect(phydev);
+ ixp4xx_mdio_remove();
npe_port_tab[NPE_ID(port->id)] = NULL;
npe_release(port->npe);
release_resource(port->mem_res);
- free_netdev(dev);
return 0;
}
static struct platform_driver ixp4xx_eth_driver = {
.driver.name = DRV_NAME,
- .probe = eth_init_one,
- .remove = eth_remove_one,
+ .probe = ixp4xx_eth_probe,
+ .remove = ixp4xx_eth_remove,
};
-
-static int __init eth_init_module(void)
-{
- int err;
-
- /*
- * FIXME: we bail out on device tree boot but this really needs
- * to be fixed in a nicer way: this registers the MDIO bus before
- * even matching the driver infrastructure, we should only probe
- * detected hardware.
- */
- if (of_have_populated_dt())
- return -ENODEV;
- if ((err = ixp4xx_mdio_register()))
- return err;
- return platform_driver_register(&ixp4xx_eth_driver);
-}
-
-static void __exit eth_cleanup_module(void)
-{
- platform_driver_unregister(&ixp4xx_eth_driver);
- ixp4xx_mdio_remove();
-}
+module_platform_driver(ixp4xx_eth_driver);
MODULE_AUTHOR("Krzysztof Halasa");
MODULE_DESCRIPTION("Intel IXP4xx Ethernet driver");
MODULE_LICENSE("GPL v2");
MODULE_ALIAS("platform:ixp4xx_eth");
-module_init(eth_init_module);
-module_exit(eth_cleanup_module);
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 5.4 062/459] spi: fsl-lpspi: fix only one cs-gpio working
From: Sasha Levin @ 2020-02-14 15:55 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Philippe Schenker, Mark Brown, Sasha Levin, linux-spi
In-Reply-To: <20200214160149.11681-1-sashal@kernel.org>
From: Philippe Schenker <philippe.schenker@toradex.com>
[ Upstream commit bc3a8b295e5bca9d1ec2622a6ba38289f9fd3d8a ]
Why it does not work at the moment:
- num_chipselect sets the number of cs-gpios that are in the DT.
This comes from drivers/spi/spi.c
- num_chipselect gets set with devm_spi_register_controller, that is
called in drivers/spi/spi.c
- devm_spi_register_controller got called after num_chipselect has
been used.
How this commit fixes the issue:
- devm_spi_register_controller gets called before num_chipselect is
being used.
Fixes: c7a402599504 ("spi: lpspi: use the core way to implement cs-gpio function")
Signed-off-by: Philippe Schenker <philippe.schenker@toradex.com>
Link: https://lore.kernel.org/r/20191204141312.1411251-1-philippe.schenker@toradex.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/spi/spi-fsl-lpspi.c | 32 ++++++++++++++++----------------
1 file changed, 16 insertions(+), 16 deletions(-)
diff --git a/drivers/spi/spi-fsl-lpspi.c b/drivers/spi/spi-fsl-lpspi.c
index 3528ed5eea9b5..92e460d4f3d10 100644
--- a/drivers/spi/spi-fsl-lpspi.c
+++ b/drivers/spi/spi-fsl-lpspi.c
@@ -862,6 +862,22 @@ static int fsl_lpspi_probe(struct platform_device *pdev)
fsl_lpspi->dev = &pdev->dev;
fsl_lpspi->is_slave = is_slave;
+ controller->bits_per_word_mask = SPI_BPW_RANGE_MASK(8, 32);
+ controller->transfer_one = fsl_lpspi_transfer_one;
+ controller->prepare_transfer_hardware = lpspi_prepare_xfer_hardware;
+ controller->unprepare_transfer_hardware = lpspi_unprepare_xfer_hardware;
+ controller->mode_bits = SPI_CPOL | SPI_CPHA | SPI_CS_HIGH;
+ controller->flags = SPI_MASTER_MUST_RX | SPI_MASTER_MUST_TX;
+ controller->dev.of_node = pdev->dev.of_node;
+ controller->bus_num = pdev->id;
+ controller->slave_abort = fsl_lpspi_slave_abort;
+
+ ret = devm_spi_register_controller(&pdev->dev, controller);
+ if (ret < 0) {
+ dev_err(&pdev->dev, "spi_register_controller error.\n");
+ goto out_controller_put;
+ }
+
if (!fsl_lpspi->is_slave) {
for (i = 0; i < controller->num_chipselect; i++) {
int cs_gpio = of_get_named_gpio(np, "cs-gpios", i);
@@ -885,16 +901,6 @@ static int fsl_lpspi_probe(struct platform_device *pdev)
controller->prepare_message = fsl_lpspi_prepare_message;
}
- controller->bits_per_word_mask = SPI_BPW_RANGE_MASK(8, 32);
- controller->transfer_one = fsl_lpspi_transfer_one;
- controller->prepare_transfer_hardware = lpspi_prepare_xfer_hardware;
- controller->unprepare_transfer_hardware = lpspi_unprepare_xfer_hardware;
- controller->mode_bits = SPI_CPOL | SPI_CPHA | SPI_CS_HIGH;
- controller->flags = SPI_MASTER_MUST_RX | SPI_MASTER_MUST_TX;
- controller->dev.of_node = pdev->dev.of_node;
- controller->bus_num = pdev->id;
- controller->slave_abort = fsl_lpspi_slave_abort;
-
init_completion(&fsl_lpspi->xfer_done);
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
@@ -952,12 +958,6 @@ static int fsl_lpspi_probe(struct platform_device *pdev)
if (ret < 0)
dev_err(&pdev->dev, "dma setup error %d, use pio\n", ret);
- ret = devm_spi_register_controller(&pdev->dev, controller);
- if (ret < 0) {
- dev_err(&pdev->dev, "spi_register_controller error.\n");
- goto out_controller_put;
- }
-
return 0;
out_controller_put:
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 5.4 046/459] x86/fpu: Deactivate FPU state after failure during state load
From: Sasha Levin @ 2020-02-14 15:54 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Sebastian Andrzej Siewior, Yu-cheng Yu, Borislav Petkov,
Andy Lutomirski, Dave Hansen, Fenghua Yu, H. Peter Anvin,
Ingo Molnar, Jann Horn, Peter Zijlstra, Ravi V. Shankar,
Rik van Riel, Thomas Gleixner, Tony Luck, x86-ml, Sasha Levin
In-Reply-To: <20200214160149.11681-1-sashal@kernel.org>
From: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
[ Upstream commit bbc55341b9c67645d1a5471506370caf7dd4a203 ]
In __fpu__restore_sig(), fpu_fpregs_owner_ctx needs to be reset if the
FPU state was not fully restored. Otherwise the following may happen (on
the same CPU):
Task A Task B fpu_fpregs_owner_ctx
*active* A.fpu
__fpu__restore_sig()
ctx switch load B.fpu
*active* B.fpu
fpregs_lock()
copy_user_to_fpregs_zeroing()
copy_kernel_to_xregs() *modify*
copy_user_to_xregs() *fails*
fpregs_unlock()
ctx switch skip loading B.fpu,
*active* B.fpu
In the success case, fpu_fpregs_owner_ctx is set to the current task.
In the failure case, the FPU state might have been modified by loading
the init state.
In this case, fpu_fpregs_owner_ctx needs to be reset in order to ensure
that the FPU state of the following task is loaded from saved state (and
not skipped because it was the previous state).
Reset fpu_fpregs_owner_ctx after a failure during restore occurred, to
ensure that the FPU state for the next task is always loaded.
The problem was debugged-by Yu-cheng Yu <yu-cheng.yu@intel.com>.
[ bp: Massage commit message. ]
Fixes: 5f409e20b7945 ("x86/fpu: Defer FPU state load until return to userspace")
Reported-by: Yu-cheng Yu <yu-cheng.yu@intel.com>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Borislav Petkov <bp@suse.de>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: Fenghua Yu <fenghua.yu@intel.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Jann Horn <jannh@google.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: "Ravi V. Shankar" <ravi.v.shankar@intel.com>
Cc: Rik van Riel <riel@surriel.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Tony Luck <tony.luck@intel.com>
Cc: x86-ml <x86@kernel.org>
Link: https://lkml.kernel.org/r/20191220195906.plk6kpmsrikvbcfn@linutronix.de
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
arch/x86/kernel/fpu/signal.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/x86/kernel/fpu/signal.c b/arch/x86/kernel/fpu/signal.c
index 0071b794ed193..400a05e1c1c51 100644
--- a/arch/x86/kernel/fpu/signal.c
+++ b/arch/x86/kernel/fpu/signal.c
@@ -352,6 +352,7 @@ static int __fpu__restore_sig(void __user *buf, void __user *buf_fx, int size)
fpregs_unlock();
return 0;
}
+ fpregs_deactivate(fpu);
fpregs_unlock();
}
@@ -403,6 +404,8 @@ static int __fpu__restore_sig(void __user *buf, void __user *buf_fx, int size)
}
if (!ret)
fpregs_mark_activate();
+ else
+ fpregs_deactivate(fpu);
fpregs_unlock();
err_out:
--
2.20.1
^ permalink raw reply related
* Re: [PATCH] kvm: x86: Print "disabled by bios" only once per host
From: Jim Mattson @ 2020-02-14 17:43 UTC (permalink / raw)
To: Erwan Velu
Cc: Erwan Velu, Paolo Bonzini, Sean Christopherson, Vitaly Kuznetsov,
Wanpeng Li, Joerg Roedel, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, H. Peter Anvin, the arch/x86 maintainers,
kvm list, LKML
In-Reply-To: <20200214143035.607115-1-e.velu@criteo.com>
On Fri, Feb 14, 2020 at 6:33 AM Erwan Velu <erwanaliasr1@gmail.com> wrote:
>
> The current behavior is to print a "disabled by bios" message per CPU thread.
> As modern CPUs can have up to 64 cores, 128 on a dual socket, and turns this
> printk to be a pretty noisy by showing up to 256 times the same line in a row.
>
> This patch offer to only print the message once per host considering the BIOS will
> disabled the feature for all sockets/cores at once and not on a per core basis.
That's quite an assumption you're making. I guess I've seen more
broken BIOSes than you have. :-) Still, I would rather see the message
just once--perhaps with an additional warning if all logical
processors aren't in agreement.
^ permalink raw reply
* [PATCH 4/4] docs: admin-guide: edid: Clarify where to run "make"
From: Jonathan Neuschäfer @ 2020-02-14 17:41 UTC (permalink / raw)
To: linux-doc
Cc: Jonathan Corbet, Jonathan Neuschäfer, Mauro Carvalho Chehab,
Cornelia Huck, Logan Gunthorpe, Andy Shevchenko,
Matthew Wilcox (Oracle), Shobhit Kukreti, Thomas Gleixner,
Greg Kroah-Hartman, Jason Gunthorpe, Harald Seiler, linux-kernel
In-Reply-To: <20200214174139.16101-1-j.neuschaefer@gmx.net>
When both the documentation and the data files lived in
Documentation/EDID, this wasn't necessary, but both have
been moved to other directories in the meantime.
Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
---
Documentation/admin-guide/edid.rst | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/admin-guide/edid.rst b/Documentation/admin-guide/edid.rst
index 7dc07942ceb2..80deeb21a265 100644
--- a/Documentation/admin-guide/edid.rst
+++ b/Documentation/admin-guide/edid.rst
@@ -34,7 +34,7 @@ individual data for a specific misbehaving monitor, commented sources
and a Makefile environment are given here.
To create binary EDID and C source code files from the existing data
-material, simply type "make".
+material, simply type "make" in tools/edid/.
If you want to create your own EDID file, copy the file 1024x768.S,
replace the settings with your own data and add a new target to the
--
2.20.1
^ permalink raw reply related
* Re: [PATCH AUTOSEL 4.4 080/100] char: hpet: Use flexible-array member
From: Eric Biggers @ 2020-02-14 17:43 UTC (permalink / raw)
To: Sasha Levin; +Cc: linux-kernel, stable, Gustavo A. R. Silva, Greg Kroah-Hartman
In-Reply-To: <20200214162425.21071-80-sashal@kernel.org>
On Fri, Feb 14, 2020 at 11:24:04AM -0500, Sasha Levin wrote:
> From: "Gustavo A. R. Silva" <gustavo@embeddedor.com>
>
> [ Upstream commit 987f028b8637cfa7658aa456ae73f8f21a7a7f6f ]
>
> Old code in the kernel uses 1-byte and 0-byte arrays to indicate the
> presence of a "variable length array":
>
> struct something {
> int length;
> u8 data[1];
> };
>
> struct something *instance;
>
> instance = kmalloc(sizeof(*instance) + size, GFP_KERNEL);
> instance->length = size;
> memcpy(instance->data, source, size);
>
> There is also 0-byte arrays. Both cases pose confusion for things like
> sizeof(), CONFIG_FORTIFY_SOURCE, etc.[1] Instead, the preferred mechanism
> to declare variable-length types such as the one above is a flexible array
> member[2] which need to be the last member of a structure and empty-sized:
>
> struct something {
> int stuff;
> u8 data[];
> };
>
> Also, by making use of the mechanism above, we will get a compiler warning
> in case the flexible array does not occur last in the structure, which
> will help us prevent some kind of undefined behavior bugs from being
> unadvertenly introduced[3] to the codebase from now on.
>
> [1] https://github.com/KSPP/linux/issues/21
> [2] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
> [3] commit 76497732932f ("cxgb3/l2t: Fix undefined behaviour")
>
> Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
> Link: https://lore.kernel.org/r/20200120235326.GA29231@embeddedor.com
> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Signed-off-by: Sasha Levin <sashal@kernel.org>
> ---
> drivers/char/hpet.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/char/hpet.c b/drivers/char/hpet.c
> index 5b38d7a8202a1..38c2ae93ce492 100644
> --- a/drivers/char/hpet.c
> +++ b/drivers/char/hpet.c
> @@ -112,7 +112,7 @@ struct hpets {
> unsigned long hp_delta;
> unsigned int hp_ntimer;
> unsigned int hp_which;
> - struct hpet_dev hp_dev[1];
> + struct hpet_dev hp_dev[];
> };
>
Umm, why are you backporting this without the commit that fixes it? Does your
AUTOSEL process really still not pay attention to Fixes tags? They are there
for a reason.
And for that matter, why are you backporting it all, given that this is a
cleanup and not a fix?
- Eric
^ permalink raw reply
* [PATCH AUTOSEL 5.4 063/459] dt-bindings: iio: adc: ad7606: Fix wrong maxItems value
From: Sasha Levin @ 2020-02-14 15:55 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Beniamin Bia, Rob Herring, Sasha Levin, linux-fbdev, linux-iio,
devicetree
In-Reply-To: <20200214160149.11681-1-sashal@kernel.org>
From: Beniamin Bia <beniamin.bia@analog.com>
[ Upstream commit a6c4f77cb3b11f81077b53c4a38f21b92d41f21e ]
This patch set the correct value for oversampling maxItems. In the
original example, appears 3 items for oversampling while the maxItems
is set to 1, this patch fixes those issues.
Fixes: 416f882c3b40 ("dt-bindings: iio: adc: Migrate AD7606 documentation to yaml")
Signed-off-by: Beniamin Bia <beniamin.bia@analog.com>
Signed-off-by: Rob Herring <robh@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
Documentation/devicetree/bindings/iio/adc/adi,ad7606.yaml | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/Documentation/devicetree/bindings/iio/adc/adi,ad7606.yaml b/Documentation/devicetree/bindings/iio/adc/adi,ad7606.yaml
index cc544fdc38bea..bc8aed17800d3 100644
--- a/Documentation/devicetree/bindings/iio/adc/adi,ad7606.yaml
+++ b/Documentation/devicetree/bindings/iio/adc/adi,ad7606.yaml
@@ -85,7 +85,7 @@ properties:
Must be the device tree identifier of the over-sampling
mode pins. As the line is active high, it should be marked
GPIO_ACTIVE_HIGH.
- maxItems: 1
+ maxItems: 3
adi,sw-mode:
description:
@@ -128,9 +128,9 @@ examples:
adi,conversion-start-gpios = <&gpio 17 GPIO_ACTIVE_HIGH>;
reset-gpios = <&gpio 27 GPIO_ACTIVE_HIGH>;
adi,first-data-gpios = <&gpio 22 GPIO_ACTIVE_HIGH>;
- adi,oversampling-ratio-gpios = <&gpio 18 GPIO_ACTIVE_HIGH
- &gpio 23 GPIO_ACTIVE_HIGH
- &gpio 26 GPIO_ACTIVE_HIGH>;
+ adi,oversampling-ratio-gpios = <&gpio 18 GPIO_ACTIVE_HIGH>,
+ <&gpio 23 GPIO_ACTIVE_HIGH>,
+ <&gpio 26 GPIO_ACTIVE_HIGH>;
standby-gpios = <&gpio 24 GPIO_ACTIVE_LOW>;
adi,sw-mode;
};
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 5.4 064/459] arm64: cpufeature: Fix the type of no FP/SIMD capability
From: Sasha Levin @ 2020-02-14 15:55 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Suzuki K Poulose, Will Deacon, Mark Rutland, Ard Biesheuvel,
Catalin Marinas, Sasha Levin, linux-arm-kernel
In-Reply-To: <20200214160149.11681-1-sashal@kernel.org>
From: Suzuki K Poulose <suzuki.poulose@arm.com>
[ Upstream commit 449443c03d8cfdacf7313e17779a2594ebf87e6d ]
The NO_FPSIMD capability is defined with scope SYSTEM, which implies
that the "absence" of FP/SIMD on at least one CPU is detected only
after all the SMP CPUs are brought up. However, we use the status
of this capability for every context switch. So, let us change
the scope to LOCAL_CPU to allow the detection of this capability
as and when the first CPU without FP is brought up.
Also, the current type allows hotplugged CPU to be brought up without
FP/SIMD when all the current CPUs have FP/SIMD and we have the userspace
up. Fix both of these issues by changing the capability to
BOOT_RESTRICTED_LOCAL_CPU_FEATURE.
Fixes: 82e0191a1aa11abf ("arm64: Support systems without FP/ASIMD")
Cc: Will Deacon <will@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Signed-off-by: Will Deacon <will@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
arch/arm64/kernel/cpufeature.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
index 80f459ad0190d..a35c0b3af321b 100644
--- a/arch/arm64/kernel/cpufeature.c
+++ b/arch/arm64/kernel/cpufeature.c
@@ -1367,7 +1367,7 @@ static const struct arm64_cpu_capabilities arm64_features[] = {
{
/* FP/SIMD is not implemented */
.capability = ARM64_HAS_NO_FPSIMD,
- .type = ARM64_CPUCAP_SYSTEM_FEATURE,
+ .type = ARM64_CPUCAP_BOOT_RESTRICTED_CPU_LOCAL_FEATURE,
.min_field_value = 0,
.matches = has_no_fpsimd,
},
--
2.20.1
^ permalink raw reply related
* [PATCH 2/4] docs: admin-guide: Move edid.rst from driver-api
From: Jonathan Neuschäfer @ 2020-02-14 17:41 UTC (permalink / raw)
To: linux-doc
Cc: Jonathan Corbet, Jonathan Neuschäfer, Mauro Carvalho Chehab,
Cornelia Huck, Logan Gunthorpe, Andy Shevchenko,
Matthew Wilcox (Oracle), Shobhit Kukreti, Thomas Gleixner,
Greg Kroah-Hartman, Jason Gunthorpe, Harald Seiler, linux-kernel,
Darrick J. Wong
In-Reply-To: <20200214174139.16101-1-j.neuschaefer@gmx.net>
This document describes actions that an admin can do, rather than
interfaces available to driver developers, so admin-guide seems to
be a more appropriate place for it.
Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
---
Documentation/{driver-api => admin-guide}/edid.rst | 0
Documentation/admin-guide/index.rst | 1 +
Documentation/driver-api/index.rst | 1 -
3 files changed, 1 insertion(+), 1 deletion(-)
rename Documentation/{driver-api => admin-guide}/edid.rst (100%)
diff --git a/Documentation/driver-api/edid.rst b/Documentation/admin-guide/edid.rst
similarity index 100%
rename from Documentation/driver-api/edid.rst
rename to Documentation/admin-guide/edid.rst
diff --git a/Documentation/admin-guide/index.rst b/Documentation/admin-guide/index.rst
index f1d0ccffbe72..5a6269fb8593 100644
--- a/Documentation/admin-guide/index.rst
+++ b/Documentation/admin-guide/index.rst
@@ -75,6 +75,7 @@ configure specific aspects of kernel behavior to your liking.
cputopology
dell_rbu
device-mapper/index
+ edid
efi-stub
ext4
nfs/index
diff --git a/Documentation/driver-api/index.rst b/Documentation/driver-api/index.rst
index 0ebe205efd0c..ea3003b3c5e5 100644
--- a/Documentation/driver-api/index.rst
+++ b/Documentation/driver-api/index.rst
@@ -74,7 +74,6 @@ available subsections can be seen below.
connector
console
dcdbas
- edid
eisa
ipmb
isa
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 5.4 066/459] usb: gadget: udc: fix possible sleep-in-atomic-context bugs in gr_probe()
From: Sasha Levin @ 2020-02-14 15:55 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Jia-Ju Bai, Felipe Balbi, Greg Kroah-Hartman, Sasha Levin,
linux-usb
In-Reply-To: <20200214160149.11681-1-sashal@kernel.org>
From: Jia-Ju Bai <baijiaju1990@gmail.com>
[ Upstream commit 9c1ed62ae0690dfe5d5e31d8f70e70a95cb48e52 ]
The driver may sleep while holding a spinlock.
The function call path (from bottom to top) in Linux 4.19 is:
drivers/usb/gadget/udc/core.c, 1175:
kzalloc(GFP_KERNEL) in usb_add_gadget_udc_release
drivers/usb/gadget/udc/core.c, 1272:
usb_add_gadget_udc_release in usb_add_gadget_udc
drivers/usb/gadget/udc/gr_udc.c, 2186:
usb_add_gadget_udc in gr_probe
drivers/usb/gadget/udc/gr_udc.c, 2183:
spin_lock in gr_probe
drivers/usb/gadget/udc/core.c, 1195:
mutex_lock in usb_add_gadget_udc_release
drivers/usb/gadget/udc/core.c, 1272:
usb_add_gadget_udc_release in usb_add_gadget_udc
drivers/usb/gadget/udc/gr_udc.c, 2186:
usb_add_gadget_udc in gr_probe
drivers/usb/gadget/udc/gr_udc.c, 2183:
spin_lock in gr_probe
drivers/usb/gadget/udc/gr_udc.c, 212:
debugfs_create_file in gr_probe
drivers/usb/gadget/udc/gr_udc.c, 2197:
gr_dfs_create in gr_probe
drivers/usb/gadget/udc/gr_udc.c, 2183:
spin_lock in gr_probe
drivers/usb/gadget/udc/gr_udc.c, 2114:
devm_request_threaded_irq in gr_request_irq
drivers/usb/gadget/udc/gr_udc.c, 2202:
gr_request_irq in gr_probe
drivers/usb/gadget/udc/gr_udc.c, 2183:
spin_lock in gr_probe
kzalloc(GFP_KERNEL), mutex_lock(), debugfs_create_file() and
devm_request_threaded_irq() can sleep at runtime.
To fix these possible bugs, usb_add_gadget_udc(), gr_dfs_create() and
gr_request_irq() are called without handling the spinlock.
These bugs are found by a static analysis tool STCheck written by myself.
Signed-off-by: Jia-Ju Bai <baijiaju1990@gmail.com>
Signed-off-by: Felipe Balbi <balbi@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/usb/gadget/udc/gr_udc.c | 16 +++++++++-------
1 file changed, 9 insertions(+), 7 deletions(-)
diff --git a/drivers/usb/gadget/udc/gr_udc.c b/drivers/usb/gadget/udc/gr_udc.c
index 7a0e9a58c2d84..116d386472efe 100644
--- a/drivers/usb/gadget/udc/gr_udc.c
+++ b/drivers/usb/gadget/udc/gr_udc.c
@@ -2176,8 +2176,6 @@ static int gr_probe(struct platform_device *pdev)
return -ENOMEM;
}
- spin_lock(&dev->lock);
-
/* Inside lock so that no gadget can use this udc until probe is done */
retval = usb_add_gadget_udc(dev->dev, &dev->gadget);
if (retval) {
@@ -2186,15 +2184,21 @@ static int gr_probe(struct platform_device *pdev)
}
dev->added = 1;
+ spin_lock(&dev->lock);
+
retval = gr_udc_init(dev);
- if (retval)
+ if (retval) {
+ spin_unlock(&dev->lock);
goto out;
-
- gr_dfs_create(dev);
+ }
/* Clear all interrupt enables that might be left on since last boot */
gr_disable_interrupts_and_pullup(dev);
+ spin_unlock(&dev->lock);
+
+ gr_dfs_create(dev);
+
retval = gr_request_irq(dev, dev->irq);
if (retval) {
dev_err(dev->dev, "Failed to request irq %d\n", dev->irq);
@@ -2223,8 +2227,6 @@ static int gr_probe(struct platform_device *pdev)
dev_info(dev->dev, "regs: %p, irq %d\n", dev->regs, dev->irq);
out:
- spin_unlock(&dev->lock);
-
if (retval)
gr_remove(pdev);
--
2.20.1
^ permalink raw reply related
* Re: [Intel-gfx] [PATCH] drm/i915: Use engine wa list for Wa_1607090982
From: Matt Roper @ 2020-02-14 17:42 UTC (permalink / raw)
To: Mika Kuoppala; +Cc: intel-gfx
In-Reply-To: <20200212165707.11143-1-mika.kuoppala@linux.intel.com>
On Wed, Feb 12, 2020 at 06:57:07PM +0200, Mika Kuoppala wrote:
> This is in mcr range of register, thus we can only verify
> it through mmio. Use engine wa list with mcr range verification
> skip.
>
> Fixes: 0db1a5f8706a ("drm/i915: Implement Wa_1607090982")
> Cc: Chris Wilson <chris@chris-wilson.co.uk>
> Signed-off-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
The headline of this patch is out of sync with the actual workaround
number being used in the code below and in the bspec (same as the patch
that this Fixes). The bspec name for this is Wa_1606931601.
It wasn't originally obvious since the workaround numbers don't match,
but Anusha already has a patch in flight for this workaround here:
https://patchwork.freedesktop.org/series/72433/#rev5
The main difference is that it looks like your patch is adding the
workaround to the "A0 only" section of the engine workarounds function,
whereas Anusha's is adding it for all steppings, which I think is what
the bspec calls for. Do you have additional information that this
should be A0-specific, or was that just an oversight?
Matt
> ---
> drivers/gpu/drm/i915/gt/intel_workarounds.c | 8 +++++---
> 1 file changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> index 62b43f538a56..ba86511f1ef9 100644
> --- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> +++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> @@ -598,9 +598,6 @@ static void tgl_ctx_workarounds_init(struct intel_engine_cs *engine,
> wa_add(wal, FF_MODE2, FF_MODE2_TDS_TIMER_MASK, val,
> IS_TGL_REVID(engine->i915, TGL_REVID_A0, TGL_REVID_A0) ? 0 :
> FF_MODE2_TDS_TIMER_MASK);
> -
> - /* Wa_1606931601:tgl */
> - WA_SET_BIT_MASKED(GEN7_ROW_CHICKEN2, GEN12_DISABLE_EARLY_READ);
> }
>
> static void
> @@ -1360,6 +1357,11 @@ rcs_engine_wa_init(struct intel_engine_cs *engine, struct i915_wa_list *wal)
> wa_write_or(wal,
> GEN7_FF_THREAD_MODE,
> GEN12_FF_TESSELATION_DOP_GATE_DISABLE);
> +
> + /* Wa_1606931601:tgl */
> + wa_masked_en(wal,
> + GEN7_ROW_CHICKEN2,
> + GEN12_DISABLE_EARLY_READ);
> }
>
> if (IS_GEN(i915, 11)) {
> --
> 2.17.1
>
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Matt Roper
Graphics Software Engineer
VTT-OSGC Platform Enablement
Intel Corporation
(916) 356-2795
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* [PATCH AUTOSEL 5.4 068/459] nfs: NFS_SWAP should depend on SWAP
From: Sasha Levin @ 2020-02-14 15:55 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Geert Uytterhoeven, Anna Schumaker, Sasha Levin, linux-nfs
In-Reply-To: <20200214160149.11681-1-sashal@kernel.org>
From: Geert Uytterhoeven <geert+renesas@glider.be>
[ Upstream commit 474c4f306eefbb21b67ebd1de802d005c7d7ecdc ]
If CONFIG_SWAP=n, it does not make much sense to offer the user the
option to enable support for swapping over NFS, as that will still fail
at run time:
# swapon /swap
swapon: /swap: swapon failed: Function not implemented
Fix this by adding a dependency on CONFIG_SWAP.
Fixes: a564b8f0398636ba ("nfs: enable swap on NFS")
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
fs/nfs/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/nfs/Kconfig b/fs/nfs/Kconfig
index 295a7a21b7744..e7dd07f478259 100644
--- a/fs/nfs/Kconfig
+++ b/fs/nfs/Kconfig
@@ -90,7 +90,7 @@ config NFS_V4
config NFS_SWAP
bool "Provide swap over NFS support"
default n
- depends on NFS_FS
+ depends on NFS_FS && SWAP
select SUNRPC_SWAP
help
This option enables swapon to work on files located on NFS mounts.
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 5.4 067/459] usb: dwc2: Fix IN FIFO allocation
From: Sasha Levin @ 2020-02-14 15:55 UTC (permalink / raw)
To: linux-kernel, stable
Cc: John Keeping, Minas Harutyunyan, Felipe Balbi, Greg Kroah-Hartman,
Sasha Levin, linux-usb
In-Reply-To: <20200214160149.11681-1-sashal@kernel.org>
From: John Keeping <john@metanate.com>
[ Upstream commit 644139f8b64d818f6345351455f14471510879a5 ]
On chips with fewer FIFOs than endpoints (for example RK3288 which has 9
endpoints, but only 6 which are cabable of input), the DPTXFSIZN
registers above the FIFO count may return invalid values.
With logging added on startup, I see:
dwc2 ff580000.usb: dwc2_hsotg_init_fifo: ep=1 sz=256
dwc2 ff580000.usb: dwc2_hsotg_init_fifo: ep=2 sz=128
dwc2 ff580000.usb: dwc2_hsotg_init_fifo: ep=3 sz=128
dwc2 ff580000.usb: dwc2_hsotg_init_fifo: ep=4 sz=64
dwc2 ff580000.usb: dwc2_hsotg_init_fifo: ep=5 sz=64
dwc2 ff580000.usb: dwc2_hsotg_init_fifo: ep=6 sz=32
dwc2 ff580000.usb: dwc2_hsotg_init_fifo: ep=7 sz=0
dwc2 ff580000.usb: dwc2_hsotg_init_fifo: ep=8 sz=0
dwc2 ff580000.usb: dwc2_hsotg_init_fifo: ep=9 sz=0
dwc2 ff580000.usb: dwc2_hsotg_init_fifo: ep=10 sz=0
dwc2 ff580000.usb: dwc2_hsotg_init_fifo: ep=11 sz=0
dwc2 ff580000.usb: dwc2_hsotg_init_fifo: ep=12 sz=0
dwc2 ff580000.usb: dwc2_hsotg_init_fifo: ep=13 sz=0
dwc2 ff580000.usb: dwc2_hsotg_init_fifo: ep=14 sz=0
dwc2 ff580000.usb: dwc2_hsotg_init_fifo: ep=15 sz=0
but:
# cat /sys/kernel/debug/ff580000.usb/fifo
Non-periodic FIFOs:
RXFIFO: Size 275
NPTXFIFO: Size 16, Start 0x00000113
Periodic TXFIFOs:
DPTXFIFO 1: Size 256, Start 0x00000123
DPTXFIFO 2: Size 128, Start 0x00000223
DPTXFIFO 3: Size 128, Start 0x000002a3
DPTXFIFO 4: Size 64, Start 0x00000323
DPTXFIFO 5: Size 64, Start 0x00000363
DPTXFIFO 6: Size 32, Start 0x000003a3
DPTXFIFO 7: Size 0, Start 0x000003e3
DPTXFIFO 8: Size 0, Start 0x000003a3
DPTXFIFO 9: Size 256, Start 0x00000123
so it seems that FIFO 9 is mirroring FIFO 1.
Fix the allocation by using the FIFO count instead of the endpoint count
when selecting a FIFO for an endpoint.
Acked-by: Minas Harutyunyan <hminas@synopsys.com>
Signed-off-by: John Keeping <john@metanate.com>
Signed-off-by: Felipe Balbi <balbi@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/usb/dwc2/gadget.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c
index 6be10e496e105..a9133773b89e4 100644
--- a/drivers/usb/dwc2/gadget.c
+++ b/drivers/usb/dwc2/gadget.c
@@ -4056,11 +4056,12 @@ static int dwc2_hsotg_ep_enable(struct usb_ep *ep,
* a unique tx-fifo even if it is non-periodic.
*/
if (dir_in && hsotg->dedicated_fifos) {
+ unsigned fifo_count = dwc2_hsotg_tx_fifo_count(hsotg);
u32 fifo_index = 0;
u32 fifo_size = UINT_MAX;
size = hs_ep->ep.maxpacket * hs_ep->mc;
- for (i = 1; i < hsotg->num_of_eps; ++i) {
+ for (i = 1; i <= fifo_count; ++i) {
if (hsotg->fifo_map & (1 << i))
continue;
val = dwc2_readl(hsotg, DPTXFSIZN(i));
--
2.20.1
^ permalink raw reply related
* [PATCH 1/4] docs: driver-api: edid: Fix list formatting
From: Jonathan Neuschäfer @ 2020-02-14 17:41 UTC (permalink / raw)
To: linux-doc
Cc: Jonathan Corbet, Jonathan Neuschäfer, Mauro Carvalho Chehab,
Cornelia Huck, Logan Gunthorpe, Andy Shevchenko,
Matthew Wilcox (Oracle), Shobhit Kukreti, Thomas Gleixner,
Greg Kroah-Hartman, Jason Gunthorpe, Harald Seiler, linux-kernel
Without the empty lines, Sphinx renders the list as part of the running
text.
Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
---
Documentation/driver-api/edid.rst | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/driver-api/edid.rst b/Documentation/driver-api/edid.rst
index b1b5acd501ed..7dc07942ceb2 100644
--- a/Documentation/driver-api/edid.rst
+++ b/Documentation/driver-api/edid.rst
@@ -11,11 +11,13 @@ Today, with the advent of Kernel Mode Setting, a graphics board is
either correctly working because all components follow the standards -
or the computer is unusable, because the screen remains dark after
booting or it displays the wrong area. Cases when this happens are:
+
- The graphics board does not recognize the monitor.
- The graphics board is unable to detect any EDID data.
- The graphics board incorrectly forwards EDID data to the driver.
- The monitor sends no or bogus EDID data.
- A KVM sends its own EDID data instead of querying the connected monitor.
+
Adding the kernel parameter "nomodeset" helps in most cases, but causes
restrictions later on.
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 5.4 354/459] ide: remove set but not used variable 'hwif'
From: Sasha Levin @ 2020-02-14 16:00 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Sasha Levin, Wang Hai, linux-ide, Hulk Robot, linuxppc-dev,
David S . Miller
In-Reply-To: <20200214160149.11681-1-sashal@kernel.org>
From: Wang Hai <wanghai38@huawei.com>
[ Upstream commit 98949a1946d70771789def0c9dbc239497f9f138 ]
Fix the following gcc warning:
drivers/ide/pmac.c: In function pmac_ide_setup_device:
drivers/ide/pmac.c:1027:14: warning: variable hwif set but not used
[-Wunused-but-set-variable]
Fixes: d58b0c39e32f ("powerpc/macio: Rework hotplug media bay support")
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Wang Hai <wanghai38@huawei.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/ide/pmac.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/ide/pmac.c b/drivers/ide/pmac.c
index b5647e34e74ee..ea0b064b5f56b 100644
--- a/drivers/ide/pmac.c
+++ b/drivers/ide/pmac.c
@@ -1019,7 +1019,6 @@ static int pmac_ide_setup_device(pmac_ide_hwif_t *pmif, struct ide_hw *hw)
struct device_node *np = pmif->node;
const int *bidp;
struct ide_host *host;
- ide_hwif_t *hwif;
struct ide_hw *hws[] = { hw };
struct ide_port_info d = pmac_port_info;
int rc;
@@ -1075,7 +1074,7 @@ static int pmac_ide_setup_device(pmac_ide_hwif_t *pmif, struct ide_hw *hw)
rc = -ENOMEM;
goto bail;
}
- hwif = pmif->hwif = host->ports[0];
+ pmif->hwif = host->ports[0];
if (on_media_bay(pmif)) {
/* Fixup bus ID for media bay */
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 5.4 069/459] clocksource/drivers/bcm2835_timer: Fix memory leak of timer
From: Sasha Levin @ 2020-02-14 15:55 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Colin Ian King, Daniel Lezcano, Sasha Levin,
bcm-kernel-feedback-list, linux-rpi-kernel, linux-arm-kernel
In-Reply-To: <20200214160149.11681-1-sashal@kernel.org>
From: Colin Ian King <colin.king@canonical.com>
[ Upstream commit 2052d032c06761330bca4944bb7858b00960e868 ]
Currently when setup_irq fails the error exit path will leak the
recently allocated timer structure. Originally the code would
throw a panic but a later commit changed the behaviour to return
via the err_iounmap path and hence we now have a memory leak. Fix
this by adding a err_timer_free error path that kfree's timer.
Addresses-Coverity: ("Resource Leak")
Fixes: 524a7f08983d ("clocksource/drivers/bcm2835_timer: Convert init function to return error")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
Link: https://lore.kernel.org/r/20191219213246.34437-1-colin.king@canonical.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/clocksource/bcm2835_timer.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/clocksource/bcm2835_timer.c b/drivers/clocksource/bcm2835_timer.c
index 2b196cbfadb62..b235f446ee50f 100644
--- a/drivers/clocksource/bcm2835_timer.c
+++ b/drivers/clocksource/bcm2835_timer.c
@@ -121,7 +121,7 @@ static int __init bcm2835_timer_init(struct device_node *node)
ret = setup_irq(irq, &timer->act);
if (ret) {
pr_err("Can't set up timer IRQ\n");
- goto err_iounmap;
+ goto err_timer_free;
}
clockevents_config_and_register(&timer->evt, freq, 0xf, 0xffffffff);
@@ -130,6 +130,9 @@ static int __init bcm2835_timer_init(struct device_node *node)
return 0;
+err_timer_free:
+ kfree(timer);
+
err_iounmap:
iounmap(base);
return ret;
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 5.4 070/459] drm/amd/display: Clear state after exiting fixed active VRR state
From: Sasha Levin @ 2020-02-14 15:55 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Amanda Liu, Anthony Koo, Harry Wentland, Rodrigo Siqueira,
Alex Deucher, Sasha Levin, amd-gfx, dri-devel
In-Reply-To: <20200214160149.11681-1-sashal@kernel.org>
From: Amanda Liu <amanda.liu@amd.com>
[ Upstream commit 6f8f76444baf405bacb0591d97549a71a9aaa1ac ]
[why]
Upon exiting a fixed active VRR state, the state isn't cleared. This
leads to the variable VRR range to be calculated incorrectly.
[how]
Set fixed active state to false when updating vrr params
Signed-off-by: Amanda Liu <amanda.liu@amd.com>
Reviewed-by: Anthony Koo <Anthony.Koo@amd.com>
Acked-by: Harry Wentland <harry.wentland@amd.com>
Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/gpu/drm/amd/display/modules/freesync/freesync.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/amd/display/modules/freesync/freesync.c b/drivers/gpu/drm/amd/display/modules/freesync/freesync.c
index 0978c698f0f85..7d67cb2c61f04 100644
--- a/drivers/gpu/drm/amd/display/modules/freesync/freesync.c
+++ b/drivers/gpu/drm/amd/display/modules/freesync/freesync.c
@@ -803,6 +803,7 @@ void mod_freesync_build_vrr_params(struct mod_freesync *mod_freesync,
2 * in_out_vrr->min_refresh_in_uhz)
in_out_vrr->btr.btr_enabled = false;
+ in_out_vrr->fixed.fixed_active = false;
in_out_vrr->btr.btr_active = false;
in_out_vrr->btr.inserted_duration_in_us = 0;
in_out_vrr->btr.frames_to_insert = 0;
@@ -822,6 +823,7 @@ void mod_freesync_build_vrr_params(struct mod_freesync *mod_freesync,
in_out_vrr->adjust.v_total_max = stream->timing.v_total;
} else if (in_out_vrr->state == VRR_STATE_ACTIVE_VARIABLE &&
refresh_range >= MIN_REFRESH_RANGE_IN_US) {
+
in_out_vrr->adjust.v_total_min =
calc_v_total_from_refresh(stream,
in_out_vrr->max_refresh_in_uhz);
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 5.4 072/459] sched/uclamp: Fix a bug in propagating uclamp value in new cgroups
From: Sasha Levin @ 2020-02-14 15:55 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Qais Yousef, Doug Smythies, Peter Zijlstra, Sasha Levin
In-Reply-To: <20200214160149.11681-1-sashal@kernel.org>
From: Qais Yousef <qais.yousef@arm.com>
[ Upstream commit 7226017ad37a888915628e59a84a2d1e57b40707 ]
When a new cgroup is created, the effective uclamp value wasn't updated
with a call to cpu_util_update_eff() that looks at the hierarchy and
update to the most restrictive values.
Fix it by ensuring to call cpu_util_update_eff() when a new cgroup
becomes online.
Without this change, the newly created cgroup uses the default
root_task_group uclamp values, which is 1024 for both uclamp_{min, max},
which will cause the rq to to be clamped to max, hence cause the
system to run at max frequency.
The problem was observed on Ubuntu server and was reproduced on Debian
and Buildroot rootfs.
By default, Ubuntu and Debian create a cpu controller cgroup hierarchy
and add all tasks to it - which creates enough noise to keep the rq
uclamp value at max most of the time. Imitating this behavior makes the
problem visible in Buildroot too which otherwise looks fine since it's a
minimal userspace.
Fixes: 0b60ba2dd342 ("sched/uclamp: Propagate parent clamps")
Reported-by: Doug Smythies <dsmythies@telus.net>
Signed-off-by: Qais Yousef <qais.yousef@arm.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Tested-by: Doug Smythies <dsmythies@telus.net>
Link: https://lore.kernel.org/lkml/000701d5b965$361b6c60$a2524520$@net/
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
kernel/sched/core.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 8dacda4b03627..00743684a549a 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -7090,6 +7090,12 @@ static int cpu_cgroup_css_online(struct cgroup_subsys_state *css)
if (parent)
sched_online_group(tg, parent);
+
+#ifdef CONFIG_UCLAMP_TASK_GROUP
+ /* Propagate the effective uclamp value for the new group */
+ cpu_util_update_eff(css);
+#endif
+
return 0;
}
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 5.4 071/459] kselftest: Minimise dependency of get_size on C library interfaces
From: Sasha Levin @ 2020-02-14 15:55 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Siddhesh Poyarekar, Masami Hiramatsu, Tim Bird, Shuah Khan,
Sasha Levin, linux-kselftest
In-Reply-To: <20200214160149.11681-1-sashal@kernel.org>
From: Siddhesh Poyarekar <siddhesh@gotplt.org>
[ Upstream commit 6b64a650f0b2ae3940698f401732988699eecf7a ]
It was observed[1] on arm64 that __builtin_strlen led to an infinite
loop in the get_size selftest. This is because __builtin_strlen (and
other builtins) may sometimes result in a call to the C library
function. The C library implementation of strlen uses an IFUNC
resolver to load the most efficient strlen implementation for the
underlying machine and hence has a PLT indirection even for static
binaries. Because this binary avoids the C library startup routines,
the PLT initialization never happens and hence the program gets stuck
in an infinite loop.
On x86_64 the __builtin_strlen just happens to expand inline and avoid
the call but that is not always guaranteed.
Further, while testing on x86_64 (Fedora 31), it was observed that the
test also failed with a segfault inside write() because the generated
code for the write function in glibc seems to access TLS before the
syscall (probably due to the cancellation point check) and fails
because TLS is not initialised.
To mitigate these problems, this patch reduces the interface with the
C library to just the syscall function. The syscall function still
sets errno on failure, which is undesirable but for now it only
affects cases where syscalls fail.
[1] https://bugs.linaro.org/show_bug.cgi?id=5479
Signed-off-by: Siddhesh Poyarekar <siddhesh@gotplt.org>
Reported-by: Masami Hiramatsu <masami.hiramatsu@linaro.org>
Tested-by: Masami Hiramatsu <masami.hiramatsu@linaro.org>
Reviewed-by: Tim Bird <tim.bird@sony.com>
Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
tools/testing/selftests/size/get_size.c | 24 ++++++++++++++++++------
1 file changed, 18 insertions(+), 6 deletions(-)
diff --git a/tools/testing/selftests/size/get_size.c b/tools/testing/selftests/size/get_size.c
index 2ad45b9443550..2980b1a63366b 100644
--- a/tools/testing/selftests/size/get_size.c
+++ b/tools/testing/selftests/size/get_size.c
@@ -11,23 +11,35 @@
* own execution. It also attempts to have as few dependencies
* on kernel features as possible.
*
- * It should be statically linked, with startup libs avoided.
- * It uses no library calls, and only the following 3 syscalls:
+ * It should be statically linked, with startup libs avoided. It uses
+ * no library calls except the syscall() function for the following 3
+ * syscalls:
* sysinfo(), write(), and _exit()
*
* For output, it avoids printf (which in some C libraries
* has large external dependencies) by implementing it's own
* number output and print routines, and using __builtin_strlen()
+ *
+ * The test may crash if any of the above syscalls fails because in some
+ * libc implementations (e.g. the GNU C Library) errno is saved in
+ * thread-local storage, which does not get initialized due to avoiding
+ * startup libs.
*/
#include <sys/sysinfo.h>
#include <unistd.h>
+#include <sys/syscall.h>
#define STDOUT_FILENO 1
static int print(const char *s)
{
- return write(STDOUT_FILENO, s, __builtin_strlen(s));
+ size_t len = 0;
+
+ while (s[len] != '\0')
+ len++;
+
+ return syscall(SYS_write, STDOUT_FILENO, s, len);
}
static inline char *num_to_str(unsigned long num, char *buf, int len)
@@ -79,12 +91,12 @@ void _start(void)
print("TAP version 13\n");
print("# Testing system size.\n");
- ccode = sysinfo(&info);
+ ccode = syscall(SYS_sysinfo, &info);
if (ccode < 0) {
print("not ok 1");
print(test_name);
print(" ---\n reason: \"could not get sysinfo\"\n ...\n");
- _exit(ccode);
+ syscall(SYS_exit, ccode);
}
print("ok 1");
print(test_name);
@@ -100,5 +112,5 @@ void _start(void)
print(" ...\n");
print("1..1\n");
- _exit(0);
+ syscall(SYS_exit, 0);
}
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 5.4 073/459] jbd2: clear JBD2_ABORT flag before journal_reset to update log tail info when load journal
From: Sasha Levin @ 2020-02-14 15:55 UTC (permalink / raw)
To: linux-kernel, stable; +Cc: Kai Li, Theodore Ts'o, Sasha Levin, linux-ext4
In-Reply-To: <20200214160149.11681-1-sashal@kernel.org>
From: Kai Li <li.kai4@h3c.com>
[ Upstream commit a09decff5c32060639a685581c380f51b14e1fc2 ]
If the journal is dirty when the filesystem is mounted, jbd2 will replay
the journal but the journal superblock will not be updated by
journal_reset() because JBD2_ABORT flag is still set (it was set in
journal_init_common()). This is problematic because when a new transaction
is then committed, it will be recorded in block 1 (journal->j_tail was set
to 1 in journal_reset()). If unclean shutdown happens again before the
journal superblock is updated, the new recorded transaction will not be
replayed during the next mount (because of stale sb->s_start and
sb->s_sequence values) which can lead to filesystem corruption.
Fixes: 85e0c4e89c1b ("jbd2: if the journal is aborted then don't allow update of the log tail")
Signed-off-by: Kai Li <li.kai4@h3c.com>
Link: https://lore.kernel.org/r/20200111022542.5008-1-li.kai4@h3c.com
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
fs/jbd2/journal.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/fs/jbd2/journal.c b/fs/jbd2/journal.c
index ef485f892d1b0..389c9be4e7919 100644
--- a/fs/jbd2/journal.c
+++ b/fs/jbd2/journal.c
@@ -1682,6 +1682,11 @@ int jbd2_journal_load(journal_t *journal)
journal->j_devname);
return -EFSCORRUPTED;
}
+ /*
+ * clear JBD2_ABORT flag initialized in journal_init_common
+ * here to update log tail information with the newest seq.
+ */
+ journal->j_flags &= ~JBD2_ABORT;
/* OK, we've finished with the dynamic journal bits:
* reinitialise the dynamic contents of the superblock in memory
@@ -1689,7 +1694,6 @@ int jbd2_journal_load(journal_t *journal)
if (journal_reset(journal))
goto recovery_error;
- journal->j_flags &= ~JBD2_ABORT;
journal->j_flags |= JBD2_LOADED;
return 0;
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 5.4 075/459] clk: ti: dra7: fix parent for gmac_clkctrl
From: Sasha Levin @ 2020-02-14 15:55 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Grygorii Strashko, Tero Kristo, Sasha Levin, linux-omap,
linux-clk
In-Reply-To: <20200214160149.11681-1-sashal@kernel.org>
From: Grygorii Strashko <grygorii.strashko@ti.com>
[ Upstream commit 69e300283796dae7e8c2e6acdabcd31336c0c93e ]
The parent clk for gmac clk ctrl has to be gmac_main_clk (125MHz) instead
of dpll_gmac_ck (1GHz). This is caused incorrect CPSW MDIO operation.
Hence, fix it.
Fixes: dffa9051d546 ('clk: ti: dra7: add new clkctrl data')
Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/clk/ti/clk-7xx.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/clk/ti/clk-7xx.c b/drivers/clk/ti/clk-7xx.c
index 9dd6185a4b4e2..66e4b2b9ec600 100644
--- a/drivers/clk/ti/clk-7xx.c
+++ b/drivers/clk/ti/clk-7xx.c
@@ -405,7 +405,7 @@ static const struct omap_clkctrl_bit_data dra7_gmac_bit_data[] __initconst = {
};
static const struct omap_clkctrl_reg_data dra7_gmac_clkctrl_regs[] __initconst = {
- { DRA7_GMAC_GMAC_CLKCTRL, dra7_gmac_bit_data, CLKF_SW_SUP, "dpll_gmac_ck" },
+ { DRA7_GMAC_GMAC_CLKCTRL, dra7_gmac_bit_data, CLKF_SW_SUP, "gmac_main_clk" },
{ 0 },
};
--
2.20.1
^ permalink raw reply related
* Re: [libnftnl PATCH] src: Fix nftnl_assert() on data_len
From: Pablo Neira Ayuso @ 2020-02-14 17:42 UTC (permalink / raw)
To: Phil Sutter, netfilter-devel
In-Reply-To: <20200214173450.GR20005@orbyte.nwl.cc>
On Fri, Feb 14, 2020 at 06:34:50PM +0100, Phil Sutter wrote:
> On Fri, Feb 14, 2020 at 06:32:47PM +0100, Pablo Neira Ayuso wrote:
> > On Fri, Feb 14, 2020 at 06:24:17PM +0100, Phil Sutter wrote:
> > > Typical idiom for *_get_u*() getters is to call *_get_data() and make
> > > sure data_len matches what each of them is returning. Yet they shouldn't
> > > trust *_get_data() to write into passed pointer to data_len since for
> > > chains and NFTNL_CHAIN_DEVICES attribute, it does not. Make sure these
> > > assert() calls trigger in those cases.
> >
> > The intention to catch for unset attributes through the assertion,
> > right?
>
> No, this is about making sure that no wrong getter is called, e.g.
> nftnl_chain_get_u64() with e.g. NFTNL_CHAIN_HOOKNUM attribute which is
> only 32bits.
I think it will also catch the case I'm asking. If attribute is unset,
then nftnl_chain_get_data() returns NULL and the assertion checks
data_len, which has not been properly initialized.
^ permalink raw reply
* [PATCH AUTOSEL 5.4 078/459] udf: Allow writing to 'Rewritable' partitions
From: Sasha Levin @ 2020-02-14 15:55 UTC (permalink / raw)
To: linux-kernel, stable; +Cc: Jan Kara, Pali Rohár, Sasha Levin
In-Reply-To: <20200214160149.11681-1-sashal@kernel.org>
From: Jan Kara <jack@suse.cz>
[ Upstream commit 15fb05fd286ac57a0802d71624daeb5c1c2d5b07 ]
UDF 2.60 standard states in section 2.2.14.2:
A partition with Access Type 3 (rewritable) shall define a Freed
Space Bitmap or a Freed Space Table, see 2.3.3. All other partitions
shall not define a Freed Space Bitmap or a Freed Space Table.
Rewritable partitions are used on media that require some form of
preprocessing before re-writing data (for example legacy MO). Such
partitions shall use Access Type 3.
Overwritable partitions are used on media that do not require
preprocessing before overwriting data (for example: CD-RW, DVD-RW,
DVD+RW, DVD-RAM, BD-RE, HD DVD-Rewritable). Such partitions shall
use Access Type 4.
however older versions of the standard didn't have this wording and
there are tools out there that create UDF filesystems with rewritable
partitions but that don't contain a Freed Space Bitmap or a Freed Space
Table on media that does not require pre-processing before overwriting a
block. So instead of forcing media with rewritable partition read-only,
base this decision on presence of a Freed Space Bitmap or a Freed Space
Table.
Reported-by: Pali Rohár <pali.rohar@gmail.com>
Reviewed-by: Pali Rohár <pali.rohar@gmail.com>
Fixes: b085fbe2ef7f ("udf: Fix crash during mount")
Link: https://lore.kernel.org/linux-fsdevel/20200112144735.hj2emsoy4uwsouxz@pali
Signed-off-by: Jan Kara <jack@suse.cz>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
fs/udf/super.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/fs/udf/super.c b/fs/udf/super.c
index 8c28e93e9b730..008bf96b1732d 100644
--- a/fs/udf/super.c
+++ b/fs/udf/super.c
@@ -1035,7 +1035,6 @@ static int check_partition_desc(struct super_block *sb,
switch (le32_to_cpu(p->accessType)) {
case PD_ACCESS_TYPE_READ_ONLY:
case PD_ACCESS_TYPE_WRITE_ONCE:
- case PD_ACCESS_TYPE_REWRITABLE:
case PD_ACCESS_TYPE_NONE:
goto force_ro;
}
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 5.4 079/459] scsi: ufs: Fix ufshcd_probe_hba() reture value in case ufshcd_scsi_add_wlus() fails
From: Sasha Levin @ 2020-02-14 15:55 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Bean Huo, Asutosh Das, Alim Akhtar, Stanley Chu,
Martin K . Petersen, Sasha Levin, linux-scsi, linux-arm-kernel,
linux-mediatek
In-Reply-To: <20200214160149.11681-1-sashal@kernel.org>
From: Bean Huo <beanhuo@micron.com>
[ Upstream commit b9fc5320212efdfb4e08b825aaa007815fd11d16 ]
A non-zero error value likely being returned by ufshcd_scsi_add_wlus() in
case of failure of adding the WLs, but ufshcd_probe_hba() doesn't use this
value, and doesn't report this failure to upper caller. This patch is to
fix this issue.
Fixes: 2a8fa600445c ("ufs: manually add well known logical units")
Link: https://lore.kernel.org/r/20200120130820.1737-2-huobean@gmail.com
Reviewed-by: Asutosh Das <asutoshd@codeaurora.org>
Reviewed-by: Alim Akhtar <alim.akhtar@samsung.com>
Reviewed-by: Stanley Chu <stanley.chu@mediatek.com>
Signed-off-by: Bean Huo <beanhuo@micron.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/scsi/ufs/ufshcd.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index 0d41a7dc1d6b2..b0d6978d78bf8 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -6953,7 +6953,8 @@ static int ufshcd_probe_hba(struct ufs_hba *hba)
ufshcd_init_icc_levels(hba);
/* Add required well known logical units to scsi mid layer */
- if (ufshcd_scsi_add_wlus(hba))
+ ret = ufshcd_scsi_add_wlus(hba);
+ if (ret)
goto out;
/* Initialize devfreq after UFS device is detected */
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 5.4 065/459] drm/nouveau/nouveau: fix incorrect sizeof on args.src an args.dst
From: Sasha Levin @ 2020-02-14 15:55 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Colin Ian King, Ben Skeggs, Sasha Levin, dri-devel, nouveau
In-Reply-To: <20200214160149.11681-1-sashal@kernel.org>
From: Colin Ian King <colin.king@canonical.com>
[ Upstream commit f42e4b337b327b1336c978c4b5174990a25f68a0 ]
The sizeof is currently on args.src and args.dst and should be on
*args.src and *args.dst. Fortunately these sizes just so happen
to be the same size so it worked, however, this should be fixed
and it also cleans up static analysis warnings
Addresses-Coverity: ("sizeof not portable")
Fixes: f268307ec7c7 ("nouveau: simplify nouveau_dmem_migrate_vma")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/gpu/drm/nouveau/nouveau_dmem.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_dmem.c b/drivers/gpu/drm/nouveau/nouveau_dmem.c
index fa14399415965..0ad5d87b5a8e5 100644
--- a/drivers/gpu/drm/nouveau/nouveau_dmem.c
+++ b/drivers/gpu/drm/nouveau/nouveau_dmem.c
@@ -635,10 +635,10 @@ nouveau_dmem_migrate_vma(struct nouveau_drm *drm,
unsigned long c, i;
int ret = -ENOMEM;
- args.src = kcalloc(max, sizeof(args.src), GFP_KERNEL);
+ args.src = kcalloc(max, sizeof(*args.src), GFP_KERNEL);
if (!args.src)
goto out;
- args.dst = kcalloc(max, sizeof(args.dst), GFP_KERNEL);
+ args.dst = kcalloc(max, sizeof(*args.dst), GFP_KERNEL);
if (!args.dst)
goto out_free_src;
--
2.20.1
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.