Regression in 4.9-rc1 for PPC32 - bisected to commit 05fd007e4629

Kernel 4.9-rc1 fails to boot on my PowerBook G4 Aluminum (32-bit PowerPC) with the following splat: Kernel Panic - not synching: Attempted to kill init: exitcode = 0x0200 Call trace: dump_stack+0x24/0x34 (unreliable) panic+0x110/0x2ac do_exit+0x464/0x834 do_group_exit+0x84/0xac

Regression in 4.9-rc1 for PPC32 - bisected to commit 05fd007e4629

Kernel 4.9-rc1 fails to boot on my PowerBook G4 Aluminum (32-bit PowerPC) with the following splat: Kernel Panic - not synching: Attempted to kill init: exitcode = 0x0200 Call trace: dump_stack+0x24/0x34 (unreliable) panic+0x110/0x2ac do_exit+0x464/0x834 do_group_exit+0x84/0xac

Re: [patch] perf_event_open.2: add cycles field in LBR records

Hi Vince, On 10/19/2016 05:10 PM, Vince Weaver wrote: > > Linux 4.3 (71ef3c6b9d4665ee7afbbe4c208a98917dcfc32f) > added a cycles field to the PERF_SAMPLE_BRANCH_STACK > last branch records. > > The kernel commit was a bit vague on this, but you can find > a few more details on this in the Intel

Re: [patch] perf_event_open.2: add cycles field in LBR records

Hi Vince, On 10/19/2016 05:10 PM, Vince Weaver wrote: > > Linux 4.3 (71ef3c6b9d4665ee7afbbe4c208a98917dcfc32f) > added a cycles field to the PERF_SAMPLE_BRANCH_STACK > last branch records. > > The kernel commit was a bit vague on this, but you can find > a few more details on this in the Intel

[PATCH V2 4/5] arm64: Allow hw watchpoint of length 3,5,6 and 7

Since, arm64 can support all offset within a double word limit. Therefore, now support other lengths within that range as well. Signed-off-by: Pratyush Anand --- arch/arm64/include/asm/hw_breakpoint.h | 4 arch/arm64/kernel/hw_breakpoint.c | 36

[PATCH V2 4/5] arm64: Allow hw watchpoint of length 3,5,6 and 7

Since, arm64 can support all offset within a double word limit. Therefore, now support other lengths within that range as well. Signed-off-by: Pratyush Anand --- arch/arm64/include/asm/hw_breakpoint.h | 4 arch/arm64/kernel/hw_breakpoint.c | 36 ++ 2

Re: [patch] perf_event_open.2: PERF_RECORD_SWITCH support

On 10/19/2016 05:14 PM, Vince Weaver wrote: > On Wed, 19 Oct 2016, Michael Kerrisk (man-pages) wrote: > >>> diff --git a/man2/perf_event_open.2 b/man2/perf_event_open.2 >>> index 68b99bb..04a0cf5 100644 >>> +.B PERF_RECORD_SWITCH_CPU_WIDE >>> +records when sampling in cpu-wide mode. >>> +This

Re: [patch] perf_event_open.2: PERF_RECORD_SWITCH support

On 10/19/2016 05:14 PM, Vince Weaver wrote: > On Wed, 19 Oct 2016, Michael Kerrisk (man-pages) wrote: > >>> diff --git a/man2/perf_event_open.2 b/man2/perf_event_open.2 >>> index 68b99bb..04a0cf5 100644 >>> +.B PERF_RECORD_SWITCH_CPU_WIDE >>> +records when sampling in cpu-wide mode. >>> +This

[PATCH V2 5/5] selftests: arm64: add test for unaligned/inexact watchpoint handling

ARM64 hardware expects 64bit aligned address for watchpoint invocation. However, it provides byte selection method to select any number of consecutive byte set within the range of 1-8. This patch adds support to test all such byte selection option for different memory write sizes. Patch also

[PATCH V2 2/5] arm64: Allow hw watchpoint at varied offset from base address

ARM64 hardware supports watchpoint at any double word aligned address. However, it can select any consecutive bytes from offset 0 to 7 from that base address. For example, if base address is programmed as 0x420030 and byte select is 0x1C, then access of 0x420032,0x420033 and 0x420034 will generate

[PATCH V2 5/5] selftests: arm64: add test for unaligned/inexact watchpoint handling

ARM64 hardware expects 64bit aligned address for watchpoint invocation. However, it provides byte selection method to select any number of consecutive byte set within the range of 1-8. This patch adds support to test all such byte selection option for different memory write sizes. Patch also

[PATCH V2 2/5] arm64: Allow hw watchpoint at varied offset from base address

ARM64 hardware supports watchpoint at any double word aligned address. However, it can select any consecutive bytes from offset 0 to 7 from that base address. For example, if base address is programmed as 0x420030 and byte select is 0x1C, then access of 0x420032,0x420033 and 0x420034 will generate

