Re: linux-next: build warning after merge of the scsi-mkp tree

Hi all, [Just adding Dick and James to the cc list] On Thu, 24 Aug 2017 15:57:56 +1000 Stephen Rothwell wrote: > > After merging the scsi-mkp tree, today's linux-next build (powerpc > ppc64_defconfig) produced this warning: > > drivers/scsi/lpfc/lpfc_nvmet.c:1457:1:

Re: linux-next: build warning after merge of the scsi-mkp tree

Hi all, [Just adding Dick and James to the cc list] On Thu, 24 Aug 2017 15:57:56 +1000 Stephen Rothwell wrote: > > After merging the scsi-mkp tree, today's linux-next build (powerpc > ppc64_defconfig) produced this warning: > > drivers/scsi/lpfc/lpfc_nvmet.c:1457:1: warning: >

linux-next: build warning after merge of the scsi-mkp tree

Hi Martin, After merging the scsi-mkp tree, today's linux-next build (powerpc ppc64_defconfig) produced this warning: drivers/scsi/lpfc/lpfc_nvmet.c:1457:1: warning: 'lpfc_nvmet_replenish_context' defined but not used [-Wunused-function] lpfc_nvmet_replenish_context(struct lpfc_hba *phba, ^

linux-next: build warning after merge of the scsi-mkp tree

Hi Martin, After merging the scsi-mkp tree, today's linux-next build (powerpc ppc64_defconfig) produced this warning: drivers/scsi/lpfc/lpfc_nvmet.c:1457:1: warning: 'lpfc_nvmet_replenish_context' defined but not used [-Wunused-function] lpfc_nvmet_replenish_context(struct lpfc_hba *phba, ^

Re: [PATCH] tty: xilinx_uartps: move to arch_initcall for earlier console

On 23.8.2017 12:55, Shubhrajyoti Datta wrote: > Signed-off-by: Shubhrajyoti Datta Empty commit message? What's the reason for this change? M > --- > drivers/tty/serial/xilinx_uartps.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git

Re: [PATCH] tty: xilinx_uartps: move to arch_initcall for earlier console

On 23.8.2017 12:55, Shubhrajyoti Datta wrote: > Signed-off-by: Shubhrajyoti Datta Empty commit message? What's the reason for this change? M > --- > drivers/tty/serial/xilinx_uartps.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/tty/serial/xilinx_uartps.c

Re: [PATCH v3 2/5] dmaengine: Add STM32 DMAMUX driver

On 2017-08-21 12:34, Pierre Yves MORDRET wrote: > OK. I will redesign my driver to take into account this idea. > > I believe I should get rid of my custom API in DMA for channelID as well. > Please > confirm. Not very clear for me whether I can keep it or not. Yes, you should be able to get

Re: [PATCH v3 2/5] dmaengine: Add STM32 DMAMUX driver

On 2017-08-21 12:34, Pierre Yves MORDRET wrote: > OK. I will redesign my driver to take into account this idea. > > I believe I should get rid of my custom API in DMA for channelID as well. > Please > confirm. Not very clear for me whether I can keep it or not. Yes, you should be able to get

[RFC 3/3] sched: depend on 64BIT_ATOMIC_ACCESS to determine if to use min_vruntime_copy

'min_vruntime_copy' is copied when 'min_vruntime' is updated for cfq_rq and used to check if updating 'min_vruntime' is completed on reader side. Because 'min_vruntime' variable is 64bit, we need a mimic of seqlock to check if the variable is not being updated on 32bit machines. On

[RFC 3/3] sched: depend on 64BIT_ATOMIC_ACCESS to determine if to use min_vruntime_copy

'min_vruntime_copy' is copied when 'min_vruntime' is updated for cfq_rq and used to check if updating 'min_vruntime' is completed on reader side. Because 'min_vruntime' variable is 64bit, we need a mimic of seqlock to check if the variable is not being updated on 32bit machines. On

[RFC 0/3] add 64BIT_ATOMIC_ACCESS and 64BIT_ATOMIC_ALIGNED_ACCESS

On some 32-bit architectures, 64bit accesses are atomic when certain conditions are satisfied. For example, on LPAE (Large Physical Address Extension) enabled ARM architecture, 'ldrd/strd' (load/store doublewords) instructions are 64bit atomic as long as the address is 64-bit aligned. This

[RFC 1/3] arch: add 64BIT_ATOMIC_ACCESS to support 64bit atomic access on 32bit machines

On some 32-bit architectures, 64bit accesses are atomic when certain conditions are satisfied. For example, on LPAE (Large Physical Address Extension) enabled ARM architecture, 'ldrd/strd' (load/store doublewords) instructions are 64bit atomic as long as the address is 64-bit aligned. This

[RFC 0/3] add 64BIT_ATOMIC_ACCESS and 64BIT_ATOMIC_ALIGNED_ACCESS

On some 32-bit architectures, 64bit accesses are atomic when certain conditions are satisfied. For example, on LPAE (Large Physical Address Extension) enabled ARM architecture, 'ldrd/strd' (load/store doublewords) instructions are 64bit atomic as long as the address is 64-bit aligned. This

