smp_mb__after_spinlock requirement too strong?

Peter pointed out in this patch https://patchwork.kernel.org/patch/9771921/ that the spinning-lock used at __schedule() should be RCsc to ensure visibility of writes prior to __schedule when the task is to be migrated to another CPU. And this is emphasized at the comment of the newly introduced

smp_mb__after_spinlock requirement too strong?

Peter pointed out in this patch https://patchwork.kernel.org/patch/9771921/ that the spinning-lock used at __schedule() should be RCsc to ensure visibility of writes prior to __schedule when the task is to be migrated to another CPU. And this is emphasized at the comment of the newly introduced

RE: [RFC/RFT][PATCH v3 0/6] sched/cpuidle: Idle loop rework

On 2018.03.10 15:55 Rafael J. Wysocki wrote: >On Saturday, March 10, 2018 5:07:36 PM CET Doug Smythies wrote: >> On 2018.03.10 01:00 Rafael J. Wysocki wrote: > ... [snip] ... > The information that they often spend more time than a tick > period in state 0 in one go *is* relevant, though. > > >

RE: [RFC/RFT][PATCH v3 0/6] sched/cpuidle: Idle loop rework

On 2018.03.10 15:55 Rafael J. Wysocki wrote: >On Saturday, March 10, 2018 5:07:36 PM CET Doug Smythies wrote: >> On 2018.03.10 01:00 Rafael J. Wysocki wrote: > ... [snip] ... > The information that they often spend more time than a tick > period in state 0 in one go *is* relevant, though. > > >

Re: Fwd: [PATCH v4.15.7 1/1] on Intel, VDSO should handle CLOCK_MONOTONIC_RAW and export 'tsc_calibration' pointer

Hi Thomas - Thanks very much for your help & guidance in previous mail: RE: On 08/03/2018, Thomas Gleixner wrote: > > The right way to do that is to put the raw conversion values and the raw > seconds base value into the vdso data and implement the counterpart of >

Re: Fwd: [PATCH v4.15.7 1/1] on Intel, VDSO should handle CLOCK_MONOTONIC_RAW and export 'tsc_calibration' pointer

Hi Thomas - Thanks very much for your help & guidance in previous mail: RE: On 08/03/2018, Thomas Gleixner wrote: > > The right way to do that is to put the raw conversion values and the raw > seconds base value into the vdso data and implement the counterpart of > getrawmonotonic64(). And if

Re: [PATCH v6 09/17] media: rkisp1: add rockchip isp1 core driver

Hi Jacob, On Thu, Mar 08, 2018 at 05:47:59PM +0800, Jacob Chen wrote: > +config VIDEO_ROCKCHIP_ISP1 > + tristate "Rockchip Image Signal Processing v1 Unit driver" > + depends on VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API > + depends on ARCH_ROCKCHIP || COMPILE_TEST > + select

Re: [PATCH v6 09/17] media: rkisp1: add rockchip isp1 core driver

Hi Jacob, On Thu, Mar 08, 2018 at 05:47:59PM +0800, Jacob Chen wrote: > +config VIDEO_ROCKCHIP_ISP1 > + tristate "Rockchip Image Signal Processing v1 Unit driver" > + depends on VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API > + depends on ARCH_ROCKCHIP || COMPILE_TEST > + select

[PATCH v4.16-rc4 1/1] x86/vdso: on Intel, VDSO should handle CLOCK_MONOTONIC_RAW

Currently the VDSO does not handle clock_gettime( CLOCK_MONOTONIC_RAW, ) on Intel / AMD - it calls vdso_fallback_gettime() for this clock, which issues a syscall, having an unacceptably high latency (minimum measurable time or time between measurements) of 300-700ns on 2

[PATCH v4.16-rc4 1/1] x86/vdso: on Intel, VDSO should handle CLOCK_MONOTONIC_RAW

Currently the VDSO does not handle clock_gettime( CLOCK_MONOTONIC_RAW, ) on Intel / AMD - it calls vdso_fallback_gettime() for this clock, which issues a syscall, having an unacceptably high latency (minimum measurable time or time between measurements) of 300-700ns on 2

Re: [PATCH v4.16-rc4 1/1] x86/vdso: on Intel, VDSO should handle CLOCK_MONOTONIC_RAW

Oops, please disregard 1st mail on $subject - I guess use of Quoted Printable is not a way of getting past the email line length. Patch I tried to send is attached as attachment - will resend inline using other method. Sorry, Regards, Jason vdso_monotonic_raw-v4.16-rc4.patch Description:

Re: [PATCH v4.16-rc4 1/1] x86/vdso: on Intel, VDSO should handle CLOCK_MONOTONIC_RAW

Oops, please disregard 1st mail on $subject - I guess use of Quoted Printable is not a way of getting past the email line length. Patch I tried to send is attached as attachment - will resend inline using other method. Sorry, Regards, Jason vdso_monotonic_raw-v4.16-rc4.patch Description:

