[PATCH 0/2] Add DTS for SDM845 SoC and MTP

Now that we have serial[1], pinctrl[2] and clock[3] drivers for SDM845 SoC out on the lists, heres the basic dts files needed to boot a SDM845 based MTP board to a ramfs based serial console shell. [1] https://patchwork.ozlabs.org/cover/860251/ [2] https://patchwork.kernel.org/patch/10157143/ [3]

Re: [PATCHv2] musb_host: fix lockup on rxcsr_h_error

Maxim, On Thu, Jan 25, 2018 at 07:24:02PM +0300, Maxim Uvarov wrote: > [1] says that issue is with back ported driver to 3.12.10. Can the > latest kernel be tested on the same hw? Agreed that it should be tested with the latest kernel. But my concern now is if stopping scheduling urbs on errors

[PATCH 1/2] arm64: dts: sdm845: Add minimal dts/dtsi files for sdm845 SoC and MTP

Add a skeletal sdm845 SoC dtsi and MTP board dts/dtsi files Signed-off-by: Rajendra Nayak --- arch/arm64/boot/dts/qcom/Makefile| 1 + arch/arm64/boot/dts/qcom/sdm845-mtp.dts | 13 ++ arch/arm64/boot/dts/qcom/sdm845-mtp.dtsi | 11 ++

[PATCH 1/2] arm64: dts: sdm845: Add minimal dts/dtsi files for sdm845 SoC and MTP

Add a skeletal sdm845 SoC dtsi and MTP board dts/dtsi files Signed-off-by: Rajendra Nayak --- arch/arm64/boot/dts/qcom/Makefile| 1 + arch/arm64/boot/dts/qcom/sdm845-mtp.dts | 13 ++ arch/arm64/boot/dts/qcom/sdm845-mtp.dtsi | 11 ++ arch/arm64/boot/dts/qcom/sdm845.dtsi | 308

Re: [PATCH v3] ACPI: Force I2C to be selected as a built-in module