[RFC 1/3] arch: add 64BIT_ATOMIC_ACCESS to support 64bit atomic access on 32bit machines

On some 32-bit architectures, 64bit accesses are atomic when certain conditions are satisfied. For example, on LPAE (Large Physical Address Extension) enabled ARM architecture, 'ldrd/strd' (load/store doublewords) instructions are 64bit atomic as long as the address is 64-bit aligned. This

[RFC 2/3] arm: enable 64BIT_ATOMIC(_ALIGNED)_ACCESS on LPAE enabled machines

'ldrd/strd' (load/store doublewords) instructions are 64bit atomic as long as the address is 64-bit aligned on LPAE (Large Physical Address Extension) enabled architectures. This feature is to guarantee atomic accesses on newly introduced 64bit wide descriptors in the translation tables. Making

[RFC 2/3] arm: enable 64BIT_ATOMIC(_ALIGNED)_ACCESS on LPAE enabled machines

'ldrd/strd' (load/store doublewords) instructions are 64bit atomic as long as the address is 64-bit aligned on LPAE (Large Physical Address Extension) enabled architectures. This feature is to guarantee atomic accesses on newly introduced 64bit wide descriptors in the translation tables. Making

[PATCH] mm/page_alloc: don't reserve ZONE_HIGHMEM for ZONE_MOVABLE request

From: Joonsoo Kim Freepage on ZONE_HIGHMEM doesn't work for kernel memory so it's not that important to reserve. When ZONE_MOVABLE is used, this problem would theorectically cause to decrease usable memory for GFP_HIGHUSER_MOVABLE allocation request which is mainly used

[PATCH] mm/page_alloc: don't reserve ZONE_HIGHMEM for ZONE_MOVABLE request

From: Joonsoo Kim Freepage on ZONE_HIGHMEM doesn't work for kernel memory so it's not that important to reserve. When ZONE_MOVABLE is used, this problem would theorectically cause to decrease usable memory for GFP_HIGHUSER_MOVABLE allocation request which is mainly used for page cache and anon

Re: [PATCH][V2][netdev-next] gre: remove duplicated assignment of iph

