linux-kernel - Re: [RFC][PATCH 0/14] PM / shmobile: Pass power domain information via DT (was: Re: [RFD] PM: Device tree representation of power domains)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 24 Jul 2012 15:20:20 +0000
From:	Arnd Bergmann <arnd@...db.de>
To:	"Rafael J. Wysocki" <rjw@...k.pl>
Cc:	Linux PM list <linux-pm@...r.kernel.org>,
	Mark Brown <broonie@...nsource.wolfsonmicro.com>,
	LKML <linux-kernel@...r.kernel.org>,
	Matthew Garrett <mjg59@...f.ucam.org>,
	Magnus Damm <magnus.damm@...il.com>,
	Grant Likely <grant.likely@...retlab.ca>,
	"Linux-sh list" <linux-sh@...r.kernel.org>
Subject: Re: [RFC][PATCH 0/14] PM / shmobile: Pass power domain information via DT (was: Re: [RFD] PM: Device tree representation of power domains)

On Saturday 21 July 2012, Rafael J. Wysocki wrote:
> On Monday, July 16, 2012, Rafael J. Wysocki wrote:
> > On Thursday, July 05, 2012, Rafael J. Wysocki wrote:
> > > On Wednesday, July 04, 2012, Mark Brown wrote:
> > > > I guess the OMAP hwmod stuff is the closest thing we've got at the
> > > > minute (I don't recall seeing any other implementations in mainline) but
> > > > the hwmods themselves don't appear in the DTS right now.  They have a
> > > > ti,hwmods property on each device naming the hwmod it's in, something
> > > > like that seems like a reasonable approach, possibly a reference to
> > > > another DT node rather than or as well as a string?  That seems fairly
> > > > easy.
> > > 
> > > Well, it looks like (and please tell me if I'm wrong) the hwmons are just
> > > string attributes that are parsed by the platform-specific code through
> > > a platform bus type notifier.
> > > 
> > > We could do that for power domains too, but then each platform wanting to
> > > use them would need to implement such a notifier and add its own routine
> > > for parsing those strings.  Would that be acceptable to everyone concerned?
> > 
> > I tried to follow the above suggestion and prepared the following patchset
> > that allows power domain information for Renesas platforms to be passed as
> > "renesas,pmdomain" string attribute of device nodes.  It adds functions
> > allowing the generic PM domains framework to use names for domain
> > identification in various situations and reworks the ARM/shmobile power domains
> > support code to used those functions instead of the "raw" ones that take
> > domain pointers as their arguments.  Finally, it defines a platform bus type
> > notifier that will add devices whose DT nodes contain the "renesas,pmdomain"
> > attribute to the power domains indicated by it (the value of that attribute
> > should be the name of the PM domain to add the device to after it's been
> > registered).  All of this should allow platform devices to be added to
> > appropriate power domains automatically based on the information read from
> > a DT.
> > 
> > The patches are on top of the current linux-next tree.
> > 
> > I've tested the patches that could be tested on the Mackerel board, except
> > for the last one (I'm still working on testing it).
> 
> Well, no comments, no objections.  Good!
> 
> I've just tested [14/14] too and it works as expected.

Sorry for taking so long to reply. I am really not that familiar with the
power domain requirements, but I do have two comments on your approach:

* I think when we want to add a generic concept to the device tree such
  as power domains, we should always make it specified in a generic way.
  You have used the "renesas,pmdomain" attribute, which is specific to
  one vendor and requires platform specific code to read it.
  Is there any reason not to put the code into the generic
  drivers/base/power/domain.c file (or near it) and make a binding that
  works for everyone?

* Mark suggested two options (string and phandle), and (you guessed it),
  I would much prefer the other one.
  IMHO using phandle makes it much easier to do this in a generic way,
  without having to document every possible string that this can be
  set to in the binding document. Obviously the phandle requires having
  a node in the device tree for each domain, but I think having that
  node is actually an advantage because it lets you describe the
  hierarchy of the domains there.

	Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/