From: Dan Carpenter <dan.carpenter@oracle.com>
To: Li Jun <jun.li@nxp.com>
Cc: devel@driverdev.osuosl.org, devicetree@vger.kernel.org,
heikki.krogerus@linux.intel.com, peter.chen@nxp.com,
gregkh@linuxfoundation.org, linux-usb@vger.kernel.org,
a.hajda@samsung.com, robh+dt@kernel.org, linux-imx@nxp.com,
linux@roeck-us.net, shufan_lee@richtek.com
Subject: Re: [PATCH v4 07/13] staging: typec: tcpci: register port before request irq
Date: Thu, 29 Mar 2018 13:52:12 +0300 [thread overview]
Message-ID: <20180329105212.lp5oydu4uejeo4h4@mwanda> (raw)
In-Reply-To: <1522253178-32414-8-git-send-email-jun.li@nxp.com>
On Thu, Mar 29, 2018 at 12:06:12AM +0800, Li Jun wrote:
> With that we can clear any pending events and the port is registered
> so driver can be ready to handle typec events once we request irq.
>
> Signed-off-by: Peter Chen <peter.chen@nxp.com>
> Signed-off-by: Li Jun <jun.li@nxp.com>
These sign offs aren't clear.
Sign offs mean that you handled the patch but didn't include any of
SCO's copyrighted UNIX code into it. Normally they're in the order of
who touched the code. So Peter touched the code first. Should he get
authorship credit? How did he touch the code first if he didn't write
the code? It doesn't make sense.
> ---
> drivers/staging/typec/tcpci.c | 15 ++++++++-------
> 1 file changed, 8 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/staging/typec/tcpci.c b/drivers/staging/typec/tcpci.c
> index 4f7ad10..9e0014b 100644
> --- a/drivers/staging/typec/tcpci.c
> +++ b/drivers/staging/typec/tcpci.c
> @@ -537,25 +537,26 @@ static int tcpci_probe(struct i2c_client *client,
> if (IS_ERR(chip->data.regmap))
> return PTR_ERR(chip->data.regmap);
>
> + i2c_set_clientdata(client, chip);
> +
> /* Disable chip interrupts before requesting irq */
> err = regmap_raw_write(chip->data.regmap, TCPC_ALERT_MASK, &val,
> sizeof(u16));
> if (err < 0)
> return err;
>
> + chip->tcpci = tcpci_register_port(&client->dev, &chip->data);
> + if (PTR_ERR_OR_ZERO(chip->tcpci))
> + return PTR_ERR(chip->tcpci);
When a function returns both error pointers and NULL that means that
NULL is a secial case of success. Like for example:
p->my_feature = get_optional_feature();
If it returns NULL that means the optional feature isn't there, but it's
fine because it's optional. But if it returns an error pointer that
means the feature is there but the hardware is buggy or something so
we shouldn't continue.
If you return PTR_ERR(NULL) that means success.
I don't think this code makes sense just from looking at it and also
when I checked tcpci_register_port() doesn't return NULL.
> +
> err = devm_request_threaded_irq(&client->dev, client->irq, NULL,
> _tcpci_irq,
> IRQF_ONESHOT | IRQF_TRIGGER_LOW,
> dev_name(&client->dev), chip);
> if (err < 0)
> - return err;
> + tcpci_unregister_port(chip->tcpci);
Can you put the "return err;" back, because that's better style. It's
better to keep the error path and success path separate if you can.
if (err < 0) {
tcpci_unregister_port(chip->tcpci);
return err;
}
return 0;
regards,
dan carpenter
next prev parent reply other threads:[~2018-03-29 10:52 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-03-28 16:06 [PATCH v4 00/13] staging: typec: tcpci: move out of staging Li Jun
2018-03-28 16:06 ` [PATCH v4 01/13] dt-bindings: connector: add properties for typec Li Jun
2018-03-29 19:54 ` Mats Karrman
2018-03-31 3:34 ` Jun Li
2018-04-03 8:29 ` Andrzej Hajda
2018-04-13 11:51 ` Jun Li
2018-04-30 11:23 ` Heikki Krogerus
2018-05-01 7:57 ` Jun Li
2018-03-28 16:06 ` [PATCH v4 02/13] dt-bindings: usb: add documentation for typec port controller(TCPCI) Li Jun
2018-04-09 20:04 ` Rob Herring
2018-04-16 11:54 ` Jun Li
2018-04-16 14:28 ` Rob Herring
2018-04-19 14:47 ` Jun Li
2018-04-30 7:41 ` Mats Karrman
2018-05-01 7:54 ` Jun Li
2018-03-28 16:06 ` [PATCH v4 03/13] staging: typec: tcpci: add compatible string for nxp ptn5110 Li Jun
2018-03-28 16:06 ` [PATCH v4 04/13] usb: typec: add fwnode to tcpc Li Jun
2018-03-29 12:57 ` Heikki Krogerus
2018-03-31 3:17 ` Jun Li
2018-03-28 16:06 ` [PATCH v4 05/13] usb: typec: add API to get typec basic port power and data config Li Jun
2018-03-28 16:06 ` [PATCH v4 06/13] usb: typec: tcpm: support get typec and pd config from device properties Li Jun
2018-03-28 16:06 ` [PATCH v4 07/13] staging: typec: tcpci: register port before request irq Li Jun
2018-03-29 10:52 ` Dan Carpenter [this message]
2018-03-31 3:09 ` Jun Li
2018-03-31 8:01 ` Dan Carpenter
2018-03-28 16:06 ` [PATCH v4 08/13] staging: typec: tcpci: enable vbus detection Li Jun
2018-03-28 16:06 ` [PATCH v4 09/13] typec: tcpm: add starting value for drp toggling Li Jun
2018-03-28 16:06 ` [PATCH v4 10/13] usb: typec: tcpm: set cc for drp toggling attach Li Jun
2018-03-29 21:18 ` Mats Karrman
2018-03-31 3:37 ` Jun Li
2018-03-29 22:49 ` Guenter Roeck
2018-03-31 4:38 ` Jun Li
2018-03-28 16:06 ` [PATCH v4 11/13] staging: typec: tcpci: keep the not connecting cc line open Li Jun
2018-03-30 15:15 ` Guenter Roeck
2018-03-31 4:49 ` Jun Li
2018-03-28 16:06 ` [PATCH v4 12/13] staging: typec: tcpci: Only touch target bit when enable vconn Li Jun
2018-03-28 16:06 ` [PATCH v4 13/13] staging: typec: tcpci: move tcpci driver out of staging Li Jun
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20180329105212.lp5oydu4uejeo4h4@mwanda \
--to=dan.carpenter@oracle.com \
--cc=a.hajda@samsung.com \
--cc=devel@driverdev.osuosl.org \
--cc=devicetree@vger.kernel.org \
--cc=gregkh@linuxfoundation.org \
--cc=heikki.krogerus@linux.intel.com \
--cc=jun.li@nxp.com \
--cc=linux-imx@nxp.com \
--cc=linux-usb@vger.kernel.org \
--cc=linux@roeck-us.net \
--cc=peter.chen@nxp.com \
--cc=robh+dt@kernel.org \
--cc=shufan_lee@richtek.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox