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 V2 2/2] i2c: mv64xxx: Remove internal compatible string from Documentation
Date: Mon, 28 Jul 2014 16:35:29 +0200	[thread overview]
Message-ID: <6346429.sjQYojn1ot@wuerfel> (raw)
In-Reply-To: <20140728141217.GE2891@lunn.ch>

On Monday 28 July 2014 16:12:17 Andrew Lunn wrote:
> > 
> > I remember this being discussed when the quirk was initially added,
> > but it seemed cleaner to handle this in the platform code at the time
> > when it was just for one particular board. Now that it's basically
> > an accepted feature of the i2c device that you have to know the
> > SoC version, that should probably become a proper API.
> > 
> > Also, we now have drivers/soc/ and can move the soc-id code there
> > with a publically documented API.
> 
> Getting the SoC ID and revision seems like something that should be
> generic. Would it be better to make this part of drivers/base/soc.c?
> mvebu already does a soc_device_register() with the relevant
> information.
> 
> Add a call something like:
> 
> /*
>  * Return the soc device attributes for a given soc_dev. If soc_dev is NULL,
>  * the first device on the soc bus is returned.
>  */
> struct soc_device_attribute *soc_attribute_get(struct soc_device * soc_dev);

Interesting idea, yes.

There could also be a higher-level function that does a strcmp() in addition,
so that a driver can do some variation of

	if (soc_name_is("Armada XP") && soc_revision_is("A0"))
		...

	Arnd

  reply	other threads:[~2014-07-28 14:35 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-07-26 17:20 [Patch V2 0/2] Generalize use of i2c quirk for Armada XP Andrew Lunn
2014-07-26 17:20 ` [Patch V2 1/2] ARM: mvebu: armada xp: Generalize use of i2c quirk Andrew Lunn
2014-10-15 15:25   ` Jason Cooper
2014-07-26 17:20 ` [Patch V2 2/2] i2c: mv64xxx: Remove internal compatible string from Documentation Andrew Lunn
2014-07-28 13:22   ` Jason Cooper
2014-07-28 13:27     ` Andrew Lunn
2014-07-28 13:51       ` Arnd Bergmann
2014-07-28 14:12         ` Andrew Lunn
2014-07-28 14:35           ` Arnd Bergmann [this message]
2014-07-28 15:25             ` Andrew Lunn
2014-07-28 15:47               ` Arnd Bergmann
2014-07-28 15:52                 ` Andrew Lunn
2014-07-28 16:03                   ` Arnd Bergmann
2014-07-28 18:29         ` Jason Gunthorpe
2014-07-29 10:21           ` Arnd Bergmann
2014-07-30  8:44         ` Maxime Ripard

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=6346429.sjQYojn1ot@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