[PATCH v8 3/3] net: hisilicon: new hip04 ethernet driver

[arnd@arndb.de (Arnd Bergmann)]

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 <zhangfei.gao@linaro.org>
> >>
> >> 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.

	Arnd