RE: [PATCH] ARM: dts: BCM5301X: Relicense most DTS files to the GPL 2.0+ / MIT

On 05/02/2018 04:11 PM, Rafał Miłecki wrote: > From: Rafał Miłecki > > These files were created and ever touched by a group of three people > only: Dan, Hauke and me. They were licensed under GNU/GPL or ISC. > > Introducing and discussing SPDX-License-Identifier resulted in a >

RE: [PATCH] ARM: dts: BCM5301X: Relicense most DTS files to the GPL 2.0+ / MIT

On 05/02/2018 04:11 PM, Rafał Miłecki wrote: > From: Rafał Miłecki > > These files were created and ever touched by a group of three people > only: Dan, Hauke and me. They were licensed under GNU/GPL or ISC. > > Introducing and discussing SPDX-License-Identifier resulted in a > conclusion that

Re: bug-introducing patches

On Wed, May 02, 2018 at 05:32:37PM +0200, Geert Uytterhoeven wrote: >Hi Sasha, > >On Tue, May 1, 2018 at 6:38 PM, Sasha Levin > wrote: >> Working on AUTOSEL, it became even more obvious to me how difficult it is >> for a >> patch to get a proper review. Maintainers

Re: bug-introducing patches

On Wed, May 02, 2018 at 05:32:37PM +0200, Geert Uytterhoeven wrote: >Hi Sasha, > >On Tue, May 1, 2018 at 6:38 PM, Sasha Levin > wrote: >> Working on AUTOSEL, it became even more obvious to me how difficult it is >> for a >> patch to get a proper review. Maintainers found it difficult to keep up

Re: [Ksummit-discuss] bug-introducing patches

On Wed, May 02, 2018 at 10:11:14AM +0200, Daniel Vetter wrote: >On Tue, May 1, 2018 at 11:15 PM, Mark Brown wrote: >> On Tue, May 01, 2018 at 04:54:48PM -0400, Theodore Y. Ts'o wrote: >>> I do think it's about AUTOSEL, because when I'm dealing with a >>> regression, I want to

Re: [Ksummit-discuss] bug-introducing patches

On Wed, May 02, 2018 at 10:11:14AM +0200, Daniel Vetter wrote: >On Tue, May 1, 2018 at 11:15 PM, Mark Brown wrote: >> On Tue, May 01, 2018 at 04:54:48PM -0400, Theodore Y. Ts'o wrote: >>> I do think it's about AUTOSEL, because when I'm dealing with a >>> regression, I want to get it fixed fast.

Re: [PATCH v7 03/10] drivers: qcom: rpmh-rsc: log RPMH requests in FTRACE

On Wed, 2 May 2018 13:37:42 -0600 Lina Iyer wrote: > Log sent RPMH requests and interrupt responses in FTRACE. > > Cc: Steven Rostedt > Signed-off-by: Lina Iyer Reviewed-by: Steven Rostedt (VMware) It's

Re: [PATCH v7 03/10] drivers: qcom: rpmh-rsc: log RPMH requests in FTRACE

On Wed, 2 May 2018 13:37:42 -0600 Lina Iyer wrote: > Log sent RPMH requests and interrupt responses in FTRACE. > > Cc: Steven Rostedt > Signed-off-by: Lina Iyer Reviewed-by: Steven Rostedt (VMware) It's now up to the subsystem maintainer to apply it. -- Steve

Re: [PATCH] x86/mm: Introduce 'no5vl kernel parameter

Hi Kirill, Thank you for the patch! Perhaps something to improve: [auto build test WARNING on tip/auto-latest] [also build test WARNING on v4.17-rc3 next-20180502] [cannot apply to tip/x86/core] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system

Re: [PATCH] x86/mm: Introduce 'no5vl kernel parameter

Hi Kirill, Thank you for the patch! Perhaps something to improve: [auto build test WARNING on tip/auto-latest] [also build test WARNING on v4.17-rc3 next-20180502] [cannot apply to tip/x86/core] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system

Re: bug-introducing patches

On Wed, May 02, 2018 at 06:30:17AM +0200, Willy Tarreau wrote: >On Tue, May 01, 2018 at 10:02:30PM +, Sasha Levin wrote: >> On Tue, May 01, 2018 at 04:54:48PM -0400, Theodore Y. Ts'o wrote: >> >Post -rc3 or -rc4, in my opinion bug fixes should wait until the next >> >merge window before they

Re: bug-introducing patches

