From: arnd@arndb.de (Arnd Bergmann)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2 2/2] i2c: mv64xxx: Fix bus hang on A0 version of the Armada XP SoCs
Date: Tue, 7 Jan 2014 10:03:30 +0100 [thread overview]
Message-ID: <201401071003.31309.arnd@arndb.de> (raw)
In-Reply-To: <52CA72BF.10604@free-electrons.com>
On Monday 06 January 2014, Gregory CLEMENT wrote:
> > Relying on the soc id patch for a "stable" bug fix seems a little
> > far-reaching to me. I would be happier to first try to do a local
> > detection based on the i2c bus device node itself. Do you know how
>
> It was my first proposal in case adding the soc id detection was
> a too big things. But it turned out that the amount of code is very
> low so I really think it worth adding it along the fix. Device tree
> is supposed to be stable so as soon as we add something in it we are
> supposed support it forever. Moreover using device tree for something
> we can probe is counter productive.
I would still be happier if we did both and only need to check the
SoC version if the device is in the "possibly broken" category
but default to the existing behavior.
My main concern is that this patch is adding platform code that we'd
otherwise have to carry in the kernel indefinitely. I agree that
it's best if we can probe stuff automatically, but that doesn't normally
mean looking at an unrelated piece of information. If the i2c controller
registers themselves tell us whether this device is broken or not,
we should use that information. Looking at a global SoC version register
however is more like checking a board ID in the pre-DT days where the
board number is the only information we have and everything is
derived from that.
> > common the A0 revision is? You mention "early release of the
> > OpenBlocks AX3-4 boards". Any others that you suspect? If not,
>
> No, from the info I gathered I expected that only OpenBlocks AX3-4
> would be the only product shipped with an A0 version and as I said
> it should be only a limit amount of them.
Ok, good. So we really only need to worry about this one board for
now and can make all the others default to normal operation without
checking the SoC version.
Another idea: Could we have a quirk in the mvebu platform code for
the AX3-4 to check the SoC version and then change the property for
the i2c controller based on whether we expect it to work or not?
This way, we wouldn't even need an interface between the platform
code and the driver code.
Arnd
next prev parent reply other threads:[~2014-01-07 9:03 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-03 9:59 [PATCH v2 0/2] Fix i2c bus hang on A0 version of the Armada XP SoCs Gregory CLEMENT
2014-01-03 9:59 ` [PATCH v2 1/2] ARM: mvebu: Add support to get the ID and the revision of a SoC Gregory CLEMENT
2014-01-03 14:47 ` Andrew Lunn
2014-01-03 14:51 ` Gregory CLEMENT
2014-01-03 15:13 ` Gregory CLEMENT
2014-01-03 16:41 ` Andrew Lunn
2014-01-03 19:30 ` Gregory CLEMENT
2014-01-03 18:48 ` Thomas Petazzoni
2014-01-03 19:25 ` Gregory CLEMENT
2014-01-03 18:59 ` Jason Gunthorpe
2014-01-03 19:35 ` Gregory CLEMENT
2014-01-05 14:25 ` Arnd Bergmann
2014-01-05 15:40 ` Andrew Lunn
2014-01-05 17:27 ` Jason Gunthorpe
2014-01-05 17:37 ` Sebastian Hesselbarth
2014-01-05 23:07 ` Jason Gunthorpe
2014-01-05 23:12 ` Sebastian Hesselbarth
2014-01-05 23:40 ` Jason Gunthorpe
2014-01-06 0:05 ` Sebastian Hesselbarth
2014-01-06 0:17 ` Andrew Lunn
2014-01-06 9:55 ` Gregory CLEMENT
2014-01-06 10:10 ` Gregory CLEMENT
2014-01-05 19:17 ` Arnd Bergmann
2014-01-05 23:51 ` Andrew Lunn
2014-01-06 15:37 ` Arnd Bergmann
2014-01-06 16:24 ` Andrew Lunn
2014-01-07 14:41 ` Arnd Bergmann
2014-01-06 10:28 ` Gregory CLEMENT
2014-01-03 9:59 ` [PATCH v2 2/2] i2c: mv64xxx: Fix bus hang on A0 version of the Armada XP SoCs Gregory CLEMENT
2014-01-03 12:20 ` Gregory CLEMENT
2014-01-03 18:49 ` Thomas Petazzoni
2014-01-03 19:31 ` Gregory CLEMENT
2014-01-05 14:33 ` Arnd Bergmann
2014-01-06 9:09 ` Gregory CLEMENT
2014-01-07 9:03 ` Arnd Bergmann [this message]
2014-01-07 13:17 ` Gregory CLEMENT
2014-01-07 20:50 ` 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=201401071003.31309.arnd@arndb.de \
--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;
as well as URLs for NNTP newsgroup(s).