From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934146AbcKKQqa (ORCPT ); Fri, 11 Nov 2016 11:46:30 -0500 Received: from mezzanine.sirena.org.uk ([106.187.55.193]:40378 "EHLO mezzanine.sirena.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755903AbcKKQq2 (ORCPT ); Fri, 11 Nov 2016 11:46:28 -0500 Date: Fri, 11 Nov 2016 16:46:10 +0000 From: Mark Brown To: Maxime Ripard Cc: Rob Herring , Chen-Yu Tsai , Liam Girdwood , devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org Message-ID: <20161111164610.rocq76fopcxjkafa@sirena.org.uk> References: <1452605842-9317-2-git-send-email-maxime.ripard@free-electrons.com> <20160112143100.GA14628@rob-hp-laptop> <20160115085734.GG4581@lukather> <20160117000434.GB7774@rob-hp-laptop> <20160118162538.GH6588@sirena.org.uk> <20160121154649.GE3997@lukather> <20160121162802.GL6588@sirena.org.uk> <20160205143328.GD31506@lukather> <20160205153258.GW4455@sirena.org.uk> <20161107154738.ewliwzx5plams4ni@lukather> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="k3zmxocbcm4bzw5v" Content-Disposition: inline In-Reply-To: <20161107154738.ewliwzx5plams4ni@lukather> X-Cookie: Apply only to affected area. User-Agent: NeoMutt/20161104 (1.7.1) X-SA-Exim-Connect-IP: 217.140.96.141 X-SA-Exim-Mail-From: broonie@sirena.org.uk Subject: Re: [PATCH v2 1/2] regulator: Add coupled regulator X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +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 --k3zmxocbcm4bzw5v Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Mon, Nov 07, 2016 at 04:47:38PM +0100, Maxime Ripard wrote: > Since regulator_get returns a struct regulator pointer, it felt > logical to try to add the list of parent regulators to it, especially > as this structure is per-consumer, and different consumers might have > different combinations of regulators. > However, this structure embeds a pointer to a struct regulator_dev, > which seems to model the regulator itself, but will also contain > pointer to the struct regulator, probably to model its parent? I guess It'd be a lot easier to follow this if you named the fields... The rdev in the struct regulator is indeed the physical device. The struct regulator called supply in struct regulator_dev is indeed the parent regulator. > my first question would be do we care about nesting? or having a > regulator with multiple parents? Well, it seems that your use case here is multiple parents so I guess we do care about it. :) > It also contains the constraints on each regulator, which might or > might not be different for each of the coupled regulators, but I'm > guessing the couple might have contraints of its own too I guess. Is > it something that might happen? Should we care about it? I can't see how one could physically have constraints that didn't apply to both parents. > And finally, my real question is, do we want to aggregate them in > struct regulator, at the consumer level, which might make the more > sense, or do we want to create an intermediate regulator internally? > What is your take on this? My initial thought without having tried to implement this is that doing things in an intermediate regulator might do a better job of encapsulating things it if it works out but I've got a feeling that it's not going to work out well and that therefore doing it in the consumer with multiple rdevs will be better. But really either approach is fine if it doesn't look horrible. --k3zmxocbcm4bzw5v Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAABCAAGBQJYJfXRAAoJECTWi3JdVIfQEjcH/3G5MKL7k2kNFgr0PTOosQ0/ 9cEIonjTDyP3kRX3JbtnFHp19DR+U88v0nYtNF8Qjzll0ukrR5xUWNk07DFNcFhO v6EgXnSxh+Z9v4O20xqK7aM3R3V7ExpGeFo1zeX3CBbxDaJEXxWMLUyjzkc2azU2 5KEcVFuX1EmMm3SMMjPHq4/uJ+TRGCBgWsBOg+tb6wL5NcrqxI6c5ZGSKOSS+mfd vbCJj3kPAYHCYqkNRh5BbSFIRObq+BrAFlgc5KWm658LPvvks1xzoo7lN5LtMPzl a7/3DmtoMlO7Giwm4ca20cpzcW7n23FlHP3XS6fb0ZSXiVwVYRZIi+eAbxu9mBo= =2oVb -----END PGP SIGNATURE----- --k3zmxocbcm4bzw5v--