On Wed, May 02, 2018 at 06:30:17AM +0200, Willy Tarreau wrote: >On Tue, May 01, 2018 at 10:02:30PM +, Sasha Levin wrote: >> On Tue, May 01, 2018 at 04:54:48PM -0400, Theodore Y. Ts'o wrote: >> >Post -rc3 or -rc4, in my opinion bug fixes should wait until the next >> >merge window before they

[PATCH v7 01/10] drivers: qcom: rpmh-rsc: add RPMH controller for QCOM SoCs

Add controller driver for QCOM SoCs that have hardware based shared resource management. The hardware IP known as RSC (Resource State Coordinator) houses multiple Direct Resource Voter (DRV) for different execution levels. A DRV is a unique voter on the state of a shared resource. A Trigger

[PATCH v7 01/10] drivers: qcom: rpmh-rsc: add RPMH controller for QCOM SoCs

Add controller driver for QCOM SoCs that have hardware based shared resource management. The hardware IP known as RSC (Resource State Coordinator) houses multiple Direct Resource Voter (DRV) for different execution levels. A DRV is a unique voter on the state of a shared resource. A Trigger

Re: Motorola Droid 4 progress, power consumption

* Pavel Machek [180502 19:12]: > Hi! > > > > Anyway, >5.5hours of standby with screen off, GSM on is already > > > usable. > > > > Just to rub that in, you do mean GSM usable for voice calls and > > SMS with your unicsy_demo with mainline kernel plus the pending > > LCD related

Re: Motorola Droid 4 progress, power consumption

* Pavel Machek [180502 19:12]: > Hi! > > > > Anyway, >5.5hours of standby with screen off, GSM on is already > > > usable. > > > > Just to rub that in, you do mean GSM usable for voice calls and > > SMS with your unicsy_demo with mainline kernel plus the pending > > LCD related patches, right?

[ANNOUNCE] 4.4.126-rt142

Hello RT Folks! I'm pleased to announce the 4.4.126-rt142 stable release. This release contains -rt changes only. It contains patches I identified which were missing in the v4.4-rt tree. There are sill a few more missing, which I haven't included into the release candidate for review. Meanwhile

[ANNOUNCE] 4.4.126-rt142

Hello RT Folks! I'm pleased to announce the 4.4.126-rt142 stable release. This release contains -rt changes only. It contains patches I identified which were missing in the v4.4-rt tree. There are sill a few more missing, which I haven't included into the release candidate for review. Meanwhile

Re: [PATCH] ARM: dts: BCM5301X: Relicense most DTS files to the GPL 2.0+ / MIT

On 05/02/2018 04:11 PM, Rafał Miłecki wrote: > From: Rafał Miłecki > > These files were created and ever touched by a group of three people > only: Dan, Hauke and me. They were licensed under GNU/GPL or ISC. > > Introducing and discussing SPDX-License-Identifier resulted in a

Re: [PATCH] ARM: dts: BCM5301X: Relicense most DTS files to the GPL 2.0+ / MIT

On 05/02/2018 04:11 PM, Rafał Miłecki wrote: > From: Rafał Miłecki > > These files were created and ever touched by a group of three people > only: Dan, Hauke and me. They were licensed under GNU/GPL or ISC. > > Introducing and discussing SPDX-License-Identifier resulted in a > conclusion that

[PATCH v7 04/10] drivers: qcom: rpmh: add RPMH helper functions

Sending RPMH requests and waiting for response from the controller through a callback is common functionality across all platform drivers. To simplify drivers, add a library functions to create RPMH client and send resource state requests. rpmh_write() is a synchronous blocking call that can be

Re: [PATCH] x86/mm: Introduce 'no5vl kernel parameter

Hi Kirill, Thank you for the patch! Yet something to improve: [auto build test ERROR on tip/auto-latest] [also build test ERROR on v4.17-rc3 next-20180502] [cannot apply to tip/x86/core] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url

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

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 requests are written to the TCS slots but are not triggered

[PATCH v7 04/10] drivers: qcom: rpmh: add RPMH helper functions

Sending RPMH requests and waiting for response from the controller through a callback is common functionality across all platform drivers. To simplify drivers, add a library functions to create RPMH client and send resource state requests. rpmh_write() is a synchronous blocking call that can be

Re: [PATCH] x86/mm: Introduce 'no5vl kernel parameter

Hi Kirill, Thank you for the patch! Yet something to improve: [auto build test ERROR on tip/auto-latest] [also build test ERROR on v4.17-rc3 next-20180502] [cannot apply to tip/x86/core] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url

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

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 requests are written to the TCS slots but are not triggered

