From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934858AbdJQSxG (ORCPT ); Tue, 17 Oct 2017 14:53:06 -0400 Received: from mail-io0-f179.google.com ([209.85.223.179]:52544 "EHLO mail-io0-f179.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753669AbdJQSxF (ORCPT ); Tue, 17 Oct 2017 14:53:05 -0400 X-Google-Smtp-Source: ABhQp+TqprZI7Asyc7ENUYJbAXYrOpScUGqXlUO0JT2SM9AltrUZXh9vwyXCkI1OOI71y/kWyfwz5Q== Date: Tue, 17 Oct 2017 11:53:01 -0700 From: Brian Norris To: Mark Brown Cc: Dmitry Torokhov , Thierry Reding , Jeffy Chen , lkml , Heiko =?iso-8859-1?Q?St=FCbner?= , "Rafael J. Wysocki" , Doug Anderson , tfiga@chromium.org, seanpaul@chromium.org, "linux-pwm@vger.kernel.org" Subject: Re: [RFC PATCH v4 7/8] pwm: Add dummy pwmchip for orphan pwms Message-ID: <20171017185259.GA41348@google.com> References: <20171017101624.12506-1-jeffy.chen@rock-chips.com> <20171017101624.12506-8-jeffy.chen@rock-chips.com> <20171017124031.GA27983@ulmo> <20171017170428.GB3408@google.com> <20171017184603.yluoukqq6hj2cgcb@sirena.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20171017184603.yluoukqq6hj2cgcb@sirena.co.uk> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Oct 17, 2017 at 07:46:03PM +0100, Mark Brown wrote: > On Tue, Oct 17, 2017 at 11:24:24AM -0700, Dmitry Torokhov wrote: > > On Tue, Oct 17, 2017 at 10:04 AM, Brian Norris wrote: > > > > BTW, since you seem to have an opinion about device links: is it > > > expected that all consumer drivers will make explicit calls to > > > device_link_add()? I thought this should be avoided, if possible (e.g., > > > this can be handled in pwm_get()). > > > Ideally we would not have this in core kernel API (pwm_get, gpiod_get, > > regulator_get, etc) but retrieve it form the firmware (device tree, > > ACPI) and use this data not only on suspend/resume but for probing as > > Right, the major initial push here was for ordering of probes so doing > it in subsystems or drivers is too late. > > > well. *How exactly* can we do that is still not clear though, so maybe > > we could plug the biggest holes by actually adding device links calls > > to the main devm__get() users... > > I would expect we can get a long way in the DT by doing a pass over the > tree and adding links between device nodes in cases where phandle > references exist. There is a potential issue with circular links which > I'm just going to handwave away right now but I'd expect that to help > otherwise. But I didn't think FDTs encoded type info. So you don't really know whether a phandle is a phandle -- it's just an int (which happens to have a corresponding property in some other node). Are we trusting our DT bindings well enough to say that, for example, we know that in any given device node, a property like 'pwms' must be a phandle to a PWM provider? OK, maybe 'pwms' is a bad example (it's unlikely to get reused, and it has a companion '#pwm-cells' property), but grepping the DT bindings directory shows a ton of one-off properties that contain phandles. Brian