Re: [PATCH v5 2/4] iio: accel: adxl345: Use I2C regmap instead of direct I2C access

On Tue, Feb 28, 2017 at 4:37 AM, Eva Rachel Retuya wrote: > Convert the driver to use regmap instead of I2C-specific functions. This > is done in preparation for splitting this driver into core and > I2C-specific code as well as introduction of SPI driver. > > Signed-off-by:

Re: [PATCH v5 2/4] iio: accel: adxl345: Use I2C regmap instead of direct I2C access

On Tue, Feb 28, 2017 at 4:37 AM, Eva Rachel Retuya wrote: > Convert the driver to use regmap instead of I2C-specific functions. This > is done in preparation for splitting this driver into core and > I2C-specific code as well as introduction of SPI driver. > > Signed-off-by: Eva Rachel Retuya >

Re: [linux-sunxi] Re: [PATCH 2/3] clk: sunxi-ng: add support for PRCM CCUs

On Thu, Mar 02, 2017 at 11:13:18PM +0800, Icenowy Zheng wrote: > > > 02.03.2017, 22:09, "Maxime Ripard" : > > On Wed, Mar 01, 2017 at 08:17:39PM +0800, Icenowy Zheng wrote: > >>  > I'm a bit worried by that to be honest. You claim to support the A31, > >>  > yet

Re: [linux-sunxi] Re: [PATCH 2/3] clk: sunxi-ng: add support for PRCM CCUs

On Thu, Mar 02, 2017 at 11:13:18PM +0800, Icenowy Zheng wrote: > > > 02.03.2017, 22:09, "Maxime Ripard" : > > On Wed, Mar 01, 2017 at 08:17:39PM +0800, Icenowy Zheng wrote: > >>  > I'm a bit worried by that to be honest. You claim to support the A31, > >>  > yet jugdging by the current state of

Re: [PATCH] vmbus: remove hv_event_tasklet_disable/enable

Dexuan Cui writes: > With the recent introduction of per-channel tasklet, we need to update > the way we handle the 3 concurrency issues: > > 1. hv_process_channel_removal -> percpu_channel_deq vs. >vmbus_chan_sched -> list_for_each_entry(..., percpu_list); > > 2.

Re: [PATCH] vmbus: remove hv_event_tasklet_disable/enable

Dexuan Cui writes: > With the recent introduction of per-channel tasklet, we need to update > the way we handle the 3 concurrency issues: > > 1. hv_process_channel_removal -> percpu_channel_deq vs. >vmbus_chan_sched -> list_for_each_entry(..., percpu_list); > > 2. vmbus_process_offer ->

Re: [PATCH v2 1/2] drm: bridge: dw-hdmi: Take input format from plat_data

On 03/03/2017 05:39 PM, Jose Abreu wrote: > Hi Neil, > > > On 03-03-2017 11:31, Neil Armstrong wrote: >> >> Sure, but I was struggling about finding an equivalence. >> >> How should I replace these ? >> >> DW_HDMI_ENC_FMT_RGB >> DW_HDMI_ENC_FMT_YCBCR444 >> DW_HDMI_ENC_FMT_YCBCR422_16BITS >>

Re: [PATCH v2 1/2] drm: bridge: dw-hdmi: Take input format from plat_data

On 03/03/2017 05:39 PM, Jose Abreu wrote: > Hi Neil, > > > On 03-03-2017 11:31, Neil Armstrong wrote: >> >> Sure, but I was struggling about finding an equivalence. >> >> How should I replace these ? >> >> DW_HDMI_ENC_FMT_RGB >> DW_HDMI_ENC_FMT_YCBCR444 >> DW_HDMI_ENC_FMT_YCBCR422_16BITS >>

Re: [RFC PATCH 10/12] staging: android: ion: Use CMA APIs directly

Hi Laura, Thank you for the patch. On Thursday 02 Mar 2017 13:44:42 Laura Abbott wrote: > When CMA was first introduced, its primary use was for DMA allocation > and the only way to get CMA memory was to call dma_alloc_coherent. This > put Ion in an awkward position since there was no device

Re: [RFC PATCH 10/12] staging: android: ion: Use CMA APIs directly

Hi Laura, Thank you for the patch. On Thursday 02 Mar 2017 13:44:42 Laura Abbott wrote: > When CMA was first introduced, its primary use was for DMA allocation > and the only way to get CMA memory was to call dma_alloc_coherent. This > put Ion in an awkward position since there was no device

Re: [RFC PATCH 04/12] staging: android: ion: Call dma_map_sg for syncing and mapping

Hi Laura, Thank you for the patch. On Thursday 02 Mar 2017 13:44:36 Laura Abbott wrote: > Technically, calling dma_buf_map_attachment should return a buffer > properly dma_mapped. Add calls to dma_map_sg to begin_cpu_access to > ensure this happens. As a side effect, this lets Ion buffers take >

Re: [RFC PATCH 04/12] staging: android: ion: Call dma_map_sg for syncing and mapping

