[PATCH 4.14 15/50] arch/arc: add copy_user_page() to to fix build error on ARC

From: Randy Dunlap [ Upstream commit 8a48c0a3360bf2bf4f40c980d0ec216e770e58ee ] fs/dax.c uses copy_user_page() but ARC does not provide that interface, resulting in a build error. Provide copy_user_page() in . ../fs/dax.c: In function 'copy_cow_page_dax': ../fs/dax.c:702:2: error: implicit

[PATCH 4.9 10/35] arch/arc: add copy_user_page() to to fix build error on ARC

From: Randy Dunlap [ Upstream commit 8a48c0a3360bf2bf4f40c980d0ec216e770e58ee ] fs/dax.c uses copy_user_page() but ARC does not provide that interface, resulting in a build error. Provide copy_user_page() in . ../fs/dax.c: In function 'copy_cow_page_dax': ../fs/dax.c:702:2: error: implicit

[PATCH 4.4 07/31] arch/arc: add copy_user_page() to to fix build error on ARC

From: Randy Dunlap [ Upstream commit 8a48c0a3360bf2bf4f40c980d0ec216e770e58ee ] fs/dax.c uses copy_user_page() but ARC does not provide that interface, resulting in a build error. Provide copy_user_page() in . ../fs/dax.c: In function 'copy_cow_page_dax': ../fs/dax.c:702:2: error: implicit

[PATCH 5.10 081/152] arch/arc: add copy_user_page() to to fix build error on ARC

From: Randy Dunlap [ Upstream commit 8a48c0a3360bf2bf4f40c980d0ec216e770e58ee ] fs/dax.c uses copy_user_page() but ARC does not provide that interface, resulting in a build error. Provide copy_user_page() in . ../fs/dax.c: In function 'copy_cow_page_dax': ../fs/dax.c:702:2: error: implicit

[PATCH 5.4 38/76] arch/arc: add copy_user_page() to to fix build error on ARC

From: Randy Dunlap [ Upstream commit 8a48c0a3360bf2bf4f40c980d0ec216e770e58ee ] fs/dax.c uses copy_user_page() but ARC does not provide that interface, resulting in a build error. Provide copy_user_page() in . ../fs/dax.c: In function 'copy_cow_page_dax': ../fs/dax.c:702:2: error: implicit

[PATCH 4.19 19/43] arch/arc: add copy_user_page() to to fix build error on ARC

From: Randy Dunlap [ Upstream commit 8a48c0a3360bf2bf4f40c980d0ec216e770e58ee ] fs/dax.c uses copy_user_page() but ARC does not provide that interface, resulting in a build error. Provide copy_user_page() in . ../fs/dax.c: In function 'copy_cow_page_dax': ../fs/dax.c:702:2: error: implicit

[PATCH 5.9 092/252] MIPS: export has_transparent_hugepage() for modules

From: Randy Dunlap [ Upstream commit 31b4d8e172f614adc53ddecb4b6b2f6411a49b84 ] MIPS should export its local version of "has_transparent_hugepage" so that loadable modules (dax) can use it. Fixes this build error: ERROR: modpost: "has_transparent_hugepage" [drivers/dax/dax.ko] undefined!

[PATCH 5.4 061/158] MIPS: export has_transparent_hugepage() for modules

From: Randy Dunlap [ Upstream commit 31b4d8e172f614adc53ddecb4b6b2f6411a49b84 ] MIPS should export its local version of "has_transparent_hugepage" so that loadable modules (dax) can use it. Fixes this build error: ERROR: modpost: "has_transparent_hugepage" [drivers/dax/dax.ko] undefined!

[PATCH 4.19 41/91] MIPS: export has_transparent_hugepage() for modules

From: Randy Dunlap [ Upstream commit 31b4d8e172f614adc53ddecb4b6b2f6411a49b84 ] MIPS should export its local version of "has_transparent_hugepage" so that loadable modules (dax) can use it. Fixes this build error: ERROR: modpost: "has_transparent_hugepage" [drivers/dax/dax.ko] undefined!

[PATCH 4.14 25/60] MIPS: export has_transparent_hugepage() for modules

From: Randy Dunlap [ Upstream commit 31b4d8e172f614adc53ddecb4b6b2f6411a49b84 ] MIPS should export its local version of "has_transparent_hugepage" so that loadable modules (dax) can use it. Fixes this build error: ERROR: modpost: "has_transparent_hugepage" [drivers/dax/dax.ko] undefined!

[PATCH 4.9 23/47] MIPS: export has_transparent_hugepage() for modules

From: Randy Dunlap [ Upstream commit 31b4d8e172f614adc53ddecb4b6b2f6411a49b84 ] MIPS should export its local version of "has_transparent_hugepage" so that loadable modules (dax) can use it. Fixes this build error: ERROR: modpost: "has_transparent_hugepage" [drivers/dax/dax.ko] undefined!

