[PATCH v2] usb: mtu3: Convert to platform remove callback returning void

[PATCH v2] usb: mtu3: Convert to platform remove callback returning void

[Uwe Kleine-König]

The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is (mostly) ignored
and this typically results in resource leaks. To improve here there is a
quest to make the remove callback return void. In the first step of this
quest all drivers are converted to .remove_new() which already returns
void.

The function mtu3_remove() can only return a non-zero value if
ssusb->dr_mode is neiter USB_DR_MODE_PERIPHERAL nor USB_DR_MODE_HOST nor
USB_DR_MODE_OTG. In this case however the probe callback doesn't succeed
and so the remove callback isn't called at all. So the code branch
resulting in this error path could just be dropped were it not for the
compiler choking on "enumeration value 'USB_DR_MODE_UNKNOWN' not handled
in switch [-Werror=switch]". So instead replace this code path by a
WARN_ON and then mtu3_remove() be converted to return void trivially.

Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
---
Changes since (implicit) v1 sent with Message-Id:
20230709163335.3458886-1-u.kleine-koenig@pengutronix.de:

 - Keep case USB_DR_MODE_UNKNOWN to cope for the compiler being called
   with -Werror=switch.
 - Rebase to a newer tree

Just to evaluate the options, I tried with a BUG_ON(ssusb->dr_mode ==
USB_DR_MODE_UNKNOWN) before the switch, but even then gcc insists on the
case label for this value.

Best regards
Uwe

 drivers/usb/mtu3/mtu3_plat.c | 19 +++++++++++++------
 1 file changed, 13 insertions(+), 6 deletions(-)

diff --git a/drivers/usb/mtu3/mtu3_plat.c b/drivers/usb/mtu3/mtu3_plat.c
index 6f264b129243..18c6cf9a2d71 100644
--- a/drivers/usb/mtu3/mtu3_plat.c
+++ b/drivers/usb/mtu3/mtu3_plat.c
@@ -451,7 +451,7 @@ static int mtu3_probe(struct platform_device *pdev)
 	return ret;
 }
 
-static int mtu3_remove(struct platform_device *pdev)
+static void mtu3_remove(struct platform_device *pdev)
 {
 	struct ssusb_mtk *ssusb = platform_get_drvdata(pdev);
 
@@ -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);
+		break;
 	}
 
 	ssusb_rscs_exit(ssusb);
@@ -478,8 +487,6 @@ static int mtu3_remove(struct platform_device *pdev)
 	pm_runtime_disable(&pdev->dev);
 	pm_runtime_put_noidle(&pdev->dev);
 	pm_runtime_set_suspended(&pdev->dev);
-
-	return 0;
 }
 
 static int resume_ip_and_ports(struct ssusb_mtk *ssusb, pm_message_t msg)