[PATCH v7 06/10] drivers: qcom: rpmh-rsc: allow invalidation of sleep/wake TCS

Allow sleep and wake commands to be cleared from the respective TCSes, so that they can be re-populated. Signed-off-by: Lina Iyer --- Changes in v7: - Move bitmap_zero() outside the loop Changes in v6: - remove unnecessary locks around __tcs_invalidate

[PATCH v7 06/10] drivers: qcom: rpmh-rsc: allow invalidation of sleep/wake TCS

Allow sleep and wake commands to be cleared from the respective TCSes, so that they can be re-populated. Signed-off-by: Lina Iyer --- Changes in v7: - Move bitmap_zero() outside the loop Changes in v6: - remove unnecessary locks around __tcs_invalidate - rename function

[PATCH v7 08/10] drivers: qcom: rpmh: allow requests to be sent asynchronously

Platform drivers that want to send a request but do not want to block until the RPMH request completes have now a new API - rpmh_write_async(). The API allocates memory and send the requests and returns the control back to the platform driver. The tx_done callback from the controller is handled

[PATCH v7 08/10] drivers: qcom: rpmh: allow requests to be sent asynchronously

Platform drivers that want to send a request but do not want to block until the RPMH request completes have now a new API - rpmh_write_async(). The API allocates memory and send the requests and returns the control back to the platform driver. The tx_done callback from the controller is handled

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

Active state requests are sent immediately to the RSC controller, while sleep and wake state requests are cached in this driver to avoid taxing the RSC controller repeatedly. The cached values will be sent to the controller when the rpmh_flush() is called. Generally, flushing is a system PM

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

Active state requests are sent immediately to the RSC controller, while sleep and wake state requests are cached in this driver to avoid taxing the RSC controller repeatedly. The cached values will be sent to the controller when the rpmh_flush() is called. Generally, flushing is a system PM

[PATCH v7 02/10] dt-bindings: introduce RPMH RSC bindings for Qualcomm SoCs

Add device binding documentation for Qualcomm Technology Inc's RPMH RSC driver. The driver is used for communicating resource state requests for shared resources. Cc: devicet...@vger.kernel.org Signed-off-by: Lina Iyer Reviewed-by: Rob Herring --- Changes

[PATCH v7 02/10] dt-bindings: introduce RPMH RSC bindings for Qualcomm SoCs

Add device binding documentation for Qualcomm Technology Inc's RPMH RSC driver. The driver is used for communicating resource state requests for shared resources. Cc: devicet...@vger.kernel.org Signed-off-by: Lina Iyer Reviewed-by: Rob Herring --- Changes in v7: - Fix example Changes

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

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 be sent and wait on the whole transaction to be complete.

[PATCH v7 10/10] drivers: qcom: rpmh-rsc: allow active requests from wake TCS

Some RSCs may only have sleep and wake TCS, i.e, there is no dedicated TCS for active mode request, but drivers may still want to make active requests from these RSCs. In such cases re-purpose the wake TCS to send active state requests. The requirement for this is that the driver is aware that

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

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 be sent and wait on the whole transaction to be complete.

[PATCH v7 10/10] drivers: qcom: rpmh-rsc: allow active requests from wake TCS

Some RSCs may only have sleep and wake TCS, i.e, there is no dedicated TCS for active mode request, but drivers may still want to make active requests from these RSCs. In such cases re-purpose the wake TCS to send active state requests. The requirement for this is that the driver is aware that

[PATCH v7 03/10] drivers: qcom: rpmh-rsc: log RPMH requests in FTRACE

Log sent RPMH requests and interrupt responses in FTRACE. Cc: Steven Rostedt Signed-off-by: Lina Iyer --- Changes in v7: - varible name changes and white space Changes in v6: - struct tcs_response was removed. Fix in trace as well.

[PATCH v7 03/10] drivers: qcom: rpmh-rsc: log RPMH requests in FTRACE

Log sent RPMH requests and interrupt responses in FTRACE. Cc: Steven Rostedt Signed-off-by: Lina Iyer --- Changes in v7: - varible name changes and white space Changes in v6: - struct tcs_response was removed. Fix in trace as well. Changes in v4: - fix compilation

[PATCH v7 00/10] drivers/qcom: add RPMH communication support

Changes in v7: - Rename 'm' and 'n' and use tcs_id and cmd_id instead - Bug fix in find_match() and other review comments from Matthias - Spinlock around get_rpmh_ctrlr() - DT documentation example fixes - Rebase on top of 4.16-rc2 Changes in v6: - Remove tasklet in rpmh-rsc.c - Remove

