[PATCH v2 2/5] video: smscufx: Less checks in ufx_usb_probe() after error detection

From: Markus Elfring Date: Sun, 26 Nov 2017 08:18:20 +0100 Up to four checks could be repeated by the ufx_usb_probe() function during error handling even if the relevant properties can be determined for the involved variables before by source code analysis. *

linux-next: Signed-off-by missing for commit in the hdlcd tree

Hi Liviu, Commit 7f2189b12359 ("drm: Fix checkpatch issue: "WARNING: braces {} are not necessary for single statement blocks."") is missing a Signed-off-by from its committer. -- Cheers, Stephen Rothwell

[PATCH v2 2/5] video: smscufx: Less checks in ufx_usb_probe() after error detection

From: Markus Elfring Date: Sun, 26 Nov 2017 08:18:20 +0100 Up to four checks could be repeated by the ufx_usb_probe() function during error handling even if the relevant properties can be determined for the involved variables before by source code analysis. * Return directly after a call of the

linux-next: Signed-off-by missing for commit in the hdlcd tree

Hi Liviu, Commit 7f2189b12359 ("drm: Fix checkpatch issue: "WARNING: braces {} are not necessary for single statement blocks."") is missing a Signed-off-by from its committer. -- Cheers, Stephen Rothwell

Re: [PATCH v2 1/5] mm: memory_hotplug: Memory hotplug (add) support for arm64

On Fri, Nov 24, 2017 at 4:23 PM, Maciej Bielski wrote: > On Fri, Nov 24, 2017 at 09:42:33AM +, Andrea Reale wrote: >> Hi Arun, >> >> >> On Fri 24 Nov 2017, 11:25, Arun KS wrote: >> > On Thu, Nov 23, 2017 at 4:43 PM, Maciej Bielski >> >

Re: [PATCH v2 1/5] mm: memory_hotplug: Memory hotplug (add) support for arm64

On Fri, Nov 24, 2017 at 4:23 PM, Maciej Bielski wrote: > On Fri, Nov 24, 2017 at 09:42:33AM +, Andrea Reale wrote: >> Hi Arun, >> >> >> On Fri 24 Nov 2017, 11:25, Arun KS wrote: >> > On Thu, Nov 23, 2017 at 4:43 PM, Maciej Bielski >> > wrote: >> >> [ ...] >> > > Introduces memory hotplug

Re: [PATCHv2 2/2] userns: control capabilities of some user namespaces

Quoting Mahesh Bandewar (mah...@bandewar.net): > From: Mahesh Bandewar > > With this new notion of "controlled" user-namespaces, the controlled > user-namespaces are marked at the time of their creation while the > capabilities of processes that belong to them are controlled

Re: [PATCHv2 2/2] userns: control capabilities of some user namespaces

Quoting Mahesh Bandewar (mah...@bandewar.net): > From: Mahesh Bandewar > > With this new notion of "controlled" user-namespaces, the controlled > user-namespaces are marked at the time of their creation while the > capabilities of processes that belong to them are controlled using the > global

Re: [PATCHv2 1/2] capability: introduce sysctl for controlled user-ns capability whitelist

Quoting Mahesh Bandewar (mah...@bandewar.net): > From: Mahesh Bandewar > > Add a sysctl variable kernel.controlled_userns_caps_whitelist. This > takes input as capability mask expressed as two comma separated hex > u32 words. The mask, however, is stored in kernel as

Re: [PATCHv2 1/2] capability: introduce sysctl for controlled user-ns capability whitelist

Quoting Mahesh Bandewar (mah...@bandewar.net): > From: Mahesh Bandewar > > Add a sysctl variable kernel.controlled_userns_caps_whitelist. This > takes input as capability mask expressed as two comma separated hex > u32 words. The mask, however, is stored in kernel as kernel_cap_t type. > > Any

Re: perf test LLVM & clang 6 failing

On 11/24/17 11:09 AM, Arnaldo Carvalho de Melo wrote: Em Fri, Nov 24, 2017 at 04:16:52PM +0100, Daniel Borkmann escreveu: [ +Yonghong ] On 11/24/2017 03:47 PM, Arnaldo Carvalho de Melo wrote: FYI, just noticed, recently updated clang to version 6, from its upstream git repo. Do you recall

Re: perf test LLVM & clang 6 failing

On 11/24/17 11:09 AM, Arnaldo Carvalho de Melo wrote: Em Fri, Nov 24, 2017 at 04:16:52PM +0100, Daniel Borkmann escreveu: [ +Yonghong ] On 11/24/2017 03:47 PM, Arnaldo Carvalho de Melo wrote: FYI, just noticed, recently updated clang to version 6, from its upstream git repo. Do you recall

Re: [PATCH v2] checkpatch: Add a warning for log messages that don't end in a new line