@@ -615,7 +622,7 @@ MODULE_DEVICE_TABLE(of, mtu3_of_match);
 
 static struct platform_driver mtu3_driver = {
 	.probe = mtu3_probe,
-	.remove = mtu3_remove,
+	.remove_new = mtu3_remove,
 	.driver = {
 		.name = MTU3_DRIVER_NAME,
 		.pm = DEV_PM_OPS,

base-commit: 98897dc735cf6635f0966f76eb0108354168fb15
-- 
2.40.1

Re: [PATCH v2] usb: mtu3: Convert to platform remove callback returning void

[Chunfeng Yun (云春峰)]

On Thu, 2023-09-14 at 22:02 +0200, Uwe Kleine-König wrote:
>  	 
> External email : Please do not click links or open attachments until
> you have verified the sender or the content.
>  The .remove() callback for a platform driver returns an int which
> makes
> many driver authors wrongly assume it's possible to do error handling
> by
> returning an error code. However the value returned is (mostly)
> ignored
> and this typically results in resource leaks. To improve here there
> is a
> quest to make the remove callback return void. In the first step of
> this
> quest all drivers are converted to .remove_new() which already
> returns
> void.
> 
> The function mtu3_remove() can only return a non-zero value if
> ssusb->dr_mode is neiter USB_DR_MODE_PERIPHERAL nor USB_DR_MODE_HOST
> nor
> USB_DR_MODE_OTG. In this case however the probe callback doesn't
> succeed
> and so the remove callback isn't called at all. So the code branch
> resulting in this error path could just be dropped were it not for
> the
> compiler choking on "enumeration value 'USB_DR_MODE_UNKNOWN' not
> handled
> in switch [-Werror=switch]". So instead replace this code path by a
> WARN_ON and then mtu3_remove() be converted to return void trivially.
> 
> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
> ---
> Changes since (implicit) v1 sent with Message-Id:
> 20230709163335.3458886-1-u.kleine-koenig@pengutronix.de:
> 
>  - Keep case USB_DR_MODE_UNKNOWN to cope for the compiler being
> called
>    with -Werror=switch.
>  - Rebase to a newer tree
> 
> Just to evaluate the options, I tried with a BUG_ON(ssusb->dr_mode ==
> USB_DR_MODE_UNKNOWN) before the switch, but even then gcc insists on
> the
> case label for this value.
> 
> Best regards
> Uwe
> 
>  drivers/usb/mtu3/mtu3_plat.c | 19 +++++++++++++------
>  1 file changed, 13 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/usb/mtu3/mtu3_plat.c
> b/drivers/usb/mtu3/mtu3_plat.c
> index 6f264b129243..18c6cf9a2d71 100644
> --- a/drivers/usb/mtu3/mtu3_plat.c
> +++ b/drivers/usb/mtu3/mtu3_plat.c
> @@ -451,7 +451,7 @@ static int mtu3_probe(struct platform_device
> *pdev)
>  return ret;
>  }
>  
> -static int mtu3_remove(struct platform_device *pdev)
> +static void mtu3_remove(struct platform_device *pdev)
>  {
>  struct ssusb_mtk *ssusb = platform_get_drvdata(pdev);
>  
> @@ -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);
> +break;
How about changing as below:
    defualt:
       break;
>  }
>  
>  ssusb_rscs_exit(ssusb);
> @@ -478,8 +487,6 @@ static int mtu3_remove(struct platform_device
> *pdev)
>  pm_runtime_disable(&pdev->dev);
>  pm_runtime_put_noidle(&pdev->dev);
>  pm_runtime_set_suspended(&pdev->dev);
> -
> -return 0;
>  }
>  
>  static int resume_ip_and_ports(struct ssusb_mtk *ssusb, pm_message_t
> msg)
> @@ -615,7 +622,7 @@ MODULE_DEVICE_TABLE(of, mtu3_of_match);
>  
>  static struct platform_driver mtu3_driver = {
>  .probe = mtu3_probe,
> -.remove = mtu3_remove,
> +.remove_new = mtu3_remove,
>  .driver = {
>  .name = MTU3_DRIVER_NAME,
>  .pm = DEV_PM_OPS,
> 
> base-commit: 98897dc735cf6635f0966f76eb0108354168fb15
> -- 
> 2.40.1
> 

Re: [PATCH v2] usb: mtu3: Convert to platform remove callback returning void

[Uwe Kleine-König]

[-- Attachment #1: Type: text/plain, Size: 1550 bytes --]

Hello,

On Tue, Sep 19, 2023 at 07:52:04AM +0000, Chunfeng Yun (云春峰) wrote:
> On Thu, 2023-09-14 at 22:02 +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);
> > +break;
> How about changing as below:
>     defualt:
>        break;
> >  }

I think a warning is a good idea as today that case cannot happen
(unless I missed something) and if it still happened, you'd want to know
as the handling is insufficient then. And I also think that if the enum
usb_dr_mode should ever be expanded, this code location should be
revisited, so the explicit "case USB_DR_MODE_UNKNOWN" is better in my
opinion.

As you suggest this variant you seem to have some upside in mind, didn't
put it into your message though. Would you share your thoughts?

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-König            |
Industrial Linux Solutions                 | https://www.pengutronix.de/ |

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PATCH v2] usb: mtu3: Convert to platform remove callback returning void

[Greg Kroah-Hartman]

