[PATCH v2 1/2] iio: Implement counter channel type and info constants

Quadrature encoders, such as rotary encoders and linear encoders, are devices which are capable of encoding the relative position and direction of motion of a shaft. This patch introduces the counter subdirectory and several IIO constants for supporting quadrature encoder counter devices.

[PATCH v2 0/2] Add IIO support for counter devices

Changes in v2: - New IIO constants have been reduced to three: IIO_COUNT, IIO_INDEX, and IIO_CHAN_INFO_PRESET - 104-QUAD-8 specific flags, modes, and configurations have been broken out and exposed via ext_info elements This patchset adds new IIO channel type and info constants to

Re: [PATCH] random: Fix kernel panic due to system_wq use before init

On Wed, Sep 14, 2016 at 12:14 PM, Waiman Long wrote: > > In the stack backtrace above, the kernel hadn't even reached SMP boot after > about 50s. That was extremely slow. I tried the 4.7.3 kernel and it booted > up fine. So I suspect that there may be too many interrupts

Re: [PATCH] random: Fix kernel panic due to system_wq use before init

On Wed, Sep 14, 2016 at 12:14 PM, Waiman Long wrote: > > In the stack backtrace above, the kernel hadn't even reached SMP boot after > about 50s. That was extremely slow. I tried the 4.7.3 kernel and it booted > up fine. So I suspect that there may be too many interrupts going on and it >

Re: [PATCH 1/6] PCI: xilinx: Keep both legacy and MSI interrupt references.

On Wed, Sep 14, 2016 at 03:32:44PM +, Bharat Kumar Gogada wrote: > On Thu, Sep 01, 2016 at 03:44:41PM +0530, Bharat Kumar Gogada wrote: > > When built with MSI support the legacy domain reference is being > > overwritten with MSI. > > Instead creating two separate domains for MSI and legacy

Re: [PATCH 1/6] PCI: xilinx: Keep both legacy and MSI interrupt references.

On Wed, Sep 14, 2016 at 03:32:44PM +, Bharat Kumar Gogada wrote: > On Thu, Sep 01, 2016 at 03:44:41PM +0530, Bharat Kumar Gogada wrote: > > When built with MSI support the legacy domain reference is being > > overwritten with MSI. > > Instead creating two separate domains for MSI and legacy

Re: [PATCH] random: Fix kernel panic due to system_wq use before init

On 09/14/2016 03:03 PM, Waiman Long wrote: While booting a 4.8-rc6 kernel on a 16-socket 768-thread Broadwell-EX system, the kernel panic'ed with the following log: [ 51.837010] BUG: unable to handle kernel NULL pointer dereference at 0102 [ 51.845635] IP: []

Re: [PATCH] random: Fix kernel panic due to system_wq use before init

On 09/14/2016 03:03 PM, Waiman Long wrote: While booting a 4.8-rc6 kernel on a 16-socket 768-thread Broadwell-EX system, the kernel panic'ed with the following log: [ 51.837010] BUG: unable to handle kernel NULL pointer dereference at 0102 [ 51.845635] IP: []

Re: [PATCH] random: Fix kernel panic due to system_wq use before init

Ugh, I detest this patch. My gut feeling is that a driver (even a fairly core one like the random code) should not have to know these kinds of details like "schedule_work() needs system_wq to have been initialized". I'm wondering if we couldn't just initialize "system_wq" earlier. Right now

Re: [PATCH] random: Fix kernel panic due to system_wq use before init

Ugh, I detest this patch. My gut feeling is that a driver (even a fairly core one like the random code) should not have to know these kinds of details like "schedule_work() needs system_wq to have been initialized". I'm wondering if we couldn't just initialize "system_wq" earlier. Right now

Re: [PATCH] checkpatch: Minimize checkpatch induced patches...

On Wed, 2016-09-14 at 20:54 +0200, Christian Borntraeger wrote: > On 09/14/2016 08:33 PM, Greg KH wrote: > > That's not true, I _WANT_ checkpatch cleanups for the portion of the > > kernel I maintain. It keeps the code correct, up to date, easier to > > maintain, and in doing so, we have found

Re: [PATCH] checkpatch: Minimize checkpatch induced patches...

On Wed, 2016-09-14 at 20:54 +0200, Christian Borntraeger wrote: > On 09/14/2016 08:33 PM, Greg KH wrote: > > That's not true, I _WANT_ checkpatch cleanups for the portion of the > > kernel I maintain. It keeps the code correct, up to date, easier to > > maintain, and in doing so, we have found

[PATCH v3 1/2] rtc-cmos: Clear ACPI-driven alarms upon resume

Currently ACPI-driven alarms are not cleared when they wake the system. As consequence, expired alarms must be manually cleared to program a new alarm. Fix this by correctly handling ACPI-driven alarms. More specifically, the ACPI specification [1] provides for two alternative implementations of

[PATCH v3 2/2] rtc-cmos: Restore alarm after resume

