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.
