Re: rtlwifi: rtl8192c_common: "BUG: KASAN: slab-out-of-bounds"

Am Montag, 6. Februar 2017, 09:45:31 CET schrieb Larry Finger: > On 02/06/2017 04:29 AM, Johannes Berg wrote: > > On Sat, 2017-02-04 at 12:41 -0600, Larry Finger wrote: > >> On 02/04/2017 10:58 AM, Dmitry Osipenko wrote: > >>> Seems the problem is caused by rtl92c_dm_*() casting .priv to > >>>

Re: rtlwifi: rtl8192c_common: "BUG: KASAN: slab-out-of-bounds"

Am Montag, 6. Februar 2017, 09:45:31 CET schrieb Larry Finger: > On 02/06/2017 04:29 AM, Johannes Berg wrote: > > On Sat, 2017-02-04 at 12:41 -0600, Larry Finger wrote: > >> On 02/04/2017 10:58 AM, Dmitry Osipenko wrote: > >>> Seems the problem is caused by rtl92c_dm_*() casting .priv to > >>>

Re: [PATCH] iio: cros_ec: Add cros_ec barometer driver

On Tue, 24 Jan 2017, Enric Balletbo i Serra wrote: > From: Gwendal Grignou > > Handle the barometer sensor presented by the ChromeOS EC Sensor hub. > > Signed-off-by: Gwendal Grignou > Signed-off-by: Enric Balletbo Serra

Re: [PATCH] iio: cros_ec: Add cros_ec barometer driver

On Tue, 24 Jan 2017, Enric Balletbo i Serra wrote: > From: Gwendal Grignou > > Handle the barometer sensor presented by the ChromeOS EC Sensor hub. > > Signed-off-by: Gwendal Grignou > Signed-off-by: Enric Balletbo Serra > --- > drivers/iio/pressure/Kconfig | 10 ++ >

Re: mm: deadlock between get_online_cpus/pcpu_alloc

On Tue, 7 Feb 2017, Michal Hocko wrote: > I am always nervous when seeing hotplug locks being used in low level > code. It has bitten us several times already and those deadlocks are > quite hard to spot when reviewing the code and very rare to hit so they > tend to live for a long time. Yep.

Re: mm: deadlock between get_online_cpus/pcpu_alloc

On Tue, 7 Feb 2017, Michal Hocko wrote: > I am always nervous when seeing hotplug locks being used in low level > code. It has bitten us several times already and those deadlocks are > quite hard to spot when reviewing the code and very rare to hit so they > tend to live for a long time. Yep.

[PATCH] gpio: pci-idio-16: Fix PCI device ID code

The ACCES PCI-IDIO-16 has a PCI device ID code of 0x0DC8. It is incorrect to use the PCI device ID code of the ACCES PCI-IIRO-8 (0x0F00). This patch fixes the said PCI device ID code mismatch. Fixes: 02e74fc0401a ("gpio: Add GPIO support for the ACCES PCI-IDIO-16") Signed-off-by: William

[PATCH] gpio: pci-idio-16: Fix PCI device ID code

The ACCES PCI-IDIO-16 has a PCI device ID code of 0x0DC8. It is incorrect to use the PCI device ID code of the ACCES PCI-IIRO-8 (0x0F00). This patch fixes the said PCI device ID code mismatch. Fixes: 02e74fc0401a ("gpio: Add GPIO support for the ACCES PCI-IDIO-16") Signed-off-by: William

[PATCH v3 1/2] drm: mali-dp: add malidp_crtc_state struct

Add a custom CRTC state struct to enable storing driver-private per-CRTC state. This patch only adds the base drm_crtc_state struct. Signed-off-by: Mihail Atanassov Reviewed-by: Brian Starkey Acked-by: Liviu Dudau --- Link

[PATCH v3 1/2] drm: mali-dp: add malidp_crtc_state struct

Add a custom CRTC state struct to enable storing driver-private per-CRTC state. This patch only adds the base drm_crtc_state struct. Signed-off-by: Mihail Atanassov Reviewed-by: Brian Starkey Acked-by: Liviu Dudau --- Link to v2: https://lkml.org/lkml/2017/2/1/378 Link to v1:

[PATCH v3 2/2] drm: mali-dp: enable gamma support

Add gamma via the DRM GAMMA_LUT/GAMMA_LUT_SIZE CRTC properties. The expected LUT size is 4096 in order to produce as accurate a set of segments as possible. This version uses only the green channel's gamma curve to set the hardware curve on DP550/650. For the sake of simplicity, it uses the same

[PATCH v3 2/2] drm: mali-dp: enable gamma support

Add gamma via the DRM GAMMA_LUT/GAMMA_LUT_SIZE CRTC properties. The expected LUT size is 4096 in order to produce as accurate a set of segments as possible. This version uses only the green channel's gamma curve to set the hardware curve on DP550/650. For the sake of simplicity, it uses the same

