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  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Sun, 07 Dec 2014 21:09:22 +0100
From:	Arnd Bergmann <>
To:	Alexander Graf <>
Cc:	Ding Tianhong <>,
	Zhangfei Gao <>,,,,,,,,,,,
Subject: Re: [PATCH v8 3/3] net: hisilicon: new hip04 ethernet driver

On Sunday 07 December 2014 10:49:12 Alexander Graf wrote:
> On 07.12.14 04:28, Ding Tianhong wrote:
> > On 2014/12/7 8:42, Alexander Graf wrote:
> >> On 19.04.14 03:13, Zhangfei Gao wrote:
> >>> Support Hisilicon hip04 ethernet driver, including 100M / 1000M controller.
> >>> The controller has no tx done interrupt, reclaim xmitted buffer in the poll.
> >>>
> >>> Signed-off-by: Zhangfei Gao <>
> >>
> >> Is this driver still supposed to go upstream? I presume this was the
> >> last submission and it's been quite some time ago 
> >>
> > 
> > yes, it is really a long time, but The hip04 did not support tx irq, 
> > we couldn't get any better idea to fix this defect, do you have any suggestion?
> Well, if hardware doesn't have a TX irq I don't see there's anything we
> can do to fix that ;).

I don't know if it's related to the ethernet on hip01, but I would assume
it is, and that platform is currently being submitted for inclusion, so
I'd definitely hope to see this driver get merged too eventually.

IIRC, the last revision of the patch set had basically fixed the problem,
except for a race that would still allow the napi poll function to exit
with poll_complete() but a full queue of TX descriptors and no fallback
to clean them up. There was also still an open question about whether or
not the driver should use skb_orphan, but I may be misremembering that part.
> Dave, what's your take here? Should we keep a driver from going upstream
> just because the hardware is partly broken? I'd really prefer to have an
> upstream driver on that SoC rather than some random (eventually even
> more broken) downstream code.

We can certainly have a slow driver for this hardware, and I'd much
prefer slow over broken. I'd guess that some of the performance impact
of the missing interrupts can now be offset with the xmit_more	 logic.

To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to
More majordomo info at

Powered by blists - more mailing lists