Hi Laura, Thank you for the patch. On Thursday 02 Mar 2017 13:44:36 Laura Abbott wrote: > Technically, calling dma_buf_map_attachment should return a buffer > properly dma_mapped. Add calls to dma_map_sg to begin_cpu_access to > ensure this happens. As a side effect, this lets Ion buffers take >

Re: [PATCH 0/3] fs, fuse subsystem refcount conversions

On Fri, Mar 3, 2017 at 10:04 AM, Elena Reshetova wrote: > Now when new refcount_t type and API are finally merged > (see include/linux/refcount.h), the following > patches convert various refcounters in the fuse filesystem from atomic_t > to refcount_t. By doing this we

Re: [PATCH 0/3] fs, fuse subsystem refcount conversions

On Fri, Mar 3, 2017 at 10:04 AM, Elena Reshetova wrote: > Now when new refcount_t type and API are finally merged > (see include/linux/refcount.h), the following > patches convert various refcounters in the fuse filesystem from atomic_t > to refcount_t. By doing this we prevent intentional or

Re: [Outreachy kernel] Re: [PATCH v3 0/5] Fixed compilation error

On Fri, Mar 3, 2017 at 9:45 PM, Julia Lawall wrote: > > > On Fri, 3 Mar 2017, SIMRAN SINGHAL wrote: > >> On Fri, Mar 3, 2017 at 9:20 PM, Joe Perches wrote: >> > On Fri, 2017-03-03 at 17:05 +0530, simran singhal wrote: >> >> Fixed compilation warning in

Re: [Outreachy kernel] Re: [PATCH v3 0/5] Fixed compilation error

On Fri, Mar 3, 2017 at 9:45 PM, Julia Lawall wrote: > > > On Fri, 3 Mar 2017, SIMRAN SINGHAL wrote: > >> On Fri, Mar 3, 2017 at 9:20 PM, Joe Perches wrote: >> > On Fri, 2017-03-03 at 17:05 +0530, simran singhal wrote: >> >> Fixed compilation warning in lustre/lustre/llite/range_lock.c >> > >> >

Re: [PATCH 0/8] Droid4 DTS update

* Sebastian Reichel [170303 03:18]: > Hi, > > On Wed, Mar 01, 2017 at 05:37:08PM -0800, Tony Lindgren wrote: > > * Sebastian Reichel [170301 17:10]: > > > Hi, > > > > > > Tony, since your omap4-droid4 dts patches were not > > > yet in a public repository and

Re: [PATCH v3 0/5] Fixed compilation error

On Fri, Mar 3, 2017 at 9:20 PM, Joe Perches wrote: > On Fri, 2017-03-03 at 17:05 +0530, simran singhal wrote: >> Fixed compilation warning in lustre/lustre/llite/range_lock.c > > Really? What compilation warning was removed? CC [M]

Re: [PATCH 0/8] Droid4 DTS update

* Sebastian Reichel [170303 03:18]: > Hi, > > On Wed, Mar 01, 2017 at 05:37:08PM -0800, Tony Lindgren wrote: > > * Sebastian Reichel [170301 17:10]: > > > Hi, > > > > > > Tony, since your omap4-droid4 dts patches were not > > > yet in a public repository and they would merge conflict > > >

Re: [PATCH v3 0/5] Fixed compilation error

On Fri, Mar 3, 2017 at 9:20 PM, Joe Perches wrote: > On Fri, 2017-03-03 at 17:05 +0530, simran singhal wrote: >> Fixed compilation warning in lustre/lustre/llite/range_lock.c > > Really? What compilation warning was removed? CC [M] drivers/staging/lustre/lustre/mgc/mgc_request.o

[GIT PULL] ARM: late soc updates for 4.11

The following changes since commit b2e3c4319d40c9055c3c587cdb82ba69b50e919d: Merge tag 'armsoc-drivers' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc (2017-02-23 15:57:04 -0800) are available in the git repository at:

[GIT PULL] ARM: late soc updates for 4.11

The following changes since commit b2e3c4319d40c9055c3c587cdb82ba69b50e919d: Merge tag 'armsoc-drivers' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc (2017-02-23 15:57:04 -0800) are available in the git repository at:

[PATCH 4/4] net: thunderx: Allow IPv6 frames with zero UDP checksum

From: Thanneeru Srinivasulu Do not consider IPv6 frames with zero UDP checksum as frames with bad checksum and drop them. Signed-off-by: Thanneeru Srinivasulu Signed-off-by: Sunil Goutham ---

[PATCH 4/4] net: thunderx: Allow IPv6 frames with zero UDP checksum

From: Thanneeru Srinivasulu Do not consider IPv6 frames with zero UDP checksum as frames with bad checksum and drop them. Signed-off-by: Thanneeru Srinivasulu Signed-off-by: Sunil Goutham --- drivers/net/ethernet/cavium/thunder/nicvf_queues.c | 6 -- 1 file changed, 4 insertions(+), 2

Re: [PATCH 00/13] rtc: Add OF device table to I2C drivers that are missing it