Re: [PATCH 11/14] serial: 8250_dw: simplify optional reset handling

On Fri, 2017-02-03 at 00:21 +0200, Andy Shevchenko wrote: > On Mon, Jan 30, 2017 at 1:41 PM, Philipp Zabel wrote: > > As of commit bb475230b8e5 ("reset: make optional functions really > > optional"), the reset framework API calls use NULL pointers to describe > > optional,

Re: [PATCH 11/14] serial: 8250_dw: simplify optional reset handling

On Fri, 2017-02-03 at 00:21 +0200, Andy Shevchenko wrote: > On Mon, Jan 30, 2017 at 1:41 PM, Philipp Zabel wrote: > > As of commit bb475230b8e5 ("reset: make optional functions really > > optional"), the reset framework API calls use NULL pointers to describe > > optional, non-present reset

Re: [PATCH 11/14] serial: 8250_dw: simplify optional reset handling

On Fri, 2017-02-03 at 00:21 +0200, Andy Shevchenko wrote: > On Mon, Jan 30, 2017 at 1:41 PM, Philipp Zabel wrote: > > As of commit bb475230b8e5 ("reset: make optional functions really > > optional"), the reset framework API calls use NULL pointers to describe > > optional,

Re: [PATCH 11/14] serial: 8250_dw: simplify optional reset handling

On Fri, 2017-02-03 at 00:21 +0200, Andy Shevchenko wrote: > On Mon, Jan 30, 2017 at 1:41 PM, Philipp Zabel wrote: > > As of commit bb475230b8e5 ("reset: make optional functions really > > optional"), the reset framework API calls use NULL pointers to describe > > optional, non-present reset

Re: [PATCH 0/2] drm/panel: Add support for the Sitronix ST7789V

On Tue, Feb 07, 2017 at 04:34:44PM +0100, Maxime Ripard wrote: > On Mon, Feb 06, 2017 at 12:29:31PM +0100, Noralf Trønnes wrote: > > > > Den 06.02.2017 11.39, skrev Maxime Ripard: > > > Hi Noralf, > > > > > > On Fri, Feb 03, 2017 at 07:48:51PM +0100, Noralf Trønnes wrote: > > > > Den 03.02.2017

Re: [PATCH 0/2] drm/panel: Add support for the Sitronix ST7789V

On Tue, Feb 07, 2017 at 04:34:44PM +0100, Maxime Ripard wrote: > On Mon, Feb 06, 2017 at 12:29:31PM +0100, Noralf Trønnes wrote: > > > > Den 06.02.2017 11.39, skrev Maxime Ripard: > > > Hi Noralf, > > > > > > On Fri, Feb 03, 2017 at 07:48:51PM +0100, Noralf Trønnes wrote: > > > > Den 03.02.2017

Re: [net-next PATCH 0/4] Documenting eBPF - extended Berkeley Packet Filter

On Tue, 7 Feb 2017 17:09:08 +0100 Jesper Dangaard Brouer wrote: > > > Question: What kernel tree should this go into??? > > > > > > If going through Jonathan Corbet, will it appear sooner here??? > > > https://www.kernel.org/doc/html/latest/ > > What about this question?

Re: [net-next PATCH 0/4] Documenting eBPF - extended Berkeley Packet Filter

On Tue, 7 Feb 2017 17:09:08 +0100 Jesper Dangaard Brouer wrote: > > > Question: What kernel tree should this go into??? > > > > > > If going through Jonathan Corbet, will it appear sooner here??? > > > https://www.kernel.org/doc/html/latest/ > > What about this question? Or let me ask in

[PATCH 01/10] media: dt-bindings: vpif: fix whitespace errors

Signed-off-by: Bartosz Golaszewski --- Documentation/devicetree/bindings/media/ti,da850-vpif.txt | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/Documentation/devicetree/bindings/media/ti,da850-vpif.txt

[PATCH 01/10] media: dt-bindings: vpif: fix whitespace errors

Signed-off-by: Bartosz Golaszewski --- Documentation/devicetree/bindings/media/ti,da850-vpif.txt | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/Documentation/devicetree/bindings/media/ti,da850-vpif.txt b/Documentation/devicetree/bindings/media/ti,da850-vpif.txt

[PATCH 02/10] ARM: dts: da850-evm: fix whitespace errors

Signed-off-by: Bartosz Golaszewski --- arch/arm/boot/dts/da850-evm.dts | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/arch/arm/boot/dts/da850-evm.dts b/arch/arm/boot/dts/da850-evm.dts index c970b6e..94938a3 100644 ---

[PATCH 02/10] ARM: dts: da850-evm: fix whitespace errors

Signed-off-by: Bartosz Golaszewski --- arch/arm/boot/dts/da850-evm.dts | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/arch/arm/boot/dts/da850-evm.dts b/arch/arm/boot/dts/da850-evm.dts index c970b6e..94938a3 100644 --- a/arch/arm/boot/dts/da850-evm.dts +++

