All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andi Shyti <andi.shyti@kernel.org>
To: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Cc: Liao Chang <liaochang1@huawei.com>,
	florian.fainelli@broadcom.com, rjui@broadcom.com,
	sbranden@broadcom.com, bcm-kernel-feedback-list@broadcom.com,
	yangyicong@hisilicon.com, aisheng.dong@nxp.com,
	shawnguo@kernel.org, s.hauer@pengutronix.de,
	kernel@pengutronix.de, festevam@gmail.com, linux-imx@nxp.com,
	kblaiech@nvidia.com, asmaa@nvidia.com, loic.poulain@linaro.org,
	rfoss@kernel.org, ardb@kernel.org, gcherian@marvell.com,
	linux-i2c@vger.kernel.org, linux-rpi-kernel@lists.infradead.org,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, linux-arm-msm@vger.kernel.org
Subject: Re: [PATCH v3 2/9] i2c: mlxbf: Use dev_err_probe in probe function
Date: Wed, 9 Aug 2023 10:02:32 +0200	[thread overview]
Message-ID: <20230809080232.ktoryciynfuhnmnk@intel.intel> (raw)
In-Reply-To: <7698ce68-c393-d566-25b9-7b2a08dd8274@linaro.org>

On Tue, Aug 08, 2023 at 05:55:29PM +0200, Krzysztof Kozlowski wrote:
> On 08/08/2023 13:47, Andi Shyti wrote:
> > Hi Krzysztof,
> > 
> > On Tue, Aug 08, 2023 at 01:31:31PM +0200, Krzysztof Kozlowski wrote:
> >> On 08/08/2023 13:29, Andi Shyti wrote:
> >>> Hi Krzysztof,
> >>>
> >>> On Tue, Aug 08, 2023 at 10:36:40AM +0200, Krzysztof Kozlowski wrote:
> >>>> On 08/08/2023 03:29, Liao Chang wrote:
> >>>>> Use the dev_err_probe function instead of dev_err in the probe function
> >>>>> so that the printed messge includes the return value and also handles
> >>>>> -EPROBE_DEFER nicely.
> >>>>>
> >>>>> Reviewed-by: Andi Shyti <andi.shyti@kernel.org>
> >>>>> Signed-off-by: Liao Chang <liaochang1@huawei.com>
> >>>>
> >>>> ...
> >>>>
> >>>>> @@ -2413,10 +2399,8 @@ static int mlxbf_i2c_probe(struct platform_device *pdev)
> >>>>>  	ret = devm_request_irq(dev, irq, mlxbf_i2c_irq,
> >>>>>  			       IRQF_SHARED | IRQF_PROBE_SHARED,
> >>>>>  			       dev_name(dev), priv);
> >>>>> -	if (ret < 0) {
> >>>>> -		dev_err(dev, "Cannot get irq %d\n", irq);
> >>>>> -		return ret;
> >>>>> -	}
> >>>>> +	if (ret < 0)
> >>>>> +		return dev_err_probe(dev, ret, "Cannot get irq %d\n", irq);
> >>>>
> >>>> I don't think this is needed:
> >>>> https://lore.kernel.org/all/20230721094641.77189-1-frank.li@vivo.com/
> >>>
> >>> Hmm, that's a bit borderline, I'd say. The change to
> >>
> >> What's borderline exactly? devm_request_threaded_irq_probe() is coming,
> >> right? If it is accepted this hunk is useless and soon should be
> >> replaced with proper one.
> > 
> > Such change is out of the scope of this series, there are two
> > options that I'd prefer (in the listed order):
> > 
> >  1. accept the patch as it is, this patch is not sent today the
> >     first time and at the current state it's correct.
> >  2. not accept a change on this line
> 
> The 2 is what I commented here. This change should not be made and
> instead we should just switch all such users to new API, because this is
> preferred for all error messages, when applicable and does not result in
> lost context. If there was no such API, sure, but we have this API coming.

To me the patch is correct... I am OK also with 2, but I find 1
more complete... let's say that it's a matter of taste?

> > Replacing devm_request_irq belongs to another series and,
> > besides, I don't want to ask Liao to hold on this series for such
> > trivialities.
> 
> So the comment about this redundant and unneeded change, thus switching
> to new API you call 'triviality' but a comment of yours of changing the
> tone of error message to 'please' is appropriate.
> https://lore.kernel.org/all/20230807231320.svssge6uymw3jiho@intel.intel/
> 
> That's double standards.

That was a joke, the review was somewhere else in my comment.

Thanks for your inputs,
Andi

