Re: Regression in i915 for 4.11-rc1 - bisected to commit 69df05e11ab8

On Thu, Mar 23, 2017 at 01:19:43PM -0500, Larry Finger wrote: > Since kernel 4.11-rc1, my desktop (Plasma5/KDE) has encountered > intermittent hangs with the following information in the logs: > > linux-4v1g.suse kernel: [drm] GPU HANG: ecode 7:0:0xf3ce, in > plasmashell [1283], reason: Hang

Re: [RESEND PATCH v2] staging:speakup: Fix alignment with parenthesis.

On Thu, Mar 23, 2017 at 07:15:38PM +0530, Arushi Singhal wrote: > Fix checkpatch issues: "CHECK: Alignment should match open parenthesis". > > Signed-off-by: Arushi Singhal I can't take patches sent in html format :( please fix your email client. thanks,

Re: Regression in i915 for 4.11-rc1 - bisected to commit 69df05e11ab8

On Thu, Mar 23, 2017 at 01:19:43PM -0500, Larry Finger wrote: > Since kernel 4.11-rc1, my desktop (Plasma5/KDE) has encountered > intermittent hangs with the following information in the logs: > > linux-4v1g.suse kernel: [drm] GPU HANG: ecode 7:0:0xf3ce, in > plasmashell [1283], reason: Hang

Re: [RESEND PATCH v2] staging:speakup: Fix alignment with parenthesis.

On Thu, Mar 23, 2017 at 07:15:38PM +0530, Arushi Singhal wrote: > Fix checkpatch issues: "CHECK: Alignment should match open parenthesis". > > Signed-off-by: Arushi Singhal I can't take patches sent in html format :( please fix your email client. thanks, greg k-h

Re: [PATCH] staging: lustre: Replace a bit shift by a use of BIT.

On Mar 22, 2017, at 06:12, Dilger, Andreas wrote: > > On Mar 21, 2017, at 22:39, Arushi Singhal > wrote: >> >> This patch replaces bit shifting on 1 with the BIT(x) macro. >> This was done with coccinelle: [snip] >> diff --git

Re: [PATCH] staging: lustre: Replace a bit shift by a use of BIT.

On Mar 22, 2017, at 06:12, Dilger, Andreas wrote: > > On Mar 21, 2017, at 22:39, Arushi Singhal > wrote: >> >> This patch replaces bit shifting on 1 with the BIT(x) macro. >> This was done with coccinelle: [snip] >> diff --git a/drivers/staging/lustre/lnet/lnet/net_fault.c >>

Re: [PATCH v4 1/4] pinctrl: rockchip: remove unnecessary locking

On Thu, Mar 23, 2017 at 09:01:43PM +0100, Heiko St?bner wrote: > Am Donnerstag, 23. März 2017, 13:29:10 CET schrieb Julia Cartwright: > > On Thu, Mar 23, 2017 at 06:55:50PM +0100, Heiko St?bner wrote: > > > Am Donnerstag, 23. März 2017, 17:51:53 CET schrieb John Keeping: > > > > On Thu, 23 Mar

Re: [PATCH v4 1/4] pinctrl: rockchip: remove unnecessary locking

On Thu, Mar 23, 2017 at 09:01:43PM +0100, Heiko St?bner wrote: > Am Donnerstag, 23. März 2017, 13:29:10 CET schrieb Julia Cartwright: > > On Thu, Mar 23, 2017 at 06:55:50PM +0100, Heiko St?bner wrote: > > > Am Donnerstag, 23. März 2017, 17:51:53 CET schrieb John Keeping: > > > > On Thu, 23 Mar

Re: [PATCH v2] KVM: kvm_io_bus_unregister_dev() should never fail

On Thu, Mar 23, 2017 at 06:24:19PM +0100, David Hildenbrand wrote: > No caller currently checks the return value of > kvm_io_bus_unregister_dev(). This is evil, as all callers silently go on > freeing their device. A stale reference will remain in the io_bus, > getting at least used again, when

Re: [PATCH v2] KVM: kvm_io_bus_unregister_dev() should never fail

On Thu, Mar 23, 2017 at 06:24:19PM +0100, David Hildenbrand wrote: > No caller currently checks the return value of > kvm_io_bus_unregister_dev(). This is evil, as all callers silently go on > freeing their device. A stale reference will remain in the io_bus, > getting at least used again, when

[PATCH] crypto: xts,lrw - fix out-of-bounds write after kmalloc failure

From: Eric Biggers In the generic XTS and LRW algorithms, for input data > 128 bytes, a temporary buffer is allocated to hold the values to be XOR'ed with the data before and after encryption or decryption. If the allocation fails, the fixed-size buffer embedded in the

[PATCH] crypto: xts,lrw - fix out-of-bounds write after kmalloc failure

From: Eric Biggers In the generic XTS and LRW algorithms, for input data > 128 bytes, a temporary buffer is allocated to hold the values to be XOR'ed with the data before and after encryption or decryption. If the allocation fails, the fixed-size buffer embedded in the request buffer is meant