[PATCH 03/10] media: dt-bindings: vpif: extend the example with an output port

This makes the example more or less correspond with the da850-evm hardware setup. Signed-off-by: Bartosz Golaszewski --- .../devicetree/bindings/media/ti,da850-vpif.txt| 35 ++ 1 file changed, 29 insertions(+), 6 deletions(-) diff --git

[PATCH 03/10] media: dt-bindings: vpif: extend the example with an output port

This makes the example more or less correspond with the da850-evm hardware setup. Signed-off-by: Bartosz Golaszewski --- .../devicetree/bindings/media/ti,da850-vpif.txt| 35 ++ 1 file changed, 29 insertions(+), 6 deletions(-) diff --git

[PATCH] nohz: Fix possible missing clock reprog after tick soft restart

ts->next_tick keeps track of the next tick deadline in order to optimize clock programmation on irq exit and avoid redundant clock device writes. Now if ts->next_tick missed an update, we may spuriously miss a clock reprog later as the nohz code is fooled by an obsolete next_tick value. This is

[PATCH] nohz: Fix possible missing clock reprog after tick soft restart

ts->next_tick keeps track of the next tick deadline in order to optimize clock programmation on irq exit and avoid redundant clock device writes. Now if ts->next_tick missed an update, we may spuriously miss a clock reprog later as the nohz code is fooled by an obsolete next_tick value. This is

Re: [PATCH] [net-next] mlxsw: add psample dependency for spectrum

From: Arnd Bergmann Date: Mon, 6 Feb 2017 17:26:30 +0100 > When PSAMPLE is a loadable module, spectrum must not be built-in: > > drivers/net/built-in.o: In function `mlxsw_sp_rx_listener_sample_func': > spectrum.c:(.text+0xe357e): undefined reference to `psample_sample_packet' >

Re: [PATCH] [net-next] mlxsw: add psample dependency for spectrum

From: Arnd Bergmann Date: Mon, 6 Feb 2017 17:26:30 +0100 > When PSAMPLE is a loadable module, spectrum must not be built-in: > > drivers/net/built-in.o: In function `mlxsw_sp_rx_listener_sample_func': > spectrum.c:(.text+0xe357e): undefined reference to `psample_sample_packet' > > This adds a

[PATCH 06/10] ARM: davinci_all_defconfig: enable VPIF display modules

Enable the VPIF display module and the video encoder present on the da850-evm UI board. Signed-off-by: Bartosz Golaszewski --- arch/arm/configs/davinci_all_defconfig | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm/configs/davinci_all_defconfig

[PATCH 06/10] ARM: davinci_all_defconfig: enable VPIF display modules

Enable the VPIF display module and the video encoder present on the da850-evm UI board. Signed-off-by: Bartosz Golaszewski --- arch/arm/configs/davinci_all_defconfig | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm/configs/davinci_all_defconfig

Re: [net-next PATCH 0/4] Documenting eBPF - extended Berkeley Packet Filter

Hi Jesper, On 02/07/2017 03:30 PM, Jesper Dangaard Brouer wrote: Question: What kernel tree should this go into??? If going through Jonathan Corbet, will it appear sooner here??? https://www.kernel.org/doc/html/latest/ If it will not appear sooner that way, then it's likely best to keep it

Re: [net-next PATCH 0/4] Documenting eBPF - extended Berkeley Packet Filter

Hi Jesper, On 02/07/2017 03:30 PM, Jesper Dangaard Brouer wrote: Question: What kernel tree should this go into??? If going through Jonathan Corbet, will it appear sooner here??? https://www.kernel.org/doc/html/latest/ If it will not appear sooner that way, then it's likely best to keep it

Re: [PATCH 1/2] dt-bindings: display: panel: Add bindings for the Sitronix ST7789V panel

On Tue, Feb 07, 2017 at 04:44:42PM +0100, Maxime Ripard wrote: > Hi Thierry, > > On Mon, Feb 06, 2017 at 02:05:49PM +0100, Thierry Reding wrote: > > On Fri, Feb 03, 2017 at 10:59:05AM +0100, Maxime Ripard wrote: > > > The Sitronix ST7789V is an LCD panel controller, controlled over SPI, that > >

Re: [PATCH 1/2] dt-bindings: display: panel: Add bindings for the Sitronix ST7789V panel

On Tue, Feb 07, 2017 at 04:44:42PM +0100, Maxime Ripard wrote: > Hi Thierry, > > On Mon, Feb 06, 2017 at 02:05:49PM +0100, Thierry Reding wrote: > > On Fri, Feb 03, 2017 at 10:59:05AM +0100, Maxime Ripard wrote: > > > The Sitronix ST7789V is an LCD panel controller, controlled over SPI, that > >

[PATCH 04/10] ARM: dts: da850-evm: add the output port to the vpif node

