Re: [RFC] coccicheck: add a test for repeat memory fetches

> 在 2017年1月10日，下午2:06，Julia Lawall 写道： > > > > On Mon, 9 Jan 2017, Kees Cook wrote: > >> Okay, this adds a few tests, for people to examine. >> >> reusercopy-cook.cocci: >> My original test, with recent updates from Julia. >> >> reusercopy-wang.cocci: >> This is

Re: [RFC] coccicheck: add a test for repeat memory fetches

> 在 2017年1月10日，下午2:06，Julia Lawall 写道： > > > > On Mon, 9 Jan 2017, Kees Cook wrote: > >> Okay, this adds a few tests, for people to examine. >> >> reusercopy-cook.cocci: >> My original test, with recent updates from Julia. >> >> reusercopy-wang.cocci: >> This is Pengfei's test, but with

[V2 1/2] document: dt: add binding for Hi3660 SoC

Add binding for hisilicon Hi3660 SoC and HiKey960 Board. Signed-off-by: Chen Feng Acked-by: Rob Herring --- Documentation/devicetree/bindings/arm/hisilicon/hisilicon.txt | 4 1 file changed, 4 insertions(+) diff --git

[V2 1/2] document: dt: add binding for Hi3660 SoC

Add binding for hisilicon Hi3660 SoC and HiKey960 Board. Signed-off-by: Chen Feng Acked-by: Rob Herring --- Documentation/devicetree/bindings/arm/hisilicon/hisilicon.txt | 4 1 file changed, 4 insertions(+) diff --git a/Documentation/devicetree/bindings/arm/hisilicon/hisilicon.txt

Re: [PATCH] [media] atmel-isc: add the isc pipeline function

Hi Hans, Thank you for your comments. On 1/9/2017 20:10, Hans Verkuil wrote: + +static int isc_s_ctrl(struct v4l2_ctrl *ctrl) +{ + struct isc_device *isc = container_of(ctrl->handler, +struct isc_device, ctrls.handler); + struct isc_ctrls

Re: [PATCH] [media] atmel-isc: add the isc pipeline function

Hi Hans, Thank you for your comments. On 1/9/2017 20:10, Hans Verkuil wrote: + +static int isc_s_ctrl(struct v4l2_ctrl *ctrl) +{ + struct isc_device *isc = container_of(ctrl->handler, +struct isc_device, ctrls.handler); + struct isc_ctrls

Re: [PATCH v6 1/2] ARM: dts: vf610-zii-dev-rev-b: Remove leftover PWM pingroup

On Mon, Jan 09, 2017 at 11:35:54PM -0800, Andrey Smirnov wrote: > Remove pwm0grp since it is: > > a) Not referenced anywhere in the DTS file (unlike Tower board it > is based on, this board does not use/expose FTM0) > > b) Configures PTB2 and PTB3 in a way that contradicts >

Re: [PATCH v6 1/2] ARM: dts: vf610-zii-dev-rev-b: Remove leftover PWM pingroup

On Mon, Jan 09, 2017 at 11:35:54PM -0800, Andrey Smirnov wrote: > Remove pwm0grp since it is: > > a) Not referenced anywhere in the DTS file (unlike Tower board it > is based on, this board does not use/expose FTM0) > > b) Configures PTB2 and PTB3 in a way that contradicts >

[V2 1/2] document: dt: add binding for Hi3660 SoC

Add binding for hisilicon Hi3660 SoC and HiKey960 Board. Signed-off-by: Chen Feng Acked-by: Rob Herring --- Documentation/devicetree/bindings/arm/hisilicon/hisilicon.txt | 4 1 file changed, 4 insertions(+) diff --git

[V2 2/2] Add initial dtsi file to support Hisilicon Hi3660 SoC with support of Octal core CPUs in two clusters(4 * A53 & 4 * A73).

Also add dts file to support HiKey960 development board which based on Hi3660 SoC. The output console is earlycon "earlycon=pl011,0xfdf05000". And the con_init uart5 with a fixed clock, which already configured at bootloader. When clock is available, the uart5 will be modified. Tested on

[V2 1/2] document: dt: add binding for Hi3660 SoC

Add binding for hisilicon Hi3660 SoC and HiKey960 Board. Signed-off-by: Chen Feng Acked-by: Rob Herring --- Documentation/devicetree/bindings/arm/hisilicon/hisilicon.txt | 4 1 file changed, 4 insertions(+) diff --git a/Documentation/devicetree/bindings/arm/hisilicon/hisilicon.txt

[V2 2/2] Add initial dtsi file to support Hisilicon Hi3660 SoC with support of Octal core CPUs in two clusters(4 * A53 & 4 * A73).

Also add dts file to support HiKey960 development board which based on Hi3660 SoC. The output console is earlycon "earlycon=pl011,0xfdf05000". And the con_init uart5 with a fixed clock, which already configured at bootloader. When clock is available, the uart5 will be modified. Tested on

Re: [PATCH 1/8] mmc-core: Use kmalloc_array() in mmc_test_area_init()

