From: ezequiel.garcia@free-electrons.com (Ezequiel Garcia)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC/PATCH] ARM: mvebu: Don't apply the quirks if the SoC revision is unknown
Date: Tue, 10 Jun 2014 10:40:40 -0300 [thread overview]
Message-ID: <20140610134040.GA1991@arch.cereza> (raw)
In-Reply-To: <5621673.VW5TXctBgm@wuerfel>
Hi Arnd,
Thanks for taking a look.
On 10 Jun 10:21 AM, Arnd Bergmann wrote:
> On Monday 09 June 2014 16:27:16 Ezequiel Garcia wrote:
> > We currently skip the I2C and thermal quirks only if the SoC revision is
> > known to be one that does not need them. If the SoC revision cannot be
> > obtained, the current behavior is to apply the quirk assuming it's needed.
> >
> > This commit changes this, by requiring the SoC revision to be known in order
> > to peform a quirk.
>
> This clearly needs a better description if we want to apply it. We had
> a rather long discussion when the code was first added exactly this
> way and you should explain which of the assumptions we made back then
> are now incorrect.
>
> Is it ever wrong (as opposed to inefficient) to apply the quirk even on a
> newer SoC?
>
Yes, for the thermal quirk it is wrong as it consists in changing the compatible
string and moving the registers around.
So if you apply the quirk on a SoC that doesn't need it, thermal won't work.
> IIRC, the reasoning was that almost all machines have the new SoC version,
Agreed, and that's why I think it's better to *not* apply the quirk unless the
SoC revision can be properly obtained and matched as needing it.
> so they should have their DTs marked with the correct IDs already.
>
Hm.. I guess the I2C and thermal quirks don't work the same way. Here's how
the latter works.
The driver supports two different compatible strings:
"armada375-thermal" and "armada375-z1-thermal". However, we don't expect the
user to know the revision, so the quirk code detects the SoC revision and
changes the compatible string if needed.
In addition, given the register offsets are different in the Z1 revision,
we workaround that by moving them in the quirk code, before the thermal
driver probes.
So, there's no "correct ID in the devicetree", as we assume the devicetree
works for the new SoC and only apply changes if we detect the SoC revision
needs the workaround.
Under this scheme, this commit makes a requirement to know the SoC revision
before applying a quirk, where the current code applies it blindly.
However, I'm not sure if this is correct for the I2C quirk. Maybe I was
too fast assuming it was.
--
Ezequiel Garc?a, Free Electrons
Embedded Linux, Kernel and Android Engineering
http://free-electrons.com
next prev parent reply other threads:[~2014-06-10 13:40 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-09 19:27 [RFC/PATCH] ARM: mvebu: Don't apply the quirks if the SoC revision is unknown Ezequiel Garcia
2014-06-10 8:21 ` Arnd Bergmann
2014-06-10 13:40 ` Ezequiel Garcia [this message]
2014-06-10 15:39 ` Gregory CLEMENT
2014-06-10 15:49 ` Ezequiel Garcia
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=20140610134040.GA1991@arch.cereza \
--to=ezequiel.garcia@free-electrons.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 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).