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
next prev parent 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: linkBe 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.