[PATCH v2] x86/uapi: fix asm/signal.h userspace compilation error

Replace size_t to fix the following asm/signal.h userspace compilation error: /usr/include/asm/signal.h:126:2: error: unknown type name 'size_t' size_t ss_size; size_t is replaced with __kernel_size_t in all cases except x32 where unsigned int has to be used instead. Signed-off-by: Dmitry V.

[PATCH v2] x86/uapi: fix asm/signal.h userspace compilation error

Replace size_t to fix the following asm/signal.h userspace compilation error: /usr/include/asm/signal.h:126:2: error: unknown type name 'size_t' size_t ss_size; size_t is replaced with __kernel_size_t in all cases except x32 where unsigned int has to be used instead. Signed-off-by: Dmitry V.

[PATCH v3 2/2] crypto: vmx - Use skcipher for xts fallback

Signed-off-by: Paulo Flabiano Smorigo --- drivers/crypto/vmx/aes_xts.c | 32 1 file changed, 16 insertions(+), 16 deletions(-) diff --git a/drivers/crypto/vmx/aes_xts.c b/drivers/crypto/vmx/aes_xts.c index 24353ec3..6adc929 100644

[PATCH v3 2/2] crypto: vmx - Use skcipher for xts fallback

Signed-off-by: Paulo Flabiano Smorigo --- drivers/crypto/vmx/aes_xts.c | 32 1 file changed, 16 insertions(+), 16 deletions(-) diff --git a/drivers/crypto/vmx/aes_xts.c b/drivers/crypto/vmx/aes_xts.c index 24353ec3..6adc929 100644 ---

Re: [PATCH v2] blkcg: allocate struct blkcg_gq outside request queue spinlock

