Need clarity on legacy RC interrupt handling

Hi, Legacy interrupts are level triggered, but i see some RC drivers use flow handler "handle_simple_irq" instead why they are not using "handle_level_irq" ? Why they are registering dummy_irq_chip with "handle_simple_irq", if they use this chip how the irq type is set for this virtual irq

Need clarity on legacy RC interrupt handling

Hi, Legacy interrupts are level triggered, but i see some RC drivers use flow handler "handle_simple_irq" instead why they are not using "handle_level_irq" ? Why they are registering dummy_irq_chip with "handle_simple_irq", if they use this chip how the irq type is set for this virtual irq

[PATCH v3 03/24] ARM: dts: imx6qdl: Add mipi_ipu1/2 multiplexers, mipi_csi, and their connections

From: Philipp Zabel This patch adds the device tree graph connecting the input multiplexers to the IPU CSIs and the MIPI-CSI2 gasket on i.MX6. The MIPI_IPU multiplexers are added as children of the iomuxc-gpr syscon device node. On i.MX6Q/D two two-input multiplexers in

[PATCH v3 02/24] ARM: dts: imx6qdl: Add compatible, clocks, irqs to MIPI CSI-2 node

Add to the MIPI CSI2 receiver node: compatible string, interrupt sources, clocks. Signed-off-by: Steve Longerbeam --- arch/arm/boot/dts/imx6qdl.dtsi | 7 +++ 1 file changed, 7 insertions(+) diff --git a/arch/arm/boot/dts/imx6qdl.dtsi

[PATCH v3 03/24] ARM: dts: imx6qdl: Add mipi_ipu1/2 multiplexers, mipi_csi, and their connections

From: Philipp Zabel This patch adds the device tree graph connecting the input multiplexers to the IPU CSIs and the MIPI-CSI2 gasket on i.MX6. The MIPI_IPU multiplexers are added as children of the iomuxc-gpr syscon device node. On i.MX6Q/D two two-input multiplexers in front of IPU1 CSI0 and

[PATCH v3 02/24] ARM: dts: imx6qdl: Add compatible, clocks, irqs to MIPI CSI-2 node

Add to the MIPI CSI2 receiver node: compatible string, interrupt sources, clocks. Signed-off-by: Steve Longerbeam --- arch/arm/boot/dts/imx6qdl.dtsi | 7 +++ 1 file changed, 7 insertions(+) diff --git a/arch/arm/boot/dts/imx6qdl.dtsi b/arch/arm/boot/dts/imx6qdl.dtsi index 53e6e63..42926e9

[PATCH v3 00/24] i.MX Media Driver

In version 3: Changes suggested by Rob Herring : - prepended FIM node properties with vendor prefix "fsl,". - make mipi csi-2 receiver compatible string SoC specific: "fsl,imx6-mipi-csi2" instead of "fsl,imx-mipi-csi2". - redundant "_clk" removed from mipi csi-2

[PATCH v3 12/24] add mux and video interface bridge entity functions

From: Philipp Zabel Signed-off-by: Philipp Zabel --- Documentation/media/uapi/mediactl/media-types.rst | 22 ++ include/uapi/linux/media.h| 6 ++ 2 files changed, 28 insertions(+) diff --git

[PATCH v3 00/24] i.MX Media Driver

In version 3: Changes suggested by Rob Herring : - prepended FIM node properties with vendor prefix "fsl,". - make mipi csi-2 receiver compatible string SoC specific: "fsl,imx6-mipi-csi2" instead of "fsl,imx-mipi-csi2". - redundant "_clk" removed from mipi csi-2 receiver clock-names

[PATCH v3 12/24] add mux and video interface bridge entity functions

From: Philipp Zabel Signed-off-by: Philipp Zabel --- Documentation/media/uapi/mediactl/media-types.rst | 22 ++ include/uapi/linux/media.h| 6 ++ 2 files changed, 28 insertions(+) diff --git a/Documentation/media/uapi/mediactl/media-types.rst

[PATCH v3 11/24] ARM: dts: imx6-sabreauto: add the ADV7180 video decoder

Enables the ADV7180 decoder sensor. The ADV7180 connects to the parallel-bus mux input on ipu1_csi0_mux. On the sabreauto, two analog video inputs are routed to the ADV7180, composite on Ain1, and composite on Ain3. Those inputs are defined via inputs and input-names under the ADV7180 node. The

[PATCH v3 13/24] platform: add video-multiplexer subdevice driver

From: Philipp Zabel This driver can handle SoC internal and external video bus multiplexers, controlled either by register bit fields or by a GPIO. The subdevice passes through frame interval and mbus configuration of the active input to the output side. Signed-off-by:

[PATCH v3 11/24] ARM: dts: imx6-sabreauto: add the ADV7180 video decoder