On Thu, Sep 14, 2023 at 10:02:51PM +0200, Uwe Kleine-König wrote:
> The .remove() callback for a platform driver returns an int which makes
> many driver authors wrongly assume it's possible to do error handling by
> returning an error code. However the value returned is (mostly) ignored
> and this typically results in resource leaks. To improve here there is a
> quest to make the remove callback return void. In the first step of this
> quest all drivers are converted to .remove_new() which already returns
> void.
> 
> The function mtu3_remove() can only return a non-zero value if
> ssusb->dr_mode is neiter USB_DR_MODE_PERIPHERAL nor USB_DR_MODE_HOST nor
> USB_DR_MODE_OTG. In this case however the probe callback doesn't succeed
> and so the remove callback isn't called at all. So the code branch
> resulting in this error path could just be dropped were it not for the
> compiler choking on "enumeration value 'USB_DR_MODE_UNKNOWN' not handled
> in switch [-Werror=switch]". So instead replace this code path by a
> WARN_ON and then mtu3_remove() be converted to return void trivially.
> 
> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
> ---
> Changes since (implicit) v1 sent with Message-Id:
> 20230709163335.3458886-1-u.kleine-koenig@pengutronix.de:
> 
>  - Keep case USB_DR_MODE_UNKNOWN to cope for the compiler being called
>    with -Werror=switch.
>  - Rebase to a newer tree
> 
> Just to evaluate the options, I tried with a BUG_ON(ssusb->dr_mode ==
> USB_DR_MODE_UNKNOWN) before the switch, but even then gcc insists on the
> case label for this value.
> 
> Best regards
> Uwe
> 
>  drivers/usb/mtu3/mtu3_plat.c | 19 +++++++++++++------
>  1 file changed, 13 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/usb/mtu3/mtu3_plat.c b/drivers/usb/mtu3/mtu3_plat.c
> index 6f264b129243..18c6cf9a2d71 100644
> --- a/drivers/usb/mtu3/mtu3_plat.c
> +++ b/drivers/usb/mtu3/mtu3_plat.c
> @@ -451,7 +451,7 @@ static int mtu3_probe(struct platform_device *pdev)
>  	return ret;
>  }
>  
> -static int mtu3_remove(struct platform_device *pdev)
> +static void mtu3_remove(struct platform_device *pdev)
>  {
>  	struct ssusb_mtk *ssusb = platform_get_drvdata(pdev);
>  
> @@ -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.

thanks,

greg k-h

Re: [PATCH v2] usb: mtu3: Convert to platform remove callback returning void

[Uwe Kleine-König]

[-- Attachment #1: Type: text/plain, Size: 1377 bytes --]

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.

I'll retest and assuming you're right, rework accordingly.

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-König            |
Industrial Linux Solutions                 | https://www.pengutronix.de/ |

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PATCH v2] usb: mtu3: Convert to platform remove callback returning void

[Greg Kroah-Hartman]

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.

Re: [PATCH v2] usb: mtu3: Convert to platform remove callback returning void

[Uwe Kleine-König]

[-- Attachment #1: Type: text/plain, Size: 2036 bytes --]

Hello Greg,

On Mon, Oct 02, 2023 at 04:53:05PM +0200, Greg Kroah-Hartman wrote:
> On Mon, Oct 02, 2023 at 04:49:59PM +0200, Uwe Kleine-König wrote:
> > 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.

The people enabling panic-on-warn *ask* for a reboot if something
strange happens, right? If ssusb->dr_mode is USB_DR_MODE_UNKNOWN in
.remove() but wasn't in .probe(), that's strange, right? If I don't
enable panic-on-warn, my system just emits a warning and then the driver
copes with what it has, right? Sounds to me as if WARN_ON does exactly
what is the right thing here.

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-König            |
Industrial Linux Solutions                 | https://www.pengutronix.de/ |

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PATCH v2] usb: mtu3: Convert to platform remove callback returning void

[Greg Kroah-Hartman]

On Mon, Oct 02, 2023 at 11:41:58PM +0200, Uwe Kleine-König wrote:
> Hello Greg,
> 
> On Mon, Oct 02, 2023 at 04:53:05PM +0200, Greg Kroah-Hartman wrote:
> > On Mon, Oct 02, 2023 at 04:49:59PM +0200, Uwe Kleine-König wrote:
> > > 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.
> 
> The people enabling panic-on-warn *ask* for a reboot if something
> strange happens, right? If ssusb->dr_mode is USB_DR_MODE_UNKNOWN in
> .remove() but wasn't in .probe(), that's strange, right? If I don't
> enable panic-on-warn, my system just emits a warning and then the driver
> copes with what it has, right? Sounds to me as if WARN_ON does exactly
> what is the right thing here.

I really don't want to add more WARN_ON() to the kernel if at all
possible.

If this "can not happen" then just don't even add code for it, why have
this at all?  The compiler warning can be handled a different way,
right?

thanks,

greg k-h

Re: [PATCH v2] usb: mtu3: Convert to platform remove callback returning void

[Uwe Kleine-König]

[-- Attachment #1: Type: text/plain, Size: 2680 bytes --]

Hello Greg,

On Thu, Oct 05, 2023 at 09:13:18AM +0200, Greg Kroah-Hartman wrote:
> On Mon, Oct 02, 2023 at 11:41:58PM +0200, Uwe Kleine-König wrote:
> > On Mon, Oct 02, 2023 at 04:53:05PM +0200, Greg Kroah-Hartman wrote:
> > > On Mon, Oct 02, 2023 at 04:49:59PM +0200, Uwe Kleine-König wrote:
> > > > 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.
> > 
> > The people enabling panic-on-warn *ask* for a reboot if something
> > strange happens, right? If ssusb->dr_mode is USB_DR_MODE_UNKNOWN in
> > .remove() but wasn't in .probe(), that's strange, right? If I don't
> > enable panic-on-warn, my system just emits a warning and then the driver
> > copes with what it has, right? Sounds to me as if WARN_ON does exactly
> > what is the right thing here.
> 
> I really don't want to add more WARN_ON() to the kernel if at all
> possible.
> 
> If this "can not happen" then just don't even add code for it, why have
> this at all?  The compiler warning can be handled a different way,
> right?

Sure, what do you suggest? A dev_warn()?

..ooOO(But maybe there are people who reboot on dev_warn(), too?)

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-König            |
Industrial Linux Solutions                 | https://www.pengutronix.de/ |

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PATCH v2] usb: mtu3: Convert to platform remove callback returning void

[Greg Kroah-Hartman]

On Fri, Oct 20, 2023 at 11:53:25AM +0200, Uwe Kleine-König wrote:
> Hello Greg,
> 
> On Thu, Oct 05, 2023 at 09:13:18AM +0200, Greg Kroah-Hartman wrote:
> > On Mon, Oct 02, 2023 at 11:41:58PM +0200, Uwe Kleine-König wrote:
> > > On Mon, Oct 02, 2023 at 04:53:05PM +0200, Greg Kroah-Hartman wrote:
> > > > On Mon, Oct 02, 2023 at 04:49:59PM +0200, Uwe Kleine-König wrote:
> > > > > 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.
> > > 
> > > The people enabling panic-on-warn *ask* for a reboot if something
> > > strange happens, right? If ssusb->dr_mode is USB_DR_MODE_UNKNOWN in
> > > .remove() but wasn't in .probe(), that's strange, right? If I don't
> > > enable panic-on-warn, my system just emits a warning and then the driver
> > > copes with what it has, right? Sounds to me as if WARN_ON does exactly
> > > what is the right thing here.
> > 
> > I really don't want to add more WARN_ON() to the kernel if at all
> > possible.
> > 
> > If this "can not happen" then just don't even add code for it, why have
> > this at all?  The compiler warning can be handled a different way,
> > right?
> 
> Sure, what do you suggest? A dev_warn()?

Sure.  but again, if this can not happen, why do anything?

> ..ooOO(But maybe there are people who reboot on dev_warn(), too?)

No, that's not a thing, thankfully :)

greg k-h