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
[
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
[
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
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
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-
>
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-
>
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'
>
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'
>
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
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
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);
>
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);
>
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-
>
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-
>
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,
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,
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,
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,
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
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
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
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 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
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
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:
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:
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
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
> +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
> +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
> +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
> +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
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
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
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
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
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
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
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
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)
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,
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,
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.
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.
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
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
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
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
---
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
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
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
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
> 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
> 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
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
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
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
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
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
>> >
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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:
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
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
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
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
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:
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
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
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
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
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
101 - 200 of 1540 matches
Mail list logo