On Sun, 2017-11-26 at 06:51 +0100, Julia Lawall wrote: > > On Sat, 25 Nov 2017, Logan Gunthorpe wrote: > > > Check for lines with a log function using a relatively strict regular > > expression catching only printk, dev_* and pr_* functions. Once > > one is found, accumulate further lines for

Re: [PATCH v2] checkpatch: Add a warning for log messages that don't end in a new line

On Sun, 2017-11-26 at 06:51 +0100, Julia Lawall wrote: > > On Sat, 25 Nov 2017, Logan Gunthorpe wrote: > > > Check for lines with a log function using a relatively strict regular > > expression catching only printk, dev_* and pr_* functions. Once > > one is found, accumulate further lines for

Re: [PATCH v2] checkpatch: Add a warning for log messages that don't end in a new line

On Sat, 25 Nov 2017, Logan Gunthorpe wrote: > Check for lines with a log function using a relatively strict regular > expression catching only printk, dev_* and pr_* functions. Once > one is found, accumulate further lines for any functions that > are split over multiple lines. I don't

Re: [PATCH v2] checkpatch: Add a warning for log messages that don't end in a new line

On Sat, 25 Nov 2017, Logan Gunthorpe wrote: > Check for lines with a log function using a relatively strict regular > expression catching only printk, dev_* and pr_* functions. Once > one is found, accumulate further lines for any functions that > are split over multiple lines. I don't

Sparse warnings from sched.h

Hi! Did these: ./include/linux/sched.h:476:62: error: dubious one-bit signed bitfield ./include/linux/sched.h:477:62: error: dubious one-bit signed bitfield ./include/linux/sched.h:478:62: error: dubious one-bit signed bitfield ./include/linux/sched.h:479:62: error: dubious one-bit signed

Sparse warnings from sched.h

Hi! Did these: ./include/linux/sched.h:476:62: error: dubious one-bit signed bitfield ./include/linux/sched.h:477:62: error: dubious one-bit signed bitfield ./include/linux/sched.h:478:62: error: dubious one-bit signed bitfield ./include/linux/sched.h:479:62: error: dubious one-bit signed

[PATCH v2] checkpatch: Add a warning for log messages that don't end in a new line

Check for lines with a log function using a relatively strict regular expression catching only printk, dev_* and pr_* functions. Once one is found, accumulate further lines for any functions that are split over multiple lines. Stop accumulating the log function line when we find a ';' or match the

[PATCH v2] checkpatch: Add a warning for log messages that don't end in a new line

Check for lines with a log function using a relatively strict regular expression catching only printk, dev_* and pr_* functions. Once one is found, accumulate further lines for any functions that are split over multiple lines. Stop accumulating the log function line when we find a ';' or match the

Re: [PATCH] x86/orc: Don't bail on stack overflow

On Sat, Nov 25, 2017 at 10:41:15PM -0600, Josh Poimboeuf wrote: > On Sat, Nov 25, 2017 at 08:25:12PM -0800, Andy Lutomirski wrote: > > On Sat, Nov 25, 2017 at 6:40 PM, Josh Poimboeuf wrote: > > > On Sat, Nov 25, 2017 at 04:16:23PM -0800, Andy Lutomirski wrote: > > >> Can you

Re: [PATCH] x86/orc: Don't bail on stack overflow

On Sat, Nov 25, 2017 at 10:41:15PM -0600, Josh Poimboeuf wrote: > On Sat, Nov 25, 2017 at 08:25:12PM -0800, Andy Lutomirski wrote: > > On Sat, Nov 25, 2017 at 6:40 PM, Josh Poimboeuf wrote: > > > On Sat, Nov 25, 2017 at 04:16:23PM -0800, Andy Lutomirski wrote: > > >> Can you send me whatever

Re: [PATCH] x86/orc: Don't bail on stack overflow

On Sat, Nov 25, 2017 at 08:25:12PM -0800, Andy Lutomirski wrote: > On Sat, Nov 25, 2017 at 6:40 PM, Josh Poimboeuf wrote: > > On Sat, Nov 25, 2017 at 04:16:23PM -0800, Andy Lutomirski wrote: > >> Can you send me whatever config and exact commit hash generated this? > >> I can

Re: [PATCH] x86/orc: Don't bail on stack overflow

On Sat, Nov 25, 2017 at 08:25:12PM -0800, Andy Lutomirski wrote: > On Sat, Nov 25, 2017 at 6:40 PM, Josh Poimboeuf wrote: > > On Sat, Nov 25, 2017 at 04:16:23PM -0800, Andy Lutomirski wrote: > >> Can you send me whatever config and exact commit hash generated this? > >> I can try to figure out

Re: [PATCH] x86/orc: Don't bail on stack overflow

On Sat, Nov 25, 2017 at 6:40 PM, Josh Poimboeuf wrote: > On Sat, Nov 25, 2017 at 04:16:23PM -0800, Andy Lutomirski wrote: >> Can you send me whatever config and exact commit hash generated this? >> I can try to figure out why it failed. > > Sorry, I've been traveling. I just

