[PATCH] kernel/rtmutex: only warn once on a try lock from bad context

One warning should be enough to get one motivated to fix this. It is possible that this happens more than once and so starts flooding the output. Later the prints will be suppressed so we only get half of it. Depending on the console system used it might not be helpfull. Signed-off-by: Sebastian

Re: [PATCH] hwrng: stm32: fix maybe uninitialized variable warning

On 26/05/16 10:34, Maxime Coquelin wrote: This patch fixes the following warning: drivers/char/hw_random/stm32-rng.c: In function 'stm32_rng_read': drivers/char/hw_random/stm32-rng.c:82:19: warning: 'sr' may be used uninitialized in this function

[PATCH] kernel/rtmutex: only warn once on a try lock from bad context

One warning should be enough to get one motivated to fix this. It is possible that this happens more than once and so starts flooding the output. Later the prints will be suppressed so we only get half of it. Depending on the console system used it might not be helpfull. Signed-off-by: Sebastian

Re: [PATCH] hwrng: stm32: fix maybe uninitialized variable warning

On 26/05/16 10:34, Maxime Coquelin wrote: This patch fixes the following warning: drivers/char/hw_random/stm32-rng.c: In function 'stm32_rng_read': drivers/char/hw_random/stm32-rng.c:82:19: warning: 'sr' may be used uninitialized in this function

[RFC v2 2/3] ASoC: Introduce SOC_SINGLE_S8_TLV() macro

This patch introduces SOC_SINGLE_S8_TLV() macro for volume control on chips which supports both negative and positive gains with sign bit on a 8 bit register, Gain ranges from -128 to +127 with a predefined step size. Currently we only have support to DOUBLE_S8_TLV() which does not fit for cases

[RFC v2 2/3] ASoC: Introduce SOC_SINGLE_S8_TLV() macro

This patch introduces SOC_SINGLE_S8_TLV() macro for volume control on chips which supports both negative and positive gains with sign bit on a 8 bit register, Gain ranges from -128 to +127 with a predefined step size. Currently we only have support to DOUBLE_S8_TLV() which does not fit for cases

[RFC v2 1/3] ASoC: msm8916: Add codec Device Tree bindings.

This patch adds DT bindings required for msm8916 codec which is integrated in msm8916 and apq8016 SOCs. Codec IP is divided into two parts, first analog which is integrated in pmic pm8916 and secondly digital part which is integrated into application processor. Codec register controls are also

[RFC v2 1/3] ASoC: msm8916: Add codec Device Tree bindings.

This patch adds DT bindings required for msm8916 codec which is integrated in msm8916 and apq8016 SOCs. Codec IP is divided into two parts, first analog which is integrated in pmic pm8916 and secondly digital part which is integrated into application processor. Codec register controls are also

[RFC v2 3/3] ASoC: msm8916: Add msm8916-wcd codec driver

This patch adds support to msm8916-wcd codec. msm8916-wcd codec is found in Qualcomm msm8916 and apq8016 processors. This codec IP is split in to two parts(Digital & Analog), Analog part is integrated in to PMIC PM8916 and the digital part is integrated into Application processor. Register access

[RFC v2 3/3] ASoC: msm8916: Add msm8916-wcd codec driver

This patch adds support to msm8916-wcd codec. msm8916-wcd codec is found in Qualcomm msm8916 and apq8016 processors. This codec IP is split in to two parts(Digital & Analog), Analog part is integrated in to PMIC PM8916 and the digital part is integrated into Application processor. Register access

[RFC v2 0/3] ASoC: Add support to Qualcomm msm8916-wcd codec

This patchset aims at adding msm8916-wcd codec support. msm8916-wcd codec is found in Qualcomm msm8916 and apq8016 processors. This codec IP is split in to two parts(Digital & Analog), Analog part is integrated in to PMIC PM8916 and the digital part is integrated into Application processor.

[RFC v2 0/3] ASoC: Add support to Qualcomm msm8916-wcd codec

This patchset aims at adding msm8916-wcd codec support. msm8916-wcd codec is found in Qualcomm msm8916 and apq8016 processors. This codec IP is split in to two parts(Digital & Analog), Analog part is integrated in to PMIC PM8916 and the digital part is integrated into Application processor.

Re: [PATCH v8 0/4] ACPI: parse the SPCR table

On 05/20/2016 04:03 PM, Aleksey Makarov wrote: > 'ARM Server Base Boot Requirements' [1] mentions SPCR (Serial Port Console > Redirection Table) [2] as a mandatory ACPI table that specifies the > configuration of serial console. Hi Russell, Can you review these patches and consider ACKing the

Re: [PATCH v8 0/4] ACPI: parse the SPCR table

On 05/20/2016 04:03 PM, Aleksey Makarov wrote: > 'ARM Server Base Boot Requirements' [1] mentions SPCR (Serial Port Console > Redirection Table) [2] as a mandatory ACPI table that specifies the > configuration of serial console. Hi Russell, Can you review these patches and consider ACKing the

