[PATCH v3] extcon: intel-cht-wc: Add Intel Cherry Trail Whiskey Cove PMIC extcon driver

Add a driver for charger detection / control on the Intel Cherrytrail Whiskey Cove PMIC. Signed-off-by: Hans de Goede --- Changes in v2: -Improve wait for charger detection loop, use jiffies to get an accurate timeout -Sort registers by address, remove duplicate definition

[PATCH v3] extcon: intel-cht-wc: Add Intel Cherry Trail Whiskey Cove PMIC extcon driver

Add a driver for charger detection / control on the Intel Cherrytrail Whiskey Cove PMIC. Signed-off-by: Hans de Goede --- Changes in v2: -Improve wait for charger detection loop, use jiffies to get an accurate timeout -Sort registers by address, remove duplicate definition -Return IRQ_NONE on

Re: [PATCH] staging: media: atomisp: fix build error

On Thu, 2017-03-23 at 21:12 +0800, Geliang Tang wrote: > Fix the following build error: > >   CC  drivers/staging/media/atomisp/pci/atomisp2/hmm/hmm.o > drivers/staging/media/atomisp/pci/atomisp2/hmm/hmm.c:52:2: >  error: excess elements in array initializer [-Werror] >   "i", /* ion */ >  

Re: [PATCH] staging: media: atomisp: fix build error

On Thu, 2017-03-23 at 21:12 +0800, Geliang Tang wrote: > Fix the following build error: > >   CC  drivers/staging/media/atomisp/pci/atomisp2/hmm/hmm.o > drivers/staging/media/atomisp/pci/atomisp2/hmm/hmm.c:52:2: >  error: excess elements in array initializer [-Werror] >   "i", /* ion */ >  

[PATCH] proc: allow to change proc mount options per mount

As per the discussion with Andy, and following what Al Viro suggested maybe this can work ? the patch is still buggy on top of Linus' tree 093b995e3b Currently hidepid mount option is propagated to all proc mounts that are in the same pid namespace. This patch make it possible to have proc mounts

[PATCH] proc: allow to change proc mount options per mount

As per the discussion with Andy, and following what Al Viro suggested maybe this can work ? the patch is still buggy on top of Linus' tree 093b995e3b Currently hidepid mount option is propagated to all proc mounts that are in the same pid namespace. This patch make it possible to have proc mounts

Re: [PATCH 4/4] drm/amdgpu: resize VRAM BAR for CPU access

- Are we going to support resizing BAR when kernel modesetting is not enabled and we are running in console under VBIOS control (VESA/VGA)? No, initial I've tried to resize the PCI BAR during probing without the help of the driver at all. But the VESA/EFI/VBIOS don't seem to be able to handle

Re: [PATCH 4/4] drm/amdgpu: resize VRAM BAR for CPU access

- Are we going to support resizing BAR when kernel modesetting is not enabled and we are running in console under VBIOS control (VESA/VGA)? No, initial I've tried to resize the PCI BAR during probing without the help of the driver at all. But the VESA/EFI/VBIOS don't seem to be able to handle

Re: [tpmdd-devel] [PATCH v2 4/7] tpm: infrastructure for TPM spaces

On Wed, Mar 22, 2017 at 04:09:21PM -0400, Ken Goldman wrote: > On 2/22/2017 12:39 PM, James Bottomley wrote: > > > > Right at the moment the kernel use of tpm2 looks like > > > > acquire chip->tpm_mutex > > load key > > process key > > unload key > > release chip->tpm_mutex > > > > While it

Re: [tpmdd-devel] [PATCH v2 4/7] tpm: infrastructure for TPM spaces

On Wed, Mar 22, 2017 at 04:09:21PM -0400, Ken Goldman wrote: > On 2/22/2017 12:39 PM, James Bottomley wrote: > > > > Right at the moment the kernel use of tpm2 looks like > > > > acquire chip->tpm_mutex > > load key > > process key > > unload key > > release chip->tpm_mutex > > > > While it

Re: [PATCH] ACPI / IPMI: allow ACPI_IPMI with IPMI_SSIF

On 03/23/2017 10:53 AM, Sinan Kaya wrote: > + depends on IPMI_SI||IPMI_SSIF Blank spaces around ||. -- Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative

Re: [PATCH] ACPI / IPMI: allow ACPI_IPMI with IPMI_SSIF

On 03/23/2017 10:53 AM, Sinan Kaya wrote: > + depends on IPMI_SI||IPMI_SSIF Blank spaces around ||. -- Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative

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

On Thu, Mar 23, 2017 at 12:11:06PM +0100, Uwe Kleine-König wrote: > Hello, > > On Thu, Mar 23, 2017 at 11:20:39AM +0100, Geert Uytterhoeven wrote: > > But having the error breaks setups where the GPIO is optional and does > > not exist. > > so the right way forward is to check harder in the

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