From: Colin King Date: Wed, 23 Aug 2017 12:59:48 +0100 > From: Colin Ian King > > iph is being assigned the same value twice; remove the redundant > first assignment. (Thanks to Nikolay Aleksandrov for pointing out > that the first

Re: [PATCH][V2][netdev-next] gre: remove duplicated assignment of iph

From: Colin King Date: Wed, 23 Aug 2017 12:59:48 +0100 > From: Colin Ian King > > iph is being assigned the same value twice; remove the redundant > first assignment. (Thanks to Nikolay Aleksandrov for pointing out > that the first asssignment should be removed and not the second) > > Fixes

Re: [PATCH net] sctp: Avoid out-of-bounds reads from address storage

From: Stefano Brivio Date: Wed, 23 Aug 2017 13:27:13 +0200 > inet_diag_msg_sctp{,l}addr_fill() and sctp_get_sctp_info() copy > sizeof(sockaddr_storage) bytes to fill in sockaddr structs used > to export diagnostic information to userspace. > > However, the memory allocated

Re: [PATCH net] sctp: Avoid out-of-bounds reads from address storage

From: Stefano Brivio Date: Wed, 23 Aug 2017 13:27:13 +0200 > inet_diag_msg_sctp{,l}addr_fill() and sctp_get_sctp_info() copy > sizeof(sockaddr_storage) bytes to fill in sockaddr structs used > to export diagnostic information to userspace. > > However, the memory allocated to store sockaddr

Re: [PATCH 3/3 v3] net: tipc: constify genl_ops

From: Arvind Yadav Date: Wed, 23 Aug 2017 16:22:20 +0530 > genl_ops are not supposed to change at runtime. All functions > working with genl_ops provided by work with > const genl_ops. So mark the non-const structs as const. > > Signed-off-by: Arvind Yadav

Re: [PATCH 3/3 v3] net: tipc: constify genl_ops

From: Arvind Yadav Date: Wed, 23 Aug 2017 16:22:20 +0530 > genl_ops are not supposed to change at runtime. All functions > working with genl_ops provided by work with > const genl_ops. So mark the non-const structs as const. > > Signed-off-by: Arvind Yadav Applied.

Re: [PATCH 0/3] constify dsa_switch_ops

From: Andrew Lunn Date: Wed, 23 Aug 2017 14:45:56 +0200 > On Wed, Aug 23, 2017 at 03:46:56PM +0530, Arvind Yadav wrote: >> dsa_switch_ops are not supposed to change at runtime. All functions >> working with dsa_switch_ops provided by work with >> const dsa_switch_ops. So mark

Re: [PATCH 0/3] constify dsa_switch_ops

From: Andrew Lunn Date: Wed, 23 Aug 2017 14:45:56 +0200 > On Wed, Aug 23, 2017 at 03:46:56PM +0530, Arvind Yadav wrote: >> dsa_switch_ops are not supposed to change at runtime. All functions >> working with dsa_switch_ops provided by work with >> const dsa_switch_ops. So mark the non-const

[PATCH] iommu/mediatek: Fix a build fail of m4u_type

The commit ("iommu/mediatek: Enlarge the validate PA range for 4GB mode") introduce the following build error: drivers/iommu/mtk_iommu.c: In function 'mtk_iommu_hw_init': >> drivers/iommu/mtk_iommu.c:536:30: error: 'const struct mtk_iommu_data' has no member named 'm4u_type'; did you mean

[PATCH] iommu/mediatek: Fix a build fail of m4u_type

The commit ("iommu/mediatek: Enlarge the validate PA range for 4GB mode") introduce the following build error: drivers/iommu/mtk_iommu.c: In function 'mtk_iommu_hw_init': >> drivers/iommu/mtk_iommu.c:536:30: error: 'const struct mtk_iommu_data' has no member named 'm4u_type'; did you mean

Re: linux-next: build warning after merge of the phy-next tree

Hi Greg, On Tue, 22 Aug 2017 15:07:33 +1000 Stephen Rothwell wrote: > > Hi Kishon, > > After merging the phy-next tree, today's linux-next build (x86_64 > allmodconfig) produced this warning: > > drivers/phy/ralink/phy-ralink-usb.c: In function 'ralink_usb_phy_probe': >

Re: linux-next: build warning after merge of the phy-next tree

Hi Greg, On Tue, 22 Aug 2017 15:07:33 +1000 Stephen Rothwell wrote: > > Hi Kishon, > > After merging the phy-next tree, today's linux-next build (x86_64 > allmodconfig) produced this warning: > > drivers/phy/ralink/phy-ralink-usb.c: In function 'ralink_usb_phy_probe': >

Re: [PATCH][net-next] net: hinic: make functions set_ctrl0 and set_ctrl1 static

From: Colin King Date: Wed, 23 Aug 2017 10:59:40 +0100 > From: Colin Ian King > > The functions set_ctrl0 and set_ctrl1 are local to the source and do > not need to be in global scope, so make them static. > > Cleans up sparse warnings: >

Re: [PATCH][net-next] net: hinic: make functions set_ctrl0 and set_ctrl1 static

From: Colin King Date: Wed, 23 Aug 2017 10:59:40 +0100 > From: Colin Ian King > > The functions set_ctrl0 and set_ctrl1 are local to the source and do > not need to be in global scope, so make them static. > > Cleans up sparse warnings: > symbol 'set_ctrl0' was not declared. Should it be

[PATCH] acpi: acpica: fix acpi operand cache leak in dsutils.c

I found an ACPI cache leak in ACPI early termination and boot continuing case. When early termination is occurred due to malicious ACPI table, Linux kernel terminates ACPI function and continues to boot process. While kernel terminates ACPI function, kmem_cache_destroy() reports Acpi-Operand

[PATCH] acpi: acpica: fix acpi operand cache leak in dsutils.c

I found an ACPI cache leak in ACPI early termination and boot continuing case. When early termination is occurred due to malicious ACPI table, Linux kernel terminates ACPI function and continues to boot process. While kernel terminates ACPI function, kmem_cache_destroy() reports Acpi-Operand

Re: [PATCH v3 1/3] lockdep: Make LOCKDEP_CROSSRELEASE configs all part of PROVE_LOCKING

On Wed, Aug 23, 2017 at 12:26:52PM +0200, Peter Zijlstra wrote: > On Wed, Aug 23, 2017 at 11:43:23AM +0900, Byungchul Park wrote: > > On Tue, Aug 22, 2017 at 03:49:22PM +0200, Peter Zijlstra wrote: > > > > So I think we'll end up hitting a lockdep deficiency and not trigger the > > > splat on

Re: [PATCH v3 1/3] lockdep: Make LOCKDEP_CROSSRELEASE configs all part of PROVE_LOCKING

On Wed, Aug 23, 2017 at 12:26:52PM +0200, Peter Zijlstra wrote: > On Wed, Aug 23, 2017 at 11:43:23AM +0900, Byungchul Park wrote: > > On Tue, Aug 22, 2017 at 03:49:22PM +0200, Peter Zijlstra wrote: > > > > So I think we'll end up hitting a lockdep deficiency and not trigger the > > > splat on

Re: [PATCH v3 1/3] lockdep: Make LOCKDEP_CROSSRELEASE configs all part of PROVE_LOCKING

On Wed, Aug 23, 2017 at 12:46:48PM +0200, Peter Zijlstra wrote: > On Wed, Aug 23, 2017 at 11:31:18AM +0900, Byungchul Park wrote: > > On Tue, Aug 22, 2017 at 11:06:03AM +0200, Peter Zijlstra wrote: > > > Currently, we do the following in process_one_work(), > > > > lockdep_map_acquire for a

Re: [PATCH v3 1/3] lockdep: Make LOCKDEP_CROSSRELEASE configs all part of PROVE_LOCKING

On Wed, Aug 23, 2017 at 12:46:48PM +0200, Peter Zijlstra wrote: > On Wed, Aug 23, 2017 at 11:31:18AM +0900, Byungchul Park wrote: > > On Tue, Aug 22, 2017 at 11:06:03AM +0200, Peter Zijlstra wrote: > > > Currently, we do the following in process_one_work(), > > > > lockdep_map_acquire for a

[PATCH v8 3/3] PCI: iproc: add device shutdown for PCI RC

PERST must be asserted around ~500ms before the reboot is applied. During soft reset (e.g., "reboot" from Linux) on some iproc based SOCs LCPLL clock and PERST both goes off simultaneously. This will cause certain Endpoints Intel NVMe not get detected, upon next boot sequence. This is

[PATCH v8 3/3] PCI: iproc: add device shutdown for PCI RC

PERST must be asserted around ~500ms before the reboot is applied. During soft reset (e.g., "reboot" from Linux) on some iproc based SOCs LCPLL clock and PERST both goes off simultaneously. This will cause certain Endpoints Intel NVMe not get detected, upon next boot sequence. This is

[PATCH v8 1/3] PCI: iproc: factor out ep configuration access

This patch factors out ep configuration access as a separate function. Signed-off-by: Oza Pawandeep diff --git a/drivers/pci/host/pcie-iproc.c b/drivers/pci/host/pcie-iproc.c index c574863..61d9be6 100644 --- a/drivers/pci/host/pcie-iproc.c +++

[PATCH v8 2/3] PCI: iproc: retry request when CRS returned from EP

PCIe spec r3.1, sec 2.3.2 If CRS software visibility is not enabled, the RC must reissue the config request as a new request. - If CRS software visibility is enabled, - for a config read of Vendor ID, the RC must return 0x0001 data - for all other config reads/writes, the RC must reissue the

[PATCH v8 1/3] PCI: iproc: factor out ep configuration access

This patch factors out ep configuration access as a separate function. Signed-off-by: Oza Pawandeep diff --git a/drivers/pci/host/pcie-iproc.c b/drivers/pci/host/pcie-iproc.c index c574863..61d9be6 100644 --- a/drivers/pci/host/pcie-iproc.c +++ b/drivers/pci/host/pcie-iproc.c @@ -448,6 +448,31

[PATCH v8 2/3] PCI: iproc: retry request when CRS returned from EP

PCIe spec r3.1, sec 2.3.2 If CRS software visibility is not enabled, the RC must reissue the config request as a new request. - If CRS software visibility is enabled, - for a config read of Vendor ID, the RC must return 0x0001 data - for all other config reads/writes, the RC must reissue the

[PATCH v8 0/3] PCI: iproc: SOC specific fixes

PCI: iproc: Retry request when CRS returned from EP Above patch adds support for CRS in PCI RC driver, otherwise if not handled at lower level, the user space PMD (poll mode drivers) can timeout. PCI: iproc: add device shutdown for PCI RC This fixes the issue where certian PCI endpoints are not

[PATCH v8 0/3] PCI: iproc: SOC specific fixes

PCI: iproc: Retry request when CRS returned from EP Above patch adds support for CRS in PCI RC driver, otherwise if not handled at lower level, the user space PMD (poll mode drivers) can timeout. PCI: iproc: add device shutdown for PCI RC This fixes the issue where certian PCI endpoints are not

Re: [PATCH V1] pinctrl: qcom: spmi-gpio: Correct power_source range check

On Tue 18 Jul 23:39 PDT 2017, fengl...@codeaurora.org wrote: > From: Fenglin Wu > > Power source selection in DIG_VIN_CTL is indexed from 0, in the range > check it shouldn't be equal to the total number of power sources. > Acked-by: Bjorn Andersson

Re: [PATCH V1] pinctrl: qcom: spmi-gpio: Correct power_source range check

On Tue 18 Jul 23:39 PDT 2017, fengl...@codeaurora.org wrote: > From: Fenglin Wu > > Power source selection in DIG_VIN_CTL is indexed from 0, in the range > check it shouldn't be equal to the total number of power sources. > Acked-by: Bjorn Andersson Regards, Bjorn > Signed-off-by: Fenglin

Re: Do we really need d_weak_revalidate???

On 24/08/17 12:07, NeilBrown wrote: > > > The more precise details, that automount action for indirect automount > points is not triggered when the 'browse' option is used, is probably > not necessary. > > Ian: if you agree with that text, and Michael doesn't provide alternate > evidence, I'll

Re: Do we really need d_weak_revalidate???

On 24/08/17 12:07, NeilBrown wrote: > > > The more precise details, that automount action for indirect automount > points is not triggered when the 'browse' option is used, is probably > not necessary. > > Ian: if you agree with that text, and Michael doesn't provide alternate > evidence, I'll

[RESENT PATCH v7 5/7] ASoC: rockchip: Add support for DP codec

Add support for optional cdn dp codec. Signed-off-by: Jeffy Chen --- Changes in v7: None Changes in v6: None Changes in v3: None Changes in v2: None sound/soc/rockchip/Kconfig| 1 + sound/soc/rockchip/rk3399_gru_sound.c | 59

[RESENT PATCH v7 5/7] ASoC: rockchip: Add support for DP codec

Add support for optional cdn dp codec. Signed-off-by: Jeffy Chen --- Changes in v7: None Changes in v6: None Changes in v3: None Changes in v2: None sound/soc/rockchip/Kconfig| 1 + sound/soc/rockchip/rk3399_gru_sound.c | 59 +-- 2 files changed,

[RESENT PATCH v7 7/7] dt-bindings: ASoC: rockchip: Update description of rockchip,codec

Update description for newly added optional audio codecs. Signed-off-by: Jeffy Chen Acked-by: Rob Herring --- Changes in v7: None Changes in v6: None Changes in v3: None Changes in v2: None

[RESENT PATCH v7 4/7] ASoC: rockchip: Parse dai links from dts

Refactor rockchip_sound_probe, parse dai links from dts instead of hard coding them. Signed-off-by: Jeffy Chen Reviewed-by: Matthias Kaehlcke Tested-by: Matthias Kaehlcke --- Changes in v7: None Changes in v6: None Changes in

[RESENT PATCH v7 7/7] dt-bindings: ASoC: rockchip: Update description of rockchip,codec

Update description for newly added optional audio codecs. Signed-off-by: Jeffy Chen Acked-by: Rob Herring --- Changes in v7: None Changes in v6: None Changes in v3: None Changes in v2: None Documentation/devicetree/bindings/sound/rockchip,rk3399-gru-sound.txt | 2 +- 1 file changed, 1

[RESENT PATCH v7 4/7] ASoC: rockchip: Parse dai links from dts

Refactor rockchip_sound_probe, parse dai links from dts instead of hard coding them. Signed-off-by: Jeffy Chen Reviewed-by: Matthias Kaehlcke Tested-by: Matthias Kaehlcke --- Changes in v7: None Changes in v6: None Changes in v3: Use compatible to match audio codecs -- Suggested-by

[RESENT PATCH v7 0/7] ASoC: rockchip: Parse dai links from dts

Currently we are using a fixed list of dai links in the driver. This serial of patches would let the driver parse dai links from dts, so that we can make some of them optional for future boards. Tested on my chromebook bob(with cros 4.4 kernel), it still works after disabled rt5514 codecs in the

[RESENT PATCH v7 6/7] ASoC: rockchip: Add support for DMIC codec

Add support for optional dmic codec. Signed-off-by: Jeffy Chen --- Changes in v7: None Changes in v6: Add dmic wakeup delay(not used for now). Changes in v3: None Changes in v2: None sound/soc/rockchip/Kconfig| 1 +

[RESENT PATCH v7 0/7] ASoC: rockchip: Parse dai links from dts

Currently we are using a fixed list of dai links in the driver. This serial of patches would let the driver parse dai links from dts, so that we can make some of them optional for future boards. Tested on my chromebook bob(with cros 4.4 kernel), it still works after disabled rt5514 codecs in the

[RESENT PATCH v7 6/7] ASoC: rockchip: Add support for DMIC codec

Add support for optional dmic codec. Signed-off-by: Jeffy Chen --- Changes in v7: None Changes in v6: Add dmic wakeup delay(not used for now). Changes in v3: None Changes in v2: None sound/soc/rockchip/Kconfig| 1 + sound/soc/rockchip/rk3399_gru_sound.c | 36

[RESENT PATCH v7 1/7] ASoC: rockchip: Use codec of_node and dai_name for rt5514 dsp

Currently we are using codec name for rt5514 dsp dai link, use codec of_node instead. Signed-off-by: Jeffy Chen --- Changes in v7: Rebase on the newest for-next Changes in v6: None Changes in v3: None Changes in v2: None sound/soc/rockchip/rk3399_gru_sound.c | 34

[RESENT PATCH v7 1/7] ASoC: rockchip: Use codec of_node and dai_name for rt5514 dsp

Currently we are using codec name for rt5514 dsp dai link, use codec of_node instead. Signed-off-by: Jeffy Chen --- Changes in v7: Rebase on the newest for-next Changes in v6: None Changes in v3: None Changes in v2: None sound/soc/rockchip/rk3399_gru_sound.c | 34

[RESENT PATCH v7 2/7] arm64: dts: rockchip: Add rt5514 dsp for Gru

Add rt5514 dsp of_node to codec list for Gru boards. Signed-off-by: Jeffy Chen --- Changes in v7: None Changes in v6: None Changes in v3: None Changes in v2: None arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)