On Thu, Jan 25, 2018 at 4:43 PM, Sinan Kaya wrote: > From: Auger Eric > > If I2C is built as a module, ACPI_I2C_OPREGION cannot be set > and any ACPI opregion calls targeting I2C fail with no opregion found. > > Commit da3c6647ee08 ("I2C/ACPI: Clean

Re: [PATCH v3] ACPI: Force I2C to be selected as a built-in module

On Thu, Jan 25, 2018 at 4:43 PM, Sinan Kaya wrote: > From: Auger Eric > > If I2C is built as a module, ACPI_I2C_OPREGION cannot be set > and any ACPI opregion calls targeting I2C fail with no opregion found. > > Commit da3c6647ee08 ("I2C/ACPI: Clean up I2C ACPI code and Add > CONFIG_I2C_ACPI

[PATCH] Update the RISC-V MAINTAINERS file

Now that we're upstream in Linux we've been able to make some infrastructure changes so our port works a bit more like other ports. Specifically: * We now have a mailing list specific to the RISC-V Linux port, hosted at lists.infreadead.org. * We now have a kernel.org git tree where work on our

[PATCH] Update the RISC-V MAINTAINERS file

Now that we're upstream in Linux we've been able to make some infrastructure changes so our port works a bit more like other ports. Specifically: * We now have a mailing list specific to the RISC-V Linux port, hosted at lists.infreadead.org. * We now have a kernel.org git tree where work on our

Re: [PATCH v4 6/7] x86/cpufeature: Blacklist SPEC_CTRL on early Spectre v2 microcodes

On Thu, 25 Jan 2018, Alan Cox wrote: > > Here's what I have now. I'm happy enough with this, so the main thing > > I'm looking for is an ack from Alan for patch #5 of the series, if I've > > got that sufficiently correct now. > > You have my ACK for patch 5: Any further changes I'll submit as

Re: [PATCH v4 6/7] x86/cpufeature: Blacklist SPEC_CTRL on early Spectre v2 microcodes

On Thu, 25 Jan 2018, Alan Cox wrote: > > Here's what I have now. I'm happy enough with this, so the main thing > > I'm looking for is an ack from Alan for patch #5 of the series, if I've > > got that sufficiently correct now. > > You have my ACK for patch 5: Any further changes I'll submit as

Re: [PATCH v2 3/5] Input: add KEY_ROTATE_LOCK_TOGGLE

Any movement on this? Are we just waiting on an ACK/NAK from Dmitry? Jason --- Now instead of four in the eights place / you’ve got three, ‘Cause you added one / (That is to say, eight) to the two, / But you can’t take seven from three,/ So you look at the sixty-fours On Tue, Dec

Re: [PATCHv2] musb_host: fix lockup on rxcsr_h_error

[1] says that issue is with back ported driver to 3.12.10. Can the latest kernel be tested on the same hw? Maxim. 2018-01-25 18:45 GMT+03:00 Bin Liu : > Hi Yegor and Max, > > On Tue, May 03, 2016 at 04:25:58PM +0200, Yegor Yefremov wrote: >> On Tue, May 3, 2016 at 3:48 PM, Bin Liu

Re: [PATCH v2 3/5] Input: add KEY_ROTATE_LOCK_TOGGLE

Any movement on this? Are we just waiting on an ACK/NAK from Dmitry? Jason --- Now instead of four in the eights place / you’ve got three, ‘Cause you added one / (That is to say, eight) to the two, / But you can’t take seven from three,/ So you look at the sixty-fours On Tue, Dec

Re: [PATCHv2] musb_host: fix lockup on rxcsr_h_error

[1] says that issue is with back ported driver to 3.12.10. Can the latest kernel be tested on the same hw? Maxim. 2018-01-25 18:45 GMT+03:00 Bin Liu : > Hi Yegor and Max, > > On Tue, May 03, 2016 at 04:25:58PM +0200, Yegor Yefremov wrote: >> On Tue, May 3, 2016 at 3:48 PM, Bin Liu wrote: >> >

Re: [RFC 09/10] x86/enter: Create macros to restrict/unrestrict Indirect Branch Speculation

On 23/01/2018 10:30, David Woodhouse wrote: > Skylake takes predictions from the generic branch target buffer when > the RSB underflows. Adding LAKML. AFAIU, some ARM Cortex cores have the same optimization. (A9 maybe, A17 probably, some recent 64-bit cores) Are there software work-arounds for

Re: [RFC 09/10] x86/enter: Create macros to restrict/unrestrict Indirect Branch Speculation

On 23/01/2018 10:30, David Woodhouse wrote: > Skylake takes predictions from the generic branch target buffer when > the RSB underflows. Adding LAKML. AFAIU, some ARM Cortex cores have the same optimization. (A9 maybe, A17 probably, some recent 64-bit cores) Are there software work-arounds for

Re: [PATCH v6 00/41] ARM: davinci: convert to common clock framework​

On 01/25/2018 06:53 AM, Sekhar Nori wrote: On Wednesday 24 January 2018 01:33 PM, Bartosz Golaszewski wrote: 2018-01-23 21:23 GMT+01:00 David Lechner : On 01/23/2018 02:05 PM, David Lechner wrote: On 01/23/2018 02:01 PM, David Lechner wrote: On 01/23/2018 01:53 PM,

Re: [PATCH v6 00/41] ARM: davinci: convert to common clock framework​

On 01/25/2018 06:53 AM, Sekhar Nori wrote: On Wednesday 24 January 2018 01:33 PM, Bartosz Golaszewski wrote: 2018-01-23 21:23 GMT+01:00 David Lechner : On 01/23/2018 02:05 PM, David Lechner wrote: On 01/23/2018 02:01 PM, David Lechner wrote: On 01/23/2018 01:53 PM, Bartosz Golaszewski

Re: [PATCH v4 6/7] x86/cpufeature: Blacklist SPEC_CTRL on early Spectre v2 microcodes

> Here's what I have now. I'm happy enough with this, so the main thing > I'm looking for is an ack from Alan for patch #5 of the series, if I've > got that sufficiently correct now. You have my ACK for patch 5: Any further changes I'll submit as updates once it's merged. I am happy with patch 5

Re: [PATCH v4 6/7] x86/cpufeature: Blacklist SPEC_CTRL on early Spectre v2 microcodes

> Here's what I have now. I'm happy enough with this, so the main thing > I'm looking for is an ack from Alan for patch #5 of the series, if I've > got that sufficiently correct now. You have my ACK for patch 5: Any further changes I'll submit as updates once it's merged. I am happy with patch 5

[PATCH v5 0/7] Basic Speculation Control feature support

Add the basic CPUID and MSR definitions for AMD and Intel, followed by the complete no-brainer: Disable KPTI on Intel CPUs which set the RDCL_NO bit to say that they don't need it, as well as others which are known not to speculate such as old Atoms and even older 32-bit chips. Alan will

[PATCH v5 0/7] Basic Speculation Control feature support

Add the basic CPUID and MSR definitions for AMD and Intel, followed by the complete no-brainer: Disable KPTI on Intel CPUs which set the RDCL_NO bit to say that they don't need it, as well as others which are known not to speculate such as old Atoms and even older 32-bit chips. Alan will

[PATCH v5 2/7] x86/cpufeatures: Add Intel feature bits for Speculation Control

Add three feature bits exposed by new microcode on Intel CPUs for speculation control. Signed-off-by: David Woodhouse Reviewed-by: Greg Kroah-Hartman Reviewed-by: Borislav Petkov --- arch/x86/include/asm/cpufeatures.h | 3 +++ 1

[PATCH v5 2/7] x86/cpufeatures: Add Intel feature bits for Speculation Control

Add three feature bits exposed by new microcode on Intel CPUs for speculation control. Signed-off-by: David Woodhouse Reviewed-by: Greg Kroah-Hartman Reviewed-by: Borislav Petkov --- arch/x86/include/asm/cpufeatures.h | 3 +++ 1 file changed, 3 insertions(+) diff --git

[PATCH v5 4/7] x86/msr: Add definitions for new speculation control MSRs

Add MSR and bit definitions for SPEC_CTRL, PRED_CMD and ARCH_CAPABILITIES. See Intel's 336996-Speculative-Execution-Side-Channel-Mitigations.pdf Signed-off-by: David Woodhouse Reviewed-by: Greg Kroah-Hartman --- arch/x86/include/asm/msr-index.h |

[PATCH v5 4/7] x86/msr: Add definitions for new speculation control MSRs

Add MSR and bit definitions for SPEC_CTRL, PRED_CMD and ARCH_CAPABILITIES. See Intel's 336996-Speculative-Execution-Side-Channel-Mitigations.pdf Signed-off-by: David Woodhouse Reviewed-by: Greg Kroah-Hartman --- arch/x86/include/asm/msr-index.h | 12 1 file changed, 12

[PATCH v5 6/7] x86/cpufeature: Blacklist SPEC_CTRL/PRED_CMD on early Spectre v2 microcodes

This doesn't refuse to load the affected microcodes; it just refuses to use the Spectre v2 mitigation features if they're detected, by clearing the appropriate feature bits. The AMD CPUID bits are handled here too, because hypervisors *may* have been exposing those bits even on Intel chips, for

[PATCH v5 6/7] x86/cpufeature: Blacklist SPEC_CTRL/PRED_CMD on early Spectre v2 microcodes

This doesn't refuse to load the affected microcodes; it just refuses to use the Spectre v2 mitigation features if they're detected, by clearing the appropriate feature bits. The AMD CPUID bits are handled here too, because hypervisors *may* have been exposing those bits even on Intel chips, for

[PATCH v5 7/7] x86/speculation: Add basic IBPB (Indirect Branch Prediction Barrier) support

Expose indirect_branch_prediction_barrier() for use in subsequent patches. [karahmed: remove the special-casing of skylake for using IBPB (wtf?), switch to using ALTERNATIVES instead of static_cpu_has] [dwmw2:set up ax/cx/dx in the asm too so it gets NOP'd out] Signed-off-by:

Re: [PATCH v6 4/6] media: i2c: Add TDA1997x HDMI receiver driver

On Mon, Jan 15, 2018 at 4:56 AM, Hans Verkuil wrote: > On 12/28/2017 09:09 PM, Tim Harvey wrote: >> Add support for the TDA1997x HDMI receivers. >> > > This looks good. > > But there is one corner case that isn't handled in this driver: what if there > is no AVI InfoFrame

[PATCH v5 7/7] x86/speculation: Add basic IBPB (Indirect Branch Prediction Barrier) support

Expose indirect_branch_prediction_barrier() for use in subsequent patches. [karahmed: remove the special-casing of skylake for using IBPB (wtf?), switch to using ALTERNATIVES instead of static_cpu_has] [dwmw2:set up ax/cx/dx in the asm too so it gets NOP'd out] Signed-off-by:

Re: [PATCH v6 4/6] media: i2c: Add TDA1997x HDMI receiver driver

On Mon, Jan 15, 2018 at 4:56 AM, Hans Verkuil wrote: > On 12/28/2017 09:09 PM, Tim Harvey wrote: >> Add support for the TDA1997x HDMI receivers. >> > > This looks good. > > But there is one corner case that isn't handled in this driver: what if there > is no AVI InfoFrame (e.g. you receive a DVI

[PATCH v5 1/7] x86/cpufeatures: Add CPUID_7_EDX CPUID leaf

This is a pure feature bits leaf. We have two AVX512 feature bits in it already which were handled as scattered bits, and I'm about to add three more from this leaf for speculation control features. Signed-off-by: David Woodhouse Reviewed-by: Greg Kroah-Hartman

[PATCH v5 1/7] x86/cpufeatures: Add CPUID_7_EDX CPUID leaf

This is a pure feature bits leaf. We have two AVX512 feature bits in it already which were handled as scattered bits, and I'm about to add three more from this leaf for speculation control features. Signed-off-by: David Woodhouse Reviewed-by: Greg Kroah-Hartman Reviewed-by: Borislav Petkov ---

Re: [PATCH] fpga: fpga-region: comment on fpga_region_program_fpga locking

On Thu, 25 Jan 2018, Alan Tull wrote: Hi Alan, I seem to remember issue coming up a couple of times. I think this comment will be very helpful. Matthew Gerlach Add a comment to the header of fpga_region_program_fpga() regarding locking of the bridges. Signed-off-by: Alan Tull

Re: [PATCH] fpga: fpga-region: comment on fpga_region_program_fpga locking

On Thu, 25 Jan 2018, Alan Tull wrote: Hi Alan, I seem to remember issue coming up a couple of times. I think this comment will be very helpful. Matthew Gerlach Add a comment to the header of fpga_region_program_fpga() regarding locking of the bridges. Signed-off-by: Alan Tull ---

[PATCH v5 5/7] x86/pti: Do not enable PTI on processors which are not vulnerable to Meltdown

Also, for CPUs which don't speculate at all, don't report that they're vulnerable to the Spectre variants either. Leave the cpu_no_meltdown[] match table with just X86_VENDOR_AMD in it for now, even though that could be done with a simple comparison, on the assumption that we'll have more to add.

[PATCH v5 3/7] x86/cpufeatures: Add AMD feature bits for Speculation Control

AMD exposes the PRED_CMD/SPEC_CTRL MSRs slightly differently to Intel. See http://lkml.kernel.org/r/2b3e25cc-286d-8bd0-aeaf-9ac4aae39...@amd.com Signed-off-by: David Woodhouse Reviewed-by: Greg Kroah-Hartman --- arch/x86/include/asm/cpufeatures.h

[PATCH v5 5/7] x86/pti: Do not enable PTI on processors which are not vulnerable to Meltdown

Also, for CPUs which don't speculate at all, don't report that they're vulnerable to the Spectre variants either. Leave the cpu_no_meltdown[] match table with just X86_VENDOR_AMD in it for now, even though that could be done with a simple comparison, on the assumption that we'll have more to add.

[PATCH v5 3/7] x86/cpufeatures: Add AMD feature bits for Speculation Control

AMD exposes the PRED_CMD/SPEC_CTRL MSRs slightly differently to Intel. See http://lkml.kernel.org/r/2b3e25cc-286d-8bd0-aeaf-9ac4aae39...@amd.com Signed-off-by: David Woodhouse Reviewed-by: Greg Kroah-Hartman --- arch/x86/include/asm/cpufeatures.h | 3 +++ 1 file changed, 3 insertions(+) diff

Re: [PATCH 2/2] usb: dwc3: drd: Fix lock-up on ID change during system suspend/resume

Hi, On 24/01/18 14:19, Roger Quadros wrote: > On 23/01/18 14:41, Roger Quadros wrote: >> Hi Manu, >> >> On 23/01/18 05:45, Manu Gautam wrote: >>> Hi, >>> >>> >>> On 1/22/2018 6:31 PM, Roger Quadros wrote: Adding/removing host/gadget controller before .pm_complete() causes a lock-up.

Re: [PATCH 2/2] usb: dwc3: drd: Fix lock-up on ID change during system suspend/resume

Hi, On 24/01/18 14:19, Roger Quadros wrote: > On 23/01/18 14:41, Roger Quadros wrote: >> Hi Manu, >> >> On 23/01/18 05:45, Manu Gautam wrote: >>> Hi, >>> >>> >>> On 1/22/2018 6:31 PM, Roger Quadros wrote: Adding/removing host/gadget controller before .pm_complete() causes a lock-up.

Re: [PATCH] dt-bindings: display: stm32: add pixel clock mandatory property

Hi, in short: this patch is "CANCELLED" : ) There is no need to add the pixel clock as a mandatory property because now the clock value is ajusted in adjusted_mode. Please have a look to patches: - drm/stm: ltdc: use crtc_mode_fixup to update adjusted_mode clock - drm/bridge/synopsys: dsi: use

Re: [PATCH] dt-bindings: display: stm32: add pixel clock mandatory property

Hi, in short: this patch is "CANCELLED" : ) There is no need to add the pixel clock as a mandatory property because now the clock value is ajusted in adjusted_mode. Please have a look to patches: - drm/stm: ltdc: use crtc_mode_fixup to update adjusted_mode clock - drm/bridge/synopsys: dsi: use

Re: linux-next: build failure after merge of the rdma tree

On Thu, 2018-01-25 at 10:50 +0200, Leon Romanovsky wrote: > On Thu, Jan 25, 2018 at 06:22:59PM +1100, Stephen Rothwell wrote: > > Hi all, > > > > After merging the rdma tree, today's linux-next build (x86_64 > > allmodconfig) failed like this: > > > > ERROR: "init_rcu_head"

Re: linux-next: build failure after merge of the rdma tree

On Thu, 2018-01-25 at 10:50 +0200, Leon Romanovsky wrote: > On Thu, Jan 25, 2018 at 06:22:59PM +1100, Stephen Rothwell wrote: > > Hi all, > > > > After merging the rdma tree, today's linux-next build (x86_64 > > allmodconfig) failed like this: > > > > ERROR: "init_rcu_head"

Re: [PATCH v3] drm/bridge/synopsys: dsi: add optional pixel clock

Hi, in short: this patch is "CANCELLED" : ) Thanks to comments from some of you, I managed to use adjusted_mode. Please have a look to the patch "drm/bridge/synopsys: dsi: use adjusted_mode in mode_set". Hope it is better, comments are welcome Many thanks, Philippe :-) On 01/23/2018 06:08