On Thu, Mar 23, 2017 at 12:11:06PM +0100, Uwe Kleine-König wrote: > Hello, > > On Thu, Mar 23, 2017 at 11:20:39AM +0100, Geert Uytterhoeven wrote: > > But having the error breaks setups where the GPIO is optional and does > > not exist. > > so the right way forward is to check harder in the

Re: [PATCH] checkpatch: Allow space leading blank lines in email headers

On Wed, Mar 22, 2017 at 11:28:40PM -0700, Joe Perches wrote: > On Wed, 2017-03-22 at 23:20 -0700, Darren Hart wrote: > > I do have an open question regarding how we're going about testing for the > > end > > of the header lines. Since we're not just testing for an empty line to > > separate > >

Re: [PATCH] checkpatch: Allow space leading blank lines in email headers

On Wed, Mar 22, 2017 at 11:28:40PM -0700, Joe Perches wrote: > On Wed, 2017-03-22 at 23:20 -0700, Darren Hart wrote: > > I do have an open question regarding how we're going about testing for the > > end > > of the header lines. Since we're not just testing for an empty line to > > separate > >

Re: [PATCH v4 1/5] crash: move crashkernel parsing and vmcore related code under CONFIG_CRASH_CORE

Hi Michael, It's been a while since this patchset is Ack'ed. Should this go through powerpc-tree or some other? Thanks Hari On Thursday 05 January 2017 10:59 PM, Hari Bathini wrote: Traditionally, kdump is used to save vmcore in case of a crash. Some architectures like powerpc can save vmcore

Re: [PATCH v4 1/5] crash: move crashkernel parsing and vmcore related code under CONFIG_CRASH_CORE

Hi Michael, It's been a while since this patchset is Ack'ed. Should this go through powerpc-tree or some other? Thanks Hari On Thursday 05 January 2017 10:59 PM, Hari Bathini wrote: Traditionally, kdump is used to save vmcore in case of a crash. Some architectures like powerpc can save vmcore

[ANNOUNCE] elkdat: an easy linux kernel development and test tool

elkdat is a tool to ease linux kernel development/test. It automatically setups linux kernel source repository and a VM for linux kernel development and test. In addition, It runs the following kinds of tests automatically just by one command. - build, install, boot you own kernel - run your own

[ANNOUNCE] elkdat: an easy linux kernel development and test tool

elkdat is a tool to ease linux kernel development/test. It automatically setups linux kernel source repository and a VM for linux kernel development and test. In addition, It runs the following kinds of tests automatically just by one command. - build, install, boot you own kernel - run your own

Re: [PATCH] tpm2: fix off-by-one comparison and out-of-bounds read error

On Wed, Mar 22, 2017 at 04:12:49PM +0300, Dan Carpenter wrote: > On Wed, Mar 22, 2017 at 11:45:37AM +, Colin Ian King wrote: > > On 22/03/17 11:42, Jarkko Sakkinen wrote: > > > On Mon, Mar 20, 2017 at 02:23:36PM +, Colin King wrote: > > >> From: Colin Ian King >

Re: [PATCH] tpm2: fix off-by-one comparison and out-of-bounds read error

On Wed, Mar 22, 2017 at 04:12:49PM +0300, Dan Carpenter wrote: > On Wed, Mar 22, 2017 at 11:45:37AM +, Colin Ian King wrote: > > On 22/03/17 11:42, Jarkko Sakkinen wrote: > > > On Mon, Mar 20, 2017 at 02:23:36PM +, Colin King wrote: > > >> From: Colin Ian King > > >> > > >> The comparison

[PATCH] ACPI / IPMI: allow ACPI_IPMI with IPMI_SSIF

ACPI_IPMI driver currently depends on IPMI System Interface (IPMI_SI) driver to be enabled. IPMI_SI driver only handles KCS, SMIC and BT BMC interfaces. IPMI_SSIF is an alternative BMC communication method. It allows BMC to be accessed over an I2C bus instead of a standard interface. Enabling

[PATCH] ACPI / IPMI: allow ACPI_IPMI with IPMI_SSIF

ACPI_IPMI driver currently depends on IPMI System Interface (IPMI_SI) driver to be enabled. IPMI_SI driver only handles KCS, SMIC and BT BMC interfaces. IPMI_SSIF is an alternative BMC communication method. It allows BMC to be accessed over an I2C bus instead of a standard interface. Enabling

Re: [PATCH] tpm2: fix off-by-one comparison and out-of-bounds read error

On Wed, Mar 22, 2017 at 11:45:37AM +, Colin Ian King wrote: > On 22/03/17 11:42, Jarkko Sakkinen wrote: > > On Mon, Mar 20, 2017 at 02:23:36PM +, Colin King wrote: > >> From: Colin Ian King > >> > >> The comparison of an out of range index into space->context_tbl

