On Fri, Aug 29, 2025 at 09:51:57PM +0200, Andrew Lunn wrote:

quoted

quoted

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.

quoted

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.