Re: [PATCH v2] rbd: Remove VLA usage

Hi Kyle, Thank you for the patch! Yet something to improve: [auto build test ERROR on linus/master] [also build test ERROR on v4.16-rc5 next-20180316] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux

Re: [PATCH v2] rbd: Remove VLA usage

Hi Kyle, Thank you for the patch! Yet something to improve: [auto build test ERROR on linus/master] [also build test ERROR on v4.16-rc5 next-20180316] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux

Re: [PATCH v2] staging: typec: rt1711h typec chip driver

Hi Guenter, 2018-03-17 10:16 GMT+08:00 Guenter Roeck : > On 03/16/2018 10:40 AM, ShuFan Lee wrote: >> >> From: ShuFan Lee >> >> Richtek RT1711H Type-C chip driver that works with >> Type-C Port Controller Manager to provide USB PD and >> USB Type-C

Re: [PATCH v2] staging: typec: rt1711h typec chip driver

Hi Guenter, 2018-03-17 10:16 GMT+08:00 Guenter Roeck : > On 03/16/2018 10:40 AM, ShuFan Lee wrote: >> >> From: ShuFan Lee >> >> Richtek RT1711H Type-C chip driver that works with >> Type-C Port Controller Manager to provide USB PD and >> USB Type-C functionalities. >> Add definition of

Re: [PATCH v2 6/6] platform/chrome: mfd/cros_ec_dev: Add sysfs entry to set keyboard wake lid angle

On Wed, Mar 7, 2018 at 8:28 AM Lee Jones wrote: > On Wed, 21 Feb 2018, Enric Balletbo i Serra wrote: > > From: Gwendal Grignou > > > > This adds a sysfs attribute (/sys/class/chromeos/cros_ec/kb_wake_angle) > > used to set and get the keyboard wake

Re: [PATCH v2 6/6] platform/chrome: mfd/cros_ec_dev: Add sysfs entry to set keyboard wake lid angle

On Wed, Mar 7, 2018 at 8:28 AM Lee Jones wrote: > On Wed, 21 Feb 2018, Enric Balletbo i Serra wrote: > > From: Gwendal Grignou > > > > This adds a sysfs attribute (/sys/class/chromeos/cros_ec/kb_wake_angle) > > used to set and get the keyboard wake lid angle. This attribute is > > present only

[PATCH] Input: atmel_mxt_ts: Add hook for Chromebooks with upstream coreboot

Chromebooks use coreboot for system initialization. coreboot has always had the default mainboard vendor string for Google machines set to "Google". Google engineers set this string to "GOOGLE" in the coreboot copies of the Chromium OS tree. The atmel_mxt_ts driver in it's current state is set to

[PATCH] Input: atmel_mxt_ts: Add hook for Chromebooks with upstream coreboot

Chromebooks use coreboot for system initialization. coreboot has always had the default mainboard vendor string for Google machines set to "Google". Google engineers set this string to "GOOGLE" in the coreboot copies of the Chromium OS tree. The atmel_mxt_ts driver in it's current state is set to

Re: [PATCH 03/14] mm/hmm: HMM should have a callback before MM is destroyed v2