[PATCH v7 00/10] drivers/qcom: add RPMH communication support

Changes in v7: - Rename 'm' and 'n' and use tcs_id and cmd_id instead - Bug fix in find_match() and other review comments from Matthias - Spinlock around get_rpmh_ctrlr() - DT documentation example fixes - Rebase on top of 4.16-rc2 Changes in v6: - Remove tasklet in rpmh-rsc.c - Remove

Re: [PATCH] drm/bridge: vga-dac: Fix edid memory leak

On Fri, Apr 20, 2018 at 02:59:59PM -0400, Sean Paul wrote: > edid should be freed once it's finished being used. > > Fixes: 56fe8b6f4991 ("drm/bridge: Add RGB to VGA bridge support") > Cc: Rob Herring > Cc: Sean Paul > Cc: Maxime Ripard

Re: [PATCH] drm/bridge: vga-dac: Fix edid memory leak

On Fri, Apr 20, 2018 at 02:59:59PM -0400, Sean Paul wrote: > edid should be freed once it's finished being used. > > Fixes: 56fe8b6f4991 ("drm/bridge: Add RGB to VGA bridge support") > Cc: Rob Herring > Cc: Sean Paul > Cc: Maxime Ripard > Cc: Archit Taneja > Cc: Andrzej Hajda > Cc: Laurent

Re: [PATCH] kbuild/debian: Use KBUILD_BUILD_* when set

On Wed, May 2, 2018 at 9:27 PM, Mathieu Malaterre wrote: > On Wed, May 2, 2018 at 1:30 PM, Riku Voipio wrote: >> On 23 April 2018 at 22:50, Mathieu Malaterre wrote: >>> Be nice to the user and check env vars KBUILD_BUILD_USER & >>>

Re: [PATCH] kbuild/debian: Use KBUILD_BUILD_* when set

On Wed, May 2, 2018 at 9:27 PM, Mathieu Malaterre wrote: > On Wed, May 2, 2018 at 1:30 PM, Riku Voipio wrote: >> On 23 April 2018 at 22:50, Mathieu Malaterre wrote: >>> Be nice to the user and check env vars KBUILD_BUILD_USER & >>> KBUILD_BUILD_HOST when those are set. >> >> mkdebian sets the

Re: [RFC PATCH v3 3/3] acpi: apei: Warn when GHES marks correctable errors as "fatal"

On 05/02/2018 02:10 PM, Pavel Machek wrote: > On Thu 2018-04-26 13:20:57, Borislav Petkov wrote: >> On Wed, Apr 25, 2018 at 03:39:51PM -0500, Alexandru Gagniuc wrote: >>> There seems to be a culture amongst BIOS teams to want to crash the >>> OS when an error can't be handled in firmware. Marking

Re: [RFC PATCH v3 3/3] acpi: apei: Warn when GHES marks correctable errors as "fatal"

On 05/02/2018 02:10 PM, Pavel Machek wrote: > On Thu 2018-04-26 13:20:57, Borislav Petkov wrote: >> On Wed, Apr 25, 2018 at 03:39:51PM -0500, Alexandru Gagniuc wrote: >>> There seems to be a culture amongst BIOS teams to want to crash the >>> OS when an error can't be handled in firmware. Marking

[PATCH] memcg: Replace mm->owner with mm->memcg

Recently it was reported that mm_update_next_owner could get into cases where it was executing it's fallback for_each_process part of the loop and thus taking up a lot of time. To deal with this replace mm->owner with mm->memcg. This just reduces the complexity of everything. As much as

[PATCH] memcg: Replace mm->owner with mm->memcg

Recently it was reported that mm_update_next_owner could get into cases where it was executing it's fallback for_each_process part of the loop and thus taking up a lot of time. To deal with this replace mm->owner with mm->memcg. This just reduces the complexity of everything. As much as

Re: [PATCH] kbuild/debian: Use KBUILD_BUILD_* when set

On Wed, May 2, 2018 at 1:30 PM, Riku Voipio wrote: > On 23 April 2018 at 22:50, Mathieu Malaterre wrote: >> Be nice to the user and check env vars KBUILD_BUILD_USER & >> KBUILD_BUILD_HOST when those are set. > > mkdebian sets the maintainer address as

Re: [PATCH] kbuild/debian: Use KBUILD_BUILD_* when set