Extend the vpif node with an output port with a single channel. NOTE: this is still just hardware description - the actual driver is registered using pdata-quirks. Signed-off-by: Bartosz Golaszewski --- arch/arm/boot/dts/da850-evm.dts | 14 +++---

[PATCH 04/10] ARM: dts: da850-evm: add the output port to the vpif node

Extend the vpif node with an output port with a single channel. NOTE: this is still just hardware description - the actual driver is registered using pdata-quirks. Signed-off-by: Bartosz Golaszewski --- arch/arm/boot/dts/da850-evm.dts | 14 +++--- arch/arm/boot/dts/da850.dtsi| 8

[PATCH 10/10] ARM: davinci: add pdata-quirks for da850-evm vpif display

Similarly to vpif capture: we need to register the vpif display driver and the corresponding adv7343 encoder in pdata-quirks as the DT support is not complete. Signed-off-by: Bartosz Golaszewski --- arch/arm/mach-davinci/pdata-quirks.c | 86

[PATCH 10/10] ARM: davinci: add pdata-quirks for da850-evm vpif display

Similarly to vpif capture: we need to register the vpif display driver and the corresponding adv7343 encoder in pdata-quirks as the DT support is not complete. Signed-off-by: Bartosz Golaszewski --- arch/arm/mach-davinci/pdata-quirks.c | 86 +++- 1 file changed,

[PATCH 07/10] ARM: davinci: fix a whitespace error

There's a stray tab in da850_vpif_legacy_init(). Remove it. Signed-off-by: Bartosz Golaszewski --- arch/arm/mach-davinci/pdata-quirks.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/mach-davinci/pdata-quirks.c

[PATCH 07/10] ARM: davinci: fix a whitespace error

There's a stray tab in da850_vpif_legacy_init(). Remove it. Signed-off-by: Bartosz Golaszewski --- arch/arm/mach-davinci/pdata-quirks.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/mach-davinci/pdata-quirks.c b/arch/arm/mach-davinci/pdata-quirks.c index

[PATCH 08/10] ARM: davinci: fix the DT boot on da850-evm

When we enable vpif capture on the da850-evm we hit a BUG_ON() because the i2c adapter can't be found. The board file boot uses i2c adapter 1 but in the DT mode it's actually adapter 0. Drop the problematic lines. Signed-off-by: Bartosz Golaszewski ---

[PATCH 08/10] ARM: davinci: fix the DT boot on da850-evm

When we enable vpif capture on the da850-evm we hit a BUG_ON() because the i2c adapter can't be found. The board file boot uses i2c adapter 1 but in the DT mode it's actually adapter 0. Drop the problematic lines. Signed-off-by: Bartosz Golaszewski --- arch/arm/mach-davinci/pdata-quirks.c | 4

[PATCH 09/10] media: vpif: use a configurable i2c_adapter_id for vpif display

The vpif display driver uses a static i2c adapter ID of 1 but on the da850-evm board in DT boot mode the i2c adapter ID is actually 0. Make the adapter ID configurable like it already is for vpif capture. Signed-off-by: Bartosz Golaszewski ---

[PATCH 09/10] media: vpif: use a configurable i2c_adapter_id for vpif display

The vpif display driver uses a static i2c adapter ID of 1 but on the da850-evm board in DT boot mode the i2c adapter ID is actually 0. Make the adapter ID configurable like it already is for vpif capture. Signed-off-by: Bartosz Golaszewski --- arch/arm/mach-davinci/board-da850-evm.c | 1

[PATCH 05/10] ARM: dts: da850: add vpif video display pins

Add a new pinctrl sub-node for vpif display pins. Move VP_CLKIN3 and VP_CLKIN2 to the display node where they actually belong (vide section 35.2.2 of the da850 datasheet). Signed-off-by: Bartosz Golaszewski --- arch/arm/boot/dts/da850-evm.dts | 2 +-

[PATCH 00/10] ARM: davinci: add vpif display support

The following series adds support for v4l2 display on da850-evm with a UI board in device tree boot mode. Patches 1/10 - 5/10 deal with the device tree: we fix whitespace errors in dts files and bindings, extend the example and the dts for da850-evm with the output port and address the pinmuxing.

[PATCH 00/10] ARM: davinci: add vpif display support

The following series adds support for v4l2 display on da850-evm with a UI board in device tree boot mode. Patches 1/10 - 5/10 deal with the device tree: we fix whitespace errors in dts files and bindings, extend the example and the dts for da850-evm with the output port and address the pinmuxing.

[PATCH 05/10] ARM: dts: da850: add vpif video display pins

Add a new pinctrl sub-node for vpif display pins. Move VP_CLKIN3 and VP_CLKIN2 to the display node where they actually belong (vide section 35.2.2 of the da850 datasheet). Signed-off-by: Bartosz Golaszewski --- arch/arm/boot/dts/da850-evm.dts | 2 +- arch/arm/boot/dts/da850.dtsi| 17

