From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753019AbcJJO3N (ORCPT ); Mon, 10 Oct 2016 10:29:13 -0400 Received: from mout.kundenserver.de ([212.227.126.135]:60604 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752648AbcJJO3M (ORCPT ); Mon, 10 Oct 2016 10:29:12 -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 0/4] soc: renesas: Identify SoC and register with the SoC bus Date: Mon, 10 Oct 2016 16:28:28 +0200 Message-ID: <6327808.hNezbnImkk@wuerfel> User-Agent: KMail/5.1.3 (Linux/4.4.0-34-generic; KDE/5.18.0; x86_64; ; ) In-Reply-To: <1475572167-29581-1-git-send-email-geert+renesas@glider.be> References: <1475572167-29581-1-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:HY0X+6ZAE8Bs+fEt1U8npDfydCg7chQOav/dku2orbjL1J7Bg+E em75dxuCs4/58rkWoSQ++ZhpC8c51kzSUJBVmSJmenQDIzawUreTffvQDKXW+y3ViA2GlY/ VMfBK/a4gjvuz93MJi+Gn+RXnACff/3hoOpa9FMVqLL11b5dnCxxywrL971uh2qMmErb8AX EtOEA1cR2An9rhgrj4vEw== X-UI-Out-Filterresults: notjunk:1;V01:K0:xehy/CLSsbU=:kp4dMweGwuvK+lzvZ2heqy fqFgMwmyeLIUZ80srnh2fZa1AEBUKpdXtPspkWpt+yic99s0trbIjqZuyNNjP3jgM4ApVdtYX jojya2l3VaXmVCXesTBoyMlbsX8Yh7N/7uVIWKKj0LHRghtWftIK2kDvQXRtqI3xhZj0iBuma IftMYerrlI133e+7oVaZERo/GAA7d9pqjHnIJZMY7R3nRgwL+Z4/gQ3rlxcf2A12JQ8vBGxbA O9D8d62OQ5KDA+2wIXienY3kbrJURp/1tGbWo1dQIJWaVioHvyAk195DusAUaD1JL0cDsntkh HSU96pM+6CyO/eN3RsZpP8nmIHLczsffLzqlXDGssBqifpYII3iY5u384tbZXAw/Vxg17E2gY qK/4NvxZTcXBGGjGtF7NWqHCHvE3DImnKqkf7BFX9y5coiE3V3ez9Qrqn3J15rBebhgFOGKJE MV7Ts1au6XjnuPwjqpN651CZ/SE1nEic42AKdGk5kA8MH1+ePt3kQT7jG0kWOjzSEnBwC/lz6 jU65MIJeAyjJkt6IJZ1ydRUHssGta0D2P6DEPCr+a+2gqL8smg/Xbg8W5riRBFbMIwkd4YKq7 C32HeUXaZXYp/lCFGYDacW51Wd2bXJv7ULBCiipCG5/eaeRbjo7OhYJdbUSR0OZIwaiVNYb1U ZeRzNALReXyVxi0FXQFm69QuxwHlDd5cVm3fpvm7Ustn8BZjAHG90W6EbQKqs3EgBGWTs6GMQ 0iKbYvbpnN5SXlQ5 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tuesday, October 4, 2016 11:09:23 AM CEST Geert Uytterhoeven wrote: > Hi all, > > Some Renesas SoCs may exist in different revisions, providing slightly > different functionalities (e.g. R-Car H3 ES1.x and ES2.0). This needs to > be catered for by drivers and/or platform code. The recently proposed > soc_device_match() API seems like a good fit to handle this. > > This patch series implements the core infrastructure to provide SoC and > revision information through the SoC bus for Renesas ARM SoCs. It > consists of 4 patches: > - Patch 1 avoids a crash when SoC revision information is needed and > provided early, > - Patch 2 (from Arnd) introduces the soc_device_match() API. > I don't know if, when, and through which channel this patch is > planned to go upstream, > - Patch 3 fixes a bug in soc_device_match(), causing a crash when > trying to match on an SoC attribute that is not provided (seen on > EMEV2, RZ/A, and R-Car M1A, which lack revision information), > - Patch 4 identifies Renesas SoCs and registers them with the SoC bus. > > Tested on (family, machine, soc_id, optional revision): > > Emma Mobile EV2, EMEV2 KZM9D Board, emev2 > RZ/A, Genmai, r7s72100 > R-Mobile, APE6EVM, r8a73a4, ES1.0 > R-Mobile, armadillo 800 eva, r8a7740, ES2.0 > R-Car Gen1, bockw, r8a7778 > R-Car Gen1, marzen, r8a7779, ES1.0 > R-Car Gen2, Lager, r8a7790, ES1.0 > R-Car Gen2, Koelsch, r8a7791, ES1.0 > R-Car Gen2, Gose, r8a7793, ES1.0 > R-Car Gen2, Alt, r8a7794, ES1.0 > R-Car Gen3, Renesas Salvator-X board based on r8a7795, r8a7795, ES1.0 > R-Car Gen3, Renesas Salvator-X board based on r8a7796, r8a7796, ES1.0 > SH-Mobile, KZM-A9-GT, sh73a0, ES2.0 As mentioned in the comment for the driver patch, I think this makes a lot of sense for the machines that have a revision register, in particular when the interpretation of that register is always done the same way, but I'm a bit skeptical about doing it in the same driver for machines that don't have the register. Matching by a device rather than the SoC platform also has the advantage that there is no need to maintain a list of compatible numbers in the driver. Arnd