linux-kernel - Re: [RFC 1/2] pwrseq: Add subsystem to handle complex power sequences

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]

Message-ID: <4396181.E2W0ve8f6g@wuerfel>
Date:	Tue, 01 Jul 2014 18:51:24 +0200
From:	Arnd Bergmann <arnd@...db.de>
To:	Ulf Hansson <ulf.hansson@...aro.org>
Cc:	Hans de Goede <hdegoede@...hat.com>,
	Olof Johansson <olof@...om.net>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-mmc@...r.kernel.org" <linux-mmc@...r.kernel.org>,
	"linux-pm@...r.kernel.org" <linux-pm@...r.kernel.org>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Linus Walleij <linus.walleij@...aro.org>,
	Mark Brown <broonie@...nel.org>,
	Alexandre Courbot <gnurou@...il.com>,
	Arend van Spriel <arend@...adcom.com>,
	Sascha Hauer <s.hauer@...gutronix.de>,
	Chris Ball <chris@...ntf.net>, Chen-Yu Tsai <wens@...e.org>,
	Russell King <linux@....linux.org.uk>,
	Tomasz Figa <tomasz.figa@...il.com>,
	Rob Herring <robh+dt@...nel.org>,
	Pawel Moll <pawel.moll@....com>,
	Mark Rutland <mark.rutland@....com>
Subject: Re: [RFC 1/2] pwrseq: Add subsystem to handle complex power sequences

On Tuesday 01 July 2014 18:42:51 Ulf Hansson wrote:
> On 20 June 2014 10:14, Hans de Goede <hdegoede@...hat.com> wrote:
> > On 06/20/2014 10:02 AM, Olof Johansson wrote:
> >> On Fri, Jun 20, 2014 at 12:27 AM, Hans de Goede <hdegoede@...hat.com> wrote:
> >> I disagree.
> >>
> >> The clock is the input to the module, and it is what needs to be
> >> enabled for the module to work. It's not the input to some
> >> power-sequence component on the module, or next to the module on the
> >> bus.
> >
> > Right, it is an input to the sdio-module, not to the mmc-host, so its an
> > input to a different piece of hardware (at different ends of the mmc bus),
> > but since the mmc-bus normally is fully discoverable we've no node for the
> > other end of the bus.
> >
> > So from the mmc-host pov, which is the one which needs to bind the pwrseq
> > driver, as that needs to be done before it can probe its bus, this is
> > a different piece of hardware, hence a subnode to the host makes perfect
> > sense.  This is in no way part of the host, so certainly it does not belong
> > inside the hosts subnode.
> 
> I fully agree with you Hans here.
> 
> If we were to put this information in the host's DT node, that would
> be a wrong description of the hardware. Currently, I can't think of
> anything better than a subnode, but I am open to suggestions.

The problem that I see with your approach is that you use a subnode
to describe an abstract concept, which isn't really a better description
of the hardware than putting the contents in the parent node itself.

It would be more sensible if the subnode was defined (in this case)
as describing the attached device (sdio card or similar), and restructure
the code around that concept.

	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/