Re: [PATCH] tpm2: fix off-by-one comparison and out-of-bounds read error

On Wed, Mar 22, 2017 at 11:45:37AM +, Colin Ian King wrote: > On 22/03/17 11:42, Jarkko Sakkinen wrote: > > On Mon, Mar 20, 2017 at 02:23:36PM +, Colin King wrote: > >> From: Colin Ian King > >> > >> The comparison of an out of range index into space->context_tbl is > >> off-by-one and

Re: [tpmdd-devel] [PATCH] tpm/tpm_crb: fix unused warnings on suspend/resume functions

On Tue, Mar 21, 2017 at 10:05:36PM +, Winkler, Tomas wrote: > > On Thu, Mar 16, 2017 at 09:51:33PM -0400, Jérémy Lefaure wrote: > > > When PM_SLEEP is disabled crb_pm_suspend and crb_pm_resume are not > > > used by SET_SYSTEM_SLEEP_PM_OPS even if PM is enabled: > > > > > >

Re: [tpmdd-devel] [PATCH] tpm/tpm_crb: fix unused warnings on suspend/resume functions

On Tue, Mar 21, 2017 at 10:05:36PM +, Winkler, Tomas wrote: > > On Thu, Mar 16, 2017 at 09:51:33PM -0400, Jérémy Lefaure wrote: > > > When PM_SLEEP is disabled crb_pm_suspend and crb_pm_resume are not > > > used by SET_SYSTEM_SLEEP_PM_OPS even if PM is enabled: > > > > > >

sg: random memory corruptions

Hello, The following program causes random assorted memory corruptions: https://gist.githubusercontent.com/dvyukov/da3463af2d1ff8c7d3624891b5d7427f/raw/09cf0f4af529f4506f9e0a9fa6bdb066a8777b9d/gistfile1.txt It does some ioctl's on /dev/sg0. general protection fault: [#1] SMP KASAN Modules

sg: random memory corruptions

Hello, The following program causes random assorted memory corruptions: https://gist.githubusercontent.com/dvyukov/da3463af2d1ff8c7d3624891b5d7427f/raw/09cf0f4af529f4506f9e0a9fa6bdb066a8777b9d/gistfile1.txt It does some ioctl's on /dev/sg0. general protection fault: [#1] SMP KASAN Modules

Re: deadlock in synchronize_srcu() in debugfs?

Hi, > Not yet. How reproducible is this? Apparently quite. I haven't tried myself - it happens during some automated test that I need to analyse further. > > We're observing that with our (backported, but very recent) driver > > against 4.9 (and 4.10, I think), > > Do I understand it correctly

Re: deadlock in synchronize_srcu() in debugfs?

Hi, > Not yet. How reproducible is this? Apparently quite. I haven't tried myself - it happens during some automated test that I need to analyse further. > > We're observing that with our (backported, but very recent) driver > > against 4.9 (and 4.10, I think), > > Do I understand it correctly

Re: deadlock in synchronize_srcu() in debugfs?

On Thu, 2017-03-23 at 08:37 -0700, Paul E. McKenney wrote: > I have not seen this, but my usual question for __synchronize_srcu() > is if some other task is blocked holding srcu_read_lock() for that > same srcu_struct. > Not as far as I can see - but that was the scenario I was outlining in my

Re: deadlock in synchronize_srcu() in debugfs?