Re: [PATCH v2 2/5] async_tx: Handle DMA devices having support for fewer PQ coefficients

On Tue, Feb 07, 2017 at 02:32:15PM +0530, Anup Patel wrote: > On Tue, Feb 7, 2017 at 1:57 PM, Dan Williams wrote: > > On Tue, Feb 7, 2017 at 12:16 AM, Anup Patel wrote: > >> The DMAENGINE framework assumes that if PQ offload is supported by a >

Re: [PATCH v2 2/5] async_tx: Handle DMA devices having support for fewer PQ coefficients

On Tue, Feb 07, 2017 at 02:32:15PM +0530, Anup Patel wrote: > On Tue, Feb 7, 2017 at 1:57 PM, Dan Williams wrote: > > On Tue, Feb 7, 2017 at 12:16 AM, Anup Patel wrote: > >> The DMAENGINE framework assumes that if PQ offload is supported by a > >> DMA device then all 256 PQ coefficients are

Re: mm: deadlock between get_online_cpus/pcpu_alloc

On Tue 07-02-17 16:22:24, Mel Gorman wrote: > On Tue, Feb 07, 2017 at 04:34:59PM +0100, Michal Hocko wrote: > > > But we do not care about the whole cpu hotplug code. The only part we > > > really do care about is the race inside drain_pages_zone and that will > > > run in an atomic context on the

Re: mm: deadlock between get_online_cpus/pcpu_alloc

On Tue 07-02-17 16:22:24, Mel Gorman wrote: > On Tue, Feb 07, 2017 at 04:34:59PM +0100, Michal Hocko wrote: > > > But we do not care about the whole cpu hotplug code. The only part we > > > really do care about is the race inside drain_pages_zone and that will > > > run in an atomic context on the

Re: [PATCH] Mfd - Fix possible NULL derefrence.

On Fri, 27 Jan 2017, Shailendra Verma wrote: > of_match_device could return NULL, and so can cause a NULL > pointer dereference later. I don't think it can. Did this actually happen to you? > Signed-off-by: Shailendra Verma > --- > drivers/mfd/mc13xxx-i2c.c |4

Re: [PATCH] Mfd - Fix possible NULL derefrence.

On Fri, 27 Jan 2017, Shailendra Verma wrote: > of_match_device could return NULL, and so can cause a NULL > pointer dereference later. I don't think it can. Did this actually happen to you? > Signed-off-by: Shailendra Verma > --- > drivers/mfd/mc13xxx-i2c.c |4 >

Re: [PATCH v3 03/14] mm: use pmd lock instead of racy checks in zap_pmd_range()

On Tue, Feb 07, 2017 at 09:11:05AM -0600, Zi Yan wrote: > >> This causes memory leak or kernel crashing, if VM_BUG_ON() is enabled. > > > > The problem is that numabalancing calls change_huge_pmd() under > > down_read(mmap_sem), not down_write(mmap_sem) as the rest of users do. > > It makes

Re: [PATCH v3 03/14] mm: use pmd lock instead of racy checks in zap_pmd_range()

On Tue, Feb 07, 2017 at 09:11:05AM -0600, Zi Yan wrote: > >> This causes memory leak or kernel crashing, if VM_BUG_ON() is enabled. > > > > The problem is that numabalancing calls change_huge_pmd() under > > down_read(mmap_sem), not down_write(mmap_sem) as the rest of users do. > > It makes

Re: [RFC 1/1] shiftfs: uid/gid shifting bind mount

On Tue, 2017-02-07 at 01:19 -0800, Christoph Hellwig wrote: > On Sat, Feb 04, 2017 at 11:19:32AM -0800, James Bottomley wrote: > > This allows any subtree to be uid/gid shifted and bound elsewhere. > > It does this by operating simlarly to overlayfs. Its primary use > > is for shifting the

Re: [RFC 1/1] shiftfs: uid/gid shifting bind mount

On Tue, 2017-02-07 at 01:19 -0800, Christoph Hellwig wrote: > On Sat, Feb 04, 2017 at 11:19:32AM -0800, James Bottomley wrote: > > This allows any subtree to be uid/gid shifted and bound elsewhere. > > It does this by operating simlarly to overlayfs. Its primary use > > is for shifting the

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

Jingoo, Are you still maintaining Backlight, or did you get bored? > 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. > Signed-off-by: Olimpiu Dejeu

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

Jingoo, Are you still maintaining Backlight, or did you get bored? > 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. > Signed-off-by: Olimpiu Dejeu >

Re: drivers/net/wireless/broadcom/brcm80211/brcmfmac/debug.c:58:6: error: redefinition of 'brcmf_debugfs_init'

On 02/07/17 02:02, kbuild test robot wrote: > Hi Kalle, > > FYI, the error/warning still remains. > > tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git > master > head: 8b1b41ee74f9712c355d66dc105bbea663ae0afd > commit: 05491d2ccf20b20a1375303441fbbfbd12b24a4f