Re: [PATCH v2 3/7] mm/memory_hotplug: prepare passing flags to add_memory() and friends

On Tue, Sep 08, 2020 at 10:10:08PM +0200, David Hildenbrand wrote: > We soon want to pass flags, e.g., to mark added System RAM resources. > mergeable. Prepare for that. What are these random "flags", and how do we know what should be passed to them? Why not make this an enumerated type so that

Re: [PATCH v2 2/7] kernel/resource: move and rename IORESOURCE_MEM_DRIVER_MANAGED

; Cc: Jason Gunthorpe > Cc: Kees Cook > Cc: Ard Biesheuvel > Cc: Pankaj Gupta > Cc: Baoquan He > Cc: Wei Yang > Cc: Eric Biederman > Cc: Thomas Gleixner > Cc: Greg Kroah-Hartman > Cc: ke...@lists.infradead.org > Signed-off-by: David Hildenbrand > --- > in

Re: [PATCH v3 08/11] driver-core: Introduce DEVICE_ATTR_ADMIN_{RO,RW}

0400 or 0600 for permissions. > > Given the expectation that CAP_SYS_ADMIN is needed to access these > sensitive attributes add an explicit helper with the _ADMIN_ identifier > for DEVICE_ATTR_ADMIN_{RO,RW}. > > Reviewed-by: Greg Kroah-Hartman > Cc: "Rafael J. Wysocki" > Signe

Re: [PATCH v2 17/22] drivers/base: Make device_find_child_by_name() compatible with sysfs inputs

On Mon, Jul 13, 2020 at 09:09:18AM -0700, Dan Williams wrote: > On Mon, Jul 13, 2020 at 8:52 AM Greg Kroah-Hartman > wrote: > > > > On Mon, Jul 13, 2020 at 08:39:43AM -0700, Dan Williams wrote: > > > On Sun, Jul 12, 2020 at 10:09 AM Greg Kroah-Hartman > > > w

Re: [PATCH v2 17/22] drivers/base: Make device_find_child_by_name() compatible with sysfs inputs

On Mon, Jul 13, 2020 at 08:39:43AM -0700, Dan Williams wrote: > On Sun, Jul 12, 2020 at 10:09 AM Greg Kroah-Hartman > wrote: > > > > On Sun, Jul 12, 2020 at 09:27:37AM -0700, Dan Williams wrote: > > > Use sysfs_streq() in device_find_child_by_name() to allow it to use

Re: [PATCH v2 17/22] drivers/base: Make device_find_child_by_name() compatible with sysfs inputs

y_name(), already account for sysfs > strings. > > Cc: Greg Kroah-Hartman > Cc: "Rafael J. Wysocki" > Signed-off-by: Dan Williams > --- > drivers/base/core.c |2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/base/core.

Re: [PATCH 08/12] driver-core: Introduce DEVICE_ATTR_ADMIN_{RO,RW}

0400 or 0600 for permissions. > > Given the expectation that CAP_SYS_ADMIN is needed to access these > sensitive attributes and an explicit helper with the _ADMIN_ identifier > for DEVICE_ATTR_ADMIN_{RO,RW}. > > Cc: Greg Kroah-Hartman > Cc: "Rafael J. Wysocki" > Signed-off-by:

Re: [PATCH 7/9] drivers/base: fix empty-body warnings in devcoredump.c

On Sat, Apr 18, 2020 at 12:15:57PM -0700, Linus Torvalds wrote: > On Sat, Apr 18, 2020 at 11:57 AM Joe Perches wrote: > > > > sysfs_create_link is __must_check > > The way to handle __must_check if you really really don't want to test > and have good reasons is > > (a) add a big comment about

Re: [PATCH 7/9] drivers/base: fix empty-body warnings in devcoredump.c

On Sun, Apr 19, 2020 at 08:02:47AM +0200, Greg Kroah-Hartman wrote: > On Sat, Apr 18, 2020 at 11:41:09AM -0700, Randy Dunlap wrote: > > Fix gcc empty-body warning when -Wextra is used: > > > > ../drivers/base/devcoredump.c:297:42: warning: suggest braces a

Re: [PATCH 7/9] drivers/base: fix empty-body warnings in devcoredump.c

On Sat, Apr 18, 2020 at 11:41:09AM -0700, Randy Dunlap wrote: > Fix gcc empty-body warning when -Wextra is used: > > ../drivers/base/devcoredump.c:297:42: warning: suggest braces around empty > body in an ‘if’ statement [-Wempty-body] > ../drivers/base/devcoredump.c:301:42: warning: suggest

Re: [PATCH v3 25/27] powerpc/powernv/pmem: Expose the serial number in sysfs

