netdev - Re: [PATCH v5] net: ethernet: add driver for Aurora VLSI NB8800 Ethernet controller

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <yw1xfv0bmhz3.fsf@unicorn.mansr.com>
Date:	Thu, 12 Nov 2015 14:04:48 +0000
From:	Måns Rullgård <mans@...sr.com>
To:	Mason <slash.tmp@...e.fr>
Cc:	linux-kernel@...r.kernel.org, netdev@...r.kernel.org
Subject: Re: [PATCH v5] net: ethernet: add driver for Aurora VLSI NB8800 Ethernet controller

Mason <slash.tmp@...e.fr> writes:

> On 10/11/2015 20:25, Måns Rullgård wrote:
>
>> Mason writes:
>> 
>>> On 10/11/2015 17:14, Mans Rullgard wrote:
>>>
>>>> This adds a driver for the Aurora VLSI NB8800 Ethernet controller.
>>>> It is an almost complete rewrite of a driver originally found in
>>>> a Sigma Designs 2.6.22 tree.
>>>>
>>>> Signed-off-by: Mans Rullgard <mans@...sr.com>
>>>> ---
>>>> Changes:
>>>> - Refactored mdio access functions
>>>> - Refactored register access helpers
>>>> - Improved error handling in rx buffer allocation
>>>> - Optimised some fifo parameters
>>>> - Overhauled tx dma. Multiple packets are now chained in a single dma
>>>>   operation if xmit_more is set, improving performance.
>>>> - Improved rx irq handling. It's not possible to disable interrupts
>>>>   entirely for napi poll, but they can be slowed down a little.
>>>> - Use readx_poll_timeout in various places
>>>> - Improved error detection
>>>> - Improved statistics
>>>> - Report hardware statistics counters through ethtool
>>>> - Improved tangox-specific setup
>>>> - Support for flow control using pause frames
>>>> - Explanatory comments added
>>>> - Various minor stylistic changes
>>>> ---
>>>>  drivers/net/ethernet/Kconfig         |    1 +
>>>>  drivers/net/ethernet/Makefile        |    1 +
>>>>  drivers/net/ethernet/aurora/Kconfig  |   20 +
>>>>  drivers/net/ethernet/aurora/Makefile |    1 +
>>>>  drivers/net/ethernet/aurora/nb8800.c | 1530 ++++++++++++++++++++++++++++++++++
>>>>  drivers/net/ethernet/aurora/nb8800.h |  314 +++++++
>>>>  6 files changed, 1867 insertions(+)
>>>
>>> The code has grown much since the previous patch, despite some
>>> refactoring. Is this mostly due to ethtool_ops support?
>>>
>>>  drivers/net/ethernet/aurora/nb8800.c | 1146 ++++++++++++++++++++++++++++++++++
>>>  drivers/net/ethernet/aurora/nb8800.h |  230 +++++++
>> 
>> Some of the increase is from new features, some from improvements, and
>> then there are a bunch of new comments.
>
> Sweet.
>
> With this version, my kernel boots faster than before
> (I had been using a 5 month-old version.)
>
> Before:
>
> [    0.613623] tangox-enet 26000.ethernet: SMP86xx internal Ethernet at 0x26000
> [    0.623638] libphy: tangox-mii: probed
> [    0.686527] tangox-enet 26000.ethernet: PHY: found Atheros 8035 ethernet at 0x4
> [    0.697169] tangox-enet 26000.ethernet eth0: MAC address 00:16:e8:02:08:42
> ...
> [    1.306360] Sending DHCP requests ..
> [    4.699969] tangox-enet 26000.ethernet eth0: Link is Up - 1Gbps/Full - flow control rx/tx
> [    8.899671] ., OK
> [    8.926343] IP-Config: Got DHCP answer from 172.27.200.1, my address is 172.27.64.49
> ...
> [    8.987327] Freeing unused kernel memory: 168K (c039e000 - c03c8000)
>
> After:
>
> [    0.623526] libphy: nb8800-mii: probed
> [    0.628092] nb8800 26000.ethernet eth0: MAC address 00:16:e8:02:08:42
> ...
> [    4.732948] nb8800 26000.ethernet eth0: Link is Up - 1Gbps/Full - flow control rx/tx
> [    4.752655] Sending DHCP requests ., OK
> [    4.782644] IP-Config: Got DHCP answer from 172.27.200.1, my address is 172.27.64.49
> ...
> [    4.849298] Freeing unused kernel memory: 164K (c039f000 - c03c8000)
>
> The DHCP request is sent later, but the kernel doesn't twiddle its thumbs
> for 4 seconds after the link comes up. Does this come from not probing the
> PHY anymore?

No, that's from properly setting the link state initially down.

> BTW, you're not using the PHY IRQ, right? I think I remember you saying
> it didn't work reliably?

It doesn't seem to be wired up on any of my boards, or there's some
magic required to activate it that I'm unaware of.

-- 
Måns Rullgård
mans@...sr.com
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html