Enables the ADV7180 decoder sensor. The ADV7180 connects to the parallel-bus mux input on ipu1_csi0_mux. On the sabreauto, two analog video inputs are routed to the ADV7180, composite on Ain1, and composite on Ain3. Those inputs are defined via inputs and input-names under the ADV7180 node. The

[PATCH v3 13/24] platform: add video-multiplexer subdevice driver

From: Philipp Zabel This driver can handle SoC internal and external video bus multiplexers, controlled either by register bit fields or by a GPIO. The subdevice passes through frame interval and mbus configuration of the active input to the output side. Signed-off-by: Sascha Hauer

[PATCH v3 16/24] media: Add i.MX media core driver

Add the core media driver for i.MX SOC. Signed-off-by: Steve Longerbeam --- Documentation/media/v4l-drivers/imx.rst | 443 ++ drivers/staging/media/Kconfig | 2 + drivers/staging/media/Makefile| 1 +

[PATCH v3 16/24] media: Add i.MX media core driver

Add the core media driver for i.MX SOC. Signed-off-by: Steve Longerbeam --- Documentation/media/v4l-drivers/imx.rst | 443 ++ drivers/staging/media/Kconfig | 2 + drivers/staging/media/Makefile| 1 + drivers/staging/media/imx/Kconfig

[PATCH v3 14/24] UAPI: Add media UAPI Kbuild file

Add an empty UAPI Kbuild file for media UAPI headers. Signed-off-by: Steve Longerbeam --- include/uapi/Kbuild | 1 + include/uapi/media/Kbuild | 1 + 2 files changed, 2 insertions(+) create mode 100644 include/uapi/media/Kbuild diff --git

[PATCH v3 14/24] UAPI: Add media UAPI Kbuild file

Add an empty UAPI Kbuild file for media UAPI headers. Signed-off-by: Steve Longerbeam --- include/uapi/Kbuild | 1 + include/uapi/media/Kbuild | 1 + 2 files changed, 2 insertions(+) create mode 100644 include/uapi/media/Kbuild diff --git a/include/uapi/Kbuild b/include/uapi/Kbuild

[PATCH v3 15/24] media: Add userspace header file for i.MX

This adds a header file for use by userspace programs wanting to interact with the i.MX media driver. It defines custom v4l2 controls and events generated by the i.MX v4l2 subdevices. Signed-off-by: Steve Longerbeam --- include/uapi/media/Kbuild | 1 +

[PATCH v3 17/24] media: imx: Add CSI subdev driver

This is a media entity subdevice for the i.MX Camera Serial Interface module. Signed-off-by: Steve Longerbeam --- drivers/staging/media/imx/Kconfig | 13 + drivers/staging/media/imx/Makefile | 2 + drivers/staging/media/imx/imx-csi.c | 644

[PATCH v3 15/24] media: Add userspace header file for i.MX

This adds a header file for use by userspace programs wanting to interact with the i.MX media driver. It defines custom v4l2 controls and events generated by the i.MX v4l2 subdevices. Signed-off-by: Steve Longerbeam --- include/uapi/media/Kbuild | 1 + include/uapi/media/imx.h | 30

[PATCH v3 17/24] media: imx: Add CSI subdev driver

This is a media entity subdevice for the i.MX Camera Serial Interface module. Signed-off-by: Steve Longerbeam --- drivers/staging/media/imx/Kconfig | 13 + drivers/staging/media/imx/Makefile | 2 + drivers/staging/media/imx/imx-csi.c | 644 3 files

[PATCH v3 18/24] media: imx: Add SMFC subdev driver

This is a media entity subdevice driver for the i.MX Sensor Multi-FIFO Controller module. Video frames are received from the CSI and can be routed to various sinks including the i.MX Image Converter for scaling, color-space conversion, motion compensated deinterlacing, and image rotation.

[PATCH v3 18/24] media: imx: Add SMFC subdev driver

This is a media entity subdevice driver for the i.MX Sensor Multi-FIFO Controller module. Video frames are received from the CSI and can be routed to various sinks including the i.MX Image Converter for scaling, color-space conversion, motion compensated deinterlacing, and image rotation.

[PATCH v3 21/24] media: imx: Add MIPI CSI-2 Receiver subdev driver

Adds MIPI CSI-2 Receiver subdev driver. This subdev is required for sensors with a MIPI CSI2 interface. Signed-off-by: Steve Longerbeam --- drivers/staging/media/imx/Makefile| 1 + drivers/staging/media/imx/imx-mipi-csi2.c | 501

[PATCH v3 20/24] media: imx: Add Camera Interface subdev driver