On 10 January 2017 at 02:31, Linus Walleij wrote: > On Sun, Jan 8, 2017 at 10:42 PM, SF Markus Elfring > wrote: > >> From: Markus Elfring >> Date: Sun, 8 Jan 2017 18:44:26 +0100 >> >> * A multiplication for

Re: [PATCH 1/8] mmc-core: Use kmalloc_array() in mmc_test_area_init()

On 10 January 2017 at 02:31, Linus Walleij wrote: > On Sun, Jan 8, 2017 at 10:42 PM, SF Markus Elfring > wrote: > >> From: Markus Elfring >> Date: Sun, 8 Jan 2017 18:44:26 +0100 >> >> * A multiplication for the size determination of a memory allocation >> indicated that an array data

[PATCH v6 2/2] ARM: dts: vf610-zii-dev: Add .dts file for rev. C

Add .dts file for rev. C of the board by factoring out commonalities into a shared include file (vf610-zii-dev-rev-b-c.dtsi) and deriving revision specific file from it (vf610-zii-dev-rev-b.dts and vf610-zii-dev-reb-c.dts). Cc: Shawn Guo Cc: Rob Herring

[PATCH v6 2/2] ARM: dts: vf610-zii-dev: Add .dts file for rev. C

Add .dts file for rev. C of the board by factoring out commonalities into a shared include file (vf610-zii-dev-rev-b-c.dtsi) and deriving revision specific file from it (vf610-zii-dev-rev-b.dts and vf610-zii-dev-reb-c.dts). Cc: Shawn Guo Cc: Rob Herring Cc: Mark Rutland Cc: Russell King Cc:

[PATCH v6 1/2] ARM: dts: vf610-zii-dev-rev-b: Remove leftover PWM pingroup

Remove pwm0grp since it is: a) Not referenced anywhere in the DTS file (unlike Tower board it is based on, this board does not use/expose FTM0) b) Configures PTB2 and PTB3 in a way that contradicts pinctrl-mdio-mux Cc: Shawn Guo Cc: Rob

[PATCH v6 1/2] ARM: dts: vf610-zii-dev-rev-b: Remove leftover PWM pingroup

Remove pwm0grp since it is: a) Not referenced anywhere in the DTS file (unlike Tower board it is based on, this board does not use/expose FTM0) b) Configures PTB2 and PTB3 in a way that contradicts pinctrl-mdio-mux Cc: Shawn Guo Cc: Rob Herring Cc: Mark Rutland

Re: NVMe vs DMA addressing limitations

Christoph, thanks for clear input. Arnd, I think that given this discussion, best short-term solution is indeed the patch I've submitted yesterday. That is, your version + coherent mask support. With that, set_dma_mask(DMA_BIT_MASK(64)) will succeed and hardware with work with swiotlb. Possible

Re: NVMe vs DMA addressing limitations

Christoph, thanks for clear input. Arnd, I think that given this discussion, best short-term solution is indeed the patch I've submitted yesterday. That is, your version + coherent mask support. With that, set_dma_mask(DMA_BIT_MASK(64)) will succeed and hardware with work with swiotlb. Possible

Re: [PATCH] rcu: fix the OOM problem of huge IP abnormal packet traffic

Hi David： The Patch "rcu: Fix soft lockup for rcu_nocb_kthread" has been added to several stable tree， it may introduced an issue in certain special scenarios, The Patch "softirq: Let ksoftirqd do its job" could fix this issue, so I hope you could add this patch to stable tree, thanks. Ding

Re: gpio_key.c device tree question

On Sun, Jan 8, 2017 at 7:42 PM, noman pouigt wrote: > Hello, > > I am trying to see how to disable the sub device nodes in > gpio_keys device node. > > I have this in my base dtsi file: > > #include "vendor_file.dtsi" > > gpio_keys { > compatible =

Re: [PATCH] rcu: fix the OOM problem of huge IP abnormal packet traffic

Hi David： The Patch "rcu: Fix soft lockup for rcu_nocb_kthread" has been added to several stable tree， it may introduced an issue in certain special scenarios, The Patch "softirq: Let ksoftirqd do its job" could fix this issue, so I hope you could add this patch to stable tree, thanks. Ding

Re: gpio_key.c device tree question

On Sun, Jan 8, 2017 at 7:42 PM, noman pouigt wrote: > Hello, > > I am trying to see how to disable the sub device nodes in > gpio_keys device node. > > I have this in my base dtsi file: > > #include "vendor_file.dtsi" > > gpio_keys { > compatible = "gpio-keys"; >

Re: [BUG] Boot failure since df9bcc2bc on veyron_speedy

Hi On 01/10/2017 04:20 PM, Ziyuan wrote: > Hi, > > On 01/10/2017 09:04 AM, S. Gilles wrote: >> On 2017-01-10T08:47:16+0800, Shawn Lin wrote: >>> Hi >>> >>> On 2017/1/9 22:49, S. Gilles wrote: On 2017-01-09T09:19:55-0500, S. Gilles wrote: > Hi, > > I have a C201, a veyron_speedy