On Thu, 2017-03-23 at 08:37 -0700, Paul E. McKenney wrote: > I have not seen this, but my usual question for __synchronize_srcu() > is if some other task is blocked holding srcu_read_lock() for that > same srcu_struct. > Not as far as I can see - but that was the scenario I was outlining in my

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

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, 2017 at 1:34 PM, Uwe Kleine-König > > wrote: > > > > > Maybe we can make gpiod_get_optional look like this: > > >

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

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, 2017 at 1:34 PM, Uwe Kleine-König > > wrote: > > > > > Maybe we can make gpiod_get_optional look like this: > > > > > > if (!dev->of_node

[PATCH v3] kasan: report only the first error by default

From: Mark Rutland Disable kasan after the first report. There are several reasons for this: * Single bug quite often has multiple invalid memory accesses causing storm in the dmesg. * Write OOB access might corrupt metadata so the next report will print bogus

[PATCH v3] kasan: report only the first error by default

From: Mark Rutland Disable kasan after the first report. There are several reasons for this: * Single bug quite often has multiple invalid memory accesses causing storm in the dmesg. * Write OOB access might corrupt metadata so the next report will print bogus alloc/free stacktraces.

Re: [PATCH v2 1/2] powerpc/powernv/cpuidle: Pass correct drv->cpumask for registration

* Rafael J. Wysocki [2017-03-23 16:28:31]: > On Thu, Mar 23, 2017 at 4:22 PM, Vaidyanathan Srinivasan > wrote: > > drv->cpumask defaults to cpu_possible_mask in __cpuidle_driver_init(). > > On PowerNV platform cpu_present could be less than

Re: [PATCH v2 1/2] powerpc/powernv/cpuidle: Pass correct drv->cpumask for registration

* Rafael J. Wysocki [2017-03-23 16:28:31]: > On Thu, Mar 23, 2017 at 4:22 PM, Vaidyanathan Srinivasan > wrote: > > drv->cpumask defaults to cpu_possible_mask in __cpuidle_driver_init(). > > On PowerNV platform cpu_present could be less than cpu_possible in cases > > where firmware detects the

Re: [PATCH v2 2/2] cpuidle: Validate cpu_dev in cpuidle_add_sysfs

* Rafael J. Wysocki [2017-03-23 16:27:31]: > On Thu, Mar 23, 2017 at 4:22 PM, Vaidyanathan Srinivasan > wrote: > > If a given cpu is not in cpu_present and cpu hotplug > > is disabled, arch can skip setting up the cpu_dev. > > > > Arch cpuidle

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

On Thu, Mar 23, 2017 at 8:32 AM, Borislav Petkov wrote: > On Thu, Mar 23, 2017 at 08:14:44AM -0700, Thomas Garnier wrote: >> Okay well then people are fine with a BUG_ON approach. I will do a >> next iteration tailored to that. I will also try to add the static >> inline

Re: [PATCH v2 2/2] cpuidle: Validate cpu_dev in cpuidle_add_sysfs

* Rafael J. Wysocki [2017-03-23 16:27:31]: > On Thu, Mar 23, 2017 at 4:22 PM, Vaidyanathan Srinivasan > wrote: > > If a given cpu is not in cpu_present and cpu hotplug > > is disabled, arch can skip setting up the cpu_dev. > > > > Arch cpuidle driver should pass correct cpu mask > > for

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

On Thu, Mar 23, 2017 at 8:32 AM, Borislav Petkov wrote: > On Thu, Mar 23, 2017 at 08:14:44AM -0700, Thomas Garnier wrote: >> Okay well then people are fine with a BUG_ON approach. I will do a >> next iteration tailored to that. I will also try to add the static >> inline suggestion from Peter. >

Re: [PATCH] x86/boot: Support uncompressed kernel

On (03/23/17 08:07), Yinghai Lu wrote: > On Thu, Mar 23, 2017 at 5:51 AM, Chao Peng > wrote: > > Compressed kernel has its own drawback: uncompressing takes time. Even > > though the time is short enough to ignore for most cases but for cases that > > time is

Re: [PATCH] x86/boot: Support uncompressed kernel

On (03/23/17 08:07), Yinghai Lu wrote: > On Thu, Mar 23, 2017 at 5:51 AM, Chao Peng > wrote: > > Compressed kernel has its own drawback: uncompressing takes time. Even > > though the time is short enough to ignore for most cases but for cases that > > time is critical this is still a big number.

Re: [PATCH v5] KVM: VMX: Fix enable VPID conditions

On Thu, Mar 23, 2017 at 5:30 AM, Wanpeng Li wrote: > From: Wanpeng Li > > This can be reproduced by running L2 on L1, and disable VPID on L0 > if w/o commit "KVM: nVMX: Fix nested VPID vmx exec control", the L2 > crash as below: > > KVM: entry failed,

Re: [PATCH v5] KVM: VMX: Fix enable VPID conditions

On Thu, Mar 23, 2017 at 5:30 AM, Wanpeng Li wrote: > From: Wanpeng Li > > This can be reproduced by running L2 on L1, and disable VPID on L0 > if w/o commit "KVM: nVMX: Fix nested VPID vmx exec control", the L2 > crash as below: > > KVM: entry failed, hardware error 0x7 > EAX=

Re: [PATCH v2 3/5] mm: use a dedicated workqueue for the free workers

On 03/22/2017 01:41 AM, Aaron Lu wrote: > On Wed, Mar 22, 2017 at 03:33:35PM +0900, Minchan Kim wrote: >> On Wed, Mar 15, 2017 at 05:00:02PM +0800, Aaron Lu wrote: >>> Introduce a workqueue for all the free workers so that user can fine >>> tune how many workers can be active through sysfs

Re: [PATCH v2 3/5] mm: use a dedicated workqueue for the free workers

On 03/22/2017 01:41 AM, Aaron Lu wrote: > On Wed, Mar 22, 2017 at 03:33:35PM +0900, Minchan Kim wrote: >> On Wed, Mar 15, 2017 at 05:00:02PM +0800, Aaron Lu wrote: >>> Introduce a workqueue for all the free workers so that user can fine >>> tune how many workers can be active through sysfs

Re: deadlock in synchronize_srcu() in debugfs?

On Thu, Mar 23, 2017 at 03:54:46PM +0100, Johannes Berg wrote: > Hi, > > Before I go hunting - has anyone seen a deadlock in synchronize_srcu() > in debugfs_remove() before? We're observing that with our (backported, > but very recent) driver against 4.9 (and 4.10, I think), but there are > no

Re: deadlock in synchronize_srcu() in debugfs?

On Thu, Mar 23, 2017 at 03:54:46PM +0100, Johannes Berg wrote: > Hi, > > Before I go hunting - has anyone seen a deadlock in synchronize_srcu() > in debugfs_remove() before? We're observing that with our (backported, > but very recent) driver against 4.9 (and 4.10, I think), but there are > no

Re: deadlock in synchronize_srcu() in debugfs?

Hi Johannes, On Thu, Mar 23 2017, Johannes Berg wrote: > Before I go hunting - has anyone seen a deadlock in synchronize_srcu() > in debugfs_remove() before? Not yet. How reproducible is this? > We're observing that with our (backported, but very recent) driver > against 4.9 (and 4.10, I

Re: deadlock in synchronize_srcu() in debugfs?

Hi Johannes, On Thu, Mar 23 2017, Johannes Berg wrote: > Before I go hunting - has anyone seen a deadlock in synchronize_srcu() > in debugfs_remove() before? Not yet. How reproducible is this? > We're observing that with our (backported, but very recent) driver > against 4.9 (and 4.10, I

Re: [PATCH V4] perf: qcom: Add L3 cache PMU driver

Hi Agustin, Structurally, this looks good to me. I have a few minor comments below; with those fixed up I think this is ready to merge. On Fri, Mar 17, 2017 at 10:24:17AM -0400, Agustin Vega-Frias wrote: > +/* > + * General constants > + */ > + > +/* Number of counters on each PMU */ > +#define

Re: [PATCH V4] perf: qcom: Add L3 cache PMU driver

Hi Agustin, Structurally, this looks good to me. I have a few minor comments below; with those fixed up I think this is ready to merge. On Fri, Mar 17, 2017 at 10:24:17AM -0400, Agustin Vega-Frias wrote: > +/* > + * General constants > + */ > + > +/* Number of counters on each PMU */ > +#define

[PATCH] ACPI / IPMI: change warning to debug on timeout

Getting timeout message from BMC when trying to read from a non-existent FRU. This is expected but warning is not. Let's reduce the warning to debug. Signed-off-by: Sinan Kaya --- drivers/acpi/acpi_ipmi.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git

[PATCH] ACPI / IPMI: change warning to debug on timeout

Getting timeout message from BMC when trying to read from a non-existent FRU. This is expected but warning is not. Let's reduce the warning to debug. Signed-off-by: Sinan Kaya --- drivers/acpi/acpi_ipmi.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git

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

On 23 March 2017 at 16:03, 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 23 March 2017 at 16:03, 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 'atk_input_show': >

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

On Thu, Mar 23, 2017 at 08:14:44AM -0700, Thomas Garnier wrote: > Okay well then people are fine with a BUG_ON approach. I will do a > next iteration tailored to that. I will also try to add the static > inline suggestion from Peter. Would it be possible, please, to refrain from top-posting when

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

On Thu, Mar 23, 2017 at 08:14:44AM -0700, Thomas Garnier wrote: > Okay well then people are fine with a BUG_ON approach. I will do a > next iteration tailored to that. I will also try to add the static > inline suggestion from Peter. Would it be possible, please, to refrain from top-posting when

Re: [PATCH] virtio_balloon: prevent uninitialized variable use

On 03/23/2017 06:17 PM, Arnd Bergmann wrote: > The latest gcc-7.0.1 snapshot reports a new warning: > > virtio/virtio_balloon.c: In function 'update_balloon_stats': > virtio/virtio_balloon.c:258:26: error: 'events[2]' is used uninitialized in > this function [-Werror=uninitialized] >

Re: [PATCH] virtio_balloon: prevent uninitialized variable use

On 03/23/2017 06:17 PM, Arnd Bergmann wrote: > The latest gcc-7.0.1 snapshot reports a new warning: > > virtio/virtio_balloon.c: In function 'update_balloon_stats': > virtio/virtio_balloon.c:258:26: error: 'events[2]' is used uninitialized in > this function [-Werror=uninitialized] >

Re: [PATCH v3 00/12] Add Basic SoC support for MT6797

Hi Mars, On 23/03/17 00:46, Mars Cheng wrote: > Hi Matthias, Rob, Marc, Stephen > > gentle ping for this patch set. I appreciate that you're eager to see this reviewed, but less than 4 days between a posting and a reminder is a bit too eager. We're not machines! ;-) Thanks, M. --

