Re: [PATCH v1 05/10] powerpc/mm: Do early ioremaps from top to bottom on PPC64 too.
On Tue, Aug 13, 2019 at 08:11:38PM +, Christophe Leroy wrote: > Until vmalloc system is up and running, ioremap basically > allocates addresses at the border of the IOREMAP area. Note that while a few other architectures have a magic hack like powerpc to make ioremap work before vmalloc, the normal practice would be to explicitly use early_ioremap. I guess your change is fine for now, but it might make sense convert powerpc to the explicit early_ioremap scheme as well.
RE: [PATCH v2 0/2] Simplify mtty driver and mdev core
> -Original Message- > From: Alex Williamson > Sent: Tuesday, August 13, 2019 10:42 PM > To: Parav Pandit > Cc: Kirti Wankhede ; k...@vger.kernel.org; linux- > ker...@vger.kernel.org; coh...@redhat.com; c...@nvidia.com > Subject: Re: [PATCH v2 0/2] Simplify mtty driver and mdev core > > On Tue, 13 Aug 2019 16:28:53 + > Parav Pandit wrote: > > > > -Original Message- > > > From: Alex Williamson > > > Sent: Tuesday, August 13, 2019 8:23 PM > > > To: Parav Pandit > > > Cc: Kirti Wankhede ; k...@vger.kernel.org; > > > linux- ker...@vger.kernel.org; coh...@redhat.com; c...@nvidia.com > > > Subject: Re: [PATCH v2 0/2] Simplify mtty driver and mdev core > > > > > > On Tue, 13 Aug 2019 14:40:02 + > > > Parav Pandit wrote: > > > > > > > > -Original Message- > > > > > From: Kirti Wankhede > > > > > Sent: Monday, August 12, 2019 5:06 PM > > > > > To: Alex Williamson ; Parav Pandit > > > > > > > > > > Cc: k...@vger.kernel.org; linux-kernel@vger.kernel.org; > > > > > coh...@redhat.com; c...@nvidia.com > > > > > Subject: Re: [PATCH v2 0/2] Simplify mtty driver and mdev core > > > > > > > > > > > > > > > > > > > > On 8/9/2019 4:32 AM, Alex Williamson wrote: > > > > > > On Thu, 8 Aug 2019 09:12:53 -0500 Parav Pandit > > > > > > wrote: > > > > > > > > > > > >> Currently mtty sample driver uses mdev state and UUID in > > > > > >> convoluated way to generate an interrupt. > > > > > >> It uses several translations from mdev_state to mdev_device > > > > > >> to mdev > > > uuid. > > > > > >> After which it does linear search of long uuid comparision to > > > > > >> find out mdev_state in mtty_trigger_interrupt(). > > > > > >> mdev_state is already available while generating interrupt > > > > > >> from which all such translations are done to reach back to > mdev_state. > > > > > >> > > > > > >> This translations are done during interrupt generation path. > > > > > >> This is unnecessary and reduandant. > > > > > > > > > > > > Is the interrupt handling efficiency of this particular sample > > > > > > driver really relevant, or is its purpose more to illustrate > > > > > > the API and provide a proof of concept? If we go to the > > > > > > trouble to optimize the sample driver and remove this > > > > > > interface from the API, what > > > do we lose? > > > > > > > > > > > > This interface was added via commit: > > > > > > > > > > > > 99e3123e3d72 vfio-mdev: Make mdev_device private and abstract > > > > > > interfaces > > > > > > > > > > > > Where the goal was to create a more formal interface and > > > > > > abstract driver access to the struct mdev_device. In part > > > > > > this served to make out-of-tree mdev vendor drivers more > > > > > > supportable; the object is considered opaque and access is > > > > > > provided via an API rather than through direct structure fields. > > > > > > > > > > > > I believe that the NVIDIA GRID mdev driver does make use of > > > > > > this interface and it's likely included in the sample driver > > > > > > specifically so that there is an in-kernel user for it (ie. > > > > > > specifically to avoid it being removed so casually). An > > > > > > interesting feature of the NVIDIA mdev driver is that I > > > > > > believe it has > > > portions that run in userspace. > > > > > > As we know, mdevs are named with a UUID, so I can imagine > > > > > > there are some efficiencies to be gained in having direct > > > > > > access to the UUID for a device when interacting with > > > > > > userspace, rather than repeatedly parsing it from a device name. > > > > > > > > > > That's right. > > > > > > > > > > > Is that really something we want to make more difficult in > > > > > > order to optimize a sample driver? Knowing that an mdev > > > > > > device uses a UUID for it's name, as tools like libvirt and > > > > > > mdevctl expect, is it really worthwhile to remove such a trivial > > > > > > API? > > > > > > > > > > > >> Hence, > > > > > >> Patch-1 simplifies mtty sample driver to directly use mdev_state. > > > > > >> > > > > > >> Patch-2, Since no production driver uses mdev_uuid(), > > > > > >> simplifies and removes redandant mdev_uuid() exported symbol. > > > > > > > > > > > > s/no production driver/no in-kernel production driver/ > > > > > > > > > > > > I'd be interested to hear how the NVIDIA folks make use of > > > > > > this API interface. Thanks, > > > > > > > > > > > > > > > > Yes, NVIDIA mdev driver do use this interface. I don't agree on > > > > > removing > > > > > mdev_uuid() interface. > > > > > > > > > We need to ask Greg or Linus on the kernel policy on whether an > > > > API should exist without in-kernel driver. We don't add such API > > > > in netdev, rdma and possibly other subsystem. Where can we find > > > > this mdev driver in-tree? > > > > > > We probably would not have added the API only for an out of tree > > > driver, but we do have a sample driver that uses it, even if it's > > > rather convoluted. The sample driver is
Re: [PATCH v1 10/10] powerpc/mm: refactor ioremap_range() and use ioremap_page_range()
Somehow this series is missing a cover letter. While you are touching all this "fun" can you also look into killing __ioremap? It seems to be a weird non-standard version of ioremap_prot (probably predating ioremap_prot) that is missing a few lines of code setting attributes that might not even be applicable for the two drivers calling it.
Re: [alsa-devel] [PATCH] soundwire: Don't build sound.o without CONFIG_ACPI
On 13-08-19, 21:24, Nathan Chancellor wrote: > On Wed, Aug 14, 2019 at 09:29:47AM +0530, Vinod Koul wrote: > > On 13-08-19, 09:22, Pierre-Louis Bossart wrote: > > > On 8/13/19 1:10 AM, Nathan Chancellor wrote: > > > I am fine with the change, but we might as well rename the file > > > acpi_slave.c > > > then? > > > > Srini's change add support for DT for the same file, so It does not make > > sense to rename. Yes this patch tries to fix a warn which is there due > > to DT being not supported but with Srini's patches this warn should go > > away as sdw_slave_add() will be invoked by the DT counterpart > > > > Sorry Nathan, we would have to live with the warn for few more days till > > I apply Srini's changes. So I am not taking this (or v2) patch > > > > That is fine as I can apply this locally. Could you point me to these > patches so that I can take a look at them? Here you go: https://lore.kernel.org/lkml/20190808144504.24823-3-srinivas.kandaga...@linaro.org/ -- ~Vinod
Re: [Linux-kernel-mentees] [PATCH v2 0/3] PCI: pci-sysfs.c cleanup
[+cc Greg] On Tue, Aug 13, 2019 at 02:45:10PM -0600, Kelsey Skunberg wrote: > This series is designed to clean up device attributes and permissions in > pci-sysfs.c. Then move the sysfs SR-IOV functions from pci-sysfs.c to > iov.c for better organization. Patches build off of each other. > > Patch 1: Define device attributes with DEVICE_ATTR*() instead of __ATTR*(). > > Patch 2: Change permissions from symbolic to the preferred octal. > > Patch 3: Move sysfs SR-IOV functions to iov.c to keep the feature's code > together. > > Changes since v1: > Add patch 1 and 2 to fix the way device attributes are defined > and change permissions from symbolic to octal. Patch 3 which moves > sysfs SR-IOV functions to iov.c will then apply cleaner. > > > Kelsey Skunberg (3): > PCI: sysfs: Define device attributes with DEVICE_ATTR*() > PCI: sysfs: Change permissions from symbolic to octal > PCI/IOV: Move sysfs SR-IOV functions to iov.c > > drivers/pci/iov.c | 168 +++ > drivers/pci/pci-sysfs.c | 217 > drivers/pci/pci.h | 2 +- > 3 files changed, 188 insertions(+), 199 deletions(-) Applied to pci/virtualization for v5.4, thanks! Beginning of thread: https://lore.kernel.org/r/20190813204513.4790-1-skunberg.kel...@gmail.com
Re: [Linux-kernel-mentees] [PATCH v2 2/3] PCI: sysfs: Change permissions from symbolic to octal
[+cc Bodong, Don, Greg for permission question]
On Tue, Aug 13, 2019 at 02:45:12PM -0600, Kelsey Skunberg wrote:
> Symbolic permissions such as "(S_IWUSR | S_IWGRP)" are not
> preferred and octal permissions should be used instead. Change all
> symbolic permissions to octal permissions.
>
> Example of old:
>
> "(S_IWUSR | S_IWGRP)"
>
> Example of new:
>
> "0220"
> static DEVICE_ATTR_RO(sriov_totalvfs);
> -static DEVICE_ATTR(sriov_numvfs, (S_IRUGO | S_IWUSR | S_IWGRP),
> - sriov_numvfs_show, sriov_numvfs_store);
> +static DEVICE_ATTR(sriov_numvfs, 0664, sriov_numvfs_show,
> sriov_numvfs_store);
> static DEVICE_ATTR_RO(sriov_offset);
> static DEVICE_ATTR_RO(sriov_stride);
> static DEVICE_ATTR_RO(sriov_vf_device);
> -static DEVICE_ATTR(sriov_drivers_autoprobe, (S_IRUGO | S_IWUSR | S_IWGRP),
> -sriov_drivers_autoprobe_show, sriov_drivers_autoprobe_store);
> +static DEVICE_ATTR(sriov_drivers_autoprobe, 0664,
> sriov_drivers_autoprobe_show,
> +sriov_drivers_autoprobe_store);
Greg noticed that sriov_numvfs and sriov_drivers_autoprobe have
"unusual" permissions. These were added by:
0e7df22401a3 ("PCI: Add sysfs sriov_drivers_autoprobe to control VF driver
binding")
1789382a72a5 ("PCI: SRIOV control and status via sysfs")
Kelsey's patch correctly preserves the existing permissions, but we
should double-check that they are the permissions they want, and
possibly add a comment about why they're different from the rest.
Bjorn
Re: [PATCH v1 02/10] powerpc/mm: rework io-workaround invocation.
On Tue, Aug 13, 2019 at 08:11:34PM +, Christophe Leroy wrote: > ppc_md.ioremap() is only used for I/O workaround on CELL platform, > so indirect function call can be avoided. > > This patch reworks the io-workaround and ioremap() functions to > use static keys for the activation of io-workaround. > > When CONFIG_PPC_IO_WORKAROUNDS or CONFIG_PPC_INDIRECT_MMIO are not > selected, the I/O workaround ioremap() voids and the static key is > not used at all. Why bother with the complex static key? ioremap isn't exactly a fast path. Just make it a normal branch if enabled, with the option to compile it out entirely as in your patch.
Re: [PATCH] powerpc/32s: fix boot failure with DEBUG_PAGEALLOC without KASAN.
On Wed, Aug 14, 2019 at 05:28:35AM +, Christophe Leroy wrote: > When KASAN is selected, the definitive hash table has to be > set up later, but there is already an early temporary one. > > When KASAN is not selected, there is no early hash table, > so the setup of the definitive hash table cannot be delayed. I think you also want to add this information to the code itself as comments..
RE: [PATCH v2 0/2] Simplify mtty driver and mdev core
Hi Christoph, Greg, > -Original Message- > From: Greg Kroah-Hartman > Sent: Tuesday, August 13, 2019 11:10 PM > To: Christoph Hellwig ; Parav Pandit > > Cc: Kirti Wankhede ; Alex Williamson > ; k...@vger.kernel.org; linux- > ker...@vger.kernel.org; coh...@redhat.com; c...@nvidia.com > Subject: Re: [PATCH v2 0/2] Simplify mtty driver and mdev core > > On Tue, Aug 13, 2019 at 09:37:21AM -0700, Christoph Hellwig wrote: > > On Tue, Aug 13, 2019 at 02:40:02PM +, Parav Pandit wrote: > > > We need to ask Greg or Linus on the kernel policy on whether an API should > exist without in-kernel driver. > > I "love" it when people try to ask a question of me and they don't actually > cc: > me. That means they really do not want the answer (or they already know > it...) > Thanks Christoph for adding me here. > I pretty much knew your answer and I was just hinting Kirti that if you ask Greg you would get the same answer. So we better cleanup without reaching out to you. :-) > The policy is that the api should not exist at all, everyone knows this, why > is this > even a question? > Yes, I am aware of this. Few subsystems in which I worked, it has followed this policy cautiously. But when I heard different policy for mdev, I asked others wisdom. > > > We don't add such API in netdev, rdma and possibly other subsystem. > > > Where can we find this mdev driver in-tree? > > > > The clear policy is that we don't keep such symbols around. Been > > there done that only recently again. > > Agreed. If anyone knows of anything else that isn't being used, we will be > glad > to free up the space by cleaning it up. > Ok. so this small patchset makes sense. Thanks for the ack and direction Christoph, Greg.
[PATCH] powerpc/32s: fix boot failure with DEBUG_PAGEALLOC without KASAN.
When KASAN is selected, the definitive hash table has to be
set up later, but there is already an early temporary one.
When KASAN is not selected, there is no early hash table,
so the setup of the definitive hash table cannot be delayed.
Reported-by: Jonathan Neuschafer
Fixes: 72f208c6a8f7 ("powerpc/32s: move hash code patching out of
MMU_init_hw()")
Signed-off-by: Christophe Leroy
---
arch/powerpc/kernel/head_32.S | 2 ++
arch/powerpc/mm/book3s32/mmu.c | 5 +
2 files changed, 7 insertions(+)
diff --git a/arch/powerpc/kernel/head_32.S b/arch/powerpc/kernel/head_32.S
index f255e22184b4..c8b4f7ed318c 100644
--- a/arch/powerpc/kernel/head_32.S
+++ b/arch/powerpc/kernel/head_32.S
@@ -897,9 +897,11 @@ start_here:
bl machine_init
bl __save_cpu_setup
bl MMU_init
+#ifdef CONFIG_KASAN
BEGIN_MMU_FTR_SECTION
bl MMU_init_hw_patch
END_MMU_FTR_SECTION_IFSET(MMU_FTR_HPTE_TABLE)
+#endif
/*
* Go back to running unmapped so we can load up new values
diff --git a/arch/powerpc/mm/book3s32/mmu.c b/arch/powerpc/mm/book3s32/mmu.c
index e249fbf6b9c3..6ddcbfad5c9e 100644
--- a/arch/powerpc/mm/book3s32/mmu.c
+++ b/arch/powerpc/mm/book3s32/mmu.c
@@ -358,6 +358,11 @@ void __init MMU_init_hw(void)
hash_mb2 = hash_mb = 32 - LG_HPTEG_SIZE - lg_n_hpteg;
if (lg_n_hpteg > 16)
hash_mb2 = 16 - LG_HPTEG_SIZE;
+
+ if (IS_ENABLED(CONFIG_KASAN))
+ return;
+
+ MMU_init_hw_patch();
}
void __init MMU_init_hw_patch(void)
--
2.13.3
RECEIVE AND KEEP THIS MONEY FOR ME IN YOUR BANK ACCOUNT,REPLY TO fta447...@gmail.com FOR DETAILS
Re: [PATCH v1 08/10] powerpc/mm: move __ioremap_at() and __iounmap_at() into ioremap.c
> +/** > + * __iounmap_from - Low level function to tear down the page tables > + * for an IO mapping. This is used for mappings that > + * are manipulated manually, like partial unmapping of > + * PCI IOs or ISA space. > + */ > +void __iounmap_at(void *ea, unsigned long size) The comment doesn't mention the function name. That's why I ususally don't even add the function name so that it doesn't get out of sync.
[rcu:dev.2019.08.12a 35/61] ERROR: "tick_nohz_full_running" [kernel/rcu/rcutorture.ko] undefined!
tree: https://kernel.googlesource.com/pub/scm/linux/kernel/git/paulmck/linux-rcu.git dev.2019.08.12a head: 8d14501a5112fd15204344f54985b2b4a5c4c5f3 commit: 76a2095343cd23efe62ca248c098dc351c74aed5 [35/61] rcutorture: Force on tick for readers and callback flooders config: x86_64-rhel (attached as .config) compiler: gcc-7 (Debian 7.4.0-10) 7.4.0 reproduce: git checkout 76a2095343cd23efe62ca248c098dc351c74aed5 # save the attached .config to linux build tree make ARCH=x86_64 If you fix the issue, kindly add following tag Reported-by: kbuild test robot All errors (new ones prefixed by >>): ERROR: "tick_nohz_dep_clear_task" [kernel/rcu/rcutorture.ko] undefined! ERROR: "tick_nohz_dep_set_task" [kernel/rcu/rcutorture.ko] undefined! >> ERROR: "tick_nohz_full_running" [kernel/rcu/rcutorture.ko] undefined! --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: application/gzip
Re: [PATCH v1 01/10] powerpc/mm: drop ppc_md.iounmap()
On Tue, Aug 13, 2019 at 08:11:33PM +, Christophe Leroy wrote: > ppc_md.iounmap() is never set, drop it. > > Signed-off-by: Christophe Leroy Hah, I was just going to send the same patch as part of an tree-wide ioremap related series.. Reviewed-by: Christoph Hellwig
Re: [PATCH 3/3] mm/mmap.c: extract __vma_unlink_list as counter part for __vma_link_list
Btw, is there any good reason we don't use a list_head for vma linkage?
GREETING BELOVED ONE,
Dear Friend, I came across your e-mail contact prior a private search whilst in need of your partnership for investment assistance in your country. I am opportune to use this medium to exhibit my legal intentions towards investing to your country under your management. I am fully convinced that you will really be of help as a business partner. My name is Aisha Gaddafi a single Mother and a Widow and i have three Children. I am the only biological Daughter of late Libyan President (Late Colonel Muammar Gaddafi). I have investment funds worth Twenty Seven Million Five Hundred Thousand United State Dollar ($27.500.000.00 ) and i need a trusted investment Manager/Partner. I am planning to go into investment projects in your country of origin or present country of Location to assist me establish the investments project. I am willing to negotiate investment/business profit sharing ratio with you base on the future investment earning profits. If you are willing to handle this project on my behalf kindly reply urgent to enable me provide you tell you more details about myself and more information about the release of the investment funds. I appreciate Your Urgent Reply to my email address: Best Regards Mrs Aisha Gaddafi
[PATCH] liquidio: add cleanup in octeon_setup_iq()
If oct->fn_list.enable_io_queues() fails, no cleanup is executed, leading
to memory/resource leaks. To fix this issue, invoke
octeon_delete_instr_queue() before returning from the function.
Signed-off-by: Wenwen Wang
---
drivers/net/ethernet/cavium/liquidio/request_manager.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/cavium/liquidio/request_manager.c
b/drivers/net/ethernet/cavium/liquidio/request_manager.c
index 0322241..6dd65f9 100644
--- a/drivers/net/ethernet/cavium/liquidio/request_manager.c
+++ b/drivers/net/ethernet/cavium/liquidio/request_manager.c
@@ -237,8 +237,10 @@ int octeon_setup_iq(struct octeon_device *oct,
}
oct->num_iqs++;
- if (oct->fn_list.enable_io_queues(oct))
+ if (oct->fn_list.enable_io_queues(oct)) {
+ octeon_delete_instr_queue(oct, iq_no);
return 1;
+ }
return 0;
}
--
2.7.4
Re: [PATCH 5/5] ARM: dts: sunxi: Add missing watchdog interrupts
On Tue, Aug 13, 2019 at 8:48 PM Maxime Ripard wrote: > > From: Maxime Ripard > > The watchdog has an interrupt on all our SoCs, but it wasn't always listed. > Add it to the devicetree where it's missing. > > Signed-off-by: Maxime Ripard Acked-by: Chen-Yu Tsai On a separate note, the A31 has four watchdogs in the timer block, and one interrupt for each watchdog. Should we expand the node to encompass all of them, or add separate nodes for each additional one? Thanks
Re: [PATCH 03/15] riscv: refactor the IPI code
On Tue, 13 Aug 2019, Christoph Hellwig wrote: > This prepare for adding native non-SBI IPI code. > > Signed-off-by: Christoph Hellwig Thanks, queued for v5.4-rc1. - Paul
Re: [PATCH 4/5] ARM: dts: sun8i: a83t: Remove the watchdog clock
On Tue, Aug 13, 2019 at 8:47 PM Maxime Ripard wrote:
>
> From: Maxime Ripard
>
> The watchdog binding doesn't define a clock, and it indeed looks like
> there's no explicit clock feeding it.
The diagram on page 133 of the manual shows OSC24M / 750 feeding the watchdog.
Other manuals, such as the A10 one, mention:
Watchdog clock source is OSC24M. if the OSC24M is turned off, the watchdog
will not work.
So in fact it does use a clock signal. It's just that we've been lazy, since
the clock rate is fixed and is always on.
ChenYu
> Let's remove it from our DT.
>
> Signed-off-by: Maxime Ripard
> ---
> arch/arm/boot/dts/sun8i-a83t.dtsi | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/arch/arm/boot/dts/sun8i-a83t.dtsi
> b/arch/arm/boot/dts/sun8i-a83t.dtsi
> index 523be6611c50..15f8c80f69a5 100644
> --- a/arch/arm/boot/dts/sun8i-a83t.dtsi
> +++ b/arch/arm/boot/dts/sun8i-a83t.dtsi
> @@ -817,7 +817,6 @@
> compatible = "allwinner,sun6i-a31-wdt";
> reg = <0x01c20ca0 0x20>;
> interrupts = ;
> - clocks = <>;
> };
>
> spdif: spdif@1c21000 {
> --
> 2.21.0
>
Re: [PATCH 13/15] riscv: clear the instruction cache and all registers when booting
On Wed, Aug 14, 2019 at 09:00:14AM +0800, Alan Kao wrote: > But it doesn't really mean that the running system has an FPU given CONFIG_FPU > enabled. Normally the existence of an FPU is checked in riscv_fill_hwcap by > searching device tree, where the code looks like > > > bool has_fpu = false; // this one is global > ... > #ifdef CONFIG_FPU > if (elf_hwcap & (COMPAT_HWCAP_ISA_F | COMPAT_HWCAP_ISA_D)) > has_fpu = true; > #endif > > > Or does CONFIG_FPU have a more intuitive meaning when CONFIG_M_MODE is > enabled? No, it doesn't.. > > > + csrrt0, CSR_MISA > > + andit0, t0, (COMPAT_HWCAP_ISA_F | COMPAT_HWCAP_ISA_D) > > + bnezt0, .Lreset_regs_done ... which is why we have these few lines of code that check the caps returns from the misa CSR, similar to the elf_caps check quoted above.
Re: [PATCH v4,1/2] PCI: hv: Detect and fix Hyper-V PCI domain number collision
Thanks for splitting these; I think that makes more sense. On Wed, Aug 14, 2019 at 12:38:54AM +, Haiyang Zhang wrote: > Currently in Azure cloud, for passthrough devices including GPU, the host > sets the device instance ID's bytes 8 - 15 to a value derived from the host > HWID, which is the same on all devices in a VM. So, the device instance > ID's bytes 8 and 9 provided by the host are no longer unique. This can > cause device passthrough to VMs to fail because the bytes 8 and 9 are used > as PCI domain number. Collision of domain numbers will cause the second > device with the same domain number fail to load. I think this patch is fine. I could be misunderstanding the commit log, but when you say "the ID bytes 8 and 9 are *no longer* unique", that suggests that they *used* to be unique but stopped being unique at some point, which of course raises the question of *when* they became non-unique. The specific information about that point would be useful to have in the commit log, e.g., is this related to a specific version of Azure, a configuration change, etc? Does this problem affect GPUs more than other passthrough devices? If all passthrough devices are affected, why mention GPUs in particular? I can't tell whether that information is relevant or superfluous. Bjorn
Re: [alsa-devel] [PATCH 06/17] soundwire: cadence_master: use firmware defaults for frame shape
On 06-08-19, 18:06, Cezary Rojewski wrote:
> On 2019-08-06 17:36, Pierre-Louis Bossart wrote:
> >
> >
> > On 8/6/19 10:27 AM, Cezary Rojewski wrote:
> > > On 2019-08-06 02:55, Pierre-Louis Bossart wrote:
> > > > diff --git a/drivers/soundwire/cadence_master.c
> > > > b/drivers/soundwire/cadence_master.c
> > > > index 5d9729b4d634..89c55e4bb72c 100644
> > > > --- a/drivers/soundwire/cadence_master.c
> > > > +++ b/drivers/soundwire/cadence_master.c
> > > > @@ -48,6 +48,8 @@
> > > > #define CDNS_MCP_SSPSTAT 0xC
> > > > #define CDNS_MCP_FRAME_SHAPE 0x10
> > > > #define CDNS_MCP_FRAME_SHAPE_INIT 0x14
> > > > +#define CDNS_MCP_FRAME_SHAPE_COL_MASK GENMASK(2, 0)
> > > > +#define CDNS_MCP_FRAME_SHAPE_ROW_OFFSET 3
> > > > #define CDNS_MCP_CONFIG_UPDATE 0x18
> > > > #define CDNS_MCP_CONFIG_UPDATE_BIT BIT(0)
> > > > @@ -175,7 +177,6 @@
> > > > /* Driver defaults */
> > > > #define CDNS_DEFAULT_CLK_DIVIDER 0
> > > > -#define CDNS_DEFAULT_FRAME_SHAPE 0x30
> > > > #define CDNS_DEFAULT_SSP_INTERVAL 0x18
> > > > #define CDNS_TX_TIMEOUT 2000
> > > > @@ -901,6 +902,20 @@ int sdw_cdns_pdi_init(struct sdw_cdns *cdns,
> > > > }
> > > > EXPORT_SYMBOL(sdw_cdns_pdi_init);
> > > > +static u32 cdns_set_initial_frame_shape(int n_rows, int n_cols)
> > > > +{
> > > > + u32 val;
> > > > + int c;
> > > > + int r;
> > > > +
> > > > + r = sdw_find_row_index(n_rows);
> > > > + c = sdw_find_col_index(n_cols) & CDNS_MCP_FRAME_SHAPE_COL_MASK;
> > > > +
> > > > + val = (r << CDNS_MCP_FRAME_SHAPE_ROW_OFFSET) | c;
> > > > +
> > > > + return val;
> > > > +}
> > > > +
> > >
> > > Guess this have been said already, but this function could be
> > > simplified - unless you really want to keep explicit variable
> > > declaration. Both "c" and "r" declarations could be merged into
> > > single line while "val" is not needed at all.
> > >
> > > One more thing - is AND bitwise op really needed for cols
> > > explicitly? We know all col values upfront - these are static and
> > > declared in global table nearby. Static declaration takes care of
> > > "initial range-check". Is another one necessary?
> > >
> > > Moreover, this is a _get_ and certainly not a _set_ type of
> > > function. I'd even consider renaming it to: "cdns_get_frame_shape"
> > > as this is neither a _set_ nor an explicit initial frame shape
> > > setter.
> > >
> > > It might be even helpful to split two usages:
> > >
> > > #define sdw_frame_shape(col_idx, row_idx) \
> > > ((row_idx << CDNS_MCP_FRAME_SHAPE_ROW_OFFSET) | col_idx)
> > >
> > > u32 cdns_get_frame_shape(u16 rows, u16 cols)
> > > {
> > > u16 c, r;
> > >
> > > r = sdw_find_row_index(rows);
> > > c = sdw_find_col_index(cols);
> > >
> > > return sdw_frame_shape(c, r);
> > > }
> > >
> > > The above may even be simplified into one-liner.
> >
> > This is a function used once on startup, there is no real need to
> > simplify further. The separate variables help add debug traces as needed
> > and keep the code readable while showing how the values are encoded into
> > a register.
>
> Eh, I've thought it's gonna be exposed to userspace (via uapi) so it can be
> fetched by tests or tools.
Uapi? I dont see anything in this or other series posted, did I miss
something? Also I am not sure I like the idea of exposing these to
userland!
>
> In such case - if there is a single usage only - guess function is fine as
> is.
--
~Vinod
Re: [alsa-devel] [PATCH] soundwire: Don't build sound.o without CONFIG_ACPI
On Wed, Aug 14, 2019 at 09:29:47AM +0530, Vinod Koul wrote:
> On 13-08-19, 09:22, Pierre-Louis Bossart wrote:
> > On 8/13/19 1:10 AM, Nathan Chancellor wrote:
> > > clang warns when CONFIG_ACPI is unset:
> > >
> > > ../drivers/soundwire/slave.c:16:12: warning: unused function
> > > 'sdw_slave_add' [-Wunused-function]
> > > static int sdw_slave_add(struct sdw_bus *bus,
> > > ^
> > > 1 warning generated.
> > >
> > > Before commit 8676b3ca4673 ("soundwire: fix regmap dependencies and
> > > align with other serial links"), this code would only be compiled when
> > > ACPI was set because it was only selected by SOUNDWIRE_INTEL, which
> > > depends on ACPI.
> > >
> > > Now, this code can be compiled without CONFIG_ACPI, which causes the
> > > above warning. The IS_ENABLED(CONFIG_ACPI) guard could be moved to avoid
> > > compiling the function; however, slave.c only contains three functions,
> > > two of which are static. Only compile slave.o when CONFIG_ACPI is set,
> > > where it will actually be used. bus.h contains a stub for
> > > sdw_acpi_find_slaves so there will be no issues with an undefined
> > > function.
> > >
> > > This has been build tested with CONFIG_ACPI set and unset in combination
> > > with CONFIG_SOUNDWIRE unset, built in, and a module.
> >
> > Thanks for the patch. Do you have a .config you can share offline so that we
> > add it to our tests?
> >
> > >
> > > Fixes: 8676b3ca4673 ("soundwire: fix regmap dependencies and align with
> > > other serial links")
> > > Link: https://github.com/ClangBuiltLinux/linux/issues/637
> > > Signed-off-by: Nathan Chancellor
> > > ---
> > > drivers/soundwire/Makefile | 6 +-
> > > drivers/soundwire/slave.c | 3 ---
> > > 2 files changed, 5 insertions(+), 4 deletions(-)
> > >
> > > diff --git a/drivers/soundwire/Makefile b/drivers/soundwire/Makefile
> > > index 45b7e5001653..226090902716 100644
> > > --- a/drivers/soundwire/Makefile
> > > +++ b/drivers/soundwire/Makefile
> > > @@ -4,9 +4,13 @@
> > > #
> > > #Bus Objs
> > > -soundwire-bus-objs := bus_type.o bus.o slave.o mipi_disco.o stream.o
> > > +soundwire-bus-objs := bus_type.o bus.o mipi_disco.o stream.o
> > > obj-$(CONFIG_SOUNDWIRE) += soundwire-bus.o
> > > +ifdef CONFIG_ACPI
> > > +soundwire-bus-objs += slave.o
> > > +endif
> >
> > I am fine with the change, but we might as well rename the file acpi_slave.c
> > then?
>
> Srini's change add support for DT for the same file, so It does not make
> sense to rename. Yes this patch tries to fix a warn which is there due
> to DT being not supported but with Srini's patches this warn should go
> away as sdw_slave_add() will be invoked by the DT counterpart
>
> Sorry Nathan, we would have to live with the warn for few more days till
> I apply Srini's changes. So I am not taking this (or v2) patch
>
That is fine as I can apply this locally. Could you point me to these
patches so that I can take a look at them?
Thanks for the reply!
Nathan
[PATCH] ARM: dts: sunxi: Add mdio bus sub-node to GMAC
From: Chen-Yu Tsai
The DWMAC binding never supported having the Ethernet PHY node as a
direct child to the controller, nor did it support the "phy" property
as a way to specify which Ethernet PHY to use. What seemed to work
was simply the implementation ignoring the "phy" property and instead
probing all addresses on the MDIO bus and using the first available
one.
The recent switch from "phy" to "phy-handle" breaks the assumptions
of the implementation, and does not match what the binding requires.
The binding requires that if an MDIO bus is described, it shall be
a sub-node with the "snps,dwmac-mdio" compatible string.
Add a device node for the MDIO bus, and move the Ethernet PHY node
under it. Also fix up the #address-cells and #size-cells properties
where needed.
Fixes: de332de26d19 ("ARM: dts: sunxi: Switch from phy to phy-handle")
Signed-off-by: Chen-Yu Tsai
---
arch/arm/boot/dts/sun6i-a31-colombus.dts | 10 ++
arch/arm/boot/dts/sun6i-a31-hummingbird.dts| 16 +---
arch/arm/boot/dts/sun6i-a31-i7.dts | 10 ++
arch/arm/boot/dts/sun6i-a31-m9.dts | 10 ++
.../boot/dts/sun6i-a31-mele-a1000g-quad.dts| 10 ++
arch/arm/boot/dts/sun6i-a31.dtsi | 8 ++--
arch/arm/boot/dts/sun6i-a31s-cs908.dts | 9 ++---
arch/arm/boot/dts/sun6i-a31s-sina31s.dts | 10 ++
.../boot/dts/sun6i-a31s-sinovoip-bpi-m2.dts| 14 --
.../boot/dts/sun7i-a20-bananapi-m1-plus.dts| 10 ++
arch/arm/boot/dts/sun7i-a20-bananapi.dts | 10 ++
arch/arm/boot/dts/sun7i-a20-bananapro.dts | 10 ++
arch/arm/boot/dts/sun7i-a20-cubieboard2.dts| 10 ++
arch/arm/boot/dts/sun7i-a20-cubietruck.dts | 10 ++
arch/arm/boot/dts/sun7i-a20-hummingbird.dts| 18 ++
arch/arm/boot/dts/sun7i-a20-i12-tvbox.dts | 10 ++
arch/arm/boot/dts/sun7i-a20-icnova-swac.dts| 10 ++
arch/arm/boot/dts/sun7i-a20-itead-ibox.dts | 2 ++
arch/arm/boot/dts/sun7i-a20-lamobo-r1.dts | 2 --
arch/arm/boot/dts/sun7i-a20-m3.dts | 10 ++
arch/arm/boot/dts/sun7i-a20-olimex-som-evb.dts | 10 ++
.../boot/dts/sun7i-a20-olimex-som204-evb.dts | 18 ++
arch/arm/boot/dts/sun7i-a20-olinuxino-lime.dts | 10 ++
.../arm/boot/dts/sun7i-a20-olinuxino-lime2.dts | 10 ++
.../arm/boot/dts/sun7i-a20-olinuxino-micro.dts | 10 ++
arch/arm/boot/dts/sun7i-a20-orangepi-mini.dts | 10 ++
arch/arm/boot/dts/sun7i-a20-orangepi.dts | 10 ++
arch/arm/boot/dts/sun7i-a20-pcduino3-nano.dts | 10 ++
arch/arm/boot/dts/sun7i-a20-pcduino3.dts | 10 ++
.../boot/dts/sun7i-a20-wits-pro-a20-dkt.dts| 10 ++
arch/arm/boot/dts/sun7i-a20.dtsi | 8 ++--
arch/arm/boot/dts/sun9i-a80-cubieboard4.dts| 10 ++
arch/arm/boot/dts/sun9i-a80-optimus.dts| 2 ++
arch/arm/boot/dts/sun9i-a80.dtsi | 8 ++--
34 files changed, 203 insertions(+), 132 deletions(-)
diff --git a/arch/arm/boot/dts/sun6i-a31-colombus.dts
b/arch/arm/boot/dts/sun6i-a31-colombus.dts
index 50092b0bd0fe..93a15eaaa8cb 100644
--- a/arch/arm/boot/dts/sun6i-a31-colombus.dts
+++ b/arch/arm/boot/dts/sun6i-a31-colombus.dts
@@ -79,10 +79,6 @@
phy-handle = <>;
phy-mode = "rgmii";
status = "okay";
-
- phy1: ethernet-phy@1 {
- reg = <1>;
- };
};
{
@@ -104,6 +100,12 @@
};
};
+ {
+ phy1: ethernet-phy@1 {
+ reg = <1>;
+ };
+};
+
{
vmmc-supply = <_vcc3v0>;
bus-width = <4>;
diff --git a/arch/arm/boot/dts/sun6i-a31-hummingbird.dts
b/arch/arm/boot/dts/sun6i-a31-hummingbird.dts
index 7c611ddbaf2f..049e6ab3cf56 100644
--- a/arch/arm/boot/dts/sun6i-a31-hummingbird.dts
+++ b/arch/arm/boot/dts/sun6i-a31-hummingbird.dts
@@ -156,13 +156,6 @@
phy-handle = <>;
phy-mode = "rgmii";
status = "okay";
-
- phy1: ethernet-phy@1 {
- reg = <1>;
- reset-gpios = < 0 21 GPIO_ACTIVE_LOW>;
- reset-assert-us = <1>;
- reset-deassert-us = <3>;
- };
};
{
@@ -199,6 +192,15 @@
status = "okay";
};
+ {
+ phy1: ethernet-phy@1 {
+ reg = <1>;
+ reset-gpios = < 0 21 GPIO_ACTIVE_LOW>;
+ reset-assert-us = <1>;
+ reset-deassert-us = <3>;
+ };
+};
+
{
vmmc-supply = <_dcdc1>;
bus-width = <4>;
diff --git a/arch/arm/boot/dts/sun6i-a31-i7.dts
b/arch/arm/boot/dts/sun6i-a31-i7.dts
index ebb0b4710afb..6cc8ccf53d88 100644
--- a/arch/arm/boot/dts/sun6i-a31-i7.dts
+++ b/arch/arm/boot/dts/sun6i-a31-i7.dts
@@ -120,10 +120,6 @@
phy-handle = <>;
phy-mode = "mii";
status = "okay";
-
- phy1: ethernet-phy@1 {
- reg = <1>;
- };
};
{
@@
Re: [alsa-devel] [PATCH v2 3/5] ASoC: core: add support to snd_soc_dai_get_sdw_stream()
On 13-08-19, 20:58, Mark Brown wrote: > On Tue, Aug 13, 2019 at 02:38:53PM -0500, Pierre-Louis Bossart wrote: > > > Indeed. I don't have a full understanding of that part to be honest, nor why > > we need something SoundWire-specific. We already abused the set_tdm_slot API > > to store an HDaudio stream, now we have a rather confusing stream > > information for SoundWire and I have about 3 other 'stream' contexts in > > SOF... I am still doing basic cleanups but this has been on my radar for a > > while. > > There is something to be said for not abusing the TDM slot API if it can > make things clearer by using bus-idiomatic mechanisms, but it does mean > everything needs to know about each individual bus :/ . Here ASoC doesn't need to know about sdw bus. As Srini explained, this helps in the case for him to get the stream context and set the stream context from the machine driver. Nothing else is expected to be done from this API. We already do a set using snd_soc_dai_set_sdw_stream(). Here we add the snd_soc_dai_get_sdw_stream() to query Thanks -- ~Vinod
Re: [PATCH v2 1/5] soundwire: Add compute_params callback
On 13-08-19, 14:08, Pierre-Louis Bossart wrote:
> On 8/13/19 1:17 PM, Srinivas Kandagatla wrote:
> >
> >
> > On 13/08/2019 15:34, Pierre-Louis Bossart wrote:
> > > On 8/13/19 3:35 AM, Srinivas Kandagatla wrote:
> > > > From: Vinod Koul
> > > >
> > > > This callback allows masters to compute the bus parameters required.
> > >
> > > This looks like a partial use of the patch ('soundwire: Add Intel
> > > resource management algorithm')? see comments below
> > >
> >
> > Yes it duplicate indeed!
> >
> > I will use that patch!
>
> Actually please don't...
> we found issues with the Intel allocation so I'd rather have the big Intel
> patch split into two parts, with callbacks+prepare/deprepare changes going
> in first. It'll be much faster/nicer for everyone.
I was about to say that as well. I think lets take this as is and Intel
algo can be on top of this. That seems easier for everyone to sort
dependencies
--
~Vinod
Re: [alsa-devel] [PATCH] soundwire: Don't build sound.o without CONFIG_ACPI
On 13-08-19, 09:22, Pierre-Louis Bossart wrote:
> On 8/13/19 1:10 AM, Nathan Chancellor wrote:
> > clang warns when CONFIG_ACPI is unset:
> >
> > ../drivers/soundwire/slave.c:16:12: warning: unused function
> > 'sdw_slave_add' [-Wunused-function]
> > static int sdw_slave_add(struct sdw_bus *bus,
> > ^
> > 1 warning generated.
> >
> > Before commit 8676b3ca4673 ("soundwire: fix regmap dependencies and
> > align with other serial links"), this code would only be compiled when
> > ACPI was set because it was only selected by SOUNDWIRE_INTEL, which
> > depends on ACPI.
> >
> > Now, this code can be compiled without CONFIG_ACPI, which causes the
> > above warning. The IS_ENABLED(CONFIG_ACPI) guard could be moved to avoid
> > compiling the function; however, slave.c only contains three functions,
> > two of which are static. Only compile slave.o when CONFIG_ACPI is set,
> > where it will actually be used. bus.h contains a stub for
> > sdw_acpi_find_slaves so there will be no issues with an undefined
> > function.
> >
> > This has been build tested with CONFIG_ACPI set and unset in combination
> > with CONFIG_SOUNDWIRE unset, built in, and a module.
>
> Thanks for the patch. Do you have a .config you can share offline so that we
> add it to our tests?
>
> >
> > Fixes: 8676b3ca4673 ("soundwire: fix regmap dependencies and align with
> > other serial links")
> > Link: https://github.com/ClangBuiltLinux/linux/issues/637
> > Signed-off-by: Nathan Chancellor
> > ---
> > drivers/soundwire/Makefile | 6 +-
> > drivers/soundwire/slave.c | 3 ---
> > 2 files changed, 5 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/soundwire/Makefile b/drivers/soundwire/Makefile
> > index 45b7e5001653..226090902716 100644
> > --- a/drivers/soundwire/Makefile
> > +++ b/drivers/soundwire/Makefile
> > @@ -4,9 +4,13 @@
> > #
> > #Bus Objs
> > -soundwire-bus-objs := bus_type.o bus.o slave.o mipi_disco.o stream.o
> > +soundwire-bus-objs := bus_type.o bus.o mipi_disco.o stream.o
> > obj-$(CONFIG_SOUNDWIRE) += soundwire-bus.o
> > +ifdef CONFIG_ACPI
> > +soundwire-bus-objs += slave.o
> > +endif
>
> I am fine with the change, but we might as well rename the file acpi_slave.c
> then?
Srini's change add support for DT for the same file, so It does not make
sense to rename. Yes this patch tries to fix a warn which is there due
to DT being not supported but with Srini's patches this warn should go
away as sdw_slave_add() will be invoked by the DT counterpart
Sorry Nathan, we would have to live with the warn for few more days till
I apply Srini's changes. So I am not taking this (or v2) patch
Thanks
>
> > +
> > #Cadence Objs
> > soundwire-cadence-objs := cadence_master.o
> > obj-$(CONFIG_SOUNDWIRE_CADENCE) += soundwire-cadence.o
> > diff --git a/drivers/soundwire/slave.c b/drivers/soundwire/slave.c
> > index f39a5815e25d..0dc188e6873b 100644
> > --- a/drivers/soundwire/slave.c
> > +++ b/drivers/soundwire/slave.c
> > @@ -60,7 +60,6 @@ static int sdw_slave_add(struct sdw_bus *bus,
> > return ret;
> > }
> > -#if IS_ENABLED(CONFIG_ACPI)
> > /*
> >* sdw_acpi_find_slaves() - Find Slave devices in Master ACPI node
> >* @bus: SDW bus instance
> > @@ -110,5 +109,3 @@ int sdw_acpi_find_slaves(struct sdw_bus *bus)
> > return 0;
> > }
> > -
> > -#endif
> >
--
~Vinod
[PATCH] x86/apic: reset LDR in clear_local_APIC
On a 32 bit RHEL6 guest with greater than 8 cpus, the
kdump kernel hangs when calibrating apic. This happens
because when apic initializes bigsmp, it also initializes LDR
even though it probably wouldn't be used.
When booting into kdump, KVM apic incorrectly reads the stale LDR
values from the guest while building the logical destination map
even for inactive vcpus. While KVM apic can be fixed to ignore apics
that haven't been enabled, a simple guest only change can be to
just clear out the LDR.
Signed-off-by: Bandan Das
---
arch/x86/kernel/apic/apic.c | 4
1 file changed, 4 insertions(+)
diff --git a/arch/x86/kernel/apic/apic.c b/arch/x86/kernel/apic/apic.c
index f5291362da1a..6b9511dc9157 100644
--- a/arch/x86/kernel/apic/apic.c
+++ b/arch/x86/kernel/apic/apic.c
@@ -1141,6 +1141,10 @@ void clear_local_APIC(void)
apic_write(APIC_LVT0, v | APIC_LVT_MASKED);
v = apic_read(APIC_LVT1);
apic_write(APIC_LVT1, v | APIC_LVT_MASKED);
+ if (!x2apic_enabled()) {
+ v = apic_read(APIC_LDR) & ~APIC_LDR_MASK;
+ apic_write(APIC_LDR, v);
+ }
if (maxlvt >= 4) {
v = apic_read(APIC_LVTPC);
apic_write(APIC_LVTPC, v | APIC_LVT_MASKED);
--
2.20.1
Re: [PATCH 1/2] riscv: Correct the initialized flow of FP register
On Wed, Aug 14, 2019 at 7:15 AM Vincent Chen wrote:
>
> On Thu, Aug 8, 2019 at 11:50 PM Paul Walmsley
> wrote:
> >
> > On Thu, 8 Aug 2019, Anup Patel wrote:
> >
> > > On Thu, Aug 8, 2019 at 1:30 PM Vincent Chen
> > > wrote:
> > > >
> > > > +static inline void fstate_off(struct task_struct *task,
> > > > + struct pt_regs *regs)
> > > > +{
> > > > + regs->sstatus = (regs->sstatus & ~(SR_FS)) | SR_FS_OFF;
> > >
> > > The SR_FS_OFF is 0x0 so no need for ORing it.
> >
> > That one looks OK to me, since it makes it more obvious to humans what's
> > happening here - reviewers won't need to know that "off" is 0x0. The
> > compiler should drop it internally, so it won't affect the generated
> > code.
> >
> Thanks for Paul's comment
> My thought is the same as Paul.
>
>
> > > Apart from above minor comment, looks good to me.
> > >
> > > Reviewed-by: Anup Patel
> >
> > Will add your Reviewed-by: tag - let us know if you want me to drop it or
> > caveat it.
> >
> >
> > - Paul
>
> Dear Anup,
> I suppose you can accept our thought about using the SR_FS_OFF flag
> because I didn't receive any reply from you.
> Thanks for your review and comments.
No problem, go ahead without dropping SR_FS_OFF flag.
You can include my Reviewed-by.
Regards,
Anup
Re: [PATCH POC] printk_ringbuffer: Alternative implementation of lockless printk ringbuffer
Hi Petr,
FWIW, I hacked a patch against my RFCv4[0] series to implement your
POC. Some parts of the patch are not particularly pretty, as I had to
"mold" it to fit numlist usage. And I was extreme with heavy memory
barrier usage to save time. But it boots, runs, and passes all my printk
interface tests. It is all behind a PETRM_POC macro, so toggling between
the two implementations is quite simple.
I varied from your POC by having the sequence number be separate from
the id. We need 64-bit sequence numbers for all architectures, but since
there are cmpxchg() calls on the id, the id probably should remain an
unsigned long. That wasn't a problem to implement because my ringbuffer
implementation has them separate as well. It also has the benefit that
no sequence bits are sacrified for the state bits.
I would like to say that I am glad to see that this works. I was not
convinced that an array-based approach would work. And although I still
think it is too complex, it is not as bad as I expected.
Particularly interesting to note by the implementation is the use of
states. numlist.c:expire_oldest_node() provides the main piece of state
logic to handle the critical point of descriptor recycling. But also
note that readers (numlist.c:numlist_read()) need to watch for two
states (committed and reusable) as well as validating the data itself.
As for performance, my test_prb test module does not provide very good
results. On a 16-core ARM64 I usually only see about 10,000 to 1,000,000
records before a writer fails to reserve. The problem seems to be that a
writer has reserved but not yet committed a record and the descriptor
array has wrapped. With the array implementation this means no further
descriptors can be assigned until that writer has committed. So a new
writer has no choice but to fail.
With the linked list approach this problem is avoided because writers
simply remove a descriptor from the committed list. With it removed, it
is less critical how long that writer takes to commit because it is not
preventing other writers from removing descriptors from the committed
list.
To compare, with the linked list implementation, the test_prb test
module ran 14 days on a 16-core ARM64 machine before I manually stopped
the test. In that time the 15 writers wrote a total of 936,341,256,222
records (average of 735,408 per second). The single reader never lost
more than 29 consecutive records (having lost a total of 0.02% of the
records). Keep in mind all of this is using a 4KB ringbuffer.
It could be argued that the test_prb module (with its massive writing
and small ringbuffer) is unrealistic. However, I would still argue that
using a linked list to manage the committed records is a simpler, more
straight forward, more robust approach that is easier to understand and
maintain. I hope with the splitting of the linked list (numlist) into
separate source files, you will also see that it is not so complicated.
John Ogness
[0] https://lkml.kernel.org/r/20190807222634.1723-1-john.ogn...@linutronix.de
-- BEGIN PATCH -
diff --git a/kernel/printk/numlist.h b/kernel/printk/numlist.h
index d4595fb9a3e9..09535e3fb055 100644
--- a/kernel/printk/numlist.h
+++ b/kernel/printk/numlist.h
@@ -2,6 +2,7 @@
#ifndef _KERNEL_PRINTK_NUMLIST_H
#define _KERNEL_PRINTK_NUMLIST_H
+#define PETRM_POC
#include
@@ -69,4 +70,25 @@ unsigned long numlist_read_tail(struct numlist *nl, u64 *seq,
bool numlist_read(struct numlist *nl, unsigned long id, u64 *seq,
unsigned long *next_id);
+#ifdef PETRM_POC
+unsigned long prb_descs_count(struct numlist *nl);
+
+enum desc_state {
+ desc_miss,
+ desc_reserved,
+ desc_committed,
+ desc_reusable,
+};
+
+#define DESC_DST_BITS (sizeof(long) * 8)
+#define DESC_COMMITTED_MASK(1UL << (DESC_DST_BITS - 1))
+#define DESC_REUSE_MASK(1UL << (DESC_DST_BITS - 2))
+#define DESC_FLAGS_MASK(DESC_COMMITTED_MASK | DESC_REUSE_MASK)
+#define DESC_ID_MASK (~DESC_FLAGS_MASK)
+
+#define DESC_ID(id)((id) & DESC_ID_MASK)
+#define DESC_ID_PREV_WRAP(nl, id) \
+ DESC_ID(DESC_ID(id) - prb_descs_count(nl))
+#endif
+
#endif /* _KERNEL_PRINTK_NUMLIST_H */
diff --git a/kernel/printk/numlist.c b/kernel/printk/numlist.c
index 16c6ffa74b01..de3dbdfdb0a8 100644
--- a/kernel/printk/numlist.c
+++ b/kernel/printk/numlist.c
@@ -79,6 +79,27 @@
* Nodes can become invalid while being read by non-consuming readers.
*/
+#ifdef PETRM_POC
+unsigned long prb_desc_get_id(unsigned long id, void *arg);
+void prb_desc_set_id(unsigned long id, unsigned long new_id, void *arg);
+unsigned long prb_desc_cmpxchg_id(unsigned long id, unsigned long old_id,
+ unsigned long new_id, void *arg);
+
+enum desc_state get_desc_state(unsigned long id, unsigned long entry_state)
+{
+ if (id != (entry_state & DESC_ID_MASK))
+ return desc_miss;
+
+ if
[PATCH] nds32: Fix typo in Kconfig.cpu
This patch fixes some spelling typo in Kconfig.cpu Signed-off-by: Masanari Iida --- arch/nds32/Kconfig.cpu | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/arch/nds32/Kconfig.cpu b/arch/nds32/Kconfig.cpu index f80a4ab63da2..f88a12fdf0f3 100644 --- a/arch/nds32/Kconfig.cpu +++ b/arch/nds32/Kconfig.cpu @@ -13,7 +13,7 @@ config FPU default n help If FPU ISA is used in user space, this configuration shall be Y to - enable required support in kerenl such as fpu context switch and + enable required support in kernel such as fpu context switch and fpu exception handler. If no FPU ISA is used in user space, say N. @@ -27,7 +27,7 @@ config LAZY_FPU enhance system performance by reducing the context switch frequency of the FPU register. - For nomal case, say Y. + For normal case, say Y. config SUPPORT_DENORMAL_ARITHMETIC bool "Denormal arithmetic support" @@ -36,7 +36,7 @@ config SUPPORT_DENORMAL_ARITHMETIC help Say Y here to enable arithmetic of denormalized number. Enabling this feature can enhance the precision for tininess number. - However, performance loss in float pointe calculations is + However, performance loss in float point calculations is possibly significant due to additional FPU exception. If the calculated tolerance for tininess number is not critical, @@ -73,7 +73,7 @@ choice the cache aliasing issue. The rest cpus(N13, N10 and D10) are implemented as VIPT data cache. It may cause the cache aliasing issue if its cache way size is larger than page size. You can specify the - CPU type direcly or choose CPU_V3 if unsure. + CPU type directly or choose CPU_V3 if unsure. A kernel built for N10 is able to run on N15, D15, N13, N10 or D10. A kernel built for N15 is able to run on N15 or D15. -- 2.23.0.rc2
Re: [PATCH RFC v1 1/2] rcu/tree: Add basic support for kfree_rcu batching
On Tue, Aug 13, 2019 at 07:53:49PM -0700, Paul E. McKenney wrote: > On Wed, Aug 14, 2019 at 09:11:03AM +0900, Byungchul Park wrote: > > On Tue, Aug 13, 2019 at 08:41:45AM -0700, Paul E. McKenney wrote: > > > On Tue, Aug 13, 2019 at 02:29:54PM +0900, Byungchul Park wrote: > > > > On Mon, Aug 12, 2019 at 09:12:34AM -0400, Joel Fernandes wrote: > > > > > On Mon, Aug 12, 2019 at 07:10:52PM +0900, Byungchul Park wrote: > > > > > > On Sun, Aug 11, 2019 at 04:49:39PM -0700, Paul E. McKenney wrote: > > > > > > > Maybe. Note well that I said "potential issue". When I checked > > > > > > > a few > > > > > > > years ago, none of the uses of rcu_barrier() cared about > > > > > > > kfree_rcu(). > > > > > > > They cared instead about call_rcu() callbacks that accessed code > > > > > > > or data > > > > > > > that was going to disappear soon, for example, due to module > > > > > > > unload or > > > > > > > filesystem unmount. > > > > > > > > > > > > > > So it -might- be that rcu_barrier() can stay as it is, but with > > > > > > > changes > > > > > > > as needed to documentation. > > > > > > > > > > Right, we should update the docs. Byungchul, do you mind sending a > > > > > patch that > > > > > documents the rcu_barrier() behavior? > > > > > > > > Are you trying to give me the chance? I feel thankful. It doens't matter > > > > to try it at the moment though, I can't follow-up until September. I'd > > > > better do that in Septamber or give it up this time. > > > > > > Which reminds me... I recall your asking if the kfree_rcu() patch > > > might be sensitive to the exact hardware, but I cannot locate that > > > email right off-hand. This is an excellent question! When faced with > > > floods of kfree_rcu() calls, I would expect some hardware, compiler, > > > and kernel-configuration sensitivity. Which is why it will likely be > > > > Yes. > > > > > necessary to do a few more improvements over time -- for but one example, > > > accumulating callbacks into vectors in order to reduce the number of > > > kfree()-time cache misses. > > > > Yes. That would be a pretty good way to mitigate the problem. I hope > > the simple way we've done works well enough so it would never happen > > though. > > > > Or I would check the condition of all system resourses e.g. CPU and > > memory and control the bandwith of them, of course only if that actually > > happens. > > > > Thanks a lot for sharing your opinion on it! > > Didn't you say earlier that you were getting OOM on your system even > with the patches? Or did I miss the resolution of that issue? I said I saw OOM with a *larger* value of KFREE_DRAIN_JIFFIES. It was fine with the patch itself. Anyway I'm sorry I expressed it in a confusing way. Thanks, Byungchul > > Thanx, Paul > > > Thanks, > > Byungchul > > > > > Thanx, Paul > > > > > > > Thanks, > > > > Byungchul > > > > > > > > > > > It also -might- be, maybe now or maybe some time in the future, > > > > > > > that > > > > > > > there will need to be a kfree_rcu_barrier() or some such. But if > > > > > > > so, > > > > > > > let's not create it until it is needed. For one thing, it is > > > > > > > reasonably > > > > > > > likely that something other than a kfree_rcu_barrier() would > > > > > > > really > > > > > > > be what was needed. After all, the main point would be to make > > > > > > > sure > > > > > > > that the old memory really was freed before allocating new memory. > > > > > > > > > > > > Now I fully understand what you meant thanks to you. Thank you for > > > > > > explaining it in detail. > > > > > > > > > > > > > But if the system had ample memory, why wait? In that case you > > > > > > > don't > > > > > > > really need to wait for all the old memory to be freed, but > > > > > > > rather for > > > > > > > sufficient memory to be available for allocation. > > > > > > > > > > > > Agree. Totally make sense. > > > > > > > > > > Agreed, all makes sense. > > > > > > > > > > thanks, > > > > > > > > > > - Joel > > > > > > > > > > [snip] > > > > > >
Re: [PATCH 1/2] riscv: Add memmove string operation.
On Wed, Aug 14, 2019 at 10:22:15AM +0800, Paul Walmsley wrote: > On Tue, 13 Aug 2019, Palmer Dabbelt wrote: > > > On Mon, 12 Aug 2019 08:04:46 PDT (-0700), Christoph Hellwig wrote: > > > On Wed, Aug 07, 2019 at 03:19:14PM +0800, Nick Hu wrote: > > > > There are some features which need this string operation for > > > > compilation, > > > > like KASAN. So the purpose of this porting is for the features like > > > > KASAN > > > > which cannot be compiled without it. > > > > > > > > KASAN's string operations would replace the original string operations > > > > and > > > > call for the architecture defined string operations. Since we don't have > > > > this in current kernel, this patch provides the implementation. > > > > > > > > This porting refers to the 'arch/nds32/lib/memmove.S'. > > > > > > This looks sensible to me, although my stringop asm is rather rusty, > > > so just an ack and not a real review-by: > > > > > > Acked-by: Christoph Hellwig > > > > FWIW, we just write this in C everywhere else and rely on the compiler to > > unroll the loops. I always prefer C to assembly when possible, so I'd > > prefer > > if we just adopt the string code from newlib. We have a RISC-V-specific > > memcpy in there, but just use the generic memmove. > > > > Maybe the best bet here would be to adopt the newlib memcpy/memmove as > > generic > > Linux functions? They're both in C so they should be fine, and they both > > look > > faster than what's in lib/string.c. Then everyone would benefit and we > > don't > > need this tricky RISC-V assembly. Also, from the look of it the newlib code > > is faster because the inner loop is unrolled. > > There's a generic memmove implementation in the kernel already: > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/linux/string.h#n362 > > Nick, could you tell us more about why the generic memmove() isn't > suitable? > > > - Paul Hi Paul, KASAN has its own string operations(memcpy/memmove/memset) because it needs to hook some code to check memory region. It would undefined the original string operations and called the string operations with the prefix '__'. But the generic string operations didn't declare with the prefix. Other archs with KASAN support like arm64 and xtensa all have their own string operations and defined with the prefix. Nick
[PATCH] arm64: dts: qcom: qcs404-evb: Mark WCSS clocks protected
'7d0c76bdf227 ("clk: qcom: Add WCSS gcc clock control for QCS404")'
introduces two new clocks to gcc. These are not used before
clk_disable_unused() and as such the clock framework tries to disable
them.
But on the EVB these registers are only accessible through TrustZone, so
these clocks must be marked as "protected" to prevent the clock code
from touching them.
Numerical values are used as the constants are not yet available in a
common tree.
Reported-by: Mark Brown
Reported-by: Niklas Cassel
Signed-off-by: Bjorn Andersson
---
arch/arm64/boot/dts/qcom/qcs404-evb.dtsi | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/qcom/qcs404-evb.dtsi
b/arch/arm64/boot/dts/qcom/qcs404-evb.dtsi
index 2289b01ee9f0..501a7330dbc8 100644
--- a/arch/arm64/boot/dts/qcom/qcs404-evb.dtsi
+++ b/arch/arm64/boot/dts/qcom/qcs404-evb.dtsi
@@ -61,7 +61,9 @@
protected-clocks = ,
,
,
- ;
+ ,
+ <141>, /* GCC_WCSS_Q6_AHB_CLK */
+ <142>; /* GCC_WCSS_Q6_AXIM_CLK */
};
_spmi_regulators {
--
2.18.0
Re: [PATCH v5 08/18] thermal: sun8i: support mod clocks
On Tue, Aug 13, 2019 at 1:06 PM Ondřej Jirman wrote:
>
> On Mon, Aug 12, 2019 at 04:54:15PM -0700, Vasily Khoruzhick wrote:
> > On Mon, Aug 12, 2019 at 4:46 PM Frank Lee wrote:
> > >
> > > HI Vasily,
> > >
> > > On Sat, Aug 10, 2019 at 2:17 PM Vasily Khoruzhick
> > > wrote:
> > > >
> > > > On Fri, Aug 9, 2019 at 10:31 PM Yangtao Li
> > > > wrote:
> > > > >
> > > > > H3 has extra clock, so introduce something in
> > > > > ths_thermal_chip/ths_device
> > > > > and adds the process of the clock.
> > > > >
> > > > > This is pre-work for supprt it.
> > > > >
> > > > > Signed-off-by: Yangtao Li
> > > > > ---
> > > > > drivers/thermal/sun8i_thermal.c | 17 -
> > > > > 1 file changed, 16 insertions(+), 1 deletion(-)
> > > > >
> > > > > diff --git a/drivers/thermal/sun8i_thermal.c
> > > > > b/drivers/thermal/sun8i_thermal.c
> > > > > index b934bc81eba7..6f4294c2aba7 100644
> > > > > --- a/drivers/thermal/sun8i_thermal.c
> > > > > +++ b/drivers/thermal/sun8i_thermal.c
> > > > > @@ -54,6 +54,7 @@ struct tsensor {
> > > > > };
> > > > >
> > > > > struct ths_thermal_chip {
> > > > > + boolhas_mod_clk;
> > > > > int sensor_num;
> > > > > int offset;
> > > > > int scale;
> > > > > @@ -69,6 +70,7 @@ struct ths_device {
> > > > > struct regmap *regmap;
> > > > > struct reset_control*reset;
> > > > > struct clk *bus_clk;
> > > > > + struct clk *mod_clk;
> > > > > struct tsensor
> > > > > sensor[MAX_SENSOR_NUM];
> > > > > };
> > > > >
> > > > > @@ -274,6 +276,12 @@ static int sun8i_ths_resource_init(struct
> > > > > ths_device *tmdev)
> > > > > if (IS_ERR(tmdev->bus_clk))
> > > > > return PTR_ERR(tmdev->bus_clk);
> > > > >
> > > > > + if (tmdev->chip->has_mod_clk) {
> > > > > + tmdev->mod_clk = devm_clk_get(>dev, "mod");
> > > > > + if (IS_ERR(tmdev->mod_clk))
> > > > > + return PTR_ERR(tmdev->mod_clk);
> > > > > + }
> > > > > +
> > > > > ret = reset_control_deassert(tmdev->reset);
> > > > > if (ret)
> > > > > return ret;
> > > > > @@ -282,12 +290,18 @@ static int sun8i_ths_resource_init(struct
> > > > > ths_device *tmdev)
> > > > > if (ret)
> > > > > goto assert_reset;
> > > > >
> > > > > - ret = sun50i_ths_calibrate(tmdev);
> > > > > + ret = clk_prepare_enable(tmdev->mod_clk);
> > > >
> > > > You have to set rate of modclk before enabling it since you can't rely
> > > > on whatever bootloader left for you.
> > > >
> > > > Also I found that parameters you're using for PC_TEMP_PERIOD, ACQ0 and
> > > > ACQ1 are too aggressive and may result in high interrupt rate to the
> > > > point when it may stall RCU. I changed driver a bit to use params from
> > > > Philipp Rossak's work (modclk set to 4MHz, PC_TEMP_PERIOD is 7, ACQ0
> > > > is 255, ACQ1 is 63) and it fixed RCU stalls for me, see [1] for
> > > > details.
> > >
> > > Why is the RCU stall happening, is it caused by a deadlock?
> > > Can you provide log information and your configuration?
> > > I am a bit curious.
> >
> > It's not deadlock, I believe it just can't handle that many interrupts
> > when running at lowest CPU frequency. Even with Philipp's settings
> > there's ~20 interrupts a second from ths. I don't remember how many
> > interrupts were there with your settings.
> >
> > Unfortunately there's nothing interesting in backtraces, I'm using
> > Pine64-LTS board.
>
> Recently there was a similar issue, with buggy CCU driver that caused
> CIR interrupts being fired constantly, and it also resulted in RCU
> stalls. Looks like a comon cause of RCU stalls.
>
> THS timing settings probably need to be made specific to the SoC, because
> I noticed that the same settings lead to wildly different timings on
> different SoCs.
>
> It would be good to measure how often ths interrupt fires with this driver
> on various SoCs.
>
> 20 times a second and more sounds like overkill. I'd expect a useful
> range to be at most 5-10 times a second. That should be enough to stop
> overheating the SoC due to suddenly increased load, even without a
> heatsink.
Note that A64 has 3 sensors and each sensor has individual interrupt,
so technically it's 6-7 interrupts per sensor per second
> regards,
> o.
>
> > > Thx,
> > > Yangtao
> > >
> > > >
> > > > [1]
> > > > https://github.com/anarsoul/linux-2.6/commit/46b8bb0fe2ccd1cd88fa9181a2ecbf79e8d513b2
> > > >
> > > >
> > > > > if (ret)
> > > > > goto bus_disable;
> > > > >
> > > > > + ret = sun50i_ths_calibrate(tmdev);
> > > > > + if (ret)
> > > > > + goto mod_disable;
> > > > > +
> > > > > return 0;
> > > > >
> > > > > +mod_disable:
> > > > > +
Re: [PATCH RFC v1 1/2] rcu/tree: Add basic support for kfree_rcu batching
On Wed, Aug 14, 2019 at 09:11:03AM +0900, Byungchul Park wrote: > On Tue, Aug 13, 2019 at 08:41:45AM -0700, Paul E. McKenney wrote: > > On Tue, Aug 13, 2019 at 02:29:54PM +0900, Byungchul Park wrote: > > > On Mon, Aug 12, 2019 at 09:12:34AM -0400, Joel Fernandes wrote: > > > > On Mon, Aug 12, 2019 at 07:10:52PM +0900, Byungchul Park wrote: > > > > > On Sun, Aug 11, 2019 at 04:49:39PM -0700, Paul E. McKenney wrote: > > > > > > Maybe. Note well that I said "potential issue". When I checked a > > > > > > few > > > > > > years ago, none of the uses of rcu_barrier() cared about > > > > > > kfree_rcu(). > > > > > > They cared instead about call_rcu() callbacks that accessed code or > > > > > > data > > > > > > that was going to disappear soon, for example, due to module unload > > > > > > or > > > > > > filesystem unmount. > > > > > > > > > > > > So it -might- be that rcu_barrier() can stay as it is, but with > > > > > > changes > > > > > > as needed to documentation. > > > > > > > > Right, we should update the docs. Byungchul, do you mind sending a > > > > patch that > > > > documents the rcu_barrier() behavior? > > > > > > Are you trying to give me the chance? I feel thankful. It doens't matter > > > to try it at the moment though, I can't follow-up until September. I'd > > > better do that in Septamber or give it up this time. > > > > Which reminds me... I recall your asking if the kfree_rcu() patch > > might be sensitive to the exact hardware, but I cannot locate that > > email right off-hand. This is an excellent question! When faced with > > floods of kfree_rcu() calls, I would expect some hardware, compiler, > > and kernel-configuration sensitivity. Which is why it will likely be > > Yes. > > > necessary to do a few more improvements over time -- for but one example, > > accumulating callbacks into vectors in order to reduce the number of > > kfree()-time cache misses. > > Yes. That would be a pretty good way to mitigate the problem. I hope > the simple way we've done works well enough so it would never happen > though. > > Or I would check the condition of all system resourses e.g. CPU and > memory and control the bandwith of them, of course only if that actually > happens. > > Thanks a lot for sharing your opinion on it! Didn't you say earlier that you were getting OOM on your system even with the patches? Or did I miss the resolution of that issue? Thanx, Paul > Thanks, > Byungchul > > > Thanx, Paul > > > > > Thanks, > > > Byungchul > > > > > > > > > It also -might- be, maybe now or maybe some time in the future, that > > > > > > there will need to be a kfree_rcu_barrier() or some such. But if > > > > > > so, > > > > > > let's not create it until it is needed. For one thing, it is > > > > > > reasonably > > > > > > likely that something other than a kfree_rcu_barrier() would really > > > > > > be what was needed. After all, the main point would be to make sure > > > > > > that the old memory really was freed before allocating new memory. > > > > > > > > > > Now I fully understand what you meant thanks to you. Thank you for > > > > > explaining it in detail. > > > > > > > > > > > But if the system had ample memory, why wait? In that case you > > > > > > don't > > > > > > really need to wait for all the old memory to be freed, but rather > > > > > > for > > > > > > sufficient memory to be available for allocation. > > > > > > > > > > Agree. Totally make sense. > > > > > > > > Agreed, all makes sense. > > > > > > > > thanks, > > > > > > > > - Joel > > > > > > > > [snip] > > > >
Re: [PATCH V38 15/29] acpi: Ignore acpi_rsdp kernel param when the kernel has been locked down
On 08/07/19 at 05:07pm, Matthew Garrett wrote:
> From: Josh Boyer
>
> This option allows userspace to pass the RSDP address to the kernel, which
> makes it possible for a user to modify the workings of hardware. Reject
> the option when the kernel is locked down. This requires some reworking
> of the existing RSDP command line logic, since the early boot code also
> makes use of a command-line passed RSDP when locating the SRAT table
> before the lockdown code has been initialised. This is achieved by
> separating the command line RSDP path in the early boot code from the
> generic RSDP path, and then copying the command line RSDP into boot
> params in the kernel proper if lockdown is not enabled. If lockdown is
> enabled and an RSDP is provided on the command line, this will only be
> used when parsing SRAT (which shouldn't permit kernel code execution)
> and will be ignored in the rest of the kernel.
>
> (Modified by Matthew Garrett in order to handle the early boot RSDP
> environment)
>
> Signed-off-by: Josh Boyer
> Signed-off-by: David Howells
> Signed-off-by: Matthew Garrett
> Reviewed-by: Kees Cook
> cc: Dave Young
> cc: linux-a...@vger.kernel.org
> ---
> arch/x86/boot/compressed/acpi.c | 19 +--
> arch/x86/include/asm/acpi.h | 9 +
> arch/x86/include/asm/x86_init.h | 2 ++
> arch/x86/kernel/acpi/boot.c | 5 +
> arch/x86/kernel/x86_init.c | 1 +
> drivers/acpi/osl.c | 14 +-
> include/linux/acpi.h| 6 ++
> 7 files changed, 49 insertions(+), 7 deletions(-)
>
> diff --git a/arch/x86/boot/compressed/acpi.c b/arch/x86/boot/compressed/acpi.c
> index 15255f388a85..149795c369f2 100644
> --- a/arch/x86/boot/compressed/acpi.c
> +++ b/arch/x86/boot/compressed/acpi.c
> @@ -26,7 +26,7 @@ struct mem_vector immovable_mem[MAX_NUMNODES*2];
> */
> #define MAX_ADDR_LEN 19
>
> -static acpi_physical_address get_acpi_rsdp(void)
> +static acpi_physical_address get_cmdline_acpi_rsdp(void)
> {
> acpi_physical_address addr = 0;
>
> @@ -278,10 +278,7 @@ acpi_physical_address get_rsdp_addr(void)
> {
> acpi_physical_address pa;
>
> - pa = get_acpi_rsdp();
> -
> - if (!pa)
> - pa = boot_params->acpi_rsdp_addr;
> + pa = boot_params->acpi_rsdp_addr;
>
> /*
>* Try to get EFI data from setup_data. This can happen when we're a
> @@ -311,7 +308,17 @@ static unsigned long get_acpi_srat_table(void)
> char arg[10];
> u8 *entry;
>
> - rsdp = (struct acpi_table_rsdp *)(long)boot_params->acpi_rsdp_addr;
> + /*
> + * Check whether we were given an RSDP on the command line. We don't
> + * stash this in boot params because the kernel itself may have
> + * different ideas about whether to trust a command-line parameter.
> + */
> + rsdp = (struct acpi_table_rsdp *)get_cmdline_acpi_rsdp();
> +
> + if (!rsdp)
> + rsdp = (struct acpi_table_rsdp *)(long)
> + boot_params->acpi_rsdp_addr;
> +
> if (!rsdp)
> return 0;
>
> diff --git a/arch/x86/include/asm/acpi.h b/arch/x86/include/asm/acpi.h
> index aac686e1e005..bc9693c9107e 100644
> --- a/arch/x86/include/asm/acpi.h
> +++ b/arch/x86/include/asm/acpi.h
> @@ -117,6 +117,12 @@ static inline bool acpi_has_cpu_in_madt(void)
> return !!acpi_lapic;
> }
>
> +#define ACPI_HAVE_ARCH_SET_ROOT_POINTER
> +static inline void acpi_arch_set_root_pointer(u64 addr)
> +{
> + x86_init.acpi.set_root_pointer(addr);
> +}
> +
> #define ACPI_HAVE_ARCH_GET_ROOT_POINTER
> static inline u64 acpi_arch_get_root_pointer(void)
> {
> @@ -125,6 +131,7 @@ static inline u64 acpi_arch_get_root_pointer(void)
>
> void acpi_generic_reduced_hw_init(void);
>
> +void x86_default_set_root_pointer(u64 addr);
> u64 x86_default_get_root_pointer(void);
>
> #else /* !CONFIG_ACPI */
> @@ -138,6 +145,8 @@ static inline void disable_acpi(void) { }
>
> static inline void acpi_generic_reduced_hw_init(void) { }
>
> +static inline void x86_default_set_root_pointer(u64 addr) { }
> +
> static inline u64 x86_default_get_root_pointer(void)
> {
> return 0;
> diff --git a/arch/x86/include/asm/x86_init.h b/arch/x86/include/asm/x86_init.h
> index ac0934189017..19435858df5f 100644
> --- a/arch/x86/include/asm/x86_init.h
> +++ b/arch/x86/include/asm/x86_init.h
> @@ -134,10 +134,12 @@ struct x86_hyper_init {
>
> /**
> * struct x86_init_acpi - x86 ACPI init functions
> + * @set_root_poitner:set RSDP address
> * @get_root_pointer:get RSDP address
> * @reduced_hw_early_init: hardware reduced platform early init
> */
> struct x86_init_acpi {
> + void (*set_root_pointer)(u64 addr);
> u64 (*get_root_pointer)(void);
> void (*reduced_hw_early_init)(void);
> };
> diff --git a/arch/x86/kernel/acpi/boot.c b/arch/x86/kernel/acpi/boot.c
> index 17b33ef604f3..04205ce127a1 100644
> --- a/arch/x86/kernel/acpi/boot.c
> +++
Re: [PATCH v2] net/mlx4_en: fix a memory leak bug
On Mon, 12 Aug 2019 14:11:35 -0500, Wenwen Wang wrote:
> In mlx4_en_config_rss_steer(), 'rss_map->indir_qp' is allocated through
> kzalloc(). After that, mlx4_qp_alloc() is invoked to configure RSS
> indirection. However, if mlx4_qp_alloc() fails, the allocated
> 'rss_map->indir_qp' is not deallocated, leading to a memory leak bug.
>
> To fix the above issue, add the 'qp_alloc_err' label to free
> 'rss_map->indir_qp'.
>
> Fixes: 4931c6ef04b4 ("net/mlx4_en: Optimized single ring steering")
> Signed-off-by: Wenwen Wang
Applied, thanks.
[PATCH AUTOSEL 5.2 005/123] ASoC: audio-graph-card: fix an use-after-free in graph_get_dai_id()
From: Wen Yang
[ Upstream commit c152f8491a8d9a4b25afd65a86eb5e55e2a8c380 ]
After calling of_node_put() on the node variable, it is still being
used, which may result in use-after-free.
Fix this issue by calling of_node_put() after the last usage.
Fixes: a0c426fe1433 ("ASoC: simple-card-utils: check "reg" property on
asoc_simple_card_get_dai_id()")
Link:
https://lore.kernel.org/r/1562743509-30496-5-git-send-email-wen.yan...@zte.com.cn
Signed-off-by: Wen Yang
Acked-by: Kuninori Morimoto
Signed-off-by: Mark Brown
Signed-off-by: Sasha Levin
---
sound/soc/generic/audio-graph-card.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/sound/soc/generic/audio-graph-card.c
b/sound/soc/generic/audio-graph-card.c
index d5188a179378f..a681ea443fc16 100644
--- a/sound/soc/generic/audio-graph-card.c
+++ b/sound/soc/generic/audio-graph-card.c
@@ -63,6 +63,7 @@ static int graph_get_dai_id(struct device_node *ep)
struct device_node *endpoint;
struct of_endpoint info;
int i, id;
+ u32 *reg;
int ret;
/* use driver specified DAI ID if exist */
@@ -83,8 +84,9 @@ static int graph_get_dai_id(struct device_node *ep)
return info.id;
node = of_get_parent(ep);
+ reg = of_get_property(node, "reg", NULL);
of_node_put(node);
- if (of_get_property(node, "reg", NULL))
+ if (reg)
return info.port;
}
node = of_graph_get_port_parent(ep);
--
2.20.1
[PATCH AUTOSEL 5.2 010/123] iio: imu: mpu6050: add missing available scan masks
From: Jean-Baptiste Maneyrol
[ Upstream commit 1244a720572fd1680ac8d6b8a4235f2e8557b810 ]
Driver only supports 3-axis gyro and/or 3-axis accel.
For icm20602, temp data is mandatory for all configurations.
Fix all single and double axis configurations (almost never used) and more
importantly fix 3-axis gyro and 6-axis accel+gyro buffer on icm20602 when
temp data is not enabled.
Signed-off-by: Jean-Baptiste Maneyrol
Fixes: 1615fe41a195 ("iio: imu: mpu6050: Fix FIFO layout for ICM20602")
Cc:
Signed-off-by: Jonathan Cameron
Signed-off-by: Sasha Levin
---
drivers/iio/imu/inv_mpu6050/inv_mpu_core.c | 43 ++
1 file changed, 43 insertions(+)
diff --git a/drivers/iio/imu/inv_mpu6050/inv_mpu_core.c
b/drivers/iio/imu/inv_mpu6050/inv_mpu_core.c
index 53a59957cc542..8a704cd5bddb7 100644
--- a/drivers/iio/imu/inv_mpu6050/inv_mpu_core.c
+++ b/drivers/iio/imu/inv_mpu6050/inv_mpu_core.c
@@ -845,6 +845,25 @@ static const struct iio_chan_spec inv_mpu_channels[] = {
INV_MPU6050_CHAN(IIO_ACCEL, IIO_MOD_Z, INV_MPU6050_SCAN_ACCL_Z),
};
+static const unsigned long inv_mpu_scan_masks[] = {
+ /* 3-axis accel */
+ BIT(INV_MPU6050_SCAN_ACCL_X)
+ | BIT(INV_MPU6050_SCAN_ACCL_Y)
+ | BIT(INV_MPU6050_SCAN_ACCL_Z),
+ /* 3-axis gyro */
+ BIT(INV_MPU6050_SCAN_GYRO_X)
+ | BIT(INV_MPU6050_SCAN_GYRO_Y)
+ | BIT(INV_MPU6050_SCAN_GYRO_Z),
+ /* 6-axis accel + gyro */
+ BIT(INV_MPU6050_SCAN_ACCL_X)
+ | BIT(INV_MPU6050_SCAN_ACCL_Y)
+ | BIT(INV_MPU6050_SCAN_ACCL_Z)
+ | BIT(INV_MPU6050_SCAN_GYRO_X)
+ | BIT(INV_MPU6050_SCAN_GYRO_Y)
+ | BIT(INV_MPU6050_SCAN_GYRO_Z),
+ 0,
+};
+
static const struct iio_chan_spec inv_icm20602_channels[] = {
IIO_CHAN_SOFT_TIMESTAMP(INV_ICM20602_SCAN_TIMESTAMP),
{
@@ -871,6 +890,28 @@ static const struct iio_chan_spec inv_icm20602_channels[]
= {
INV_MPU6050_CHAN(IIO_ACCEL, IIO_MOD_Z, INV_ICM20602_SCAN_ACCL_Z),
};
+static const unsigned long inv_icm20602_scan_masks[] = {
+ /* 3-axis accel + temp (mandatory) */
+ BIT(INV_ICM20602_SCAN_ACCL_X)
+ | BIT(INV_ICM20602_SCAN_ACCL_Y)
+ | BIT(INV_ICM20602_SCAN_ACCL_Z)
+ | BIT(INV_ICM20602_SCAN_TEMP),
+ /* 3-axis gyro + temp (mandatory) */
+ BIT(INV_ICM20602_SCAN_GYRO_X)
+ | BIT(INV_ICM20602_SCAN_GYRO_Y)
+ | BIT(INV_ICM20602_SCAN_GYRO_Z)
+ | BIT(INV_ICM20602_SCAN_TEMP),
+ /* 6-axis accel + gyro + temp (mandatory) */
+ BIT(INV_ICM20602_SCAN_ACCL_X)
+ | BIT(INV_ICM20602_SCAN_ACCL_Y)
+ | BIT(INV_ICM20602_SCAN_ACCL_Z)
+ | BIT(INV_ICM20602_SCAN_GYRO_X)
+ | BIT(INV_ICM20602_SCAN_GYRO_Y)
+ | BIT(INV_ICM20602_SCAN_GYRO_Z)
+ | BIT(INV_ICM20602_SCAN_TEMP),
+ 0,
+};
+
/*
* The user can choose any frequency between INV_MPU6050_MIN_FIFO_RATE and
* INV_MPU6050_MAX_FIFO_RATE, but only these frequencies are matched by the
@@ -1130,9 +1171,11 @@ int inv_mpu_core_probe(struct regmap *regmap, int irq,
const char *name,
if (chip_type == INV_ICM20602) {
indio_dev->channels = inv_icm20602_channels;
indio_dev->num_channels = ARRAY_SIZE(inv_icm20602_channels);
+ indio_dev->available_scan_masks = inv_icm20602_scan_masks;
} else {
indio_dev->channels = inv_mpu_channels;
indio_dev->num_channels = ARRAY_SIZE(inv_mpu_channels);
+ indio_dev->available_scan_masks = inv_mpu_scan_masks;
}
indio_dev->info = _info;
--
2.20.1
[PATCH AUTOSEL 5.2 007/123] iio: adc: max9611: Fix misuse of GENMASK macro
From: Joe Perches
[ Upstream commit ae8cc91a7d85e018c0c267f580820b2bb558cd48 ]
Arguments are supposed to be ordered high then low.
Signed-off-by: Joe Perches
Fixes: 69780a3bbc0b ("iio: adc: Add Maxim max9611 ADC driver")
Cc:
Signed-off-by: Jonathan Cameron
Signed-off-by: Sasha Levin
---
drivers/iio/adc/max9611.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/iio/adc/max9611.c b/drivers/iio/adc/max9611.c
index 917223d5ff5bb..0e3c6529fc4c9 100644
--- a/drivers/iio/adc/max9611.c
+++ b/drivers/iio/adc/max9611.c
@@ -83,7 +83,7 @@
#define MAX9611_TEMP_MAX_POS 0x7f80
#define MAX9611_TEMP_MAX_NEG 0xff80
#define MAX9611_TEMP_MIN_NEG 0xd980
-#define MAX9611_TEMP_MASK GENMASK(7, 15)
+#define MAX9611_TEMP_MASK GENMASK(15, 7)
#define MAX9611_TEMP_SHIFT 0x07
#define MAX9611_TEMP_RAW(_r) ((_r) >> MAX9611_TEMP_SHIFT)
#define MAX9611_TEMP_SCALE_NUM 100
--
2.20.1
[PATCH AUTOSEL 5.2 012/123] regulator: axp20x: fix DCDC5 and DCDC6 for AXP803
From: Jernej Skrabec
[ Upstream commit 8f46e22b5ac692b48d04bb722547ca17b66dda02 ]
Refactoring of axp20x driver introduced a bug in AXP803's DCDC6
regulator definition. AXP803_DCDC6_1120mV_STEPS was obtained by
subtracting 0x47 and 0x33. This should be 0x14 (hex) and not 14
(dec).
Refactoring also carried over a bug in DCDC5 regulator definition.
Number of possible voltages must be for 1 bigger than maximum valid
voltage index, because 0 is also valid and it means lowest voltage.
Fixes: 1dbe0ccb0631 ("regulator: axp20x-regulator: add support for AXP803")
Fixes: db4a555f7c4c ("regulator: axp20x: use defines for masks")
Signed-off-by: Jernej Skrabec
Link: https://lore.kernel.org/r/20190713090717.347-3-jernej.skra...@siol.net
Signed-off-by: Mark Brown
Signed-off-by: Sasha Levin
---
drivers/regulator/axp20x-regulator.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/regulator/axp20x-regulator.c
b/drivers/regulator/axp20x-regulator.c
index c951568994a11..989506bd90b19 100644
--- a/drivers/regulator/axp20x-regulator.c
+++ b/drivers/regulator/axp20x-regulator.c
@@ -174,14 +174,14 @@
#define AXP803_DCDC5_1140mV_STEPS 35
#define AXP803_DCDC5_1140mV_END\
(AXP803_DCDC5_1140mV_START + AXP803_DCDC5_1140mV_STEPS)
-#define AXP803_DCDC5_NUM_VOLTAGES 68
+#define AXP803_DCDC5_NUM_VOLTAGES 69
#define AXP803_DCDC6_600mV_START 0x00
#define AXP803_DCDC6_600mV_STEPS 50
#define AXP803_DCDC6_600mV_END \
(AXP803_DCDC6_600mV_START + AXP803_DCDC6_600mV_STEPS)
#define AXP803_DCDC6_1120mV_START 0x33
-#define AXP803_DCDC6_1120mV_STEPS 14
+#define AXP803_DCDC6_1120mV_STEPS 20
#define AXP803_DCDC6_1120mV_END\
(AXP803_DCDC6_1120mV_START + AXP803_DCDC6_1120mV_STEPS)
#define AXP803_DCDC6_NUM_VOLTAGES 72
--
2.20.1
[PATCH AUTOSEL 5.2 004/123] ASoC: audio-graph-card: fix use-after-free in graph_dai_link_of_dpcm()
From: Wen Yang
[ Upstream commit aa2e362cb6b3f5ca88093ada01e1a0ace8a517b2 ]
After calling of_node_put() on the ports, port, and node variables,
they are still being used, which may result in use-after-free.
Fix this issue by calling of_node_put() after the last usage.
Fixes: dd98fbc558a0 ("ASoC: audio-graph-card: cleanup DAI link loop method -
step1")
Link:
https://lore.kernel.org/r/1562743509-30496-4-git-send-email-wen.yan...@zte.com.cn
Signed-off-by: Wen Yang
Acked-by: Kuninori Morimoto
Signed-off-by: Mark Brown
Signed-off-by: Sasha Levin
---
sound/soc/generic/audio-graph-card.c | 26 +-
1 file changed, 13 insertions(+), 13 deletions(-)
diff --git a/sound/soc/generic/audio-graph-card.c
b/sound/soc/generic/audio-graph-card.c
index 70ed28d97d497..d5188a179378f 100644
--- a/sound/soc/generic/audio-graph-card.c
+++ b/sound/soc/generic/audio-graph-card.c
@@ -222,10 +222,6 @@ static int graph_dai_link_of_dpcm(struct asoc_simple_priv
*priv,
dev_dbg(dev, "link_of DPCM (%pOF)\n", ep);
- of_node_put(ports);
- of_node_put(port);
- of_node_put(node);
-
if (li->cpu) {
int is_single_links = 0;
@@ -243,17 +239,17 @@ static int graph_dai_link_of_dpcm(struct asoc_simple_priv
*priv,
ret = asoc_simple_parse_cpu(ep, dai_link, _single_links);
if (ret)
- return ret;
+ goto out_put_node;
ret = asoc_simple_parse_clk_cpu(dev, ep, dai_link, dai);
if (ret < 0)
- return ret;
+ goto out_put_node;
ret = asoc_simple_set_dailink_name(dev, dai_link,
"fe.%s",
dai_link->cpu_dai_name);
if (ret < 0)
- return ret;
+ goto out_put_node;
/* card->num_links includes Codec */
asoc_simple_canonicalize_cpu(dai_link, is_single_links);
@@ -277,17 +273,17 @@ static int graph_dai_link_of_dpcm(struct asoc_simple_priv
*priv,
ret = asoc_simple_parse_codec(ep, dai_link);
if (ret < 0)
- return ret;
+ goto out_put_node;
ret = asoc_simple_parse_clk_codec(dev, ep, dai_link, dai);
if (ret < 0)
- return ret;
+ goto out_put_node;
ret = asoc_simple_set_dailink_name(dev, dai_link,
"be.%s",
codecs->dai_name);
if (ret < 0)
- return ret;
+ goto out_put_node;
/* check "prefix" from top node */
snd_soc_of_parse_node_prefix(top, cconf, codecs->of_node,
@@ -307,19 +303,23 @@ static int graph_dai_link_of_dpcm(struct asoc_simple_priv
*priv,
ret = asoc_simple_parse_tdm(ep, dai);
if (ret)
- return ret;
+ goto out_put_node;
ret = asoc_simple_parse_daifmt(dev, cpu_ep, codec_ep,
NULL, _link->dai_fmt);
if (ret < 0)
- return ret;
+ goto out_put_node;
dai_link->dpcm_playback = 1;
dai_link->dpcm_capture = 1;
dai_link->ops = _ops;
dai_link->init = asoc_simple_dai_init;
- return 0;
+out_put_node:
+ of_node_put(ports);
+ of_node_put(port);
+ of_node_put(node);
+ return ret;
}
static int graph_dai_link_of(struct asoc_simple_priv *priv,
--
2.20.1
Re: [PATCH linux-next] drivers: dma: Fix sparse warning for mux_configure32
On 2019/8/13 12:43, Vinod Koul wrote:
> On 12-08-19, 15:42, Mao Wenan wrote:
>
> Patch title is incorrect, it should mention the changes in patch, for
> example make mux_configure32 static
>
> Do read up on Documentation/process/submitting-patches.rst again!
>
>> There is one sparse warning in drivers/dma/fsl-edma-common.c,
>
> It will help to explain the warning before the fix
>
>> fix it by setting mux_configure32() as static.
>>
>> make allmodconfig ARCH=mips CROSS_COMPILE=mips-linux-gnu-
>> make C=2 drivers/dma/fsl-edma-common.o ARCH=mips
>> CROSS_COMPILE=mips-linux-gnu-
>
> Make cmds are not relevant for the log
>
>> drivers/dma/fsl-edma-common.c:93:6: warning: symbol 'mux_configure32' was
>> not declared. Should it be static?
>
> This one is and should be retained
>
>>
>> Fixes: 232a7f18cf8ec ("dmaengine: fsl-edma: add i.mx7ulp edma2 version
>> support")
>> Signed-off-by: Mao Wenan
>> ---
>> drivers/dma/fsl-edma-common.c | 4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/dma/fsl-edma-common.c b/drivers/dma/fsl-edma-common.c
>> index 6d6d8a4..7dbf7df 100644
>> --- a/drivers/dma/fsl-edma-common.c
>> +++ b/drivers/dma/fsl-edma-common.c
>> @@ -90,8 +90,8 @@ static void mux_configure8(struct fsl_edma_chan *fsl_chan,
>> void __iomem *addr,
>> iowrite8(val8, addr + off);
>> }
>>
>> -void mux_configure32(struct fsl_edma_chan *fsl_chan, void __iomem *addr,
>> - u32 off, u32 slot, bool enable)
>> +static void mux_configure32(struct fsl_edma_chan *fsl_chan, void __iomem
>> *addr,
>
> just change this to static
>
>> +u32 off, u32 slot, bool enable)
>
> and dont change anything else.
>
> If you feel to change this, propose a new patch for this line explaining
> why this should be changed
thanks, I will send v2.
>
>> {
>> u32 val;
>>
>> --
>> 2.7.4
>
[PATCH AUTOSEL 5.2 029/123] ASoC: dapm: fix a memory leak bug
From: Wenwen Wang [ Upstream commit 45004d66f2a28d78f543fb2ffbc133e31dc2d162 ] In snd_soc_dapm_new_control_unlocked(), a kernel buffer is allocated in dapm_cnew_widget() to hold the new dapm widget. Then, different actions are taken according to the id of the widget, i.e., 'w->id'. If any failure occurs during this process, snd_soc_dapm_new_control_unlocked() should be terminated by going to the 'request_failed' label. However, the allocated kernel buffer is not freed on this code path, leading to a memory leak bug. To fix the above issue, free the buffer before returning from snd_soc_dapm_new_control_unlocked() through the 'request_failed' label. Signed-off-by: Wenwen Wang Link: https://lore.kernel.org/r/1563803864-2809-1-git-send-email-wang6...@umn.edu Signed-off-by: Mark Brown Signed-off-by: Sasha Levin --- sound/soc/soc-dapm.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/sound/soc/soc-dapm.c b/sound/soc/soc-dapm.c index 835ce1ff188d9..f40adb604c25b 100644 --- a/sound/soc/soc-dapm.c +++ b/sound/soc/soc-dapm.c @@ -3705,6 +3705,8 @@ snd_soc_dapm_new_control_unlocked(struct snd_soc_dapm_context *dapm, dev_err(dapm->dev, "ASoC: Failed to request %s: %d\n", w->name, ret); + kfree_const(w->sname); + kfree(w); return ERR_PTR(ret); } -- 2.20.1
[PATCH AUTOSEL 5.2 017/123] HID: Add 044f:b320 ThrustMaster, Inc. 2 in 1 DT
From: Ilya Trukhanov
[ Upstream commit 65f11c72780fa9d598df88def045ccb6a885cf80 ]
Enable force feedback for the Thrustmaster Dual Trigger 2 in 1 Rumble Force
gamepad. Compared to other Thrustmaster devices, left and right rumble
motors here are swapped.
Signed-off-by: Ilya Trukhanov
Signed-off-by: Jiri Kosina
Signed-off-by: Sasha Levin
---
drivers/hid/hid-tmff.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/hid/hid-tmff.c b/drivers/hid/hid-tmff.c
index e12f2588ddebb..bdfc5ff3b2c5c 100644
--- a/drivers/hid/hid-tmff.c
+++ b/drivers/hid/hid-tmff.c
@@ -22,6 +22,8 @@
#include "hid-ids.h"
+#define THRUSTMASTER_DEVICE_ID_2_IN_1_DT 0xb320
+
static const signed short ff_rumble[] = {
FF_RUMBLE,
-1
@@ -76,6 +78,7 @@ static int tmff_play(struct input_dev *dev, void *data,
struct hid_field *ff_field = tmff->ff_field;
int x, y;
int left, right;/* Rumbling */
+ int motor_swap;
switch (effect->type) {
case FF_CONSTANT:
@@ -100,6 +103,13 @@ static int tmff_play(struct input_dev *dev, void *data,
ff_field->logical_minimum,
ff_field->logical_maximum);
+ /* 2-in-1 strong motor is left */
+ if (hid->product == THRUSTMASTER_DEVICE_ID_2_IN_1_DT) {
+ motor_swap = left;
+ left = right;
+ right = motor_swap;
+ }
+
dbg_hid("(left,right)=(%08x, %08x)\n", left, right);
ff_field->value[0] = left;
ff_field->value[1] = right;
@@ -226,6 +236,8 @@ static const struct hid_device_id tm_devices[] = {
.driver_data = (unsigned long)ff_rumble },
{ HID_USB_DEVICE(USB_VENDOR_ID_THRUSTMASTER, 0xb304), /* FireStorm
Dual Power 2 (and 3) */
.driver_data = (unsigned long)ff_rumble },
+ { HID_USB_DEVICE(USB_VENDOR_ID_THRUSTMASTER,
THRUSTMASTER_DEVICE_ID_2_IN_1_DT), /* Dual Trigger 2-in-1 */
+ .driver_data = (unsigned long)ff_rumble },
{ HID_USB_DEVICE(USB_VENDOR_ID_THRUSTMASTER, 0xb323), /* Dual Trigger
3-in-1 (PC Mode) */
.driver_data = (unsigned long)ff_rumble },
{ HID_USB_DEVICE(USB_VENDOR_ID_THRUSTMASTER, 0xb324), /* Dual Trigger
3-in-1 (PS3 Mode) */
--
2.20.1
[PATCH AUTOSEL 5.2 024/123] spi: pxa2xx: Balance runtime PM enable/disable on error
From: Lubomir Rintel
[ Upstream commit 1274204542f683e1d8491ebe9cc86284d5a8ebcc ]
Don't undo the PM initialization if we error out before we managed to
initialize it. The call to pm_runtime_disable() without being preceded
by pm_runtime_enable() would disturb the balance of the Force.
In practice, this happens if we fail to allocate any of the GPIOS ("cs",
"ready") due to -EPROBE_DEFER because we're getting probled before the
GPIO driver.
Signed-off-by: Lubomir Rintel
Link: https://lore.kernel.org/r/20190719122713.3444318-1-lkund...@v3.sk
Signed-off-by: Mark Brown
Signed-off-by: Sasha Levin
---
drivers/spi/spi-pxa2xx.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/spi/spi-pxa2xx.c b/drivers/spi/spi-pxa2xx.c
index af3f37ba82c83..c1af8887d9186 100644
--- a/drivers/spi/spi-pxa2xx.c
+++ b/drivers/spi/spi-pxa2xx.c
@@ -1817,14 +1817,16 @@ static int pxa2xx_spi_probe(struct platform_device
*pdev)
status = devm_spi_register_controller(>dev, controller);
if (status != 0) {
dev_err(>dev, "problem registering spi controller\n");
- goto out_error_clock_enabled;
+ goto out_error_pm_runtime_enabled;
}
return status;
-out_error_clock_enabled:
+out_error_pm_runtime_enabled:
pm_runtime_put_noidle(>dev);
pm_runtime_disable(>dev);
+
+out_error_clock_enabled:
clk_disable_unprepare(ssp->clk);
out_error_dma_irq_alloc:
--
2.20.1
[PATCH AUTOSEL 5.2 015/123] ASoC: Intel: bytcht_es8316: Add quirk for Irbis NB41 netbook
From: Hans de Goede
[ Upstream commit aa2ba991c4206d5b778dcaa7b4997396e79f8e90 ]
The Irbis NB41 netbook has its internal mic on IN2, inverted jack-detect
and stereo speakers, add a quirk for this.
Cc: russianneuroman...@ya.ru
Reported-and-tested-by: russianneuroman...@ya.ru
Signed-off-by: Hans de Goede
Link: https://lore.kernel.org/r/20190712112708.25327-1-hdego...@redhat.com
Signed-off-by: Mark Brown
Signed-off-by: Sasha Levin
---
sound/soc/intel/boards/bytcht_es8316.c | 8
1 file changed, 8 insertions(+)
diff --git a/sound/soc/intel/boards/bytcht_es8316.c
b/sound/soc/intel/boards/bytcht_es8316.c
index 2fe1ce8791235..c360ebc3ccc7f 100644
--- a/sound/soc/intel/boards/bytcht_es8316.c
+++ b/sound/soc/intel/boards/bytcht_es8316.c
@@ -436,6 +436,14 @@ static const struct acpi_gpio_mapping
byt_cht_es8316_gpios[] = {
/* Please keep this list alphabetically sorted */
static const struct dmi_system_id byt_cht_es8316_quirk_table[] = {
+ { /* Irbis NB41 */
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "IRBIS"),
+ DMI_MATCH(DMI_PRODUCT_NAME, "NB41"),
+ },
+ .driver_data = (void *)(BYT_CHT_ES8316_INTMIC_IN2_MAP
+ | BYT_CHT_ES8316_JD_INVERTED),
+ },
{ /* Teclast X98 Plus II */
.matches = {
DMI_MATCH(DMI_SYS_VENDOR, "TECLAST"),
--
2.20.1
[PATCH AUTOSEL 5.2 023/123] ASoC: SOF: use __u32 instead of uint32_t in uapi headers
From: Masahiro Yamada
[ Upstream commit 62ec3d13601bd626ca7a0edef6d45dbb753d94e8 ]
When CONFIG_UAPI_HEADER_TEST=y, exported headers are compile-tested to
make sure they can be included from user-space.
Currently, header.h and fw.h are excluded from the test coverage.
To make them join the compile-test, we need to fix the build errors
attached below.
For a case like this, we decided to use __u{8,16,32,64} variable types
in this discussion:
https://lkml.org/lkml/2019/6/5/18
Build log:
CC usr/include/sound/sof/header.h.s
CC usr/include/sound/sof/fw.h.s
In file included from :32:0:
./usr/include/sound/sof/header.h:19:2: error: unknown type name ‘uint32_t’
uint32_t magic; /**< 'S', 'O', 'F', '\0' */
^~~~
./usr/include/sound/sof/header.h:20:2: error: unknown type name ‘uint32_t’
uint32_t type; /**< component specific type */
^~~~
./usr/include/sound/sof/header.h:21:2: error: unknown type name ‘uint32_t’
uint32_t size; /**< size in bytes of data excl. this struct */
^~~~
./usr/include/sound/sof/header.h:22:2: error: unknown type name ‘uint32_t’
uint32_t abi; /**< SOF ABI version */
^~~~
./usr/include/sound/sof/header.h:23:2: error: unknown type name ‘uint32_t’
uint32_t reserved[4]; /**< reserved for future use */
^~~~
./usr/include/sound/sof/header.h:24:2: error: unknown type name ‘uint32_t’
uint32_t data[0]; /**< Component data - opaque to core */
^~~~
In file included from :32:0:
./usr/include/sound/sof/fw.h:49:2: error: unknown type name ‘uint32_t’
uint32_t size; /* bytes minus this header */
^~~~
./usr/include/sound/sof/fw.h:50:2: error: unknown type name ‘uint32_t’
uint32_t offset; /* offset from base */
^~~~
./usr/include/sound/sof/fw.h:64:2: error: unknown type name ‘uint32_t’
uint32_t size; /* bytes minus this header */
^~~~
./usr/include/sound/sof/fw.h:65:2: error: unknown type name ‘uint32_t’
uint32_t num_blocks; /* number of blocks */
^~~~
./usr/include/sound/sof/fw.h:73:2: error: unknown type name ‘uint32_t’
uint32_t file_size; /* size of file minus this header */
^~~~
./usr/include/sound/sof/fw.h:74:2: error: unknown type name ‘uint32_t’
uint32_t num_modules; /* number of modules */
^~~~
./usr/include/sound/sof/fw.h:75:2: error: unknown type name ‘uint32_t’
uint32_t abi; /* version of header format */
^~~~
Signed-off-by: Masahiro Yamada
Link:
https://lore.kernel.org/r/20190721142308.30306-1-yamada.masah...@socionext.com
Signed-off-by: Mark Brown
Signed-off-by: Sasha Levin
---
include/uapi/sound/sof/fw.h | 16 +---
include/uapi/sound/sof/header.h | 14 --
2 files changed, 17 insertions(+), 13 deletions(-)
diff --git a/include/uapi/sound/sof/fw.h b/include/uapi/sound/sof/fw.h
index 1afca973eb097..e9f697467a861 100644
--- a/include/uapi/sound/sof/fw.h
+++ b/include/uapi/sound/sof/fw.h
@@ -13,6 +13,8 @@
#ifndef __INCLUDE_UAPI_SOF_FW_H__
#define __INCLUDE_UAPI_SOF_FW_H__
+#include
+
#define SND_SOF_FW_SIG_SIZE4
#define SND_SOF_FW_ABI 1
#define SND_SOF_FW_SIG "Reef"
@@ -46,8 +48,8 @@ enum snd_sof_fw_blk_type {
struct snd_sof_blk_hdr {
enum snd_sof_fw_blk_type type;
- uint32_t size; /* bytes minus this header */
- uint32_t offset;/* offset from base */
+ __u32 size; /* bytes minus this header */
+ __u32 offset; /* offset from base */
} __packed;
/*
@@ -61,8 +63,8 @@ enum snd_sof_fw_mod_type {
struct snd_sof_mod_hdr {
enum snd_sof_fw_mod_type type;
- uint32_t size; /* bytes minus this header */
- uint32_t num_blocks;/* number of blocks */
+ __u32 size; /* bytes minus this header */
+ __u32 num_blocks; /* number of blocks */
} __packed;
/*
@@ -70,9 +72,9 @@ struct snd_sof_mod_hdr {
*/
struct snd_sof_fw_header {
unsigned char sig[SND_SOF_FW_SIG_SIZE]; /* "Reef" */
- uint32_t file_size; /* size of file minus this header */
- uint32_t num_modules; /* number of modules */
- uint32_t abi; /* version of header format */
+ __u32 file_size;/* size of file minus this header */
+ __u32 num_modules; /* number of modules */
+ __u32 abi; /* version of header format */
} __packed;
#endif
diff --git a/include/uapi/sound/sof/header.h b/include/uapi/sound/sof/header.h
index 7868990b0d6f3..5f4518e7a9723 100644
--- a/include/uapi/sound/sof/header.h
+++ b/include/uapi/sound/sof/header.h
@@ -9,6 +9,8 @@
#ifndef __INCLUDE_UAPI_SOUND_SOF_USER_HEADER_H__
#define __INCLUDE_UAPI_SOUND_SOF_USER_HEADER_H__
+#include
+
/*
* Header for all non IPC ABI data.
*
@@ -16,12 +18,12 @@
* Used by any bespoke component data structures or binary blobs.
*/
struct sof_abi_hdr {
- uint32_t magic; /**< 'S', 'O', 'F', '\0' */
- uint32_t type; /**< component specific type */
-
[PATCH AUTOSEL 5.2 018/123] MIPS: kernel: only use i8253 clocksource with periodic clockevent
From: Thomas Bogendoerfer
[ Upstream commit a07e3324538a989b7cdbf2c679be6a7f9df2544f ]
i8253 clocksource needs a free running timer. This could only
be used, if i8253 clockevent is set up as periodic.
Signed-off-by: Thomas Bogendoerfer
Signed-off-by: Paul Burton
Cc: Ralf Baechle
Cc: James Hogan
Cc: linux-m...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Sasha Levin
---
arch/mips/kernel/i8253.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/mips/kernel/i8253.c b/arch/mips/kernel/i8253.c
index 5f209f111e59e..df7ddd246eaac 100644
--- a/arch/mips/kernel/i8253.c
+++ b/arch/mips/kernel/i8253.c
@@ -32,7 +32,8 @@ void __init setup_pit_timer(void)
static int __init init_pit_clocksource(void)
{
- if (num_possible_cpus() > 1) /* PIT does not scale! */
+ if (num_possible_cpus() > 1 || /* PIT does not scale! */
+ !clockevent_state_periodic(_clockevent))
return 0;
return clocksource_i8253_init();
--
2.20.1
[PATCH AUTOSEL 5.2 014/123] ASoC: samsung: odroid: fix a double-free issue for cpu_dai
From: Wen Yang
[ Upstream commit 2abee12c0ab1924a69993d2c063a39a952e7d836 ]
The cpu_dai variable is still being used after the of_node_put() call,
which may result in double-free:
of_node_put(cpu_dai);---> released here
ret = devm_snd_soc_register_card(dev, card);
if (ret < 0) {
...
goto err_put_clk_i2s;--> jump to err_put_clk_i2s
...
err_put_clk_i2s:
clk_put(priv->clk_i2s_bus);
err_put_sclk:
clk_put(priv->sclk_i2s);
err_put_cpu_dai:
of_node_put(cpu_dai);--> double-free here
Fixes: d832d2b246c5 ("ASoC: samsung: odroid: Fix of_node refcount unbalance")
Signed-off-by: Wen Yang
Cc: Krzysztof Kozlowski
Cc: Sangbeom Kim
Cc: Sylwester Nawrocki
Cc: Liam Girdwood
Cc: Mark Brown
Cc: Jaroslav Kysela
Cc: Takashi Iwai
Cc: alsa-de...@alsa-project.org
Cc: linux-kernel@vger.kernel.org
Link:
https://lore.kernel.org/r/1562989575-33785-3-git-send-email-wen.yan...@zte.com.cn
Signed-off-by: Mark Brown
Signed-off-by: Sasha Levin
---
sound/soc/samsung/odroid.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sound/soc/samsung/odroid.c b/sound/soc/samsung/odroid.c
index 95c35e3ff3303..d606e48fe551a 100644
--- a/sound/soc/samsung/odroid.c
+++ b/sound/soc/samsung/odroid.c
@@ -299,7 +299,6 @@ static int odroid_audio_probe(struct platform_device *pdev)
ret = PTR_ERR(priv->clk_i2s_bus);
goto err_put_sclk;
}
- of_node_put(cpu_dai);
ret = devm_snd_soc_register_card(dev, card);
if (ret < 0) {
@@ -307,6 +306,7 @@ static int odroid_audio_probe(struct platform_device *pdev)
goto err_put_clk_i2s;
}
+ of_node_put(cpu_dai);
of_node_put(codec);
return 0;
--
2.20.1
[PATCH AUTOSEL 5.2 013/123] ASoC: samsung: odroid: fix an use-after-free issue for codec
From: Wen Yang
[ Upstream commit 9b6d104a6b150bd4d3e5b039340e1f6b20c2e3c1 ]
The codec variable is still being used after the of_node_put() call,
which may result in use-after-free.
Fixes: bc3cf17b575a ("ASoC: samsung: odroid: Add support for secondary CPU DAI")
Signed-off-by: Wen Yang
Cc: Krzysztof Kozlowski
Cc: Sangbeom Kim
Cc: Sylwester Nawrocki
Cc: Liam Girdwood
Cc: Mark Brown
Cc: Jaroslav Kysela
Cc: Takashi Iwai
Cc: alsa-de...@alsa-project.org
Cc: linux-kernel@vger.kernel.org
Link:
https://lore.kernel.org/r/1562989575-33785-2-git-send-email-wen.yan...@zte.com.cn
Signed-off-by: Mark Brown
Signed-off-by: Sasha Levin
---
sound/soc/samsung/odroid.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/sound/soc/samsung/odroid.c b/sound/soc/samsung/odroid.c
index e688169ff12ab..95c35e3ff3303 100644
--- a/sound/soc/samsung/odroid.c
+++ b/sound/soc/samsung/odroid.c
@@ -275,9 +275,8 @@ static int odroid_audio_probe(struct platform_device *pdev)
}
of_node_put(cpu);
- of_node_put(codec);
if (ret < 0)
- return ret;
+ goto err_put_node;
ret = snd_soc_of_get_dai_link_codecs(dev, codec, codec_link);
if (ret < 0)
@@ -308,6 +307,7 @@ static int odroid_audio_probe(struct platform_device *pdev)
goto err_put_clk_i2s;
}
+ of_node_put(codec);
return 0;
err_put_clk_i2s:
@@ -317,6 +317,8 @@ static int odroid_audio_probe(struct platform_device *pdev)
err_put_cpu_dai:
of_node_put(cpu_dai);
snd_soc_of_put_dai_link_codecs(codec_link);
+err_put_node:
+ of_node_put(codec);
return ret;
}
--
2.20.1
[PATCH AUTOSEL 5.2 020/123] libbpf: sanitize VAR to conservative 1-byte INT
From: Andrii Nakryiko
[ Upstream commit 1d4126c4e1190d2f7d3f388552f9bd17ae0c64fc ]
If VAR in non-sanitized BTF was size less than 4, converting such VAR
into an INT with size=4 will cause BTF validation failure due to
violationg of STRUCT (into which DATASEC was converted) member size.
Fix by conservatively using size=1.
Signed-off-by: Andrii Nakryiko
Signed-off-by: Alexei Starovoitov
Signed-off-by: Sasha Levin
---
tools/lib/bpf/libbpf.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
index 3865a5d272514..77e14d9954796 100644
--- a/tools/lib/bpf/libbpf.c
+++ b/tools/lib/bpf/libbpf.c
@@ -1044,8 +1044,13 @@ static void bpf_object__sanitize_btf(struct bpf_object
*obj)
if (!has_datasec && kind == BTF_KIND_VAR) {
/* replace VAR with INT */
t->info = BTF_INFO_ENC(BTF_KIND_INT, 0, 0);
- t->size = sizeof(int);
- *(int *)(t+1) = BTF_INT_ENC(0, 0, 32);
+ /*
+* using size = 1 is the safest choice, 4 will be too
+* big and cause kernel BTF validation failure if
+* original variable took less than 4 bytes
+*/
+ t->size = 1;
+ *(int *)(t+1) = BTF_INT_ENC(0, 0, 8);
} else if (!has_datasec && kind == BTF_KIND_DATASEC) {
/* replace DATASEC with STRUCT */
struct btf_var_secinfo *v = (void *)(t + 1);
--
2.20.1
[PATCH AUTOSEL 5.2 019/123] mips: fix cacheinfo
From: Vladimir Kondratiev
[ Upstream commit b8bea8a5e5d942e62203416ab41edecaed4fda02 ]
Because CONFIG_OF defined for MIPS, cacheinfo attempts to fill information
from DT, ignoring data filled by architecture routine. This leads to error
reported
cacheinfo: Unable to detect cache hierarchy for CPU 0
Way to fix this provided in
commit fac51482577d ("drivers: base: cacheinfo: fix x86 with
CONFIG_OF enabled")
Utilize same mechanism to report that cacheinfo set by architecture
specific function
Signed-off-by: Vladimir Kondratiev
Signed-off-by: Paul Burton
Cc: Ralf Baechle
Cc: James Hogan
Cc: linux-m...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Sasha Levin
---
arch/mips/kernel/cacheinfo.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/mips/kernel/cacheinfo.c b/arch/mips/kernel/cacheinfo.c
index e0dd66881da68..f777e44653d57 100644
--- a/arch/mips/kernel/cacheinfo.c
+++ b/arch/mips/kernel/cacheinfo.c
@@ -69,6 +69,8 @@ static int __populate_cache_leaves(unsigned int cpu)
if (c->tcache.waysize)
populate_cache(tcache, this_leaf, 3, CACHE_TYPE_UNIFIED);
+ this_cpu_ci->cpu_map_populated = true;
+
return 0;
}
--
2.20.1
[PATCH AUTOSEL 5.2 022/123] ASoC: dapm: Fix handling of custom_stop_condition on DAPM graph walks
From: Charles Keepax
[ Upstream commit 8dd26dff00c0636b1d8621acaeef3f6f3a39dd77 ]
DPCM uses snd_soc_dapm_dai_get_connected_widgets to build a
list of the widgets connected to a specific front end DAI so it
can search through this list for available back end DAIs. The
custom_stop_condition was added to is_connected_ep to facilitate this
list not containing more widgets than is necessary. Doing so both
speeds up the DPCM handling as less widgets need to be searched and
avoids issues with CODEC to CODEC links as these would be confused
with back end DAIs if they appeared in the list of available widgets.
custom_stop_condition was implemented by aborting the graph walk
when the condition is triggered, however there is an issue with this
approach. Whilst walking the graph is_connected_ep should update the
endpoints cache on each widget, if the walk is aborted the number
of attached end points is unknown for that sub-graph. When the stop
condition triggered, the original patch ignored the triggering widget
and returned zero connected end points; a later patch updated this
to set the triggering widget's cache to 1 and return that. Both of
these approaches result in inaccurate values being stored in various
end point caches as the values propagate back through the graph,
which can result in later issues with widgets powering/not powering
unexpectedly.
As the original goal was to reduce the size of the widget list passed
to the DPCM code, the simplest solution is to limit the functionality
of the custom_stop_condition to the widget list. This means the rest
of the graph will still be processed resulting in correct end point
caches, but only widgets up to the stop condition will be added to the
returned widget list.
Fixes: 6742064aef7f ("ASoC: dapm: support user-defined stop condition in
dai_get_connected_widgets")
Fixes: 5fdd022c2026 ("ASoC: dpcm: play nice with CODEC<->CODEC links")
Fixes: 09464974eaa8 ("ASoC: dapm: Fix to return correct path list in
is_connected_ep.")
Signed-off-by: Charles Keepax
Link:
https://lore.kernel.org/r/20190718084333.15598-1-ckee...@opensource.cirrus.com
Signed-off-by: Mark Brown
Signed-off-by: Sasha Levin
---
sound/soc/soc-dapm.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/sound/soc/soc-dapm.c b/sound/soc/soc-dapm.c
index c91df5a9c8406..835ce1ff188d9 100644
--- a/sound/soc/soc-dapm.c
+++ b/sound/soc/soc-dapm.c
@@ -1156,8 +1156,8 @@ static __always_inline int is_connected_ep(struct
snd_soc_dapm_widget *widget,
list_add_tail(>work_list, list);
if (custom_stop_condition && custom_stop_condition(widget, dir)) {
- widget->endpoints[dir] = 1;
- return widget->endpoints[dir];
+ list = NULL;
+ custom_stop_condition = NULL;
}
if ((widget->is_ep & SND_SOC_DAPM_DIR_TO_EP(dir)) && widget->connected)
{
@@ -1194,8 +1194,8 @@ static __always_inline int is_connected_ep(struct
snd_soc_dapm_widget *widget,
*
* Optionally, can be supplied with a function acting as a stopping condition.
* This function takes the dapm widget currently being examined and the walk
- * direction as an arguments, it should return true if the walk should be
- * stopped and false otherwise.
+ * direction as an arguments, it should return true if widgets from that point
+ * in the graph onwards should not be added to the widget list.
*/
static int is_connected_output_ep(struct snd_soc_dapm_widget *widget,
struct list_head *list,
--
2.20.1
[PATCH AUTOSEL 5.2 033/123] selftests: forwarding: gre_multipath: Fix flower filters
From: Ido Schimmel
[ Upstream commit 1be79d89b7ae96e004911bd228ce8c2b5cc6415f ]
The TC filters used in the test do not work with veth devices because the
outer Ethertype is 802.1Q and not IPv4. The test passes with mlxsw
netdevs since the hardware always looks at "The first Ethertype that
does not point to either: VLAN, CNTAG or configurable Ethertype".
Fix this by matching on the VLAN ID instead, but on the ingress side.
The reason why this is not performed at egress is explained in the
commit cited below.
Fixes: 541ad323db3a ("selftests: forwarding: gre_multipath: Update next-hop
statistics match criteria")
Signed-off-by: Ido Schimmel
Reported-by: Stephen Suryaputra
Tested-by: Stephen Suryaputra
Signed-off-by: David S. Miller
Signed-off-by: Sasha Levin
---
.../selftests/net/forwarding/gre_multipath.sh | 24 +--
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/tools/testing/selftests/net/forwarding/gre_multipath.sh
b/tools/testing/selftests/net/forwarding/gre_multipath.sh
index 37d7297e1cf8a..a8d8e8b3dc819 100755
--- a/tools/testing/selftests/net/forwarding/gre_multipath.sh
+++ b/tools/testing/selftests/net/forwarding/gre_multipath.sh
@@ -93,18 +93,10 @@ sw1_create()
ip route add vrf v$ol1 192.0.2.16/28 \
nexthop dev g1a \
nexthop dev g1b
-
- tc qdisc add dev $ul1 clsact
- tc filter add dev $ul1 egress pref 111 prot ipv4 \
- flower dst_ip 192.0.2.66 action pass
- tc filter add dev $ul1 egress pref 222 prot ipv4 \
- flower dst_ip 192.0.2.82 action pass
}
sw1_destroy()
{
- tc qdisc del dev $ul1 clsact
-
ip route del vrf v$ol1 192.0.2.16/28
ip route del vrf v$ol1 192.0.2.82/32 via 192.0.2.146
@@ -139,10 +131,18 @@ sw2_create()
ip route add vrf v$ol2 192.0.2.0/28 \
nexthop dev g2a \
nexthop dev g2b
+
+ tc qdisc add dev $ul2 clsact
+ tc filter add dev $ul2 ingress pref 111 prot 802.1Q \
+ flower vlan_id 111 action pass
+ tc filter add dev $ul2 ingress pref 222 prot 802.1Q \
+ flower vlan_id 222 action pass
}
sw2_destroy()
{
+ tc qdisc del dev $ul2 clsact
+
ip route del vrf v$ol2 192.0.2.0/28
ip route del vrf v$ol2 192.0.2.81/32 via 192.0.2.145
@@ -215,15 +215,15 @@ multipath4_test()
nexthop dev g1a weight $weight1 \
nexthop dev g1b weight $weight2
- local t0_111=$(tc_rule_stats_get $ul1 111 egress)
- local t0_222=$(tc_rule_stats_get $ul1 222 egress)
+ local t0_111=$(tc_rule_stats_get $ul2 111 ingress)
+ local t0_222=$(tc_rule_stats_get $ul2 222 ingress)
ip vrf exec v$h1 \
$MZ $h1 -q -p 64 -A 192.0.2.1 -B 192.0.2.18 \
-d 1msec -t udp "sp=1024,dp=0-32768"
- local t1_111=$(tc_rule_stats_get $ul1 111 egress)
- local t1_222=$(tc_rule_stats_get $ul1 222 egress)
+ local t1_111=$(tc_rule_stats_get $ul2 111 ingress)
+ local t1_222=$(tc_rule_stats_get $ul2 222 ingress)
local d111=$((t1_111 - t0_111))
local d222=$((t1_222 - t0_222))
--
2.20.1
[PATCH AUTOSEL 5.2 025/123] bpf: sockmap, sock_map_delete needs to use xchg
From: John Fastabend
[ Upstream commit 45a4521dcbd92e71c9e53031b40e34211d3b4feb ]
__sock_map_delete() may be called from a tcp event such as unhash or
close from the following trace,
tcp_bpf_close()
tcp_bpf_remove()
sk_psock_unlink()
sock_map_delete_from_link()
__sock_map_delete()
In this case the sock lock is held but this only protects against
duplicate removals on the TCP side. If the map is free'd then we have
this trace,
sock_map_free
xchg() <- replaces map entry
sock_map_unref()
sk_psock_put()
sock_map_del_link()
The __sock_map_delete() call however uses a read, test, null over the
map entry which can result in both paths trying to free the map
entry.
To fix use xchg in TCP paths as well so we avoid having two references
to the same map entry.
Fixes: 604326b41a6fb ("bpf, sockmap: convert to generic sk_msg interface")
Signed-off-by: John Fastabend
Signed-off-by: Daniel Borkmann
Signed-off-by: Sasha Levin
---
net/core/sock_map.c | 14 +-
1 file changed, 9 insertions(+), 5 deletions(-)
diff --git a/net/core/sock_map.c b/net/core/sock_map.c
index be6092ac69f8a..1d40e040320d2 100644
--- a/net/core/sock_map.c
+++ b/net/core/sock_map.c
@@ -281,16 +281,20 @@ static int __sock_map_delete(struct bpf_stab *stab,
struct sock *sk_test,
struct sock **psk)
{
struct sock *sk;
+ int err = 0;
raw_spin_lock_bh(>lock);
sk = *psk;
if (!sk_test || sk_test == sk)
- *psk = NULL;
+ sk = xchg(psk, NULL);
+
+ if (likely(sk))
+ sock_map_unref(sk, psk);
+ else
+ err = -EINVAL;
+
raw_spin_unlock_bh(>lock);
- if (unlikely(!sk))
- return -EINVAL;
- sock_map_unref(sk, psk);
- return 0;
+ return err;
}
static void sock_map_delete_from_link(struct bpf_map *map, struct sock *sk,
--
2.20.1
[PATCH AUTOSEL 5.2 026/123] bpf: sockmap, synchronize_rcu before free'ing map
From: John Fastabend
[ Upstream commit 2bb90e5cc90e1d09f631aeab041a9cf913a5bbe5 ]
We need to have a synchronize_rcu before free'ing the sockmap because
any outstanding psock references will have a pointer to the map and
when they use this could trigger a use after free.
Fixes: 604326b41a6fb ("bpf, sockmap: convert to generic sk_msg interface")
Signed-off-by: John Fastabend
Signed-off-by: Daniel Borkmann
Signed-off-by: Sasha Levin
---
net/core/sock_map.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/net/core/sock_map.c b/net/core/sock_map.c
index 1d40e040320d2..bbc91597d8364 100644
--- a/net/core/sock_map.c
+++ b/net/core/sock_map.c
@@ -252,6 +252,8 @@ static void sock_map_free(struct bpf_map *map)
raw_spin_unlock_bh(>lock);
rcu_read_unlock();
+ synchronize_rcu();
+
bpf_map_area_free(stab->sks);
kfree(stab);
}
--
2.20.1
[PATCH AUTOSEL 5.2 030/123] bonding: Force slave speed check after link state recovery for 802.3ad
From: Thomas Falcon
[ Upstream commit 12185dfe44360f814ac4ead9d22ad2af7511b2e9 ]
The following scenario was encountered during testing of logical
partition mobility on pseries partitions with bonded ibmvnic
adapters in LACP mode.
1. Driver receives a signal that the device has been
swapped, and it needs to reset to initialize the new
device.
2. Driver reports loss of carrier and begins initialization.
3. Bonding driver receives NETDEV_CHANGE notifier and checks
the slave's current speed and duplex settings. Because these
are unknown at the time, the bond sets its link state to
BOND_LINK_FAIL and handles the speed update, clearing
AD_PORT_LACP_ENABLE.
4. Driver finishes recovery and reports that the carrier is on.
5. Bond receives a new notification and checks the speed again.
The speeds are valid but miimon has not altered the link
state yet. AD_PORT_LACP_ENABLE remains off.
Because the slave's link state is still BOND_LINK_FAIL,
no further port checks are made when it recovers. Though
the slave devices are operational and have valid speed
and duplex settings, the bond will not send LACPDU's. The
simplest fix I can see is to force another speed check
in bond_miimon_commit. This way the bond will update
AD_PORT_LACP_ENABLE if needed when transitioning from
BOND_LINK_FAIL to BOND_LINK_UP.
CC: Jarod Wilson
CC: Jay Vosburgh
CC: Veaceslav Falico
CC: Andy Gospodarek
Signed-off-by: Thomas Falcon
Signed-off-by: David S. Miller
Signed-off-by: Sasha Levin
---
drivers/net/bonding/bond_main.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
index b0aab3a0a1bfa..41f6da5b4bab8 100644
--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/bond_main.c
@@ -2203,6 +2203,15 @@ static void bond_miimon_commit(struct bonding *bond)
bond_for_each_slave(bond, slave, iter) {
switch (slave->new_link) {
case BOND_LINK_NOCHANGE:
+ /* For 802.3ad mode, check current slave speed and
+* duplex again in case its port was disabled after
+* invalid speed/duplex reporting but recovered before
+* link monitoring could make a decision on the actual
+* link status
+*/
+ if (BOND_MODE(bond) == BOND_MODE_8023AD &&
+ slave->link == BOND_LINK_UP)
+ bond_3ad_adapter_speed_duplex_changed(slave);
continue;
case BOND_LINK_UP:
--
2.20.1
[PATCH AUTOSEL 5.2 046/123] ASoC: ti: davinci-mcasp: Fix clk PDIR handling for i2s master mode
From: Peter Ujfalusi
[ Upstream commit 34a2a80ff30b5d2330abfa8980c7f0cc15a8158a ]
When running McASP as master capture alone will not record any audio unless
a parallel playback stream is running. As soon as the playback stops the
captured data is going to be silent again.
In McASP master mode we need to set the PDIR for the clock pins and fix
the mcasp_set_axr_pdir() to skip the bits in the PDIR registers above
AMUTE.
This went unnoticed as most of the boards uses McASP as slave and neither
of these issues are visible (audible) in those setups.
Fixes: ca3d9433349e ("ASoC: davinci-mcasp: Update PDIR (pin direction) register
handling")
Signed-off-by: Peter Ujfalusi
Link: https://lore.kernel.org/r/20190725083423.7321-1-peter.ujfal...@ti.com
Signed-off-by: Mark Brown
Signed-off-by: Sasha Levin
---
sound/soc/ti/davinci-mcasp.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/sound/soc/ti/davinci-mcasp.c b/sound/soc/ti/davinci-mcasp.c
index 5e8e31743a28d..dc01bbca0ff69 100644
--- a/sound/soc/ti/davinci-mcasp.c
+++ b/sound/soc/ti/davinci-mcasp.c
@@ -194,7 +194,7 @@ static inline void mcasp_set_axr_pdir(struct davinci_mcasp
*mcasp, bool enable)
{
u32 bit;
- for_each_set_bit(bit, >pdir, PIN_BIT_AFSR) {
+ for_each_set_bit(bit, >pdir, PIN_BIT_AMUTE) {
if (enable)
mcasp_set_bits(mcasp, DAVINCI_MCASP_PDIR_REG, BIT(bit));
else
@@ -222,6 +222,7 @@ static void mcasp_start_rx(struct davinci_mcasp *mcasp)
if (mcasp_is_synchronous(mcasp)) {
mcasp_set_ctl_reg(mcasp, DAVINCI_MCASP_GBLCTLX_REG, TXHCLKRST);
mcasp_set_ctl_reg(mcasp, DAVINCI_MCASP_GBLCTLX_REG, TXCLKRST);
+ mcasp_set_clk_pdir(mcasp, true);
}
/* Activate serializer(s) */
--
2.20.1
[PATCH AUTOSEL 5.2 044/123] st_nci_hci_connectivity_event_received: null check the allocation
From: Navid Emamdoost [ Upstream commit 3008e06fdf0973770370f97d5f1fba3701d8281d ] devm_kzalloc may fail and return NULL. So the null check is needed. Signed-off-by: Navid Emamdoost Signed-off-by: David S. Miller Signed-off-by: Sasha Levin --- drivers/nfc/st-nci/se.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/nfc/st-nci/se.c b/drivers/nfc/st-nci/se.c index c3e10b6ab3a4d..f25f1ec5f9e97 100644 --- a/drivers/nfc/st-nci/se.c +++ b/drivers/nfc/st-nci/se.c @@ -333,6 +333,8 @@ static int st_nci_hci_connectivity_event_received(struct nci_dev *ndev, transaction = (struct nfc_evt_transaction *)devm_kzalloc(dev, skb->len - 2, GFP_KERNEL); + if (!transaction) + return -ENOMEM; transaction->aid_len = skb->data[1]; memcpy(transaction->aid, >data[2], transaction->aid_len); -- 2.20.1
[PATCH AUTOSEL 5.2 043/123] st21nfca_connectivity_event_received: null check the allocation
From: Navid Emamdoost [ Upstream commit 9891d06836e67324c9e9c4675ed90fc8b8110034 ] devm_kzalloc may fail and return null. So the null check is needed. Signed-off-by: Navid Emamdoost Signed-off-by: David S. Miller Signed-off-by: Sasha Levin --- drivers/nfc/st21nfca/se.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/nfc/st21nfca/se.c b/drivers/nfc/st21nfca/se.c index 06fc542fd1987..6586378cacb05 100644 --- a/drivers/nfc/st21nfca/se.c +++ b/drivers/nfc/st21nfca/se.c @@ -317,6 +317,8 @@ int st21nfca_connectivity_event_received(struct nfc_hci_dev *hdev, u8 host, transaction = (struct nfc_evt_transaction *)devm_kzalloc(dev, skb->len - 2, GFP_KERNEL); + if (!transaction) + return -ENOMEM; transaction->aid_len = skb->data[1]; memcpy(transaction->aid, >data[2], -- 2.20.1
[PATCH AUTOSEL 5.2 050/123] qed: RDMA - Fix the hw_ver returned in device attributes
From: Michal Kalderon [ Upstream commit 81af04b432fdfabcdbd2c06be2ee647e3ca41a22 ] The hw_ver field was initialized to zero. Return the chip revision. This is relevant for rdma driver. Signed-off-by: Michal Kalderon Signed-off-by: David S. Miller Signed-off-by: Sasha Levin --- drivers/net/ethernet/qlogic/qed/qed_rdma.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/ethernet/qlogic/qed/qed_rdma.c b/drivers/net/ethernet/qlogic/qed/qed_rdma.c index 13802b825d65a..909422d939033 100644 --- a/drivers/net/ethernet/qlogic/qed/qed_rdma.c +++ b/drivers/net/ethernet/qlogic/qed/qed_rdma.c @@ -442,7 +442,7 @@ static void qed_rdma_init_devinfo(struct qed_hwfn *p_hwfn, /* Vendor specific information */ dev->vendor_id = cdev->vendor_id; dev->vendor_part_id = cdev->device_id; - dev->hw_ver = 0; + dev->hw_ver = cdev->chip_rev; dev->fw_ver = (FW_MAJOR_VERSION << 24) | (FW_MINOR_VERSION << 16) | (FW_REVISION_VERSION << 8) | (FW_ENGINEERING_VERSION); -- 2.20.1
[PATCH AUTOSEL 5.2 048/123] ASoC: ti: davinci-mcasp: Correct slot_width posed constraint
From: Peter Ujfalusi
[ Upstream commit 1e112c35e3c96db7c8ca6ddaa96574f00c06e7db ]
The slot_width is a property for the bus while the constraint for
SNDRV_PCM_HW_PARAM_SAMPLE_BITS is for the in memory format.
Applying slot_width constraint to sample_bits works most of the time, but
it will blacklist valid formats in some cases.
With slot_width 24 we can support S24_3LE and S24_LE formats as they both
look the same on the bus, but a a 24 constraint on sample_bits would not
allow S24_LE as it is stored in 32bits in memory.
Implement a simple hw_rule function to allow all formats which require less
or equal number of bits on the bus as slot_width (if configured).
Signed-off-by: Peter Ujfalusi
Link: https://lore.kernel.org/r/20190726064244.3762-2-peter.ujfal...@ti.com
Signed-off-by: Mark Brown
Signed-off-by: Sasha Levin
---
sound/soc/ti/davinci-mcasp.c | 43
1 file changed, 34 insertions(+), 9 deletions(-)
diff --git a/sound/soc/ti/davinci-mcasp.c b/sound/soc/ti/davinci-mcasp.c
index dc01bbca0ff69..56009d1472084 100644
--- a/sound/soc/ti/davinci-mcasp.c
+++ b/sound/soc/ti/davinci-mcasp.c
@@ -1254,6 +1254,28 @@ static int davinci_mcasp_trigger(struct
snd_pcm_substream *substream,
return ret;
}
+static int davinci_mcasp_hw_rule_slot_width(struct snd_pcm_hw_params *params,
+ struct snd_pcm_hw_rule *rule)
+{
+ struct davinci_mcasp_ruledata *rd = rule->private;
+ struct snd_mask *fmt = hw_param_mask(params, SNDRV_PCM_HW_PARAM_FORMAT);
+ struct snd_mask nfmt;
+ int i, slot_width;
+
+ snd_mask_none();
+ slot_width = rd->mcasp->slot_width;
+
+ for (i = 0; i <= SNDRV_PCM_FORMAT_LAST; i++) {
+ if (snd_mask_test(fmt, i)) {
+ if (snd_pcm_format_width(i) <= slot_width) {
+ snd_mask_set(, i);
+ }
+ }
+ }
+
+ return snd_mask_refine(fmt, );
+}
+
static const unsigned int davinci_mcasp_dai_rates[] = {
8000, 11025, 16000, 22050, 32000, 44100, 48000, 64000,
88200, 96000, 176400, 192000,
@@ -1361,7 +1383,7 @@ static int davinci_mcasp_startup(struct snd_pcm_substream
*substream,
struct davinci_mcasp_ruledata *ruledata =
>ruledata[substream->stream];
u32 max_channels = 0;
- int i, dir;
+ int i, dir, ret;
int tdm_slots = mcasp->tdm_slots;
/* Do not allow more then one stream per direction */
@@ -1390,6 +1412,7 @@ static int davinci_mcasp_startup(struct snd_pcm_substream
*substream,
max_channels++;
}
ruledata->serializers = max_channels;
+ ruledata->mcasp = mcasp;
max_channels *= tdm_slots;
/*
* If the already active stream has less channels than the calculated
@@ -1415,20 +1438,22 @@ static int davinci_mcasp_startup(struct
snd_pcm_substream *substream,
0, SNDRV_PCM_HW_PARAM_CHANNELS,
>chconstr[substream->stream]);
- if (mcasp->slot_width)
- snd_pcm_hw_constraint_minmax(substream->runtime,
-SNDRV_PCM_HW_PARAM_SAMPLE_BITS,
-8, mcasp->slot_width);
+ if (mcasp->slot_width) {
+ /* Only allow formats require <= slot_width bits on the bus */
+ ret = snd_pcm_hw_rule_add(substream->runtime, 0,
+ SNDRV_PCM_HW_PARAM_FORMAT,
+ davinci_mcasp_hw_rule_slot_width,
+ ruledata,
+ SNDRV_PCM_HW_PARAM_FORMAT, -1);
+ if (ret)
+ return ret;
+ }
/*
* If we rely on implicit BCLK divider setting we should
* set constraints based on what we can provide.
*/
if (mcasp->bclk_master && mcasp->bclk_div == 0 && mcasp->sysclk_freq) {
- int ret;
-
- ruledata->mcasp = mcasp;
-
ret = snd_pcm_hw_rule_add(substream->runtime, 0,
SNDRV_PCM_HW_PARAM_RATE,
davinci_mcasp_hw_rule_rate,
--
2.20.1
[PATCH AUTOSEL 5.2 049/123] net: usb: qmi_wwan: Add the BroadMobi BM818 card
From: Bob Ham
[ Upstream commit 9a07406b00cdc6ec689dc142540739575c717f3c ]
The BroadMobi BM818 M.2 card uses the QMI protocol
Signed-off-by: Bob Ham
Signed-off-by: Angus Ainslie (Purism)
Signed-off-by: David S. Miller
Signed-off-by: Sasha Levin
---
drivers/net/usb/qmi_wwan.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/usb/qmi_wwan.c b/drivers/net/usb/qmi_wwan.c
index 8b4ad10cf9402..26c5207466afc 100644
--- a/drivers/net/usb/qmi_wwan.c
+++ b/drivers/net/usb/qmi_wwan.c
@@ -1294,6 +1294,7 @@ static const struct usb_device_id products[] = {
{QMI_FIXED_INTF(0x2001, 0x7e35, 4)},/* D-Link DWM-222 */
{QMI_FIXED_INTF(0x2020, 0x2031, 4)},/* Olicard 600 */
{QMI_FIXED_INTF(0x2020, 0x2033, 4)},/* BroadMobi BM806U */
+ {QMI_FIXED_INTF(0x2020, 0x2060, 4)},/* BroadMobi BM818 */
{QMI_FIXED_INTF(0x0f3d, 0x68a2, 8)},/* Sierra Wireless MC7700 */
{QMI_FIXED_INTF(0x114f, 0x68a2, 8)},/* Sierra Wireless MC7750 */
{QMI_FIXED_INTF(0x1199, 0x68a2, 8)},/* Sierra Wireless MC7710 in
QMI mode */
--
2.20.1
[PATCH AUTOSEL 5.2 052/123] habanalabs: fix F/W download in BE architecture
From: Ben Segal
[ Upstream commit 75035fe22b808a520e1d712ebe913684ba406e01 ]
writeX macros might perform byte-swapping in BE architectures. As our F/W
is in LE format, we need to make sure no byte-swapping will occur.
There is a standard kernel function (called memcpy_toio) for copying data
to I/O area which is used in a lot of drivers to download F/W to PCIe
adapters. That function also makes sure the data is copied "as-is",
without byte-swapping.
This patch use that function to copy the F/W to the GOYA ASIC instead of
writeX macros.
Signed-off-by: Ben Segal
Reviewed-by: Oded Gabbay
Signed-off-by: Oded Gabbay
Signed-off-by: Sasha Levin
---
drivers/misc/habanalabs/firmware_if.c | 19 ++-
1 file changed, 2 insertions(+), 17 deletions(-)
diff --git a/drivers/misc/habanalabs/firmware_if.c
b/drivers/misc/habanalabs/firmware_if.c
index eda5d7fcb79f2..fe9e57a81b6fd 100644
--- a/drivers/misc/habanalabs/firmware_if.c
+++ b/drivers/misc/habanalabs/firmware_if.c
@@ -24,7 +24,7 @@ int hl_fw_push_fw_to_device(struct hl_device *hdev, const
char *fw_name,
{
const struct firmware *fw;
const u64 *fw_data;
- size_t fw_size, i;
+ size_t fw_size;
int rc;
rc = request_firmware(, fw_name, hdev->dev);
@@ -45,22 +45,7 @@ int hl_fw_push_fw_to_device(struct hl_device *hdev, const
char *fw_name,
fw_data = (const u64 *) fw->data;
- if ((fw->size % 8) != 0)
- fw_size -= 8;
-
- for (i = 0 ; i < fw_size ; i += 8, fw_data++, dst += 8) {
- if (!(i & (0x8 - 1))) {
- dev_dbg(hdev->dev,
- "copied so far %zu out of %zu for %s firmware",
- i, fw_size, fw_name);
- usleep_range(20, 100);
- }
-
- writeq(*fw_data, dst);
- }
-
- if ((fw->size % 8) != 0)
- writel(*(const u32 *) fw_data, dst);
+ memcpy_toio(dst, fw_data, fw_size);
out:
release_firmware(fw);
--
2.20.1
[PATCH AUTOSEL 5.2 056/123] netfilter: ipset: Copy the right MAC address in bitmap:ip,mac and hash:ip,mac sets
From: Stefano Brivio
[ Upstream commit 1b4a75108d5bc153daf965d334e77e8e94534f96 ]
In commit 8cc4ccf58379 ("ipset: Allow matching on destination MAC address
for mac and ipmac sets"), ipset.git commit 1543514c46a7, I added to the
KADT functions for sets matching on MAC addreses the copy of source or
destination MAC address depending on the configured match.
This was done correctly for hash:mac, but for hash:ip,mac and
bitmap:ip,mac, copying and pasting the same code block presents an
obvious problem: in these two set types, the MAC address is the second
dimension, not the first one, and we are actually selecting the MAC
address depending on whether the first dimension (IP address) specifies
source or destination.
Fix this by checking for the IPSET_DIM_TWO_SRC flag in option flags.
This way, mixing source and destination matches for the two dimensions
of ip,mac set types works as expected. With this setup:
ip netns add A
ip link add veth1 type veth peer name veth2 netns A
ip addr add 192.0.2.1/24 dev veth1
ip -net A addr add 192.0.2.2/24 dev veth2
ip link set veth1 up
ip -net A link set veth2 up
dst=$(ip netns exec A cat /sys/class/net/veth2/address)
ip netns exec A ipset create test_bitmap bitmap:ip,mac range 192.0.0.0/16
ip netns exec A ipset add test_bitmap 192.0.2.1,${dst}
ip netns exec A iptables -A INPUT -m set ! --match-set test_bitmap src,dst -j
DROP
ip netns exec A ipset create test_hash hash:ip,mac
ip netns exec A ipset add test_hash 192.0.2.1,${dst}
ip netns exec A iptables -A INPUT -m set ! --match-set test_hash src,dst -j
DROP
ipset correctly matches a test packet:
# ping -c1 192.0.2.2 >/dev/null
# echo $?
0
Reported-by: Chen Yi
Fixes: 8cc4ccf58379 ("ipset: Allow matching on destination MAC address for mac
and ipmac sets")
Signed-off-by: Stefano Brivio
Signed-off-by: Jozsef Kadlecsik
Signed-off-by: Sasha Levin
---
net/netfilter/ipset/ip_set_bitmap_ipmac.c | 2 +-
net/netfilter/ipset/ip_set_hash_ipmac.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/netfilter/ipset/ip_set_bitmap_ipmac.c
b/net/netfilter/ipset/ip_set_bitmap_ipmac.c
index b73c37b3a791f..cfe7b556775f1 100644
--- a/net/netfilter/ipset/ip_set_bitmap_ipmac.c
+++ b/net/netfilter/ipset/ip_set_bitmap_ipmac.c
@@ -227,7 +227,7 @@ bitmap_ipmac_kadt(struct ip_set *set, const struct sk_buff
*skb,
e.id = ip_to_id(map, ip);
- if (opt->flags & IPSET_DIM_ONE_SRC)
+ if (opt->flags & IPSET_DIM_TWO_SRC)
ether_addr_copy(e.ether, eth_hdr(skb)->h_source);
else
ether_addr_copy(e.ether, eth_hdr(skb)->h_dest);
diff --git a/net/netfilter/ipset/ip_set_hash_ipmac.c
b/net/netfilter/ipset/ip_set_hash_ipmac.c
index eb14434083203..24d8f4df4230c 100644
--- a/net/netfilter/ipset/ip_set_hash_ipmac.c
+++ b/net/netfilter/ipset/ip_set_hash_ipmac.c
@@ -93,7 +93,7 @@ hash_ipmac4_kadt(struct ip_set *set, const struct sk_buff
*skb,
(skb_mac_header(skb) + ETH_HLEN) > skb->data)
return -EINVAL;
- if (opt->flags & IPSET_DIM_ONE_SRC)
+ if (opt->flags & IPSET_DIM_TWO_SRC)
ether_addr_copy(e.ether, eth_hdr(skb)->h_source);
else
ether_addr_copy(e.ether, eth_hdr(skb)->h_dest);
--
2.20.1
[PATCH] Fix an OOB bug in parse_audio_mixer_unit
The `uac_mixer_unit_descriptor` shown as below is read from the
device side. In `parse_audio_mixer_unit`, `baSourceID` field is
accessed from index 0 to `bNrInPins` - 1, the current implementation
assumes that descriptor is always valid (the length of descriptor
is no shorter than 5 + `bNrInPins`). If a descriptor read from
the device side is invalid, it may trigger out-of-bound memory
access.
```
struct uac_mixer_unit_descriptor {
__u8 bLength;
__u8 bDescriptorType;
__u8 bDescriptorSubtype;
__u8 bUnitID;
__u8 bNrInPins;
__u8 baSourceID[];
}
```
This patch fixes the bug by add a sanity check on the length of
the descriptor.
Signed-off-by: Hui Peng
Reported-by: Hui Peng
Reported-by: Mathias Payer
---
sound/usb/mixer.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/sound/usb/mixer.c b/sound/usb/mixer.c
index 7498b5191b68..38202ce67237 100644
--- a/sound/usb/mixer.c
+++ b/sound/usb/mixer.c
@@ -2091,6 +2091,15 @@ static int parse_audio_mixer_unit(struct mixer_build
*state, int unitid,
struct usb_audio_term iterm;
int input_pins, num_ins, num_outs;
int pin, ich, err;
+ int desc_len = (int) ((unsigned long) state->buffer +
+ state->buflen - (unsigned long) raw_desc);
+
+ if (desc_len < sizeof(*desc) + desc->bNrInPins) {
+ usb_audio_err(state->chip,
+ "descriptor %d too short\n",
+ unitid);
+ return -EINVAL;
+ }
err = uac_mixer_unit_get_channels(state, desc);
if (err < 0) {
--
2.22.1
[PATCH AUTOSEL 5.2 054/123] net: stmmac: manage errors returned by of_get_mac_address()
From: Martin Blumenstingl
[ Upstream commit 195b2919ccd7ffcaf6b6bbcb39444a53ab8308c7 ]
Commit d01f449c008a ("of_net: add NVMEM support to of_get_mac_address")
added support for reading the MAC address from an nvmem-cell. This
required changing the logic to return an error pointer upon failure.
If stmmac is loaded before the nvmem provider driver then
of_get_mac_address() return an error pointer with -EPROBE_DEFER.
Propagate this error so the stmmac driver will be probed again after the
nvmem provider driver is loaded.
Default to a random generated MAC address in case of any other error,
instead of using the error pointer as MAC address.
Fixes: d01f449c008a ("of_net: add NVMEM support to of_get_mac_address")
Signed-off-by: Martin Blumenstingl
Reviewed-by: Neil Armstrong
Signed-off-by: David S. Miller
Signed-off-by: Sasha Levin
---
drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
index 0f0f4b31eb7ec..9b5218a8c15bc 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
@@ -385,6 +385,13 @@ stmmac_probe_config_dt(struct platform_device *pdev, const
char **mac)
return ERR_PTR(-ENOMEM);
*mac = of_get_mac_address(np);
+ if (IS_ERR(*mac)) {
+ if (PTR_ERR(*mac) == -EPROBE_DEFER)
+ return ERR_CAST(*mac);
+
+ *mac = NULL;
+ }
+
plat->interface = of_get_phy_mode(np);
/* Get max speed of operation from device tree */
--
2.20.1
[PATCH AUTOSEL 5.2 058/123] netfilter: ebtables: also count base chain policies
From: Florian Westphal
[ Upstream commit 3b48300d5cc7c7bed63fddb006c4046549ed4aec ]
ebtables doesn't include the base chain policies in the rule count,
so we need to add them manually when we call into the x_tables core
to allocate space for the comapt offset table.
This lead syzbot to trigger:
WARNING: CPU: 1 PID: 9012 at net/netfilter/x_tables.c:649
xt_compat_add_offset.cold+0x11/0x36 net/netfilter/x_tables.c:649
Reported-by: syzbot+276ddebab3382bbf7...@syzkaller.appspotmail.com
Fixes: 2035f3ff8eaa ("netfilter: ebtables: compat: un-break 32bit setsockopt
when no rules are present")
Signed-off-by: Florian Westphal
Signed-off-by: Pablo Neira Ayuso
Signed-off-by: Sasha Levin
---
net/bridge/netfilter/ebtables.c | 28 +---
1 file changed, 17 insertions(+), 11 deletions(-)
diff --git a/net/bridge/netfilter/ebtables.c b/net/bridge/netfilter/ebtables.c
index fd84b48e48b57..c8177a89f52c3 100644
--- a/net/bridge/netfilter/ebtables.c
+++ b/net/bridge/netfilter/ebtables.c
@@ -1770,20 +1770,28 @@ static int compat_calc_entry(const struct ebt_entry *e,
return 0;
}
+static int ebt_compat_init_offsets(unsigned int number)
+{
+ if (number > INT_MAX)
+ return -EINVAL;
+
+ /* also count the base chain policies */
+ number += NF_BR_NUMHOOKS;
+
+ return xt_compat_init_offsets(NFPROTO_BRIDGE, number);
+}
static int compat_table_info(const struct ebt_table_info *info,
struct compat_ebt_replace *newinfo)
{
unsigned int size = info->entries_size;
const void *entries = info->entries;
+ int ret;
newinfo->entries_size = size;
- if (info->nentries) {
- int ret = xt_compat_init_offsets(NFPROTO_BRIDGE,
-info->nentries);
- if (ret)
- return ret;
- }
+ ret = ebt_compat_init_offsets(info->nentries);
+ if (ret)
+ return ret;
return EBT_ENTRY_ITERATE(entries, size, compat_calc_entry, info,
entries, newinfo);
@@ -2234,11 +2242,9 @@ static int compat_do_replace(struct net *net, void
__user *user,
xt_compat_lock(NFPROTO_BRIDGE);
- if (tmp.nentries) {
- ret = xt_compat_init_offsets(NFPROTO_BRIDGE, tmp.nentries);
- if (ret < 0)
- goto out_unlock;
- }
+ ret = ebt_compat_init_offsets(tmp.nentries);
+ if (ret < 0)
+ goto out_unlock;
ret = compat_copy_entries(entries_tmp, tmp.entries_size, );
if (ret < 0)
--
2.20.1
[PATCH AUTOSEL 5.2 055/123] netfilter: ipset: Actually allow destination MAC address for hash:ip,mac sets too
From: Stefano Brivio
[ Upstream commit b89d15480d0cacacae1a0fe0b3da01b529f2914f ]
In commit 8cc4ccf58379 ("ipset: Allow matching on destination MAC address
for mac and ipmac sets"), ipset.git commit 1543514c46a7, I removed the
KADT check that prevents matching on destination MAC addresses for
hash:mac sets, but forgot to remove the same check for hash:ip,mac set.
Drop this check: functionality is now commented in man pages and there's
no reason to restrict to source MAC address matching anymore.
Reported-by: Chen Yi
Fixes: 8cc4ccf58379 ("ipset: Allow matching on destination MAC address for mac
and ipmac sets")
Signed-off-by: Stefano Brivio
Signed-off-by: Jozsef Kadlecsik
Signed-off-by: Sasha Levin
---
net/netfilter/ipset/ip_set_hash_ipmac.c | 4
1 file changed, 4 deletions(-)
diff --git a/net/netfilter/ipset/ip_set_hash_ipmac.c
b/net/netfilter/ipset/ip_set_hash_ipmac.c
index faf59b6a998fe..eb14434083203 100644
--- a/net/netfilter/ipset/ip_set_hash_ipmac.c
+++ b/net/netfilter/ipset/ip_set_hash_ipmac.c
@@ -89,10 +89,6 @@ hash_ipmac4_kadt(struct ip_set *set, const struct sk_buff
*skb,
struct hash_ipmac4_elem e = { .ip = 0, { .foo[0] = 0, .foo[1] = 0 } };
struct ip_set_ext ext = IP_SET_INIT_KEXT(skb, opt, set);
-/* MAC can be src only */
- if (!(opt->flags & IPSET_DIM_TWO_SRC))
- return 0;
-
if (skb_mac_header(skb) < skb->head ||
(skb_mac_header(skb) + ETH_HLEN) > skb->data)
return -EINVAL;
--
2.20.1
[PATCH AUTOSEL 5.2 057/123] netfilter: ipset: Fix rename concurrency with listing
From: Jozsef Kadlecsik
[ Upstream commit 6c1f7e2c1b96ab9b09ac97c4df2bd9dc327206f6 ]
Shijie Luo reported that when stress-testing ipset with multiple concurrent
create, rename, flush, list, destroy commands, it can result
ipset : Broken LIST kernel message: missing DATA part!
error messages and broken list results. The problem was the rename operation
was not properly handled with respect of listing. The patch fixes the issue.
Reported-by: Shijie Luo
Signed-off-by: Jozsef Kadlecsik
Signed-off-by: Sasha Levin
---
net/netfilter/ipset/ip_set_core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/netfilter/ipset/ip_set_core.c
b/net/netfilter/ipset/ip_set_core.c
index 16afa0df4004d..e103c875383a5 100644
--- a/net/netfilter/ipset/ip_set_core.c
+++ b/net/netfilter/ipset/ip_set_core.c
@@ -1161,7 +1161,7 @@ static int ip_set_rename(struct net *net, struct sock
*ctnl,
return -ENOENT;
write_lock_bh(_set_ref_lock);
- if (set->ref != 0) {
+ if (set->ref != 0 || set->ref_netlink != 0) {
ret = -IPSET_ERR_REFERENCED;
goto out;
}
--
2.20.1
[PATCH AUTOSEL 5.2 068/123] enetc: Fix build error without PHYLIB
From: YueHaibing
[ Upstream commit 5f4e4203add2b860d2345312509a160f8292063b ]
If PHYLIB is not set, build enetc will fails:
drivers/net/ethernet/freescale/enetc/enetc.o: In function `enetc_open':
enetc.c: undefined reference to `phy_disconnect'
enetc.c: undefined reference to `phy_start'
drivers/net/ethernet/freescale/enetc/enetc.o: In function `enetc_close':
enetc.c: undefined reference to `phy_stop'
enetc.c: undefined reference to `phy_disconnect'
drivers/net/ethernet/freescale/enetc/enetc_ethtool.o: undefined reference to
`phy_ethtool_get_link_ksettings'
drivers/net/ethernet/freescale/enetc/enetc_ethtool.o: undefined reference to
`phy_ethtool_set_link_ksettings'
drivers/net/ethernet/freescale/enetc/enetc_mdio.o: In function
`enetc_mdio_probe':
enetc_mdio.c: undefined reference to `mdiobus_alloc_size'
enetc_mdio.c: undefined reference to `mdiobus_free'
Reported-by: Hulk Robot
Fixes: d4fd0404c1c9 ("enetc: Introduce basic PF and VF ENETC ethernet drivers")
Signed-off-by: YueHaibing
Acked-by: Claudiu Manoil
Signed-off-by: David S. Miller
Signed-off-by: Sasha Levin
---
drivers/net/ethernet/freescale/enetc/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/ethernet/freescale/enetc/Kconfig
b/drivers/net/ethernet/freescale/enetc/Kconfig
index 8429f5c1d8106..8ac109e73a7bb 100644
--- a/drivers/net/ethernet/freescale/enetc/Kconfig
+++ b/drivers/net/ethernet/freescale/enetc/Kconfig
@@ -2,6 +2,7 @@
config FSL_ENETC
tristate "ENETC PF driver"
depends on PCI && PCI_MSI && (ARCH_LAYERSCAPE || COMPILE_TEST)
+ select PHYLIB
help
This driver supports NXP ENETC gigabit ethernet controller PCIe
physical function (PF) devices, managing ENETC Ports at a privileged
--
2.20.1
[PATCH AUTOSEL 5.2 067/123] driver core: Fix use-after-free and double free on glue directory
From: Muchun Song
[ Upstream commit ac43432cb1f5c2950408534987e57c2071e24d8f ]
There is a race condition between removing glue directory and adding a new
device under the glue dir. It can be reproduced in following test:
CPU1: CPU2:
device_add()
get_device_parent()
class_dir_create_and_add()
kobject_add_internal()
create_dir()// create glue_dir
device_add()
get_device_parent()
kobject_get() // get glue_dir
device_del()
cleanup_glue_dir()
kobject_del(glue_dir)
kobject_add()
kobject_add_internal()
create_dir() // in glue_dir
sysfs_create_dir_ns()
kernfs_create_dir_ns(sd)
sysfs_remove_dir() // glue_dir->sd=NULL
sysfs_put()// free glue_dir->sd
// sd is freed
kernfs_new_node(sd)
kernfs_get(glue_dir)
kernfs_add_one()
kernfs_put()
Before CPU1 remove last child device under glue dir, if CPU2 add a new
device under glue dir, the glue_dir kobject reference count will be
increase to 2 via kobject_get() in get_device_parent(). And CPU2 has
been called kernfs_create_dir_ns(), but not call kernfs_new_node().
Meanwhile, CPU1 call sysfs_remove_dir() and sysfs_put(). This result in
glue_dir->sd is freed and it's reference count will be 0. Then CPU2 call
kernfs_get(glue_dir) will trigger a warning in kernfs_get() and increase
it's reference count to 1. Because glue_dir->sd is freed by CPU1, the next
call kernfs_add_one() by CPU2 will fail(This is also use-after-free)
and call kernfs_put() to decrease reference count. Because the reference
count is decremented to 0, it will also call kmem_cache_free() to free
the glue_dir->sd again. This will result in double free.
In order to avoid this happening, we also should make sure that kernfs_node
for glue_dir is released in CPU1 only when refcount for glue_dir kobj is
1 to fix this race.
The following calltrace is captured in kernel 4.14 with the following patch
applied:
commit 726e41097920 ("drivers: core: Remove glue dirs from sysfs earlier")
--
[3.633703] WARNING: CPU: 4 PID: 513 at .../fs/kernfs/dir.c:494
Here is WARN_ON(!atomic_read(>count) in kernfs_get().
[3.633986] Call trace:
[3.633991] kernfs_create_dir_ns+0xa8/0xb0
[3.633994] sysfs_create_dir_ns+0x54/0xe8
[3.634001] kobject_add_internal+0x22c/0x3f0
[3.634005] kobject_add+0xe4/0x118
[3.634011] device_add+0x200/0x870
[3.634017] _request_firmware+0x958/0xc38
[3.634020] request_firmware_into_buf+0x4c/0x70
[3.634064] kernel BUG at .../mm/slub.c:294!
Here is BUG_ON(object == fp) in set_freepointer().
[3.634346] Call trace:
[3.634351] kmem_cache_free+0x504/0x6b8
[3.634355] kernfs_put+0x14c/0x1d8
[3.634359] kernfs_create_dir_ns+0x88/0xb0
[3.634362] sysfs_create_dir_ns+0x54/0xe8
[3.634366] kobject_add_internal+0x22c/0x3f0
[3.634370] kobject_add+0xe4/0x118
[3.634374] device_add+0x200/0x870
[3.634378] _request_firmware+0x958/0xc38
[3.634381] request_firmware_into_buf+0x4c/0x70
--
Fixes: 726e41097920 ("drivers: core: Remove glue dirs from sysfs earlier")
Signed-off-by: Muchun Song
Reviewed-by: Mukesh Ojha
Signed-off-by: Prateek Sood
Link: https://lore.kernel.org/r/20190727032122.24639-1-smuc...@gmail.com
Signed-off-by: Greg Kroah-Hartman
Signed-off-by: Sasha Levin
---
drivers/base/core.c | 53 -
1 file changed, 52 insertions(+), 1 deletion(-)
diff --git a/drivers/base/core.c b/drivers/base/core.c
index eaf3aa0cb8031..2dc0123cbba12 100644
--- a/drivers/base/core.c
+++ b/drivers/base/core.c
@@ -1820,12 +1820,63 @@ static inline struct kobject *get_glue_dir(struct
device *dev)
*/
static void cleanup_glue_dir(struct device *dev, struct kobject *glue_dir)
{
+ unsigned int ref;
+
/* see if we live in a "glue" directory */
if (!live_in_glue_dir(glue_dir, dev))
return;
mutex_lock(_mutex);
- if (!kobject_has_children(glue_dir))
+ /**
+* There is a race condition between removing glue directory
+* and adding a new device under the glue
[PATCH AUTOSEL 5.2 063/123] iwlwifi: dbg_ini: move iwl_dbg_tlv_load_bin out of debug override ifdef
From: Shahar S Matityahu
[ Upstream commit 072b30642f90b01d139131ec7bf763778a3a3f41 ]
ini debug mode should work even if debug override is not defined.
Signed-off-by: Shahar S Matityahu
Fixes: 68f6f492c4fa ("iwlwifi: trans: support loading ini TLVs from external
file")
Signed-off-by: Luca Coelho
Signed-off-by: Johannes Berg
Signed-off-by: Sasha Levin
---
drivers/net/wireless/intel/iwlwifi/iwl-drv.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/wireless/intel/iwlwifi/iwl-drv.c
b/drivers/net/wireless/intel/iwlwifi/iwl-drv.c
index fba242284507b..efd4bf04d0162 100644
--- a/drivers/net/wireless/intel/iwlwifi/iwl-drv.c
+++ b/drivers/net/wireless/intel/iwlwifi/iwl-drv.c
@@ -1627,6 +1627,8 @@ struct iwl_drv *iwl_drv_start(struct iwl_trans *trans)
init_completion(>request_firmware_complete);
INIT_LIST_HEAD(>list);
+ iwl_load_fw_dbg_tlv(drv->trans->dev, drv->trans);
+
#ifdef CONFIG_IWLWIFI_DEBUGFS
/* Create the device debugfs entries. */
drv->dbgfs_drv = debugfs_create_dir(dev_name(trans->dev),
--
2.20.1
[PATCH AUTOSEL 5.2 064/123] iwlwifi: dbg_ini: move iwl_dbg_tlv_free outside of debugfs ifdef
From: Shahar S Matityahu
[ Upstream commit abcbef5977df1fb61026ba429964cd6b9a085699 ]
The driver should call iwl_dbg_tlv_free even if debugfs is not defined
since ini mode does not depend on debugfs ifdef.
Signed-off-by: Shahar S Matityahu
Fixes: 68f6f492c4fa ("iwlwifi: trans: support loading ini TLVs from external
file")
Signed-off-by: Luca Coelho
Signed-off-by: Johannes Berg
Signed-off-by: Sasha Levin
---
drivers/net/wireless/intel/iwlwifi/iwl-drv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/intel/iwlwifi/iwl-drv.c
b/drivers/net/wireless/intel/iwlwifi/iwl-drv.c
index efd4bf04d0162..fa81ad67539f3 100644
--- a/drivers/net/wireless/intel/iwlwifi/iwl-drv.c
+++ b/drivers/net/wireless/intel/iwlwifi/iwl-drv.c
@@ -1649,8 +1649,8 @@ struct iwl_drv *iwl_drv_start(struct iwl_trans *trans)
err_fw:
#ifdef CONFIG_IWLWIFI_DEBUGFS
debugfs_remove_recursive(drv->dbgfs_drv);
- iwl_fw_dbg_free(drv->trans);
#endif
+ iwl_fw_dbg_free(drv->trans);
kfree(drv);
err:
return ERR_PTR(ret);
--
2.20.1
[PATCH AUTOSEL 5.2 073/123] net: usb: pegasus: fix improper read if get_registers() fail
From: Denis Kirjanov
[ Upstream commit 224c04973db1125fcebefffd86115f99f50f8277 ]
get_registers() may fail with -ENOMEM and in this
case we can read a garbage from the status variable tmp.
Reported-by: syzbot+3499a83b2d062ae40...@syzkaller.appspotmail.com
Signed-off-by: Denis Kirjanov
Signed-off-by: David S. Miller
Signed-off-by: Sasha Levin
---
drivers/net/usb/pegasus.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/usb/pegasus.c b/drivers/net/usb/pegasus.c
index 6d25dea5ad4b2..f7d117d80cfbb 100644
--- a/drivers/net/usb/pegasus.c
+++ b/drivers/net/usb/pegasus.c
@@ -282,7 +282,7 @@ static void mdio_write(struct net_device *dev, int phy_id,
int loc, int val)
static int read_eprom_word(pegasus_t *pegasus, __u8 index, __u16 *retdata)
{
int i;
- __u8 tmp;
+ __u8 tmp = 0;
__le16 retdatai;
int ret;
--
2.20.1
[PATCHv6 2/2] PCI: layerscape: Add CONFIG_PCI_LAYERSCAPE_EP to build EP/RC separately
Add CONFIG_PCI_LAYERSCAPE_EP to build EP/RC separately. Signed-off-by: Xiaowei Bao --- v2: - No change. v3: - modify the commit message. v4: - send the patch again with '--to'. v5: - No change. v6: - remove the [EXT] tag of the $SUBJECT in email. drivers/pci/controller/dwc/Kconfig | 20 ++-- drivers/pci/controller/dwc/Makefile | 3 ++- 2 files changed, 20 insertions(+), 3 deletions(-) diff --git a/drivers/pci/controller/dwc/Kconfig b/drivers/pci/controller/dwc/Kconfig index 6ea778a..869c645 100644 --- a/drivers/pci/controller/dwc/Kconfig +++ b/drivers/pci/controller/dwc/Kconfig @@ -131,13 +131,29 @@ config PCI_KEYSTONE_EP DesignWare core functions to implement the driver. config PCI_LAYERSCAPE - bool "Freescale Layerscape PCIe controller" + bool "Freescale Layerscape PCIe controller - Host mode" depends on OF && (ARM || ARCH_LAYERSCAPE || COMPILE_TEST) depends on PCI_MSI_IRQ_DOMAIN select MFD_SYSCON select PCIE_DW_HOST help - Say Y here if you want PCIe controller support on Layerscape SoCs. + Say Y here if you want to enable PCIe controller support on Layerscape + SoCs to work in Host mode. + This controller can work either as EP or RC. The RCW[HOST_AGT_PEX] + determines which PCIe controller works in EP mode and which PCIe + controller works in RC mode. + +config PCI_LAYERSCAPE_EP + bool "Freescale Layerscape PCIe controller - Endpoint mode" + depends on OF && (ARM || ARCH_LAYERSCAPE || COMPILE_TEST) + depends on PCI_ENDPOINT + select PCIE_DW_EP + help + Say Y here if you want to enable PCIe controller support on Layerscape + SoCs to work in Endpoint mode. + This controller can work either as EP or RC. The RCW[HOST_AGT_PEX] + determines which PCIe controller works in EP mode and which PCIe + controller works in RC mode. config PCI_HISI depends on OF && (ARM64 || COMPILE_TEST) diff --git a/drivers/pci/controller/dwc/Makefile b/drivers/pci/controller/dwc/Makefile index b085dfd..824fde7 100644 --- a/drivers/pci/controller/dwc/Makefile +++ b/drivers/pci/controller/dwc/Makefile @@ -8,7 +8,8 @@ obj-$(CONFIG_PCI_EXYNOS) += pci-exynos.o obj-$(CONFIG_PCI_IMX6) += pci-imx6.o obj-$(CONFIG_PCIE_SPEAR13XX) += pcie-spear13xx.o obj-$(CONFIG_PCI_KEYSTONE) += pci-keystone.o -obj-$(CONFIG_PCI_LAYERSCAPE) += pci-layerscape.o pci-layerscape-ep.o +obj-$(CONFIG_PCI_LAYERSCAPE) += pci-layerscape.o +obj-$(CONFIG_PCI_LAYERSCAPE_EP) += pci-layerscape-ep.o obj-$(CONFIG_PCIE_QCOM) += pcie-qcom.o obj-$(CONFIG_PCIE_ARMADA_8K) += pcie-armada8k.o obj-$(CONFIG_PCIE_ARTPEC6) += pcie-artpec6.o -- 2.9.5
[PATCH AUTOSEL 5.2 069/123] isdn: hfcsusb: Fix mISDN driver crash caused by transfer buffer on the stack
From: Juliana Rodrigueiro
[ Upstream commit d8a1de3d5bb881507602bc02e004904828f88711 ]
Since linux 4.9 it is not possible to use buffers on the stack for DMA
transfers.
During usb probe the driver crashes with "transfer buffer is on stack" message.
This fix k-allocates a buffer to be used on "read_reg_atomic", which is a macro
that calls "usb_control_msg" under the hood.
Kernel 4.19 backtrace:
usb_hcd_submit_urb+0x3e5/0x900
? sched_clock+0x9/0x10
? log_store+0x203/0x270
? get_random_u32+0x6f/0x90
? cache_alloc_refill+0x784/0x8a0
usb_submit_urb+0x3b4/0x550
usb_start_wait_urb+0x4e/0xd0
usb_control_msg+0xb8/0x120
hfcsusb_probe+0x6bc/0xb40 [hfcsusb]
usb_probe_interface+0xc2/0x260
really_probe+0x176/0x280
driver_probe_device+0x49/0x130
__driver_attach+0xa9/0xb0
? driver_probe_device+0x130/0x130
bus_for_each_dev+0x5a/0x90
driver_attach+0x14/0x20
? driver_probe_device+0x130/0x130
bus_add_driver+0x157/0x1e0
driver_register+0x51/0xe0
usb_register_driver+0x5d/0x120
? 0xf81ed000
hfcsusb_drv_init+0x17/0x1000 [hfcsusb]
do_one_initcall+0x44/0x190
? free_unref_page_commit+0x6a/0xd0
do_init_module+0x46/0x1c0
load_module+0x1dc1/0x2400
sys_init_module+0xed/0x120
do_fast_syscall_32+0x7a/0x200
entry_SYSENTER_32+0x6b/0xbe
Signed-off-by: Juliana Rodrigueiro
Signed-off-by: David S. Miller
Signed-off-by: Sasha Levin
---
drivers/isdn/hardware/mISDN/hfcsusb.c | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/drivers/isdn/hardware/mISDN/hfcsusb.c
b/drivers/isdn/hardware/mISDN/hfcsusb.c
index 8fb7c5dea07fc..008a74a1ed444 100644
--- a/drivers/isdn/hardware/mISDN/hfcsusb.c
+++ b/drivers/isdn/hardware/mISDN/hfcsusb.c
@@ -1693,13 +1693,23 @@ hfcsusb_stop_endpoint(struct hfcsusb *hw, int channel)
static int
setup_hfcsusb(struct hfcsusb *hw)
{
+ void *dmabuf = kmalloc(sizeof(u_char), GFP_KERNEL);
u_char b;
+ int ret;
if (debug & DBG_HFC_CALL_TRACE)
printk(KERN_DEBUG "%s: %s\n", hw->name, __func__);
+ if (!dmabuf)
+ return -ENOMEM;
+
+ ret = read_reg_atomic(hw, HFCUSB_CHIP_ID, dmabuf);
+
+ memcpy(, dmabuf, sizeof(u_char));
+ kfree(dmabuf);
+
/* check the chip id */
- if (read_reg_atomic(hw, HFCUSB_CHIP_ID, ) != 1) {
+ if (ret != 1) {
printk(KERN_DEBUG "%s: %s: cannot read chip id\n",
hw->name, __func__);
return 1;
--
2.20.1
[PATCH AUTOSEL 5.2 070/123] net: phy: phy_led_triggers: Fix a possible null-pointer dereference in phy_led_trigger_change_speed()
From: Jia-Ju Bai [ Upstream commit 271da132e29b5341c31eca6ba6a72ea1302ebac8 ] In phy_led_trigger_change_speed(), there is an if statement on line 48 to check whether phy->last_triggered is NULL: if (!phy->last_triggered) When phy->last_triggered is NULL, it is used on line 52: led_trigger_event(>last_triggered->trigger, LED_OFF); Thus, a possible null-pointer dereference may occur. To fix this bug, led_trigger_event(>last_triggered->trigger, LED_OFF) is called when phy->last_triggered is not NULL. This bug is found by a static analysis tool STCheck written by the OSLAB group in Tsinghua University. Signed-off-by: Jia-Ju Bai Signed-off-by: David S. Miller Signed-off-by: Sasha Levin --- drivers/net/phy/phy_led_triggers.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/net/phy/phy_led_triggers.c b/drivers/net/phy/phy_led_triggers.c index b86a4b2116f81..59a94e07e7c55 100644 --- a/drivers/net/phy/phy_led_triggers.c +++ b/drivers/net/phy/phy_led_triggers.c @@ -48,8 +48,9 @@ void phy_led_trigger_change_speed(struct phy_device *phy) if (!phy->last_triggered) led_trigger_event(>led_link_trigger->trigger, LED_FULL); + else + led_trigger_event(>last_triggered->trigger, LED_OFF); - led_trigger_event(>last_triggered->trigger, LED_OFF); led_trigger_event(>trigger, LED_FULL); phy->last_triggered = plt; } -- 2.20.1
[PATCH AUTOSEL 5.2 066/123] iwlwifi: mvm: send LQ command always ASYNC
From: Gregory Greenman
[ Upstream commit cd4d6b0bcd51580efda9ae54ab7b2d630b4147dc ]
The only place where the command was sent as SYNC is during
init and this is not really critical. This change is required
for replacing RS mutex with a spinlock (in the subsequent patch),
since SYNC comamnd requres sleeping and thus the flow cannot
be done when holding a spinlock.
Signed-off-by: Gregory Greenman
Signed-off-by: Luca Coelho
Signed-off-by: Johannes Berg
Signed-off-by: Sasha Levin
---
drivers/net/wireless/intel/iwlwifi/mvm/mvm.h | 2 +-
drivers/net/wireless/intel/iwlwifi/mvm/rs.c | 23 ++-
drivers/net/wireless/intel/iwlwifi/mvm/sta.c | 2 +-
.../net/wireless/intel/iwlwifi/mvm/utils.c| 4 ++--
4 files changed, 16 insertions(+), 15 deletions(-)
diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/mvm.h
b/drivers/net/wireless/intel/iwlwifi/mvm/mvm.h
index 88af1f0ba3f0f..31c8636b2a3f8 100644
--- a/drivers/net/wireless/intel/iwlwifi/mvm/mvm.h
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/mvm.h
@@ -1806,7 +1806,7 @@ iwl_mvm_vif_dbgfs_clean(struct iwl_mvm *mvm, struct
ieee80211_vif *vif)
#endif /* CONFIG_IWLWIFI_DEBUGFS */
/* rate scaling */
-int iwl_mvm_send_lq_cmd(struct iwl_mvm *mvm, struct iwl_lq_cmd *lq, bool sync);
+int iwl_mvm_send_lq_cmd(struct iwl_mvm *mvm, struct iwl_lq_cmd *lq);
void iwl_mvm_update_frame_stats(struct iwl_mvm *mvm, u32 rate, bool agg);
int rs_pretty_print_rate(char *buf, int bufsz, const u32 rate);
void rs_update_last_rssi(struct iwl_mvm *mvm,
diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/rs.c
b/drivers/net/wireless/intel/iwlwifi/mvm/rs.c
index 836541caa3167..01b032f18bc8b 100644
--- a/drivers/net/wireless/intel/iwlwifi/mvm/rs.c
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/rs.c
@@ -1326,7 +1326,7 @@ void iwl_mvm_rs_tx_status(struct iwl_mvm *mvm, struct
ieee80211_sta *sta,
IWL_DEBUG_RATE(mvm,
"Too many rates mismatch. Send sync LQ.
rs_state %d\n",
lq_sta->rs_state);
- iwl_mvm_send_lq_cmd(mvm, _sta->lq, false);
+ iwl_mvm_send_lq_cmd(mvm, _sta->lq);
}
/* Regardless, ignore this status info for outdated rate */
return;
@@ -1388,7 +1388,8 @@ void iwl_mvm_rs_tx_status(struct iwl_mvm *mvm, struct
ieee80211_sta *sta,
if (info->status.ampdu_ack_len == 0)
info->status.ampdu_len = 1;
- rs_collect_tlc_data(mvm, mvmsta, tid, curr_tbl,
tx_resp_rate.index,
+ rs_collect_tlc_data(mvm, mvmsta, tid, curr_tbl,
+ tx_resp_rate.index,
info->status.ampdu_len,
info->status.ampdu_ack_len);
@@ -1823,7 +1824,7 @@ static void rs_update_rate_tbl(struct iwl_mvm *mvm,
struct iwl_scale_tbl_info *tbl)
{
rs_fill_lq_cmd(mvm, sta, lq_sta, >rate);
- iwl_mvm_send_lq_cmd(mvm, _sta->lq, false);
+ iwl_mvm_send_lq_cmd(mvm, _sta->lq);
}
static bool rs_tweak_rate_tbl(struct iwl_mvm *mvm,
@@ -2925,7 +2926,7 @@ void rs_update_last_rssi(struct iwl_mvm *mvm,
static void rs_initialize_lq(struct iwl_mvm *mvm,
struct ieee80211_sta *sta,
struct iwl_lq_sta *lq_sta,
-enum nl80211_band band, bool update)
+enum nl80211_band band)
{
struct iwl_scale_tbl_info *tbl;
struct rs_rate *rate;
@@ -2955,7 +2956,7 @@ static void rs_initialize_lq(struct iwl_mvm *mvm,
rs_set_expected_tpt_table(lq_sta, tbl);
rs_fill_lq_cmd(mvm, sta, lq_sta, rate);
/* TODO restore station should remember the lq cmd */
- iwl_mvm_send_lq_cmd(mvm, _sta->lq, !update);
+ iwl_mvm_send_lq_cmd(mvm, _sta->lq);
}
static void rs_drv_get_rate(void *mvm_r, struct ieee80211_sta *sta,
@@ -3208,7 +3209,7 @@ void iwl_mvm_update_frame_stats(struct iwl_mvm *mvm, u32
rate, bool agg)
* Called after adding a new station to initialize rate scaling
*/
static void rs_drv_rate_init(struct iwl_mvm *mvm, struct ieee80211_sta *sta,
-enum nl80211_band band, bool update)
+enum nl80211_band band)
{
int i, j;
struct ieee80211_hw *hw = mvm->hw;
@@ -3288,7 +3289,7 @@ static void rs_drv_rate_init(struct iwl_mvm *mvm, struct
ieee80211_sta *sta,
#ifdef CONFIG_IWLWIFI_DEBUGFS
iwl_mvm_reset_frame_stats(mvm);
#endif
- rs_initialize_lq(mvm, sta, lq_sta, band, update);
+ rs_initialize_lq(mvm, sta, lq_sta, band);
}
static void rs_drv_rate_update(void *mvm_r,
@@ -3602,7 +3603,7 @@ static void rs_set_lq_ss_params(struct iwl_mvm *mvm,
bfersta_ss_params &= ~LQ_SS_BFER_ALLOWED;
bfersta_lq_cmd->ss_params = cpu_to_le32(bfersta_ss_params);
-
[PATCH AUTOSEL 5.2 074/123] spi: pxa2xx: Add support for Intel Tiger Lake
From: Jarkko Nikula
[ Upstream commit a4127952859a869cf3fc5a49547dbe2ffa2eac89 ]
Intel Tiger Lake -LP LPSS SPI controller is otherwise similar than
Cannon Lake but has more controllers and up to two chip selects per
controller.
Signed-off-by: Jarkko Nikula
Link:
https://lore.kernel.org/r/20190801134901.12635-1-jarkko.nik...@linux.intel.com
Signed-off-by: Mark Brown
Signed-off-by: Sasha Levin
---
drivers/spi/spi-pxa2xx.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/spi/spi-pxa2xx.c b/drivers/spi/spi-pxa2xx.c
index c1af8887d9186..1f32c9e3ca65c 100644
--- a/drivers/spi/spi-pxa2xx.c
+++ b/drivers/spi/spi-pxa2xx.c
@@ -1453,6 +1453,14 @@ static const struct pci_device_id
pxa2xx_spi_pci_compound_match[] = {
{ PCI_VDEVICE(INTEL, 0x02aa), LPSS_CNL_SSP },
{ PCI_VDEVICE(INTEL, 0x02ab), LPSS_CNL_SSP },
{ PCI_VDEVICE(INTEL, 0x02fb), LPSS_CNL_SSP },
+ /* TGL-LP */
+ { PCI_VDEVICE(INTEL, 0xa0aa), LPSS_CNL_SSP },
+ { PCI_VDEVICE(INTEL, 0xa0ab), LPSS_CNL_SSP },
+ { PCI_VDEVICE(INTEL, 0xa0de), LPSS_CNL_SSP },
+ { PCI_VDEVICE(INTEL, 0xa0df), LPSS_CNL_SSP },
+ { PCI_VDEVICE(INTEL, 0xa0fb), LPSS_CNL_SSP },
+ { PCI_VDEVICE(INTEL, 0xa0fd), LPSS_CNL_SSP },
+ { PCI_VDEVICE(INTEL, 0xa0fe), LPSS_CNL_SSP },
{ },
};
--
2.20.1
[PATCH AUTOSEL 5.2 080/123] NFSv4: Fix a credential refcount leak in nfs41_check_delegation_stateid
From: Trond Myklebust [ Upstream commit 8c39a39e28b86a4021d9be314ce01019bafa5fdc ] It is unsafe to dereference delegation outside the rcu lock, and in any case, the refcount is guaranteed held if cred is non-zero. Signed-off-by: Trond Myklebust Signed-off-by: Sasha Levin --- fs/nfs/nfs4proc.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/fs/nfs/nfs4proc.c b/fs/nfs/nfs4proc.c index 6418cb6c079bd..11a5aa46e64c3 100644 --- a/fs/nfs/nfs4proc.c +++ b/fs/nfs/nfs4proc.c @@ -2749,8 +2749,7 @@ static void nfs41_check_delegation_stateid(struct nfs4_state *state) if (status == -NFS4ERR_EXPIRED || status == -NFS4ERR_BAD_STATEID) nfs_finish_clear_delegation_stateid(state, ); - if (delegation->cred) - put_cred(cred); + put_cred(cred); } /** -- 2.20.1
[PATCH AUTOSEL 5.2 079/123] enetc: Select PHYLIB while CONFIG_FSL_ENETC_VF is set
From: YueHaibing
[ Upstream commit 2802d2cf24b1ca7ea4c54dde266ded6a16020eb5 ]
Like FSL_ENETC, when CONFIG_FSL_ENETC_VF is set,
we should select PHYLIB, otherwise building still fails:
drivers/net/ethernet/freescale/enetc/enetc.o: In function `enetc_open':
enetc.c:(.text+0x2744): undefined reference to `phy_start'
enetc.c:(.text+0x282c): undefined reference to `phy_disconnect'
drivers/net/ethernet/freescale/enetc/enetc.o: In function `enetc_close':
enetc.c:(.text+0x28f8): undefined reference to `phy_stop'
enetc.c:(.text+0x2904): undefined reference to `phy_disconnect'
drivers/net/ethernet/freescale/enetc/enetc_ethtool.o:(.rodata+0x3f8): undefined
reference to `phy_ethtool_get_link_ksettings'
drivers/net/ethernet/freescale/enetc/enetc_ethtool.o:(.rodata+0x400): undefined
reference to `phy_ethtool_set_link_ksettings'
Reported-by: Hulk Robot
Fixes: d4fd0404c1c9 ("enetc: Introduce basic PF and VF ENETC ethernet drivers")
Signed-off-by: YueHaibing
Signed-off-by: David S. Miller
Signed-off-by: Sasha Levin
---
drivers/net/ethernet/freescale/enetc/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/ethernet/freescale/enetc/Kconfig
b/drivers/net/ethernet/freescale/enetc/Kconfig
index 8ac109e73a7bb..a268e74b1834e 100644
--- a/drivers/net/ethernet/freescale/enetc/Kconfig
+++ b/drivers/net/ethernet/freescale/enetc/Kconfig
@@ -13,6 +13,7 @@ config FSL_ENETC
config FSL_ENETC_VF
tristate "ENETC VF driver"
depends on PCI && PCI_MSI && (ARCH_LAYERSCAPE || COMPILE_TEST)
+ select PHYLIB
help
This driver supports NXP ENETC gigabit ethernet controller PCIe
virtual function (VF) devices enabled by the ENETC PF driver.
--
2.20.1
[PATCH AUTOSEL 5.2 082/123] NFSv4.1: Fix open stateid recovery
From: Trond Myklebust
[ Upstream commit 27a30cf64a5cbe2105e4ff9613246b32d584766a ]
The logic for checking in nfs41_check_open_stateid() whether the state
is supported by a delegation is inverted. In addition, it makes more
sense to perform that check before we check for expired locks.
Fixes: 8a64c4ef106d1 ("NFSv4.1: Even if the stateid is OK,...")
Signed-off-by: Trond Myklebust
Signed-off-by: Sasha Levin
---
fs/nfs/nfs4proc.c | 65 +++
1 file changed, 38 insertions(+), 27 deletions(-)
diff --git a/fs/nfs/nfs4proc.c b/fs/nfs/nfs4proc.c
index 11a5aa46e64c3..b3fd75c8629a4 100644
--- a/fs/nfs/nfs4proc.c
+++ b/fs/nfs/nfs4proc.c
@@ -1654,6 +1654,14 @@ static void nfs_state_set_open_stateid(struct nfs4_state
*state,
write_sequnlock(>seqlock);
}
+static void nfs_state_clear_open_state_flags(struct nfs4_state *state)
+{
+ clear_bit(NFS_O_RDWR_STATE, >flags);
+ clear_bit(NFS_O_WRONLY_STATE, >flags);
+ clear_bit(NFS_O_RDONLY_STATE, >flags);
+ clear_bit(NFS_OPEN_STATE, >flags);
+}
+
static void nfs_state_set_delegation(struct nfs4_state *state,
const nfs4_stateid *deleg_stateid,
fmode_t fmode)
@@ -2045,13 +2053,7 @@ static int nfs4_open_recover(struct nfs4_opendata
*opendata, struct nfs4_state *
{
int ret;
- /* Don't trigger recovery in nfs_test_and_clear_all_open_stateid */
- clear_bit(NFS_O_RDWR_STATE, >flags);
- clear_bit(NFS_O_WRONLY_STATE, >flags);
- clear_bit(NFS_O_RDONLY_STATE, >flags);
/* memory barrier prior to reading state->n_* */
- clear_bit(NFS_DELEGATED_STATE, >flags);
- clear_bit(NFS_OPEN_STATE, >flags);
smp_rmb();
ret = nfs4_open_recover_helper(opendata, FMODE_READ|FMODE_WRITE);
if (ret != 0)
@@ -2127,6 +2129,8 @@ static int nfs4_open_reclaim(struct nfs4_state_owner *sp,
struct nfs4_state *sta
ctx = nfs4_state_find_open_context(state);
if (IS_ERR(ctx))
return -EAGAIN;
+ clear_bit(NFS_DELEGATED_STATE, >flags);
+ nfs_state_clear_open_state_flags(state);
ret = nfs4_do_open_reclaim(ctx, state);
put_nfs_open_context(ctx);
return ret;
@@ -2669,6 +2673,7 @@ static int nfs40_open_expired(struct nfs4_state_owner
*sp, struct nfs4_state *st
{
/* NFSv4.0 doesn't allow for delegation recovery on open expire */
nfs40_clear_delegation_stateid(state);
+ nfs_state_clear_open_state_flags(state);
return nfs4_open_expired(sp, state);
}
@@ -2711,13 +2716,13 @@ static int nfs41_test_and_free_expired_stateid(struct
nfs_server *server,
return -NFS4ERR_EXPIRED;
}
-static void nfs41_check_delegation_stateid(struct nfs4_state *state)
+static int nfs41_check_delegation_stateid(struct nfs4_state *state)
{
struct nfs_server *server = NFS_SERVER(state->inode);
nfs4_stateid stateid;
struct nfs_delegation *delegation;
const struct cred *cred = NULL;
- int status;
+ int status, ret = NFS_OK;
/* Get the delegation credential for use by test/free_stateid */
rcu_read_lock();
@@ -2725,20 +2730,15 @@ static void nfs41_check_delegation_stateid(struct
nfs4_state *state)
if (delegation == NULL) {
rcu_read_unlock();
nfs_state_clear_delegation(state);
- return;
+ return NFS_OK;
}
nfs4_stateid_copy(, >stateid);
- if (test_bit(NFS_DELEGATION_REVOKED, >flags)) {
- rcu_read_unlock();
- nfs_state_clear_delegation(state);
- return;
- }
if (!test_and_clear_bit(NFS_DELEGATION_TEST_EXPIRED,
>flags)) {
rcu_read_unlock();
- return;
+ return NFS_OK;
}
if (delegation->cred)
@@ -2748,8 +2748,24 @@ static void nfs41_check_delegation_stateid(struct
nfs4_state *state)
trace_nfs4_test_delegation_stateid(state, NULL, status);
if (status == -NFS4ERR_EXPIRED || status == -NFS4ERR_BAD_STATEID)
nfs_finish_clear_delegation_stateid(state, );
+ else
+ ret = status;
put_cred(cred);
+ return ret;
+}
+
+static void nfs41_delegation_recover_stateid(struct nfs4_state *state)
+{
+ nfs4_stateid tmp;
+
+ if (test_bit(NFS_DELEGATED_STATE, >flags) &&
+ nfs4_copy_delegation_stateid(state->inode, state->state,
+ , NULL) &&
+ nfs4_stateid_match_other(>stateid, ))
+ nfs_state_set_delegation(state, , state->state);
+ else
+ nfs_state_clear_delegation(state);
}
/**
@@ -2819,21 +2835,12 @@ static int nfs41_check_open_stateid(struct nfs4_state
*state)
const struct cred *cred = state->owner->so_cred;
int status;
- if (test_bit(NFS_OPEN_STATE, >flags) == 0) {
- if
[PATCH AUTOSEL 5.2 081/123] NFSv4: When recovering state fails with EAGAIN, retry the same recovery
From: Trond Myklebust
[ Upstream commit c34fae003c79570b6c930b425fea3f0b7b1e7056 ]
If the server returns with EAGAIN when we're trying to recover from
a server reboot, we currently delay for 1 second, but then mark the
stateid as needing recovery after the grace period has expired.
Instead, we should just retry the same recovery process immediately
after the 1 second delay. Break out of the loop after 10 retries.
Fixes: 35a61606a612 ("NFS: Reduce indentation of the switch statement...")
Signed-off-by: Trond Myklebust
Signed-off-by: Sasha Levin
---
fs/nfs/nfs4state.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/fs/nfs/nfs4state.c b/fs/nfs/nfs4state.c
index e2e3c4f04d3e0..556ec916846f0 100644
--- a/fs/nfs/nfs4state.c
+++ b/fs/nfs/nfs4state.c
@@ -1606,6 +1606,7 @@ static int __nfs4_reclaim_open_state(struct
nfs4_state_owner *sp, struct nfs4_st
static int nfs4_reclaim_open_state(struct nfs4_state_owner *sp, const struct
nfs4_state_recovery_ops *ops)
{
struct nfs4_state *state;
+ unsigned int loop = 0;
int status = 0;
/* Note: we rely on the sp->so_states list being ordered
@@ -1632,8 +1633,10 @@ static int nfs4_reclaim_open_state(struct
nfs4_state_owner *sp, const struct nfs
switch (status) {
default:
- if (status >= 0)
+ if (status >= 0) {
+ loop = 0;
break;
+ }
printk(KERN_ERR "NFS: %s: unhandled error %d\n",
__func__, status);
/* Fall through */
case -ENOENT:
@@ -1647,6 +1650,10 @@ static int nfs4_reclaim_open_state(struct
nfs4_state_owner *sp, const struct nfs
break;
case -EAGAIN:
ssleep(1);
+ if (loop++ < 10) {
+ set_bit(ops->state_flag_bit, >flags);
+ break;
+ }
/* Fall through */
case -NFS4ERR_ADMIN_REVOKED:
case -NFS4ERR_STALE_STATEID:
--
2.20.1
[PATCH AUTOSEL 5.2 077/123] ASoC: amd: acp3x: use dma_ops of parent device for acp3x dma driver
From: Vijendar Mukunda
[ Upstream commit 88639051017fb61a414b636dd0fc490da2b62b64 ]
AMD platform device acp3x_rv_i2s created by parent PCI device
driver. Pass struct device of the parent to
snd_pcm_lib_preallocate_pages() so dma_alloc_coherent() can use
correct dma_ops. Otherwise, it will use default dma_ops which
is nommu_dma_ops on x86_64 even when IOMMU is enabled and
set to non passthrough mode.
Signed-off-by: Vijendar Mukunda
Link:
https://lore.kernel.org/r/1564753899-17124-1-git-send-email-vijendar.muku...@amd.com
Signed-off-by: Mark Brown
Signed-off-by: Sasha Levin
---
sound/soc/amd/raven/acp3x-pcm-dma.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/sound/soc/amd/raven/acp3x-pcm-dma.c
b/sound/soc/amd/raven/acp3x-pcm-dma.c
index 9775bda2a4ca3..d8aa6ab3f68bc 100644
--- a/sound/soc/amd/raven/acp3x-pcm-dma.c
+++ b/sound/soc/amd/raven/acp3x-pcm-dma.c
@@ -367,9 +367,11 @@ static snd_pcm_uframes_t acp3x_dma_pointer(struct
snd_pcm_substream *substream)
static int acp3x_dma_new(struct snd_soc_pcm_runtime *rtd)
{
+ struct snd_soc_component *component = snd_soc_rtdcom_lookup(rtd,
+ DRV_NAME);
+ struct device *parent = component->dev->parent;
snd_pcm_lib_preallocate_pages_for_all(rtd->pcm, SNDRV_DMA_TYPE_DEV,
- rtd->pcm->card->dev,
- MIN_BUFFER, MAX_BUFFER);
+ parent, MIN_BUFFER, MAX_BUFFER);
return 0;
}
--
2.20.1
[PATCH AUTOSEL 5.2 085/123] NFS: Fix regression whereby fscache errors are appearing on 'nofsc' mounts
From: Trond Myklebust
[ Upstream commit dea1bb35c5f35e0577cfc61f79261d80b8715221 ]
People are reporing seeing fscache errors being reported concerning
duplicate cookies even in cases where they are not setting up fscache
at all. The rule needs to be that if fscache is not enabled, then it
should have no side effects at all.
To ensure this is the case, we disable fscache completely on all superblocks
for which the 'fsc' mount option was not set. In order to avoid issues
with '-oremount', we also disable the ability to turn fscache on via
remount.
Fixes: f1fe29b4a02d ("NFS: Use i_writecount to control whether...")
Link: https://bugzilla.kernel.org/show_bug.cgi?id=200145
Signed-off-by: Trond Myklebust
Cc: Steve Dickson
Cc: David Howells
Signed-off-by: Sasha Levin
---
fs/nfs/fscache.c | 7 ++-
fs/nfs/fscache.h | 2 +-
fs/nfs/super.c | 1 +
3 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/fs/nfs/fscache.c b/fs/nfs/fscache.c
index 53507aa96b0b6..3800ab6f08fa8 100644
--- a/fs/nfs/fscache.c
+++ b/fs/nfs/fscache.c
@@ -114,6 +114,10 @@ void nfs_fscache_get_super_cookie(struct super_block *sb,
const char *uniq, int
struct rb_node **p, *parent;
int diff;
+ nfss->fscache_key = NULL;
+ nfss->fscache = NULL;
+ if (!(nfss->options & NFS_OPTION_FSCACHE))
+ return;
if (!uniq) {
uniq = "";
ulen = 1;
@@ -226,10 +230,11 @@ void nfs_fscache_release_super_cookie(struct super_block
*sb)
void nfs_fscache_init_inode(struct inode *inode)
{
struct nfs_fscache_inode_auxdata auxdata;
+ struct nfs_server *nfss = NFS_SERVER(inode);
struct nfs_inode *nfsi = NFS_I(inode);
nfsi->fscache = NULL;
- if (!S_ISREG(inode->i_mode))
+ if (!(nfss->fscache && S_ISREG(inode->i_mode)))
return;
memset(, 0, sizeof(auxdata));
diff --git a/fs/nfs/fscache.h b/fs/nfs/fscache.h
index 25a75e40d91d9..ad041cfbf9ec0 100644
--- a/fs/nfs/fscache.h
+++ b/fs/nfs/fscache.h
@@ -182,7 +182,7 @@ static inline void nfs_fscache_wait_on_invalidate(struct
inode *inode)
*/
static inline const char *nfs_server_fscache_state(struct nfs_server *server)
{
- if (server->fscache && (server->options & NFS_OPTION_FSCACHE))
+ if (server->fscache)
return "yes";
return "no ";
}
diff --git a/fs/nfs/super.c b/fs/nfs/super.c
index f88ddac2dcdf3..4d375b517eda8 100644
--- a/fs/nfs/super.c
+++ b/fs/nfs/super.c
@@ -2239,6 +2239,7 @@ nfs_compare_remount_data(struct nfs_server *nfss,
data->acdirmin != nfss->acdirmin / HZ ||
data->acdirmax != nfss->acdirmax / HZ ||
data->timeo != (10U * nfss->client->cl_timeout->to_initval / HZ) ||
+ (data->options & NFS_OPTION_FSCACHE) != (nfss->options &
NFS_OPTION_FSCACHE) ||
data->nfs_server.port != nfss->port ||
data->nfs_server.addrlen != nfss->nfs_client->cl_addrlen ||
!rpc_cmp_addr((struct sockaddr *)>nfs_server.address,
--
2.20.1
[PATCH AUTOSEL 5.2 086/123] HID: quirks: Set the INCREMENT_USAGE_ON_DUPLICATE quirk on Saitek X52
From: István Váradi
[ Upstream commit 7bc74853fd61432ec59f812a40425bf6d8c986a4 ]
The Saitek X52 joystick has a pair of axes that are originally
(by the Windows driver) used as mouse pointer controls. The corresponding
usage->hid values are 0x50024 and 0x50026. Thus they are handled
as unknown axes and both get mapped to ABS_MISC. The quirk makes
the second axis to be mapped to ABS_MISC1 and thus made available
separately.
[jkos...@suse.cz: squashed two patches into one]
Signed-off-by: István Váradi
Signed-off-by: Jiri Kosina
Signed-off-by: Sasha Levin
---
drivers/hid/hid-ids.h| 1 +
drivers/hid/hid-quirks.c | 1 +
2 files changed, 2 insertions(+)
diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
index 34a812025b948..76aa474e92c15 100644
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -990,6 +990,7 @@
#define USB_DEVICE_ID_SAITEK_RAT7 0x0cd7
#define USB_DEVICE_ID_SAITEK_RAT9 0x0cfa
#define USB_DEVICE_ID_SAITEK_MMO7 0x0cd0
+#define USB_DEVICE_ID_SAITEK_X52 0x075c
#define USB_VENDOR_ID_SAMSUNG 0x0419
#define USB_DEVICE_ID_SAMSUNG_IR_REMOTE0x0001
diff --git a/drivers/hid/hid-quirks.c b/drivers/hid/hid-quirks.c
index 5b669f7d653fa..4fe2c3ab76f9c 100644
--- a/drivers/hid/hid-quirks.c
+++ b/drivers/hid/hid-quirks.c
@@ -141,6 +141,7 @@ static const struct hid_device_id hid_quirks[] = {
{ HID_USB_DEVICE(USB_VENDOR_ID_RETROUSB,
USB_DEVICE_ID_RETROUSB_SNES_RETROPAD), HID_QUIRK_INCREMENT_USAGE_ON_DUPLICATE },
{ HID_USB_DEVICE(USB_VENDOR_ID_RETROUSB,
USB_DEVICE_ID_RETROUSB_SNES_RETROPORT), HID_QUIRK_INCREMENT_USAGE_ON_DUPLICATE
},
{ HID_USB_DEVICE(USB_VENDOR_ID_SAITEK, USB_DEVICE_ID_SAITEK_RUMBLEPAD),
HID_QUIRK_BADPAD },
+ { HID_USB_DEVICE(USB_VENDOR_ID_SAITEK, USB_DEVICE_ID_SAITEK_X52),
HID_QUIRK_INCREMENT_USAGE_ON_DUPLICATE },
{ HID_USB_DEVICE(USB_VENDOR_ID_SEMICO,
USB_DEVICE_ID_SEMICO_USB_KEYKOARD2), HID_QUIRK_NO_INIT_REPORTS },
{ HID_USB_DEVICE(USB_VENDOR_ID_SEMICO,
USB_DEVICE_ID_SEMICO_USB_KEYKOARD), HID_QUIRK_NO_INIT_REPORTS },
{ HID_USB_DEVICE(USB_VENDOR_ID_SENNHEISER,
USB_DEVICE_ID_SENNHEISER_BTD500USB), HID_QUIRK_NOGET },
--
2.20.1
[PATCH AUTOSEL 5.2 100/123] ata: rb532_cf: Fix unused variable warning in rb532_pata_driver_probe
From: "Gustavo A. R. Silva"
[ Upstream commit db341a049ec7e87053c91008cb452d0bfa6dde72 ]
Fix the following warning (Building: rb532_defconfig mips):
drivers/ata/pata_rb532_cf.c: In function ‘rb532_pata_driver_remove’:
drivers/ata/pata_rb532_cf.c:161:24: warning: unused variable ‘info’
[-Wunused-variable]
struct rb532_cf_info *info = ah->private_data;
^~~~
Fixes: cd56f35e52d9 ("ata: rb532_cf: Convert to use GPIO descriptors")
Signed-off-by: Gustavo A. R. Silva
Signed-off-by: Jens Axboe
Signed-off-by: Sasha Levin
---
drivers/ata/pata_rb532_cf.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/ata/pata_rb532_cf.c b/drivers/ata/pata_rb532_cf.c
index 7c37f2ff09e41..deae466395de1 100644
--- a/drivers/ata/pata_rb532_cf.c
+++ b/drivers/ata/pata_rb532_cf.c
@@ -158,7 +158,6 @@ static int rb532_pata_driver_probe(struct platform_device
*pdev)
static int rb532_pata_driver_remove(struct platform_device *pdev)
{
struct ata_host *ah = platform_get_drvdata(pdev);
- struct rb532_cf_info *info = ah->private_data;
ata_host_detach(ah);
--
2.20.1
[PATCH AUTOSEL 5.2 095/123] sched/psi: Reduce psimon FIFO priority
From: Peter Zijlstra
[ Upstream commit 14f5c7b46a41a595fc61db37f55721714729e59e ]
PSI defaults to a FIFO-99 thread, reduce this to FIFO-1.
FIFO-99 is the very highest priority available to SCHED_FIFO and
it not a suitable default; it would indicate the psi work is the
most important work on the machine.
Since Real-Time tasks will have pre-allocated memory and locked it in
place, Real-Time tasks do not care about PSI. All it needs is to be
above OTHER.
Signed-off-by: Peter Zijlstra (Intel)
Acked-by: Johannes Weiner
Tested-by: Suren Baghdasaryan
Cc: Thomas Gleixner
Signed-off-by: Sasha Levin
---
kernel/sched/psi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/sched/psi.c b/kernel/sched/psi.c
index 7acc632c3b82b..7fe2c5fd26b54 100644
--- a/kernel/sched/psi.c
+++ b/kernel/sched/psi.c
@@ -1051,7 +1051,7 @@ struct psi_trigger *psi_trigger_create(struct psi_group
*group,
if (!rcu_access_pointer(group->poll_kworker)) {
struct sched_param param = {
- .sched_priority = MAX_RT_PRIO - 1,
+ .sched_priority = 1,
};
struct kthread_worker *kworker;
--
2.20.1
[PATCH AUTOSEL 5.2 099/123] s390: put _stext and _etext into .text section
From: Vasily Gorbik
[ Upstream commit 24350fdadbdec780406a1ef988e6cd3875e374a8 ]
Perf relies on _etext and _stext symbols being one of 't', 'T', 'v' or
'V'. Put them into .text section to guarantee that.
Also moves padding to page boundary inside .text which has an effect that
.text section is now padded with nops rather than 0's, which apparently
has been the initial intention for specifying 0x0700 fill expression.
Reported-by: Thomas Richter
Tested-by: Thomas Richter
Suggested-by: Andreas Krebbel
Signed-off-by: Vasily Gorbik
Signed-off-by: Sasha Levin
---
arch/s390/kernel/vmlinux.lds.S | 10 --
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/arch/s390/kernel/vmlinux.lds.S b/arch/s390/kernel/vmlinux.lds.S
index 49d55327de0bc..7e0eb40209177 100644
--- a/arch/s390/kernel/vmlinux.lds.S
+++ b/arch/s390/kernel/vmlinux.lds.S
@@ -32,10 +32,9 @@ PHDRS {
SECTIONS
{
. = 0x10;
- _stext = .; /* Start of text section */
.text : {
- /* Text and read-only data */
- _text = .;
+ _stext = .; /* Start of text section */
+ _text = .; /* Text and read-only data */
HEAD_TEXT
TEXT_TEXT
SCHED_TEXT
@@ -47,11 +46,10 @@ SECTIONS
*(.text.*_indirect_*)
*(.fixup)
*(.gnu.warning)
+ . = ALIGN(PAGE_SIZE);
+ _etext = .; /* End of text section */
} :text = 0x0700
- . = ALIGN(PAGE_SIZE);
- _etext = .; /* End of text section */
-
NOTES :text :note
.dummy : { *(.dummy) } :data
--
2.20.1
[PATCH AUTOSEL 5.2 091/123] SMB3: Kernel oops mounting a encryptData share with CONFIG_DEBUG_VIRTUAL
From: Sebastien Tisserant
[ Upstream commit ee9d66182392695535cc9fccfcb40c16f72de2a9 ]
Fix kernel oops when mounting a encryptData CIFS share with
CONFIG_DEBUG_VIRTUAL
Signed-off-by: Sebastien Tisserant
Reviewed-by: Pavel Shilovsky
Signed-off-by: Steve French
Signed-off-by: Sasha Levin
---
fs/cifs/smb2ops.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/fs/cifs/smb2ops.c b/fs/cifs/smb2ops.c
index ae10d6e297c3a..42de31d206169 100644
--- a/fs/cifs/smb2ops.c
+++ b/fs/cifs/smb2ops.c
@@ -3439,7 +3439,15 @@ fill_transform_hdr(struct smb2_transform_hdr *tr_hdr,
unsigned int orig_len,
static inline void smb2_sg_set_buf(struct scatterlist *sg, const void *buf,
unsigned int buflen)
{
- sg_set_page(sg, virt_to_page(buf), buflen, offset_in_page(buf));
+ void *addr;
+ /*
+* VMAP_STACK (at least) puts stack into the vmalloc address space
+*/
+ if (is_vmalloc_addr(buf))
+ addr = vmalloc_to_page(buf);
+ else
+ addr = virt_to_page(buf);
+ sg_set_page(sg, addr, buflen, offset_in_page(buf));
}
/* Assumes the first rqst has a transform header as the first iov.
--
2.20.1
[PATCH AUTOSEL 5.2 089/123] drm/rockchip: Suspend DP late
From: Douglas Anderson
[ Upstream commit f7ccbed656f78212593ca965d9a8f34bf24e0aab ]
In commit fe64ba5c6323 ("drm/rockchip: Resume DP early") we moved
resume to be early but left suspend at its normal time. This seems
like it could be OK, but casues problems if a suspend gets interrupted
partway through. The OS only balances matching suspend/resume levels.
...so if suspend was called then resume will be called. If suspend
late was called then resume early will be called. ...but if suspend
was called resume early might not get called. This leads to an
unbalance in the clock enables / disables.
Lets take the simple fix and just move suspend to be late to match.
This makes the PM core take proper care in keeping things balanced.
Fixes: fe64ba5c6323 ("drm/rockchip: Resume DP early")
Signed-off-by: Douglas Anderson
Signed-off-by: Sean Paul
Link:
https://patchwork.freedesktop.org/patch/msgid/20190802184616.44822-1-diand...@chromium.org
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/rockchip/analogix_dp-rockchip.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
index 95e5c517a15f7..9aae3d8e99ef4 100644
--- a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
+++ b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
@@ -432,7 +432,7 @@ static int rockchip_dp_resume(struct device *dev)
static const struct dev_pm_ops rockchip_dp_pm_ops = {
#ifdef CONFIG_PM_SLEEP
- .suspend = rockchip_dp_suspend,
+ .suspend_late = rockchip_dp_suspend,
.resume_early = rockchip_dp_resume,
#endif
};
--
2.20.1
[PATCH AUTOSEL 5.2 096/123] sched/psi: Do not require setsched permission from the trigger creator
From: Suren Baghdasaryan [ Upstream commit 04e048cf09d7b5fc995817cdc5ae1acd4482429c ] When a process creates a new trigger by writing into /proc/pressure/* files, permissions to write such a file should be used to determine whether the process is allowed to do so or not. Current implementation would also require such a process to have setsched capability. Setting of psi trigger thread's scheduling policy is an implementation detail and should not be exposed to the user level. Remove the permission check by using _nocheck version of the function. Suggested-by: Nick Kralevich Signed-off-by: Suren Baghdasaryan Signed-off-by: Peter Zijlstra (Intel) Cc: lize...@huawei.com Cc: mi...@redhat.com Cc: a...@linux-foundation.org Cc: kernel-t...@android.com Cc: dennissz...@gmail.com Cc: den...@kernel.org Cc: han...@cmpxchg.org Cc: ax...@kernel.dk Link: https://lkml.kernel.org/r/20190730013310.162367-1-sur...@google.com Signed-off-by: Sasha Levin --- kernel/sched/psi.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kernel/sched/psi.c b/kernel/sched/psi.c index 7fe2c5fd26b54..23fbbcc414d5d 100644 --- a/kernel/sched/psi.c +++ b/kernel/sched/psi.c @@ -1061,7 +1061,7 @@ struct psi_trigger *psi_trigger_create(struct psi_group *group, mutex_unlock(>trigger_lock); return ERR_CAST(kworker); } - sched_setscheduler(kworker->task, SCHED_FIFO, ); + sched_setscheduler_nocheck(kworker->task, SCHED_FIFO, ); kthread_init_delayed_work(>poll_work, psi_poll_work); rcu_assign_pointer(group->poll_kworker, kworker); -- 2.20.1
[PATCH AUTOSEL 5.2 103/123] net: stmmac: Fix issues when number of Queues >= 4
From: Jose Abreu [ Upstream commit e8df7e8c233a18d2704e37ecff47583b494789d3 ] When queues >= 4 we use different registers but we were not subtracting the offset of 4. Fix this. Found out by Coverity. Signed-off-by: Jose Abreu Signed-off-by: David S. Miller Signed-off-by: Sasha Levin --- drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c | 4 drivers/net/ethernet/stmicro/stmmac/dwxgmac2_core.c | 4 2 files changed, 8 insertions(+) diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c b/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c index e3850938cf2f3..d7bf0ad954b8c 100644 --- a/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c @@ -85,6 +85,8 @@ static void dwmac4_rx_queue_priority(struct mac_device_info *hw, u32 value; base_register = (queue < 4) ? GMAC_RXQ_CTRL2 : GMAC_RXQ_CTRL3; + if (queue >= 4) + queue -= 4; value = readl(ioaddr + base_register); @@ -102,6 +104,8 @@ static void dwmac4_tx_queue_priority(struct mac_device_info *hw, u32 value; base_register = (queue < 4) ? GMAC_TXQ_PRTY_MAP0 : GMAC_TXQ_PRTY_MAP1; + if (queue >= 4) + queue -= 4; value = readl(ioaddr + base_register); diff --git a/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_core.c b/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_core.c index 64b8cb88ea45d..d4bd99770f5d1 100644 --- a/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_core.c +++ b/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_core.c @@ -106,6 +106,8 @@ static void dwxgmac2_rx_queue_prio(struct mac_device_info *hw, u32 prio, u32 value, reg; reg = (queue < 4) ? XGMAC_RXQ_CTRL2 : XGMAC_RXQ_CTRL3; + if (queue >= 4) + queue -= 4; value = readl(ioaddr + reg); value &= ~XGMAC_PSRQ(queue); @@ -169,6 +171,8 @@ static void dwxgmac2_map_mtl_to_dma(struct mac_device_info *hw, u32 queue, u32 value, reg; reg = (queue < 4) ? XGMAC_MTL_RXQ_DMA_MAP0 : XGMAC_MTL_RXQ_DMA_MAP1; + if (queue >= 4) + queue -= 4; value = readl(ioaddr + reg); value &= ~XGMAC_QxMDMACH(queue); -- 2.20.1
[PATCH AUTOSEL 5.2 105/123] drm/amdgpu: pin the csb buffer on hw init for gfx v8
From: Likun Gao
[ Upstream commit 72cda9bb5e219aea0f2f62f56ae05198c59022a7 ]
Without this pin, the csb buffer will be filled with inconsistent
data after S3 resume. And that will causes gfx hang on gfxoff
exit since this csb will be executed then.
Signed-off-by: Likun Gao
Tested-by: Paul Gover
Reviewed-by: Feifei Xu
Reviewed-by: Xiaojie Yuan
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c | 40 +++
1 file changed, 40 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
b/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
index 02955e6e9dd9e..c21ef99cc590f 100644
--- a/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
@@ -1317,6 +1317,39 @@ static int gfx_v8_0_rlc_init(struct amdgpu_device *adev)
return 0;
}
+static int gfx_v8_0_csb_vram_pin(struct amdgpu_device *adev)
+{
+ int r;
+
+ r = amdgpu_bo_reserve(adev->gfx.rlc.clear_state_obj, false);
+ if (unlikely(r != 0))
+ return r;
+
+ r = amdgpu_bo_pin(adev->gfx.rlc.clear_state_obj,
+ AMDGPU_GEM_DOMAIN_VRAM);
+ if (!r)
+ adev->gfx.rlc.clear_state_gpu_addr =
+ amdgpu_bo_gpu_offset(adev->gfx.rlc.clear_state_obj);
+
+ amdgpu_bo_unreserve(adev->gfx.rlc.clear_state_obj);
+
+ return r;
+}
+
+static void gfx_v8_0_csb_vram_unpin(struct amdgpu_device *adev)
+{
+ int r;
+
+ if (!adev->gfx.rlc.clear_state_obj)
+ return;
+
+ r = amdgpu_bo_reserve(adev->gfx.rlc.clear_state_obj, true);
+ if (likely(r == 0)) {
+ amdgpu_bo_unpin(adev->gfx.rlc.clear_state_obj);
+ amdgpu_bo_unreserve(adev->gfx.rlc.clear_state_obj);
+ }
+}
+
static void gfx_v8_0_mec_fini(struct amdgpu_device *adev)
{
amdgpu_bo_free_kernel(>gfx.mec.hpd_eop_obj, NULL, NULL);
@@ -4777,6 +4810,10 @@ static int gfx_v8_0_hw_init(void *handle)
gfx_v8_0_init_golden_registers(adev);
gfx_v8_0_constants_init(adev);
+ r = gfx_v8_0_csb_vram_pin(adev);
+ if (r)
+ return r;
+
r = adev->gfx.rlc.funcs->resume(adev);
if (r)
return r;
@@ -4893,6 +4930,9 @@ static int gfx_v8_0_hw_fini(void *handle)
else
pr_err("rlc is busy, skip halt rlc\n");
amdgpu_gfx_rlc_exit_safe_mode(adev);
+
+ gfx_v8_0_csb_vram_unpin(adev);
+
return 0;
}
--
2.20.1
[PATCH AUTOSEL 5.2 101/123] Input: iforce - add sanity checks
From: Oliver Neukum [ Upstream commit 849f5ae3a513c550cad741c68dd3d7eb2bcc2a2c ] The endpoint type should also be checked before a device is accepted. Reported-by: syzbot+5efc10c005014d061...@syzkaller.appspotmail.com Signed-off-by: Oliver Neukum Signed-off-by: Dmitry Torokhov Signed-off-by: Sasha Levin --- drivers/input/joystick/iforce/iforce-usb.c | 5 + 1 file changed, 5 insertions(+) diff --git a/drivers/input/joystick/iforce/iforce-usb.c b/drivers/input/joystick/iforce/iforce-usb.c index f1569ae8381bc..a0a686f56ac4f 100644 --- a/drivers/input/joystick/iforce/iforce-usb.c +++ b/drivers/input/joystick/iforce/iforce-usb.c @@ -129,7 +129,12 @@ static int iforce_usb_probe(struct usb_interface *intf, return -ENODEV; epirq = >endpoint[0].desc; + if (!usb_endpoint_is_int_in(epirq)) + return -ENODEV; + epout = >endpoint[1].desc; + if (!usb_endpoint_is_int_out(epout)) + return -ENODEV; if (!(iforce = kzalloc(sizeof(struct iforce) + 32, GFP_KERNEL))) goto fail; -- 2.20.1
[PATCH AUTOSEL 4.19 10/68] net: mvpp2: Don't check for 3 consecutive Idle frames for 10G links
From: Maxime Chevallier
[ Upstream commit bba18318e7d1d5c8b0bbafd65010a0cee3c65608 ]
PPv2's XLGMAC can wait for 3 idle frames before triggering a link up
event. This can cause the link to be stuck low when there's traffic on
the interface, so disable this feature.
Fixes: 4bb043262878 ("net: mvpp2: phylink support")
Signed-off-by: Maxime Chevallier
Signed-off-by: David S. Miller
Signed-off-by: Sasha Levin
---
drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
index 6455511457ca3..9b608d23ff7ee 100644
--- a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
+++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
@@ -4412,9 +4412,9 @@ static void mvpp2_xlg_config(struct mvpp2_port *port,
unsigned int mode,
if (state->pause & MLO_PAUSE_RX)
ctrl0 |= MVPP22_XLG_CTRL0_RX_FLOW_CTRL_EN;
- ctrl4 &= ~MVPP22_XLG_CTRL4_MACMODSELECT_GMAC;
- ctrl4 |= MVPP22_XLG_CTRL4_FWD_FC | MVPP22_XLG_CTRL4_FWD_PFC |
-MVPP22_XLG_CTRL4_EN_IDLE_CHECK;
+ ctrl4 &= ~(MVPP22_XLG_CTRL4_MACMODSELECT_GMAC |
+ MVPP22_XLG_CTRL4_EN_IDLE_CHECK);
+ ctrl4 |= MVPP22_XLG_CTRL4_FWD_FC | MVPP22_XLG_CTRL4_FWD_PFC;
writel(ctrl0, port->base + MVPP22_XLG_CTRL0_REG);
writel(ctrl4, port->base + MVPP22_XLG_CTRL4_REG);
--
2.20.1