Re: [BUG] Boot failure since df9bcc2bc on veyron_speedy

Hi On 01/10/2017 04:20 PM, Ziyuan wrote: > Hi, > > On 01/10/2017 09:04 AM, S. Gilles wrote: >> On 2017-01-10T08:47:16+0800, Shawn Lin wrote: >>> Hi >>> >>> On 2017/1/9 22:49, S. Gilles wrote: On 2017-01-09T09:19:55-0500, S. Gilles wrote: > Hi, > > I have a C201, a veyron_speedy

Re: [BUG] Boot failure since df9bcc2bc on veyron_speedy

Hi, On 01/10/2017 09:04 AM, S. Gilles wrote: On 2017-01-10T08:47:16+0800, Shawn Lin wrote: Hi On 2017/1/9 22:49, S. Gilles wrote: On 2017-01-09T09:19:55-0500, S. Gilles wrote: Hi, I have a C201, a veyron_speedy device (which uses rk3288) running vanilla kernels. With recent kernels it will

Re: [BUG] Boot failure since df9bcc2bc on veyron_speedy

Hi, On 01/10/2017 09:04 AM, S. Gilles wrote: On 2017-01-10T08:47:16+0800, Shawn Lin wrote: Hi On 2017/1/9 22:49, S. Gilles wrote: On 2017-01-09T09:19:55-0500, S. Gilles wrote: Hi, I have a C201, a veyron_speedy device (which uses rk3288) running vanilla kernels. With recent kernels it will

Re: NVMe vs DMA addressing limitations

On Tue, Jan 10, 2017 at 09:47:21AM +0300, Nikita Yushchenko wrote: > I'm now working with HW that: > - is now way "low end" or "obsolete", it has 4G of RAM and 8 CPU cores, > and is being manufactured and developed, > - has 75% of it's RAM located beyond first 4G of address space, > - can't

Re: NVMe vs DMA addressing limitations

On Tue, Jan 10, 2017 at 09:47:21AM +0300, Nikita Yushchenko wrote: > I'm now working with HW that: > - is now way "low end" or "obsolete", it has 4G of RAM and 8 CPU cores, > and is being manufactured and developed, > - has 75% of it's RAM located beyond first 4G of address space, > - can't

[RESEND PATCHv1 7/8] mmc: sdhci-msm: Make HS400 tuning follow as per recommeneded HW sequence

During tuning execution for HS400 mode, HW sequence recommends to select MCLK_SEL/2(0x3) in VENDOR_SPEC & sdhc msm clock at GCC to be 400MHZ (nearest supported clk). Add this change in tuning sequence during HS400 tuning. Signed-off-by: Ritesh Harjani ---

[RESEND PATCHv1 6/8] mmc: sdhci: Clear SDHCI_HS400_TUNING flag after platform_execute_tuning

Clear SDHCI_HS400_TUNING flag after platform_execute_tuning so that platform_execute_tuning may use it if needed. Signed-off-by: Ritesh Harjani --- drivers/mmc/host/sdhci.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/mmc/host/sdhci.c

[RESEND PATCHv1 8/8] mmc: sdhci-msm: Provide enhanced_strobe mode feature support

This provides enhanced_strobe mode feature support in sdhci-msm driver. Signed-off-by: Ritesh Harjani --- drivers/mmc/host/sdhci-msm.c | 34 +- 1 file changed, 25 insertions(+), 9 deletions(-) diff --git a/drivers/mmc/host/sdhci-msm.c

[RESEND PATCHv1 7/8] mmc: sdhci-msm: Make HS400 tuning follow as per recommeneded HW sequence

During tuning execution for HS400 mode, HW sequence recommends to select MCLK_SEL/2(0x3) in VENDOR_SPEC & sdhc msm clock at GCC to be 400MHZ (nearest supported clk). Add this change in tuning sequence during HS400 tuning. Signed-off-by: Ritesh Harjani --- drivers/mmc/host/sdhci-msm.c | 16

[RESEND PATCHv1 6/8] mmc: sdhci: Clear SDHCI_HS400_TUNING flag after platform_execute_tuning

Clear SDHCI_HS400_TUNING flag after platform_execute_tuning so that platform_execute_tuning may use it if needed. Signed-off-by: Ritesh Harjani --- drivers/mmc/host/sdhci.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/mmc/host/sdhci.c

[RESEND PATCHv1 8/8] mmc: sdhci-msm: Provide enhanced_strobe mode feature support

This provides enhanced_strobe mode feature support in sdhci-msm driver. Signed-off-by: Ritesh Harjani --- drivers/mmc/host/sdhci-msm.c | 34 +- 1 file changed, 25 insertions(+), 9 deletions(-) diff --git a/drivers/mmc/host/sdhci-msm.c

Re: [PATCH v11 2/8] power: add power sequence library