On 03/03/2017 at 12:27:23 -0300, Javier Martinez Canillas wrote: > On 03/03/2017 12:01 PM, Alexandre Belloni wrote: > > On 03/03/2017 at 11:29:11 -0300, Javier Martinez Canillas wrote: > >> This series add OF device ID tables to RTC I2C drivers whose devices are > >> either used in Device Tree

Re: [PATCH 00/13] rtc: Add OF device table to I2C drivers that are missing it

On 03/03/2017 at 12:27:23 -0300, Javier Martinez Canillas wrote: > On 03/03/2017 12:01 PM, Alexandre Belloni wrote: > > On 03/03/2017 at 11:29:11 -0300, Javier Martinez Canillas wrote: > >> This series add OF device ID tables to RTC I2C drivers whose devices are > >> either used in Device Tree

Re: [PATCH] drm/arcpgu: Get rid of "encoder-slave" property

On Fri, Mar 03, 2017 at 06:19:24PM +0300, Alexey Brodkin wrote: > We used to use "encoder-slave" property in PGU's > Device Tree node to refer to the encoder, but since there's > a way to find it with some code smarts we get rid of > obviously extra complication in PGU node. > > Again inspired by

Re: [PATCH] drm/arcpgu: Get rid of "encoder-slave" property

On Fri, Mar 03, 2017 at 06:19:24PM +0300, Alexey Brodkin wrote: > We used to use "encoder-slave" property in PGU's > Device Tree node to refer to the encoder, but since there's > a way to find it with some code smarts we get rid of > obviously extra complication in PGU node. > > Again inspired by

Re: [PATCH 0/8] Droid4 DTS update

* Sebastian Reichel [170303 03:03]: > On Wed, Mar 01, 2017 at 05:49:11PM -0800, Tony Lindgren wrote: > > Some of the command mode LCD patches could be sent out too, and > > if the timing patch is OK then we can configure the LCD in the dts > > too. Have you had a chance to look

Re: [PATCH 0/8] Droid4 DTS update

* Sebastian Reichel [170303 03:03]: > On Wed, Mar 01, 2017 at 05:49:11PM -0800, Tony Lindgren wrote: > > Some of the command mode LCD patches could be sent out too, and > > if the timing patch is OK then we can configure the LCD in the dts > > too. Have you had a chance to look at those related

[PATCH v3 1/3] staging: wlan-ng: Replace "the the " with "the"

This patch replace "the the " with "the". The replacement couldn't be automated because sometimes the first "the" was meant to be another word. Signed-off-by: simran singhal --- drivers/staging/wlan-ng/prism2sta.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)

[PATCH v3 1/3] staging: wlan-ng: Replace "the the " with "the"

This patch replace "the the " with "the". The replacement couldn't be automated because sometimes the first "the" was meant to be another word. Signed-off-by: simran singhal --- drivers/staging/wlan-ng/prism2sta.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

Re: [PATCH 1/2] HID: hiddev: move hiddev's minor number from struct hid_device to hiddev

Hi Jaejoong, [auto build test ERROR on hid/for-next] [also build test ERROR on v4.10 next-20170303] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Jaejoong-Kim/HID-hiddev-move-hiddev-s-minor

Re: [PATCH 1/2] HID: hiddev: move hiddev's minor number from struct hid_device to hiddev

Hi Jaejoong, [auto build test ERROR on hid/for-next] [also build test ERROR on v4.10 next-20170303] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Jaejoong-Kim/HID-hiddev-move-hiddev-s-minor

Re: [PATCH 0/8] Droid4 DTS update

Hi, On Wed, Mar 01, 2017 at 05:49:11PM -0800, Tony Lindgren wrote: > * Tony Lindgren [170301 17:45]: > > * Sebastian Reichel [170301 17:10]: > > > Hi, > > > > > > Tony, since your omap4-droid4 dts patches were not > > > yet in a public repository and they

Re: [PATCH 0/8] Droid4 DTS update

Hi, On Wed, Mar 01, 2017 at 05:49:11PM -0800, Tony Lindgren wrote: > * Tony Lindgren [170301 17:45]: > > * Sebastian Reichel [170301 17:10]: > > > Hi, > > > > > > Tony, since your omap4-droid4 dts patches were not > > > yet in a public repository and they would merge conflict > > > with my

[Regression] Changes to i2c-piix4.c initialisation prevent loading of sp5100_tco watchdog driver on AMD SB800 chipset

Dear Linux folks, Unfortunately, commit 2fee61d22e (i2c: piix4: Add support for multiplexed main adapter in SB800) [1] caused a regression. Tim reported that to the Linux Kernel Bugtracker as bug #170741 last September [2], but it looks like the affected subsystems don’t use it. So I just copy

[Regression] Changes to i2c-piix4.c initialisation prevent loading of sp5100_tco watchdog driver on AMD SB800 chipset

Dear Linux folks, Unfortunately, commit 2fee61d22e (i2c: piix4: Add support for multiplexed main adapter in SB800) [1] caused a regression. Tim reported that to the Linux Kernel Bugtracker as bug #170741 last September [2], but it looks like the affected subsystems don’t use it. So I just copy

