From: Mark Brown <broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
To: Mika Westerberg
<mika.westerberg-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
Cc: Jarkko Nikula
<jarkko.nikula-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>,
linux-spi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [PATCH RESEND] spi: spidev: Allow matching DT compatible strings from ACPI
Date: Wed, 29 Jun 2016 17:21:27 +0100 [thread overview]
Message-ID: <20160629162127.GA6247@sirena.org.uk> (raw)
In-Reply-To: <20160629091304.GP1711-3PARRvDOhMZrdx17CPfAsdBPR1lH4CV8@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 1077 bytes --]
On Wed, Jun 29, 2016 at 12:13:04PM +0300, Mika Westerberg wrote:
> On Tue, Jun 28, 2016 at 05:18:22PM +0100, Mark Brown wrote:
> > So you're saying that it's not possible for ACPI to use anything
> > *except* an explicitly listed compatible string to bind? What we want
> > to avoid is any ACPI tables that explicitly list spidev since that's a
> > total abstraction failure.
> That's exactly what I'm saying. We never match using the node name
> (which is always 32-bit "string" like "SPI0"). For PRP0001 match to
> succeeed you need to have "compatible" property.
> Without the "compatible" property you get a warning from ACPI core:
> \_SB.SPI1.SPID requires 'compatible' property
> and it will not match anything.
But can that compatible string be spidev and be matched via the paths DT
uses while still ensuring that enough of the OF matching code is enabled
to cause the check to warn? That's the problem.
Life would be a lot eaiser if Intel would use DT where it's appropriate,
or if the OF in ACPI stuff were more transparent and needed fewer
special cases.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]
next prev parent reply other threads:[~2016-06-29 16:21 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-06-27 11:34 [PATCH RESEND] spi: spidev: Allow matching DT compatible strings from ACPI Mika Westerberg
[not found] ` <1467027248-6191-1-git-send-email-mika.westerberg-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
2016-06-27 12:24 ` Mark Brown
[not found] ` <20160627122448.GU28202-GFdadSzt00ze9xe1eoZjHA@public.gmane.org>
2016-06-28 9:22 ` Mika Westerberg
[not found] ` <20160628092234.GG1711-3PARRvDOhMZrdx17CPfAsdBPR1lH4CV8@public.gmane.org>
2016-06-28 11:47 ` Mark Brown
[not found] ` <20160628114742.GM17217-GFdadSzt00ze9xe1eoZjHA@public.gmane.org>
2016-06-28 14:35 ` Mika Westerberg
[not found] ` <20160628143528.GK1711-3PARRvDOhMZrdx17CPfAsdBPR1lH4CV8@public.gmane.org>
2016-06-28 15:07 ` Mark Brown
[not found] ` <20160628150752.GO17217-GFdadSzt00ze9xe1eoZjHA@public.gmane.org>
2016-06-28 15:23 ` Mika Westerberg
[not found] ` <20160628152338.GN1711-3PARRvDOhMZrdx17CPfAsdBPR1lH4CV8@public.gmane.org>
2016-06-28 16:18 ` Mark Brown
[not found] ` <20160628161822.GQ17217-GFdadSzt00ze9xe1eoZjHA@public.gmane.org>
2016-06-29 9:13 ` Mika Westerberg
[not found] ` <20160629091304.GP1711-3PARRvDOhMZrdx17CPfAsdBPR1lH4CV8@public.gmane.org>
2016-06-29 16:21 ` Mark Brown [this message]
[not found] ` <20160629162127.GA6247-GFdadSzt00ze9xe1eoZjHA@public.gmane.org>
2016-06-29 16:34 ` Mika Westerberg
[not found] ` <20160629163420.GC1711-3PARRvDOhMZrdx17CPfAsdBPR1lH4CV8@public.gmane.org>
2016-06-29 18:31 ` Mark Brown
[not found] ` <20160629183101.GN6247-GFdadSzt00ze9xe1eoZjHA@public.gmane.org>
2016-06-29 18:51 ` Mika Westerberg
[not found] ` <20160629185155.GG1711-3PARRvDOhMZrdx17CPfAsdBPR1lH4CV8@public.gmane.org>
2016-06-29 19:20 ` Mark Brown
[not found] ` <20160629192059.GV6247-GFdadSzt00ze9xe1eoZjHA@public.gmane.org>
2016-06-30 12:49 ` Mika Westerberg
[not found] ` <20160630124931.GD23527-3PARRvDOhMZrdx17CPfAsdBPR1lH4CV8@public.gmane.org>
2016-07-01 10:12 ` Mark Brown
2016-07-01 10:19 ` Mika Westerberg
[not found] ` <20160701101912.GL23527-3PARRvDOhMZrdx17CPfAsdBPR1lH4CV8@public.gmane.org>
2016-07-01 14:50 ` Mark Brown
[not found] ` <20160701145035.GP6247-GFdadSzt00ze9xe1eoZjHA@public.gmane.org>
2016-07-02 9:01 ` Mika Westerberg
[not found] ` <20160702090114.GS23527-3PARRvDOhMZrdx17CPfAsdBPR1lH4CV8@public.gmane.org>
2016-07-02 10:15 ` Mark Brown
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=20160629162127.GA6247@sirena.org.uk \
--to=broonie-dgejt+ai2ygdnm+yrofe0a@public.gmane.org \
--cc=jarkko.nikula-VuQAYsv1563Yd54FQh9/CA@public.gmane.org \
--cc=linux-spi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=mika.westerberg-VuQAYsv1563Yd54FQh9/CA@public.gmane.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).