Re: [PATCH 3/5] i2c: i2c-stm32f7: add driver

> Yes the STM32F7 has a new I2C IP core compared to STM32F4. > The engine, the machine state are very different. > I tried few months ago to write a common driver but it was very very > difficilcut as the 2 IP are not so much things in common. Good, thanks for the heads up! signature.asc

Re: [PATCH 3/5] i2c: i2c-stm32f7: add driver

> Yes the STM32F7 has a new I2C IP core compared to STM32F4. > The engine, the machine state are very different. > I tried few months ago to write a common driver but it was very very > difficilcut as the 2 IP are not so much things in common. Good, thanks for the heads up! signature.asc

Re: [PATCH v2 02/14] i2c: mv64xxx: simplify optional reset handling

On Wed, Mar 15, 2017 at 12:31:34PM +0100, Philipp Zabel wrote: > As of commit bb475230b8e5 ("reset: make optional functions really > optional"), the reset framework API calls use NULL pointers to describe > optional, non-present reset controls. > > This allows to return errors from

Re: [PATCH v2 02/14] i2c: mv64xxx: simplify optional reset handling

On Wed, Mar 15, 2017 at 12:31:34PM +0100, Philipp Zabel wrote: > As of commit bb475230b8e5 ("reset: make optional functions really > optional"), the reset framework API calls use NULL pointers to describe > optional, non-present reset controls. > > This allows to return errors from

Re: [PATCH v2] staging: lustre: Replace a bit shift by a use of BIT.

On Mar 22, 2017, at 09:53, Arushi Singhal wrote: > > This patch replaces bit shifting on 1 with the BIT(x) macro. > This was done with coccinelle: > @@ > constant c; > @@ > > -1 << c > +BIT(c) > > Signed-off-by: Arushi Singhal

Re: [PATCH v2] staging: lustre: Replace a bit shift by a use of BIT.

On Mar 22, 2017, at 09:53, Arushi Singhal wrote: > > This patch replaces bit shifting on 1 with the BIT(x) macro. > This was done with coccinelle: > @@ > constant c; > @@ > > -1 << c > +BIT(c) > > Signed-off-by: Arushi Singhal Reviewed-by: Andreas Dilger > --- > changes in v2 > - remove

Re: [PATCH 3/5] i2c: i2c-stm32f7: add driver

Hi Wolfram, Yes the STM32F7 has a new I2C IP core compared to STM32F4. The engine, the machine state are very different. I tried few months ago to write a common driver but it was very very difficilcut as the 2 IP are not so much things in common. BR, Cedric 2017-03-23 21:17 GMT+01:00 Wolfram

Re: [PATCH 3/5] i2c: i2c-stm32f7: add driver

Hi Wolfram, Yes the STM32F7 has a new I2C IP core compared to STM32F4. The engine, the machine state are very different. I tried few months ago to write a common driver but it was very very difficilcut as the 2 IP are not so much things in common. BR, Cedric 2017-03-23 21:17 GMT+01:00 Wolfram

Re: [PATCH 1/3] perf/x86: add sysfs entry to freeze counter on SMI

