From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Andrew F. Davis" Subject: Re: [PATCH v4 4/5] regulator: tps65912: Add regulator driver for the TPS65912 PMIC Date: Tue, 10 Nov 2015 13:40:38 -0600 Message-ID: <56424836.7000608@ti.com> References: <20151105101417.GM1717@sirena.org.uk> <563B9A10.4020907@ti.com> <20151106104322.GA18409@sirena.org.uk> <563CED25.6020405@ti.com> <20151106211651.GJ18409@sirena.org.uk> <5640DAC0.9080008@ti.com> <20151110095719.GC12392@sirena.org.uk> <56421FA5.1020103@ti.com> <20151110170447.GI12392@sirena.org.uk> <56422ECC.6070603@ti.com> <20151110184408.GJ12392@sirena.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20151110184408.GJ12392@sirena.org.uk> Sender: linux-kernel-owner@vger.kernel.org To: Mark Brown Cc: Rob Herring , Pawel Moll , Mark Rutland , Ian Campbell , Kumar Gala , Lee Jones , Alexandre Courbot , Grygorii Strashko , devicetree@vger.kernel.org, linux-kernel@vger.kernel.org List-Id: devicetree@vger.kernel.org On 11/10/2015 12:44 PM, Mark Brown wrote: > On Tue, Nov 10, 2015 at 11:52:12AM -0600, Andrew F. Davis wrote: > >> Anyway, All I'm trying to do here is keep things clean in the DT. We only have >> one consistent option: > > No, not really. > >> Match all sub parts by compatible: > >> Or we end up with some hybrid approach, matching some on node name, others >> on compatible when needed. Yes, the above matches Linux device model (still >> not sure why that is such a problem?), but it also matches modular functionality >> in the device. > > There's also the third option where we don't have any compatible strings > in the subnodes at all. > Ok, two, but would you really want to go that way? Matching by node name costs us all of the flexibility of DT sub-device selection. Still don't see an upside as we would now be locked to node names instead of compatible strings to declare component type compatibility (what they are for). From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751607AbbKJTkx (ORCPT ); Tue, 10 Nov 2015 14:40:53 -0500 Received: from comal.ext.ti.com ([198.47.26.152]:60424 "EHLO comal.ext.ti.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750893AbbKJTkv (ORCPT ); Tue, 10 Nov 2015 14:40:51 -0500 Subject: Re: [PATCH v4 4/5] regulator: tps65912: Add regulator driver for the TPS65912 PMIC To: Mark Brown References: <20151105101417.GM1717@sirena.org.uk> <563B9A10.4020907@ti.com> <20151106104322.GA18409@sirena.org.uk> <563CED25.6020405@ti.com> <20151106211651.GJ18409@sirena.org.uk> <5640DAC0.9080008@ti.com> <20151110095719.GC12392@sirena.org.uk> <56421FA5.1020103@ti.com> <20151110170447.GI12392@sirena.org.uk> <56422ECC.6070603@ti.com> <20151110184408.GJ12392@sirena.org.uk> CC: Rob Herring , Pawel Moll , Mark Rutland , Ian Campbell , Kumar Gala , Lee Jones , Alexandre Courbot , Grygorii Strashko , , From: "Andrew F. Davis" Message-ID: <56424836.7000608@ti.com> Date: Tue, 10 Nov 2015 13:40:38 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <20151110184408.GJ12392@sirena.org.uk> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 11/10/2015 12:44 PM, Mark Brown wrote: > On Tue, Nov 10, 2015 at 11:52:12AM -0600, Andrew F. Davis wrote: > >> Anyway, All I'm trying to do here is keep things clean in the DT. We only have >> one consistent option: > > No, not really. > >> Match all sub parts by compatible: > >> Or we end up with some hybrid approach, matching some on node name, others >> on compatible when needed. Yes, the above matches Linux device model (still >> not sure why that is such a problem?), but it also matches modular functionality >> in the device. > > There's also the third option where we don't have any compatible strings > in the subnodes at all. > Ok, two, but would you really want to go that way? Matching by node name costs us all of the flexibility of DT sub-device selection. Still don't see an upside as we would now be locked to node names instead of compatible strings to declare component type compatibility (what they are for).