Re: [PATCH v3] drm/bridge/synopsys: dsi: add optional pixel clock

Hi, in short: this patch is "CANCELLED" : ) Thanks to comments from some of you, I managed to use adjusted_mode. Please have a look to the patch "drm/bridge/synopsys: dsi: use adjusted_mode in mode_set". Hope it is better, comments are welcome Many thanks, Philippe :-) On 01/23/2018 06:08

Re: [patches] Re: [PATCH v2 4/4] RISC-V: Move to the new generic IRQ handler

On Thu, 25 Jan 2018 00:31:53 PST (-0800), sho...@gmail.com wrote: On Wed, Jan 24, 2018 at 07:07:56PM -0800, Palmer Dabbelt wrote: The old mechanism for handling IRQs on RISC-V was pretty ugly: the arch code looked at the Kconfig entry for our first-level irqchip driver and called into it

Re: [patches] Re: [PATCH v2 4/4] RISC-V: Move to the new generic IRQ handler

On Thu, 25 Jan 2018 00:31:53 PST (-0800), sho...@gmail.com wrote: On Wed, Jan 24, 2018 at 07:07:56PM -0800, Palmer Dabbelt wrote: The old mechanism for handling IRQs on RISC-V was pretty ugly: the arch code looked at the Kconfig entry for our first-level irqchip driver and called into it

