Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756162AbcLNO7p (ORCPT ); Wed, 14 Dec 2016 09:59:45 -0500 Received: from h1.radempa.de ([176.9.142.194]:45487 "EHLO mail.cosmopool.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755004AbcLNO7o (ORCPT ); Wed, 14 Dec 2016 09:59:44 -0500 X-Greylist: delayed 375 seconds by postgrey-1.27 at vger.kernel.org; Wed, 14 Dec 2016 09:59:44 EST From: Harald Geyer To: Liam Girdwood , Mark Brown cc: linux-kernel@vger.kernel.org Subject: Question about regulator API MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <1652.1481727174.1@stardust.g4.wien.funkfeuer.at> Date: Wed, 14 Dec 2016 15:52:54 +0100 Message-Id: Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1947 Lines: 42 Hi all! I have a quite complex situation with regulator consumers, which I'm not sure how to handle best. Suppose there is some quirky HW that after some random time crashes - i.e. it doesn't respond to requests anymore at all. The driver can detect this situation and the only way to fix it is to disable the supply for 2 seconds, then enable it again. Also after enabling the power supply the driver needs to wait 2 seconds before talking to the HW. Now the complicated part: The HW is some kind of sensor which often is used in an array of identical devices. To make the wiring simpler all these devices are attatched to the same supply (and maybe the same bus), however they are read independently and thus also are independent devices from the kernel POV. Thus the following constraints should be met: * When user space asks the driver to read a device, it needs to "claim" the supply and ensure that it has been up for at least 2 seconds before proceeding to read the HW. The supply would be "locked" enabled. (I think this is standard regulator API.) * When HW failure is detected, the driver needs to tell the supply to turn off for at least 2 seconds, wait for all other devices to release the supply so it can actually be turned off, then wait for the off period, then start over again. (This is easy only with getting the supply exclusively.) * It should be possible to read multiple devices quickly when everything is okay and working. (Having 6 2-second delays accumulate would be quite annoying.) (This won't work with exclusive supply usage.) * Optionally: If all devices are idle the supply would be enabled if short response time is desired, but disabled if power saving is desired. Can this somehow be solved with the existing API? If not, do you think it would be reasonable/possible to extend the API to cover situations like the one described above? Any help or hints are appreciated. TIA, Harald