Re: [4.1.x -- 4.6.x and probably HEAD] Reproducible unprivileged panic/TLB BUG on sparc via a stack-protected rt_sigaction() ka_restorer, courtesy of the glibc testsuite

On 27 May 2016, John Paul Adrian Glaubitz outgrape: > Hi Nick! > > On 05/27/2016 03:19 PM, Nick Alcock wrote: >> So I've been working on a patch series (see below) that applies GCC's >> -fstack-protector{-all,-strong} to almost all of glibc bar the dynamic >> linker. In trying to upstream it, one

Re: [4.1.x -- 4.6.x and probably HEAD] Reproducible unprivileged panic/TLB BUG on sparc via a stack-protected rt_sigaction() ka_restorer, courtesy of the glibc testsuite

On 27 May 2016, John Paul Adrian Glaubitz outgrape: > Hi Nick! > > On 05/27/2016 03:19 PM, Nick Alcock wrote: >> So I've been working on a patch series (see below) that applies GCC's >> -fstack-protector{-all,-strong} to almost all of glibc bar the dynamic >> linker. In trying to upstream it, one

[PATCH v8 2/3] i2c: tegra: add separate function for config_load programing

Define separate function for configuration load register handling to make it use by different functions later. Signed-off-by: Shardar Shariff Md --- Changes in v2: - Remove unnecessary paranthesis and align to 80 characters per line Changes in v3: - Add separate function

[PATCH v8 2/3] i2c: tegra: add separate function for config_load programing

Define separate function for configuration load register handling to make it use by different functions later. Signed-off-by: Shardar Shariff Md --- Changes in v2: - Remove unnecessary paranthesis and align to 80 characters per line Changes in v3: - Add separate function for config load

Re: [PATCH 2/2] sched/fair: Skip detach and attach load avgs for new group task

On 26 May 2016 at 21:44, Yuyang Du wrote: > Hi Vincent, > > On Thu, May 26, 2016 at 01:50:56PM +0200, Vincent Guittot wrote: >> On 26 May 2016 at 03:14, Yuyang Du wrote: >> > Vincent reported that the first task to a new task group's cfs_rq will >> > be

[PATCH v8 1/3] i2c: tegra: use readx_poll_timeout after config_load reg programmed

After CONFIG_LOAD register programing instead of explicitly waiting for timeout, use readx_poll_timeout() to check for register value to get updated or wait till timeout. Signed-off-by: Shardar Shariff Md --- Changes in v4: - Split timeout calculation to separate patch

Re: [PATCH 2/2] sched/fair: Skip detach and attach load avgs for new group task

On 26 May 2016 at 21:44, Yuyang Du wrote: > Hi Vincent, > > On Thu, May 26, 2016 at 01:50:56PM +0200, Vincent Guittot wrote: >> On 26 May 2016 at 03:14, Yuyang Du wrote: >> > Vincent reported that the first task to a new task group's cfs_rq will >> > be attached in attach_task_cfs_rq() and once

[PATCH v8 1/3] i2c: tegra: use readx_poll_timeout after config_load reg programmed

After CONFIG_LOAD register programing instead of explicitly waiting for timeout, use readx_poll_timeout() to check for register value to get updated or wait till timeout. Signed-off-by: Shardar Shariff Md --- Changes in v4: - Split timeout calculation to separate patch Changes in v5: - Move

[PATCH v8 3/3] i2c: tegra: proper handling of error cases

