Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751875AbdHGPmx (ORCPT ); Mon, 7 Aug 2017 11:42:53 -0400 Received: from mezzanine.sirena.org.uk ([106.187.55.193]:43980 "EHLO mezzanine.sirena.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751398AbdHGPmv (ORCPT ); Mon, 7 Aug 2017 11:42:51 -0400 Date: Mon, 7 Aug 2017 16:41:52 +0100 From: Mark Brown To: Hans de Goede Cc: Guenter Roeck , Darren Hart , Andy Shevchenko , Wolfram Sang , Sebastian Reichel , Greg Kroah-Hartman , Heikki Krogerus , Liam Girdwood , platform-driver-x86@vger.kernel.org, linux-kernel@vger.kernel.org, linux-i2c@vger.kernel.org, Liam Breck , Tony Lindgren , linux-pm@vger.kernel.org, devel@driverdev.osuosl.org Message-ID: <20170807154152.wt5b4y3s3oe4cnam@sirena.org.uk> References: <20170806123555.5124-1-hdegoede@redhat.com> <20170806123555.5124-11-hdegoede@redhat.com> <2d04e538-0594-0073-939e-feb6c1a66cdf@roeck-us.net> <85c668d5-c6f0-a94c-4dd5-1b425cdff339@redhat.com> <20170807111054.4lp5rgc5vpnsmhim@sirena.org.uk> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="3xhp6eecqwa65oob" Content-Disposition: inline In-Reply-To: X-Cookie: Did I say 2? I lied. User-Agent: NeoMutt/20170609 (1.8.3) X-SA-Exim-Connect-IP: 2001:470:1f1d:6b5::3 X-SA-Exim-Mail-From: broonie@sirena.org.uk Subject: Re: [PATCH 10/18] staging: typec: fusb302: Add support for fcs,vbus-regulator-name device-property X-SA-Exim-Version: 4.2.1 (built Tue, 02 Aug 2016 21:08:31 +0000) X-SA-Exim-Scanned: No (on mezzanine.sirena.org.uk); Unknown failure Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2270 Lines: 60 --3xhp6eecqwa65oob Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Mon, Aug 07, 2017 at 04:41:18PM +0200, Hans de Goede wrote: > On 07-08-17 13:10, Mark Brown wrote: > Problem 1) > The regulator in question is part of the bq24292i charger-IC attached to > a private i2c bus between the PMIC and the charger. The driver for the i2c > controller inside the PMIC which drivers this bus currently also instantiates > the i2c-client for the charger: ... > Note that the bq24190 driver is a generic driver, so to pass the > board specific regulator_init_data to it I would need to somehow > pass it here, but I don't see how, except by storing a pointer to > it in an u64 device-property which seems like a bad idea I2C has a perfectly good platform_data pointer in the board info for this stuff. > Problem 2) > Even if I could add the mapping through regulator_init_data > then it may well be too late, if the regulator_get happens > before the bq24190 driver registers its regulator (and thus > the mapping) the regulator_get for it may have already > happened and returned a dummy-regulator, or another regulator > with the rather generic vbus name. If you don't have control over the instantiation ordering but you have a firmware which claims to provide a complete description of regulators then you'd need to add an interface that allows mappings to be registered separately to regulator registration. Whatever you're doing the answer isn't to try to specify the name of the supply through some firmware binding, that's just obviously not sensible both in terms of a firmware abstraction and in terms of how the abstractions in Linux work. --3xhp6eecqwa65oob Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAABCAAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAlmIij8ACgkQJNaLcl1U h9BNuwf+PWkLyNaHfN0NiBNfczWsNCL6qAEBsD7KWz+h8eroBWBoJhiS87B3uxwO dGzmtkpKFY/KcrvjNKmCD4lHJV3D9N9KPxfhQV69q4rWaMyfgelMyUudwvwOpgGL Vs0e8qxdwtCtnzZdg8dSS7tVMdxBqnnPMRFevlLRFHezriCKbCLT0ckw4yEnZebc sPMjQuApMZzZ0JBtWNwod4trkK3fJ2MK7QQhD4XpXEDTYPyfYAIs7yBNhtJGgkkM vbEokYgyXXsQ+u3wcEn8PJSVuK+8AaIrczZcv2lv7cD7jPpk5dK/3QDJeCnjx2Yc dz8Cc9ZVEljEbXm66bP7lOPccROlrw== =1mgV -----END PGP SIGNATURE----- --3xhp6eecqwa65oob--