All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sebastian Hesselbarth <sebastian.hesselbarth-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
To: Kevin Hao <haokexin-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: Stephen N Chivers
	<schivers-znpAAEhiOVUQrrorzV6ljw@public.gmane.org>,
	Chris Proctor <cproctor-znpAAEhiOVUQrrorzV6ljw@public.gmane.org>,
	Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>,
	devicetree <devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	Scott Wood <scottwood-KZfg59tc24xl57MIdRCFDg@public.gmane.org>,
	linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org
Subject: Re: Linux-3.14-rc2: Order of serial node compatibles in DTS files.
Date: Wed, 12 Feb 2014 12:26:14 +0100	[thread overview]
Message-ID: <52FB5A56.2050402@gmail.com> (raw)
In-Reply-To: <20140212103153.GC15434-2Y/eJ/Q4tBKYoDLmhA0N63T7OC0tnCxdQQ4Iyu8u01E@public.gmane.org>

On 02/12/14 11:31, Kevin Hao wrote:
> On Wed, Feb 12, 2014 at 09:30:00AM +0100, Sebastian Hesselbarth wrote:
>> On 02/12/2014 06:28 AM, Kevin Hao wrote:
>>> On Wed, Feb 12, 2014 at 10:21:58AM +1000, Stephen N Chivers wrote:
>>>> 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.
>>>
>>> How about the following fix?
>>>
>>> diff --git a/drivers/of/base.c b/drivers/of/base.c
>>> index ff85450d5683..ca91984d3c4b 100644
>>> --- a/drivers/of/base.c
>>> +++ b/drivers/of/base.c
>>> @@ -730,32 +730,40 @@ out:
>>>   }
>>>   EXPORT_SYMBOL(of_find_node_with_property);
>>>
>>> +static int of_match_type_name(const struct device_node *node,
>>> +				const struct of_device_id *m)
>>
>> I am fine with having a sub-function here, but it should rather be
>> named of_match_type_or_name.
>
> OK.
>
>>
>>> +{
>>> +	int match = 1;
>>> +
>>> +	if (m->name[0])
>>> +		match &= node->name && !strcmp(m->name, node->name);
>>> +
>>> +	if (m->type[0])
>>> +		match &= node->type && !strcmp(m->type, node->type);
>>> +
>>> +	return match;
>>> +}
>> [...]
>>> +	/* Check against matches without compatible string */
>>> +	m = matches;
>>> +	while (!m->compatible[0] && (m->name[0] || m->type[0])) {
>>
>> We shouldn't check for anything else than the sentinel here.
>> Although I guess yours will not quit early as mine did but that
>> way we don't have to worry about it.
>
> Yes, this is still buggy. I will change something like this:
>
> 	m = matches;
> 	/* Check against matches without compatible string */
> 	while (m->name[0] || m->type[0] || m->compatible[0]) {
> 		if (m->compatible[0]) {
> 			m++;
> 			continue;
> 		}
>
> 		match = of_match_type_name(node, m);
> 		if (match)
> 			return m;
> 		m++;
> 	}

You can cook it down to:

	m = matches;
	/* Check against matches without compatible string */
	while (m->name[0] || m->type[0] || m->compatible[0]) {
		if (!m->compatible[0] && of_match_type_or_name(node, m)
			return m;
		m++;
	}





--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

WARNING: multiple messages have this Message-ID (diff)
From: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
To: Kevin Hao <haokexin@gmail.com>
Cc: Chris Proctor <cproctor@csc.com.au>,
	Arnd Bergmann <arnd@arndb.de>,
	devicetree <devicetree@vger.kernel.org>,
	Stephen N Chivers <schivers@csc.com.au>,
	Scott Wood <scottwood@freescale.com>,
	linuxppc-dev@lists.ozlabs.org
Subject: Re: Linux-3.14-rc2: Order of serial node compatibles in DTS files.
Date: Wed, 12 Feb 2014 12:26:14 +0100	[thread overview]
Message-ID: <52FB5A56.2050402@gmail.com> (raw)
In-Reply-To: <20140212103153.GC15434@pek-khao-d1.corp.ad.wrs.com>

On 02/12/14 11:31, Kevin Hao wrote:
> On Wed, Feb 12, 2014 at 09:30:00AM +0100, Sebastian Hesselbarth wrote:
>> On 02/12/2014 06:28 AM, Kevin Hao wrote:
>>> On Wed, Feb 12, 2014 at 10:21:58AM +1000, Stephen N Chivers wrote:
>>>> 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.
>>>
>>> How about the following fix?
>>>
>>> diff --git a/drivers/of/base.c b/drivers/of/base.c
>>> index ff85450d5683..ca91984d3c4b 100644
>>> --- a/drivers/of/base.c
>>> +++ b/drivers/of/base.c
>>> @@ -730,32 +730,40 @@ out:
>>>   }
>>>   EXPORT_SYMBOL(of_find_node_with_property);
>>>
>>> +static int of_match_type_name(const struct device_node *node,
>>> +				const struct of_device_id *m)
>>
>> I am fine with having a sub-function here, but it should rather be
>> named of_match_type_or_name.
>
> OK.
>
>>
>>> +{
>>> +	int match = 1;
>>> +
>>> +	if (m->name[0])
>>> +		match &= node->name && !strcmp(m->name, node->name);
>>> +
>>> +	if (m->type[0])
>>> +		match &= node->type && !strcmp(m->type, node->type);
>>> +
>>> +	return match;
>>> +}
>> [...]
>>> +	/* Check against matches without compatible string */
>>> +	m = matches;
>>> +	while (!m->compatible[0] && (m->name[0] || m->type[0])) {
>>
>> We shouldn't check for anything else than the sentinel here.
>> Although I guess yours will not quit early as mine did but that
>> way we don't have to worry about it.
>
> Yes, this is still buggy. I will change something like this:
>
> 	m = matches;
> 	/* Check against matches without compatible string */
> 	while (m->name[0] || m->type[0] || m->compatible[0]) {
> 		if (m->compatible[0]) {
> 			m++;
> 			continue;
> 		}
>
> 		match = of_match_type_name(node, m);
> 		if (match)
> 			return m;
> 		m++;
> 	}

You can cook it down to:

	m = matches;
	/* Check against matches without compatible string */
	while (m->name[0] || m->type[0] || m->compatible[0]) {
		if (!m->compatible[0] && of_match_type_or_name(node, m)
			return m;
		m++;
	}

  parent reply	other threads:[~2014-02-12 11:26 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-02-06  2:09 arch/powerpc/math-emu/mtfsf.c - incorrect mask? Stephen N Chivers
2014-02-06  8:26 ` Gabriel Paubert
2014-02-07  1:27   ` Stephen N Chivers
2014-02-07 10:10     ` Gabriel Paubert
2014-02-07 20:49       ` James Yang
2014-02-09 19:42         ` Stephen N Chivers
2014-02-10 16:50           ` James Yang
2014-02-10 11:03         ` Gabriel Paubert
2014-02-10 11:17           ` David Laight
2014-02-10 12:21             ` Gabriel Paubert
2014-02-10 12:32               ` David Laight
2014-02-10 13:00                 ` Gabriel Paubert
2014-02-10 17:03           ` James Yang
2014-02-11  7:26             ` Gabriel Paubert
2014-02-11 20:57               ` Linux-3.14-rc2: Order of serial node compatibles in DTS files Stephen N Chivers
     [not found]                 ` <OF6F6A0029.3B20EF5B-ONCA257C7C.0071BFDA-CA257C7C.00732AD3-SmukeSwxQOQ@public.gmane.org>
2014-02-11 22:33                   ` Kumar Gala
2014-02-11 22:33                     ` Kumar Gala
     [not found]                     ` <63AEBD99-AA87-4FD7-BBDA-0CE419959F14-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r@public.gmane.org>
2014-02-11 22:51                       ` Sebastian Hesselbarth
2014-02-11 22:51                         ` Sebastian Hesselbarth
2014-02-11 23:38                         ` Stephen N Chivers
     [not found]                           ` <OFB203CA90.B048F8AA-ONCA257C7C.0081A816-CA257C7C.0081DCE3-SmukeSwxQOQ@public.gmane.org>
2014-02-11 23:43                             ` Sebastian Hesselbarth
2014-02-11 23:43                               ` Sebastian Hesselbarth
     [not found]                               ` <52FAB5A7.7080208-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2014-02-12 11:00                                 ` Arnd Bergmann
2014-02-12 11:00                                   ` Arnd Bergmann
     [not found]                         ` <52FAA97F.4060600-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2014-02-11 23:41                           ` Scott Wood
2014-02-11 23:41                             ` Scott Wood
     [not found]                             ` <1392162080.6733.404.camel-88ow+0ZRuxG2UiBs7uKeOtHuzzzSOjJt@public.gmane.org>
2014-02-11 23:46                               ` Sebastian Hesselbarth
2014-02-11 23:46                                 ` Sebastian Hesselbarth
     [not found]                                 ` <52FAB65C.4090201-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2014-02-12  0:21                                   ` Stephen N Chivers
2014-02-12  0:21                                     ` Stephen N Chivers
     [not found]                                     ` <OF9BA019D5.46DA1E29-ONCA257C7D.000089EA-CA257C7D.00020333-SmukeSwxQOQ@public.gmane.org>
2014-02-12  5:28                                       ` Kevin Hao
2014-02-12  5:28                                         ` Kevin Hao
     [not found]                                         ` <20140212052816.GA15434-2Y/eJ/Q4tBKYoDLmhA0N63T7OC0tnCxdQQ4Iyu8u01E@public.gmane.org>
2014-02-12  8:30                                           ` Sebastian Hesselbarth
2014-02-12  8:30                                             ` Sebastian Hesselbarth
     [not found]                                             ` <52FB3108.3000202-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2014-02-12 10:31                                               ` Kevin Hao
2014-02-12 10:31                                                 ` Kevin Hao
     [not found]                                                 ` <20140212103153.GC15434-2Y/eJ/Q4tBKYoDLmhA0N63T7OC0tnCxdQQ4Iyu8u01E@public.gmane.org>
2014-02-12 11:26                                                   ` Sebastian Hesselbarth [this message]
2014-02-12 11:26                                                     ` Sebastian Hesselbarth
     [not found]                                                     ` <52FB5A56.2050402-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2014-02-12 11:32                                                       ` Kevin Hao
2014-02-12 11:32                                                         ` Kevin Hao
2014-02-12  8:25                                       ` Sebastian Hesselbarth
2014-02-12  8:25                                         ` Sebastian Hesselbarth
     [not found]                                         ` <52FB2FF4.6060905-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2014-02-12 10:35                                           ` Kevin Hao
2014-02-12 10:35                                             ` Kevin Hao

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=52FB5A56.2050402@gmail.com \
    --to=sebastian.hesselbarth-re5jqeeqqe8avxtiumwx3w@public.gmane.org \
    --cc=arnd-r2nGTMty4D4@public.gmane.org \
    --cc=cproctor-znpAAEhiOVUQrrorzV6ljw@public.gmane.org \
    --cc=devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=haokexin-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
    --cc=linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org \
    --cc=schivers-znpAAEhiOVUQrrorzV6ljw@public.gmane.org \
    --cc=scottwood-KZfg59tc24xl57MIdRCFDg@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 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.