Re: [PATCH] usb: gadget: fsl: Fix a wrong judgment in fsl_udc_probe()

2020-04-10 Thread Markus Elfring
> If the function "platform_get_irq()" failed, the negative value
> returned will not be detected here, including "-EPROBE_DEFER",

I suggest to adjust this change description.

Wording alternative:
  The negative return value (which could eventually be “-EPROBE_DEFER”)
  will not be detected here from a failed call of the function 
“platform_get_irq”.


> which causes the application to fail to get the correct error message.

Will another fine-tuning become relevant also for this wording?


> Thus it must be fixed.

Wording alternative:
  Thus adjust the error detection and corresponding exception handling.


> Signed-off-by: Tang Bin 
> Signed-off-by: Shengju Zhang 

How do you think about to add the tags “Fixes”, “Link” and “Reported-by”?
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/submitting-patches.rst?id=c0cc271173b2e1c2d8d0ceaef14e4dfa79eefc0d#n584

usb: gadget: fsl_udc_core: Checking for a failed platform_get_irq() call in 
fsl_udc_probe()
https://lore.kernel.org/linux-usb/36341bb1-1e00-5eb1-d032-60dcc614d...@web.de/
https://lkml.org/lkml/2020/4/8/442

…
> +++ b/drivers/usb/gadget/udc/fsl_udc_core.c
> @@ -2441,8 +2441,8 @@ static int fsl_udc_probe(struct platform_device *pdev)
>   udc_controller->max_ep = (dccparams & DCCPARAMS_DEN_MASK) * 2;
>
>   udc_controller->irq = platform_get_irq(pdev, 0);
> - if (!udc_controller->irq) {
> - ret = -ENODEV;
> + if (udc_controller->irq <= 0) {

Will such a failure predicate need any more clarification?

How does this check fit to the current software documentation?


> + ret = udc_controller->irq ? : -ENODEV;

Will it be clearer to specify values for all cases in such a conditional 
operator
(instead of leaving one case empty)?

Regards,
Markus


Re: [PATCH] usb: gadget: fsl: Fix a wrong judgment in fsl_udc_probe()

2020-04-10 Thread Tang Bin

Hi Markus

On 2020/4/10 15:33, Markus Elfring wrote:

If the function "platform_get_irq()" failed, the negative value
returned will not be detected here, including "-EPROBE_DEFER",

I suggest to adjust this change description.

Wording alternative:
   The negative return value (which could eventually be “-EPROBE_DEFER”)
   will not be detected here from a failed call of the function 
“platform_get_irq”.
Hardware experiments show that the negative return value is not just 
"-EPROBE_DEFER".



which causes the application to fail to get the correct error message.

Will another fine-tuning become relevant also for this wording?

Maybe that's not quite accurate.




Thus it must be fixed.

Wording alternative:
   Thus adjust the error detection and corresponding exception handling.

Got it.




Signed-off-by: Tang Bin 
Signed-off-by: Shengju Zhang 

How do you think about to add the tags “Fixes”, “Link” and “Reported-by”?
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/submitting-patches.rst?id=c0cc271173b2e1c2d8d0ceaef14e4dfa79eefc0d#n584

usb: gadget: fsl_udc_core: Checking for a failed platform_get_irq() call in 
fsl_udc_probe()
https://lore.kernel.org/linux-usb/36341bb1-1e00-5eb1-d032-60dcc614d...@web.de/
https://lkml.org/lkml/2020/4/8/442

…

+++ b/drivers/usb/gadget/udc/fsl_udc_core.c
@@ -2441,8 +2441,8 @@ static int fsl_udc_probe(struct platform_device *pdev)
udc_controller->max_ep = (dccparams & DCCPARAMS_DEN_MASK) * 2;

udc_controller->irq = platform_get_irq(pdev, 0);
-   if (!udc_controller->irq) {
-   ret = -ENODEV;
+   if (udc_controller->irq <= 0) {

Will such a failure predicate need any more clarification?

How does this check fit to the current software documentation?

Maybe my tags are not suitable.




+   ret = udc_controller->irq ? : -ENODEV;

Will it be clearer to specify values for all cases in such a conditional 
operator
(instead of leaving one case empty)?


I don't know what you mean of "instead of leaving one case empty". But 
by experiment, "ret = udc_controller->irq ? : -ENODEV" or "ret = 
udc_controller->irq < 0 ? udc_controller->irq : -ENODEV" should be 
suitable here.



Thank you for your guidance.

Tang Bin





Re: [PATCH] usb: gadget: fsl: Fix a wrong judgment in fsl_udc_probe()

2020-04-10 Thread Sergei Shtylyov

Hello!

On 10.04.2020 4:58, Tang Bin wrote:


If the function "platform_get_irq()" failed, the negative value
returned will not be detected here, including "-EPROBE_DEFER", which
causes the application to fail to get the correct error message.
Thus it must be fixed.

Signed-off-by: Tang Bin 
Signed-off-by: Shengju Zhang 
---
  drivers/usb/gadget/udc/fsl_udc_core.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/gadget/udc/fsl_udc_core.c 
b/drivers/usb/gadget/udc/fsl_udc_core.c
index ec6eda426..60853ad10 100644
--- a/drivers/usb/gadget/udc/fsl_udc_core.c
+++ b/drivers/usb/gadget/udc/fsl_udc_core.c
@@ -2441,8 +2441,8 @@ static int fsl_udc_probe(struct platform_device *pdev)
udc_controller->max_ep = (dccparams & DCCPARAMS_DEN_MASK) * 2;
  
  	udc_controller->irq = platform_get_irq(pdev, 0);

-   if (!udc_controller->irq) {


   This check has always been wrong, doesn't account for real errors and
probe deferral...


-   ret = -ENODEV;
+   if (udc_controller->irq <= 0) {


   Note that platfrom_get_irq() no longer returns 0 on error.


+   ret = udc_controller->irq ? : -ENODEV;
goto err_iounmap;
}


MBR, Sergei


Re: [PATCH] usb: gadget: fsl: Fix a wrong judgment in fsl_udc_probe()

2020-04-10 Thread Sergei Shtylyov

On 10.04.2020 4:58, Tang Bin wrote:


If the function "platform_get_irq()" failed, the negative value
returned will not be detected here, including "-EPROBE_DEFER", which
causes the application to fail to get the correct error message.
Thus it must be fixed.


   platform_get_irq() prints an appropriate error message, the problem is that
the current code calls request_irq() with error code instead of IRQ.


Signed-off-by: Tang Bin 
Signed-off-by: Shengju Zhang 

[...]

MBR, Sergei


Re: [PATCH] usb: gadget: fsl: Fix a wrong judgment in fsl_udc_probe()

2020-04-14 Thread Dan Carpenter
On Fri, Apr 10, 2020 at 04:05:06PM +0800, Tang Bin wrote:
> > 
> > 
> > > Thus it must be fixed.
> > Wording alternative:
> >Thus adjust the error detection and corresponding exception handling.
>
> Got it.

Wow...

No, don't listen to Markus when it comes to writing commit messages.
You couldn't find worse advice anywhere.  :P

regards,
dan carpenter



Re: [PATCH] usb: gadget: fsl: Fix a wrong judgment in fsl_udc_probe()

2020-04-14 Thread Tang Bin

Hi

On 2020/4/14 16:30, Dan Carpenter wrote:

On Fri, Apr 10, 2020 at 04:05:06PM +0800, Tang Bin wrote:



Thus it must be fixed.

Wording alternative:
Thus adjust the error detection and corresponding exception handling.

Got it.

Wow...

No, don't listen to Markus when it comes to writing commit messages.
You couldn't find worse advice anywhere.  :P


I'm actively waiting for a reply from the maintainer. Thank you very much.

Tang Bin






Re: [PATCH] usb: gadget: fsl: Fix a wrong judgment in fsl_udc_probe()

2020-05-22 Thread Li Yang
On Tue, Apr 14, 2020 at 4:13 AM Tang Bin  wrote:
>
> Hi
>
> On 2020/4/14 16:30, Dan Carpenter wrote:
> > On Fri, Apr 10, 2020 at 04:05:06PM +0800, Tang Bin wrote:
> >>>
>  Thus it must be fixed.
> >>> Wording alternative:
> >>> Thus adjust the error detection and corresponding exception handling.
> >> Got it.
> > Wow...
> >
> > No, don't listen to Markus when it comes to writing commit messages.
> > You couldn't find worse advice anywhere.  :P
>
> I'm actively waiting for a reply from the maintainer. Thank you very much.

Sorry for the late response.

Acked-by: Li Yang 

Regards,
Leo