On Sat, Jan 07, 2017 at 10:54:56AM +0200, Krzysztof Kozlowski wrote: > On Thu, Jan 05, 2017 at 02:01:53PM +0800, Peter Chen wrote: > > We have an well-known problem that the device needs to do some power > > sequence before it can be recognized by related host, the typical > > example like

[RESEND PATCHv1 5/8] mmc: sdhci-msm: configure CORE_CSR_CDC_DELAY_CFG to recommended value

From: Subhash Jadavani Program CORE_CSR_CDC_DELAY_CFG for hardware recommended 1.25ns delay. We may see data CRC errors if it's programmed for any other delay value. Signed-off-by: Subhash Jadavani Signed-off-by: Ritesh Harjani

Re: [PATCH v11 2/8] power: add power sequence library

On Sat, Jan 07, 2017 at 10:54:56AM +0200, Krzysztof Kozlowski wrote: > On Thu, Jan 05, 2017 at 02:01:53PM +0800, Peter Chen wrote: > > We have an well-known problem that the device needs to do some power > > sequence before it can be recognized by related host, the typical > > example like

[RESEND PATCHv1 5/8] mmc: sdhci-msm: configure CORE_CSR_CDC_DELAY_CFG to recommended value

From: Subhash Jadavani Program CORE_CSR_CDC_DELAY_CFG for hardware recommended 1.25ns delay. We may see data CRC errors if it's programmed for any other delay value. Signed-off-by: Subhash Jadavani Signed-off-by: Ritesh Harjani --- drivers/mmc/host/sdhci-msm.c | 2 +- 1 file changed, 1

[RESEND PATCHv1 3/8] mmc: sdhci-msm: Factor out sdhci_msm_hs400

Factor out sdhci_msm_hs400 used for DLL calibration in HS400 modes. This function will be needed for enhanced_strobe as well. Signed-off-by: Ritesh Harjani --- drivers/mmc/host/sdhci-msm.c | 32 ++-- 1 file changed, 26 insertions(+), 6

[RESEND PATCHv1 0/8] mmc: sdhci-msm: Provide support for enhanced strobe

Hi, Resending this patch series, as no one could review it -possibly due to holidays during that time. This patch series mainly provides enhanced strobe support to sdhci-msm driver along with some additions of HW recommended sequence. This has been tested on 8996 based internal target & on

[RESEND PATCHv1 3/8] mmc: sdhci-msm: Factor out sdhci_msm_hs400

Factor out sdhci_msm_hs400 used for DLL calibration in HS400 modes. This function will be needed for enhanced_strobe as well. Signed-off-by: Ritesh Harjani --- drivers/mmc/host/sdhci-msm.c | 32 ++-- 1 file changed, 26 insertions(+), 6 deletions(-) diff --git

[RESEND PATCHv1 0/8] mmc: sdhci-msm: Provide support for enhanced strobe

Hi, Resending this patch series, as no one could review it -possibly due to holidays during that time. This patch series mainly provides enhanced strobe support to sdhci-msm driver along with some additions of HW recommended sequence. This has been tested on 8996 based internal target & on

[RESEND PATCHv1 4/8] mmc: sdhci-msm: Reset vendor specific func register on probe

From: Venkat Gopalakrishnan The vendor specific func register doesn't get reset when using the software reset register. The various bootloader's could leave this in an unknown state, hence reset this register to it's power on reset value during probe. Signed-off-by:

[RESEND PATCHv1 2/8] mmc: sdhci-msm: Factor out function to set/get msm clock rate

Factor out msm_set/get_clock_rate_for_bus_mode for it's later use in changing the tuning sequence for selecting HS400 bus speed mode. Signed-off-by: Ritesh Harjani --- drivers/mmc/host/sdhci-msm.c | 64 +++- 1 file changed, 40

[RESEND PATCHv1 1/8] mmc: sdhci-msm: Factor out sdhci_msm_hc_select_mode

This factors out sdhci_msm_hc_select_mode to later use it during enhanced_strobe mode select. It also further breaks sdhci_msm_hc_select_mode into separate functions for configuring HS400 mode or other modes. Signed-off-by: Ritesh Harjani --- drivers/mmc/host/sdhci-msm.c

[RESEND PATCHv1 4/8] mmc: sdhci-msm: Reset vendor specific func register on probe

From: Venkat Gopalakrishnan The vendor specific func register doesn't get reset when using the software reset register. The various bootloader's could leave this in an unknown state, hence reset this register to it's power on reset value during probe. Signed-off-by: Venkat Gopalakrishnan

[RESEND PATCHv1 2/8] mmc: sdhci-msm: Factor out function to set/get msm clock rate

Factor out msm_set/get_clock_rate_for_bus_mode for it's later use in changing the tuning sequence for selecting HS400 bus speed mode. Signed-off-by: Ritesh Harjani --- drivers/mmc/host/sdhci-msm.c | 64 +++- 1 file changed, 40 insertions(+), 24

[RESEND PATCHv1 1/8] mmc: sdhci-msm: Factor out sdhci_msm_hc_select_mode