On Wed, May 2, 2018 at 1:30 PM, Riku Voipio wrote: > On 23 April 2018 at 22:50, Mathieu Malaterre wrote: >> Be nice to the user and check env vars KBUILD_BUILD_USER & >> KBUILD_BUILD_HOST when those are set. > > mkdebian sets the maintainer address as "$name <$email>", but this > patch only sets

Re: [PATCH v2 4/5] kernel hacking: new config DEBUG_EXPERIENCE to apply GCC -Og optimization

On 05/02/2018 06:44 AM, changbin...@intel.com wrote: > From: Changbin Du > Sorry, I missed one: > diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug > index ab55801..e264199 100644 > --- a/lib/Kconfig.debug > +++ b/lib/Kconfig.debug > @@ -216,6 +216,27 @@ config

Re: [PATCH v2 4/5] kernel hacking: new config DEBUG_EXPERIENCE to apply GCC -Og optimization

On 05/02/2018 06:44 AM, changbin...@intel.com wrote: > From: Changbin Du > Sorry, I missed one: > diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug > index ab55801..e264199 100644 > --- a/lib/Kconfig.debug > +++ b/lib/Kconfig.debug > @@ -216,6 +216,27 @@ config NO_AUTO_INLINE > > If

Re: Motorola Droid 4 progress, power consumption

Hi! > > Anyway, >5.5hours of standby with screen off, GSM on is already > > usable. > > Just to rub that in, you do mean GSM usable for voice calls and > SMS with your unicsy_demo with mainline kernel plus the pending > LCD related patches, right? :) Plus some other patches, yes. > > This is

Re: Motorola Droid 4 progress, power consumption

Hi! > > Anyway, >5.5hours of standby with screen off, GSM on is already > > usable. > > Just to rub that in, you do mean GSM usable for voice calls and > SMS with your unicsy_demo with mainline kernel plus the pending > LCD related patches, right? :) Plus some other patches, yes. > > This is

Re: [RFC PATCH v3 3/3] acpi: apei: Warn when GHES marks correctable errors as "fatal"

On Thu 2018-04-26 13:20:57, Borislav Petkov wrote: > On Wed, Apr 25, 2018 at 03:39:51PM -0500, Alexandru Gagniuc wrote: > > There seems to be a culture amongst BIOS teams to want to crash the > > OS when an error can't be handled in firmware. Marking GHES errors as > > "fatal" is a very common way

Re: [RFC PATCH v3 3/3] acpi: apei: Warn when GHES marks correctable errors as "fatal"

On Thu 2018-04-26 13:20:57, Borislav Petkov wrote: > On Wed, Apr 25, 2018 at 03:39:51PM -0500, Alexandru Gagniuc wrote: > > There seems to be a culture amongst BIOS teams to want to crash the > > OS when an error can't be handled in firmware. Marking GHES errors as > > "fatal" is a very common way

Re: [PATCH] proc: restore seekdir("/proc", 256) semantics

Hi! > Long time ago "/proc/self" was an honest symlink and all not-PID entries > were output before /proc/$PID. To not lose /proc/self in readdir output > after it became permanently positive dentry it was stuck before /proc/1. > > One side effect of the change was that the code > > d =

Re: [PATCH] proc: restore seekdir("/proc", 256) semantics

Hi! > Long time ago "/proc/self" was an honest symlink and all not-PID entries > were output before /proc/$PID. To not lose /proc/self in readdir output > after it became permanently positive dentry it was stuck before /proc/1. > > One side effect of the change was that the code > > d =

Re: [RFC PATCH] driver core: make deferring probe forever optional

On 02/05/18 15:48, Rob Herring wrote: On Wed, May 2, 2018 at 6:40 AM, Robin Murphy wrote: On 01/05/18 22:31, Rob Herring wrote: Deferred probe will currently wait forever on dependent devices to probe, but sometimes a driver will never exist. It's also not always

Re: [RFC PATCH] driver core: make deferring probe forever optional

On 02/05/18 15:48, Rob Herring wrote: On Wed, May 2, 2018 at 6:40 AM, Robin Murphy wrote: On 01/05/18 22:31, Rob Herring wrote: Deferred probe will currently wait forever on dependent devices to probe, but sometimes a driver will never exist. It's also not always critical for a driver to

Re: [PATCH 2/2] clk: qcom: Add video clock controller driver for SDM845

Quoting Nischal, Amit (2018-05-02 00:56:35) > > > Thanks for the review. > As of now, there are no resets defined for VIDEOCC. So I will move > the #reset-cells tooptional property in the dt-binding. > Same will be updated in the next patch series. Please don't make it optional. It should be

