Re: [RFC PATCH v1 1/2] virt: memctl: control guest physical memory properties

2024-05-14 Thread Greg Kroah-Hartman
On Tue, May 14, 2024 at 06:21:57PM -0700, Yuanchu Xie wrote:
> On Tue, May 14, 2024 at 9:06 AM Greg Kroah-Hartman
>  wrote:
> >
> > On Mon, May 13, 2024 at 07:03:00PM -0700, Yuanchu Xie wrote:
> > > Memctl provides a way for the guest to control its physical memory
> > > properties, and enables optimizations and security features. For
> > > example, the guest can provide information to the host where parts of a
> > > hugepage may be unbacked, or sensitive data may not be swapped out, etc.
> > >...
> > Pretty generic name for a hardware-specific driver :(
> It's not for real hardware btw. Its use case is similar to pvpanic
> where the device is emulated by the VMM. I can change the name if it's
> a problem.

This file is only used for a single PCI device, that is very
hardware-specific even if that hardware is "fake" :)

Please make the name more specific as well.

thanks,

greg k-h



Re: [RFC PATCH v1 1/2] virt: memctl: control guest physical memory properties

2024-05-14 Thread Greg Kroah-Hartman
On Mon, May 13, 2024 at 07:03:00PM -0700, Yuanchu Xie wrote:
> +/*
> + * Used for internal kernel memctl calls, i.e. to better support kernel 
> stacks,
> + * or to efficiently zero hugetlb pages.
> + */
> +long memctl_vmm_call(__u64 func_code, __u64 addr, __u64 length, __u64 arg,
> +  struct memctl_buf *buf)
> +{
> + buf->call.func_code = func_code;
> + buf->call.addr = addr;
> + buf->call.length = length;
> + buf->call.arg = arg;
> +
> + return __memctl_vmm_call(buf);
> +}
> +EXPORT_SYMBOL(memctl_vmm_call);

You export something that is never actually called, which implies that
this is not tested at all (i.e. it is dead code.)  Please remove.

Also, why not EXPORT_SYMBOL_GPL()?   (I have to ask, sorry.)

thanks,

greg k-h



Re: [RFC PATCH v1 1/2] virt: memctl: control guest physical memory properties

2024-05-14 Thread Greg Kroah-Hartman
On Mon, May 13, 2024 at 07:03:00PM -0700, Yuanchu Xie wrote:
> Memctl provides a way for the guest to control its physical memory
> properties, and enables optimizations and security features. For
> example, the guest can provide information to the host where parts of a
> hugepage may be unbacked, or sensitive data may not be swapped out, etc.
> 
> Memctl allows guests to manipulate its gPTE entries in the SLAT, and
> also some other properties of the memory map the back's host memory.
> This is achieved by using the KVM_CAP_SYNC_MMU capability. When this
> capability is available, the changes in the backing of the memory region
> on the host are automatically reflected into the guest. For example, an
> mmap() or madvise() that affects the region will be made visible
> immediately.
> 
> There are two components of the implementation: the guest Linux driver
> and Virtual Machine Monitor (VMM) device. A guest-allocated shared
> buffer is negotiated per-cpu through a few PCI MMIO registers, the VMM
> device assigns a unique command for each per-cpu buffer. The guest
> writes its memctl request in the per-cpu buffer, then writes the
> corresponding command into the command register, calling into the VMM
> device to perform the memctl request.
> 
> The synchronous per-cpu shared buffer approach avoids the kick and busy
> waiting that the guest would have to do with virtio virtqueue transport.
> 
> We provide both kernel and userspace APIs
> Kernel API
> long memctl_vmm_call(__u64 func_code, __u64 addr, __u64 length, __u64 arg,
>struct memctl_buf *buf);
> 
> Kernel drivers can take advantage of the memctl calls to provide
> paravirtualization of kernel stacks or page zeroing.
> 
> User API
> >From the userland, the memctl guest driver is controlled via ioctl(2)
> call. It requires CAP_SYS_ADMIN.
> 
> ioctl(fd, MEMCTL_IOCTL, union memctl_vmm *memctl_vmm);
> 
> Guest userland applications can tag VMAs and guest hugepages, or advise
> the host on how to handle sensitive guest pages.
> 
> Supported function codes and their use cases:
> MEMCTL_FREE/REMOVE/DONTNEED/PAGEOUT. For the guest. One can reduce the
> struct page and page table lookup overhead by using hugepages backed by
> smaller pages on the host. These memctl commands can allow for partial
> freeing of private guest hugepages to save memory. They also allow
> kernel memory, such as kernel stacks and task_structs to be
> paravirtualized.
> 
> MEMCTL_UNMERGEABLE is useful for security, when the VM does not want to
> share its backing pages.
> The same with MADV_DONTDUMP, so sensitive pages are not included in a
> dump.
> MLOCK/UNLOCK can advise the host that sensitive information is not
> swapped out on the host.
> 
> MEMCTL_MPROTECT_NONE/R/W/RW. For guest stacks backed by hugepages, stack
> guard pages can be handled in the host and memory can be saved in the
> hugepage.
> 
> MEMCTL_SET_VMA_ANON_NAME is useful for observability and debugging how
> guest memory is being mapped on the host.
> 
> Sample program making use of MEMCTL_SET_VMA_ANON_NAME and
> MEMCTL_DONTNEED:
> https://github.com/Dummyc0m/memctl-set-anon-vma-name/tree/main
> https://github.com/Dummyc0m/memctl-set-anon-vma-name/tree/dontneed
> 
> The VMM implementation is being proposed for Cloud Hypervisor:
> https://github.com/Dummyc0m/cloud-hypervisor/
> 
> Cloud Hypervisor issue:
> https://github.com/cloud-hypervisor/cloud-hypervisor/issues/6318
> 
> Signed-off-by: Yuanchu Xie 
> ---
>  .../userspace-api/ioctl/ioctl-number.rst  |   2 +
>  drivers/virt/Kconfig  |   2 +
>  drivers/virt/Makefile |   1 +
>  drivers/virt/memctl/Kconfig   |  10 +
>  drivers/virt/memctl/Makefile  |   2 +
>  drivers/virt/memctl/memctl.c  | 425 ++
>  include/linux/memctl.h|  27 ++
>  include/uapi/linux/memctl.h   |  81 

You are mixing your PCI driver in with the memctl core code, is that
intentional?  Will there never be another PCI device for this type of
interface other than this one PCI device?

And if so, why export anything, why isn't this all in one body of code?

>  8 files changed, 550 insertions(+)
>  create mode 100644 drivers/virt/memctl/Kconfig
>  create mode 100644 drivers/virt/memctl/Makefile
>  create mode 100644 drivers/virt/memctl/memctl.c
>  create mode 100644 include/linux/memctl.h
>  create mode 100644 include/uapi/linux/memctl.h
> 
> diff --git a/Documentation/userspace-api/ioctl/ioctl-number.rst 
> b/Documentation/userspace-api/ioctl/ioctl-number.rst
> index 457e16f06e04..789d1251c0be 100644
> --- a/Documentation/userspace-api/ioctl/ioctl-number.rst
> +++ b/Documentation/userspace-api/ioctl/ioctl-number.rst
> @@ -368,6 +368,8 @@ Code  Seq#Include File
>Comments
>  0xCD  01 linux/reiserfs_fs.h
>  0xCE  01-02  uapi/linux/cxl_mem.h

Re: [PATCH] Revert "tracing/trigger: Fix to return error if failed to alloc snapshot"

2024-04-19 Thread Greg Kroah-Hartman
On Thu, Apr 18, 2024 at 06:58:06PM +0530, Siddh Raman Pant wrote:
> This reverts commit b5085b5ac1d96ea2a8a6240f869655176ce44197.
> 
> The change has an incorrect assumption about the return value because
> in the current stable trees for versions 5.15 and before, the following
> commit responsible for making 0 a success value is not present:
> b8cc44a4d3c1 ("tracing: Remove logic for registering multiple event triggers 
> at a time")
> 
> The return value should be 0 on failure in the current tree, because in
> the functions event_trigger_callback() and event_enable_trigger_func(),
> we have:
> 
>   ret = cmd_ops->reg(glob, trigger_ops, trigger_data, file);
>   /*
>* The above returns on success the # of functions enabled,
>* but if it didn't find any functions it returns zero.
>* Consider no functions a failure too.
>*/
>   if (!ret) {
>   ret = -ENOENT;
> 
> Cc: sta...@kernel.org # 5.15, 5.10, 5.4, 4.19
> Signed-off-by: Siddh Raman Pant 
> ---
>  kernel/trace/trace_events_trigger.c | 6 ++
>  1 file changed, 2 insertions(+), 4 deletions(-)

Now queued up everywhere, thanks.

greg k-h



[PATCH 6.8 114/172] fs/proc: remove redundant comments from /proc/bootconfig

2024-04-15 Thread Greg Kroah-Hartman
6.8-stable review patch.  If anyone has any objections, please let me know.

--

From: Zhenhua Huang 

commit fbbdc255fbee59b4207a5398fdb4f04590681a79 upstream.

commit 717c7c894d4b ("fs/proc: Add boot loader arguments as comment to
/proc/bootconfig") adds bootloader argument comments into /proc/bootconfig.

/proc/bootconfig shows boot_command_line[] multiple times following
every xbc key value pair, that's duplicated and not necessary.
Remove redundant ones.

Output before and after the fix is like:
key1 = value1
*bootloader argument comments*
key2 = value2
*bootloader argument comments*
key3 = value3
*bootloader argument comments*
...

key1 = value1
key2 = value2
key3 = value3
*bootloader argument comments*
...

Link: https://lore.kernel.org/all/20240409044358.1156477-1-paul...@kernel.org/

Fixes: 717c7c894d4b ("fs/proc: Add boot loader arguments as comment to 
/proc/bootconfig")
Signed-off-by: Zhenhua Huang 
Signed-off-by: Paul E. McKenney 
Cc: 
Cc: 
Cc: sta...@vger.kernel.org
Acked-by: Masami Hiramatsu (Google) 
Signed-off-by: Masami Hiramatsu (Google) 
Signed-off-by: Greg Kroah-Hartman 
---
 fs/proc/bootconfig.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/fs/proc/bootconfig.c b/fs/proc/bootconfig.c
index 902b326e1e56..e5635a6b127b 100644
--- a/fs/proc/bootconfig.c
+++ b/fs/proc/bootconfig.c
@@ -62,12 +62,12 @@ static int __init copy_xbc_key_value_list(char *dst, size_t 
size)
break;
dst += ret;
}
-   if (ret >= 0 && boot_command_line[0]) {
-   ret = snprintf(dst, rest(dst, end), "# Parameters from 
bootloader:\n# %s\n",
-  boot_command_line);
-   if (ret > 0)
-   dst += ret;
-   }
+   }
+   if (ret >= 0 && boot_command_line[0]) {
+   ret = snprintf(dst, rest(dst, end), "# Parameters from 
bootloader:\n# %s\n",
+  boot_command_line);
+   if (ret > 0)
+   dst += ret;
}
 out:
kfree(key);
-- 
2.44.0






Re: [PATCH] [v4] module: don't ignore sysfs_create_link() failures

2024-04-11 Thread Greg Kroah-Hartman
On Mon, Apr 08, 2024 at 09:00:06AM -0700, Luis Chamberlain wrote:
> On Mon, Apr 08, 2024 at 10:05:58AM +0200, Arnd Bergmann wrote:
> > From: Arnd Bergmann 
> > 
> > The sysfs_create_link() return code is marked as __must_check, but the
> > module_add_driver() function tries hard to not care, by assigning the
> > return code to a variable. When building with 'make W=1', gcc still
> > warns because this variable is only assigned but not used:
> > 
> > drivers/base/module.c: In function 'module_add_driver':
> > drivers/base/module.c:36:6: warning: variable 'no_warn' set but not used 
> > [-Wunused-but-set-variable]
> > 
> > Rework the code to properly unwind and return the error code to the
> > caller. My reading of the original code was that it tries to
> > not fail when the links already exist, so keep ignoring -EEXIST
> > errors.
> > 
> > Fixes: e17e0f51aeea ("Driver core: show drivers in /sys/module/")
> > Reviewed-by: Greg Kroah-Hartman 
> 
> Reviewed-by: Luis Chamberlain 

Oh right, I should apply this, sorry about that, will go do that now...



Re: [PATCH] [v3] module: don't ignore sysfs_create_link() failures

2024-04-05 Thread Greg Kroah-Hartman
On Tue, Mar 26, 2024 at 03:57:18PM +0100, Arnd Bergmann wrote:
> From: Arnd Bergmann 
> 
> The sysfs_create_link() return code is marked as __must_check, but the
> module_add_driver() function tries hard to not care, by assigning the
> return code to a variable. When building with 'make W=1', gcc still
> warns because this variable is only assigned but not used:
> 
> drivers/base/module.c: In function 'module_add_driver':
> drivers/base/module.c:36:6: warning: variable 'no_warn' set but not used 
> [-Wunused-but-set-variable]
> 
> Rework the code to properly unwind and return the error code to the
> caller. My reading of the original code was that it tries to
> not fail when the links already exist, so keep ignoring -EEXIST
> errors.
> 
> Cc: Luis Chamberlain 
> Cc: linux-modu...@vger.kernel.org
> Cc: Greg Kroah-Hartman 
> Cc: "Rafael J. Wysocki" 
> Fixes: e17e0f51aeea ("Driver core: show drivers in /sys/module/")
> See-also: 4a7fb6363f2d ("add __must_check to device management code")
> Signed-off-by: Arnd Bergmann 
> ---
> v3: make error handling stricter, add unwinding,
>  fix build fail with CONFIG_MODULES=n
> v2: rework to actually handle the error. I have not tested the
> error handling beyond build testing, so please review carefully.
> ---
>  drivers/base/base.h   |  9 ++---
>  drivers/base/bus.c|  9 -
>  drivers/base/module.c | 42 +++---
>  3 files changed, 45 insertions(+), 15 deletions(-)

Reviewed-by: Greg Kroah-Hartman 



Re: [PATCH] [v2] module: don't ignore sysfs_create_link() failures

2024-03-23 Thread Greg Kroah-Hartman
On Fri, Mar 22, 2024 at 06:39:11PM +0100, Arnd Bergmann wrote:
> From: Arnd Bergmann 
> 
> The sysfs_create_link() return code is marked as __must_check, but the
> module_add_driver() function tries hard to not care, by assigning the
> return code to a variable. When building with 'make W=1', gcc still
> warns because this variable is only assigned but not used:
> 
> drivers/base/module.c: In function 'module_add_driver':
> drivers/base/module.c:36:6: warning: variable 'no_warn' set but not used 
> [-Wunused-but-set-variable]
> 
> Rework the code to properly unwind and return the error code to the
> caller. My reading of the original code was that it tries to
> not fail when the links already exist, so keep ignoring -EEXIST
> errors.
> 
> Cc: Luis Chamberlain 
> Cc: linux-modu...@vger.kernel.org
> Cc: Greg Kroah-Hartman 
> Cc: "Rafael J. Wysocki" 
> Fixes: e17e0f51aeea ("Driver core: show drivers in /sys/module/")
> See-also: 4a7fb6363f2d ("add __must_check to device management code")
> Signed-off-by: Arnd Bergmann 
> ---
> v2: rework to actually handle the error. I have not tested the
> error handling beyond build testing, so please review carefully.
> ---
>  drivers/base/base.h   |  2 +-
>  drivers/base/bus.c|  7 ++-
>  drivers/base/module.c | 42 +++---
>  3 files changed, 38 insertions(+), 13 deletions(-)
> 
> diff --git a/drivers/base/base.h b/drivers/base/base.h
> index 0738ccad08b2..0e04bfe02943 100644
> --- a/drivers/base/base.h
> +++ b/drivers/base/base.h
> @@ -192,7 +192,7 @@ extern struct kset *devices_kset;
>  void devices_kset_move_last(struct device *dev);
>  
>  #if defined(CONFIG_MODULES) && defined(CONFIG_SYSFS)
> -void module_add_driver(struct module *mod, struct device_driver *drv);
> +int module_add_driver(struct module *mod, struct device_driver *drv);
>  void module_remove_driver(struct device_driver *drv);
>  #else
>  static inline void module_add_driver(struct module *mod,
> diff --git a/drivers/base/bus.c b/drivers/base/bus.c
> index daee55c9b2d9..7ef75b60d331 100644
> --- a/drivers/base/bus.c
> +++ b/drivers/base/bus.c
> @@ -674,7 +674,12 @@ int bus_add_driver(struct device_driver *drv)
>   if (error)
>   goto out_del_list;
>   }
> - module_add_driver(drv->owner, drv);
> + error = module_add_driver(drv->owner, drv);
> + if (error) {
> + printk(KERN_ERR "%s: failed to create module links for %s\n",
> + __func__, drv->name);
> + goto out_del_list;

Don't we need to walk back the driver_attach() call here if this fails?

> + }
>  
>   error = driver_create_file(drv, _attr_uevent);
>   if (error) {
> diff --git a/drivers/base/module.c b/drivers/base/module.c
> index 46ad4d636731..61282eaed670 100644
> --- a/drivers/base/module.c
> +++ b/drivers/base/module.c
> @@ -30,14 +30,14 @@ static void module_create_drivers_dir(struct 
> module_kobject *mk)
>   mutex_unlock(_dir_mutex);
>  }
>  
> -void module_add_driver(struct module *mod, struct device_driver *drv)
> +int module_add_driver(struct module *mod, struct device_driver *drv)
>  {
>   char *driver_name;
> - int no_warn;
> + int ret;
>   struct module_kobject *mk = NULL;
>  
>   if (!drv)
> - return;
> + return 0;
>  
>   if (mod)
>   mk = >mkobj;
> @@ -56,17 +56,37 @@ void module_add_driver(struct module *mod, struct 
> device_driver *drv)
>   }
>  
>   if (!mk)
> - return;
> + return 0;
> +
> + ret = sysfs_create_link(>p->kobj, >kobj, "module");
> + if (ret && ret != -EEXIST)

Why would EEXIST happen here?  How can this be called twice?

> + return ret;
>  
> - /* Don't check return codes; these calls are idempotent */
> - no_warn = sysfs_create_link(>p->kobj, >kobj, "module");
>   driver_name = make_driver_name(drv);
> - if (driver_name) {
> - module_create_drivers_dir(mk);
> - no_warn = sysfs_create_link(mk->drivers_dir, >p->kobj,
> - driver_name);
> - kfree(driver_name);
> + if (!driver_name) {
> + ret = -ENOMEM;
> + goto out;
> + }
> +
> + module_create_drivers_dir(mk);
> + if (!mk->drivers_dir) {
> + ret = -EINVAL;
> + goto out;
>   }
> +
> + ret = sysfs_create_link(mk->drivers_dir, >p->kobj, driver_name);
> + if (ret && ret != -EEXIST)
> + goto out;

Same EEXIST question here.

thanks,

greg k-h



Re: [PATCH] module: silence warning about unused 'no_warn' variable

2024-03-22 Thread Greg Kroah-Hartman
On Fri, Mar 22, 2024 at 02:20:05PM +0100, Arnd Bergmann wrote:
> From: Arnd Bergmann 
> 
> The sysfs_create_link() return code is marked as __must_check, but the
> module_add_driver() function tries hard to not care, by assigning the
> return code to a variable. When building with 'make W=1', gcc still
> warns because this variable is only assigned but not used:
> 
> drivers/base/module.c: In function 'module_add_driver':
> drivers/base/module.c:36:6: warning: variable 'no_warn' set but not used 
> [-Wunused-but-set-variable]
> 
> Add an explicit cast to void to prevent this check as well.
> 
> Cc: Luis Chamberlain 
> Cc: linux-modu...@vger.kernel.org
> Cc: Greg Kroah-Hartman 
> Cc: "Rafael J. Wysocki" 
> Fixes: e17e0f51aeea ("Driver core: show drivers in /sys/module/")
> See-also: 4a7fb6363f2d ("add __must_check to device management code")
> Signed-off-by: Arnd Bergmann 
> ---
> I'm not entirely sure what bug the __must_check on sysfs_create_link()
> is trying to prevent, or why the module loader code is allowed to
> ignore this. It would be nice to have an Ack from the sysfs maintainers
> on this.

No, let's fix this properly and unwind if we can't create the link.  You
are pointing at something from 2006, so I guess we always thought "this
can not fail" and never did anything about it since then.

thanks,

greg k-h



Re: [PATCH 0/3] Fairphone 5 PMIC-GLINK support (USB-C, charger, fuel gauge)

2024-02-07 Thread Greg Kroah-Hartman
On Wed, Feb 07, 2024 at 12:20:00AM +0100, Luca Weiss wrote:
> On Tue Jan 2, 2024 at 2:53 PM CET, Greg Kroah-Hartman wrote:
> > On Tue, Jan 02, 2024 at 02:43:24PM +0100, Luca Weiss wrote:
> > > On Tue Jan 2, 2024 at 2:36 PM CET, Greg Kroah-Hartman wrote:
> > > > On Thu, Dec 21, 2023 at 02:45:26PM +0100, Luca Weiss wrote:
> > > > > On Thu Dec 21, 2023 at 1:53 PM CET, Konrad Dybcio wrote:
> > > > > > On 21.12.2023 11:34, Dmitry Baryshkov wrote:
> > > > > > > On Thu, 21 Dec 2023 at 09:33, Luca Weiss 
> > > > > > >  wrote:
> > > > > > >>
> > > > > > >> On Wed Dec 20, 2023 at 1:32 PM CET, Konrad Dybcio wrote:
> > > > > > >>> On 20.12.2023 11:02, Luca Weiss wrote:
> > > > > > >>>> This series adds all the necessary bits to enable USB-C role 
> > > > > > >>>> switching,
> > > > > > >>>> charger and fuel gauge (all via pmic-glink) on Fairphone 5.
> > > > > > >>>>
> > > > > > >>>> One thing that could be made different is the pmic-glink 
> > > > > > >>>> compatible.
> > > > > > >>>> I've chosen to use qcm6490 compatible for it and not sc7280 
> > > > > > >>>> since
> > > > > > >>>> there's plenty of firmware variety on sc7280-based platforms 
> > > > > > >>>> and they
> > > > > > >>>> might require different quirks in the future, so limit this 
> > > > > > >>>> PDOS quirk
> > > > > > >>>> to just qcm6490 for now.
> > > > > > >>>>
> > > > > > >>>> If someone thinks it should be qcom,sc7280-pmic-glink, please 
> > > > > > >>>> let me
> > > > > > >>>> know :)
> > > > > > >>> IMO it's best to continue using the "base soc" (which just so 
> > > > > > >>> happened
> > > > > > >>> to fall onto sc7280 this time around) for all compatibles, 
> > > > > > >>> unless the
> > > > > > >>> derivatives actually had changes
> > > > > > >>
> > > > > > >> Hi Konrad,
> > > > > > >>
> > > > > > >> I think at some point I asked Dmitry what he thought and he 
> > > > > > >> mentioned
> > > > > > >> qcm6490. Even found the message again:
> > > > > > >>
> > > > > > >>> well, since it is a firmware thing, you might want to emphasise 
> > > > > > >>> that.
> > > > > > >>> So from my POV qcm6490 makes more sense
> > > > > > >>
> > > > > > >> But yeah since it's likely that sc7280 firmware behaves the same 
> > > > > > >> as
> > > > > > >> qcm6490 firmware it's probably okay to use sc7280 compatible, 
> > > > > > >> worst case
> > > > > > >> we change it later :) I'll send a v2 with those changes.
> > > > > > > 
> > > > > > > Worst case we end up with sc7280 which has yet another slightly
> > > > > > > different UCSI / PMIC GLINK implementation, but the compatible 
> > > > > > > string
> > > > > > > is already taken.
> > > > > > > I still suppose that this should be a qcm6490-related string.
> > > > > > Right, let's keep qcm then
> > > > > 
> > > > > Ack from my side also. Thanks for the feedback!
> > > >
> > > > This doesn't apply to my tree, where should it be going through?
> > > 
> > > As far as I can see the dependency for the driver commit 1d103d6af241
> > > ("usb: typec: ucsi: fix UCSI on buggy Qualcomm devices") was applied to
> > > Bjorn's qcom tree, so 2/3 should also go there then.
> > > 
> > > Patch 3/3 (arm64 dts) definitely also Bjorn's qcom tree.
> > > 
> > > So that leaves patch 1/3 which Bjorn can probably pick up as well but
> > > looking at git log you also picked up some for that file in the past,
> > > dunno.
> >
> > Ok, for any remaining ones that want to be merged before 6.8-rc1 is out,
> > feel free to add my:
> >
> > Acked-by: Greg Kroah-Hartman 
> >
> > If they don't get picked up by 6.8-rc1, feel free to rebase and send it
> > for me to take through my tree.
> 
> Hi Greg,
> 
> This applies cleanly on -next as of next-20240206 still.
> 
> Could you please pick it up for v6.9? I can also send a v2 with only
> the two remaining patches (dts was applied to qcom by Bjorn already).

v2 with just the remaining patches would be great, thanks.

greg k-h



Re: [PATCH] device-dax: make dax_bus_type const

2024-02-05 Thread Greg Kroah-Hartman
On Sun, Feb 04, 2024 at 01:07:11PM -0300, Ricardo B. Marliere wrote:
> Now that the driver core can properly handle constant struct bus_type,
> move the dax_bus_type variable to be a constant structure as well,
> placing it into read-only memory which can not be modified at runtime.
> 
> Cc: Greg Kroah-Hartman 
> Suggested-by: Greg Kroah-Hartman 
> Signed-off-by: Ricardo B. Marliere 

Reviewed-by: Greg Kroah-Hartman 



Re: [PATCH] nvdimm: make nvdimm_bus_type const

2024-02-05 Thread Greg Kroah-Hartman
On Sun, Feb 04, 2024 at 05:20:07PM -0300, Ricardo B. Marliere wrote:
> Now that the driver core can properly handle constant struct bus_type,
> move the nvdimm_bus_type variable to be a constant structure as well,
> placing it into read-only memory which can not be modified at runtime.
> 
> Cc: Greg Kroah-Hartman 
> Suggested-by: Greg Kroah-Hartman 
> Signed-off-by: Ricardo B. Marliere 

Reviewed-by: Greg Kroah-Hartman 



Re: [PATCH] rpmsg: core: make rpmsg_bus const

2024-02-05 Thread Greg Kroah-Hartman
On Sun, Feb 04, 2024 at 05:32:05PM -0300, Ricardo B. Marliere wrote:
> Now that the driver core can properly handle constant struct bus_type,
> move the rpmsg_bus variable to be a constant structure as well,
> placing it into read-only memory which can not be modified at runtime.
> 
> Cc: Greg Kroah-Hartman 
> Suggested-by: Greg Kroah-Hartman 
> Signed-off-by: Ricardo B. Marliere 

Reviewed-by: Greg Kroah-Hartman 



Re: [PATCH] vdpa: make vdpa_bus const

2024-02-05 Thread Greg Kroah-Hartman
On Sun, Feb 04, 2024 at 05:50:45PM -0300, Ricardo B. Marliere wrote:
> Now that the driver core can properly handle constant struct bus_type,
> move the vdpa_bus variable to be a constant structure as well,
> placing it into read-only memory which can not be modified at runtime.
> 
> Cc: Greg Kroah-Hartman 
> Suggested-by: Greg Kroah-Hartman 
> Signed-off-by: Ricardo B. Marliere 

Reviewed-by: Greg Kroah-Hartman 



Re: [PATCH] virtio: make virtio_bus const

2024-02-05 Thread Greg Kroah-Hartman
On Sun, Feb 04, 2024 at 05:52:51PM -0300, Ricardo B. Marliere wrote:
> Now that the driver core can properly handle constant struct bus_type,
> move the virtio_bus variable to be a constant structure as well,
> placing it into read-only memory which can not be modified at runtime.
> 
> Cc: Greg Kroah-Hartman 
> Suggested-by: Greg Kroah-Hartman 
> Signed-off-by: Ricardo B. Marliere 

Reviewed-by: Greg Kroah-Hartman 



Re: [PATCH v2 0/5] PM: domains: Add helpers for multi PM domains to avoid open-coding

2024-01-26 Thread Greg Kroah-Hartman
On Fri, Jan 26, 2024 at 05:12:12PM +0100, Ulf Hansson wrote:
> On Fri, 5 Jan 2024 at 17:01, Ulf Hansson  wrote:
> >
> > Updates in v2:
> > - Ccing Daniel Baluta and Iuliana Prodan the NXP remoteproc patches 
> > to
> > requests help with testing.
> > - Fixed NULL pointer bug in patch1, pointed out by Nikunj.
> > - Added some tested/reviewed-by tags.
> >
> >
> > Attaching/detaching of a device to multiple PM domains has started to 
> > become a
> > common operation for many drivers, typically during ->probe() and 
> > ->remove().
> > In most cases, this has lead to lots of boilerplate code in the drivers.
> >
> > This series adds a pair of helper functions to manage the attach/detach of a
> > device to its multiple PM domains. Moreover, a couple of drivers have been
> > converted to use the new helpers as a proof of concept.
> >
> > Note 1)
> > The changes in the drivers have only been compile tested, while the helpers
> > have been tested along with a couple of local dummy drivers that I have 
> > hacked
> > up to model both genpd providers and genpd consumers.
> >
> > Note 2)
> > I was struggling to make up mind if we should have a separate helper to 
> > attach
> > all available power-domains described in DT, rather than providing "NULL" 
> > to the
> > dev_pm_domain_attach_list(). I decided not to, but please let me know if you
> > prefer the other option.
> >
> > Note 3)
> > For OPP integration, as a follow up I am striving to make the
> > dev_pm_opp_attach_genpd() redundant. Instead I think we should move towards
> > using dev_pm_opp_set_config()->_opp_set_required_devs(), which would allow 
> > us to
> > use the helpers that $subject series is adding.
> >
> > Kind regards
> > Ulf Hansson
> 
> Rafael, Greg, do have any objections to this series or would you be
> okay that I queue this up via my pmdomain tree?

I'll defer to Rafael here.



Re: [PATCH 0/3] Fairphone 5 PMIC-GLINK support (USB-C, charger, fuel gauge)