To summarize the issue observed in error cases: SW Flow: For i2c message transfer, packet header and data payload is posted and then required error/packet completion interrupts are enabled later. HW flow: HW process the packet just after packet header is posted, if ARB lost/NACK error occurs (SW

[PATCH v8 3/3] i2c: tegra: proper handling of error cases

To summarize the issue observed in error cases: SW Flow: For i2c message transfer, packet header and data payload is posted and then required error/packet completion interrupts are enabled later. HW flow: HW process the packet just after packet header is posted, if ARB lost/NACK error occurs (SW

Re: [PATCH] drivers: usb: dwc3 : Configure DMA properties and ops from DT

Hi, Leo Li writes: >> Leo Li writes: > On certain platforms (e.g. ARM64) the dma_ops needs to be explicitly set > to be able to do DMA allocations, so use the of_dma_configure() helper > to populate the dma properties and assign an appropriate

Re: [4.1.x -- 4.6.x and probably HEAD] Reproducible unprivileged panic/TLB BUG on sparc via a stack-protected rt_sigaction() ka_restorer, courtesy of the glibc testsuite

Hi Nick! On 05/27/2016 03:19 PM, Nick Alcock wrote: > So I've been working on a patch series (see below) that applies GCC's > -fstack-protector{-all,-strong} to almost all of glibc bar the dynamic > linker. In trying to upstream it, one review commenter queried one > SPARC-specific patch in the

Re: [PATCH] drivers: usb: dwc3 : Configure DMA properties and ops from DT

Hi, Leo Li writes: >> Leo Li writes: > On certain platforms (e.g. ARM64) the dma_ops needs to be explicitly set > to be able to do DMA allocations, so use the of_dma_configure() helper > to populate the dma properties and assign an appropriate dma_ops. > > Signed-off-by:

Re: [4.1.x -- 4.6.x and probably HEAD] Reproducible unprivileged panic/TLB BUG on sparc via a stack-protected rt_sigaction() ka_restorer, courtesy of the glibc testsuite

Hi Nick! On 05/27/2016 03:19 PM, Nick Alcock wrote: > So I've been working on a patch series (see below) that applies GCC's > -fstack-protector{-all,-strong} to almost all of glibc bar the dynamic > linker. In trying to upstream it, one review commenter queried one > SPARC-specific patch in the

[PATCH 2/2] usb: phy: phy-brcm-usb: Add Broadcom STB USB Phy driver

Add a new USB Phy driver for Broadcom STB SoCs. This driver supports all Broadcom STB ARM SoCs. This driver in combination with the generic ohci, ehci and xhci platform drivers will enable USB1.1, USB2.0 and USB3.0 support. This Phy driver also supports the Broadcom UDC gadget driver.

[PATCH 2/2] usb: phy: phy-brcm-usb: Add Broadcom STB USB Phy driver

Add a new USB Phy driver for Broadcom STB SoCs. This driver supports all Broadcom STB ARM SoCs. This driver in combination with the generic ohci, ehci and xhci platform drivers will enable USB1.1, USB2.0 and USB3.0 support. This Phy driver also supports the Broadcom UDC gadget driver.

[PATCH 0/2] Add Broadcom USB PHY driver for Broadcom STB SoCs

Add Broadcom USB PHY driver for Broadcom STB SoCs. This driver in combination with the generic ohci, ehci and xhci platform drivers will enable USB1.1, USB2.0 and USB3.0 support. NOTE: An unrelated patch is in the pipline to move the file drivers/soc/brcmstb/common.c to

[PATCH 0/2] Add Broadcom USB PHY driver for Broadcom STB SoCs

Add Broadcom USB PHY driver for Broadcom STB SoCs. This driver in combination with the generic ohci, ehci and xhci platform drivers will enable USB1.1, USB2.0 and USB3.0 support. NOTE: An unrelated patch is in the pipline to move the file drivers/soc/brcmstb/common.c to

[PATCH 1/2] soc: brcmstb: Add Product ID and Family ID helper functions

Signed-off-by: Al Cooper --- drivers/soc/brcmstb/common.c| 12 include/linux/soc/brcmstb/brcmstb.h | 10 ++ 2 files changed, 22 insertions(+) diff --git a/drivers/soc/brcmstb/common.c b/drivers/soc/brcmstb/common.c index 94e7335..454f4c2 100644

[PATCH 1/2] soc: brcmstb: Add Product ID and Family ID helper functions

Signed-off-by: Al Cooper --- drivers/soc/brcmstb/common.c| 12 include/linux/soc/brcmstb/brcmstb.h | 10 ++ 2 files changed, 22 insertions(+) diff --git a/drivers/soc/brcmstb/common.c b/drivers/soc/brcmstb/common.c index 94e7335..454f4c2 100644 ---

Re: [PATCH v2 2/8] [media] Add signed 16-bit pixel format

On 27/05/2016 14:18, Hans Verkuil wrote: > On 05/27/2016 02:52 PM, Nick Dyer wrote: >> On 27/05/2016 13:38, Hans Verkuil wrote: >>> On 05/04/2016 07:07 PM, Nick Dyer wrote: +V4L2_PIX_FMT_YS16 +Grey-scale image + + +Description + +This is a

Re: [PATCH v2 2/8] [media] Add signed 16-bit pixel format

On 27/05/2016 14:18, Hans Verkuil wrote: > On 05/27/2016 02:52 PM, Nick Dyer wrote: >> On 27/05/2016 13:38, Hans Verkuil wrote: >>> On 05/04/2016 07:07 PM, Nick Dyer wrote: +V4L2_PIX_FMT_YS16 +Grey-scale image + + +Description + +This is a

Re: [PATCH] hwrng: stm32 - fix build warning

On Wednesday 25 May 2016 03:36 PM, Arnd Bergmann wrote: On Wednesday, May 25, 2016 7:35:17 AM CEST Sudip Mukherjee wrote: On Tuesday 24 May 2016 02:05 AM, Arnd Bergmann wrote: On Monday, May 23, 2016 6:14:08 PM CEST Sudip Mukherjee wrote: We have been getting build warning about:

Re: [PATCH] hwrng: stm32 - fix build warning

On Wednesday 25 May 2016 03:36 PM, Arnd Bergmann wrote: On Wednesday, May 25, 2016 7:35:17 AM CEST Sudip Mukherjee wrote: On Tuesday 24 May 2016 02:05 AM, Arnd Bergmann wrote: On Monday, May 23, 2016 6:14:08 PM CEST Sudip Mukherjee wrote: We have been getting build warning about:

Re: [RFC/PATCH 1/2] doc: bindings: Add bindings documentation for mtd otp nvmem

Hi Moritz, On Thu, 26 May 2016 10:28:48 -0700 Moritz Fischer wrote: > Hi Boris, > > On Thu, May 26, 2016 at 1:04 AM, Boris Brezillon > wrote: > > > I think the MTD partition -> nvmem connection could benefit to non-OTP > >

Re: [RFC/PATCH 1/2] doc: bindings: Add bindings documentation for mtd otp nvmem

Hi Moritz, On Thu, 26 May 2016 10:28:48 -0700 Moritz Fischer wrote: > Hi Boris, > > On Thu, May 26, 2016 at 1:04 AM, Boris Brezillon > wrote: > > > I think the MTD partition -> nvmem connection could benefit to non-OTP > > partitions too. > > Yeah, I thought about that, too. Would you use

Re: [PATCH v2 1/2] media: Media Device Allocator API

On 05/25/2016 01:39 AM, Shuah Khan wrote: > Media Device Allocator API to allows multiple drivers share a media device. > Using this API, drivers can allocate a media device with the shared struct > device as the key. Once the media device is allocated by a driver, other > drivers can get a

Re: [PATCH v2 1/2] media: Media Device Allocator API

On 05/25/2016 01:39 AM, Shuah Khan wrote: > Media Device Allocator API to allows multiple drivers share a media device. > Using this API, drivers can allocate a media device with the shared struct > device as the key. Once the media device is allocated by a driver, other > drivers can get a

Re: [PATCH] dell-smm-hwmon: Cache fan_type() calls and use fan_status() for fan detection

On Friday 27 May 2016 15:05:54 Thorsten Leemhuis wrote: > Pali Rohár wrote on 27.05.2016 12:45: > > […] > > Looks like there are two different problems with dell-smm-hwmon > > driver: 1) Fan speed going randomly up and down without system > > freeze […] > > So for problem 1) I need to know: > > >

