public inbox for linux-arm-kernel@lists.infradead.org
 help / color / mirror / Atom feed
From: arnd@arndb.de (Arnd Bergmann)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 0/4] Introducing Exynos ChipId driver
Date: Mon, 05 May 2014 17:01:53 +0200	[thread overview]
Message-ID: <5374218.SlGnAKNqhD@wuerfel> (raw)
In-Reply-To: <4239261.HFHm7SU1iH@wuerfel>

On Monday 05 May 2014 16:58:14 Arnd Bergmann wrote:
> > Also for platsmp.c and pm.c I can think of following approaches
> > 1: Keep these macros till we get generic solution?
> > 2: Allow chipid driver to expose APIs to check SoC id and SoC revisions 
> > till we get
> > generic solution. So that at least we can remove #ifdef  based macros
> > as soc_is_exynosXYZ.
> > 3: Use of "of_flat_dt_is_compatible" or similar APIs in these machine files 
> > till we get
> > generic solution. For some cases where we want to know SoC revision let us
> > map chipid register and get revision there itself.
> > 
> > Please let me know what approach you think will be good?
> 
> I think 1 or 2 would be better than 3. Between those two, I'm undecided,
> but I think either way the SoC specific values would be better kept in the
> mach-samsung directory than in plat/cpu.h or linux/exynos-chipid.h.

Actually, a good compromise for now would be to add the chipid driver
to mach-exynos instead of drivers/bus. This way you can keep the uses
of the ID local to the exynos platform code until it's no longer needed.
Then it can get moved out to drivers/soc to be shared with arm64.

	Arnd

  reply	other threads:[~2014-05-05 15:01 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-05-03  6:11 [PATCH 0/4] Introducing Exynos ChipId driver Pankaj Dubey
2014-05-03  6:11 ` [PATCH 1/4] ARM: EXYNOS: remove soc_is_exynos4/5 from exynos.c Pankaj Dubey
2014-05-03  6:11 ` [PATCH 2/4] ARM: EXYNOS: remove unused header inclusion from hotplug.c Pankaj Dubey
2014-05-03  6:11 ` [PATCH 3/4] misc: exynos-chipid: Add Exynos Chipid driver support Pankaj Dubey
2014-05-05  7:57   ` Krzysztof Kozlowski
2014-05-05  9:28     ` Pankaj Dubey
2014-05-03  6:11 ` [PATCH 4/4] ARM: EXYNOS: Refactoring to remove soc_is_exynosXXXX macros from exynos Pankaj Dubey
2014-05-03 15:02 ` [PATCH 0/4] Introducing Exynos ChipId driver Arnd Bergmann
2014-05-05  9:23   ` Pankaj Dubey
2014-05-05 14:58     ` Arnd Bergmann
2014-05-05 15:01       ` Arnd Bergmann [this message]
2014-05-06  6:57       ` Pankaj Dubey
2014-05-06  7:24         ` Arnd Bergmann
2014-05-12  1:47       ` Olof Johansson
2014-05-12  9:47         ` Arnd Bergmann
2014-05-05 15:34   ` Rob Herring
2014-05-06  7:22     ` 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=5374218.SlGnAKNqhD@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