On Mon, Oct 02, 2023 at 04:49:59PM +0200, Uwe Kleine-König wrote:
> Hello Greg,
>
> On Mon, Oct 02, 2023 at 04:39:47PM +0200, Greg Kroah-Hartman wrote:
> > On Thu, Sep 14, 2023 at 10:02:51PM +0200, Uwe Kleine-König wrote:
> > > @@ -469,8 +469,17 @@ static int mtu3_remove(struct platform_device *pdev)
> > > ssusb_gadget_exit(ssusb);
> > > ssusb_host_exit(ssusb);
> > > break;
> > > - default:
> > > - return -EINVAL;
> > > + case USB_DR_MODE_UNKNOWN:
> > > + /*
> > > + * This cannot happen because with dr_mode ==
> > > + * USB_DR_MODE_UNKNOWN, .probe() doesn't succeed and so
> > > + * .remove() wouldn't be called at all. However (little
> > > + * surprising) the compiler isn't smart enough to see that, so
> > > + * we explicitly have this case item to not make the compiler
> > > + * wail about an unhandled enumeration value.
> > > + */
> > > + WARN_ON(1);
> >
> > Please don't add new WARN_ON() calls to the kernel, print out a big
> > error message and return, don't reboot the machine.
>
> Huh, printing out an loud error message was my intention. It's news to
> me that WARN_ON() reboots the machine?! I thought BUG_ON() was the one
> with the effects you describe that I shouldn't use.
panic-on-warn is set for zillions[1] of Linux systems out there, so systems
will reboot.
thanks,
greg k-h
[1] Unofficial number, I know the "cloud" systems set this, as well as
all of Samsung's phone kernels, a non-trivial amount of Linux
instances in the wild.