On Fri, Feb 28, 2020 at 05:25:31PM +1100, Andrew Donnellan wrote: > On 21/2/20 2:27 pm, Alastair D'Silva wrote: > > +int ocxlpmem_sysfs_add(struct ocxlpmem *ocxlpmem) > > +{ > > + int i, rc; > > + > > + for (i = 0; i < ARRAY_SIZE(attrs); i++) { > > + rc = device_create_file(>dev,

Re: [PATCH v2 1/7] drivers/base: Introduce kill_device()

register() for > subsystems like libnvdimm that might need to handle multiple user > threads racing to delete a device. > > This refactoring does not change any behavior, but it is a pre-requisite > for follow-on fixes and therefore marked for -stable. > > Cc: Greg Kroah-Hartma

Re: [PATCH v2 7/7] driver-core, libnvdimm: Let device subsystems add local lockdep coverage

easier for you to debug." Sure, apeal to my vanity and quote me in the changelog, it's as if you are making it trivial for me to ack this... Acked-by: Greg Kroah-Hartman :) ___ Linux-nvdimm mailing list Linux-nvdimm@lists.01.org https://lists.01.org/mailman/listinfo/linux-nvdimm

Re: [PATCH 6/6] driver-core, libnvdimm: Let device subsystems add local lockdep coverage

On Wed, Jun 19, 2019 at 03:21:58PM -0700, Dan Williams wrote: > On Tue, Jun 11, 2019 at 4:40 PM Dan Williams wrote: > > > > For good reason, the standard device_lock() is marked > > lockdep_set_novalidate_class() because there is simply no sane way to > > describe the myriad ways the

Re: [PATCH v2 1/6] drivers/base/devres: Introduce devm_release_action()

> Introduce devm_release_action() so the release action can be triggered > via a new devm_memunmap_pages() api in a follow-on change. > > Cc: Logan Gunthorpe > Cc: Bjorn Helgaas > Cc: Christoph Hellwig > Cc: Greg Kroah-Hartman > Cc: "Rafael J. Wysocki" > Revi

[PATCH 5.0 057/246] mm/resource: Return real error codes from walk failures

5.0-stable review patch. If anyone has any objections, please let me know. -- [ Upstream commit 5cd401ace914dc68556c6d2fcae0c349444d5f86 ] walk_system_ram_range() can return an error code either becuase *it* failed, or because the 'func' that it calls returned an error. The

Re: [driver-core PATCH v9 1/9] driver core: Establish order of operations for device_add and device_del via bitflag

On Thu, Jan 10, 2019 at 09:37:32AM -0800, Alexander Duyck wrote: > On Thu, 2018-12-20 at 16:28 +0100, Greg Kroah-Hartman wrote: > > On Wed, Dec 19, 2018 at 03:27:48PM +0100, Rafael J. Wysocki wrote: > > > On Thu, Dec 13, 2018 at 1:45 AM Alexander Duyck > > >

Re: [driver-core PATCH v9 1/9] driver core: Establish order of operations for device_add and device_del via bitflag

On Wed, Dec 19, 2018 at 03:27:48PM +0100, Rafael J. Wysocki wrote: > On Thu, Dec 13, 2018 at 1:45 AM Alexander Duyck > wrote: > > > > Add an additional bit flag to the device struct named "dead". > > > > This additional flag provides a guarantee that when a device_del is > > executed on a given

[PATCH 4.18 073/171] acpi/nfit, x86/mce: Handle only uncorrectable machine checks

86-ml CC: Yazen Ghannam Link: http://lkml.kernel.org/r/20181026003729.8420-1-vishal.l.ve...@intel.com Signed-off-by: Greg Kroah-Hartman --- arch/x86/include/asm/mce.h |1 + arch/x86/kernel/cpu/mcheck/mce.c |3 ++- drivers/acpi/nfit/mce.c |4 ++-- 3 files changed

[PATCH 4.18 074/171] acpi/nfit, x86/mce: Validate a MCEs address before using it

9.8420-2-vishal.l.ve...@intel.com Signed-off-by: Greg Kroah-Hartman --- arch/x86/include/asm/mce.h |1 + arch/x86/kernel/cpu/mcheck/mce.c |3 ++- drivers/acpi/nfit/mce.c |4 3 files changed, 7 insertions(+), 1 deletion(-) --- a/arch/x86/include/asm/mce.h +++ b/arc

[PATCH 4.19 091/205] acpi/nfit, x86/mce: Validate a MCEs address before using it

9.8420-2-vishal.l.ve...@intel.com Signed-off-by: Greg Kroah-Hartman --- arch/x86/include/asm/mce.h |1 + arch/x86/kernel/cpu/mcheck/mce.c |3 ++- drivers/acpi/nfit/mce.c |4 3 files changed, 7 insertions(+), 1 deletion(-) --- a/arch/x86/include/asm/mce.h +++ b/arc