Some platform firmware may interfere with the RTC alarm over suspend, resulting in the kernel and hardware having different ideas about system state but also potentially causing problems with firmware that assumes the OS will clean this case up. This patch restores the RTC alarm on resume to

[PATCH v3 1/2] rtc-cmos: Clear ACPI-driven alarms upon resume

Currently ACPI-driven alarms are not cleared when they wake the system. As consequence, expired alarms must be manually cleared to program a new alarm. Fix this by correctly handling ACPI-driven alarms. More specifically, the ACPI specification [1] provides for two alternative implementations of

[PATCH v3 2/2] rtc-cmos: Restore alarm after resume

Some platform firmware may interfere with the RTC alarm over suspend, resulting in the kernel and hardware having different ideas about system state but also potentially causing problems with firmware that assumes the OS will clean this case up. This patch restores the RTC alarm on resume to

[PATCH tty-next 6/6] devpts: Change the owner of /dev/pts/ptmx to the mounter of /dev/pts

In 99.99% of the cases only root in a user namespace can mount /dev/pts and in those cases the owner of /dev/pts/ptmx will remain root.root In the oddball case where someone else has CAP_SYS_ADMIN this code modifies the /dev/pts mount code to use current_fsuid and current_fsgid as the values to

[PATCH tty-next 6/6] devpts: Change the owner of /dev/pts/ptmx to the mounter of /dev/pts

In 99.99% of the cases only root in a user namespace can mount /dev/pts and in those cases the owner of /dev/pts/ptmx will remain root.root In the oddball case where someone else has CAP_SYS_ADMIN this code modifies the /dev/pts mount code to use current_fsuid and current_fsgid as the values to

[PATCH tty-next 2/6] devpts: Move the creation of /dev/pts/ptmx into fill_super

The code makes more sense here and things are just clearer. Signed-off-by: "Eric W. Biederman" --- fs/devpts/inode.c | 19 +++ 1 file changed, 11 insertions(+), 8 deletions(-) diff --git a/fs/devpts/inode.c b/fs/devpts/inode.c index

[PATCH tty-next 5/6] devpts: Remove sync_filesystems

devpts does not and never will have anything to sync so don't bother calling sync_filesystems on remount. Signed-off-by: "Eric W. Biederman" --- fs/devpts/inode.c | 1 - 1 file changed, 1 deletion(-) diff --git a/fs/devpts/inode.c b/fs/devpts/inode.c index

[PATCH tty-next 2/6] devpts: Move the creation of /dev/pts/ptmx into fill_super

The code makes more sense here and things are just clearer. Signed-off-by: "Eric W. Biederman" --- fs/devpts/inode.c | 19 +++ 1 file changed, 11 insertions(+), 8 deletions(-) diff --git a/fs/devpts/inode.c b/fs/devpts/inode.c index c59d39f2d512..43773543a783 100644 ---

[PATCH tty-next 5/6] devpts: Remove sync_filesystems

devpts does not and never will have anything to sync so don't bother calling sync_filesystems on remount. Signed-off-by: "Eric W. Biederman" --- fs/devpts/inode.c | 1 - 1 file changed, 1 deletion(-) diff --git a/fs/devpts/inode.c b/fs/devpts/inode.c index e058ec677207..17593d3fcdbe 100644 ---

[PATCH tty-next 1/6] devpts: Move parse_mount_options into fill_super

Signed-off-by: "Eric W. Biederman" --- fs/devpts/inode.c | 16 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/fs/devpts/inode.c b/fs/devpts/inode.c index 79a5941c2474..c59d39f2d512 100644 --- a/fs/devpts/inode.c +++ b/fs/devpts/inode.c @@

[PATCH tty-next 3/6] devpts: Simplify devpts_mount by using mount_nodev

Now that all of the work of setting up a superblock has been moved to devpts_fill_super simplify devpts_mount by calling mount_nodev instead of rolling mount_nodev by hand. Signed-off-by: "Eric W. Biederman" --- fs/devpts/inode.c | 19 +-- 1 file changed,

[PATCH tty-next 4/6] devpts: Make devpts_kill_sb safe if fsi is NULL

Signed-off-by: "Eric W. Biederman" --- fs/devpts/inode.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/fs/devpts/inode.c b/fs/devpts/inode.c index a48b40b0bd1e..e058ec677207 100644 --- a/fs/devpts/inode.c +++ b/fs/devpts/inode.c @@ -458,7 +458,8 @@

[PATCH tty-next 4/6] devpts: Make devpts_kill_sb safe if fsi is NULL

Signed-off-by: "Eric W. Biederman" --- fs/devpts/inode.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/fs/devpts/inode.c b/fs/devpts/inode.c index a48b40b0bd1e..e058ec677207 100644 --- a/fs/devpts/inode.c +++ b/fs/devpts/inode.c @@ -458,7 +458,8 @@ static void

[PATCH tty-next 1/6] devpts: Move parse_mount_options into fill_super