[PATCH V2 1/5] hw_breakpoint: Allow watchpoint of length 3,5,6 and 7

We only support breakpoint/watchpoint of length 1, 2, 4 and 8. If we can support other length as well, then user may watch more data with less number of watchpoints (provided hardware supports it). For example: if we have to watch only 4th, 5th and 6th byte from a 64 bit aligned address, we will

[PATCH V2 0/5] ARM64: More flexible HW watchpoint

Currently, we do not support all the byte select option provided by ARM64 specs for a HW watchpoint. This patch set will help user to instrument a watchpoint with all possible byte select options. Changes since v1: Introduced a new patch 3/5 where it takes care of the situation when HW does not

[PATCH V2 1/5] hw_breakpoint: Allow watchpoint of length 3,5,6 and 7

We only support breakpoint/watchpoint of length 1, 2, 4 and 8. If we can support other length as well, then user may watch more data with less number of watchpoints (provided hardware supports it). For example: if we have to watch only 4th, 5th and 6th byte from a 64 bit aligned address, we will

[PATCH V2 0/5] ARM64: More flexible HW watchpoint

Currently, we do not support all the byte select option provided by ARM64 specs for a HW watchpoint. This patch set will help user to instrument a watchpoint with all possible byte select options. Changes since v1: Introduced a new patch 3/5 where it takes care of the situation when HW does not

[PATCH V2 3/5] arm64: hw_breakpoint: Handle inexact watchpoint addresses

From: Pavel Labath Arm64 hardware does not always report a watchpoint hit address that matches one of the watchpoints set. It can also report an address "near" the watchpoint if a single instruction access both watched and unwatched addresses. There is no

[PATCH V2 3/5] arm64: hw_breakpoint: Handle inexact watchpoint addresses

From: Pavel Labath Arm64 hardware does not always report a watchpoint hit address that matches one of the watchpoints set. It can also report an address "near" the watchpoint if a single instruction access both watched and unwatched addresses. There is no straight-forward way, short of

Re: [RESEND PATCH v2 4/4] usb: doc: add document for USB3 debug port usage

Hi Jani, On 10/19/2016 03:48 PM, Jani Nikula wrote: > On Wed, 19 Oct 2016, Lu Baolu wrote: >> Add Documentation/usb/usb3-debug-port.txt. This document includes >> the user guide for USB3 debug port. > If you're adding completely new files, please at least consider

Re: [RESEND PATCH v2 4/4] usb: doc: add document for USB3 debug port usage

Hi Jani, On 10/19/2016 03:48 PM, Jani Nikula wrote: > On Wed, 19 Oct 2016, Lu Baolu wrote: >> Add Documentation/usb/usb3-debug-port.txt. This document includes >> the user guide for USB3 debug port. > If you're adding completely new files, please at least consider writing > them in

Re: [4.9-rc1+] intel_uncore builtin + CONFIG_DEBUG_TEST_DRIVER_REMOVE kernel panic

On Wed, Oct 19, 2016 at 09:19:43PM +0200, Jiri Olsa wrote: > I think the reason here is that presume pmu devices are always added, > but we add them only if pmu_bus_running (in perf_event_sysfs_init) > is set which might happen after uncore initcall > > attached patch fixes the issue for me

Re: [4.9-rc1+] intel_uncore builtin + CONFIG_DEBUG_TEST_DRIVER_REMOVE kernel panic

On Wed, Oct 19, 2016 at 09:19:43PM +0200, Jiri Olsa wrote: > I think the reason here is that presume pmu devices are always added, > but we add them only if pmu_bus_running (in perf_event_sysfs_init) > is set which might happen after uncore initcall > > attached patch fixes the issue for me

Re: Regression in intel_powerclamp, due to cpu whitelist removal

On Wed, 2016-10-19 at 20:45 -0700, Jacob Pan wrote: > On Tue, 18 Oct 2016 14:20:49 + > Alok Kataria wrote: > > > > > Hi Jacob, Zhang,  > > > > One of your recent commit "thermal/powerclamp: remove cpu > > whitelist” [1], has caused a regression in the kernel.  > > > >

Re: Regression in intel_powerclamp, due to cpu whitelist removal

On Wed, 2016-10-19 at 20:45 -0700, Jacob Pan wrote: > On Tue, 18 Oct 2016 14:20:49 + > Alok Kataria wrote: > > > > > Hi Jacob, Zhang,  > > > > One of your recent commit "thermal/powerclamp: remove cpu > > whitelist” [1], has caused a regression in the kernel.  > > > > That commit changed

Re: [PATCH v3 1/2] arm64: dts: uniphier: add CPU clock and OPP table for LD11 SoC

On 20-10-16, 13:44, Masahiro Yamada wrote: > Add a CPU clock to every CPU node and a CPU OPP table to use the > generic cpufreq driver. > > Note: > clock-latency-ns (300ns) was calculated based on the CPU-gear switch > sequencer spec; it takes 12 clock cycles on the sequencer running > at 50 MHz,