This factors out sdhci_msm_hc_select_mode to later use it during enhanced_strobe mode select. It also further breaks sdhci_msm_hc_select_mode into separate functions for configuring HS400 mode or other modes. Signed-off-by: Ritesh Harjani --- drivers/mmc/host/sdhci-msm.c | 201

Re: [PATCH 0/4] ARM: dts: mt7623: Add initial Geek Force support

On 08/01/2017 14:30, Andreas Färber wrote: > > Andreas Färber (4): > Documentation: devicetree: Add vendor prefix for AsiaRF > Documentation: devicetree: arm: mediatek: Add Geek Force board > ARM: dts: mt7623: Add Geek Force config > MAINTAINERS: Extend ARM/Mediatek SoC support section

Re: [PATCH 0/4] ARM: dts: mt7623: Add initial Geek Force support

On 08/01/2017 14:30, Andreas Färber wrote: > > Andreas Färber (4): > Documentation: devicetree: Add vendor prefix for AsiaRF > Documentation: devicetree: arm: mediatek: Add Geek Force board > ARM: dts: mt7623: Add Geek Force config > MAINTAINERS: Extend ARM/Mediatek SoC support section

Re: [PATCH] serial: 8250_lpss: Unconditionally set PCI master for Quark

On 2017-01-10 00:24, Andy Shevchenko wrote: > On Mon, Jan 9, 2017 at 7:11 PM, Jan Kiszka wrote: >> On 2017-01-05 22:56, Andy Shevchenko wrote: >>> On Thu, Jan 5, 2017 at 1:56 AM, Andy Shevchenko >>> wrote: >>> >>> Ah, Jan, perhaps you would like

Re: [PATCH] serial: 8250_lpss: Unconditionally set PCI master for Quark

On 2017-01-10 00:24, Andy Shevchenko wrote: > On Mon, Jan 9, 2017 at 7:11 PM, Jan Kiszka wrote: >> On 2017-01-05 22:56, Andy Shevchenko wrote: >>> On Thu, Jan 5, 2017 at 1:56 AM, Andy Shevchenko >>> wrote: >>> >>> Ah, Jan, perhaps you would like to comment on this one as well >>>

[PATCH] clk: cs2000: add Suspend/Redume feature

From: Khiem Nguyen CS2000 needs re-setup when redume, otherwise, it can't handle correct clock rate. Signed-off-by: Khiem Nguyen [Kuninori: cleanup original patch] Signed-off-by: Kuninori Morimoto

[PATCH] clk: cs2000: add Suspend/Redume feature

From: Khiem Nguyen CS2000 needs re-setup when redume, otherwise, it can't handle correct clock rate. Signed-off-by: Khiem Nguyen [Kuninori: cleanup original patch] Signed-off-by: Kuninori Morimoto --- drivers/clk/clk-cs2000-cp.c | 22 ++ 1 file changed, 22 insertions(+)

Re: [PATCH 1/1] ARM: dts: add Armadeus Systems OPOS6UL AND OPOS6ULDEV support

On Mon, Jan 09, 2017 at 05:00:18PM +0100, Sébastien Szymanski wrote: > OPOS6UL is an i.MX6UL based SoM. > OPOS6ULDev is a carrier board for the OPOS6UL SoM. > > For more details see: > http://www.opossom.com/english/products-processor_boards-opos6ul.html >

Re: [PATCH 1/1] ARM: dts: add Armadeus Systems OPOS6UL AND OPOS6ULDEV support

On Mon, Jan 09, 2017 at 05:00:18PM +0100, Sébastien Szymanski wrote: > OPOS6UL is an i.MX6UL based SoM. > OPOS6ULDev is a carrier board for the OPOS6UL SoM. > > For more details see: > http://www.opossom.com/english/products-processor_boards-opos6ul.html >

NVMe vs DMA addressing limitations