Re: [RFC PATCH 00/12] Ion cleanup in preparation for moving out of staging

Hi Laura, Thank you for the patches. On Thursday 02 Mar 2017 13:44:32 Laura Abbott wrote: > Hi, > > There's been some recent discussions[1] about Ion-like frameworks. There's > apparently interest in just keeping Ion since it works reasonablly well. > This series does what should be the final

Re: [RFC PATCH 00/12] Ion cleanup in preparation for moving out of staging

Hi Laura, Thank you for the patches. On Thursday 02 Mar 2017 13:44:32 Laura Abbott wrote: > Hi, > > There's been some recent discussions[1] about Ion-like frameworks. There's > apparently interest in just keeping Ion since it works reasonablly well. > This series does what should be the final

Re: [PATCH] drm/arcpgu: Opt in debugfs

On Fri, Mar 03, 2017 at 03:30:35PM +0300, Alexey Brodkin wrote: > This change adopts debugfs usage for outputting useful data. > As of today we print: > * Mode and real HW clock values > * Standard FB info > > Code is heavily borrowed from ARM's HDLCD thus adding Liviu in Cc. FWIW:

Re: [PATCH] drm/arcpgu: Opt in debugfs

On Fri, Mar 03, 2017 at 03:30:35PM +0300, Alexey Brodkin wrote: > This change adopts debugfs usage for outputting useful data. > As of today we print: > * Mode and real HW clock values > * Standard FB info > > Code is heavily borrowed from ARM's HDLCD thus adding Liviu in Cc. FWIW:

Re: [PATCH v2 0/2] patches for Innomedia INNEX GENESIS/ATARI adapter

Hi, After some checks on the devices I have and the history of the code, I think the patch in this form is correct: Acked-By: Benjamin Tissoires Actually, in the discussion that introduced those checks, there was even a mention of checking the NULL state byte.

Re: [PATCH v2 0/2] patches for Innomedia INNEX GENESIS/ATARI adapter

Hi, After some checks on the devices I have and the history of the code, I think the patch in this form is correct: Acked-By: Benjamin Tissoires Actually, in the discussion that introduced those checks, there was even a mention of checking the NULL state byte. Unfortunately, it didn't end up

Re: mm: use-after-free in zap_page_range

Hello Dmitry, On Fri, Mar 03, 2017 at 02:54:26PM +0100, Dmitry Vyukov wrote: > The following program triggers use-after-free in zap_page_range: > https://gist.githubusercontent.com/dvyukov/b59dfbaa0cb1e5231094d228fa57c9bd/raw/95c4da18cb96f8aaa47c10012d8c4484fd5917ad/gistfile1.txt I posted the

Re: mm: use-after-free in zap_page_range

Hello Dmitry, On Fri, Mar 03, 2017 at 02:54:26PM +0100, Dmitry Vyukov wrote: > The following program triggers use-after-free in zap_page_range: > https://gist.githubusercontent.com/dvyukov/b59dfbaa0cb1e5231094d228fa57c9bd/raw/95c4da18cb96f8aaa47c10012d8c4484fd5917ad/gistfile1.txt I posted the

Re: [PATCH 2/2] Fix endiannes error

These patches look good but you need to resend with a correct subsystem prefix in the subject. It should be: [PATCH 2/2] Staging: wlan-ng: Fix endiannes error Hm... Also "endiannes" doesn't look like correct spelling. Just say "endian". On Thu, Mar 02, 2017 at 09:30:12PM +0100, Adrien

Re: [PATCH 2/2] Fix endiannes error

These patches look good but you need to resend with a correct subsystem prefix in the subject. It should be: [PATCH 2/2] Staging: wlan-ng: Fix endiannes error Hm... Also "endiannes" doesn't look like correct spelling. Just say "endian". On Thu, Mar 02, 2017 at 09:30:12PM +0100, Adrien

Re: [Outreachy kernel] Re: [PATCH v3 0/5] Fixed compilation error

On Fri, 3 Mar 2017, SIMRAN SINGHAL wrote: > On Fri, Mar 3, 2017 at 9:20 PM, Joe Perches wrote: > > On Fri, 2017-03-03 at 17:05 +0530, simran singhal wrote: > >> Fixed compilation warning in lustre/lustre/llite/range_lock.c > > > > Really? What compilation warning was

Re: [Outreachy kernel] Re: [PATCH v3 0/5] Fixed compilation error

On Fri, 3 Mar 2017, SIMRAN SINGHAL wrote: > On Fri, Mar 3, 2017 at 9:20 PM, Joe Perches wrote: > > On Fri, 2017-03-03 at 17:05 +0530, simran singhal wrote: > >> Fixed compilation warning in lustre/lustre/llite/range_lock.c > > > > Really? What compilation warning was removed? > > CC [M]

Re: [RFC 07/11] mm: remove SWAP_AGAIN in ttu