Re: [PATCH v3 1/2] arm64: dts: uniphier: add CPU clock and OPP table for LD11 SoC

On 20-10-16, 13:44, Masahiro Yamada wrote: > Add a CPU clock to every CPU node and a CPU OPP table to use the > generic cpufreq driver. > > Note: > clock-latency-ns (300ns) was calculated based on the CPU-gear switch > sequencer spec; it takes 12 clock cycles on the sequencer running > at 50 MHz,

Re: [lkp] [ipc/sem.c] 5864a2fd30: aim9.shared_memory.ops_per_sec -13.0%

On 10/20/2016 02:21 AM, Andrew Morton wrote: On Wed, 19 Oct 2016 06:38:14 +0200 Manfred Spraul wrote: Hi, as discussed before: The root cause for the performance regression is the smp_mb() that was added into the fast path. I see two options: 1) switch to full

Re: [lkp] [ipc/sem.c] 5864a2fd30: aim9.shared_memory.ops_per_sec -13.0%

On 10/20/2016 02:21 AM, Andrew Morton wrote: On Wed, 19 Oct 2016 06:38:14 +0200 Manfred Spraul wrote: Hi, as discussed before: The root cause for the performance regression is the smp_mb() that was added into the fast path. I see two options: 1) switch to full spin_lock()/spin_unlock() for

[PATCH v3 2/2] arm64: dts: uniphier: add CPU clocks and OPP tables for LD20 SoC

Add a CPU clock to every CPU node and CPU OPP tables to use the generic cpufreq driver. All the CPUs in each cluster share the same OPP table. Note: clock-latency-ns (300ns) was calculated based on the CPU-gear switch sequencer spec; it takes 12 clock cycles on the sequencer running at 50 MHz,

[PATCH v3 2/2] arm64: dts: uniphier: add CPU clocks and OPP tables for LD20 SoC

Add a CPU clock to every CPU node and CPU OPP tables to use the generic cpufreq driver. All the CPUs in each cluster share the same OPP table. Note: clock-latency-ns (300ns) was calculated based on the CPU-gear switch sequencer spec; it takes 12 clock cycles on the sequencer running at 50 MHz,

[PATCH v3 1/2] arm64: dts: uniphier: add CPU clock and OPP table for LD11 SoC

Add a CPU clock to every CPU node and a CPU OPP table to use the generic cpufreq driver. Note: clock-latency-ns (300ns) was calculated based on the CPU-gear switch sequencer spec; it takes 12 clock cycles on the sequencer running at 50 MHz, plus a bit additional latency. Signed-off-by: Masahiro

[PATCH v3 1/2] arm64: dts: uniphier: add CPU clock and OPP table for LD11 SoC

Add a CPU clock to every CPU node and a CPU OPP table to use the generic cpufreq driver. Note: clock-latency-ns (300ns) was calculated based on the CPU-gear switch sequencer spec; it takes 12 clock cycles on the sequencer running at 50 MHz, plus a bit additional latency. Signed-off-by: Masahiro

Re: [PATCH 2/2] phy: qcom-qmp: new qmp phy driver for qcom-chipsets

On Wed, Oct 19, 2016 at 4:24 PM, Vivek Gautam wrote: > CC: Srinivas Kandagatla > > > On 10/19/2016 04:13 PM, Vivek Gautam wrote: >> >> Qualcomm SOCs have QMP phy controller that provides support >> to a number of controller, viz. PCIe, UFS, and USB. >> Add a new

Re: [PATCH 2/2] phy: qcom-qmp: new qmp phy driver for qcom-chipsets

On Wed, Oct 19, 2016 at 4:24 PM, Vivek Gautam wrote: > CC: Srinivas Kandagatla > > > On 10/19/2016 04:13 PM, Vivek Gautam wrote: >> >> Qualcomm SOCs have QMP phy controller that provides support >> to a number of controller, viz. PCIe, UFS, and USB. >> Add a new driver, based on generic phy

[RFC][PATCH 1/2 v2] usb: dwc2: Force port resume on switching to device mode

From: Chen Yu We've seen failures when switching between host and gadget mode, which was diagnosed as being caused due to the bus being auto-suspended when we switched. So this patch forces a port resume when switching to device mode if the bus is suspended. Cc: Wei Xu

[RFC][PATCH 1/2 v2] usb: dwc2: Force port resume on switching to device mode

From: Chen Yu We've seen failures when switching between host and gadget mode, which was diagnosed as being caused due to the bus being auto-suspended when we switched. So this patch forces a port resume when switching to device mode if the bus is suspended. Cc: Wei Xu Cc: Guodong Xu Cc:

[RFC][PATCH 2/2 v2] usb: dwc2: Add a quirk to allow speed negotiation for Hisilicon Hi6220

