From: arnd@arndb.de (Arnd Bergmann)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH V3 0/6] ARM64: Add support for FSL's LS2085A SoC
Date: Thu, 04 Sep 2014 11:39:15 +0200 [thread overview]
Message-ID: <3563146.jh46O3eIbG@wuerfel> (raw)
In-Reply-To: <20140904091319.GA32228@leverpostej>
On Thursday 04 September 2014 10:13:19 Mark Rutland wrote:
> On Wed, Sep 03, 2014 at 07:31:44PM +0100, Arnd Bergmann wrote:
> > On Wednesday 03 September 2014 17:31:30 Mark Rutland wrote:
> > >
> > > However, I'm not sure I follow the reasoning for making this
> > > significantly harder, and even ignoring that I don't think this does
> > > make things significantly harder. Especially so if we have a PSCI node
> > > but not an enable method -- in that case its trivial to patch in an
> > > unrelated enable-method anyhow.
> >
> > Right, it's not actually much harder. A better way to look at it is
> > probably that we document what which parts we expect to stay constant
> > and which parts are to be filled out by the boot loader. Independent
> > of what PSCI implementation the boot loader provides, we would like
> > to see enable-method="psci".
>
> So in the /cpus node, have a comment like:
>
> /*
> * We expect the enable-method to be "psci", but this is dependent on
> * the FW, which will fill this in.
> */
I was thinking of leaving the enable-method in the cpus node, but having
an empty psci node with a similar comment.
> Or, should we put together a soc-guidance.txt with that, ensuring things
> are initialised correctly (CNTVOFF, CNTFREQ), etc?
I would very much welcome documentation like that!
> > I just saw that Geoff had a related comment, and documenting this
> > would make it clearer to other reviewers, as well as people that
> > happen to look at this file as a base for new platforms.
>
> I agree that having something to point people in the right direction is
> a good idea. The only point I disagree with is putitng something in the
> DT that can be trivially made false (and possibly with good reason).
>
> I'm happy with having comments.
Right, but I see no good reason for having something else in the
enable-method, the only way I can see why that would be done is for
the boot loader or firmware implementer to be misinformed.
Arnd
next prev parent reply other threads:[~2014-09-04 9:39 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-03 15:13 [PATCH V3 0/6] ARM64: Add support for FSL's LS2085A SoC Bhupesh Sharma
2014-09-03 15:13 ` [PATCH V3 1/6] Documentation: DT: Add bindings for FSL NS16550A UART Bhupesh Sharma
2014-09-03 15:13 ` [PATCH V3 2/6] Documentation: DT: Add entry for FSL LS2085A SoC and Simulator model Bhupesh Sharma
2014-09-03 15:13 ` [PATCH V3 3/6] Documentation: DT: Add entry for FSL Management Complex Bhupesh Sharma
2014-09-03 15:13 ` [PATCH V3 4/6] arm64: Add DTS support for FSL's LS2085A SoC Bhupesh Sharma
2014-09-03 18:34 ` Arnd Bergmann
2014-09-04 7:55 ` bhupesh.sharma at freescale.com
2014-09-20 20:35 ` bhupesh.sharma at freescale.com
2014-09-03 15:13 ` [PATCH V3 5/6] arm64: dts/Makefile: Add support for FSL's LS2085A simulator model Bhupesh Sharma
2014-09-03 15:13 ` [PATCH V3 6/6] arm64: Add support for FSL's LS2085A SoC in Kconfig and defconfig Bhupesh Sharma
2014-09-03 15:29 ` [PATCH V3 0/6] ARM64: Add support for FSL's LS2085A SoC Arnd Bergmann
2014-09-03 15:36 ` bhupesh.sharma at freescale.com
2014-09-03 15:39 ` Arnd Bergmann
2014-09-03 15:42 ` bhupesh.sharma at freescale.com
2014-09-03 15:56 ` Mark Rutland
2014-09-03 16:05 ` Arnd Bergmann
2014-09-03 16:09 ` Mark Rutland
2014-09-03 16:10 ` bhupesh.sharma at freescale.com
2014-09-03 16:18 ` Arnd Bergmann
2014-09-03 16:31 ` Mark Rutland
2014-09-03 18:31 ` Arnd Bergmann
2014-09-04 9:13 ` Mark Rutland
2014-09-04 9:39 ` Arnd Bergmann [this message]
2014-09-04 16:32 ` Stuart Yoder
2014-09-09 11:46 ` bhupesh.sharma at freescale.com
2014-09-09 13:42 ` Catalin Marinas
2014-09-20 20:35 ` bhupesh.sharma at freescale.com
2014-09-22 13:55 ` Mark Rutland
2014-09-24 14:50 ` Stuart Yoder
2014-09-03 18:30 ` Geoff Levand
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=3563146.jh46O3eIbG@wuerfel \
--to=arnd@arndb.de \
--cc=linux-arm-kernel@lists.infradead.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox