From: Arnd Bergmann <arnd@arndb.de>
To: linuxppc-dev@lists.ozlabs.org
Cc: Geert Uytterhoeven <geert+renesas@glider.be>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Yangbo Lu <yangbo.lu@nxp.com>, Simon Horman <horms@verge.net.au>,
Magnus Damm <magnus.damm@gmail.com>,
Rob Herring <robh+dt@kernel.org>,
Mark Rutland <mark.rutland@arm.com>,
devicetree@vger.kernel.org, Dirk Behme <dirk.behme@de.bosch.com>,
linux-kernel@vger.kernel.org, linux-renesas-soc@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v2 7/7] soc: renesas: Identify SoC and register with the SoC bus
Date: Wed, 09 Nov 2016 17:55:28 +0100 [thread overview]
Message-ID: <3693445.TSdZGaiT9S@wuerfel> (raw)
In-Reply-To: <1477913455-5314-8-git-send-email-geert+renesas@glider.be>
On Monday, October 31, 2016 12:30:55 PM CET Geert Uytterhoeven wrote:
> v2:
> - Drop SoC families and family names; use fixed "Renesas" instead,
I think I'd rather have seen the family names left in there, but it's
not important, so up to you.
> - Use "renesas,prr" and "renesas,cccr" device nodes in DT if
> available, else fall back to hardcoded addresses for compatibility
> with existing DTBs,
I only see patches 2, 3, 5, and 7 in my inbox, so I'm lacking the DT
binding for these, among other things.
It does seem wrong to have a device node for a specific register though.
Shouldn't the node be for the block of registers that these are inside
of?
> - Don't register the SoC bus if the chip ID register is missing,
Why? My objection was to hardcoding the register, not to registering
the device? I think I'd rather see the device registered with an
empty revision string.
> +#define CCCR 0xe600101c /* Common Chip Code Register */
> +#define PRR 0xff000044 /* Product Register */
> +#define PRR3 0xfff00044 /* Product Register on R-Car Gen3 */
> +
> +static const struct of_device_id renesas_socs[] __initconst = {
> +#ifdef CONFIG_ARCH_R8A73A4
> + { .compatible = "renesas,r8a73a4", .data = (void *)PRR, },
> +#endif
> +#ifdef CONFIG_ARCH_R8A7740
> + { .compatible = "renesas,r8a7740", .data = (void *)CCCR, },
> +#endif
My preference here would be to list the register address only for
SoCs that are known to need them, while also having .dtb files that
don't have the nodes.
> +static int __init renesas_soc_init(void)
> +{
> + struct soc_device_attribute *soc_dev_attr;
> + const struct of_device_id *match;
> + void __iomem *chipid = NULL;
> + struct soc_device *soc_dev;
> + struct device_node *np;
> + unsigned int product;
> +
> + np = of_find_matching_node_and_match(NULL, renesas_socs, &match);
> + if (!np)
> + return -ENODEV;
> +
> + of_node_put(np);
> +
> + /* Try PRR first, then CCCR, then hardcoded fallback */
> + np = of_find_compatible_node(NULL, NULL, "renesas,prr");
> + if (!np)
> + np = of_find_compatible_node(NULL, NULL, "renesas,cccr");
> + if (np) {
> + chipid = of_iomap(np, 0);
> + of_node_put(np);
> + } else if (match->data) {
> + chipid = ioremap((uintptr_t)match->data, 4);
> + }
> + if (!chipid)
>
Here, I'd turn the order around and look for the DT nodes of the
devices first. Only if they are not found, look at the compatible
string of the root node. No need to search for a node though,
you know which one it is when you look for a compatible =
"renesas,r8a73a4".
Arnd
next prev parent reply other threads:[~2016-11-09 16:55 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-10-31 11:30 [PATCH v2 0/7] soc: renesas: Identify SoC and register with the SoC bus Geert Uytterhoeven
2016-10-31 11:30 ` [PATCH v2 1/7] base: soc: Early register bus when needed Geert Uytterhoeven
2016-10-31 11:30 ` [PATCH v2 2/7] base: soc: Introduce soc_device_match() interface Geert Uytterhoeven
[not found] ` <1477913455-5314-1-git-send-email-geert+renesas-gXvu3+zWzMSzQB+pC5nmwQ@public.gmane.org>
2016-10-31 11:30 ` [PATCH v2 3/7] base: soc: Check for NULL SoC device attributes Geert Uytterhoeven
2016-10-31 11:30 ` [PATCH v2 5/7] ARM: shmobile: Document DT bindings for CCCR and PRR Geert Uytterhoeven
2016-11-09 18:24 ` Rob Herring
2016-10-31 11:30 ` [PATCH v2 7/7] soc: renesas: Identify SoC and register with the SoC bus Geert Uytterhoeven
2016-11-09 16:55 ` Arnd Bergmann [this message]
2016-11-10 10:19 ` Geert Uytterhoeven
2016-11-10 11:37 ` Arnd Bergmann
2016-11-14 10:51 ` Geert Uytterhoeven
2016-11-14 11:22 ` Arnd Bergmann
2016-10-31 11:30 ` [PATCH v2 4/7] base: soc: Provide a dummy implementation of soc_device_match() Geert Uytterhoeven
2016-10-31 11:30 ` [PATCH v2 6/7] arm64: dts: r8a7795: Add device node for PRR Geert Uytterhoeven
2016-11-07 9:35 ` [PATCH v2 0/7] soc: renesas: Identify SoC and register with the SoC bus Geert Uytterhoeven
[not found] ` <CAMuHMdV4HG0aOr4Qp_OZXU=3jLeOJ2QaMKp09a3v4489ABbRcA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2016-11-07 18:33 ` Krzysztof Kozlowski
2016-11-09 13:34 ` Geert Uytterhoeven
[not found] ` <CAMuHMdUmpMpizZpq1V-sLA8Cf2q5oOgOVxGOvKXqTHvn+Mj7Tg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2016-11-09 16:56 ` Arnd Bergmann
2016-11-09 17:19 ` Geert Uytterhoeven
2016-11-09 21:12 ` Arnd Bergmann
2016-11-10 9:22 ` Geert Uytterhoeven
2016-11-10 10:56 ` Geert Uytterhoeven
2016-11-10 10:59 ` Ulf Hansson
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=3693445.TSdZGaiT9S@wuerfel \
--to=arnd@arndb.de \
--cc=devicetree@vger.kernel.org \
--cc=dirk.behme@de.bosch.com \
--cc=geert+renesas@glider.be \
--cc=gregkh@linuxfoundation.org \
--cc=horms@verge.net.au \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-renesas-soc@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=magnus.damm@gmail.com \
--cc=mark.rutland@arm.com \
--cc=robh+dt@kernel.org \
--cc=yangbo.lu@nxp.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).