From: Chen Yu The Hi6220's usb controller is limited in that it does not support "Split Transactions", so it does not support communicating with low-speed and full-speed devices behind a high-speed hub. Thus it requires a quirk so that we can manually drop the usb speed

[RFC][PATCH 0/2 v2] dwc2 fixes for HiKey

I wanted to send out two patches we're using on the dwc2 driver in order to make HiKey function. The first is seemingly just a bug fix we ran into when changing modes while the bus was auto-suspended. The second is a little more interesting as it works around a limitation of the the device in

[RFC][PATCH 2/2 v2] usb: dwc2: Add a quirk to allow speed negotiation for Hisilicon Hi6220

From: Chen Yu The Hi6220's usb controller is limited in that it does not support "Split Transactions", so it does not support communicating with low-speed and full-speed devices behind a high-speed hub. Thus it requires a quirk so that we can manually drop the usb speed when low/full-speed are

[RFC][PATCH 0/2 v2] dwc2 fixes for HiKey

I wanted to send out two patches we're using on the dwc2 driver in order to make HiKey function. The first is seemingly just a bug fix we ran into when changing modes while the bus was auto-suspended. The second is a little more interesting as it works around a limitation of the the device in

Re: [PATCH 1/2] phy: qcom-qusb2: New driver for QUSB2 PHY on Qcom chips

On Wed, Oct 19, 2016 at 4:13 PM, Vivek Gautam wrote: > PHY transceiver driver for QUSB2 phy controller that provides > HighSpeed functionality for DWC3 controller present on > Qualcomm chipsets. > > This driver is based on phy-msm-qusb driver available in > msm-4.4

Re: [PATCH 1/2] phy: qcom-qusb2: New driver for QUSB2 PHY on Qcom chips

On Wed, Oct 19, 2016 at 4:13 PM, Vivek Gautam wrote: > PHY transceiver driver for QUSB2 phy controller that provides > HighSpeed functionality for DWC3 controller present on > Qualcomm chipsets. > > This driver is based on phy-msm-qusb driver available in > msm-4.4 kernel @codeaurora[1] > > [1]

Re: [PATCH] kbuild: provide include/asm/asm-prototypes.h for ARM

On Wed, 19 Oct 2016 16:32:00 +0100 Russell King - ARM Linux wrote: > On Wed, Oct 19, 2016 at 05:02:55PM +0200, Arnd Bergmann wrote: > > On Wednesday, October 19, 2016 4:52:06 PM CEST Michal Marek wrote: > > > Dne 17.10.2016 v 14:26 Arnd Bergmann napsal(a): > > > > This

Re: [PATCH] kbuild: provide include/asm/asm-prototypes.h for ARM

On Wed, 19 Oct 2016 16:32:00 +0100 Russell King - ARM Linux wrote: > On Wed, Oct 19, 2016 at 05:02:55PM +0200, Arnd Bergmann wrote: > > On Wednesday, October 19, 2016 4:52:06 PM CEST Michal Marek wrote: > > > Dne 17.10.2016 v 14:26 Arnd Bergmann napsal(a): > > > > This adds an

4.9-rc1 boot regression, ambiguous bisect result

Hi, I am currently unable to boot a Yoga 900 with latest mainline, but 4.8 boots. The symptom is a reboot before the video console is available. I bisected to commit 816e76129ed5 "efi: Allow drivers to reserve boot services forever". However, that commit is known to be broken. The proposed

4.9-rc1 boot regression, ambiguous bisect result

Hi, I am currently unable to boot a Yoga 900 with latest mainline, but 4.8 boots. The symptom is a reboot before the video console is available. I bisected to commit 816e76129ed5 "efi: Allow drivers to reserve boot services forever". However, that commit is known to be broken. The proposed

Re: Regression in intel_powerclamp, due to cpu whitelist removal

On Wed, 2016-10-19 at 20:45 -0700, Jacob Pan wrote: > On Tue, 18 Oct 2016 14:20:49 + > Alok Kataria wrote: > > > Hi Jacob, Zhang, > > > > One of your recent commit "thermal/powerclamp: remove cpu > > whitelist” [1], has caused a regression in the kernel. > > > > That

Re: Regression in intel_powerclamp, due to cpu whitelist removal

On Wed, 2016-10-19 at 20:45 -0700, Jacob Pan wrote: > On Tue, 18 Oct 2016 14:20:49 + > Alok Kataria wrote: > > > Hi Jacob, Zhang, > > > > One of your recent commit "thermal/powerclamp: remove cpu > > whitelist” [1], has caused a regression in the kernel. > > > > That commit changed

Re: [PATCH v2 2/2] arm64: dts: uniphier: add CPU clocks and OPP tables for LD20 SoC

2016-10-20 12:55 GMT+09:00 Viresh Kumar : > On 20-10-16, 10:15, Masahiro Yamada wrote: >> + opp@6 { >> + opp-hz = /bits/ 64 <67000>; >> + clock-latency-ns = <300>; >> + }; >> +

