Message ID | 20231010085906.3440452-3-o.rempel@pengutronix.de |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:612c:2908:b0:403:3b70:6f57 with SMTP id ib8csp53727vqb; Tue, 10 Oct 2023 01:59:37 -0700 (PDT) X-Google-Smtp-Source: AGHT+IFprKHQnhoMiHWSINIGnUU3GUBJrsPluPKXsixjcu33f5TNVUPGEg2NuYoUAiL0DGWDg+tY X-Received: by 2002:a17:902:dacd:b0:1c7:54ee:c53c with SMTP id q13-20020a170902dacd00b001c754eec53cmr20612210plx.57.1696928377525; Tue, 10 Oct 2023 01:59:37 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1696928377; cv=none; d=google.com; s=arc-20160816; b=OgoJKto+5HNGk7dAS0DL/aVhCo//7ciZs4SVWtNmR+zLivN0+GMD7wwlvuN5V+s5PG 3sVaWoc2Jy+QB8pEM7kkWM0WPYLD2RMk+6yhrADvIX9PbYVwPQzeubIoOPdv3PGzKUdE lQ8Jq/PODSp7Faxu2vpoVSrb2ItWQv0LMytidlRKNmulUViDUx4vQKI7GysGvmEJW2EB l58DxitmWeuncwDqqhMpp0UeGfXKWLWVcqQgnQlqWET8jB/Ox4YdKHJbkOLGFJMnLOG/ G+cVvXPexJrt2iafFUNpHOYKKm8UsyvQSMbuFZ2ACeobKTiDG8YAtIFDtSis1FgjCwRw kTCQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from; bh=q8mv6Qa6LwhZF31RWqon3w9vah0lJH0nLKEsdWfhMvc=; fh=04ly7V1xWE1eBTBwtRUQiwjHX8ICozxkXNJpuSLZLOA=; b=nhbUHJkqIQoIhGJcAmic4Ru4+jGVIpcSMI6lPBkoBhdSyRb8FKNxkEaEocIxga+nbv fR+yoEXyEh2EiMn49+6RfDyuzA6Iz+Rq8onlMUhRErDIr8tv864ycIhH5uRxEETEif9N 0Q4YsnBtUppx4fwCkwbaY3m2FsBsMWjarxbZ59Htdyv38f0ZUoEY9jR/7Ird6544Wm7G 8eQQnX5pjMSLSWkkXstWMBdEI5FCJIYTLODk6V5MQc53EDSh/wcilImpdYDq1VvELTSc IsMLNk6TSBlZpd4KnJPMGx4k1tB+mWs5gyu8mxL2EroWi71/ZDXP8nzfwi7FdMFcK/ER G1sw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:5 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: from groat.vger.email (groat.vger.email. [2620:137:e000::3:5]) by mx.google.com with ESMTPS id lf15-20020a170902fb4f00b001bbc80a2a3asi10840861plb.299.2023.10.10.01.59.37 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 10 Oct 2023 01:59:37 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:5 as permitted sender) client-ip=2620:137:e000::3:5; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:5 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by groat.vger.email (Postfix) with ESMTP id 5E70180CFD18; Tue, 10 Oct 2023 01:59:35 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at groat.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229729AbjJJI7X (ORCPT <rfc822;rua109.linux@gmail.com> + 20 others); Tue, 10 Oct 2023 04:59:23 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42520 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229476AbjJJI7T (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Tue, 10 Oct 2023 04:59:19 -0400 Received: from metis.whiteo.stw.pengutronix.de (metis.whiteo.stw.pengutronix.de [IPv6:2a0a:edc0:2:b01:1d::104]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 1C5B1A4 for <linux-kernel@vger.kernel.org>; Tue, 10 Oct 2023 01:59:18 -0700 (PDT) Received: from drehscheibe.grey.stw.pengutronix.de ([2a0a:edc0:0:c01:1d::a2]) by metis.whiteo.stw.pengutronix.de with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <ore@pengutronix.de>) id 1qq8a4-00016X-Oc; Tue, 10 Oct 2023 10:59:08 +0200 Received: from [2a0a:edc0:0:1101:1d::ac] (helo=dude04.red.stw.pengutronix.de) by drehscheibe.grey.stw.pengutronix.de with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from <ore@pengutronix.de>) id 1qq8a3-000cTO-Tp; Tue, 10 Oct 2023 10:59:07 +0200 Received: from ore by dude04.red.stw.pengutronix.de with local (Exim 4.96) (envelope-from <ore@pengutronix.de>) id 1qq8a3-00ER24-2o; Tue, 10 Oct 2023 10:59:07 +0200 From: Oleksij Rempel <o.rempel@pengutronix.de> To: Liam Girdwood <lgirdwood@gmail.com>, Mark Brown <broonie@kernel.org>, Rob Herring <robh+dt@kernel.org>, Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>, Conor Dooley <conor+dt@kernel.org> Cc: Oleksij Rempel <o.rempel@pengutronix.de>, kernel@pengutronix.de, linux-kernel@vger.kernel.org, devicetree@vger.kernel.org Subject: [PATCH v1 3/3] regulator: fixed: forward under-voltage events Date: Tue, 10 Oct 2023 10:59:06 +0200 Message-Id: <20231010085906.3440452-3-o.rempel@pengutronix.de> X-Mailer: git-send-email 2.39.2 In-Reply-To: <20231010085906.3440452-1-o.rempel@pengutronix.de> References: <20231010085906.3440452-1-o.rempel@pengutronix.de> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-SA-Exim-Connect-IP: 2a0a:edc0:0:c01:1d::a2 X-SA-Exim-Mail-From: ore@pengutronix.de X-SA-Exim-Scanned: No (on metis.whiteo.stw.pengutronix.de); SAEximRunCond expanded to false X-PTX-Original-Recipient: linux-kernel@vger.kernel.org X-Spam-Status: No, score=2.8 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_SBL_CSS,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on groat.vger.email Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (groat.vger.email [0.0.0.0]); Tue, 10 Oct 2023 01:59:35 -0700 (PDT) X-Spam-Level: ** X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1779358370728538053 X-GMAIL-MSGID: 1779358370728538053 |
Series |
[v1,1/3] regulator: dt-bindings: fixed-regulator: Add under-voltage interrupt support
|
|
Commit Message
Oleksij Rempel
Oct. 10, 2023, 8:59 a.m. UTC
Add handler to forward under-voltage events.
On systems for more or less complicated regulator chains we need to
forward under-voltage events to actual driver which need to react on
them.
Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
---
drivers/regulator/fixed.c | 36 +++++++++++++++++++++++++++++++++++-
1 file changed, 35 insertions(+), 1 deletion(-)
Comments
On Tue, Oct 10, 2023 at 10:59:06AM +0200, Oleksij Rempel wrote: > Add handler to forward under-voltage events. > On systems for more or less complicated regulator chains we need to > forward under-voltage events to actual driver which need to react on > them. It isn't clear to me why this would be implemented in one specific driver, nor why this would be done unconditionally. Could you provide some information on the problem you're trying to solve here? This feels like something that should be a core feature. > +static int reg_fixed_regulator_notifier(struct notifier_block *nb, > + unsigned long event, void *data) > +{ > + struct fixed_voltage_data *priv = > + container_of(nb, struct fixed_voltage_data, nb); > + struct regulator_dev *rdev = priv->dev; > + > + if (event != REGULATOR_EVENT_UNDER_VOLTAGE_WARN && > + event != REGULATOR_EVENT_UNDER_VOLTAGE) > + return NOTIFY_OK; > + > + regulator_notifier_call_chain(rdev, event, NULL); This would be better written as a switch statement for extensibility, and it's not clear why the filtering?
Hi, On Tue, Oct 10, 2023 at 01:19:36PM +0100, Mark Brown wrote: > On Tue, Oct 10, 2023 at 10:59:06AM +0200, Oleksij Rempel wrote: > > Add handler to forward under-voltage events. > > On systems for more or less complicated regulator chains we need to > > forward under-voltage events to actual driver which need to react on > > them. > > It isn't clear to me why this would be implemented in one specific > driver, nor why this would be done unconditionally. Could you provide > some information on the problem you're trying to solve here? The hardware I am working with has an under-voltage sensor on the 24V supply regulator and some backup capacitors to run SoC for 100ms. I want to forward under-voltage events across a chain of different regulators to a designated consumer. For instance, to the mmc driver, enabling it to initiate shutdown before power loss occurs. Additionally, a bit can be set in the volatile memory of a scratch pad in an RTC clock to record sudden power loss, which can be checked on the next system start. > This feels like something that should be a core feature. Agreed. I am relatively new to the regulator framework and am uncertain about the optimal location for registering the event forwarding. Could you advise on this? > > +static int reg_fixed_regulator_notifier(struct notifier_block *nb, > > + unsigned long event, void *data) > > +{ > > + struct fixed_voltage_data *priv = > > + container_of(nb, struct fixed_voltage_data, nb); > > + struct regulator_dev *rdev = priv->dev; > > + > > + if (event != REGULATOR_EVENT_UNDER_VOLTAGE_WARN && > > + event != REGULATOR_EVENT_UNDER_VOLTAGE) > > + return NOTIFY_OK; > > + > > + regulator_notifier_call_chain(rdev, event, NULL); > > This would be better written as a switch statement for extensibility, ack. > and it's not clear why the filtering? I started with a conservative approach because I'm not sure about the possible effects of forwarding all events. If forwarding all events is a good idea, I can do it. Regards, Oleksij
On Tue, Oct 10, 2023 at 02:55:31PM +0200, Oleksij Rempel wrote: > Hi, > > On Tue, Oct 10, 2023 at 01:19:36PM +0100, Mark Brown wrote: > > On Tue, Oct 10, 2023 at 10:59:06AM +0200, Oleksij Rempel wrote: > > > Add handler to forward under-voltage events. > > > On systems for more or less complicated regulator chains we need to > > > forward under-voltage events to actual driver which need to react on > > > them. > > > > It isn't clear to me why this would be implemented in one specific > > driver, nor why this would be done unconditionally. Could you provide > > some information on the problem you're trying to solve here? > > The hardware I am working with has an under-voltage sensor on the 24V > supply regulator and some backup capacitors to run SoC for 100ms. I want > to forward under-voltage events across a chain of different regulators > to a designated consumer. For instance, to the mmc driver, enabling it > to initiate shutdown before power loss occurs. Additionally, a bit can > be set in the volatile memory of a scratch pad in an RTC clock to record > sudden power loss, which can be checked on the next system start. The bit picture of my HW may potentially be even more advanced: - some regulator chain paths are disabled by the HW. With other words under-voltage event is converted to fail or disable. There is nothing what software can do, but it will be good to reflect it on the SW side for diagnostic. - some paths can be disabled by software to get some more milliseconds of life and complete emergency shutdown task.
On Tue, Oct 10, 2023 at 02:55:31PM +0200, Oleksij Rempel wrote: > The hardware I am working with has an under-voltage sensor on the 24V > supply regulator and some backup capacitors to run SoC for 100ms. I want > to forward under-voltage events across a chain of different regulators > to a designated consumer. For instance, to the mmc driver, enabling it > to initiate shutdown before power loss occurs. Additionally, a bit can > be set in the volatile memory of a scratch pad in an RTC clock to record > sudden power loss, which can be checked on the next system start. So it sounds like the underlying need is to flag the notifications from one of the regulators as being system wide and then take action based on those notifications somewhere basically disconnected? That does seem like a good use case. The MMC doesn't specifically care that it is handling a regulator notification, it more wants to know that the system is dying and doesn't really care how we figured that out so if we can hook it into a system level notificaiton it'd be happy and would also be able to handle other critical faults. I would have thought that we should have some mechanisms for this already for RAS type stuff but I'm drawing a blank on what it actually is if there is an existing abstraction. It could potentially go through userspace though there's latency concerns there which might not be ideal, there should at least be some policy for userspace. For the regulator itself we probably want a way to identify regulators as being system critical so they start notifying. It would be tempting to just do that by default but that would likely cause some issues for example with regulators for things like SD cards which are more likely to get hardware problems that don't comprimise the entire system. We could do that with DT, either a property or some sort of runtime consumer, but it might be better to have a control in sysfs that userspace can turn on? OTOH the ability do something about this depends on specific hardware design... I've copied in Sebastian since this sounds like the sort of thing that power supplies might have some kind of handling for, or at least if we need to add something we should make it so that the power supplies can be joined up to it. I do see temperature and capacity alerts in the sysfs ABI for power supplies, but nothing for voltage. I've also coped in Naresh and Zev who've been discussing something vaugely similar with userspace notifications for the userspace consumer - it's not the same thing given that you don't specifically need userspace to be involved here but it feels like it might have something of a similar shape, or at least there might be some shared interest.
On Tue, Oct 10, 2023 at 06:19:59PM +0100, Mark Brown wrote: > On Tue, Oct 10, 2023 at 02:55:31PM +0200, Oleksij Rempel wrote: > > > The hardware I am working with has an under-voltage sensor on the 24V > > supply regulator and some backup capacitors to run SoC for 100ms. I want > > to forward under-voltage events across a chain of different regulators > > to a designated consumer. For instance, to the mmc driver, enabling it > > to initiate shutdown before power loss occurs. Additionally, a bit can > > be set in the volatile memory of a scratch pad in an RTC clock to record > > sudden power loss, which can be checked on the next system start. > > So it sounds like the underlying need is to flag the notifications from > one of the regulators as being system wide and then take action based on > those notifications somewhere basically disconnected? That does seem > like a good use case. > > The MMC doesn't specifically care that it is handling a regulator > notification, it more wants to know that the system is dying and doesn't > really care how we figured that out so if we can hook it into a system > level notificaiton it'd be happy and would also be able to handle other > critical faults. I would have thought that we should have some > mechanisms for this already for RAS type stuff but I'm drawing a blank > on what it actually is if there is an existing abstraction. It could > potentially go through userspace though there's latency concerns there > which might not be ideal, there should at least be some policy for > userspace. The project I'm working prefers reducing user space daemons to configure and enforce RAS policies due to time and financial budget constraints. The customer is inclined to invest only in essential infrastructure. Configuration through the device tree and kernel defaults is preferable. For instance, having a default kernel governor that doesn’t require user space configuration aligns with the project’s objectives. While a proper UAPI might not be implemented in the first run, the design will allow for it to be added and extended by other projects in the future. > For the regulator itself we probably want a way to identify regulators > as being system critical so they start notifying. It would be tempting > to just do that by default but that would likely cause some issues for > example with regulators for things like SD cards which are more likely > to get hardware problems that don't comprimise the entire system. We > could do that with DT, either a property or some sort of runtime > consumer, but it might be better to have a control in sysfs that > userspace can turn on? OTOH the ability do something about this depends > on specific hardware design... > > I've copied in Sebastian since this sounds like the sort of thing that > power supplies might have some kind of handling for, or at least if we > need to add something we should make it so that the power supplies can > be joined up to it. I do see temperature and capacity alerts in the > sysfs ABI for power supplies, but nothing for voltage. Thank you for pointing towards the power supply framework. Given the hardware design of my project, I can envision mapping the following states and properties within this framework: 1. States: - POWER_SUPPLY_STATUS_FULL: When the capacitor is fully charged. - POWER_SUPPLY_STATUS_DISCHARGING: Triggered when an under-voltage event is detected. 2. Technology: - POWER_SUPPLY_TECHNOLOGY_CAPACITOR 3. Capacity Level: - Post under-voltage detection, the system would immediately transition to POWER_SUPPLY_CAPACITY_LEVEL_CRITICAL state. 4. Properties: - POWER_SUPPLY_PROP_TIME_TO_EMPTY_NOW: 100ms, representing the time until complete power loss. - POWER_SUPPLY_TYPE_MAINS: Under normal operation. - POWER_SUPPLY_TYPE_BATTERY: Triggered when under-voltage is detected. Considering the above mapping, my initial step would be to create a simple regulator coupled (if regulator is still needed in this casr) with a Device Tree (DT) based power supply driver. This setup would align with the existing power supply framework, with a notable extension being the system-wide notification for emergency shutdown upon under-voltage detection. > I've also coped in Naresh and Zev who've been discussing something > vaugely similar with userspace notifications for the userspace consumer > - it's not the same thing given that you don't specifically need > userspace to be involved here but it feels like it might have something > of a similar shape, or at least there might be some shared interest. Regards, Oleksij
On Wed, Oct 11, 2023 at 09:59:31AM +0200, Oleksij Rempel wrote: > Configuration through the device tree and kernel defaults is preferable. > For instance, having a default kernel governor that doesn’t require user > space configuration aligns with the project’s objectives. That's policy though... > > > For the regulator itself we probably want a way to identify regulators > > as being system critical so they start notifying. It would be tempting > > to just do that by default but that would likely cause some issues for > > example with regulators for things like SD cards which are more likely > > to get hardware problems that don't comprimise the entire system. We > > could do that with DT, either a property or some sort of runtime > > consumer, but it might be better to have a control in sysfs that > > userspace can turn on? OTOH the ability do something about this depends > > on specific hardware design... > > > > I've copied in Sebastian since this sounds like the sort of thing that > > power supplies might have some kind of handling for, or at least if we > > need to add something we should make it so that the power supplies can > > be joined up to it. I do see temperature and capacity alerts in the > > sysfs ABI for power supplies, but nothing for voltage. > > Thank you for pointing towards the power supply framework. Given the hardware > design of my project, I can envision mapping the following states and > properties within this framework: There's also hw_failure_emergency_poweroff() which looks like exactly what you're trying to trigger here. > Considering the above mapping, my initial step would be to create a simple > regulator coupled (if regulator is still needed in this casr) with a Device > Tree (DT) based power supply driver. This setup would align with the existing > power supply framework, with a notable extension being the system-wide > notification for emergency shutdown upon under-voltage detection. It sounds like this is actually a regulator regardless of if it also appears via some other API.
On Wed, Oct 11, 2023 at 12:38:19PM +0100, Mark Brown wrote: > On Wed, Oct 11, 2023 at 09:59:31AM +0200, Oleksij Rempel wrote: > > > Configuration through the device tree and kernel defaults is preferable. > > For instance, having a default kernel governor that doesn’t require user > > space configuration aligns with the project’s objectives. > > That's policy though... > > > > > > For the regulator itself we probably want a way to identify regulators > > > as being system critical so they start notifying. It would be tempting Can the "criticality" could be determined by the severity (ERROR vs WARNING)? > > > to just do that by default but that would likely cause some issues for > > > example with regulators for things like SD cards which are more likely > > > to get hardware problems that don't comprimise the entire system. We "comprimise the entire system" sounds (to my ears) exactly the difference between WARNING and ERROR notifications. > > > could do that with DT, either a property or some sort of runtime > > > consumer, but it might be better to have a control in sysfs that > > > userspace can turn on? OTOH the ability do something about this depends > > > on specific hardware design... > > > > > > I've copied in Sebastian since this sounds like the sort of thing that > > > power supplies might have some kind of handling for, or at least if we > > > need to add something we should make it so that the power supplies can > > > be joined up to it. I do see temperature and capacity alerts in the > > > sysfs ABI for power supplies, but nothing for voltage. > > > > Thank you for pointing towards the power supply framework. Given the hardware > > design of my project, I can envision mapping the following states and > > properties within this framework: > > There's also hw_failure_emergency_poweroff() which looks like exactly > what you're trying to trigger here. There is already a path from regulator notification handling to the hw_failure_emergency_poweroff() - although only when handling the IRQs fail and this failure is marked as fatal. > > Considering the above mapping, my initial step would be to create a simple > > regulator coupled (if regulator is still needed in this casr) with a Device > > Tree (DT) based power supply driver. This setup would align with the existing > > power supply framework, with a notable extension being the system-wide > > notification for emergency shutdown upon under-voltage detection. > > It sounds like this is actually a regulator regardless of if it also > appears via some other API. I wonder if it would make sense to add a 'protector' in regulator core. The 'protector' could register to listen the notifications from those regulators which have some 'regulator-fatal-notifications = <list of notifications>;' -property defined in device-tree. In my eyes the device-tree is correct place for this information because whether an "anomaly" in regulator output compromises the system is a property of hardware. Yours, -- Matti
On Thu, Oct 12, 2023 at 10:08:40AM +0300, Matti Vaittinen wrote: > In my eyes the device-tree is correct place for this information > because whether an "anomaly" in regulator output compromises the system > is a property of hardware. Yes, it's mainly the handling that has a policy element.
Hi, On Wed, Oct 11, 2023 at 09:59:31AM +0200, Oleksij Rempel wrote: > On Tue, Oct 10, 2023 at 06:19:59PM +0100, Mark Brown wrote: > > On Tue, Oct 10, 2023 at 02:55:31PM +0200, Oleksij Rempel wrote: > > > The hardware I am working with has an under-voltage sensor on the 24V > > > supply regulator and some backup capacitors to run SoC for 100ms. I want > > > to forward under-voltage events across a chain of different regulators > > > to a designated consumer. For instance, to the mmc driver, enabling it > > > to initiate shutdown before power loss occurs. Additionally, a bit can > > > be set in the volatile memory of a scratch pad in an RTC clock to record > > > sudden power loss, which can be checked on the next system start. > > > > So it sounds like the underlying need is to flag the notifications from > > one of the regulators as being system wide and then take action based on > > those notifications somewhere basically disconnected? That does seem > > like a good use case. > > > > The MMC doesn't specifically care that it is handling a regulator > > notification, it more wants to know that the system is dying and doesn't > > really care how we figured that out so if we can hook it into a system > > level notificaiton it'd be happy and would also be able to handle other > > critical faults. I would have thought that we should have some > > mechanisms for this already for RAS type stuff but I'm drawing a blank > > on what it actually is if there is an existing abstraction. It could > > potentially go through userspace though there's latency concerns there > > which might not be ideal, there should at least be some policy for > > userspace. > > The project I'm working prefers reducing user space daemons to configure and > enforce RAS policies due to time and financial budget constraints. The customer > is inclined to invest only in essential infrastructure. > > Configuration through the device tree and kernel defaults is preferable. > For instance, having a default kernel governor that doesn’t require user > space configuration aligns with the project’s objectives. > > While a proper UAPI might not be implemented in the first run, the > design will allow for it to be added and extended by other projects in > the future. > > > For the regulator itself we probably want a way to identify regulators > > as being system critical so they start notifying. It would be tempting > > to just do that by default but that would likely cause some issues for > > example with regulators for things like SD cards which are more likely > > to get hardware problems that don't comprimise the entire system. We > > could do that with DT, either a property or some sort of runtime > > consumer, but it might be better to have a control in sysfs that > > userspace can turn on? OTOH the ability do something about this depends > > on specific hardware design... > > > > I've copied in Sebastian since this sounds like the sort of thing that > > power supplies might have some kind of handling for, or at least if we > > need to add something we should make it so that the power supplies can > > be joined up to it. I do see temperature and capacity alerts in the > > sysfs ABI for power supplies, but nothing for voltage. > > Thank you for pointing towards the power supply framework. Given the hardware > design of my project, I can envision mapping the following states and > properties within this framework: > > 1. States: > - POWER_SUPPLY_STATUS_FULL: When the capacitor is fully charged. > - POWER_SUPPLY_STATUS_DISCHARGING: Triggered when an under-voltage event is > detected. > > 2. Technology: > - POWER_SUPPLY_TECHNOLOGY_CAPACITOR > > 3. Capacity Level: > - Post under-voltage detection, the system would immediately transition to > POWER_SUPPLY_CAPACITY_LEVEL_CRITICAL state. > > 4. Properties: > - POWER_SUPPLY_PROP_TIME_TO_EMPTY_NOW: 100ms, representing the time until > complete power loss. > - POWER_SUPPLY_TYPE_MAINS: Under normal operation. > - POWER_SUPPLY_TYPE_BATTERY: Triggered when under-voltage is detected. I don't know if power-supply is the best fit for this, but if you continue on this path: POWER_SUPPLY_TYPE is supposed to be fixed. You either have a battery or a charger. If you want to go the power-supply way, you need two devices: One POWER_SUPPLY_TYPE_MAINS for the regulator charging the capacitor and one POWER_SUPPLY_TYPE_BATTERY for the capacitor. The MAINS device is important to keep power_supply_is_system_supplied() working as expected. Note, that there is no generic solution how to handle critical battery events in the power-supply framework at the moment. On Laptops userspace handles early poweroff based on the information supplied by the kernel. Right now there is one phone battery driver doing 'orderly_poweroff(true)' on critical battery state. That's about it. Greetings, -- Sebastian
diff --git a/drivers/regulator/fixed.c b/drivers/regulator/fixed.c index 493dd244e4f4..99d37f1ebbc9 100644 --- a/drivers/regulator/fixed.c +++ b/drivers/regulator/fixed.c @@ -33,6 +33,7 @@ struct fixed_voltage_data { struct regulator_desc desc; struct regulator_dev *dev; + struct notifier_block nb; struct clk *enable_clock; unsigned int enable_counter; @@ -105,6 +106,39 @@ static int reg_is_enabled(struct regulator_dev *rdev) return priv->enable_counter > 0; } +static int reg_fixed_regulator_notifier(struct notifier_block *nb, + unsigned long event, void *data) +{ + struct fixed_voltage_data *priv = + container_of(nb, struct fixed_voltage_data, nb); + struct regulator_dev *rdev = priv->dev; + + if (event != REGULATOR_EVENT_UNDER_VOLTAGE_WARN && + event != REGULATOR_EVENT_UNDER_VOLTAGE) + return NOTIFY_OK; + + regulator_notifier_call_chain(rdev, event, NULL); + + return NOTIFY_OK; +} + +static int reg_fixed_register_reg_notifier(struct fixed_voltage_data *priv, + struct device *dev) +{ + struct regulator_dev *rdev = priv->dev; + int ret; + + if (!rdev->supply) + return 0; + + priv->nb.notifier_call = reg_fixed_regulator_notifier; + ret = devm_regulator_register_notifier(rdev->supply, &priv->nb); + if (ret) + return dev_err_probe(dev, ret, "Failed to register notifier\n"); + + return 0; +} + static irqreturn_t reg_fixed_under_voltage_irq_handler(int irq, void *data) { struct fixed_voltage_data *priv = data; @@ -327,7 +361,7 @@ static int reg_fixed_voltage_probe(struct platform_device *pdev) if (ret) return ret; - return 0; + return reg_fixed_register_reg_notifier(drvdata, dev); } #if defined(CONFIG_OF)