[PATCH] soc/tegra: Fix bad of_node_put() in powergate init

The for_each_child_of_node macro itself maintains the correct reference count of the nodes so the explicit of_node_put() call causes a warning: [0.098960] OF: ERROR: Bad of_node_put() on /pmc@7000e400/powergates/xusba [0.098981] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.11.3 #1-NixOS [

[PATCH] soc/tegra: Fix bad of_node_put() in powergate init

The for_each_child_of_node macro itself maintains the correct reference count of the nodes so the explicit of_node_put() call causes a warning: [0.098960] OF: ERROR: Bad of_node_put() on /pmc@7000e400/powergates/xusba [0.098981] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.11.3 #1-NixOS [

Re: [PATCH] [RFC] ARM: move __bug_table into .data for XIP_KERNEL

On Sat, 29 Jul 2017, Ard Biesheuvel wrote: > > > > On 28 Jul 2017, at 16:27, Nicolas Pitre wrote: > > > >> On Fri, 28 Jul 2017, Arnd Bergmann wrote: > >> > >> Matt Hart reports that vf610m4_defconfig kernels grew to 2GB > >> xipImage size after the __bug_table

Re: [PATCH] [RFC] ARM: move __bug_table into .data for XIP_KERNEL

On Sat, 29 Jul 2017, Ard Biesheuvel wrote: > > > > On 28 Jul 2017, at 16:27, Nicolas Pitre wrote: > > > >> On Fri, 28 Jul 2017, Arnd Bergmann wrote: > >> > >> Matt Hart reports that vf610m4_defconfig kernels grew to 2GB > >> xipImage size after the __bug_table change. > >> > >> I tried out

RE: [PATCH V5 net-next 7/8] net: hns3: Add Ethtool support to HNS3 driver

Hi Andrew, > -Original Message- > From: Andrew Lunn [mailto:and...@lunn.ch] > Sent: Saturday, July 29, 2017 12:49 AM > To: Salil Mehta > Cc: da...@davemloft.net; Zhuangyuzeng (Yisen); huangdaode; lipeng (Y); > mehta.salil@gmail.com; net...@vger.kernel.org; linux- >

RE: [PATCH V5 net-next 7/8] net: hns3: Add Ethtool support to HNS3 driver

Hi Andrew, > -Original Message- > From: Andrew Lunn [mailto:and...@lunn.ch] > Sent: Saturday, July 29, 2017 12:49 AM > To: Salil Mehta > Cc: da...@davemloft.net; Zhuangyuzeng (Yisen); huangdaode; lipeng (Y); > mehta.salil@gmail.com; net...@vger.kernel.org; linux- >

Re: [PATCH] staging: pi433: fix Kconfig entry

On Tue, Jul 25, 2017 at 05:38:05PM +0200, Arnd Bergmann wrote: > I ran into a build error with the new pi433 driver and > CONFIG_SPI disabled: > > drivers/staging/pi433/pi433_if.o: In function `pi433_probe.part.6': > pi433_if.c:(.text+0x1657): undefined reference to `spi_write_then_read' >

Re: [PATCH] staging: pi433: fix Kconfig entry

On Tue, Jul 25, 2017 at 05:38:05PM +0200, Arnd Bergmann wrote: > I ran into a build error with the new pi433 driver and > CONFIG_SPI disabled: > > drivers/staging/pi433/pi433_if.o: In function `pi433_probe.part.6': > pi433_if.c:(.text+0x1657): undefined reference to `spi_write_then_read' >

Re: [PATCH v2] ARM: dts: bcm283x: Move the BCM2837 DT contents from arm64 to arm.

On 07/26/2017 01:01 PM, Eric Anholt wrote: > BCM2837 is somewhat unusual in that we build its DT on both arm32 and > arm64. Most devices are being run in arm32 mode. > > Having the body of the DT for 2837 separate from 2835/6 has been a > source of pain, as we often need to make changes that

Re: [PATCH v2] ARM: dts: bcm283x: Move the BCM2837 DT contents from arm64 to arm.

On 07/26/2017 01:01 PM, Eric Anholt wrote: > BCM2837 is somewhat unusual in that we build its DT on both arm32 and > arm64. Most devices are being run in arm32 mode. > > Having the body of the DT for 2837 separate from 2835/6 has been a > source of pain, as we often need to make changes that

RE: [PATCH V5 net-next 6/8] net: hns3: Add MDIO support to HNS3 Ethernet driver for hip08 SoC

Hi Andrew, > -Original Message- > From: linux-rdma-ow...@vger.kernel.org [mailto:linux-rdma- > ow...@vger.kernel.org] On Behalf Of Andrew Lunn > Sent: Saturday, July 29, 2017 12:29 AM > To: Salil Mehta > Cc: da...@davemloft.net; Zhuangyuzeng (Yisen); huangdaode; lipeng (Y); >

RE: [PATCH V5 net-next 6/8] net: hns3: Add MDIO support to HNS3 Ethernet driver for hip08 SoC

