On 02/12/2014 01:21 AM, Stephen N Chivers wrote:
Sebastian Hesselbarth <sebastian.hesselbarth@xxxxxxxxx> wrote on
02/12/2014 10:46:36 AM:
From: Sebastian Hesselbarth <sebastian.hesselbarth@xxxxxxxxx>
To: Scott Wood <scottwood@xxxxxxxxxxxxx>
Cc: Kumar Gala <galak@xxxxxxxxxxxxxxxxxxx>, Stephen N Chivers
<schivers@xxxxxxxxxx>, Chris Proctor <cproctor@xxxxxxxxxx>,
linuxppc-dev@xxxxxxxxxxxxxxxx, Arnd Bergmann <arnd@xxxxxxxx>,
devicetree <devicetree@xxxxxxxxxxxxxxx>
Date: 02/12/2014 11:04 AM
Subject: Re: Linux-3.14-rc2: Order of serial node compatibles in DTS
files.
On 02/12/2014 12:41 AM, Scott Wood wrote:
Regardless of whether .type = "serial" gets removed, it seems wrong for
of_match_node() to accept a .type-only match (or .name, or anything else
that doesn't involve .compatible) before it accepts a compatible match
other than the first in the compatible property.
Right, I thought about it and came to the same conclusion. I sent a
patch a second ago to prefer .compatible != NULL matches over those
with .compatible == NULL.
Would be great if Stephen can re-test that. If it solves the issue, I
can send a patch tomorrow.
Done.
But, the Interrupt Controller (MPIC)
goes AWOL and it is down hill from there.
The MPIC is specified in the DTS as:
mpic: pic@40000 {
interrupt-controller;
#address-cells = <0>;
#interrupt-cells = <2>;
reg = <0x40000 0x40000>;
compatible = "chrp,open-pic";
device_type = "open-pic";
big-endian;
};
The board support file has the standard mechanism for allocating
the PIC:
struct mpic *mpic;
mpic = mpic_alloc(NULL, 0, 0, 0, 256, " OpenPIC ");
BUG_ON(mpic == NULL);
mpic_init(mpic);
I checked for damage in applying the patch and it has applied
correctly.
Hmm, I did a mistake in the patch:
- while (m->name[0] || m->type[0]) {
+ while (m->compatible[0] || m->name[0] || m->type[0]) {
for the second added match. Otherwise, the matches are not
evaluated down to the sentinel but the loop quits on the first
match table entry without .name and .type set.
Sebastian
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