Re: [PATCH v3 00/12] Add Basic SoC support for MT6797

Hi Mars, On 23/03/17 00:46, Mars Cheng wrote: > Hi Matthias, Rob, Marc, Stephen > > gentle ping for this patch set. I appreciate that you're eager to see this reviewed, but less than 4 days between a posting and a reminder is a bit too eager. We're not machines! ;-) Thanks, M. --

Re: deadlock in synchronize_srcu() in debugfs?

On Thu, 2017-03-23 at 15:54 +0100, Johannes Berg wrote: > Before I go hunting - has anyone seen a deadlock in > synchronize_srcu() in debugfs_remove() before? Isn't it possible for the following to happen? CPU1CPU2 mutex_lock();

Re: deadlock in synchronize_srcu() in debugfs?

On Thu, 2017-03-23 at 15:54 +0100, Johannes Berg wrote: > Before I go hunting - has anyone seen a deadlock in > synchronize_srcu() in debugfs_remove() before? Isn't it possible for the following to happen? CPU1CPU2 mutex_lock();

Re: [PATCH] hibernation: on 32-bit x86, disabled in favor of KASLR

On Thu, Mar 23, 2017 at 2:23 PM, Evgenii Shatokhin wrote: > On 23.03.2017 03:27, Kees Cook wrote: >> >> This is a modified revert of commit 65fe935dd238 ("x86/KASLR, x86/power: >> Remove x86 hibernation restrictions"), since it appears that 32-bit >> hibernation still