[PATCH v4.16-rc4 1/1] x86/vdso: on Intel, VDSO should handle CLOCK_MONOTONIC_RAW

Currently the VDSO does not handle clock_gettime( CLOCK_MONOTONIC_RAW, ) on Intel / AMD - it calls vdso_fallback_gettime() for this clock, which issues a syscall, having an unacceptably high latency (minimum measurable time or time between measurements) of 300-700ns on 2

[PATCH v4.16-rc4 1/1] x86/vdso: on Intel, VDSO should handle CLOCK_MONOTONIC_RAW

Currently the VDSO does not handle clock_gettime( CLOCK_MONOTONIC_RAW, ) on Intel / AMD - it calls vdso_fallback_gettime() for this clock, which issues a syscall, having an unacceptably high latency (minimum measurable time or time between measurements) of 300-700ns on 2

[PATCH 0/4] driver core: use put_device() instead of kfree()

Never directly free @dev after calling device_register(), even if it returned an error! Always use put_device() to give up the reference initialized. Arvind Yadav (4): [PATCH 1/4] base: soc: use put_device() instead of kfree() [PATCH 2/4] driver core: platform: use put_device() if

[PATCH 0/4] driver core: use put_device() instead of kfree()

Never directly free @dev after calling device_register(), even if it returned an error! Always use put_device() to give up the reference initialized. Arvind Yadav (4): [PATCH 1/4] base: soc: use put_device() instead of kfree() [PATCH 2/4] driver core: platform: use put_device() if

[PATCH 1/4] base: soc: use put_device() instead of kfree()

Never directly free @dev after calling device_register(), even if it returned an error! Always use put_device() to give up the reference initialized. Signed-off-by: Arvind Yadav --- drivers/base/soc.c | 2 ++ 1 file changed, 2 insertions(+) diff --git

[PATCH 4/4] driver core: cpu: use put_device() if device_register fail

if device_register() returned an error! Always use put_device() to give up the reference initialized. Signed-off-by: Arvind Yadav --- drivers/base/cpu.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/base/cpu.c b/drivers/base/cpu.c

[PATCH 3/4] driver core: node: use put_device() if device_register fail

if device_register() returned an error! Always use put_device() to give up the reference initialized. Signed-off-by: Arvind Yadav --- drivers/base/node.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/base/node.c b/drivers/base/node.c

[PATCH 2/4] driver core: platform: use put_device() if device_register fail

if device_register() returned an error! Always use put_device() to give up the reference initialized. Signed-off-by: Arvind Yadav --- drivers/base/platform.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/base/platform.c

[PATCH 1/4] base: soc: use put_device() instead of kfree()

Never directly free @dev after calling device_register(), even if it returned an error! Always use put_device() to give up the reference initialized. Signed-off-by: Arvind Yadav --- drivers/base/soc.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/base/soc.c b/drivers/base/soc.c

[PATCH 4/4] driver core: cpu: use put_device() if device_register fail

if device_register() returned an error! Always use put_device() to give up the reference initialized. Signed-off-by: Arvind Yadav --- drivers/base/cpu.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/base/cpu.c b/drivers/base/cpu.c index d21a2d9..2da998b 100644

[PATCH 3/4] driver core: node: use put_device() if device_register fail

if device_register() returned an error! Always use put_device() to give up the reference initialized. Signed-off-by: Arvind Yadav --- drivers/base/node.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/base/node.c b/drivers/base/node.c index ee090ab..c5f81fc

[PATCH 2/4] driver core: platform: use put_device() if device_register fail

if device_register() returned an error! Always use put_device() to give up the reference initialized. Signed-off-by: Arvind Yadav --- drivers/base/platform.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/base/platform.c b/drivers/base/platform.c index

Re: [RFC v2 00/83] NOVA: a new file system for persistent memory

On Sat, Mar 10, 2018 at 6:14 PM, Theodore Y. Ts'o wrote: > FYI, your patch set doesn't even compile for me without these fixups. > I'm not sure why you were trying to declare inline functions in a > header file without the function body? > Thanks for catching this. I will fix it

Re: [RFC v2 00/83] NOVA: a new file system for persistent memory

On Sat, Mar 10, 2018 at 6:14 PM, Theodore Y. Ts'o wrote: > FYI, your patch set doesn't even compile for me without these fixups. > I'm not sure why you were trying to declare inline functions in a > header file without the function body? > Thanks for catching this. I will fix it in the next

Re: [PATCH] platform/x86: fujitsu-laptop: Revert UNSUPPORTED_CMD back to an int

On Sat, Mar 10, 2018 at 09:43:53PM +0100, Micha?? K??pie?? wrote: > UNSUPPORTED_CMD was previously 0x8000 (int), but commit 819cddae7cfa > ("platform/x86: fujitsu-laptop: Clean up constants") changed it into an > unsigned long due to BIT() being used to define it. As call_fext_func() >

Re: [PATCH] platform/x86: fujitsu-laptop: Revert UNSUPPORTED_CMD back to an int