Hi Tejun, > > Ah, indeed, but we can break out allocation of blkg and its > initialization, right? It's a bit more work but then we'd be able to > do something like. > > > retry: > new_blkg = alloc; > lock; > sanity checks; > blkg = blkg_lookup_and_create(...,

Re: [PATCH v2] blkcg: allocate struct blkcg_gq outside request queue spinlock

Hi Tejun, > > Ah, indeed, but we can break out allocation of blkg and its > initialization, right? It's a bit more work but then we'd be able to > do something like. > > > retry: > new_blkg = alloc; > lock; > sanity checks; > blkg = blkg_lookup_and_create(...,

[PATCHv2 14/14] treewide: Decouple cacheflush.h and set_memory.h

Now that all call sites, completely decouple cacheflush.h and set_memory.h Signed-off-by: Laura Abbott --- arch/arm/include/asm/cacheflush.h | 1 - arch/arm64/include/asm/cacheflush.h | 1 - arch/s390/include/asm/Kbuild| 1 + arch/s390/include/asm/cacheflush.h |

[PATCHv2 13/14] ALSA: hda: Use set_memory.h header

set_memory_* functions have moved to set_memory.h. Switch to this explicitly. Signed-off-by: Laura Abbott --- sound/pci/hda/hda_intel.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c index

[PATCHv2 14/14] treewide: Decouple cacheflush.h and set_memory.h

Now that all call sites, completely decouple cacheflush.h and set_memory.h Signed-off-by: Laura Abbott --- arch/arm/include/asm/cacheflush.h | 1 - arch/arm64/include/asm/cacheflush.h | 1 - arch/s390/include/asm/Kbuild| 1 + arch/s390/include/asm/cacheflush.h | 8

[PATCHv2 13/14] ALSA: hda: Use set_memory.h header

set_memory_* functions have moved to set_memory.h. Switch to this explicitly. Signed-off-by: Laura Abbott --- sound/pci/hda/hda_intel.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c index 16108f0e..e3d8756 100644 ---

[PATCH] [media] ad5820: remove incorrect __exit markups

Even if bus is not hot-pluggable, devices can be unbound from the driver via sysfs, so we should not be using __exit annotations on remove() methods. The only exception is drivers registered with platform_driver_probe() which specifically disables sysfs bind/unbind attributes. Signed-off-by:

[PATCH] [media] ad5820: remove incorrect __exit markups

Even if bus is not hot-pluggable, devices can be unbound from the driver via sysfs, so we should not be using __exit annotations on remove() methods. The only exception is drivers registered with platform_driver_probe() which specifically disables sysfs bind/unbind attributes. Signed-off-by:

[PATCH] video: fbdev: pmag-aa-fb: remove incorrect __exit markups

Even if bus is not hot-pluggable, devices can be unbound from the driver via sysfs, so we should not be using __exit annotations on remove() methods. The only exception is drivers registered with platform_driver_probe() which specifically disables sysfs bind/unbind attributes. Signed-off-by:

[PATCH] video: fbdev: pmag-aa-fb: remove incorrect __exit markups

Even if bus is not hot-pluggable, devices can be unbound from the driver via sysfs, so we should not be using __exit annotations on remove() methods. The only exception is drivers registered with platform_driver_probe() which specifically disables sysfs bind/unbind attributes. Signed-off-by:

[PATCH 03/20] asm-generic: Drop getrlimit and setrlimit syscalls from default list

The newer prlimit64 syscall provides all the functionality provided by the getrlimit and setrlimit syscalls and adds the pid of target process, so future architectures won't need to include getrlimit and setrlimit. Therefore drop getrlimit and setrlimit syscalls from the generic syscall list

[PATCH 03/20] asm-generic: Drop getrlimit and setrlimit syscalls from default list

The newer prlimit64 syscall provides all the functionality provided by the getrlimit and setrlimit syscalls and adds the pid of target process, so future architectures won't need to include getrlimit and setrlimit. Therefore drop getrlimit and setrlimit syscalls from the generic syscall list

Re: [tpmdd-devel] [PATCH] tpm: do not suspend/resume if power stays on

On Wed, Mar 1, 2017 at 3:18 PM, Jason Gunthorpe wrote: > On Wed, Mar 01, 2017 at 02:39:09PM -0800, Sonny Rao wrote: > >> > We recently added global suspend/resume callbacks to the TPM >> > core. Those call backs do not power off the TPM, they just prepare its >> >

Re: [tpmdd-devel] [PATCH] tpm: do not suspend/resume if power stays on

On Wed, Mar 1, 2017 at 3:18 PM, Jason Gunthorpe wrote: > On Wed, Mar 01, 2017 at 02:39:09PM -0800, Sonny Rao wrote: > >> > We recently added global suspend/resume callbacks to the TPM >> > core. Those call backs do not power off the TPM, they just prepare its >> > internal state to loose power to

[PATCH 19/20] arm64:ilp32: add vdso-ilp32 and use for signal return

From: Philipp Tomsich ILP32 VDSO exports next symbols: __kernel_rt_sigreturn; __kernel_gettimeofday; __kernel_clock_gettime; __kernel_clock_getres. What shared object to use, kernel selects depending on result of is_ilp32_compat_task() in

[PATCH 19/20] arm64:ilp32: add vdso-ilp32 and use for signal return

From: Philipp Tomsich ILP32 VDSO exports next symbols: __kernel_rt_sigreturn; __kernel_gettimeofday; __kernel_clock_gettime; __kernel_clock_getres. What shared object to use, kernel selects depending on result of is_ilp32_compat_task() in arch/arm64/kernel/vdso.c, so it substitutes correct

[PATCH] rtc: omap: mark PM methods as __maybe_unused

Instead of using #ifdef guards around PM methods, let's annotate them as __maybe_unused, as it provides better compile coverage. Also drop empty stub for omap_rtc_runtime_resume(). Signed-off-by: Dmitry Torokhov --- drivers/rtc/rtc-omap.c | 18 -- 1

[PATCH] rtc: omap: mark PM methods as __maybe_unused

Instead of using #ifdef guards around PM methods, let's annotate them as __maybe_unused, as it provides better compile coverage. Also drop empty stub for omap_rtc_runtime_resume(). Signed-off-by: Dmitry Torokhov --- drivers/rtc/rtc-omap.c | 18 -- 1 file changed, 4

Re: [PATCH 24/44] x86: intel-family.h: Add GEMINI_LAKE SOC

On Wed, Mar 1, 2017 at 7:27 AM, Len Brown wrote: > From: Len Brown > --- a/arch/x86/include/asm/intel-family.h > +++ b/arch/x86/include/asm/intel-family.h > @@ -59,6 +59,7 @@ > #define INTEL_FAM6_ATOM_MERRIFIELD 0x4A /* Tangier */ > #define

Re: [PATCH 24/44] x86: intel-family.h: Add GEMINI_LAKE SOC

On Wed, Mar 1, 2017 at 7:27 AM, Len Brown wrote: > From: Len Brown > --- a/arch/x86/include/asm/intel-family.h > +++ b/arch/x86/include/asm/intel-family.h > @@ -59,6 +59,7 @@ > #define INTEL_FAM6_ATOM_MERRIFIELD 0x4A /* Tangier */ > #define INTEL_FAM6_ATOM_MOOREFIELD 0x5A /* Anniedale

[PATCH] iio: magnetometer: ak8974: remove incorrect __exit markups

Even if bus is not hot-pluggable, devices can be unbound from the driver via sysfs, so we should not be using __exit annotations on remove() methods. The only exception is drivers registered with platform_driver_probe() which specifically disables sysfs bind/unbind attributes. Signed-off-by:

[PATCH] iio: magnetometer: ak8974: remove incorrect __exit markups

Even if bus is not hot-pluggable, devices can be unbound from the driver via sysfs, so we should not be using __exit annotations on remove() methods. The only exception is drivers registered with platform_driver_probe() which specifically disables sysfs bind/unbind attributes. Signed-off-by:

[PATCH cgroup/for-4.10-fixes] cgroup/pids: remove spurious suspicious RCU usage warning

pids_can_fork() is special in that the css association is guaranteed to be stable throughout the function and thus doesn't need RCU protection around task_css access. When determining the css to charge the pid, task_css_check() is used to override the RCU sanity check. While adding a warning

[PATCH cgroup/for-4.10-fixes] cgroup/pids: remove spurious suspicious RCU usage warning

pids_can_fork() is special in that the css association is guaranteed to be stable throughout the function and thus doesn't need RCU protection around task_css access. When determining the css to charge the pid, task_css_check() is used to override the RCU sanity check. While adding a warning

[PATCH] power: supply: twl4030_charger: remove incorrect __exit markups

Even if bus is not hot-pluggable, the devices can be unbound from the driver via sysfs, so we should not be using __exit annotations on remove() methods. The only exception is drivers registered with platform_driver_probe() which specifically disables sysfs bind/unbind attributes. Signed-off-by:

Re: e1000_netpoll() , BUG: sleeping function called from invalid context

On 01.03.2017 23:38, Thomas Gleixner wrote: On Wed, 1 Mar 2017, Gabriel C wrote: On 01.03.2017 18:13, Thomas Gleixner wrote: On Sat, 18 Feb 2017, Gabriel C wrote: That got changed in commit 3111912971251 which got into Linus tree during the 4.10 merge window. So it is in 4.10-rc8.

[PATCH] power: supply: twl4030_charger: remove incorrect __exit markups

Even if bus is not hot-pluggable, the devices can be unbound from the driver via sysfs, so we should not be using __exit annotations on remove() methods. The only exception is drivers registered with platform_driver_probe() which specifically disables sysfs bind/unbind attributes. Signed-off-by:

Re: e1000_netpoll() , BUG: sleeping function called from invalid context

On 01.03.2017 23:38, Thomas Gleixner wrote: On Wed, 1 Mar 2017, Gabriel C wrote: On 01.03.2017 18:13, Thomas Gleixner wrote: On Sat, 18 Feb 2017, Gabriel C wrote: That got changed in commit 3111912971251 which got into Linus tree during the 4.10 merge window. So it is in 4.10-rc8.

Re: [PATCH v2 0/2] fujitsu-laptop: acpi_fujitsu_bl_notify() cleanup

On Wed, Mar 01, 2017 at 07:42:52AM +0100, Micha?? K??pie?? wrote: > Here are two minor cleanups for acpi_fujitsu_bl_notify() that I came up > with while preparing the sparse keymap migration. These both look innoculous at first glance. I will review them and test on hardware within the next 48

Re: [PATCH v2 0/2] fujitsu-laptop: acpi_fujitsu_bl_notify() cleanup

On Wed, Mar 01, 2017 at 07:42:52AM +0100, Micha?? K??pie?? wrote: > Here are two minor cleanups for acpi_fujitsu_bl_notify() that I came up > with while preparing the sparse keymap migration. These both look innoculous at first glance. I will review them and test on hardware within the next 48

Re: [PATCH] mmc: core: Fix access to HS400-ES devices

Hi, On Wed, Mar 1, 2017 at 2:11 PM, Guenter Roeck wrote: > HS400-ES devices fail to initialize with the following error messages. > > mmc1: power class selection to bus width 8 ddr 0 failed > mmc1: error -110 whilst initialising MMC card > > This was seen on Samsung

Re: [PATCH] mmc: core: Fix access to HS400-ES devices

Hi, On Wed, Mar 1, 2017 at 2:11 PM, Guenter Roeck wrote: > HS400-ES devices fail to initialize with the following error messages. > > mmc1: power class selection to bus width 8 ddr 0 failed > mmc1: error -110 whilst initialising MMC card > > This was seen on Samsung Chromebook Plus. Code

[PATCH] rtc: omap: remove incorrect __exit markups

Even if bus is not hot-pluggable, devices can be unbound from the driver via sysfs, so we should not be using __exit annotations on remove() methods. The only exception is drivers registered with platform_driver_probe(), which specifically disables sysfs bind/unbind attributes. Signed-off-by:

[PATCH] rtc: omap: remove incorrect __exit markups

Even if bus is not hot-pluggable, devices can be unbound from the driver via sysfs, so we should not be using __exit annotations on remove() methods. The only exception is drivers registered with platform_driver_probe(), which specifically disables sysfs bind/unbind attributes. Signed-off-by:

Re: [RFC PATCH 2/2] kprobes/x86: Exit single-stepping before trying fixup_exception

On Tue, 28 Feb 2017 01:14:38 +0900 Masami Hiramatsu wrote: > Exit single-stepping out of line and get back regs->ip to original > (probed) address before trying fixup_exception() if the exception > happened on the singlestep buffer, since the fixup_exception() > depends on

Re: [RFC PATCH 2/2] kprobes/x86: Exit single-stepping before trying fixup_exception

On Tue, 28 Feb 2017 01:14:38 +0900 Masami Hiramatsu wrote: > Exit single-stepping out of line and get back regs->ip to original > (probed) address before trying fixup_exception() if the exception > happened on the singlestep buffer, since the fixup_exception() > depends on regs->ip to search an

Re: [PATCH v5 06/10] seccomp,landlock: Handle Landlock events per process hierarchy

On 01/03/2017 23:20, Andy Lutomirski wrote: > On Wed, Mar 1, 2017 at 2:14 PM, Mickaël Salaün wrote: >> >> On 28/02/2017 21:01, Andy Lutomirski wrote: >>> On Tue, Feb 21, 2017 at 5:26 PM, Mickaël Salaün wrote: The seccomp(2) syscall can be use to apply a

Re: [PATCH v5 06/10] seccomp,landlock: Handle Landlock events per process hierarchy

On 01/03/2017 23:20, Andy Lutomirski wrote: > On Wed, Mar 1, 2017 at 2:14 PM, Mickaël Salaün wrote: >> >> On 28/02/2017 21:01, Andy Lutomirski wrote: >>> On Tue, Feb 21, 2017 at 5:26 PM, Mickaël Salaün wrote: The seccomp(2) syscall can be use to apply a Landlock rule to the current

Re: [PATCH v2] ARM: OMAP2+: Fix device node reference counts

* Guenter Roeck [170301 12:16]: > On Wed, Mar 01, 2017 at 10:04:39AM -0800, Tony Lindgren wrote: > > * Guenter Roeck [170228 11:55]: > > > After commit 'of: fix of_node leak caused in of_find_node_opts_by_path', > > > the following error may be reported

Re: [PATCH v2] ARM: OMAP2+: Fix device node reference counts

* Guenter Roeck [170301 12:16]: > On Wed, Mar 01, 2017 at 10:04:39AM -0800, Tony Lindgren wrote: > > * Guenter Roeck [170228 11:55]: > > > After commit 'of: fix of_node leak caused in of_find_node_opts_by_path', > > > the following error may be reported when running omap images. > > > > > > OF:

Re: [PATCH v5 06/10] seccomp,landlock: Handle Landlock events per process hierarchy

On Wed, Mar 1, 2017 at 2:14 PM, Mickaël Salaün wrote: > > On 28/02/2017 21:01, Andy Lutomirski wrote: >> On Tue, Feb 21, 2017 at 5:26 PM, Mickaël Salaün wrote: >>> The seccomp(2) syscall can be use to apply a Landlock rule to the >>> current process. As with a

Re: [PATCH v5 06/10] seccomp,landlock: Handle Landlock events per process hierarchy

On Wed, Mar 1, 2017 at 2:14 PM, Mickaël Salaün wrote: > > On 28/02/2017 21:01, Andy Lutomirski wrote: >> On Tue, Feb 21, 2017 at 5:26 PM, Mickaël Salaün wrote: >>> The seccomp(2) syscall can be use to apply a Landlock rule to the >>> current process. As with a seccomp filter, the Landlock rule

Re: [PATCH v5 0/4] iio: accel: adxl345: Split driver into core and I2C then add SPI support

On Tue, Feb 28, 2017 at 4:37 AM, Eva Rachel Retuya wrote: > This patchset modifies the adxl345 to use regmap. In doing so, we can > easily introduce SPI support and let regmap handle the rest. > > Recap of basic features: read_raw for x, y and z axes, scale. After > applying

Re: [PATCH v5 0/4] iio: accel: adxl345: Split driver into core and I2C then add SPI support

On Tue, Feb 28, 2017 at 4:37 AM, Eva Rachel Retuya wrote: > This patchset modifies the adxl345 to use regmap. In doing so, we can > easily introduce SPI support and let regmap handle the rest. > > Recap of basic features: read_raw for x, y and z axes, scale. After > applying this series, driver

Re: [PATCH v2 2/3] clk: meson-gxbb: Add MALI clocks

On 03/01, Neil Armstrong wrote: > diff --git a/drivers/clk/meson/gxbb.c b/drivers/clk/meson/gxbb.c > index a52063f..31f6090 100644 > --- a/drivers/clk/meson/gxbb.c > +++ b/drivers/clk/meson/gxbb.c > @@ -634,6 +634,131 @@ > }, > }; > > +/* > + * The MALI IP is clocked by two identical

Re: [PATCH v2 2/3] clk: meson-gxbb: Add MALI clocks

On 03/01, Neil Armstrong wrote: > diff --git a/drivers/clk/meson/gxbb.c b/drivers/clk/meson/gxbb.c > index a52063f..31f6090 100644 > --- a/drivers/clk/meson/gxbb.c > +++ b/drivers/clk/meson/gxbb.c > @@ -634,6 +634,131 @@ > }, > }; > > +/* > + * The MALI IP is clocked by two identical

Re: net: use-after-free in neigh_timer_handler/sock_wfree

On Wed, Mar 1, 2017 at 3:09 PM, Cong Wang wrote: > > But I doubt skb_orphan() is the solution here, shouldn't we just > update sk->sk_wmem_alloc with skb->truesize changes? Is it worth it ? Apart from syszkaller I mean... We started with something that had a real

Re: net: use-after-free in neigh_timer_handler/sock_wfree

On Wed, Mar 1, 2017 at 3:09 PM, Cong Wang wrote: > > But I doubt skb_orphan() is the solution here, shouldn't we just > update sk->sk_wmem_alloc with skb->truesize changes? Is it worth it ? Apart from syszkaller I mean... We started with something that had a real impact on real workloads.

Re: [PATCH 1/2] dt-bindings: qoriq-clock: Add coreclk

On Tue, Feb 28, 2017 at 7:45 PM, Y.T. Tang wrote: > Hi Rob, > >> -Original Message- >> From: Rob Herring [mailto:r...@kernel.org] >> Sent: Tuesday, February 28, 2017 1:19 AM >> To: Y.T. Tang >> Cc: mturque...@baylibre.com;

Re: [PATCH 1/2] dt-bindings: qoriq-clock: Add coreclk

On Tue, Feb 28, 2017 at 7:45 PM, Y.T. Tang wrote: > Hi Rob, > >> -Original Message- >> From: Rob Herring [mailto:r...@kernel.org] >> Sent: Tuesday, February 28, 2017 1:19 AM >> To: Y.T. Tang >> Cc: mturque...@baylibre.com; sb...@codeaurora.org; >> mark.rutl...@arm.com;

Re: [PATCH v4] platform/x86: ideapad-laptop: Add sysfs interface for touchpad state

On Wed, Feb 22, 2017 at 12:24 PM, Ritesh Raj Sarraf wrote: > Any further comment on this patch ? Will this be accepted ? > Please give a N/ACK. First of all, please do not top post. > On Sat, 2017-02-18 at 00:17 +0530, Ritesh Raj Sarraf wrote: >> Lenovo Yoga (many variants:

Re: [PATCH v4] platform/x86: ideapad-laptop: Add sysfs interface for touchpad state

On Wed, Feb 22, 2017 at 12:24 PM, Ritesh Raj Sarraf wrote: > Any further comment on this patch ? Will this be accepted ? > Please give a N/ACK. First of all, please do not top post. > On Sat, 2017-02-18 at 00:17 +0530, Ritesh Raj Sarraf wrote: >> Lenovo Yoga (many variants: Yoga, Yoga2 Pro,

Re: [PATCH V3 2/7] PM / OPP: Introduce "domain-performance-state" binding to OPP nodes

On Wed, Mar 1, 2017 at 12:27 AM, Rajendra Nayak wrote: > > > On 02/28/2017 09:22 PM, Rob Herring wrote: >> On Tue, Feb 28, 2017 at 9:14 AM, Ulf Hansson wrote: >>> [...] >>> > ---> Parent domain-2 (Contains

Re: [PATCH V3 2/7] PM / OPP: Introduce "domain-performance-state" binding to OPP nodes

On Wed, Mar 1, 2017 at 12:27 AM, Rajendra Nayak wrote: > > > On 02/28/2017 09:22 PM, Rob Herring wrote: >> On Tue, Feb 28, 2017 at 9:14 AM, Ulf Hansson wrote: >>> [...] >>> > ---> Parent domain-2 (Contains > Perfomance states) >

Re: fs: use-after-free in userfaultfd_exit

On Wed, Mar 01, 2017 at 07:48:00PM +0100, Dmitry Vyukov wrote: > Hello, > > I've got the following use-after-free report while running syzkaller > fuzzer on 86292b33d4b79ee03e2f43ea0381ef85f077c760: Yes, I posted the fix for this one last Friday, I found it during stress testing, it triggered

Re: fs: use-after-free in userfaultfd_exit

On Wed, Mar 01, 2017 at 07:48:00PM +0100, Dmitry Vyukov wrote: > Hello, > > I've got the following use-after-free report while running syzkaller > fuzzer on 86292b33d4b79ee03e2f43ea0381ef85f077c760: Yes, I posted the fix for this one last Friday, I found it during stress testing, it triggered

Re: [PATCH v5 0/4] New Microsemi PCI Switch Management Driver

On 01/03/17 03:59 PM, Keith Busch wrote: > Okay, I see. Was mistakenliy looking at v4. The v5 looks right. Great! Thanks for reviewing that for me. Logan

Re: [PATCH v5 0/4] New Microsemi PCI Switch Management Driver

On 01/03/17 03:59 PM, Keith Busch wrote: > Okay, I see. Was mistakenliy looking at v4. The v5 looks right. Great! Thanks for reviewing that for me. Logan

Re: [PATCH 15/19] kernel: convert audit_tree.count from atomic_t to refcount_t

On Wed, Mar 1, 2017 at 11:35 AM, Paul Moore wrote: > On Tue, Feb 28, 2017 at 7:16 PM, Kees Cook wrote: >> On Tue, Feb 28, 2017 at 2:11 PM, Paul Moore wrote: >>> I just realized that include/linux/refcount.h didn't make it into >>>

Re: [PATCH 15/19] kernel: convert audit_tree.count from atomic_t to refcount_t

On Wed, Mar 1, 2017 at 11:35 AM, Paul Moore wrote: > On Tue, Feb 28, 2017 at 7:16 PM, Kees Cook wrote: >> On Tue, Feb 28, 2017 at 2:11 PM, Paul Moore wrote: >>> I just realized that include/linux/refcount.h didn't make it into >>> v4.10 which means there is going to be delay until I merge them

[PATCH] ARM: dts: NSP: GPIO reboot open-source

The libgpio code pre-sets the GPIO values for the gpio-reset in the device tree. This results in the device being reset during bringup. To prevent this pre-setting, use the "open-source" flag in the device tree. Signed-off-by: Jon Mason Fixes: b1aaf88 ("ARM: dts: NSP:

Re: [PATCH v5 0/4] New Microsemi PCI Switch Management Driver

On 01/03/17 03:26 PM, Keith Busch wrote: > I think this is from using the managed device resource API to request the > irq actions. The scope of the resource used to be tied to the pci_dev's > dev, but now it's the new switchec class dev, which has a different > lifetime while open references

[PATCH] ARM: dts: NSP: GPIO reboot open-source

The libgpio code pre-sets the GPIO values for the gpio-reset in the device tree. This results in the device being reset during bringup. To prevent this pre-setting, use the "open-source" flag in the device tree. Signed-off-by: Jon Mason Fixes: b1aaf88 ("ARM: dts: NSP: Add GPIO reboot method to

Re: [PATCH v5 0/4] New Microsemi PCI Switch Management Driver

On 01/03/17 03:26 PM, Keith Busch wrote: > I think this is from using the managed device resource API to request the > irq actions. The scope of the resource used to be tied to the pci_dev's > dev, but now it's the new switchec class dev, which has a different > lifetime while open references

Re: net: use-after-free in neigh_timer_handler/sock_wfree

On Wed, Mar 1, 2017 at 1:54 PM, Eric Dumazet wrote: > On Wed, Mar 1, 2017 at 1:43 PM, Cong Wang wrote: >>> >>> This one looks very similar to a previous one: >>> https://groups.google.com/forum/#!topic/syzkaller/BhyN5OFd7sQ >>> >>> Both happen on

Re: net: use-after-free in neigh_timer_handler/sock_wfree

On Wed, Mar 1, 2017 at 1:54 PM, Eric Dumazet wrote: > On Wed, Mar 1, 2017 at 1:43 PM, Cong Wang wrote: >>> >>> This one looks very similar to a previous one: >>> https://groups.google.com/forum/#!topic/syzkaller/BhyN5OFd7sQ >>> >>> Both happen on raw v6 sockets. >>> >>> For me, it seems the sk

[PATCH] mmc: core: Fix access to HS400-ES devices

HS400-ES devices fail to initialize with the following error messages. mmc1: power class selection to bus width 8 ddr 0 failed mmc1: error -110 whilst initialising MMC card This was seen on Samsung Chromebook Plus. Code analysis points to commit 3d4ef329757c ("mmc: core: fix multi-bit bus width

[PATCH] mmc: core: Fix access to HS400-ES devices

HS400-ES devices fail to initialize with the following error messages. mmc1: power class selection to bus width 8 ddr 0 failed mmc1: error -110 whilst initialising MMC card This was seen on Samsung Chromebook Plus. Code analysis points to commit 3d4ef329757c ("mmc: core: fix multi-bit bus width

Re: selftests broke upstream

On 03/01/2017 07:29 AM, Shuah Khan wrote: > On 03/01/2017 02:24 AM, Ingo Molnar wrote: >> >> Hi, >> >> The x86 selftests build broke upstream: >> >> triton:~/tip/tools/testing/selftests/x86> make >> Makefile:44: warning: overriding recipe for target 'clean' > > This is odd. It should work. Are

Re: selftests broke upstream

On 03/01/2017 07:29 AM, Shuah Khan wrote: > On 03/01/2017 02:24 AM, Ingo Molnar wrote: >> >> Hi, >> >> The x86 selftests build broke upstream: >> >> triton:~/tip/tools/testing/selftests/x86> make >> Makefile:44: warning: overriding recipe for target 'clean' > > This is odd. It should work. Are

Re: net: use-after-free in neigh_timer_handler/sock_wfree

On Wed, Mar 1, 2017 at 1:43 PM, Cong Wang wrote: >> >> This one looks very similar to a previous one: >> https://groups.google.com/forum/#!topic/syzkaller/BhyN5OFd7sQ >> >> Both happen on raw v6 sockets. >> >> For me, it seems the sk refcnt is not correct, skb should

Re: net: use-after-free in neigh_timer_handler/sock_wfree

On Wed, Mar 1, 2017 at 1:43 PM, Cong Wang wrote: >> >> This one looks very similar to a previous one: >> https://groups.google.com/forum/#!topic/syzkaller/BhyN5OFd7sQ >> >> Both happen on raw v6 sockets. >> >> For me, it seems the sk refcnt is not correct, skb should still hold >> a refcnt so it

Re: [PATCH 4/4] arm: dts: rockchip: Enable post_ios_power_on and pre-power-on-delay-ms

Hi Romain, Am Mittwoch, 1. März 2017, 15:53:10 CET schrieb Romain Perier: > This enables the property post_ios_power_on. With this property, the > driver pwrseq_simple will do its entire power sequence at the end of the > mmc_power_up() function. The property pre-power-on-delay-ms adds a delay >

Re: [PATCH 4/4] arm: dts: rockchip: Enable post_ios_power_on and pre-power-on-delay-ms

Hi Romain, Am Mittwoch, 1. März 2017, 15:53:10 CET schrieb Romain Perier: > This enables the property post_ios_power_on. With this property, the > driver pwrseq_simple will do its entire power sequence at the end of the > mmc_power_up() function. The property pre-power-on-delay-ms adds a delay >

[PATCH] Bluetooth: btqcomsmd: fix compile-test dependency

compile-testing fails when QCOM_SMD is a loadable module: drivers/bluetooth/built-in.o: In function `btqcomsmd_send': btqca.c:(.text+0xa8): undefined reference to `qcom_smd_send' drivers/bluetooth/built-in.o: In function `btqcomsmd_probe': btqca.c:(.text+0x3ec): undefined reference to

[PATCH 1/2] staging/vc04_services: initialize cache line size properly

While debugging another problem I noticed that g_cache_line_size gets set to sizeof(CACHE_LINE_SIZE), which is sizeof(int) or 4, while presumably CACHE_LINE_SIZE (e.g. 32) was meant. This initializes it the way it was meant. Signed-off-by: Arnd Bergmann ---

[PATCH] Bluetooth: btqcomsmd: fix compile-test dependency

compile-testing fails when QCOM_SMD is a loadable module: drivers/bluetooth/built-in.o: In function `btqcomsmd_send': btqca.c:(.text+0xa8): undefined reference to `qcom_smd_send' drivers/bluetooth/built-in.o: In function `btqcomsmd_probe': btqca.c:(.text+0x3ec): undefined reference to

[PATCH 1/2] staging/vc04_services: initialize cache line size properly

While debugging another problem I noticed that g_cache_line_size gets set to sizeof(CACHE_LINE_SIZE), which is sizeof(int) or 4, while presumably CACHE_LINE_SIZE (e.g. 32) was meant. This initializes it the way it was meant. Signed-off-by: Arnd Bergmann ---

Re: [PATCH v5 0/4] New Microsemi PCI Switch Management Driver

On Wed, Mar 01, 2017 at 03:37:03PM -0700, Logan Gunthorpe wrote: > On 01/03/17 03:26 PM, Keith Busch wrote: > > I think this is from using the managed device resource API to request the > > irq actions. The scope of the resource used to be tied to the pci_dev's > > dev, but now it's the new

Re: [PATCH v5 0/4] New Microsemi PCI Switch Management Driver

On Wed, Mar 01, 2017 at 03:37:03PM -0700, Logan Gunthorpe wrote: > On 01/03/17 03:26 PM, Keith Busch wrote: > > I think this is from using the managed device resource API to request the > > irq actions. The scope of the resource used to be tied to the pci_dev's > > dev, but now it's the new

Re: [PATCH] mm, add_memory_resource: hold device_hotplug lock over mem_hotplug_{begin, done}

On Wed, Mar 1, 2017 at 9:04 AM, Heiko Carstens wrote: > On Wed, Mar 01, 2017 at 07:52:18AM -0800, Dan Williams wrote: >> On Wed, Mar 1, 2017 at 4:51 AM, Heiko Carstens >> wrote: >> > Since it is anything but obvious why Dan wrote in changelog

Re: [PATCH] mm, add_memory_resource: hold device_hotplug lock over mem_hotplug_{begin, done}

On Wed, Mar 1, 2017 at 9:04 AM, Heiko Carstens wrote: > On Wed, Mar 01, 2017 at 07:52:18AM -0800, Dan Williams wrote: >> On Wed, Mar 1, 2017 at 4:51 AM, Heiko Carstens >> wrote: >> > Since it is anything but obvious why Dan wrote in changelog of b5d24fda9c3d >> > ("mm, devm_memremap_pages: hold

Re: PPro arch_cpu_idle: NMI watchdog: Watchdog detected hard LOCKUP on cpu 1

> > This is on my trusty IBM PC365, dual Pentium Pro. 4.10 worked fine, > > 4.10.0-09686-g9e314890292c and 4.10.0-10770-g2d6be4abf514 exhibit a > > problem. Ocassionally NMI watchdog kicks in and discovers one of the > > CPUs in LOCKUP. The system keeps running fine. The first lockup was > >

Re: PPro arch_cpu_idle: NMI watchdog: Watchdog detected hard LOCKUP on cpu 1

> > This is on my trusty IBM PC365, dual Pentium Pro. 4.10 worked fine, > > 4.10.0-09686-g9e314890292c and 4.10.0-10770-g2d6be4abf514 exhibit a > > problem. Ocassionally NMI watchdog kicks in and discovers one of the > > CPUs in LOCKUP. The system keeps running fine. The first lockup was > >

[PATCH 2/2] staging/vc04_services: add CONFIG_OF dependency

After several hours of debugging this obviously bogus but elaborate gcc-7.0.1 warning, drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c: In function 'vchiq_complete_bulk': drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c:603:4: error: argument 2 null where

[PATCH 2/2] staging/vc04_services: add CONFIG_OF dependency

After several hours of debugging this obviously bogus but elaborate gcc-7.0.1 warning, drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c: In function 'vchiq_complete_bulk': drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c:603:4: error: argument 2 null where

Re: [PATCH v5 0/4] New Microsemi PCI Switch Management Driver

Hey, Seems to me like an elegant solution would be to implement a 'cdev_kill' function which could kill all the processes using a cdev. Thus, during an unbind, a driver could call it and be sure that there are no users left and it can safely allow the devres unwind to continue. Then no difficult

Re: [PATCH v5 0/4] New Microsemi PCI Switch Management Driver

Hey, Seems to me like an elegant solution would be to implement a 'cdev_kill' function which could kill all the processes using a cdev. Thus, during an unbind, a driver could call it and be sure that there are no users left and it can safely allow the devres unwind to continue. Then no difficult

Re: [PATCH 01/10] x86: assembly, ENTRY for fn, GLOBAL for data

* Jiri Slaby wrote: > This is a start of series to unify use of ENTRY, ENDPROC, GLOBAL, END, > and other macros across x86. When we have all this sorted out, this will > help to inject DWARF unwinding info by objtool later. > > So, let us use the macros this way: > * ENTRY --

Re: [PATCH 01/10] x86: assembly, ENTRY for fn, GLOBAL for data

* Jiri Slaby wrote: > This is a start of series to unify use of ENTRY, ENDPROC, GLOBAL, END, > and other macros across x86. When we have all this sorted out, this will > help to inject DWARF unwinding info by objtool later. > > So, let us use the macros this way: > * ENTRY -- start of a global

Re: [PATCH] [RFC] x86: avoid -mtune=atom for objtool warnings

On Wed, Mar 1, 2017 at 5:53 PM, Josh Poimboeuf wrote: > On Wed, Mar 01, 2017 at 04:27:29PM +0100, Arnd Bergmann wrote: > I see no apparent reason for the ud2. It's the possible division by zero. This change would avoid the ud2: diff --git a/drivers/i2c/busses/i2c-img-scb.c

Re: [PATCH] [RFC] x86: avoid -mtune=atom for objtool warnings

On Wed, Mar 1, 2017 at 5:53 PM, Josh Poimboeuf wrote: > On Wed, Mar 01, 2017 at 04:27:29PM +0100, Arnd Bergmann wrote: > I see no apparent reason for the ud2. It's the possible division by zero. This change would avoid the ud2: diff --git a/drivers/i2c/busses/i2c-img-scb.c

Re: [tpmdd-devel] [PATCH] tpm: do not suspend/resume if power stays on

On Wed, Mar 1, 2017 at 10:43 AM, Jason Gunthorpe wrote: >> > +Optional properties: >> > +- powered-while-suspended: present when the TPM is left powered on between >> > + suspend and resume (makes the suspend/resume callbacks do nothing). >> >> This reads like

[GIT PULL] watchdog updates for v4.11 - take 2

Hi Linus, Please pull additional watchdog updates for Linux v4.11 from signed tag: git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging.git watchdog-for-linus-v4.11-2 Thanks, Guenter -- The following changes since commit 2d6be4abf514fc26c83d239c7f31da1f95e4a31d: Merge

Re: [tpmdd-devel] [PATCH] tpm: do not suspend/resume if power stays on

On Wed, Mar 1, 2017 at 10:43 AM, Jason Gunthorpe wrote: >> > +Optional properties: >> > +- powered-while-suspended: present when the TPM is left powered on between >> > + suspend and resume (makes the suspend/resume callbacks do nothing). >> >> This reads like configuration rather than a HW

[GIT PULL] watchdog updates for v4.11 - take 2

Hi Linus, Please pull additional watchdog updates for Linux v4.11 from signed tag: git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging.git watchdog-for-linus-v4.11-2 Thanks, Guenter -- The following changes since commit 2d6be4abf514fc26c83d239c7f31da1f95e4a31d: Merge

<    1   2   3   4   5   6   7   8   9   10   >