Re: [PATCH] x86/orc: Don't bail on stack overflow

On Sat, Nov 25, 2017 at 6:40 PM, Josh Poimboeuf wrote: > On Sat, Nov 25, 2017 at 04:16:23PM -0800, Andy Lutomirski wrote: >> Can you send me whatever config and exact commit hash generated this? >> I can try to figure out why it failed. > > Sorry, I've been traveling. I just got some time to

[PATCH] fs: befs: btree: Fixed some coding standard issues

Fixed some coding standard issues. Signed-off-by: Alex Frappier Lachapelle --- fs/befs/btree.c | 97 ++--- 1 file changed, 51 insertions(+), 46 deletions(-) diff --git a/fs/befs/btree.c b/fs/befs/btree.c

[PATCH] fs: befs: btree: Fixed some coding standard issues

Fixed some coding standard issues. Signed-off-by: Alex Frappier Lachapelle --- fs/befs/btree.c | 97 ++--- 1 file changed, 51 insertions(+), 46 deletions(-) diff --git a/fs/befs/btree.c b/fs/befs/btree.c index 1b7e0f7128d6..76a401c48bae

d7be102f29 ("cfg80211: initialize regulatory keys/database later"): kernel BUG at crypto/asymmetric_keys/public_key.c:80!

FYI, we noticed the following commit (built with gcc-4.8): commit: d7be102f2945a626f55e0501e52bb31ba3e77b81 ("cfg80211: initialize regulatory keys/database later") https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git master in testcase: boot on test machine: qemu-system-x86_64

d7be102f29 ("cfg80211: initialize regulatory keys/database later"): kernel BUG at crypto/asymmetric_keys/public_key.c:80!

FYI, we noticed the following commit (built with gcc-4.8): commit: d7be102f2945a626f55e0501e52bb31ba3e77b81 ("cfg80211: initialize regulatory keys/database later") https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git master in testcase: boot on test machine: qemu-system-x86_64

[PATCH] auxdisplay: img-ascii-lcd: add MODULE_LICENSE("GPL")

This matches the header at the top of the file and squashes: WARNING: modpost: missing MODULE_LICENSE() in drivers/auxdisplay/img-ascii-lcd.o see include/linux/module.h for more information Signed-off-by: Daniel Axtens --- drivers/auxdisplay/img-ascii-lcd.c | 2 ++ 1 file

[PATCH] auxdisplay: img-ascii-lcd: add MODULE_LICENSE("GPL")

This matches the header at the top of the file and squashes: WARNING: modpost: missing MODULE_LICENSE() in drivers/auxdisplay/img-ascii-lcd.o see include/linux/module.h for more information Signed-off-by: Daniel Axtens --- drivers/auxdisplay/img-ascii-lcd.c | 2 ++ 1 file changed, 2

Re: [PATCH] x86/orc: Don't bail on stack overflow

On Sat, Nov 25, 2017 at 04:16:23PM -0800, Andy Lutomirski wrote: > Can you send me whatever config and exact commit hash generated this? > I can try to figure out why it failed. Sorry, I've been traveling. I just got some time to take a look at this. I think there are at least two unwinder

Re: [PATCH] x86/orc: Don't bail on stack overflow

On Sat, Nov 25, 2017 at 04:16:23PM -0800, Andy Lutomirski wrote: > Can you send me whatever config and exact commit hash generated this? > I can try to figure out why it failed. Sorry, I've been traveling. I just got some time to take a look at this. I think there are at least two unwinder

[lib/rbtree,drm/mm] 653c9f9a4d: BUG:kernel_hang_in_boot_stage

FYI, we noticed the following commit (built with gcc-5): commit: 653c9f9a4dd8037ffc5afbb1040d15566aa8f533 ("lib/rbtree,drm/mm: Add rbtree_replace_node_cached()") git://anongit.freedesktop.org/drm-intel topic/core-for-CI in testcase: boot on test machine: qemu-system-i386 -enable-kvm -smp 2 -m

[lib/rbtree,drm/mm] 653c9f9a4d: BUG:kernel_hang_in_boot_stage

FYI, we noticed the following commit (built with gcc-5): commit: 653c9f9a4dd8037ffc5afbb1040d15566aa8f533 ("lib/rbtree,drm/mm: Add rbtree_replace_node_cached()") git://anongit.freedesktop.org/drm-intel topic/core-for-CI in testcase: boot on test machine: qemu-system-i386 -enable-kvm -smp 2 -m

Re: [PATCH v2] xfs: handle register_shrinker error

Dave Chinner wrote: > IOWs, we don't actually need to touch this code, but if you really > must, just remove the KM_NOFS tag. OK. Then, please remove KM_NOFS. GFP_KERNEL is safer than GFP_NOFS in the sense that it won't cause OOM lockup due to unable to invoke the OOM killer.