Signed-off-by: "Eric W. Biederman" --- fs/devpts/inode.c | 16 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/fs/devpts/inode.c b/fs/devpts/inode.c index 79a5941c2474..c59d39f2d512 100644 --- a/fs/devpts/inode.c +++ b/fs/devpts/inode.c @@ -395,6 +395,7 @@ static

[PATCH tty-next 3/6] devpts: Simplify devpts_mount by using mount_nodev

Now that all of the work of setting up a superblock has been moved to devpts_fill_super simplify devpts_mount by calling mount_nodev instead of rolling mount_nodev by hand. Signed-off-by: "Eric W. Biederman" --- fs/devpts/inode.c | 19 +-- 1 file changed, 1 insertion(+), 18

Re: [RFC v3 07/22] landlock: Handle file comparisons

On Wed, Sep 14, 2016 at 09:24:00AM +0200, Mickaël Salaün wrote: > Add eBPF functions to compare file system access with a Landlock file > system handle: > * bpf_landlock_cmp_fs_prop_with_struct_file(prop, map, map_op, file) > This function allows to compare the dentry, inode, device or mount >

Re: [RFC v3 07/22] landlock: Handle file comparisons

On Wed, Sep 14, 2016 at 09:24:00AM +0200, Mickaël Salaün wrote: > Add eBPF functions to compare file system access with a Landlock file > system handle: > * bpf_landlock_cmp_fs_prop_with_struct_file(prop, map, map_op, file) > This function allows to compare the dentry, inode, device or mount >

[PATCH tty-next 0/6] Minor devpts cleanups, fixes and enhancments

Greg please apply the following patches to tty-next. If tty-next is not the proper tree please let me know and I will take these patches through my user namespace tree. The follow patches perform a few small cleanups and one enhancement to devpts, with a net decrease in code size. The big

[PATCH tty-next 0/6] Minor devpts cleanups, fixes and enhancments

Greg please apply the following patches to tty-next. If tty-next is not the proper tree please let me know and I will take these patches through my user namespace tree. The follow patches perform a few small cleanups and one enhancement to devpts, with a net decrease in code size. The big

Re: [GIT PULL] Greybus driver subsystem for 4.9-rc1