Re: [tip:x86/pti] x86/retpoline: Fill return stack buffer on vmexit

On Thu, 2018-01-25 at 16:51 +0100, Borislav Petkov wrote: > > > And the seg fault is objtool's way of telling you you need a > > ANNOTATE_NOSPEC_ALTERNATIVE above the alternative ;-) > > Except that it blew up when I did this which doesn't have ALTERNATIVE > (it's the diff I saved :-)) Yeah,

Re: [tip:x86/pti] x86/retpoline: Fill return stack buffer on vmexit

On Thu, 2018-01-25 at 16:51 +0100, Borislav Petkov wrote: > > > And the seg fault is objtool's way of telling you you need a > > ANNOTATE_NOSPEC_ALTERNATIVE above the alternative ;-) > > Except that it blew up when I did this which doesn't have ALTERNATIVE > (it's the diff I saved :-)) Yeah,

PATCH v6 1/6] livepatch: Use lists to manage patches, objects and functions

From: Jason Baron Currently klp_patch contains a pointer to a statically allocated array of struct klp_object and struct klp_objects contains a pointer to a statically allocated array of klp_func. In order to allow for the dynamic allocation of objects and functions, link

PATCH v6 1/6] livepatch: Use lists to manage patches, objects and functions

From: Jason Baron Currently klp_patch contains a pointer to a statically allocated array of struct klp_object and struct klp_objects contains a pointer to a statically allocated array of klp_func. In order to allow for the dynamic allocation of objects and functions, link klp_patch, klp_object,

