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
| ||
|
Date: Mon, 8 Dec 2014 09:48:07 +0800 From: Ding Tianhong <dingtianhong@...wei.com> To: Arnd Bergmann <arnd@...db.de>, Alexander Graf <agraf@...e.de> CC: Zhangfei Gao <zhangfei.gao@...aro.org>, <davem@...emloft.net>, <linux@....linux.org.uk>, <f.fainelli@...il.com>, <sergei.shtylyov@...entembedded.com>, <mark.rutland@....com>, <David.Laight@...lab.com>, <eric.dumazet@...il.com>, <xuwei5@...ilicon.com>, <linux-arm-kernel@...ts.infradead.org>, <netdev@...r.kernel.org>, <devicetree@...r.kernel.org> Subject: Re: [PATCH v8 3/3] net: hisilicon: new hip04 ethernet driver On 2014/12/8 4:09, Arnd Bergmann wrote: > 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@...aro.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 Ok, if so, I can modify this patch set and send them again base on zhangfei's last version just for reviewing. Regards Ding > -- > 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 > > . > -- 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
Powered by blists - more mailing lists