On 03/02/2017 12:09 PM, Minchan Kim wrote: > In 2002, [1] introduced SWAP_AGAIN. > At that time, ttuo used spin_trylock(>page_table_lock) so it's Small nit: Please expand "ttuo" here. TTU in the first place is also not very clear but we have that in many places. > really easy to contend and fail

Re: Dell Inspiron 5558/0VNM2T and suspend/resume problem with r8169

On Fri, Mar 3, 2017 at 12:40 PM, Diego Viola wrote: > On Fri, Mar 3, 2017 at 12:37 PM, Diego Viola wrote: >> On Wed, Mar 1, 2017 at 12:47 PM, Diego Viola wrote: >>> On Wed, Mar 1, 2017 at 12:44 PM, Diego Viola

Re: [RFC 07/11] mm: remove SWAP_AGAIN in ttu

On 03/02/2017 12:09 PM, Minchan Kim wrote: > In 2002, [1] introduced SWAP_AGAIN. > At that time, ttuo used spin_trylock(>page_table_lock) so it's Small nit: Please expand "ttuo" here. TTU in the first place is also not very clear but we have that in many places. > really easy to contend and fail

Re: Dell Inspiron 5558/0VNM2T and suspend/resume problem with r8169

On Fri, Mar 3, 2017 at 12:40 PM, Diego Viola wrote: > On Fri, Mar 3, 2017 at 12:37 PM, Diego Viola wrote: >> On Wed, Mar 1, 2017 at 12:47 PM, Diego Viola wrote: >>> On Wed, Mar 1, 2017 at 12:44 PM, Diego Viola wrote: My machine (a Dell Inspiron 5558 laptop) fails to resume from suspend

[PATCH V3 4/4] dts/imx6q-b850v3: Use megachips-stdpxxxx-ge-b850v3-fw bridges (LVDS-DP++)

Configures the megachips-stdp-ge-b850v3-fw bridges on the GE B850v3 dts file. Cc: Laurent Pinchart Cc: Martyn Welch Cc: Martin Donnelly Cc: Javier Martinez Canillas Cc: Enric

[PATCH V3 4/4] dts/imx6q-b850v3: Use megachips-stdpxxxx-ge-b850v3-fw bridges (LVDS-DP++)

Configures the megachips-stdp-ge-b850v3-fw bridges on the GE B850v3 dts file. Cc: Laurent Pinchart Cc: Martyn Welch Cc: Martin Donnelly Cc: Javier Martinez Canillas Cc: Enric Balletbo i Serra Cc: Philipp Zabel Cc: Rob Herring Cc: Fabio Estevam Signed-off-by: Peter Senna Tschudin ---

Re: [Outreachy kernel] [PATCH v3 0/3] Replace "the the " with "the"

On Fri, 3 Mar 2017, simran singhal wrote: > This patch series replace "the the " with "the" in various drivers. > > v3: > -Resend the complete patch series. Acked-by: Julia Lawall > > > simran singhal (3): > staging: wlan-ng: Replace "the the " with "the" >

Re: [Outreachy kernel] [PATCH v3 0/3] Replace "the the " with "the"

On Fri, 3 Mar 2017, simran singhal wrote: > This patch series replace "the the " with "the" in various drivers. > > v3: > -Resend the complete patch series. Acked-by: Julia Lawall > > > simran singhal (3): > staging: wlan-ng: Replace "the the " with "the" > staging: rtl8192u: Replace

[PATCH v3] tpm: do not suspend/resume if power stays on

From: Sonny Rao The suspend/resume behavior of the TPM can be controlled by setting "powered-while-suspended" in the DTS. This is useful for the cases when hardware does not power-off the TPM. Signed-off-by: Sonny Rao Signed-off-by: Enric Balletbo

[PATCH v3] tpm: do not suspend/resume if power stays on

From: Sonny Rao The suspend/resume behavior of the TPM can be controlled by setting "powered-while-suspended" in the DTS. This is useful for the cases when hardware does not power-off the TPM. Signed-off-by: Sonny Rao Signed-off-by: Enric Balletbo i Serra --- Changes since v2: Jarkko

[PATCH V3 2/4] MAINTAINERS: Add entry for megachips-stdpxxxx-ge-b850v3-fw

Add MAINTAINERS entry for the second video output of the GE B850v3: STDP4028-ge-b850v3-fw bridges (LVDS-DP) STDP2690-ge-b850v3-fw bridges (DP-DP++) Cc: Laurent Pinchart Cc: Martyn Welch Cc: Martin Donnelly

[PATCH V3 2/4] MAINTAINERS: Add entry for megachips-stdpxxxx-ge-b850v3-fw

Add MAINTAINERS entry for the second video output of the GE B850v3: STDP4028-ge-b850v3-fw bridges (LVDS-DP) STDP2690-ge-b850v3-fw bridges (DP-DP++) Cc: Laurent Pinchart Cc: Martyn Welch Cc: Martin Donnelly Cc: Daniel Vetter Cc: Enric Balletbo i Serra Cc: Philipp Zabel Cc: Rob

[PATCH V3 0/4] megachips-stdpxxxx-ge-b850v3-fw