Re: [PATCH 2/2] clk: qcom: Add video clock controller driver for SDM845

Quoting Nischal, Amit (2018-05-02 00:56:35) > > > Thanks for the review. > As of now, there are no resets defined for VIDEOCC. So I will move > the #reset-cells tooptional property in the dt-binding. > Same will be updated in the next patch series. Please don't make it optional. It should be

Re: [PATCH 2/2] iov_iter: fix memory leak in pipe_get_pages_alloc()

On Wed, May 02, 2018 at 08:16:57PM +0200, Ilya Dryomov wrote: > Make n signed to avoid leaking the pages array if __pipe_get_pages() > fails. Applied, with s/fails/& to allocate any pages/.

Re: [PATCH 2/2] iov_iter: fix memory leak in pipe_get_pages_alloc()

On Wed, May 02, 2018 at 08:16:57PM +0200, Ilya Dryomov wrote: > Make n signed to avoid leaking the pages array if __pipe_get_pages() > fails. Applied, with s/fails/& to allocate any pages/.

Re: [PATCH v2] Input: atmel_mxt_ts - add missing compatible strings to OF device table

Hi Dmitry, On 05/01/2018 10:57 PM, Dmitry Torokhov wrote: > From: Javier Martinez Canillas > > Commit af503716ac14 ("i2c: core: report OF style module alias for devices > registered via OF") fixed how the I2C core reports the module alias when > devices are registered via

Re: [PATCH v2] Input: atmel_mxt_ts - add missing compatible strings to OF device table

Hi Dmitry, On 05/01/2018 10:57 PM, Dmitry Torokhov wrote: > From: Javier Martinez Canillas > > Commit af503716ac14 ("i2c: core: report OF style module alias for devices > registered via OF") fixed how the I2C core reports the module alias when > devices are registered via OF. > > But the

[PATCH] arm: omap1: ams-delta: fix deferred_fiq handler

The deferred_fiq handler used to limit hardware operations to IRQ unmask only, relying on gpio-omap assigned handler performing the ACKs. Since commit 80ac93c27441 ("gpio: omap: Fix lost edge interrupts") this is no longer the case as handle_edge_irq() has been replaced with handle_simmple_irq()

[PATCH] arm: omap1: ams-delta: fix deferred_fiq handler

The deferred_fiq handler used to limit hardware operations to IRQ unmask only, relying on gpio-omap assigned handler performing the ACKs. Since commit 80ac93c27441 ("gpio: omap: Fix lost edge interrupts") this is no longer the case as handle_edge_irq() has been replaced with handle_simmple_irq()

Re: [RFC PATCH for 4.18 00/14] Restartable Sequences

On Wed, May 2, 2018 at 10:22 AM Peter Zijlstra wrote: >> On Wed, May 02, 2018 at 03:53:47AM +, Daniel Colascione wrote: > > Suppose we make a userspace mutex implemented with a lock word having three > > bits: acquired, sleep_mode, and wait_pending, with the rest of the

Re: [RFC PATCH for 4.18 00/14] Restartable Sequences

On Wed, May 2, 2018 at 10:22 AM Peter Zijlstra wrote: >> On Wed, May 02, 2018 at 03:53:47AM +, Daniel Colascione wrote: > > Suppose we make a userspace mutex implemented with a lock word having three > > bits: acquired, sleep_mode, and wait_pending, with the rest of the word not > > being

[PATCH 3/4] staging: lustre: obdclass: guarantee all keys filled

From: Hongchao Zhang In keys_fill, the key_set_version could be changed after the keys are filled, then the keys in this context won't be refilled by the following lu_context_refill for its version is equal to the current key_set_version. In lu_context_refill, the

[PATCH 3/4] staging: lustre: obdclass: guarantee all keys filled

From: Hongchao Zhang In keys_fill, the key_set_version could be changed after the keys are filled, then the keys in this context won't be refilled by the following lu_context_refill for its version is equal to the current key_set_version. In lu_context_refill, the key_set_version should be

[PATCH 2/4] staging: lustre: obdclass: hoist locking in lu_context_exit()

From: "John L. Hammond" Hoist lu_keys_guard locking out of the for loop in lu_context_exit(). Signed-off-by: John L. Hammond Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-8918 Reviewed-on: https://review.whamcloud.com/24217 Reviewed-by:

[PATCH 1/4] staging: lustre: obdclass: change spinlock of key to rwlock

