From: broonie@opensource.wolfsonmicro.com (Mark Brown)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] ARM: S3C64XX: Fix clkdev device names for I2C clocks
Date: Wed, 31 Aug 2011 11:25:30 +0100 [thread overview]
Message-ID: <20110831102530.GV2061@opensource.wolfsonmicro.com> (raw)
In-Reply-To: <CAJuYYwQikeoPbDX5DV4Y_HzOz2t04otLEUMye8CPpGLvhjwhyw@mail.gmail.com>
On Wed, Aug 31, 2011 at 01:44:20PM +0530, Thomas Abraham wrote:
> There are two instances of clock with name i2c registered for s3c64xx.
> One has a devname and the other does not. So this continued to work.
> The i2c0 clock instance did not get a devname because its instance id
> was -1 (prior to clkdev support).
Not having devname will *work* - the problem is that it'll work too
often and return the wrong clock whenever anything goes wrong.
> If a devname is added to i2c0 clock instance for s3c64xx, it should be
> set to "s3c2440-i2c". If the devname is set to "s3c2440-i2c.0", then
> CONFIG_S3C_DEV_I2C1 will have to defined for s3c64xx, otherwise, as
> per arch/arm/plat-samsung/dev-i2c0.c, the platform device id for i2c0
> instance will be -1 and the clock lookup for i2c0 will fail.
All of which is just asking for fragility; the ifdefs for renumbering
the device are really unhelpful here - the system always has two I2C
controllers and the numbering is going to change depending on which
boards are built in so you can break things by enabling support for a
second board.
Frankly I'm not convinced that all this dancing about with explicitly
selecting which devices to enable is worth it; the space savings are
extremely small and the complexity regularly causes issues that just
shouldn't exist.
prev parent reply other threads:[~2011-08-31 10:25 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-08-30 21:30 [PATCH] ARM: S3C64XX: Fix clkdev device names for I2C clocks Mark Brown
2011-08-30 23:48 ` Kyungmin Park
2011-08-31 0:21 ` Mark Brown
2011-08-31 8:14 ` Thomas Abraham
2011-08-31 10:25 ` Mark Brown [this message]
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=20110831102530.GV2061@opensource.wolfsonmicro.com \
--to=broonie@opensource.wolfsonmicro.com \
--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 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.