2024-01-02 Thread Greg Kroah-Hartman
On Tue, Jan 02, 2024 at 02:43:24PM +0100, Luca Weiss wrote:
> On Tue Jan 2, 2024 at 2:36 PM CET, Greg Kroah-Hartman wrote:
> > On Thu, Dec 21, 2023 at 02:45:26PM +0100, Luca Weiss wrote:
> > > On Thu Dec 21, 2023 at 1:53 PM CET, Konrad Dybcio wrote:
> > > > On 21.12.2023 11:34, Dmitry Baryshkov wrote:
> > > > > On Thu, 21 Dec 2023 at 09:33, Luca Weiss  
> > > > > wrote:
> > > > >>
> > > > >> On Wed Dec 20, 2023 at 1:32 PM CET, Konrad Dybcio wrote:
> > > > >>> On 20.12.2023 11:02, Luca Weiss wrote:
> > > > >>>> This series adds all the necessary bits to enable USB-C role 
> > > > >>>> switching,
> > > > >>>> charger and fuel gauge (all via pmic-glink) on Fairphone 5.
> > > > >>>>
> > > > >>>> One thing that could be made different is the pmic-glink 
> > > > >>>> compatible.
> > > > >>>> I've chosen to use qcm6490 compatible for it and not sc7280 since
> > > > >>>> there's plenty of firmware variety on sc7280-based platforms and 
> > > > >>>> they
> > > > >>>> might require different quirks in the future, so limit this PDOS 
> > > > >>>> quirk
> > > > >>>> to just qcm6490 for now.
> > > > >>>>
> > > > >>>> If someone thinks it should be qcom,sc7280-pmic-glink, please let 
> > > > >>>> me
> > > > >>>> know :)
> > > > >>> IMO it's best to continue using the "base soc" (which just so 
> > > > >>> happened
> > > > >>> to fall onto sc7280 this time around) for all compatibles, unless 
> > > > >>> the
> > > > >>> derivatives actually had changes
> > > > >>
> > > > >> Hi Konrad,
> > > > >>
> > > > >> I think at some point I asked Dmitry what he thought and he mentioned
> > > > >> qcm6490. Even found the message again:
> > > > >>
> > > > >>> well, since it is a firmware thing, you might want to emphasise 
> > > > >>> that.
> > > > >>> So from my POV qcm6490 makes more sense
> > > > >>
> > > > >> But yeah since it's likely that sc7280 firmware behaves the same as
> > > > >> qcm6490 firmware it's probably okay to use sc7280 compatible, worst 
> > > > >> case
> > > > >> we change it later :) I'll send a v2 with those changes.
> > > > > 
> > > > > Worst case we end up with sc7280 which has yet another slightly
> > > > > different UCSI / PMIC GLINK implementation, but the compatible string
> > > > > is already taken.
> > > > > I still suppose that this should be a qcm6490-related string.
> > > > Right, let's keep qcm then
> > > 
> > > Ack from my side also. Thanks for the feedback!
> >
> > This doesn't apply to my tree, where should it be going through?
> 
> As far as I can see the dependency for the driver commit 1d103d6af241
> ("usb: typec: ucsi: fix UCSI on buggy Qualcomm devices") was applied to
> Bjorn's qcom tree, so 2/3 should also go there then.
> 
> Patch 3/3 (arm64 dts) definitely also Bjorn's qcom tree.
> 
> So that leaves patch 1/3 which Bjorn can probably pick up as well but
> looking at git log you also picked up some for that file in the past,
> dunno.

Ok, for any remaining ones that want to be merged before 6.8-rc1 is out,
feel free to add my:

Acked-by: Greg Kroah-Hartman 

If they don't get picked up by 6.8-rc1, feel free to rebase and send it
for me to take through my tree.

thanks,

greg k-h



Re: [PATCH 0/3] Fairphone 5 PMIC-GLINK support (USB-C, charger, fuel gauge)

2024-01-02 Thread Greg Kroah-Hartman
On Thu, Dec 21, 2023 at 02:45:26PM +0100, Luca Weiss wrote:
> On Thu Dec 21, 2023 at 1:53 PM CET, Konrad Dybcio wrote:
> > On 21.12.2023 11:34, Dmitry Baryshkov wrote:
> > > On Thu, 21 Dec 2023 at 09:33, Luca Weiss  wrote:
> > >>
> > >> On Wed Dec 20, 2023 at 1:32 PM CET, Konrad Dybcio wrote:
> > >>> On 20.12.2023 11:02, Luca Weiss wrote:
> >  This series adds all the necessary bits to enable USB-C role switching,
> >  charger and fuel gauge (all via pmic-glink) on Fairphone 5.
> > 
> >  One thing that could be made different is the pmic-glink compatible.
> >  I've chosen to use qcm6490 compatible for it and not sc7280 since
> >  there's plenty of firmware variety on sc7280-based platforms and they
> >  might require different quirks in the future, so limit this PDOS quirk
> >  to just qcm6490 for now.
> > 
> >  If someone thinks it should be qcom,sc7280-pmic-glink, please let me
> >  know :)
> > >>> IMO it's best to continue using the "base soc" (which just so happened
> > >>> to fall onto sc7280 this time around) for all compatibles, unless the
> > >>> derivatives actually had changes
> > >>
> > >> Hi Konrad,
> > >>
> > >> I think at some point I asked Dmitry what he thought and he mentioned
> > >> qcm6490. Even found the message again:
> > >>
> > >>> well, since it is a firmware thing, you might want to emphasise that.
> > >>> So from my POV qcm6490 makes more sense
> > >>
> > >> But yeah since it's likely that sc7280 firmware behaves the same as
> > >> qcm6490 firmware it's probably okay to use sc7280 compatible, worst case
> > >> we change it later :) I'll send a v2 with those changes.
> > > 
> > > Worst case we end up with sc7280 which has yet another slightly
> > > different UCSI / PMIC GLINK implementation, but the compatible string
> > > is already taken.
> > > I still suppose that this should be a qcm6490-related string.
> > Right, let's keep qcm then
> 
> Ack from my side also. Thanks for the feedback!

This doesn't apply to my tree, where should it be going through?

thanks,
greg k-h



Re: [PATCH v6 2/4] dax/bus: Use guard(device) in sysfs attribute helpers

2023-12-14 Thread Greg Kroah-Hartman
On Thu, Dec 14, 2023 at 10:25:27PM -0700, Vishal Verma wrote:
> Use the guard(device) macro to lock a 'struct device', and unlock it
> automatically when going out of scope using Scope Based Resource
> Management semantics. A lot of the sysfs attribute writes in
> drivers/dax/bus.c benefit from a cleanup using these, so change these
> where applicable.

Wait, why are you needing to call device_lock() at all here?  Why is dax
special in needing this when no other subsystem requires it?

> 
> Cc: Joao Martins 
> Cc: Dan Williams 
> Signed-off-by: Vishal Verma 
> ---
>  drivers/dax/bus.c | 143 
> ++
>  1 file changed, 59 insertions(+), 84 deletions(-)
> 
> diff --git a/drivers/dax/bus.c b/drivers/dax/bus.c
> index 1ff1ab5fa105..6226de131d17 100644
> --- a/drivers/dax/bus.c
> +++ b/drivers/dax/bus.c
> @@ -294,13 +294,10 @@ static ssize_t available_size_show(struct device *dev,
>   struct device_attribute *attr, char *buf)
>  {
>   struct dax_region *dax_region = dev_get_drvdata(dev);
> - unsigned long long size;
>  
> - device_lock(dev);
> - size = dax_region_avail_size(dax_region);
> - device_unlock(dev);
> + guard(device)(dev);

You have a valid device here, why are you locking it?  How can it go
away?  And if it can, shouldn't you have a local lock for it, and not
abuse the driver core lock?

>  
> - return sprintf(buf, "%llu\n", size);
> + return sprintf(buf, "%llu\n", dax_region_avail_size(dax_region));

sysfs_emit() everywhere please.

But again, the issue is "why do you need a lock"?

thanks,

greg k-h



Re: [PATCH v5 4/4] dax: add a sysfs knob to control memmap_on_memory behavior

2023-12-14 Thread Greg Kroah-Hartman
On Thu, Dec 14, 2023 at 12:37:57AM -0700, Vishal Verma wrote:
> +static ssize_t memmap_on_memory_show(struct device *dev,
> +  struct device_attribute *attr, char *buf)
> +{
> + struct dev_dax *dev_dax = to_dev_dax(dev);
> +
> + return sprintf(buf, "%d\n", dev_dax->memmap_on_memory);

checkpatch should have noticed that this should be sysfs_emit(), right?
If not, please make the change anyway.

> diff --git a/Documentation/ABI/testing/sysfs-bus-dax 
> b/Documentation/ABI/testing/sysfs-bus-dax
> index 6359f7bc9bf4..40d9965733b2 100644
> --- a/Documentation/ABI/testing/sysfs-bus-dax
> +++ b/Documentation/ABI/testing/sysfs-bus-dax
> @@ -134,3 +134,20 @@ KernelVersion:   v5.1
>  Contact: nvd...@lists.linux.dev
>  Description:
>   (RO) The id attribute indicates the region id of a dax region.
> +
> +What:/sys/bus/dax/devices/daxX.Y/memmap_on_memory
> +Date:October, 2023

It's not October anymore :)

thanks,

greg k-h



Re: [ANNOUNCE] 5.10.201-rt98

2023-11-24 Thread Greg Kroah-Hartman
On Wed, Nov 22, 2023 at 10:36:23AM -0300, Luis Claudio R. Goncalves wrote:
> On Tue, Nov 21, 2023 at 10:01:25PM -0300, Luis Claudio R. Goncalves wrote:
> > Hello RT-list!
> > 
> > I'm pleased to announce the 5.10.201-rt98 stable release.
> > 
> > This release is just an update to the new stable 5.10.201
> > version and no RT changes have been made.
> > 
> > You can get this release via the git tree at:
> > 
> >   git://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-stable-rt.git
> > 
> >   branch: v5.10-rt
> >   Head SHA1: 3a93f0a0d49dd0db4c6876ca9a7369350e64320e
> 
> Greg KH,
> 
> While testing v5.10.201-rt98 I stumbled over this warning:
> 
> [ 1000.312397] run blktests nvme/005 at 2023-11-21 21:46:30
> ...
> [ 1000.500478] workqueue: WQ_MEM_RECLAIM nvmet_tcp_wq:nvmet_tcp_io_work 
> [nvmet_tcp] is flushing !WQ_MEM_RECLAIM events:0x0
> [ 1000.500490] WARNING: CPU: 0 PID: 6 at kernel/workqueue.c:2620 
> check_flush_dependency+0x11f/0x140
> 
> That seems to be fixed by:
> 
> 533d2e8b4d5e4 nvmet-tcp: fix lockdep complaint on nvmet_tcp_wq flush 
> during queue teardown
> (and depending on what else is backported)
> ddd2b8de9f85b nvmet: fix workqueue MEM_RECLAIM flushing dependency
> 
> Is this something that can be added to your v5.10 queue or should I carry
> this fix on v5.10-rt in the meantime?

That's odd, as this commit is already in the 5.10.138 release, so how
can we apply it again?

confused,

greg k-h



Re: [REGRESSION] USB ports do not work after suspend/resume cycle with v6.6.2

2023-11-24 Thread Greg Kroah-Hartman
On Fri, Nov 24, 2023 at 01:59:24PM +0100, Vlastimil Babka wrote:
> +Cc workflows
> 
> On 11/24/23 12:43, Greg Kroah-Hartman wrote:
> > On Thu, Nov 23, 2023 at 07:20:46PM +0100, Oleksandr Natalenko wrote:
> >> Hello.
> >> 
> >> Since v6.6.2 kernel release I'm experiencing a regression with regard
> >> to USB ports behaviour after a suspend/resume cycle.
> >> 
> >> If a USB port is empty before suspending, after resuming the machine
> >> the port doesn't work. After a device insertion there's no reaction in
> >> the kernel log whatsoever, although I do see that the device gets
> >> powered up physically. If the machine is suspended with a device
> >> inserted into the USB port, the port works fine after resume.
> >> 
> >> This is an AMD-based machine with hci version 0x110 reported. As per
> >> the changelog between v6.6.1 and v6.6.2, 603 commits were backported
> >> into v6.6.2, and one of the commits was as follows:
> >> 
> >> $ git log --oneline v6.6.1..v6.6.2 -- drivers/usb/host/xhci-pci.c 
> >> 14a51fa544225 xhci: Loosen RPM as default policy to cover for AMD xHC
> >> 1.1
> >> 
> >> It seems that this commit explicitly enables runtime PM specifically
> >> for my platform. As per dmesg:
> >> 
> >> v6.6.1: quirks 0x0410 v6.6.2: quirks 0x00020410
> >> 
> >> Here, bit 33 gets set, which, as expected, corresponds to:
> >> 
> >> drivers/usb/host/xhci.h 1895:#define XHCI_DEFAULT_PM_RUNTIME_ALLOW
> >> BIT_ULL(33)
> >> 
> >> This commit is backported from the upstream commit 4baf12181509, which
> >> is one of 16 commits of the following series named "xhci features":
> >> 
> >> https://lore.kernel.org/all/20231019102924.2797346-1-mathias.ny...@linux.intel.com/
> >>
> >>  It appears that there was another commit in this series, also from
> >> Basavaraj (in Cc), a5d6264b638e, which was not picked for v6.6.2, but
> >> which stated the following:
> >> 
> >> Use the low-power states of the underlying platform to enable runtime
> >> PM. If the platform doesn't support runtime D3, then enabling default
> >> RPM will result in the controller malfunctioning, as in the case of
> >> hotplug devices not being detected because of a failed interrupt
> >> generation.
> >> 
> >> It felt like this was exactly my case. So, I've conducted two tests:
> >> 
> >> 1. Reverted 14a51fa544225 from v6.6.2. With this revert the USB ports
> >> started to work fine, just as they did in v6.6.1. 2. Left 14a51fa544225
> >> in place, but also applied upstream a5d6264b638e on top of v6.6.2. With
> >> this patch added the USB ports also work after a suspend/resume cycle.
> >> 
> >> This runtime PM enablement did also impact my AX200 Bluetooth device,
> >> resulting in long delays before headphones/speaker can connect, but
> >> I've solved this with btusb.enable_autosuspend=N. I think this has
> >> nothing to do with the original issue, and I'm OK with this workaround
> >> unless someone has got a different idea.
> >> 
> >> With that, please consider either reverting 14a51fa544225 from the
> >> stable kernel, or applying a5d6264b638e in addition to it. Given the
> >> mainline kernel has got both of them, I'm in favour of applying
> >> additional commit to the stable kernel.
> > 
> > I've applied this other commit as well to all of the affected branches, 
> > thanks for letting us know.
> > 
> >> I'm also Cc'ing all the people from our Mastodon discussion where I
> >> initially complained about the issue as well as about stable kernel
> >> branch stability:
> >> 
> >> https://activitypub.natalenko.name/@oleksandr/statuses/01HFRXBYWMXF9G4KYPE3XHH0S8
> >>
> >>  I'm not going to expand more on that in this email, especially given
> >> Greg indicated he read the conversation, but I'm open to continuing
> >> this discussion as I still think that current workflow brings visible
> >> issues to ordinary users, and hence some adjustments should be made.
> > 
> > What type of adjustments exactly?  Testing on wide ranges of systems is
> > pretty hard, and this patch explicitly was set to be backported when it
> > hit Linus's tree,
> 
> Are you sure about that "explicitly was set to be backported" part?
> According to Documentation/process/stable-kernel-rules.rst:
> 
> > There are three options to submit a change to

Re: stable-rc: 5.15 - all builds failed - ld.lld: error: undefined symbol: kallsyms_on_each_symbol

2023-11-02 Thread Greg Kroah-Hartman
On Wed, Nov 01, 2023 at 08:54:56PM +0530, Naresh Kamboju wrote:
> Hi Greg,
> 
> I see the following build warning / errors everywhere on stable-rc 5.15 
> branch.
> 
> ld.lld: error: undefined symbol: kallsyms_on_each_symbol
> >>> referenced by trace_kprobe.c
> >>>   trace/trace_kprobe.o:(create_local_trace_kprobe) in archive 
> >>> kernel/built-in.a
> >>> referenced by trace_kprobe.c
> >>>   trace/trace_kprobe.o:(__trace_kprobe_create) in archive 
> >>> kernel/built-in.a
> make[1]: *** [Makefile:1227: vmlinux] Error 1
> 
> Links,
>  - 
> https://storage.tuxsuite.com/public/linaro/lkft/builds/2XXALLRIZaXJVcqhff4ZmGTeZoQ/
> 
> - Naresh

Offending commit now dropped, thanks.

greg k-h



Re: [PATCH 04/10] staging: ks7010: remove unused ioctl handler

2023-10-09 Thread Greg Kroah-Hartman
On Mon, Oct 09, 2023 at 04:19:02PM +0200, Arnd Bergmann wrote:
> From: Arnd Bergmann 
> 
> The ndo_do_ioctl function has no actual callers, and doesn't do much here,
> so just remove it entirely as preparation for removing the callback pointer
> from net_device_ops.
> 
> Signed-off-by: Arnd Bergmann 


Reviewed-by: Greg Kroah-Hartman 


Re: [PATCH 05/10] staging: rtl8192: remove unused legacy ioctl handlers

2023-10-09 Thread Greg Kroah-Hartman
On Mon, Oct 09, 2023 at 04:19:03PM +0200, Arnd Bergmann wrote:
> From: Arnd Bergmann 
> 
> The .ndo_do_ioctl functions are never called, and can just be removed,
> especially since this is a staging driver.
> 
> Signed-off-by: Arnd Bergmann 
> ---
>  drivers/staging/rtl8192u/ieee80211/dot11d.c   |  41 --
>  drivers/staging/rtl8192u/ieee80211/dot11d.h   |   2 -
>  .../staging/rtl8192u/ieee80211/ieee80211.h|  12 -
>  .../rtl8192u/ieee80211/ieee80211_softmac.c| 563 --
>  drivers/staging/rtl8192u/r8192U.h |   2 -
>  drivers/staging/rtl8192u/r8192U_core.c| 109 
>  6 files changed, 729 deletions(-)

Reviewed-by: Greg Kroah-Hartman 


Re: [PATCH 07/10] staging: rtl8723bs: remove dead code

2023-10-09 Thread Greg Kroah-Hartman
On Mon, Oct 09, 2023 at 04:19:05PM +0200, Arnd Bergmann wrote:
> From: Arnd Bergmann 
> 
> The .ndo_do_ioctl functions are never called, so the three implementation here
> is useless but only works as a way to identify the device in the notifiers,
> which can really be removed as well.
> 
> Looking through the exported functions, I found a bunch more that have
> no callers, so just drop all of those.
> 
> Signed-off-by: Arnd Bergmann 

Reviewed-by: Greg Kroah-Hartman 


Re: [PATCH 06/10] staging: rtl8712: remove unused legacy ioctl handlers

2023-10-09 Thread Greg Kroah-Hartman
On Mon, Oct 09, 2023 at 04:19:04PM +0200, Arnd Bergmann wrote:
> From: Arnd Bergmann 
> 
> The .ndo_do_ioctl functions are never called, and can just be removed,
> especially since this is a staging driver.
> 
> Signed-off-by: Arnd Bergmann 
> ---
>  drivers/staging/rtl8712/os_intfs.c|   1 -
>  drivers/staging/rtl8712/osdep_intf.h  |   2 -
>  drivers/staging/rtl8712/rtl871x_ioctl_linux.c | 124 --
>  3 files changed, 127 deletions(-)

Reviewed-by: Greg Kroah-Hartman 


[PATCH] testing: nvdimm: make struct class structures constant

2023-10-06 Thread Greg Kroah-Hartman
Now that the driver core allows for struct class to be in read-only
memory, we should make all 'class' structures declared at build time
placing them into read-only memory, instead of having to be dynamically
allocated at runtime.

Cc: Dan Williams 
Cc: Vishal Verma 
Cc: Dave Jiang 
Cc: Ira Weiny 
Signed-off-by: Greg Kroah-Hartman 
---
 tools/testing/nvdimm/test/ndtest.c | 17 +
 tools/testing/nvdimm/test/nfit.c   | 14 +++---
 2 files changed, 16 insertions(+), 15 deletions(-)

diff --git a/tools/testing/nvdimm/test/ndtest.c 
b/tools/testing/nvdimm/test/ndtest.c
index 3eba10c1e3e8..fd26189d53be 100644
--- a/tools/testing/nvdimm/test/ndtest.c
+++ b/tools/testing/nvdimm/test/ndtest.c
@@ -38,7 +38,11 @@ enum {
 
 static DEFINE_SPINLOCK(ndtest_lock);
 static struct ndtest_priv *instances[NUM_INSTANCES];
-static struct class *ndtest_dimm_class;
+
+static const struct class ndtest_dimm_class = {
+   .name = "nfit_test_dimm",
+};
+
 static struct gen_pool *ndtest_pool;
 
 static struct ndtest_dimm dimm_group1[] = {
@@ -737,7 +741,7 @@ static int ndtest_dimm_register(struct ndtest_priv *priv,
return -ENXIO;
}
 
-   dimm->dev = device_create_with_groups(ndtest_dimm_class,
+   dimm->dev = device_create_with_groups(_dimm_class,
 >pdev.dev,
 0, dimm, dimm_attribute_groups,
 "test_dimm%d", id);
@@ -906,8 +910,7 @@ static void cleanup_devices(void)
gen_pool_destroy(ndtest_pool);
 
 
-   if (ndtest_dimm_class)
-   class_destroy(ndtest_dimm_class);
+   class_unregister(_dimm_class);
 }
 
 static __init int ndtest_init(void)
@@ -921,11 +924,9 @@ static __init int ndtest_init(void)
 
nfit_test_setup(ndtest_resource_lookup, NULL);
 
-   ndtest_dimm_class = class_create("nfit_test_dimm");
-   if (IS_ERR(ndtest_dimm_class)) {
-   rc = PTR_ERR(ndtest_dimm_class);
+   rc = class_regster(_dimm_class);
+   if (rc)
goto err_register;
-   }
 
ndtest_pool = gen_pool_create(ilog2(SZ_4M), NUMA_NO_NODE);
if (!ndtest_pool) {
diff --git a/tools/testing/nvdimm/test/nfit.c b/tools/testing/nvdimm/test/nfit.c
index 005043bd9623..a61df347a33d 100644
--- a/tools/testing/nvdimm/test/nfit.c
+++ b/tools/testing/nvdimm/test/nfit.c
@@ -1712,7 +1712,9 @@ static void put_dimms(void *data)
device_unregister(t->dimm_dev[i]);
 }
 
-static struct class *nfit_test_dimm;
+static const struct class nfit_test_dimm = {
+   .name = "nfit_test_dimm",
+};
 
 static int dimm_name_to_id(struct device *dev)
 {
@@ -1830,7 +1832,7 @@ static int nfit_test_dimm_init(struct nfit_test *t)
if (devm_add_action_or_reset(>pdev.dev, put_dimms, t))
return -ENOMEM;
for (i = 0; i < t->num_dcr; i++) {
-   t->dimm_dev[i] = device_create_with_groups(nfit_test_dimm,
+   t->dimm_dev[i] = device_create_with_groups(_test_dimm,
>pdev.dev, 0, NULL,
nfit_test_dimm_attribute_groups,
"test_dimm%d", i + t->dcr_idx);
@@ -3276,11 +3278,9 @@ static __init int nfit_test_init(void)
if (!nfit_wq)
return -ENOMEM;
 
-   nfit_test_dimm = class_create("nfit_test_dimm");
-   if (IS_ERR(nfit_test_dimm)) {
-   rc = PTR_ERR(nfit_test_dimm);
+   rc = class_register(_test_dimm);
+   if (rc)
goto err_register;
-   }
 
nfit_pool = gen_pool_create(ilog2(SZ_4M), NUMA_NO_NODE);
if (!nfit_pool) {
@@ -3377,7 +3377,7 @@ static __exit void nfit_test_exit(void)
 
for (i = 0; i < NUM_NFITS; i++)
put_device([i]->pdev.dev);
-   class_destroy(nfit_test_dimm);
+   class_unregister(_test_dimm);
 }
 
 module_init(nfit_test_init);
-- 
2.42.0




[PATCH] net: appletalk: remove cops support

2023-09-27 Thread Greg Kroah-Hartman
The COPS Appletalk support is very old, never said to actually work
properly, and the firmware code for the devices are under a very suspect
license.  Remove it all to clear up the license issue, if it is still
needed and actually used by anyone, we can add it back later once the
license is cleared up.

Reported-by: Prarit Bhargava 
Cc: Christoph Hellwig 
Cc: Vitaly Kuznetsov 
Cc: jsch...@samba.org
Signed-off-by: Greg Kroah-Hartman 
---
 .../device_drivers/appletalk/cops.rst |   80 --
 .../device_drivers/appletalk/index.rst|   18 -
 .../networking/device_drivers/index.rst   |1 -
 drivers/net/Space.c   |6 -
 drivers/net/appletalk/Kconfig |   30 -
 drivers/net/appletalk/Makefile|1 -
 drivers/net/appletalk/cops.c  | 1005 -
 drivers/net/appletalk/cops.h  |   61 -
 drivers/net/appletalk/cops_ffdrv.h|  532 -
 drivers/net/appletalk/cops_ltdrv.h|  241 
 include/net/Space.h   |1 -
 11 files changed, 1976 deletions(-)
 delete mode 100644 Documentation/networking/device_drivers/appletalk/cops.rst
 delete mode 100644 Documentation/networking/device_drivers/appletalk/index.rst
 delete mode 100644 drivers/net/appletalk/cops.c
 delete mode 100644 drivers/net/appletalk/cops.h
 delete mode 100644 drivers/net/appletalk/cops_ffdrv.h
 delete mode 100644 drivers/net/appletalk/cops_ltdrv.h

diff --git a/Documentation/networking/device_drivers/appletalk/cops.rst 
b/Documentation/networking/device_drivers/appletalk/cops.rst
deleted file mode 100644
index 964ba80599a9..
--- a/Documentation/networking/device_drivers/appletalk/cops.rst
+++ /dev/null
@@ -1,80 +0,0 @@
-.. SPDX-License-Identifier: GPL-2.0
-
-
-The COPS LocalTalk Linux driver (cops.c)
-
-
-By Jay Schulist 
-
-This driver has two modes and they are: Dayna mode and Tangent mode.
-Each mode corresponds with the type of card. It has been found
-that there are 2 main types of cards and all other cards are
-the same and just have different names or only have minor differences
-such as more IO ports. As this driver is tested it will
-become more clear exactly what cards are supported.
-
-Right now these cards are known to work with the COPS driver. The
-LT-200 cards work in a somewhat more limited capacity than the
-DL200 cards, which work very well and are in use by many people.
-
-TANGENT driver mode:
-   - Tangent ATB-II, Novell NL-1000, Daystar Digital LT-200
-
-DAYNA driver mode:
-   - Dayna DL2000/DaynaTalk PC (Half Length), COPS LT-95,
-   - Farallon PhoneNET PC III, Farallon PhoneNET PC II
-
-Other cards possibly supported mode unknown though:
-   - Dayna DL2000 (Full length)
-
-The COPS driver defaults to using Dayna mode. To change the driver's
-mode if you built a driver with dual support use board_type=1 or
-board_type=2 for Dayna or Tangent with insmod.
-
-Operation/loading of the driver
-===
-
-Use modprobe like this:/sbin/modprobe cops.o (IO #) (IRQ #)
-If you do not specify any options the driver will try and use the IO = 0x240,
-IRQ = 5. As of right now I would only use IRQ 5 for the card, if autoprobing.
-
-To load multiple COPS driver Localtalk cards you can do one of the following::
-
-   insmod cops io=0x240 irq=5
-   insmod -o cops2 cops io=0x260 irq=3
-
-Or in lilo.conf put something like this::
-
-   append="ether=5,0x240,lt0 ether=3,0x260,lt1"
-
-Then bring up the interface with ifconfig. It will look something like this::
-
-  lt0   Link encap:UNSPEC  HWaddr 
00-00-00-00-00-00-00-F7-00-00-00-00-00-00-00-00
-   inet addr:192.168.1.2  Bcast:192.168.1.255  Mask:255.255.255.0
-   UP BROADCAST RUNNING NOARP MULTICAST  MTU:600  Metric:1
-   RX packets:0 errors:0 dropped:0 overruns:0 frame:0
-   TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 coll:0
-
-Netatalk Configuration
-==
-
-You will need to configure atalkd with something like the following to make
-it work with the cops.c driver.
-
-* For single LTalk card use::
-
-dummy -seed -phase 2 -net 2000 -addr 2000.10 -zone "1033"
-lt0 -seed -phase 1 -net 1000 -addr 1000.50 -zone "1033"
-
-* For multiple cards, Ethernet and LocalTalk::
-
-eth0 -seed -phase 2 -net 3000 -addr 3000.20 -zone "1033"
-lt0 -seed -phase 1 -net 1000 -addr 1000.50 -zone "1033"
-
-* For multiple LocalTalk cards, and an Ethernet card.
-
-* Order seems to matter here, Ethernet last::
-
-lt0 -seed -phase 1 -net 1000 -addr 1000.10 -zone "LocalTalk1"
-lt1 -seed -phase 1 -net 2000 -addr 2000.20 -zone "LocalTalk2"
-eth0 -seed -phase 2 -net 3000 -addr 3000.30 -zone "EtherTalk"
diff --git a/Documentation/networking/device_

Re: [PATCH v3 2/8] cxl/acpi: Add root device lockdep validation

2022-04-21 Thread Greg Kroah-Hartman
On Thu, Apr 21, 2022 at 08:33:18AM -0700, Dan Williams wrote:
> The CXL "root" device, ACPI0017, is an attach point for coordinating
> platform level CXL resources and is the parent device for a CXL port
> topology tree. As such it has distinct locking rules relative to other
> CXL subsystem objects, but because it is an ACPI device the lock class
> is established well before it is given to the cxl_acpi driver.
> 
> However, the lockdep API does support changing the lock class "live" for
> situations like this. Add a device_lock_set_class() helper that a driver
> can use in ->probe() to set a custom lock class, and
> device_lock_reset_class() to return to the default "no validate" class
> before the custom lock class key goes out of scope after ->remove().
> 
> Note the helpers are all macros to support dead code elimination in the
> CONFIG_PROVE_LOCKING=n case.
> 
> Suggested-by: Peter Zijlstra 
> Cc: Greg Kroah-Hartman 
> Cc: "Rafael J. Wysocki" 
> Cc: Ingo Molnar 
> Cc: Will Deacon 
> Cc: Waiman Long 
> Cc: Boqun Feng 
> Cc: Alison Schofield 
> Cc: Vishal Verma 
> Cc: Ira Weiny 
> Cc: Ben Widawsky 
> Cc: Jonathan Cameron 
> Signed-off-by: Dan Williams 
> ---
>  drivers/cxl/acpi.c |   15 +++
>  include/linux/device.h |   25 +
>  2 files changed, 40 insertions(+)

Much simpler, great work.

Reviewed-by: Greg Kroah-Hartman 



Re: [PATCH v3 7/8] device-core: Kill the lockdep_mutex

2022-04-21 Thread Greg Kroah-Hartman
On Thu, Apr 21, 2022 at 08:33:45AM -0700, Dan Williams wrote:
> Per Peter [1], the lockdep API has native support for all the use cases
> lockdep_mutex was attempting to enable. Now that all lockdep_mutex users
> have been converted to those APIs, drop this lock.
> 
> Link: 
> https://lore.kernel.org/r/ylf0dewci8myl...@hirez.programming.kicks-ass.net [1]
> Cc: Greg Kroah-Hartman 
> Cc: "Rafael J. Wysocki" 
> Suggested-by: Peter Zijlstra 
> Signed-off-by: Dan Williams 

YES!

Acked-by: Greg Kroah-Hartman 


Nice work.



Re: Re: [syzbot] INFO: rcu detected stall in tx

2021-04-20 Thread Greg Kroah-Hartman
On Mon, Apr 19, 2021 at 08:56:19PM +, Guido Kiener wrote:
> Hi all,
> 
> The error is in usbtmc_interrupt(struct urb *urb) since five years. The 
> status code EPROTO is not handled correctly.
> It's not a showstopper, but we should fix it and check the status code 
> according to usbtmc_read_bulk_cb() or
> usb_skeleton.c.
> @Dave: Do you have time? Otherwise I can do it.
> @Greg: Is it urgent?

No idea, but patches for known problems are always good to get completed
as soon as possible :)

thanks,

greg k-h


Re: [PATCH 1/2] Revert "USB: serial: ch341: add new Product ID for CH341A"

2021-04-20 Thread Greg Kroah-Hartman
On Mon, Apr 19, 2021 at 09:25:19PM -0500, Frank Zago wrote:
> From: frank zago 
> 
> The 0x5512 USB PID is for the I2C/GPIO/SPI interfaces. UART is still
> present but only the TX and RX pins are available; DTS, DTR, ... are
> used for other things. Remove the PID, and let a I2C driver bind to
> it.
> 
> Existing CH341 boards usually have physical jumpers to switch between
> the 3 modes.
> 
> This reverts commit 46ee4abb10a07bd8f8ce910ee6b4ae6a947d7f63.
> 
> Signed-off-by: Frank Zago 
> Signed-off-by: frank zago 

Why are you signing off twice?



Re: [PATCH 5.10 043/103] net: tipc: Fix spelling errors in net/tipc module

2021-04-20 Thread Greg Kroah-Hartman
On Mon, Apr 19, 2021 at 11:32:47PM +0200, Pavel Machek wrote:
> Hi!
> 
> > [ Upstream commit a79ace4b312953c5835fafb12adc3cb6878b26bd ]
> > 
> > These patches fix a series of spelling errors in net/tipc module.
> 
> This should not be in -stable, it just cleans up comments.

Agreed, now dropped, thanks.

greg k-h


Re: [PATCH 5.10 042/103] net/rds: Avoid potential use after free in rds_send_remove_from_sock

2021-04-20 Thread Greg Kroah-Hartman
On Mon, Apr 19, 2021 at 11:29:30PM +0200, Pavel Machek wrote:
> Hi!
> 
> > [ Upstream commit 0c85a7e87465f2d4cbc768e245f4f45b2f299b05 ]
> > 
> > In case of rs failure in rds_send_remove_from_sock(), the 'rm' resource
> > is freed and later under spinlock, causing potential use-after-free.
> > Set the free pointer to NULL to avoid undefined behavior.
> 
> This patch is crazy. Take a look at Message-ID:
> <20210419084953.GA28564@amd>. Or just look at the patch :-).

You are correct, everything submitted from this author and domain
recently was done as a "research project" to see if they could mess with
kernel maintainers and slip in pointless changes to the kernel.

Not acceptable at all...

greg k-h


Re: [PATCH 5.10 042/103] net/rds: Avoid potential use after free in rds_send_remove_from_sock

2021-04-20 Thread Greg Kroah-Hartman
On Mon, Apr 19, 2021 at 03:05:53PM +0200, Greg Kroah-Hartman wrote:
> From: Aditya Pakki 
> 
> [ Upstream commit 0c85a7e87465f2d4cbc768e245f4f45b2f299b05 ]
> 
> In case of rs failure in rds_send_remove_from_sock(), the 'rm' resource
> is freed and later under spinlock, causing potential use-after-free.
> Set the free pointer to NULL to avoid undefined behavior.
> 
> Signed-off-by: Aditya Pakki 
> Acked-by: Santosh Shilimkar 
> Signed-off-by: David S. Miller 
> Signed-off-by: Sasha Levin 
> ---
>  net/rds/message.c | 1 +
>  net/rds/send.c| 2 +-
>  2 files changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/net/rds/message.c b/net/rds/message.c
> index 799034e0f513..4fc66ff0f1ec 100644
> --- a/net/rds/message.c
> +++ b/net/rds/message.c
> @@ -180,6 +180,7 @@ void rds_message_put(struct rds_message *rm)
>   rds_message_purge(rm);
>  
>   kfree(rm);
> + rm = NULL;
>   }
>  }
>  EXPORT_SYMBOL_GPL(rds_message_put);
> diff --git a/net/rds/send.c b/net/rds/send.c
> index 985d0b7713ac..fe5264b9d4b3 100644
> --- a/net/rds/send.c
> +++ b/net/rds/send.c
> @@ -665,7 +665,7 @@ static void rds_send_remove_from_sock(struct list_head 
> *messages, int status)
>  unlock_and_drop:
>   spin_unlock_irqrestore(>m_rs_lock, flags);
>   rds_message_put(rm);
> - if (was_on_sock)
> + if (was_on_sock && rm)
>   rds_message_put(rm);
>   }
>  
> -- 
> 2.30.2
> 
> 
> 

Ah crap, I will go drop this stuff.

I also will strongly recommend that all maintainers blacklist umn.edu
patches at this point in time, as it is obvious that a professor there
is operating a sociological experiment on Linux kernel maintainers and
is wasting our time.

This is not ok.

greg k-h


Re: [PATCH 00/13] [RFC] Rust support

2021-04-19 Thread Greg Kroah-Hartman
On Mon, Apr 19, 2021 at 05:24:33PM -0700, Nick Desaulniers wrote:
> On Fri, Apr 16, 2021 at 10:39 AM Willy Tarreau  wrote:
> >
> > resources usage, I'm really not convinced at all it's suited for
> > low-level development. I understand the interest of the experiment
> > to help the language evolve into that direction, but I fear that
> > the kernel will soon be as bloated and insecure as a browser, and
> > that's really not to please me.
> 
> Dunno, I don't think the introduction of Rust made Firefox _more_ insecure.
> https://wiki.mozilla.org/Oxidation#Within_Firefox
> 
> I pray no executives ever see Dmitry Vyukov's 2019 Linux Plumbers Conf
> talk "Reflections on kernel quality, development process and testing."
> https://www.youtube.com/watch?v=iAfrrNdl2f4
> or his 2018 Linux Security Summit talk "Syzbot and the Tale of
> Thousand Kernel Bugs" https://www.youtube.com/watch?v=qrBVXxZDVQY
> (and they're just fuzzing the syscall interface and USB devices.
> Imagine once folks can more easily craft malformed bluetooth and wifi
> packets.)
> 
> I'd imagine the first term that comes to mind for them might be
> "liability."  They are quite sensitive to these vulnerabilities with
> silly names, logos, and websites.  There are many of us that believe
> an incremental approach of introducing a memory safe language to our
> existing infrastructure at the very least to attempt to improve the
> quality of drivers for those that choose to use such tools is a better
> approach.

I would LOVE it if some "executives" would see the above presentations,
because then they would maybe actually fund developers to fix bugs and
maintain the kernel code, instead of only allowing them to add new
features.

Seriously, that's the real problem, that Dmitry's work has exposed, the
lack of people allowed to do this type of bugfixing and maintenance on
company time, for something that the company relies on, is a huge issue.
"executives" feel that they are willing to fund the initial work and
then "throw it over the wall to the community" once it is merged, and
then they can forget about it as "the community" will maintain it for
them for free.  And that's a lie, as Dmitry's work shows.

The world creates new use cases and testing ability all the time, which
exposes bugs that have been around in old code.  Once the bugs are fixed
in that layer of code, the next layer down can finally be tested and
then look, more corner cases of issues.

Rewriting the kernel in another language is not going to fix the
majority of the issues that fuzzing finds here automagically, as that
work has exposed us to things like fault-injection and malicious USB
packets that no language would have saved us from "automatically".  All
of those code paths deal with "unsafe" data that doesn't magically
become "safe" because we switch languages.

And over time, what we have determined is "safe" has changed!  People
forget that only a few years ago have we decided that the kernel now has
to protect userspace programs from malicious hardware.  That's a major
shift in thinking, now data that we used to blindly trust can not be
trusted at all.  And "executives" want us to fix all of those issues for
free, when really it's a major design shift for loads of kernel
subsystems to handle this new threat model.

So yes, please spread that talk around.  Maybe then will we actually get
funding and support to FIX the bugs that those tools test.  Right now,
the primary fixer of those findings are _INTERNS_ as that's all
companies are willing to fund to fix this type of thing.

And don't get me started on the inability for "executives" to fund other
parts of Linux that they rely on, because they want "other companies" to
do it instead.  The tragedy-of-the-commons is a real threat to Linux,
and always has been...

thanks,

greg k-h


[PATCH 5.4 22/73] ASoC: fsl_esai: Fix TDM slot setup for I2S mode

2021-04-19 Thread Greg Kroah-Hartman
From: Alexander Shiyan 

[ Upstream commit e7a48c710defa0e0fef54d42b7d9e4ab596e2761 ]

When using the driver in I2S TDM mode, the fsl_esai_startup()
function rewrites the number of slots previously set by the
fsl_esai_set_dai_tdm_slot() function to 2.
To fix this, let's use the saved slot count value or, if TDM
is not used and the number of slots is not set, the driver will use
the default value (2), which is set by fsl_esai_probe().

Signed-off-by: Alexander Shiyan 
Acked-by: Nicolin Chen 
Link: https://lore.kernel.org/r/20210402081405.9892-1-shc_w...@mail.ru
Signed-off-by: Mark Brown 
Signed-off-by: Sasha Levin 
---
 sound/soc/fsl/fsl_esai.c | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/sound/soc/fsl/fsl_esai.c b/sound/soc/fsl/fsl_esai.c
index 84290be778f0..33ade79fa032 100644
--- a/sound/soc/fsl/fsl_esai.c
+++ b/sound/soc/fsl/fsl_esai.c
@@ -494,11 +494,13 @@ static int fsl_esai_startup(struct snd_pcm_substream 
*substream,
   ESAI_SAICR_SYNC, esai_priv->synchronous ?
   ESAI_SAICR_SYNC : 0);
 
-   /* Set a default slot number -- 2 */
+   /* Set slots count */
regmap_update_bits(esai_priv->regmap, REG_ESAI_TCCR,
-  ESAI_xCCR_xDC_MASK, ESAI_xCCR_xDC(2));
+  ESAI_xCCR_xDC_MASK,
+  ESAI_xCCR_xDC(esai_priv->slots));
regmap_update_bits(esai_priv->regmap, REG_ESAI_RCCR,
-  ESAI_xCCR_xDC_MASK, ESAI_xCCR_xDC(2));
+  ESAI_xCCR_xDC_MASK,
+  ESAI_xCCR_xDC(esai_priv->slots));
}
 