WARNING: multiple messages have this Message-ID (diff)
From: Andi Shyti <andi.shyti@kernel.org>
To: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Cc: Liao Chang <liaochang1@huawei.com>,
	florian.fainelli@broadcom.com, rjui@broadcom.com,
	sbranden@broadcom.com, bcm-kernel-feedback-list@broadcom.com,
	yangyicong@hisilicon.com, aisheng.dong@nxp.com,
	shawnguo@kernel.org, s.hauer@pengutronix.de,
	kernel@pengutronix.de, festevam@gmail.com, linux-imx@nxp.com,
	kblaiech@nvidia.com, asmaa@nvidia.com, loic.poulain@linaro.org,
	rfoss@kernel.org, ardb@kernel.org, gcherian@marvell.com,
	linux-i2c@vger.kernel.org, linux-rpi-kernel@lists.infradead.org,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, linux-arm-msm@vger.kernel.org
Subject: Re: [PATCH v3 2/9] i2c: mlxbf: Use dev_err_probe in probe function
Date: Wed, 9 Aug 2023 10:02:32 +0200	[thread overview]
Message-ID: <20230809080232.ktoryciynfuhnmnk@intel.intel> (raw)
In-Reply-To: <7698ce68-c393-d566-25b9-7b2a08dd8274@linaro.org>

On Tue, Aug 08, 2023 at 05:55:29PM +0200, Krzysztof Kozlowski wrote:
> On 08/08/2023 13:47, Andi Shyti wrote:
> > Hi Krzysztof,
> > 
> > On Tue, Aug 08, 2023 at 01:31:31PM +0200, Krzysztof Kozlowski wrote:
> >> On 08/08/2023 13:29, Andi Shyti wrote:
> >>> Hi Krzysztof,
> >>>
> >>> On Tue, Aug 08, 2023 at 10:36:40AM +0200, Krzysztof Kozlowski wrote:
> >>>> On 08/08/2023 03:29, Liao Chang wrote:
> >>>>> Use the dev_err_probe function instead of dev_err in the probe function
> >>>>> so that the printed messge includes the return value and also handles
> >>>>> -EPROBE_DEFER nicely.
> >>>>>
> >>>>> Reviewed-by: Andi Shyti <andi.shyti@kernel.org>
> >>>>> Signed-off-by: Liao Chang <liaochang1@huawei.com>
> >>>>
> >>>> ...
> >>>>
> >>>>> @@ -2413,10 +2399,8 @@ static int mlxbf_i2c_probe(struct platform_device *pdev)
> >>>>>  	ret = devm_request_irq(dev, irq, mlxbf_i2c_irq,
> >>>>>  			       IRQF_SHARED | IRQF_PROBE_SHARED,
> >>>>>  			       dev_name(dev), priv);
> >>>>> -	if (ret < 0) {
> >>>>> -		dev_err(dev, "Cannot get irq %d\n", irq);
> >>>>> -		return ret;
> >>>>> -	}
> >>>>> +	if (ret < 0)
> >>>>> +		return dev_err_probe(dev, ret, "Cannot get irq %d\n", irq);
> >>>>
> >>>> I don't think this is needed:
> >>>> https://lore.kernel.org/all/20230721094641.77189-1-frank.li@vivo.com/
> >>>
> >>> Hmm, that's a bit borderline, I'd say. The change to
> >>
> >> What's borderline exactly? devm_request_threaded_irq_probe() is coming,
> >> right? If it is accepted this hunk is useless and soon should be
> >> replaced with proper one.
> > 
> > Such change is out of the scope of this series, there are two
> > options that I'd prefer (in the listed order):
> > 
> >  1. accept the patch as it is, this patch is not sent today the
> >     first time and at the current state it's correct.
> >  2. not accept a change on this line
> 
> The 2 is what I commented here. This change should not be made and
> instead we should just switch all such users to new API, because this is
> preferred for all error messages, when applicable and does not result in
> lost context. If there was no such API, sure, but we have this API coming.

To me the patch is correct... I am OK also with 2, but I find 1
more complete... let's say that it's a matter of taste?

> > Replacing devm_request_irq belongs to another series and,
> > besides, I don't want to ask Liao to hold on this series for such
> > trivialities.
> 
> So the comment about this redundant and unneeded change, thus switching
> to new API you call 'triviality' but a comment of yours of changing the
> tone of error message to 'please' is appropriate.
> https://lore.kernel.org/all/20230807231320.svssge6uymw3jiho@intel.intel/
> 
> That's double standards.

That was a joke, the review was somewhere else in my comment.

Thanks for your inputs,
Andi

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2023-08-09  8:02 UTC|newest]