The video processing pipeline on the second output on the GE B850v3: Host -> LVDS|--(STDP4028)--|DP -> DP|--(STDP2690)--|DP++ -> Video output Each bridge has a dedicated flash containing firmware for supporting the custom design. The result is that in this design neither the STDP4028 nor the

[PATCH V3 0/4] megachips-stdpxxxx-ge-b850v3-fw

The video processing pipeline on the second output on the GE B850v3: Host -> LVDS|--(STDP4028)--|DP -> DP|--(STDP2690)--|DP++ -> Video output Each bridge has a dedicated flash containing firmware for supporting the custom design. The result is that in this design neither the STDP4028 nor the

[PATCH V3 1/4] dt-bindings: display: megachips-stdpxxxx-ge-b850v3-fw

Devicetree binding documentation for the second video output of the GE B850v3: STDP4028-ge-b850v3-fw bridges (LVDS-DP) STDP2690-ge-b850v3-fw bridges (DP-DP++) Added entry for MegaChips at: Documentation/devicetree/bindings/vendor-prefixes.txt Cc: Laurent Pinchart

[PATCH V3 3/4] drm/bridge: Drivers for megachips-stdpxxxx-ge-b850v3-fw (LVDS-DP++)

The video processing pipeline on the second output on the GE B850v3: Host -> LVDS|--(STDP4028)--|DP -> DP|--(STDP2690)--|DP++ -> Video output Each bridge has a dedicated flash containing firmware for supporting the custom design. The result is that in this design neither the STDP4028 nor the

[PATCH V3 1/4] dt-bindings: display: megachips-stdpxxxx-ge-b850v3-fw

Devicetree binding documentation for the second video output of the GE B850v3: STDP4028-ge-b850v3-fw bridges (LVDS-DP) STDP2690-ge-b850v3-fw bridges (DP-DP++) Added entry for MegaChips at: Documentation/devicetree/bindings/vendor-prefixes.txt Cc: Laurent Pinchart Cc: Martyn Welch Cc:

[PATCH V3 3/4] drm/bridge: Drivers for megachips-stdpxxxx-ge-b850v3-fw (LVDS-DP++)

The video processing pipeline on the second output on the GE B850v3: Host -> LVDS|--(STDP4028)--|DP -> DP|--(STDP2690)--|DP++ -> Video output Each bridge has a dedicated flash containing firmware for supporting the custom design. The result is that in this design neither the STDP4028 nor the

Re: net/dccp: use-after-free in dccp_feat_activate_values

On Fri, 2017-03-03 at 07:22 -0800, Eric Dumazet wrote: > On Fri, Mar 3, 2017 at 7:12 AM, Dmitry Vyukov wrote: > > The first bot that picked this up started spewing: > > > > BUG: spinlock recursion on CPU#1, syz-executor2/9452 > > Yes. The bug is not about locking the

Re: net/dccp: use-after-free in dccp_feat_activate_values

On Fri, 2017-03-03 at 07:22 -0800, Eric Dumazet wrote: > On Fri, Mar 3, 2017 at 7:12 AM, Dmitry Vyukov wrote: > > The first bot that picked this up started spewing: > > > > BUG: spinlock recursion on CPU#1, syz-executor2/9452 > > Yes. The bug is not about locking the listener, but protecting

[PATCH v3 2/3] staging: rtl8192u: Replace "the the " with "the"

This patch replace "the the " with "the". The replacement couldn't be automated because sometimes the first "the" was meant to be another word. Signed-off-by: simran singhal --- drivers/staging/rtl8192u/ieee80211/ieee80211_rx.c | 2 +- 1 file changed, 1 insertion(+), 1

[PATCH v3 2/3] staging: rtl8192u: Replace "the the " with "the"

This patch replace "the the " with "the". The replacement couldn't be automated because sometimes the first "the" was meant to be another word. Signed-off-by: simran singhal --- drivers/staging/rtl8192u/ieee80211/ieee80211_rx.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

[PATCH v3 3/3] staging: unisys: Replace "the the " with "the"

This patch replace "the the " with "the". The replacement couldn't be automated because sometimes the first "the" was meant to be another word. Signed-off-by: simran singhal --- drivers/staging/unisys/visorbus/visorbus_main.c | 2 +- 1 file changed, 1 insertion(+), 1

[PATCH v3 3/3] staging: unisys: Replace "the the " with "the"

This patch replace "the the " with "the". The replacement couldn't be automated because sometimes the first "the" was meant to be another word. Signed-off-by: simran singhal --- drivers/staging/unisys/visorbus/visorbus_main.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

[PATCH v3 0/3] Replace "the the " with "the"

This patch series replace "the the " with "the" in various drivers. v3: -Resend the complete patch series. simran singhal (3): staging: wlan-ng: Replace "the the " with "the" staging: rtl8192u: Replace "the the " with "the" staging: unisys: Replace "the the " with "the"

[PATCH v3 0/3] Replace "the the " with "the"