This is the camera interface driver that provides the v4l2 user interface. Frames can be received from various sources: - directly from SMFC for capturing unconverted images directly from camera sensors. - from the IC pre-process encode task. - from the IC pre-process viewfinder task. - from

[PATCH v3 19/24] media: imx: Add IC subdev drivers

This is a set of three media entity subdevice drivers for the i.MX Image Converter. The i.MX IC module contains three independent "tasks": - Pre-processing Encode task: video frames are routed directly from the CSI and can be scaled, color-space converted, and rotated. Scaled output is

[PATCH v3 21/24] media: imx: Add MIPI CSI-2 Receiver subdev driver

Adds MIPI CSI-2 Receiver subdev driver. This subdev is required for sensors with a MIPI CSI2 interface. Signed-off-by: Steve Longerbeam --- drivers/staging/media/imx/Makefile| 1 + drivers/staging/media/imx/imx-mipi-csi2.c | 501 ++ 2 files changed, 502

[PATCH v3 20/24] media: imx: Add Camera Interface subdev driver

This is the camera interface driver that provides the v4l2 user interface. Frames can be received from various sources: - directly from SMFC for capturing unconverted images directly from camera sensors. - from the IC pre-process encode task. - from the IC pre-process viewfinder task. - from

[PATCH v3 19/24] media: imx: Add IC subdev drivers

This is a set of three media entity subdevice drivers for the i.MX Image Converter. The i.MX IC module contains three independent "tasks": - Pre-processing Encode task: video frames are routed directly from the CSI and can be scaled, color-space converted, and rotated. Scaled output is

[PATCH 2/2] staging:rtl8712 Aligned code with open parenthesis

Aligned code with open parenthesis to fix a checkpatch warning Signed-off-by: Scott Matheina --- drivers/staging/rtl8712/mlme_linux.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/staging/rtl8712/mlme_linux.c

[PATCH 2/2] staging:rtl8712 Aligned code with open parenthesis

Aligned code with open parenthesis to fix a checkpatch warning Signed-off-by: Scott Matheina --- drivers/staging/rtl8712/mlme_linux.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/staging/rtl8712/mlme_linux.c b/drivers/staging/rtl8712/mlme_linux.c index

[PATCH 1/2] staging:rtl8712: Removed unnecessary parentheses

Removed unnecessary parentheses identified by checkpatch Signed-off-by: Scott Matheina --- drivers/staging/rtl8712/ieee80211.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/staging/rtl8712/ieee80211.c b/drivers/staging/rtl8712/ieee80211.c

[PATCH 1/2] staging:rtl8712: Removed unnecessary parentheses

Removed unnecessary parentheses identified by checkpatch Signed-off-by: Scott Matheina --- drivers/staging/rtl8712/ieee80211.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/staging/rtl8712/ieee80211.c b/drivers/staging/rtl8712/ieee80211.c index

[PATCH v3 24/24] ARM: imx_v6_v7_defconfig: Enable staging video4linux drivers

Enable imx v4l2 staging drivers. For video capture on i.MX, the video multiplexer subdev is required. On the SabreAuto, the ADV7180 video decoder is required along with i2c-mux-gpio. The Sabrelite requires PWM clocks for the OV5640. Increase max zoneorder to allow larger video buffer allocations.

[PATCH v3 22/24] media: imx: Add MIPI CSI-2 OV5640 sensor subdev driver

This driver is based on ov5640_mipi.c from Freescale imx_3.10.17_1.0.0_beta branch, modified heavily to bring forward to latest interfaces and code cleanup. Signed-off-by: Steve Longerbeam --- drivers/staging/media/imx/Kconfig |8 +

[PATCH v3 24/24] ARM: imx_v6_v7_defconfig: Enable staging video4linux drivers

Enable imx v4l2 staging drivers. For video capture on i.MX, the video multiplexer subdev is required. On the SabreAuto, the ADV7180 video decoder is required along with i2c-mux-gpio. The Sabrelite requires PWM clocks for the OV5640. Increase max zoneorder to allow larger video buffer allocations.

[PATCH v3 22/24] media: imx: Add MIPI CSI-2 OV5640 sensor subdev driver

This driver is based on ov5640_mipi.c from Freescale imx_3.10.17_1.0.0_beta branch, modified heavily to bring forward to latest interfaces and code cleanup. Signed-off-by: Steve Longerbeam --- drivers/staging/media/imx/Kconfig |8 + drivers/staging/media/imx/Makefile |2 +

[PATCH v3 10/24] ARM: dts: imx6-sabreauto: add pinctrl for gpt input capture

Add pinctrl groups for both GPT input capture channels. Signed-off-by: Steve Longerbeam --- arch/arm/boot/dts/imx6qdl-sabreauto.dtsi | 12 1 file changed, 12 insertions(+) diff --git a/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi

