* Re: Synopsys Ethernet QoS Driver
From: Florian Fainelli @ 2016-11-18 16:35 UTC (permalink / raw)
To: Joao Pinto, davem, jeffrey.t.kirsher, jiri, saeedm, idosch
Cc: netdev, linux-kernel, CARLOS.PALMINHA, andreas.irestal
In-Reply-To: <fbf4263b-2b08-611d-f9cb-1f09c6f91117@synopsys.com>
On 11/18/2016 08:31 AM, Joao Pinto wrote:
> Hi Florian,
>
> On 18-11-2016 14:53, Florian Fainelli wrote:
>> On November 18, 2016 4:28:30 AM PST, Joao Pinto <Joao.Pinto@synopsys.com> wrote:
>>>
>>> Dear all,
>>>
>>> My name is Joao Pinto and I work at Synopsys.
>>> I am a kernel developer with special focus in mainline collaboration,
>>> both Linux
>>> and Buildroot. I was recently named one of the maintainers of the PCIe
>>> Designware core driver and I was the author of the Designware UFS
>>> driver stack.
>>>
>>> I am sending you this e-mail because you were the suggested contacts
>> >from the
>>> get_maintainers script concerning Ethernet drivers :).
>>>
>>> Currently I have the task to work on the mainline Ethernet QoS driver
>>> in which
>>> you are the author. The work would consist of the following:
>>>
>>> a) Separate the current driver in a Core driver (common ops) + platform
>>> glue
>>> driver + pci glue driver
>>> b) Add features that are currently only available internally
>>> c) Add specific phy support using the PHY framework
>>>
>>> I would also gladly be available to be its maintainer if you agree with
>>> it.
>>
>> Since you have both the hardware and a clear todo list for this driver, start submitting patches, get them included in David's tree and over time chances are that you will become the maintainer, either explicitly by adding an entry in the MAINTAINERS file or just by consistently contributing to this area.
>
> Thanks for the feedback.
>
> So I found 2 suitable git trees:
> a) kernel/git/davem/net.git
> b) kernel/git/davem/net-next.git
>
> We should submit to net.git correct? The net-next.git is a tree with selected
> patches for upstream only?
net-next.git is the git tree where new features/enhancements can be
submitted, while net.git is for bug fixes. Unless you absolutely need
to, it is common practice to avoid having changes in net-next.git depend
on net.git and vice versa.
Hope this helps.
--
Florian
^ permalink raw reply
* Re: [net-next] af_packet: Use virtio_net_hdr_to_skb().
From: David Miller @ 2016-11-18 16:35 UTC (permalink / raw)
To: jarno; +Cc: netdev
In-Reply-To: <1479348402-126248-1-git-send-email-jarno@ovn.org>
From: Jarno Rajahalme <jarno@ovn.org>
Date: Wed, 16 Nov 2016 18:06:42 -0800
> Use the common virtio_net_hdr_to_skb() instead of open coding it.
> Other call sites were changed by commit fd2a0437dc, but this one was
> missed, maybe because it is split in two parts of the source code.
>
> Also fix other call sites to be more uniform.
>
> Fixes: fd2a0437dc ("virtio_net: introduce virtio_net_hdr_{from,to}_skb")
> Signed-off-by: Jarno Rajahalme <jarno@ovn.org>
This patch is doing many more things that just this.
Do not mix unrelated changes together:
> @@ -821,9 +821,8 @@ static ssize_t macvtap_put_user(struct macvtap_queue *q,
> if (iov_iter_count(iter) < vnet_hdr_len)
> return -EINVAL;
>
> - ret = virtio_net_hdr_from_skb(skb, &vnet_hdr,
> - macvtap_is_little_endian(q));
> - if (ret)
> + if (virtio_net_hdr_from_skb(skb, &vnet_hdr,
> + macvtap_is_little_endian(q)))
> BUG();
>
> if (copy_to_iter(&vnet_hdr, sizeof(vnet_hdr), iter) !=
This has nothing to do with modifying code to use vrtio_net_hdr_to_skb(), it
doesn't belong in this patch.
> @@ -1361,15 +1360,12 @@ static ssize_t tun_put_user(struct tun_struct *tun,
> }
>
> if (vnet_hdr_sz) {
> - struct virtio_net_hdr gso = { 0 }; /* no info leak */
> - int ret;
> -
> + struct virtio_net_hdr gso;
This is _extremely_ opaque. The initializer is trying to prevent kernel memory
info leaks onto the network or into user space.
Maybe this transformation is valid but:
1) YOU DON'T EVEN MENTION IT IN YOUR COMMIT MESSAGE.
2) It's unrelated to this specific change, therefore it belongs in
a separate change.
3) You don't explain that it is a valid transformation, not why.
It is extremely disappointing to catch unrelated, potentially far
reaching things embedded in a patch when I review it.
Please do not ever do this.
> @@ -98,4 +98,4 @@ static inline int virtio_net_hdr_from_skb(const struct sk_buff *skb,
> return 0;
> }
>
> -#endif /* _LINUX_VIRTIO_BYTEORDER */
> +#endif /* _LINUX_VIRTIO_NET_H */
Another unrelated change.
> diff --git a/net/packet/af_packet.c b/net/packet/af_packet.c
> index 11db0d6..09abb88 100644
> --- a/net/packet/af_packet.c
> +++ b/net/packet/af_packet.c
> @@ -1971,8 +1971,6 @@ static unsigned int run_filter(struct sk_buff *skb,
> static int __packet_rcv_vnet(const struct sk_buff *skb,
> struct virtio_net_hdr *vnet_hdr)
> {
> - *vnet_hdr = (const struct virtio_net_hdr) { 0 };
> -
There is no way this belongs in this patch, and again you do not explain
why removing this initializer is valid.
^ permalink raw reply
* Re: Synopsys Ethernet QoS Driver
From: Joao Pinto @ 2016-11-18 16:31 UTC (permalink / raw)
To: Florian Fainelli, Joao Pinto, davem, jeffrey.t.kirsher, jiri,
saeedm, idosch
Cc: netdev, linux-kernel, CARLOS.PALMINHA, andreas.irestal
In-Reply-To: <771E7B93-5AB6-4F2B-8DEB-58DDB6A96D13@gmail.com>
Hi Florian,
On 18-11-2016 14:53, Florian Fainelli wrote:
> On November 18, 2016 4:28:30 AM PST, Joao Pinto <Joao.Pinto@synopsys.com> wrote:
>>
>> Dear all,
>>
>> My name is Joao Pinto and I work at Synopsys.
>> I am a kernel developer with special focus in mainline collaboration,
>> both Linux
>> and Buildroot. I was recently named one of the maintainers of the PCIe
>> Designware core driver and I was the author of the Designware UFS
>> driver stack.
>>
>> I am sending you this e-mail because you were the suggested contacts
>>from the
>> get_maintainers script concerning Ethernet drivers :).
>>
>> Currently I have the task to work on the mainline Ethernet QoS driver
>> in which
>> you are the author. The work would consist of the following:
>>
>> a) Separate the current driver in a Core driver (common ops) + platform
>> glue
>> driver + pci glue driver
>> b) Add features that are currently only available internally
>> c) Add specific phy support using the PHY framework
>>
>> I would also gladly be available to be its maintainer if you agree with
>> it.
>
> Since you have both the hardware and a clear todo list for this driver, start submitting patches, get them included in David's tree and over time chances are that you will become the maintainer, either explicitly by adding an entry in the MAINTAINERS file or just by consistently contributing to this area.
Thanks for the feedback.
So I found 2 suitable git trees:
a) kernel/git/davem/net.git
b) kernel/git/davem/net-next.git
We should submit to net.git correct? The net-next.git is a tree with selected
patches for upstream only?
>
^ permalink raw reply
* Re: Synopsys Ethernet QoS Driver
From: Florian Fainelli @ 2016-11-18 14:53 UTC (permalink / raw)
To: Joao Pinto, davem, jeffrey.t.kirsher, jiri, saeedm, idosch
Cc: netdev, linux-kernel, CARLOS.PALMINHA, andreas.irestal
In-Reply-To: <cbe5f79b-53a4-e116-1e09-bc975a66a8ca@synopsys.com>
On November 18, 2016 4:28:30 AM PST, Joao Pinto <Joao.Pinto@synopsys.com> wrote:
>
>Dear all,
>
>My name is Joao Pinto and I work at Synopsys.
>I am a kernel developer with special focus in mainline collaboration,
>both Linux
>and Buildroot. I was recently named one of the maintainers of the PCIe
>Designware core driver and I was the author of the Designware UFS
>driver stack.
>
>I am sending you this e-mail because you were the suggested contacts
>from the
>get_maintainers script concerning Ethernet drivers :).
>
>Currently I have the task to work on the mainline Ethernet QoS driver
>in which
>you are the author. The work would consist of the following:
>
>a) Separate the current driver in a Core driver (common ops) + platform
>glue
>driver + pci glue driver
>b) Add features that are currently only available internally
>c) Add specific phy support using the PHY framework
>
>I would also gladly be available to be its maintainer if you agree with
>it.
Since you have both the hardware and a clear todo list for this driver, start submitting patches, get them included in David's tree and over time chances are that you will become the maintainer, either explicitly by adding an entry in the MAINTAINERS file or just by consistently contributing to this area.
--
Florian
^ permalink raw reply
* Re: [mm PATCH v3 00/23] Add support for DMA writable pages being writable by the network stack
From: Alexander Duyck @ 2016-11-18 16:10 UTC (permalink / raw)
To: Andrew Morton
Cc: linux-mm, Netdev, linux-kernel@vger.kernel.org, Alexander Duyck
In-Reply-To: <20161110113027.76501.63030.stgit@ahduyck-blue-test.jf.intel.com>
On Thu, Nov 10, 2016 at 3:34 AM, Alexander Duyck
<alexander.h.duyck@intel.com> wrote:
> The first 19 patches in the set add support for the DMA attribute
> DMA_ATTR_SKIP_CPU_SYNC on multiple platforms/architectures. This is needed
> so that we can flag the calls to dma_map/unmap_page so that we do not
> invalidate cache lines that do not currently belong to the device. Instead
> we have to take care of this in the driver via a call to
> sync_single_range_for_cpu prior to freeing the Rx page.
>
> Patch 20 adds support for dma_map_page_attrs and dma_unmap_page_attrs so
> that we can unmap and map a page using the DMA_ATTR_SKIP_CPU_SYNC
> attribute.
>
> Patch 21 adds support for freeing a page that has multiple references being
> held by a single caller. This way we can free page fragments that were
> allocated by a given driver.
>
> The last 2 patches use these updates in the igb driver, and lay the
> groundwork to allow for us to reimplement the use of build_skb.
>
> v1: Minor fixes based on issues found by kernel build bot
> Few minor changes for issues found on code review
> Added Acked-by for patches that were acked and not changed
>
> v2: Added a few more Acked-by
> Submitting patches to mm instead of net-next
>
> v3: Added Acked-by for PowerPC architecture
> Dropped first 3 patches which were accepted into swiotlb tree
> Dropped comments describing swiotlb changes.
>
> ---
>
> Alexander Duyck (23):
> arch/arc: Add option to skip sync on DMA mapping
> arch/arm: Add option to skip sync on DMA map and unmap
> arch/avr32: Add option to skip sync on DMA map
> arch/blackfin: Add option to skip sync on DMA map
> arch/c6x: Add option to skip sync on DMA map and unmap
> arch/frv: Add option to skip sync on DMA map
> arch/hexagon: Add option to skip DMA sync as a part of mapping
> arch/m68k: Add option to skip DMA sync as a part of mapping
> arch/metag: Add option to skip DMA sync as a part of map and unmap
> arch/microblaze: Add option to skip DMA sync as a part of map and unmap
> arch/mips: Add option to skip DMA sync as a part of map and unmap
> arch/nios2: Add option to skip DMA sync as a part of map and unmap
> arch/openrisc: Add option to skip DMA sync as a part of mapping
> arch/parisc: Add option to skip DMA sync as a part of map and unmap
> arch/powerpc: Add option to skip DMA sync as a part of mapping
> arch/sh: Add option to skip DMA sync as a part of mapping
> arch/sparc: Add option to skip DMA sync as a part of map and unmap
> arch/tile: Add option to skip DMA sync as a part of map and unmap
> arch/xtensa: Add option to skip DMA sync as a part of mapping
> dma: Add calls for dma_map_page_attrs and dma_unmap_page_attrs
> mm: Add support for releasing multiple instances of a page
> igb: Update driver to make use of DMA_ATTR_SKIP_CPU_SYNC
> igb: Update code to better handle incrementing page count
>
>
> arch/arc/mm/dma.c | 5 ++
> arch/arm/common/dmabounce.c | 16 ++++--
> arch/avr32/mm/dma-coherent.c | 7 ++-
> arch/blackfin/kernel/dma-mapping.c | 8 +++
> arch/c6x/kernel/dma.c | 14 ++++-
> arch/frv/mb93090-mb00/pci-dma-nommu.c | 14 ++++-
> arch/frv/mb93090-mb00/pci-dma.c | 9 +++
> arch/hexagon/kernel/dma.c | 6 ++
> arch/m68k/kernel/dma.c | 8 +++
> arch/metag/kernel/dma.c | 16 +++++-
> arch/microblaze/kernel/dma.c | 10 +++-
> arch/mips/loongson64/common/dma-swiotlb.c | 2 -
> arch/mips/mm/dma-default.c | 8 ++-
> arch/nios2/mm/dma-mapping.c | 26 +++++++---
> arch/openrisc/kernel/dma.c | 3 +
> arch/parisc/kernel/pci-dma.c | 20 ++++++--
> arch/powerpc/kernel/dma.c | 9 +++
> arch/sh/kernel/dma-nommu.c | 7 ++-
> arch/sparc/kernel/iommu.c | 4 +-
> arch/sparc/kernel/ioport.c | 4 +-
> arch/tile/kernel/pci-dma.c | 12 ++++-
> arch/xtensa/kernel/pci-dma.c | 7 ++-
> drivers/net/ethernet/intel/igb/igb.h | 7 ++-
> drivers/net/ethernet/intel/igb/igb_main.c | 77 +++++++++++++++++++----------
> include/linux/dma-mapping.h | 20 +++++---
> include/linux/gfp.h | 2 +
> mm/page_alloc.c | 14 +++++
> 27 files changed, 246 insertions(+), 89 deletions(-)
>
So I am just wondering if I need to resubmit this to pick up the new
"Acked-by"s or if I should just wait?
As I said in the description my hope is to get this into the -mm tree
and I am not familiar with what the process is for being accepted
there.
Thanks.
- Alex
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCH] netns: make struct pernet_operations::id unsigned int
From: David Miller @ 2016-11-18 16:08 UTC (permalink / raw)
To: adobriyan; +Cc: netdev
In-Reply-To: <20161117015821.GA1200@avx2>
From: Alexey Dobriyan <adobriyan@gmail.com>
Date: Thu, 17 Nov 2016 04:58:21 +0300
> Make struct pernet_operations::id unsigned.
...
> Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
Applied, thank you.
^ permalink raw reply
* [PATCH] mlxsw: switchib: add MLXSW_PCI dependency
From: Arnd Bergmann @ 2016-11-18 16:01 UTC (permalink / raw)
To: Jiri Pirko, Ido Schimmel
Cc: Arnd Bergmann, David S. Miller, Ivan Vecera, Elad Raz, netdev,
linux-kernel
The newly added switchib driver fails to link if MLXSW_PCI=m:
drivers/net/ethernet/mellanox/mlxsw/mlxsw_switchib.o: In function^Cmlxsw_sib_module_exit':
switchib.c:(.exit.text+0x8): undefined reference to `mlxsw_pci_driver_unregister'
switchib.c:(.exit.text+0x10): undefined reference to `mlxsw_pci_driver_unregister'
drivers/net/ethernet/mellanox/mlxsw/mlxsw_switchib.o: In function `mlxsw_sib_module_init':
switchib.c:(.init.text+0x28): undefined reference to `mlxsw_pci_driver_register'
switchib.c:(.init.text+0x38): undefined reference to `mlxsw_pci_driver_register'
switchib.c:(.init.text+0x48): undefined reference to `mlxsw_pci_driver_unregister'
The other two such sub-drivers have a dependency, so add the same one
here. In theory we could allow this driver if MLXSW_PCI is disabled,
but it's probably not worth it.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
drivers/net/ethernet/mellanox/mlxsw/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/mellanox/mlxsw/Kconfig b/drivers/net/ethernet/mellanox/mlxsw/Kconfig
index bac2e5e826e2..49237a24605e 100644
--- a/drivers/net/ethernet/mellanox/mlxsw/Kconfig
+++ b/drivers/net/ethernet/mellanox/mlxsw/Kconfig
@@ -31,7 +31,7 @@ config MLXSW_PCI
config MLXSW_SWITCHIB
tristate "Mellanox Technologies SwitchIB and SwitchIB-2 support"
- depends on MLXSW_CORE && NET_SWITCHDEV
+ depends on MLXSW_CORE && MLXSW_PCI && NET_SWITCHDEV
default m
---help---
This driver supports Mellanox Technologies SwitchIB and SwitchIB-2
--
2.9.0
^ permalink raw reply related
* Re: [net-next PATCH v2] net: dummy: Introduce dummy virtual functions
From: Phil Sutter @ 2016-11-18 15:59 UTC (permalink / raw)
To: Or Gerlitz; +Cc: David Miller, Linux Netdev List, Sabrina Dubroca
In-Reply-To: <CAJ3xEMhG4Eeh6pwY2Uq_KxmuHJb9-xYYkr4Ps_kQWwEXeB9Sbg@mail.gmail.com>
Hi,
On Fri, Nov 18, 2016 at 12:04:14AM +0200, Or Gerlitz wrote:
> On Mon, Nov 14, 2016 at 3:02 PM, Phil Sutter <phil@nwl.cc> wrote:
>
> > Due to the assumption that all PFs are PCI devices, this implementation
> > is not completely straightforward: In order to allow for
> > rtnl_fill_ifinfo() to see the dummy VFs, a fake PCI parent device is
> > attached to the dummy netdev. This has to happen at the right spot so
> > register_netdevice() does not get confused. This patch abuses
> > ndo_fix_features callback for that. In ndo_uninit callback, the fake
> > parent is removed again for the same purpose.
>
> So you did some mimic-ing of PCI interface, how do you let the user to
> config the number of VFs? though a module param? why? if the module
> param only serves to say how many VF the device supports, maybe
> support the maximum possible by PCI spec and skip the module param?
Yes, this is controlled via module parameter. But it doesn't say how
much is supported but rather how many dummy VFs are to be created for
each dummy interface.
> > +module_param(num_vfs, int, 0);
> > +MODULE_PARM_DESC(num_vfs, "Number of dummy VFs per dummy device");
> > +
>
> > @@ -190,6 +382,7 @@ static int __init dummy_init_one(void)
> > err = register_netdevice(dev_dummy);
> > if (err < 0)
> > goto err;
> > +
> > return 0;
>
> nit, remove this added blank line..
Oh yes, thanks. Spontaneous reviewer's blindness. :)
The implementation is problematic in another aspect though: Upon reboot,
it seems like no netdev ops are being called but the fake PCI parent's
kobject is being freed which does not work (and leads to an oops).
Cheers, Phil
^ permalink raw reply
* Re: [PATCH net-next] udp: enable busy polling for all sockets
From: David Miller @ 2016-11-18 15:45 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev, willemb
In-Reply-To: <1479316242.8455.213.camel@edumazet-glaptop3.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Wed, 16 Nov 2016 09:10:42 -0800
> From: Eric Dumazet <edumazet@google.com>
>
> UDP busy polling is restricted to connected UDP sockets.
>
> This is because sk_busy_loop() only takes care of one NAPI context.
>
> There are cases where it could be extended.
>
> 1) Some hosts receive traffic on a single NIC, with one RX queue.
>
> 2) Some applications use SO_REUSEPORT and associated BPF filter
> to split the incoming traffic on one UDP socket per RX
> queue/thread/cpu
>
> 3) Some UDP sockets are used to send/receive traffic for one flow, but
> they do not bother with connect()
>
>
> This patch records the napi_id of first received skb, giving more
> reach to busy polling.
>
> Tested:
>
> lpaa23:~# echo 70 >/proc/sys/net/core/busy_read
> lpaa24:~# echo 70 >/proc/sys/net/core/busy_read
>
> lpaa23:~# for f in `seq 1 10`; do ./super_netperf 1 -H lpaa24 -t UDP_RR -l 5; done
>
> Before patch :
> 27867 28870 37324 41060 41215
> 36764 36838 44455 41282 43843
> After patch :
> 73920 73213 70147 74845 71697
> 68315 68028 75219 70082 73707
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Applied, thanks Eric.
^ permalink raw reply
* Re: [PATCH v3 3/5] net: asix: Fix AX88772x resume failures
From: Jon Hunter @ 2016-11-18 15:09 UTC (permalink / raw)
To: allan, robert.foss, freddy, Dean_Jenkins, Mark_Craske, davem,
ivecera, john.stultz, vpalatin, stephen, grundler, changchias,
andrew, tremyfr, colin.king, linux-usb, netdev, linux-kernel,
vpalatin
In-Reply-To: <010d01d23e5b$d8993130$89cb9390$@asix.com.tw>
Hi Allan,
On 14/11/16 09:45, ASIX_Allan [Office] wrote:
> Hi Jon,
>
> Please help to double check if the USB host controller of your Terga
> platform had been powered OFF while running the ax88772_suspend() routine or
> not?
Sorry for the delay. Today I set up a local board to reproduce this on
and was able to recreate the same problem. The Tegra xhci driver does
not power off during suspend and simply calls xhci_suspend(). I also
checked vbus to see if it was turning off but it is not. Furthermore I
don't see a new USB device detected after the error and so I don't see
any evidence that it ever disconnects.
Cheers
Jon
--
nvpublic
^ permalink raw reply
* [PATCH net] rtnetlink: fix FDB size computation
From: Sabrina Dubroca @ 2016-11-18 14:50 UTC (permalink / raw)
To: netdev; +Cc: Sabrina Dubroca, Hubert Sokolowski
Add missing NDA_VLAN attribute's size.
Fixes: 1e53d5bb8878 ("net: Pass VLAN ID to rtnl_fdb_notify.")
Signed-off-by: Sabrina Dubroca <sd@queasysnail.net>
---
net/core/rtnetlink.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/net/core/rtnetlink.c b/net/core/rtnetlink.c
index 2a75127f0e9e..92e75af2dc6a 100644
--- a/net/core/rtnetlink.c
+++ b/net/core/rtnetlink.c
@@ -2863,7 +2863,10 @@ static int nlmsg_populate_fdb_fill(struct sk_buff *skb,
static inline size_t rtnl_fdb_nlmsg_size(void)
{
- return NLMSG_ALIGN(sizeof(struct ndmsg)) + nla_total_size(ETH_ALEN);
+ return NLMSG_ALIGN(sizeof(struct ndmsg)) +
+ nla_total_size(ETH_ALEN) + /* NDA_LLADDR */
+ nla_total_size(sizeof(u16)) + /* NDA_VLAN */
+ 0;
}
static void rtnl_fdb_notify(struct net_device *dev, u8 *addr, u16 vid, int type,
--
2.10.2
^ permalink raw reply related
* Re: [PATCH] net: fec: Detect and recover receive queue hangs
From: Chris Lesiak @ 2016-11-18 14:36 UTC (permalink / raw)
To: Andy Duan
Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
Jaccon Bastiaansen
In-Reply-To: <AM4PR0401MB2260764510A33C534AB0136FFFB00@AM4PR0401MB2260.eurprd04.prod.outlook.com>
On 11/18/2016 12:44 AM, Andy Duan wrote:
> From: Chris Lesiak <chris.lesiak@licor.com> Sent: Friday, November 18, 2016 5:15 AM
> >To: Andy Duan <fugang.duan@nxp.com>
> >Cc: netdev@vger.kernel.org; linux-kernel@vger.kernel.org; Jaccon
> >Bastiaansen <jaccon.bastiaansen@gmail.com>; chris.lesiak@licor.com
> >Subject: [PATCH] net: fec: Detect and recover receive queue hangs
> >
> >This corrects a problem that appears to be similar to ERR006358. But while
> >ERR006358 is a race when the tx queue transitions from empty to not empty,
> >this problem is a race when the rx queue transitions from full to not full.
> >
> >The symptom is a receive queue that is stuck. The ENET_RDAR register will
> >read 0, indicating that there are no empty receive descriptors in the receive
> >ring. Since no additional frames can be queued, no RXF interrupts occur.
> >
> >This problem can be triggered with a 1 Gb link and about 400 Mbps of traffic.
I can cause the error by running the following on an imx6q: iperf -s -u
And sending packets from the other end of a 1 Gbps link:
iperf -c $IPADDR -u -b40000pps
A few others have seen this problem.
See: https://community.nxp.com/thread/322882
> >
> >This patch detects this condition, sets the work_rx bit, and reschedules the
> >poll method.
> >
> >Signed-off-by: Chris Lesiak <chris.lesiak@licor.com>
> >---
> > drivers/net/ethernet/freescale/fec_main.c | 31
> >+++++++++++++++++++++++++++++++
> > 1 file changed, 31 insertions(+)
> >
> Firstly, how to reproduce the issue, pls list the reproduce steps. Thanks.
> Secondly, pls check below comments.
>
> >diff --git a/drivers/net/ethernet/freescale/fec_main.c
> >b/drivers/net/ethernet/freescale/fec_main.c
> >index fea0f33..8a87037 100644
> >--- a/drivers/net/ethernet/freescale/fec_main.c
> >+++ b/drivers/net/ethernet/freescale/fec_main.c
> >@@ -1588,6 +1588,34 @@ fec_enet_interrupt(int irq, void *dev_id)
> > return ret;
> > }
> >
> >+static inline bool
> >+fec_enet_recover_rxq(struct fec_enet_private *fep, u16 queue_id) {
> >+ int work_bit = (queue_id == 0) ? 2 : ((queue_id == 1) ? 0 : 1);
> >+
> >+ if (readl(fep->rx_queue[queue_id]->bd.reg_desc_active))
> If rx ring is really empty in slight throughput cases, rdar is always cleared, then there always do napi reschedule.
I think that you are concerned that if rdar is zero due to this hardware
problem,
but the rx ring is actually empty, then fec_enet_rx_queue will never do
a write
to rdar so that it can be non-zero. That will cause napi to always be
resceduled.
I suppose that might be the case with zero rx traffic, and I was
concerned that
it might be true even when there was rx traffic. I suspected that the
hardware,
seeing that rdar is zero, would never queue another packet, even if
there were
in fact empty descriptors. But it doesn't seem to be the case. It does
reschedule
multiple times, but eventually sees some packets in the rx ring and
recovers.
I admit that I do not completely understand how that can happen. I did
confirm
that fec_enet_active_rxring is not being called.
Maybe someone with a deeper understanding of the fec than I can provide an
explanation.
>
> >+ return false;
> >+
> >+ dev_notice_once(&fep->pdev->dev, "Recovered rx queue\n");
> >+
> >+ fep->work_rx |= 1 << work_bit;
> >+
> >+ return true;
> >+}
> >+
> >+static inline bool fec_enet_recover_rxqs(struct fec_enet_private *fep)
> >+{
> >+ unsigned int q;
> >+ bool ret = false;
> >+
> >+ for (q = 0; q < fep->num_rx_queues; q++) {
> >+ if (fec_enet_recover_rxq(fep, q))
> >+ ret = true;
> >+ }
> >+
> >+ return ret;
> >+}
> >+
> > static int fec_enet_rx_napi(struct napi_struct *napi, int budget) {
> > struct net_device *ndev = napi->dev;
> >@@ -1601,6 +1629,9 @@ static int fec_enet_rx_napi(struct napi_struct *napi,
> >int budget)
> > if (pkts < budget) {
> > napi_complete(napi);
> > writel(FEC_DEFAULT_IMASK, fep->hwp + FEC_IMASK);
> >+
> >+ if (fec_enet_recover_rxqs(fep) && napi_reschedule(napi))
> >+ writel(FEC_NAPI_IMASK, fep->hwp + FEC_IMASK);
> > }
> > return pkts;
> > }
> >--
> >2.5.5
>
--
Chris Lesiak
Principal Design Engineer, Software
LI-COR Biosciences
chris.lesiak@licor.com
Any opinions expressed are those of the author and
do not necessarily represent those of his employer.
^ permalink raw reply
* [RFC PATCH v2 2/2] macb: Enable 1588 support in SAMA5D2 platform.
From: Andrei Pistirica @ 2016-11-18 14:21 UTC (permalink / raw)
To: netdev, linux-kernel, linux-arm-kernel, davem, nicolas.ferre,
harinikatakamlinux, harini.katakam
Cc: punnaia, michals, anirudh, boris.brezillon, alexandre.belloni,
tbultel, richardcochran, Andrei Pistirica
In-Reply-To: <1479478912-14067-1-git-send-email-andrei.pistirica@microchip.com>
Hardware time stamp on the PTP Ethernet packets are received using the
SO_TIMESTAMPING API. Where timers are obtained from the PTP event/peer
registers.
Signed-off-by: Andrei Pistirica <andrei.pistirica@microchip.com>
---
Version 2 patch for: https://patchwork.kernel.org/patch/9310991/
Modificaions:
- add PTP caps for SAMA5D2/3/4 platforms
- and cosmetic changes
drivers/net/ethernet/cadence/macb.c | 24 +++-
drivers/net/ethernet/cadence/macb.h | 13 ++
drivers/net/ethernet/cadence/macb_ptp.c | 222 ++++++++++++++++++++++++++++++++
3 files changed, 254 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ethernet/cadence/macb.c b/drivers/net/ethernet/cadence/macb.c
index d975882..eb66b76 100644
--- a/drivers/net/ethernet/cadence/macb.c
+++ b/drivers/net/ethernet/cadence/macb.c
@@ -697,6 +697,8 @@ static void macb_tx_interrupt(struct macb_queue *queue)
/* First, update TX stats if needed */
if (skb) {
+ macb_ptp_do_txstamp(bp, skb);
+
netdev_vdbg(bp->dev, "skb %u (data %p) TX complete\n",
macb_tx_ring_wrap(tail), skb->data);
bp->stats.tx_packets++;
@@ -853,6 +855,8 @@ static int gem_rx(struct macb *bp, int budget)
GEM_BFEXT(RX_CSUM, ctrl) & GEM_RX_CSUM_CHECKED_MASK)
skb->ip_summed = CHECKSUM_UNNECESSARY;
+ macb_ptp_do_rxstamp(bp, skb);
+
bp->stats.rx_packets++;
bp->stats.rx_bytes += skb->len;
@@ -1946,6 +1950,8 @@ static int macb_open(struct net_device *dev)
netif_tx_start_all_queues(dev);
+ macb_ptp_init(dev);
+
return 0;
}
@@ -2204,7 +2210,7 @@ static const struct ethtool_ops gem_ethtool_ops = {
.get_regs_len = macb_get_regs_len,
.get_regs = macb_get_regs,
.get_link = ethtool_op_get_link,
- .get_ts_info = ethtool_op_get_ts_info,
+ .get_ts_info = macb_get_ts_info,
.get_ethtool_stats = gem_get_ethtool_stats,
.get_strings = gem_get_ethtool_strings,
.get_sset_count = gem_get_sset_count,
@@ -2221,7 +2227,14 @@ static int macb_ioctl(struct net_device *dev, struct ifreq *rq, int cmd)
if (!phydev)
return -ENODEV;
- return phy_mii_ioctl(phydev, rq, cmd);
+ switch (cmd) {
+ case SIOCSHWTSTAMP:
+ return macb_hwtst_set(dev, rq, cmd);
+ case SIOCGHWTSTAMP:
+ return macb_hwtst_get(dev, rq);
+ default:
+ return phy_mii_ioctl(phydev, rq, cmd);
+ }
}
static int macb_set_features(struct net_device *netdev,
@@ -2812,7 +2825,7 @@ static const struct macb_config pc302gem_config = {
};
static const struct macb_config sama5d2_config = {
- .caps = MACB_CAPS_USRIO_DEFAULT_IS_MII_GMII,
+ .caps = MACB_CAPS_USRIO_DEFAULT_IS_MII_GMII | MACB_CAPS_GEM_HAS_PTP,
.dma_burst_length = 16,
.clk_init = macb_clk_init,
.init = macb_init,
@@ -2820,14 +2833,15 @@ static const struct macb_config sama5d2_config = {
static const struct macb_config sama5d3_config = {
.caps = MACB_CAPS_SG_DISABLED | MACB_CAPS_GIGABIT_MODE_AVAILABLE
- | MACB_CAPS_USRIO_DEFAULT_IS_MII_GMII,
+ | MACB_CAPS_USRIO_DEFAULT_IS_MII_GMII
+ | MACB_CAPS_GEM_HAS_PTP,
.dma_burst_length = 16,
.clk_init = macb_clk_init,
.init = macb_init,
};
static const struct macb_config sama5d4_config = {
- .caps = MACB_CAPS_USRIO_DEFAULT_IS_MII_GMII,
+ .caps = MACB_CAPS_USRIO_DEFAULT_IS_MII_GMII | MACB_CAPS_GEM_HAS_PTP,
.dma_burst_length = 4,
.clk_init = macb_clk_init,
.init = macb_init,
diff --git a/drivers/net/ethernet/cadence/macb.h b/drivers/net/ethernet/cadence/macb.h
index 2ee9af8..3ac824a 100644
--- a/drivers/net/ethernet/cadence/macb.h
+++ b/drivers/net/ethernet/cadence/macb.h
@@ -918,8 +918,21 @@ struct macb {
#ifdef CONFIG_MACB_USE_HWSTAMP
void macb_ptp_init(struct net_device *ndev);
+void macb_ptp_do_rxstamp(struct macb *bp, struct sk_buff *skb);
+void macb_ptp_do_txstamp(struct macb *bp, struct sk_buff *skb);
+int macb_ptp_get_ts_info(struct net_device *dev, struct ethtool_ts_info *info);
+#define macb_get_ts_info macb_ptp_get_ts_info
+int macb_hwtst_set(struct net_device *netdev, struct ifreq *ifr, int cmd);
+int macb_hwtst_get(struct net_device *netdev, struct ifreq *ifr);
#else
void macb_ptp_init(struct net_device *ndev) { }
+void macb_ptp_do_rxstamp(struct macb *bp, struct sk_buff *skb) { }
+void macb_ptp_do_txstamp(struct macb *bp, struct sk_buff *skb) { }
+#define macb_get_ts_info ethtool_op_get_ts_info
+int macb_hwtst_set(struct net_device *netdev, struct ifreq *ifr, int cmd)
+ { return -EOPNOTSUPP; }
+int macb_hwtst_get(struct net_device *netdev, struct ifreq *ifr)
+ { return -EOPNOTSUPP; }
#endif
static inline bool macb_is_gem(struct macb *bp)
diff --git a/drivers/net/ethernet/cadence/macb_ptp.c b/drivers/net/ethernet/cadence/macb_ptp.c
index 81ce3a9..f476b55 100644
--- a/drivers/net/ethernet/cadence/macb_ptp.c
+++ b/drivers/net/ethernet/cadence/macb_ptp.c
@@ -227,3 +227,225 @@ void macb_ptp_init(struct net_device *ndev)
dev_info(&bp->pdev->dev, "%s ptp clock registered.\n", GMAC_TIMER_NAME);
}
+/* While the GEM can timestamp PTP packets, it does not mark the RX descriptor
+ * to identify them. UDP packets must be parsed to identify PTP packets.
+ *
+ * Note: Inspired from drivers/net/ethernet/ti/cpts.c
+ */
+static int macb_get_ptp_peer(struct sk_buff *skb, int ptp_class)
+{
+ unsigned int offset = 0;
+ u8 *msgtype, *data = skb->data;
+
+ /* PTP frames are rare! */
+ if (likely(ptp_class == PTP_CLASS_NONE))
+ return -1;
+
+ if (ptp_class & PTP_CLASS_VLAN)
+ offset += VLAN_HLEN;
+
+ switch (ptp_class & PTP_CLASS_PMASK) {
+ case PTP_CLASS_IPV4:
+ offset += ETH_HLEN + IPV4_HLEN(data + offset) + UDP_HLEN;
+ break;
+ case PTP_CLASS_IPV6:
+ offset += ETH_HLEN + IP6_HLEN + UDP_HLEN;
+ break;
+ case PTP_CLASS_L2:
+ offset += ETH_HLEN;
+ break;
+
+ /* something went wrong! */
+ default:
+ return -1;
+ }
+
+ if (skb->len + ETH_HLEN < offset + OFF_PTP_SEQUENCE_ID)
+ return -1;
+
+ if (unlikely(ptp_class & PTP_CLASS_V1))
+ msgtype = data + offset + OFF_PTP_CONTROL;
+ else
+ msgtype = data + offset;
+
+ return (*msgtype) & 0x2;
+}
+
+static void macb_ptp_tx_hwtstamp(struct macb *bp, struct sk_buff *skb,
+ int peer_ev)
+{
+ struct skb_shared_hwtstamps *shhwtstamps = skb_hwtstamps(skb);
+ struct timespec64 ts;
+ u64 ns;
+
+ /* PTP Peer Event Frame packets */
+ if (peer_ev) {
+ ts.tv_sec = gem_readl(bp, PEFTSL);
+ ts.tv_nsec = gem_readl(bp, PEFTN);
+
+ /* PTP Event Frame packets */
+ } else {
+ ts.tv_sec = gem_readl(bp, EFTSL);
+ ts.tv_nsec = gem_readl(bp, EFTN);
+ }
+ ns = timespec64_to_ns(&ts);
+
+ memset(shhwtstamps, 0, sizeof(struct skb_shared_hwtstamps));
+ shhwtstamps->hwtstamp = ns_to_ktime(ns);
+ skb_tstamp_tx(skb, skb_hwtstamps(skb));
+}
+
+/* no static since it is called from macb driver! */
+void macb_ptp_do_txstamp(struct macb *bp, struct sk_buff *skb)
+{
+ if (!bp->hwts_tx_en)
+ return;
+
+ if (unlikely(skb_shinfo(skb)->tx_flags & SKBTX_HW_TSTAMP)) {
+ int class = ptp_classify_raw(skb);
+ int peer;
+
+ peer = macb_get_ptp_peer(skb, class);
+ if (peer < 0)
+ return;
+
+ /* Timestamp this packet */
+ macb_ptp_tx_hwtstamp(bp, skb, peer);
+ }
+}
+
+static void macb_ptp_rx_hwtstamp(struct macb *bp, struct sk_buff *skb,
+ int peer_ev)
+{
+ struct skb_shared_hwtstamps *shhwtstamps = skb_hwtstamps(skb);
+ struct timespec64 ts;
+ u64 ns;
+
+ if (peer_ev) {
+ /* PTP Peer Event Frame packets */
+ ts.tv_sec = gem_readl(bp, PEFRSL);
+ ts.tv_nsec = gem_readl(bp, PEFRN);
+ } else {
+ /* PTP Event Frame packets */
+ ts.tv_sec = gem_readl(bp, EFRSL);
+ ts.tv_nsec = gem_readl(bp, EFRN);
+ }
+ ns = timespec64_to_ns(&ts);
+
+ memset(shhwtstamps, 0, sizeof(struct skb_shared_hwtstamps));
+ shhwtstamps->hwtstamp = ns_to_ktime(ns);
+}
+
+/* no static since it is called from macb driver! */
+void macb_ptp_do_rxstamp(struct macb *bp, struct sk_buff *skb)
+{
+ int class;
+ int peer;
+
+ if (!bp->hwts_rx_en)
+ return;
+
+ __skb_push(skb, ETH_HLEN);
+ class = ptp_classify_raw(skb);
+ __skb_pull(skb, ETH_HLEN);
+
+ peer = macb_get_ptp_peer(skb, class);
+ if (peer < 0)
+ return;
+
+ macb_ptp_rx_hwtstamp(bp, skb, peer);
+}
+
+int macb_ptp_get_ts_info(struct net_device *dev, struct ethtool_ts_info *info)
+{
+ struct macb *bp = netdev_priv(dev);
+
+ ethtool_op_get_ts_info(dev, info);
+ info->so_timestamping =
+ SOF_TIMESTAMPING_TX_SOFTWARE |
+ SOF_TIMESTAMPING_RX_SOFTWARE |
+ SOF_TIMESTAMPING_SOFTWARE |
+ SOF_TIMESTAMPING_TX_HARDWARE |
+ SOF_TIMESTAMPING_RX_HARDWARE |
+ SOF_TIMESTAMPING_RAW_HARDWARE;
+ info->phc_index = -1;
+
+ if (bp->ptp_clock)
+ info->phc_index = ptp_clock_index(bp->ptp_clock);
+
+ return 0;
+}
+
+int macb_hwtst_set(struct net_device *netdev, struct ifreq *ifr, int cmd)
+{
+ struct hwtstamp_config config;
+ struct macb *priv = netdev_priv(netdev);
+ u32 regval;
+
+ netdev_vdbg(netdev, "macb_hwtstamp_ioctl\n");
+
+ if (copy_from_user(&config, ifr->ifr_data, sizeof(config)))
+ return -EFAULT;
+
+ /* reserved for future extensions */
+ if (config.flags)
+ return -EINVAL;
+
+ switch (config.tx_type) {
+ case HWTSTAMP_TX_OFF:
+ priv->hwts_tx_en = 0;
+ break;
+ case HWTSTAMP_TX_ON:
+ priv->hwts_tx_en = 1;
+ break;
+ default:
+ return -ERANGE;
+ }
+
+ switch (config.rx_filter) {
+ case HWTSTAMP_FILTER_NONE:
+ if (priv->hwts_rx_en)
+ priv->hwts_rx_en = 0;
+ break;
+ case HWTSTAMP_FILTER_PTP_V1_L4_EVENT:
+ case HWTSTAMP_FILTER_PTP_V2_L4_EVENT:
+ case HWTSTAMP_FILTER_PTP_V2_L2_EVENT:
+ case HWTSTAMP_FILTER_ALL:
+ case HWTSTAMP_FILTER_PTP_V1_L4_SYNC:
+ case HWTSTAMP_FILTER_PTP_V1_L4_DELAY_REQ:
+ case HWTSTAMP_FILTER_PTP_V2_L2_SYNC:
+ case HWTSTAMP_FILTER_PTP_V2_L4_SYNC:
+ case HWTSTAMP_FILTER_PTP_V2_L2_DELAY_REQ:
+ case HWTSTAMP_FILTER_PTP_V2_L4_DELAY_REQ:
+ case HWTSTAMP_FILTER_PTP_V2_EVENT:
+ case HWTSTAMP_FILTER_PTP_V2_SYNC:
+ case HWTSTAMP_FILTER_PTP_V2_DELAY_REQ:
+ config.rx_filter = HWTSTAMP_FILTER_ALL;
+ regval = macb_readl(priv, NCR);
+ macb_writel(priv, NCR, (regval | MACB_BIT(SRTSM)));
+
+ if (!priv->hwts_rx_en)
+ priv->hwts_rx_en = 1;
+ break;
+ default:
+ return -ERANGE;
+ }
+
+ return copy_to_user(ifr->ifr_data, &config, sizeof(config)) ?
+ -EFAULT : 0;
+}
+
+int macb_hwtst_get(struct net_device *netdev, struct ifreq *ifr)
+{
+ struct hwtstamp_config config;
+ struct macb *priv = netdev_priv(netdev);
+
+ config.flags = 0;
+ config.tx_type = priv->hwts_tx_en ? HWTSTAMP_TX_ON : HWTSTAMP_TX_OFF;
+ config.rx_filter = (priv->hwts_rx_en ?
+ HWTSTAMP_FILTER_ALL : HWTSTAMP_FILTER_NONE);
+
+ return copy_to_user(ifr->ifr_data, &config, sizeof(config)) ?
+ -EFAULT : 0;
+}
+
--
1.9.1
^ permalink raw reply related
* [RFC PATCH v2 1/2] macb: Add 1588 support in Cadence GEM.
From: Andrei Pistirica @ 2016-11-18 14:21 UTC (permalink / raw)
To: netdev, linux-kernel, linux-arm-kernel, davem, nicolas.ferre,
harinikatakamlinux, harini.katakam
Cc: punnaia, michals, anirudh, boris.brezillon, alexandre.belloni,
tbultel, richardcochran, Andrei Pistirica
Cadence GEM provides a 102 bit time counter with 48 bits for seconds,
30 bits for nsecs and 24 bits for sub-nsecs to control 1588 timestamping.
This patch does the following:
- Registers to ptp clock framework
- Timer initialization is done by writing time of day to the timer counter.
- ns increment register is programmed as NSEC_PER_SEC/TSU_CLK.
For a 16 bit subns precision, the subns increment equals
remainder of (NS_PER_SEC/TSU_CLK) * (2^16).
- HW time stamp capabilities are advertised via ethtool and macb ioctl is
updated accordingly.
- Timestamps are obtained from the TX/RX PTP event/PEER registers.
The timestamp obtained thus is updated in skb for upper layers to access.
- The drivers register functions with ptp to perform time and frequency
adjustment.
- Time adjustment is done by writing to the 1558_ADJUST register.
The controller will read the delta in this register and update the timer
counter register. Alternatively, for large time offset adjustments,
the driver reads the secs and nsecs counter values, adds/subtracts the
delta and updates the timer counter.
- Frequency adjustment is not directly supported by this IP.
addend is the initial value ns increment and similarly addendesub.
The ppb (parts per billion) provided is used as
ns_incr = addend +/- (ppb/rate).
Similarly the remainder of the above is used to populate subns increment.
In case the ppb requested is negative AND subns adjustment greater than
the addendsub, ns_incr is reduced by 1 and subns_incr is adjusted in
positive accordingly.
Signed-off-by: Andrei Pistirica <andrei.pistirica@microchip.com>
Signed-off-by: Harini Katakam <harinik@xilinx.com>
---
Version 2 patch for: https://patchwork.kernel.org/patch/9310989/.
Modifications:
- bitfields for TSU are named according to SAMA5D2 data sheet
- identify GEM-PTP support based on platform capability
- add spinlock for TSU access
- change macb_ptp_adjfreq and use fewer 64bit divisions
drivers/net/ethernet/cadence/Kconfig | 10 +-
drivers/net/ethernet/cadence/Makefile | 8 +-
drivers/net/ethernet/cadence/macb.h | 80 +++++++++++
drivers/net/ethernet/cadence/macb_ptp.c | 229 ++++++++++++++++++++++++++++++++
4 files changed, 325 insertions(+), 2 deletions(-)
create mode 100644 drivers/net/ethernet/cadence/macb_ptp.c
diff --git a/drivers/net/ethernet/cadence/Kconfig b/drivers/net/ethernet/cadence/Kconfig
index f0bcb15..ebbc65f 100644
--- a/drivers/net/ethernet/cadence/Kconfig
+++ b/drivers/net/ethernet/cadence/Kconfig
@@ -29,6 +29,14 @@ config MACB
support for the MACB/GEM chip.
To compile this driver as a module, choose M here: the module
- will be called macb.
+ will be called cadence-macb.
+
+config MACB_USE_HWSTAMP
+ bool "Use IEEE 1588 hwstamp"
+ depends on MACB
+ default y
+ select PTP_1588_CLOCK
+ ---help---
+ Enable IEEE 1588 Precision Time Protocol (PTP) support for MACB.
endif # NET_CADENCE
diff --git a/drivers/net/ethernet/cadence/Makefile b/drivers/net/ethernet/cadence/Makefile
index 91f79b1..4402d42 100644
--- a/drivers/net/ethernet/cadence/Makefile
+++ b/drivers/net/ethernet/cadence/Makefile
@@ -2,4 +2,10 @@
# Makefile for the Atmel network device drivers.
#
-obj-$(CONFIG_MACB) += macb.o
+cadence-macb-y := macb.o
+
+ifeq ($(CONFIG_MACB_USE_HWSTAMP),y)
+cadence-macb-y += macb_ptp.o
+endif
+
+obj-$(CONFIG_MACB) += cadence-macb.o
diff --git a/drivers/net/ethernet/cadence/macb.h b/drivers/net/ethernet/cadence/macb.h
index 3f385ab..2ee9af8 100644
--- a/drivers/net/ethernet/cadence/macb.h
+++ b/drivers/net/ethernet/cadence/macb.h
@@ -10,6 +10,10 @@
#ifndef _MACB_H
#define _MACB_H
+#include <linux/net_tstamp.h>
+#include <linux/ptp_clock.h>
+#include <linux/ptp_clock_kernel.h>
+
#define MACB_GREGS_NBR 16
#define MACB_GREGS_VERSION 2
#define MACB_MAX_QUEUES 8
@@ -129,6 +133,20 @@
#define GEM_RXIPCCNT 0x01a8 /* IP header Checksum Error Counter */
#define GEM_RXTCPCCNT 0x01ac /* TCP Checksum Error Counter */
#define GEM_RXUDPCCNT 0x01b0 /* UDP Checksum Error Counter */
+#define GEM_TISUBN 0x01bc /* 1588 Timer Increment Sub-ns */
+#define GEM_TSH 0x01c0 /* 1588 Timer Seconds High */
+#define GEM_TSL 0x01d0 /* 1588 Timer Seconds Low */
+#define GEM_TN 0x01d4 /* 1588 Timer Nanoseconds */
+#define GEM_TA 0x01d8 /* 1588 Timer Adjust */
+#define GEM_TI 0x01dc /* 1588 Timer Increment */
+#define GEM_EFTSL 0x01e0 /* PTP Event Frame Tx Seconds Low */
+#define GEM_EFTN 0x01e4 /* PTP Event Frame Tx Nanoseconds */
+#define GEM_EFRSL 0x01e8 /* PTP Event Frame Rx Seconds Low */
+#define GEM_EFRN 0x01ec /* PTP Event Frame Rx Nanoseconds */
+#define GEM_PEFTSL 0x01f0 /* PTP Peer Event Frame Tx Secs Low */
+#define GEM_PEFTN 0x01f4 /* PTP Peer Event Frame Tx Ns */
+#define GEM_PEFRSL 0x01f8 /* PTP Peer Event Frame Rx Sec Low */
+#define GEM_PEFRN 0x01fc /* PTP Peer Event Frame Rx Ns */
#define GEM_DCFG1 0x0280 /* Design Config 1 */
#define GEM_DCFG2 0x0284 /* Design Config 2 */
#define GEM_DCFG3 0x0288 /* Design Config 3 */
@@ -171,6 +189,7 @@
#define MACB_NCR_TPF_SIZE 1
#define MACB_TZQ_OFFSET 12 /* Transmit zero quantum pause frame */
#define MACB_TZQ_SIZE 1
+#define MACB_SRTSM_OFFSET 15
/* Bitfields in NCFGR */
#define MACB_SPD_OFFSET 0 /* Speed */
@@ -312,6 +331,36 @@
#define MACB_PFR_SIZE 1
#define MACB_PTZ_OFFSET 13 /* Enable pause time zero interrupt */
#define MACB_PTZ_SIZE 1
+#define MACB_PFTR_OFFSET 14 /* Pause Frame Transmitted */
+#define MACB_PFTR_SIZE 1
+#define MACB_DRQFR_OFFSET 18 /* PTP Delay Request Frame Received */
+#define MACB_DRQFR_SIZE 1
+#define MACB_SFR_OFFSET 19 /* PTP Sync Frame Received */
+#define MACB_SFR_SIZE 1
+#define MACB_DRQFT_OFFSET 20 /* PTP Delay Request Frame Transmitted */
+#define MACB_DRQFT_SIZE 1
+#define MACB_SFT_OFFSET 21 /* PTP Sync Frame Transmitted */
+#define MACB_SFT_SIZE 1
+#define MACB_PDRQFR_OFFSET 22 /* PDelay Request Frame Received */
+#define MACB_PDRQFR_SIZE 1
+#define MACB_PDRSFR_OFFSET 23 /* PDelay Response Frame Received */
+#define MACB_PDRSFR_SIZE 1
+#define MACB_PDRQFT_OFFSET 24 /* PDelay Request Frame Transmitted */
+#define MACB_PDRQFT_SIZE 1
+#define MACB_PDRSFT_OFFSET 25 /* PDelay Response Frame Transmitted */
+#define MACB_PDRSFT_SIZE 1
+#define MACB_SRI_OFFSET 26 /* TSU Seconds Register Increment */
+#define MACB_SRI_SIZE 1
+#define MACB_WOL_OFFSET 28 /* Wake On LAN */
+#define MACB_WOL_SIZE 1
+
+/* Timer increment fields */
+#define MACB_TI_CNS_OFFSET 0
+#define MACB_TI_CNS_SIZE 8
+#define MACB_TI_ACNS_OFFSET 8
+#define MACB_TI_ACNS_SIZE 8
+#define MACB_TI_NIT_OFFSET 16
+#define MACB_TI_NIT_SIZE 8
/* Bitfields in MAN */
#define MACB_DATA_OFFSET 0 /* data */
@@ -375,6 +424,18 @@
#define GEM_TX_PKT_BUFF_OFFSET 21
#define GEM_TX_PKT_BUFF_SIZE 1
+/* Bitfields in TISUBN */
+#define GEM_SUBNSINCR_OFFSET 0
+#define GEM_SUBNSINCR_SIZE 16
+
+/* Bitfields in TI */
+#define GEM_NSINCR_OFFSET 0
+#define GEM_NSINCR_SIZE 8
+
+/* Bitfields in ADJ */
+#define GEM_ADDSUB_OFFSET 31
+#define GEM_ADDSUB_SIZE 1
+
/* Constants for CLK */
#define MACB_CLK_DIV8 0
#define MACB_CLK_DIV16 1
@@ -405,6 +466,7 @@
#define MACB_CAPS_SG_DISABLED 0x40000000
#define MACB_CAPS_MACB_IS_GEM 0x80000000
#define MACB_CAPS_JUMBO 0x00000010
+#define MACB_CAPS_GEM_HAS_PTP 0x00000020
/* Bit manipulation macros */
#define MACB_BIT(name) \
@@ -840,8 +902,26 @@ struct macb {
unsigned int rx_frm_len_mask;
unsigned int jumbo_max_len;
+
+#ifdef CONFIG_MACB_USE_HWSTAMP
+ unsigned int hwts_tx_en;
+ unsigned int hwts_rx_en;
+ spinlock_t tsu_clk_lock;
+ unsigned int tsu_rate;
+
+ struct ptp_clock *ptp_clock;
+ struct ptp_clock_info ptp_caps;
+ unsigned int ns_incr;
+ unsigned int subns_incr;
+#endif
};
+#ifdef CONFIG_MACB_USE_HWSTAMP
+void macb_ptp_init(struct net_device *ndev);
+#else
+void macb_ptp_init(struct net_device *ndev) { }
+#endif
+
static inline bool macb_is_gem(struct macb *bp)
{
return !!(bp->caps & MACB_CAPS_MACB_IS_GEM);
diff --git a/drivers/net/ethernet/cadence/macb_ptp.c b/drivers/net/ethernet/cadence/macb_ptp.c
new file mode 100644
index 0000000..81ce3a9
--- /dev/null
+++ b/drivers/net/ethernet/cadence/macb_ptp.c
@@ -0,0 +1,229 @@
+/*
+ * PTP 1588 clock for SAMA5D2 platform.
+ *
+ * Copyright (C) 2015 Xilinx Inc.
+ * Copyright (C) 2016 Microchip Technology
+ *
+ * Authors: Harini Katakam <harinik@xilinx.com>
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#include <linux/clk.h>
+#include <linux/device.h>
+#include <linux/etherdevice.h>
+#include <linux/platform_device.h>
+#include <linux/time64.h>
+#include <linux/ptp_classify.h>
+#include <linux/if_ether.h>
+#include <linux/if_vlan.h>
+
+#include "macb.h"
+
+#define GMAC_TIMER_NAME "gmac-gem-ptp"
+
+static inline void macb_tsu_get_time(struct macb *bp, struct timespec64 *ts)
+{
+ u64 sec, sech, secl;
+
+ spin_lock(&bp->tsu_clk_lock);
+
+ /* get GEM internal time */
+ sech = gem_readl(bp, TSH);
+ secl = gem_readl(bp, TSL);
+ ts->tv_nsec = gem_readl(bp, TN);
+ ts->tv_sec = (sech << 32) | secl;
+
+ /* minimize the error */
+ sech = gem_readl(bp, TSH);
+ secl = gem_readl(bp, TSL);
+ sec = (sech << 32) | secl;
+ if (ts->tv_sec != sec) {
+ ts->tv_sec = sec;
+ ts->tv_nsec = gem_readl(bp, TN);
+ }
+
+ spin_unlock(&bp->tsu_clk_lock);
+}
+
+static inline void macb_tsu_set_time(struct macb *bp,
+ const struct timespec64 *ts)
+{
+ u32 ns, sech, secl;
+ s64 word_mask = 0xffffffff;
+
+ sech = (u32)ts->tv_sec;
+ secl = (u32)ts->tv_sec;
+ ns = ts->tv_nsec;
+ if (ts->tv_sec > word_mask)
+ sech = (ts->tv_sec >> 32);
+
+ spin_lock(&bp->tsu_clk_lock);
+
+ /* TSH doesn't latch the time and no atomicity! */
+ gem_writel(bp, TSH, sech);
+ gem_writel(bp, TSL, secl);
+ gem_writel(bp, TN, ns);
+
+ spin_unlock(&bp->tsu_clk_lock);
+}
+
+static int macb_ptp_adjfreq(struct ptp_clock_info *ptp, s32 ppb)
+{
+ struct macb *bp = container_of(ptp, struct macb, ptp_caps);
+ u32 addend, addend_frac, rem;
+ u64 drift_tmr, diff, diff_frac = 0;
+ int neg_adj = 0;
+
+ if (ppb < 0) {
+ neg_adj = 1;
+ ppb = -ppb;
+ }
+
+ /* drift/period */
+ drift_tmr = (bp->ns_incr * ppb) +
+ ((bp->subns_incr * ppb) >> 16);
+
+ /* drift/cycle */
+ diff = div_u64_rem(drift_tmr, 1000000000ULL, &rem);
+
+ /* drift fraction/cycle, if necessary */
+ if (rem) {
+ u64 fraction = rem;
+ fraction = fraction << 16;
+
+ diff_frac = div_u64(fraction, 1000000000ULL);
+ }
+
+ /* adjustmets */
+ addend = neg_adj ? (bp->ns_incr - diff) : (bp->ns_incr + diff);
+ addend_frac = neg_adj ? (bp->subns_incr - diff_frac) :
+ (bp->subns_incr + diff_frac);
+
+ spin_lock(&bp->tsu_clk_lock);
+
+ gem_writel(bp, TISUBN, GEM_BF(SUBNSINCR, addend_frac));
+ gem_writel(bp, TI, GEM_BF(NSINCR, addend));
+
+ spin_unlock(&bp->tsu_clk_lock);
+ return 0;
+}
+
+static int macb_ptp_adjtime(struct ptp_clock_info *ptp, s64 delta)
+{
+ struct macb *bp = container_of(ptp, struct macb, ptp_caps);
+ struct timespec64 now, then = ns_to_timespec64(delta);
+ u32 adj, sign = 0;
+
+ if (delta < 0) {
+ delta = -delta;
+ sign = 1;
+ }
+
+ if (delta > 0x3FFFFFFF) {
+ macb_tsu_get_time(bp, &now);
+
+ if (sign)
+ now = timespec64_sub(now, then);
+ else
+ now = timespec64_add(now, then);
+
+ macb_tsu_set_time(bp, (const struct timespec64 *)&now);
+ } else {
+ adj = delta;
+ if (sign)
+ adj |= GEM_BIT(ADDSUB);
+
+ gem_writel(bp, TA, adj);
+ }
+
+ return 0;
+}
+
+static int macb_ptp_gettime(struct ptp_clock_info *ptp,
+ struct timespec64 *ts)
+{
+ struct macb *bp = container_of(ptp, struct macb, ptp_caps);
+
+ macb_tsu_get_time(bp, ts);
+
+ return 0;
+}
+
+static int macb_ptp_settime(struct ptp_clock_info *ptp,
+ const struct timespec64 *ts)
+{
+ struct macb *bp = container_of(ptp, struct macb, ptp_caps);
+
+ macb_tsu_set_time(bp, ts);
+
+ return 0;
+}
+
+static int macb_ptp_enable(struct ptp_clock_info *ptp,
+ struct ptp_clock_request *rq, int on)
+{
+ return -EOPNOTSUPP;
+}
+
+static struct ptp_clock_info macb_ptp_caps = {
+ .owner = THIS_MODULE,
+ .name = GMAC_TIMER_NAME,
+ .max_adj = 250000000,
+ .n_alarm = 0,
+ .n_ext_ts = 0,
+ .n_per_out = 0,
+ .n_pins = 0,
+ .pps = 0,
+ .adjfreq = macb_ptp_adjfreq,
+ .adjtime = macb_ptp_adjtime,
+ .gettime64 = macb_ptp_gettime,
+ .settime64 = macb_ptp_settime,
+ .enable = macb_ptp_enable,
+};
+
+void macb_ptp_init(struct net_device *ndev)
+{
+ struct macb *bp = netdev_priv(ndev);
+ struct timespec64 now;
+ u32 rem = 0;
+
+ if (!(bp->caps | MACB_CAPS_GEM_HAS_PTP)){
+ netdev_vdbg(bp->dev, "Platform does not support PTP!\n");
+ return;
+ }
+
+ spin_lock_init(&bp->tsu_clk_lock);
+
+ bp->ptp_caps = macb_ptp_caps;
+ bp->tsu_rate = clk_get_rate(bp->pclk);
+
+ getnstimeofday64(&now);
+ macb_tsu_set_time(bp, (const struct timespec64 *)&now);
+
+ bp->ns_incr = div_u64_rem(NSEC_PER_SEC, bp->tsu_rate, &rem);
+ if (rem) {
+ u64 adj = rem;
+ /* Multiply by 2^16 as subns register is 16 bits */
+ adj <<= 16;
+ bp->subns_incr = div_u64(adj, bp->tsu_rate);
+ } else {
+ bp->subns_incr = 0;
+ }
+
+ gem_writel(bp, TISUBN, GEM_BF(SUBNSINCR, bp->subns_incr));
+ gem_writel(bp, TI, GEM_BF(NSINCR, bp->ns_incr));
+ gem_writel(bp, TA, 0);
+
+ bp->ptp_clock = ptp_clock_register(&bp->ptp_caps, NULL);
+ if (IS_ERR(&bp->ptp_clock)) {
+ bp->ptp_clock = NULL;
+ pr_err("ptp clock register failed\n");
+ return;
+ }
+
+ dev_info(&bp->pdev->dev, "%s ptp clock registered.\n", GMAC_TIMER_NAME);
+}
+
--
1.9.1
^ permalink raw reply related
* Re: Synopsys Ethernet QoS Driver
From: Joao Pinto @ 2016-11-18 14:20 UTC (permalink / raw)
To: mued dib, Joao Pinto
Cc: davem, jeffrey.t.kirsher, jiri, saeedm, idosch, netdev,
linux-kernel, CARLOS.PALMINHA, andreas.irestal
In-Reply-To: <CADvZ6ErjyVR5ShWTk0QesWLYR1m3p8yAMkK8v9gm2kN5xTv8zw@mail.gmail.com>
Hello Ozgur,
Thanks for your feedback.
On 18-11-2016 13:09, mued dib wrote:
> Dear Joao;
>
> thanks for support and this project is good. I have some questions, Linux
> already support to QoS with "tc". right?
>
> Can you send us a list of driver files you are interested?
For now we are interesting in improving the synopsys QoS driver under
/nect/ethernet/synopsys. For now the driver structure consists of a single file
called dwc_eth_qos.c, containing synopsys ethernet qos common ops and platform
related stuff.
Our strategy would be:
a) Implement a platform glue driver (dwc_eth_qos_pltfm.c)
b) Implement a pci glue driver (dwc_eth_qos_pci.c)
c) Implement a "core driver" (dwc_eth_qos.c) that would only have Ethernet QoS
related stuff to be reused by the platform / pci drivers
d) Add a set of features to the "core driver" that we have available internally
Thanks,
Joao
>
> Regards,
>
> Ozgur Karatas
>
> 2016-11-18 15:28 GMT+03:00 Joao Pinto <Joao.Pinto@synopsys.com>:
>
>>
>> Dear all,
>>
>> My name is Joao Pinto and I work at Synopsys.
>> I am a kernel developer with special focus in mainline collaboration, both
>> Linux
>> and Buildroot. I was recently named one of the maintainers of the PCIe
>> Designware core driver and I was the author of the Designware UFS driver
>> stack.
>>
>> I am sending you this e-mail because you were the suggested contacts from
>> the
>> get_maintainers script concerning Ethernet drivers :).
>>
>> Currently I have the task to work on the mainline Ethernet QoS driver in
>> which
>> you are the author. The work would consist of the following:
>>
>> a) Separate the current driver in a Core driver (common ops) + platform
>> glue
>> driver + pci glue driver
>> b) Add features that are currently only available internally
>> c) Add specific phy support using the PHY framework
>>
>> I would also gladly be available to be its maintainer if you agree with it.
>>
>> It would be great to have your collaboration in the project if you are
>> available
>> to review the work in progress.
>>
>> Thank you and I am looking forward for your feedback!
>>
>> Joao Pinto
>>
>
^ permalink raw reply
* Re: [PATCH iproute2 0/2] tc: flower: Support matching on SCTP ports
From: Simon Horman @ 2016-11-18 13:27 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: David Miller, netdev
In-Reply-To: <20161112103209.242d3e5e@samsung9>
On Sat, Nov 12, 2016 at 10:32:09AM +0300, Stephen Hemminger wrote:
> On Thu, 3 Nov 2016 13:26:39 +0100
> Simon Horman <simon.horman@netronome.com> wrote:
>
> > Hi,
> >
> > this short series adds support for matching on SCTP ports in the same way
> > that matching on TCP and UDP ports is already supported. It corresponds to
> > a net-next patch to add the same support to the kernel.
> >
> > Example usage:
> >
> > tc qdisc add dev eth0 ingress
> >
> > tc filter add dev eth0 protocol ip parent ffff: \
> > flower indev eth0 ip_proto sctp dst_port 80 \
> > action drop
> >
> >
> > Simon Horman (2):
> > tc: update headers for TCA_FLOWER_KEY_SCTP_*
> > tc: flower: Support matching on SCTP ports
> >
> > include/linux/pkt_cls.h | 5 ++++
> > tc/f_flower.c | 65 +++++++++++++++++++++++--------------------------
> > 2 files changed, 36 insertions(+), 34 deletions(-)
> >
>
> Applied, thanks.
Hi Stephen,
I'm not seeing these on
git://git.kernel.org/pub/scm/linux/kernel/git/shemminger/iproute2.git
Could you push them or let me know where to look?
I found a few problems that want fixing.
^ permalink raw reply
* Re: [RFC PATCH 2/3] net: macb: Add support for 1588 for Zynq Ultrascale+ MPSoC
From: Rafal Ozieblo @ 2016-11-18 13:03 UTC (permalink / raw)
To: harini.katakam@xilinx.com
Cc: Nicolas Ferre, Andrei Pistirica, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, Richard Cochran
>+static inline void macb_handle_txtstamp(struct macb *bp, struct sk_buff *skb,
>+ struct macb_dma_desc *desc)
>+{
>+ u32 ts_s, ts_ns;
>+ u8 msg_type;
>+
>+ skb_copy_from_linear_data_offset(skb, GEM_TX_PTPHDR_OFFSET,
>+ &msg_type, 1);
>+
>+ /* Bit[32:6] of TS secs from register
>+ * Bit[5:0] of TS secs from BD
>+ * TS nano secs is available in BD
>+ */
>+ if (msg_type & 0x2) {
>+ /* PTP Peer Event Frame packets */
>+ ts_s = (gem_readl(bp, 1588PEERTXSEC) & GEM_SEC_MASK) |
>+ ((desc->tsl >> GEM_TSL_SEC_RS) |
>+ (desc->tsh << GEM_TSH_SEC_LS));
>+ ts_ns = desc->tsl & GEM_TSL_NSEC_MASK;
>+ } else {
>+ /* PTP Event Frame packets */
>+ ts_s = (gem_readl(bp, 1588TXSEC) & GEM_SEC_MASK) |
>+ ((desc->tsl >> GEM_TSL_SEC_RS) |
>+ (desc->tsh << GEM_TSH_SEC_LS));
>+ ts_ns = desc->tsl & GEM_TSL_NSEC_MASK;
>+ }
>+
>+ struct skb_shared_hwtstamps *shhwtstamps = skb_hwtstamps(skb);
>+
>+ memset(shhwtstamps, 0, sizeof(struct skb_shared_hwtstamps));
>+ shhwtstamps->hwtstamp = ns_to_ktime((ts_s * NS_PER_SEC) + ts_ns);
>+ skb_tstamp_tx(skb, skb_hwtstamps(skb));
>+}
>+
> static void macb_tx_interrupt(struct macb_queue *queue)
> {
> unsigned int tail;
>@@ -703,6 +745,10 @@ static void macb_tx_interrupt(struct macb_queue *queue)
> bp->stats.tx_bytes += skb->len;
> }
>
>+#ifdef CONFIG_MACB_EXT_BD
>+ if (skb_shinfo(skb)->tx_flags & SKBTX_HW_TSTAMP)
>+ macb_handle_txtstamp(bp, skb, desc);
>+#endif
> /* Now we can safely release resources */
> macb_tx_unmap(bp, tx_skb);
>
>@@ -796,6 +842,39 @@ static void discard_partial_frame(struct macb *bp,
>unsigned int begin,
> */
> }
I think, you can not do it in that way.
It will hold two locks. If you enable appropriate option in kernel (as far as I remember CONFIG_DEBUG_SPINLOCK) you will get a warning here.
Please look at following call-stack:
1. macb_interrupt() // spin_lock(&bp->lock) is taken
2. macb_tx_interrupt()
3. macb_handle_txtstamp()
4. skb_tstamp_tx()
5. __skb_tstamp_tx()
6. skb_may_tx_timestamp()
7. read_lock_bh() // second lock is taken
I know that those are different locks and different types. But this could lead to deadlocks. This is the reason of warning I could see.
And this is the reason why I get timestamp in interrupt routine but pass it to skb outside interrupt (using circular buffer).
Best regards,
Rafal Ozieblo | Firmware System Engineer,
phone nbr.: +48 32 5085469
www.cadence.com
^ permalink raw reply
* Re: [PATCH v8 5/6] net: ipv4, ipv6: run cgroup eBPF egress programs
From: Pablo Neira Ayuso @ 2016-11-18 12:37 UTC (permalink / raw)
To: Daniel Mack
Cc: htejun-b10kYP2dOMg, daniel-FeC+5ew28dpmcu3hnIyYJQ,
ast-b10kYP2dOMg, davem-fT/PcQaiUtIeIZ0/mPfg9Q, kafai-b10kYP2dOMg,
fw-HFFVJYpyMKqzQB+pC5nmwQ, harald-H+wXaHxf7aLQT0dZR+AlfA,
netdev-u79uwXL29TY76Z2rM5mHXA, sargun-GaZTRHToo+CzQB+pC5nmwQ,
cgroups-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1479407229-14861-6-git-send-email-daniel-cYrQPVfZoowdnm+yROfE0A@public.gmane.org>
On Thu, Nov 17, 2016 at 07:27:08PM +0100, Daniel Mack wrote:
[...]
> @@ -312,6 +314,12 @@ int ip_mc_output(struct net *net, struct sock *sk, struct sk_buff *skb)
> skb->dev = dev;
> skb->protocol = htons(ETH_P_IP);
>
> + ret = BPF_CGROUP_RUN_PROG_INET_EGRESS(sk, skb);
> + if (ret) {
> + kfree_skb(skb);
> + return ret;
> + }
> +
> /*
> * Multicasts are looped back for other local users
> */
> @@ -364,12 +372,19 @@ int ip_mc_output(struct net *net, struct sock *sk, struct sk_buff *skb)
> int ip_output(struct net *net, struct sock *sk, struct sk_buff *skb)
> {
> struct net_device *dev = skb_dst(skb)->dev;
> + int ret;
>
> IP_UPD_PO_STATS(net, IPSTATS_MIB_OUT, skb->len);
>
> skb->dev = dev;
> skb->protocol = htons(ETH_P_IP);
>
> + ret = BPF_CGROUP_RUN_PROG_INET_EGRESS(sk, skb);
> + if (ret) {
> + kfree_skb(skb);
> + return ret;
> + }
> +
> return NF_HOOK_COND(NFPROTO_IPV4, NF_INET_POST_ROUTING,
> net, sk, skb, NULL, dev,
> ip_finish_output,
Please, place this after the netfilter hook.
Since this new hook may mangle output packets, any mangling
potentially interfers and breaks conntrack.
Thank you.
^ permalink raw reply
* Synopsys Ethernet QoS Driver
From: Joao Pinto @ 2016-11-18 12:31 UTC (permalink / raw)
To: davem, jeffrey.t.kirsher, jiri, saeedm, idosch
Cc: netdev, linux-kernel, CARLOS.PALMINHA, andreas.irestal
In-Reply-To: <cbe5f79b-53a4-e116-1e09-bc975a66a8ca@synopsys.com>
[The previous e-mail had an error, please consider this one. Thank you.]
Dear all,
My name is Joao Pinto and I work at Synopsys.
I am a kernel developer with special focus in mainline collaboration, both Linux
and Buildroot. I was recently named one of the maintainers of the PCIe
Designware core driver and I was the author of the Designware UFS driver stack.
I am sending you this e-mail because you were the suggested contacts from the
get_maintainers script concerning Ethernet drivers :).
Currently I have the task to work on the mainline Ethernet QoS driver. The work
would consist of the following:
a) Separate the current driver in a Core driver (common ops) + platform glue
driver + pci glue driver
b) Add features that are currently only available internally
c) Add specific phy support using the PHY framework
I would also gladly be available to be its maintainer if you agree with it.
It would be great to have your collaboration in the project if you are available
to review the work in progress.
Thank you and I am looking forward for your feedback!
Joao Pinto
^ permalink raw reply
* Synopsys Ethernet QoS Driver
From: Joao Pinto @ 2016-11-18 12:28 UTC (permalink / raw)
To: davem, jeffrey.t.kirsher, jiri, saeedm, idosch
Cc: netdev, linux-kernel, CARLOS.PALMINHA, andreas.irestal
Dear all,
My name is Joao Pinto and I work at Synopsys.
I am a kernel developer with special focus in mainline collaboration, both Linux
and Buildroot. I was recently named one of the maintainers of the PCIe
Designware core driver and I was the author of the Designware UFS driver stack.
I am sending you this e-mail because you were the suggested contacts from the
get_maintainers script concerning Ethernet drivers :).
Currently I have the task to work on the mainline Ethernet QoS driver in which
you are the author. The work would consist of the following:
a) Separate the current driver in a Core driver (common ops) + platform glue
driver + pci glue driver
b) Add features that are currently only available internally
c) Add specific phy support using the PHY framework
I would also gladly be available to be its maintainer if you agree with it.
It would be great to have your collaboration in the project if you are available
to review the work in progress.
Thank you and I am looking forward for your feedback!
Joao Pinto
^ permalink raw reply
* Re: [PATCH net-next] cadence: Add hardware PTP support.
From: Richard Cochran @ 2016-11-18 12:27 UTC (permalink / raw)
To: Rafal Ozieblo
Cc: Harini Katakam, Nicolas Ferre, Andrei Pistirica,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <BN3PR07MB2516D135ECCF2A68C1687EB6C9B00@BN3PR07MB2516.namprd07.prod.outlook.com>
On Fri, Nov 18, 2016 at 11:55:37AM +0000, Rafal Ozieblo wrote:
> >I'm not sure of your application and why this is necessary.
> >Can you please check Andrei's patches and mine and Richard Cochran's comments?
> >I use linuxptp to test.
And please, PLEASE, put me onto CC for all PTP related patches. I am
the maintainer, you know.
Thanks,
Richard
^ permalink raw reply
* [RFC PATCH 1/2] macb: Add 1588 support in Cadence GEM.
From: Rafal Ozieblo @ 2016-11-18 12:05 UTC (permalink / raw)
To: andrei.pistirica@microchip.com
Cc: Nicolas Ferre, harini.katakam@xilinx.com, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
Hello Andrei,
>+static struct ptp_clock_info macb_ptp_caps = {
>+ .owner = THIS_MODULE,
>+ .name = GMAC_TIMER_NAME,
>+ .max_adj = 250000000,
>+ .n_alarm = 0,
>+ .n_ext_ts = 0,
>+ .n_per_out = 0,
>+ .n_pins = 0,
>+ .pps = 0,
>+ .adjfreq = macb_ptp_adjfreq,
>+ .adjtime = macb_ptp_adjtime,
>+ .gettime64 = macb_ptp_gettime,
>+ .settime64 = macb_ptp_settime,
>+ .enable = macb_ptp_enable,
>+};
I'm wondering, how did you count max_adj ?
Best regards,
Rafal Ozieblo | Firmware System Engineer,
phone nbr.: +48 32 5085469
www.cadence.com
^ permalink raw reply
* Re: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable
From: Mark Lord @ 2016-11-18 12:03 UTC (permalink / raw)
To: Hayes Wang, netdev@vger.kernel.org
Cc: nic_swsd, linux-kernel@vger.kernel.org, linux-usb@vger.kernel.org
In-Reply-To: <0835B3720019904CB8F7AA43166CEEB201050B7E@RTITMBSV03.realtek.com.tw>
On 16-11-18 02:57 AM, Hayes Wang wrote:
..
> Besides, the maximum data length which the RTL8152 would send to
> the host is 16KB. That is, if the agg_buf_sz is 16KB, the host
> wouldn't split it. However, you still see problems for it.
How does the RTL8152 know that the limit is 16KB,
rather than some other number? Is this a hardwired number
in the hardware, or is it a parameter that the software
sends to the chip during initialization?
I have a USB analyzer, but it is difficult to figure out how
to program an appropriate trigger point for the capture,
since the problem (with 16KB URBs) takes minutes to hours
or even days to trigger.
And the output from the analyzer is in some proprietary format.
The in-kernel software analzer could be useful, but I have never
figured out how to use it. :)
Since my earlier email, I have figured out another piece of the
puzzle with this dongle.
The first issue is that a packet sometimes begins in one URB,
and completes in the next URB, without an rx_desc at the start
of the second URB. This I have already reported earlier.
But the driver, as written, sometimes accesses bytes outside
of the 16KB URB buffer, because it trusts the non-existent
rx_desc in these cases, and also because it accesses bytes
from the rx_desc without first checking whether there is
sufficient remaining space in the URB to hold an rx_desc.
These incorrect accesses sometimes touch memory outside
of the URB buffer. Since the driver allocates all of its
rx URB buffers at once, they are highly likely to be
physically (and therefore virtually) adjacent in memory.
So mistakenly accessing beyond the end of one buffer will
often result in a read from memory of the next URB buffer.
Which causes a portion of it to be loaded in the the D-cache.
When that URB is subsequently filled by DMA, there then exists
a data-consistency issue: the D-cache contains stale information
from before the latest DMA cycle.
So this explains the strange memory behaviour observed earlier on.
When I add a call to invalidate_dcache_range() to the driver
just before it begins examining a new rx URB, the problems go away.
So this confirms the observations.
Using non-cacheable RAM also makes the problem go away.
But neither is a fix for the real buffer overrun accesses in the driver.
Fix the "packet spans URBs" bug, and fix the driver to ALWAYS
test lengths/ranges before accessing the actual buffer,
and everything should begin working reliably.
Cheers
--
Mark Lord
Real-Time Remedies Inc.
mlord@pobox.com
^ permalink raw reply
* RE: [PATCH net-next] cadence: Add hardware PTP support.
From: Rafal Ozieblo @ 2016-11-18 11:55 UTC (permalink / raw)
To: Harini Katakam
Cc: Nicolas Ferre, Andrei Pistirica, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <CAFcVECLoMyJJLwAQ_+xN9GNLeVbew7RU_vURZjK94VXH2zS7EA@mail.gmail.com>
>Hi Rafal
>
>I'm still comparing the full solution but just a couple of things first:
><snip>
>> @@ -876,6 +964,17 @@ static int gem_rx(struct macb *bp, int budget)
>> bp->stats.rx_packets++;
>> bp->stats.rx_bytes += skb->len;
>>
>> +#if IS_ENABLED(CONFIG_PTP_1588_CLOCK)
>> + if (bp->ptp_hw_support) {
>> + struct timespec64 ts;
>> +
>> + if (MACB_BFEXT(DMA_RX_TS_VALID, desc->addr)) {
>> + macb_hw_timestamp(bp, desc->dma_desc_ts_1, desc->dma_desc_ts_2, &ts);
>> + skb_hwtstamps(skb)->hwtstamp = ktime_set(ts.tv_sec, ts.tv_nsec);
>> + }
>> + }
>> +#endif
>> +
>
>I've had to read PTP event registers for upper part of seconds timestamp in addition to the descriptor (since descriptor only has 5 bits of seconds TS).
>I don't know which version of the IP you use - it could be different.
>Please let me know so that I can check the spec.
>Same with tx timestamp of course.
I use GEM_GXL 1p9 and 1p10 but I should be comatible with old version as well.
From documentation:
Receive Buffer Descriptor Entry
Word 0:
Bit 2:
Address [2] of beginning of buffer.
Or
In Extended Buffer Descriptor Mode (DMA configuration register[28] = 1), indicates a valid timestamp in the BD entry
Transmit Buffer Descriptor Entry
Word 1:
Bit 23:
For Extended Buffer Descriptor Mode this bit Indicates a timestamp has been captured in the BD. Otherwise Reserved.
>
><snip>
>> @@ -1195,6 +1297,87 @@ static irqreturn_t macb_interrupt(int irq, void *dev_id)
>> queue_writel(queue, ISR, MACB_BIT(HRESP));
>> }
>>
>> +#if IS_ENABLED(CONFIG_PTP_1588_CLOCK)
>> + if (status & MACB_BIT(PTP_DELAY_REQ_FRAME_RECEIVED)) {
>> + if (bp->caps & MACB_CAPS_ISR_CLEAR_ON_WRITE)
>> + queue_writel(queue, ISR, MACB_BIT(PTP_DELAY_REQ_FRAME_RECEIVED));
>> + if (macb_ptp_time_frame_rx_get(bp, &ts) != 0) {
>> + ts.tv_sec = 0;
>> + ts.tv_nsec = 0;
>> + }
>> + macb_ptp_event(bp, &ts);
>> + }
>> +
>> + if (status & MACB_BIT(PTP_SYNC_FRAME_RECEIVED)) {
>> + if (bp->caps & MACB_CAPS_ISR_CLEAR_ON_WRITE)
>> + queue_writel(queue, ISR, MACB_BIT(PTP_SYNC_FRAME_RECEIVED));
>> + if (macb_ptp_time_frame_rx_get(bp, &ts) != 0) {
>> + ts.tv_sec = 0;
>> + ts.tv_nsec = 0;
>> + }
>> + macb_ptp_event(bp, &ts);
>> + }
>> +
>> + if (status & MACB_BIT(PTP_DELAY_REQ_FRAME_TRANSMITTED)) {
>> + if (bp->caps & MACB_CAPS_ISR_CLEAR_ON_WRITE)
>> + queue_writel(queue, ISR, MACB_BIT(PTP_DELAY_REQ_FRAME_TRANSMITTED));
>> + if (macb_ptp_time_frame_tx_get(bp, &ts) != 0) {
>> + ts.tv_sec = 0;
>> + ts.tv_nsec = 0;
>> + }
>> + macb_ptp_event(bp, &ts);
>> + }
>> +
>> + if (status & MACB_BIT(PTP_SYNC_FRAME_TRANSMITTED)) {
>> + if (bp->caps & MACB_CAPS_ISR_CLEAR_ON_WRITE)
>> + queue_writel(queue, ISR, MACB_BIT(PTP_SYNC_FRAME_TRANSMITTED));
>> + if (macb_ptp_time_frame_tx_get(bp, &ts) != 0) {
>> + ts.tv_sec = 0;
>> + ts.tv_nsec = 0;
>> + }
>> + macb_ptp_event(bp, &ts);
>> + }
>> +
>> + if (status & MACB_BIT(PTP_PDELAY_REQ_FRAME_RECEIVED)) {
>> + if (bp->caps & MACB_CAPS_ISR_CLEAR_ON_WRITE)
>> + queue_writel(queue, ISR, MACB_BIT(PTP_PDELAY_REQ_FRAME_RECEIVED));
>> + if (macb_ptp_time_peer_frame_rx_get(bp, &ts) != 0) {
>> + ts.tv_sec = 0;
>> + ts.tv_nsec = 0;
>> + }
>> + macb_ptp_event(bp, &ts);
>> + }
>> +
>> + if (status & MACB_BIT(PTP_PDELAY_RESP_FRAME_RECEIVED)) {
>> + if (bp->caps & MACB_CAPS_ISR_CLEAR_ON_WRITE)
>> + queue_writel(queue, ISR, MACB_BIT(PTP_PDELAY_RESP_FRAME_RECEIVED));
>> + if (macb_ptp_time_peer_frame_rx_get(bp, &ts) != 0) {
>> + ts.tv_sec = 0;
>> + ts.tv_nsec = 0;
>> + }
>> + macb_ptp_event(bp, &ts);
>> + }
>> +
>> + if (status & MACB_BIT(PTP_PDELAY_REQ_FRAME_TRANSMITTED)) {
>> + if (bp->caps & MACB_CAPS_ISR_CLEAR_ON_WRITE)
>> + queue_writel(queue, ISR, MACB_BIT(PTP_PDELAY_REQ_FRAME_TRANSMITTED));
>> + if (macb_ptp_time_peer_frame_tx_get(bp, &ts) != 0) {
>> + ts.tv_sec = 0;
>> + ts.tv_nsec = 0;
>> + }
>> + macb_ptp_event(bp, &ts);
>> + }
>> +
>> + if (status & MACB_BIT(PTP_PDELAY_RESP_FRAME_TRANSMITTED)) {
>> + if (bp->caps & MACB_CAPS_ISR_CLEAR_ON_WRITE)
>> + queue_writel(queue, ISR, MACB_BIT(PTP_PDELAY_RESP_FRAME_TRANSMITTED));
>> + if (macb_ptp_time_peer_frame_tx_get(bp, &ts) != 0) {
>> + ts.tv_sec = 0;
>> + ts.tv_nsec = 0;
>> + }
>> + macb_ptp_event(bp, &ts);
>> + }
>> +#endif
>
>I'm not sure of your application and why this is necessary.
>Can you please check Andrei's patches and mine and Richard Cochran's comments?
>I use linuxptp to test.
>
This could be an overhead. I use linuxptp as well and it works.
>Regards,
>Harini
>
Best regards,
Rafal Ozieblo | Firmware System Engineer,
phone nbr.: +48 32 5085469
www.cadence.com
^ permalink raw reply
* [patch net-next] liquidio CN23XX: bitwise vs logical AND typo
From: Dan Carpenter @ 2016-11-18 11:47 UTC (permalink / raw)
To: Derek Chickles, Raghu Vatsavayi
Cc: Satanand Burla, Felix Manlunas, netdev, kernel-janitors
We obviously intended a bitwise AND here, not a logical one.
Fixes: 8c978d059224 ("liquidio CN23XX: Mailbox support")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
diff --git a/drivers/net/ethernet/cavium/liquidio/octeon_mailbox.c b/drivers/net/ethernet/cavium/liquidio/octeon_mailbox.c
index 5309384..73696b42 100644
--- a/drivers/net/ethernet/cavium/liquidio/octeon_mailbox.c
+++ b/drivers/net/ethernet/cavium/liquidio/octeon_mailbox.c
@@ -301,7 +301,7 @@ int octeon_mbox_process_message(struct octeon_mbox *mbox)
sizeof(struct octeon_mbox_cmd));
if (!mbox_cmd.msg.s.resp_needed) {
mbox->state &= ~OCTEON_MBOX_STATE_REQUEST_RECEIVED;
- if (!(mbox->state &&
+ if (!(mbox->state &
OCTEON_MBOX_STATE_RESPONSE_PENDING))
mbox->state = OCTEON_MBOX_STATE_IDLE;
writeq(OCTEON_PFVFSIG, mbox->mbox_read_reg);
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox