[PATCH] drm/panel: simple: Fix the bus_format for the Ontat panel.

This fixes bad color output. When I was first testing the device I had the DPI hardware set to 666 mode, but apparently in the refactor to use the bus_format information from the panel driver, I failed to actually update the panel. Signed-off-by: Eric Anholt Fixes: e8b6f561b2ee

[PATCH] drm/panel: simple: Fix the bus_format for the Ontat panel.

This fixes bad color output. When I was first testing the device I had the DPI hardware set to 666 mode, but apparently in the refactor to use the bus_format information from the panel driver, I failed to actually update the panel. Signed-off-by: Eric Anholt Fixes: e8b6f561b2ee ("drm/panel:

[PATCH] drm/vc4: Fix oops dereferencing DPI's connector since panel_bridge.

In the cleanup, I didn't notice that we needed to dereference the connector for the bus_format. Fix the regression by looking up the first (and only) connector attached to us, and assume that its bus_format is what we want. Some day it would be good to have that part of display_info attached to

[PATCH] drm/vc4: Fix oops dereferencing DPI's connector since panel_bridge.

In the cleanup, I didn't notice that we needed to dereference the connector for the bus_format. Fix the regression by looking up the first (and only) connector attached to us, and assume that its bus_format is what we want. Some day it would be good to have that part of display_info attached to

Re: [PATCH] Input: stmpe-keypad - remove VLA usage

On Fri, Mar 09, 2018 at 04:42:08PM -0600, 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 > > Signed-off-by:

Re: [PATCH] Input: stmpe-keypad - remove VLA usage

On Fri, Mar 09, 2018 at 04:42:08PM -0600, 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 > > Signed-off-by:

Re: WARNING in __proc_create

On Fri, Mar 9, 2018 at 3:21 PM, Eric Dumazet wrote: > > > On 03/09/2018 03:05 PM, Cong Wang wrote: >> >> >> BTW, the warning itself is all about empty names, so perhaps >> it's better to fix them separately. > > > Huh ? You want more syzbot reports ? I do not. I always

Re: WARNING in __proc_create

On Fri, Mar 9, 2018 at 3:21 PM, Eric Dumazet wrote: > > > On 03/09/2018 03:05 PM, Cong Wang wrote: >> >> >> BTW, the warning itself is all about empty names, so perhaps >> it's better to fix them separately. > > > Huh ? You want more syzbot reports ? I do not. I always prefer one patch to fix

[PATCH v4 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

[PATCH v4 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

[PATCH v4 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 v4: - fix compilation issues, use __assign_str - use %#x instead of 0x%08x Changes in v3: - Use __string()

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

Changes in v4: - Rename variables as suggested by Stephen and Evan - Lot of minor syntax and style fixes - Fix FTRACE compilation error - Improve doc comments and DT description Changes in v3: - Address Steven's comments in FTRACE - Fix DT documentation as suggested by Rob H - Fix error handling

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

Changes in v4: - Rename variables as suggested by Stephen and Evan - Lot of minor syntax and style fixes - Fix FTRACE compilation error - Improve doc comments and DT description Changes in v3: - Address Steven's comments in FTRACE - Fix DT documentation as suggested by Rob H - Fix error handling

[PATCH v4 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 v4: - fix compilation issues, use __assign_str - use %#x instead of 0x%08x Changes in v3: - Use __string() instead of char * - fix

Re: [PATCH v5 1/3] Input: gpio-keys - add support for wakeup event action

On Thu, Mar 08, 2018 at 03:32:11PM +0800, Jeffy Chen wrote: > Add support for specifying event actions to trigger wakeup when using > the gpio-keys input device as a wakeup source. > > This would allow the device to configure when to wakeup the system. For > example a gpio-keys input device for

Re: [PATCH v5 1/3] Input: gpio-keys - add support for wakeup event action

On Thu, Mar 08, 2018 at 03:32:11PM +0800, Jeffy Chen wrote: > Add support for specifying event actions to trigger wakeup when using > the gpio-keys input device as a wakeup source. > > This would allow the device to configure when to wakeup the system. For > example a gpio-keys input device for

[PATCH v4 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 --- Changes in v3: - Move to soc/qcom

[PATCH v4 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 --- Changes in v3: - Move to soc/qcom - Amend text per

[PATCH v4 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 v4: - refactored the rphm_rsc_invalidate() --- drivers/soc/qcom/rpmh-internal.h | 1 + drivers/soc/qcom/rpmh-rsc.c

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

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 rpmh_flush() is called. Generally, flushing is a system

[PATCH v4 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 v4: - refactored the rphm_rsc_invalidate() --- drivers/soc/qcom/rpmh-internal.h | 1 + drivers/soc/qcom/rpmh-rsc.c | 48

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

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 rpmh_flush() is called. Generally, flushing is a system

[PATCH v4 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 v4 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 v4 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 v4 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 v4 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 v4 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 v4 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 v4 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 v4 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 v4 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

Re: WARNING in __proc_create

On 03/09/2018 03:05 PM, Cong Wang wrote: BTW, the warning itself is all about empty names, so perhaps it's better to fix them separately. Huh ? You want more syzbot reports ? I do not. I unblocked this report today [1], you can be sure that as soon as syzbot gets the correct tag

Re: WARNING in __proc_create

On 03/09/2018 03:05 PM, Cong Wang wrote: BTW, the warning itself is all about empty names, so perhaps it's better to fix them separately. Huh ? You want more syzbot reports ? I do not. I unblocked this report today [1], you can be sure that as soon as syzbot gets the correct tag

Re: WARNING in __proc_create

Cong Wang wrote: > On Fri, Mar 9, 2018 at 2:58 PM, Eric Dumazet wrote: > > > > > > On 03/09/2018 02:56 PM, Eric Dumazet wrote: > > > >> > >> I sent a patch a while back, but Pablo/Florian wanted more than that > >> simple fix. > >> > >> We also

Re: WARNING in __proc_create

Cong Wang wrote: > On Fri, Mar 9, 2018 at 2:58 PM, Eric Dumazet wrote: > > > > > > On 03/09/2018 02:56 PM, Eric Dumazet wrote: > > > >> > >> I sent a patch a while back, but Pablo/Florian wanted more than that > >> simple fix. > >> > >> We also need to filter special characters like '/' > >

[PATCH v2, simpler] ia64: fix ptrace(PTRACE_GETREGS) (unbreaks strace, gdb)

The strace breakage looks like that: ./strace: get_regs: get_regs_error: Input/output error It happens because ia64 needs to load unwind tables to read certain registers in 'PTRACE_GETREGS'. Unwind tables fail to load at kernel startup due to GCC quirk on the following code (logged as PR 84184):

[PATCH v2, simpler] ia64: fix ptrace(PTRACE_GETREGS) (unbreaks strace, gdb)

The strace breakage looks like that: ./strace: get_regs: get_regs_error: Input/output error It happens because ia64 needs to load unwind tables to read certain registers in 'PTRACE_GETREGS'. Unwind tables fail to load at kernel startup due to GCC quirk on the following code (logged as PR 84184):

Re: [PATCH v2 1/4] dt-bindings: mfd: Add Gateworks System Controller bindings

On Mon, Mar 05, 2018 at 02:02:38PM -0800, Tim Harvey wrote: > This patch adds documentation of device-tree bindings for the > Gateworks System Controller (GSC). > > Signed-off-by: Tim Harvey > --- > Documentation/devicetree/bindings/mfd/gsc.txt | 159 >

Re: [PATCH v2 1/4] dt-bindings: mfd: Add Gateworks System Controller bindings

On Mon, Mar 05, 2018 at 02:02:38PM -0800, Tim Harvey wrote: > This patch adds documentation of device-tree bindings for the > Gateworks System Controller (GSC). > > Signed-off-by: Tim Harvey > --- > Documentation/devicetree/bindings/mfd/gsc.txt | 159 > ++ > 1 file

[PATCH] firmware: add a function to load optional firmware v2

Currently the firmware loader only exposes one silent path for querying optional firmware, and that is request_firmware_direct(). This function also disables the usermodehelper fallback which might not always be the desired behaviour. This patch introduces request_firmware_optional(), which will

[PATCH] firmware: add a function to load optional firmware v2

Currently the firmware loader only exposes one silent path for querying optional firmware, and that is request_firmware_direct(). This function also disables the usermodehelper fallback which might not always be the desired behaviour. This patch introduces request_firmware_optional(), which will

Re: Nokia N900: refcount_t underflow, use after free

On 03/09/2018 04:18 PM, Pavel Machek wrote: > On Fri 2018-03-09 16:13:36, Suman Anna wrote: >> On 03/09/2018 06:08 AM, Robin Murphy wrote: >>> On 08/03/18 18:50, Pavel Machek wrote: Hi! >> * Pavel Machek [180308 14:31]: >>> Hi! >>> >>> I'm getting this

Re: Nokia N900: refcount_t underflow, use after free

On 03/09/2018 04:18 PM, Pavel Machek wrote: > On Fri 2018-03-09 16:13:36, Suman Anna wrote: >> On 03/09/2018 06:08 AM, Robin Murphy wrote: >>> On 08/03/18 18:50, Pavel Machek wrote: Hi! >> * Pavel Machek [180308 14:31]: >>> Hi! >>> >>> I'm getting this warning... Has

Re: [PATCH v4] cpuset: Enable cpuset controller in default hierarchy

On 03/09/2018 05:17 PM, Peter Zijlstra wrote: > On Fri, Mar 09, 2018 at 03:43:34PM -0500, Waiman Long wrote: >> The isolcpus= parameter just reduce the cpus available to the rests of >> the system. The cpuset controller does look at that value and make >> adjustment accordingly, but it has no

Re: [PATCH v4] cpuset: Enable cpuset controller in default hierarchy

On 03/09/2018 05:17 PM, Peter Zijlstra wrote: > On Fri, Mar 09, 2018 at 03:43:34PM -0500, Waiman Long wrote: >> The isolcpus= parameter just reduce the cpus available to the rests of >> the system. The cpuset controller does look at that value and make >> adjustment accordingly, but it has no

Re: WARNING in __proc_create

On Fri, Mar 9, 2018 at 2:58 PM, Eric Dumazet wrote: > > > On 03/09/2018 02:56 PM, Eric Dumazet wrote: > >> >> I sent a patch a while back, but Pablo/Florian wanted more than that >> simple fix. >> >> We also need to filter special characters like '/' proc_create_data()

Re: WARNING in __proc_create

On Fri, Mar 9, 2018 at 2:58 PM, Eric Dumazet wrote: > > > On 03/09/2018 02:56 PM, Eric Dumazet wrote: > >> >> I sent a patch a while back, but Pablo/Florian wanted more than that >> simple fix. >> >> We also need to filter special characters like '/' proc_create_data() itself accepts '/', so it

Re: [PATCH v5 1/3] of: cache phandle nodes to reduce cost of of_find_node_by_phandle()

On Sun, Mar 04, 2018 at 04:14:47PM -0800, frowand.l...@gmail.com wrote: > From: Frank Rowand > > Create a cache of the nodes that contain a phandle property. Use this > cache to find the node for a given phandle value instead of scanning > the devicetree to find the node.

Re: [PATCH v5 1/3] of: cache phandle nodes to reduce cost of of_find_node_by_phandle()

On Sun, Mar 04, 2018 at 04:14:47PM -0800, frowand.l...@gmail.com wrote: > From: Frank Rowand > > Create a cache of the nodes that contain a phandle property. Use this > cache to find the node for a given phandle value instead of scanning > the devicetree to find the node. If the phandle value

Re: WARNING in __proc_create

Eric Dumazet wrote: > >>fs/proc/generic.c:354 > > > >We need to reject empty names. > > > > I sent a patch a while back, but Pablo/Florian wanted more than that simple > fix. > > We also need to filter special characters like '/' > > Or maybe I am mixing with something

Re: WARNING in __proc_create

Eric Dumazet wrote: > >>fs/proc/generic.c:354 > > > >We need to reject empty names. > > > > I sent a patch a while back, but Pablo/Florian wanted more than that simple > fix. > > We also need to filter special characters like '/' > > Or maybe I am mixing with something else. Argh, sorry, this

Re: [PATCH v6 2/6] regulator: bindings: Add properties for coupled regulators

On Fri, Mar 09, 2018 at 01:22:04PM +0100, Maciej Purski wrote: > Some regulators require keeping their voltage spread below defined > max_spread. > > Add properties to provide information on regulators' coupling. > > Signed-off-by: Maciej Purski > --- >

Re: [PATCH v6 2/6] regulator: bindings: Add properties for coupled regulators

On Fri, Mar 09, 2018 at 01:22:04PM +0100, Maciej Purski wrote: > Some regulators require keeping their voltage spread below defined > max_spread. > > Add properties to provide information on regulators' coupling. > > Signed-off-by: Maciej Purski > --- >

Re: Make set_handle_irq and handle_arch_irq generic, v3

On Fri, 9 Mar 2018, Palmer Dabbelt wrote: > On Fri, 09 Mar 2018 02:20:12 PST (-0800), t...@linutronix.de wrote: > > This looks sensible. We have two options for getting this merged: > > > > 1) I'll take the whole lot through tip/irq/core > > > > 2) I'll apply patch 1/N to a special branch in

Re: Nokia N900: v4.16-rc4: oops in iio when grepping sysfs

Hi! > > Hmm. Looks like there's a lot of fun to be had with sysfs. > > > > > > pavel@n900:~$ uname -a > > Linux n900 4.16.0-rc4-59690-g7f84626-dirty #543 Thu Mar 8 19:53:30 CET > > 2018 armv7l GNU/Linux > > > > [ 306.402496] bq2415x: command Timer reset > > [ 312.761322] adp1653 2-0030: Read

Re: Make set_handle_irq and handle_arch_irq generic, v3

On Fri, 9 Mar 2018, Palmer Dabbelt wrote: > On Fri, 09 Mar 2018 02:20:12 PST (-0800), t...@linutronix.de wrote: > > This looks sensible. We have two options for getting this merged: > > > > 1) I'll take the whole lot through tip/irq/core > > > > 2) I'll apply patch 1/N to a special branch in

Re: Nokia N900: v4.16-rc4: oops in iio when grepping sysfs

Hi! > > Hmm. Looks like there's a lot of fun to be had with sysfs. > > > > > > pavel@n900:~$ uname -a > > Linux n900 4.16.0-rc4-59690-g7f84626-dirty #543 Thu Mar 8 19:53:30 CET > > 2018 armv7l GNU/Linux > > > > [ 306.402496] bq2415x: command Timer reset > > [ 312.761322] adp1653 2-0030: Read

Re: WARNING in __proc_create

On 03/09/2018 02:56 PM, Eric Dumazet wrote: I sent a patch a while back, but Pablo/Florian wanted more than that simple fix. We also need to filter special characters like '/' Or maybe I am mixing with something else. Yes, Florian mentioned that we also had to reject "." and ".."

Re: WARNING in __proc_create

On 03/09/2018 02:56 PM, Eric Dumazet wrote: I sent a patch a while back, but Pablo/Florian wanted more than that simple fix. We also need to filter special characters like '/' Or maybe I am mixing with something else. Yes, Florian mentioned that we also had to reject "." and ".."

Re: [PATCH v2 2/2] riscv/atomic: Strengthen implementations with fences

On Fri, 09 Mar 2018 13:30:08 PST (-0800), parri.and...@gmail.com wrote: On Fri, Mar 09, 2018 at 10:54:27AM -0800, Palmer Dabbelt wrote: On Fri, 09 Mar 2018 10:36:44 PST (-0800), parri.and...@gmail.com wrote: [...] >This belongs to the "few style fixes" (in the specific, 80-chars lines)

Re: [PATCH v2 2/2] riscv/atomic: Strengthen implementations with fences

On Fri, 09 Mar 2018 13:30:08 PST (-0800), parri.and...@gmail.com wrote: On Fri, Mar 09, 2018 at 10:54:27AM -0800, Palmer Dabbelt wrote: On Fri, 09 Mar 2018 10:36:44 PST (-0800), parri.and...@gmail.com wrote: [...] >This belongs to the "few style fixes" (in the specific, 80-chars lines)

Re: [PATCH][RFC] rslib: Remove VLAs by setting upper bound on nroots

On Fri, 9 Mar 2018, Kees Cook wrote: > On Fri, Mar 9, 2018 at 7:49 AM, Thomas Gleixner wrote: > > On Fri, 9 Mar 2018, Kees Cook wrote: > > Maybe I should just go with 24 as the max, and if we have a case where > we need more, address it then? Works for me. Thanks,

Re: [PATCH][RFC] rslib: Remove VLAs by setting upper bound on nroots

On Fri, 9 Mar 2018, Kees Cook wrote: > On Fri, Mar 9, 2018 at 7:49 AM, Thomas Gleixner wrote: > > On Fri, 9 Mar 2018, Kees Cook wrote: > > Maybe I should just go with 24 as the max, and if we have a case where > we need more, address it then? Works for me. Thanks, tglx

Re: WARNING in __proc_create

On 03/09/2018 02:48 PM, Cong Wang wrote: On Fri, Mar 9, 2018 at 1:59 PM, syzbot wrote: Hello, syzbot hit the following crash on net-next commit 617aebe6a97efa539cc4b8a52adccd89596e6be0 (Sun Feb 4 00:25:42 2018 +) Merge tag

Re: WARNING in __proc_create

On 03/09/2018 02:48 PM, Cong Wang wrote: On Fri, Mar 9, 2018 at 1:59 PM, syzbot wrote: Hello, syzbot hit the following crash on net-next commit 617aebe6a97efa539cc4b8a52adccd89596e6be0 (Sun Feb 4 00:25:42 2018 +) Merge tag 'usercopy-v4.16-rc1' of

Re: [PATCH] proc: register filesystem last

On Sat, 10 Mar 2018 01:27:09 +0300 Alexey Dobriyan wrote: > As soon as register_filesystem() exits, filesystem can be mounted. > It is better to present fully operational /proc. > > Of course it doesn't matter because /proc is not modular > but do it anyway. > > Drop error

Re: [PATCH] proc: register filesystem last

On Sat, 10 Mar 2018 01:27:09 +0300 Alexey Dobriyan wrote: > As soon as register_filesystem() exits, filesystem can be mounted. > It is better to present fully operational /proc. > > Of course it doesn't matter because /proc is not modular > but do it anyway. > > Drop error check, it should be

Re: [PATCH v11 8/8] perf: ARM DynamIQ Shared Unit PMU support

On 03/09/2018 05:35 AM, Mark Rutland wrote: On Fri, Mar 09, 2018 at 10:53:14AM +, Suzuki K Poulose wrote: + Cc: Lorenzo, Charles. On 08/03/18 23:59, Saravana Kannan wrote: On 01/02/2018 03:25 AM, Suzuki K Poulose wrote: Add support for the Cluster PMU part of the ARM DynamIQ Shared Unit

Re: [PATCH v11 8/8] perf: ARM DynamIQ Shared Unit PMU support

On 03/09/2018 05:35 AM, Mark Rutland wrote: On Fri, Mar 09, 2018 at 10:53:14AM +, Suzuki K Poulose wrote: + Cc: Lorenzo, Charles. On 08/03/18 23:59, Saravana Kannan wrote: On 01/02/2018 03:25 AM, Suzuki K Poulose wrote: Add support for the Cluster PMU part of the ARM DynamIQ Shared Unit

Re: WARNING in __proc_create

On Fri, Mar 9, 2018 at 1:59 PM, syzbot wrote: > Hello, > > syzbot hit the following crash on net-next commit > 617aebe6a97efa539cc4b8a52adccd89596e6be0 (Sun Feb 4 00:25:42 2018 +) > Merge tag 'usercopy-v4.16-rc1' of >

Re: WARNING in __proc_create

On Fri, Mar 9, 2018 at 1:59 PM, syzbot wrote: > Hello, > > syzbot hit the following crash on net-next commit > 617aebe6a97efa539cc4b8a52adccd89596e6be0 (Sun Feb 4 00:25:42 2018 +) > Merge tag 'usercopy-v4.16-rc1' of > git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux > > So far this

[PATCH v2] mm: make start_isolate_page_range() fail if already isolated

start_isolate_page_range() is used to set the migrate type of a set of pageblocks to MIGRATE_ISOLATE while attempting to start a migration operation. It assumes that only one thread is calling it for the specified range. This routine is used by CMA, memory hotplug and gigantic huge pages. Each

Re: [PATCH] device_handler: remove VLAs

On Fri, 2018-03-09 at 23:32 +0100, Stephen Kitt wrote: > In preparation to enabling -Wvla, remove VLAs and replace them with > fixed-length arrays instead. > > scsi_dh_{alua,emc,rdac} use variable-length array declarations to > store command blocks, with the appropriate size as determined by >

[PATCH v2] mm: make start_isolate_page_range() fail if already isolated

start_isolate_page_range() is used to set the migrate type of a set of pageblocks to MIGRATE_ISOLATE while attempting to start a migration operation. It assumes that only one thread is calling it for the specified range. This routine is used by CMA, memory hotplug and gigantic huge pages. Each

Re: [PATCH] device_handler: remove VLAs

On Fri, 2018-03-09 at 23:32 +0100, Stephen Kitt wrote: > In preparation to enabling -Wvla, remove VLAs and replace them with > fixed-length arrays instead. > > scsi_dh_{alua,emc,rdac} use variable-length array declarations to > store command blocks, with the appropriate size as determined by >

Re: [PATCH] scsi: resolve COMMAND_SIZE at compile time

On Fri, 2018-03-09 at 23:33 +0100, Stephen Kitt wrote: > +/* > + * SCSI command sizes are as follows, in bytes, for fixed size commands, per > + * group: 6, 10, 10, 12, 16, 12, 10, 10. The top three bits of an opcode > + * determine its group. > + * The size table is encoded into a 32-bit value by

Re: [PATCH] scsi: resolve COMMAND_SIZE at compile time

On Fri, 2018-03-09 at 23:33 +0100, Stephen Kitt wrote: > +/* > + * SCSI command sizes are as follows, in bytes, for fixed size commands, per > + * group: 6, 10, 10, 12, 16, 12, 10, 10. The top three bits of an opcode > + * determine its group. > + * The size table is encoded into a 32-bit value by

[PATCH] Input: stmpe-keypad - remove VLA usage

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 Signed-off-by: Gustavo A. R. Silva ---

[PATCH] Input: stmpe-keypad - remove VLA usage

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 Signed-off-by: Gustavo A. R. Silva --- drivers/input/keyboard/stmpe-keypad.c | 10 ++ 1

Re: [PATCH] x86, powerpc : pkey-mprotect must allow pkey-0

On 03/09/2018 12:12 AM, Ram Pai wrote: > Once an address range is associated with an allocated pkey, it cannot be > reverted back to key-0. There is no valid reason for the above behavior. On > the contrary applications need the ability to do so. Why don't we just set pkey 0 to be allocated in

Re: [PATCH] x86, powerpc : pkey-mprotect must allow pkey-0

On 03/09/2018 12:12 AM, Ram Pai wrote: > Once an address range is associated with an allocated pkey, it cannot be > reverted back to key-0. There is no valid reason for the above behavior. On > the contrary applications need the ability to do so. Why don't we just set pkey 0 to be allocated in

[PATCH v5 04/36] drm/rockchip: add mutex vop lock

From: zain wang Add a lock to vop to avoid disabling the crtc while waiting for a line flag while enabling psr. If we disable in the middle of waiting for the line flag, we'll end up timing out or worse. Signed-off-by: zain wang Signed-off-by: Sean

[PATCH v5 04/36] drm/rockchip: add mutex vop lock

From: zain wang Add a lock to vop to avoid disabling the crtc while waiting for a line flag while enabling psr. If we disable in the middle of waiting for the line flag, we'll end up timing out or worse. Signed-off-by: zain wang Signed-off-by: Sean Paul Signed-off-by: Thierry Escande

[PATCH v5 00/36] DRM Rockchip rk3399 (Kevin)

Hi, This patchset includes cleanups, improvements, and bug fixes for Rockchip DRM driver and PSR support. This new version is the same as before removing some of the patches already applied and fixing the Exynos issue due patch '[v4 15/38] drm/bridge: analogix_dp: Ensure edp is disabled when

[PATCH v5 00/36] DRM Rockchip rk3399 (Kevin)

Hi, This patchset includes cleanups, improvements, and bug fixes for Rockchip DRM driver and PSR support. This new version is the same as before removing some of the patches already applied and fixing the Exynos issue due patch '[v4 15/38] drm/bridge: analogix_dp: Ensure edp is disabled when

[PATCH v5 02/36] drm/rockchip: Remove analogix psr worker

From: Sean Paul Now that the spinlocks and timers are gone, we can remove the psr worker located in rockchip's analogix driver and do the enable/disable directly. This should simplify the code and remove races on disable. Cc: 征增 王 Cc: Stéphane

[PATCH v5 02/36] drm/rockchip: Remove analogix psr worker

From: Sean Paul Now that the spinlocks and timers are gone, we can remove the psr worker located in rockchip's analogix driver and do the enable/disable directly. This should simplify the code and remove races on disable. Cc: 征增 王 Cc: Stéphane Marchesin Signed-off-by: Sean Paul

[PATCH v5 03/36] drm/bridge: analogix_dp: Don't change psr while bridge is disabled

From: zain wang There is a race between AUX CH bring-up and enabling bridge which will cause link training to fail. To avoid hitting it, don't change psr state while enabling the bridge. Cc: Tomeu Vizoso Cc: Sean Paul

[PATCH v5 03/36] drm/bridge: analogix_dp: Don't change psr while bridge is disabled

From: zain wang There is a race between AUX CH bring-up and enabling bridge which will cause link training to fail. To avoid hitting it, don't change psr state while enabling the bridge. Cc: Tomeu Vizoso Cc: Sean Paul Signed-off-by: zain wang Signed-off-by: Caesar Wang [seanpaul fixed up

[PATCH] scsi: resolve COMMAND_SIZE at compile time

COMMAND_SIZE currently uses an array of values in block/scsi_ioctl.c. A number of device_handler functions use this to initialise arrays, and this is flagged by -Wvla. This patch replaces COMMAND_SIZE with a variant using a formula which can be resolved at compile time in cases where the opcode

[PATCH] scsi: resolve COMMAND_SIZE at compile time

COMMAND_SIZE currently uses an array of values in block/scsi_ioctl.c. A number of device_handler functions use this to initialise arrays, and this is flagged by -Wvla. This patch replaces COMMAND_SIZE with a variant using a formula which can be resolved at compile time in cases where the opcode

[PATCH v5 05/36] drm/bridge: analogix_dp: add fast link train for eDP

From: zain wang We would meet a short black screen when exit PSR with the full link training, In this case, we should use fast link train instead of full link training. Signed-off-by: zain wang Signed-off-by: Sean Paul

[PATCH v5 06/36] drm/rockchip: Only wait for panel ACK on PSR entry

From: zain wang We currently wait for the panel to mirror our intended PSR state before continuing on both PSR enter and PSR exit. This is really only important to do when we're entering PSR, since we want to be sure the last frame we pushed is being served from the panel's

[PATCH v5 05/36] drm/bridge: analogix_dp: add fast link train for eDP

From: zain wang We would meet a short black screen when exit PSR with the full link training, In this case, we should use fast link train instead of full link training. Signed-off-by: zain wang Signed-off-by: Sean Paul Signed-off-by: Thierry Escande Signed-off-by: Enric Balletbo i Serra

[PATCH v5 06/36] drm/rockchip: Only wait for panel ACK on PSR entry

From: zain wang We currently wait for the panel to mirror our intended PSR state before continuing on both PSR enter and PSR exit. This is really only important to do when we're entering PSR, since we want to be sure the last frame we pushed is being served from the panel's internal fb before

[PATCH v5 07/36] drm/bridge: analogix_dp: Move enable video into config_video()

From: Lin Huang We need to enable video before analogix_dp_is_video_stream_on(), so we can get the right video stream status. Cc: 征增 王 Cc: Stéphane Marchesin Signed-off-by: Lin Huang Signed-off-by: Sean Paul

[PATCH v5 07/36] drm/bridge: analogix_dp: Move enable video into config_video()

From: Lin Huang We need to enable video before analogix_dp_is_video_stream_on(), so we can get the right video stream status. Cc: 征增 王 Cc: Stéphane Marchesin Signed-off-by: Lin Huang Signed-off-by: Sean Paul Signed-off-by: Thierry Escande Reviewed-by: Andrzej Hajda Signed-off-by: Enric

[PATCH v5 09/36] drm/bridge: analogix_dp: Don't use fast link training when panel just powered up

From: zain wang Panel would reset its setting when it powers down. It would forget the last succeeded link training setting. So we can't use the last successful link training setting to do fast link training. Let's reset fast_train_enable in analogix_dp_bridge_disable();

[PATCH v5 09/36] drm/bridge: analogix_dp: Don't use fast link training when panel just powered up

From: zain wang Panel would reset its setting when it powers down. It would forget the last succeeded link training setting. So we can't use the last successful link training setting to do fast link training. Let's reset fast_train_enable in analogix_dp_bridge_disable(); Cc: Stéphane Marchesin

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