Re: [PATCH] dell-smm-hwmon: Cache fan_type() calls and use fan_status() for fan detection

On Friday 27 May 2016 15:05:54 Thorsten Leemhuis wrote: > Pali Rohár wrote on 27.05.2016 12:45: > > […] > > Looks like there are two different problems with dell-smm-hwmon > > driver: 1) Fan speed going randomly up and down without system > > freeze […] > > So for problem 1) I need to know: > > >

[4.1.x -- 4.6.x and probably HEAD] Reproducible unprivileged panic/TLB BUG on sparc via a stack-protected rt_sigaction() ka_restorer, courtesy of the glibc testsuite

[Resent with fixed address for sparclinux@; sorry!] So I've been working on a patch series (see below) that applies GCC's -fstack-protector{-all,-strong} to almost all of glibc bar the dynamic linker. In trying to upstream it, one review commenter queried one SPARC-specific patch in the series;

[4.1.x -- 4.6.x and probably HEAD] Reproducible unprivileged panic/TLB BUG on sparc via a stack-protected rt_sigaction() ka_restorer, courtesy of the glibc testsuite

[Resent with fixed address for sparclinux@; sorry!] So I've been working on a patch series (see below) that applies GCC's -fstack-protector{-all,-strong} to almost all of glibc bar the dynamic linker. In trying to upstream it, one review commenter queried one SPARC-specific patch in the series;

Re: [PATCH v2 2/8] [media] Add signed 16-bit pixel format

On 05/27/2016 02:52 PM, Nick Dyer wrote: > On 27/05/2016 13:38, Hans Verkuil wrote: >> On 05/04/2016 07:07 PM, Nick Dyer wrote: >>> +V4L2_PIX_FMT_YS16 >>> +Grey-scale image >>> + >>> + >>> +Description >>> + >>> +This is a signed grey-scale image with a depth of 16 bits per >>>

Re: [PATCH v2 2/8] [media] Add signed 16-bit pixel format

On 05/27/2016 02:52 PM, Nick Dyer wrote: > On 27/05/2016 13:38, Hans Verkuil wrote: >> On 05/04/2016 07:07 PM, Nick Dyer wrote: >>> +V4L2_PIX_FMT_YS16 >>> +Grey-scale image >>> + >>> + >>> +Description >>> + >>> +This is a signed grey-scale image with a depth of 16 bits per >>>

Re: [PATCH v4 01/18] remoteproc: st_xp70_rproc: add a xp70 slimcore rproc driver

