All of lore.kernel.org
 help / color / mirror / Atom feed
From: Timon Baetz <timon.baetz@protonmail.com>
To: Krzysztof Kozlowski <krzk@kernel.org>
Cc: Liam Girdwood <lgirdwood@gmail.com>,
	Mark Brown <broonie@kernel.org>, Rob Herring <robh+dt@kernel.org>,
	Sebastian Reichel <sre@kernel.org>,
	linux-kernel@vger.kernel.org, devicetree@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	linux-samsung-soc@vger.kernel.org, linux-pm@vger.kernel.org
Subject: Re: [PATCH 3/3] power: supply: max8997_charger: Switch to new binding
Date: Mon, 01 Feb 2021 09:26:42 +0000	[thread overview]
Message-ID: <20210201083128.18499ffd.timon.baetz@protonmail.com> (raw)
In-Reply-To: <20210131172840.fxaadhhsafa4aeex@kozik-lap>

On Sun, 31 Jan 2021 18:28:40 +0100, Krzysztof Kozlowski wrote:
> On Sat, Jan 30, 2021 at 05:30:14PM +0000, Timon Baetz wrote:
> > Get regulator from parent device's node and extcon by name.
> >
> > Signed-off-by: Timon Baetz <timon.baetz@protonmail.com>
> > ---
> >  drivers/power/supply/max8997_charger.c | 12 ++++++++----
> >  1 file changed, 8 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/power/supply/max8997_charger.c b/drivers/power/supply/max8997_charger.c
> > index 321bd6b8ee41..625d8cc4312a 100644
> > --- a/drivers/power/supply/max8997_charger.c
> > +++ b/drivers/power/supply/max8997_charger.c
> > @@ -168,6 +168,7 @@ static int max8997_battery_probe(struct platform_device *pdev)
> >  	int ret = 0;
> >  	struct charger_data *charger;
> >  	struct max8997_dev *iodev = dev_get_drvdata(pdev->dev.parent);
> > +	struct device_node *np = pdev->dev.of_node;
> >  	struct i2c_client *i2c = iodev->i2c;
> >  	struct max8997_platform_data *pdata = iodev->pdata;
> >  	struct power_supply_config psy_cfg = {};
> > @@ -237,20 +238,23 @@ static int max8997_battery_probe(struct platform_device *pdev)
> >  		return PTR_ERR(charger->battery);
> >  	}
> >
> > +	// grab regulator from parent device's node
> > +	pdev->dev.of_node = iodev->dev->of_node;
> >  	charger->reg = devm_regulator_get_optional(&pdev->dev, "charger");
> > +	pdev->dev.of_node = np;  
> 
> I think the device does not have its own node anymore. Or did I miss
> something?

The idea is to reset of_node to whatever it was before (NULL) and basically 
leave the device unchanged. Probe might run again because of deferral.

> >  	if (IS_ERR(charger->reg)) {
> >  		if (PTR_ERR(charger->reg) == -EPROBE_DEFER)
> >  			return -EPROBE_DEFER;
> >  		dev_info(&pdev->dev, "couldn't get charger regulator\n");
> >  	}
> > -	charger->edev = extcon_get_edev_by_phandle(&pdev->dev, 0);
> > -	if (IS_ERR(charger->edev)) {
> > -		if (PTR_ERR(charger->edev) == -EPROBE_DEFER)
> > +	charger->edev = extcon_get_extcon_dev("max8997-muic");
> > +	if (IS_ERR_OR_NULL(charger->edev)) {
> > +		if (!charger->edev)  
> 
> Isn't NULL returned when there is simply no extcon? It's different than
> deferred probe. Returning here EPROBE_DEFER might lead to infinite probe
> tries (on every new device probe) instead of just failing it.

extcon_get_extcon_dev() just loops through all registered extcon devices
and compared names. It will return NULL when "max8997-muic" isn't
registered yet. extcon_get_extcon_dev() never returns EPROBE_DEFER so
checking for NULL seems to be the only way. Other drivers using that
function also do NULL check and return EPROBE_DEFER.

Thanks for reviewing,
Timon


WARNING: multiple messages have this Message-ID (diff)
From: Timon Baetz <timon.baetz@protonmail.com>
To: Krzysztof Kozlowski <krzk@kernel.org>
Cc: devicetree@vger.kernel.org, linux-samsung-soc@vger.kernel.org,
	linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org,
	Rob Herring <robh+dt@kernel.org>,
	Liam Girdwood <lgirdwood@gmail.com>,
	Mark Brown <broonie@kernel.org>,
	Sebastian Reichel <sre@kernel.org>,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 3/3] power: supply: max8997_charger: Switch to new binding
Date: Mon, 01 Feb 2021 09:26:42 +0000	[thread overview]
Message-ID: <20210201083128.18499ffd.timon.baetz@protonmail.com> (raw)
In-Reply-To: <20210131172840.fxaadhhsafa4aeex@kozik-lap>

On Sun, 31 Jan 2021 18:28:40 +0100, Krzysztof Kozlowski wrote:
> On Sat, Jan 30, 2021 at 05:30:14PM +0000, Timon Baetz wrote:
> > Get regulator from parent device's node and extcon by name.
> >
> > Signed-off-by: Timon Baetz <timon.baetz@protonmail.com>
> > ---
> >  drivers/power/supply/max8997_charger.c | 12 ++++++++----
> >  1 file changed, 8 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/power/supply/max8997_charger.c b/drivers/power/supply/max8997_charger.c
> > index 321bd6b8ee41..625d8cc4312a 100644
> > --- a/drivers/power/supply/max8997_charger.c
> > +++ b/drivers/power/supply/max8997_charger.c
> > @@ -168,6 +168,7 @@ static int max8997_battery_probe(struct platform_device *pdev)
> >  	int ret = 0;
> >  	struct charger_data *charger;
> >  	struct max8997_dev *iodev = dev_get_drvdata(pdev->dev.parent);
> > +	struct device_node *np = pdev->dev.of_node;
> >  	struct i2c_client *i2c = iodev->i2c;
> >  	struct max8997_platform_data *pdata = iodev->pdata;
> >  	struct power_supply_config psy_cfg = {};
> > @@ -237,20 +238,23 @@ static int max8997_battery_probe(struct platform_device *pdev)
> >  		return PTR_ERR(charger->battery);
> >  	}
> >
> > +	// grab regulator from parent device's node
> > +	pdev->dev.of_node = iodev->dev->of_node;
> >  	charger->reg = devm_regulator_get_optional(&pdev->dev, "charger");
> > +	pdev->dev.of_node = np;  
> 
> I think the device does not have its own node anymore. Or did I miss
> something?