[RESENT PATCH v7 3/7] arm64: dts: rockchip: Update rt5514 devices' compatible for Gru

Currently the rt5514 i2c driver and rt5514 spi driver are using the same compatible string. Add additional unused compatible strings to identify them for Gru boards. Signed-off-by: Jeffy Chen --- Changes in v7: None Changes in v6: None Changes in v3: None Changes in

[RESENT PATCH v7 2/7] arm64: dts: rockchip: Add rt5514 dsp for Gru

Add rt5514 dsp of_node to codec list for Gru boards. Signed-off-by: Jeffy Chen --- Changes in v7: None Changes in v6: None Changes in v3: None Changes in v2: None arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git

[RESENT PATCH v7 3/7] arm64: dts: rockchip: Update rt5514 devices' compatible for Gru

Currently the rt5514 i2c driver and rt5514 spi driver are using the same compatible string. Add additional unused compatible strings to identify them for Gru boards. Signed-off-by: Jeffy Chen --- Changes in v7: None Changes in v6: None Changes in v3: None Changes in v2: None

Re: possible circular locking dependency detected [was: linux-next: Tree for Aug 22]

Hi, On (08/24/17 12:39), Boqun Feng wrote: > On Wed, Aug 23, 2017 at 02:55:17PM +0900, Sergey Senozhatsky wrote: > > On (08/23/17 13:35), Boqun Feng wrote: > > > > KERN_CONT and "\n" should not be together. "\n" flushes the cont > > > > buffer immediately. > > > > > > > > > > Hmm.. Not quite