Hi Andrew, > -Original Message- > From: linux-rdma-ow...@vger.kernel.org [mailto:linux-rdma- > ow...@vger.kernel.org] On Behalf Of Andrew Lunn > Sent: Saturday, July 29, 2017 12:29 AM > To: Salil Mehta > Cc: da...@davemloft.net; Zhuangyuzeng (Yisen); huangdaode; lipeng (Y); >

RE: [PATCH V5 net-next 6/8] net: hns3: Add MDIO support to HNS3 Ethernet driver for hip08 SoC

Hi Andrew, > -Original Message- > From: Andrew Lunn [mailto:and...@lunn.ch] > Sent: Saturday, July 29, 2017 12:24 AM > To: Salil Mehta > Cc: da...@davemloft.net; Zhuangyuzeng (Yisen); huangdaode; lipeng (Y); > mehta.salil@gmail.com; net...@vger.kernel.org; linux- >

RE: [PATCH V5 net-next 6/8] net: hns3: Add MDIO support to HNS3 Ethernet driver for hip08 SoC

Hi Andrew, > -Original Message- > From: Andrew Lunn [mailto:and...@lunn.ch] > Sent: Saturday, July 29, 2017 12:24 AM > To: Salil Mehta > Cc: da...@davemloft.net; Zhuangyuzeng (Yisen); huangdaode; lipeng (Y); > mehta.salil@gmail.com; net...@vger.kernel.org; linux- >

Re: [PATCH V5 net-next 7/8] net: hns3: Add Ethtool support to HNS3 driver