The idea is to reset of_node to whatever it was before (NULL) and basically 
leave the device unchanged. Probe might run again because of deferral.

> >  	if (IS_ERR(charger->reg)) {
> >  		if (PTR_ERR(charger->reg) == -EPROBE_DEFER)
> >  			return -EPROBE_DEFER;
> >  		dev_info(&pdev->dev, "couldn't get charger regulator\n");
> >  	}
> > -	charger->edev = extcon_get_edev_by_phandle(&pdev->dev, 0);
> > -	if (IS_ERR(charger->edev)) {
> > -		if (PTR_ERR(charger->edev) == -EPROBE_DEFER)
> > +	charger->edev = extcon_get_extcon_dev("max8997-muic");
> > +	if (IS_ERR_OR_NULL(charger->edev)) {
> > +		if (!charger->edev)  
> 
> Isn't NULL returned when there is simply no extcon? It's different than
> deferred probe. Returning here EPROBE_DEFER might lead to infinite probe
> tries (on every new device probe) instead of just failing it.

extcon_get_extcon_dev() just loops through all registered extcon devices
and compared names. It will return NULL when "max8997-muic" isn't
registered yet. extcon_get_extcon_dev() never returns EPROBE_DEFER so
checking for NULL seems to be the only way. Other drivers using that
function also do NULL check and return EPROBE_DEFER.

Thanks for reviewing,
Timon


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

  reply	other threads:[~2021-02-01  9:27 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-30 17:28 [PATCH 0/3] charger-supply for max8997_charger Timon Baetz
2021-01-30 17:28 ` Timon Baetz
2021-01-30 17:29 ` [PATCH 1/3] regulator: dt-bindings: Document charger-supply for max8997 Timon Baetz
2021-01-30 17:29   ` Timon Baetz
2021-01-31 16:46   ` Krzysztof Kozlowski
2021-01-30 17:29 ` [PATCH 2/3] ARM: dts: exynos: Add charger supply for I9100 Timon Baetz
2021-01-30 17:29   ` Timon Baetz
2021-02-11  5:59   ` Timon Baetz
2021-02-11  5:59     ` Timon Baetz
2021-02-11  7:39     ` Krzysztof Kozlowski
2021-02-11  7:39       ` Krzysztof Kozlowski
2021-03-02  8:52   ` Krzysztof Kozlowski
2021-03-02  8:52     ` Krzysztof Kozlowski
2021-01-30 17:30 ` [PATCH 3/3] power: supply: max8997_charger: Switch to new binding Timon Baetz
2021-01-30 17:30   ` Timon Baetz
2021-01-31 17:28   ` Krzysztof Kozlowski
2021-01-31 17:28     ` Krzysztof Kozlowski
2021-02-01  9:26     ` Timon Baetz [this message]
2021-02-01  9:26       ` Timon Baetz
2021-02-01 18:03       ` Krzysztof Kozlowski
2021-02-01 18:03         ` Krzysztof Kozlowski
2021-03-09  7:47         ` Timon Baetz
2021-03-09  7:47           ` Timon Baetz
2021-03-26 16:20   ` Timon Baetz
2021-03-26 16:20     ` Timon Baetz
2021-02-03 21:07 ` (subset) [PATCH 0/3] charger-supply for max8997_charger Mark Brown
2021-02-03 21:07   ` Mark Brown

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=20210201083128.18499ffd.timon.baetz@protonmail.com \
    --to=timon.baetz@protonmail.com \
    --cc=broonie@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=krzk@kernel.org \
    --cc=lgirdwood@gmail.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=linux-samsung-soc@vger.kernel.org \
    --cc=robh+dt@kernel.org \
    --cc=sre@kernel.org \
    /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.