Re: drivers/net/wireless/broadcom/brcm80211/brcmfmac/debug.c:58:6: error: redefinition of 'brcmf_debugfs_init'

On 02/07/17 02:02, kbuild test robot wrote: > Hi Kalle, > > FYI, the error/warning still remains. > > tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git > master > head: 8b1b41ee74f9712c355d66dc105bbea663ae0afd > commit: 05491d2ccf20b20a1375303441fbbfbd12b24a4f

Re: [PATCH] mfd: Add support for several boards to Kontron PLD driver

On Thu, 26 Jan 2017, Michael Brunner wrote: > This patch adds the DMI system ID of the Kontron COMe-bBD#, COMe-bKL6, > COMe-cKL6, COMe-bSL6 and COMe-cAL6 boards to the Kontron PLD driver. The > list of supported products in the module description is also updated. > > Signed-off-by: Michael

Re: [PATCH] mfd: Add support for several boards to Kontron PLD driver

On Thu, 26 Jan 2017, Michael Brunner wrote: > This patch adds the DMI system ID of the Kontron COMe-bBD#, COMe-bKL6, > COMe-cKL6, COMe-bSL6 and COMe-cAL6 boards to the Kontron PLD driver. The > list of supported products in the module description is also updated. > > Signed-off-by: Michael

[PATCH v2 2/2] Input: synaptics-rmi4 - f30/f03: Forward mechanical buttons on buttonpads to PS/2 guest

On the latest series of ThinkPads, the button events for the TrackPoint are reported through the touchpad itself as opposed to the TrackPoint device. In order to report these buttons properly, we need to forward them to the TrackPoint device and notify psmouse to send the button presses/releases.

[PATCH v2 2/2] Input: synaptics-rmi4 - f30/f03: Forward mechanical buttons on buttonpads to PS/2 guest

On the latest series of ThinkPads, the button events for the TrackPoint are reported through the touchpad itself as opposed to the TrackPoint device. In order to report these buttons properly, we need to forward them to the TrackPoint device and notify psmouse to send the button presses/releases.

Re: [PATCH 03/10] Input: synaptics-rmi4 - f30/f03: Forward mechanical buttons on buttonpads to PS/2 guest