[PATCH v3 08/24] ARM: dts: imx6-sabreauto: create i2cmux for i2c3

The sabreauto uses a steering pin to select between the SDA signal on i2c3 bus, and a data-in pin for an SPI NOR chip. Use i2cmux to control this steering pin. Idle state of the i2cmux selects SPI NOR. This is not a classic way to use i2cmux, since one side of the mux selects something other than

[PATCH v3 08/24] ARM: dts: imx6-sabreauto: create i2cmux for i2c3

The sabreauto uses a steering pin to select between the SDA signal on i2c3 bus, and a data-in pin for an SPI NOR chip. Use i2cmux to control this steering pin. Idle state of the i2cmux selects SPI NOR. This is not a classic way to use i2cmux, since one side of the mux selects something other than

[PATCH v3 10/24] ARM: dts: imx6-sabreauto: add pinctrl for gpt input capture

Add pinctrl groups for both GPT input capture channels. Signed-off-by: Steve Longerbeam --- arch/arm/boot/dts/imx6qdl-sabreauto.dtsi | 12 1 file changed, 12 insertions(+) diff --git a/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi b/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi index

[PATCH v3 04/24] ARM: dts: imx6qdl: add media device

Signed-off-by: Steve Longerbeam --- arch/arm/boot/dts/imx6q.dtsi | 4 arch/arm/boot/dts/imx6qdl.dtsi | 8 2 files changed, 12 insertions(+) diff --git a/arch/arm/boot/dts/imx6q.dtsi b/arch/arm/boot/dts/imx6q.dtsi index 9b2ca32..8867e78 100644 ---

[PATCH v3 05/24] ARM: dts: imx6qdl-sabrelite: remove erratum ERR006687 workaround

There is a pin conflict with GPIO_6. This pin functions as a power input pin to the OV5642 camera sensor, but ENET uses it as the h/w workaround for erratum ERR006687, to wake-up the ARM cores on normal RX and TX packet done events. So we need to remove the h/w workaround to support the OV5642.

[PATCH v3 09/24] ARM: dts: imx6-sabreauto: add reset-gpios property for max7310_b

The reset pin to the port expander chip (MAX7310) is controlled by a gpio, so define a reset-gpios property to control it. There are three MAX7310's on the SabreAuto CPU card (max7310_[abc]), but all use the same pin for their reset. Since all can't acquire the same pin, assign it to max7310_b,

[PATCH v3 07/24] ARM: dts: imx6-sabresd: add OV5642 and OV5640 camera sensors

Enables the OV5642 parallel-bus sensor, and the OV5640 MIPI CSI-2 sensor. The OV5642 connects to the parallel-bus mux input port on ipu1_csi0_mux. The OV5640 connects to the input port on the MIPI CSI-2 receiver on mipi_csi. It is set to transmit over MIPI virtual channel 1. Until the OV5652

[PATCH v3 06/24] ARM: dts: imx6-sabrelite: add OV5642 and OV5640 camera sensors

Enables the OV5642 parallel-bus sensor, and the OV5640 MIPI CSI-2 sensor. Both hang off the same i2c2 bus, so they require different (and non- default) i2c slave addresses. The OV5642 connects to the parallel-bus mux input port on ipu1_csi0_mux. The OV5640 connects to the input port on the MIPI

[PATCH v3 06/24] ARM: dts: imx6-sabrelite: add OV5642 and OV5640 camera sensors

Enables the OV5642 parallel-bus sensor, and the OV5640 MIPI CSI-2 sensor. Both hang off the same i2c2 bus, so they require different (and non- default) i2c slave addresses. The OV5642 connects to the parallel-bus mux input port on ipu1_csi0_mux. The OV5640 connects to the input port on the MIPI

[PATCH v3 04/24] ARM: dts: imx6qdl: add media device

Signed-off-by: Steve Longerbeam --- arch/arm/boot/dts/imx6q.dtsi | 4 arch/arm/boot/dts/imx6qdl.dtsi | 8 2 files changed, 12 insertions(+) diff --git a/arch/arm/boot/dts/imx6q.dtsi b/arch/arm/boot/dts/imx6q.dtsi index 9b2ca32..8867e78 100644 --- a/arch/arm/boot/dts/imx6q.dtsi

[PATCH v3 05/24] ARM: dts: imx6qdl-sabrelite: remove erratum ERR006687 workaround

There is a pin conflict with GPIO_6. This pin functions as a power input pin to the OV5642 camera sensor, but ENET uses it as the h/w workaround for erratum ERR006687, to wake-up the ARM cores on normal RX and TX packet done events. So we need to remove the h/w workaround to support the OV5642.

[PATCH v3 09/24] ARM: dts: imx6-sabreauto: add reset-gpios property for max7310_b