PATCH v6 2/6] livepatch: Free only structures with initialized kobject

We are going to add a feature called atomic replace. It will allow to create a patch that would replace all already registered patches. For this, we will need to dynamically create funcs' and objects' for functions that are not longer patched. We will want to reuse the existing init() and free()

PATCH v6 2/6] livepatch: Free only structures with initialized kobject

We are going to add a feature called atomic replace. It will allow to create a patch that would replace all already registered patches. For this, we will need to dynamically create funcs' and objects' for functions that are not longer patched. We will want to reuse the existing init() and free()

PATCH v6 5/6] livepatch: Support separate list for replaced patches.

From: Jason Baron We are going to add a feature called atomic replace. It will allow to create a patch that would replace all already registered patches. The replaced patches will stay registered because they are typically unregistered by some package uninstall scripts. But

PATCH v6 5/6] livepatch: Support separate list for replaced patches.

From: Jason Baron We are going to add a feature called atomic replace. It will allow to create a patch that would replace all already registered patches. The replaced patches will stay registered because they are typically unregistered by some package uninstall scripts. But we will remove these

PATCH v6 3/6] livepatch: Initial support for dynamic structures

From: Jason Baron We are going to add a feature called atomic replace. It will allow to create a patch that would replace all already registered patches. For this, we will need to dynamically create funcs' and objects' for functions that are not longer patched. This patch

PATCH v6 3/6] livepatch: Initial support for dynamic structures

From: Jason Baron We are going to add a feature called atomic replace. It will allow to create a patch that would replace all already registered patches. For this, we will need to dynamically create funcs' and objects' for functions that are not longer patched. This patch adds basic framework

PATCH v6 6/6] livepatch: Add atomic replace

From: Jason Baron Sometimes we would like to revert a particular fix. Currently, this is not easy because we want to keep all other fixes active and we could revert only the last applied patch. One solution would be to apply new patch that implemented all the reverted

PATCH v6 6/6] livepatch: Add atomic replace

From: Jason Baron Sometimes we would like to revert a particular fix. Currently, this is not easy because we want to keep all other fixes active and we could revert only the last applied patch. One solution would be to apply new patch that implemented all the reverted functions like in the

PATCH v6 4/6] livepatch: Allow to unpatch only functions of the given type

