linux-kernel - Re: [PATCH v3] extcon: palmas: hide error messages if gpio returns -EPROBE

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 18 Feb 2020 11:48:10 +0100
From:   Ladislav Michl <ladis@...ux-mips.org>
To:     Chanwoo Choi <cw00.choi@...sung.com>
Cc:     "H. Nikolaus Schaller" <hns@...delico.com>,
        MyungJoo Ham <myungjoo.ham@...sung.com>,
        linux-kernel@...r.kernel.org, letux-kernel@...nphoenux.org,
        kernel@...a-handheld.com, linux-omap@...r.kernel.org
Subject: Re: [PATCH v3] extcon: palmas: hide error messages if gpio returns
 -EPROBE_DEFER

On Tue, Feb 18, 2020 at 07:35:47PM +0900, Chanwoo Choi wrote:
> On 2/18/20 7:21 PM, Ladislav Michl wrote:
> > On Tue, Feb 18, 2020 at 12:28:25PM +0900, Chanwoo Choi wrote:
> >> On 2/17/20 10:38 PM, H. Nikolaus Schaller wrote:
> >>> If the gpios are probed after this driver (e.g. if they
> >>> come from an i2c expander) there is no need to print an
> >>> error message.
> >>>
> >>> Signed-off-by: H. Nikolaus Schaller <hns@...delico.com>
> >>> ---
> >>>  drivers/extcon/extcon-palmas.c | 8 ++++++--
> >>>  1 file changed, 6 insertions(+), 2 deletions(-)
> >>>
> >>> diff --git a/drivers/extcon/extcon-palmas.c b/drivers/extcon/extcon-palmas.c
> >>> index edc5016f46f1..cea58d0cb457 100644
> >>> --- a/drivers/extcon/extcon-palmas.c
> >>> +++ b/drivers/extcon/extcon-palmas.c
> >>> @@ -205,14 +205,18 @@ static int palmas_usb_probe(struct platform_device *pdev)
> >>>  
> >>>  	palmas_usb->id_gpiod = devm_gpiod_get_optional(&pdev->dev, "id",
> >>>  							GPIOD_IN);
> >>> -	if (IS_ERR(palmas_usb->id_gpiod)) {
> >>> +	if (PTR_ERR(palmas_usb->id_gpiod) == -EPROBE_DEFER) {
> >>> +		return -EPROBE_DEFER;

Here we returned...

> >>> +	} else if (IS_ERR(palmas_usb->id_gpiod)) {

How could this else get triggered?

> >>>  		dev_err(&pdev->dev, "failed to get id gpio\n");
> >>>  		return PTR_ERR(palmas_usb->id_gpiod);
> >>>  	}
> >>>  
> >>>  	palmas_usb->vbus_gpiod = devm_gpiod_get_optional(&pdev->dev, "vbus",
> >>>  							GPIOD_IN);
> >>> -	if (IS_ERR(palmas_usb->vbus_gpiod)) {
> >>> +	if (PTR_ERR(palmas_usb->vbus_gpiod) == -EPROBE_DEFER) {
> >>> +		return -EPROBE_DEFER;
> >>> +	} else if (IS_ERR(palmas_usb->vbus_gpiod)) {
> >>>  		dev_err(&pdev->dev, "failed to get vbus gpio\n");
> >>>  		return PTR_ERR(palmas_usb->vbus_gpiod);
> >>>  	}
> >>>
> >>
> >> I think that it is enough to handle the -EPROBE_DEFER.
> >> Also, I prefer to use single if/else statement 
> >> instead of the nested if/else statement.
> >>
> >> Applied it.
> > 
> > Uh... As it is? Then it is matter of time it triggers someones cocci
> > script pointing to else after return. Could you at least fix this?
> 
> Sorry. I don't understand. Do you mean that this patch has the
> some issue of cocci script?

Yes.

> I think that it fixes the probe sequence issue
> between extcon-palmas and gpio driver. It is not related to
> any result from cocci script. If the extcon-palmas.c has
> the issue by cocci or checkpatch, anyone can send the other patch
> for fixup.

Do you mean to send fixup to what you just applied? What happened
to review process? Nikolaus himself told you patch could be better
and we were just waiting which solution you choose to send final patch.

> I think that it is enough to fix the issue which is only
> related to the probe sequence between gpio and extcon-palmas.c

Agree, but look again at the patch.

	ladis