The reset pin to the port expander chip (MAX7310) is controlled by a gpio, so define a reset-gpios property to control it. There are three MAX7310's on the SabreAuto CPU card (max7310_[abc]), but all use the same pin for their reset. Since all can't acquire the same pin, assign it to max7310_b,

[PATCH v3 07/24] ARM: dts: imx6-sabresd: add OV5642 and OV5640 camera sensors

Enables the OV5642 parallel-bus sensor, and the OV5640 MIPI CSI-2 sensor. The OV5642 connects to the parallel-bus mux input port on ipu1_csi0_mux. The OV5640 connects to the input port on the MIPI CSI-2 receiver on mipi_csi. It is set to transmit over MIPI virtual channel 1. Until the OV5652

[PATCH v3 01/24] [media] dt-bindings: Add bindings for i.MX media driver

Add bindings documentation for the i.MX media driver. Signed-off-by: Steve Longerbeam --- Documentation/devicetree/bindings/media/imx.txt | 57 + 1 file changed, 57 insertions(+) create mode 100644

[PATCH v3 01/24] [media] dt-bindings: Add bindings for i.MX media driver

Add bindings documentation for the i.MX media driver. Signed-off-by: Steve Longerbeam --- Documentation/devicetree/bindings/media/imx.txt | 57 + 1 file changed, 57 insertions(+) create mode 100644 Documentation/devicetree/bindings/media/imx.txt diff --git

Re: [PATCH 4.4 00/58] 4.4.41-stable review

On 01/06/2017 02:43 PM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.4.41 release. > There are 58 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses

Re: [PATCH 4.4 00/58] 4.4.41-stable review

On 01/06/2017 02:43 PM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.4.41 release. > There are 58 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses

Re: [PATCH 4.9 000/116] 4.9.2-stable review

On 01/06/2017 02:42 PM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.9.2 release. > There are 116 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses

Re: [PATCH 4.9 000/116] 4.9.2-stable review

On 01/06/2017 02:42 PM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.9.2 release. > There are 116 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses

Re: [PATCH 4.8 00/96] 4.8.17-stable review

On 01/06/2017 02:42 PM, Greg Kroah-Hartman wrote: > > NOTE: This is the LAST 4.8-stable kernel to be released. After this, it > should be end-of-life. Please move to the 4.9-stable tree at this point > in time. > > > This

Re: [PATCH 4.8 00/96] 4.8.17-stable review

On 01/06/2017 02:42 PM, Greg Kroah-Hartman wrote: > > NOTE: This is the LAST 4.8-stable kernel to be released. After this, it > should be end-of-life. Please move to the 4.9-stable tree at this point > in time. > > > This

Re: [PATCH perf/core 3/3] perf-probe: Fix to probe on gcc generated functions in modules

On Fri, 6 Jan 2017 15:17:11 -0300 Arnaldo Carvalho de Melo wrote: > Em Sat, Jan 07, 2017 at 01:22:23AM +0900, Masami Hiramatsu escreveu: > > On Thu, 5 Jan 2017 15:47:43 -0300 > > Arnaldo Carvalho de Melo wrote: > > > Em Thu, Jan 05, 2017 at 12:30:37PM -0300,

Re: [PATCH perf/core 3/3] perf-probe: Fix to probe on gcc generated functions in modules

On Fri, 6 Jan 2017 15:17:11 -0300 Arnaldo Carvalho de Melo wrote: > Em Sat, Jan 07, 2017 at 01:22:23AM +0900, Masami Hiramatsu escreveu: > > On Thu, 5 Jan 2017 15:47:43 -0300 > > Arnaldo Carvalho de Melo wrote: > > > Em Thu, Jan 05, 2017 at 12:30:37PM -0300, Arnaldo Carvalho de Melo > > >

Re: [PATCH v3 1/2] backlight arcxcnn add support for ArcticSand devices

On Fri, 2017-01-06 at 15:48 -0500, Olimpiu Dejeu wrote: > backlight: Add support for Arctic Sand LED backlight driver chips > This driver provides support for the Arctic Sand arc2c0608 chip, > and provides a framework to support future devices. style trivia: > diff --git

Re: [PATCH v3 1/2] backlight arcxcnn add support for ArcticSand devices

On Fri, 2017-01-06 at 15:48 -0500, Olimpiu Dejeu wrote: > backlight: Add support for Arctic Sand LED backlight driver chips > This driver provides support for the Arctic Sand arc2c0608 chip, > and provides a framework to support future devices. style trivia: > diff --git

Re: [PATCH V7 1/4] Documentation/devicetree/bindings: b850v3_lvds_dp