Re: [PATCH v2] xfs: handle register_shrinker error

Dave Chinner wrote: > IOWs, we don't actually need to touch this code, but if you really > must, just remove the KM_NOFS tag. OK. Then, please remove KM_NOFS. GFP_KERNEL is safer than GFP_NOFS in the sense that it won't cause OOM lockup due to unable to invoke the OOM killer.

Re: [PATCH 1/6] perf: Add new type PERF_TYPE_PROBE

On 11/24/17 12:28 AM, Peter Zijlstra wrote: On Thu, Nov 23, 2017 at 10:31:29PM -0800, Alexei Starovoitov wrote: unfortunately 32-bit is more screwed than it seems: $ cat align.c #include struct S { unsigned long long a; } s; struct U { unsigned long long a; } u; int main() {

Re: [PATCH 1/6] perf: Add new type PERF_TYPE_PROBE

On 11/24/17 12:28 AM, Peter Zijlstra wrote: On Thu, Nov 23, 2017 at 10:31:29PM -0800, Alexei Starovoitov wrote: unfortunately 32-bit is more screwed than it seems: $ cat align.c #include struct S { unsigned long long a; } s; struct U { unsigned long long a; } u; int main() {

[PATCH] Staging: comedi: das16: Fixed a const struct coding style issue

Fixed a coding style issue. Signed-off-by: Alex Frappier Lachapelle --- drivers/staging/comedi/drivers/das16.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/staging/comedi/drivers/das16.c

[PATCH] Staging: comedi: das16: Fixed a const struct coding style issue

Fixed a coding style issue. Signed-off-by: Alex Frappier Lachapelle --- drivers/staging/comedi/drivers/das16.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/staging/comedi/drivers/das16.c b/drivers/staging/comedi/drivers/das16.c index

[PATCH v2] Staging: sm750fb: Fix coding style issue in ddk750_sii164.c

This is a patch to the ddk750_sii164.c file that fixes line length warnings found by the checkpatch.pl script Signed-off-by: Jeremy Lacomis --- Changes in v2: - Change definition of i2cReadReg/i2cWriteReg - Remove unnecessary casts drivers/staging/sm750fb/ddk750_sii164.c |

[PATCH v2] Staging: sm750fb: Fix coding style issue in ddk750_sii164.c

This is a patch to the ddk750_sii164.c file that fixes line length warnings found by the checkpatch.pl script Signed-off-by: Jeremy Lacomis --- Changes in v2: - Change definition of i2cReadReg/i2cWriteReg - Remove unnecessary casts drivers/staging/sm750fb/ddk750_sii164.c | 87

Re: [PATCH] Input: elantech - add new icbody type 15

On Sun, Nov 19, 2017 at 10:56:47PM +0800, Aaron Ma wrote: > The touchpad of Lenovo Thinkpad L480 reports it's version as 15. > > Cc: sta...@vger.kernel.org > Signed-off-by: Aaron Ma Applied, thank you. > --- > drivers/input/mouse/elantech.c | 2 +- > 1 file changed, 1

Re: [PATCH] Input: elantech - add new icbody type 15

On Sun, Nov 19, 2017 at 10:56:47PM +0800, Aaron Ma wrote: > The touchpad of Lenovo Thinkpad L480 reports it's version as 15. > > Cc: sta...@vger.kernel.org > Signed-off-by: Aaron Ma Applied, thank you. > --- > drivers/input/mouse/elantech.c | 2 +- > 1 file changed, 1 insertion(+), 1

Re: [PATCH 2/2] staging: rtl8188eu: Fix private WEXT IOCTL calls

