Re: [PATCH 04/18] rpmsg: glink: Move the common glink protocol implementation to glink_native.c

On 8/16/2017 10:48 PM, Sricharan R wrote: + +struct glink_msg { + __le16 cmd; + __le16 param1; + __le32 param2; + u8 data[]; +} __packed; why we are using extra u8 data[] member here ? + +/** + * struct glink_defer_cmd - deferred incoming control message + * @node:

Re: [PATCH 04/18] rpmsg: glink: Move the common glink protocol implementation to glink_native.c

On 8/16/2017 10:48 PM, Sricharan R wrote: + +struct glink_msg { + __le16 cmd; + __le16 param1; + __le32 param2; + u8 data[]; +} __packed; why we are using extra u8 data[] member here ? + +/** + * struct glink_defer_cmd - deferred incoming control message + * @node:

[PATCH 1/3] mfd: Add support for Cherry Trail Dollar Cove TI PMIC

This patch adds the MFD driver for Dollar Cove TI PMIC (ACPI INT33F5) that is found on some Intel Cherry Trail devices. The driver is based on the original work by Intel, found at: https://github.com/01org/ProductionKernelQuilts This is a minimal version for adding the basic resources.

[PATCH 2/3] input/keyboard: Add support for Dollar Cove TI power button

This provides a new input driver for supporting the power button on Dollar Cove TI PMIC, found on Cherrytrail-based devices. The patch is based on the original work by Intel, found at: https://github.com/01org/ProductionKernelQuilts Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=193891

[PATCH 1/3] mfd: Add support for Cherry Trail Dollar Cove TI PMIC

This patch adds the MFD driver for Dollar Cove TI PMIC (ACPI INT33F5) that is found on some Intel Cherry Trail devices. The driver is based on the original work by Intel, found at: https://github.com/01org/ProductionKernelQuilts This is a minimal version for adding the basic resources.

[PATCH 2/3] input/keyboard: Add support for Dollar Cove TI power button

This provides a new input driver for supporting the power button on Dollar Cove TI PMIC, found on Cherrytrail-based devices. The patch is based on the original work by Intel, found at: https://github.com/01org/ProductionKernelQuilts Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=193891

[PATCH 0/3] Dollar Cove TI PMIC support for Intel Cherry Trail

Hi, this is a patch set to add the support for Dollar Cove TI PMIC found on some Intel Cherry Trail laptops / tablets. All drivers are based on the original code from Intel downstream patches, with lots of rewrites and cleanups. MFD driver is implemented as a stand-alone like a few other

Re: linux-next: manual merge of the tip tree with the iommu tree

Hi Stephen, On 08/22/17 at 01:50pm, Stephen Rothwell wrote: > Hi all, > > Today's linux-next merge of the tip tree got conflicts in: > > drivers/iommu/amd_iommu.c > drivers/iommu/amd_iommu_init.c > drivers/iommu/amd_iommu_proto.h > drivers/iommu/amd_iommu_types.h > > between commits: >

[PATCH 0/3] Dollar Cove TI PMIC support for Intel Cherry Trail

Hi, this is a patch set to add the support for Dollar Cove TI PMIC found on some Intel Cherry Trail laptops / tablets. All drivers are based on the original code from Intel downstream patches, with lots of rewrites and cleanups. MFD driver is implemented as a stand-alone like a few other

Re: linux-next: manual merge of the tip tree with the iommu tree

Hi Stephen, On 08/22/17 at 01:50pm, Stephen Rothwell wrote: > Hi all, > > Today's linux-next merge of the tip tree got conflicts in: > > drivers/iommu/amd_iommu.c > drivers/iommu/amd_iommu_init.c > drivers/iommu/amd_iommu_proto.h > drivers/iommu/amd_iommu_types.h > > between commits: >

[PATCH 3/3] ACPI / PMIC: Add opregion driver for Intel Dollar Cove TI PMIC

This patch adds the opregion driver for Dollar Cove TI PMIC on Intel Cherry Trail devices. The patch is based on the original work by Intel, found at: https://github.com/01org/ProductionKernelQuilts with many cleanups and rewrites. The driver is currently provided only as built-in to

[PATCH 3/3] ACPI / PMIC: Add opregion driver for Intel Dollar Cove TI PMIC

This patch adds the opregion driver for Dollar Cove TI PMIC on Intel Cherry Trail devices. The patch is based on the original work by Intel, found at: https://github.com/01org/ProductionKernelQuilts with many cleanups and rewrites. The driver is currently provided only as built-in to

Re: [PATCH v8 1/2] sched/deadline: Add support for SD_PREFER_SIBLING on find_later_rq()

On Mon, Aug 21, 2017 at 03:07:57PM +0100, Juri Lelli wrote: > > Consider a 4 core, SMT2 system: > > > > LLC [0 - 7] > > > > SMT [0,1] [2,3] [4,5] [6,7] > > > > If we do a wake-up on CPU0, we'll find CPU1, mark that as fallback, > > continue up the domain tree, exclude 0,1 from

Re: [PATCH v8 1/2] sched/deadline: Add support for SD_PREFER_SIBLING on find_later_rq()

On Mon, Aug 21, 2017 at 03:07:57PM +0100, Juri Lelli wrote: > > Consider a 4 core, SMT2 system: > > > > LLC [0 - 7] > > > > SMT [0,1] [2,3] [4,5] [6,7] > > > > If we do a wake-up on CPU0, we'll find CPU1, mark that as fallback, > > continue up the domain tree, exclude 0,1 from

Re: [PATCH v8 1/2] sched/deadline: Add support for SD_PREFER_SIBLING on find_later_rq()

On Mon, Aug 21, 2017 at 02:44:58PM +0100, Juri Lelli wrote: > Hi, > On 18/08/17 17:21, Byungchul Park wrote: > > It would be better to try to check other siblings first if > > SD_PREFER_SIBLING is flaged when pushing tasks - migration. > > > > Signed-off-by: Byungchul Park

Re: [PATCH v8 1/2] sched/deadline: Add support for SD_PREFER_SIBLING on find_later_rq()

On Mon, Aug 21, 2017 at 02:44:58PM +0100, Juri Lelli wrote: > Hi, > On 18/08/17 17:21, Byungchul Park wrote: > > It would be better to try to check other siblings first if > > SD_PREFER_SIBLING is flaged when pushing tasks - migration. > > > > Signed-off-by: Byungchul Park > > Mmm, this looks

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

On Mon, Aug 21, 2017 at 05:46:00PM +0200, Peter Zijlstra wrote: > > > Booting the very latest -tip on my test machine gets me the below splat. > > Dave, TJ, FYI, lockdep grew annotations for completions; it remembers > which locks were taken before we complete() and checks none of those are >

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

On Mon, Aug 21, 2017 at 05:46:00PM +0200, Peter Zijlstra wrote: > > > Booting the very latest -tip on my test machine gets me the below splat. > > Dave, TJ, FYI, lockdep grew annotations for completions; it remembers > which locks were taken before we complete() and checks none of those are >

Re: linux-next: manual merge of the l2-mtd tree with the kbuild-current tree

Hi Boris, 2017-08-22 14:37 GMT+09:00 Boris Brezillon : > Le Tue, 22 Aug 2017 11:56:14 +1000, > Stephen Rothwell a écrit : > >> Hi Brian, >> >> Today's linux-next merge of the l2-mtd tree got a conflict in: >> >>

Re: linux-next: manual merge of the l2-mtd tree with the kbuild-current tree

Hi Boris, 2017-08-22 14:37 GMT+09:00 Boris Brezillon : > Le Tue, 22 Aug 2017 11:56:14 +1000, > Stephen Rothwell a écrit : > >> Hi Brian, >> >> Today's linux-next merge of the l2-mtd tree got a conflict in: >> >> include/asm-generic/vmlinux.lds.h >> >> between commit: >> >> cb87481ee89d

Re: qustion about eeh_add_virt_device

On Sun, 2017-08-13 at 16:54 +0200, Julia Lawall wrote: > Hello, Hello, sorry for the delayed response. > > At the suggestion of Christoph Hellwig, I am working on inlining the > functions stored in the err_handler field of a pci_driver structure into > the pci_driver structure itself. A number

Re: qustion about eeh_add_virt_device

On Sun, 2017-08-13 at 16:54 +0200, Julia Lawall wrote: > Hello, Hello, sorry for the delayed response. > > At the suggestion of Christoph Hellwig, I am working on inlining the > functions stored in the err_handler field of a pci_driver structure into > the pci_driver structure itself. A number

Re: linux-next: manual merge of the l2-mtd tree with the kbuild-current tree

Le Tue, 22 Aug 2017 11:56:14 +1000, Stephen Rothwell a écrit : > Hi Brian, > > Today's linux-next merge of the l2-mtd tree got a conflict in: > > include/asm-generic/vmlinux.lds.h > > between commit: > > cb87481ee89d ("kbuild: linker script do not match C names

Re: linux-next: manual merge of the l2-mtd tree with the kbuild-current tree

Le Tue, 22 Aug 2017 11:56:14 +1000, Stephen Rothwell a écrit : > Hi Brian, > > Today's linux-next merge of the l2-mtd tree got a conflict in: > > include/asm-generic/vmlinux.lds.h > > between commit: > > cb87481ee89d ("kbuild: linker script do not match C names unless >

linux-next: build failure after merge of the slave-dma tree

Hi Vinod, After merging the slave-dma tree, today's linux-next build (x86_64 allmodconfig) failed like this: In file included from drivers/dma/dmaengine.h:9:0, from drivers/dma/altera-msgdma.c:27: drivers/dma/altera-msgdma.c: In function 'msgdma_probe':

linux-next: build failure after merge of the slave-dma tree

Hi Vinod, After merging the slave-dma tree, today's linux-next build (x86_64 allmodconfig) failed like this: In file included from drivers/dma/dmaengine.h:9:0, from drivers/dma/altera-msgdma.c:27: drivers/dma/altera-msgdma.c: In function 'msgdma_probe':

[PATCH] storvsc: do not assume SG list is continuous when doing bounce buffers (for 4.1 stable only)

From: Long Li This patch is for linux-stable 4.1 branch only. storvsc checks the SG list for gaps before passing them to Hyper-v device. If there are gaps, data is copied to a bounce buffer and a continuous data buffer is passed to Hyper-V. The check on gaps assumes SG

[PATCH] storvsc: do not assume SG list is continuous when doing bounce buffers (for 4.1 stable only)

From: Long Li This patch is for linux-stable 4.1 branch only. storvsc checks the SG list for gaps before passing them to Hyper-v device. If there are gaps, data is copied to a bounce buffer and a continuous data buffer is passed to Hyper-V. The check on gaps assumes SG list is continuous, and

[PATCH v2 3/3] ARM: sunxi: add support for R40 SoC

Allwinner R40 is a new SoC, with Quad Core Cortex-A7 and peripherals like A20. Add support for it. Signed-off-by: Icenowy Zheng --- Changes in v2: - Fix alphabetical orders. Documentation/arm/sunxi/README | 6 ++

[PATCH v2 3/3] ARM: sunxi: add support for R40 SoC

Allwinner R40 is a new SoC, with Quad Core Cortex-A7 and peripherals like A20. Add support for it. Signed-off-by: Icenowy Zheng --- Changes in v2: - Fix alphabetical orders. Documentation/arm/sunxi/README | 6 ++ Documentation/devicetree/bindings/arm/sunxi.txt | 1 +

[PATCH v2 2/3] ARM: sunxi: fix the core number of V3s in sunxi README

The Allwinner V3s SoC is not quad-core, but single-core. Fix this in the README file. Fixes: b074fede01c0 ("arm: sunxi: add support for V3s SoC") Signed-off-by: Icenowy Zheng --- Documentation/arm/sunxi/README | 9 + 1 file changed, 5 insertions(+), 4 deletions(-)

[PATCH v2 2/3] ARM: sunxi: fix the core number of V3s in sunxi README

The Allwinner V3s SoC is not quad-core, but single-core. Fix this in the README file. Fixes: b074fede01c0 ("arm: sunxi: add support for V3s SoC") Signed-off-by: Icenowy Zheng --- Documentation/arm/sunxi/README | 9 + 1 file changed, 5 insertions(+), 4 deletions(-) diff --git

Re: [PATCH v2 2/3] i2c: davinci: Add PM Runtime Support

On Tuesday 22 August 2017 06:47 AM, Franklin S Cooper Jr wrote: > > > On 08/21/2017 04:05 AM, Sekhar Nori wrote: >> On Thursday 17 August 2017 03:47 AM, Franklin S Cooper Jr wrote: >> >>> @@ -802,7 +821,6 @@ static int davinci_i2c_probe(struct platform_device >>> *pdev) >>> dev->clk =

Re: [PATCH v2 2/3] i2c: davinci: Add PM Runtime Support

On Tuesday 22 August 2017 06:47 AM, Franklin S Cooper Jr wrote: > > > On 08/21/2017 04:05 AM, Sekhar Nori wrote: >> On Thursday 17 August 2017 03:47 AM, Franklin S Cooper Jr wrote: >> >>> @@ -802,7 +821,6 @@ static int davinci_i2c_probe(struct platform_device >>> *pdev) >>> dev->clk =

[PATCH v2 1/3] dt-bindings: add compatible string for Allwinner V3s SoC

The compatible string for Allwinner V3s SoC used to be missing. Add it to the binding document. Fixes: b074fede01c0 ("arm: sunxi: add support for V3s SoC") Signed-off-by: Icenowy Zheng --- Documentation/devicetree/bindings/arm/sunxi.txt | 1 + 1 file changed, 1 insertion(+)

[PATCH v2 1/3] dt-bindings: add compatible string for Allwinner V3s SoC

The compatible string for Allwinner V3s SoC used to be missing. Add it to the binding document. Fixes: b074fede01c0 ("arm: sunxi: add support for V3s SoC") Signed-off-by: Icenowy Zheng --- Documentation/devicetree/bindings/arm/sunxi.txt | 1 + 1 file changed, 1 insertion(+) diff --git

Re: [PATCH 4/4] staging: iio: tsl2x7x: constify i2c_device_id

Hi On Tuesday 22 August 2017 01:50 AM, Dan Carpenter wrote: Don't say "[PATCH 4/4]". It's not a patchset or a part of an email thread. Yes, It's part of these patchset. [PATCH 1/4] misc: apds9802als: constify i2c_device_id [PATCH 2/4] misc: hmc6352: constify i2c_device_id [PATCH 3/4]

Re: [PATCH 4/4] staging: iio: tsl2x7x: constify i2c_device_id

Hi On Tuesday 22 August 2017 01:50 AM, Dan Carpenter wrote: Don't say "[PATCH 4/4]". It's not a patchset or a part of an email thread. Yes, It's part of these patchset. [PATCH 1/4] misc: apds9802als: constify i2c_device_id [PATCH 2/4] misc: hmc6352: constify i2c_device_id [PATCH 3/4]

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

On Mon, Aug 21, 2017 at 05:46:00PM +0200, Peter Zijlstra wrote: > Now given the above observance rule and the fact that the below report > is from the complete, the thing that happened appears to be: > > > lockdep_map_acquire(>lockdep_map) > down_write() > >

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

On Mon, Aug 21, 2017 at 05:46:00PM +0200, Peter Zijlstra wrote: > Now given the above observance rule and the fact that the below report > is from the complete, the thing that happened appears to be: > > > lockdep_map_acquire(>lockdep_map) > down_write() > >

Re: [PATCH 2/2] ARM: sunxi: add support for R40 SoC

在 2017-08-21 17:34，Maxime Ripard 写道： Hi, On Sun, Aug 20, 2017 at 01:29:57PM +0800, Icenowy Zheng wrote: Allwinner R40 is a new SoC, with Quad Core Cortex-A7 and peripherals like A20. Add support for it. Signed-off-by: Icenowy Zheng --- Documentation/arm/sunxi/README

Re: [PATCH 2/2] ARM: sunxi: add support for R40 SoC

在 2017-08-21 17:34，Maxime Ripard 写道： Hi, On Sun, Aug 20, 2017 at 01:29:57PM +0800, Icenowy Zheng wrote: Allwinner R40 is a new SoC, with Quad Core Cortex-A7 and peripherals like A20. Add support for it. Signed-off-by: Icenowy Zheng --- Documentation/arm/sunxi/README | 6

Re: [PATCH v2 2/5] powerpc: pseries: vio: match parent nodes with of_find_node_by_path

Rob Herring writes: > In preparation to remove the full path from device_node.full_name, use > of_find_node_by_path instead of open coding with strcmp. > > Signed-off-by: Rob Herring > Cc: Benjamin Herrenschmidt > Cc: Paul Mackerras

Re: [PATCH v2 2/5] powerpc: pseries: vio: match parent nodes with of_find_node_by_path

Rob Herring writes: > In preparation to remove the full path from device_node.full_name, use > of_find_node_by_path instead of open coding with strcmp. > > Signed-off-by: Rob Herring > Cc: Benjamin Herrenschmidt > Cc: Paul Mackerras > Cc: Michael Ellerman > Cc: linuxppc-...@lists.ozlabs.org

Re: [RFC v1 4/6] platform: x86: Add generic Intel IPC driver

Hi Andy, On 08/18/2017 05:38 AM, Andy Shevchenko wrote: On Tue, Aug 1, 2017 at 9:13 PM, wrote: From: Kuppuswamy Sathyanarayanan Currently intel_scu_ipc.c, intel_pmc_ipc.c and intel_punit_ipc.c

Re: [RFC v1 4/6] platform: x86: Add generic Intel IPC driver

Hi Andy, On 08/18/2017 05:38 AM, Andy Shevchenko wrote: On Tue, Aug 1, 2017 at 9:13 PM, wrote: From: Kuppuswamy Sathyanarayanan Currently intel_scu_ipc.c, intel_pmc_ipc.c and intel_punit_ipc.c redundantly implements the same IPC features and has lot of code duplication between them. This

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

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': drivers/phy/ralink/phy-ralink-usb.c:195:13: warning: cast from pointer to integer of different size

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

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': drivers/phy/ralink/phy-ralink-usb.c:195:13: warning: cast from pointer to integer of different size

Re: [RFC v1 2/6] platform/x86: intel_pmc_ipc: Use devm_* calls in driver probe

Hi, On 08/18/2017 05:24 AM, Andy Shevchenko wrote: On Tue, Aug 1, 2017 at 9:13 PM, wrote: From: Kuppuswamy Sathyanarayanan This patch cleans up unnecessary free/alloc calls in this driver by using

Re: [RFC v1 2/6] platform/x86: intel_pmc_ipc: Use devm_* calls in driver probe

Hi, On 08/18/2017 05:24 AM, Andy Shevchenko wrote: On Tue, Aug 1, 2017 at 9:13 PM, wrote: From: Kuppuswamy Sathyanarayanan This patch cleans up unnecessary free/alloc calls in this driver by using devm_* calls. static int ipc_plat_remove(struct platform_device *pdev) { - struct

Re: [GIT PULL] phy: for 4.14

Hi Greg, On Monday 21 August 2017 06:15 PM, Kishon Vijay Abraham I wrote: > Hi Greg, > > Please find the phy pull request for 4.14 merge window below. > > It adds a new USB phy driver for Ralink SoC, add support for PCIe and > SATA PHY in phy-mt65xx-usb3 driver, add support for allwinner A83T >

Re: [GIT PULL] phy: for 4.14

Hi Greg, On Monday 21 August 2017 06:15 PM, Kishon Vijay Abraham I wrote: > Hi Greg, > > Please find the phy pull request for 4.14 merge window below. > > It adds a new USB phy driver for Ralink SoC, add support for PCIe and > SATA PHY in phy-mt65xx-usb3 driver, add support for allwinner A83T >

Re: [RFC v1 3/6] platform/x86: intel_pmc_ipc: Use MFD framework to create dependent devices

Hi Andy, On 08/18/2017 05:29 AM, Andy Shevchenko wrote: On Tue, Aug 1, 2017 at 9:13 PM, wrote: Currently, we have lot of repetitive code in dependent device resource allocation and device creation handling code. This logic can be improved if we

Re: [RFC v1 3/6] platform/x86: intel_pmc_ipc: Use MFD framework to create dependent devices

Hi Andy, On 08/18/2017 05:29 AM, Andy Shevchenko wrote: On Tue, Aug 1, 2017 at 9:13 PM, wrote: Currently, we have lot of repetitive code in dependent device resource allocation and device creation handling code. This logic can be improved if we use MFD framework for dependent device

Re: 4.13.0-rc4 sparc64: can't allocate MSI-X affinity masks for 2 vectors

> > >> I think with this patch from -rc6 the symptoms should be cured: > >> > >> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c005390374957baacbc38eef96ea360559510aa7 > >> > >> if that theory is right. > > > > The result with 4.13-rc6 is positive but mixed: the

Re: 4.13.0-rc4 sparc64: can't allocate MSI-X affinity masks for 2 vectors

> > >> I think with this patch from -rc6 the symptoms should be cured: > >> > >> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c005390374957baacbc38eef96ea360559510aa7 > >> > >> if that theory is right. > > > > The result with 4.13-rc6 is positive but mixed: the

Re: [RFC v1 1/6] platform/x86: intel_pmc_ipc: Fix error handling in ipc_pci_probe()

Hi Andy, On 08/18/2017 05:22 AM, Andy Shevchenko wrote: On Tue, Aug 1, 2017 at 9:13 PM, wrote: From: Kuppuswamy Sathyanarayanan This patch adds proper error handling for failure cases in ipc_pci_probe()

Re: [RFC v1 1/6] platform/x86: intel_pmc_ipc: Fix error handling in ipc_pci_probe()

Hi Andy, On 08/18/2017 05:22 AM, Andy Shevchenko wrote: On Tue, Aug 1, 2017 at 9:13 PM, wrote: From: Kuppuswamy Sathyanarayanan This patch adds proper error handling for failure cases in ipc_pci_probe() function. Signed-off-by: Kuppuswamy Sathyanarayanan ---

[GIT PULL v2] phy: for 4.14

Hi Greg, Stephen Rothwell reported a issue with my previous pull request w.r.t missing Signed-off-by committer. I've fixed that in this pull request. It adds a new USB phy driver for Ralink SoC, add support for PCIe and SATA PHY in phy-mt65xx-usb3 driver, add support for allwinner A83T USB PHY

[GIT PULL v2] phy: for 4.14

Hi Greg, Stephen Rothwell reported a issue with my previous pull request w.r.t missing Signed-off-by committer. I've fixed that in this pull request. It adds a new USB phy driver for Ralink SoC, add support for PCIe and SATA PHY in phy-mt65xx-usb3 driver, add support for allwinner A83T USB PHY

Re: [PATCH 2/2] sched/fair: Fix use of NULL with find_idlest_group

Hi Peter, On Mon, Aug 21, 2017 at 2:14 PM, Peter Zijlstra wrote: > On Mon, Aug 21, 2017 at 04:21:28PM +0100, Brendan Jackman wrote: >> The current use of returning NULL from find_idlest_group is broken in >> two cases: >> >> a1) The local group is not allowed. >> >>In

Re: [PATCH 2/2] sched/fair: Fix use of NULL with find_idlest_group

Hi Peter, On Mon, Aug 21, 2017 at 2:14 PM, Peter Zijlstra wrote: > On Mon, Aug 21, 2017 at 04:21:28PM +0100, Brendan Jackman wrote: >> The current use of returning NULL from find_idlest_group is broken in >> two cases: >> >> a1) The local group is not allowed. >> >>In this case, we currently

Re: [PATCH v4 1/9] ASoC: rt5514: Avoid legacy dai naming

Hi Mark, thanks for your reply. On 08/22/2017 01:31 AM, Mark Brown wrote: On Fri, Aug 18, 2017 at 11:03:46PM +0800, jeffy wrote: when using legacy dai naming, the dai->name for rt5514-spi would be the dev name, which is spi2.0 with my local 4.4 kernel, and would be spi32765.0 with upstream

Re: [PATCH v4 1/9] ASoC: rt5514: Avoid legacy dai naming

Hi Mark, thanks for your reply. On 08/22/2017 01:31 AM, Mark Brown wrote: On Fri, Aug 18, 2017 at 11:03:46PM +0800, jeffy wrote: when using legacy dai naming, the dai->name for rt5514-spi would be the dev name, which is spi2.0 with my local 4.4 kernel, and would be spi32765.0 with upstream

Re: [PATCH v5 0/4] Add support for ThunderX2 pmu events using json files

Hi Arnaldo, Will, are there any comments on this series? On Wed, Aug 16, 2017 at 12:40 PM, Ganapatrao Kulkarni wrote: > Extending json/jevent framework for parsing arm64 event files. > Adding jevents for ThunderX2 implementation defined PMU events. > > v5: >

Re: [PATCH v5 0/4] Add support for ThunderX2 pmu events using json files

Hi Arnaldo, Will, are there any comments on this series? On Wed, Aug 16, 2017 at 12:40 PM, Ganapatrao Kulkarni wrote: > Extending json/jevent framework for parsing arm64 event files. > Adding jevents for ThunderX2 implementation defined PMU events. > > v5: >- Addressed comments from

linux-next: manual merge of the rcu tree with the tip tree

Hi all, Today's linux-next merge of the rcu tree got a conflict in: arch/x86/mm/tlb.c between commit: 94b1b03b519b ("x86/mm: Rework lazy TLB mode and TLB freshness tracking") from the tip tree and commit: 3ed668659e95 ("membarrier: Document scheduler barrier requirements") from the

linux-next: manual merge of the rcu tree with the tip tree

Hi all, Today's linux-next merge of the rcu tree got a conflict in: arch/x86/mm/tlb.c between commit: 94b1b03b519b ("x86/mm: Rework lazy TLB mode and TLB freshness tracking") from the tip tree and commit: 3ed668659e95 ("membarrier: Document scheduler barrier requirements") from the

[PATCH v2 3/4] net: phy: realtek: add disable RX internal delay mode

From: Icenowy Zheng Some RTL8211E chips have broken GbE function, which needs a hack to fix. It's said that this fix will affect the performance on not-buggy PHYs, so it should only be enabled on boards with the broken PHY. Currently only some Pine64+ boards are known to have

[PATCH v2 3/4] net: phy: realtek: add disable RX internal delay mode

From: Icenowy Zheng Some RTL8211E chips have broken GbE function, which needs a hack to fix. It's said that this fix will affect the performance on not-buggy PHYs, so it should only be enabled on boards with the broken PHY. Currently only some Pine64+ boards are known to have this issue. This

[PATCH v2 2/4] net: phy: realtek: change macro name for page select register

From: Icenowy Zheng The page select register also exists on RTL8211E PHY (although it behaves slightly differently). Change the register macro name to remove the F. Signed-off-by: Icenowy Zheng --- drivers/net/phy/realtek.c | 12 +++- 1 file

[PATCH v2 2/4] net: phy: realtek: change macro name for page select register

From: Icenowy Zheng The page select register also exists on RTL8211E PHY (although it behaves slightly differently). Change the register macro name to remove the F. Signed-off-by: Icenowy Zheng --- drivers/net/phy/realtek.c | 12 +++- 1 file changed, 7 insertions(+), 5 deletions(-)

[PATCH v2 4/4] arm64: allwinner: a64: disable the RTL8211E internal RX delay on Pine64+

Some Pine64+ boards have a broken RTL8211E PHY, which cannot work reliably in 1000Base-T mode with default configuration. A solution is passed to Pine64, which is said to be disabling the internal RX delay of the PHY. Enable the hack by set the PHY mode to RGMII-TXID. Signed-off-by: Icenowy

[PATCH v2 4/4] arm64: allwinner: a64: disable the RTL8211E internal RX delay on Pine64+

Some Pine64+ boards have a broken RTL8211E PHY, which cannot work reliably in 1000Base-T mode with default configuration. A solution is passed to Pine64, which is said to be disabling the internal RX delay of the PHY. Enable the hack by set the PHY mode to RGMII-TXID. Signed-off-by: Icenowy

[PATCH v2 1/4] net: stmmac: dwmac-sun8i: support RGMII modes with PHY internal delay

Some boards uses a PHY with internal delay with an Allwinner SoC. Support these PHY modes in the driver. As the driver has no configuration registers for these modes, just treat them as ordinary RGMII. Signed-off-by: Icenowy Zheng ---

[PATCH v2 1/4] net: stmmac: dwmac-sun8i: support RGMII modes with PHY internal delay

Some boards uses a PHY with internal delay with an Allwinner SoC. Support these PHY modes in the driver. As the driver has no configuration registers for these modes, just treat them as ordinary RGMII. Signed-off-by: Icenowy Zheng --- drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c | 3 +++

[PATCH v2 0/4] Workaround broken RTL8211E on some Pine64+ boards

Some Pine64+ boards come with bad RTL8211E PHYs, which cannot work reliably unless do some hack. According to Pine64 people, Realtek describes the hack as totally disabling RX delay, and it's not documented at all. This patchset introduces the workaround on Pine64+. The first patch adds RGMII

[PATCH v2 0/4] Workaround broken RTL8211E on some Pine64+ boards

Some Pine64+ boards come with bad RTL8211E PHYs, which cannot work reliably unless do some hack. According to Pine64 people, Realtek describes the hack as totally disabling RX delay, and it's not documented at all. This patchset introduces the workaround on Pine64+. The first patch adds RGMII

linux-next: manual merge of the tip tree with the iommu tree

Hi all, Today's linux-next merge of the tip tree got conflicts in: drivers/iommu/amd_iommu.c drivers/iommu/amd_iommu_init.c drivers/iommu/amd_iommu_proto.h drivers/iommu/amd_iommu_types.h between commits: 4c232a708be1 ("iommu/amd: Detect pre enabled translation") 9494ea90a56d

linux-next: manual merge of the tip tree with the iommu tree

Hi all, Today's linux-next merge of the tip tree got conflicts in: drivers/iommu/amd_iommu.c drivers/iommu/amd_iommu_init.c drivers/iommu/amd_iommu_proto.h drivers/iommu/amd_iommu_types.h between commits: 4c232a708be1 ("iommu/amd: Detect pre enabled translation") 9494ea90a56d

Re: L0AN

Do you need a personal/business L0AN, if yes contact Softlink Int'L for more info

Re: L0AN

Do you need a personal/business L0AN, if yes contact Softlink Int'L for more info

[PATCH v1 2/3] arm: dts: add Nuvoton NPCM750 device tree

Add a common device tree for all Nuvoton NPCM750 BMCs and a board specific device tree for the NPCM750 (Poleg) evaluation board. Signed-off-by: Brendan Higgins --- .../devicetree/bindings/arm/npcm/npcm.txt | 6 + arch/arm/boot/dts/nuvoton-npcm750-evb.dts

[PATCH v1 2/3] arm: dts: add Nuvoton NPCM750 device tree

Add a common device tree for all Nuvoton NPCM750 BMCs and a board specific device tree for the NPCM750 (Poleg) evaluation board. Signed-off-by: Brendan Higgins --- .../devicetree/bindings/arm/npcm/npcm.txt | 6 + arch/arm/boot/dts/nuvoton-npcm750-evb.dts | 63 ++

Re: [PATCH] mfd: intel-lpss: Put I2C and SPI controllers into reset state on suspend

Hello Lee, Gentle ping. Do you see any issues with the following change? Thanks, Furquan On Sun, Jul 23, 2017 at 11:02 PM, Furquan Shaikh wrote: > > Commit 274e43edcda6f ("mfd: intel-lpss: Do not put device in reset > state on suspend") changed the behavior on suspend by

Re: [PATCH] mfd: intel-lpss: Put I2C and SPI controllers into reset state on suspend

Hello Lee, Gentle ping. Do you see any issues with the following change? Thanks, Furquan On Sun, Jul 23, 2017 at 11:02 PM, Furquan Shaikh wrote: > > Commit 274e43edcda6f ("mfd: intel-lpss: Do not put device in reset > state on suspend") changed the behavior on suspend by not putting LPSS >

[PATCH v1 3/3] MAINTAINERS: Add entry for the Nuvoton NPCM architecture

Add maintainers and reviewers for the Nuvoton NPCM architecture. Signed-off-by: Brendan Higgins --- MAINTAINERS | 13 + 1 file changed, 13 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 44cb004c765d..67064bf11904 100644 --- a/MAINTAINERS +++

[PATCH v1 3/3] MAINTAINERS: Add entry for the Nuvoton NPCM architecture

Add maintainers and reviewers for the Nuvoton NPCM architecture. Signed-off-by: Brendan Higgins --- MAINTAINERS | 13 + 1 file changed, 13 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 44cb004c765d..67064bf11904 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -1598,6

linux-next: manual merge of the tip tree with the arm64 tree

Hi all, Today's linux-next merge of the tip tree got a conflict in: drivers/firmware/efi/libstub/arm64-stub.c between commit: 170976bcab07 ("efi/arm64: add EFI_KIMG_ALIGN") from the arm64 tree and commit: 0426a4e68f18 ("efi/libstub/arm64: Force 'hidden' visibility for section

linux-next: manual merge of the tip tree with the arm64 tree

Hi all, Today's linux-next merge of the tip tree got a conflict in: drivers/firmware/efi/libstub/arm64-stub.c between commit: 170976bcab07 ("efi/arm64: add EFI_KIMG_ALIGN") from the arm64 tree and commit: 0426a4e68f18 ("efi/libstub/arm64: Force 'hidden' visibility for section

[PATCH v1 1/3] arm: npcm: add basic support for Nuvoton BMCs

Adds basic support for the Nuvoton NPCM750 BMC. Signed-off-by: Brendan Higgins --- arch/arm/Kconfig | 2 + arch/arm/Makefile| 1 + arch/arm/mach-npcm/Kconfig | 60 +++ arch/arm/mach-npcm/Makefile | 3 +

[PATCH v1 1/3] arm: npcm: add basic support for Nuvoton BMCs

Adds basic support for the Nuvoton NPCM750 BMC. Signed-off-by: Brendan Higgins --- arch/arm/Kconfig | 2 + arch/arm/Makefile| 1 + arch/arm/mach-npcm/Kconfig | 60 +++ arch/arm/mach-npcm/Makefile | 3 + arch/arm/mach-npcm/headsmp.S | 120

[PATCH v1 0/3] arm: npcm: add basic support for Nuvoton BMCs

This patch set adds support for the Nuvoton NPCM Baseboard Management Controller (BMC) SoC architecture as well as the NPCM750 variant. NPCM is an ARM based SoC with external DDR RAM and supports a large set of peripherals. The NPCM750 is based on Cortex A9 and comes in single core and dual core

[PATCH v1 0/3] arm: npcm: add basic support for Nuvoton BMCs

This patch set adds support for the Nuvoton NPCM Baseboard Management Controller (BMC) SoC architecture as well as the NPCM750 variant. NPCM is an ARM based SoC with external DDR RAM and supports a large set of peripherals. The NPCM750 is based on Cortex A9 and comes in single core and dual core

Re: [PATCH 2/2] mm: Update NUMA counter threshold size

On 2017年08月15日 17:58, Mel Gorman wrote: > On Tue, Aug 15, 2017 at 04:45:36PM +0800, Kemi Wang wrote: >> Threshold CPU cyclesThroughput(88 threads) >> 32 799 241760478 >> 64 640 301628829 >> 125 537 358906028 <==> system by

Re: [PATCH 2/2] mm: Update NUMA counter threshold size

On 2017年08月15日 17:58, Mel Gorman wrote: > On Tue, Aug 15, 2017 at 04:45:36PM +0800, Kemi Wang wrote: >> Threshold CPU cyclesThroughput(88 threads) >> 32 799 241760478 >> 64 640 301628829 >> 125 537 358906028 <==> system by

[PATCH v4 4/4] arm64: dts: rockchip: Handle pcie wake in pcie driver for Gru

Currently we are handling pcie wake irq in mrvl wifi driver. Move it to rockchip pcie driver for Gru boards. Signed-off-by: Jeffy Chen --- Changes in v4: None Changes in v3: None Changes in v2: None arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi | 15 +--

[PATCH v4 4/4] arm64: dts: rockchip: Handle pcie wake in pcie driver for Gru

Currently we are handling pcie wake irq in mrvl wifi driver. Move it to rockchip pcie driver for Gru boards. Signed-off-by: Jeffy Chen --- Changes in v4: None Changes in v3: None Changes in v2: None arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi | 15 +-- 1 file changed, 9

[PATCH v4 3/4] dt-bindings: PCI: rockchip: Add support for pcie wake irq

Add an optional interrupt for PCIE_WAKE pin. Signed-off-by: Jeffy Chen --- Changes in v4: None Changes in v3: None Changes in v2: None .../devicetree/bindings/pci/rockchip-pcie.txt| 20 1 file changed, 12 insertions(+), 8 deletions(-)

[PATCH v4 1/4] PCI: rockchip: Fix error handlings

Fix error handlings in probe & resume. Signed-off-by: Jeffy Chen --- Changes in v4: Rebase on newest for-next branch, also fix error handling by: 1e7f570a1b86 PCI: rockchip: Idle inactive PHY(s) Changes in v3: None Changes in v2: None

  1   2   3   4   5   6   7   8   9   10   >