On Sat, Mar 10, 2018 at 09:43:53PM +0100, Micha?? K??pie?? wrote: > UNSUPPORTED_CMD was previously 0x8000 (int), but commit 819cddae7cfa > ("platform/x86: fujitsu-laptop: Clean up constants") changed it into an > unsigned long due to BIT() being used to define it. As call_fext_func() >

Re: [PATCH 0/9] KEYS: Blacklisting & UEFI database load

On Wed, Mar 07, 2018 at 07:28:37AM -0800, James Bottomley wrote: > On Wed, 2018-03-07 at 08:18 -0500, Mimi Zohar wrote: > > On Tue, 2018-03-06 at 15:05 +0100, Jiri Slaby wrote: > > > what's the status of this please? Distributors (I checked SUSE, > > > RedHat and Ubuntu) have to carry these

Re: [PATCH 0/9] KEYS: Blacklisting & UEFI database load

On Wed, Mar 07, 2018 at 07:28:37AM -0800, James Bottomley wrote: > On Wed, 2018-03-07 at 08:18 -0500, Mimi Zohar wrote: > > On Tue, 2018-03-06 at 15:05 +0100, Jiri Slaby wrote: > > > what's the status of this please? Distributors (I checked SUSE, > > > RedHat and Ubuntu) have to carry these

ERROR: "sst_context_init" [sound/soc/intel/atom/sst/snd-intel-sst-acpi.ko] undefined!

tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 3266b5bd97eaa72793df0b6e5a106c69ccc166c4 commit: 4772c16ede522d46219a59646503d2020841a6f4 ASoC: Intel: Kconfig: Simplify-clarify ACPI/PCI dependencies date: 9 weeks ago config:

ERROR: "sst_context_init" [sound/soc/intel/atom/sst/snd-intel-sst-acpi.ko] undefined!

tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 3266b5bd97eaa72793df0b6e5a106c69ccc166c4 commit: 4772c16ede522d46219a59646503d2020841a6f4 ASoC: Intel: Kconfig: Simplify-clarify ACPI/PCI dependencies date: 9 weeks ago config:

Re: [PATCH v3 15/15] selinux: delay sid population for rootfs till init is complete

On Tue, 20 Feb 2018, Stephen Smalley wrote: On Fri, 2018-02-16 at 20:33 +, Taras Kondratiuk wrote: From: Victor Kamensky With initramfs cpio format that supports extended attributes we need to skip sid population on sys_lsetxattr call from initramfs for rootfs if

Re: [PATCH v3 15/15] selinux: delay sid population for rootfs till init is complete

On Tue, 20 Feb 2018, Stephen Smalley wrote: On Fri, 2018-02-16 at 20:33 +, Taras Kondratiuk wrote: From: Victor Kamensky With initramfs cpio format that supports extended attributes we need to skip sid population on sys_lsetxattr call from initramfs for rootfs if security server is not

Re: [PATCH v3 14/15] selinux: allow setxattr on rootfs so initramfs code can set them

On Tue, 20 Feb 2018, Stephen Smalley wrote: On Fri, 2018-02-16 at 20:33 +, Taras Kondratiuk wrote: From: Victor Kamensky initramfs code supporting extended cpio format have ability to fill extended attributes from cpio archive, but if SELinux enabled and security

Re: [PATCH v3 14/15] selinux: allow setxattr on rootfs so initramfs code can set them

On Tue, 20 Feb 2018, Stephen Smalley wrote: On Fri, 2018-02-16 at 20:33 +, Taras Kondratiuk wrote: From: Victor Kamensky initramfs code supporting extended cpio format have ability to fill extended attributes from cpio archive, but if SELinux enabled and security server is not

Re: [PATCH net-next] modules: allow modprobe load regular elf binaries

On Sat, Mar 10, 2018 at 1:43 AM, Alexei Starovoitov wrote: > On 3/9/18 11:37 AM, Andy Lutomirski wrote: >> >> On Fri, Mar 9, 2018 at 6:55 PM, David Miller wrote: >>> >>> From: Alexei Starovoitov >>> Date: Fri, 9 Mar 2018 10:50:49 -0800 >>> On

Re: [PATCH net-next] modules: allow modprobe load regular elf binaries

On Sat, Mar 10, 2018 at 1:43 AM, Alexei Starovoitov wrote: > On 3/9/18 11:37 AM, Andy Lutomirski wrote: >> >> On Fri, Mar 9, 2018 at 6:55 PM, David Miller wrote: >>> >>> From: Alexei Starovoitov >>> Date: Fri, 9 Mar 2018 10:50:49 -0800 >>> On 3/9/18 10:23 AM, Andy Lutomirski wrote: >

Re: [RFC v2 00/83] NOVA: a new file system for persistent memory

FYI, your patch set doesn't even compile for me without these fixups. I'm not sure why you were trying to declare inline functions in a header file without the function body? - Ted diff --git a/fs/nova/balloc.c b/fs/nova/balloc.c index