Re: [PATCH] hibernation: on 32-bit x86, disabled in favor of KASLR

On Thu, Mar 23, 2017 at 2:23 PM, Evgenii Shatokhin wrote: > On 23.03.2017 03:27, Kees Cook wrote: >> >> This is a modified revert of commit 65fe935dd238 ("x86/KASLR, x86/power: >> Remove x86 hibernation restrictions"), since it appears that 32-bit >> hibernation still can't support KASLR. 64-bit

Re: [PATCH v2 1/2] powerpc/powernv/cpuidle: Pass correct drv->cpumask for registration

On Thu, Mar 23, 2017 at 4:22 PM, Vaidyanathan Srinivasan wrote: > drv->cpumask defaults to cpu_possible_mask in __cpuidle_driver_init(). > On PowerNV platform cpu_present could be less than cpu_possible in cases > where firmware detects the cpu, but it is not available

Re: [PATCH v2 1/2] powerpc/powernv/cpuidle: Pass correct drv->cpumask for registration

On Thu, Mar 23, 2017 at 4:22 PM, Vaidyanathan Srinivasan wrote: > drv->cpumask defaults to cpu_possible_mask in __cpuidle_driver_init(). > On PowerNV platform cpu_present could be less than cpu_possible in cases > where firmware detects the cpu, but it is not available to the OS. When >

Re: [PATCH v2 2/2] cpuidle: Validate cpu_dev in cpuidle_add_sysfs

On Thu, Mar 23, 2017 at 4:22 PM, Vaidyanathan Srinivasan wrote: > If a given cpu is not in cpu_present and cpu hotplug > is disabled, arch can skip setting up the cpu_dev. > > Arch cpuidle driver should pass correct cpu mask > for registration, but failing to do so by

Re: [PATCH] EDAC, pnd2_edac: fix build error without CONFIG_EDAC_DEBUG

On Thu, Mar 23, 2017 at 04:16:35PM +0100, Arnd Bergmann wrote: > Calling into functions inside of the #ifdef causes an obvious compile error: > > drivers/edac/pnd2_edac.c: In function 'pnd2_init': > drivers/edac/pnd2_edac.c:1521:2: error: implicit declaration of function > 'setup_pnd2_debug';

Re: [PATCH v2 2/2] cpuidle: Validate cpu_dev in cpuidle_add_sysfs

On Thu, Mar 23, 2017 at 4:22 PM, Vaidyanathan Srinivasan wrote: > If a given cpu is not in cpu_present and cpu hotplug > is disabled, arch can skip setting up the cpu_dev. > > Arch cpuidle driver should pass correct cpu mask > for registration, but failing to do so by the driver > causes error to

Re: [PATCH] EDAC, pnd2_edac: fix build error without CONFIG_EDAC_DEBUG

On Thu, Mar 23, 2017 at 04:16:35PM +0100, Arnd Bergmann wrote: > Calling into functions inside of the #ifdef causes an obvious compile error: > > drivers/edac/pnd2_edac.c: In function 'pnd2_init': > drivers/edac/pnd2_edac.c:1521:2: error: implicit declaration of function > 'setup_pnd2_debug';

[PATCH v2 2/2] cpuidle: Validate cpu_dev in cpuidle_add_sysfs

