All of lore.kernel.org
 help / color / mirror / Atom feed
From: Arnd Bergmann <arnd@arndb.de>
To: Geert Uytterhoeven <geert+renesas@glider.be>
Cc: Simon Horman <horms@verge.net.au>,
	Magnus Damm <magnus.damm@gmail.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Yangbo Lu <yangbo.lu@nxp.com>, Lee Jones <lee.jones@linaro.org>,
	Dirk Behme <dirk.behme@de.bosch.com>,
	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	[thread overview]
Message-ID: <6327808.hNezbnImkk@wuerfel> (raw)
In-Reply-To: <1475572167-29581-1-git-send-email-geert+renesas@glider.be>

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

WARNING: multiple messages have this Message-ID (diff)
From: arnd@arndb.de (Arnd Bergmann)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 0/4] soc: renesas: Identify SoC and register with the SoC bus
Date: Mon, 10 Oct 2016 16:28:28 +0200	[thread overview]
Message-ID: <6327808.hNezbnImkk@wuerfel> (raw)
In-Reply-To: <1475572167-29581-1-git-send-email-geert+renesas@glider.be>

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

  parent reply	other threads:[~2016-10-10 14:29 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-10-04  9:09 [PATCH 0/4] soc: renesas: Identify SoC and register with the SoC bus Geert Uytterhoeven
2016-10-04  9:09 ` [PATCH 1/4] base: soc: Early register bus when needed Geert Uytterhoeven
2016-10-10 14:15   ` Arnd Bergmann
2016-10-10 14:15     ` Arnd Bergmann
2016-10-04  9:09 ` [PATCH 2/4] base: soc: Introduce soc_device_match() interface Geert Uytterhoeven
2016-10-19  8:26   ` Greg Kroah-Hartman
2016-10-04  9:09 ` [PATCH 3/4] base: soc: Check for NULL SoC device attributes Geert Uytterhoeven
2016-10-10 14:13   ` Arnd Bergmann
2016-10-10 14:13     ` Arnd Bergmann
2016-10-19  8:26   ` Greg Kroah-Hartman
2016-10-04  9:09 ` [PATCH/RFC 4/4] soc: renesas: Identify SoC and register with the SoC bus Geert Uytterhoeven
2016-10-05 12:17   ` Dirk Behme
2016-10-05 12:17     ` Dirk Behme
2016-10-10 14:23   ` Arnd Bergmann
2016-10-10 14:23     ` Arnd Bergmann
2016-10-19  8:02     ` Geert Uytterhoeven
2016-10-19  8:02       ` Geert Uytterhoeven
2016-10-19 10:59       ` Arnd Bergmann
2016-10-19 10:59         ` Arnd Bergmann
2016-10-21 18:16         ` Geert Uytterhoeven
2016-10-21 18:16           ` Geert Uytterhoeven
2016-10-21 21:16           ` Arnd Bergmann
2016-10-21 21:16             ` Arnd Bergmann
2016-10-22  7:44             ` Geert Uytterhoeven
2016-10-22  7:44               ` Geert Uytterhoeven
2016-10-29 21:27               ` Arnd Bergmann
2016-10-29 21:27                 ` Arnd Bergmann
2016-10-31 10:30                 ` Geert Uytterhoeven
2016-10-31 10:30                   ` Geert Uytterhoeven
2016-10-10 14:28 ` Arnd Bergmann [this message]
2016-10-10 14:28   ` [PATCH 0/4] " Arnd Bergmann
2016-10-19  8:10   ` Geert Uytterhoeven
2016-10-19  8:10     ` Geert Uytterhoeven
2016-10-19  8:10     ` Geert Uytterhoeven
2016-10-19 10:32     ` Arnd Bergmann
2016-10-19 10:32       ` Arnd Bergmann
2016-10-19 10:32       ` Arnd Bergmann

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=6327808.hNezbnImkk@wuerfel \
    --to=arnd@arndb.de \
    --cc=dirk.behme@de.bosch.com \
    --cc=geert+renesas@glider.be \
    --cc=gregkh@linuxfoundation.org \
    --cc=horms@verge.net.au \
    --cc=lee.jones@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-renesas-soc@vger.kernel.org \
    --cc=magnus.damm@gmail.com \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.