>> I believe the bounce buffering code you refer to is not in SATA/SCSI/MMC >> but in block layer, in particular it should be controlled by >> blk_queue_bounce_limit(). [Yes there is CONFIG_MMC_BLOCK_BOUNCE but it >> is something completely different, namely it is for request merging for >> hw

NVMe vs DMA addressing limitations

>> I believe the bounce buffering code you refer to is not in SATA/SCSI/MMC >> but in block layer, in particular it should be controlled by >> blk_queue_bounce_limit(). [Yes there is CONFIG_MMC_BLOCK_BOUNCE but it >> is something completely different, namely it is for request merging for >> hw

[PATCH v2 2/2] nvmem: core: Allow getting nvmem cell with a NULL cell id

The nvmem cell with a NULL cell name/id should be the one with no accompanying 'nvmem-cell-names' property, and thus will be the cell at index 0 in the device tree. So, we default to index 0 and update the cell index only when nvmem cell name id exists. Suggested-by: Stephen Boyd

[PATCH v2 1/2] nvmem: core: Correct a bunch of function documentations

Correct the documentation for arguments to a number of functions. Signed-off-by: Vivek Gautam --- Based on torvald's master branch. Changes since v1: - Removed unnecessary whitespaces. drivers/nvmem/core.c | 30 -- 1 file changed, 16

[PATCH v2 2/2] nvmem: core: Allow getting nvmem cell with a NULL cell id

The nvmem cell with a NULL cell name/id should be the one with no accompanying 'nvmem-cell-names' property, and thus will be the cell at index 0 in the device tree. So, we default to index 0 and update the cell index only when nvmem cell name id exists. Suggested-by: Stephen Boyd Signed-off-by:

[PATCH v2 1/2] nvmem: core: Correct a bunch of function documentations

Correct the documentation for arguments to a number of functions. Signed-off-by: Vivek Gautam --- Based on torvald's master branch. Changes since v1: - Removed unnecessary whitespaces. drivers/nvmem/core.c | 30 -- 1 file changed, 16 insertions(+), 14

RE: [PATCH v6 kernel 0/5] Extend virtio-balloon for fast (de)inflating & fast live migration

Hi guys, Could you help to review this patch set? Thanks! Liang > -Original Message- > From: Li, Liang Z > Sent: Wednesday, December 21, 2016 2:52 PM > To: k...@vger.kernel.org > Cc: virtio-...@lists.oasis-open.org; qemu-de...@nongnu.org; linux- > m...@kvack.org;

RE: [PATCH v6 kernel 0/5] Extend virtio-balloon for fast (de)inflating & fast live migration

Hi guys, Could you help to review this patch set? Thanks! Liang > -Original Message- > From: Li, Liang Z > Sent: Wednesday, December 21, 2016 2:52 PM > To: k...@vger.kernel.org > Cc: virtio-...@lists.oasis-open.org; qemu-de...@nongnu.org; linux- > m...@kvack.org;

[RESEND RFC 1/3] mmc: sdhci: Add platform_dumpregs callback support to sdhci_ops.

From: Sahitya Tummala Add new host operation ->platform_dumpregs to provide a mechanism through which host drivers can dump platform specific registers in addition to SDHC registers during error conditions. Signed-off-by: Sahitya Tummala

[RESEND RFC 3/3] mmc: sdhci: Add more debug info in case of data error

print error log message and dump sdhc registers for debugging purpose in case of data errors (except when tuning commands generate CRC/timeout/end bit errors). Signed-off-by: Ritesh Harjani Signed-off-by: Asutosh Das --- drivers/mmc/host/sdhci.c

[RESEND RFC 1/3] mmc: sdhci: Add platform_dumpregs callback support to sdhci_ops.

From: Sahitya Tummala Add new host operation ->platform_dumpregs to provide a mechanism through which host drivers can dump platform specific registers in addition to SDHC registers during error conditions. Signed-off-by: Sahitya Tummala Signed-off-by: Ritesh Harjani ---

[RESEND RFC 3/3] mmc: sdhci: Add more debug info in case of data error

print error log message and dump sdhc registers for debugging purpose in case of data errors (except when tuning commands generate CRC/timeout/end bit errors). Signed-off-by: Ritesh Harjani Signed-off-by: Asutosh Das --- drivers/mmc/host/sdhci.c | 21 +++-- 1 file changed, 19

[RESEND RFC 2/3] mmc: sdhci-msm: Implement platform_dumpregs callback in sdhci-msm

From: Sahitya Tummala Implement ->platform_dumpregs host operation to print the platform specific registers in addition to standard SDHC register during error conditions. Signed-off-by: Sahitya Tummala Signed-off-by: Ritesh Harjani

[RESEND RFC 0/3] mmc: sdhci: sdhci-msm: Add more debug logs

Resending this small set of patches. Below is a small set of patches which provide useful info for debugging issues. Patch 1 :- This provide callback mechanism for platform drivers to dump their necessary register info at the time of sdhci_dumpregs. Patch 2 :- This implements this callback

[RESEND RFC 2/3] mmc: sdhci-msm: Implement platform_dumpregs callback in sdhci-msm

From: Sahitya Tummala Implement ->platform_dumpregs host operation to print the platform specific registers in addition to standard SDHC register during error conditions. Signed-off-by: Sahitya Tummala Signed-off-by: Ritesh Harjani --- drivers/mmc/host/sdhci-msm.c | 34

[RESEND RFC 0/3] mmc: sdhci: sdhci-msm: Add more debug logs

Resending this small set of patches. Below is a small set of patches which provide useful info for debugging issues. Patch 1 :- This provide callback mechanism for platform drivers to dump their necessary register info at the time of sdhci_dumpregs. Patch 2 :- This implements this callback

ATTENZIONE

ATTENZIONE; La cassetta postale ha superato il limite di archiviazione, che è 5 GB come definiti dall'amministratore, che è attualmente in esecuzione su 10.9GB, non si può essere in grado di inviare o ricevere nuovi messaggi fino a ri-convalidare la tua mailbox. Per rinnovare la vostra casella

ATTENZIONE

ATTENZIONE; La cassetta postale ha superato il limite di archiviazione, che è 5 GB come definiti dall'amministratore, che è attualmente in esecuzione su 10.9GB, non si può essere in grado di inviare o ricevere nuovi messaggi fino a ri-convalidare la tua mailbox. Per rinnovare la vostra casella

Re: [PATCH v5 2/3] dmaeninge: xilinx_dma: Fix bug in multiple frame stores scenario in vdma

On Sat, Jan 07, 2017 at 12:15:29PM +0530, Kedareswara rao Appana wrote: > When VDMA is configured for more than one frame in the h/w > for example h/w is configured for n number of frames and user > Submits n number of frames and triggered the DMA using issue_pending API. title case in middle if

Re: [PATCH v5 2/3] dmaeninge: xilinx_dma: Fix bug in multiple frame stores scenario in vdma

On Sat, Jan 07, 2017 at 12:15:29PM +0530, Kedareswara rao Appana wrote: > When VDMA is configured for more than one frame in the h/w > for example h/w is configured for n number of frames and user > Submits n number of frames and triggered the DMA using issue_pending API. title case in middle if

Re: [PATCH v5 1/3] dmaengine: xilinx_dma: Check for channel idle state before submitting dma descriptor

On Sat, Jan 07, 2017 at 12:15:28PM +0530, Kedareswara rao Appana wrote: > Add channel idle state to ensure that dma descriptor is not > submitted when VDMA engine is in progress. any reason why you want to make your own varible and not use the HW to query as done earlier. It is not clear to me

Re: [PATCH v5 1/3] dmaengine: xilinx_dma: Check for channel idle state before submitting dma descriptor

On Sat, Jan 07, 2017 at 12:15:28PM +0530, Kedareswara rao Appana wrote: > Add channel idle state to ensure that dma descriptor is not > submitted when VDMA engine is in progress. any reason why you want to make your own varible and not use the HW to query as done earlier. It is not clear to me

Re: [PATCH v5 2/2] ARM: dts: vf610-zii-dev: Add .dts file for rev. C

On Sat, Jan 07, 2017 at 12:06:54PM -0800, Andrey Smirnov wrote: > Add .dts file for rev. C of the board by factoring out commonalities > into a shared include file (vf610-zii-dev-rev-b-c.dtsi) and deriving > revision specific file from it (vf610-zii-dev-rev-b.dts and > vf610-zii-dev-reb-c.dts). >

Re: [PATCH v5 2/2] ARM: dts: vf610-zii-dev: Add .dts file for rev. C

On Sat, Jan 07, 2017 at 12:06:54PM -0800, Andrey Smirnov wrote: > Add .dts file for rev. C of the board by factoring out commonalities > into a shared include file (vf610-zii-dev-rev-b-c.dtsi) and deriving > revision specific file from it (vf610-zii-dev-rev-b.dts and > vf610-zii-dev-reb-c.dts). >

pull-request: wireless-drivers 2017-01-10

Hi Dave, here's the pull request with the important rtlwifi fix, more info in the tag below. During the long weekend we had here I finally updated Ubuntu on my workstation and git was updated along that. If you see anything funny or problems in my pull request due to the upgrade, please let me

pull-request: wireless-drivers 2017-01-10

Hi Dave, here's the pull request with the important rtlwifi fix, more info in the tag below. During the long weekend we had here I finally updated Ubuntu on my workstation and git was updated along that. If you see anything funny or problems in my pull request due to the upgrade, please let me

Re: [PATCH 3/3] xen: optimize xenbus driver for multiple concurrent xenstore accesses

On 09/01/17 22:17, Boris Ostrovsky wrote: > On 01/06/2017 10:05 AM, Juergen Gross wrote: >> Handling of multiple concurrent Xenstore accesses through xenbus driver >> either from the kernel or user land is rather lame today: xenbus is >> capable to have one access active only at one point of time.

Re: [PATCH 3/3] xen: optimize xenbus driver for multiple concurrent xenstore accesses

On 09/01/17 22:17, Boris Ostrovsky wrote: > On 01/06/2017 10:05 AM, Juergen Gross wrote: >> Handling of multiple concurrent Xenstore accesses through xenbus driver >> either from the kernel or user land is rather lame today: xenbus is >> capable to have one access active only at one point of time.

[PATCH v4 2/2] dt-bindings: clk: add rockchip,grf property for RK3399

Add support for rockchip,grf property which is used for GRF muxes on RK3399. Signed-off-by: Xing Zheng --- Changes in v4: - update the decription for rockchip,grf property Changes in v3: None Changes in v2: None

[PATCH v4 2/2] dt-bindings: clk: add rockchip,grf property for RK3399

Add support for rockchip,grf property which is used for GRF muxes on RK3399. Signed-off-by: Xing Zheng --- Changes in v4: - update the decription for rockchip,grf property Changes in v3: None Changes in v2: None Documentation/devicetree/bindings/clock/rockchip,rk3399-cru.txt | 6 ++ 1

[PATCH v4 1/2] arm64: dts: rockchip: add "rockchip, grf" property for RK3399 PMUCRU/CRU

The structure rockchip_clk_provider needs to refer the GRF regmap in somewhere, if the CRU node has not "rockchip,grf" property, calling syscon_regmap_lookup_by_phandle will return an invalid GRF regmap, and the MUXGRF type clock will be not supported. Therefore, we need to add them.

[PATCH v4 0/2] Add support rockchip,grf property for RK3399 PMU/GRU

Hi, The structure rockchip_clk_provider needs to refer the GRF regmap in somewhere, if the CRU node has not "rockchip,grf" property, calling syscon_regmap_lookup_by_phandle will return an invalid GRF regmap, and the MUXGRF type clock will be not supported. Therefore, we need to add them.

[PATCH v4 0/2] Add support rockchip,grf property for RK3399 PMU/GRU

Hi, The structure rockchip_clk_provider needs to refer the GRF regmap in somewhere, if the CRU node has not "rockchip,grf" property, calling syscon_regmap_lookup_by_phandle will return an invalid GRF regmap, and the MUXGRF type clock will be not supported. Therefore, we need to add them.

[PATCH v4 1/2] arm64: dts: rockchip: add "rockchip, grf" property for RK3399 PMUCRU/CRU

The structure rockchip_clk_provider needs to refer the GRF regmap in somewhere, if the CRU node has not "rockchip,grf" property, calling syscon_regmap_lookup_by_phandle will return an invalid GRF regmap, and the MUXGRF type clock will be not supported. Therefore, we need to add them.

Re: [PATCH v1] security: Fix inode_getattr documentation

On Thu, 22 Dec 2016, Mickaël Salaün wrote: > Replace arguments @mnt and @dentry with @path. > > Signed-off-by: Mickaël Salaün > Cc: James Morris > Cc: Serge E. Hallyn > --- > include/linux/lsm_hooks.h | 3 +-- > 1 file changed, 1

Re: [PATCH v1] security: Fix inode_getattr documentation

On Thu, 22 Dec 2016, Mickaël Salaün wrote: > Replace arguments @mnt and @dentry with @path. > > Signed-off-by: Mickaël Salaün > Cc: James Morris > Cc: Serge E. Hallyn > --- > include/linux/lsm_hooks.h | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) Applied to

Re: [PATCH 1/5] perf, tools: Add probing for xed

Hi Andi, just a very minor cosmetic detail, but your editor seems to use tabs while there were 8 spaces around, causing visual alignment defects below : On Mon, Jan 09, 2017 at 05:02:21PM -0800, Andi Kleen wrote: > diff --git a/tools/build/Makefile.feature b/tools/build/Makefile.feature > index

Re: [PATCH 1/5] perf, tools: Add probing for xed

Hi Andi, just a very minor cosmetic detail, but your editor seems to use tabs while there were 8 spaces around, causing visual alignment defects below : On Mon, Jan 09, 2017 at 05:02:21PM -0800, Andi Kleen wrote: > diff --git a/tools/build/Makefile.feature b/tools/build/Makefile.feature > index

Re: [PATCH V2 2/5] phy: phy-exynos-pcie: Add support for Exynos PCIe phy

Hi Vivek, On 01/10/2017 03:07 PM, Vivek Gautam wrote: > Hi Jaehoon, > > > On 01/04/2017 06:04 PM, Jaehoon Chung wrote: >> This patch supports to use Generic Phy framework for Exynos PCIe phy. >> When Exynos that supported the pcie want to use the PCIe, >> it needs to control the phy resgister.

Re: [PATCH V2 2/5] phy: phy-exynos-pcie: Add support for Exynos PCIe phy

Hi Vivek, On 01/10/2017 03:07 PM, Vivek Gautam wrote: > Hi Jaehoon, > > > On 01/04/2017 06:04 PM, Jaehoon Chung wrote: >> This patch supports to use Generic Phy framework for Exynos PCIe phy. >> When Exynos that supported the pcie want to use the PCIe, >> it needs to control the phy resgister.

Re: [PATCH V2 2/5] phy: phy-exynos-pcie: Add support for Exynos PCIe phy

Hi Jaehoon, On 01/04/2017 06:04 PM, Jaehoon Chung wrote: This patch supports to use Generic Phy framework for Exynos PCIe phy. When Exynos that supported the pcie want to use the PCIe, it needs to control the phy resgister. But it should be more complex to control in their own PCIe device

Re: [PATCH V2 2/5] phy: phy-exynos-pcie: Add support for Exynos PCIe phy

Hi Jaehoon, On 01/04/2017 06:04 PM, Jaehoon Chung wrote: This patch supports to use Generic Phy framework for Exynos PCIe phy. When Exynos that supported the pcie want to use the PCIe, it needs to control the phy resgister. But it should be more complex to control in their own PCIe device

  1   2   3   4   5   6   7   8   9   10   >