From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f52.google.com (mail-wr1-f52.google.com [209.85.221.52]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 92941377560 for ; Thu, 30 Apr 2026 06:44:43 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.52 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777531485; cv=none; b=sxF0iQuYOadxbiHvdNdOAvlHwXwWrv3yWe26v+PnWkk/j38Zp0i97/hvm5GgCkSxA+jDU/CMCSeNTPBJ9xW334g/+xhakb7WStb3pVR32S3Lfd2ZGMprbU0qWwG/TwSYwthg3/wDqSQjuX+c52VQw0mtugFJjM+vGPXvRVUKOFY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777531485; c=relaxed/simple; bh=6vkSjfsaUvn4HoxFZ3Gd5gtDl6IUXlY9Myy1Q7YZwLM=; h=Mime-Version:Content-Type:Date:Message-Id:To:Cc:Subject:From: References:In-Reply-To; b=Ck80ci/GlOb27Cm2p6HqlRYrXCy0LcB7f1NmI3Loknc5twbYAWKDytiRD739OCoOq1qiFLNKMGdaWCd7PZBqml8QO5mlem+yF3RYpK581Omk99c5tQpDtlidNo1Wd28FESio3/WeC6ZDJqNtk/a/hRnJibWU/XkNnmhEFiOkzs8= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=fairphone.com; spf=pass smtp.mailfrom=fairphone.com; dkim=pass (2048-bit key) header.d=fairphone.com header.i=@fairphone.com header.b=l/4K0inN; arc=none smtp.client-ip=209.85.221.52 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=fairphone.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=fairphone.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=fairphone.com header.i=@fairphone.com header.b="l/4K0inN" Received: by mail-wr1-f52.google.com with SMTP id ffacd0b85a97d-43cf8d550bdso468561f8f.0 for ; Wed, 29 Apr 2026 23:44:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fairphone.com; s=fair; t=1777531482; x=1778136282; darn=vger.kernel.org; h=in-reply-to:references:from:subject:cc:to:message-id:date :content-transfer-encoding:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=xB7hE4S8UQ/5V2vbPQugzj+D4yHDlkwUFtbgwiN5BoQ=; b=l/4K0inNOTJzIBb7fhVkKYyw9E2KkLs2P82LHCdoE0Mo4HPxwlZ+Zmi3eSejnxVxYW t5L5PzYPYamkgaV+0gy2+3r8LyvEiA6LUN3xNOh4cw+XtY61/lmPPQQEtG+GWrfwOP5K NRVZu/GYdBAFr38bmm0hxZovXxlC7dQf6b6GK0HAXo1Ojv50/eYU1NEtllmDS2ozMfni Fgqr30wrfyL7obw4lBGDIebmWtqe8/2VW5WSqprZD1iBtJLYMD5QjkbcNsihGh/16LPo QX48gO/dMjwMyu9AfreGKEj8i0W8wiKisJ3pfX5q7GlHvfgDrNNjtyK51NNI9s/P31df qAJQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1777531482; x=1778136282; h=in-reply-to:references:from:subject:cc:to:message-id:date :content-transfer-encoding:mime-version:x-gm-gg:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=xB7hE4S8UQ/5V2vbPQugzj+D4yHDlkwUFtbgwiN5BoQ=; b=RdIWVBYBMsjwivtecAfC2RyT0JC+u4FL0GbLs9+YBx5zwifBtMQ5DA03aQeoMua5Fd O5QLLflj5ZBuKFNTK/ciei9mh8NeHWsQa1iyrSIcGgaNySCusl4gMCfs1/vLaZ3rVow9 zn7xURNGaLaJh3FnRVR8h3xzrJ6bcpboRULQ/znc5361LFGqvFnj6r6gNZ22XyXePUcm sdI0G2zui2vdqfpSQ5jPrzeCDrH8nus7rrXwXHa73R9kJ9wjocTA2WcIAPXkeAiKeEqR BVzR9ZZC5XMjkjx/k5PuXOQl13vuhZTg8O7dv+8dFyI5/m3wUf2zzw21UDieRk0IN+nT ZTcg== X-Forwarded-Encrypted: i=1; AFNElJ/3NfY3uBnZyYsVkmWAdWKBVK4U0Ue4Ivkdm8KWpKfdwg1QT7X0PRBEZ7G+BP7BepnRbI7Q/kgCrvT2nek=@vger.kernel.org X-Gm-Message-State: AOJu0YwYeZjjB1IAMJ/UTIWQt1hT2bPAkpfSo7oP+gCSFF1qqPuHsEyu zPoecMoVPu15Hyj6JCENNEDhOoS5Tw4gFYoimCZ4uSBbzXTaLx+ZNsfXRsoYr4mcC/g= X-Gm-Gg: AeBDieu7SHW+E9oP/PO4tuanO1uUuGlY6AL2wLEqUTYhMIQNDl49H9nPkNPENhgx+2c PMtH5cuObASK2T07cAWWGUd/6YckjSf4GrL4+84ScM7M2dBHVi0LdIMSH2UCirLejFLnebTbbzl n90CtR9wS1CLWRdVUNbs4P14zVioGgwGogf2EV2Ap315LFhAOMUdc6U9xdja4oaY59JDVrKTIDu qNPRTxGqN4p6kwAcGUwOTmXFBoYL9h2vMptQH6qbrJmye9N3/Mavk8i2a6/XcaKlsxA4bH1N0ox jxyUYjUfzl0VBSapl2+wU0bVp5zhm5ne/O3ii2eXfMEN/5CqTT3ZpOOC3OUmJQiBUt4+K276h1m caGsfVZRqzbGmUxsgEvU127KNgTJqLWy7BNR4SfPG9Uzma73sZzH6Nrsb1FXivJqN7jWx6H2HLY QRO2PuqqdtaJsTQcLL99GtOHfBB58K0z0112lanzzg7jRk9Ppu+DLufPVM4lCx6SJkTQ8ue9n1O VsqnqSwXQ== X-Received: by 2002:a05:6000:288d:b0:43c:fde7:f1 with SMTP id ffacd0b85a97d-4493e0c3deemr2283159f8f.18.1777531481727; Wed, 29 Apr 2026 23:44:41 -0700 (PDT) Received: from localhost (046124200255.public.t-mobile.at. [46.124.200.255]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-447b72176fesm10227827f8f.17.2026.04.29.23.44.40 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 29 Apr 2026 23:44:41 -0700 (PDT) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Date: Thu, 30 Apr 2026 08:44:40 +0200 Message-Id: To: "Mark Brown" , "Luca Weiss" Cc: "Liam Girdwood" , , "Griffin Kroah-Hartman" Subject: Re: Unexpected behavior of of_regulator_get()? From: "Luca Weiss" X-Mailer: aerc 0.21.0-0-g5549850facc2 References: In-Reply-To: Hi Mark, Thanks for your reply. On Thu Apr 30, 2026 at 2:10 AM CEST, Mark Brown wrote: > On Wed, Apr 29, 2026 at 10:18:31AM +0200, Luca Weiss wrote: > >> In a simplified version, we have this devicetree structure: >>=20 >> gpio-keys { >> compatible =3D "gpio-keys"; >>=20 >> event-hall-sensor { >> label =3D "Hall Effect Sensor"; >> vdd-supply =3D <&vreg_l10b>; >> }; > > I don't understand what this is supposed to describe. gpio-keys is in my understanding a sort of generic nodes where you describe different GPIOs that should create an input event. Like the Volume up button, or a switch on the device. Additionally many devices have a hall sensor (a.k.a flip cover sensor) which can detect whether a magnet in a flip case is essentially touching the device - therefore the screen should turn off. Such hall effect sensor requires power, so the IC has a VDD/VCC pin which needs to be powered, in order for the GPIO of the IC to trigger, and that Linux can create an input event from it. So far this was mostly described in devicetree using regulator-always-on because the devicetree bindings & driver did not support that. The patch series that's being worked on is supposed to implement that. Obviously since it hasn't been posted yet, it doesn't have an ack from the dt binding maintainers but I assume it shouldn't be too controversial. >> Looking through the code this seems to be caused by of_get_regulator() >> first doing of_parse_phandle(node, prop_name, 0) which is checking on >> the node itself. > >> But then if this does not succeed, it calls >> of_get_child_regulator(dev->of_node, prop_name) which goes through every >> child node of the top-level device (gpio-keys) until it finds a >> regulator. So this will find the vdd-supply of event-hall-sensor even >> for key-volume-up and switch. > > Why does this single device have multiple distinct supplies going into > it all called "SUPPLY"? That doesn't seem like the sort of thing that > happens in system designs. I would not expect to see multiple distinct > supplies with the same name going into the same device. gpio-keys is not really a single device, while you could create multiple different instances of gpio-keys for different keys: gpio-keys-a { compatible =3D "gpio-keys"; key-a { // ... }; }; gpio-keys-b { compatible =3D "gpio-keys"; key-b { // ... }; }; Usually they are just put into one gpio-keys node, which describe separate keys as subnodes. There's devm_regulator_get_optional() which gets a regulator for a given device (on the gpio-keys level), and my expectation of of_regulator_get() was that you point it at a devicetree node (e.g. the event-hall-sensor subnode and it grabs the regulator from that node, not from the parent (gpio-keys), nor from a different subnode of gpio-keys. >> A workaround from the driver side would be to check for the presence of >> vdd-supply on the child (fwnode_property_present(child, "vdd-supply")) >> before trying to get a regulator but I feel like resolving this in the >> regulator core would be the better solution? > > I think we need to take a step back here and look at what the binding is > supposed to describe and what it is trying to accomplish. =20 Is it clearer now? Regards Luca