On Fri, Jul 28, 2017 at 11:26:51PM +0100, Salil Mehta wrote: > +static const struct hns3_link_mode_mapping hns3_lm_map[] = { > + {HNS3_LM_FIBRE_BIT, ETHTOOL_LINK_MODE_FIBRE_BIT, FLG}, > + {HNS3_LM_AUTONEG_BIT, ETHTOOL_LINK_MODE_Autoneg_BIT, FLG}, > + {HNS3_LM_TP_BIT,

Re: [PATCH V5 net-next 7/8] net: hns3: Add Ethtool support to HNS3 driver

On Fri, Jul 28, 2017 at 11:26:51PM +0100, Salil Mehta wrote: > +static const struct hns3_link_mode_mapping hns3_lm_map[] = { > + {HNS3_LM_FIBRE_BIT, ETHTOOL_LINK_MODE_FIBRE_BIT, FLG}, > + {HNS3_LM_AUTONEG_BIT, ETHTOOL_LINK_MODE_Autoneg_BIT, FLG}, > + {HNS3_LM_TP_BIT,

RE: [PATCH v4 1/3] mfd: Add new mfd device TPS68470

Hi Lee, > Subject: Re: [PATCH v4 1/3] mfd: Add new mfd device TPS68470 > > On Tue, 25 Jul 2017, Mani, Rajmohan wrote: > > > Hi Lee, > > > > > Subject: Re: [PATCH v4 1/3] mfd: Add new mfd device TPS68470 > > > > > > On Fri, 21 Jul 2017, Mani, Rajmohan wrote: > > > > > On Wed, 19 Jul 2017,

RE: [PATCH v4 1/3] mfd: Add new mfd device TPS68470

Hi Lee, > Subject: Re: [PATCH v4 1/3] mfd: Add new mfd device TPS68470 > > On Tue, 25 Jul 2017, Mani, Rajmohan wrote: > > > Hi Lee, > > > > > Subject: Re: [PATCH v4 1/3] mfd: Add new mfd device TPS68470 > > > > > > On Fri, 21 Jul 2017, Mani, Rajmohan wrote: > > > > > On Wed, 19 Jul 2017,

Re: [PATCH 0/3] ANDROID: binder: reconcile with android common tree

On Fri, Jul 28, 2017 at 01:56:05PM +0200, Martijn Coenen wrote: > When comparing the android common kernel branch with > upstream, I found several differences. > > The "add padding" patch has long been applied in common, > and shipping versions of Android userspace depends on this > particular

Re: [PATCH 0/3] ANDROID: binder: reconcile with android common tree

On Fri, Jul 28, 2017 at 01:56:05PM +0200, Martijn Coenen wrote: > When comparing the android common kernel branch with > upstream, I found several differences. > > The "add padding" patch has long been applied in common, > and shipping versions of Android userspace depends on this > particular

Re: [PATCH v5 0/2] ZII RAVE platform driver

On Fri, Jul 28, 2017 at 07:27:02AM -0700, Andrey Smirnov wrote: > Greg, > > I am not sure if you are the right person to send these to, if you are > not, please let me know who would be the appropriate recepient and sorry for > the noise. Why not the platform driver maintainer(s)? Doesn't

RE: [PATCH v4 1/3] mfd: Add new mfd device TPS68470

Hi Andy, > Subject: Re: [PATCH v4 1/3] mfd: Add new mfd device TPS68470 > > On Fri, Jul 28, 2017 at 3:30 AM, Mani, Rajmohan > wrote: > >> On Wed, Jul 26, 2017 at 11:23 AM, Lee Jones > wrote: > >> > On Tue, 25 Jul 2017, Andy Shevchenko wrote: > >>

Re: [PATCH v5 0/2] ZII RAVE platform driver

On Fri, Jul 28, 2017 at 07:27:02AM -0700, Andrey Smirnov wrote: > Greg, > > I am not sure if you are the right person to send these to, if you are > not, please let me know who would be the appropriate recepient and sorry for > the noise. Why not the platform driver maintainer(s)? Doesn't

RE: [PATCH v4 1/3] mfd: Add new mfd device TPS68470

Hi Andy, > Subject: Re: [PATCH v4 1/3] mfd: Add new mfd device TPS68470 > > On Fri, Jul 28, 2017 at 3:30 AM, Mani, Rajmohan > wrote: > >> On Wed, Jul 26, 2017 at 11:23 AM, Lee Jones > wrote: > >> > On Tue, 25 Jul 2017, Andy Shevchenko wrote: > >> >> On Tue, Jul 25, 2017 at 12:10 PM, Lee Jones

[PATCH] selftests: ptp: include default header install path

Add the usr/include subdirectory of the top-level tree to the include path to fix build when cross compiling for ARM. testptp.c: In function 'main': testptp.c:289:15: error: 'struct ptp_clock_caps' has no member named 'cross_timestamping' caps.cross_timestamping); Signed-off-by:

[PATCH] selftests: ptp: include default header install path

Add the usr/include subdirectory of the top-level tree to the include path to fix build when cross compiling for ARM. testptp.c: In function 'main': testptp.c:289:15: error: 'struct ptp_clock_caps' has no member named 'cross_timestamping' caps.cross_timestamping); Signed-off-by:

Re: [PATCH 1/2] arm64: dts: move ns2 into northstar2 directory

On 07/19/2017 10:05 AM, Scott Branden wrote: > Place northstar2 into its own subdirectory. This helps as the number > of Broadcom boards grow and we can separate them per SoC. > > Signed-off-by: Scott Branden Applied, thanks Scott. -- Florian

Re: [PATCH 1/2] arm64: dts: move ns2 into northstar2 directory

On 07/19/2017 10:05 AM, Scott Branden wrote: > Place northstar2 into its own subdirectory. This helps as the number > of Broadcom boards grow and we can separate them per SoC. > > Signed-off-by: Scott Branden Applied, thanks Scott. -- Florian

Re: [PATCH V5 net-next 6/8] net: hns3: Add MDIO support to HNS3 Ethernet driver for hip08 SoC

> +int hclge_mac_mdio_config(struct hclge_dev *hdev) > +{ .. > +} > + > +int hclge_mac_start_phy(struct hclge_dev *hdev) > +{ > +} > + > +void hclge_mac_stop_phy(struct hclge_dev *hdev) > +{ > +} > -- These are not static functions. So i would expect them to be in a header file somewhere

Re: [PATCH V5 net-next 6/8] net: hns3: Add MDIO support to HNS3 Ethernet driver for hip08 SoC

> +int hclge_mac_mdio_config(struct hclge_dev *hdev) > +{ .. > +} > + > +int hclge_mac_start_phy(struct hclge_dev *hdev) > +{ > +} > + > +void hclge_mac_stop_phy(struct hclge_dev *hdev) > +{ > +} > -- These are not static functions. So i would expect them to be in a header file somewhere

Re: [PATCH V5 net-next 6/8] net: hns3: Add MDIO support to HNS3 Ethernet driver for hip08 SoC

> +static void hclge_mac_adjust_link(struct net_device *netdev) > +{ > + struct hnae3_handle *h = *((void **)netdev_priv(netdev)); > + struct hclge_vport *vport = hclge_get_vport(h); > + struct hclge_dev *hdev = vport->back; > + int duplex, speed; > + int ret; > + > + speed

Re: [PATCH V5 net-next 6/8] net: hns3: Add MDIO support to HNS3 Ethernet driver for hip08 SoC

> +static void hclge_mac_adjust_link(struct net_device *netdev) > +{ > + struct hnae3_handle *h = *((void **)netdev_priv(netdev)); > + struct hclge_vport *vport = hclge_get_vport(h); > + struct hclge_dev *hdev = vport->back; > + int duplex, speed; > + int ret; > + > + speed

[PATCH 3/6] ARM: dts: keystone-k2e: Add DSP node

The Keystone 2 66AK2E SoC has one TMS320C66x DSP Core Subsystem (C66x CorePac), with a 1.4 GHz C66x Fixed or Floating-Point DSP Core, and 32 KB of L1P & L1D SRAMs and a 1 MB L2 SRAM. Add the DT node for this DSP processor sub-system. The processor does not have a MMU, and uses various IPC

[PATCH 3/6] ARM: dts: keystone-k2e: Add DSP node

The Keystone 2 66AK2E SoC has one TMS320C66x DSP Core Subsystem (C66x CorePac), with a 1.4 GHz C66x Fixed or Floating-Point DSP Core, and 32 KB of L1P & L1D SRAMs and a 1 MB L2 SRAM. Add the DT node for this DSP processor sub-system. The processor does not have a MMU, and uses various IPC

[PATCH 2/6] ARM: dts: keystone-k2l: Add DSP nodes

The Keystone 2 66AK2L SoCs have 4 TMS320C66x DSP Core Subsystems (C66x CorePacs), each with a 1.0 GHz or 1.2 GHz C66x Fixed / Floating-Point DSP Core, and 32 KB of L1P & L1D SRAMs and a 1 MB L2 SRAM. Add the DT nodes for these DSP processor sub-systems. The processors do not have an MMU, and use

[PATCH 5/6] ARM: dts: keystone-k2l-evm: Add and enable common DSP CMA memory pool

From: Sam Nelson A common CMA memory pool reserved memory node is added, and is attached to all the DSP nodes through the 'memory-region' property on the 66AK2L EVM board. This area will be used for allocating virtio rings and buffers. The common node allows the DSP Memory

[PATCH 2/6] ARM: dts: keystone-k2l: Add DSP nodes

The Keystone 2 66AK2L SoCs have 4 TMS320C66x DSP Core Subsystems (C66x CorePacs), each with a 1.0 GHz or 1.2 GHz C66x Fixed / Floating-Point DSP Core, and 32 KB of L1P & L1D SRAMs and a 1 MB L2 SRAM. Add the DT nodes for these DSP processor sub-systems. The processors do not have an MMU, and use

[PATCH 5/6] ARM: dts: keystone-k2l-evm: Add and enable common DSP CMA memory pool

From: Sam Nelson A common CMA memory pool reserved memory node is added, and is attached to all the DSP nodes through the 'memory-region' property on the 66AK2L EVM board. This area will be used for allocating virtio rings and buffers. The common node allows the DSP Memory Protection and Address

[PATCH 6/6] ARM: dts: keystone-k2e-evm: Add and enable DSP CMA memory pool

From: Sam Nelson A CMA memory pool reserved memory node is added, and is attached to the DSP node through the 'memory-region' property on the K2E EVM board. This area will be used for allocating virtio rings and buffers. This node allows the DSP Memory Protection and Address

[PATCH 6/6] ARM: dts: keystone-k2e-evm: Add and enable DSP CMA memory pool

From: Sam Nelson A CMA memory pool reserved memory node is added, and is attached to the DSP node through the 'memory-region' property on the K2E EVM board. This area will be used for allocating virtio rings and buffers. This node allows the DSP Memory Protection and Address Extension (MPAX)

[PATCH 1/6] ARM: dts: keystone-k2hk: Add DSP nodes

The Keystone 2 66AK2H/66AK2K SoCs have upto 8 TMS320C66x DSP Core Subsystems (C66x CorePacs), each with a 1.0 GHz or 1.2 GHz C66x Fixed/Floating-Point DSP Core, and 32 KB of L1P & L1D SRAMs and a 1 MB L2 SRAM. Add the DT nodes for these DSP processor sub-systems. The processors do not have an MMU,

[PATCH 1/6] ARM: dts: keystone-k2hk: Add DSP nodes

The Keystone 2 66AK2H/66AK2K SoCs have upto 8 TMS320C66x DSP Core Subsystems (C66x CorePacs), each with a 1.0 GHz or 1.2 GHz C66x Fixed/Floating-Point DSP Core, and 32 KB of L1P & L1D SRAMs and a 1 MB L2 SRAM. Add the DT nodes for these DSP processor sub-systems. The processors do not have an MMU,

[PATCH 0/6] Add DSP DT nodes on Keystone platforms

Hi Santosh, The following series adds the DT nodes for the DSP devices present on the Keystone2 66AK2H/K, 66AK2L and 66AK2E SoCs. They are disabled in the base dts files, and enabled in the corresponding board files alongside an added common reserved CMA pool that is used by all the DSP devices.

[PATCH 0/6] Add DSP DT nodes on Keystone platforms

Hi Santosh, The following series adds the DT nodes for the DSP devices present on the Keystone2 66AK2H/K, 66AK2L and 66AK2E SoCs. They are disabled in the base dts files, and enabled in the corresponding board files alongside an added common reserved CMA pool that is used by all the DSP devices.

[PATCH 4/6] ARM: dts: keystone-k2hk-evm: Add and enable common DSP CMA memory pool

From: Sam Nelson A common CMA memory pool reserved memory node is added, and is attached to all the DSP nodes through the 'memory-region' property on the 66AK2H EVM board. This area will be used for allocating virtio rings and buffers. The common node allows the DSP Memory

[PATCH 4/6] ARM: dts: keystone-k2hk-evm: Add and enable common DSP CMA memory pool

From: Sam Nelson A common CMA memory pool reserved memory node is added, and is attached to all the DSP nodes through the 'memory-region' property on the 66AK2H EVM board. This area will be used for allocating virtio rings and buffers. The common node allows the DSP Memory Protection and Address

[PATCH] Bluetooth: btusb: add ID for LiteOn 04ca:3016

Contains a QCA6174A-5 chipset, with USB BT. Let's support loading firmware on it. Signed-off-by: Brian Norris --- drivers/bluetooth/btusb.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c index

[PATCH] Bluetooth: btusb: add ID for LiteOn 04ca:3016

Contains a QCA6174A-5 chipset, with USB BT. Let's support loading firmware on it. Signed-off-by: Brian Norris --- drivers/bluetooth/btusb.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c index 1cefff772cd0..24cc8383fdd4 100644 ---

Re: [PATCH v8 1/3] perf: cavium: Support memory controller PMU counters

On Thu, Jul 27, 2017 at 03:15:15PM +0200, Borislav Petkov wrote: > On Thu, Jul 27, 2017 at 11:08:56AM +0200, Jan Glauber wrote: > > OK. As fixing the firmware will take quite some time I'll go for the memory > > controller driver that starts EDAC / PMU depending on their CONFIG_. > > > > What

Re: [PATCH v8 1/3] perf: cavium: Support memory controller PMU counters

On Thu, Jul 27, 2017 at 03:15:15PM +0200, Borislav Petkov wrote: > On Thu, Jul 27, 2017 at 11:08:56AM +0200, Jan Glauber wrote: > > OK. As fixing the firmware will take quite some time I'll go for the memory > > controller driver that starts EDAC / PMU depending on their CONFIG_. > > > > What

Re: [PATCH v12 5/8] virtio-balloon: VIRTIO_BALLOON_F_SG

On Thu, Jul 27, 2017 at 10:50:11AM +0800, Wei Wang wrote: > > > > OK I thought this over. While we might need these new APIs in > > > > the future, I think that at the moment, there's a way to implement > > > > this feature that is significantly simpler. Just add each s/g > > > > as a separate

Re: [PATCH v12 5/8] virtio-balloon: VIRTIO_BALLOON_F_SG

On Thu, Jul 27, 2017 at 10:50:11AM +0800, Wei Wang wrote: > > > > OK I thought this over. While we might need these new APIs in > > > > the future, I think that at the moment, there's a way to implement > > > > this feature that is significantly simpler. Just add each s/g > > > > as a separate

Re: [PATCH] [RFC] ARM: move __bug_table into .data for XIP_KERNEL

> On 28 Jul 2017, at 16:27, Nicolas Pitre wrote: > >> On Fri, 28 Jul 2017, Arnd Bergmann wrote: >> >> Matt Hart reports that vf610m4_defconfig kernels grew to 2GB >> xipImage size after the __bug_table change. >> >> I tried out a few things and found that moving the

Re: [PATCH] [RFC] ARM: move __bug_table into .data for XIP_KERNEL

> On 28 Jul 2017, at 16:27, Nicolas Pitre wrote: > >> On Fri, 28 Jul 2017, Arnd Bergmann wrote: >> >> Matt Hart reports that vf610m4_defconfig kernels grew to 2GB >> xipImage size after the __bug_table change. >> >> I tried out a few things and found that moving the bug table >> into the

Re: [PATCH v12 5/8] virtio-balloon: VIRTIO_BALLOON_F_SG

On Fri, Jul 28, 2017 at 04:25:19PM +0800, Wei Wang wrote: > On 07/12/2017 08:40 PM, Wei Wang wrote: > > Add a new feature, VIRTIO_BALLOON_F_SG, which enables to > > transfer a chunk of ballooned (i.e. inflated/deflated) pages using > > scatter-gather lists to the host. > > > > The implementation

Re: [PATCH v12 5/8] virtio-balloon: VIRTIO_BALLOON_F_SG

On Fri, Jul 28, 2017 at 04:25:19PM +0800, Wei Wang wrote: > On 07/12/2017 08:40 PM, Wei Wang wrote: > > Add a new feature, VIRTIO_BALLOON_F_SG, which enables to > > transfer a chunk of ballooned (i.e. inflated/deflated) pages using > > scatter-gather lists to the host. > > > > The implementation

Re: [PATCH V3] pci: quirk: Apply APM ACS quirk to XGene devices

On Fri, 28 Jul 2017 11:50:43 -0700 Feng Kan wrote: > The APM X-Gene PCIe root port does not support ACS at this point. > However, the hw provides isolation and source validation through > the SMMU. The stream ID generated by the PCIe ports contain both > the BDF as well as the port

Re: [PATCH V3] pci: quirk: Apply APM ACS quirk to XGene devices

On Fri, 28 Jul 2017 11:50:43 -0700 Feng Kan wrote: > The APM X-Gene PCIe root port does not support ACS at this point. > However, the hw provides isolation and source validation through > the SMMU. The stream ID generated by the PCIe ports contain both > the BDF as well as the port ID in its 3

Re: [PATCH] device property: Fix usecount for of_graph_get_port_parent()

On Fri, Jul 28, 2017 at 3:23 AM, Tony Lindgren wrote: > * Tony Lindgren [170727 23:02]: >> * Rob Herring [170727 15:19]: >> > On Thu, Jul 27, 2017 at 4:44 AM, Tony Lindgren wrote: >> > > --- a/drivers/of/property.c >> >

Re: [PATCH] device property: Fix usecount for of_graph_get_port_parent()

On Fri, Jul 28, 2017 at 3:23 AM, Tony Lindgren wrote: > * Tony Lindgren [170727 23:02]: >> * Rob Herring [170727 15:19]: >> > On Thu, Jul 27, 2017 at 4:44 AM, Tony Lindgren wrote: >> > > --- a/drivers/of/property.c >> > > +++ b/drivers/of/property.c >> > > @@ -708,6 +708,15 @@ struct

[GIT PULL] DeviceTree fixes for 4.13

Linus, Please pull 2 small DT fixes for 4.13. Rob The following changes since commit 5771a8c08880cdca3bfb4a3fc6d309d6bba20877: Linux v4.13-rc1 (2017-07-15 15:22:10 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git

[GIT PULL] DeviceTree fixes for 4.13

Linus, Please pull 2 small DT fixes for 4.13. Rob The following changes since commit 5771a8c08880cdca3bfb4a3fc6d309d6bba20877: Linux v4.13-rc1 (2017-07-15 15:22:10 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git

Re: [PATCH 4.4 40/57] tpm: Provide strong locking for device removal

On Wed, Jul 26, 2017 at 02:03:06PM -0600, Jason Gunthorpe wrote: > On Wed, Jul 26, 2017 at 12:56:37PM -0700, Greg Kroah-Hartman wrote: > > On Tue, Jul 25, 2017 at 11:56:01PM +0100, Ben Hutchings wrote: > > > On Wed, 2017-07-19 at 13:12 +0200, Greg Kroah-Hartman wrote: > > > > 4.4-stable review

Re: [PATCH 4.4 40/57] tpm: Provide strong locking for device removal

On Wed, Jul 26, 2017 at 02:03:06PM -0600, Jason Gunthorpe wrote: > On Wed, Jul 26, 2017 at 12:56:37PM -0700, Greg Kroah-Hartman wrote: > > On Tue, Jul 25, 2017 at 11:56:01PM +0100, Ben Hutchings wrote: > > > On Wed, 2017-07-19 at 13:12 +0200, Greg Kroah-Hartman wrote: > > > > 4.4-stable review

Re: [PATCH 4.4 66/90] powerpc/numa: Fix percpu allocations to be NUMA aware

On Fri, Jul 28, 2017 at 03:53:35PM +0200, Michal Hocko wrote: > JFYI. We have encountered a regression after applying this patch on a > large ppc machine. While the patch is the right thing to do it doesn't > work well with the current vmalloc area size on ppc and large machines > where NUMA nodes

Re: [PATCH 4.4 66/90] powerpc/numa: Fix percpu allocations to be NUMA aware

On Fri, Jul 28, 2017 at 03:53:35PM +0200, Michal Hocko wrote: > JFYI. We have encountered a regression after applying this patch on a > large ppc machine. While the patch is the right thing to do it doesn't > work well with the current vmalloc area size on ppc and large machines > where NUMA nodes

[PATCH v4 2/4] net: ethernet: ti: cpts: convert to use ptp auxiliary worker

There could be significant delay in CPTS work schedule under high system load and on -RT which could cause CPTS misbehavior due to internal counter overflow. Usage of own kthread_worker allows to avoid such kind of issues and makes it possible to tune priority of CPTS kthread_worker thread on -RT

[PATCH v4 2/4] net: ethernet: ti: cpts: convert to use ptp auxiliary worker

There could be significant delay in CPTS work schedule under high system load and on -RT which could cause CPTS misbehavior due to internal counter overflow. Usage of own kthread_worker allows to avoid such kind of issues and makes it possible to tune priority of CPTS kthread_worker thread on -RT

Re: [PATCH net-next 4/4] net: dsa: lan9303: MDIO access phy registers directly

Den 28. juli 2017 23:28, skrev Andrew Lunn: Since the kernel module license is GPL, EXPORT_SYMBOL_GPL() would seem to be appropriate, which can be done as a subsequent patch. Reviewed-by: Florian Fainelli I have no idea how these legalities work. But for the record, I

[PATCH v4 0/4] net: ethernet: ti: cpts: fix tx timestamping timeout

Hi With the low Ethernet connection speed cpdma notification about packet processing can be received before CPTS TX timestamp event, which is set when packet actually left CPSW while cpdma notification is sent when packet pushed in CPSW fifo. As result, when connection is slow and CPU is fast

Re: [PATCH net-next 4/4] net: dsa: lan9303: MDIO access phy registers directly

Den 28. juli 2017 23:28, skrev Andrew Lunn: Since the kernel module license is GPL, EXPORT_SYMBOL_GPL() would seem to be appropriate, which can be done as a subsequent patch. Reviewed-by: Florian Fainelli I have no idea how these legalities work. But for the record, I give consent to change

[PATCH v4 0/4] net: ethernet: ti: cpts: fix tx timestamping timeout

Hi With the low Ethernet connection speed cpdma notification about packet processing can be received before CPTS TX timestamp event, which is set when packet actually left CPSW while cpdma notification is sent when packet pushed in CPSW fifo. As result, when connection is slow and CPU is fast

[PATCH v4 4/4] net: ethernet: ti: cpts: fix fifo read in cpts_find_ts

Now the call chain cpts_find_ts() |- cpts_fifo_read(cpts, CPTS_EV_PUSH) will stop reading CPTS FIFO if PUSH event is found. But this is not expected and CPTS FIFI should be completely drained here. This is most probably copy-paste error and it has no negative impact as CPTS_EV_PUSH should not

[PATCH v4 4/4] net: ethernet: ti: cpts: fix fifo read in cpts_find_ts

Now the call chain cpts_find_ts() |- cpts_fifo_read(cpts, CPTS_EV_PUSH) will stop reading CPTS FIFO if PUSH event is found. But this is not expected and CPTS FIFI should be completely drained here. This is most probably copy-paste error and it has no negative impact as CPTS_EV_PUSH should not

[PATCH v4 1/4] ptp: introduce ptp auxiliary worker

Many PTP drivers required to perform some asynchronous or periodic work, like periodically handling PHC counter overflow or handle delayed timestamp for RX/TX network packets. In most of the cases, such work is implemented using workqueues. Unfortunately, Kernel workqueues might introduce

[PATCH v4 1/4] ptp: introduce ptp auxiliary worker

Many PTP drivers required to perform some asynchronous or periodic work, like periodically handling PHC counter overflow or handle delayed timestamp for RX/TX network packets. In most of the cases, such work is implemented using workqueues. Unfortunately, Kernel workqueues might introduce

Re: [PATCHv2 2/2] ACPI / CPPC: Make cppc acpi driver aware of pcc subspace ids

Hi George, On 7/21/2017 1:43 AM, George Cherian wrote: > Based on ACPI 6.2 Section 8.4.7.1.9 If the PCC register space is used, > all PCC registers, for all processors in the same performance > domain (as defined by _PSD), must be defined to be in the same subspace. > Based on Section 14.1 of

Re: [PATCHv2 2/2] ACPI / CPPC: Make cppc acpi driver aware of pcc subspace ids

Hi George, On 7/21/2017 1:43 AM, George Cherian wrote: > Based on ACPI 6.2 Section 8.4.7.1.9 If the PCC register space is used, > all PCC registers, for all processors in the same performance > domain (as defined by _PSD), must be defined to be in the same subspace. > Based on Section 14.1 of

Re: [PATCH Y.A. RESEND] MAINTAINERS: fix alpha. ordering

On Thu, Jul 27, 2017 at 8:12 PM, Joe Perches wrote: > > I think it's better to centralize the MAINTAINERS > location in /MAINTAINERS/ than spread > them all over the tree given how many subsystems and > maintainerships are also spread around the tree. > > But the get_maintainers

Re: [PATCH Y.A. RESEND] MAINTAINERS: fix alpha. ordering

On Thu, Jul 27, 2017 at 8:12 PM, Joe Perches wrote: > > I think it's better to centralize the MAINTAINERS > location in /MAINTAINERS/ than spread > them all over the tree given how many subsystems and > maintainerships are also spread around the tree. > > But the get_maintainers patch I sent

[PATCH v4 3/4] net: ethernet: ti: cpts: fix tx timestamping timeout

With the low speed Ethernet connection CPDMA notification about packet processing can be received before CPTS TX timestamp event, which is set when packet actually left CPSW while cpdma notification is sent when packet pushed in CPSW fifo. As result, when connection is slow and CPU is fast enough

[PATCH v4 3/4] net: ethernet: ti: cpts: fix tx timestamping timeout

With the low speed Ethernet connection CPDMA notification about packet processing can be received before CPTS TX timestamp event, which is set when packet actually left CPSW while cpdma notification is sent when packet pushed in CPSW fifo. As result, when connection is slow and CPU is fast enough

[PATCH V5 net-next 3/8] net: hns3: Add HNS3 IMP(Integrated Mgmt Proc) Cmd Interface Support

This patch adds the support of IMP (Integrated Management Processor) command interface to the HNS3 driver. Each PF/VF has support of CQP(Command Queue Pair) ring interface. Each CQP consis of send queue CSQ and receive queue CRQ. There are various commands a PF/VF may support, like for Flow Table

[PATCH V5 net-next 3/8] net: hns3: Add HNS3 IMP(Integrated Mgmt Proc) Cmd Interface Support

This patch adds the support of IMP (Integrated Management Processor) command interface to the HNS3 driver. Each PF/VF has support of CQP(Command Queue Pair) ring interface. Each CQP consis of send queue CSQ and receive queue CRQ. There are various commands a PF/VF may support, like for Flow Table

[PATCH V5 net-next 1/8] net: hns3: Add support of HNS3 Ethernet Driver for hip08 SoC

This patch adds the support of Hisilicon Network Subsystem 3 Ethernet driver to hip08 family of SoCs. This driver includes basic Rx/Tx functionality. It also includes the client registration code with the HNAE3(Hisilicon Network Acceleration Engine 3) framework. This work provides the initial

[PATCH V5 net-next 1/8] net: hns3: Add support of HNS3 Ethernet Driver for hip08 SoC

This patch adds the support of Hisilicon Network Subsystem 3 Ethernet driver to hip08 family of SoCs. This driver includes basic Rx/Tx functionality. It also includes the client registration code with the HNAE3(Hisilicon Network Acceleration Engine 3) framework. This work provides the initial

[PATCH V5 net-next 4/8] net: hns3: Add HNS3 Acceleration Engine & Compatibility Layer Support

This patch adds the support of Hisilicon Network Subsystem Accceleration Engine and common operations to access it. This layer provides access to the hardware configuration, hardware statistics. This layer is also responsible for triggering the initialization of the PHY layer through the below

[PATCH V5 net-next 4/8] net: hns3: Add HNS3 Acceleration Engine & Compatibility Layer Support

This patch adds the support of Hisilicon Network Subsystem Accceleration Engine and common operations to access it. This layer provides access to the hardware configuration, hardware statistics. This layer is also responsible for triggering the initialization of the PHY layer through the below

[PATCH V5 net-next 6/8] net: hns3: Add MDIO support to HNS3 Ethernet driver for hip08 SoC

This patch adds the support of MDIO bus interface for HNS3 driver. Code provides various interfaces to start and stop the PHY layer and to read and write the MDIO bus or PHY. Signed-off-by: Daode Huang Signed-off-by: lipeng Signed-off-by: Salil

[PATCH V5 net-next 6/8] net: hns3: Add MDIO support to HNS3 Ethernet driver for hip08 SoC

This patch adds the support of MDIO bus interface for HNS3 driver. Code provides various interfaces to start and stop the PHY layer and to read and write the MDIO bus or PHY. Signed-off-by: Daode Huang Signed-off-by: lipeng Signed-off-by: Salil Mehta Signed-off-by: Yisen Zhuang --- Patch V5:

[PATCH V5 net-next 5/8] net: hns3: Add support of TX Scheduler & Shaper to HNS3 driver

THis patch adds the support of the Scheduling and Shaping functionalities during the transmit leg. This also adds the support of Pause at MAC level. (Pause at per-priority level shall be added later along with the DCB feature). Hardware as such consists of two types of cofiguration of 6 level

[PATCH V5 net-next 5/8] net: hns3: Add support of TX Scheduler & Shaper to HNS3 driver

THis patch adds the support of the Scheduling and Shaping functionalities during the transmit leg. This also adds the support of Pause at MAC level. (Pause at per-priority level shall be added later along with the DCB feature). Hardware as such consists of two types of cofiguration of 6 level

[PATCH V5 net-next 8/8] net: hns3: Add HNS3 driver to kernel build framework & MAINTAINERS

This patch updates the MAINTAINERS file with HNS3 Ethernet driver maintainers names and other details. This also introduces the new Makefiles required to build the HNS3 Ethernet driver and updates the existing Kconfig file in the hisilicon folder. Signed-off-by: Salil Mehta

[PATCH V5 net-next 7/8] net: hns3: Add Ethtool support to HNS3 driver

This patch adds the support of the Ethtool interface to the HNS3 Ethernet driver. Various commands to read the statistics, configure the offloading, loopback selftest etc. are supported. Signed-off-by: Daode Huang Signed-off-by: lipeng

[PATCH V5 net-next 8/8] net: hns3: Add HNS3 driver to kernel build framework & MAINTAINERS

This patch updates the MAINTAINERS file with HNS3 Ethernet driver maintainers names and other details. This also introduces the new Makefiles required to build the HNS3 Ethernet driver and updates the existing Kconfig file in the hisilicon folder. Signed-off-by: Salil Mehta --- Patch V5:

[PATCH V5 net-next 7/8] net: hns3: Add Ethtool support to HNS3 driver

This patch adds the support of the Ethtool interface to the HNS3 Ethernet driver. Various commands to read the statistics, configure the offloading, loopback selftest etc. are supported. Signed-off-by: Daode Huang Signed-off-by: lipeng Signed-off-by: Salil Mehta Signed-off-by: Yisen Zhuang

[PATCH V5 net-next 2/8] net: hns3: Add support of the HNAE3 framework

This patch adds the support of the HNAE3 (Hisilicon Network Acceleration Engine 3) framework support to the HNS3 driver. Framework facilitates clients like ENET(HNS3 Ethernet Driver), RoCE and user-space Ethernet drivers (like ODP etc.) to register with HNAE3 devices and their associated

[PATCH V5 net-next 2/8] net: hns3: Add support of the HNAE3 framework

This patch adds the support of the HNAE3 (Hisilicon Network Acceleration Engine 3) framework support to the HNS3 driver. Framework facilitates clients like ENET(HNS3 Ethernet Driver), RoCE and user-space Ethernet drivers (like ODP etc.) to register with HNAE3 devices and their associated

[PATCH V5 net-next 0/8] Hisilicon Network Subsystem 3 Ethernet Driver

This patch-set contains the support of the HNS3 (Hisilicon Network Subsystem 3) Ethernet driver for hip08 family of SoCs and future upcoming SoCs. Hisilicon's new hip08 SoCs have integrated ethernet based on PCI Express and hence there was a need of new driver over the previous HNS driver which

[PATCH V5 net-next 0/8] Hisilicon Network Subsystem 3 Ethernet Driver

This patch-set contains the support of the HNS3 (Hisilicon Network Subsystem 3) Ethernet driver for hip08 family of SoCs and future upcoming SoCs. Hisilicon's new hip08 SoCs have integrated ethernet based on PCI Express and hence there was a need of new driver over the previous HNS driver which

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