return 0;
-- 
2.30.2





[PATCH 5.4 30/73] net: ieee802154: stop dump llsec devkeys for monitors

2021-04-19 Thread Greg Kroah-Hartman
From: Alexander Aring 

[ Upstream commit 080d1a57a94d93e70f84b7a360baa351388c574f ]

This patch stops dumping llsec devkeys for monitors which we don't support
yet. Otherwise we will access llsec mib which isn't initialized for
monitors.

Signed-off-by: Alexander Aring 
Link: https://lore.kernel.org/r/20210405003054.256017-10-aahri...@redhat.com
Signed-off-by: Stefan Schmidt 
Signed-off-by: Sasha Levin 
---
 net/ieee802154/nl802154.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/net/ieee802154/nl802154.c b/net/ieee802154/nl802154.c
index 4f6777193029..66785e1eb559 100644
--- a/net/ieee802154/nl802154.c
+++ b/net/ieee802154/nl802154.c
@@ -1874,6 +1874,11 @@ nl802154_dump_llsec_devkey(struct sk_buff *skb, struct 
netlink_callback *cb)
if (err)
return err;
 
+   if (wpan_dev->iftype == NL802154_IFTYPE_MONITOR) {
+   err = skb->len;
+   goto out_err;
+   }
+
if (!wpan_dev->netdev) {
err = -EINVAL;
goto out_err;
-- 
2.30.2





[PATCH 5.4 60/73] ibmvnic: avoid calling napi_disable() twice

2021-04-19 Thread Greg Kroah-Hartman
From: Lijun Pan 

commit 0775ebc4cf8554bdcd2c212669a0868ab68df5c0 upstream.

__ibmvnic_open calls napi_disable without checking whether NAPI polling
has already been disabled or not. This could cause napi_disable
being called twice, which could generate deadlock. For example,
the first napi_disable will spin until NAPI_STATE_SCHED is cleared
by napi_complete_done, then set it again.
When napi_disable is called the second time, it will loop infinitely
because no dev->poll will be running to clear NAPI_STATE_SCHED.

To prevent above scenario from happening, call ibmvnic_napi_disable()
which checks if napi is disabled or not before calling napi_disable.

Fixes: bfc32f297337 ("ibmvnic: Move resource initialization to its own routine")
Suggested-by: Thomas Falcon 
Signed-off-by: Lijun Pan 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/net/ethernet/ibm/ibmvnic.c |3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

--- a/drivers/net/ethernet/ibm/ibmvnic.c
+++ b/drivers/net/ethernet/ibm/ibmvnic.c
@@ -1081,8 +1081,7 @@ static int __ibmvnic_open(struct net_dev
 
rc = set_link_state(adapter, IBMVNIC_LOGICAL_LNK_UP);
if (rc) {
-   for (i = 0; i < adapter->req_rx_queues; i++)
-   napi_disable(>napi[i]);
+   ibmvnic_napi_disable(adapter);
release_resources(adapter);
return rc;
}




[PATCH 5.4 68/73] r8169: fix performance regression related to PCIe max read request size

2021-04-19 Thread Greg Kroah-Hartman
From: Heiner Kallweit 

[ Upstream commit 21b5f672fb2eb1366dedc4ac9d32431146b378d3 ]

It turned out that on low performance systems the original change can
cause lower tx performance. On a N3450-based mini-PC tx performance
in iperf3 was reduced from 950Mbps to ~900Mbps. Therefore effectively
revert the original change, just use pcie_set_readrq() now instead of
changing the PCIe capability register directly.

Fixes: 2df49d365498 ("r8169: remove fiddling with the PCIe max read request 
size")
Signed-off-by: Heiner Kallweit 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin 
---
 drivers/net/ethernet/realtek/r8169_main.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/net/ethernet/realtek/r8169_main.c 
b/drivers/net/ethernet/realtek/r8169_main.c
index 5ca28985c86b..19ebde91555d 100644
--- a/drivers/net/ethernet/realtek/r8169_main.c
+++ b/drivers/net/ethernet/realtek/r8169_main.c
@@ -4099,15 +4099,18 @@ static void rtl_hw_jumbo_enable(struct rtl8169_private 
*tp)
switch (tp->mac_version) {
case RTL_GIGA_MAC_VER_12:
case RTL_GIGA_MAC_VER_17:
+   pcie_set_readrq(tp->pci_dev, 512);
r8168b_1_hw_jumbo_enable(tp);
break;
case RTL_GIGA_MAC_VER_18 ... RTL_GIGA_MAC_VER_26:
+   pcie_set_readrq(tp->pci_dev, 512);
r8168c_hw_jumbo_enable(tp);
break;
case RTL_GIGA_MAC_VER_27 ... RTL_GIGA_MAC_VER_28:
r8168dp_hw_jumbo_enable(tp);
break;
case RTL_GIGA_MAC_VER_31 ... RTL_GIGA_MAC_VER_33:
+   pcie_set_readrq(tp->pci_dev, 512);
r8168e_hw_jumbo_enable(tp);
break;
default:
@@ -4137,6 +4140,9 @@ static void rtl_hw_jumbo_disable(struct rtl8169_private 
*tp)
break;
}
rtl_lock_config_regs(tp);
+
+   if (pci_is_pcie(tp->pci_dev) && tp->supports_gmii)
+   pcie_set_readrq(tp->pci_dev, 4096);
 }
 
 static void rtl_jumbo_config(struct rtl8169_private *tp, int mtu)
-- 
2.30.2





[PATCH 5.4 67/73] r8169: simplify setting PCI_EXP_DEVCTL_NOSNOOP_EN

2021-04-19 Thread Greg Kroah-Hartman
From: Heiner Kallweit 

[ Upstream commit e0bbe7cbb3c5ff72d680993edf89db2391e80d5d ]

r8168b_0_hw_jumbo_enable() and r8168b_0_hw_jumbo_disable() both do the
same and just set PCI_EXP_DEVCTL_NOSNOOP_EN. We can simplify the code
by moving this setting for RTL8168B to rtl_hw_start_8168().

Signed-off-by: Heiner Kallweit 
Signed-off-by: Jakub Kicinski 
Signed-off-by: Sasha Levin 
---
 drivers/net/ethernet/realtek/r8169_main.c | 34 +++
 1 file changed, 10 insertions(+), 24 deletions(-)

diff --git a/drivers/net/ethernet/realtek/r8169_main.c 
b/drivers/net/ethernet/realtek/r8169_main.c
index fb11561a4f17..5ca28985c86b 100644
--- a/drivers/net/ethernet/realtek/r8169_main.c
+++ b/drivers/net/ethernet/realtek/r8169_main.c
@@ -4083,29 +4083,13 @@ static void r8168e_hw_jumbo_disable(struct 
rtl8169_private *tp)
RTL_W8(tp, Config4, RTL_R8(tp, Config4) & ~0x01);
 }
 
-static void r8168b_0_hw_jumbo_enable(struct rtl8169_private *tp)
-{
-   pcie_capability_set_word(tp->pci_dev, PCI_EXP_DEVCTL,
-PCI_EXP_DEVCTL_NOSNOOP_EN);
-}
-
-static void r8168b_0_hw_jumbo_disable(struct rtl8169_private *tp)
-{
-   pcie_capability_set_word(tp->pci_dev, PCI_EXP_DEVCTL,
-PCI_EXP_DEVCTL_NOSNOOP_EN);
-}
-
 static void r8168b_1_hw_jumbo_enable(struct rtl8169_private *tp)
 {
-   r8168b_0_hw_jumbo_enable(tp);
-
RTL_W8(tp, Config4, RTL_R8(tp, Config4) | (1 << 0));
 }
 
 static void r8168b_1_hw_jumbo_disable(struct rtl8169_private *tp)
 {
-   r8168b_0_hw_jumbo_disable(tp);
-
RTL_W8(tp, Config4, RTL_R8(tp, Config4) & ~(1 << 0));
 }
 
@@ -4113,9 +4097,6 @@ static void rtl_hw_jumbo_enable(struct rtl8169_private 
*tp)
 {
rtl_unlock_config_regs(tp);
switch (tp->mac_version) {
-   case RTL_GIGA_MAC_VER_11:
-   r8168b_0_hw_jumbo_enable(tp);
-   break;
case RTL_GIGA_MAC_VER_12:
case RTL_GIGA_MAC_VER_17:
r8168b_1_hw_jumbo_enable(tp);
@@ -4139,9 +4120,6 @@ static void rtl_hw_jumbo_disable(struct rtl8169_private 
*tp)
 {
rtl_unlock_config_regs(tp);
switch (tp->mac_version) {
-   case RTL_GIGA_MAC_VER_11:
-   r8168b_0_hw_jumbo_disable(tp);
-   break;
case RTL_GIGA_MAC_VER_12:
case RTL_GIGA_MAC_VER_17:
r8168b_1_hw_jumbo_disable(tp);
@@ -5406,10 +5384,18 @@ static void rtl_hw_start_8125(struct rtl8169_private 
*tp)
 
 static void rtl_hw_start_8168(struct rtl8169_private *tp)
 {
-   if (tp->mac_version == RTL_GIGA_MAC_VER_13 ||
-   tp->mac_version == RTL_GIGA_MAC_VER_16)
+   switch (tp->mac_version) {
+   case RTL_GIGA_MAC_VER_11:
+   case RTL_GIGA_MAC_VER_12:
+   case RTL_GIGA_MAC_VER_13:
+   case RTL_GIGA_MAC_VER_16:
+   case RTL_GIGA_MAC_VER_17:
pcie_capability_set_word(tp->pci_dev, PCI_EXP_DEVCTL,
 PCI_EXP_DEVCTL_NOSNOOP_EN);
+   break;
+   default:
+   break;
+   }
 
if (rtl_is_8168evl_up(tp))
RTL_W8(tp, MaxTxPacketSize, EarlySize);
-- 
2.30.2





[PATCH 5.4 69/73] r8169: improve rtl_jumbo_config

2021-04-19 Thread Greg Kroah-Hartman
From: Heiner Kallweit 

[ Upstream commit 9db0ac57bd3286fedcf43a86b29b847cea281cc7 ]

Merge enabling and disabling jumbo packets to one function to make
the code a little simpler.

Signed-off-by: Heiner Kallweit 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin 
---
 drivers/net/ethernet/realtek/r8169_main.c | 69 +--
 1 file changed, 27 insertions(+), 42 deletions(-)

diff --git a/drivers/net/ethernet/realtek/r8169_main.c 
b/drivers/net/ethernet/realtek/r8169_main.c
index 19ebde91555d..1352dd0b69e9 100644
--- a/drivers/net/ethernet/realtek/r8169_main.c
+++ b/drivers/net/ethernet/realtek/r8169_main.c
@@ -4093,66 +4093,52 @@ static void r8168b_1_hw_jumbo_disable(struct 
rtl8169_private *tp)
RTL_W8(tp, Config4, RTL_R8(tp, Config4) & ~(1 << 0));
 }
 
-static void rtl_hw_jumbo_enable(struct rtl8169_private *tp)
+static void rtl_jumbo_config(struct rtl8169_private *tp)
 {
-   rtl_unlock_config_regs(tp);
-   switch (tp->mac_version) {
-   case RTL_GIGA_MAC_VER_12:
-   case RTL_GIGA_MAC_VER_17:
-   pcie_set_readrq(tp->pci_dev, 512);
-   r8168b_1_hw_jumbo_enable(tp);
-   break;
-   case RTL_GIGA_MAC_VER_18 ... RTL_GIGA_MAC_VER_26:
-   pcie_set_readrq(tp->pci_dev, 512);
-   r8168c_hw_jumbo_enable(tp);
-   break;
-   case RTL_GIGA_MAC_VER_27 ... RTL_GIGA_MAC_VER_28:
-   r8168dp_hw_jumbo_enable(tp);
-   break;
-   case RTL_GIGA_MAC_VER_31 ... RTL_GIGA_MAC_VER_33:
-   pcie_set_readrq(tp->pci_dev, 512);
-   r8168e_hw_jumbo_enable(tp);
-   break;
-   default:
-   break;
-   }
-   rtl_lock_config_regs(tp);
-}
+   bool jumbo = tp->dev->mtu > ETH_DATA_LEN;
 
-static void rtl_hw_jumbo_disable(struct rtl8169_private *tp)
-{
rtl_unlock_config_regs(tp);
switch (tp->mac_version) {
case RTL_GIGA_MAC_VER_12:
case RTL_GIGA_MAC_VER_17:
-   r8168b_1_hw_jumbo_disable(tp);
+   if (jumbo) {
+   pcie_set_readrq(tp->pci_dev, 512);
+   r8168b_1_hw_jumbo_enable(tp);
+   } else {
+   r8168b_1_hw_jumbo_disable(tp);
+   }
break;
case RTL_GIGA_MAC_VER_18 ... RTL_GIGA_MAC_VER_26:
-   r8168c_hw_jumbo_disable(tp);
+   if (jumbo) {
+   pcie_set_readrq(tp->pci_dev, 512);
+   r8168c_hw_jumbo_enable(tp);
+   } else {
+   r8168c_hw_jumbo_disable(tp);
+   }
break;
case RTL_GIGA_MAC_VER_27 ... RTL_GIGA_MAC_VER_28:
-   r8168dp_hw_jumbo_disable(tp);
+   if (jumbo)
+   r8168dp_hw_jumbo_enable(tp);
+   else
+   r8168dp_hw_jumbo_disable(tp);
break;
case RTL_GIGA_MAC_VER_31 ... RTL_GIGA_MAC_VER_33:
-   r8168e_hw_jumbo_disable(tp);
+   if (jumbo) {
+   pcie_set_readrq(tp->pci_dev, 512);
+   r8168e_hw_jumbo_enable(tp);
+   } else {
+   r8168e_hw_jumbo_disable(tp);
+   }
break;
default:
break;
}
rtl_lock_config_regs(tp);
 
-   if (pci_is_pcie(tp->pci_dev) && tp->supports_gmii)
+   if (!jumbo && pci_is_pcie(tp->pci_dev) && tp->supports_gmii)
pcie_set_readrq(tp->pci_dev, 4096);
 }
 
-static void rtl_jumbo_config(struct rtl8169_private *tp, int mtu)
-{
-   if (mtu > ETH_DATA_LEN)
-   rtl_hw_jumbo_enable(tp);
-   else
-   rtl_hw_jumbo_disable(tp);
-}
-
 DECLARE_RTL_COND(rtl_chipcmd_cond)
 {
return RTL_R8(tp, ChipCmd) & CmdReset;
@@ -5458,7 +5444,7 @@ static void rtl_hw_start(struct  rtl8169_private *tp)
rtl_set_rx_tx_desc_registers(tp);
rtl_lock_config_regs(tp);
 
-   rtl_jumbo_config(tp, tp->dev->mtu);
+   rtl_jumbo_config(tp);
 
/* Initially a 10 us delay. Turned it into a PCI commit. - FR */
RTL_R16(tp, CPlusCmd);
@@ -5473,10 +5459,9 @@ static int rtl8169_change_mtu(struct net_device *dev, 
int new_mtu)
 {
struct rtl8169_private *tp = netdev_priv(dev);
 
-   rtl_jumbo_config(tp, new_mtu);
-
dev->mtu = new_mtu;
netdev_update_features(dev);
+   rtl_jumbo_config(tp);
 
/* Reportedly at least Asus X453MA truncates packets otherwise */
if (tp->mac_version == RTL_GIGA_MAC_VER_37)
-- 
2.30.2





[PATCH 5.4 43/73] dm verity fec: fix misaligned RS roots IO

2021-04-19 Thread Greg Kroah-Hartman
From: Jaegeuk Kim 

commit 8ca7cab82bda4eb0b8064befeeeaa38106cac637 upstream.

commit df7b59ba9245 ("dm verity: fix FEC for RS roots unaligned to
block size") introduced the possibility for misaligned roots IO
relative to the underlying device's logical block size. E.g. Android's
default RS roots=2 results in dm_bufio->block_size=1024, which causes
the following EIO if the logical block size of the device is 4096,
given v->data_dev_block_bits=12:

E sd 0: 0:0:0: [sda] tag#30 request not aligned to the logical block size
E blk_update_request: I/O error, dev sda, sector 10368424 op 0x0:(READ) flags 
0x0 phys_seg 1 prio class 0
E device-mapper: verity-fec: 254:8: FEC 9244672: parity read failed (block 
18056): -5

Fix this by onlu using f->roots for dm_bufio blocksize IFF it is
aligned to v->data_dev_block_bits.

Fixes: df7b59ba9245 ("dm verity: fix FEC for RS roots unaligned to block size")
Cc: sta...@vger.kernel.org
Signed-off-by: Jaegeuk Kim 
Signed-off-by: Mike Snitzer 
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/md/dm-verity-fec.c |   11 ---
 drivers/md/dm-verity-fec.h |1 +
 2 files changed, 9 insertions(+), 3 deletions(-)

--- a/drivers/md/dm-verity-fec.c
+++ b/drivers/md/dm-verity-fec.c
@@ -65,7 +65,7 @@ static u8 *fec_read_parity(struct dm_ver
u8 *res;
 
position = (index + rsb) * v->fec->roots;
-   block = div64_u64_rem(position, v->fec->roots << SECTOR_SHIFT, );
+   block = div64_u64_rem(position, v->fec->io_size, );
*offset = (unsigned)rem;
 
res = dm_bufio_read(v->fec->bufio, block, buf);
@@ -154,7 +154,7 @@ static int fec_decode_bufs(struct dm_ver
 
/* read the next block when we run out of parity bytes */
offset += v->fec->roots;
-   if (offset >= v->fec->roots << SECTOR_SHIFT) {
+   if (offset >= v->fec->io_size) {
dm_bufio_release(buf);
 
par = fec_read_parity(v, rsb, block_offset, , 
);
@@ -742,8 +742,13 @@ int verity_fec_ctr(struct dm_verity *v)
return -E2BIG;
}
 
+   if ((f->roots << SECTOR_SHIFT) & ((1 << v->data_dev_block_bits) - 1))
+   f->io_size = 1 << v->data_dev_block_bits;
+   else
+   f->io_size = v->fec->roots << SECTOR_SHIFT;
+
f->bufio = dm_bufio_client_create(f->dev->bdev,
- f->roots << SECTOR_SHIFT,
+ f->io_size,
  1, 0, NULL, NULL);
if (IS_ERR(f->bufio)) {
ti->error = "Cannot initialize FEC bufio client";
--- a/drivers/md/dm-verity-fec.h
+++ b/drivers/md/dm-verity-fec.h
@@ -36,6 +36,7 @@ struct dm_verity_fec {
struct dm_dev *dev; /* parity data device */
struct dm_bufio_client *data_bufio; /* for data dev access */
struct dm_bufio_client *bufio;  /* for parity data access */
+   size_t io_size; /* IO size for roots */
sector_t start; /* parity data start in blocks */
sector_t blocks;/* number of blocks covered */
sector_t rounds;/* number of interleaving rounds */




[PATCH 5.4 65/73] arm64: dts: allwinner: Fix SD card CD GPIO for SOPine systems

2021-04-19 Thread Greg Kroah-Hartman
From: Andre Przywara 

[ Upstream commit 3dd4ce4185df6798dcdcc3669bddb35899d7d5e1 ]

Commit 941432d00768 ("arm64: dts: allwinner: Drop non-removable from
SoPine/LTS SD card") enabled the card detect GPIO for the SOPine module,
along the way with the Pine64-LTS, which share the same base .dtsi.

However while both boards indeed have a working CD GPIO on PF6, the
polarity is different: the SOPine modules uses a "push-pull" socket,
which has an active-high switch, while the Pine64-LTS use the more
traditional push-push socket and the common active-low switch.

Fix the polarity in the sopine.dtsi, and overwrite it in the LTS
board .dts, to make the SD card work again on systems using SOPine
modules.

Fixes: 941432d00768 ("arm64: dts: allwinner: Drop non-removable from SoPine/LTS 
SD card")
Reported-by: Ashley 
Signed-off-by: Andre Przywara 
Signed-off-by: Maxime Ripard 
Link: https://lore.kernel.org/r/20210316144219.5973-1-andre.przyw...@arm.com
Signed-off-by: Sasha Levin 
---
 arch/arm64/boot/dts/allwinner/sun50i-a64-pine64-lts.dts | 4 
 arch/arm64/boot/dts/allwinner/sun50i-a64-sopine.dtsi| 2 +-
 2 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64-lts.dts 
b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64-lts.dts
index 72d6961dc312..8d15164f2a3c 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64-lts.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64-lts.dts
@@ -11,3 +11,7 @@
compatible = "pine64,pine64-lts", "allwinner,sun50i-r18",
 "allwinner,sun50i-a64";
 };
+
+ {
+   cd-gpios = < 5 6 GPIO_ACTIVE_LOW>; /* PF6 push-push switch */
+};
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-sopine.dtsi 
b/arch/arm64/boot/dts/allwinner/sun50i-a64-sopine.dtsi
index d935e3028fcb..19e5b7e298fd 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64-sopine.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-sopine.dtsi
@@ -57,7 +57,7 @@
vmmc-supply = <_dcdc1>;
disable-wp;
bus-width = <4>;
-   cd-gpios = < 5 6 GPIO_ACTIVE_LOW>; /* PF6 */
+   cd-gpios = < 5 6 GPIO_ACTIVE_HIGH>; /* PF6 push-pull switch */
status = "okay";
 };
 
-- 
2.30.2





[PATCH 5.4 66/73] r8169: remove fiddling with the PCIe max read request size

2021-04-19 Thread Greg Kroah-Hartman
From: Heiner Kallweit 

[ Upstream commit 2df49d36549808a7357ad9f78b7a8e39516e7809 ]

The attempt to improve performance by changing the PCIe max read request
size was added in the vendor driver more than 10 years back and copied
to r8169 driver. In the vendor driver this has been removed long ago.
Obviously it had no effect, also in my tests I didn't see any
difference. Typically the max payload size is less than 512 bytes
anyway, and the PCI core takes care that the maximum supported value
is set. So let's remove fiddling with PCIe max read request size from
r8169 too.

Signed-off-by: Heiner Kallweit 
Signed-off-by: Jakub Kicinski 
Signed-off-by: Sasha Levin 
---
 drivers/net/ethernet/realtek/r8169_main.c | 40 +++
 1 file changed, 4 insertions(+), 36 deletions(-)

diff --git a/drivers/net/ethernet/realtek/r8169_main.c 
b/drivers/net/ethernet/realtek/r8169_main.c
index bd8decc54b87..fb11561a4f17 100644
--- a/drivers/net/ethernet/realtek/r8169_main.c
+++ b/drivers/net/ethernet/realtek/r8169_main.c
@@ -742,12 +742,6 @@ static void rtl_unlock_config_regs(struct rtl8169_private 
*tp)
RTL_W8(tp, Cfg9346, Cfg9346_Unlock);
 }
 
-static void rtl_tx_performance_tweak(struct rtl8169_private *tp, u16 force)
-{
-   pcie_capability_clear_and_set_word(tp->pci_dev, PCI_EXP_DEVCTL,
-  PCI_EXP_DEVCTL_READRQ, force);
-}
-
 static bool rtl_is_8125(struct rtl8169_private *tp)
 {
return tp->mac_version >= RTL_GIGA_MAC_VER_60;
@@ -4057,14 +4051,12 @@ static void r8168c_hw_jumbo_enable(struct 
rtl8169_private *tp)
 {
RTL_W8(tp, Config3, RTL_R8(tp, Config3) | Jumbo_En0);
RTL_W8(tp, Config4, RTL_R8(tp, Config4) | Jumbo_En1);
-   rtl_tx_performance_tweak(tp, PCI_EXP_DEVCTL_READRQ_512B);
 }
 
 static void r8168c_hw_jumbo_disable(struct rtl8169_private *tp)
 {
RTL_W8(tp, Config3, RTL_R8(tp, Config3) & ~Jumbo_En0);
RTL_W8(tp, Config4, RTL_R8(tp, Config4) & ~Jumbo_En1);
-   rtl_tx_performance_tweak(tp, PCI_EXP_DEVCTL_READRQ_4096B);
 }
 
 static void r8168dp_hw_jumbo_enable(struct rtl8169_private *tp)
@@ -4082,7 +4074,6 @@ static void r8168e_hw_jumbo_enable(struct rtl8169_private 
*tp)
RTL_W8(tp, MaxTxPacketSize, 0x24);
RTL_W8(tp, Config3, RTL_R8(tp, Config3) | Jumbo_En0);
RTL_W8(tp, Config4, RTL_R8(tp, Config4) | 0x01);
-   rtl_tx_performance_tweak(tp, PCI_EXP_DEVCTL_READRQ_512B);
 }
 
 static void r8168e_hw_jumbo_disable(struct rtl8169_private *tp)
@@ -4090,19 +4081,18 @@ static void r8168e_hw_jumbo_disable(struct 
rtl8169_private *tp)
RTL_W8(tp, MaxTxPacketSize, 0x3f);
RTL_W8(tp, Config3, RTL_R8(tp, Config3) & ~Jumbo_En0);
RTL_W8(tp, Config4, RTL_R8(tp, Config4) & ~0x01);
-   rtl_tx_performance_tweak(tp, PCI_EXP_DEVCTL_READRQ_4096B);
 }
 
 static void r8168b_0_hw_jumbo_enable(struct rtl8169_private *tp)
 {
-   rtl_tx_performance_tweak(tp,
-   PCI_EXP_DEVCTL_READRQ_512B | PCI_EXP_DEVCTL_NOSNOOP_EN);
+   pcie_capability_set_word(tp->pci_dev, PCI_EXP_DEVCTL,
+PCI_EXP_DEVCTL_NOSNOOP_EN);
 }
 
 static void r8168b_0_hw_jumbo_disable(struct rtl8169_private *tp)
 {
-   rtl_tx_performance_tweak(tp,
-   PCI_EXP_DEVCTL_READRQ_4096B | PCI_EXP_DEVCTL_NOSNOOP_EN);
+   pcie_capability_set_word(tp->pci_dev, PCI_EXP_DEVCTL,
+PCI_EXP_DEVCTL_NOSNOOP_EN);
 }
 
 static void r8168b_1_hw_jumbo_enable(struct rtl8169_private *tp)
@@ -4575,18 +4565,12 @@ static void rtl_hw_start_8168d(struct rtl8169_private 
*tp)
rtl_set_def_aspm_entry_latency(tp);
 
rtl_disable_clock_request(tp);
-
-   if (tp->dev->mtu <= ETH_DATA_LEN)
-   rtl_tx_performance_tweak(tp, PCI_EXP_DEVCTL_READRQ_4096B);
 }
 
 static void rtl_hw_start_8168dp(struct rtl8169_private *tp)
 {
rtl_set_def_aspm_entry_latency(tp);
 
-   if (tp->dev->mtu <= ETH_DATA_LEN)
-   rtl_tx_performance_tweak(tp, PCI_EXP_DEVCTL_READRQ_4096B);
-
rtl_disable_clock_request(tp);
 }
 
@@ -4601,8 +4585,6 @@ static void rtl_hw_start_8168d_4(struct rtl8169_private 
*tp)
 
rtl_set_def_aspm_entry_latency(tp);
 
-   rtl_tx_performance_tweak(tp, PCI_EXP_DEVCTL_READRQ_4096B);
-
rtl_ephy_init(tp, e_info_8168d_4);
 
rtl_enable_clock_request(tp);
@@ -4677,8 +4659,6 @@ static void rtl_hw_start_8168f(struct rtl8169_private *tp)
 {
rtl_set_def_aspm_entry_latency(tp);
 
-   rtl_tx_performance_tweak(tp, PCI_EXP_DEVCTL_READRQ_4096B);
-
rtl_eri_write(tp, 0xc0, ERIAR_MASK_0011, 0x);
rtl_eri_write(tp, 0xb8, ERIAR_MASK_0011, 0x);
rtl_set_fifo_size(tp, 0x10, 0x10, 0x02, 0x06);
@@ -4741,8 +4721,6 @@ static void rtl_hw_start_8168g(struct rtl8169_private *tp)
 
rtl_set_def_aspm_entry_latency(tp);
 
-   rtl_tx_performance_tweak(tp, PCI_EXP_DEVCTL_READRQ_4096B);
-
rtl_reset_packet_filter(tp);
rtl_eri_write(tp, 

[PATCH 5.4 64/73] ARM: footbridge: fix PCI interrupt mapping

2021-04-19 Thread Greg Kroah-Hartman
From: Russell King 

[ Upstream commit 30e3b4f256b4e366a61658c294f6a21b8626dda7 ]

Since commit 30fdfb929e82 ("PCI: Add a call to pci_assign_irq() in
pci_device_probe()"), the PCI code will call the IRQ mapping function
whenever a PCI driver is probed. If these are marked as __init, this
causes an oops if a PCI driver is loaded or bound after the kernel has
initialised.

Fixes: 30fdfb929e82 ("PCI: Add a call to pci_assign_irq() in 
pci_device_probe()")
Signed-off-by: Russell King 
Signed-off-by: Sasha Levin 
---
 arch/arm/mach-footbridge/cats-pci.c  | 4 ++--
 arch/arm/mach-footbridge/ebsa285-pci.c   | 4 ++--
 arch/arm/mach-footbridge/netwinder-pci.c | 2 +-
 arch/arm/mach-footbridge/personal-pci.c  | 5 ++---
 4 files changed, 7 insertions(+), 8 deletions(-)

diff --git a/arch/arm/mach-footbridge/cats-pci.c 
b/arch/arm/mach-footbridge/cats-pci.c
index 0b2fd7e2e9b4..90b1e9be430e 100644
--- a/arch/arm/mach-footbridge/cats-pci.c
+++ b/arch/arm/mach-footbridge/cats-pci.c
@@ -15,14 +15,14 @@
 #include 
 
 /* cats host-specific stuff */
-static int irqmap_cats[] __initdata = { IRQ_PCI, IRQ_IN0, IRQ_IN1, IRQ_IN3 };
+static int irqmap_cats[] = { IRQ_PCI, IRQ_IN0, IRQ_IN1, IRQ_IN3 };
 
 static u8 cats_no_swizzle(struct pci_dev *dev, u8 *pin)
 {
return 0;
 }
 
-static int __init cats_map_irq(const struct pci_dev *dev, u8 slot, u8 pin)
+static int cats_map_irq(const struct pci_dev *dev, u8 slot, u8 pin)
 {
if (dev->irq >= 255)
return -1;  /* not a valid interrupt. */
diff --git a/arch/arm/mach-footbridge/ebsa285-pci.c 
b/arch/arm/mach-footbridge/ebsa285-pci.c
index 6f28aaa9ca79..c3f280d08fa7 100644
--- a/arch/arm/mach-footbridge/ebsa285-pci.c
+++ b/arch/arm/mach-footbridge/ebsa285-pci.c
@@ -14,9 +14,9 @@
 #include 
 #include 
 
-static int irqmap_ebsa285[] __initdata = { IRQ_IN3, IRQ_IN1, IRQ_IN0, IRQ_PCI 
};
+static int irqmap_ebsa285[] = { IRQ_IN3, IRQ_IN1, IRQ_IN0, IRQ_PCI };
 
-static int __init ebsa285_map_irq(const struct pci_dev *dev, u8 slot, u8 pin)
+static int ebsa285_map_irq(const struct pci_dev *dev, u8 slot, u8 pin)
 {
if (dev->vendor == PCI_VENDOR_ID_CONTAQ &&
dev->device == PCI_DEVICE_ID_CONTAQ_82C693)
diff --git a/arch/arm/mach-footbridge/netwinder-pci.c 
b/arch/arm/mach-footbridge/netwinder-pci.c
index 9473aa0305e5..e8304392074b 100644
--- a/arch/arm/mach-footbridge/netwinder-pci.c
+++ b/arch/arm/mach-footbridge/netwinder-pci.c
@@ -18,7 +18,7 @@
  * We now use the slot ID instead of the device identifiers to select
  * which interrupt is routed where.
  */
-static int __init netwinder_map_irq(const struct pci_dev *dev, u8 slot, u8 pin)
+static int netwinder_map_irq(const struct pci_dev *dev, u8 slot, u8 pin)
 {
switch (slot) {
case 0:  /* host bridge */
diff --git a/arch/arm/mach-footbridge/personal-pci.c 
b/arch/arm/mach-footbridge/personal-pci.c
index 4391e433a4b2..9d19aa98a663 100644
--- a/arch/arm/mach-footbridge/personal-pci.c
+++ b/arch/arm/mach-footbridge/personal-pci.c
@@ -14,13 +14,12 @@
 #include 
 #include 
 
-static int irqmap_personal_server[] __initdata = {
+static int irqmap_personal_server[] = {
IRQ_IN0, IRQ_IN1, IRQ_IN2, IRQ_IN3, 0, 0, 0,
IRQ_DOORBELLHOST, IRQ_DMA1, IRQ_DMA2, IRQ_PCI
 };
 
-static int __init personal_server_map_irq(const struct pci_dev *dev, u8 slot,
-   u8 pin)
+static int personal_server_map_irq(const struct pci_dev *dev, u8 slot, u8 pin)
 {
unsigned char line;
 
-- 
2.30.2





[PATCH 5.4 63/73] gro: ensure frag0 meets IP header alignment

2021-04-19 Thread Greg Kroah-Hartman
From: Eric Dumazet 

commit 38ec4944b593fd90c5ef4253e66ae5769d04 upstream.

After commit 0f6925b3e8da ("virtio_net: Do not pull payload in skb->head")
Guenter Roeck reported one failure in his tests using sh architecture.

After much debugging, we have been able to spot silent unaligned accesses
in inet_gro_receive()

The issue at hand is that upper networking stacks assume their header
is word-aligned. Low level drivers are supposed to reserve NET_IP_ALIGN
bytes before the Ethernet header to make that happen.

This patch hardens skb_gro_reset_offset() to not allow frag0 fast-path
if the fragment is not properly aligned.

Some arches like x86, arm64 and powerpc do not care and define NET_IP_ALIGN
as 0, this extra check will be a NOP for them.

Note that if frag0 is not used, GRO will call pskb_may_pull()
as many times as needed to pull network and transport headers.

Fixes: 0f6925b3e8da ("virtio_net: Do not pull payload in skb->head")
Fixes: 78a478d0efd9 ("gro: Inline skb_gro_header and cache frag0 virtual 
address")
Signed-off-by: Eric Dumazet 
Reported-by: Guenter Roeck 
Cc: Xuan Zhuo 
Cc: "Michael S. Tsirkin" 
Cc: Jason Wang 
Acked-by: Michael S. Tsirkin 
Tested-by: Guenter Roeck 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman 
---
 net/core/dev.c |3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -5406,7 +5406,8 @@ static void skb_gro_reset_offset(struct
 
if (skb_mac_header(skb) == skb_tail_pointer(skb) &&
pinfo->nr_frags &&
-   !PageHighMem(skb_frag_page(frag0))) {
+   !PageHighMem(skb_frag_page(frag0)) &&
+   (!NET_IP_ALIGN || !(skb_frag_off(frag0) & 3))) {
NAPI_GRO_CB(skb)->frag0 = skb_frag_address(frag0);
NAPI_GRO_CB(skb)->frag0_len = min_t(unsigned int,
skb_frag_size(frag0),




[PATCH 5.4 62/73] ibmvnic: remove duplicate napi_schedule call in open function

2021-04-19 Thread Greg Kroah-Hartman
From: Lijun Pan 

commit 7c451f3ef676c805a4b77a743a01a5c21a250a73 upstream.

Remove the unnecessary napi_schedule() call in __ibmvnic_open() since
interrupt_rx() calls napi_schedule_prep/__napi_schedule during every
receive interrupt.

Fixes: ed651a10875f ("ibmvnic: Updated reset handling")
Signed-off-by: Lijun Pan 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/net/ethernet/ibm/ibmvnic.c |5 -
 1 file changed, 5 deletions(-)

--- a/drivers/net/ethernet/ibm/ibmvnic.c
+++ b/drivers/net/ethernet/ibm/ibmvnic.c
@@ -1088,11 +1088,6 @@ static int __ibmvnic_open(struct net_dev
 
netif_tx_start_all_queues(netdev);
 
-   if (prev_state == VNIC_CLOSED) {
-   for (i = 0; i < adapter->req_rx_queues; i++)
-   napi_schedule(>napi[i]);
-   }
-
adapter->state = VNIC_OPEN;
return rc;
 }




[PATCH 5.4 73/73] net: phy: marvell: fix detection of PHY on Topaz switches

2021-04-19 Thread Greg Kroah-Hartman
From: Pali Rohár 

commit 1fe976d308acb6374c899a4ee8025a0a016e453e upstream.

Since commit fee2d546414d ("net: phy: marvell: mv88e6390 temperature
sensor reading"), Linux reports the temperature of Topaz hwmon as
constant -75°C.

This is because switches from the Topaz family (88E6141 / 88E6341) have
the address of the temperature sensor register different from Peridot.

This address is instead compatible with 88E1510 PHYs, as was used for
Topaz before the above mentioned commit.

Create a new mapping table between switch family and PHY ID for families
which don't have a model number. And define PHY IDs for Topaz and Peridot
families.

Create a new PHY ID and a new PHY driver for Topaz's internal PHY.
The only difference from Peridot's PHY driver is the HWMON probing
method.

Prior this change Topaz's internal PHY is detected by kernel as:

  PHY [...] driver [Marvell 88E6390] (irq=63)

And afterwards as:

  PHY [...] driver [Marvell 88E6341 Family] (irq=63)

Signed-off-by: Pali Rohár 
BugLink: https://github.com/globalscaletechnologies/linux/issues/1
Fixes: fee2d546414d ("net: phy: marvell: mv88e6390 temperature sensor reading")
Reviewed-by: Marek Behún 
Reviewed-by: Andrew Lunn 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/net/dsa/mv88e6xxx/chip.c |   30 +-
 drivers/net/phy/marvell.c|   29 ++---
 include/linux/marvell_phy.h  |5 +++--
 3 files changed, 42 insertions(+), 22 deletions(-)

--- a/drivers/net/dsa/mv88e6xxx/chip.c
+++ b/drivers/net/dsa/mv88e6xxx/chip.c
@@ -2766,10 +2766,17 @@ unlock:
return err;
 }
 
+/* prod_id for switch families which do not have a PHY model number */
+static const u16 family_prod_id_table[] = {
+   [MV88E6XXX_FAMILY_6341] = MV88E6XXX_PORT_SWITCH_ID_PROD_6341,
+   [MV88E6XXX_FAMILY_6390] = MV88E6XXX_PORT_SWITCH_ID_PROD_6390,
+};
+
 static int mv88e6xxx_mdio_read(struct mii_bus *bus, int phy, int reg)
 {
struct mv88e6xxx_mdio_bus *mdio_bus = bus->priv;
struct mv88e6xxx_chip *chip = mdio_bus->chip;
+   u16 prod_id;
u16 val;
int err;
 
@@ -2780,23 +2787,12 @@ static int mv88e6xxx_mdio_read(struct mi
err = chip->info->ops->phy_read(chip, bus, phy, reg, );
mv88e6xxx_reg_unlock(chip);
 
-   if (reg == MII_PHYSID2) {
-   /* Some internal PHYs don't have a model number. */
-   if (chip->info->family != MV88E6XXX_FAMILY_6165)
-   /* Then there is the 6165 family. It gets is
-* PHYs correct. But it can also have two
-* SERDES interfaces in the PHY address
-* space. And these don't have a model
-* number. But they are not PHYs, so we don't
-* want to give them something a PHY driver
-* will recognise.
-*
-* Use the mv88e6390 family model number
-* instead, for anything which really could be
-* a PHY,
-*/
-   if (!(val & 0x3f0))
-   val |= MV88E6XXX_PORT_SWITCH_ID_PROD_6390 >> 4;
+   /* Some internal PHYs don't have a model number. */
+   if (reg == MII_PHYSID2 && !(val & 0x3f0) &&
+   chip->info->family < ARRAY_SIZE(family_prod_id_table)) {
+   prod_id = family_prod_id_table[chip->info->family];
+   if (prod_id)
+   val |= prod_id >> 4;
}
 
return err ? err : val;
--- a/drivers/net/phy/marvell.c
+++ b/drivers/net/phy/marvell.c
@@ -2401,9 +2401,31 @@ static struct phy_driver marvell_drivers
.get_stats = marvell_get_stats,
},
{
-   .phy_id = MARVELL_PHY_ID_88E6390,
+   .phy_id = MARVELL_PHY_ID_88E6341_FAMILY,
.phy_id_mask = MARVELL_PHY_ID_MASK,
-   .name = "Marvell 88E6390",
+   .name = "Marvell 88E6341 Family",
+   /* PHY_GBIT_FEATURES */
+   .probe = m88e1510_probe,
+   .config_init = _config_init,
+   .config_aneg = _config_aneg,
+   .read_status = _read_status,
+   .ack_interrupt = _ack_interrupt,
+   .config_intr = _config_intr,
+   .did_interrupt = _did_interrupt,
+   .resume = _resume,
+   .suspend = _suspend,
+   .read_page = marvell_read_page,
+   .write_page = marvell_write_page,
+   .get_sset_count = marvell_get_sset_count,
+   .get_strings = marvell_get_strings,
+   .get_stats = marvell_get_stats,
+   .get_tunable = m88e1540_get_tunable,
+   .set_tunable = m88e1540_set_tun

[PATCH 5.4 61/73] ibmvnic: remove duplicate napi_schedule call in do_reset function

2021-04-19 Thread Greg Kroah-Hartman
From: Lijun Pan 

commit d3a6abccbd272aea7dc2c6f984bb5a2c11278e44 upstream.

During adapter reset, do_reset/do_hard_reset calls ibmvnic_open(),
which will calls napi_schedule if previous state is VNIC_CLOSED
(i.e, the reset case, and "ifconfig down" case). So there is no need
for do_reset to call napi_schedule again at the end of the function
though napi_schedule will neglect the request if napi is already
scheduled.

Fixes: ed651a10875f ("ibmvnic: Updated reset handling")
Signed-off-by: Lijun Pan 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/net/ethernet/ibm/ibmvnic.c |6 +-
 1 file changed, 1 insertion(+), 5 deletions(-)

--- a/drivers/net/ethernet/ibm/ibmvnic.c
+++ b/drivers/net/ethernet/ibm/ibmvnic.c
@@ -1849,7 +1849,7 @@ static int do_reset(struct ibmvnic_adapt
u64 old_num_rx_queues, old_num_tx_queues;
u64 old_num_rx_slots, old_num_tx_slots;
struct net_device *netdev = adapter->netdev;
-   int i, rc;
+   int rc;
 
netdev_dbg(adapter->netdev, "Re-setting driver (%d)\n",
   rwi->reset_reason);
@@ -1994,10 +1994,6 @@ static int do_reset(struct ibmvnic_adapt
/* refresh device's multicast list */
ibmvnic_set_multi(netdev);
 
-   /* kick napi */
-   for (i = 0; i < adapter->req_rx_queues; i++)
-   napi_schedule(>napi[i]);
-
if (adapter->reset_reason == VNIC_RESET_FAILOVER ||
adapter->reset_reason == VNIC_RESET_MOBILITY) {
call_netdevice_notifiers(NETDEV_NOTIFY_PEERS, netdev);




[PATCH 5.4 72/73] ARM: 9071/1: uprobes: Dont hook on thumb instructions

2021-04-19 Thread Greg Kroah-Hartman
From: Fredrik Strupe 

commit d2f7eca60b29006285d57c7035539e33300e89e5 upstream.

Since uprobes is not supported for thumb, check that the thumb bit is
not set when matching the uprobes instruction hooks.

The Arm UDF instructions used for uprobes triggering
(UPROBE_SWBP_ARM_INSN and UPROBE_SS_ARM_INSN) coincidentally share the
same encoding as a pair of unallocated 32-bit thumb instructions (not
UDF) when the condition code is 0b (0xf). This in effect makes it
possible to trigger the uprobes functionality from thumb, and at that
using two unallocated instructions which are not permanently undefined.

Signed-off-by: Fredrik Strupe 
Cc: sta...@vger.kernel.org
Fixes: c7edc9e326d5 ("ARM: add uprobes support")
Signed-off-by: Russell King 
Signed-off-by: Greg Kroah-Hartman 
---
 arch/arm/probes/uprobes/core.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

--- a/arch/arm/probes/uprobes/core.c
+++ b/arch/arm/probes/uprobes/core.c
@@ -204,7 +204,7 @@ unsigned long uprobe_get_swbp_addr(struc
 static struct undef_hook uprobes_arm_break_hook = {
.instr_mask = 0x0fff,
.instr_val  = (UPROBE_SWBP_ARM_INSN & 0x0fff),
-   .cpsr_mask  = MODE_MASK,
+   .cpsr_mask  = (PSR_T_BIT | MODE_MASK),
.cpsr_val   = USR_MODE,
.fn = uprobe_trap_handler,
 };
@@ -212,7 +212,7 @@ static struct undef_hook uprobes_arm_bre
 static struct undef_hook uprobes_arm_ss_hook = {
.instr_mask = 0x0fff,
.instr_val  = (UPROBE_SS_ARM_INSN & 0x0fff),
-   .cpsr_mask  = MODE_MASK,
+   .cpsr_mask  = (PSR_T_BIT | MODE_MASK),
.cpsr_val   = USR_MODE,
.fn = uprobe_trap_handler,
 };




[PATCH 5.4 71/73] r8169: dont advertise pause in jumbo mode

2021-04-19 Thread Greg Kroah-Hartman
From: Heiner Kallweit 

[ Upstream commit 453a77894efa4d9b6ef9644d74b9419c47ac427c ]

It has been reported [0] that using pause frames in jumbo mode impacts
performance. There's no available chip documentation, but vendor
drivers r8168 and r8125 don't advertise pause in jumbo mode. So let's
do the same, according to Roman it fixes the issue.

[0] https://bugzilla.kernel.org/show_bug.cgi?id=212617

Fixes: 9cf9b84cc701 ("r8169: make use of phy_set_asym_pause")
Reported-by: Roman Mamedov 
Tested-by: Roman Mamedov 
Signed-off-by: Heiner Kallweit 
Cc: sta...@vger.kernel.org
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin 
---
 drivers/net/ethernet/realtek/r8169_main.c | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/realtek/r8169_main.c 
b/drivers/net/ethernet/realtek/r8169_main.c
index 4e4953b1433a..8ff178fc2670 100644
--- a/drivers/net/ethernet/realtek/r8169_main.c
+++ b/drivers/net/ethernet/realtek/r8169_main.c
@@ -4138,6 +4138,13 @@ static void rtl_jumbo_config(struct rtl8169_private *tp)
 
if (pci_is_pcie(tp->pci_dev) && tp->supports_gmii)
pcie_set_readrq(tp->pci_dev, readrq);
+
+   /* Chip doesn't support pause in jumbo mode */
+   linkmode_mod_bit(ETHTOOL_LINK_MODE_Pause_BIT,
+tp->phydev->advertising, !jumbo);
+   linkmode_mod_bit(ETHTOOL_LINK_MODE_Asym_Pause_BIT,
+tp->phydev->advertising, !jumbo);
+   phy_start_aneg(tp->phydev);
 }
 
 DECLARE_RTL_COND(rtl_chipcmd_cond)
@@ -6314,8 +6321,6 @@ static int r8169_phy_connect(struct rtl8169_private *tp)
if (!tp->supports_gmii)
phy_set_max_speed(phydev, SPEED_100);
 
-   phy_support_asym_pause(phydev);
-
phy_attached_info(phydev);
 
return 0;
-- 
2.30.2





[PATCH 5.4 31/73] net: ieee802154: forbid monitor for add llsec devkey

2021-04-19 Thread Greg Kroah-Hartman
From: Alexander Aring 

[ Upstream commit a347b3b394868fef15b16f143719df56184be81d ]

This patch forbids to add llsec devkey for monitor interfaces which we
don't support yet. Otherwise we will access llsec mib which isn't
initialized for monitors.

Signed-off-by: Alexander Aring 
Link: https://lore.kernel.org/r/20210405003054.256017-11-aahri...@redhat.com
Signed-off-by: Stefan Schmidt 
Signed-off-by: Sasha Levin 
---
 net/ieee802154/nl802154.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/net/ieee802154/nl802154.c b/net/ieee802154/nl802154.c
index 66785e1eb559..65987215dd0c 100644
--- a/net/ieee802154/nl802154.c
+++ b/net/ieee802154/nl802154.c
@@ -1936,6 +1936,9 @@ static int nl802154_add_llsec_devkey(struct sk_buff *skb, 
struct genl_info *info
struct ieee802154_llsec_device_key key;
__le64 extended_addr;
 
+   if (wpan_dev->iftype == NL802154_IFTYPE_MONITOR)
+   return -EOPNOTSUPP;
+
if (!info->attrs[NL802154_ATTR_SEC_DEVKEY] ||
nla_parse_nested_deprecated(attrs, NL802154_DEVKEY_ATTR_MAX, 
info->attrs[NL802154_ATTR_SEC_DEVKEY], nl802154_devkey_policy, info->extack) < 
0)
return -EINVAL;
-- 
2.30.2





[PATCH 5.4 70/73] r8169: tweak max read request size for newer chips also in jumbo mtu mode

2021-04-19 Thread Greg Kroah-Hartman
From: Heiner Kallweit 

[ Upstream commit 5e00e16cb98935bcf06f51931876d898c226f65c ]

So far we don't increase the max read request size if we switch to
jumbo mode before bringing up the interface for the first time.
Let's change this.

Signed-off-by: Heiner Kallweit 
Signed-off-by: Jakub Kicinski 
Signed-off-by: Sasha Levin 
---
 drivers/net/ethernet/realtek/r8169_main.c | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/net/ethernet/realtek/r8169_main.c 
b/drivers/net/ethernet/realtek/r8169_main.c
index 1352dd0b69e9..4e4953b1433a 100644
--- a/drivers/net/ethernet/realtek/r8169_main.c
+++ b/drivers/net/ethernet/realtek/r8169_main.c
@@ -4096,13 +4096,14 @@ static void r8168b_1_hw_jumbo_disable(struct 
rtl8169_private *tp)
 static void rtl_jumbo_config(struct rtl8169_private *tp)
 {
bool jumbo = tp->dev->mtu > ETH_DATA_LEN;
+   int readrq = 4096;
 
rtl_unlock_config_regs(tp);
switch (tp->mac_version) {
case RTL_GIGA_MAC_VER_12:
case RTL_GIGA_MAC_VER_17:
if (jumbo) {
-   pcie_set_readrq(tp->pci_dev, 512);
+   readrq = 512;
r8168b_1_hw_jumbo_enable(tp);
} else {
r8168b_1_hw_jumbo_disable(tp);
@@ -4110,7 +4111,7 @@ static void rtl_jumbo_config(struct rtl8169_private *tp)
break;
case RTL_GIGA_MAC_VER_18 ... RTL_GIGA_MAC_VER_26:
if (jumbo) {
-   pcie_set_readrq(tp->pci_dev, 512);
+   readrq = 512;
r8168c_hw_jumbo_enable(tp);
} else {
r8168c_hw_jumbo_disable(tp);
@@ -4135,8 +4136,8 @@ static void rtl_jumbo_config(struct rtl8169_private *tp)
}
rtl_lock_config_regs(tp);
 
-   if (!jumbo && pci_is_pcie(tp->pci_dev) && tp->supports_gmii)
-   pcie_set_readrq(tp->pci_dev, 4096);
+   if (pci_is_pcie(tp->pci_dev) && tp->supports_gmii)
+   pcie_set_readrq(tp->pci_dev, readrq);
 }
 
 DECLARE_RTL_COND(rtl_chipcmd_cond)
-- 
2.30.2





[PATCH 5.4 44/73] readdir: make sure to verify directory entry for legacy interfaces too

2021-04-19 Thread Greg Kroah-Hartman
From: Linus Torvalds 

commit 0c93ac69407d63a85be0129aa55ffaec27ffebd3 upstream.

This does the directory entry name verification for the legacy
"fillonedir" (and compat) interface that goes all the way back to the
dark ages before we had a proper dirent, and the readdir() system call
returned just a single entry at a time.

Nobody should use this interface unless you still have binaries from
1991, but let's do it right.

This came up during discussions about unsafe_copy_to_user() and proper
checking of all the inputs to it, as the networking layer is looking to
use it in a few new places.  So let's make sure the _old_ users do it
all right and proper, before we add new ones.

See also commit 8a23eb804ca4 ("Make filldir[64]() verify the directory
entry filename is valid") which did the proper modern interfaces that
people actually use. It had a note:

Note that I didn't bother adding the checks to any legacy interfaces
that nobody uses.

which this now corrects.  Note that we really don't care about POSIX and
the presense of '/' in a directory entry, but verify_dirent_name() also
ends up doing the proper name length verification which is what the
input checking discussion was about.

[ Another option would be to remove the support for this particular very
  old interface: any binaries that use it are likely a.out binaries, and
  they will no longer run anyway since we removed a.out binftm support
  in commit eac616557050 ("x86: Deprecate a.out support").

  But I'm not sure which came first: getdents() or ELF support, so let's
  pretend somebody might still have a working binary that uses the
  legacy readdir() case.. ]

Link: 
https://lore.kernel.org/lkml/CAHk-=wjbvzcahatvg0d81w5o0-kt5ppthhfj5iedfq+bgtg...@mail.gmail.com/
Acked-by: Al Viro 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman 
---
 fs/readdir.c |6 ++
 1 file changed, 6 insertions(+)

--- a/fs/readdir.c
+++ b/fs/readdir.c
@@ -150,6 +150,9 @@ static int fillonedir(struct dir_context
 
if (buf->result)
return -EINVAL;
+   buf->result = verify_dirent_name(name, namlen);
+   if (buf->result < 0)
+   return buf->result;
d_ino = ino;
if (sizeof(d_ino) < sizeof(ino) && d_ino != ino) {
buf->result = -EOVERFLOW;
@@ -417,6 +420,9 @@ static int compat_fillonedir(struct dir_
 
if (buf->result)
return -EINVAL;
+   buf->result = verify_dirent_name(name, namlen);
+   if (buf->result < 0)
+   return buf->result;
d_ino = ino;
if (sizeof(d_ino) < sizeof(ino) && d_ino != ino) {
buf->result = -EOVERFLOW;




[PATCH 5.4 42/73] HID: wacom: set EV_KEY and EV_ABS only for non-HID_GENERIC type of devices

2021-04-19 Thread Greg Kroah-Hartman
From: Ping Cheng 

commit 276559d8d02c2709281578976ca2f53bc62063d4 upstream.

Valid HID_GENERIC type of devices set EV_KEY and EV_ABS by wacom_map_usage.
When *_input_capabilities are reached, those devices should already have
their proper EV_* set. EV_KEY and EV_ABS only need to be set for
non-HID_GENERIC type of devices in *_input_capabilities.

Devices that don't support HID descitoprs will pass back to hid-input for
registration without being accidentally rejected by the introduction of
patch: "Input: refuse to register absolute devices without absinfo"

Fixes: 6ecfe51b4082 ("Input: refuse to register absolute devices without 
absinfo")
Signed-off-by: Ping Cheng 
Reviewed-by: Jason Gerecke 
Tested-by: Juan Garrido 
CC: sta...@vger.kernel.org
Signed-off-by: Jiri Kosina 
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/hid/wacom_wac.c |6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

--- a/drivers/hid/wacom_wac.c
+++ b/drivers/hid/wacom_wac.c
@@ -3574,8 +3574,6 @@ int wacom_setup_pen_input_capabilities(s
 {
struct wacom_features *features = _wac->features;
 
-   input_dev->evbit[0] |= BIT_MASK(EV_KEY) | BIT_MASK(EV_ABS);
-
if (!(features->device_type & WACOM_DEVICETYPE_PEN))
return -ENODEV;
 
@@ -3590,6 +3588,7 @@ int wacom_setup_pen_input_capabilities(s
return 0;
}
 
+   input_dev->evbit[0] |= BIT_MASK(EV_KEY) | BIT_MASK(EV_ABS);
__set_bit(BTN_TOUCH, input_dev->keybit);
__set_bit(ABS_MISC, input_dev->absbit);
 
@@ -3742,8 +3741,6 @@ int wacom_setup_touch_input_capabilities
 {
struct wacom_features *features = _wac->features;
 
-   input_dev->evbit[0] |= BIT_MASK(EV_KEY) | BIT_MASK(EV_ABS);
-
if (!(features->device_type & WACOM_DEVICETYPE_TOUCH))
return -ENODEV;
 
@@ -3756,6 +3753,7 @@ int wacom_setup_touch_input_capabilities
/* setup has already been done */
return 0;
 
+   input_dev->evbit[0] |= BIT_MASK(EV_KEY) | BIT_MASK(EV_ABS);
__set_bit(BTN_TOUCH, input_dev->keybit);
 
if (features->touch_max == 1) {




[PATCH 5.4 24/73] net: ieee802154: stop dump llsec keys for monitors

2021-04-19 Thread Greg Kroah-Hartman
From: Alexander Aring 

[ Upstream commit fb3c5cdf88cd504ef11d59e8d656f4bc896c6922 ]

This patch stops dumping llsec keys for monitors which we don't support
yet. Otherwise we will access llsec mib which isn't initialized for
monitors.

Signed-off-by: Alexander Aring 
Link: https://lore.kernel.org/r/20210405003054.256017-4-aahri...@redhat.com
Signed-off-by: Stefan Schmidt 
Signed-off-by: Sasha Levin 
---
 net/ieee802154/nl802154.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/net/ieee802154/nl802154.c b/net/ieee802154/nl802154.c
index f03958fcb5be..27e34aab09a6 100644
--- a/net/ieee802154/nl802154.c
+++ b/net/ieee802154/nl802154.c
@@ -1514,6 +1514,11 @@ nl802154_dump_llsec_key(struct sk_buff *skb, struct 
netlink_callback *cb)
if (err)
return err;
 
+   if (wpan_dev->iftype == NL802154_IFTYPE_MONITOR) {
+   err = skb->len;
+   goto out_err;
+   }
+
if (!wpan_dev->netdev) {
err = -EINVAL;
goto out_err;
-- 
2.30.2





[PATCH 5.4 29/73] net: ieee802154: forbid monitor for del llsec dev

2021-04-19 Thread Greg Kroah-Hartman
From: Alexander Aring 

[ Upstream commit ad8f9de1f3566686af35b1c6b43240726541da61 ]

This patch forbids to del llsec dev for monitor interfaces which we
don't support yet. Otherwise we will access llsec mib which isn't
initialized for monitors.

Signed-off-by: Alexander Aring 
Link: https://lore.kernel.org/r/20210405003054.256017-9-aahri...@redhat.com
Signed-off-by: Stefan Schmidt 
Signed-off-by: Sasha Levin 
---
 net/ieee802154/nl802154.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/net/ieee802154/nl802154.c b/net/ieee802154/nl802154.c
index 797888b4b2ce..4f6777193029 100644
--- a/net/ieee802154/nl802154.c
+++ b/net/ieee802154/nl802154.c
@@ -1802,6 +1802,9 @@ static int nl802154_del_llsec_dev(struct sk_buff *skb, 
struct genl_info *info)
struct nlattr *attrs[NL802154_DEV_ATTR_MAX + 1];
__le64 extended_addr;
 
+   if (wpan_dev->iftype == NL802154_IFTYPE_MONITOR)
+   return -EOPNOTSUPP;
+
if (!info->attrs[NL802154_ATTR_SEC_DEVICE] ||
nla_parse_nested_deprecated(attrs, NL802154_DEV_ATTR_MAX, 
info->attrs[NL802154_ATTR_SEC_DEVICE], nl802154_dev_policy, info->extack))
return -EINVAL;
-- 
2.30.2





[PATCH 5.4 28/73] net: ieee802154: forbid monitor for add llsec dev

2021-04-19 Thread Greg Kroah-Hartman
From: Alexander Aring 

[ Upstream commit 5303f956b05a2886ff42890908156afaec0f95ac ]

This patch forbids to add llsec dev for monitor interfaces which we
don't support yet. Otherwise we will access llsec mib which isn't
initialized for monitors.

Signed-off-by: Alexander Aring 
Link: https://lore.kernel.org/r/20210405003054.256017-8-aahri...@redhat.com
Signed-off-by: Stefan Schmidt 
Signed-off-by: Sasha Levin 
---
 net/ieee802154/nl802154.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/net/ieee802154/nl802154.c b/net/ieee802154/nl802154.c
index 97074180c2e5..797888b4b2ce 100644
--- a/net/ieee802154/nl802154.c
+++ b/net/ieee802154/nl802154.c
@@ -1784,6 +1784,9 @@ static int nl802154_add_llsec_dev(struct sk_buff *skb, 
struct genl_info *info)
struct wpan_dev *wpan_dev = dev->ieee802154_ptr;
struct ieee802154_llsec_device dev_desc;
 
+   if (wpan_dev->iftype == NL802154_IFTYPE_MONITOR)
+   return -EOPNOTSUPP;
+
if (ieee802154_llsec_parse_device(info->attrs[NL802154_ATTR_SEC_DEVICE],
  _desc) < 0)
return -EINVAL;
-- 
2.30.2





[PATCH 5.4 27/73] net: ieee802154: stop dump llsec devs for monitors

2021-04-19 Thread Greg Kroah-Hartman
From: Alexander Aring 

[ Upstream commit 5582d641e6740839c9b83efd1fbf9bcd00b6f5fc ]

This patch stops dumping llsec devs for monitors which we don't support
yet. Otherwise we will access llsec mib which isn't initialized for
monitors.

Signed-off-by: Alexander Aring 
Link: https://lore.kernel.org/r/20210405003054.256017-7-aahri...@redhat.com
Signed-off-by: Stefan Schmidt 
Signed-off-by: Sasha Levin 
---
 net/ieee802154/nl802154.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/net/ieee802154/nl802154.c b/net/ieee802154/nl802154.c
index 7fdcbaecc4fd..97074180c2e5 100644
--- a/net/ieee802154/nl802154.c
+++ b/net/ieee802154/nl802154.c
@@ -1693,6 +1693,11 @@ nl802154_dump_llsec_dev(struct sk_buff *skb, struct 
netlink_callback *cb)
if (err)
return err;
 
+   if (wpan_dev->iftype == NL802154_IFTYPE_MONITOR) {
+   err = skb->len;
+   goto out_err;
+   }
+
if (!wpan_dev->netdev) {
err = -EINVAL;
goto out_err;
-- 
2.30.2





[PATCH 5.4 26/73] net: ieee802154: forbid monitor for del llsec key

2021-04-19 Thread Greg Kroah-Hartman
From: Alexander Aring 

[ Upstream commit b6e2949544a183f590ae6f3ef2d12c44e38a ]

This patch forbids to del llsec key for monitor interfaces which we
don't support yet. Otherwise we will access llsec mib which isn't
initialized for monitors.

Signed-off-by: Alexander Aring 
Link: https://lore.kernel.org/r/20210405003054.256017-6-aahri...@redhat.com
Signed-off-by: Stefan Schmidt 
Signed-off-by: Sasha Levin 
---
 net/ieee802154/nl802154.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/net/ieee802154/nl802154.c b/net/ieee802154/nl802154.c
index 0920f320b59b..7fdcbaecc4fd 100644
--- a/net/ieee802154/nl802154.c
+++ b/net/ieee802154/nl802154.c
@@ -1625,6 +1625,9 @@ static int nl802154_del_llsec_key(struct sk_buff *skb, 
struct genl_info *info)
struct nlattr *attrs[NL802154_KEY_ATTR_MAX + 1];
struct ieee802154_llsec_key_id id;
 
+   if (wpan_dev->iftype == NL802154_IFTYPE_MONITOR)
+   return -EOPNOTSUPP;
+
if (!info->attrs[NL802154_ATTR_SEC_KEY] ||
nla_parse_nested_deprecated(attrs, NL802154_KEY_ATTR_MAX, 
info->attrs[NL802154_ATTR_SEC_KEY], nl802154_key_policy, info->extack))
return -EINVAL;
-- 
2.30.2





[PATCH 5.4 59/73] i40e: fix the panic when running bpf in xdpdrv mode

2021-04-19 Thread Greg Kroah-Hartman
From: Jason Xing 

commit 4e39a072a6a0fc422ba7da5e4336bdc295d70211 upstream.

Fix this panic by adding more rules to calculate the value of @rss_size_max
which could be used in allocating the queues when bpf is loaded, which,
however, could cause the failure and then trigger the NULL pointer of
vsi->rx_rings. Prio to this fix, the machine doesn't care about how many
cpus are online and then allocates 256 queues on the machine with 32 cpus
online actually.

Once the load of bpf begins, the log will go like this "failed to get
tracking for 256 queues for VSI 0 err -12" and this "setup of MAIN VSI
failed".

Thus, I attach the key information of the crash-log here.

BUG: unable to handle kernel NULL pointer dereference at

RIP: 0010:i40e_xdp+0xdd/0x1b0 [i40e]
Call Trace:
[2160294.717292]  ? i40e_reconfig_rss_queues+0x170/0x170 [i40e]
[2160294.717666]  dev_xdp_install+0x4f/0x70
[2160294.718036]  dev_change_xdp_fd+0x11f/0x230
[2160294.718380]  ? dev_disable_lro+0xe0/0xe0
[2160294.718705]  do_setlink+0xac7/0xe70
[2160294.719035]  ? __nla_parse+0xed/0x120
[2160294.719365]  rtnl_newlink+0x73b/0x860

Fixes: 41c445ff0f48 ("i40e: main driver core")
Co-developed-by: Shujin Li 
Signed-off-by: Shujin Li 
Signed-off-by: Jason Xing 
Reviewed-by: Jesse Brandeburg 
Acked-by: Jesper Dangaard Brouer 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/net/ethernet/intel/i40e/i40e_main.c |6 ++
 1 file changed, 6 insertions(+)

--- a/drivers/net/ethernet/intel/i40e/i40e_main.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_main.c
@@ -11872,6 +11872,7 @@ static int i40e_sw_init(struct i40e_pf *
 {
int err = 0;
int size;
+   u16 pow;
 
/* Set default capability flags */
pf->flags = I40E_FLAG_RX_CSUM_ENABLED |
@@ -11890,6 +11891,11 @@ static int i40e_sw_init(struct i40e_pf *
pf->rss_table_size = pf->hw.func_caps.rss_table_size;
pf->rss_size_max = min_t(int, pf->rss_size_max,
 pf->hw.func_caps.num_tx_qp);
+
+   /* find the next higher power-of-2 of num cpus */
+   pow = roundup_pow_of_two(num_online_cpus());
+   pf->rss_size_max = min_t(int, pf->rss_size_max, pow);
+
if (pf->hw.func_caps.rss) {
pf->flags |= I40E_FLAG_RSS_ENABLED;
pf->alloc_rss_size = min_t(int, pf->rss_size_max,




[PATCH 5.4 58/73] net: ip6_tunnel: Unregister catch-all devices

2021-04-19 Thread Greg Kroah-Hartman
From: Hristo Venev 

commit 941ea91e87a6e879ed82dad4949f6234f2702bec upstream.

Similarly to the sit case, we need to remove the tunnels with no
addresses that have been moved to another network namespace.

Fixes: 0bd8762824e73 ("ip6tnl: add x-netns support")
Signed-off-by: Hristo Venev 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman 
---
 net/ipv6/ip6_tunnel.c |   10 ++
 1 file changed, 10 insertions(+)

--- a/net/ipv6/ip6_tunnel.c
+++ b/net/ipv6/ip6_tunnel.c
@@ -2217,6 +2217,16 @@ static void __net_exit ip6_tnl_destroy_t
t = rtnl_dereference(t->next);
}
}
+
+   t = rtnl_dereference(ip6n->tnls_wc[0]);
+   while (t) {
+   /* If dev is in the same netns, it has already
+* been added to the list by the previous loop.
+*/
+   if (!net_eq(dev_net(t->dev), net))
+   unregister_netdevice_queue(t->dev, list);
+   t = rtnl_dereference(t->next);
+   }
 }
 
 static int __net_init ip6_tnl_init_net(struct net *net)




[PATCH 5.4 56/73] net: davicom: Fix regulator not turned off on failed probe

2021-04-19 Thread Greg Kroah-Hartman
From: Christophe JAILLET 

commit 31457db3750c0b0ed229d836f2609fdb8a5b790e upstream.

When the probe fails, we must disable the regulator that was previously
enabled.

This patch is a follow-up to commit ac88c531a5b3
("net: davicom: Fix regulator not turned off on failed probe") which missed
one case.

Fixes: 7994fe55a4a2 ("dm9000: Add regulator and reset support to dm9000")
Signed-off-by: Christophe JAILLET 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/net/ethernet/davicom/dm9000.c |6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

--- a/drivers/net/ethernet/davicom/dm9000.c
+++ b/drivers/net/ethernet/davicom/dm9000.c
@@ -1476,8 +1476,10 @@ dm9000_probe(struct platform_device *pde
 
/* Init network device */
ndev = alloc_etherdev(sizeof(struct board_info));
-   if (!ndev)
-   return -ENOMEM;
+   if (!ndev) {
+   ret = -ENOMEM;
+   goto out_regulator_disable;
+   }
 
SET_NETDEV_DEV(ndev, >dev);
 




[PATCH 5.4 57/73] net: sit: Unregister catch-all devices

2021-04-19 Thread Greg Kroah-Hartman
From: Hristo Venev 

commit 610f8c0fc8d46e0933955ce13af3d64484a4630a upstream.

A sit interface created without a local or a remote address is linked
into the `sit_net::tunnels_wc` list of its original namespace. When
deleting a network namespace, delete the devices that have been moved.

The following script triggers a null pointer dereference if devices
linked in a deleted `sit_net` remain:

for i in `seq 1 30`; do
ip netns add ns-test
ip netns exec ns-test ip link add dev veth0 type veth peer veth1
ip netns exec ns-test ip link add dev sit$i type sit dev veth0
ip netns exec ns-test ip link set dev sit$i netns $$
ip netns del ns-test
done
for i in `seq 1 30`; do
ip link del dev sit$i
done

Fixes: 5e6700b3bf98f ("sit: add support of x-netns")
Signed-off-by: Hristo Venev 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman 
---
 net/ipv6/sit.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

--- a/net/ipv6/sit.c
+++ b/net/ipv6/sit.c
@@ -1819,9 +1819,9 @@ static void __net_exit sit_destroy_tunne
if (dev->rtnl_link_ops == _link_ops)
unregister_netdevice_queue(dev, head);
 
-   for (prio = 1; prio < 4; prio++) {
+   for (prio = 0; prio < 4; prio++) {
int h;
-   for (h = 0; h < IP6_SIT_HASH_SIZE; h++) {
+   for (h = 0; h < (prio ? IP6_SIT_HASH_SIZE : 1); h++) {
struct ip_tunnel *t;
 
t = rtnl_dereference(sitn->tunnels[prio][h]);




[PATCH 5.4 54/73] net: macb: fix the restore of cmp registers

2021-04-19 Thread Greg Kroah-Hartman
From: Claudiu Beznea 

commit a714e27ea8bdee2b238748029d31472d0a65b611 upstream.

Commit a14d273ba159 ("net: macb: restore cmp registers on resume path")
introduces the restore of CMP registers on resume path. In case the IP
doesn't support type 2 screeners (zero on DCFG8 register) the
struct macb::rx_fs_list::list is not initialized and thus the
list_for_each_entry(item, >rx_fs_list.list, list) loop introduced in
commit a14d273ba159 ("net: macb: restore cmp registers on resume path")
will access an uninitialized list leading to crash. Thus, initialize
the struct macb::rx_fs_list::list without taking into account if the
IP supports type 2 screeners or not.

Fixes: a14d273ba159 ("net: macb: restore cmp registers on resume path")
Signed-off-by: Claudiu Beznea 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/net/ethernet/cadence/macb_main.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/net/ethernet/cadence/macb_main.c
+++ b/drivers/net/ethernet/cadence/macb_main.c
@@ -3590,6 +3590,7 @@ static int macb_init(struct platform_dev
reg = gem_readl(bp, DCFG8);
bp->max_tuples = min((GEM_BFEXT(SCR2CMP, reg) / 3),
GEM_BFEXT(T2SCR, reg));
+   INIT_LIST_HEAD(>rx_fs_list.list);
if (bp->max_tuples > 0) {
/* also needs one ethtype match to check IPv4 */
if (GEM_BFEXT(SCR2ETH, reg) > 0) {
@@ -3600,7 +3601,6 @@ static int macb_init(struct platform_dev
/* Filtering is supported in hw but don't enable it in 
kernel now */
dev->hw_features |= NETIF_F_NTUPLE;
/* init Rx flow definitions */
-   INIT_LIST_HEAD(>rx_fs_list.list);
bp->rx_fs_list.count = 0;
spin_lock_init(>rx_fs_lock);
} else




[PATCH 5.4 55/73] netfilter: nft_limit: avoid possible divide error in nft_limit_init

2021-04-19 Thread Greg Kroah-Hartman
From: Eric Dumazet 

commit b895bdf5d643b6feb7c60856326dd4feb6981560 upstream.

div_u64() divides u64 by u32.

nft_limit_init() wants to divide u64 by u64, use the appropriate
math function (div64_u64)

divide error:  [#1] PREEMPT SMP KASAN
CPU: 1 PID: 8390 Comm: syz-executor188 Not tainted 5.12.0-rc4-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 
01/01/2011
RIP: 0010:div_u64_rem include/linux/math64.h:28 [inline]
RIP: 0010:div_u64 include/linux/math64.h:127 [inline]
RIP: 0010:nft_limit_init+0x2a2/0x5e0 net/netfilter/nft_limit.c:85
Code: ef 4c 01 eb 41 0f 92 c7 48 89 de e8 38 a5 22 fa 4d 85 ff 0f 85 97 02 00 
00 e8 ea 9e 22 fa 4c 0f af f3 45 89 ed 31 d2 4c 89 f0 <49> f7 f5 49 89 c6 e8 d3 
9e 22 fa 48 8d 7d 48 48 b8 00 00 00 00 00
RSP: 0018:c90009447198 EFLAGS: 00010246
RAX:  RBX: 2000 RCX: 
RDX:  RSI: 875152e6 RDI: 0003
RBP: 888020f80908 R08: 2000 R09: 
R10: 875152d8 R11:  R12: c90009447270
R13:  R14:  R15: 
FS:  0097a300() GS:8880b9d0() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: 21c4 CR3: 26a52000 CR4: 001506e0
DR0:  DR1:  DR2: 
DR3:  DR6: fffe0ff0 DR7: 0400
Call Trace:
 nf_tables_newexpr net/netfilter/nf_tables_api.c:2675 [inline]
 nft_expr_init+0x145/0x2d0 net/netfilter/nf_tables_api.c:2713
 nft_set_elem_expr_alloc+0x27/0x280 net/netfilter/nf_tables_api.c:5160
 nf_tables_newset+0x1997/0x3150 net/netfilter/nf_tables_api.c:4321
 nfnetlink_rcv_batch+0x85a/0x21b0 net/netfilter/nfnetlink.c:456
 nfnetlink_rcv_skb_batch net/netfilter/nfnetlink.c:580 [inline]
 nfnetlink_rcv+0x3af/0x420 net/netfilter/nfnetlink.c:598
 netlink_unicast_kernel net/netlink/af_netlink.c:1312 [inline]
 netlink_unicast+0x533/0x7d0 net/netlink/af_netlink.c:1338
 netlink_sendmsg+0x856/0xd90 net/netlink/af_netlink.c:1927
 sock_sendmsg_nosec net/socket.c:654 [inline]
 sock_sendmsg+0xcf/0x120 net/socket.c:674
 sys_sendmsg+0x6e8/0x810 net/socket.c:2350
 ___sys_sendmsg+0xf3/0x170 net/socket.c:2404
 __sys_sendmsg+0xe5/0x1b0 net/socket.c:2433
 do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46
 entry_SYSCALL_64_after_hwframe+0x44/0xae

Fixes: c26844eda9d4 ("netfilter: nf_tables: Fix nft limit burst handling")
Fixes: 3e0f64b7dd31 ("netfilter: nft_limit: fix packet ratelimiting")
Signed-off-by: Eric Dumazet 
Diagnosed-by: Luigi Rizzo 
Reported-by: syzbot 
Signed-off-by: Pablo Neira Ayuso 
Signed-off-by: Greg Kroah-Hartman 
---
 net/netfilter/nft_limit.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

--- a/net/netfilter/nft_limit.c
+++ b/net/netfilter/nft_limit.c
@@ -76,13 +76,13 @@ static int nft_limit_init(struct nft_lim
return -EOVERFLOW;
 
if (pkts) {
-   tokens = div_u64(limit->nsecs, limit->rate) * limit->burst;
+   tokens = div64_u64(limit->nsecs, limit->rate) * limit->burst;
} else {
/* The token bucket size limits the number of tokens can be
 * accumulated. tokens_max specifies the bucket size.
 * tokens_max = unit * (rate + burst) / rate.
 */
-   tokens = div_u64(limit->nsecs * (limit->rate + limit->burst),
+   tokens = div64_u64(limit->nsecs * (limit->rate + limit->burst),
 limit->rate);
}
 




[PATCH 5.4 51/73] libnvdimm/region: Fix nvdimm_has_flush() to handle ND_REGION_ASYNC

2021-04-19 Thread Greg Kroah-Hartman
From: Vaibhav Jain 

commit a2948b17f6b936fc52f86c0f92c46d2f91928b79 upstream.

In case a platform doesn't provide explicit flush-hints but provides an
explicit flush callback via ND_REGION_ASYNC region flag, then
nvdimm_has_flush() still returns '0' indicating that writes do not
require flushing. This happens on PPC64 with patch at [1] applied, where
'deep_flush' of a region was denied even though an explicit flush
function was provided.

Fix this by adding a condition to nvdimm_has_flush() to test for the
ND_REGION_ASYNC flag on the region and see if a 'region->flush' callback
is assigned.

Link: 
http://lore.kernel.org/r/161703936121.36.7260632399582101498.stgit@e1fbed493c87 
[1]
Fixes: c5d4355d10d4 ("libnvdimm: nd_region flush callback support")
Reported-by: Shivaprasad G Bhat 
Signed-off-by: Vaibhav Jain 
Link: https://lore.kernel.org/r/20210402092555.208590-1-vaib...@linux.ibm.com
Signed-off-by: Dan Williams 
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/nvdimm/region_devs.c |9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

--- a/drivers/nvdimm/region_devs.c
+++ b/drivers/nvdimm/region_devs.c
@@ -1142,6 +1142,11 @@ int nvdimm_has_flush(struct nd_region *n
|| !IS_ENABLED(CONFIG_ARCH_HAS_PMEM_API))
return -ENXIO;
 
+   /* Test if an explicit flush function is defined */
+   if (test_bit(ND_REGION_ASYNC, _region->flags) && nd_region->flush)
+   return 1;
+
+   /* Test if any flush hints for the region are available */
for (i = 0; i < nd_region->ndr_mappings; i++) {
struct nd_mapping *nd_mapping = _region->mapping[i];
struct nvdimm *nvdimm = nd_mapping->nvdimm;
@@ -1152,8 +1157,8 @@ int nvdimm_has_flush(struct nd_region *n
}
 
/*
-* The platform defines dimm devices without hints, assume
-* platform persistence mechanism like ADR
+* The platform defines dimm devices without hints nor explicit flush,
+* assume platform persistence mechanism like ADR
 */
return 0;
 }




[PATCH 5.4 50/73] netfilter: conntrack: do not print icmpv6 as unknown via /proc

2021-04-19 Thread Greg Kroah-Hartman
From: Pablo Neira Ayuso 

commit fbea31808ca124dd73ff6bb1e67c9af4607c3e32 upstream.

/proc/net/nf_conntrack shows icmpv6 as unknown.

Fixes: 09ec82f5af99 ("netfilter: conntrack: remove protocol name from l4proto 
struct")
Signed-off-by: Pablo Neira Ayuso 
Signed-off-by: Greg Kroah-Hartman 
---
 net/netfilter/nf_conntrack_standalone.c |1 +
 1 file changed, 1 insertion(+)

--- a/net/netfilter/nf_conntrack_standalone.c
+++ b/net/netfilter/nf_conntrack_standalone.c
@@ -266,6 +266,7 @@ static const char* l4proto_name(u16 prot
case IPPROTO_GRE: return "gre";
case IPPROTO_SCTP: return "sctp";
case IPPROTO_UDPLITE: return "udplite";
+   case IPPROTO_ICMPV6: return "icmpv6";
}
 
return "unknown";




[PATCH 5.4 53/73] netfilter: arp_tables: add pre_exit hook for table unregister

2021-04-19 Thread Greg Kroah-Hartman
From: Florian Westphal 

commit d163a925ebbc6eb5b562b0f1d72c7e817aa75c40 upstream.

Same problem that also existed in iptables/ip(6)tables, when
arptable_filter is removed there is no longer a wait period before the
table/ruleset is free'd.

Unregister the hook in pre_exit, then remove the table in the exit
function.
This used to work correctly because the old nf_hook_unregister API
did unconditional synchronize_net.

The per-net hook unregister function uses call_rcu instead.

Fixes: b9e69e127397 ("netfilter: xtables: don't hook tables by default")
Signed-off-by: Florian Westphal 
Signed-off-by: Pablo Neira Ayuso 
Signed-off-by: Greg Kroah-Hartman 
---
 include/linux/netfilter_arp/arp_tables.h |5 +++--
 net/ipv4/netfilter/arp_tables.c  |9 +++--
 net/ipv4/netfilter/arptable_filter.c |   10 +-
 3 files changed, 19 insertions(+), 5 deletions(-)

--- a/include/linux/netfilter_arp/arp_tables.h
+++ b/include/linux/netfilter_arp/arp_tables.h
@@ -52,8 +52,9 @@ extern void *arpt_alloc_initial_table(co
 int arpt_register_table(struct net *net, const struct xt_table *table,
const struct arpt_replace *repl,
const struct nf_hook_ops *ops, struct xt_table **res);
-void arpt_unregister_table(struct net *net, struct xt_table *table,
-  const struct nf_hook_ops *ops);
+void arpt_unregister_table(struct net *net, struct xt_table *table);
+void arpt_unregister_table_pre_exit(struct net *net, struct xt_table *table,
+   const struct nf_hook_ops *ops);
 extern unsigned int arpt_do_table(struct sk_buff *skb,
  const struct nf_hook_state *state,
  struct xt_table *table);
--- a/net/ipv4/netfilter/arp_tables.c
+++ b/net/ipv4/netfilter/arp_tables.c
@@ -1580,10 +1580,15 @@ out_free:
return ret;
 }
 
-void arpt_unregister_table(struct net *net, struct xt_table *table,
-  const struct nf_hook_ops *ops)
+void arpt_unregister_table_pre_exit(struct net *net, struct xt_table *table,
+   const struct nf_hook_ops *ops)
 {
nf_unregister_net_hooks(net, ops, hweight32(table->valid_hooks));
+}
+EXPORT_SYMBOL(arpt_unregister_table_pre_exit);
+
+void arpt_unregister_table(struct net *net, struct xt_table *table)
+{
__arpt_unregister_table(net, table);
 }
 
--- a/net/ipv4/netfilter/arptable_filter.c
+++ b/net/ipv4/netfilter/arptable_filter.c
@@ -56,16 +56,24 @@ static int __net_init arptable_filter_ta
return err;
 }
 
+static void __net_exit arptable_filter_net_pre_exit(struct net *net)
+{
+   if (net->ipv4.arptable_filter)
+   arpt_unregister_table_pre_exit(net, net->ipv4.arptable_filter,
+  arpfilter_ops);
+}
+
 static void __net_exit arptable_filter_net_exit(struct net *net)
 {
if (!net->ipv4.arptable_filter)
return;
-   arpt_unregister_table(net, net->ipv4.arptable_filter, arpfilter_ops);
+   arpt_unregister_table(net, net->ipv4.arptable_filter);
net->ipv4.arptable_filter = NULL;
 }
 
 static struct pernet_operations arptable_filter_net_ops = {
.exit = arptable_filter_net_exit,
+   .pre_exit = arptable_filter_net_pre_exit,
 };
 
 static int __init arptable_filter_init(void)




[PATCH 5.4 49/73] scsi: libsas: Reset num_scatter if libata marks qc as NODATA

2021-04-19 Thread Greg Kroah-Hartman
From: Jolly Shah 

commit 176ddd89171ddcf661862d90c5d257877f7326d6 upstream.

When the cache_type for the SCSI device is changed, the SCSI layer issues a
MODE_SELECT command. The caching mode details are communicated via a
request buffer associated with the SCSI command with data direction set as
DMA_TO_DEVICE (scsi_mode_select()). When this command reaches the libata
layer, as a part of generic initial setup, libata layer sets up the
scatterlist for the command using the SCSI command (ata_scsi_qc_new()).
This command is then translated by the libata layer into
ATA_CMD_SET_FEATURES (ata_scsi_mode_select_xlat()). The libata layer treats
this as a non-data command (ata_mselect_caching()), since it only needs an
ATA taskfile to pass the caching on/off information to the device. It does
not need the scatterlist that has been setup, so it does not perform
dma_map_sg() on the scatterlist (ata_qc_issue()). Unfortunately, when this
command reaches the libsas layer (sas_ata_qc_issue()), libsas layer sees it
as a non-data command with a scatterlist. It cannot extract the correct DMA
length since the scatterlist has not been mapped with dma_map_sg() for a
DMA operation. When this partially constructed SAS task reaches pm80xx
LLDD, it results in the following warning:

"pm80xx_chip_sata_req 6058: The sg list address
start_addr=0x data_len=0x0end_addr_high=0x
end_addr_low=0x has crossed 4G boundary"

Update libsas to handle ATA non-data commands separately so num_scatter and
total_xfer_len remain 0.

Link: https://lore.kernel.org/r/20210318225632.2481291-1-jol...@google.com
Fixes: 53de092f47ff ("scsi: libsas: Set data_dir as DMA_NONE if libata marks qc 
as NODATA")
Tested-by: Luo Jiaxing 
Reviewed-by: John Garry 
Signed-off-by: Jolly Shah 
Signed-off-by: Martin K. Petersen 
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/scsi/libsas/sas_ata.c |9 -
 1 file changed, 4 insertions(+), 5 deletions(-)

--- a/drivers/scsi/libsas/sas_ata.c
+++ b/drivers/scsi/libsas/sas_ata.c
@@ -200,18 +200,17 @@ static unsigned int sas_ata_qc_issue(str
memcpy(task->ata_task.atapi_packet, qc->cdb, qc->dev->cdb_len);
task->total_xfer_len = qc->nbytes;
task->num_scatter = qc->n_elem;
+   task->data_dir = qc->dma_dir;
+   } else if (qc->tf.protocol == ATA_PROT_NODATA) {
+   task->data_dir = DMA_NONE;
} else {
for_each_sg(qc->sg, sg, qc->n_elem, si)
xfer += sg_dma_len(sg);
 
task->total_xfer_len = xfer;
task->num_scatter = si;
-   }
-
-   if (qc->tf.protocol == ATA_PROT_NODATA)
-   task->data_dir = DMA_NONE;
-   else
task->data_dir = qc->dma_dir;
+   }
task->scatter = qc->sg;
task->ata_task.retry_count = 1;
task->task_state_flags = SAS_TASK_STATE_PENDING;




[PATCH 5.4 25/73] net: ieee802154: forbid monitor for add llsec key

2021-04-19 Thread Greg Kroah-Hartman
From: Alexander Aring 

[ Upstream commit 08470c5453339369bd3d590c4cbb0b5961cdcbb6 ]

This patch forbids to add llsec key for monitor interfaces which we
don't support yet. Otherwise we will access llsec mib which isn't
initialized for monitors.

Signed-off-by: Alexander Aring 
Link: https://lore.kernel.org/r/20210405003054.256017-5-aahri...@redhat.com
Signed-off-by: Stefan Schmidt 
Signed-off-by: Sasha Levin 
---
 net/ieee802154/nl802154.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/net/ieee802154/nl802154.c b/net/ieee802154/nl802154.c
index 27e34aab09a6..0920f320b59b 100644
--- a/net/ieee802154/nl802154.c
+++ b/net/ieee802154/nl802154.c
@@ -1573,6 +1573,9 @@ static int nl802154_add_llsec_key(struct sk_buff *skb, 
struct genl_info *info)
struct ieee802154_llsec_key_id id = { };
u32 commands[NL802154_CMD_FRAME_NR_IDS / 32] = { };
 
+   if (wpan_dev->iftype == NL802154_IFTYPE_MONITOR)
+   return -EOPNOTSUPP;
+
if (!info->attrs[NL802154_ATTR_SEC_KEY] ||
nla_parse_nested_deprecated(attrs, NL802154_KEY_ATTR_MAX, 
info->attrs[NL802154_ATTR_SEC_KEY], nl802154_key_policy, info->extack))
return -EINVAL;
-- 
2.30.2





[PATCH 5.4 52/73] netfilter: bridge: add pre_exit hooks for ebtable unregistration

2021-04-19 Thread Greg Kroah-Hartman
From: Florian Westphal 

commit 7ee3c61dcd28bf6e290e06ad382f13511dc790e9 upstream.

Just like ip/ip6/arptables, the hooks have to be removed, then
synchronize_rcu() has to be called to make sure no more packets are being
processed before the ruleset data is released.

Place the hook unregistration in the pre_exit hook, then call the new
ebtables pre_exit function from there.

Years ago, when first netns support got added for netfilter+ebtables,
this used an older (now removed) netfilter hook unregister API, that did
a unconditional synchronize_rcu().

Now that all is done with call_rcu, ebtable_{filter,nat,broute} pernet exit
handlers may free the ebtable ruleset while packets are still in flight.

This can only happens on module removal, not during netns exit.

The new function expects the table name, not the table struct.

This is because upcoming patch set (targeting -next) will remove all
net->xt.{nat,filter,broute}_table instances, this makes it necessary
to avoid external references to those member variables.

The existing APIs will be converted, so follow the upcoming scheme of
passing name + hook type instead.

Fixes: aee12a0a3727e ("ebtables: remove nf_hook_register usage")
Signed-off-by: Florian Westphal 
Signed-off-by: Pablo Neira Ayuso 
Signed-off-by: Greg Kroah-Hartman 
---
 include/linux/netfilter_bridge/ebtables.h |5 +++--
 net/bridge/netfilter/ebtable_broute.c |8 +++-
 net/bridge/netfilter/ebtable_filter.c |8 +++-
 net/bridge/netfilter/ebtable_nat.c|8 +++-
 net/bridge/netfilter/ebtables.c   |   30 +++---
 5 files changed, 51 insertions(+), 8 deletions(-)

--- a/include/linux/netfilter_bridge/ebtables.h
+++ b/include/linux/netfilter_bridge/ebtables.h
@@ -110,8 +110,9 @@ extern int ebt_register_table(struct net
  const struct ebt_table *table,
  const struct nf_hook_ops *ops,
  struct ebt_table **res);
-extern void ebt_unregister_table(struct net *net, struct ebt_table *table,
-const struct nf_hook_ops *);
+extern void ebt_unregister_table(struct net *net, struct ebt_table *table);
+void ebt_unregister_table_pre_exit(struct net *net, const char *tablename,
+  const struct nf_hook_ops *ops);
 extern unsigned int ebt_do_table(struct sk_buff *skb,
 const struct nf_hook_state *state,
 struct ebt_table *table);
--- a/net/bridge/netfilter/ebtable_broute.c
+++ b/net/bridge/netfilter/ebtable_broute.c
@@ -105,14 +105,20 @@ static int __net_init broute_net_init(st
  >xt.broute_table);
 }
 
+static void __net_exit broute_net_pre_exit(struct net *net)
+{
+   ebt_unregister_table_pre_exit(net, "broute", _ops_broute);
+}
+
 static void __net_exit broute_net_exit(struct net *net)
 {
-   ebt_unregister_table(net, net->xt.broute_table, _ops_broute);
+   ebt_unregister_table(net, net->xt.broute_table);
 }
 
 static struct pernet_operations broute_net_ops = {
.init = broute_net_init,
.exit = broute_net_exit,
+   .pre_exit = broute_net_pre_exit,
 };
 
 static int __init ebtable_broute_init(void)
--- a/net/bridge/netfilter/ebtable_filter.c
+++ b/net/bridge/netfilter/ebtable_filter.c
@@ -99,14 +99,20 @@ static int __net_init frame_filter_net_i
  >xt.frame_filter);
 }
 
+static void __net_exit frame_filter_net_pre_exit(struct net *net)
+{
+   ebt_unregister_table_pre_exit(net, "filter", ebt_ops_filter);
+}
+
 static void __net_exit frame_filter_net_exit(struct net *net)
 {
-   ebt_unregister_table(net, net->xt.frame_filter, ebt_ops_filter);
+   ebt_unregister_table(net, net->xt.frame_filter);
 }
 
 static struct pernet_operations frame_filter_net_ops = {
.init = frame_filter_net_init,
.exit = frame_filter_net_exit,
+   .pre_exit = frame_filter_net_pre_exit,
 };
 
 static int __init ebtable_filter_init(void)
--- a/net/bridge/netfilter/ebtable_nat.c
+++ b/net/bridge/netfilter/ebtable_nat.c
@@ -99,14 +99,20 @@ static int __net_init frame_nat_net_init
  >xt.frame_nat);
 }
 
+static void __net_exit frame_nat_net_pre_exit(struct net *net)
+{
+   ebt_unregister_table_pre_exit(net, "nat", ebt_ops_nat);
+}
+
 static void __net_exit frame_nat_net_exit(struct net *net)
 {
-   ebt_unregister_table(net, net->xt.frame_nat, ebt_ops_nat);
+   ebt_unregister_table(net, net->xt.frame_nat);
 }
 
 static struct pernet_operations frame_nat_net_ops = {
.init = frame_nat_net_init,
.exit = frame_nat_net_exit,
+   .pre_exit = frame_nat_net_pre_exit,
 };
 
 static int __init ebtable_nat_init(void)
--- a/net/bridge/netfilter/ebtables.c
+++ b/net/bridge/netfilter/ebtables.c
@@ -1237,10 +1237,34 @@ ou

[PATCH 5.4 48/73] riscv: Fix spelling mistake "SPARSEMEM" to "SPARSMEM"

2021-04-19 Thread Greg Kroah-Hartman
From: Kefeng Wang 

commit 199fc6b8dee7d6d50467a57e0dc7e3e1b7d59966 upstream.

There is a spelling mistake when SPARSEMEM Kconfig copy.

Fixes: a5406a7ff56e ("riscv: Correct SPARSEMEM configuration")
Cc: sta...@vger.kernel.org
Signed-off-by: Kefeng Wang 
Signed-off-by: Palmer Dabbelt 
Signed-off-by: Greg Kroah-Hartman 
---
 arch/riscv/Kconfig |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/arch/riscv/Kconfig
+++ b/arch/riscv/Kconfig
@@ -101,7 +101,7 @@ config ARCH_FLATMEM_ENABLE
 config ARCH_SPARSEMEM_ENABLE
def_bool y
depends on MMU
-   select SPARSEMEM_STATIC if 32BIT && SPARSMEM
+   select SPARSEMEM_STATIC if 32BIT && SPARSEMEM
select SPARSEMEM_VMEMMAP_ENABLE if 64BIT
 
 config ARCH_SELECT_MEMORY_MODEL




[PATCH 5.4 47/73] vfio/pci: Add missing range check in vfio_pci_mmap

2021-04-19 Thread Greg Kroah-Hartman
From: Christian A. Ehrhardt 

commit 909290786ea335366e21d7f1ed5812b90f2f0a92 upstream.

When mmaping an extra device region verify that the region index
derived from the mmap offset is valid.

Fixes: a15b1883fee1 ("vfio_pci: Allow mapping extra regions")
Cc: sta...@vger.kernel.org
Signed-off-by: Christian A. Ehrhardt 
Message-Id: <20210412214124.ga241...@lisa.in-ulm.de>
Reviewed-by: David Gibson 
Reviewed-by: Cornelia Huck 
Signed-off-by: Alex Williamson 
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/vfio/pci/vfio_pci.c |4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

--- a/drivers/vfio/pci/vfio_pci.c
+++ b/drivers/vfio/pci/vfio_pci.c
@@ -1474,6 +1474,8 @@ static int vfio_pci_mmap(void *device_da
 
index = vma->vm_pgoff >> (VFIO_PCI_OFFSET_SHIFT - PAGE_SHIFT);
 
+   if (index >= VFIO_PCI_NUM_REGIONS + vdev->num_regions)
+   return -EINVAL;
if (vma->vm_end < vma->vm_start)
return -EINVAL;
if ((vma->vm_flags & VM_SHARED) == 0)
@@ -1482,7 +1484,7 @@ static int vfio_pci_mmap(void *device_da
int regnum = index - VFIO_PCI_NUM_REGIONS;
struct vfio_pci_region *region = vdev->region + regnum;
 
-   if (region && region->ops && region->ops->mmap &&
+   if (region->ops && region->ops->mmap &&
(region->flags & VFIO_REGION_INFO_FLAG_MMAP))
return region->ops->mmap(vdev, region, vma);
return -EINVAL;




[PATCH 5.4 46/73] arm64: alternatives: Move length validation in alternative_{insn, endif}

2021-04-19 Thread Greg Kroah-Hartman
From: Nathan Chancellor 

commit 22315a2296f4c251fa92aec45fbbae37e9301b6c upstream.

After commit 2decad92f473 ("arm64: mte: Ensure TIF_MTE_ASYNC_FAULT is
set atomically"), LLVM's integrated assembler fails to build entry.S:

:5:7: error: expected assembly-time absolute expression
 .org . - (664b-663b) + (662b-661b)
  ^
:6:7: error: expected assembly-time absolute expression
 .org . - (662b-661b) + (664b-663b)
  ^

The root cause is LLVM's assembler has a one-pass design, meaning it
cannot figure out these instruction lengths when the .org directive is
outside of the subsection that they are in, which was changed by the
.arch_extension directive added in the above commit.

Apply the same fix from commit 966a0acce2fc ("arm64/alternatives: move
length validation inside the subsection") to the alternative_endif
macro, shuffling the .org directives so that the length validation
happen will always happen in the same subsections. alternative_insn has
not shown any issue yet but it appears that it could have the same issue
in the future so just preemptively change it.

Fixes: f7b93d42945c ("arm64/alternatives: use subsections for replacement 
sequences")
Cc:  # 5.8.x
Link: https://github.com/ClangBuiltLinux/linux/issues/1347
Signed-off-by: Nathan Chancellor 
Reviewed-by: Sami Tolvanen 
Tested-by: Sami Tolvanen 
Reviewed-by: Nick Desaulniers 
Tested-by: Nick Desaulniers 
Link: https://lore.kernel.org/r/20210414000803.662534-1-nat...@kernel.org
Signed-off-by: Catalin Marinas 
Signed-off-by: Greg Kroah-Hartman 
---
 arch/arm64/include/asm/alternative.h |8 
 1 file changed, 4 insertions(+), 4 deletions(-)

--- a/arch/arm64/include/asm/alternative.h
+++ b/arch/arm64/include/asm/alternative.h
@@ -119,9 +119,9 @@ static inline void apply_alternatives_mo
.popsection
.subsection 1
 663:   \insn2
-664:   .previous
-   .org. - (664b-663b) + (662b-661b)
+664:   .org. - (664b-663b) + (662b-661b)
.org. - (662b-661b) + (664b-663b)
+   .previous
.endif
 .endm
 
@@ -191,11 +191,11 @@ static inline void apply_alternatives_mo
  */
 .macro alternative_endif
 664:
+   .org. - (664b-663b) + (662b-661b)
+   .org. - (662b-661b) + (664b-663b)
.if .Lasm_alt_mode==0
.previous
.endif
-   .org. - (664b-663b) + (662b-661b)
-   .org. - (662b-661b) + (664b-663b)
 .endm
 
 /*




[PATCH 5.4 45/73] arm64: fix inline asm in load_unaligned_zeropad()

2021-04-19 Thread Greg Kroah-Hartman
From: Peter Collingbourne 

commit 185f2e5f51c2029efd9dd26cceb968a44fe053c6 upstream.

The inline asm's addr operand is marked as input-only, however in
the case where an exception is taken it may be modified by the BIC
instruction on the exception path. Fix the problem by using a temporary
register as the destination register for the BIC instruction.

Signed-off-by: Peter Collingbourne 
Cc: sta...@vger.kernel.org
Link: 
https://linux-review.googlesource.com/id/I84538c8a2307d567b4f45bb20b715451005f9617
Link: https://lore.kernel.org/r/20210401165110.3952103-1-...@google.com
Signed-off-by: Will Deacon 
Signed-off-by: Greg Kroah-Hartman 
---
 arch/arm64/include/asm/word-at-a-time.h |   10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

--- a/arch/arm64/include/asm/word-at-a-time.h
+++ b/arch/arm64/include/asm/word-at-a-time.h
@@ -53,7 +53,7 @@ static inline unsigned long find_zero(un
  */
 static inline unsigned long load_unaligned_zeropad(const void *addr)
 {
-   unsigned long ret, offset;
+   unsigned long ret, tmp;
 
/* Load word from unaligned pointer addr */
asm(
@@ -61,9 +61,9 @@ static inline unsigned long load_unalign
"2:\n"
"   .pushsection .fixup,\"ax\"\n"
"   .align 2\n"
-   "3: and %1, %2, #0x7\n"
-   "   bic %2, %2, #0x7\n"
-   "   ldr %0, [%2]\n"
+   "3: bic %1, %2, #0x7\n"
+   "   ldr %0, [%1]\n"
+   "   and %1, %2, #0x7\n"
"   lsl %1, %1, #0x3\n"
 #ifndef __AARCH64EB__
"   lsr %0, %0, %1\n"
@@ -73,7 +73,7 @@ static inline unsigned long load_unalign
"   b   2b\n"
"   .popsection\n"
_ASM_EXTABLE(1b, 3b)
-   : "=" (ret), "=" (offset)
+   : "=" (ret), "=" (tmp)
: "r" (addr), "Q" (*(unsigned long *)addr));
 
return ret;




[PATCH 5.4 41/73] Input: i8042 - fix Pegatron C15B ID entry

2021-04-19 Thread Greg Kroah-Hartman
From: Arnd Bergmann 

commit daa58c8eec0a65ac8e2e77ff3ea8a233d8eec954 upstream.

The Zenbook Flip entry that was added overwrites a previous one
because of a typo:

In file included from drivers/input/serio/i8042.h:23,
 from drivers/input/serio/i8042.c:131:
drivers/input/serio/i8042-x86ia64io.h:591:28: error: initialized field 
overwritten [-Werror=override-init]
  591 | .matches = {
  |^
drivers/input/serio/i8042-x86ia64io.h:591:28: note: (near initialization for 
'i8042_dmi_noselftest_table[0].matches')

Add the missing separator between the two.

Fixes: b5d6e7ab7fe7 ("Input: i8042 - add ASUS Zenbook Flip to noselftest list")
Signed-off-by: Arnd Bergmann 
Reviewed-by: Hans de Goede 
Reviewed-by: Marcos Paulo de Souza 
Link: https://lore.kernel.org/r/20210323130623.2302402-1-a...@kernel.org
Cc: sta...@vger.kernel.org
Signed-off-by: Dmitry Torokhov 
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/input/serio/i8042-x86ia64io.h |1 +
 1 file changed, 1 insertion(+)

--- a/drivers/input/serio/i8042-x86ia64io.h
+++ b/drivers/input/serio/i8042-x86ia64io.h
@@ -588,6 +588,7 @@ static const struct dmi_system_id i8042_
DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
DMI_MATCH(DMI_CHASSIS_TYPE, "10"), /* Notebook */
},
+   }, {
.matches = {
DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
DMI_MATCH(DMI_CHASSIS_TYPE, "31"), /* Convertible 
Notebook */




[PATCH 5.4 03/73] scsi: qla2xxx: Dual FCP-NVMe target port support

2021-04-19 Thread Greg Kroah-Hartman
From: Michael Hernandez 

[ Upstream commit 84ed362ac40ca44dbbbebf767301463aa72bc797 ]

Some storage arrays advertise FCP LUNs and NVMe namespaces behind the same
WWN.  The driver now offers a user option by way of NVRAM parameter to
allow users to choose, on a per port basis, the kind of FC-4 type they
would like to prioritize for login.

Link: https://lore.kernel.org/r/20190912180918.6436-9-hmadh...@marvell.com
Signed-off-by: Michael Hernandez 
Signed-off-by: Himanshu Madhani 
Signed-off-by: Martin K. Petersen 
Signed-off-by: Sasha Levin 
---
 drivers/scsi/qla2xxx/qla_def.h| 26 -
 drivers/scsi/qla2xxx/qla_fw.h |  2 +
 drivers/scsi/qla2xxx/qla_gs.c | 42 
 drivers/scsi/qla2xxx/qla_init.c   | 64 ++-
 drivers/scsi/qla2xxx/qla_inline.h | 12 ++
 drivers/scsi/qla2xxx/qla_mbx.c| 11 +++---
 drivers/scsi/qla2xxx/qla_os.c | 17 
 7 files changed, 114 insertions(+), 60 deletions(-)

diff --git a/drivers/scsi/qla2xxx/qla_def.h b/drivers/scsi/qla2xxx/qla_def.h
index 1eb3fe281cc3..894c2716b7ce 100644
--- a/drivers/scsi/qla2xxx/qla_def.h
+++ b/drivers/scsi/qla2xxx/qla_def.h
@@ -2281,7 +2281,7 @@ typedef struct {
uint8_t fabric_port_name[WWN_SIZE];
uint16_t fp_speed;
uint8_t fc4_type;
-   uint8_t fc4f_nvme;  /* nvme fc4 feature bits */
+   uint8_t fc4_features;
 } sw_info_t;
 
 /* FCP-4 types */
@@ -2450,7 +2450,7 @@ typedef struct fc_port {
u32 supported_classes;
 
uint8_t fc4_type;
-   uint8_t fc4f_nvme;
+   uint8_t fc4_features;
uint8_t scan_state;
 
unsigned long last_queue_full;
@@ -2481,6 +2481,9 @@ typedef struct fc_port {
u16 n2n_chip_reset;
 } fc_port_t;
 
+#define FC4_PRIORITY_NVME  0
+#define FC4_PRIORITY_FCP   1
+
 #define QLA_FCPORT_SCAN1
 #define QLA_FCPORT_FOUND   2
 
@@ -4296,6 +4299,8 @@ struct qla_hw_data {
atomic_tnvme_active_aen_cnt;
uint16_tnvme_last_rptd_aen; /* Last recorded aen 
count */
 
+   uint8_t fc4_type_priority;
+
atomic_t zio_threshold;
uint16_t last_zio_threshold;
 
@@ -4821,6 +4826,23 @@ struct sff_8247_a0 {
 ha->current_topology == ISP_CFG_N || \
 !ha->current_topology)
 
+#define NVME_TYPE(fcport) \
+   (fcport->fc4_type & FS_FC4TYPE_NVME) \
+
+#define FCP_TYPE(fcport) \
+   (fcport->fc4_type & FS_FC4TYPE_FCP) \
+
+#define NVME_ONLY_TARGET(fcport) \
+   (NVME_TYPE(fcport) && !FCP_TYPE(fcport))  \
+
+#define NVME_FCP_TARGET(fcport) \
+   (FCP_TYPE(fcport) && NVME_TYPE(fcport)) \
+
+#define NVME_TARGET(ha, fcport) \
+   ((NVME_FCP_TARGET(fcport) && \
+   (ha->fc4_type_priority == FC4_PRIORITY_NVME)) || \
+   NVME_ONLY_TARGET(fcport)) \
+
 #include "qla_target.h"
 #include "qla_gbl.h"
 #include "qla_dbg.h"
diff --git a/drivers/scsi/qla2xxx/qla_fw.h b/drivers/scsi/qla2xxx/qla_fw.h
index dc2366a29665..9dc09c117416 100644
--- a/drivers/scsi/qla2xxx/qla_fw.h
+++ b/drivers/scsi/qla2xxx/qla_fw.h
@@ -2105,4 +2105,6 @@ struct qla_fcp_prio_cfg {
 #define FA_FLASH_LAYOUT_ADDR_83(0x3F1000/4)
 #define FA_FLASH_LAYOUT_ADDR_28(0x11000/4)
 
+#define NVRAM_DUAL_FCP_NVME_FLAG_OFFSET0x196
+
 #endif
diff --git a/drivers/scsi/qla2xxx/qla_gs.c b/drivers/scsi/qla2xxx/qla_gs.c
index fc6e12fb7d77..ae13aabf280b 100644
--- a/drivers/scsi/qla2xxx/qla_gs.c
+++ b/drivers/scsi/qla2xxx/qla_gs.c
@@ -248,7 +248,7 @@ qla2x00_ga_nxt(scsi_qla_host_t *vha, fc_port_t *fcport)
WWN_SIZE);
 
fcport->fc4_type = (ct_rsp->rsp.ga_nxt.fc4_types[2] & BIT_0) ?
-   FC4_TYPE_FCP_SCSI : FC4_TYPE_OTHER;
+   FS_FC4TYPE_FCP : FC4_TYPE_OTHER;
 
if (ct_rsp->rsp.ga_nxt.port_type != NS_N_PORT_TYPE &&
ct_rsp->rsp.ga_nxt.port_type != NS_NL_PORT_TYPE)
@@ -2887,7 +2887,7 @@ qla2x00_gff_id(scsi_qla_host_t *vha, sw_info_t *list)
struct ct_sns_req   *ct_req;
struct ct_sns_rsp   *ct_rsp;
struct qla_hw_data *ha = vha->hw;
-   uint8_t fcp_scsi_features = 0;
+   uint8_t fcp_scsi_features = 0, nvme_features = 0;
struct ct_arg arg;
 
for (i = 0; i < ha->max_fibre_devices; i++) {
@@ -2933,14 +2933,19 @@ qla2x00_gff_id(scsi_qla_host_t *vha, sw_info_t *list)
   ct_rsp->rsp.gff_id.fc4_features[GFF_FCP_SCSI_OFFSET];
fcp_scsi_features &= 0x0f;
 
-   if (fcp_scsi_features)
-   list[i].fc4_type = FC4_TYPE_FCP_SCSI;
-   else
-   list[i].fc4_type = FC4_TYPE_OTHER;
+   if (fcp_scsi_features) {
+   list[i].fc4_type = FS_FC4TYPE_FCP;
+   list[i].fc4_features = fcp_scsi_features;
+   }
 
-   list[i].fc4f_nvme =
+  

[PATCH 5.4 18/73] neighbour: Disregard DEAD dst in neigh_update

2021-04-19 Thread Greg Kroah-Hartman
From: Tong Zhu 

[ Upstream commit d47ec7a0a7271dda08932d6208e4ab65ab0c987c ]

After a short network outage, the dst_entry is timed out and put
in DST_OBSOLETE_DEAD. We are in this code because arp reply comes
from this neighbour after network recovers. There is a potential
race condition that dst_entry is still in DST_OBSOLETE_DEAD.
With that, another neighbour lookup causes more harm than good.

In best case all packets in arp_queue are lost. This is
counterproductive to the original goal of finding a better path
for those packets.

I observed a worst case with 4.x kernel where a dst_entry in
DST_OBSOLETE_DEAD state is associated with loopback net_device.
It leads to an ethernet header with all zero addresses.
A packet with all zero source MAC address is quite deadly with
mac80211, ath9k and 802.11 block ack.  It fails
ieee80211_find_sta_by_ifaddr in ath9k (xmit.c). Ath9k flushes tx
queue (ath_tx_complete_aggr). BAW (block ack window) is not
updated. BAW logic is damaged and ath9k transmission is disabled.

Signed-off-by: Tong Zhu 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin 
---
 net/core/neighbour.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/core/neighbour.c b/net/core/neighbour.c
index 7080d708b7d0..6635b83113f8 100644
--- a/net/core/neighbour.c
+++ b/net/core/neighbour.c
@@ -1379,7 +1379,7 @@ static int __neigh_update(struct neighbour *neigh, const 
u8 *lladdr,
 * we can reinject the packet there.
 */
n2 = NULL;
-   if (dst) {
+   if (dst && dst->obsolete != DST_OBSOLETE_DEAD) {
n2 = dst_neigh_lookup_skb(dst, skb);
if (n2)
n1 = n2;
-- 
2.30.2





[PATCH 5.4 16/73] arc: kernel: Return -EFAULT if copy_to_user() fails

2021-04-19 Thread Greg Kroah-Hartman
From: Wang Qing 

[ Upstream commit 46e152186cd89d940b26726fff11eb3f4935b45a ]

The copy_to_user() function returns the number of bytes remaining to be
copied, but we want to return -EFAULT if the copy doesn't complete.

Signed-off-by: Wang Qing 
Signed-off-by: Vineet Gupta 
Signed-off-by: Sasha Levin 
---
 arch/arc/kernel/signal.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arc/kernel/signal.c b/arch/arc/kernel/signal.c
index 3d57ed0d8535..404518051093 100644
--- a/arch/arc/kernel/signal.c
+++ b/arch/arc/kernel/signal.c
@@ -96,7 +96,7 @@ stash_usr_regs(struct rt_sigframe __user *sf, struct pt_regs 
*regs,
 sizeof(sf->uc.uc_mcontext.regs.scratch));
err |= __copy_to_user(>uc.uc_sigmask, set, sizeof(sigset_t));
 
-   return err;
+   return err ? -EFAULT : 0;
 }
 
 static int restore_usr_regs(struct pt_regs *regs, struct rt_sigframe __user 
*sf)
@@ -110,7 +110,7 @@ static int restore_usr_regs(struct pt_regs *regs, struct 
rt_sigframe __user *sf)
&(sf->uc.uc_mcontext.regs.scratch),
sizeof(sf->uc.uc_mcontext.regs.scratch));
if (err)
-   return err;
+   return -EFAULT;
 
set_current_blocked();
regs->bta   = uregs.scratch.bta;
-- 
2.30.2





[PATCH 5.4 36/73] net/rds: Avoid potential use after free in rds_send_remove_from_sock

2021-04-19 Thread Greg Kroah-Hartman
From: Aditya Pakki 

[ Upstream commit 0c85a7e87465f2d4cbc768e245f4f45b2f299b05 ]

In case of rs failure in rds_send_remove_from_sock(), the 'rm' resource
is freed and later under spinlock, causing potential use-after-free.
Set the free pointer to NULL to avoid undefined behavior.

Signed-off-by: Aditya Pakki 
Acked-by: Santosh Shilimkar 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin 
---
 net/rds/message.c | 1 +
 net/rds/send.c| 2 +-
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/net/rds/message.c b/net/rds/message.c
index 92b6b22884d4..ed1d2255ce5a 100644
--- a/net/rds/message.c
+++ b/net/rds/message.c
@@ -180,6 +180,7 @@ void rds_message_put(struct rds_message *rm)
rds_message_purge(rm);
 
kfree(rm);
+   rm = NULL;
}
 }
 EXPORT_SYMBOL_GPL(rds_message_put);
diff --git a/net/rds/send.c b/net/rds/send.c
index 68e2bdb08fd0..aa3bc081773f 100644
--- a/net/rds/send.c
+++ b/net/rds/send.c
@@ -665,7 +665,7 @@ static void rds_send_remove_from_sock(struct list_head 
*messages, int status)
 unlock_and_drop:
spin_unlock_irqrestore(>m_rs_lock, flags);
rds_message_put(rm);
-   if (was_on_sock)
+   if (was_on_sock && rm)
rds_message_put(rm);
}
 
-- 
2.30.2





[PATCH 5.4 40/73] Input: s6sy761 - fix coordinate read bit shift

2021-04-19 Thread Greg Kroah-Hartman
From: Caleb Connolly 

commit 30b3f68715595dee7fe4d9bd91a2252c3becdf0a upstream.

The touch coordinate register contains the following:

byte 3 byte 2 byte 1
+++ +-+ +-+
||| | | | |
| X[3:0] | Y[3:0] | | Y[11:4] | | X[11:4] |
||| | | | |
+++ +-+ +-+

Bytes 2 and 1 need to be shifted left by 4 bits, the least significant
nibble of each is stored in byte 3. Currently they are only
being shifted by 3 causing the reported coordinates to be incorrect.

This matches downstream examples, and has been confirmed on my
device (OnePlus 7 Pro).

Fixes: 0145a7141e59 ("Input: add support for the Samsung S6SY761 touchscreen")
Signed-off-by: Caleb Connolly 
Reviewed-by: Andi Shyti 
Link: https://lore.kernel.org/r/20210305185710.225168-1-ca...@connolly.tech
Cc: sta...@vger.kernel.org
Signed-off-by: Dmitry Torokhov 
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/input/touchscreen/s6sy761.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

--- a/drivers/input/touchscreen/s6sy761.c
+++ b/drivers/input/touchscreen/s6sy761.c
@@ -145,8 +145,8 @@ static void s6sy761_report_coordinates(s
u8 major = event[4];
u8 minor = event[5];
u8 z = event[6] & S6SY761_MASK_Z;
-   u16 x = (event[1] << 3) | ((event[3] & S6SY761_MASK_X) >> 4);
-   u16 y = (event[2] << 3) | (event[3] & S6SY761_MASK_Y);
+   u16 x = (event[1] << 4) | ((event[3] & S6SY761_MASK_X) >> 4);
+   u16 y = (event[2] << 4) | (event[3] & S6SY761_MASK_Y);
 
input_mt_slot(sdata->input, tid);
 




[PATCH 5.4 37/73] net: tipc: Fix spelling errors in net/tipc module

2021-04-19 Thread Greg Kroah-Hartman
From: Zheng Yongjun 

[ Upstream commit a79ace4b312953c5835fafb12adc3cb6878b26bd ]

These patches fix a series of spelling errors in net/tipc module.

Reported-by: Hulk Robot 
Signed-off-by: Zheng Yongjun 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin 
---
 net/tipc/bearer.h | 6 +++---
 net/tipc/net.c| 2 +-
 net/tipc/node.c   | 2 +-
 3 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/net/tipc/bearer.h b/net/tipc/bearer.h
index ea0f3c49cbed..a7b4cf66dfc2 100644
--- a/net/tipc/bearer.h
+++ b/net/tipc/bearer.h
@@ -149,9 +149,9 @@ struct tipc_media {
  * care of initializing all other fields.
  */
 struct tipc_bearer {
-   void __rcu *media_ptr;  /* initalized by media */
-   u32 mtu;/* initalized by media */
-   struct tipc_media_addr addr;/* initalized by media */
+   void __rcu *media_ptr;  /* initialized by media */
+   u32 mtu;/* initialized by media */
+   struct tipc_media_addr addr;/* initialized by media */
char name[TIPC_MAX_BEARER_NAME];
struct tipc_media *media;
struct tipc_media_addr bcast_addr;
diff --git a/net/tipc/net.c b/net/tipc/net.c
index 2498ce8b83c1..2600be4b0d89 100644
--- a/net/tipc/net.c
+++ b/net/tipc/net.c
@@ -89,7 +89,7 @@
  * - A spin lock to protect the registry of kernel/driver users (reg.c)
  * - A global spin_lock (tipc_port_lock), which only task is to ensure
  *   consistency where more than one port is involved in an operation,
- *   i.e., whe a port is part of a linked list of ports.
+ *   i.e., when a port is part of a linked list of ports.
  *   There are two such lists; 'port_list', which is used for management,
  *   and 'wait_list', which is used to queue ports during congestion.
  *
diff --git a/net/tipc/node.c b/net/tipc/node.c
index c8f6177dd5a2..47f7c8e856c6 100644
--- a/net/tipc/node.c
+++ b/net/tipc/node.c
@@ -1482,7 +1482,7 @@ int tipc_node_xmit(struct net *net, struct sk_buff_head 
*list,
 }
 
 /* tipc_node_xmit_skb(): send single buffer to destination
- * Buffers sent via this functon are generally TIPC_SYSTEM_IMPORTANCE
+ * Buffers sent via this function are generally TIPC_SYSTEM_IMPORTANCE
  * messages, which will not be rejected
  * The only exception is datagram messages rerouted after secondary
  * lookup, which are rare and safe to dispose of anyway.
-- 
2.30.2





[PATCH 5.4 38/73] mac80211: clear sta->fast_rx when STA removed from 4-addr VLAN

2021-04-19 Thread Greg Kroah-Hartman
From: Seevalamuthu Mariappan 

[ Upstream commit dd0b45538146cb6a54d6da7663b8c3afd16ebcfd ]

In some race conditions, with more clients and traffic configuration,
below crash is seen when making the interface down. sta->fast_rx wasn't
cleared when STA gets removed from 4-addr AP_VLAN interface. The crash is
due to try accessing 4-addr AP_VLAN interface's net_device (fast_rx->dev)
which has been deleted already.

Resolve this by clearing sta->fast_rx pointer when STA removes
from a 4-addr VLAN.

[  239.449529] Unable to handle kernel NULL pointer dereference at virtual 
address 0004
[  239.449531] pgd = 80204000
...
[  239.481496] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.4.60 #227
[  239.481591] Hardware name: Generic DT based system
[  239.487665] task: be05b700 ti: be08e000 task.ti: be08e000
[  239.492360] PC is at get_rps_cpu+0x2d4/0x31c
[  239.497823] LR is at 0xbe08fc54
...
[  239.778574] [<80739740>] (get_rps_cpu) from [<8073cb10>] 
(netif_receive_skb_internal+0x8c/0xac)
[  239.786722] [<8073cb10>] (netif_receive_skb_internal) from [<8073d578>] 
(napi_gro_receive+0x48/0xc4)
[  239.795267] [<8073d578>] (napi_gro_receive) from [] 
(ieee80211_mark_rx_ba_filtered_frames+0xbcc/0x12d4 [mac80211])
[  239.804776] [] (ieee80211_mark_rx_ba_filtered_frames [mac80211]) 
from [] (ieee80211_rx_napi+0x7b8/0x8c8 [mac8
0211])
[  239.815857] [] (ieee80211_rx_napi [mac80211]) from [] 
(ath11k_dp_process_rx+0x7bc/0x8c8 [ath11k])
[  239.827757] [] (ath11k_dp_process_rx [ath11k]) from [] 
(ath11k_dp_service_srng+0x2c0/0x2e0 [ath11k])
[  239.838484] [] (ath11k_dp_service_srng [ath11k]) from [<7f55b7dc>] 
(ath11k_ahb_ext_grp_napi_poll+0x20/0x84 [ath11k_ahb]
)
[  239.849419] [<7f55b7dc>] (ath11k_ahb_ext_grp_napi_poll [ath11k_ahb]) from 
[<8073ce1c>] (net_rx_action+0xe0/0x28c)
[  239.860945] [<8073ce1c>] (net_rx_action) from [<80324868>] 
(__do_softirq+0xe4/0x228)
[  239.871269] [<80324868>] (__do_softirq) from [<80324c48>] 
(irq_exit+0x98/0x108)
[  239.879080] [<80324c48>] (irq_exit) from [<8035c59c>] 
(__handle_domain_irq+0x90/0xb4)
[  239.886114] [<8035c59c>] (__handle_domain_irq) from [<8030137c>] 
(gic_handle_irq+0x50/0x94)
[  239.894100] [<8030137c>] (gic_handle_irq) from [<803024c0>] 
(__irq_svc+0x40/0x74)

Signed-off-by: Seevalamuthu Mariappan 
Link: 
https://lore.kernel.org/r/1616163532-3881-1-git-send-email-seeva...@codeaurora.org
Signed-off-by: Johannes Berg 
Signed-off-by: Sasha Levin 
---
 net/mac80211/cfg.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/net/mac80211/cfg.c b/net/mac80211/cfg.c
index 677928bf13d1..1b50bbf030ed 100644
--- a/net/mac80211/cfg.c
+++ b/net/mac80211/cfg.c
@@ -1670,8 +1670,10 @@ static int ieee80211_change_station(struct wiphy *wiphy,
}
 
if (sta->sdata->vif.type == NL80211_IFTYPE_AP_VLAN &&
-   sta->sdata->u.vlan.sta)
+   sta->sdata->u.vlan.sta) {
+   ieee80211_clear_fast_rx(sta);
RCU_INIT_POINTER(sta->sdata->u.vlan.sta, NULL);
+   }
 
if (test_sta_flag(sta, WLAN_STA_AUTHORIZED))
ieee80211_vif_dec_num_mcast(sta->sdata);
-- 
2.30.2





[PATCH 5.4 39/73] virt_wifi: Return micros for BSS TSF values

2021-04-19 Thread Greg Kroah-Hartman
From: A. Cody Schuffelen 

[ Upstream commit b57aa17f07c9270e576ef7df09f142978b5a75f0 ]

cfg80211_inform_bss expects to receive a TSF value, but is given the
time since boot in nanoseconds. TSF values are expected to be at
microsecond scale rather than nanosecond scale.

Signed-off-by: A. Cody Schuffelen 
Link: https://lore.kernel.org/r/20210318200419.1421034-1-schuffe...@google.com
Signed-off-by: Johannes Berg 
Signed-off-by: Sasha Levin 
---
 drivers/net/wireless/virt_wifi.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/net/wireless/virt_wifi.c b/drivers/net/wireless/virt_wifi.c
index 01305ba2d3aa..9d04ca53229b 100644
--- a/drivers/net/wireless/virt_wifi.c
+++ b/drivers/net/wireless/virt_wifi.c
@@ -12,6 +12,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 static struct wiphy *common_wiphy;
@@ -168,11 +169,11 @@ static void virt_wifi_scan_result(struct work_struct 
*work)
 scan_result.work);
struct wiphy *wiphy = priv_to_wiphy(priv);
struct cfg80211_scan_info scan_info = { .aborted = false };
+   u64 tsf = div_u64(ktime_get_boottime_ns(), 1000);
 
informed_bss = cfg80211_inform_bss(wiphy, _5ghz,
   CFG80211_BSS_FTYPE_PRESP,
-  fake_router_bssid,
-  ktime_get_boottime_ns(),
+  fake_router_bssid, tsf,
   WLAN_CAPABILITY_ESS, 0,
   (void *), sizeof(ssid),
   DBM_TO_MBM(-50), GFP_KERNEL);
-- 
2.30.2





[PATCH 5.4 32/73] net: ieee802154: forbid monitor for del llsec devkey

2021-04-19 Thread Greg Kroah-Hartman
From: Alexander Aring 

[ Upstream commit 6fb8045319ef172dc88a8142e7f8b58c7608137e ]

This patch forbids to del llsec devkey for monitor interfaces which we
don't support yet. Otherwise we will access llsec mib which isn't
initialized for monitors.

Signed-off-by: Alexander Aring 
Link: https://lore.kernel.org/r/20210405003054.256017-12-aahri...@redhat.com
Signed-off-by: Stefan Schmidt 
Signed-off-by: Sasha Levin 
---
 net/ieee802154/nl802154.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/net/ieee802154/nl802154.c b/net/ieee802154/nl802154.c
index 65987215dd0c..0c43b951a33f 100644
--- a/net/ieee802154/nl802154.c
+++ b/net/ieee802154/nl802154.c
@@ -1970,6 +1970,9 @@ static int nl802154_del_llsec_devkey(struct sk_buff *skb, 
struct genl_info *info
struct ieee802154_llsec_device_key key;
__le64 extended_addr;
 
+   if (wpan_dev->iftype == NL802154_IFTYPE_MONITOR)
+   return -EOPNOTSUPP;
+
if (!info->attrs[NL802154_ATTR_SEC_DEVKEY] ||
nla_parse_nested_deprecated(attrs, NL802154_DEVKEY_ATTR_MAX, 
info->attrs[NL802154_ATTR_SEC_DEVKEY], nl802154_devkey_policy, info->extack))
return -EINVAL;
-- 
2.30.2





[PATCH 5.4 34/73] net: ieee802154: forbid monitor for add llsec seclevel

2021-04-19 Thread Greg Kroah-Hartman
From: Alexander Aring 

[ Upstream commit 9ec87e322428d4734ac647d1a8e507434086993d ]

This patch forbids to add llsec seclevel for monitor interfaces which we
don't support yet. Otherwise we will access llsec mib which isn't
initialized for monitors.

Signed-off-by: Alexander Aring 
Link: https://lore.kernel.org/r/20210405003054.256017-14-aahri...@redhat.com
Signed-off-by: Stefan Schmidt 
Signed-off-by: Sasha Levin 
---
 net/ieee802154/nl802154.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/net/ieee802154/nl802154.c b/net/ieee802154/nl802154.c
index 4dd936c7db8b..328bb9f5342e 100644
--- a/net/ieee802154/nl802154.c
+++ b/net/ieee802154/nl802154.c
@@ -2136,6 +2136,9 @@ static int nl802154_add_llsec_seclevel(struct sk_buff 
*skb,
struct wpan_dev *wpan_dev = dev->ieee802154_ptr;
struct ieee802154_llsec_seclevel sl;
 
+   if (wpan_dev->iftype == NL802154_IFTYPE_MONITOR)
+   return -EOPNOTSUPP;
+
if (llsec_parse_seclevel(info->attrs[NL802154_ATTR_SEC_LEVEL],
 ) < 0)
return -EINVAL;
-- 
2.30.2





[PATCH 5.4 33/73] net: ieee802154: stop dump llsec seclevels for monitors

2021-04-19 Thread Greg Kroah-Hartman
From: Alexander Aring 

[ Upstream commit 4c9b4f55ad1f5a4b6206ac4ea58f273126d21925 ]

This patch stops dumping llsec seclevels for monitors which we don't
support yet. Otherwise we will access llsec mib which isn't initialized
for monitors.

Signed-off-by: Alexander Aring 
Link: https://lore.kernel.org/r/20210405003054.256017-13-aahri...@redhat.com
Signed-off-by: Stefan Schmidt 
Signed-off-by: Sasha Levin 
---
 net/ieee802154/nl802154.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/net/ieee802154/nl802154.c b/net/ieee802154/nl802154.c
index 0c43b951a33f..4dd936c7db8b 100644
--- a/net/ieee802154/nl802154.c
+++ b/net/ieee802154/nl802154.c
@@ -2047,6 +2047,11 @@ nl802154_dump_llsec_seclevel(struct sk_buff *skb, struct 
netlink_callback *cb)
if (err)
return err;
 
+   if (wpan_dev->iftype == NL802154_IFTYPE_MONITOR) {
+   err = skb->len;
+   goto out_err;
+   }
+
if (!wpan_dev->netdev) {
err = -EINVAL;
goto out_err;
-- 
2.30.2





[PATCH 5.4 35/73] pcnet32: Use pci_resource_len to validate PCI resource

2021-04-19 Thread Greg Kroah-Hartman
From: Guenter Roeck 

[ Upstream commit 66c3f05ddc538ee796321210c906b6ae6fc0792a ]

pci_resource_start() is not a good indicator to determine if a PCI
resource exists or not, since the resource may start at address 0.
This is seen when trying to instantiate the driver in qemu for riscv32
or riscv64.

pci :00:01.0: reg 0x10: [io  0x-0x001f]
pci :00:01.0: reg 0x14: [mem 0x-0x001f]
...
pcnet32: card has no PCI IO resources, aborting

Use pci_resouce_len() instead.

Signed-off-by: Guenter Roeck 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin 
---
 drivers/net/ethernet/amd/pcnet32.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/amd/pcnet32.c 
b/drivers/net/ethernet/amd/pcnet32.c
index f5ad12c10934..da84660ceae1 100644
--- a/drivers/net/ethernet/amd/pcnet32.c
+++ b/drivers/net/ethernet/amd/pcnet32.c
@@ -1548,8 +1548,7 @@ pcnet32_probe_pci(struct pci_dev *pdev, const struct 
pci_device_id *ent)
}
pci_set_master(pdev);
 
-   ioaddr = pci_resource_start(pdev, 0);
-   if (!ioaddr) {
+   if (!pci_resource_len(pdev, 0)) {
if (pcnet32_debug & NETIF_MSG_PROBE)
pr_err("card has no PCI IO resources, aborting\n");
err = -ENODEV;
@@ -1562,6 +1561,8 @@ pcnet32_probe_pci(struct pci_dev *pdev, const struct 
pci_device_id *ent)
pr_err("architecture does not support 32bit PCI 
busmaster DMA\n");
goto err_disable_dev;
}
+
+   ioaddr = pci_resource_start(pdev, 0);
if (!request_region(ioaddr, PCNET32_TOTAL_SIZE, "pcnet32_probe_pci")) {
if (pcnet32_debug & NETIF_MSG_PROBE)
pr_err("io address range already allocated\n");
-- 
2.30.2





[PATCH 5.4 00/73] 5.4.114-rc1 review

2021-04-19 Thread Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.4.114 release.
There are 73 patches in this series, all will be posted as a response
to this one.  If anyone has any issues with these being applied, please
let me know.

Responses should be made by Wed, 21 Apr 2021 13:05:09 +.
Anything received after that time might be too late.

The whole patch series can be found in one patch at:

https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.4.114-rc1.gz
or in the git tree and branch at:

git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
linux-5.4.y
and the diffstat can be found below.

thanks,

greg k-h

-
Pseudo-Shortlog of commits:

Greg Kroah-Hartman 
Linux 5.4.114-rc1

Pali Rohár 
net: phy: marvell: fix detection of PHY on Topaz switches

Fredrik Strupe 
ARM: 9071/1: uprobes: Don't hook on thumb instructions

Heiner Kallweit 
r8169: don't advertise pause in jumbo mode

Heiner Kallweit 
r8169: tweak max read request size for newer chips also in jumbo mtu mode

Heiner Kallweit 
r8169: improve rtl_jumbo_config

Heiner Kallweit 
r8169: fix performance regression related to PCIe max read request size

Heiner Kallweit 
r8169: simplify setting PCI_EXP_DEVCTL_NOSNOOP_EN

Heiner Kallweit 
r8169: remove fiddling with the PCIe max read request size

Andre Przywara 
arm64: dts: allwinner: Fix SD card CD GPIO for SOPine systems

Russell King 
ARM: footbridge: fix PCI interrupt mapping

Eric Dumazet 
gro: ensure frag0 meets IP header alignment

Lijun Pan 
ibmvnic: remove duplicate napi_schedule call in open function

Lijun Pan 
ibmvnic: remove duplicate napi_schedule call in do_reset function

Lijun Pan 
ibmvnic: avoid calling napi_disable() twice

Jason Xing 
i40e: fix the panic when running bpf in xdpdrv mode

Hristo Venev 
net: ip6_tunnel: Unregister catch-all devices

Hristo Venev 
net: sit: Unregister catch-all devices

Christophe JAILLET 
net: davicom: Fix regulator not turned off on failed probe

Eric Dumazet 
netfilter: nft_limit: avoid possible divide error in nft_limit_init

Claudiu Beznea 
net: macb: fix the restore of cmp registers

Florian Westphal 
netfilter: arp_tables: add pre_exit hook for table unregister

Florian Westphal 
netfilter: bridge: add pre_exit hooks for ebtable unregistration

Vaibhav Jain 
libnvdimm/region: Fix nvdimm_has_flush() to handle ND_REGION_ASYNC

Pablo Neira Ayuso 
netfilter: conntrack: do not print icmpv6 as unknown via /proc

Jolly Shah 
scsi: libsas: Reset num_scatter if libata marks qc as NODATA

Kefeng Wang 
riscv: Fix spelling mistake "SPARSEMEM" to "SPARSMEM"

Christian A. Ehrhardt 
vfio/pci: Add missing range check in vfio_pci_mmap

Nathan Chancellor 
arm64: alternatives: Move length validation in alternative_{insn, endif}

Peter Collingbourne 
arm64: fix inline asm in load_unaligned_zeropad()

Linus Torvalds 
readdir: make sure to verify directory entry for legacy interfaces too

Jaegeuk Kim 
dm verity fec: fix misaligned RS roots IO

Ping Cheng 
HID: wacom: set EV_KEY and EV_ABS only for non-HID_GENERIC type of devices

Arnd Bergmann 
Input: i8042 - fix Pegatron C15B ID entry

Caleb Connolly 
Input: s6sy761 - fix coordinate read bit shift

A. Cody Schuffelen 
virt_wifi: Return micros for BSS TSF values

Seevalamuthu Mariappan 
mac80211: clear sta->fast_rx when STA removed from 4-addr VLAN

Zheng Yongjun 
net: tipc: Fix spelling errors in net/tipc module

Aditya Pakki 
net/rds: Avoid potential use after free in rds_send_remove_from_sock

Guenter Roeck 
pcnet32: Use pci_resource_len to validate PCI resource

Alexander Aring 
net: ieee802154: forbid monitor for add llsec seclevel

Alexander Aring 
net: ieee802154: stop dump llsec seclevels for monitors

Alexander Aring 
net: ieee802154: forbid monitor for del llsec devkey

Alexander Aring 
net: ieee802154: forbid monitor for add llsec devkey

Alexander Aring 
net: ieee802154: stop dump llsec devkeys for monitors

Alexander Aring 
net: ieee802154: forbid monitor for del llsec dev

Alexander Aring 
net: ieee802154: forbid monitor for add llsec dev

Alexander Aring 
net: ieee802154: stop dump llsec devs for monitors

Alexander Aring 
net: ieee802154: forbid monitor for del llsec key

Alexander Aring 
net: ieee802154: forbid monitor for add llsec key

Alexander Aring 
net: ieee802154: stop dump llsec keys for monitors

Martin Wilck 
scsi: scsi_transport_srp: Don't block target in SRP_PORT_LOST state

Alexander Shiyan 
ASoC: fsl_esai: Fix TDM slot setup for I2S mode

Rob Clark 
drm/msm: Fix a5xx/a6xx timestamps

Arnd Bergmann 
ARM: omap1: fix building with clang IAS

Arnd Bergmann 
ARM: keystone: fix integer overflow warning

Tong Zhu 
neighbour: Disregard DEAD dst in neigh_update

Ryan Lee 
ASoC: ma

[PATCH 5.4 09/73] net/sctp: fix race condition in sctp_destroy_sock

2021-04-19 Thread Greg Kroah-Hartman
From: Or Cohen 

commit b166a20b07382b8bc1dcee2a448715c9c2c81b5b upstream.

If sctp_destroy_sock is called without sock_net(sk)->sctp.addr_wq_lock
held and sp->do_auto_asconf is true, then an element is removed
from the auto_asconf_splist without any proper locking.

This can happen in the following functions:
1. In sctp_accept, if sctp_sock_migrate fails.
2. In inet_create or inet6_create, if there is a bpf program
   attached to BPF_CGROUP_INET_SOCK_CREATE which denies
   creation of the sctp socket.

The bug is fixed by acquiring addr_wq_lock in sctp_destroy_sock
instead of sctp_close.

This addresses CVE-2021-23133.

Reported-by: Or Cohen 
Reviewed-by: Xin Long 
Fixes: 610236587600 ("bpf: Add new cgroup attach type to enable sock 
modifications")
Signed-off-by: Or Cohen 
Acked-by: Marcelo Ricardo Leitner 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman 
---
 net/sctp/socket.c |   13 +
 1 file changed, 5 insertions(+), 8 deletions(-)

--- a/net/sctp/socket.c
+++ b/net/sctp/socket.c
@@ -1539,11 +1539,9 @@ static void sctp_close(struct sock *sk,
 
/* Supposedly, no process has access to the socket, but
 * the net layers still may.
-* Also, sctp_destroy_sock() needs to be called with addr_wq_lock
-* held and that should be grabbed before socket lock.
 */
-   spin_lock_bh(>sctp.addr_wq_lock);
-   bh_lock_sock_nested(sk);
+   local_bh_disable();
+   bh_lock_sock(sk);
 
/* Hold the sock, since sk_common_release() will put sock_put()
 * and we have just a little more cleanup.
@@ -1552,7 +1550,7 @@ static void sctp_close(struct sock *sk,
sk_common_release(sk);
 
bh_unlock_sock(sk);
-   spin_unlock_bh(>sctp.addr_wq_lock);
+   local_bh_enable();
 
sock_put(sk);
 
@@ -5115,9 +5113,6 @@ static int sctp_init_sock(struct sock *s
sk_sockets_allocated_inc(sk);
sock_prot_inuse_add(net, sk->sk_prot, 1);
 
-   /* Nothing can fail after this block, otherwise
-* sctp_destroy_sock() will be called without addr_wq_lock held
-*/
if (net->sctp.default_auto_asconf) {
spin_lock(_net(sk)->sctp.addr_wq_lock);
list_add_tail(>auto_asconf_list,
@@ -5152,7 +5147,9 @@ static void sctp_destroy_sock(struct soc
 
if (sp->do_auto_asconf) {
sp->do_auto_asconf = 0;
+   spin_lock_bh(_net(sk)->sctp.addr_wq_lock);
list_del(>auto_asconf_list);
+   spin_unlock_bh(_net(sk)->sctp.addr_wq_lock);
}
sctp_endpoint_free(sp->ep);
local_bh_disable();




[PATCH 5.4 08/73] scsi: qla2xxx: Fix fabric scan hang

2021-04-19 Thread Greg Kroah-Hartman
From: Quinn Tran 

[ Upstream commit f57a0107359605b29f4ea9afb8ee2e03473b1448 ]

On timeout, SRB pointer was cleared from outstanding command array and
dropped.  It was not allowed to go through the done process and cleanup.
This patch will abort the SRB where FW will return it with an error status
and resume the normal cleanup.

Link: https://lore.kernel.org/r/20191217220617.28084-3-hmadh...@marvell.com
Signed-off-by: Quinn Tran 
Signed-off-by: Himanshu Madhani 
Signed-off-by: Martin K. Petersen 
Signed-off-by: Sasha Levin 
---
 drivers/scsi/qla2xxx/qla_gbl.h  |  1 +
 drivers/scsi/qla2xxx/qla_init.c | 34 +++
 drivers/scsi/qla2xxx/qla_iocb.c | 41 ++---
 3 files changed, 53 insertions(+), 23 deletions(-)

diff --git a/drivers/scsi/qla2xxx/qla_gbl.h b/drivers/scsi/qla2xxx/qla_gbl.h
index 5a3c47eed645..7aa233771ec8 100644
--- a/drivers/scsi/qla2xxx/qla_gbl.h
+++ b/drivers/scsi/qla2xxx/qla_gbl.h
@@ -256,6 +256,7 @@ extern char *qla2x00_get_fw_version_str(struct 
scsi_qla_host *, char *);
 
 extern void qla2x00_mark_device_lost(scsi_qla_host_t *, fc_port_t *, int, int);
 extern void qla2x00_mark_all_devices_lost(scsi_qla_host_t *, int);
+extern int qla24xx_async_abort_cmd(srb_t *, bool);
 
 extern struct fw_blob *qla2x00_request_firmware(scsi_qla_host_t *);
 
diff --git a/drivers/scsi/qla2xxx/qla_init.c b/drivers/scsi/qla2xxx/qla_init.c
index b4f0c2c8414e..643b8ae36cbe 100644
--- a/drivers/scsi/qla2xxx/qla_init.c
+++ b/drivers/scsi/qla2xxx/qla_init.c
@@ -50,16 +50,9 @@ qla2x00_sp_timeout(struct timer_list *t)
 {
srb_t *sp = from_timer(sp, t, u.iocb_cmd.timer);
struct srb_iocb *iocb;
-   struct req_que *req;
-   unsigned long flags;
-   struct qla_hw_data *ha = sp->vha->hw;
 
-   WARN_ON_ONCE(irqs_disabled());
-   spin_lock_irqsave(>hardware_lock, flags);
-   req = sp->qpair->req;
-   req->outstanding_cmds[sp->handle] = NULL;
+   WARN_ON(irqs_disabled());
iocb = >u.iocb_cmd;
-   spin_unlock_irqrestore(>hardware_lock, flags);
iocb->timeout(sp);
 }
 
@@ -153,7 +146,7 @@ static void qla24xx_abort_sp_done(srb_t *sp, int res)
sp->free(sp);
 }
 
-static int qla24xx_async_abort_cmd(srb_t *cmd_sp, bool wait)
+int qla24xx_async_abort_cmd(srb_t *cmd_sp, bool wait)
 {
scsi_qla_host_t *vha = cmd_sp->vha;
struct srb_iocb *abt_iocb;
@@ -253,6 +246,7 @@ qla2x00_async_iocb_timeout(void *data)
case SRB_NACK_PRLI:
case SRB_NACK_LOGO:
case SRB_CTRL_VP:
+   default:
rc = qla24xx_async_abort_cmd(sp, false);
if (rc) {
spin_lock_irqsave(sp->qpair->qp_lock_ptr, flags);
@@ -269,10 +263,6 @@ qla2x00_async_iocb_timeout(void *data)
sp->done(sp, QLA_FUNCTION_TIMEOUT);
}
break;
-   default:
-   WARN_ON_ONCE(true);
-   sp->done(sp, QLA_FUNCTION_TIMEOUT);
-   break;
}
 }
 
@@ -1794,9 +1784,23 @@ qla2x00_tmf_iocb_timeout(void *data)
 {
srb_t *sp = data;
struct srb_iocb *tmf = >u.iocb_cmd;
+   int rc, h;
+   unsigned long flags;
 
-   tmf->u.tmf.comp_status = CS_TIMEOUT;
-   complete(>u.tmf.comp);
+   rc = qla24xx_async_abort_cmd(sp, false);
+   if (rc) {
+   spin_lock_irqsave(sp->qpair->qp_lock_ptr, flags);
+   for (h = 1; h < sp->qpair->req->num_outstanding_cmds; h++) {
+   if (sp->qpair->req->outstanding_cmds[h] == sp) {
+   sp->qpair->req->outstanding_cmds[h] = NULL;
+   break;
+   }
+   }
+   spin_unlock_irqrestore(sp->qpair->qp_lock_ptr, flags);
+   tmf->u.tmf.comp_status = CS_TIMEOUT;
+   tmf->u.tmf.data = QLA_FUNCTION_FAILED;
+   complete(>u.tmf.comp);
+   }
 }
 
 static void qla2x00_tmf_sp_done(srb_t *sp, int res)
diff --git a/drivers/scsi/qla2xxx/qla_iocb.c b/drivers/scsi/qla2xxx/qla_iocb.c
index 3f43410fab9d..936103604d02 100644
--- a/drivers/scsi/qla2xxx/qla_iocb.c
+++ b/drivers/scsi/qla2xxx/qla_iocb.c
@@ -2537,13 +2537,32 @@ qla2x00_els_dcmd_iocb_timeout(void *data)
fc_port_t *fcport = sp->fcport;
struct scsi_qla_host *vha = sp->vha;
struct srb_iocb *lio = >u.iocb_cmd;
+   unsigned long flags = 0;
+   int res, h;
 
ql_dbg(ql_dbg_io, vha, 0x3069,
"%s Timeout, hdl=%x, portid=%02x%02x%02x\n",
sp->name, sp->handle, fcport->d_id.b.domain, fcport->d_id.b.area,
fcport->d_id.b.al_pa);
 
-   complete(>u.els_logo.comp);
+   /* Abort the exchange */
+   res = qla24xx_async_abort_cmd(sp, false);
+   if (res) {
+   ql_dbg(ql_dbg_io, vha, 0x3070,
+   "mbx abort_command failed.\n");
+   spin_lock_irqsave(sp->qpair->qp_lock_ptr, flags);
+   for (h = 1; 

[PATCH 5.4 23/73] scsi: scsi_transport_srp: Dont block target in SRP_PORT_LOST state

2021-04-19 Thread Greg Kroah-Hartman
From: Martin Wilck 

[ Upstream commit 5cd0f6f57639c5afbb36100c69281fee82c95ee7 ]

rport_dev_loss_timedout() sets the rport state to SRP_PORT_LOST and the
SCSI target state to SDEV_TRANSPORT_OFFLINE. If this races with
srp_reconnect_work(), a warning is printed:

Mar 27 18:48:07 ictm1604s01h4 kernel: dev_loss_tmo expired for SRP port-18:1 / 
host18.
Mar 27 18:48:07 ictm1604s01h4 kernel: [ cut here ]
Mar 27 18:48:07 ictm1604s01h4 kernel: scsi_internal_device_block(18:0:0:100) 
failed: ret = -22
Mar 27 18:48:07 ictm1604s01h4 kernel: Call Trace:
Mar 27 18:48:07 ictm1604s01h4 kernel:  ? scsi_target_unblock+0x50/0x50 
[scsi_mod]
Mar 27 18:48:07 ictm1604s01h4 kernel:  starget_for_each_device+0x80/0xb0 
[scsi_mod]
Mar 27 18:48:07 ictm1604s01h4 kernel:  target_block+0x24/0x30 [scsi_mod]
Mar 27 18:48:07 ictm1604s01h4 kernel:  device_for_each_child+0x57/0x90
Mar 27 18:48:07 ictm1604s01h4 kernel:  srp_reconnect_rport+0xe4/0x230 
[scsi_transport_srp]
Mar 27 18:48:07 ictm1604s01h4 kernel:  srp_reconnect_work+0x40/0xc0 
[scsi_transport_srp]

Avoid this by not trying to block targets for rports in SRP_PORT_LOST
state.

Link: https://lore.kernel.org/r/20210401091105.8046-1-mwi...@suse.com
Reviewed-by: Bart Van Assche 
Signed-off-by: Martin Wilck 
Signed-off-by: Martin K. Petersen 
Signed-off-by: Sasha Levin 
---
 drivers/scsi/scsi_transport_srp.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/scsi/scsi_transport_srp.c 
b/drivers/scsi/scsi_transport_srp.c
index 8cd0a87764df..9fee851c23a5 100644
--- a/drivers/scsi/scsi_transport_srp.c
+++ b/drivers/scsi/scsi_transport_srp.c
@@ -541,7 +541,7 @@ int srp_reconnect_rport(struct srp_rport *rport)
res = mutex_lock_interruptible(>mutex);
if (res)
goto out;
-   if (rport->state != SRP_RPORT_FAIL_FAST)
+   if (rport->state != SRP_RPORT_FAIL_FAST && rport->state != 
SRP_RPORT_LOST)
/*
 * sdev state must be SDEV_TRANSPORT_OFFLINE, transition
 * to SDEV_BLOCK is illegal. Calling scsi_target_unblock()
-- 
2.30.2





[PATCH 5.4 07/73] scsi: qla2xxx: Fix stuck login session using prli_pend_timer

2021-04-19 Thread Greg Kroah-Hartman
From: Quinn Tran 

[ Upstream commit 8aaac2d7da873aebeba92c666f82c00bbd74aaf9 ]

Session is stuck if driver sees FW has received a PRLI. Driver allows FW to
finish with processing of PRLI by checking back with FW at a later time to
see if the PRLI has finished. Instead, driver failed to push forward after
re-checking PRLI completion.

Fixes: ce0ba496dccf ("scsi: qla2xxx: Fix stuck login session")
Cc: sta...@vger.kernel.org # 5.3
Link: https://lore.kernel.org/r/20191217220617.28084-9-hmadh...@marvell.com
Signed-off-by: Quinn Tran 
Signed-off-by: Himanshu Madhani 
Signed-off-by: Martin K. Petersen 
Signed-off-by: Sasha Levin 
---
 drivers/scsi/qla2xxx/qla_def.h|  5 +
 drivers/scsi/qla2xxx/qla_init.c   | 34 +++
 drivers/scsi/qla2xxx/qla_target.c |  1 +
 3 files changed, 32 insertions(+), 8 deletions(-)

diff --git a/drivers/scsi/qla2xxx/qla_def.h b/drivers/scsi/qla2xxx/qla_def.h
index 5e940543eaa1..7c22f8eea3ea 100644
--- a/drivers/scsi/qla2xxx/qla_def.h
+++ b/drivers/scsi/qla2xxx/qla_def.h
@@ -2402,6 +2402,7 @@ typedef struct fc_port {
unsigned int scan_needed:1;
unsigned int n2n_flag:1;
unsigned int explicit_logout:1;
+   unsigned int prli_pend_timer:1;
 
struct completion nvme_del_done;
uint32_t nvme_prli_service_param;
@@ -2428,6 +2429,7 @@ typedef struct fc_port {
struct work_struct free_work;
struct work_struct reg_work;
uint64_t jiffies_at_registration;
+   unsigned long prli_expired;
struct qlt_plogi_ack_t *plogi_link[QLT_PLOGI_LINK_MAX];
 
uint16_t tgt_id;
@@ -4857,6 +4859,9 @@ struct sff_8247_a0 {
(ha->fc4_type_priority == FC4_PRIORITY_NVME)) || \
NVME_ONLY_TARGET(fcport)) \
 
+#define PRLI_PHASE(_cls) \
+   ((_cls == DSC_LS_PRLI_PEND) || (_cls == DSC_LS_PRLI_COMP))
+
 #include "qla_target.h"
 #include "qla_gbl.h"
 #include "qla_dbg.h"
diff --git a/drivers/scsi/qla2xxx/qla_init.c b/drivers/scsi/qla2xxx/qla_init.c
index 0aac1eb1e013..b4f0c2c8414e 100644
--- a/drivers/scsi/qla2xxx/qla_init.c
+++ b/drivers/scsi/qla2xxx/qla_init.c
@@ -696,7 +696,7 @@ static void qla24xx_handle_gnl_done_event(scsi_qla_host_t 
*vha,
port_id_t id;
u64 wwn;
u16 data[2];
-   u8 current_login_state;
+   u8 current_login_state, nvme_cls;
 
fcport = ea->fcport;
ql_dbg(ql_dbg_disc, vha, 0x,
@@ -755,10 +755,17 @@ static void qla24xx_handle_gnl_done_event(scsi_qla_host_t 
*vha,
 
loop_id = le16_to_cpu(e->nport_handle);
loop_id = (loop_id & 0x7fff);
-   if (NVME_TARGET(vha->hw, fcport))
-   current_login_state = e->current_login_state >> 4;
-   else
-   current_login_state = e->current_login_state & 0xf;
+   nvme_cls = e->current_login_state >> 4;
+   current_login_state = e->current_login_state & 0xf;
+
+   if (PRLI_PHASE(nvme_cls)) {
+   current_login_state = nvme_cls;
+   fcport->fc4_type &= ~FS_FC4TYPE_FCP;
+   fcport->fc4_type |= FS_FC4TYPE_NVME;
+   } else if (PRLI_PHASE(current_login_state)) {
+   fcport->fc4_type |= FS_FC4TYPE_FCP;
+   fcport->fc4_type &= ~FS_FC4TYPE_NVME;
+   }
 
ql_dbg(ql_dbg_disc, vha, 0x20e2,
"%s found %8phC CLS [%x|%x] fc4_type %d ID[%06x|%06x] 
lid[%d|%d]\n",
@@ -1238,12 +1245,19 @@ qla24xx_async_prli(struct scsi_qla_host *vha, fc_port_t 
*fcport)
struct srb_iocb *lio;
int rval = QLA_FUNCTION_FAILED;
 
-   if (!vha->flags.online)
+   if (!vha->flags.online) {
+   ql_dbg(ql_dbg_disc, vha, 0x, "%s %d %8phC exit\n",
+   __func__, __LINE__, fcport->port_name);
return rval;
+   }
 
-   if (fcport->fw_login_state == DSC_LS_PLOGI_PEND ||
-   fcport->fw_login_state == DSC_LS_PRLI_PEND)
+   if ((fcport->fw_login_state == DSC_LS_PLOGI_PEND ||
+   fcport->fw_login_state == DSC_LS_PRLI_PEND) &&
+   qla_dual_mode_enabled(vha)) {
+   ql_dbg(ql_dbg_disc, vha, 0x, "%s %d %8phC exit\n",
+   __func__, __LINE__, fcport->port_name);
return rval;
+   }
 
sp = qla2x00_get_sp(vha, fcport, GFP_KERNEL);
if (!sp)
@@ -1622,6 +1636,10 @@ int qla24xx_fcport_handle_login(struct scsi_qla_host 
*vha, fc_port_t *fcport)
break;
default:
if (fcport->login_pause) {
+   ql_dbg(ql_dbg_disc, vha, 0x20d8,
+   "%s %d %8phC exit\n",
+   __func__, __LINE__,
+   fcport->port_name);
fcport->last_rscn_gen = fcport->rscn_gen;
fcport->last_login_gen 

[PATCH 5.4 06/73] scsi: qla2xxx: Add a shadow variable to hold disc_state history of fcport

2021-04-19 Thread Greg Kroah-Hartman
From: Shyam Sundar 

[ Upstream commit 27258a5771446f9c7edc929ecb76fe2c12c29d97 ]

This patch adds a shadow variable to hold disc_state history for the fcport
and prints state transition when the logging is enabled.

Link: https://lore.kernel.org/r/20191217220617.28084-4-hmadh...@marvell.com
Signed-off-by: Shyam Sundar 
Signed-off-by: Himanshu Madhani 
Signed-off-by: Martin K. Petersen 
Signed-off-by: Sasha Levin 
---
 drivers/scsi/qla2xxx/qla_dbg.c|  2 +-
 drivers/scsi/qla2xxx/qla_def.h| 14 ++
 drivers/scsi/qla2xxx/qla_gbl.h|  1 +
 drivers/scsi/qla2xxx/qla_gs.c |  2 +-
 drivers/scsi/qla2xxx/qla_init.c   | 29 +++--
 drivers/scsi/qla2xxx/qla_inline.h | 24 
 drivers/scsi/qla2xxx/qla_iocb.c   |  7 ---
 drivers/scsi/qla2xxx/qla_os.c |  2 +-
 drivers/scsi/qla2xxx/qla_target.c | 11 ++-
 9 files changed, 67 insertions(+), 25 deletions(-)

diff --git a/drivers/scsi/qla2xxx/qla_dbg.c b/drivers/scsi/qla2xxx/qla_dbg.c
index 7bbff91f8883..88a56e8480f7 100644
--- a/drivers/scsi/qla2xxx/qla_dbg.c
+++ b/drivers/scsi/qla2xxx/qla_dbg.c
@@ -18,7 +18,7 @@
  * | Device Discovery |   0x2134   | 0x210e-0x2116  |
  * | || 0x211a |
  * |  || 0x211c-0x2128  |
- * |  || 0x212a-0x2130  |
+ * |  || 0x212a-0x2134  |
  * | Queue Command and IO tracing |   0x3074   | 0x300b |
  * |  || 0x3027-0x3028  |
  * |  || 0x303d-0x3041  |
diff --git a/drivers/scsi/qla2xxx/qla_def.h b/drivers/scsi/qla2xxx/qla_def.h
index 894c2716b7ce..5e940543eaa1 100644
--- a/drivers/scsi/qla2xxx/qla_def.h
+++ b/drivers/scsi/qla2xxx/qla_def.h
@@ -2464,6 +2464,7 @@ typedef struct fc_port {
struct qla_tgt_sess *tgt_session;
struct ct_sns_desc ct_desc;
enum discovery_state disc_state;
+   atomic_t shadow_disc_state;
enum discovery_state next_disc_state;
enum login_state fw_login_state;
unsigned long dm_login_expire;
@@ -2508,6 +2509,19 @@ struct event_arg {
 
 extern const char *const port_state_str[5];
 
+static const char * const port_dstate_str[] = {
+   "DELETED",
+   "GNN_ID",
+   "GNL",
+   "LOGIN_PEND",
+   "LOGIN_FAILED",
+   "GPDB",
+   "UPD_FCPORT",
+   "LOGIN_COMPLETE",
+   "ADISC",
+   "DELETE_PEND"
+};
+
 /*
  * FC port flags.
  */
diff --git a/drivers/scsi/qla2xxx/qla_gbl.h b/drivers/scsi/qla2xxx/qla_gbl.h
index 5b163ad85c34..5a3c47eed645 100644
--- a/drivers/scsi/qla2xxx/qla_gbl.h
+++ b/drivers/scsi/qla2xxx/qla_gbl.h
@@ -80,6 +80,7 @@ extern int qla24xx_async_gnl(struct scsi_qla_host *, 
fc_port_t *);
 int qla2x00_post_work(struct scsi_qla_host *vha, struct qla_work_evt *e);
 extern void *qla2x00_alloc_iocbs_ready(struct qla_qpair *, srb_t *);
 extern int qla24xx_update_fcport_fcp_prio(scsi_qla_host_t *, fc_port_t *);
+extern int qla24xx_async_abort_cmd(srb_t *, bool);
 
 extern void qla2x00_set_fcport_state(fc_port_t *fcport, int state);
 extern fc_port_t *
diff --git a/drivers/scsi/qla2xxx/qla_gs.c b/drivers/scsi/qla2xxx/qla_gs.c
index ae13aabf280b..d9b5ea77fde9 100644
--- a/drivers/scsi/qla2xxx/qla_gs.c
+++ b/drivers/scsi/qla2xxx/qla_gs.c
@@ -4290,7 +4290,7 @@ int qla24xx_async_gnnid(scsi_qla_host_t *vha, fc_port_t 
*fcport)
if (!vha->flags.online || (fcport->flags & FCF_ASYNC_SENT))
return rval;
 
-   fcport->disc_state = DSC_GNN_ID;
+   qla2x00_set_fcport_disc_state(fcport, DSC_GNN_ID);
sp = qla2x00_get_sp(vha, fcport, GFP_ATOMIC);
if (!sp)
goto done;
diff --git a/drivers/scsi/qla2xxx/qla_init.c b/drivers/scsi/qla2xxx/qla_init.c
index 5d2d0c287469..0aac1eb1e013 100644
--- a/drivers/scsi/qla2xxx/qla_init.c
+++ b/drivers/scsi/qla2xxx/qla_init.c
@@ -337,10 +337,10 @@ qla2x00_async_login(struct scsi_qla_host *vha, fc_port_t 
*fcport,
if (!sp)
goto done;
 
+   qla2x00_set_fcport_disc_state(fcport, DSC_LOGIN_PEND);
fcport->flags |= FCF_ASYNC_SENT;
fcport->logout_completed = 0;
 
-   fcport->disc_state = DSC_LOGIN_PEND;
sp->type = SRB_LOGIN_CMD;
sp->name = "login";
sp->gen1 = fcport->rscn_gen;
@@ -544,7 +544,7 @@ static int qla_post_els_plogi_work(struct scsi_qla_host 
*vha, fc_port_t *fcport)
 
e->u.fcport.fcport = fcport;
fcport->flags |= FCF_ASYNC_ACTIVE;
-   fcport->disc_state = DSC_LOGIN_PEND;
+   qla2x00_set_fcport_disc_state(fcport, DSC_LOGIN_PEND);
return qla2x00_post_work(vha, e);
 }
 
@@ -847,7 +847,8 @@ static void qla24xx_handle_gnl_done_event(scsi_qla_host_t 
*vha,
 * with GNL. Push disc_state back to DELETED
 

[PATCH 5.4 05/73] scsi: qla2xxx: Retry PLOGI on FC-NVMe PRLI failure

2021-04-19 Thread Greg Kroah-Hartman
From: Quinn Tran 

[ Upstream commit 983f127603fac650fa34ee69db363e4615eaf9e7 ]

Current code will send PRLI with FC-NVMe bit set for the targets which
support only FCP. This may result into issue with targets which do not
understand NVMe and will go into a strange state. This patch would restart
the login process by going back to PLOGI state. The PLOGI state will force
the target to respond to correct PRLI request.

Fixes: c76ae845ea836 ("scsi: qla2xxx: Add error handling for PLOGI ELS 
passthrough")
Cc: sta...@vger.kernel.org # 5.4
Link: https://lore.kernel.org/r/20191105150657.8092-2-hmadh...@marvell.com
Reviewed-by: Ewan D. Milne 
Signed-off-by: Quinn Tran 
Signed-off-by: Himanshu Madhani 
Signed-off-by: Martin K. Petersen 
Signed-off-by: Sasha Levin 
---
 drivers/scsi/qla2xxx/qla_init.c | 37 +++--
 drivers/scsi/qla2xxx/qla_iocb.c |  6 +-
 2 files changed, 13 insertions(+), 30 deletions(-)

diff --git a/drivers/scsi/qla2xxx/qla_init.c b/drivers/scsi/qla2xxx/qla_init.c
index 633317651138..5d2d0c287469 100644
--- a/drivers/scsi/qla2xxx/qla_init.c
+++ b/drivers/scsi/qla2xxx/qla_init.c
@@ -1911,42 +1911,21 @@ qla24xx_handle_prli_done_event(struct scsi_qla_host 
*vha, struct event_arg *ea)
 * FCP/NVMe port
 */
if (NVME_FCP_TARGET(ea->fcport)) {
-   if (vha->hw->fc4_type_priority == FC4_PRIORITY_NVME)
-   ea->fcport->fc4_type &= ~FS_FC4TYPE_NVME;
-   else
-   ea->fcport->fc4_type &= ~FS_FC4TYPE_FCP;
ql_dbg(ql_dbg_disc, vha, 0x2118,
"%s %d %8phC post %s prli\n",
__func__, __LINE__, ea->fcport->port_name,
(ea->fcport->fc4_type & FS_FC4TYPE_NVME) ?
"NVMe" : "FCP");
-   qla24xx_post_prli_work(vha, ea->fcport);
-   break;
+   if (vha->hw->fc4_type_priority == FC4_PRIORITY_NVME)
+   ea->fcport->fc4_type &= ~FS_FC4TYPE_NVME;
+   else
+   ea->fcport->fc4_type &= ~FS_FC4TYPE_FCP;
}
 
-   /* at this point both PRLI NVME & PRLI FCP failed */
-   if (N2N_TOPO(vha->hw)) {
-   if (ea->fcport->n2n_link_reset_cnt < 3) {
-   ea->fcport->n2n_link_reset_cnt++;
-   /*
-* remote port is not sending Plogi. Reset
-* link to kick start his state machine
-*/
-   set_bit(N2N_LINK_RESET, >dpc_flags);
-   } else {
-   ql_log(ql_log_warn, vha, 0x2119,
-   "%s %d %8phC Unable to reconnect\n",
-   __func__, __LINE__, ea->fcport->port_name);
-   }
-   } else {
-   /*
-* switch connect. login failed. Take connection
-* down and allow relogin to retrigger
-*/
-   ea->fcport->flags &= ~FCF_ASYNC_SENT;
-   ea->fcport->keep_nport_handle = 0;
-   qlt_schedule_sess_for_deletion(ea->fcport);
-   }
+   ea->fcport->flags &= ~FCF_ASYNC_SENT;
+   ea->fcport->keep_nport_handle = 0;
+   ea->fcport->logout_on_delete = 1;
+   qlt_schedule_sess_for_deletion(ea->fcport);
break;
}
 }
diff --git a/drivers/scsi/qla2xxx/qla_iocb.c b/drivers/scsi/qla2xxx/qla_iocb.c
index c0720c8e2f6d..53ccbd6b71ed 100644
--- a/drivers/scsi/qla2xxx/qla_iocb.c
+++ b/drivers/scsi/qla2xxx/qla_iocb.c
@@ -2772,6 +2772,7 @@ static void qla2x00_els_dcmd2_sp_done(srb_t *sp, int res)
ea.rc = res;
qla_handle_els_plogi_done(vha, );
break;
+
case CS_IOCB_ERROR:
switch (fw_status[1]) {
case LSC_SCODE_PORTID_USED:
@@ -2842,6 +2843,7 @@ static void qla2x00_els_dcmd2_sp_done(srb_t *sp, int res)
fw_status[0], fw_status[1], fw_status[2]);
 
fcport->flags &= ~FCF_ASYNC_SENT;
+   fcport->disc_state = DSC_LOGIN_FAILED;
set_bit(RELOGIN_NEEDED, >dpc_flags);
break;
}
@@ -2854,6 +2856,7 @@ static void qla2x00_els_dcmd2_sp_done(srb_t *sp, int res)
fw_status[0], fw_status[1], fw_status[2]);
 
sp->fcport->flags &= ~FCF_ASYNC_SENT;
+   sp->fcport->disc_state = 

[PATCH 5.4 04/73] scsi: qla2xxx: Fix device connect issues in P2P configuration

2021-04-19 Thread Greg Kroah-Hartman
From: Arun Easi 

[ Upstream commit 65e9200938052ce90f24421bb057e1be1d6147c7 ]

P2P needs to take the alternate plogi route.

Link: https://lore.kernel.org/r/20191105150657.8092-8-hmadh...@marvell.com
Reviewed-by: Ewan D. Milne 
Signed-off-by: Arun Easi 
Signed-off-by: Himanshu Madhani 
Signed-off-by: Martin K. Petersen 
Signed-off-by: Sasha Levin 
---
 drivers/scsi/qla2xxx/qla_gbl.h  | 1 +
 drivers/scsi/qla2xxx/qla_init.c | 9 +
 drivers/scsi/qla2xxx/qla_iocb.c | 5 ++---
 3 files changed, 12 insertions(+), 3 deletions(-)

diff --git a/drivers/scsi/qla2xxx/qla_gbl.h b/drivers/scsi/qla2xxx/qla_gbl.h
index d11416dcee4e..5b163ad85c34 100644
--- a/drivers/scsi/qla2xxx/qla_gbl.h
+++ b/drivers/scsi/qla2xxx/qla_gbl.h
@@ -917,4 +917,5 @@ int qla2x00_set_data_rate(scsi_qla_host_t *vha, uint16_t 
mode);
 
 /* nvme.c */
 void qla_nvme_unregister_remote_port(struct fc_port *fcport);
+void qla_handle_els_plogi_done(scsi_qla_host_t *vha, struct event_arg *ea);
 #endif /* _QLA_GBL_H */
diff --git a/drivers/scsi/qla2xxx/qla_init.c b/drivers/scsi/qla2xxx/qla_init.c
index bc7460da394f..633317651138 100644
--- a/drivers/scsi/qla2xxx/qla_init.c
+++ b/drivers/scsi/qla2xxx/qla_init.c
@@ -1738,6 +1738,15 @@ void qla24xx_handle_relogin_event(scsi_qla_host_t *vha,
qla24xx_fcport_handle_login(vha, fcport);
 }
 
+void qla_handle_els_plogi_done(scsi_qla_host_t *vha,
+ struct event_arg *ea)
+{
+   ql_dbg(ql_dbg_disc, vha, 0x2118,
+   "%s %d %8phC post PRLI\n",
+   __func__, __LINE__, ea->fcport->port_name);
+   qla24xx_post_prli_work(vha, ea->fcport);
+}
+
 /*
  * RSCN(s) came in for this fcport, but the RSCN(s) was not able
  * to be consumed by the fcport
diff --git a/drivers/scsi/qla2xxx/qla_iocb.c b/drivers/scsi/qla2xxx/qla_iocb.c
index 2e272fc858ed..c0720c8e2f6d 100644
--- a/drivers/scsi/qla2xxx/qla_iocb.c
+++ b/drivers/scsi/qla2xxx/qla_iocb.c
@@ -2769,9 +2769,8 @@ static void qla2x00_els_dcmd2_sp_done(srb_t *sp, int res)
case CS_COMPLETE:
memset(, 0, sizeof(ea));
ea.fcport = fcport;
-   ea.data[0] = MBS_COMMAND_COMPLETE;
-   ea.sp = sp;
-   qla24xx_handle_plogi_done_event(vha, );
+   ea.rc = res;
+   qla_handle_els_plogi_done(vha, );
break;
case CS_IOCB_ERROR:
switch (fw_status[1]) {
-- 
2.30.2





[PATCH 5.4 21/73] drm/msm: Fix a5xx/a6xx timestamps

2021-04-19 Thread Greg Kroah-Hartman
From: Rob Clark 

[ Upstream commit 9fbd3088351b92e8c2cef6e37a39decb12a8d5bb ]

They were reading a counter that was configured to ALWAYS_COUNT (ie.
cycles that the GPU is doing something) rather than ALWAYS_ON.  This
isn't the thing that userspace is looking for.

Signed-off-by: Rob Clark 
Acked-by: Jordan Crouse 
Message-Id: <20210325012358.1759770-2-robdcl...@gmail.com>
Signed-off-by: Rob Clark 
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 4 ++--
 drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c 
b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
index f84049119f1c..e3579e5ffa14 100644
--- a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
@@ -1131,8 +1131,8 @@ static int a5xx_pm_suspend(struct msm_gpu *gpu)
 
 static int a5xx_get_timestamp(struct msm_gpu *gpu, uint64_t *value)
 {
-   *value = gpu_read64(gpu, REG_A5XX_RBBM_PERFCTR_CP_0_LO,
-   REG_A5XX_RBBM_PERFCTR_CP_0_HI);
+   *value = gpu_read64(gpu, REG_A5XX_RBBM_ALWAYSON_COUNTER_LO,
+   REG_A5XX_RBBM_ALWAYSON_COUNTER_HI);
 
return 0;
 }
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c 
b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
index ab75f0309d4b..df2656e57991 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
@@ -773,8 +773,8 @@ static int a6xx_get_timestamp(struct msm_gpu *gpu, uint64_t 
*value)
/* Force the GPU power on so we can read this register */
a6xx_gmu_set_oob(_gpu->gmu, GMU_OOB_GPU_SET);
 
-   *value = gpu_read64(gpu, REG_A6XX_RBBM_PERFCTR_CP_0_LO,
-   REG_A6XX_RBBM_PERFCTR_CP_0_HI);
+   *value = gpu_read64(gpu, REG_A6XX_CP_ALWAYS_ON_COUNTER_LO,
+   REG_A6XX_CP_ALWAYS_ON_COUNTER_HI);
 
a6xx_gmu_clear_oob(_gpu->gmu, GMU_OOB_GPU_SET);
return 0;
-- 
2.30.2





  1   2   3   4   5   6   7   8   9   10   >