Re: [RFC v2 00/83] NOVA: a new file system for persistent memory

FYI, your patch set doesn't even compile for me without these fixups. I'm not sure why you were trying to declare inline functions in a header file without the function body? - Ted diff --git a/fs/nova/balloc.c b/fs/nova/balloc.c index

Re: [RFC PATCH] KVM: arm/arm64: vgic: change condition for level interrupt resampling

On Sat, Mar 10, 2018 at 12:20 PM, Marc Zyngier wrote: > On Fri, 09 Mar 2018 21:36:12 +, > Christoffer Dall wrote: >> >> On Thu, Mar 08, 2018 at 05:28:44PM +, Marc Zyngier wrote: >> > I'd be more confident if we did forbid P+A for such interrupts >> > altogether, as

Re: [RFC PATCH] KVM: arm/arm64: vgic: change condition for level interrupt resampling

On Sat, Mar 10, 2018 at 12:20 PM, Marc Zyngier wrote: > On Fri, 09 Mar 2018 21:36:12 +, > Christoffer Dall wrote: >> >> On Thu, Mar 08, 2018 at 05:28:44PM +, Marc Zyngier wrote: >> > I'd be more confident if we did forbid P+A for such interrupts >> > altogether, as they really feel like

Re: [RFC/RFT][PATCH v3 5/6] sched: idle: Select idle state before stopping the tick