On Thu, Mar 23, 2017 at 11:25:49AM -0700, kan.li...@intel.com wrote: > + for_each_possible_cpu(cpu) { > + rdmsrl_on_cpu(cpu, MSR_IA32_DEBUGCTLMSR, ); > + if (val) > + wrmsrl_on_cpu(cpu, MSR_IA32_DEBUGCTLMSR, debugctlmsr | >

Re: [PATCH 1/3] perf/x86: add sysfs entry to freeze counter on SMI

On Thu, Mar 23, 2017 at 11:25:49AM -0700, kan.li...@intel.com wrote: > + for_each_possible_cpu(cpu) { > + rdmsrl_on_cpu(cpu, MSR_IA32_DEBUGCTLMSR, ); > + if (val) > + wrmsrl_on_cpu(cpu, MSR_IA32_DEBUGCTLMSR, debugctlmsr | >

Re: [PATCH 04/46] selinux: Use kmalloc_array() in hashtab_create()

On Sun, Jan 15, 2017 at 10:01 AM, SF Markus Elfring wrote: > From: Markus Elfring > Date: Sat, 14 Jan 2017 12:06:13 +0100 > > A multiplication for the size determination of a memory allocation > indicated that an array data structure

Re: [PATCH 04/46] selinux: Use kmalloc_array() in hashtab_create()

On Sun, Jan 15, 2017 at 10:01 AM, SF Markus Elfring wrote: > From: Markus Elfring > Date: Sat, 14 Jan 2017 12:06:13 +0100 > > 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: crypto: out-of-bounds write in pre_crypt

Hi Dmitry, On Thu, Mar 23, 2017 at 11:51:30AM +0100, Dmitry Vyukov wrote: > Hello, > > I've got the following report while running syzkaller fuzzer. > init_crypt ignores kmalloc failure, which later leads to out-of-bounds > writes in ptr_crypt. On commit >

Re: crypto: out-of-bounds write in pre_crypt

Hi Dmitry, On Thu, Mar 23, 2017 at 11:51:30AM +0100, Dmitry Vyukov wrote: > Hello, > > I've got the following report while running syzkaller fuzzer. > init_crypt ignores kmalloc failure, which later leads to out-of-bounds > writes in ptr_crypt. On commit >

Re: [PATCH 05/46] selinux: Adjust four checks for null pointers

On Sun, Jan 15, 2017 at 10:02 AM, SF Markus Elfring wrote: > From: Markus Elfring > Date: Sat, 14 Jan 2017 12:36:59 +0100 > MIME-Version: 1.0 > Content-Type: text/plain; charset=UTF-8 > Content-Transfer-Encoding: 8bit > > The script

Re: [PATCH 05/46] selinux: Adjust four checks for null pointers

On Sun, Jan 15, 2017 at 10:02 AM, SF Markus Elfring wrote: > From: Markus Elfring > Date: Sat, 14 Jan 2017 12:36:59 +0100 > MIME-Version: 1.0 > Content-Type: text/plain; charset=UTF-8 > Content-Transfer-Encoding: 8bit > > The script "checkpatch.pl" pointed information out like the following. > >

Re: [PATCH 1/2] leds: Add driver for Qualcomm LPG

Hi! > The Light Pulse Generator (LPG) is a PWM-block found in a wide range of > PMICs from Qualcomm. It can operate on fixed parameters or based on a > lookup-table, altering the duty cycle over time - which provides the > means for e.g. hardware assisted transitions of LED brightness. Ok, this

Re: [PATCH v5 3/4] arm/syscalls: Specific usage of verify_pre_usermode_state

On Thu, Mar 23, 2017 at 10:25 AM, Thomas Garnier wrote: > Implement specific usage of verify_pre_usermode_state for user-mode > returns for arm. Signed-off-by: Thomas Garnier Not sure why it was not there anymore. -- Thomas

Re: [PATCH 1/2] leds: Add driver for Qualcomm LPG

Hi! > The Light Pulse Generator (LPG) is a PWM-block found in a wide range of > PMICs from Qualcomm. It can operate on fixed parameters or based on a > lookup-table, altering the duty cycle over time - which provides the > means for e.g. hardware assisted transitions of LED brightness. Ok, this

Re: [PATCH v5 3/4] arm/syscalls: Specific usage of verify_pre_usermode_state

On Thu, Mar 23, 2017 at 10:25 AM, Thomas Garnier wrote: > Implement specific usage of verify_pre_usermode_state for user-mode > returns for arm. Signed-off-by: Thomas Garnier Not sure why it was not there anymore. -- Thomas

Re: [PATCH v5 4/4] arm64/syscalls: Specific usage of verify_pre_usermode_state

On Thu, Mar 23, 2017 at 10:25 AM, Thomas Garnier wrote: > Implement specific usage of verify_pre_usermode_state for user-mode > returns for arm64. Signed-off-by: Thomas Garnier Not sure why it was not there anymore. -- Thomas

Re: [PATCH v5 4/4] arm64/syscalls: Specific usage of verify_pre_usermode_state

On Thu, Mar 23, 2017 at 10:25 AM, Thomas Garnier wrote: > Implement specific usage of verify_pre_usermode_state for user-mode > returns for arm64. Signed-off-by: Thomas Garnier Not sure why it was not there anymore. -- Thomas

Re: [PATCH v5 2/4] x86/syscalls: Specific usage of verify_pre_usermode_state

On Thu, Mar 23, 2017 at 10:25 AM, Thomas Garnier wrote: > Implement specific usage of verify_pre_usermode_state for user-mode > returns for x86. Signed-off-by: Thomas Garnier Not sure why it was not there anymore. -- Thomas

Re: [PATCH v5 2/4] x86/syscalls: Specific usage of verify_pre_usermode_state

On Thu, Mar 23, 2017 at 10:25 AM, Thomas Garnier wrote: > Implement specific usage of verify_pre_usermode_state for user-mode > returns for x86. Signed-off-by: Thomas Garnier Not sure why it was not there anymore. -- Thomas

Re: security, hugetlbfs: write to user memory in hugetlbfs_destroy_inode

On 03/23/2017 06:49 AM, Tetsuo Handa wrote: > Dmitry Vyukov wrote: >> On Thu, Mar 23, 2017 at 2:06 PM, Dmitry Vyukov wrote: >>> Hello, >>> >>> I've got the following report while running syzkaller fuzzer on >>> 093b995e3b55a0ae0670226ddfcb05bfbf0099ae. Note the preceding

Re: security, hugetlbfs: write to user memory in hugetlbfs_destroy_inode

On 03/23/2017 06:49 AM, Tetsuo Handa wrote: > Dmitry Vyukov wrote: >> On Thu, Mar 23, 2017 at 2:06 PM, Dmitry Vyukov wrote: >>> Hello, >>> >>> I've got the following report while running syzkaller fuzzer on >>> 093b995e3b55a0ae0670226ddfcb05bfbf0099ae. Note the preceding injected >>> kmalloc

[PATCH] lkdtm: add bad USER_DS test

This adds CORRUPT_USER_DS to check that the get_fs() test on syscall return still sees USER_DS during the new VERIFY_PRE_USERMODE_STATE checks. Signed-off-by: Kees Cook --- drivers/misc/lkdtm.h | 1 + drivers/misc/lkdtm_bugs.c | 20

[PATCH] lkdtm: add bad USER_DS test

This adds CORRUPT_USER_DS to check that the get_fs() test on syscall return still sees USER_DS during the new VERIFY_PRE_USERMODE_STATE checks. Signed-off-by: Kees Cook --- drivers/misc/lkdtm.h | 1 + drivers/misc/lkdtm_bugs.c | 20 drivers/misc/lkdtm_core.c | 1 + 3

Re: [PATCH 1/3] perf/x86: add sysfs entry to freeze counter on SMI

On Thu, Mar 23, 2017 at 11:25:49AM -0700, kan.li...@intel.com wrote: > From: Kan Liang > > When setting FREEZE_WHILE_SMM bit in IA32_DEBUGCTL, all performance > counters will be effected. There is no way to do per-counter freeze > on smi. So it should not use the per-event

Re: [PATCH 1/3] perf/x86: add sysfs entry to freeze counter on SMI

On Thu, Mar 23, 2017 at 11:25:49AM -0700, kan.li...@intel.com wrote: > From: Kan Liang > > When setting FREEZE_WHILE_SMM bit in IA32_DEBUGCTL, all performance > counters will be effected. There is no way to do per-counter freeze > on smi. So it should not use the per-event interface (e.g. ioctl

Re: [PATCH 03/46] selinux: Improve size determinations in four functions

On Sun, Jan 15, 2017 at 10:00 AM, SF Markus Elfring wrote: > From: Markus Elfring > Date: Sat, 14 Jan 2017 11:22:12 +0100 > > Replace the specification of data structures by pointer dereferences > as the parameter for the operator

Re: [PATCH 03/46] selinux: Improve size determinations in four functions

On Sun, Jan 15, 2017 at 10:00 AM, SF Markus Elfring wrote: > From: Markus Elfring > Date: Sat, 14 Jan 2017 11:22:12 +0100 > > Replace the specification of data structures by pointer dereferences > as the parameter for the operator "sizeof" to make the corresponding size > determination a bit

Re: [PATCH v1 6/8] gpio: acpi: Explain how to get GPIO descriptors in ACPI case

On Thu, Mar 23, 2017 at 09:46:16PM +0200, Andy Shevchenko wrote: > Documentation lacks of explanation how we actually use device properties > for GPIO resources. > > Add a section to the documentation about that. > > Suggested-by: Mika Westerberg >

Re: [PATCH v1 6/8] gpio: acpi: Explain how to get GPIO descriptors in ACPI case

On Thu, Mar 23, 2017 at 09:46:16PM +0200, Andy Shevchenko wrote: > Documentation lacks of explanation how we actually use device properties > for GPIO resources. > > Add a section to the documentation about that. > > Suggested-by: Mika Westerberg > Signed-off-by: Andy Shevchenko > --- >

Re: [PATCH 00/13] Add HD44780 Character LCD support

Hi Willy, On Thu, Mar 23, 2017 at 8:03 PM, Willy TARREAU wrote: > On Thu, Mar 23, 2017 at 07:49:53PM +0100, Geert Uytterhoeven wrote: >> I take it you're using v1 of the patchset? >> >> v2 had this change: >> >> - Move backlight mutex initialization before call to >>

Re: [PATCH 00/13] Add HD44780 Character LCD support

Hi Willy, On Thu, Mar 23, 2017 at 8:03 PM, Willy TARREAU wrote: > On Thu, Mar 23, 2017 at 07:49:53PM +0100, Geert Uytterhoeven wrote: >> I take it you're using v1 of the patchset? >> >> v2 had this change: >> >> - Move backlight mutex initialization before call to >>

Re: [PATCH 02/46] selinux: Delete an unnecessary return statement in cond_compute_av()

On Sun, Jan 15, 2017 at 9:58 AM, SF Markus Elfring wrote: > From: Markus Elfring > Date: Sat, 14 Jan 2017 11:00:23 +0100 > > The script "checkpatch.pl" pointed information out like the following. > > WARNING: void function return

Re: [PATCH 02/46] selinux: Delete an unnecessary return statement in cond_compute_av()

On Sun, Jan 15, 2017 at 9:58 AM, SF Markus Elfring wrote: > From: Markus Elfring > Date: Sat, 14 Jan 2017 11:00:23 +0100 > > The script "checkpatch.pl" pointed information out like the following. > > WARNING: void function return statements are not generally useful > > Thus remove such a

Re: [PATCH] hwmon: asus_atk0110.c fix uninitialized data access

On Thu, Mar 23, 2017 at 04:03:11PM +0100, Arnd Bergmann wrote: > The latest gcc-7 snapshot adds a warning to point out that when > atk_read_value_old or atk_read_value_new fails, we copy > uninitialized data into sensor->cached_value: > > drivers/hwmon/asus_atk0110.c: In function

Re: [PATCH] hwmon: asus_atk0110.c fix uninitialized data access

On Thu, Mar 23, 2017 at 04:03:11PM +0100, Arnd Bergmann wrote: > The latest gcc-7 snapshot adds a warning to point out that when > atk_read_value_old or atk_read_value_new fails, we copy > uninitialized data into sensor->cached_value: > > drivers/hwmon/asus_atk0110.c: In function

Re: [PATCH 01/46] selinux: Use kmalloc_array() in cond_init_bool_indexes()

On Sun, Jan 15, 2017 at 9:56 AM, SF Markus Elfring wrote: > From: Markus Elfring > Date: Sat, 14 Jan 2017 10:48:28 +0100 > > * A multiplication for the size determination of a memory allocation > indicated that an array data

Re: [PATCH 01/46] selinux: Use kmalloc_array() in cond_init_bool_indexes()

On Sun, Jan 15, 2017 at 9:56 AM, SF Markus Elfring wrote: > From: Markus Elfring > Date: Sat, 14 Jan 2017 10:48:28 +0100 > > * A multiplication for the size determination of a memory allocation > indicated that an array data structure should be processed. > Thus use the corresponding

[PATCH] ACPI / gpio: do not fall back to parsing _CRS when we get a deferral

If, while locating GPIOs by name, we get probe deferral, we should immediately report it to caller rather than trying to fall back to parsing unnamed GPIOs from _CRS block. Signed-off-by: Dmitry Torokhov --- drivers/gpio/gpiolib-acpi.c | 4 +++- 1 file changed, 3

[PATCH] ACPI / gpio: do not fall back to parsing _CRS when we get a deferral

If, while locating GPIOs by name, we get probe deferral, we should immediately report it to caller rather than trying to fall back to parsing unnamed GPIOs from _CRS block. Signed-off-by: Dmitry Torokhov --- drivers/gpio/gpiolib-acpi.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)

Re: [PATCH v1 3/8] gpio: acpi: Do sanity check for GpioInt in acpi_find_gpio()

On Thu, Mar 23, 2017 at 09:46:13PM +0200, Andy Shevchenko wrote: > Check that we don't ask for output direction on GpioInt resource in cases with > or without _DSD defined. > > Signed-off-by: Andy Shevchenko Reviewed-by: Dmitry Torokhov

Re: [PATCH v1 3/8] gpio: acpi: Do sanity check for GpioInt in acpi_find_gpio()

On Thu, Mar 23, 2017 at 09:46:13PM +0200, Andy Shevchenko wrote: > Check that we don't ask for output direction on GpioInt resource in cases with > or without _DSD defined. > > Signed-off-by: Andy Shevchenko Reviewed-by: Dmitry Torokhov > --- > drivers/gpio/gpiolib-acpi.c | 10 +- >

Re: [PATCH 3/5] i2c: i2c-stm32f7: add driver

On Fri, Mar 17, 2017 at 10:58:56AM +0100, M'boumba Cedric Madianga wrote: > This patch adds initial support for the STM32F7 I2C controller. > > Signed-off-by: M'boumba Cedric Madianga So, the STM32F7 has a new I2C IP core compared to STM32F4? signature.asc

Re: [PATCH 3/5] i2c: i2c-stm32f7: add driver

On Fri, Mar 17, 2017 at 10:58:56AM +0100, M'boumba Cedric Madianga wrote: > This patch adds initial support for the STM32F7 I2C controller. > > Signed-off-by: M'boumba Cedric Madianga So, the STM32F7 has a new I2C IP core compared to STM32F4? signature.asc Description: PGP signature

Re: [RFT PATCH 5/6] pinctrl: meson: use gpio-ranges from DT

Hi Neil, On Thu, Mar 23, 2017 at 5:27 PM, Neil Armstrong wrote: > When trying to add a gpio-hog, we enter a weird loop where the gpio-ranges > is needed when gpiochip_add_data() is called but in the current implementation > the ranges are added from the driver

Re: [RFT PATCH 5/6] pinctrl: meson: use gpio-ranges from DT

Hi Neil, On Thu, Mar 23, 2017 at 5:27 PM, Neil Armstrong wrote: > When trying to add a gpio-hog, we enter a weird loop where the gpio-ranges > is needed when gpiochip_add_data() is called but in the current implementation > the ranges are added from the driver afterwards. > > A simple solution

Re: [PATCH v5 1/4] syscalls: Restore address limit after a syscall

On Thu, Mar 23, 2017 at 10:25 AM, Thomas Garnier wrote: > This patch ensures a syscall does not return to user-mode with a kernel > address limit. If that happened, a process can corrupt kernel-mode > memory and elevate privileges. > > For example, it would mitigation this

Re: [PATCH v5 1/4] syscalls: Restore address limit after a syscall

On Thu, Mar 23, 2017 at 10:25 AM, Thomas Garnier wrote: > This patch ensures a syscall does not return to user-mode with a kernel > address limit. If that happened, a process can corrupt kernel-mode > memory and elevate privileges. > > For example, it would mitigation this bug: > > -

Re: [PATCH v1 2/8] gpio: acpi: Align acpi_find_gpio() with DT version

On Thu, Mar 23, 2017 at 09:46:12PM +0200, Andy Shevchenko wrote: > By some reason acpi_find_gpio() and acpi_gpio_count() have compared connection > ID to "gpios" when tries to check if suffix is needed or not. > > Don't do any assumptions about what connection ID can be and, when defined, > use

Re: [PATCH v1 2/8] gpio: acpi: Align acpi_find_gpio() with DT version

On Thu, Mar 23, 2017 at 09:46:12PM +0200, Andy Shevchenko wrote: > By some reason acpi_find_gpio() and acpi_gpio_count() have compared connection > ID to "gpios" when tries to check if suffix is needed or not. > > Don't do any assumptions about what connection ID can be and, when defined, > use

Re: [PATCH v1 4/8] gpio: acpi: Even more tighten up ACPI GPIO lookups

On Thu, Mar 23, 2017 at 09:46:14PM +0200, Andy Shevchenko wrote: > The commit 10cf4899f8af ("gpiolib: tighten up ACPI legacy gpio lookups") > prevents to getting same resource twice if the driver asks twice using same s/same/different/ > connection ID. > > But the whole idea of fallback might

Re: [PATCH v1 4/8] gpio: acpi: Even more tighten up ACPI GPIO lookups

On Thu, Mar 23, 2017 at 09:46:14PM +0200, Andy Shevchenko wrote: > The commit 10cf4899f8af ("gpiolib: tighten up ACPI legacy gpio lookups") > prevents to getting same resource twice if the driver asks twice using same s/same/different/ > connection ID. > > But the whole idea of fallback might

Re: [PATCH V2] i2c: tegra-bpmp: Enable Tegra BPMP I2C adapter

On Thu, Mar 23, 2017 at 11:56:56AM +, Jon Hunter wrote: > Enable the Tegra BPMP I2C adapter by default if the Tegra BPMP itself > is enabled. This adapter is used as the I2C interface for the PMIC on > the Tegra186 Jetson-TX2 platform. > > Signed-off-by: Jon Hunter >

Re: [PATCH V2] i2c: tegra-bpmp: Enable Tegra BPMP I2C adapter

On Thu, Mar 23, 2017 at 11:56:56AM +, Jon Hunter wrote: > Enable the Tegra BPMP I2C adapter by default if the Tegra BPMP itself > is enabled. This adapter is used as the I2C interface for the PMIC on > the Tegra186 Jetson-TX2 platform. > > Signed-off-by: Jon Hunter > Acked-by: Thierry Reding

Re: RAID array is gone, please help

OK, I used gdisk to remove the GPT and MBR from each disk. mdadm --assemble still doesn't work... says it can't find the superblock. The mdadm --examine commands also say that no superblock is detected. I guess I'll go ahead with --create... On 3/23/2017 20:59, Lennart Sorensen wrote: On Thu,

Re: RAID array is gone, please help

OK, I used gdisk to remove the GPT and MBR from each disk. mdadm --assemble still doesn't work... says it can't find the superblock. The mdadm --examine commands also say that no superblock is detected. I guess I'll go ahead with --create... On 3/23/2017 20:59, Lennart Sorensen wrote: On Thu,

Re: [PATCH] qedf: fix wrong le16 conversion

David Miller writes: >> Dave: Since you queued the firmware patch, mind taking this fix through >> your tree? > > Ok, applied to net-next, thanks. Great, thanks! -- Martin K. Petersen Oracle Linux Engineering

Re: [PATCH] qedf: fix wrong le16 conversion

David Miller writes: >> Dave: Since you queued the firmware patch, mind taking this fix through >> your tree? > > Ok, applied to net-next, thanks. Great, thanks! -- Martin K. Petersen Oracle Linux Engineering

Re: [PATCH v4 1/4] pinctrl: rockchip: remove unnecessary locking

Am Donnerstag, 23. März 2017, 13:29:10 CET schrieb Julia Cartwright: > On Thu, Mar 23, 2017 at 06:55:50PM +0100, Heiko St?bner wrote: > > Am Donnerstag, 23. März 2017, 17:51:53 CET schrieb John Keeping: > > > On Thu, 23 Mar 2017 11:10:20 -0500, Julia Cartwright wrote: > [..] > > > > > [..] > > >

Re: [PATCH v4 1/4] pinctrl: rockchip: remove unnecessary locking

Am Donnerstag, 23. März 2017, 13:29:10 CET schrieb Julia Cartwright: > On Thu, Mar 23, 2017 at 06:55:50PM +0100, Heiko St?bner wrote: > > Am Donnerstag, 23. März 2017, 17:51:53 CET schrieb John Keeping: > > > On Thu, 23 Mar 2017 11:10:20 -0500, Julia Cartwright wrote: > [..] > > > > > [..] > > >

Re: RAID array is gone, please help

On Thu, Mar 23, 2017 at 08:38:08PM +0100, Stephen Mueller wrote: > Apologies, I should have started this on linux-raid... > > > stephen@fred> sudo gdisk -l /dev/sdc > GPT fdisk (gdisk) version 1.0.1 > > Partition table scan: > MBR: protective > BSD: not present > APM: not present > GPT:

Re: RAID array is gone, please help

On Thu, Mar 23, 2017 at 08:38:08PM +0100, Stephen Mueller wrote: > Apologies, I should have started this on linux-raid... > > > stephen@fred> sudo gdisk -l /dev/sdc > GPT fdisk (gdisk) version 1.0.1 > > Partition table scan: > MBR: protective > BSD: not present > APM: not present > GPT:

Re: [PATCH 4/4] tty/serial: sh-sci: remove uneeded IS_ERR_OR_NULL calls

On Thu, Mar 23, 2017 at 08:10:20PM +0100, Uwe Kleine-König wrote: > On Thu, Mar 23, 2017 at 08:44:41AM -0700, Dmitry Torokhov wrote: > > On Thu, Mar 23, 2017 at 07:43:25AM -0700, Dmitry Torokhov wrote: > > > On Thu, Mar 23, 2017 at 02:41:53PM +0100, Linus Walleij wrote: > > > > On Thu, Mar 23,

Re: [PATCH 4/4] tty/serial: sh-sci: remove uneeded IS_ERR_OR_NULL calls

On Thu, Mar 23, 2017 at 08:10:20PM +0100, Uwe Kleine-König wrote: > On Thu, Mar 23, 2017 at 08:44:41AM -0700, Dmitry Torokhov wrote: > > On Thu, Mar 23, 2017 at 07:43:25AM -0700, Dmitry Torokhov wrote: > > > On Thu, Mar 23, 2017 at 02:41:53PM +0100, Linus Walleij wrote: > > > > On Thu, Mar 23,

[RFC v5 6/9] sched/deadline: make GRUB a task's flag

From: Luca Abeni Signed-off-by: Luca Abeni Tested-by: Daniel Bristot de Oliveira --- include/uapi/linux/sched.h | 1 + kernel/sched/core.c| 3 ++- kernel/sched/deadline.c| 3 ++- 3 files changed, 5

[RFC v5 6/9] sched/deadline: make GRUB a task's flag

From: Luca Abeni Signed-off-by: Luca Abeni Tested-by: Daniel Bristot de Oliveira --- include/uapi/linux/sched.h | 1 + kernel/sched/core.c| 3 ++- kernel/sched/deadline.c| 3 ++- 3 files changed, 5 insertions(+), 2 deletions(-) diff --git a/include/uapi/linux/sched.h

[RFC v5 4/9] sched/deadline: implement GRUB accounting

From: Luca Abeni According to the GRUB (Greedy Reclaimation of Unused Bandwidth) reclaiming algorithm, the runtime is not decreased as "dq = -dt", but as "dq = -Uact dt" (where Uact is the per-runqueue active utilization). Hence, this commit modifies the runtime

[RFC v5 4/9] sched/deadline: implement GRUB accounting

From: Luca Abeni According to the GRUB (Greedy Reclaimation of Unused Bandwidth) reclaiming algorithm, the runtime is not decreased as "dq = -dt", but as "dq = -Uact dt" (where Uact is the per-runqueue active utilization). Hence, this commit modifies the runtime accounting rule in

[RFC v5 1/9] sched/deadline: track the active utilization

From: Luca Abeni Active utilization is defined as the total utilization of active (TASK_RUNNING) tasks queued on a runqueue. Hence, it is increased when a task wakes up and is decreased when a task blocks. When a task is migrated from CPUi to CPUj, immediately subtract the

[RFC v5 1/9] sched/deadline: track the active utilization

From: Luca Abeni Active utilization is defined as the total utilization of active (TASK_RUNNING) tasks queued on a runqueue. Hence, it is increased when a task wakes up and is decreased when a task blocks. When a task is migrated from CPUi to CPUj, immediately subtract the task's utilization

[RFC v5 7/9] sched/deadline: track the "total rq utilization" too

From: Luca Abeni The total rq utilization is defined as the sum of the utilisations of tasks that are "assigned" to a runqueue, independently from their state (TASK_RUNNING or blocked) Signed-off-by: Luca Abeni Signed-off-by: Claudio

[RFC v5 8/9] sched/deadline: base GRUB reclaiming on the inactive utilization

From: Luca Abeni Instead of decreasing the runtime as "dq = -Uact dt" (eventually divided by the maximum utilization available for deadline tasks), decrease it as "dq = -(1 - Uinact) dt", where Uinact is the "inactive utilization". In this way, the maximum fraction of

[RFC v5 7/9] sched/deadline: track the "total rq utilization" too

From: Luca Abeni The total rq utilization is defined as the sum of the utilisations of tasks that are "assigned" to a runqueue, independently from their state (TASK_RUNNING or blocked) Signed-off-by: Luca Abeni Signed-off-by: Claudio Scordino Tested-by: Daniel Bristot de Oliveira ---

[RFC v5 8/9] sched/deadline: base GRUB reclaiming on the inactive utilization

From: Luca Abeni Instead of decreasing the runtime as "dq = -Uact dt" (eventually divided by the maximum utilization available for deadline tasks), decrease it as "dq = -(1 - Uinact) dt", where Uinact is the "inactive utilization". In this way, the maximum fraction of CPU time that can be

[RFC v5 5/9] sched/deadline: do not reclaim the whole CPU bandwidth

From: Luca Abeni Original GRUB tends to reclaim 100% of the CPU time... And this allows a CPU hog to starve non-deadline tasks. To address this issue, allow the scheduler to reclaim only a specified fraction of CPU time. Signed-off-by: Luca Abeni

[RFC v5 5/9] sched/deadline: do not reclaim the whole CPU bandwidth

From: Luca Abeni Original GRUB tends to reclaim 100% of the CPU time... And this allows a CPU hog to starve non-deadline tasks. To address this issue, allow the scheduler to reclaim only a specified fraction of CPU time. Signed-off-by: Luca Abeni Tested-by: Daniel Bristot de Oliveira ---

[RFC v5 0/9] CPU reclaiming for SCHED_DEADLINE

From: Luca Abeni Hi all, here is yet another version of the patchset implementing CPU reclaiming (using the GRUB algorithm[1]) for SCHED_DEADLINE. Basically, this feature allows SCHED_DEADLINE tasks to consume more than their reserved runtime, up to a maximum

[RFC v5 0/9] CPU reclaiming for SCHED_DEADLINE

From: Luca Abeni Hi all, here is yet another version of the patchset implementing CPU reclaiming (using the GRUB algorithm[1]) for SCHED_DEADLINE. Basically, this feature allows SCHED_DEADLINE tasks to consume more than their reserved runtime, up to a maximum fraction of the CPU time (so that

[RFC v5 2/9] sched/deadline: improve the tracking of active utilization

From: Luca Abeni This patch implements a more theoretically sound algorithm for tracking active utilization: instead of decreasing it when a task blocks, use a timer (the "inactive timer", named after the "Inactive" task state of the GRUB algorithm) to decrease the

[RFC v5 2/9] sched/deadline: improve the tracking of active utilization

From: Luca Abeni This patch implements a more theoretically sound algorithm for tracking active utilization: instead of decreasing it when a task blocks, use a timer (the "inactive timer", named after the "Inactive" task state of the GRUB algorithm) to decrease the active utilization at the so

[RFC v5 3/9] sched/deadline: fix the update of the total -deadline utilization

From: Luca Abeni Now that the inactive timer can be armed to fire at the 0-lag time, it is possible to use inactive_task_timer() to update the total -deadline utilization (dl_b->total_bw) at the correct time, fixing dl_overflow() and __setparam_dl(). Signed-off-by:

[RFC v5 9/9] sched/deadline: also reclaim bandwidth not used by dl tasks

From: Luca Abeni This commit introduces a per-runqueue "extra utilization" that can be reclaimed by deadline tasks. In this way, the maximum fraction of CPU time that can reclaimed by deadline tasks is fixed (and configurable) and does not depend on the total deadline

[RFC v5 3/9] sched/deadline: fix the update of the total -deadline utilization

From: Luca Abeni Now that the inactive timer can be armed to fire at the 0-lag time, it is possible to use inactive_task_timer() to update the total -deadline utilization (dl_b->total_bw) at the correct time, fixing dl_overflow() and __setparam_dl(). Signed-off-by: Luca Abeni Tested-by: Daniel

[RFC v5 9/9] sched/deadline: also reclaim bandwidth not used by dl tasks

From: Luca Abeni This commit introduces a per-runqueue "extra utilization" that can be reclaimed by deadline tasks. In this way, the maximum fraction of CPU time that can reclaimed by deadline tasks is fixed (and configurable) and does not depend on the total deadline utilization.

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