If a given cpu is not in cpu_present and cpu hotplug is disabled, arch can skip setting up the cpu_dev. Arch cpuidle driver should pass correct cpu mask for registration, but failing to do so by the driver causes error to propagate and crash like this: [ 30.076045] Unable to handle kernel

[PATCH v2 1/2] powerpc/powernv/cpuidle: Pass correct drv->cpumask for registration

drv->cpumask defaults to cpu_possible_mask in __cpuidle_driver_init(). On PowerNV platform cpu_present could be less than cpu_possible in cases where firmware detects the cpu, but it is not available to the OS. When CONFIG_HOTPLUG_CPU=n, such cpus are not hotplugable at runtime and hence we skip

[PATCH v2 2/2] cpuidle: Validate cpu_dev in cpuidle_add_sysfs

If a given cpu is not in cpu_present and cpu hotplug is disabled, arch can skip setting up the cpu_dev. Arch cpuidle driver should pass correct cpu mask for registration, but failing to do so by the driver causes error to propagate and crash like this: [ 30.076045] Unable to handle kernel

[PATCH v2 1/2] powerpc/powernv/cpuidle: Pass correct drv->cpumask for registration

drv->cpumask defaults to cpu_possible_mask in __cpuidle_driver_init(). On PowerNV platform cpu_present could be less than cpu_possible in cases where firmware detects the cpu, but it is not available to the OS. When CONFIG_HOTPLUG_CPU=n, such cpus are not hotplugable at runtime and hence we skip

[PATCH v1 0/2] cpuidle: Fixes in cpuidle driver

When CONFIG_HOTPLUG_CPU=n and cpu_present is less than cpu_possible, then cpuidle-powernv not passing an explicit drv->cpu_mask allows generic cpuidle driver to try create sysfs objects for cpus that does not have cpu_devices created by calling register_cpu(). This caused kernel to access

[PATCH v1 0/2] cpuidle: Fixes in cpuidle driver

When CONFIG_HOTPLUG_CPU=n and cpu_present is less than cpu_possible, then cpuidle-powernv not passing an explicit drv->cpu_mask allows generic cpuidle driver to try create sysfs objects for cpus that does not have cpu_devices created by calling register_cpu(). This caused kernel to access

Re: [PATCH 3/4] RAS: Add a Corrected Errors Collector

On Wed, Mar 22, 2017 at 07:03:39PM +0100, Borislav Petkov wrote: > Lemme try to write a small script exercising exactly that scenario to > see whether I'm actually not talking crap here :-) Ok, here's a snapshot from the CEC after letting it run for a couple of hours in a guest with a script

Re: usb: use-after-free write in usb_hcd_link_urb_to_ep

On Thu, Mar 23, 2017 at 4:04 PM, Alan Stern wrote: > On Thu, 23 Mar 2017, Dmitry Vyukov wrote: > >> > Putting these together: >> > >> > The memory was allocated in usb_internal_control_msg() line 93. >> > The later events occurred within the call in line

Re: [PATCH 3/4] RAS: Add a Corrected Errors Collector

On Wed, Mar 22, 2017 at 07:03:39PM +0100, Borislav Petkov wrote: > Lemme try to write a small script exercising exactly that scenario to > see whether I'm actually not talking crap here :-) Ok, here's a snapshot from the CEC after letting it run for a couple of hours in a guest with a script

Re: usb: use-after-free write in usb_hcd_link_urb_to_ep

On Thu, Mar 23, 2017 at 4:04 PM, Alan Stern wrote: > On Thu, 23 Mar 2017, Dmitry Vyukov wrote: > >> > Putting these together: >> > >> > The memory was allocated in usb_internal_control_msg() line 93. >> > The later events occurred within the call in line 100 to >> >

Re: [PATCH 03/15] extcon: cht-wc: Add Intel Cherry Trail Whiskey Cove PMIC extcon driver

Hi, On 21-03-17 06:16, Chanwoo Choi wrote: Hi, On 2017년 03월 21일 04:57, Hans de Goede wrote: Hi, On 20-03-17 02:33, Chanwoo Choi wrote: Hi, On 2017년 03월 17일 18:55, Hans de Goede wrote: Add a driver for charger detection / control on the Intel Cherrytrail Whiskey Cove PMIC. Signed-off-by:

Re: [PATCH 03/15] extcon: cht-wc: Add Intel Cherry Trail Whiskey Cove PMIC extcon driver

Hi, On 21-03-17 06:16, Chanwoo Choi wrote: Hi, On 2017년 03월 21일 04:57, Hans de Goede wrote: Hi, On 20-03-17 02:33, Chanwoo Choi wrote: Hi, On 2017년 03월 17일 18:55, Hans de Goede wrote: Add a driver for charger detection / control on the Intel Cherrytrail Whiskey Cove PMIC. Signed-off-by:

