Re: [PATCH 3/3] power: supply: max8997_charger: Switch to new binding
From: Timon Baetz <hidden>
Date: 2021-02-01 09:27:35
Also in:
linux-devicetree, linux-pm, linux-samsung-soc, lkml
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:quoted
Get regulator from parent device's node and extcon by name. Signed-off-by: Timon Baetz <redacted> --- 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.
quoted
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