From: Jason Baron We are going to add a feature called atomic replace. It will allow to create a patch that would replace all already registered patches. For this, we will need to dynamically create funcs' and objects' for functions that are not longer patched. The

PATCH v6 4/6] livepatch: Allow to unpatch only functions of the given type

From: Jason Baron We are going to add a feature called atomic replace. It will allow to create a patch that would replace all already registered patches. For this, we will need to dynamically create funcs' and objects' for functions that are not longer patched. The dynamically allocated objects

PATCH v6 0/6] livepatch: Atomic replace feature

Hi, the atomic replace allows to create cumulative patches. They are useful when you maintain many livepatches and want to remove one that is lower on the stack. In addition it is very useful when more patches touch the same function and there are dependencies between them. This is my rework

PATCH v6 0/6] livepatch: Atomic replace feature

Hi, the atomic replace allows to create cumulative patches. They are useful when you maintain many livepatches and want to remove one that is lower on the stack. In addition it is very useful when more patches touch the same function and there are dependencies between them. This is my rework

[PATCH] drm/stm: ltdc: use crtc_mode_fixup to update adjusted_mode clock

There is a difference between the panel/bridge requested pixel clock value and the real one due to the hw platform clock preciseness (pll, dividers...). This patch updates the adjusted_mode clock value with the real hw clock value so then attached encoder & connector can use it for precise timing

[PATCH] drm/stm: ltdc: use crtc_mode_fixup to update adjusted_mode clock

There is a difference between the panel/bridge requested pixel clock value and the real one due to the hw platform clock preciseness (pll, dividers...). This patch updates the adjusted_mode clock value with the real hw clock value so then attached encoder & connector can use it for precise timing

Re: [RFC PATCH V4 1/5] workqueue: rename system workqueues

Hello, On Thu, Jan 25, 2018 at 07:54:41AM -0800, Tejun Heo wrote: > On Thu, Jan 25, 2018 at 03:01:40PM +0800, Wen Yang wrote: > > Rename system_wq's wq->name from "events" to "system_percpu", > > and similarly for the similarly named workqueues. > > > > Signed-off-by: Wen Yang

Re: [RFC PATCH V4 1/5] workqueue: rename system workqueues

Hello, On Thu, Jan 25, 2018 at 07:54:41AM -0800, Tejun Heo wrote: > On Thu, Jan 25, 2018 at 03:01:40PM +0800, Wen Yang wrote: > > Rename system_wq's wq->name from "events" to "system_percpu", > > and similarly for the similarly named workqueues. > > > > Signed-off-by: Wen Yang > >

Re: [PATCH bpf-next] cgroup: support attaching eBPF programs to net_prio cgroup

On Thu, Jan 25, 2018 at 11:50 PM, Tejun Heo wrote: > On Thu, Jan 25, 2018 at 11:38:48PM +0800, Yafang Shao wrote: >> If net_prio is used, we could also use eBPF programs to attach it, >> because the net_prio cgroup could be got with prioidx in struct >> sock_cgroup_data. >> Hence

Re: [PATCH bpf-next] cgroup: support attaching eBPF programs to net_prio cgroup

On Thu, Jan 25, 2018 at 11:50 PM, Tejun Heo wrote: > On Thu, Jan 25, 2018 at 11:38:48PM +0800, Yafang Shao wrote: >> If net_prio is used, we could also use eBPF programs to attach it, >> because the net_prio cgroup could be got with prioidx in struct >> sock_cgroup_data. >> Hence it should not

Re: [PATCH v6 11/12] arm64: topology: enable ACPI/PPTT based CPU topology

Hi, On 01/25/2018 06:15 AM, Xiongfeng Wang wrote: Hi Jeremy, I have tested the patch with the newest UEFI. It prints the below error: [4.017371] BUG: arch topology borken [4.021069] BUG: arch topology borken [4.024764] BUG: arch topology borken [4.028460] BUG: arch topology

Re: [PATCH v6 11/12] arm64: topology: enable ACPI/PPTT based CPU topology

Hi, On 01/25/2018 06:15 AM, Xiongfeng Wang wrote: Hi Jeremy, I have tested the patch with the newest UEFI. It prints the below error: [4.017371] BUG: arch topology borken [4.021069] BUG: arch topology borken [4.024764] BUG: arch topology borken [4.028460] BUG: arch topology

[PATCH] drm/bridge/synopsys: dsi: use adjusted_mode in mode_set