On 05/25/2016 06:06 PM, Peter Griffin wrote: XP70 slim core is used as a basis for many IPs in the STi chipsets such as fdma, display, and demux. To avoid duplicating the elf loading code in each device driver an xp70 rproc driver has been created. This driver is designed to be used by other

Re: [PATCH v4 01/18] remoteproc: st_xp70_rproc: add a xp70 slimcore rproc driver

On 05/25/2016 06:06 PM, Peter Griffin wrote: XP70 slim core is used as a basis for many IPs in the STi chipsets such as fdma, display, and demux. To avoid duplicating the elf loading code in each device driver an xp70 rproc driver has been created. This driver is designed to be used by other

Re: [PATCH 0/3] mm, thp: remove duplication and fix locking issues in swapin

On Mon 23-05-16 20:29:29, Ebru Akagunduz wrote: > On Mon, May 23, 2016 at 08:14:08PM +0300, Ebru Akagunduz wrote: > > This patch series removes duplication of included header > > and fixes locking inconsistency in khugepaged swapin > > > > Ebru Akagunduz (3): > > mm, thp: remove duplication of

Re: [PATCH 0/3] mm, thp: remove duplication and fix locking issues in swapin

On Mon 23-05-16 20:29:29, Ebru Akagunduz wrote: > On Mon, May 23, 2016 at 08:14:08PM +0300, Ebru Akagunduz wrote: > > This patch series removes duplication of included header > > and fixes locking inconsistency in khugepaged swapin > > > > Ebru Akagunduz (3): > > mm, thp: remove duplication of

[PATCH] iwlwifi: mvm: avoid harmless -Wmaybe-uninialized warning

gcc is apparently unablel to track the state of the local 'resp_v2' variable across the kzalloc() function, and warns about the response variable being used without an initialization: drivers/net/wireless/intel/iwlwifi/mvm/nvm.c: In function ‘iwl_mvm_update_mcc’:

[PATCH] iwlwifi: mvm: avoid harmless -Wmaybe-uninialized warning

gcc is apparently unablel to track the state of the local 'resp_v2' variable across the kzalloc() function, and warns about the response variable being used without an initialization: drivers/net/wireless/intel/iwlwifi/mvm/nvm.c: In function ‘iwl_mvm_update_mcc’:

Re: [PATCH] dell-smm-hwmon: Cache fan_type() calls and use fan_status() for fan detection

Pali Rohár wrote on 27.05.2016 12:45: > […] > Looks like there are two different problems with dell-smm-hwmon driver: > 1) Fan speed going randomly up and down without system freeze > […] > So for problem 1) I need to know: > > * Is it regression? […] Yes, it is known to be a regression from

Re: [PATCH] dell-smm-hwmon: Cache fan_type() calls and use fan_status() for fan detection

Pali Rohár wrote on 27.05.2016 12:45: > […] > Looks like there are two different problems with dell-smm-hwmon driver: > 1) Fan speed going randomly up and down without system freeze > […] > So for problem 1) I need to know: > > * Is it regression? […] Yes, it is known to be a regression from

Re: [PATCH 01/23] all: syscall wrappers: add documentation

On Fri, May 27, 2016 at 12:49:11PM +0200, Arnd Bergmann wrote: > On Friday, May 27, 2016 10:30:52 AM CEST Catalin Marinas wrote: > > On Fri, May 27, 2016 at 10:42:59AM +0200, Arnd Bergmann wrote: > > > On Friday, May 27, 2016 8:03:57 AM CEST Heiko Carstens wrote: > > > > > > > > Cost wise, this

Re: [PATCH 01/23] all: syscall wrappers: add documentation

On Fri, May 27, 2016 at 12:49:11PM +0200, Arnd Bergmann wrote: > On Friday, May 27, 2016 10:30:52 AM CEST Catalin Marinas wrote: > > On Fri, May 27, 2016 at 10:42:59AM +0200, Arnd Bergmann wrote: > > > On Friday, May 27, 2016 8:03:57 AM CEST Heiko Carstens wrote: > > > > > > > > Cost wise, this

[PATCH 08/15] mtd: nand: move hynix specific initialization in nand_hynix.c

Moving Hynix specific initialization into nand_hynix.c. This is part of the "separate vendor specific code from core" cleanup process. Signed-off-by: Boris Brezillon --- drivers/mtd/nand/Makefile | 1 + drivers/mtd/nand/nand_base.c | 108

[PATCH 08/15] mtd: nand: move hynix specific initialization in nand_hynix.c

Moving Hynix specific initialization into nand_hynix.c. This is part of the "separate vendor specific code from core" cleanup process. Signed-off-by: Boris Brezillon --- drivers/mtd/nand/Makefile | 1 + drivers/mtd/nand/nand_base.c | 108 ++

[PATCH 01/15] mtd: nand: get rid of the mtd parameter in all auto-detection functions