On Wed, 2016-09-14 at 20:29 +0200, Greg KH wrote: trivial note: > +static size_t gb_timesync_log_frame_time(struct gb_timesync_svc > *timesync_svc, > + char *buf, size_t buflen) > +{ > + struct gb_svc *svc = timesync_svc->svc; > + struct

Re: [GIT PULL] Greybus driver subsystem for 4.9-rc1

On Wed, 2016-09-14 at 20:29 +0200, Greg KH wrote: trivial note: > +static size_t gb_timesync_log_frame_time(struct gb_timesync_svc > *timesync_svc, > + char *buf, size_t buflen) > +{ > + struct gb_svc *svc = timesync_svc->svc; > + struct

[PATCH] random: Fix kernel panic due to system_wq use before init

While booting a 4.8-rc6 kernel on a 16-socket 768-thread Broadwell-EX system, the kernel panic'ed with the following log: [ 51.837010] BUG: unable to handle kernel NULL pointer dereference at 0102 [ 51.845635] IP: [] __queue_work+0x32/0x420 [ 52.004366] Call Trace: [

[PATCH] random: Fix kernel panic due to system_wq use before init

While booting a 4.8-rc6 kernel on a 16-socket 768-thread Broadwell-EX system, the kernel panic'ed with the following log: [ 51.837010] BUG: unable to handle kernel NULL pointer dereference at 0102 [ 51.845635] IP: [] __queue_work+0x32/0x420 [ 52.004366] Call Trace: [

Re: rfc: Updating SubmittingPatches with [RFC PATCH] and/or [WIP PATCH]

On Wed, 07 Sep 2016 12:47:41 -0700 Joe Perches wrote: > +If the patch or patch series is just a proposal to garner comments > +use [RFC PATCH] before each patch subject. > + > +If the patch or patch seriies is incomplete or possibly contains known > +defects and you would like

Re: rfc: Updating SubmittingPatches with [RFC PATCH] and/or [WIP PATCH]

On Wed, 07 Sep 2016 12:47:41 -0700 Joe Perches wrote: > +If the patch or patch series is just a proposal to garner comments > +use [RFC PATCH] before each patch subject. > + > +If the patch or patch seriies is incomplete or possibly contains known > +defects and you would like others to see the

[PATCH v2 6/7] leds: gpio: switch to managed version of led_classdev_register

Using the managed version of led_classdev_register allows to significantly simplify the code. Signed-off-by: Heiner Kallweit --- v2: - rebased due to removal of patch 2 of the original series --- drivers/leds/leds-gpio.c | 23 ++- 1 file changed, 2

[PATCH v2 4/7] leds: gpio: simplify gpio_leds_create

Definition of np can be moved into the loop as well to simplify the code a little. Signed-off-by: Heiner Kallweit --- v2: - rebased due to removal of patch 2 of the original series --- drivers/leds/leds-gpio.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff

[PATCH v2 5/7] leds: gpio: fix and simplify reading property "label"

Checking for the presence of the property first isn't strictly needed as we can react on the return code of fwnode_property_read_string. Also, even if the presence of a property "label" was checked, reading a string value for it theoretically still can fail and this case isn't handled.

[PATCH v2 6/7] leds: gpio: switch to managed version of led_classdev_register

Using the managed version of led_classdev_register allows to significantly simplify the code. Signed-off-by: Heiner Kallweit --- v2: - rebased due to removal of patch 2 of the original series --- drivers/leds/leds-gpio.c | 23 ++- 1 file changed, 2 insertions(+), 21

[PATCH v2 4/7] leds: gpio: simplify gpio_leds_create

Definition of np can be moved into the loop as well to simplify the code a little. Signed-off-by: Heiner Kallweit --- v2: - rebased due to removal of patch 2 of the original series --- drivers/leds/leds-gpio.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git

[PATCH v2 5/7] leds: gpio: fix and simplify reading property "label"

Checking for the presence of the property first isn't strictly needed as we can react on the return code of fwnode_property_read_string. Also, even if the presence of a property "label" was checked, reading a string value for it theoretically still can fail and this case isn't handled.

[PATCH v2 1/7] leds: gpio: introduce gpio_blink_set_t

Introduce a typedef gpio_blink_set_t to improve readability of the code. Signed-off-by: Heiner Kallweit --- v2: - no change --- drivers/leds/leds-gpio.c | 6 ++ include/linux/leds.h | 9 ++--- 2 files changed, 8 insertions(+), 7 deletions(-) diff --git

[PATCH v2 1/7] leds: gpio: introduce gpio_blink_set_t

Introduce a typedef gpio_blink_set_t to improve readability of the code. Signed-off-by: Heiner Kallweit --- v2: - no change --- drivers/leds/leds-gpio.c | 6 ++ include/linux/leds.h | 9 ++--- 2 files changed, 8 insertions(+), 7 deletions(-) diff --git a/drivers/leds/leds-gpio.c

[PATCH v2 2/7] leds: gpio: fix an unhandled error case in create_gpio_led

gpiod_get_value_cansleep returns 0, 1, or an error code. So far errors are not handled and treated the same as 1. Change this to bail out if an error code is returned and remove the double negation. Signed-off-by: Heiner Kallweit --- v2: - rebased due to removal of patch 2

[PATCH v2 3/7] leds: gpio: add helper cdev_to_gpio_led_data

Add a helper for the container_of as it's used more than once. Signed-off-by: Heiner Kallweit --- v2: - rebased due to removal of patch 2 of the original series --- drivers/leds/leds-gpio.c | 12 1 file changed, 8 insertions(+), 4 deletions(-) diff --git

[PATCH v2 7/7] leds: gpio: fix and simplify error handling in gpio_leds_create

Simplify the error handling and add a missing call to fwnode_handle_put when checking led.name. Signed-off-by: Heiner Kallweit --- v2: - rebased due to removal of patch 2 of the original series --- drivers/leds/leds-gpio.c | 12 1 file changed, 4

[PATCH v2 2/7] leds: gpio: fix an unhandled error case in create_gpio_led

gpiod_get_value_cansleep returns 0, 1, or an error code. So far errors are not handled and treated the same as 1. Change this to bail out if an error code is returned and remove the double negation. Signed-off-by: Heiner Kallweit --- v2: - rebased due to removal of patch 2 of the original series

[PATCH v2 3/7] leds: gpio: add helper cdev_to_gpio_led_data

Add a helper for the container_of as it's used more than once. Signed-off-by: Heiner Kallweit --- v2: - rebased due to removal of patch 2 of the original series --- drivers/leds/leds-gpio.c | 12 1 file changed, 8 insertions(+), 4 deletions(-) diff --git a/drivers/leds/leds-gpio.c

[PATCH v2 7/7] leds: gpio: fix and simplify error handling in gpio_leds_create

Simplify the error handling and add a missing call to fwnode_handle_put when checking led.name. Signed-off-by: Heiner Kallweit --- v2: - rebased due to removal of patch 2 of the original series --- drivers/leds/leds-gpio.c | 12 1 file changed, 4 insertions(+), 8 deletions(-) diff

Re: [PATCH 4/5] HID:hid-logitech: Rewrite of descriptor for all DF wheels

On Fri, September 9, 2016 7:34 pm, kbuild test robot wrote: > All warnings (new ones prefixed by >>): > > > drivers/hid/hid-lg.c: In function 'lg_report_fixup': > >>> drivers/hid/hid-lg.c:347:28: warning: unused variable 'rev_min' >>> [-Wunused-variable] >>> > __u16 bcdDevice, rev_maj, rev_min; >

Re: [PATCH 4/5] HID:hid-logitech: Rewrite of descriptor for all DF wheels

On Fri, September 9, 2016 7:34 pm, kbuild test robot wrote: > All warnings (new ones prefixed by >>): > > > drivers/hid/hid-lg.c: In function 'lg_report_fixup': > >>> drivers/hid/hid-lg.c:347:28: warning: unused variable 'rev_min' >>> [-Wunused-variable] >>> > __u16 bcdDevice, rev_maj, rev_min; >

Re: [PATCH v5 1/5] vfs: Add current_time() api

On Wed, 14 Sep 2016, Deepa Dinamani wrote: > +/** > + * current_time - Return FS time > + * @inode: inode. > + * > + * Return the current time truncated to the time granularity supported by > + * the fs. > + * > + * Note that inode and inode->sb cannot be NULL. > + * Otherwise, the function warns

Re: [PATCH v5 1/5] vfs: Add current_time() api

On Wed, 14 Sep 2016, Deepa Dinamani wrote: > +/** > + * current_time - Return FS time > + * @inode: inode. > + * > + * Return the current time truncated to the time granularity supported by > + * the fs. > + * > + * Note that inode and inode->sb cannot be NULL. > + * Otherwise, the function warns

Re: [PATCH] checkpatch: Minimize checkpatch induced patches...

On 09/14/2016 08:33 PM, Greg KH wrote: > On Wed, Sep 14, 2016 at 08:16:55PM +0200, Christian Borntraeger wrote: >> On 09/14/2016 08:06 PM, Joe Perches wrote: >>> On Wed, 2016-09-14 at 19:56 +0200, Christian Borntraeger wrote: >>> This will certainly help to reduce the noise. On the other hand

Re: [PATCH] checkpatch: Minimize checkpatch induced patches...

On 09/14/2016 08:33 PM, Greg KH wrote: > On Wed, Sep 14, 2016 at 08:16:55PM +0200, Christian Borntraeger wrote: >> On 09/14/2016 08:06 PM, Joe Perches wrote: >>> On Wed, 2016-09-14 at 19:56 +0200, Christian Borntraeger wrote: >>> This will certainly help to reduce the noise. On the other hand

Re: [PATCH] prctl,x86 Add PR_[GET|SET]_CPUID for controlling the CPUID instruction.

On Tue, Sep 13, 2016 at 11:13 PM, Kyle Huey wrote: > On Mon, Sep 12, 2016 at 9:56 AM, Andy Lutomirski wrote: >> You should explicitly check that, if the >> feature is set under Xen PV, then the MSR actually works as >> advertised. This may require talking

Re: [PATCH] prctl,x86 Add PR_[GET|SET]_CPUID for controlling the CPUID instruction.

On Tue, Sep 13, 2016 at 11:13 PM, Kyle Huey wrote: > On Mon, Sep 12, 2016 at 9:56 AM, Andy Lutomirski wrote: >> You should explicitly check that, if the >> feature is set under Xen PV, then the MSR actually works as >> advertised. This may require talking to the Xen folks to make sure >> you're

Re: [RFC v3 03/22] bpf,landlock: Add a new arraymap type to deal with (Landlock) handles

On Wed, Sep 14, 2016 at 09:23:56AM +0200, Mickaël Salaün wrote: > This new arraymap looks like a set and brings new properties: > * strong typing of entries: the eBPF functions get the array type of > elements instead of CONST_PTR_TO_MAP (e.g. > CONST_PTR_TO_LANDLOCK_HANDLE_FS); > * force

Re: [RFC v3 03/22] bpf,landlock: Add a new arraymap type to deal with (Landlock) handles

On Wed, Sep 14, 2016 at 09:23:56AM +0200, Mickaël Salaün wrote: > This new arraymap looks like a set and brings new properties: > * strong typing of entries: the eBPF functions get the array type of > elements instead of CONST_PTR_TO_MAP (e.g. > CONST_PTR_TO_LANDLOCK_HANDLE_FS); > * force

Re: [PATCH] clk-kona-setup: Use kmalloc_array() in parent_process()

On 09/14/2016 01:40 PM, SF Markus Elfring wrote: > From: Markus Elfring > Date: Wed, 14 Sep 2016 20:26:05 +0200 > > A multiplication for the size determination of a memory allocation > indicated that an array data structure should be processed. > Thus use the

Re: [PATCH net-next 2/2] net: deprecate eth_change_mtu, remove usage

On Wed, Sep 14, 2016 at 05:59:14AM +0800, kbuild test robot wrote: > Hi Jarod, > > [auto build test ERROR on net-next/master] > > url: > https://github.com/0day-ci/linux/commits/Jarod-Wilson/net-centralize-net_device-min-max-MTU-checking/20160913-042130 > config: mips-xway_defconfig

Re: [PATCH] clk-kona-setup: Use kmalloc_array() in parent_process()

On 09/14/2016 01:40 PM, SF Markus Elfring wrote: > From: Markus Elfring > Date: Wed, 14 Sep 2016 20:26:05 +0200 > > A multiplication for the size determination of a memory allocation > indicated that an array data structure should be processed. > Thus use the corresponding function

Re: [PATCH net-next 2/2] net: deprecate eth_change_mtu, remove usage

On Wed, Sep 14, 2016 at 05:59:14AM +0800, kbuild test robot wrote: > Hi Jarod, > > [auto build test ERROR on net-next/master] > > url: > https://github.com/0day-ci/linux/commits/Jarod-Wilson/net-centralize-net_device-min-max-MTU-checking/20160913-042130 > config: mips-xway_defconfig

Re: [RFC v3 11/22] seccomp,landlock: Handle Landlock hooks per process hierarchy

On Wed, Sep 14, 2016 at 12:24 AM, Mickaël Salaün wrote: > A Landlock program will be triggered according to its subtype/origin > bitfield. The LANDLOCK_FLAG_ORIGIN_SECCOMP value will trigger the > Landlock program when a seccomp filter will return RET_LANDLOCK. > Moreover, it is

Re: [RFC v3 11/22] seccomp,landlock: Handle Landlock hooks per process hierarchy

On Wed, Sep 14, 2016 at 12:24 AM, Mickaël Salaün wrote: > A Landlock program will be triggered according to its subtype/origin > bitfield. The LANDLOCK_FLAG_ORIGIN_SECCOMP value will trigger the > Landlock program when a seccomp filter will return RET_LANDLOCK. > Moreover, it is possible to

Re: TRIM/UNMAP/DISCARD via ATA Passthrough

> "Jason" == Jason A Donenfeld writes: Jason, Jason> These USB enclosures do not support SCSI UNMAP. However, they do Jason> support ATA-passthrough, and `hdparm -I` shows that TRIM is Jason> supported. How do they signal that they support the passthrough? -- Martin K.

Re: TRIM/UNMAP/DISCARD via ATA Passthrough

> "Jason" == Jason A Donenfeld writes: Jason, Jason> These USB enclosures do not support SCSI UNMAP. However, they do Jason> support ATA-passthrough, and `hdparm -I` shows that TRIM is Jason> supported. How do they signal that they support the passthrough? -- Martin K. Petersen

Re: [PATCH v3 00/14] Clock improvement for video playback

On 08/29, gabriel.fernan...@st.com wrote: > From: Gabriel Fernandez > > v3: > - Rebase to v4.8-rc1 > - Tipo fix in st,clkgen-pll.txt > - Add Ack of Peter for the series > - Add missed patch: "ARM: DT: STiH4xx: Simplify clock binding of STiH4xx > platforms" > >

Re: [PATCH v3 00/14] Clock improvement for video playback

On 08/29, gabriel.fernan...@st.com wrote: > From: Gabriel Fernandez > > v3: > - Rebase to v4.8-rc1 > - Tipo fix in st,clkgen-pll.txt > - Add Ack of Peter for the series > - Add missed patch: "ARM: DT: STiH4xx: Simplify clock binding of STiH4xx > platforms" > > v2: > - Simpliflication

[PATCH] clk-kona-setup: Use kmalloc_array() in parent_process()

From: Markus Elfring Date: Wed, 14 Sep 2016 20:26:05 +0200 A multiplication for the size determination of a memory allocation indicated that an array data structure should be processed. Thus use the corresponding function "kmalloc_array". This issue was detected

[PATCH] clk-kona-setup: Use kmalloc_array() in parent_process()

From: Markus Elfring Date: Wed, 14 Sep 2016 20:26:05 +0200 A multiplication for the size determination of a memory allocation indicated that an array data structure should be processed. Thus use the corresponding function "kmalloc_array". This issue was detected by using the Coccinelle

Re: [PATCH 08/12] x86/dumpstack: Pin the target stack in save_stack_trace_tsk()

On Wed, Sep 14, 2016 at 11:22:00AM -0700, Andy Lutomirski wrote: > On Wed, Sep 14, 2016 at 7:55 AM, Josh Poimboeuf wrote: > > On Tue, Sep 13, 2016 at 02:29:28PM -0700, Andy Lutomirski wrote: > >> This will prevent a crash if the target task dies before or while > >> dumping

Re: [PATCH 08/12] x86/dumpstack: Pin the target stack in save_stack_trace_tsk()

On Wed, Sep 14, 2016 at 11:22:00AM -0700, Andy Lutomirski wrote: > On Wed, Sep 14, 2016 at 7:55 AM, Josh Poimboeuf wrote: > > On Tue, Sep 13, 2016 at 02:29:28PM -0700, Andy Lutomirski wrote: > >> This will prevent a crash if the target task dies before or while > >> dumping its stack once we

Re: [PATCH] checkpatch: Minimize checkpatch induced patches...

On Wed, Sep 14, 2016 at 08:16:55PM +0200, Christian Borntraeger wrote: > On 09/14/2016 08:06 PM, Joe Perches wrote: > > On Wed, 2016-09-14 at 19:56 +0200, Christian Borntraeger wrote: > > > >> This will certainly help to reduce the noise. On the other hand I remember > >> Linus > >> saying

Re: [PATCH] checkpatch: Minimize checkpatch induced patches...

On Wed, Sep 14, 2016 at 08:16:55PM +0200, Christian Borntraeger wrote: > On 09/14/2016 08:06 PM, Joe Perches wrote: > > On Wed, 2016-09-14 at 19:56 +0200, Christian Borntraeger wrote: > > > >> This will certainly help to reduce the noise. On the other hand I remember > >> Linus > >> saying

Re: [RFC v3 18/22] cgroup,landlock: Add CGRP_NO_NEW_PRIVS to handle unprivileged hooks

On Wed, Sep 14, 2016 at 12:24 AM, Mickaël Salaün wrote: > Add a new flag CGRP_NO_NEW_PRIVS for each cgroup. This flag is initially > set for all cgroup except the root. The flag is clear when a new process > without the no_new_privs flags is attached to the cgroup. > > If a

Re: [RFC v3 18/22] cgroup,landlock: Add CGRP_NO_NEW_PRIVS to handle unprivileged hooks

On Wed, Sep 14, 2016 at 12:24 AM, Mickaël Salaün wrote: > Add a new flag CGRP_NO_NEW_PRIVS for each cgroup. This flag is initially > set for all cgroup except the root. The flag is clear when a new process > without the no_new_privs flags is attached to the cgroup. > > If a cgroup is landlocked,

Re: [PATCHv5 0/6] x86: 32-bit compatible C/R on x86_64

On 09/05/2016 04:33 PM, Dmitry Safonov wrote: Changes from v4: - check both vm_ops and vm_private_data to avoid (unlikely) confusion with some other vma in map_vdso_once (as Andy noticed) - which would lead to unable to use this API in that unlikely-case (vm_private_data may be

Re: [PATCHv5 0/6] x86: 32-bit compatible C/R on x86_64

On 09/05/2016 04:33 PM, Dmitry Safonov wrote: Changes from v4: - check both vm_ops and vm_private_data to avoid (unlikely) confusion with some other vma in map_vdso_once (as Andy noticed) - which would lead to unable to use this API in that unlikely-case (vm_private_data may be

[PATCH] ARM: s3c24xx: Add dma_slave_map for s3c2440 devices

This patch updates the s3c24xx dma driver to be able to pass a dma_slave_map array via the platform data. This is needed to be able to use the new, simpler dmaengine API [1]. I used the virtual DMA channels as a parameter for the dma_filter function. By doing that, I could reuse the existing

[PATCH] ARM: s3c24xx: Add dma_slave_map for s3c2440 devices

This patch updates the s3c24xx dma driver to be able to pass a dma_slave_map array via the platform data. This is needed to be able to use the new, simpler dmaengine API [1]. I used the virtual DMA channels as a parameter for the dma_filter function. By doing that, I could reuse the existing

Re: [GIT PULL] Greybus driver subsystem for 4.9-rc1

On Wed, Sep 14, 2016 at 08:07:54PM +0200, Greg KH wrote: > On Wed, Sep 14, 2016 at 06:36:26PM +0100, Mark Rutland wrote: > > Hi Greg, > > > > On Wed, Sep 14, 2016 at 12:09:49PM +0200, Greg KH wrote: > > > Given that it's never a good idea to keep subsystems out of the mainline > > > kernel, I've

Re: [GIT PULL] Greybus driver subsystem for 4.9-rc1

On Wed, Sep 14, 2016 at 08:07:54PM +0200, Greg KH wrote: > On Wed, Sep 14, 2016 at 06:36:26PM +0100, Mark Rutland wrote: > > Hi Greg, > > > > On Wed, Sep 14, 2016 at 12:09:49PM +0200, Greg KH wrote: > > > Given that it's never a good idea to keep subsystems out of the mainline > > > kernel, I've

Re: [RFC v3 19/22] landlock: Add interrupted origin

On Wed, Sep 14, 2016 at 12:24 AM, Mickaël Salaün wrote: > This third origin of hook call should cover all possible trigger paths > (e.g. page fault). Landlock eBPF programs can then take decisions > accordingly. > > Signed-off-by: Mickaël Salaün > Cc: Alexei

Re: [RFC v3 19/22] landlock: Add interrupted origin

On Wed, Sep 14, 2016 at 12:24 AM, Mickaël Salaün wrote: > This third origin of hook call should cover all possible trigger paths > (e.g. page fault). Landlock eBPF programs can then take decisions > accordingly. > > Signed-off-by: Mickaël Salaün > Cc: Alexei Starovoitov > Cc: Andy Lutomirski >

Re: [PATCH v3 0/4] tpm/tpm_crb: implement power management.

On Wed, Sep 14, 2016 at 07:06:52PM +0300, Jarkko Sakkinen wrote: > On Wed, Sep 14, 2016 at 07:06:02PM +0300, Jarkko Sakkinen wrote: > > On Wed, Sep 14, 2016 at 06:28:03AM +, Winkler, Tomas wrote: > > > On Mon, 2016-09-12 at 16:04 +0300, Tomas Winkler wrote: > > > > Te overall platform ability

Re: [PATCH v3 0/4] tpm/tpm_crb: implement power management.

On Wed, Sep 14, 2016 at 07:06:52PM +0300, Jarkko Sakkinen wrote: > On Wed, Sep 14, 2016 at 07:06:02PM +0300, Jarkko Sakkinen wrote: > > On Wed, Sep 14, 2016 at 06:28:03AM +, Winkler, Tomas wrote: > > > On Mon, 2016-09-12 at 16:04 +0300, Tomas Winkler wrote: > > > > Te overall platform ability

Re: [PATCH] clk: st: clk-flexgen: Unmap region obtained by of_iomap

On 09/14, arvind.yadav...@gmail.com wrote: > @@ -337,6 +339,8 @@ static void __init st_of_flexgen_setup(struct device_node > *np) > return; > > err: > + if (reg) This is always true? Why check? > + iounmap(reg); > if (clk_data) >

Re: [PATCH] clk: st: clk-flexgen: Unmap region obtained by of_iomap

On 09/14, arvind.yadav...@gmail.com wrote: > @@ -337,6 +339,8 @@ static void __init st_of_flexgen_setup(struct device_node > *np) > return; > > err: > + if (reg) This is always true? Why check? > + iounmap(reg); > if (clk_data) >

Re: [PATCH] checkpatch: Minimize checkpatch induced patches...

On 09/14/2016 08:21 PM, Joe Perches wrote: > On Wed, 2016-09-14 at 20:16 +0200, Christian Borntraeger wrote: >> You know what. >> with some additional writing like >> "Existing code outside staging is not supposed to be "fixed" to match >> checkpatch. >> Please do not send checkpatch initiated

Re: [PATCH] checkpatch: Minimize checkpatch induced patches...

On 09/14/2016 08:21 PM, Joe Perches wrote: > On Wed, 2016-09-14 at 20:16 +0200, Christian Borntraeger wrote: >> You know what. >> with some additional writing like >> "Existing code outside staging is not supposed to be "fixed" to match >> checkpatch. >> Please do not send checkpatch initiated

Re: [PATCH 08/12] x86/dumpstack: Pin the target stack in save_stack_trace_tsk()

On Wed, Sep 14, 2016 at 7:55 AM, Josh Poimboeuf wrote: > On Tue, Sep 13, 2016 at 02:29:28PM -0700, Andy Lutomirski wrote: >> This will prevent a crash if the target task dies before or while >> dumping its stack once we start freeing task stacks early. >> >> Signed-off-by:

Re: [PATCH 08/12] x86/dumpstack: Pin the target stack in save_stack_trace_tsk()

On Wed, Sep 14, 2016 at 7:55 AM, Josh Poimboeuf wrote: > On Tue, Sep 13, 2016 at 02:29:28PM -0700, Andy Lutomirski wrote: >> This will prevent a crash if the target task dies before or while >> dumping its stack once we start freeing task stacks early. >> >> Signed-off-by: Andy Lutomirski > > Do

[PATCH] drm/vc4: Fall back to using an EDID probe in the absence of a GPIO.

On Pi0/1/2, we use an external GPIO line for hotplug detection, since the HDMI_HOTPLUG register isn't connected to anything. However, with the Pi3 the HPD GPIO line has moved off to a GPIO expander that will be tricky to get to (the firmware is constantly polling the expander using i2c0, so we'll

Re: [PATCH] checkpatch: Minimize checkpatch induced patches...

On Wed, 2016-09-14 at 20:16 +0200, Christian Borntraeger wrote: > You know what.  > with some additional writing like  > "Existing code outside staging is not supposed to be "fixed" to match > checkpatch. > Please do not send checkpatch initiated patches for those files" > near the newly created

[PATCH] drm/vc4: Fall back to using an EDID probe in the absence of a GPIO.

On Pi0/1/2, we use an external GPIO line for hotplug detection, since the HDMI_HOTPLUG register isn't connected to anything. However, with the Pi3 the HPD GPIO line has moved off to a GPIO expander that will be tricky to get to (the firmware is constantly polling the expander using i2c0, so we'll

Re: [PATCH] checkpatch: Minimize checkpatch induced patches...

On Wed, 2016-09-14 at 20:16 +0200, Christian Borntraeger wrote: > You know what.  > with some additional writing like  > "Existing code outside staging is not supposed to be "fixed" to match > checkpatch. > Please do not send checkpatch initiated patches for those files" > near the newly created

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