[PATCH v3 1/7] pinctrl: dt-bindings: Add documentation for Armada 37xx pin controllers

Document the device tree binding for the pin controllers found on the Armada 37xx SoCs. Update the binding documention of the xtal clk which is a subnode of this syscon node. Signed-off-by: Gregory CLEMENT ---

Re: [RFC v0 1/2] interconnect: Add generic interconnect controller API

On 03/23/2017 03:21 AM, Michael Turquette wrote: Hi Georgi, Quoting Georgi Djakov (2017-03-01 10:22:34) diff --git a/Documentation/devicetree/bindings/interconnect/interconnect.txt b/Documentation/devicetree/bindings/interconnect/interconnect.txt new file mode 100644 index

[PATCH v3 1/7] pinctrl: dt-bindings: Add documentation for Armada 37xx pin controllers

Document the device tree binding for the pin controllers found on the Armada 37xx SoCs. Update the binding documention of the xtal clk which is a subnode of this syscon node. Signed-off-by: Gregory CLEMENT --- Documentation/devicetree/bindings/clock/armada3700-xtal-clock.txt | 7 +--

Re: [RFC v0 1/2] interconnect: Add generic interconnect controller API

On 03/23/2017 03:21 AM, Michael Turquette wrote: Hi Georgi, Quoting Georgi Djakov (2017-03-01 10:22:34) diff --git a/Documentation/devicetree/bindings/interconnect/interconnect.txt b/Documentation/devicetree/bindings/interconnect/interconnect.txt new file mode 100644 index

[PATCH v3 0/7] Add support for pinctrl/gpio on Armada 37xx

Hi, In this third version I finally managed to use gpio-ranges from the device tree. For the record, this series adds support for the pin and gpio controllers present on the Armada 37xx SoCs. Each Armada 37xx SoC comes with 2 pin controllers: one on the south bridge (managing 28 pins) and one on

[PATCH v3 0/7] Add support for pinctrl/gpio on Armada 37xx

Hi, In this third version I finally managed to use gpio-ranges from the device tree. For the record, this series adds support for the pin and gpio controllers present on the Armada 37xx SoCs. Each Armada 37xx SoC comes with 2 pin controllers: one on the south bridge (managing 28 pins) and one on

[PATCH v3 2/7] arm64: marvell: enable the Armada 37xx pinctrl driver

This commit makes sure the driver for the Armada 37xx pin controller is enabled. Signed-off-by: Gregory CLEMENT --- arch/arm64/Kconfig.platforms | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms

Re: [REGRESSION] 07ec51480b5e ("virtio_pci: use shared interrupts for virtqueues") causes crashes in guest

On Thu, Mar 23, 2017 at 01:13:50PM +0800, Jason Wang wrote: > >From 312859b596e83a2164a8430343d31fce2a5ad808 Mon Sep 17 00:00:00 2001 > From: Jason Wang > Date: Thu, 23 Mar 2017 13:07:16 +0800 > Subject: [PATCH] virtio_pci: fix out of bound access for msix_names > >

[PATCH v3 2/7] arm64: marvell: enable the Armada 37xx pinctrl driver

This commit makes sure the driver for the Armada 37xx pin controller is enabled. Signed-off-by: Gregory CLEMENT --- arch/arm64/Kconfig.platforms | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms index 129cc5ae4091..f2bb1691264f

Re: [REGRESSION] 07ec51480b5e ("virtio_pci: use shared interrupts for virtqueues") causes crashes in guest

On Thu, Mar 23, 2017 at 01:13:50PM +0800, Jason Wang wrote: > >From 312859b596e83a2164a8430343d31fce2a5ad808 Mon Sep 17 00:00:00 2001 > From: Jason Wang > Date: Thu, 23 Mar 2017 13:07:16 +0800 > Subject: [PATCH] virtio_pci: fix out of bound access for msix_names > > Signed-off-by: Jason Wang I

[PATCH v3 4/7] pinctrl: armada-37xx: Add gpio support

GPIO management is pretty simple and is part of the same IP than the pin controller for the Armada 37xx SoCs. This patch adds the GPIO support to the pinctrl-armada-37xx.c file, it also allows sharing common functions between the gpiolib and the pinctrl drivers. Signed-off-by: Gregory CLEMENT

[PATCH v3 4/7] pinctrl: armada-37xx: Add gpio support

GPIO management is pretty simple and is part of the same IP than the pin controller for the Armada 37xx SoCs. This patch adds the GPIO support to the pinctrl-armada-37xx.c file, it also allows sharing common functions between the gpiolib and the pinctrl drivers. Signed-off-by: Gregory CLEMENT

<    6   7   8   9   10   11   12   13   14   15   >