Now that struct nand_chip embeds an mtd_info object we can get rid of the mtd parameter and extract it from the chip parameter with the nand_to_mtd() helper. Signed-off-by: Boris Brezillon --- drivers/mtd/nand/nand_base.c | 56

[PATCH 10/15] mtd: nand: move micron specific initialization in nand_micron.c

Moving Micron specific initialization into nand_micron.c. This is part of the "separate vendor specific code from core" cleanup process. Signed-off-by: Boris Brezillon --- drivers/mtd/nand/Makefile | 1 + drivers/mtd/nand/nand_base.c | 31

[PATCH 11/15] mtd: nand: move AMD/Spansion specific initialization in nand_amd.c

Moving AMD/Spansion specific initialization into nand_amd.c. This is part of the "separate vendor specific code from core" cleanup process. Signed-off-by: Boris Brezillon --- drivers/mtd/nand/Makefile| 1 + drivers/mtd/nand/nand_amd.c | 60

[PATCH 03/15] mtd: nand: get rid of busw parameter

Auto-detection functions are passed a busw parameter to retrieve the actual NAND bus width and eventually set the correct value in chip->options. Rework the nand_get_flash_type() function to get rid of this extra parameter and let detection code directly set the NAND_BUSWIDTH_16 flag in

[PATCH 01/15] mtd: nand: get rid of the mtd parameter in all auto-detection functions

Now that struct nand_chip embeds an mtd_info object we can get rid of the mtd parameter and extract it from the chip parameter with the nand_to_mtd() helper. Signed-off-by: Boris Brezillon --- drivers/mtd/nand/nand_base.c | 56 1 file changed, 30

[PATCH 10/15] mtd: nand: move micron specific initialization in nand_micron.c

Moving Micron specific initialization into nand_micron.c. This is part of the "separate vendor specific code from core" cleanup process. Signed-off-by: Boris Brezillon --- drivers/mtd/nand/Makefile | 1 + drivers/mtd/nand/nand_base.c | 31 +--- drivers/mtd/nand/nand_ids.c

[PATCH 11/15] mtd: nand: move AMD/Spansion specific initialization in nand_amd.c

Moving AMD/Spansion specific initialization into nand_amd.c. This is part of the "separate vendor specific code from core" cleanup process. Signed-off-by: Boris Brezillon --- drivers/mtd/nand/Makefile| 1 + drivers/mtd/nand/nand_amd.c | 60

[PATCH 03/15] mtd: nand: get rid of busw parameter

Auto-detection functions are passed a busw parameter to retrieve the actual NAND bus width and eventually set the correct value in chip->options. Rework the nand_get_flash_type() function to get rid of this extra parameter and let detection code directly set the NAND_BUSWIDTH_16 flag in

[PATCH 00/15] mtd: nand: allow vendor specific detection/initialization

Hello, This patch series is a step forward in supporting vendor-specific functionalities. This series is mainly moving vendor-specific initialization or detection code out of the core, but also introduces an infrastructure allowing support for vendor-specific features. While those features might

[PATCH 00/15] mtd: nand: allow vendor specific detection/initialization

Hello, This patch series is a step forward in supporting vendor-specific functionalities. This series is mainly moving vendor-specific initialization or detection code out of the core, but also introduces an infrastructure allowing support for vendor-specific features. While those features might

[PATCH 04/15] mtd: nand: rename nand_get_flash_type() into nand_detect()

The only caller of nand_get_flash_type() (nand_scan_ident()) actually don't use the returned nand_flash_dev pointer except for converting it to to an error code. Rename this function nand_detect() and make it return an integer. Signed-off-by: Boris Brezillon

[PATCH 12/15] mtd: nand: move Macronix specific initialization in nand_macronix.c

Moving Macronix specific initialization into nand_macronix.c. This is part of the "separate vendor specific code from core" cleanup process. Signed-off-by: Boris Brezillon --- drivers/mtd/nand/Makefile| 1 + drivers/mtd/nand/nand_base.c | 11

[PATCH 04/15] mtd: nand: rename nand_get_flash_type() into nand_detect()

The only caller of nand_get_flash_type() (nand_scan_ident()) actually don't use the returned nand_flash_dev pointer except for converting it to to an error code. Rename this function nand_detect() and make it return an integer. Signed-off-by: Boris Brezillon --- drivers/mtd/nand/nand_base.c |

[PATCH 12/15] mtd: nand: move Macronix specific initialization in nand_macronix.c

Moving Macronix specific initialization into nand_macronix.c. This is part of the "separate vendor specific code from core" cleanup process. Signed-off-by: Boris Brezillon --- drivers/mtd/nand/Makefile| 1 + drivers/mtd/nand/nand_base.c | 11 --- drivers/mtd/nand/nand_ids.c

[PATCH 06/15] mtd: nand: kill the MTD_NAND_IDS Kconfig option