This patch series replace "the the " with "the" in various drivers. v3: -Resend the complete patch series. simran singhal (3): staging: wlan-ng: Replace "the the " with "the" staging: rtl8192u: Replace "the the " with "the" staging: unisys: Replace "the the " with "the"

Re: [PATCH 1/3] doc: bindings: Add bindings documentation for mtd nvmem

On Thu, 2 Mar 2017 21:22:20 +0100 Boris Brezillon wrote: > On Thu, 2 Mar 2017 20:50:21 +0100 > Alban wrote: > > > Add the binding to expose MTD partitions as nvmem providers. > > Looks good. Maybe you should take the case you describe in

Re: [PATCH 1/3] doc: bindings: Add bindings documentation for mtd nvmem

On Thu, 2 Mar 2017 21:22:20 +0100 Boris Brezillon wrote: > On Thu, 2 Mar 2017 20:50:21 +0100 > Alban wrote: > > > Add the binding to expose MTD partitions as nvmem providers. > > Looks good. Maybe you should take the case you describe in your > cover-letter into account and add an extra

[PATCH 2/2] dt-bindings: display: atmel: Fix path to atmel-hlcdc.txt

The relative path pointed to Documentation/devicetree/bindings/display/mfd/atmel-hlcdc.txt instead of Documentation/devicetree/bindings/mfd/atmel-hlcdc.txt Signed-off-by: Richard Genoud --- Documentation/devicetree/bindings/display/atmel/hlcdc-dc.txt | 2 +- 1 file

[PATCH 2/2] dt-bindings: display: atmel: Fix path to atmel-hlcdc.txt

The relative path pointed to Documentation/devicetree/bindings/display/mfd/atmel-hlcdc.txt instead of Documentation/devicetree/bindings/mfd/atmel-hlcdc.txt Signed-off-by: Richard Genoud --- Documentation/devicetree/bindings/display/atmel/hlcdc-dc.txt | 2 +- 1 file changed, 1 insertion(+), 1

[GIT PULL] Urgent fix for Kselftest 4.11-rc1

Hi Linus, Please pull this urgent fix for Kselftest. This update consists of an urgent fix for individual test build failures introduced in the 4.11-rc1 update. Without this fix individual test builds fail. This is a regression introduced in a commit in my previous pull update for 4.11-rc1.

[GIT PULL] Urgent fix for Kselftest 4.11-rc1

Hi Linus, Please pull this urgent fix for Kselftest. This update consists of an urgent fix for individual test build failures introduced in the 4.11-rc1 update. Without this fix individual test builds fail. This is a regression introduced in a commit in my previous pull update for 4.11-rc1.

Re: [PATCH v4 1/3] x86: Introduce a new constant KERNEL_MAPPING_SIZE

On Sun, Feb 26, 2017 at 12:09:08PM +0800, Baoquan He wrote: > Am I right on understanding it? That's exactly what I mean: KERNEL_IMAGE_SIZE is 512M by default but we're not hard-constrained to it - we're hard-constrained to a 1G limit as this is the 1G which is covered by level2_kernel_pgt. And

Re: [PATCH v4 1/3] x86: Introduce a new constant KERNEL_MAPPING_SIZE

On Sun, Feb 26, 2017 at 12:09:08PM +0800, Baoquan He wrote: > Am I right on understanding it? That's exactly what I mean: KERNEL_IMAGE_SIZE is 512M by default but we're not hard-constrained to it - we're hard-constrained to a 1G limit as this is the 1G which is covered by level2_kernel_pgt. And

Re: [PATCH v4 1/3] x86: Introduce a new constant KERNEL_MAPPING_SIZE

On Fri, Mar 03, 2017 at 08:06:16PM +0800, Baoquan He wrote: > OK, I am trying to make things clearer, seems I failed. I thought kernel > iamge size is only allowed to be 512M at most, but can be mapped into 1G > region. It doesn't look like it. But we could be missing something. You could try

[PATCH v3 3/3] printk: fix double printing with earlycon

If a console was specified by ACPI SPCR table _and_ command line parameters like "console=ttyAMA0" _and_ "earlycon" were specified, then log messages appear twice. The root cause is that the code traverses the list of specified consoles (the `console_cmdline` array) and stops at the first match.

Re: [PATCH v4 1/3] x86: Introduce a new constant KERNEL_MAPPING_SIZE

On Fri, Mar 03, 2017 at 08:06:16PM +0800, Baoquan He wrote: > OK, I am trying to make things clearer, seems I failed. I thought kernel > iamge size is only allowed to be 512M at most, but can be mapped into 1G > region. It doesn't look like it. But we could be missing something. You could try

[PATCH v3 3/3] printk: fix double printing with earlycon

If a console was specified by ACPI SPCR table _and_ command line parameters like "console=ttyAMA0" _and_ "earlycon" were specified, then log messages appear twice. The root cause is that the code traverses the list of specified consoles (the `console_cmdline` array) and stops at the first match.

Re: [PATCH 1/2] mm: use is_migrate_highatomic() to simplify the code