Hi Dmitry, On Feb 06 2017 or thereabouts, Dmitry Torokhov wrote: > Hi Benjamin, > > On Tue, Jan 10, 2017 at 05:11:21PM +0100, Benjamin Tissoires wrote: > > +void rmi_f03_commit_buttons(struct rmi_function *fn) > > +{ > > + struct f03_data *f03 = dev_get_drvdata(>dev); > > + int i; > > + > >

[PATCH v2 1/2] Input: psmouse - add a custom serio protocol to send extra information

The tracksticks on the Lenovo thinkpads have their buttons connected through the touchpad device. We already fixed that in synaptics.c, but when we switch the device into RMI4 mode to have proper support, the pass-through functionality can't deal with them easily. We add a new PS/2 flag and

Re: [PATCH 03/10] Input: synaptics-rmi4 - f30/f03: Forward mechanical buttons on buttonpads to PS/2 guest

Hi Dmitry, On Feb 06 2017 or thereabouts, Dmitry Torokhov wrote: > Hi Benjamin, > > On Tue, Jan 10, 2017 at 05:11:21PM +0100, Benjamin Tissoires wrote: > > +void rmi_f03_commit_buttons(struct rmi_function *fn) > > +{ > > + struct f03_data *f03 = dev_get_drvdata(>dev); > > + int i; > > + > >

[PATCH v2 1/2] Input: psmouse - add a custom serio protocol to send extra information

The tracksticks on the Lenovo thinkpads have their buttons connected through the touchpad device. We already fixed that in synaptics.c, but when we switch the device into RMI4 mode to have proper support, the pass-through functionality can't deal with them easily. We add a new PS/2 flag and

Re: [PATCH 1/2] drm/rockchip: support mode_valid for crtc

On Sun, Feb 05, 2017 at 03:36:36PM +0800, Mark Yao wrote: > drm crtc already has mode_fixup callback to can do mode check, but > We actually want to valid display mode on connector getmode time, > mode_fixup can't do it. > > So add a private mode_valid callback to rockchip crtc, connectors can >

Re: [PATCH 1/2] drm/rockchip: support mode_valid for crtc

On Sun, Feb 05, 2017 at 03:36:36PM +0800, Mark Yao wrote: > drm crtc already has mode_fixup callback to can do mode check, but > We actually want to valid display mode on connector getmode time, > mode_fixup can't do it. > > So add a private mode_valid callback to rockchip crtc, connectors can >

Re: [GIT PULL 2/4] soc: samsung: pmu for v4.11, third round

On Thursday, February 2, 2017 8:30:06 PM CET Krzysztof Kozlowski wrote: > 3rd round of improvements for Exynos PMU driver for v4.11: > 1. Add defines in header for future patches changing the pad >retention control. > Pulled into next/drivers, thanks! Arnd

Re: [GIT PULL 2/4] soc: samsung: pmu for v4.11, third round

On Thursday, February 2, 2017 8:30:06 PM CET Krzysztof Kozlowski wrote: > 3rd round of improvements for Exynos PMU driver for v4.11: > 1. Add defines in header for future patches changing the pad >retention control. > Pulled into next/drivers, thanks! Arnd

Re: mm: deadlock between get_online_cpus/pcpu_alloc

On Tue, Feb 07, 2017 at 04:34:59PM +0100, Michal Hocko wrote: > > But we do not care about the whole cpu hotplug code. The only part we > > really do care about is the race inside drain_pages_zone and that will > > run in an atomic context on the specific CPU. > > > > You are absolutely right

Re: mm: deadlock between get_online_cpus/pcpu_alloc

On Tue, Feb 07, 2017 at 04:34:59PM +0100, Michal Hocko wrote: > > But we do not care about the whole cpu hotplug code. The only part we > > really do care about is the race inside drain_pages_zone and that will > > run in an atomic context on the specific CPU. > > > > You are absolutely right

Re: [GIT PULL 1/4] soc: samsung: pm_domains for v4.11

On Thursday, February 2, 2017 8:30:05 PM CET Krzysztof Kozlowski wrote: > Improve the PM domains driver for Exynos by displaying a user-friendly name of > power domain. Till now, the name of node from DT was used which mostly is > just > "power-domain". We need more than that. > Pulled into

Re: [GIT PULL 1/4] soc: samsung: pm_domains for v4.11

On Thursday, February 2, 2017 8:30:05 PM CET Krzysztof Kozlowski wrote: > Improve the PM domains driver for Exynos by displaying a user-friendly name of > power domain. Till now, the name of node from DT was used which mostly is > just > "power-domain". We need more than that. > Pulled into

Re: [PATCH v2] PCI: pciehp: Don't enable PME on runtime suspend

On Tuesday, February 07, 2017 07:26:59 AM Lukas Wunner wrote: > On Mon, Feb 06, 2017 at 10:52:12PM +0100, Rafael J. Wysocki wrote: > > On Monday, February 06, 2017 10:20:41 PM Lukas Wunner wrote: > > > On Mon, Feb 06, 2017 at 11:54:05AM -0600, Bjorn Helgaas wrote: > > > > On Mon, Feb 06, 2017 at

Re: [PATCH v2] PCI: pciehp: Don't enable PME on runtime suspend

On Tuesday, February 07, 2017 07:26:59 AM Lukas Wunner wrote: > On Mon, Feb 06, 2017 at 10:52:12PM +0100, Rafael J. Wysocki wrote: > > On Monday, February 06, 2017 10:20:41 PM Lukas Wunner wrote: > > > On Mon, Feb 06, 2017 at 11:54:05AM -0600, Bjorn Helgaas wrote: > > > > On Mon, Feb 06, 2017 at

[PATCH] media: imx: csi: fix crop rectangle reset in sink set_fmt

The csi_try_crop call in set_fmt should compare the cropping rectangle to the currently set input format, not to the previous input format. Signed-off-by: Philipp Zabel --- This is a patch against the current imx-media-staging-md-wip branch. S_FMT wouldn't update the

[PATCH] media: imx: csi: fix crop rectangle reset in sink set_fmt

The csi_try_crop call in set_fmt should compare the cropping rectangle to the currently set input format, not to the previous input format. Signed-off-by: Philipp Zabel --- This is a patch against the current imx-media-staging-md-wip branch. S_FMT wouldn't update the cropping rectangle during

RE: [PATCH] PCI: hv: fix wslot_to_devfn()

> -Original Message- > From: Dexuan Cui > Sent: Tuesday, February 7, 2017 4:00 AM > To: Bjorn Helgaas ; linux-...@vger.kernel.org; > de...@linuxdriverproject.org; Jake Oshins > Cc: KY Srinivasan ; Stephen Hemminger >

RE: [PATCH] PCI: hv: fix wslot_to_devfn()

> -Original Message- > From: Dexuan Cui > Sent: Tuesday, February 7, 2017 4:00 AM > To: Bjorn Helgaas ; linux-...@vger.kernel.org; > de...@linuxdriverproject.org; Jake Oshins > Cc: KY Srinivasan ; Stephen Hemminger > ; Haiyang Zhang ; > o...@aepfle.de; gre...@linuxfoundation.org;

[PATCH 0/2] Disable the MSR T-state if it is enabled after resumed

Disable the MSR T-state if it is enabled after resumed back, because generally we don't expect the throttling to be enabled after resumed and should rely on other OS components to adjust the throttling state. Chen Yu (2): ACPI throttling: Disable the MSR T-state if enabled after resumed

[PATCH 0/2] Disable the MSR T-state if it is enabled after resumed

Disable the MSR T-state if it is enabled after resumed back, because generally we don't expect the throttling to be enabled after resumed and should rely on other OS components to adjust the throttling state. Chen Yu (2): ACPI throttling: Disable the MSR T-state if enabled after resumed

Re: [PATCH 4.9 00/66] 4.9.9-stable review

On Tue, Feb 07, 2017 at 08:59:52AM -0700, Shuah Khan wrote: > On 02/07/2017 05:58 AM, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 4.9.9 release. > > There are 66 patches in this series, all will be posted as a response > > to this one. If anyone has any

Re: [PATCH 4.9 00/66] 4.9.9-stable review

On Tue, Feb 07, 2017 at 08:59:52AM -0700, Shuah Khan wrote: > On 02/07/2017 05:58 AM, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 4.9.9 release. > > There are 66 patches in this series, all will be posted as a response > > to this one. If anyone has any

Re: [PATCH v5 2/6] drm/rockchip/dsi: dw-mipi: support RK3399 mipi dsi

On Sun, Feb 05, 2017 at 11:54:10AM +0800, Chris Zhong wrote: > The vopb/vopl switch register of RK3399 mipi is different from RK3288, > the default setting for mipi dsi mode is different too, so add a > of_device_id structure to distinguish them, and make sure set the > correct mode before mipi

Re: [PATCH v5 2/6] drm/rockchip/dsi: dw-mipi: support RK3399 mipi dsi

On Sun, Feb 05, 2017 at 11:54:10AM +0800, Chris Zhong wrote: > The vopb/vopl switch register of RK3399 mipi is different from RK3288, > the default setting for mipi dsi mode is different too, so add a > of_device_id structure to distinguish them, and make sure set the > correct mode before mipi

Re: [net-next PATCH 0/4] Documenting eBPF - extended Berkeley Packet Filter

On Tue, 7 Feb 2017 08:37:17 -0700 Jonathan Corbet wrote: > On Tue, 07 Feb 2017 15:30:11 +0100 > Jesper Dangaard Brouer wrote: > > > Question: What kernel tree should this go into??? > > > > If going through Jonathan Corbet, will it appear sooner here??? > >

Re: [net-next PATCH 0/4] Documenting eBPF - extended Berkeley Packet Filter

On Tue, 7 Feb 2017 08:37:17 -0700 Jonathan Corbet wrote: > On Tue, 07 Feb 2017 15:30:11 +0100 > Jesper Dangaard Brouer wrote: > > > Question: What kernel tree should this go into??? > > > > If going through Jonathan Corbet, will it appear sooner here??? > >

Re: [PATCH] genhd: Do not hold event lock when scheduling workqueue elements

On 02/06/2017 11:29 PM, Dexuan Cui wrote: >> From: linux-block-ow...@vger.kernel.org [mailto:linux-block- >> ow...@vger.kernel.org] On Behalf Of Dexuan Cui >> with the linux-next kernel. >> >> I can boot the guest with linux-next's next-20170130 without any issue, >> but since next-20170131 I

Re: [PATCH] genhd: Do not hold event lock when scheduling workqueue elements

On 02/06/2017 11:29 PM, Dexuan Cui wrote: >> From: linux-block-ow...@vger.kernel.org [mailto:linux-block- >> ow...@vger.kernel.org] On Behalf Of Dexuan Cui >> with the linux-next kernel. >> >> I can boot the guest with linux-next's next-20170130 without any issue, >> but since next-20170131 I

Re: [PATCH 3/3] cros_ec: Don't signal wake event for non-wake host events

On Wed, 25 Jan 2017, Thierry Escande wrote: > From: Shawn Nematbakhsh > > The subset of wake-enabled host events is defined by the EC, but the EC > may still send non-wake host events if we're in the process of > suspending. Get the mask of wake-enabled host events from the

Re: [PATCH 3/3] cros_ec: Don't signal wake event for non-wake host events

On Wed, 25 Jan 2017, Thierry Escande wrote: > From: Shawn Nematbakhsh > > The subset of wake-enabled host events is defined by the EC, but the EC > may still send non-wake host events if we're in the process of > suspending. Get the mask of wake-enabled host events from the EC and > filter out

[PATCH 2/7] serial: exar: Fix initialization of EXAR registers for ports > 0

So far, pci_xr17v35x_setup always initialized 8XMODE, FCTR & Co. for port 0 because it used the address of that port instead of moving the pointer according to the port number. Fix this and remove the unneeded temporary ioremap by moving default_setup up and reusing the membase it fills into the

[PATCH 2/7] serial: exar: Fix initialization of EXAR registers for ports > 0

So far, pci_xr17v35x_setup always initialized 8XMODE, FCTR & Co. for port 0 because it used the address of that port instead of moving the pointer according to the port number. Fix this and remove the unneeded temporary ioremap by moving default_setup up and reusing the membase it fills into the

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