MTD_NAND_IDS is selected by MTD_NAND, which makes it useless. Remove the Kconfig option and link nand_ids.o into the nand.o object file. Doing that also prevents adding an extra nand_ids.ko module when MTD_NAND is activated as a module. Signed-off-by: Boris Brezillon

[PATCH 05/15] mtd: nand: add vendor specific initialization step

A lot of NANDs are implementing generic features in a non-generic way, or are providing advanced auto-detection logic where the NAND ID bytes meaning changes with the NAND generation. Providing this vendor specific initialization step will allow us to get rid of the full ids in the nand_ids table

[PATCH 07/15] mtd: nand: move samsung specific initialization in nand_samsung.c

Moving Samsung specific initialization into nand_samsung.c. This is part of the "separate vendor specific code from core" cleanup process. Signed-off-by: Boris Brezillon --- drivers/mtd/nand/Makefile | 1 + drivers/mtd/nand/nand_base.c| 52

[PATCH 06/15] mtd: nand: kill the MTD_NAND_IDS Kconfig option

MTD_NAND_IDS is selected by MTD_NAND, which makes it useless. Remove the Kconfig option and link nand_ids.o into the nand.o object file. Doing that also prevents adding an extra nand_ids.ko module when MTD_NAND is activated as a module. Signed-off-by: Boris Brezillon ---

[PATCH 05/15] mtd: nand: add vendor specific initialization step

A lot of NANDs are implementing generic features in a non-generic way, or are providing advanced auto-detection logic where the NAND ID bytes meaning changes with the NAND generation. Providing this vendor specific initialization step will allow us to get rid of the full ids in the nand_ids table

[PATCH 07/15] mtd: nand: move samsung specific initialization in nand_samsung.c

Moving Samsung specific initialization into nand_samsung.c. This is part of the "separate vendor specific code from core" cleanup process. Signed-off-by: Boris Brezillon --- drivers/mtd/nand/Makefile | 1 + drivers/mtd/nand/nand_base.c| 52 ++--

[PATCH 09/15] mtd: nand: move toshiba specific initialization in nand_toshiba.c

Moving Hynix specific initialization into nand_toshiba.c. This is part of the "separate vendor specific code from core" cleanup process. Signed-off-by: Boris Brezillon --- drivers/mtd/nand/Makefile | 1 + drivers/mtd/nand/nand_base.c| 19

Re: [PATCH] arm64: defconfig: Enable cros-ec and battery driver

On 05/27/2016 02:17 PM, Jon Hunter wrote: > > On 27/05/16 12:46, Krzysztof Kozlowski wrote: >> On 05/27/2016 12:28 PM, Jon Hunter wrote: >>> Hi Krzysztof, >>> >>> On 27/05/16 09:37, Krzysztof Kozlowski wrote: >>> >>> ... >>> Indeed I was struggling with similar issue in bq27x00_battery. The

Re: [PATCH v3 2/5] usb: dwc3: add dis_u2_freeclk_exists_quirk

Hi, William Wu writes: > Add a quirk to clear the GUSB2PHYCFG.U2_FREECLK_EXISTS bit, > which specifies whether the USB2.0 PHY provides a free-running > PHY clock, which is active when the clock control input is active. > > Signed-off-by: William Wu

[PATCH 13/15] mtd: nand: samsung: retrieve ECC requirements from extended ID

From: Hans de Goede On some nand controllers with hw-ecc the controller code wants to know the ecc strength and size and having these as 0, 0 is not accepted. Specifying these in devicetree is possible but undesirable as the nand may be different in different production

[PATCH 09/15] mtd: nand: move toshiba specific initialization in nand_toshiba.c

Moving Hynix specific initialization into nand_toshiba.c. This is part of the "separate vendor specific code from core" cleanup process. Signed-off-by: Boris Brezillon --- drivers/mtd/nand/Makefile | 1 + drivers/mtd/nand/nand_base.c| 19 ++--- drivers/mtd/nand/nand_ids.c

Re: [PATCH] arm64: defconfig: Enable cros-ec and battery driver

On 05/27/2016 02:17 PM, Jon Hunter wrote: > > On 27/05/16 12:46, Krzysztof Kozlowski wrote: >> On 05/27/2016 12:28 PM, Jon Hunter wrote: >>> Hi Krzysztof, >>> >>> On 27/05/16 09:37, Krzysztof Kozlowski wrote: >>> >>> ... >>> Indeed I was struggling with similar issue in bq27x00_battery. The

Re: [PATCH v3 2/5] usb: dwc3: add dis_u2_freeclk_exists_quirk

Hi, William Wu writes: > Add a quirk to clear the GUSB2PHYCFG.U2_FREECLK_EXISTS bit, > which specifies whether the USB2.0 PHY provides a free-running > PHY clock, which is active when the clock control input is active. > > Signed-off-by: William Wu can you rebase on top of my testing/next?