On Fri 03-03-17 19:10:13, Xishi Qiu wrote: > Introduce two helpers, is_migrate_highatomic() and > is_migrate_highatomic_page(). > Simplify the code, no functional changes. static inline helpers would be nicer than macros > Signed-off-by: Xishi Qiu OK this fits with other

[PATCH v3 3/5] staging: lustre: lustre: Remove unnecessary cast on void pointer

The following Coccinelle script was used to detect this: @r@ expression x; void* e; type T; identifier f; @@ ( *((T *)e) | ((T *)x)[...] | ((T*)x)->f | - (T*) e ) Signed-off-by: simran singhal --- drivers/staging/lustre/lustre/llite/range_lock.c | 2 +-

Re: [PATCH 1/2] mm: use is_migrate_highatomic() to simplify the code

On Fri 03-03-17 19:10:13, Xishi Qiu wrote: > Introduce two helpers, is_migrate_highatomic() and > is_migrate_highatomic_page(). > Simplify the code, no functional changes. static inline helpers would be nicer than macros > Signed-off-by: Xishi Qiu OK this fits with other MIGRATE_$FOO types

[PATCH v3 3/5] staging: lustre: lustre: Remove unnecessary cast on void pointer

The following Coccinelle script was used to detect this: @r@ expression x; void* e; type T; identifier f; @@ ( *((T *)e) | ((T *)x)[...] | ((T*)x)->f | - (T*) e ) Signed-off-by: simran singhal --- drivers/staging/lustre/lustre/llite/range_lock.c | 2 +-

Re: [tpmdd-devel] [PATCH v2] tpm: do not suspend/resume if power stays on

Hi Jarkko, Thanks for the review On 03/03/17 16:12, Jarkko Sakkinen wrote: > On Thu, Mar 02, 2017 at 04:42:57PM +0100, Enric Balletbo i Serra wrote: >> From: Sonny Rao >> >> The suspend/resume behavior of the TPM can be controlled by setting >> "powered-while-suspended"

Re: [tpmdd-devel] [PATCH v2] tpm: do not suspend/resume if power stays on

Hi Jarkko, Thanks for the review On 03/03/17 16:12, Jarkko Sakkinen wrote: > On Thu, Mar 02, 2017 at 04:42:57PM +0100, Enric Balletbo i Serra wrote: >> From: Sonny Rao >> >> The suspend/resume behavior of the TPM can be controlled by setting >> "powered-while-suspended" in the DTS. This is

Re: [PATCH v9 00/10] mux controller abstraction and iio/i2c muxes

On 2017-02-28 18:18, Greg Kroah-Hartman wrote: > On Tue, Feb 28, 2017 at 04:17:52PM +0100, Peter Rosin wrote: >> Hi! >> >> The status of this series [1] is that Rob Herring has acked/reviewed all >> devicetree changes, so I suppose that's ok. Jonathan Cameron has acked >> the additions to the iio

Re: [PATCH v9 00/10] mux controller abstraction and iio/i2c muxes

On 2017-02-28 18:18, Greg Kroah-Hartman wrote: > On Tue, Feb 28, 2017 at 04:17:52PM +0100, Peter Rosin wrote: >> Hi! >> >> The status of this series [1] is that Rob Herring has acked/reviewed all >> devicetree changes, so I suppose that's ok. Jonathan Cameron has acked >> the additions to the iio

Re: [PATCH v3 0/5] Fixed compilation error

On Fri, 2017-03-03 at 17:05 +0530, simran singhal wrote: > Fixed compilation warning in lustre/lustre/llite/range_lock.c Really? What compilation warning was removed? > simran singhal (5): > staging: nvec: Remove unnecessary cast on void pointer > staging: lustre: Remove unnecessary cast on

Re: [PATCH v3 0/5] Fixed compilation error

On Fri, 2017-03-03 at 17:05 +0530, simran singhal wrote: > Fixed compilation warning in lustre/lustre/llite/range_lock.c Really? What compilation warning was removed? > simran singhal (5): > staging: nvec: Remove unnecessary cast on void pointer > staging: lustre: Remove unnecessary cast on

Re: [PATCH v3 6/6] iio: adc: stm32: add support for EXTI trigger

On 03/03/2017 02:00 PM, Fabrice Gasnier wrote: > On 03/03/2017 12:45 PM, Lars-Peter Clausen wrote: >> On 02/28/2017 05:51 PM, Fabrice Gasnier wrote: >>> EXTi (external interrupt) signal can be routed internally as trigger >>> source for ADC conversions: STM32F4 ADC can use EXTI11. >>> >>> Retrieve

Re: [PATCH v3 6/6] iio: adc: stm32: add support for EXTI trigger

On 03/03/2017 02:00 PM, Fabrice Gasnier wrote: > On 03/03/2017 12:45 PM, Lars-Peter Clausen wrote: >> On 02/28/2017 05:51 PM, Fabrice Gasnier wrote: >>> EXTi (external interrupt) signal can be routed internally as trigger >>> source for ADC conversions: STM32F4 ADC can use EXTI11. >>> >>> Retrieve

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