Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756269AbcDGNZO (ORCPT ); Thu, 7 Apr 2016 09:25:14 -0400 Received: from mail-wm0-f54.google.com ([74.125.82.54]:38641 "EHLO mail-wm0-f54.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751862AbcDGNZL (ORCPT ); Thu, 7 Apr 2016 09:25:11 -0400 To: Mark Brown , Javier Martinez Canillas From: Martin Fuzzey Subject: Regulator: drivers that need to know their supply Cc: linux-kernel@vger.kernel.org Message-ID: <57065FB5.6040707@parkeon.com> Date: Thu, 7 Apr 2016 15:25:09 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1576 Lines: 56 Hi, I am working on a driver for the tps22993 load switch. This chip has configurable slew rates but no voltage setting (as it's just a switch). To implement the .enable_time() method I need the voltage (which is the supply's voltage). The problem is that, when my regulator is configured as always-on the supply is not known when .enable_time() is called from regulator_register() (it does work if the regulator is not always-on) This is similar to the problem fixed by 5e3ca2b349b1 regulator: Try to resolve regulators supplies on registration and the follow up deadlock fix. I tried adding a new function: struct regulator *rdev_get_supply(struct regulator_dev *rdev) { int rc; rc = regulator_resolve_supply(rdev); if (rc) return ERR_PTR(rc); return rdev->supply; } EXPORT_SYMBOL_GPL(rdev_get_supply); Unfortunately that doesn't work. First of all supply_name is not set at that point (since it is set in regulator_register() AFTER set_machine_constraints()) Even after swapping the call order in regulator_register() it still doesn't work for my configuration since the parent supply is probed later so rdev_get_supply() returns -EDEFER which just results in a warning message from _regulator_do_enable() when it propagates back from .enable_time() 3V3_LCD: enable_time() failed: -517 And even without that problem there is a risk of another deadlock since the driver callbacks are called from regulator_register() with the regulator_list mutex held in the always_on case. Any ideas how to do this? Regards, Martin