[PATCH 13/15] mtd: nand: samsung: retrieve ECC requirements from extended ID

From: Hans de Goede On some nand controllers with hw-ecc the controller code wants to know the ecc strength and size and having these as 0, 0 is not accepted. Specifying these in devicetree is possible but undesirable as the nand may be different in different production runs of the same board,

Re: [PATCH v2 8/8] Input: atmel_mxt_ts - add support for reference data

On 05/04/2016 07:07 PM, Nick Dyer wrote: > There are different datatypes available from a maXTouch chip. Add > support to retrieve reference data as well. > > Signed-off-by: Nick Dyer > --- > drivers/input/touchscreen/atmel_mxt_ts.c | 66 >

Re: [PATCH v2 8/8] Input: atmel_mxt_ts - add support for reference data

On 05/04/2016 07:07 PM, Nick Dyer wrote: > There are different datatypes available from a maXTouch chip. Add > support to retrieve reference data as well. > > Signed-off-by: Nick Dyer > --- > drivers/input/touchscreen/atmel_mxt_ts.c | 66 > +++- > 1 file changed, 56

[PATCH 14/15] mtd: nand: hynix: rework NAND ID decoding to extract more information

The current NAND ID detection in nand_hynix.c is not handling the different scheme used by Hynix, thus forcing developers to add new entries in the nand_ids table each time they want to support a new MLC NAND. Enhance the detection logic to handle all known formats. This does not necessarily mean

[PATCH 02/15] mtd: nand: store nand ID in struct nand_chip

Store the NAND ID in struct nand_chip to avoid passing id_data and id_len as function parameters. Signed-off-by: Boris Brezillon --- drivers/mtd/nand/nand_base.c | 55 include/linux/mtd/nand.h | 13 +++

[PATCH 02/15] mtd: nand: store nand ID in struct nand_chip

Store the NAND ID in struct nand_chip to avoid passing id_data and id_len as function parameters. Signed-off-by: Boris Brezillon --- drivers/mtd/nand/nand_base.c | 55 include/linux/mtd/nand.h | 13 +++ 2 files changed, 43 insertions(+),

[PATCH 14/15] mtd: nand: hynix: rework NAND ID decoding to extract more information

The current NAND ID detection in nand_hynix.c is not handling the different scheme used by Hynix, thus forcing developers to add new entries in the nand_ids table each time they want to support a new MLC NAND. Enhance the detection logic to handle all known formats. This does not necessarily mean

[PATCH 15/15] mtd: nand: hynix: add read-retry support for 1x nm MLC NANDs

All Hynix MLC NANDs using the produced with the 1X nm process support read-retry. This read retry implementation should also be reusable for other Hynix NANDs, but the method to retrieve the read-retry parameters from the read-retry OTP area might change a bit (some NANDs are even using a fixed

[PATCH 15/15] mtd: nand: hynix: add read-retry support for 1x nm MLC NANDs

All Hynix MLC NANDs using the produced with the 1X nm process support read-retry. This read retry implementation should also be reusable for other Hynix NANDs, but the method to retrieve the read-retry parameters from the read-retry OTP area might change a bit (some NANDs are even using a fixed

Re: [PATCH v2 4/8] Input: atmel_mxt_ts - output diagnostic debug via v4l2 device

Hi Nick, On 05/04/2016 07:07 PM, Nick Dyer wrote: > Register a video device to output T37 diagnostic data. > > Signed-off-by: Nick Dyer > --- > drivers/input/touchscreen/Kconfig| 2 + > drivers/input/touchscreen/atmel_mxt_ts.c | 271 >

Re: [PATCH v2 4/8] Input: atmel_mxt_ts - output diagnostic debug via v4l2 device

Hi Nick, On 05/04/2016 07:07 PM, Nick Dyer wrote: > Register a video device to output T37 diagnostic data. > > Signed-off-by: Nick Dyer > --- > drivers/input/touchscreen/Kconfig| 2 + > drivers/input/touchscreen/atmel_mxt_ts.c | 271 > +++ > 2 files

Re: [PATCH v2 2/8] [media] Add signed 16-bit pixel format

On 27/05/2016 13:38, Hans Verkuil wrote: > On 05/04/2016 07:07 PM, Nick Dyer wrote: >> +V4L2_PIX_FMT_YS16 >> +Grey-scale image >> + >> + >> +Description >> + >> +This is a signed grey-scale image with a depth of 16 bits per >> +pixel. The most significant byte is stored at

Re: [PATCH v2 2/8] [media] Add signed 16-bit pixel format

On 27/05/2016 13:38, Hans Verkuil wrote: > On 05/04/2016 07:07 PM, Nick Dyer wrote: >> +V4L2_PIX_FMT_YS16 >> +Grey-scale image >> + >> + >> +Description >> + >> +This is a signed grey-scale image with a depth of 16 bits per >> +pixel. The most significant byte is stored at

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