From: Li Xi Most of the time, keys are never changed. So rwlock might be better for the concurrency of key read. Signed-off-by: Li Xi Signed-off-by: Gu Zheng Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-6800 Reviewed-on:

[PATCH 1/4] staging: lustre: obdclass: change spinlock of key to rwlock

From: Li Xi Most of the time, keys are never changed. So rwlock might be better for the concurrency of key read. Signed-off-by: Li Xi Signed-off-by: Gu Zheng Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-6800 Reviewed-on: http://review.whamcloud.com/15558 Reviewed-by: Faccini Bruno

[PATCH 2/4] staging: lustre: obdclass: hoist locking in lu_context_exit()

From: "John L. Hammond" Hoist lu_keys_guard locking out of the for loop in lu_context_exit(). Signed-off-by: John L. Hammond Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-8918 Reviewed-on: https://review.whamcloud.com/24217 Reviewed-by: Dmitry Eremin Reviewed-by: Jinshan Xiong

[PATCH 4/4] staging: lustre: obdclass: change object lookup to no wait mode

From: Lai Siyao Currently we set LU_OBJECT_HEARD_BANSHEE on object when we want to remove object from cache, but this may lead to deadlock, because when other process lookup such object, it needs to wait for this object until release (done at last refcount put), while that

[PATCH 4/4] staging: lustre: obdclass: change object lookup to no wait mode

From: Lai Siyao Currently we set LU_OBJECT_HEARD_BANSHEE on object when we want to remove object from cache, but this may lead to deadlock, because when other process lookup such object, it needs to wait for this object until release (done at last refcount put), while that process maybe already

[PATCH 0/4] staging: lustre: obdclass: missing lu_object fixes

With the work going for lu_object by Neil I noticed him solving the same problem as the Intel developers in a very similar approach. Also with the changes we don't want to lose these important changes. This is more mean for a basic review since in the end Neil and this work will be combined in

[PATCH 0/4] staging: lustre: obdclass: missing lu_object fixes

With the work going for lu_object by Neil I noticed him solving the same problem as the Intel developers in a very similar approach. Also with the changes we don't want to lose these important changes. This is more mean for a basic review since in the end Neil and this work will be combined in

Re: [lustre-devel] [PATCH 04/10] staging: lustre: lu_object: move retry logic inside htable_lookup

> On Apr 30, 2018, at 21:52, NeilBrown wrote: > > > > The current retry logic, to wait when a 'dying' object is found, > > spans multiple functions. The process is attached to a waitqueue > > and set TASK_UNINTERRUPTIBLE in htable_lookup, and this status > > is passed back

Re: [lustre-devel] [PATCH 04/10] staging: lustre: lu_object: move retry logic inside htable_lookup

> On Apr 30, 2018, at 21:52, NeilBrown wrote: > > > > The current retry logic, to wait when a 'dying' object is found, > > spans multiple functions. The process is attached to a waitqueue > > and set TASK_UNINTERRUPTIBLE in htable_lookup, and this status > > is passed back through

[PATCH 2/2] iov_iter: fix memory leak in pipe_get_pages_alloc()

Make n signed to avoid leaking the pages array if __pipe_get_pages() fails. Signed-off-by: Ilya Dryomov --- lib/iov_iter.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lib/iov_iter.c b/lib/iov_iter.c index 4d5bf40d399d..fdae394172fa 100644 ---

[PATCH 2/2] iov_iter: fix memory leak in pipe_get_pages_alloc()

Make n signed to avoid leaking the pages array if __pipe_get_pages() fails. Signed-off-by: Ilya Dryomov --- lib/iov_iter.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lib/iov_iter.c b/lib/iov_iter.c index 4d5bf40d399d..fdae394172fa 100644 --- a/lib/iov_iter.c +++

Re: [PATCH v2 3/4] seccomp: Audit attempts to modify the actions_logged sysctl

On Wednesday, May 2, 2018 11:53:19 AM EDT Tyler Hicks wrote: > The decision to log a seccomp action will always be subject to the > value of the kernel.seccomp.actions_logged sysctl, even for processes > that are being inspected via the audit subsystem, in an upcoming patch. > Therefore, we need

Re: [PATCH v2 3/4] seccomp: Audit attempts to modify the actions_logged sysctl

On Wednesday, May 2, 2018 11:53:19 AM EDT Tyler Hicks wrote: > The decision to log a seccomp action will always be subject to the > value of the kernel.seccomp.actions_logged sysctl, even for processes > that are being inspected via the audit subsystem, in an upcoming patch. > Therefore, we need

Re: [PATCH 09/10] staging: lustre: move remaining code from linux-module.c to module.c