Hi, What was broken was private/device specific IOCTL calls implemented by this driver. The standard IOCTL calls worked and the driver worked as it was in client mode. But in AP mode with hostapd (https://w1.fi/hostapd/) the rtl871xdrv driver of hostapd (which is required for using devices

Re: [PATCH 2/2] staging: rtl8188eu: Fix private WEXT IOCTL calls

Hi, What was broken was private/device specific IOCTL calls implemented by this driver. The standard IOCTL calls worked and the driver worked as it was in client mode. But in AP mode with hostapd (https://w1.fi/hostapd/) the rtl871xdrv driver of hostapd (which is required for using devices

Re: [PATCH] input: pegasus_notetaker: add license information

Hi Martin, On Sat, Nov 18, 2017 at 09:45:18AM +0100, Martin Kepplinger wrote: > This adds an SPDX license identifier to this driver I wrote some time back. > > Signed-off-by: Martin Kepplinger > --- > drivers/input/tablet/pegasus_notetaker.c | 1 + > 1 file changed, 1

Re: [PATCH] input: pegasus_notetaker: add license information

Hi Martin, On Sat, Nov 18, 2017 at 09:45:18AM +0100, Martin Kepplinger wrote: > This adds an SPDX license identifier to this driver I wrote some time back. > > Signed-off-by: Martin Kepplinger > --- > drivers/input/tablet/pegasus_notetaker.c | 1 + > 1 file changed, 1 insertion(+) > > diff

[PATCH] rtc: Remove unused RTC_DEVICE_NAME_SIZE

The last usage was removed in 5c82a6ae0 when rtc_device.name was removed Signed-off-by: Cole Robinson --- Just noticed this when looking at commits a few months back... include/linux/rtc.h | 1 - 1 file changed, 1 deletion(-) diff --git a/include/linux/rtc.h

[PATCH] rtc: Remove unused RTC_DEVICE_NAME_SIZE

The last usage was removed in 5c82a6ae0 when rtc_device.name was removed Signed-off-by: Cole Robinson --- Just noticed this when looking at commits a few months back... include/linux/rtc.h | 1 - 1 file changed, 1 deletion(-) diff --git a/include/linux/rtc.h b/include/linux/rtc.h index

Re: [PATCH] ASoC: fsl_ssi: Override bit clock rate based on slot number

On Sat, Nov 25, 2017 at 11:29:48PM +0100, Lukasz Majewski wrote: > Nicolin, do you know what happened with this patch? I couldn't find it > in current linux/master. > > Has it been applied to any asoc tree for being upstreamed? A similar patch with an updated subject got applied:

Re: [PATCH] ASoC: fsl_ssi: Override bit clock rate based on slot number

On Sat, Nov 25, 2017 at 11:29:48PM +0100, Lukasz Majewski wrote: > Nicolin, do you know what happened with this patch? I couldn't find it > in current linux/master. > > Has it been applied to any asoc tree for being upstreamed? A similar patch with an updated subject got applied:

Re: [PATCH 42/43] x86/mm/kaiser: Allow KAISER to be enabled/disabled at runtime

On Sat, Nov 25, 2017 at 2:48 PM, Thomas Gleixner wrote: > On Sat, 25 Nov 2017, Andy Lutomirski wrote: >> > On Nov 25, 2017, at 1:05 PM, Thomas Gleixner wrote: >> > On Sat, 25 Nov 2017, Andy Lutomirski wrote: >> >> Keep in mind that, for a static_branch,

Re: [PATCH 42/43] x86/mm/kaiser: Allow KAISER to be enabled/disabled at runtime

On Sat, Nov 25, 2017 at 2:48 PM, Thomas Gleixner wrote: > On Sat, 25 Nov 2017, Andy Lutomirski wrote: >> > On Nov 25, 2017, at 1:05 PM, Thomas Gleixner wrote: >> > On Sat, 25 Nov 2017, Andy Lutomirski wrote: >> >> Keep in mind that, for a static_branch, actually setting the thing needs >> >> to

Re: [PATCH] Support TrackStick of Thinkpad L570

On Mon, Nov 20, 2017 at 04:55:30PM +0900, Masaki Ota wrote: > From: Masaki Ota > - The issue is that Thinkpad L570 TrackStick does not work. Because the main > interface of Thinkpad L570 device is SMBus, so ALPS overlooked PS2 interface > Firmware setting of TrackStick.

Re: [PATCH] Support TrackStick of Thinkpad L570

On Mon, Nov 20, 2017 at 04:55:30PM +0900, Masaki Ota wrote: > From: Masaki Ota > - The issue is that Thinkpad L570 TrackStick does not work. Because the main > interface of Thinkpad L570 device is SMBus, so ALPS overlooked PS2 interface > Firmware setting of TrackStick. The detail is that

Re: [PATCH] x86/orc: Don't bail on stack overflow

Can you send me whatever config and exact commit hash generated this? I can try to figure out why it failed. On Sat, Nov 25, 2017 at 3:13 PM, Thomas Gleixner wrote: > On Sat, 25 Nov 2017, Andy Lutomirski wrote: > >> On Sat, Nov 25, 2017 at 9:28 AM, Andy Lutomirski

Re: [PATCH] x86/orc: Don't bail on stack overflow

Can you send me whatever config and exact commit hash generated this? I can try to figure out why it failed. On Sat, Nov 25, 2017 at 3:13 PM, Thomas Gleixner wrote: > On Sat, 25 Nov 2017, Andy Lutomirski wrote: > >> On Sat, Nov 25, 2017 at 9:28 AM, Andy Lutomirski wrote: >> > If we overflow the

Re: [PATCH] Support TrackStick of Thinkpad L570

Hi, On Mon, Nov 20, 2017 at 04:55:30PM +0900, Masaki Ota wrote: > From: Masaki Ota > - The issue is that Thinkpad L570 TrackStick does not work. Because the main > interface of Thinkpad L570 device is SMBus, so ALPS overlooked PS2 interface > Firmware setting of

Re: [PATCH] Support TrackStick of Thinkpad L570

Hi, On Mon, Nov 20, 2017 at 04:55:30PM +0900, Masaki Ota wrote: > From: Masaki Ota > - The issue is that Thinkpad L570 TrackStick does not work. Because the main > interface of Thinkpad L570 device is SMBus, so ALPS overlooked PS2 interface > Firmware setting of TrackStick. The detail is that

Re: [PATCH v2] powerpc: fix boot on BOOK3S_32 with CONFIG_STRICT_KERNEL_RWX

On Thu, Nov 23, 2017 at 11:04 PM, Michael Ellerman wrote: > Christophe LEROY writes: >> Le 22/11/2017 à 12:48, Michael Ellerman a écrit : >>> Christophe LEROY writes: Le 22/11/2017 à 00:07, Balbir Singh a écrit : >

Re: [PATCH v2] powerpc: fix boot on BOOK3S_32 with CONFIG_STRICT_KERNEL_RWX

On Thu, Nov 23, 2017 at 11:04 PM, Michael Ellerman wrote: > Christophe LEROY writes: >> Le 22/11/2017 à 12:48, Michael Ellerman a écrit : >>> Christophe LEROY writes: Le 22/11/2017 à 00:07, Balbir Singh a écrit : > On Wed, Nov 22, 2017 at 1:28 AM, Christophe Leroy > wrote: >>

Re: [patch V4 01/11] Documentation: Add license-rules.rst to describe how to properly identify file licenses

Pavel: On Sat, Nov 25, 2017 at 7:51 PM, Pavel Machek wrote: > On Fri 2017-11-17 15:06:39, Mauro Carvalho Chehab wrote: >> Hi Thomas, >> >> Em Fri, 17 Nov 2017 11:00:33 +0100 (CET) >> Thomas Gleixner escreveu: >> >> > Subject: Documentation: Add

Re: [patch V4 01/11] Documentation: Add license-rules.rst to describe how to properly identify file licenses

Pavel: On Sat, Nov 25, 2017 at 7:51 PM, Pavel Machek wrote: > On Fri 2017-11-17 15:06:39, Mauro Carvalho Chehab wrote: >> Hi Thomas, >> >> Em Fri, 17 Nov 2017 11:00:33 +0100 (CET) >> Thomas Gleixner escreveu: >> >> > Subject: Documentation: Add license-rules.rst to describe how to properly >>

Re: [PATCH v2] xfs: handle register_shrinker error

On Fri, Nov 24, 2017 at 09:03:28PM +0900, Tetsuo Handa wrote: > Michal Hocko wrote: > > Thanks. Updated patch below > > --- > > From 1009db61988c48c9a9e327a9d076945b29b02eee Mon Sep 17 00:00:00 2001 > > From: Michal Hocko > > Date: Thu, 23 Nov 2017 17:13:40 +0100 > > Subject:

Re: [PATCH v2] xfs: handle register_shrinker error

On Fri, Nov 24, 2017 at 09:03:28PM +0900, Tetsuo Handa wrote: > Michal Hocko wrote: > > Thanks. Updated patch below > > --- > > From 1009db61988c48c9a9e327a9d076945b29b02eee Mon Sep 17 00:00:00 2001 > > From: Michal Hocko > > Date: Thu, 23 Nov 2017 17:13:40 +0100 > > Subject: [PATCH] xfs: fortify

Re: [GIT PULL] afs: Fixes

Linus Torvalds wrote: > However, even when you do that, the page can be writable in other > mappings. At least fork(), for example, only clears the dirty bit, > doesn't mark it write-protected. I assumed the rmap walk done by page_mkclean() would take care of that

Re: [GIT PULL] afs: Fixes

Linus Torvalds wrote: > However, even when you do that, the page can be writable in other > mappings. At least fork(), for example, only clears the dirty bit, > doesn't mark it write-protected. I assumed the rmap walk done by page_mkclean() would take care of that but I'm not really clear on

Re: [PATCH] x86/orc: Don't bail on stack overflow

On Sat, 25 Nov 2017, Andy Lutomirski wrote: > On Sat, Nov 25, 2017 at 9:28 AM, Andy Lutomirski wrote: > > If we overflow the stack into a guard page and then try to unwind > > it with ORC, it should work perfectly: by construction, there can't > > be any meaningful data in the

Re: [PATCH] x86/orc: Don't bail on stack overflow

On Sat, 25 Nov 2017, Andy Lutomirski wrote: > On Sat, Nov 25, 2017 at 9:28 AM, Andy Lutomirski wrote: > > If we overflow the stack into a guard page and then try to unwind > > it with ORC, it should work perfectly: by construction, there can't > > be any meaningful data in the guard page because

Re: regression: 4.13 cannot follow symlinks on some ext3 fs

Am 25.11.2017 um 23:32 schrieb Dave Chinner: On Fri, Nov 24, 2017 at 03:03:37PM -0700, Andreas Dilger wrote: Any worse an idea than running a new kernel on an old system? Newer e2fsck fixes a lot of bugs that are present in older e2fsck as well... I'm running with everything up to date

Re: regression: 4.13 cannot follow symlinks on some ext3 fs

Am 25.11.2017 um 23:32 schrieb Dave Chinner: On Fri, Nov 24, 2017 at 03:03:37PM -0700, Andreas Dilger wrote: Any worse an idea than running a new kernel on an old system? Newer e2fsck fixes a lot of bugs that are present in older e2fsck as well... I'm running with everything up to date

[PATCH] nvmem: core: let stride and word_size default to 1

If the caller doesn't set stride and/or word_size in struct nvmem_config then nvmem_register accepts this but we may face strange effects later due to both values being 0. Therefore use 1 as default for both values. Signed-off-by: Heiner Kallweit --- drivers/nvmem/core.c

[PATCH] nvmem: core: let stride and word_size default to 1

If the caller doesn't set stride and/or word_size in struct nvmem_config then nvmem_register accepts this but we may face strange effects later due to both values being 0. Therefore use 1 as default for both values. Signed-off-by: Heiner Kallweit --- drivers/nvmem/core.c | 4 ++-- 1 file

Re: regression: 4.13 cannot follow symlinks on some ext3 fs

On Sat, Nov 25, 2017 at 11:45:07PM +0100, Reindl Harald wrote: > > Am 25.11.2017 um 23:32 schrieb Dave Chinner: > >On Fri, Nov 24, 2017 at 03:03:37PM -0700, Andreas Dilger wrote: > >>Any worse an idea than running a new kernel on an old system? > >>Newer e2fsck fixes a lot of bugs that are

Re: regression: 4.13 cannot follow symlinks on some ext3 fs

On Sat, Nov 25, 2017 at 11:45:07PM +0100, Reindl Harald wrote: > > Am 25.11.2017 um 23:32 schrieb Dave Chinner: > >On Fri, Nov 24, 2017 at 03:03:37PM -0700, Andreas Dilger wrote: > >>Any worse an idea than running a new kernel on an old system? > >>Newer e2fsck fixes a lot of bugs that are

Re: [GIT PULL] afs: Fixes

On Sat, Nov 25, 2017 at 12:35 PM, David Howells wrote: > > Doesn't clear_page_dirty_for_io() write-protect the PTE for the page to be > written out, in which case ->page_mkwrite() will get called again before the > page is redirtied? No, it literally just sets the dirty bit

Re: [GIT PULL] afs: Fixes

On Sat, Nov 25, 2017 at 12:35 PM, David Howells wrote: > > Doesn't clear_page_dirty_for_io() write-protect the PTE for the page to be > written out, in which case ->page_mkwrite() will get called again before the > page is redirtied? No, it literally just sets the dirty bit (and does

[PATCH v2] staging: sm750b: Fix coding style issues in sm750_accel.c

This is a patch to sm750_accel.c that fixes 80-character line length warnings found by checkpatch.pl. It also fixes some grammatical errors in comments and moves parameter-specific comments from inline to before the function. Signed-off-by: Jeremy Lacomis --- Changes in v2:

[PATCH v2] staging: sm750b: Fix coding style issues in sm750_accel.c

This is a patch to sm750_accel.c that fixes 80-character line length warnings found by checkpatch.pl. It also fixes some grammatical errors in comments and moves parameter-specific comments from inline to before the function. Signed-off-by: Jeremy Lacomis --- Changes in v2: - Change function

Re: [PATCH 42/43] x86/mm/kaiser: Allow KAISER to be enabled/disabled at runtime

On Sat, 25 Nov 2017, Andy Lutomirski wrote: > > On Nov 25, 2017, at 1:05 PM, Thomas Gleixner wrote: > > On Sat, 25 Nov 2017, Andy Lutomirski wrote: > >> Keep in mind that, for a static_branch, actually setting the thing needs > >> to be deferred, but that's straightforward. >

Re: [PATCH 42/43] x86/mm/kaiser: Allow KAISER to be enabled/disabled at runtime

On Sat, 25 Nov 2017, Andy Lutomirski wrote: > > On Nov 25, 2017, at 1:05 PM, Thomas Gleixner wrote: > > On Sat, 25 Nov 2017, Andy Lutomirski wrote: > >> Keep in mind that, for a static_branch, actually setting the thing needs > >> to be deferred, but that's straightforward. > > > > That's not an

Re: [GIT PULL] afs: Fixes

On Sat, Nov 25, 2017 at 10:35:43PM +, David Howells wrote: > Linus Torvalds wrote: > > > So I see in the commit message why afs needs to do this, but it's > > worth pointing out that it's > > > > (a) impossible to avoid the "inconsistent data" case for

Re: [GIT PULL] afs: Fixes

On Sat, Nov 25, 2017 at 10:35:43PM +, David Howells wrote: > Linus Torvalds wrote: > > > So I see in the commit message why afs needs to do this, but it's > > worth pointing out that it's > > > > (a) impossible to avoid the "inconsistent data" case for writable mmap'ed > > pages > >

Re: [PATCH 0/5] Consolidate init_task handling

I've updated my git branch with changed descriptions, but the content is the same. David

Re: [PATCH 0/5] Consolidate init_task handling

I've updated my git branch with changed descriptions, but the content is the same. David

[PATCH] ALSA: ice1724: Fix resume issues with Prodigy 7.1 HiFi

There are two issues after resuming from suspend on the Audiotrak Prodigy 7.1 HiFi: - the output volume is set to 100% - microphone input isn't working anymore This patch fixes these issues by reinitializing both codecs of the device and restoring the previous volumes during resume.

[PATCH] ALSA: ice1724: Fix resume issues with Prodigy 7.1 HiFi

There are two issues after resuming from suspend on the Audiotrak Prodigy 7.1 HiFi: - the output volume is set to 100% - microphone input isn't working anymore This patch fixes these issues by reinitializing both codecs of the device and restoring the previous volumes during resume.

Re: [PATCH 0/5] Consolidate init_task handling

Linus Torvalds wrote: > Or at least it's a very unusual use of that word. Why doesn't the > explanation just say what it does: "move", and say from where to where > ("from macro to definition" or something)? > > Or "remove macro XYZ, expanding it in place", or

Re: [PATCH 0/5] Consolidate init_task handling

Linus Torvalds wrote: > Or at least it's a very unusual use of that word. Why doesn't the > explanation just say what it does: "move", and say from where to where > ("from macro to definition" or something)? > > Or "remove macro XYZ, expanding it in place", or something? To me, > "unroll" has a

Re: [PATCH] Staging: sm750fb: Fix coding style issue in ddk750_sii164.c

On Sat, 2017-11-25 at 12:59 -0500, Jeremy Lacomis wrote: > This is a patch to the ddk750_sii164.c file that fixes line length warnings > found by the checkpatch.pl script > > Signed-off-by: Jeremy Lacomis > --- > drivers/staging/sm750fb/ddk750_sii164.c | 39 >

Re: [PATCH] Staging: sm750fb: Fix coding style issue in ddk750_sii164.c

On Sat, 2017-11-25 at 12:59 -0500, Jeremy Lacomis wrote: > This is a patch to the ddk750_sii164.c file that fixes line length warnings > found by the checkpatch.pl script > > Signed-off-by: Jeremy Lacomis > --- > drivers/staging/sm750fb/ddk750_sii164.c | 39 > +++--

Re: [GIT PULL] afs: Fixes

Linus Torvalds wrote: > So I see in the commit message why afs needs to do this, but it's > worth pointing out that it's > > (a) impossible to avoid the "inconsistent data" case for writable mmap'ed > pages Doesn't clear_page_dirty_for_io() write-protect the

Re: [GIT PULL] afs: Fixes

Linus Torvalds wrote: > So I see in the commit message why afs needs to do this, but it's > worth pointing out that it's > > (a) impossible to avoid the "inconsistent data" case for writable mmap'ed > pages Doesn't clear_page_dirty_for_io() write-protect the PTE for the page to be written

Re: regression: 4.13 cannot follow symlinks on some ext3 fs

On Fri, Nov 24, 2017 at 03:03:37PM -0700, Andreas Dilger wrote: > On Nov 24, 2017, at 9:51 AM, Andi Kleen wrote: > > > >> We checked old kernels, and old e2fsprogs, and didn't see any cases > >> where fast (<= 60 chars) symlinks were created using external blocks. > >> It

Re: regression: 4.13 cannot follow symlinks on some ext3 fs

On Fri, Nov 24, 2017 at 03:03:37PM -0700, Andreas Dilger wrote: > On Nov 24, 2017, at 9:51 AM, Andi Kleen wrote: > > > >> We checked old kernels, and old e2fsprogs, and didn't see any cases > >> where fast (<= 60 chars) symlinks were created using external blocks. > >> It seems that _something_

Re: [PATCH] ASoC: fsl_ssi: Override bit clock rate based on slot number

Hi Nicolin, > On Wed, Sep 13, 2017 at 10:02:20AM +0200, Arnaud Mouiche wrote: > > > >Could you please give me a few set of examples of how you set > > >set_sysclk(), set_tdm_slot() with the current driver? The idea > > >here is to figure out a way to calculate the bclk in hw_params > > >without

Re: [PATCH] ASoC: fsl_ssi: Override bit clock rate based on slot number

Hi Nicolin, > On Wed, Sep 13, 2017 at 10:02:20AM +0200, Arnaud Mouiche wrote: > > > >Could you please give me a few set of examples of how you set > > >set_sysclk(), set_tdm_slot() with the current driver? The idea > > >here is to figure out a way to calculate the bclk in hw_params > > >without

  1   2   3   4   >