Thread overview: 56+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-08-08  1:29 [PATCH v3 0/9] Use dev_err_probe in i2c probe function Liao Chang
2023-08-08  1:29 ` Liao Chang
2023-08-08  1:29 ` [PATCH v3 1/9] i2c: bcm2835: Use dev_err_probe in " Liao Chang
2023-08-08  1:29   ` Liao Chang
2023-08-08  9:37   ` Markus Elfring
2023-08-08 11:31     ` Andi Shyti
2023-08-08 11:31       ` Andi Shyti
2023-08-08  1:29 ` [PATCH v3 2/9] i2c: mlxbf: " Liao Chang
2023-08-08  1:29   ` Liao Chang
2023-08-08  8:36   ` Krzysztof Kozlowski
2023-08-08  8:36     ` Krzysztof Kozlowski
2023-08-08 11:29     ` Andi Shyti
2023-08-08 11:29       ` Andi Shyti
2023-08-08 11:31       ` Krzysztof Kozlowski
2023-08-08 11:31         ` Krzysztof Kozlowski
2023-08-08 11:47         ` Andi Shyti
2023-08-08 11:47           ` Andi Shyti
2023-08-08 15:55           ` Krzysztof Kozlowski
2023-08-08 15:55             ` Krzysztof Kozlowski
2023-08-09  8:02             ` Andi Shyti [this message]
2023-08-09  8:02               ` Andi Shyti
2023-08-08 10:32   ` Markus Elfring
2023-08-08  1:29 ` [PATCH v3 3/9] i2c: xlp9xx: " Liao Chang
2023-08-08  1:29   ` Liao Chang
2023-08-08  8:36   ` Krzysztof Kozlowski
2023-08-08  8:36     ` Krzysztof Kozlowski
2023-08-08  1:29 ` [PATCH v3 4/9] i2c: hisi: " Liao Chang
2023-08-08  1:29   ` Liao Chang
2023-08-08  8:36   ` Krzysztof Kozlowski
2023-08-08  8:36     ` Krzysztof Kozlowski
2023-08-08  1:29 ` [PATCH v3 5/9] i2c: qcom-cci: " Liao Chang
2023-08-08  1:29   ` Liao Chang
2023-08-10 15:06   ` Bjorn Andersson
2023-08-10 15:06     ` Bjorn Andersson
2023-08-08  1:29 ` [PATCH v3 6/9] i2c: pxa: " Liao Chang
2023-08-08  1:29   ` Liao Chang
2023-08-08  1:29 ` [PATCH v3 7/9] i2c: dln2: " Liao Chang
2023-08-08  1:29   ` Liao Chang
2023-08-08  1:29 ` [PATCH v3 8/9] i2c: imx-lpi2c: " Liao Chang
2023-08-08  1:29   ` Liao Chang
2023-08-08  8:37   ` Krzysztof Kozlowski
2023-08-08  8:37     ` Krzysztof Kozlowski
2023-08-08  1:29 ` [PATCH v3 9/9] i2c: synquacer: " Liao Chang
2023-08-08  1:29   ` Liao Chang
2023-08-08  8:37   ` Krzysztof Kozlowski
2023-08-08  8:37     ` Krzysztof Kozlowski
2023-08-09 19:21   ` Andi Shyti
2023-08-09 19:21     ` Andi Shyti
2023-08-10  2:33     ` Liao, Chang
2023-08-10  2:33       ` Liao, Chang
2023-08-10  8:10       ` Andi Shyti
2023-08-10  8:10         ` Andi Shyti
2023-08-10  8:19 ` [PATCH v3 0/9] Use dev_err_probe in i2c " Andi Shyti
2023-08-10  8:19   ` Andi Shyti
2023-08-14 15:16   ` Wolfram Sang
2023-08-14 15:16     ` Wolfram Sang

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=20230809080232.ktoryciynfuhnmnk@intel.intel \
    --to=andi.shyti@kernel.org \
    --cc=aisheng.dong@nxp.com \
    --cc=ardb@kernel.org \
    --cc=asmaa@nvidia.com \
    --cc=bcm-kernel-feedback-list@broadcom.com \
    --cc=festevam@gmail.com \
    --cc=florian.fainelli@broadcom.com \
    --cc=gcherian@marvell.com \
    --cc=kblaiech@nvidia.com \
    --cc=kernel@pengutronix.de \
    --cc=krzysztof.kozlowski@linaro.org \
    --cc=liaochang1@huawei.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-i2c@vger.kernel.org \
    --cc=linux-imx@nxp.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-rpi-kernel@lists.infradead.org \
    --cc=loic.poulain@linaro.org \
    --cc=rfoss@kernel.org \
    --cc=rjui@broadcom.com \
    --cc=s.hauer@pengutronix.de \
    --cc=sbranden@broadcom.com \
    --cc=shawnguo@kernel.org \
    --cc=yangyicong@hisilicon.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.