From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id ABB33C64ED8 for ; Mon, 27 Feb 2023 13:07:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:From:MIME-Version:Message-ID:Subject:Cc :To:Date:Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References: List-Owner; bh=HphlG8D4zKZPVoXfJG46BC7GDRvYJY+cSAJpO/bmr54=; b=ij8P0wN7DYCIhW 2CJdqamieLBfX0jG076gZE/7gVRNLt6+Eu/waho1wpFZywqbepYe3FZj3vUMhC1v1VvImfNd2r/+Z +V3gq/b2T6ckU8iXYMC4amLtjLixIPA1tapAsa/9t82GRW2SV/b8DAHmHXFq/B0eJcqufEEVqNd+f 7mePj0E8ybVZl2tPWxMs0w6Cc8LxBhVabVqIoszODA35wFW9Q1nhhLLsYJlVK5mDScF7udI0i4Fto nJM2f3tLz6fjZVltn/enhSgwtqORsAy86u15eIxShMZVmxXUoTpip/zAjIuG0HeNK9DtMiS7wgBxp pe1b32ag7dB+b6/ug7Sg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1pWdCX-009g95-EG; Mon, 27 Feb 2023 13:05:57 +0000 Received: from metis.ext.pengutronix.de ([2001:67c:670:201:290:27ff:fe1d:cc33]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1pWdCT-009g7j-R9 for linux-arm-kernel@lists.infradead.org; Mon, 27 Feb 2023 13:05:55 +0000 Received: from ptx.hi.pengutronix.de ([2001:67c:670:100:1d::c0]) by metis.ext.pengutronix.de with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pWdCI-0006PM-PC; Mon, 27 Feb 2023 14:05:42 +0100 Received: from sha by ptx.hi.pengutronix.de with local (Exim 4.92) (envelope-from ) id 1pWdCI-0001VE-AZ; Mon, 27 Feb 2023 14:05:42 +0100 Date: Mon, 27 Feb 2023 14:05:42 +0100 To: linux-kernel@vger.kernel.org Cc: Mark Brown , Liam Girdwood , kernel@pengutronix.de, linux-arm-kernel@lists.infradead.org Subject: About regulator error events Message-ID: <20230227130542.GM32097@pengutronix.de> MIME-Version: 1.0 Content-Disposition: inline X-Sent-From: Pengutronix Hildesheim X-URL: http://www.pengutronix.de/ X-Accept-Language: de,en X-Accept-Content-Type: text/plain User-Agent: Mutt/1.10.1 (2018-07-13) From: Sascha Hauer X-SA-Exim-Connect-IP: 2001:67c:670:100:1d::c0 X-SA-Exim-Mail-From: sha@pengutronix.de X-SA-Exim-Scanned: No (on metis.ext.pengutronix.de); SAEximRunCond expanded to false X-PTX-Original-Recipient: linux-arm-kernel@lists.infradead.org X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230227_050553_901901_DEB62083 X-CRM114-Status: GOOD ( 20.78 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org I have a board here which has some current limited power switches on it and I wonder if I can do something reasonable with the error interrupt pins these switches have. The devices do not have a communication channel, instead they only have an enable pin and an error interrupt pin. See https://www.diodes.com/assets/Datasheets/AP22652_53_52A_53A.pdf for a datasheet. The devices come in two variants, one goes into current limiting mode in case of overcurrent and the other variant switches off until it gets re-enabled again. At first sight it seemed logical to me to wire up the error interrupt pins to REGULATOR_EVENT_OVER_CURRENT events. That was easy to do, but now the question is: What can a regulator consumer do with these events? The strategy I had in mind was to disable the regulator, enable it again to see if the errors persists and if it does, permanently disable the device. Disabling the regulator only works though when there's only one consumer. With multiple consumers only the enable count decreases, but the regulator itself stays enabled. This means implementing such a policy at the consumer side is not generally possible. Implementing a policy in the regulator core seems awkward as well, as a good strategy likely differs between different consumers. A first good step might be to notify the user somehow. While we can get the overcurrent status of a regulator from /sys/class/regulator/*/over_current there doesn't seem to be any way to get a regulator event in userspace, right? Would patches changing that be welcomed? There doesn't seem to be much prior art for handling regulator error events in the kernel. It would be great to get some input what others do in this situation, or to get some ideas what they would do if they had the time to do so ;) Sascha -- Pengutronix e.K. | | Steuerwalder Str. 21 | http://www.pengutronix.de/ | 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 | _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel