All of lore.kernel.org
 help / color / mirror / Atom feed
From: jeffy <jeffy.chen@rock-chips.com>
To: Mark Brown <broonie@kernel.org>, Brian Norris <briannorris@chromium.org>
Cc: "Dmitry Torokhov" <dmitry.torokhov@gmail.com>,
	"Thierry Reding" <thierry.reding@gmail.com>,
	lkml <linux-kernel@vger.kernel.org>,
	"Heiko Stübner" <heiko@sntech.de>,
	"Rafael J. Wysocki" <rjw@rjwysocki.net>,
	"Doug Anderson" <dianders@chromium.org>,
	tfiga@chromium.org, seanpaul@chromium.org,
	"linux-pwm@vger.kernel.org" <linux-pwm@vger.kernel.org>
Subject: Re: [RFC PATCH v4 7/8] pwm: Add dummy pwmchip for orphan pwms
Date: Wed, 18 Oct 2017 13:16:16 +0800	[thread overview]
Message-ID: <59E6E3A0.2030105@rock-chips.com> (raw)
In-Reply-To: <20171017190501.wa272jreg26tprfo@sirena.co.uk>

Hi guys,

On 10/18/2017 03:05 AM, Mark Brown wrote:
> On Tue, Oct 17, 2017 at 11:53:01AM -0700, Brian Norris wrote:
>> On Tue, Oct 17, 2017 at 07:46:03PM +0100, Mark Brown wrote:
>
>>> 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.
>
> If we're going with the 90% thing we can probably get a long way with a
> whitelist of properties, and we'll be able to take that a lot further
> with the validatable schemas if they ever happen.
>

so it looks like we are going to use device link in common code to fix 
this issue(and also other dependency issue), then i will drop this patch 
and the followed rockchip drm device link patch in next version :)


also the reason why i try to use dummy chip instead is that:

currently we have these devices: rockchip spi device(master) -> 
cros_ec_spi device(child) -> cros_ec_pwm(spi based pwm) -> pwm_bl

i added device link to cros_ec_pwm and pwm_bl, that works well for 
unbind/bind cros_ec_pwm device case, but there's a warning when i try to 
unbind cros_ec_spi:


static void device_links_purge(struct device *dev)
{
...
         list_for_each_entry_safe_reverse(link, ln, 
&dev->links.consumers, s_node) {
                 WARN_ON(link->status != DL_STATE_DORMANT &&
                         link->status != DL_STATE_NONE);        <--- hit 
warning here!
                 __device_link_del(link);
         }


but i checked again, that could due to the way spi core unregester 
children devices. maybe it need to call device_release_driver

  reply	other threads:[~2017-10-18  5:16 UTC|newest]

Thread overview: 54+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-10-17 10:16 [RFC PATCH v4 0/8] rockchip: kevin: Enable edp display Jeffy Chen
2017-10-17 10:16 ` Jeffy Chen
2017-10-17 10:16 ` Jeffy Chen
2017-10-17 10:16 ` [RFC PATCH v4 1/8] arm64: dts: rockchip: Enable edp disaplay on kevin Jeffy Chen
2017-10-17 10:16   ` Jeffy Chen
2017-10-17 10:16   ` Jeffy Chen
2017-10-17 10:16 ` [RFC PATCH v4 2/8] drm/rockchip: analogix_dp: Fix error handling path Jeffy Chen
2017-10-17 10:16   ` Jeffy Chen
2017-10-17 17:57   ` Sean Paul
2017-10-17 17:57     ` Sean Paul
2017-10-17 17:57     ` Sean Paul
2017-10-17 10:16 ` [RFC PATCH v4 3/8] drm/rockchip: dw-mipi-dsi: " Jeffy Chen
2017-10-17 10:16   ` Jeffy Chen
2017-10-17 10:16   ` Jeffy Chen
2017-10-17 18:02   ` Sean Paul
2017-10-17 18:02     ` Sean Paul
2017-10-17 18:02     ` Sean Paul
2017-10-17 10:16 ` [RFC PATCH v4 4/8] drm/rockchip: dw_hdmi: " Jeffy Chen
2017-10-17 10:16   ` Jeffy Chen
2017-10-17 10:16   ` Jeffy Chen
2017-10-17 18:10   ` Sean Paul
2017-10-17 18:10     ` Sean Paul
2017-10-17 18:10     ` Sean Paul
2017-10-19  1:54     ` jeffy
2017-10-19  1:54       ` jeffy
2017-10-19  1:54       ` jeffy
2017-10-17 10:16 ` [RFC PATCH v4 5/8] drm/rockchip: inno_hdmi: " Jeffy Chen
2017-10-17 10:16   ` Jeffy Chen
2017-10-17 18:18   ` Sean Paul
2017-10-17 18:18     ` Sean Paul
2017-10-17 10:16 ` [RFC PATCH v4 6/8] drm/bridge/analogix: Do not use device's drvdata Jeffy Chen
2017-10-17 10:16   ` Jeffy Chen
2017-10-17 10:16   ` Jeffy Chen
2017-10-17 18:18   ` Sean Paul
2017-10-17 18:18     ` Sean Paul
2017-10-17 18:18     ` Sean Paul
2017-10-17 23:43   ` Jingoo Han
2017-10-17 23:43     ` Jingoo Han
2017-10-17 23:43     ` Jingoo Han
2017-10-18  4:46     ` Archit Taneja
2017-10-18  4:46       ` Archit Taneja
2017-10-18  4:46       ` Archit Taneja
2017-10-17 10:16 ` [RFC PATCH v4 7/8] pwm: Add dummy pwmchip for orphan pwms Jeffy Chen
2017-10-17 12:40   ` Thierry Reding
2017-10-17 17:04     ` Brian Norris
2017-10-17 18:24       ` Dmitry Torokhov
2017-10-17 18:46         ` Mark Brown
2017-10-17 18:53           ` Brian Norris
2017-10-17 19:05             ` Mark Brown
2017-10-18  5:16               ` jeffy [this message]
2017-10-17 10:16 ` [RFC PATCH v4 8/8] drm/rockchip: Add device links for master and components Jeffy Chen
2017-10-17 10:16   ` Jeffy Chen
2017-10-17 18:24   ` Sean Paul
2017-10-17 18:24     ` Sean Paul

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=59E6E3A0.2030105@rock-chips.com \
    --to=jeffy.chen@rock-chips.com \
    --cc=briannorris@chromium.org \
    --cc=broonie@kernel.org \
    --cc=dianders@chromium.org \
    --cc=dmitry.torokhov@gmail.com \
    --cc=heiko@sntech.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pwm@vger.kernel.org \
    --cc=rjw@rjwysocki.net \
    --cc=seanpaul@chromium.org \
    --cc=tfiga@chromium.org \
    --cc=thierry.reding@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.