Re: [PATCH v2 2/2] arm64: dts: uniphier: add CPU clocks and OPP tables for LD20 SoC

2016-10-20 12:55 GMT+09:00 Viresh Kumar : > On 20-10-16, 10:15, Masahiro Yamada wrote: >> + opp@6 { >> + opp-hz = /bits/ 64 <67000>; >> + clock-latency-ns = <300>; >> + }; >> + opp@7 { >> +

Re: [PATCH v2 2/2] arm64: dts: uniphier: add CPU clocks and OPP tables for LD20 SoC

On 20-10-16, 10:15, Masahiro Yamada wrote: > + opp@6 { > + opp-hz = /bits/ 64 <67000>; > + clock-latency-ns = <300>; > + }; > + opp@7 { > + opp-hz = /bits/ 64 <74000>; > +

Re: [PATCH v2 2/2] arm64: dts: uniphier: add CPU clocks and OPP tables for LD20 SoC

On 20-10-16, 10:15, Masahiro Yamada wrote: > + opp@6 { > + opp-hz = /bits/ 64 <67000>; > + clock-latency-ns = <300>; > + }; > + opp@7 { > + opp-hz = /bits/ 64 <74000>; > +

Re: [GIT PULL] kbuild changes for v4.9-rc1

On Wed, 19 Oct 2016 16:38:14 +0200 Michal Marek wrote: > Dne 18.10.2016 v 03:34 Nicholas Piggin napsal(a): > > We should probably just bring all these arch patches through the > > kbuild tree. > > > > I'm sorry for the breakage: I didn't realize it broke the build with > > some

Re: [GIT PULL] kbuild changes for v4.9-rc1

On Wed, 19 Oct 2016 16:38:14 +0200 Michal Marek wrote: > Dne 18.10.2016 v 03:34 Nicholas Piggin napsal(a): > > We should probably just bring all these arch patches through the > > kbuild tree. > > > > I'm sorry for the breakage: I didn't realize it broke the build with > > some configs,

[PATCH v2 3/8] drm/sun4i: tcon: Move SoC specific quirks to a DT matched data structure

We already have some differences between the 2 supported SoCs. More will be added as we support other SoCs. To avoid bloating the probe function with even more conditionals, move the quirks to a separate data structure that's tied to the compatible string. Signed-off-by: Chen-Yu Tsai

[PATCH v2 5/8] drm/sun4i: Add compatible strings for A31/A31s display pipelines

The A31's display pipeline has 2 frontends, 2 backends, and 2 TCONs. It also has new display enhancement blocks, such as the DRC (Dynamic Range Controller), the DEU (Display Enhancement Unit), and the CMU (Color Management Unit). It supports HDMI, MIPI DSI, and 2 LCD/LVDS channels. The A31s

[PATCH v2 2/8] drm/sun4i: sun6i-drc: Support DRC on A31 and A31s

The A31 and A31s also have the DRC as part of the display pipeline. As we know virtually nothing about them, just add compatible strings for both SoCs to the stub driver. Signed-off-by: Chen-Yu Tsai Acked-by: Rob Herring ---

[PATCH v2 3/8] drm/sun4i: tcon: Move SoC specific quirks to a DT matched data structure

We already have some differences between the 2 supported SoCs. More will be added as we support other SoCs. To avoid bloating the probe function with even more conditionals, move the quirks to a separate data structure that's tied to the compatible string. Signed-off-by: Chen-Yu Tsai ---

[PATCH v2 5/8] drm/sun4i: Add compatible strings for A31/A31s display pipelines

The A31's display pipeline has 2 frontends, 2 backends, and 2 TCONs. It also has new display enhancement blocks, such as the DRC (Dynamic Range Controller), the DEU (Display Enhancement Unit), and the CMU (Color Management Unit). It supports HDMI, MIPI DSI, and 2 LCD/LVDS channels. The A31s

[PATCH v2 2/8] drm/sun4i: sun6i-drc: Support DRC on A31 and A31s

The A31 and A31s also have the DRC as part of the display pipeline. As we know virtually nothing about them, just add compatible strings for both SoCs to the stub driver. Signed-off-by: Chen-Yu Tsai Acked-by: Rob Herring --- Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt | 2 ++

[PATCH v2 0/8] drm/sun4i: Support first display pipeline on sun6i

Hi everyone, This series adds support for the first display pipeline found on the A31 and A31s SoCs, with output through the RGB LCD interface. This has been tested on the Sinlinx SinA31s development board, with its included 7" LCD panel, and the Merrii Hummingbird A31 development board, with

[PATCH v2 4/8] drm/sun4i: Add compatible string for A31/A31s TCON (timing controller)

The A31 TCON has mux controls for how TCON outputs are routed to the HDMI and MIPI DSI blocks. Since the A31s does not have MIPI DSI, it only has a mux for the HDMI controller input. This patch only adds support for the compatible strings. Actual support for the mux controls should be added with

Re: [PATCH 5/6] clk: pxa: transfer CPU clock setting from pxa2xx-cpufreq

On 19-10-16, 13:51, Stephen Boyd wrote: > On 10/19, Robert Jarzmik wrote: > > Stephen Boyd writes: > > > > > On 10/18, Robert Jarzmik wrote: > > >> Robert Jarzmik writes: > > >> Hi Michael and Stephen, > > >> > > >> I'm planing on sending a v2 next

[PATCH v2 0/8] drm/sun4i: Support first display pipeline on sun6i

Hi everyone, This series adds support for the first display pipeline found on the A31 and A31s SoCs, with output through the RGB LCD interface. This has been tested on the Sinlinx SinA31s development board, with its included 7" LCD panel, and the Merrii Hummingbird A31 development board, with

[PATCH v2 4/8] drm/sun4i: Add compatible string for A31/A31s TCON (timing controller)

The A31 TCON has mux controls for how TCON outputs are routed to the HDMI and MIPI DSI blocks. Since the A31s does not have MIPI DSI, it only has a mux for the HDMI controller input. This patch only adds support for the compatible strings. Actual support for the mux controls should be added with

Re: [PATCH 5/6] clk: pxa: transfer CPU clock setting from pxa2xx-cpufreq

On 19-10-16, 13:51, Stephen Boyd wrote: > On 10/19, Robert Jarzmik wrote: > > Stephen Boyd writes: > > > > > On 10/18, Robert Jarzmik wrote: > > >> Robert Jarzmik writes: > > >> Hi Michael and Stephen, > > >> > > >> I'm planing on sending a v2 next week with minor corrections, mostly in > >

[PATCH v2 7/8] ARM: dts: sun6i: Add A31 LCD0 RGB888 pins

The LCD0 controller on the A31 can do RGB output up to 8 bits per channel. Add the pins for RGB888 output. Signed-off-by: Chen-Yu Tsai --- arch/arm/boot/dts/sun6i-a31.dtsi | 13 + 1 file changed, 13 insertions(+) diff --git a/arch/arm/boot/dts/sun6i-a31.dtsi

[PATCH v2 8/8] ARM: dts: sun6i: hummingbird-a31: Enable display output through VGA bridge

The Hummingbird A31 board has a RGB-to-VGA bridge which converts RGB output from the LCD interface to VGA signals. Enable this part of the display pipeline. Signed-off-by: Chen-Yu Tsai --- arch/arm/boot/dts/sun6i-a31-hummingbird.dts | 56 + 1 file

[PATCH v2 6/8] ARM: dts: sun6i: Add device nodes for first display pipeline

The A31 has 2 parallel display pipelines, which can be intermixed. However the driver currently only supports one of them. Signed-off-by: Chen-Yu Tsai --- arch/arm/boot/dts/sun6i-a31.dtsi | 152 ++ arch/arm/boot/dts/sun6i-a31s.dtsi | 8 ++ 2

[PATCH v2 7/8] ARM: dts: sun6i: Add A31 LCD0 RGB888 pins

The LCD0 controller on the A31 can do RGB output up to 8 bits per channel. Add the pins for RGB888 output. Signed-off-by: Chen-Yu Tsai --- arch/arm/boot/dts/sun6i-a31.dtsi | 13 + 1 file changed, 13 insertions(+) diff --git a/arch/arm/boot/dts/sun6i-a31.dtsi

[PATCH v2 8/8] ARM: dts: sun6i: hummingbird-a31: Enable display output through VGA bridge

The Hummingbird A31 board has a RGB-to-VGA bridge which converts RGB output from the LCD interface to VGA signals. Enable this part of the display pipeline. Signed-off-by: Chen-Yu Tsai --- arch/arm/boot/dts/sun6i-a31-hummingbird.dts | 56 + 1 file changed, 56

[PATCH v2 6/8] ARM: dts: sun6i: Add device nodes for first display pipeline

The A31 has 2 parallel display pipelines, which can be intermixed. However the driver currently only supports one of them. Signed-off-by: Chen-Yu Tsai --- arch/arm/boot/dts/sun6i-a31.dtsi | 152 ++ arch/arm/boot/dts/sun6i-a31s.dtsi | 8 ++ 2 files changed,

Re: [PATCH 08/10] ufs-qcom: phy/hcd: Refactoring phy clock handling

On Thu, Oct 20, 2016 at 12:48 AM, Subhash Jadavani wrote: > On 2016-10-19 10:45, Vivek Gautam wrote: >> >> Hi, >> >> >> On Wed, Oct 19, 2016 at 1:43 AM, Subhash Jadavani >> wrote: >>> >>> On 2016-10-18 07:28, Vivek Gautam wrote:

Re: Regression in intel_powerclamp, due to cpu whitelist removal

On Tue, 18 Oct 2016 14:20:49 + Alok Kataria wrote: > Hi Jacob, Zhang, > > One of your recent commit "thermal/powerclamp: remove cpu > whitelist” [1], has caused a regression in the kernel. > > That commit changed powerclamp_probe from requiring all of the > following

Re: [PATCH 08/10] ufs-qcom: phy/hcd: Refactoring phy clock handling

On Thu, Oct 20, 2016 at 12:48 AM, Subhash Jadavani wrote: > On 2016-10-19 10:45, Vivek Gautam wrote: >> >> Hi, >> >> >> On Wed, Oct 19, 2016 at 1:43 AM, Subhash Jadavani >> wrote: >>> >>> On 2016-10-18 07:28, Vivek Gautam wrote: Add phy clock enable code to phy_power_on/off

Re: Regression in intel_powerclamp, due to cpu whitelist removal

On Tue, 18 Oct 2016 14:20:49 + Alok Kataria wrote: > Hi Jacob, Zhang, > > One of your recent commit "thermal/powerclamp: remove cpu > whitelist” [1], has caused a regression in the kernel. > > That commit changed powerclamp_probe from requiring all of the > following features: > >

[PATCH v2 1/8] drm/bridge: rgb-to-vga: Support an enable GPIO

Some rgb-to-vga bridges have an enable GPIO, either directly tied to an enable pin on the bridge IC, or indirectly controlling a power switch. Add support for it. Signed-off-by: Chen-Yu Tsai --- .../bindings/display/bridge/dumb-vga-dac.txt | 2 ++

[PATCH v2 1/8] drm/bridge: rgb-to-vga: Support an enable GPIO

Some rgb-to-vga bridges have an enable GPIO, either directly tied to an enable pin on the bridge IC, or indirectly controlling a power switch. Add support for it. Signed-off-by: Chen-Yu Tsai --- .../bindings/display/bridge/dumb-vga-dac.txt | 2 ++ drivers/gpu/drm/bridge/dumb-vga-dac.c

[PATCH] ata: set ncq_prio_enabled if device has support

We previously had a check to see if the device has support for prioritized ncq commands and a check to see if a device flag is set, through a sysfs variable, in order to send a prioritized command. This patch only allows the sysfs variable to be set if the device supports prioritized commands

[PATCH] ata: set ncq_prio_enabled if device has support

We previously had a check to see if the device has support for prioritized ncq commands and a check to see if a device flag is set, through a sysfs variable, in order to send a prioritized command. This patch only allows the sysfs variable to be set if the device supports prioritized commands

[PATCH 2/2] mailbox: sti: Fix module autoload for OF registration

If the driver is built as a module, autoload won't work because the module alias information is not filled. So user-space can't match the registered device with the corresponding module. Export the module alias information using the MODULE_DEVICE_TABLE() macro. Before this patch: $ modinfo

[PATCH 2/2] mailbox: sti: Fix module autoload for OF registration

If the driver is built as a module, autoload won't work because the module alias information is not filled. So user-space can't match the registered device with the corresponding module. Export the module alias information using the MODULE_DEVICE_TABLE() macro. Before this patch: $ modinfo

Re: [PATCH v2 1/4] cpufreq: pxa: use generic platdev driver for device-tree

On 19-10-16, 22:06, Robert Jarzmik wrote: > Viresh Kumar writes: > > >> >> + { .compatible = "marvell,pxa250", }, > >> >> + { .compatible = "marvell,pxa270", }, > >> >> > >> >> { .compatible = "samsung,exynos3250", }, > >> >> { .compatible =

[PATCH 1/2] mailbox: mailbox-test: Fix module autoload

If the driver is built as a module, autoload won't work because the module alias information is not filled. So user-space can't match the registered device with the corresponding module. Export the module alias information using the MODULE_DEVICE_TABLE() macro. Before this patch: $ modinfo

Re: [PATCH v2 1/4] cpufreq: pxa: use generic platdev driver for device-tree

On 19-10-16, 22:06, Robert Jarzmik wrote: > Viresh Kumar writes: > > >> >> + { .compatible = "marvell,pxa250", }, > >> >> + { .compatible = "marvell,pxa270", }, > >> >> > >> >> { .compatible = "samsung,exynos3250", }, > >> >> { .compatible = "samsung,exynos4210", },

[PATCH 1/2] mailbox: mailbox-test: Fix module autoload

If the driver is built as a module, autoload won't work because the module alias information is not filled. So user-space can't match the registered device with the corresponding module. Export the module alias information using the MODULE_DEVICE_TABLE() macro. Before this patch: $ modinfo

Re: [PATCH v4 3/5] powerpc/mm: allow memory hotplug into a memoryless node

On 07/10/16 05:36, Reza Arbab wrote: > Remove the check which prevents us from hotplugging into an empty node. > > This limitation has been questioned before [1], and judging by the > response, there doesn't seem to be a reason we can't remove it. No issues > have been found in light testing. >

Re: [PATCH v4 3/5] powerpc/mm: allow memory hotplug into a memoryless node

On 07/10/16 05:36, Reza Arbab wrote: > Remove the check which prevents us from hotplugging into an empty node. > > This limitation has been questioned before [1], and judging by the > response, there doesn't seem to be a reason we can't remove it. No issues > have been found in light testing. >

Re: 4.8.1 regression with cpufreq governors

On 19-10-16, 15:06, Tim Walberg wrote: > This indeed turned out to be the fix. Really? How can this fix the ondemand governor thing? Or is it that Ondemand never broke ? -- viresh

Re: 4.8.1 regression with cpufreq governors

On 19-10-16, 15:06, Tim Walberg wrote: > This indeed turned out to be the fix. Really? How can this fix the ondemand governor thing? Or is it that Ondemand never broke ? -- viresh

linux-next: Tree for Oct 20

Hi all, Changes since 20161019: The net-next tree gained a conflict against the net tree. The akpm-current tree still had its build failures for which I applied 2 patches. Non-merge commits (relative to Linus' tree): 1344 1791 files changed, 152207 insertions(+), 26046 deletions

linux-next: Tree for Oct 20

Hi all, Changes since 20161019: The net-next tree gained a conflict against the net tree. The akpm-current tree still had its build failures for which I applied 2 patches. Non-merge commits (relative to Linus' tree): 1344 1791 files changed, 152207 insertions(+), 26046 deletions

Re: [PATCH net-next 6/6] net: use core MTU range checking in misc drivers

On Thu, Oct 20, 2016 at 12:38:46AM +0200, Stefan Richter wrote: > On Oct 19 Sabrina Dubroca wrote: > > 2016-10-18, 22:33:33 -0400, Jarod Wilson wrote: > > [...] > > > diff --git a/drivers/firewire/net.c b/drivers/firewire/net.c > > > index 309311b..b5f125c 100644 > > > --- a/drivers/firewire/net.c

Re: [PATCH net-next 6/6] net: use core MTU range checking in misc drivers

On Thu, Oct 20, 2016 at 12:38:46AM +0200, Stefan Richter wrote: > On Oct 19 Sabrina Dubroca wrote: > > 2016-10-18, 22:33:33 -0400, Jarod Wilson wrote: > > [...] > > > diff --git a/drivers/firewire/net.c b/drivers/firewire/net.c > > > index 309311b..b5f125c 100644 > > > --- a/drivers/firewire/net.c

Re: x32 is broken in 4.9-rc1 due to "x86/signal: Add SA_{X32,IA32}_ABI sa_flags"

On Thu, Oct 20, 2016 at 01:02:59AM +0300, Dmitry Safonov wrote: > 2016-10-19 20:33 GMT+03:00 Mikulas Patocka : > > On Wed, 19 Oct 2016, Mikulas Patocka wrote: > >> In the kernel 4.9-rc1, the x32 support is seriously broken, a x32 process > >> is killed with SIGKILL after

Re: x32 is broken in 4.9-rc1 due to "x86/signal: Add SA_{X32,IA32}_ABI sa_flags"

On Thu, Oct 20, 2016 at 01:02:59AM +0300, Dmitry Safonov wrote: > 2016-10-19 20:33 GMT+03:00 Mikulas Patocka : > > On Wed, 19 Oct 2016, Mikulas Patocka wrote: > >> In the kernel 4.9-rc1, the x32 support is seriously broken, a x32 process > >> is killed with SIGKILL after returning from any signal

[PATCH 0/1] mm/hugetlb: fix huge page reservation leak in private mapping error paths

This issue was discovered by Jan Stancek as described in https://lkml.kernel.org/r/57ff7bb4.1070...@redhat.com Error paths in hugetlb_cow() and hugetlb_no_page() do not properly clean up reservation entries when freeing a newly allocated huge page. This issue was introduced with commit

[PATCH 0/1] mm/hugetlb: fix huge page reservation leak in private mapping error paths

This issue was discovered by Jan Stancek as described in https://lkml.kernel.org/r/57ff7bb4.1070...@redhat.com Error paths in hugetlb_cow() and hugetlb_no_page() do not properly clean up reservation entries when freeing a newly allocated huge page. This issue was introduced with commit

[PATCH 1/1] mm/hugetlb: fix huge page reservation leak in private mapping error paths

Error paths in hugetlb_cow() and hugetlb_no_page() may free a newly allocated huge page. If a reservation was associated with the huge page, alloc_huge_page() consumed the reservation while allocating. When the newly allocated page is freed in free_huge_page(), it will increment the global

[PATCH 1/1] mm/hugetlb: fix huge page reservation leak in private mapping error paths

Error paths in hugetlb_cow() and hugetlb_no_page() may free a newly allocated huge page. If a reservation was associated with the huge page, alloc_huge_page() consumed the reservation while allocating. When the newly allocated page is freed in free_huge_page(), it will increment the global

  1   2   3   4   5   6   7   8   9   10   >