On Thu, Nov 16, 2023 at 10:42 AM Paolo Abeni <pabeni@xxxxxxxxxx> wrote: > We need a suitable Fixes tag even here ;) Ok, I will add it in my next version. > > --- > > drivers/net/usb/ax88179_178a.c | 13 ------------- > > 1 file changed, 13 deletions(-) > > > > diff --git a/drivers/net/usb/ax88179_178a.c b/drivers/net/usb/ax88179_178a.c > > index 4ea0e155bb0d..864c6fc2db33 100644 > > --- a/drivers/net/usb/ax88179_178a.c > > +++ b/drivers/net/usb/ax88179_178a.c > > @@ -1678,7 +1678,6 @@ static const struct driver_info ax88179_info = { > > .unbind = ax88179_unbind, > > .status = ax88179_status, > > .link_reset = ax88179_link_reset, > > - .reset = ax88179_reset, > > .stop = ax88179_stop, > > .flags = FLAG_ETHER | FLAG_FRAMING_AX, > > .rx_fixup = ax88179_rx_fixup, > > This looks potentially dangerous, as the device will not get a reset in > down/up cycles; *possibly* dropping the reset call from ax88179_bind() > would be safer. Ok, I had the doubt about which reset would be the best, because it seemed to me that reset would be better as soon as possible. I will try what you say to avoid down/up cycles. > In both cases touching so many H/W variant with testing available on a > single one sounds dangerous. Is the unneeded 2nd reset causing any > specific issue? Actually, this double reboot somewhat masked the first problem, because the probability of getting a successful initialization, if there is a previous problem seems to be higher. So, it is not strictly needed but I think it is better to avoid a second unnecessary reset. Ok, if I modify the call from ax88179_bind() I will be respecting the reset operation of all devices. Thanks Best regards José Ignacio