The "adjusted_mode" clock value (ie the real pixel clock) is more accurate than "mode" clock value (ie the panel/bridge requested clock value). It offers a better preciseness for timing computations and allows to reduce the extra dsi bandwidth in burst mode (from ~20% to ~10-12%, hw platform

[PATCH] drm/bridge/synopsys: dsi: use adjusted_mode in mode_set

The "adjusted_mode" clock value (ie the real pixel clock) is more accurate than "mode" clock value (ie the panel/bridge requested clock value). It offers a better preciseness for timing computations and allows to reduce the extra dsi bandwidth in burst mode (from ~20% to ~10-12%, hw platform

Re: [RFC] spi: add spi multiplexing functions for dt

On 24 January 2018 at 14:54, Mark Brown wrote: > On Wed, Jan 24, 2018 at 02:01:55PM +, Ben Whitten wrote: >> On 23 January 2018 at 11:11, Mark Brown wrote: > >> > level. Things that have their own transfer function would be better off >> > just being

Re: [RFC PATCH V4 1/5] workqueue: rename system workqueues

Hello, On Thu, Jan 25, 2018 at 03:01:40PM +0800, Wen Yang wrote: > Rename system_wq's wq->name from "events" to "system_percpu", > and similarly for the similarly named workqueues. > > Signed-off-by: Wen Yang > Signed-off-by: Jiang Biao >

Re: [RFC] spi: add spi multiplexing functions for dt

On 24 January 2018 at 14:54, Mark Brown wrote: > On Wed, Jan 24, 2018 at 02:01:55PM +, Ben Whitten wrote: >> On 23 January 2018 at 11:11, Mark Brown wrote: > >> > level. Things that have their own transfer function would be better off >> > just being first order SPI controllers I think so

Re: [RFC PATCH V4 1/5] workqueue: rename system workqueues

Hello, On Thu, Jan 25, 2018 at 03:01:40PM +0800, Wen Yang wrote: > Rename system_wq's wq->name from "events" to "system_percpu", > and similarly for the similarly named workqueues. > > Signed-off-by: Wen Yang > Signed-off-by: Jiang Biao > Signed-off-by: Tan Hu > Suggested-by: Tejun Heo > Cc:

Re: [PATCH RFC 0/4] irqchip: qcom: add support for PDC interrupt controller

On Wed, Jan 24 2018 at 17:54 +, Sudeep Holla wrote: On 24/01/18 17:43, Lina Iyer wrote: On Wed, Jan 24 2018 at 10:10 +, Sudeep Holla wrote: On 23/01/18 18:44, Lina Iyer wrote: On Tue, Jan 23 2018 at 18:15 +, Sudeep Holla wrote: Also when will this PDC wakeup interrupts get

Re: [PATCH RFC 0/4] irqchip: qcom: add support for PDC interrupt controller

On Wed, Jan 24 2018 at 17:54 +, Sudeep Holla wrote: On 24/01/18 17:43, Lina Iyer wrote: On Wed, Jan 24 2018 at 10:10 +, Sudeep Holla wrote: On 23/01/18 18:44, Lina Iyer wrote: On Tue, Jan 23 2018 at 18:15 +, Sudeep Holla wrote: Also when will this PDC wakeup interrupts get

Re: [tip:x86/pti] x86/retpoline: Fill return stack buffer on vmexit

On Thu, Jan 25, 2018 at 09:10:24AM -0600, Josh Poimboeuf wrote: > Huh? GCC doesn't even look inside the inline asm. That's why we had to > implement ASM_CALL_CONSTRAINT. That wasn't very correct. What I meant was: *we* need to tell gcc that the inline asm *might* clobber registers and which

Re: [tip:x86/pti] x86/retpoline: Fill return stack buffer on vmexit

On Thu, Jan 25, 2018 at 09:10:24AM -0600, Josh Poimboeuf wrote: > Huh? GCC doesn't even look inside the inline asm. That's why we had to > implement ASM_CALL_CONSTRAINT. That wasn't very correct. What I meant was: *we* need to tell gcc that the inline asm *might* clobber registers and which

[PATCH bpf-next] cgroup: support attaching eBPF programs to net_prio cgroup

If net_prio is used, we could also use eBPF programs to attach it, because the net_prio cgroup could be got with prioidx in struct sock_cgroup_data. Hence it should not only be limited to cgroup2. Signed-off-by: Yafang Shao --- include/linux/cgroup.h | 16 +++-

[PATCH bpf-next] cgroup: support attaching eBPF programs to net_prio cgroup

If net_prio is used, we could also use eBPF programs to attach it, because the net_prio cgroup could be got with prioidx in struct sock_cgroup_data. Hence it should not only be limited to cgroup2. Signed-off-by: Yafang Shao --- include/linux/cgroup.h | 16 +++-

Re: [PATCH 4.14 023/159] mm/sparsemem: Allocate mem_section at runtime for CONFIG_SPARSEMEM_EXTREME=y

On Wed, Jan 17, 2018 at 01:24:54PM +0800, Baoquan He wrote: > Hi Kirill, > > I setup qemu 2.9.0 to test 5-level on kexec/kdump support. While both > kexec and kdump reset to BIOS immediately after triggering. I saw your > patch adding 5-level paging support for kexec. Wonder if your test >

Re: [PATCH 4.14 023/159] mm/sparsemem: Allocate mem_section at runtime for CONFIG_SPARSEMEM_EXTREME=y

On Wed, Jan 17, 2018 at 01:24:54PM +0800, Baoquan He wrote: > Hi Kirill, > > I setup qemu 2.9.0 to test 5-level on kexec/kdump support. While both > kexec and kdump reset to BIOS immediately after triggering. I saw your > patch adding 5-level paging support for kexec. Wonder if your test >

Re: [PATCH bpf-next] cgroup: support attaching eBPF programs to net_prio cgroup

On Thu, Jan 25, 2018 at 11:38:48PM +0800, Yafang Shao wrote: > If net_prio is used, we could also use eBPF programs to attach it, > because the net_prio cgroup could be got with prioidx in struct > sock_cgroup_data. > Hence it should not only be limited to cgroup2. I really don't wanna do this.

Re: [PATCH bpf-next] cgroup: support attaching eBPF programs to net_prio cgroup

On Thu, Jan 25, 2018 at 11:38:48PM +0800, Yafang Shao wrote: > If net_prio is used, we could also use eBPF programs to attach it, > because the net_prio cgroup could be got with prioidx in struct > sock_cgroup_data. > Hence it should not only be limited to cgroup2. I really don't wanna do this.

[PATCH 2/2] Input: sirfsoc-onkey: Improve a size determination in sirfsoc_pwrc_probe()

From: Markus Elfring Date: Thu, 25 Jan 2018 16:35:13 +0100 Replace the specification of a data structure by a pointer dereference as the parameter for the operator "sizeof" to make the corresponding size determination a bit safer according to the Linux coding style

[PATCH 2/2] Input: sirfsoc-onkey: Improve a size determination in sirfsoc_pwrc_probe()

From: Markus Elfring Date: Thu, 25 Jan 2018 16:35:13 +0100 Replace the specification of a data structure by a pointer dereference as the parameter for the operator "sizeof" to make the corresponding size determination a bit safer according to the Linux coding style convention. This issue was

[PATCH v1 1/2] Kconfig : Remove HAS_IOMEM dependency for Graphics support

The 'commit e25df1205f37 ("[S390] Kconfig: menus with depends on HAS_IOMEM.")' added the HAS_IOMEM dependecy for "Graphics support". This disabled the "Graphics support" menu for S390. But if we enable VT layer for S390, we would also need to enable the dummy console. So let's remove the HAS_IOMEM

[PATCH v1 1/2] Kconfig : Remove HAS_IOMEM dependency for Graphics support

The 'commit e25df1205f37 ("[S390] Kconfig: menus with depends on HAS_IOMEM.")' added the HAS_IOMEM dependecy for "Graphics support". This disabled the "Graphics support" menu for S390. But if we enable VT layer for S390, we would also need to enable the dummy console. So let's remove the HAS_IOMEM

[PATCH v1 0/2] Kconfig changes to enable Graphics Support for S390

Hi, This series of patches are in preparation for enabling an additional tty and console for a S390 KVM guest using a virtio-gpu device[1]. One of the steps to do this would be to enable CONFIG_VT for S390, and this would also require the dummy console (CONFIG_DUMMY_CONSOLE). Patch 1 enables the

[PATCH v1 0/2] Kconfig changes to enable Graphics Support for S390

Hi, This series of patches are in preparation for enabling an additional tty and console for a S390 KVM guest using a virtio-gpu device[1]. One of the steps to do this would be to enable CONFIG_VT for S390, and this would also require the dummy console (CONFIG_DUMMY_CONSOLE). Patch 1 enables the

[PATCH v1 2/2] fbdev: Kconfig: Add HAS_IOMEM dependency for FB_OPENCORES

The Opencores framebuffer device uses I/O memory and with CONFIG_HAS_IOMEM disabled will lead to build errors: ERROR: "devm_ioremap_resource" [drivers/video/fbdev/ocfb.ko] undefined! Fix this by adding HAS_IOMEM dependency for FB_OPENCORES. Signed-off-by: Farhan Ali

[PATCH v1 2/2] fbdev: Kconfig: Add HAS_IOMEM dependency for FB_OPENCORES

The Opencores framebuffer device uses I/O memory and with CONFIG_HAS_IOMEM disabled will lead to build errors: ERROR: "devm_ioremap_resource" [drivers/video/fbdev/ocfb.ko] undefined! Fix this by adding HAS_IOMEM dependency for FB_OPENCORES. Signed-off-by: Farhan Ali ---

[PATCH 1/2] Input: sirfsoc-onkey: Delete an error message for a failed memory allocation in sirfsoc_pwrc_probe()

From: Markus Elfring Date: Thu, 25 Jan 2018 16:32:09 +0100 Omit an extra message for a memory allocation failure in this function. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring ---

[PATCH 1/2] Input: sirfsoc-onkey: Delete an error message for a failed memory allocation in sirfsoc_pwrc_probe()

From: Markus Elfring Date: Thu, 25 Jan 2018 16:32:09 +0100 Omit an extra message for a memory allocation failure in this function. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring --- drivers/input/misc/sirfsoc-onkey.c | 4 +--- 1 file changed, 1

<    4   5   6   7   8   9   10   11   12   13   >