[PATCH 4.19 090/205] acpi/nfit, x86/mce: Handle only uncorrectable machine checks

86-ml CC: Yazen Ghannam Link: http://lkml.kernel.org/r/20181026003729.8420-1-vishal.l.ve...@intel.com Signed-off-by: Greg Kroah-Hartman --- arch/x86/include/asm/mce.h |1 + arch/x86/kernel/cpu/mcheck/mce.c |3 ++- drivers/acpi/nfit/mce.c |4 ++-- 3 files changed

Re: [PATCH v2 05/17] compat_ioctl: move more drivers to generic_compat_ioctl_ptrarg

uble-checked all these drivers to ensure that all ioctl arguments > are used as pointers or are ignored, but are not interpreted as integer > values. > > Signed-off-by: Arnd Bergmann Acked-by: Greg Kroah-Hartman ___ Linux-nvdimm mailing list

Re: [PATCH v3 01/16] chardev: add helper function to register char devs with a struct device

On Thu, Mar 16, 2017 at 11:38:40AM -0600, Logan Gunthorpe wrote: > > I don't know why kbuild didn't catch these before, but it looks like we > > really need to include device.h in cdev.h now to fix up these build > > warnings, right? > > > I'll try that out and rebase the char-misc-testing tree

Re: [PATCH v3 01/16] chardev: add helper function to register char devs with a struct device

On Mon, Mar 06, 2017 at 12:04:17AM -0700, Logan Gunthorpe wrote: > Credit for this patch goes is shared with Dan Williams [1]. I've > taken things one step further to make the helper function more > useful and clean up calling code. > > There's a common pattern in the kernel whereby a struct cdev

Re: [PATCH v3 16/16] switchtec: utilize new device_add_cdev helper function

On Mon, Mar 06, 2017 at 12:04:32AM -0700, Logan Gunthorpe wrote: > Very straightforward conversion to device_add_cdev. Drop cdev_add and > device_add and use cdev_device_add. > > Signed-off-by: Logan Gunthorpe > --- > drivers/pci/switch/switchtec.c | 11 ++- > 1

Re: [rtc-linux] [PATCH v3 05/16] gpiolib: utilize new cdev_device_add helper function

On Tue, Mar 14, 2017 at 04:28:28PM +0100, Linus Walleij wrote: > On Mon, Mar 6, 2017 at 8:04 AM, Logan Gunthorpe wrote: > > > Replace the open coded registration of the cdev and dev with the > > new device_add_cdev() helper. The helper replaces a common pattern by > > taking

Re: [PATCH v3 06/16] tpm-chip: utilize new cdev_device_add helper function

On Mon, Mar 06, 2017 at 11:04:26PM +0200, Jarkko Sakkinen wrote: > On Mon, Mar 06, 2017 at 12:04:22AM -0700, Logan Gunthorpe wrote: > > Replace the open coded registration of the cdev and dev with the > > new device_add_cdev() helper. The helper replaces a common pattern by > > taking the proper

Re: [PATCH v2 01/16] chardev: add helper function to register char devs with a struct device

On Mon, Feb 27, 2017 at 07:36:09PM -0800, Dan Williams wrote: > On Mon, Feb 27, 2017 at 7:27 PM, Logan Gunthorpe wrote: > > > > > > On 27/02/17 09:56 AM, Jason Gunthorpe wrote: > >> Yes please, that is way too subtle. Suggest: > >> > >> NOTE: Callers must assume that

Re: [4.4, 4.7 stable PATCH] acpi, nfit: check for the correct event code in notifications

On Mon, Oct 24, 2016 at 03:58:06PM -0600, Vishal Verma wrote: > commit c09f12186d6b03b798832d95289af76495990192 upstream. > > Commit 209851649dc4 "acpi: nfit: Add support for hot-add" added > support for _FIT notifications, but it neglected to verify the > notification event code matches the one

[PATCH 4.7 19/31] x86/boot: Fix kdump, cleanup aborted E820_PRAM max_pfn manipulation

693517367139607.st...@dwillia2-desk3.amr.corp.intel.com Signed-off-by: Ingo Molnar <mi...@kernel.org> Signed-off-by: Greg Kroah-Hartman <gre...@linuxfoundation.org> --- arch/x86/kernel/e820.c | 14 +- 1 file changed, 5 insertions(+), 9 deletions(-)

[PATCH 4.4 13/21] x86/boot: Fix kdump, cleanup aborted E820_PRAM max_pfn manipulation

693517367139607.st...@dwillia2-desk3.amr.corp.intel.com Signed-off-by: Ingo Molnar <mi...@kernel.org> Signed-off-by: Greg Kroah-Hartman <gre...@linuxfoundation.org> --- arch/x86/kernel/e820.c | 14 +- 1 file changed, 5 insertions(+), 9 deletions(-)