On 04 January, 2017 21:39 CET, Rob Herring wrote: > On Tue, Jan 3, 2017 at 5:34 PM, Peter Senna Tschudin > wrote: > > Hi Rob, > > > > Thank you for the review. > > > > On 03 January, 2017 23:51 CET, Rob Herring wrote: > > > >>

Re: [PATCH V7 1/4] Documentation/devicetree/bindings: b850v3_lvds_dp

On 04 January, 2017 21:39 CET, Rob Herring wrote: > On Tue, Jan 3, 2017 at 5:34 PM, Peter Senna Tschudin > wrote: > > Hi Rob, > > > > Thank you for the review. > > > > On 03 January, 2017 23:51 CET, Rob Herring wrote: > > > >> On Sun, Jan 01, 2017 at 09:24:29PM +0100, Peter Senna Tschudin

[PATCH v5] net: stmmac: fix maxmtu assignment to be within valid range

From: "Kweh, Hock Leong" There is no checking valid value of maxmtu when getting it from device tree. This resolution added the checking condition to ensure the assignment is made within a valid range. Signed-off-by: Kweh, Hock Leong ---

[PATCH v5] net: stmmac: fix maxmtu assignment to be within valid range

From: "Kweh, Hock Leong" There is no checking valid value of maxmtu when getting it from device tree. This resolution added the checking condition to ensure the assignment is made within a valid range. Signed-off-by: Kweh, Hock Leong --- changelog v5: * revert back that plat->maxmtu >

Re: [PATCH] i2c: core: helper function to detect slave mode