> There is no longer any need to keep this code separate, > and now we can remove linux-module.c > > Signed-off-by: NeilBrown Reviewed-by: James Simmons > --- > .../staging/lustre/include/linux/libcfs/libcfs.h |4 >

Re: [PATCH 09/10] staging: lustre: move remaining code from linux-module.c to module.c

> There is no longer any need to keep this code separate, > and now we can remove linux-module.c > > Signed-off-by: NeilBrown Reviewed-by: James Simmons > --- > .../staging/lustre/include/linux/libcfs/libcfs.h |4 > drivers/staging/lustre/lnet/libcfs/Makefile|1 >

[PATCH 1/2] iov_iter: fix return type of __pipe_get_pages()

It returns -EFAULT and happens to be a helper for pipe_get_pages() whose return type is ssize_t. Signed-off-by: Ilya Dryomov --- lib/iov_iter.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lib/iov_iter.c b/lib/iov_iter.c index

[PATCH 1/2] iov_iter: fix return type of __pipe_get_pages()

It returns -EFAULT and happens to be a helper for pipe_get_pages() whose return type is ssize_t. Signed-off-by: Ilya Dryomov --- lib/iov_iter.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lib/iov_iter.c b/lib/iov_iter.c index 970212670b6a..4d5bf40d399d 100644 ---

Re: [PATCH 08/10] staging: lustre: move misc-device registration closer to related code.

> The ioctl handler for the misc device is in lnet/libcfs/module.c > but is it registered in lnet/libcfs/linux/linux-module.c. > > Keeping related code together make maintenance easier, so move the > code. > > Signed-off-by: NeilBrown Reviewed-by: James Simmons

Re: [PATCH 08/10] staging: lustre: move misc-device registration closer to related code.

> The ioctl handler for the misc device is in lnet/libcfs/module.c > but is it registered in lnet/libcfs/linux/linux-module.c. > > Keeping related code together make maintenance easier, so move the > code. > > Signed-off-by: NeilBrown Reviewed-by: James Simmons > --- >

Re: [PATCH 01/10] staging: lustre: ldlm: store name directly in namespace.

> Rather than storing the name of a namespace in the > hash table, store it directly in the namespace. > This will allow the hashtable to be changed to use > rhashtable. > > Signed-off-by: NeilBrown Reviewed-by: James Simmons > --- >

Re: [PATCH 01/10] staging: lustre: ldlm: store name directly in namespace.

> Rather than storing the name of a namespace in the > hash table, store it directly in the namespace. > This will allow the hashtable to be changed to use > rhashtable. > > Signed-off-by: NeilBrown Reviewed-by: James Simmons > --- > drivers/staging/lustre/lustre/include/lustre_dlm.h |5

Re: [PATCH v4 0/6] clocksource: rework Atmel TCB timer driver

On 02/05/2018 15:34:18+0200, Sebastian Andrzej Siewior wrote: > On 2018-04-26 20:52:33 [+0200], Alexandre Belloni wrote: > > > > I don't remember you posted anything for the TCB. Wasn't it focused on > > getting rid of the PIT irq? > > the PIT irq which was shared with the UART one some devices,

Re: [PATCH v4 0/6] clocksource: rework Atmel TCB timer driver

On 02/05/2018 15:34:18+0200, Sebastian Andrzej Siewior wrote: > On 2018-04-26 20:52:33 [+0200], Alexandre Belloni wrote: > > > > I don't remember you posted anything for the TCB. Wasn't it focused on > > getting rid of the PIT irq? > > the PIT irq which was shared with the UART one some devices,

Re: [lustre_init] BUG: unable to handle kernel NULL pointer dereference at 0000000000000004

> Hello, > > FYI this happens in mainline kernel 4.17.0-rc3. > It looks like a new regression since v4.17-rc1. > > It occurs in 2 out of 2 boots. > > [ 54.222599] Magic number: 14:276:994 > [ 54.223261] tty ttyd7: hash matches > [ 54.223841] tty ttyaa: hash matches > [ 54.227288]

Re: [lustre_init] BUG: unable to handle kernel NULL pointer dereference at 0000000000000004

> Hello, > > FYI this happens in mainline kernel 4.17.0-rc3. > It looks like a new regression since v4.17-rc1. > > It occurs in 2 out of 2 boots. > > [ 54.222599] Magic number: 14:276:994 > [ 54.223261] tty ttyd7: hash matches > [ 54.223841] tty ttyaa: hash matches > [ 54.227288]

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