Re: possible circular locking dependency detected [was: linux-next: Tree for Aug 22]

Hi, On (08/24/17 12:39), Boqun Feng wrote: > On Wed, Aug 23, 2017 at 02:55:17PM +0900, Sergey Senozhatsky wrote: > > On (08/23/17 13:35), Boqun Feng wrote: > > > > KERN_CONT and "\n" should not be together. "\n" flushes the cont > > > > buffer immediately. > > > > > > > > > > Hmm.. Not quite

Re: Do we really need d_weak_revalidate???

On 24/08/17 12:07, NeilBrown wrote: > On Wed, Aug 23 2017, Ian Kent wrote: > >> >> That inconsistency has bothered me for quite a while now. >> >> It was carried over from the autofs module behavior when automounting >> support was added to the VFS. What's worse is it prevents the use of >> the

Re: Do we really need d_weak_revalidate???

On 24/08/17 12:07, NeilBrown wrote: > On Wed, Aug 23 2017, Ian Kent wrote: > >> >> That inconsistency has bothered me for quite a while now. >> >> It was carried over from the autofs module behavior when automounting >> support was added to the VFS. What's worse is it prevents the use of >> the

Re: [PATCH v2] ASoC: Add a sanity check before using dai driver name

Hi Dong, Thanks for noticing, will send new patch soon :) On 08/24/2017 11:46 AM, Donglin Peng wrote: On Thu, Aug 24, 2017 at 11:34 AM, Jeffy Chen wrote: list_for_each_entry(dai, >dai_list, list) { if (dlc->dai_name &&

Re: [PATCH v2] ASoC: Add a sanity check before using dai driver name

Hi Dong, Thanks for noticing, will send new patch soon :) On 08/24/2017 11:46 AM, Donglin Peng wrote: On Thu, Aug 24, 2017 at 11:34 AM, Jeffy Chen wrote: list_for_each_entry(dai, >dai_list, list) { if (dlc->dai_name && strcmp(dai->name,

[PATCH v3] ASoC: Add a sanity check before using dai driver name

The dai driver's name is allowed to be NULL. So add a sanity check for that. Signed-off-by: Jeffy Chen Reported-by: Donglin Peng --- Changes in v3: Fix typo Changes in v2: Keep the oringinal check style. sound/soc/soc-core.c | 3 ++- 1 file

Re: [PATCH v7 1/2] PCI: iproc: Retry request when CRS returned from EP

On Wed, Aug 23, 2017 at 11:30 PM, Bjorn Helgaas wrote: > On Wed, Aug 23, 2017 at 09:32:06PM +0530, Oza Oza wrote: >> On Wed, Aug 23, 2017 at 9:22 PM, Sinan Kaya wrote: >> > Hi Oza, >> > >> >> In working Enumuration case I get following: >> >> [

Re: [PATCH v7 1/2] PCI: iproc: Retry request when CRS returned from EP

On Wed, Aug 23, 2017 at 11:30 PM, Bjorn Helgaas wrote: > On Wed, Aug 23, 2017 at 09:32:06PM +0530, Oza Oza wrote: >> On Wed, Aug 23, 2017 at 9:22 PM, Sinan Kaya wrote: >> > Hi Oza, >> > >> >> In working Enumuration case I get following: >> >> [9.125976] pci :00:00.0: bridge configuration

[PATCH v3] ASoC: Add a sanity check before using dai driver name

The dai driver's name is allowed to be NULL. So add a sanity check for that. Signed-off-by: Jeffy Chen Reported-by: Donglin Peng --- Changes in v3: Fix typo Changes in v2: Keep the oringinal check style. sound/soc/soc-core.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff

Re: possible circular locking dependency detected [was: linux-next: Tree for Aug 22]

On Wed, Aug 23, 2017 at 02:55:17PM +0900, Sergey Senozhatsky wrote: > On (08/23/17 13:35), Boqun Feng wrote: > > > KERN_CONT and "\n" should not be together. "\n" flushes the cont > > > buffer immediately. > > > > > > > Hmm.. Not quite familiar with printk() stuffs, but I could see several > >

Re: possible circular locking dependency detected [was: linux-next: Tree for Aug 22]

On Wed, Aug 23, 2017 at 02:55:17PM +0900, Sergey Senozhatsky wrote: > On (08/23/17 13:35), Boqun Feng wrote: > > > KERN_CONT and "\n" should not be together. "\n" flushes the cont > > > buffer immediately. > > > > > > > Hmm.. Not quite familiar with printk() stuffs, but I could see several > >

Re: [PATCH RESEND1 00/12] ALSA: vsnd: Add Xen para-virtualized frontend driver

On Aug 23 2017 23:51, Oleksandr Grytsov wrote: Hi, Thank you for detailed explanation. We understand that emulated interrupt on the frontend side is completely not acceptable and definitely we need to provide some feedback mechanism from Dom0 to DomU. In our case it is technically impossible

Re: [PATCH RESEND1 00/12] ALSA: vsnd: Add Xen para-virtualized frontend driver

On Aug 23 2017 23:51, Oleksandr Grytsov wrote: Hi, Thank you for detailed explanation. We understand that emulated interrupt on the frontend side is completely not acceptable and definitely we need to provide some feedback mechanism from Dom0 to DomU. In our case it is technically impossible

Re: Do we really need d_weak_revalidate???

On 24/08/17 11:21, NeilBrown wrote: > On Wed, Aug 23 2017, Ian Kent wrote: > >> On 23/08/17 10:32, Ian Kent wrote: >>> On 23/08/17 09:06, NeilBrown wrote: On Mon, Aug 21 2017, Ian Kent wrote: >> >> A mount isn't triggered by kern_path(pathname, 0, ). >> That '0' would need

Re: Do we really need d_weak_revalidate???

On 24/08/17 11:21, NeilBrown wrote: > On Wed, Aug 23 2017, Ian Kent wrote: > >> On 23/08/17 10:32, Ian Kent wrote: >>> On 23/08/17 09:06, NeilBrown wrote: On Mon, Aug 21 2017, Ian Kent wrote: >> >> A mount isn't triggered by kern_path(pathname, 0, ). >> That '0' would need

Re: [RFC PATCH 1/4] mm: madvise: read loop's step size beforehand in madvise_inject_error(), prepare for THP support.

On Wed, Aug 23, 2017 at 10:20:02AM -0400, Zi Yan wrote: > On 23 Aug 2017, at 3:49, Naoya Horiguchi wrote: > > > On Mon, Aug 14, 2017 at 09:52:13PM -0400, Zi Yan wrote: > >> From: Zi Yan > >> > >> The loop in madvise_inject_error() reads its step size from a page > >> after

Re: [RFC PATCH 1/4] mm: madvise: read loop's step size beforehand in madvise_inject_error(), prepare for THP support.

On Wed, Aug 23, 2017 at 10:20:02AM -0400, Zi Yan wrote: > On 23 Aug 2017, at 3:49, Naoya Horiguchi wrote: > > > On Mon, Aug 14, 2017 at 09:52:13PM -0400, Zi Yan wrote: > >> From: Zi Yan > >> > >> The loop in madvise_inject_error() reads its step size from a page > >> after it is soft-offlined.

Re: [PATCH] zram: add zstd to the supported algorithms list

Hello Sergey, On Thu, Aug 24, 2017 at 10:49:36AM +0900, Sergey Senozhatsky wrote: > Add ZSTD to the list of supported compression algorithms. > > Official benchmarks [1]: First of all, thanks for the work! I want to ask one thing. Could you add some benchmark(e.g.,) result(comp ratio and

Re: [PATCH v2 2/2] KVM: X86: Fix loss of exception which has not yet injected

2017-08-23 20:27 GMT+08:00 Paolo Bonzini : > On 23/08/2017 12:23, Wanpeng Li wrote: >> @@ -6341,7 +6345,8 @@ static int inject_pending_event(struct kvm_vcpu *vcpu, >> bool req_int_win) >> int r; >> >> /* try to reinject previous events if any */ >> - if

Re: [PATCH] zram: add zstd to the supported algorithms list

Hello Sergey, On Thu, Aug 24, 2017 at 10:49:36AM +0900, Sergey Senozhatsky wrote: > Add ZSTD to the list of supported compression algorithms. > > Official benchmarks [1]: First of all, thanks for the work! I want to ask one thing. Could you add some benchmark(e.g.,) result(comp ratio and

Re: [PATCH v2 2/2] KVM: X86: Fix loss of exception which has not yet injected

2017-08-23 20:27 GMT+08:00 Paolo Bonzini : > On 23/08/2017 12:23, Wanpeng Li wrote: >> @@ -6341,7 +6345,8 @@ static int inject_pending_event(struct kvm_vcpu *vcpu, >> bool req_int_win) >> int r; >> >> /* try to reinject previous events if any */ >> - if

[PATCH] usb:xhci:Fix regression when ATI chipsets detected

From: Sandeep Singh The following commit cause a regression on ATI chipsets. 'commit e788787ef4f9 ("usb:xhci:Add quirk for Certain failing HP keyboard on reset after resume")' This causes pinfo->smbus_dev to be wrongly set to NULL on systems with the ATI chipset that this

[PATCH] usb:xhci:Fix regression when ATI chipsets detected

From: Sandeep Singh The following commit cause a regression on ATI chipsets. 'commit e788787ef4f9 ("usb:xhci:Add quirk for Certain failing HP keyboard on reset after resume")' This causes pinfo->smbus_dev to be wrongly set to NULL on systems with the ATI chipset that this function checks for

Re: [PATCH 2/2] tracing: Fix kmemleak in set_trigger_filter

- Original Message - > From: "Steven Rostedt" > To: "Chunyu Hu" > Cc: mi...@kernel.org, linux-kernel@vger.kernel.org > Sent: Thursday, August 24, 2017 10:15:41 AM > Subject: Re: [PATCH 2/2] tracing: Fix kmemleak in set_trigger_filter > > On Wed,

Re: [PATCH 2/2] tracing: Fix kmemleak in set_trigger_filter

- Original Message - > From: "Steven Rostedt" > To: "Chunyu Hu" > Cc: mi...@kernel.org, linux-kernel@vger.kernel.org > Sent: Thursday, August 24, 2017 10:15:41 AM > Subject: Re: [PATCH 2/2] tracing: Fix kmemleak in set_trigger_filter > > On Wed, 23 Aug 2017 18:58:03 -0400 (EDT) >

Re: [PATCH 0/1] devpts: use dynamic_dname() to generate proc name

Hi On 2017-08-23, Eric W. Biederman wrote: > Linus Torvalds writes: > > On Wed, Aug 23, 2017 at 6:49 PM, Linus Torvalds > > wrote: [...] > This is so far untested (except for compiling) but I think this will > work. > > I factor

Re: [PATCH 0/1] devpts: use dynamic_dname() to generate proc name

Hi On 2017-08-23, Eric W. Biederman wrote: > Linus Torvalds writes: > > On Wed, Aug 23, 2017 at 6:49 PM, Linus Torvalds > > wrote: [...] > This is so far untested (except for compiling) but I think this will > work. > > I factor out devpts_ptmx_path out of devpts_acquire so the code >

[PATCH v3 2/4] KVM: X86: Fix loss of exception which has not yet injected

From: Wanpeng Li vmx_complete_interrupts() assumes that the exception is always injected, so it would be dropped by kvm_clear_exception_queue(). This patch separates exception.pending from exception.injected, exception.inject represents the exception is injected or the

[PATCH v3 4/4] KVM: nVMX: Fix trying to cancel vmlauch/vmresume

From: Wanpeng Li [ cut here ] WARNING: CPU: 7 PID: 3861 at /home/kernel/ssd/kvm/arch/x86/kvm//vmx.c:11299 nested_vmx_vmexit+0x176e/0x1980 [kvm_intel] CPU: 7 PID: 3861 Comm: qemu-system-x86 Tainted: GW OE 4.13.0-rc4+ #11 RIP:

[PATCH v3 2/4] KVM: X86: Fix loss of exception which has not yet injected

From: Wanpeng Li vmx_complete_interrupts() assumes that the exception is always injected, so it would be dropped by kvm_clear_exception_queue(). This patch separates exception.pending from exception.injected, exception.inject represents the exception is injected or the exception should be

[PATCH v3 4/4] KVM: nVMX: Fix trying to cancel vmlauch/vmresume

From: Wanpeng Li [ cut here ] WARNING: CPU: 7 PID: 3861 at /home/kernel/ssd/kvm/arch/x86/kvm//vmx.c:11299 nested_vmx_vmexit+0x176e/0x1980 [kvm_intel] CPU: 7 PID: 3861 Comm: qemu-system-x86 Tainted: GW OE 4.13.0-rc4+ #11 RIP:

[PATCH v3 1/4] KVM: VMX: use kvm_event_needs_reinjection

From: Wanpeng Li Use kvm_event_needs_reinjection() encapsulation. Cc: Paolo Bonzini Cc: Radim Krčmář Signed-off-by: Wanpeng Li --- arch/x86/kvm/vmx.c | 4 +--- 1 file changed, 1 insertion(+), 3

[PATCH v3 3/4] KVM: VMX: Move the nested_vmx_inject_exception_vmexit call from nested_vmx_check_exception to vmx_queue_exception

From: Wanpeng Li Move the nested_vmx_inject_exception_vmexit call from nested_vmx_check_exception to vmx_queue_exception. Signed-off-by: Wanpeng Li --- arch/x86/kvm/vmx.c | 21 +++-- 1 file changed, 11 insertions(+), 10

  1   2   3   4   5   6   7   8   9   10   >