On Fri, Mar 09, 2018 at 10:46:55AM +0100, Rafael J. Wysocki wrote: > --- linux-pm.orig/kernel/time/tick-sched.h > +++ linux-pm/kernel/time/tick-sched.h > @@ -30,6 +30,7 @@ enum tick_nohz_mode { > * when the CPU returns from nohz sleep. > * @next_tick: Next tick

Re: [RFC/RFT][PATCH v3 5/6] sched: idle: Select idle state before stopping the tick

On Fri, Mar 09, 2018 at 10:46:55AM +0100, Rafael J. Wysocki wrote: > --- linux-pm.orig/kernel/time/tick-sched.h > +++ linux-pm/kernel/time/tick-sched.h > @@ -30,6 +30,7 @@ enum tick_nohz_mode { > * when the CPU returns from nohz sleep. > * @next_tick: Next tick

htmldocs: include/net/cfg80211.h:4115: warning: Function parameter or member 'wext.bssid' not described in 'wireless_dev'

tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 3266b5bd97eaa72793df0b6e5a106c69ccc166c4 commit: 84ce5b987783d362ee4e737b653d6e2feacfa40c scripts: kernel-doc: improve nested logic to handle multiple identifiers date: 3 months ago reproduce: make

htmldocs: include/net/cfg80211.h:4115: warning: Function parameter or member 'wext.bssid' not described in 'wireless_dev'

tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 3266b5bd97eaa72793df0b6e5a106c69ccc166c4 commit: 84ce5b987783d362ee4e737b653d6e2feacfa40c scripts: kernel-doc: improve nested logic to handle multiple identifiers date: 3 months ago reproduce: make

Re: a Heisenbug tale

On 2018-03-09 10:45, Ard Biesheuvel wrote: > On 8 March 2018 at 23:19, Rasmus Villemoes wrote: >> On 2018-03-07 20:25, Leonard Crestez wrote: >>> Hello, >>> >> >> What we ended up doing was to explicitly set the mtime of every file in >> the repo to the same reference

Re: a Heisenbug tale

On 2018-03-09 10:45, Ard Biesheuvel wrote: > On 8 March 2018 at 23:19, Rasmus Villemoes wrote: >> On 2018-03-07 20:25, Leonard Crestez wrote: >>> Hello, >>> >> >> What we ended up doing was to explicitly set the mtime of every file in >> the repo to the same reference time after the git checkout

[PATCH] media: ivtv: add parameter to enable ivtvfb on x86 PAT systems

ivtvfb was previously disabled for x86 PAT-enabled systems by commit 1bf1735b4780 ("x86/mm/pat, drivers/media/ivtv: Use arch_phys_wc_add() and require PAT disabled") as a workaround to abstract MTRR code away from device drivers. The driver is not easily upgradable to the PAT-aware ioremap_wc()

[PATCH] media: ivtv: add parameter to enable ivtvfb on x86 PAT systems

ivtvfb was previously disabled for x86 PAT-enabled systems by commit 1bf1735b4780 ("x86/mm/pat, drivers/media/ivtv: Use arch_phys_wc_add() and require PAT disabled") as a workaround to abstract MTRR code away from device drivers. The driver is not easily upgradable to the PAT-aware ioremap_wc()

[PATCH] platform/x86: dell_smbios: Resolve dependency error on ACPI_WMI

Similarly to DCDBAS for DELL_SMBIOS_SMM, if DELL_SMBIOS_WMI is enabled, DELL_SMBIOS becomes dependent on ACPI_WMI. Update the depends line to prevent a configuration where DELL_SMBIOS=y and either backend dependency =m. Update the comment accordingly. Cc: Mario Limonciello

[PATCH] platform/x86: dell_smbios: Resolve dependency error on ACPI_WMI

Similarly to DCDBAS for DELL_SMBIOS_SMM, if DELL_SMBIOS_WMI is enabled, DELL_SMBIOS becomes dependent on ACPI_WMI. Update the depends line to prevent a configuration where DELL_SMBIOS=y and either backend dependency =m. Update the comment accordingly. Cc: Mario Limonciello Cc: Andy Shevchenko

Re: [RFC/RFT][PATCH v3 0/6] sched/cpuidle: Idle loop rework

On Saturday, March 10, 2018 5:07:36 PM CET Doug Smythies wrote: > On 2018.03.10 01:00 Rafael J. Wysocki wrote: > > On Saturday, March 10, 2018 8:41:39 AM CET Doug Smythies wrote: > >> > >> With apologies to those that do not like the term "PowerNightmares", > > > > OK, and what exactly do you

Re: [RFC/RFT][PATCH v3 0/6] sched/cpuidle: Idle loop rework

On Saturday, March 10, 2018 5:07:36 PM CET Doug Smythies wrote: > On 2018.03.10 01:00 Rafael J. Wysocki wrote: > > On Saturday, March 10, 2018 8:41:39 AM CET Doug Smythies wrote: > >> > >> With apologies to those that do not like the term "PowerNightmares", > > > > OK, and what exactly do you

drivers/media/dvb-frontends/stb0899_drv.h:151:36: error: weak declaration of 'stb0899_attach' being applied to a already existing, static definition

tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 3266b5bd97eaa72793df0b6e5a106c69ccc166c4 commit: 6cdeaed3b1420bd2569891be0c4123ff59628e9e media: dvb_usb_pctv452e: module refcount changes were unbalanced date: 3 months ago config:

drivers/media/dvb-frontends/stb0899_drv.h:151:36: error: weak declaration of 'stb0899_attach' being applied to a already existing, static definition

tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 3266b5bd97eaa72793df0b6e5a106c69ccc166c4 commit: 6cdeaed3b1420bd2569891be0c4123ff59628e9e media: dvb_usb_pctv452e: module refcount changes were unbalanced date: 3 months ago config:

Re: [PATCH] drivers: net: wireless: ath: ath9: dfs: remove VLA usage

> Just wondering. Is this actually a VLA. FFT_NUM_SAMPLES was static const so > not really going to show a lot of variation. This array will always have the > same size on the stack. The issue is that unlike in C++, a `static const` can't be used in a constant expression in C. It's unclear why C

Re: [PATCH] drivers: net: wireless: ath: ath9: dfs: remove VLA usage

> Just wondering. Is this actually a VLA. FFT_NUM_SAMPLES was static const so > not really going to show a lot of variation. This array will always have the > same size on the stack. The issue is that unlike in C++, a `static const` can't be used in a constant expression in C. It's unclear why C

Re: Simplifying our RCU models

On Sat, Mar 10, 2018 at 02:47:26PM -0800, Paul E. McKenney wrote: > On Sat, Mar 10, 2018 at 05:29:46PM +0100, Andrea Parri wrote: > > On Sat, Mar 10, 2018 at 08:04:09AM -0800, Paul E. McKenney wrote: > > > On Fri, Mar 09, 2018 at 10:55:20AM +0100, Andrea Parri wrote: > > > > On Thu, Mar 08, 2018

Re: Simplifying our RCU models

On Sat, Mar 10, 2018 at 02:47:26PM -0800, Paul E. McKenney wrote: > On Sat, Mar 10, 2018 at 05:29:46PM +0100, Andrea Parri wrote: > > On Sat, Mar 10, 2018 at 08:04:09AM -0800, Paul E. McKenney wrote: > > > On Fri, Mar 09, 2018 at 10:55:20AM +0100, Andrea Parri wrote: > > > > On Thu, Mar 08, 2018

kernel/jump_label.c:377:51: warning: cast to pointer from integer of different size

tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 3266b5bd97eaa72793df0b6e5a106c69ccc166c4 commit: dc1dd184c2f0016bec35c0d7a48c057e0ad763d3 jump_label: Warn on failed jump_label patching attempt date: 2 weeks ago config: sparc64-allyesconfig (attached as

kernel/jump_label.c:377:51: warning: cast to pointer from integer of different size

tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 3266b5bd97eaa72793df0b6e5a106c69ccc166c4 commit: dc1dd184c2f0016bec35c0d7a48c057e0ad763d3 jump_label: Warn on failed jump_label patching attempt date: 2 weeks ago config: sparc64-allyesconfig (attached as

Re: [PATCH] drivers: net: wireless: ath: ath9: dfs: remove VLA usage

On 03/10/2018 05:12 PM, Kees Cook wrote: On Sat, Mar 10, 2018 at 3:06 PM, Arend van Spriel wrote: On 3/9/2018 1:30 PM, Andreas Christoforou wrote: The kernel would like to have all stack VLA usage removed. I think there was a remark made earlier to give

Re: [PATCH] drivers: net: wireless: ath: ath9: dfs: remove VLA usage

On 03/10/2018 05:12 PM, Kees Cook wrote: On Sat, Mar 10, 2018 at 3:06 PM, Arend van Spriel wrote: On 3/9/2018 1:30 PM, Andreas Christoforou wrote: The kernel would like to have all stack VLA usage removed. I think there was a remark made earlier to give more explanation here. It should

mm/percpu.c:2723:2: warning: #warning "the CRIS architecture has physical and virtual addresses confused"

tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 3266b5bd97eaa72793df0b6e5a106c69ccc166c4 commit: abee210500ed15a22787009d9210b9a34911afcc percpu: hack to let the CRIS architecture to boot until they clean up date: 3 months ago config:

mm/percpu.c:2723:2: warning: #warning "the CRIS architecture has physical and virtual addresses confused"

tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 3266b5bd97eaa72793df0b6e5a106c69ccc166c4 commit: abee210500ed15a22787009d9210b9a34911afcc percpu: hack to let the CRIS architecture to boot until they clean up date: 3 months ago config:

Re: [PATCH] drivers: net: wireless: ath: ath9: dfs: remove VLA usage

On Sat, Mar 10, 2018 at 3:06 PM, Arend van Spriel wrote: > On 3/9/2018 1:30 PM, Andreas Christoforou wrote: >> >> The kernel would like to have all stack VLA usage removed. > > > I think there was a remark made earlier to give more explanation here. It > should

Re: [PATCH] drivers: net: wireless: ath: ath9: dfs: remove VLA usage

On Sat, Mar 10, 2018 at 3:06 PM, Arend van Spriel wrote: > On 3/9/2018 1:30 PM, Andreas Christoforou wrote: >> >> The kernel would like to have all stack VLA usage removed. > > > I think there was a remark made earlier to give more explanation here. It > should explain why we want "VLA on stack"

Re: [PATCH] drivers: net: wireless: ath: ath9: dfs: remove VLA usage

On 3/9/2018 1:30 PM, Andreas Christoforou wrote: The kernel would like to have all stack VLA usage removed. I think there was a remark made earlier to give more explanation here. It should explain why we want "VLA on stack" removed. Signed-off-by: Andreas Christoforou

Re: [PATCH] drivers: net: wireless: ath: ath9: dfs: remove VLA usage

On 3/9/2018 1:30 PM, Andreas Christoforou wrote: The kernel would like to have all stack VLA usage removed. I think there was a remark made earlier to give more explanation here. It should explain why we want "VLA on stack" removed. Signed-off-by: Andreas Christoforou ---

htmldocs: include/linux/crypto.h:469: warning: Function parameter or member 'cra_u.ablkcipher' not described in 'crypto_alg'

tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 3266b5bd97eaa72793df0b6e5a106c69ccc166c4 commit: 151c468b44a89a9f3173ab8575690014b7249893 scripts: kernel-doc: print the declaration name on warnings date: 3 months ago reproduce: make htmldocs All

htmldocs: include/linux/crypto.h:469: warning: Function parameter or member 'cra_u.ablkcipher' not described in 'crypto_alg'

tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 3266b5bd97eaa72793df0b6e5a106c69ccc166c4 commit: 151c468b44a89a9f3173ab8575690014b7249893 scripts: kernel-doc: print the declaration name on warnings date: 3 months ago reproduce: make htmldocs All

[PATCH] rslib: Remove VLAs by setting upper bound on nroots

Avoid stack VLAs[1] by always allocating the upper bound of stack space needed. The existing users of rslib appear to max out at 24 roots[2], so use that as the upper bound until we have a reason to change it. Alternative considered: make init_rs() a true caller-instance and pre-allocate the

[PATCH] rslib: Remove VLAs by setting upper bound on nroots

Avoid stack VLAs[1] by always allocating the upper bound of stack space needed. The existing users of rslib appear to max out at 24 roots[2], so use that as the upper bound until we have a reason to change it. Alternative considered: make init_rs() a true caller-instance and pre-allocate the

[PATCH v2 2/2] iio: chemical: sgp30: Support Sensirion SGPxx sensors

Support Sensirion SGP30 and SGPC3 multi-pixel I2C gas sensors Supported Features: * Indoor Air Quality (IAQ) concentrations for - tVOC (in_concentration_voc_input) - CO2eq (in_concentration_co2_input) - SGP30 only IAQ concentrations are periodically read out by a background thread to

[PATCH v2 2/2] iio: chemical: sgp30: Support Sensirion SGPxx sensors

Support Sensirion SGP30 and SGPC3 multi-pixel I2C gas sensors Supported Features: * Indoor Air Quality (IAQ) concentrations for - tVOC (in_concentration_voc_input) - CO2eq (in_concentration_co2_input) - SGP30 only IAQ concentrations are periodically read out by a background thread to

[PATCH v2 0/2] iio: chemical: sgp30: Support SGP30 / SGPC3 Gas Sensors

This patch series adds support for Sensirion SGP30 and SGPC3 I2C gas sensors. Further product specs available from: https://www.sensirion.com/en/environmental-sensors/gas-sensors/multi-pixel-gas-sensors/ https://www.sensirion.com/en/about-us/links/#c15360 Patch 1/2 add new IIO modifiers used by

[PATCH v2 1/2] iio: Add modifiers for ethanol and H2 gases

Add ethanol and H2 gas modifiers: * IIO_MOD_ETHANOL * IIO_MOD_H2 Signed-off-by: Andreas Brauchli --- Documentation/ABI/testing/sysfs-bus-iio | 4 include/uapi/linux/iio/types.h | 2 ++ tools/iio/iio_event_monitor.c | 4 3 files

[PATCH v2 0/2] iio: chemical: sgp30: Support SGP30 / SGPC3 Gas Sensors

This patch series adds support for Sensirion SGP30 and SGPC3 I2C gas sensors. Further product specs available from: https://www.sensirion.com/en/environmental-sensors/gas-sensors/multi-pixel-gas-sensors/ https://www.sensirion.com/en/about-us/links/#c15360 Patch 1/2 add new IIO modifiers used by

[PATCH v2 1/2] iio: Add modifiers for ethanol and H2 gases

Add ethanol and H2 gas modifiers: * IIO_MOD_ETHANOL * IIO_MOD_H2 Signed-off-by: Andreas Brauchli --- Documentation/ABI/testing/sysfs-bus-iio | 4 include/uapi/linux/iio/types.h | 2 ++ tools/iio/iio_event_monitor.c | 4 3 files changed, 10 insertions(+) diff --git

Re: [PATCH 2/2] iio: chemical: sgpxx: triggered buffer support

On Sat, 2017-11-25 at 17:48 +, Jonathan Cameron wrote: > On Tue, 21 Nov 2017 17:11:29 +0100 > Andreas Brauchli wrote: > > > Support triggered buffer for use with e.g. hrtimer for automated > > polling to ensure that the sensor's internal baseline is correctly > >

Re: [PATCH 2/2] iio: chemical: sgpxx: triggered buffer support

On Sat, 2017-11-25 at 17:48 +, Jonathan Cameron wrote: > On Tue, 21 Nov 2017 17:11:29 +0100 > Andreas Brauchli wrote: > > > Support triggered buffer for use with e.g. hrtimer for automated > > polling to ensure that the sensor's internal baseline is correctly > > updated independently of the

Re: [PATCH 1/2] iio: chemical: sgpxx: Support Sensirion SGPxx sensors

Dear Peter, Jonathan, Thanks for the thourough and speedy review and apologies for the delayed reply. Many of your comments are integrated in the v2 patch series - details below. On Sam, 2017-11-25 at 17:41 +, Jonathan Cameron wrote: > On Tue, 21 Nov 2017 22:46:07 +0100 (CET) > Peter

Re: [PATCH 1/2] iio: chemical: sgpxx: Support Sensirion SGPxx sensors

Dear Peter, Jonathan, Thanks for the thourough and speedy review and apologies for the delayed reply. Many of your comments are integrated in the v2 patch series - details below. On Sam, 2017-11-25 at 17:41 +, Jonathan Cameron wrote: > On Tue, 21 Nov 2017 22:46:07 +0100 (CET) > Peter

Re: [PATCH] ARM: BCM5301X: Fix NAND ECC parameters for Linksys Panamera

On 10 March 2018 at 18:12, Vivek Unune wrote: > Using BCH8 gives ecc errors and makes the router unsuable. > Switching to BCH1 fixes these errors. Can you provide CFE's log messages starting with "Decompressing...done" and up to the "Press Ctrl+C to stop in CFE" please?

Re: [PATCH] ARM: BCM5301X: Fix NAND ECC parameters for Linksys Panamera

On 10 March 2018 at 18:12, Vivek Unune wrote: > Using BCH8 gives ecc errors and makes the router unsuable. > Switching to BCH1 fixes these errors. Can you provide CFE's log messages starting with "Decompressing...done" and up to the "Press Ctrl+C to stop in CFE" please? I'd like to see what NAND

[PATCH 3/3] wlcore: Use common error handling code in wl1271_acx_sta_rate_policies()

From: Markus Elfring Date: Sat, 10 Mar 2018 22:18:45 +0100 Add a jump target so that a bit of exception handling can be better reused at the end of this function. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring

[PATCH 3/3] wlcore: Use common error handling code in wl1271_acx_sta_rate_policies()

From: Markus Elfring Date: Sat, 10 Mar 2018 22:18:45 +0100 Add a jump target so that a bit of exception handling can be better reused at the end of this function. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring --- drivers/net/wireless/ti/wlcore/acx.c

[PATCH 2/3] wlcore: Return directly after a failed kzalloc() in wl1271_acx_sta_rate_policies()

From: Markus Elfring Date: Sat, 10 Mar 2018 22:00:31 +0100 Return directly after a call of the function "kzalloc" failed at the beginning. Signed-off-by: Markus Elfring --- drivers/net/wireless/ti/wlcore/acx.c | 7 ++- 1 file

[PATCH 2/3] wlcore: Return directly after a failed kzalloc() in wl1271_acx_sta_rate_policies()

From: Markus Elfring Date: Sat, 10 Mar 2018 22:00:31 +0100 Return directly after a call of the function "kzalloc" failed at the beginning. Signed-off-by: Markus Elfring --- drivers/net/wireless/ti/wlcore/acx.c | 7 ++- 1 file changed, 2 insertions(+), 5 deletions(-) diff --git

[PATCH 1/3] wlcore: Delete an unnecessary variable initialisation in wl1271_acx_sta_rate_policies()

From: Markus Elfring Date: Sat, 10 Mar 2018 21:51:17 +0100 The local variable "ret" will be set to an appropriate value a bit later. Thus omit the explicit initialisation at the beginning. Signed-off-by: Markus Elfring ---

[PATCH 1/3] wlcore: Delete an unnecessary variable initialisation in wl1271_acx_sta_rate_policies()

From: Markus Elfring Date: Sat, 10 Mar 2018 21:51:17 +0100 The local variable "ret" will be set to an appropriate value a bit later. Thus omit the explicit initialisation at the beginning. Signed-off-by: Markus Elfring --- drivers/net/wireless/ti/wlcore/acx.c | 2 +- 1 file changed, 1

[PATCH 0/3] wlcore: Adjustments for wl1271_acx_sta_rate_policies()

From: Markus Elfring Date: Sat, 10 Mar 2018 22:25:45 +0100 Three update suggestions were taken into account from static source code analysis. Markus Elfring (3): Delete an unnecessary variable initialisation Return directly after a failed kzalloc() Use

[PATCH 0/3] wlcore: Adjustments for wl1271_acx_sta_rate_policies()

From: Markus Elfring Date: Sat, 10 Mar 2018 22:25:45 +0100 Three update suggestions were taken into account from static source code analysis. Markus Elfring (3): Delete an unnecessary variable initialisation Return directly after a failed kzalloc() Use common error handling code

Re: [PATCH] scsi: resolve COMMAND_SIZE at compile time

On 2018-03-10 03:49 PM, James Bottomley wrote: On Sat, 2018-03-10 at 14:29 +0100, Stephen Kitt wrote: Hi Bart, On Fri, 9 Mar 2018 22:47:12 +, Bart Van Assche wrote: On Fri, 2018-03-09 at 23:33 +0100, Stephen Kitt wrote: +/* + * SCSI command sizes are as

Re: [PATCH] scsi: resolve COMMAND_SIZE at compile time

On 2018-03-10 03:49 PM, James Bottomley wrote: On Sat, 2018-03-10 at 14:29 +0100, Stephen Kitt wrote: Hi Bart, On Fri, 9 Mar 2018 22:47:12 +, Bart Van Assche wrote: On Fri, 2018-03-09 at 23:33 +0100, Stephen Kitt wrote: +/* + * SCSI command sizes are as follows, in bytes, for fixed

Re: [PATCH] leds: fix wrong dmi_match on PC Engines APU LEDs

Hi Hans, Thank you for the patch. On 03/05/2018 06:09 PM, Hans Ulli Kroll wrote: > APU has compared to APU2 no DMI_BOARD_NAME. > Use DMI_PRODUCT_NAME instead. Could we have the commit message more expressive? Is it that now this driver doesn't work for APU board? > Signed-off-by: Hans Ulli

Re: [PATCH] leds: fix wrong dmi_match on PC Engines APU LEDs

Hi Hans, Thank you for the patch. On 03/05/2018 06:09 PM, Hans Ulli Kroll wrote: > APU has compared to APU2 no DMI_BOARD_NAME. > Use DMI_PRODUCT_NAME instead. Could we have the commit message more expressive? Is it that now this driver doesn't work for APU board? > Signed-off-by: Hans Ulli

Re: [PATCH] x86: always use SYSCALL_DEFINE*

On 10 Mar 2018, at 20:55, Tautschnig, Michael wrote: > > All syscall arguments are passed in as types of the same byte size as > unsigned long (width of full registers). Using a smaller type without a > cast may result in losing bits of information. SYSCALL_DEFINE*

Re: [PATCH] x86: always use SYSCALL_DEFINE*

On 10 Mar 2018, at 20:55, Tautschnig, Michael wrote: > > All syscall arguments are passed in as types of the same byte size as > unsigned long (width of full registers). Using a smaller type without a > cast may result in losing bits of information. SYSCALL_DEFINE* introduce > adequate type

  1   2   3   4   5   6   7   >