On 03/16/2018 08:47 PM, John Hubbard wrote: > On 03/16/2018 07:36 PM, John Hubbard wrote: >> On 03/16/2018 12:14 PM, jgli...@redhat.com wrote: >>> From: Ralph Campbell >>> >> >> >> >>> +static void hmm_release(struct mmu_notifier *mn, struct mm_struct *mm) >>> +{ >>> +

Re: [PATCH 03/14] mm/hmm: HMM should have a callback before MM is destroyed v2

On 03/16/2018 08:47 PM, John Hubbard wrote: > On 03/16/2018 07:36 PM, John Hubbard wrote: >> On 03/16/2018 12:14 PM, jgli...@redhat.com wrote: >>> From: Ralph Campbell >>> >> >> >> >>> +static void hmm_release(struct mmu_notifier *mn, struct mm_struct *mm) >>> +{ >>> + struct hmm *hmm =

Re: [PATCH] phy: core: Allow phy_pm_runtime_xxx API calls with NULL phy

Hi Manu, Thank you for the patch! Perhaps something to improve: [auto build test WARNING on v4.16-rc4] [also build test WARNING on next-20180316] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits

Re: [PATCH] phy: core: Allow phy_pm_runtime_xxx API calls with NULL phy

Hi Manu, Thank you for the patch! Perhaps something to improve: [auto build test WARNING on v4.16-rc4] [also build test WARNING on next-20180316] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits

Re: [PATCH 08/14] mm/hmm: cleanup special vma handling (VM_SPECIAL)

On 03/16/2018 12:14 PM, jgli...@redhat.com wrote: > From: Jérôme Glisse > > Special vma (one with any of the VM_SPECIAL flags) can not be access by > device because there is no consistent model accross device drivers on > those vma and their backing memory. > > This patch

Re: [PATCH 08/14] mm/hmm: cleanup special vma handling (VM_SPECIAL)

On 03/16/2018 12:14 PM, jgli...@redhat.com wrote: > From: Jérôme Glisse > > Special vma (one with any of the VM_SPECIAL flags) can not be access by > device because there is no consistent model accross device drivers on > those vma and their backing memory. > > This patch directly use hmm_range

Re: [PATCH v4] EDAC, sb_edac: Remove VLA usage

On Wed, Mar 14, 2018 at 01:21:32PM -0500, Gustavo A. R. Silva wrote: > In preparation to enabling -Wvla, remove VLA and replace it > with a fixed-length array instead. > > Fixed as part of the directive to remove all VLAs from > the kernel: https://lkml.org/lkml/2018/3/7/621 > > Also, remove

Re: [PATCH v4] EDAC, sb_edac: Remove VLA usage

On Wed, Mar 14, 2018 at 01:21:32PM -0500, Gustavo A. R. Silva wrote: > In preparation to enabling -Wvla, remove VLA and replace it > with a fixed-length array instead. > > Fixed as part of the directive to remove all VLAs from > the kernel: https://lkml.org/lkml/2018/3/7/621 > > Also, remove

Re: [PATCH v3 18/18] infiniband: cxgb4: Eliminate duplicate barriers on weakly-ordered archs

On Fri, Mar 16, 2018 at 11:25 PM, Sinan Kaya wrote: > @@ -477,15 +477,16 @@ static inline void t4_ring_sq_db(struct t4_wq *wq, u16 > inc, union t4_wr *wqe) > (u64 *)wqe); > } else { > pr_debug("DB

Re: [PATCH v3 18/18] infiniband: cxgb4: Eliminate duplicate barriers on weakly-ordered archs

On Fri, Mar 16, 2018 at 11:25 PM, Sinan Kaya wrote: > @@ -477,15 +477,16 @@ static inline void t4_ring_sq_db(struct t4_wq *wq, u16 > inc, union t4_wr *wqe) > (u64 *)wqe); > } else { > pr_debug("DB wq->sq.pidx = %d\n",

Re: [PATCH v3 18/18] infiniband: cxgb4: Eliminate duplicate barriers on weakly-ordered archs

On 3/17/2018 12:03 AM, Sinan Kaya wrote: > On 3/16/2018 11:40 PM, Sinan Kaya wrote: >> I'll change writel_relaxed() with __raw_writel() in the series like you >> suggested >> and also look at your other comments. > > I spoke too soon. > > Now that I realized, code needs to follow one of the

Re: [PATCH v3 18/18] infiniband: cxgb4: Eliminate duplicate barriers on weakly-ordered archs

On 3/17/2018 12:03 AM, Sinan Kaya wrote: > On 3/16/2018 11:40 PM, Sinan Kaya wrote: >> I'll change writel_relaxed() with __raw_writel() in the series like you >> suggested >> and also look at your other comments. > > I spoke too soon. > > Now that I realized, code needs to follow one of the

Re: [PATCH v3 18/18] infiniband: cxgb4: Eliminate duplicate barriers on weakly-ordered archs

On 3/16/18 6:04 PM, Steve Wise wrote: Anybody understand why the PPC implementation of writeX_relaxed() isn't relaxed? You probably should ask that on the linuxppc-...@lists.ozlabs.org mailing list. I've always wondered why PowerPC has non-standard I/O accessors. -- Qualcomm Datacenter

Re: [PATCH v3 18/18] infiniband: cxgb4: Eliminate duplicate barriers on weakly-ordered archs

On 3/16/18 6:04 PM, Steve Wise wrote: Anybody understand why the PPC implementation of writeX_relaxed() isn't relaxed? You probably should ask that on the linuxppc-...@lists.ozlabs.org mailing list. I've always wondered why PowerPC has non-standard I/O accessors. -- Qualcomm Datacenter

Re: [PATCH v3 18/18] infiniband: cxgb4: Eliminate duplicate barriers on weakly-ordered archs

On 3/16/2018 11:40 PM, Sinan Kaya wrote: > I'll change writel_relaxed() with __raw_writel() in the series like you > suggested > and also look at your other comments. I spoke too soon. Now that I realized, code needs to follow one of the following patterns for correctness 1) wmb()

Re: [PATCH v3 18/18] infiniband: cxgb4: Eliminate duplicate barriers on weakly-ordered archs

On 3/16/2018 11:40 PM, Sinan Kaya wrote: > I'll change writel_relaxed() with __raw_writel() in the series like you > suggested > and also look at your other comments. I spoke too soon. Now that I realized, code needs to follow one of the following patterns for correctness 1) wmb()

Re: [PATCH v4.16-rc5 1/1] x86/vdso: VDSO should handle clock_gettime(CLOCK_MONOTONIC_RAW) without syscall

Hi, Thank you for the patch! Yet something to improve: [auto build test ERROR on v4.16-rc4] [also build test ERROR on next-20180316] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/jason-vas

Re: [PATCH v4.16-rc5 1/1] x86/vdso: VDSO should handle clock_gettime(CLOCK_MONOTONIC_RAW) without syscall

Hi, Thank you for the patch! Yet something to improve: [auto build test ERROR on v4.16-rc4] [also build test ERROR on next-20180316] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/jason-vas

Re: [PATCH 07/14] mm/hmm: use uint64_t for HMM pfn instead of defining hmm_pfn_t to ulong

On 03/16/2018 12:14 PM, jgli...@redhat.com wrote: > From: Jérôme Glisse > Hi Jerome, This one looks great. A couple of trivial typo fixes are listed below. You can add: Reviewed-by: John Hubbard > All device driver we care about are using 64bits

Re: [PATCH 07/14] mm/hmm: use uint64_t for HMM pfn instead of defining hmm_pfn_t to ulong

On 03/16/2018 12:14 PM, jgli...@redhat.com wrote: > From: Jérôme Glisse > Hi Jerome, This one looks great. A couple of trivial typo fixes are listed below. You can add: Reviewed-by: John Hubbard > All device driver we care about are using 64bits page table entry. In > order to match this

Re: [PATCH 03/14] mm/hmm: HMM should have a callback before MM is destroyed v2

On 03/16/2018 07:36 PM, John Hubbard wrote: > On 03/16/2018 12:14 PM, jgli...@redhat.com wrote: >> From: Ralph Campbell >> > > > >> +static void hmm_release(struct mmu_notifier *mn, struct mm_struct *mm) >> +{ >> +struct hmm *hmm = mm->hmm; >> +struct hmm_mirror

Re: [PATCH 03/14] mm/hmm: HMM should have a callback before MM is destroyed v2

On 03/16/2018 07:36 PM, John Hubbard wrote: > On 03/16/2018 12:14 PM, jgli...@redhat.com wrote: >> From: Ralph Campbell >> > > > >> +static void hmm_release(struct mmu_notifier *mn, struct mm_struct *mm) >> +{ >> +struct hmm *hmm = mm->hmm; >> +struct hmm_mirror *mirror; >> +struct

[PATCH i2c/slave-mqueue v1] i2c: slave-mqueue: add a slave backend to receive and queue messages

Some protocols over I2C are designed for bi-directional transferring messages by using I2C Master Write protocol. Like the MCTP (Management Component Transport Protocol) and IPMB (Intelligent Platform Management Bus), they both require that the userspace can receive messages from I2C dirvers under

[PATCH i2c/slave-mqueue v1] i2c: slave-mqueue: add a slave backend to receive and queue messages

Some protocols over I2C are designed for bi-directional transferring messages by using I2C Master Write protocol. Like the MCTP (Management Component Transport Protocol) and IPMB (Intelligent Platform Management Bus), they both require that the userspace can receive messages from I2C dirvers under

Re: [PATCH v3 18/18] infiniband: cxgb4: Eliminate duplicate barriers on weakly-ordered archs

On 3/16/2018 7:05 PM, Steve Wise wrote: >> >> On 3/16/2018 5:05 PM, Steve Wise wrote: Code includes wmb() followed by writel(). writel() already has a barrier >>> on some architectures like arm64. This ends up CPU observing two barriers back to back before executing >> the

Re: [PATCH v3 18/18] infiniband: cxgb4: Eliminate duplicate barriers on weakly-ordered archs

On 3/16/2018 7:05 PM, Steve Wise wrote: >> >> On 3/16/2018 5:05 PM, Steve Wise wrote: Code includes wmb() followed by writel(). writel() already has a barrier >>> on some architectures like arm64. This ends up CPU observing two barriers back to back before executing >> the

Re: [PATCH 06/14] mm/hmm: remove HMM_PFN_READ flag and ignore peculiar architecture

On 03/16/2018 12:14 PM, jgli...@redhat.com wrote: > From: Jérôme Glisse > > Only peculiar architecture allow write without read thus assume that > any valid pfn do allow for read. Note we do not care for write only > because it does make sense with thing like atomic compare

Re: [PATCH 06/14] mm/hmm: remove HMM_PFN_READ flag and ignore peculiar architecture

On 03/16/2018 12:14 PM, jgli...@redhat.com wrote: > From: Jérôme Glisse > > Only peculiar architecture allow write without read thus assume that > any valid pfn do allow for read. Note we do not care for write only > because it does make sense with thing like atomic compare and exchange > or any

Re: [PATCH 05/14] mm/hmm: use struct for hmm_vma_fault(), hmm_vma_get_pfns() parameters

On 03/16/2018 12:14 PM, jgli...@redhat.com wrote: > From: Jérôme Glisse > Hi Jerome, I failed to find any problems in this patch, so: Reviewed-by: John Hubbard There are a couple of documentation recommended typo fixes listed below, which are very

Re: [PATCH 05/14] mm/hmm: use struct for hmm_vma_fault(), hmm_vma_get_pfns() parameters

On 03/16/2018 12:14 PM, jgli...@redhat.com wrote: > From: Jérôme Glisse > Hi Jerome, I failed to find any problems in this patch, so: Reviewed-by: John Hubbard There are a couple of documentation recommended typo fixes listed below, which are very minor but as long as I'm here I'll point

Re: [PATCH 2/2] kprobe: fix: Add ftrace_ops_assist_func to kprobe blacklist

On Sat, 17 Mar 2018 10:22:11 +0900 Masami Hiramatsu wrote: > Or, we can check it by ftrace_location_range() as below patch. Cute ;-) > > Note that as a side-effect, we can not trace functions in trace_kprobe.c > anymore, and this means it is hard to me to make a testcase

Re: [PATCH 2/2] kprobe: fix: Add ftrace_ops_assist_func to kprobe blacklist

On Sat, 17 Mar 2018 10:22:11 +0900 Masami Hiramatsu wrote: > Or, we can check it by ftrace_location_range() as below patch. Cute ;-) > > Note that as a side-effect, we can not trace functions in trace_kprobe.c > anymore, and this means it is hard to me to make a testcase of kprobe events. >

Re: [PATCH 03/14] mm/hmm: HMM should have a callback before MM is destroyed v2

On 03/16/2018 12:14 PM, jgli...@redhat.com wrote: > From: Ralph Campbell > > +static void hmm_release(struct mmu_notifier *mn, struct mm_struct *mm) > +{ > + struct hmm *hmm = mm->hmm; > + struct hmm_mirror *mirror; > + struct hmm_mirror *mirror_next; > + > +

Re: [PATCH 03/14] mm/hmm: HMM should have a callback before MM is destroyed v2

On 03/16/2018 12:14 PM, jgli...@redhat.com wrote: > From: Ralph Campbell > > +static void hmm_release(struct mmu_notifier *mn, struct mm_struct *mm) > +{ > + struct hmm *hmm = mm->hmm; > + struct hmm_mirror *mirror; > + struct hmm_mirror *mirror_next; > + > +

Re: [PATCH v2] staging: typec: rt1711h typec chip driver

On 03/16/2018 10:40 AM, ShuFan Lee wrote: From: ShuFan Lee Richtek RT1711H Type-C chip driver that works with Type-C Port Controller Manager to provide USB PD and USB Type-C functionalities. Add definition of TCPC_CC_STATUS_TOGGLING. Signed-off-by: ShuFan Lee

Re: [PATCH v2] staging: typec: rt1711h typec chip driver

On 03/16/2018 10:40 AM, ShuFan Lee wrote: From: ShuFan Lee Richtek RT1711H Type-C chip driver that works with Type-C Port Controller Manager to provide USB PD and USB Type-C functionalities. Add definition of TCPC_CC_STATUS_TOGGLING. Signed-off-by: ShuFan Lee Does this patch require DT

Re: [PATCH 04/14] mm/hmm: hmm_pfns_bad() was accessing wrong struct

On 03/16/2018 12:14 PM, jgli...@redhat.com wrote: > From: Jérôme Glisse > > The private field of mm_walk struct point to an hmm_vma_walk struct and > not to the hmm_range struct desired. Fix to get proper struct pointer. > > Signed-off-by: Jérôme Glisse

Re: [PATCH 04/14] mm/hmm: hmm_pfns_bad() was accessing wrong struct

On 03/16/2018 12:14 PM, jgli...@redhat.com wrote: > From: Jérôme Glisse > > The private field of mm_walk struct point to an hmm_vma_walk struct and > not to the hmm_range struct desired. Fix to get proper struct pointer. > > Signed-off-by: Jérôme Glisse > Cc: sta...@vger.kernel.org > Cc:

Re: [PATCH v3 1/7] watchdog: sama5d4: make use of timeout-secs provided in devicetree

On 03/16/2018 06:37 AM, Marcus Folkesson wrote: Hi, Am I supposed to do something more to make this patchset picked up? Did you check linux-next ? Guenter Thanks, Marcus Folkesson On Sun, Feb 11, 2018 at 09:08:41PM +0100, Marcus Folkesson wrote: watchdog_init_timeout() will allways pick

Re: [PATCH v3 1/7] watchdog: sama5d4: make use of timeout-secs provided in devicetree

On 03/16/2018 06:37 AM, Marcus Folkesson wrote: Hi, Am I supposed to do something more to make this patchset picked up? Did you check linux-next ? Guenter Thanks, Marcus Folkesson On Sun, Feb 11, 2018 at 09:08:41PM +0100, Marcus Folkesson wrote: watchdog_init_timeout() will allways pick

Re: [PATCH v7 0/2] hwmon: (ucd9000) Add gpio and debugfs interfaces

On 03/16/2018 02:22 PM, Eddie James wrote: The ucd9000 series chips have gpio pins. Add a gpio chip interface to the ucd device so that users can query and set the state of the gpio pins. Add a debugfs interface using the existing pmbus debugfs directory to provide MFR_STATUS and the status of

Re: [PATCH v7 0/2] hwmon: (ucd9000) Add gpio and debugfs interfaces

On 03/16/2018 02:22 PM, Eddie James wrote: The ucd9000 series chips have gpio pins. Add a gpio chip interface to the ucd device so that users can query and set the state of the gpio pins. Add a debugfs interface using the existing pmbus debugfs directory to provide MFR_STATUS and the status of

Re: [PATCH v5 0/2] Remove false-positive VLAs when using max()

On Fri, Mar 16, 2018 at 9:14 PM, Linus Torvalds wrote: > On Fri, Mar 16, 2018 at 1:03 PM, Miguel Ojeda > wrote: >>> >>> Kees - is there some online "gcc-4.4 checker" somewhere? This does >>> seem to work with my gcc. I actually

Re: [PATCH v5 0/2] Remove false-positive VLAs when using max()

On Fri, Mar 16, 2018 at 9:14 PM, Linus Torvalds wrote: > On Fri, Mar 16, 2018 at 1:03 PM, Miguel Ojeda > wrote: >>> >>> Kees - is there some online "gcc-4.4 checker" somewhere? This does >>> seem to work with my gcc. I actually tested some of those files you >>> pointed at now. >> >> I use this

Re: [v6] watchdog: add SPDX identifiers for watchdog subsystem

On Fri, Mar 16, 2018 at 04:14:11PM +0100, Marcus Folkesson wrote: > - Add SPDX identifier > - Remove boiler plate license text > - If MODULE_LICENSE and boiler plate does not match, go for boiler plate > license > > Signed-off-by: Marcus Folkesson > Acked-by: Adam

Re: [v6] watchdog: add SPDX identifiers for watchdog subsystem

On Fri, Mar 16, 2018 at 04:14:11PM +0100, Marcus Folkesson wrote: > - Add SPDX identifier > - Remove boiler plate license text > - If MODULE_LICENSE and boiler plate does not match, go for boiler plate > license > > Signed-off-by: Marcus Folkesson > Acked-by: Adam Thomson > Acked-by: Baruch

Re: [PATCH] net: ethernet: arc: Fix a potential memory leak if an optional regulator is deferred

Hi Christophe, Thank you for the patch! Yet something to improve: [auto build test ERROR on v4.16-rc4] [also build test ERROR on next-20180316] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits

Re: [PATCH] net: ethernet: arc: Fix a potential memory leak if an optional regulator is deferred

Hi Christophe, Thank you for the patch! Yet something to improve: [auto build test ERROR on v4.16-rc4] [also build test ERROR on next-20180316] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits

Re: [PATCH v3] vsprintf: Prevent crash when dereferencing invalid pointers

On (03/16/18 09:55), Petr Mladek wrote: [..] > I am not sure if it is worth it. I think that we would catch 99% of > problems by checking the first byte. > > This patch was motivated by a code clean up rather than bug reports. OK. Then I think we really need this "the patch is just good enough"

Re: [PATCH v3] vsprintf: Prevent crash when dereferencing invalid pointers

On (03/16/18 09:55), Petr Mladek wrote: [..] > I am not sure if it is worth it. I think that we would catch 99% of > problems by checking the first byte. > > This patch was motivated by a code clean up rather than bug reports. OK. Then I think we really need this "the patch is just good enough"

Re: [PATCH 2/2] kprobe: fix: Add ftrace_ops_assist_func to kprobe blacklist

On Sat, 17 Mar 2018 09:13:34 +0900 Masami Hiramatsu wrote: > On Fri, 16 Mar 2018 13:53:01 -0400 (EDT) > Mathieu Desnoyers wrote: > > > - On Mar 16, 2018, at 12:48 PM, rostedt rost...@goodmis.org wrote: > > > > > On Fri, 16 Mar 2018

Re: [PATCH 2/2] kprobe: fix: Add ftrace_ops_assist_func to kprobe blacklist

On Sat, 17 Mar 2018 09:13:34 +0900 Masami Hiramatsu wrote: > On Fri, 16 Mar 2018 13:53:01 -0400 (EDT) > Mathieu Desnoyers wrote: > > > - On Mar 16, 2018, at 12:48 PM, rostedt rost...@goodmis.org wrote: > > > > > On Fri, 16 Mar 2018 12:41:34 -0400 > > > Steven Rostedt wrote: > > > > > >>

[PATCH 02/14] mm/hmm: fix header file if/else/endif maze v2

From: Jérôme Glisse The #if/#else/#endif for IS_ENABLED(CONFIG_HMM) were wrong. Because of this after multiple include there was multiple definition of both hmm_mm_init() and hmm_mm_destroy() leading to build failure if HMM was enabled (CONFIG_HMM set). Changed since v1: -

Re: [PATCH v3 1/5] tpm: fix intermittent failure with self tests

On Mon, 2018-03-05 at 18:56 +0200, Jarkko Sakkinen wrote: > index 9e80a953d693..1adb976a2e37 100644 > --- a/drivers/char/tpm/tpm-interface.c > +++ b/drivers/char/tpm/tpm-interface.c > @@ -537,14 +537,26 @@ ssize_t tpm_transmit_cmd(struct tpm_chip *chip, > struct tpm_space *space, >  

[PATCH 02/14] mm/hmm: fix header file if/else/endif maze v2

From: Jérôme Glisse The #if/#else/#endif for IS_ENABLED(CONFIG_HMM) were wrong. Because of this after multiple include there was multiple definition of both hmm_mm_init() and hmm_mm_destroy() leading to build failure if HMM was enabled (CONFIG_HMM set). Changed since v1: - Fix the maze when

Re: [PATCH v3 1/5] tpm: fix intermittent failure with self tests

On Mon, 2018-03-05 at 18:56 +0200, Jarkko Sakkinen wrote: > index 9e80a953d693..1adb976a2e37 100644 > --- a/drivers/char/tpm/tpm-interface.c > +++ b/drivers/char/tpm/tpm-interface.c > @@ -537,14 +537,26 @@ ssize_t tpm_transmit_cmd(struct tpm_chip *chip, > struct tpm_space *space, >  

Re: [PATCH] acpi, numa: fix pxm to online numa node associations

[ adding Toshi's correct address ] On Thu, Mar 15, 2018 at 8:08 PM, Dan Williams wrote: > Commit 99759869faf1 "acpi: Add acpi_map_pxm_to_online_node()" added > support for mapping a given proximity to its nearest, by SLIT distance, > online node. However, it sometimes

Re: [PATCH] acpi, numa: fix pxm to online numa node associations

[ adding Toshi's correct address ] On Thu, Mar 15, 2018 at 8:08 PM, Dan Williams wrote: > Commit 99759869faf1 "acpi: Add acpi_map_pxm_to_online_node()" added > support for mapping a given proximity to its nearest, by SLIT distance, > online node. However, it sometimes returns unexpected results

Re: [PATCH v5 1/9] sysctl: Add flags to support min/max range clamping

On Fri, Mar 16, 2018 at 02:13:42PM -0400, Waiman Long wrote: > When the CTL_FLAGS_CLAMP_RANGE flag is set in the ctl_table > entry, any update from the userspace will be clamped to the given > range without error if either the proc_dointvec_minmax() or the > proc_douintvec_minmax() handlers is

Re: [PATCH v5 1/9] sysctl: Add flags to support min/max range clamping

On Fri, Mar 16, 2018 at 02:13:42PM -0400, Waiman Long wrote: > When the CTL_FLAGS_CLAMP_RANGE flag is set in the ctl_table > entry, any update from the userspace will be clamped to the given > range without error if either the proc_dointvec_minmax() or the > proc_douintvec_minmax() handlers is

[PATCH 1/2] regulator: add QCOM RPMh regulator driver

Add the QCOM RPMh regulator driver to manage PMIC regulators which are controlled via RPMh on some Qualcomm Technologies, Inc. SoCs. RPMh is a hardware block which contains several accelerators which are used to manage various hardware resources that are shared between the processors of the SoC.

[PATCH 1/2] regulator: add QCOM RPMh regulator driver

Add the QCOM RPMh regulator driver to manage PMIC regulators which are controlled via RPMh on some Qualcomm Technologies, Inc. SoCs. RPMh is a hardware block which contains several accelerators which are used to manage various hardware resources that are shared between the processors of the SoC.

[PATCH 0/2] regulator: add QCOM RPMh regulator driver

Hello, This patch series adds a driver and device tree binding documentation for PMIC regulator control via Resource Power Manager-hardened (RPMh) on some Qualcomm Technologies, Inc. SoCs such as SDM845. RPMh is a hardware block which contains several accelerators which are used to manage

[PATCH 2/2] dt-bindings: regulator: add QCOM RPMh regulator bindings

Introduce bindings for RPMh regulator devices found on some Qualcomm Technlogies, Inc. SoCs. These devices allow a given processor within the SoC to make PMIC regulator requests which are aggregated within the RPMh hardware block along with requests from other processors in the SoC to determine

[PATCH 0/2] regulator: add QCOM RPMh regulator driver

Hello, This patch series adds a driver and device tree binding documentation for PMIC regulator control via Resource Power Manager-hardened (RPMh) on some Qualcomm Technologies, Inc. SoCs such as SDM845. RPMh is a hardware block which contains several accelerators which are used to manage

[PATCH 2/2] dt-bindings: regulator: add QCOM RPMh regulator bindings

Introduce bindings for RPMh regulator devices found on some Qualcomm Technlogies, Inc. SoCs. These devices allow a given processor within the SoC to make PMIC regulator requests which are aggregated within the RPMh hardware block along with requests from other processors in the SoC to determine

Re: [linux-sunxi] [PATCH v4 7/9] clk: sunxi-ng: add support for the Allwinner H6 CCU

Hi, Dne petek, 16. marec 2018 ob 15:02:13 CET je Icenowy Zheng napisal(a): > The Allwinner H6 SoC has a CCU which has been largely rearranged. > > Add support for it in the sunxi-ng CCU framework. > > Signed-off-by: Icenowy Zheng > Acked-by: Maxime Ripard

Re: [linux-sunxi] [PATCH v4 7/9] clk: sunxi-ng: add support for the Allwinner H6 CCU

Hi, Dne petek, 16. marec 2018 ob 15:02:13 CET je Icenowy Zheng napisal(a): > The Allwinner H6 SoC has a CCU which has been largely rearranged. > > Add support for it in the sunxi-ng CCU framework. > > Signed-off-by: Icenowy Zheng > Acked-by: Maxime Ripard > --- > Changes in v4: > - Extract

Re: New -Werror=restrict error with incremental gcc

On 03/15/2018 08:11 PM, Josh Poimboeuf wrote: On Thu, Mar 15, 2018 at 08:06:26AM -0700, Laura Abbott wrote: This only showed up with the very latest rawhide snapshot, .17 worked and .18 started failing. I had to download .18 manually to test locally

Re: New -Werror=restrict error with incremental gcc

On 03/15/2018 08:11 PM, Josh Poimboeuf wrote: On Thu, Mar 15, 2018 at 08:06:26AM -0700, Laura Abbott wrote: This only showed up with the very latest rawhide snapshot, .17 worked and .18 started failing. I had to download .18 manually to test locally

Re: [PATCH v5 2/9] proc/sysctl: Provide additional ctl_table.flags checks

On Fri, Mar 16, 2018 at 02:13:43PM -0400, Waiman Long wrote: > Checking code is added to provide the following additional > ctl_table.flags checks: > > 1) No unknown flag is allowed. > 2) Minimum of a range cannot be larger than the maximum value. > 3) The signed and unsigned flags are

Re: [PATCH v5 2/9] proc/sysctl: Provide additional ctl_table.flags checks

On Fri, Mar 16, 2018 at 02:13:43PM -0400, Waiman Long wrote: > Checking code is added to provide the following additional > ctl_table.flags checks: > > 1) No unknown flag is allowed. > 2) Minimum of a range cannot be larger than the maximum value. > 3) The signed and unsigned flags are

Re: [PATCH v4 1/5] PCI: endpoint: BAR width should not depend on sizeof dma_addr_t

On Fri, Mar 16, 2018 at 06:02:20PM +, Lorenzo Pieralisi wrote: > On Thu, Mar 08, 2018 at 02:33:26PM +0100, Niklas Cassel wrote: > > If a BAR supports 64-bit width or not depends on the hardware, > > and should thus not depend on sizeof(dma_addr_t). > > > > Since this driver is generic,

Re: [PATCH v4 1/5] PCI: endpoint: BAR width should not depend on sizeof dma_addr_t

On Fri, Mar 16, 2018 at 06:02:20PM +, Lorenzo Pieralisi wrote: > On Thu, Mar 08, 2018 at 02:33:26PM +0100, Niklas Cassel wrote: > > If a BAR supports 64-bit width or not depends on the hardware, > > and should thus not depend on sizeof(dma_addr_t). > > > > Since this driver is generic,

Re: [PATCH 2/4] mm/hmm: fix header file if/else/endif maze

Hi Jérôme, I love your patch! Yet something to improve: [auto build test ERROR on linus/master] [also build test ERROR on v4.16-rc5 next-20180316] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux

Re: [PATCH 2/4] mm/hmm: fix header file if/else/endif maze

Hi Jérôme, I love your patch! Yet something to improve: [auto build test ERROR on linus/master] [also build test ERROR on v4.16-rc5 next-20180316] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux

Re: [PATCH v5 0/2] Remove false-positive VLAs when using max()

On Fri, Mar 16, 2018 at 9:14 PM, Linus Torvalds wrote: > On Fri, Mar 16, 2018 at 1:03 PM, Miguel Ojeda > wrote: >>> >>> Kees - is there some online "gcc-4.4 checker" somewhere? This does >>> seem to work with my gcc. I actually

Re: [PATCH v5 0/2] Remove false-positive VLAs when using max()

On Fri, Mar 16, 2018 at 9:14 PM, Linus Torvalds wrote: > On Fri, Mar 16, 2018 at 1:03 PM, Miguel Ojeda > wrote: >>> >>> Kees - is there some online "gcc-4.4 checker" somewhere? This does >>> seem to work with my gcc. I actually tested some of those files you >>> pointed at now. >> >> I use this

Re: [PATCH v4 09/10] drivers: qcom: rpmh: add support for batch RPMH request

On Fri, Mar 9, 2018 at 3:26 PM Lina Iyer wrote: > Platform drivers need make a lot of resource state requests at the same > time, say, at the start or end of an usecase. It can be quite > inefficient to send each request separately. Instead they can give the > RPMH library

Re: [PATCH v4 09/10] drivers: qcom: rpmh: add support for batch RPMH request

On Fri, Mar 9, 2018 at 3:26 PM Lina Iyer wrote: > Platform drivers need make a lot of resource state requests at the same > time, say, at the start or end of an usecase. It can be quite > inefficient to send each request separately. Instead they can give the > RPMH library a batch of requests to

Re: [PATCH v4 07/10] drivers: qcom: rpmh: cache sleep/wake state requests

On Fri, Mar 9, 2018 at 3:27 PM Lina Iyer wrote: > Active state requests are sent immediately to the mailbox controller, > while sleep and wake state requests are cached in this driver to avoid > taxing the mailbox controller repeatedly. The cached values will be sent > to

Re: [PATCH v4 07/10] drivers: qcom: rpmh: cache sleep/wake state requests

On Fri, Mar 9, 2018 at 3:27 PM Lina Iyer wrote: > Active state requests are sent immediately to the mailbox controller, > while sleep and wake state requests are cached in this driver to avoid > taxing the mailbox controller repeatedly. The cached values will be sent > to the controller when the

Re: [PATCH v4 05/10] drivers: qcom: rpmh-rsc: write sleep/wake requests to TCS

On Fri, Mar 9, 2018 at 3:27 PM Lina Iyer wrote: > Sleep and wake requests are sent when the application processor > subsystem of the SoC is entering deep sleep states like in suspend. > These requests help lower the system power requirements when the > resources are not in

Re: [PATCH v4 05/10] drivers: qcom: rpmh-rsc: write sleep/wake requests to TCS

On Fri, Mar 9, 2018 at 3:27 PM Lina Iyer wrote: > Sleep and wake requests are sent when the application processor > subsystem of the SoC is entering deep sleep states like in suspend. > These requests help lower the system power requirements when the > resources are not in use. > Sleep and wake

Re: [PATCH] dcache: remove trailing whitespace

TW, happens in *all* branches. If you do that kind > of stuff, at least do it against something in the public trees > and _tell_ _what_ _it_ _is_ _against_. Hello Al, I always base my patches on linux-next, which is usually correct, and if it isn't, the maintainer usually say

Re: [PATCH] dcache: remove trailing whitespace

hes. If you do that kind > of stuff, at least do it against something in the public trees > and _tell_ _what_ _it_ _is_ _against_. Hello Al, I always base my patches on linux-next, which is usually correct, and if it isn't, the maintainer usually says something :) The patch in question i

[PATCH] drm/i915: Disable some extra clang warnings

Commit 39bf4de89ff7 ("drm/i915: Add -Wall -Wextra to our build, set warnings to full") enabled extra warnings for i915 to spot possible bugs in new code, and then disabled a subset of these warnings to keep the current code building without warnings (with gcc). Enabling the extra warnings also

[PATCH] drm/i915: Disable some extra clang warnings

Commit 39bf4de89ff7 ("drm/i915: Add -Wall -Wextra to our build, set warnings to full") enabled extra warnings for i915 to spot possible bugs in new code, and then disabled a subset of these warnings to keep the current code building without warnings (with gcc). Enabling the extra warnings also

Re: general protection fault in ucma_connect

On Fri, Mar 16, 2018 at 04:59:02PM -0700, syzbot wrote: > Hello, > > syzbot hit the following crash on upstream commit > e2c15aff5f353ba80bd3bb49840837f65fa5cc43 (Thu Mar 15 18:07:35 2018 +) > Merge tag 'sound-4.16-rc6' of > git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound > > So

Re: general protection fault in ucma_connect

On Fri, Mar 16, 2018 at 04:59:02PM -0700, syzbot wrote: > Hello, > > syzbot hit the following crash on upstream commit > e2c15aff5f353ba80bd3bb49840837f65fa5cc43 (Thu Mar 15 18:07:35 2018 +) > Merge tag 'sound-4.16-rc6' of > git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound > > So

Re: [PATCH 2/2] kprobe: fix: Add ftrace_ops_assist_func to kprobe blacklist

On Fri, 16 Mar 2018 13:53:01 -0400 (EDT) Mathieu Desnoyers wrote: > - On Mar 16, 2018, at 12:48 PM, rostedt rost...@goodmis.org wrote: > > > On Fri, 16 Mar 2018 12:41:34 -0400 > > Steven Rostedt wrote: > > > >> Yes, kprobes are

Re: [PATCH 2/2] kprobe: fix: Add ftrace_ops_assist_func to kprobe blacklist

On Fri, 16 Mar 2018 13:53:01 -0400 (EDT) Mathieu Desnoyers wrote: > - On Mar 16, 2018, at 12:48 PM, rostedt rost...@goodmis.org wrote: > > > On Fri, 16 Mar 2018 12:41:34 -0400 > > Steven Rostedt wrote: > > > >> Yes, kprobes are dangerous. I'm not saying it shouldn't be fixed, I'm > >>

  1   2   3   4   5   6   7   8   9   10   >