All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrzej Hajda <a.hajda@samsung.com>
To: Mark Brown <broonie@kernel.org>
Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>,
	Linux PM list <linux-pm@vger.kernel.org>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Alan Stern <stern@rowland.harvard.edu>,
	Grant Likely <grant.likely@linaro.org>,
	Rob Herring <robh@kernel.org>,
	Tomeu Vizoso <tomeu.vizoso@collabora.com>,
	Thierry Reding <treding@nvidia.com>,
	Dmitry Torokhov <dtor@google.com>,
	Geert Uytterhoeven <geert@linux-m68k.org>,
	Michael Turquette <mturquette@baylibre.com>
Subject: Re: [RFD] Functional dependencies between devices
Date: Tue, 24 Nov 2015 14:56:45 +0100	[thread overview]
Message-ID: <56546C9D.3090206@samsung.com> (raw)
In-Reply-To: <20151121140428.GJ26072@sirena.org.uk>

On 11/21/2015 03:04 PM, Mark Brown wrote:
> On Thu, Nov 19, 2015 at 07:50:45AM +0100, Andrzej Hajda wrote:
>> On 11/17/2015 02:55 PM, Mark Brown wrote:
>>> This is going to be really common but I'm not sure I see a problem with
>>> it in terms of what Raphael is proposing - could you go into more detail
>>> on the problem you see here?
>> If clock provider is not a device driver and it depends on clocks of
>> another clock
>> provider you cannot 'translate' this dependency as dependency between
>> devices,
> What makes you say that this is the case?  There should be nothing
> stopping us having dependencies between two devices of the same type.

To be clear I described situation that one clock provider uses clock
of another clock provider and consumer is not modeled as device.


>
>> so this RFD does not cover them.
>> Additionally if you look into kernel there are many calls in form
>> 'clk_get(NULL, name)',
>> it suggests that not only clock providers are consumers without
>> underlying device driver.
> Like I said in my earlier reply:
>
> | > - many clock providers, irq domains are not provided by devices,
>
> | That seems like something we can and possibly should change if we want.
>
> This applies just as much to consumers as to providers.

OK, then it is just something to do :)

Regards
Andrzej

  reply	other threads:[~2015-11-24 13:56 UTC|newest]

Thread overview: 55+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-10-27 15:24 [RFD] Functional dependencies between devices Rafael J. Wysocki
2015-10-27 15:20 ` Tomeu Vizoso
2015-10-28  2:15   ` Rafael J. Wysocki
2015-10-28 14:26     ` Tomeu Vizoso
2015-10-28 15:54       ` Rafael J. Wysocki
2015-10-29  0:18         ` Mark Brown
2015-10-29 14:03         ` Tomeu Vizoso
2015-10-29 14:31           ` Alan Stern
2015-10-31  2:23             ` Rafael J. Wysocki
2015-10-31 15:22               ` Alan Stern
2015-10-29  0:15 ` Mark Brown
2015-10-31  2:13   ` Rafael J. Wysocki
2015-10-31  2:40     ` Mark Brown
2015-10-30  9:50 ` Linus Walleij
2015-10-30 22:52 ` Greg Kroah-Hartman
2016-01-07 14:55   ` Tomeu Vizoso
2016-01-07 21:29     ` Greg Kroah-Hartman
2016-01-08  7:28       ` Tomeu Vizoso
2016-01-08 15:15         ` Greg Kroah-Hartman
2015-11-09 12:32 ` Thierry Reding
2015-11-09 21:42   ` Rafael J. Wysocki
2015-11-17 12:44 ` Andrzej Hajda
2015-11-18  2:17   ` Rafael J. Wysocki
2015-11-19  9:08     ` Andrzej Hajda
2015-11-19 22:04       ` Rafael J. Wysocki
2015-11-20  1:11         ` Rafael J. Wysocki
2015-11-24 14:57         ` Andrzej Hajda
2015-11-24 16:28           ` Rafael J. Wysocki
2015-11-30  7:16             ` Andrzej Hajda
2015-11-17 12:49 ` Andrzej Hajda
2015-11-17 13:55   ` Mark Brown
2015-11-19  6:50     ` Andrzej Hajda
2015-11-21 14:04       ` Mark Brown
2015-11-24 13:56         ` Andrzej Hajda [this message]
2015-11-19 13:18     ` Thierry Reding
2015-11-21 13:26       ` Mark Brown
2015-11-17 20:31   ` Alan Stern
2015-11-17 22:47     ` Mark Brown
2016-01-14  1:52 ` [RFC][PATCH 0/5] " Rafael J. Wysocki
2016-01-14  1:53   ` [RFC][PATCH 1/5] driver core: Add a wrapper around __device_release_driver() Rafael J. Wysocki
2016-01-14  1:54   ` [RFC][PATCH 2/5] driver core: Functional dependencies tracking support Rafael J. Wysocki
2016-06-08 12:48     ` Mark Brown
2016-06-08 18:12       ` Rafael J. Wysocki
2016-06-08 18:35         ` Mark Brown
2016-06-08 20:48           ` Rafael J. Wysocki
2016-06-08 22:24             ` Mark Brown
2016-01-14  1:55   ` [RFC][PATCH 3/5] PM core: Make async suspend/resume of devices use device links Rafael J. Wysocki
2016-06-08 12:59     ` Mark Brown
2016-01-14  1:56   ` [RFC][PATCH 4/5] PM core: Make runtime PM " Rafael J. Wysocki
2016-01-14  1:56   ` [RFC][PATCH 5/5] PM core: Optimize the use of device links for runtime PM Rafael J. Wysocki
2016-01-14 14:19   ` [RFC][PATCH 0/5] Functional dependencies between devices Tomeu Vizoso
2016-01-15  0:44     ` Rafael J. Wysocki
2016-06-08 12:15   ` Mark Brown
2016-06-08 17:24     ` Rafael J. Wysocki
2016-06-08 17:33       ` Mark Brown

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=56546C9D.3090206@samsung.com \
    --to=a.hajda@samsung.com \
    --cc=broonie@kernel.org \
    --cc=dtor@google.com \
    --cc=geert@linux-m68k.org \
    --cc=grant.likely@linaro.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=mturquette@baylibre.com \
    --cc=rjw@rjwysocki.net \
    --cc=robh@kernel.org \
    --cc=stern@rowland.harvard.edu \
    --cc=tomeu.vizoso@collabora.com \
    --cc=treding@nvidia.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.