[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5A57083856F7D3CC+20250901021822.GB21078@nic-Precision-5820-Tower>
Date: Mon, 1 Sep 2025 10:18:22 +0800
From: Yibo Dong <dong100@...se.com>
To: Andrew Lunn <andrew@...n.ch>
Cc: andrew+netdev@...n.ch, davem@...emloft.net, edumazet@...gle.com,
kuba@...nel.org, pabeni@...hat.com, horms@...nel.org,
corbet@....net, gur.stavi@...wei.com, maddy@...ux.ibm.com,
mpe@...erman.id.au, danishanwar@...com, lee@...ger.us,
gongfan1@...wei.com, lorenzo@...nel.org, geert+renesas@...der.be,
Parthiban.Veerasooran@...rochip.com, lukas.bulwahn@...hat.com,
alexanderduyck@...com, richardcochran@...il.com, kees@...nel.org,
gustavoars@...nel.org, rdunlap@...radead.org,
vadim.fedorenko@...ux.dev, netdev@...r.kernel.org,
linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-hardening@...r.kernel.org
Subject: Re: [PATCH net-next v9 5/5] net: rnpgbe: Add register_netdev
On Fri, Aug 29, 2025 at 09:51:57PM +0200, Andrew Lunn wrote:
> > > Back to the ^C handling. This could be interrupted before the firmware
> > > is told the driver is loaded. That EINTR is thrown away here, so the
> > > driver thinks everything is O.K, but the firmware still thinks there
> > > is no MAC driver. What happens then?
> > >
> >
> > The performance will be very poor since low working frequency,
> > that is not we want.
> >
> > > And this is the same problem i pointed out before, you ignore EINTR in
> > > a void function. Rather than fix one instance, you should of reviewed
> > > the whole driver and fixed them all. You cannot expect the Reviewers
> > > to do this for you.
> >
> > I see, I will change 'void' to 'int' in order to handle err, and try to check
> > other functions.
>
> Also, consider, do you really want ^C handling? How many other drivers
> do this? How much time and effort is it going to take you to fix up
> all the calls which might return -EINTR and your code is currently
> broken?
>
> Andrew
>
Originally ^C is designed to handle '/sys/xxx’, and as you said before,
'It is pretty unusual for ethernet drivers to export data in /sys'.
I should use 'metex_lock', not 'mutex_lock_interruptible'.
Thanks for your feedback.
Powered by blists - more mailing lists