From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752940AbcJJOX7 (ORCPT ); Mon, 10 Oct 2016 10:23:59 -0400 Received: from mout.kundenserver.de ([212.227.126.133]:50189 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752737AbcJJOX6 (ORCPT ); Mon, 10 Oct 2016 10:23:58 -0400 From: Arnd Bergmann To: Geert Uytterhoeven Cc: Simon Horman , Magnus Damm , Greg Kroah-Hartman , Yangbo Lu , Lee Jones , Dirk Behme , linux-arm-kernel@lists.infradead.org, linux-renesas-soc@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH/RFC 4/4] soc: renesas: Identify SoC and register with the SoC bus Date: Mon, 10 Oct 2016 16:23:19 +0200 Message-ID: <1560471.cOCZ4VcGTh@wuerfel> User-Agent: KMail/5.1.3 (Linux/4.4.0-34-generic; KDE/5.18.0; x86_64; ; ) In-Reply-To: <1475572167-29581-5-git-send-email-geert+renesas@glider.be> References: <1475572167-29581-1-git-send-email-geert+renesas@glider.be> <1475572167-29581-5-git-send-email-geert+renesas@glider.be> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Provags-ID: V03:K0:u0NgHxvqWxh799C1j9UxB7lEWw/WtJK7k43W2bCpnKCPWcHgOJc PdNh3EFjVZySpvZSv+y7dd5GEpuZ0bVezzNZnhcUhBc5ixXDS4NahDy/ZRgbO8HJSFbiCfe zb/MuyY86dNahxTKPgBlWDp2WmviZlx7fUfmOLNxITbvU9s6uSQVyoaRsIqx3ULs8tCJTeq 3a6GrQXO9QTFvS8gMN1Bg== X-UI-Out-Filterresults: notjunk:1;V01:K0:wmn0RiCzk84=:T39l8FhbuS3Q5H+x045Ipi /O9FYNIe2+UU9WM43vyV6Vh/vOtkOKvffjMq2LXd9spH2aOJVXcnF6uKnGNWyIYNAXjB6r3ut mAaeoRll+SKhDlwUZ8wj2YPq/BVfHWm3dQwzXOvbT+n1VGCqg0YWwkhYEH0NX6nN2WWtIuZLf pBfAhr1quu5KcoqH9O4Jy4TutS3T6uLC9ryBzkW1SFGL3ciMCK18+edqicBbpIEFaCmG709vf B2CNchIwnEGf+Ky0cchULXb9zAoh26/mxLE0qUQIEGiJfoihQj/zAZZsbC7pAOD+1FwokfRu2 k4whjJLoaRqN4Bv9vz2XvWf69dzvC7VOj5b/z39ofDHMd0ElAj8nmlG+gBp/sxbcJF6oounz2 eDUL9NdQikzKIJ7KgufWTMTG9nN6lIxkpG53flQOaXXkGcMtm1jzutE3lXoedVGyB5w3DhdgC wRtn2UOZQFKgWIzHk0nect80b76PQJNYvsJaCmkkBCpcYBLsyGprCd95nM35Jh8vzM8CMX48+ nbjKTghyZIXkitMXULUnWueKvb+p8TiOJ5XUZQWj/vwLDuGqG3m8dT3EG9+6Q/6QcoUthWv2c BLTryXB7tVMzn+3NfEV9kp5lJ0/VjHlmp9BEGGCjm+xYIDUy1vBpuPh30rYGPLwBYQ9wxlQzZ 67HRw/ENIK6MSXceHKk1xvef4VBY8rwRpaoqRKACV9aZHjE1ijOhV9OeNjUOOqWrOdIR8y58S kr5LD/3rEHwAK6Qm Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tuesday, October 4, 2016 11:09:27 AM CEST Geert Uytterhoeven wrote: > Identify the SoC type and revision, and register this information with > the SoC bus, so it is available under /sys/devices/soc0/, and can be > checked where needed using soc_device_match(). > > In addition, on SoCs that support it, the product ID is read from a > hardware register and validated, to catch accidental use of a DTB for a > different SoC. > > Example: > > Detected Renesas r8a7791 ES1.0 > ... > # cat /sys/devices/soc0/{family,machine,soc_id,revision} > R-Car Gen2 > Koelsch > r8a7791 > ES1.0 > Seems all reasonable. > Signed-off-by: Geert Uytterhoeven > --- > This patch does NOT add a call to > > of_platform_default_populate(NULL, NULL, > soc_device_to_device(soc_dev)); > > Contrary to suggested by commit 74d1d82cdaaec727 ("drivers/base: add bus > for System-on-Chip devices), doing so would not only move on-SoC devices > from /sys/devices/platform/ to /sys/devices/soc0/, but also all other > board (off-SoC) devices specified in the DTB. Right, we have moved away from that a while ago, and now just use the device for identification, not to model the device hierarchy. > diff --git a/drivers/soc/renesas/renesas-soc.c b/drivers/soc/renesas/renesas-soc.c > new file mode 100644 > index 0000000000000000..74b72e4112b8889e > --- /dev/null > +++ b/drivers/soc/renesas/renesas-soc.c > @@ -0,0 +1,266 @@ > +/* > + * Renesas SoC Identification > + * > + * Copyright (C) 2014-2016 Glider bvba > + * > + * This program is free software; you can redistribute it and/or modify > + * it under the terms of the GNU General Public License as published by > + * the Free Software Foundation; version 2 of the License. > + * > + * This program is distributed in the hope that it will be useful, > + * but WITHOUT ANY WARRANTY; without even the implied warranty of > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > + * GNU General Public License for more details. > + */ > + > +#include > +#include > +#include > +#include > +#include > + > + > +struct renesas_family { > + const char name[16]; > + u32 reg; /* CCCR, PVR, or PRR */ > +}; > + > +static const struct renesas_family fam_emev2 __initconst = { > + .name = "Emma Mobile EV2", > +}; As this is not related to the others and doesn't have the respective register, I'd leave the platform out of this, and possibly have a separate driver for it. > +static const struct renesas_family fam_rza __initconst = { > + .name = "RZ/A", > +}; I'm not sure about the relationship between this one and the others, maybe it should be treated in the same way as emev2 and left out from this driver? > +static const struct renesas_family fam_rmobile __initconst = { > + .name = "R-Mobile", > + .reg = 0xe600101c, /* CCCR (Common Chip Code Register) */ > +}; > + > +static const struct renesas_family fam_rcar_gen1 __initconst = { > + .name = "R-Car Gen1", > + .reg = 0xff000044, /* PRR (Product Register) */ > +}; > + > +static const struct renesas_family fam_rcar_gen2 __initconst = { > + .name = "R-Car Gen2", > + .reg = 0xff000044, /* PRR (Product Register) */ > +}; > + > +static const struct renesas_family fam_rcar_gen3 __initconst = { > + .name = "R-Car Gen3", > + .reg = 0xfff00044, /* PRR (Product Register) */ > +}; > + > +static const struct renesas_family fam_rzg __initconst = { > + .name = "RZ/G", > + .reg = 0xff000044, /* PRR (Product Register) */ > +}; > + > +static const struct renesas_family fam_shmobile __initconst = { > + .name = "SH-Mobile", > + .reg = 0xe600101c, /* CCCR (Common Chip Code Register) */ > +}; These seem to fall into two distinct categories, maybe there is a better way to group them. What device contain the two kinds of registers (PRR, CCCR)? Hardcoding the register address seems rather ugly here, so maybe there is a way to have two separate probe methods based on the surrounding register range, and then bind to that? > +static const struct of_device_id renesas_socs[] __initconst = { > +#ifdef CONFIG_ARCH_EMEV2 > + { .compatible = "renesas,emev2", .data = &soc_emev2 }, > +#endif > +#ifdef CONFIG_ARCH_R7S72100 > + { .compatible = "renesas,r7s72100", .data = &soc_rz_a1h }, > +#endif > +#ifdef CONFIG_ARCH_R8A73A4 I think the #ifdefs here will result in warnings for unused symbols when the Kconfig symbols are disabled. Arnd