On 01/07/2017 02:19 AM, Andy Shevchenko wrote: > On Sat, Jan 7, 2017 at 1:43 AM, Vladimir Zapolskiy wrote: >> On 01/07/2017 12:45 AM, Andy Shevchenko wrote: >>> On Fri, Jan 6, 2017 at 11:46 PM, Vladimir Zapolskiy wrote: > + if (IS_BUILTIN(CONFIG_OF) &&

Re: [PATCH] i2c: core: helper function to detect slave mode

On 01/07/2017 02:19 AM, Andy Shevchenko wrote: > On Sat, Jan 7, 2017 at 1:43 AM, Vladimir Zapolskiy wrote: >> On 01/07/2017 12:45 AM, Andy Shevchenko wrote: >>> On Fri, Jan 6, 2017 at 11:46 PM, Vladimir Zapolskiy wrote: > + if (IS_BUILTIN(CONFIG_OF) && dev->of_node) {

Re: [PATCH 1/5] ARM: dts: qcom: apq8064: Add missing scm clock

On Wed, Dec 21, 2016 at 3:49 AM, Bjorn Andersson wrote: > As per the device tree binding the apq8064 scm node requires the core > clock to be specified, so add this. > > Cc: John Stultz > Signed-off-by: Bjorn Andersson

Re: [PATCH 1/5] ARM: dts: qcom: apq8064: Add missing scm clock

On Wed, Dec 21, 2016 at 3:49 AM, Bjorn Andersson wrote: > As per the device tree binding the apq8064 scm node requires the core > clock to be specified, so add this. > > Cc: John Stultz > Signed-off-by: Bjorn Andersson > --- > arch/arm/boot/dts/qcom-apq8064.dtsi | 3 +++ > 1 file changed, 3

Re: [PATCH] xen: do not re-use pirq number cached in pci device msi msg data

On Thu, Jan 05, 2017 at 02:28:56PM -0500, Dan Streetman wrote: > Do not read a pci device's msi message data to see if a pirq was > previously configured for the device's msi/msix, as the old pirq was > unmapped and may now be in use by another pci device. The previous > pirq should never be

Re: [PATCH 2/5] ARM: dts: qcom: apq8064: Add riva-pil node

On Wed, Dec 21, 2016 at 3:49 AM, Bjorn Andersson wrote: > Add nodes for the Riva PIL, IRIS RF module, BT and WiFI services exposed > by the Riva firmware and the related memory reserve. > > Also provides pinctrl nodes for devices enabling the riva-pil. > > Cc: John

Re: [PATCH] xen: do not re-use pirq number cached in pci device msi msg data

On Thu, Jan 05, 2017 at 02:28:56PM -0500, Dan Streetman wrote: > Do not read a pci device's msi message data to see if a pirq was > previously configured for the device's msi/msix, as the old pirq was > unmapped and may now be in use by another pci device. The previous > pirq should never be

Re: [PATCH 2/5] ARM: dts: qcom: apq8064: Add riva-pil node

On Wed, Dec 21, 2016 at 3:49 AM, Bjorn Andersson wrote: > Add nodes for the Riva PIL, IRIS RF module, BT and WiFI services exposed > by the Riva firmware and the related memory reserve. > > Also provides pinctrl nodes for devices enabling the riva-pil. > > Cc: John Stultz > Signed-off-by: Bjorn

[RFC PATCH v2 2/2] block: fix blk_get_backing_dev_info() crash, use bdev->bd_queue

The ->bd_queue member of struct block_device was added in commit 87192a2a49c4 ("vfs: cache request_queue in struct block_device") in v3.3. However, blk_get_backing_dev_info() has been using bdev_get_queue() and grabbing the request_queue through the gendisk since before the git era. At final

[RFC PATCH v2 2/2] block: fix blk_get_backing_dev_info() crash, use bdev->bd_queue

The ->bd_queue member of struct block_device was added in commit 87192a2a49c4 ("vfs: cache request_queue in struct block_device") in v3.3. However, blk_get_backing_dev_info() has been using bdev_get_queue() and grabbing the request_queue through the gendisk since before the git era. At final

[RFC PATCH v2 0/2] block: fix backing_dev_info lifetime

v1 of these changes [1] was a one line change to bdev_get_queue() to prevent a shutdown crash when del_gendisk() races the final __blkdev_put(). While it is known at del_gendisk() time that the queue is still alive, Jan Kara points to other paths [2] that are racing __blkdev_put() where the

[RFC PATCH v2 1/2] block: fix lifetime of request_queue / backing_dev_info relative to bdev

By definition the lifetime of a struct block_device is equal to the lifetime of its corresponding inode since they both live in struct bdev_inode. Up until the inode is destroyed it may be the target of delayed write-back requests. Issuing write-back to a block_device requires a lookup of the bdev

[RFC PATCH v2 1/2] block: fix lifetime of request_queue / backing_dev_info relative to bdev

By definition the lifetime of a struct block_device is equal to the lifetime of its corresponding inode since they both live in struct bdev_inode. Up until the inode is destroyed it may be the target of delayed write-back requests. Issuing write-back to a block_device requires a lookup of the bdev

[RFC PATCH v2 0/2] block: fix backing_dev_info lifetime

v1 of these changes [1] was a one line change to bdev_get_queue() to prevent a shutdown crash when del_gendisk() races the final __blkdev_put(). While it is known at del_gendisk() time that the queue is still alive, Jan Kara points to other paths [2] that are racing __blkdev_put() where the

Re: [PATCH v2 1/4] timekeeping: export do_adjtimex() to modules

On Wed, Jan 4, 2017 at 9:24 AM, Vitaly Kuznetsov wrote: > While do_adjtimex() is available to userspace via adjtimex syscall it is > not available to modules which may want to implement in-kernel 'NTP > clients'. Hyper-V hv_utils is going to be the first one. > >

Re: [PATCH v2 1/4] timekeeping: export do_adjtimex() to modules

On Wed, Jan 4, 2017 at 9:24 AM, Vitaly Kuznetsov wrote: > While do_adjtimex() is available to userspace via adjtimex syscall it is > not available to modules which may want to implement in-kernel 'NTP > clients'. Hyper-V hv_utils is going to be the first one. > > Signed-off-by: Vitaly Kuznetsov

Re: [PATCH v2 2/4] hv_util: switch to using timespec64

On Wed, Jan 4, 2017 at 9:24 AM, Vitaly Kuznetsov wrote: > do_settimeofday() is deprecated, use do_settimeofday64() instead. > > Signed-off-by: Vitaly Kuznetsov Looks sane. Acked-by: John Stultz thanks -john

Re: [PATCH v2 2/4] hv_util: switch to using timespec64

On Wed, Jan 4, 2017 at 9:24 AM, Vitaly Kuznetsov wrote: > do_settimeofday() is deprecated, use do_settimeofday64() instead. > > Signed-off-by: Vitaly Kuznetsov Looks sane. Acked-by: John Stultz thanks -john

Re: [PATCH v2 4/4] hv_util: improve time adjustment accuracy by disabling interrupts

On Wed, Jan 4, 2017 at 9:24 AM, Vitaly Kuznetsov wrote: > If we happen to receive interrupts during hv_set_host_time() execution > our adjustments may get inaccurate. Make the whole function atomic. > Unfortunately, we can's call do_settimeofday64() with interrupts > disabled

Re: [PATCH v2 4/4] hv_util: improve time adjustment accuracy by disabling interrupts

On Wed, Jan 4, 2017 at 9:24 AM, Vitaly Kuznetsov wrote: > If we happen to receive interrupts during hv_set_host_time() execution > our adjustments may get inaccurate. Make the whole function atomic. > Unfortunately, we can's call do_settimeofday64() with interrupts > disabled as some cross-CPU

Re: [PATCH] platform/x86: fujitsu-laptop: rework logolamp_set() to properly handle errors

On Fri, Jan 06, 2017 at 08:24:31PM +0100, Micha?? K??pie?? wrote: > > On Thu, Jan 5, 2017 at 3:11 PM, Micha?? K??pie?? wrote: > > > Potential errors returned by some call_fext_func() calls inside > > > logolamp_set() are currently ignored. Rework logolamp_set() to properly > >

Re: [PATCH] platform/x86: fujitsu-laptop: rework logolamp_set() to properly handle errors

On Fri, Jan 06, 2017 at 08:24:31PM +0100, Micha?? K??pie?? wrote: > > On Thu, Jan 5, 2017 at 3:11 PM, Micha?? K??pie?? wrote: > > > Potential errors returned by some call_fext_func() calls inside > > > logolamp_set() are currently ignored. Rework logolamp_set() to properly > > > handle them.

Re: [PATCH v2 3/4] hv_util: use do_adjtimex() to update system time

On Wed, Jan 4, 2017 at 9:24 AM, Vitaly Kuznetsov wrote: > With TimeSync version 4 protocol support we started updating system time > continuously through the whole lifetime of Hyper-V guests. Every 5 seconds > there is a time sample from the host which triggers

Re: [PATCH v2 3/4] hv_util: use do_adjtimex() to update system time

On Wed, Jan 4, 2017 at 9:24 AM, Vitaly Kuznetsov wrote: > With TimeSync version 4 protocol support we started updating system time > continuously through the whole lifetime of Hyper-V guests. Every 5 seconds > there is a time sample from the host which triggers do_settimeofday[64](). > While the

RE: [PATCH v3] net: stmmac: fix maxmtu assignment to be within valid range

> -Original Message- > From: Andy Shevchenko [mailto:andy.shevche...@gmail.com] > Sent: Saturday, January 07, 2017 8:07 AM > To: Kweh, Hock Leong > Cc: David S. Miller ; Joao Pinto > ; Giuseppe CAVALLARO

RE: [PATCH v3] net: stmmac: fix maxmtu assignment to be within valid range

> -Original Message- > From: Andy Shevchenko [mailto:andy.shevche...@gmail.com] > Sent: Saturday, January 07, 2017 8:07 AM > To: Kweh, Hock Leong > Cc: David S. Miller ; Joao Pinto > ; Giuseppe CAVALLARO ; > seraphin.bonna...@st.com; Jarod Wilson ; Alexandre > TORGUE ; Joachim Eastwood >

Re: [PATCH] ssb: main.c: This patch removes unnecessary return statement using spatch tool

Hi Rahul, On Sat, Jan 7, 2017 at 2:20 AM, Rahul Krishnan wrote: > This patch removes unnecessary return statement using spatch. This doesn't describe the patch. > Signed-off-by: Rahul Krishnan > --- > drivers/ssb/main.c | 6 ++ > 1

Re: [PATCH] ssb: main.c: This patch removes unnecessary return statement using spatch tool

Hi Rahul, On Sat, Jan 7, 2017 at 2:20 AM, Rahul Krishnan wrote: > This patch removes unnecessary return statement using spatch. This doesn't describe the patch. > Signed-off-by: Rahul Krishnan > --- > drivers/ssb/main.c | 6 ++ > 1 file changed, 2 insertions(+), 4 deletions(-) > > diff

Re: [PATCH v3 1/3] timekeeping: Add a fast and NMI safe boot clock

On Thu, Nov 24, 2016 at 12:20 PM, Joel Fernandes wrote: > This boot clock can be used as a tracing clock and will account for > suspend time. > > To keep it NMI safe since we're accessing from tracing, we're not using a > separate timekeeper with updates to monotonic clock and

Re: [PATCH v3 1/3] timekeeping: Add a fast and NMI safe boot clock

On Thu, Nov 24, 2016 at 12:20 PM, Joel Fernandes wrote: > This boot clock can be used as a tracing clock and will account for > suspend time. > > To keep it NMI safe since we're accessing from tracing, we're not using a > separate timekeeper with updates to monotonic clock and boot offset >

Re: [PATCH] clk: scpi: don't add cpufreq device if the scpi dvfs node is disabled

seems the patch works as intended. W dniu 06.01.2017 o 13:34, Sudeep Holla pisze: > Currently we add the virtual cpufreq device unconditionally even when > the SCPI DVFS clock provider node is disabled. This will cause cpufreq > driver to throw errors when it gets initailised on boot/modprobe and

Re: [PATCH] clk: scpi: don't add cpufreq device if the scpi dvfs node is disabled

seems the patch works as intended. W dniu 06.01.2017 o 13:34, Sudeep Holla pisze: > Currently we add the virtual cpufreq device unconditionally even when > the SCPI DVFS clock provider node is disabled. This will cause cpufreq > driver to throw errors when it gets initailised on boot/modprobe and

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