From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ian Campbell Subject: Re: [PATCH 09/10] xen: arm: Drop device_tree_node_compatible Date: Wed, 18 Jun 2014 16:20:02 +0100 Message-ID: <1403104802.6568.83.camel@kazak.uk.xensource.com> References: <1402919079.14907.22.camel@kazak.uk.xensource.com> <1402919103-29642-9-git-send-email-ian.campbell@citrix.com> <1403102868.6568.68.camel@kazak.uk.xensource.com> <53A1A8F1.7020203@linaro.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <53A1A8F1.7020203@linaro.org> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Julien Grall Cc: Stefano Stabellini , Naresh Bhat , tim@xen.org, xen-devel@lists.xen.org, Roy Franz , Fu Wei List-Id: xen-devel@lists.xenproject.org On Wed, 2014-06-18 at 15:57 +0100, Julien Grall wrote: > On 06/18/2014 03:47 PM, Ian Campbell wrote: > > On Wed, 2014-06-18 at 15:43 +0100, Stefano Stabellini wrote: > >> On Mon, 16 Jun 2014, Ian Campbell wrote: > >>> Instead use fdt_node_check_compatible from libfdt. > >> > >> Unfortunately the two functions are not equivalent: > >> fdt_node_check_compatible uses memcmp while device_tree_node_compatible > >> uses strcasecmp that ignores cases. > > > > I hadn't spotted this. > > > > They can't both be spec complaint I think. I expect > > fdt_node_check_compatible (from libfdt) is more likely to be the one > > which is correct. > > In dt_device_is_compatible we use strcasecmp as Linux does. > > For Linux, it looks like the use a less restrictive way in generic code > (i.e strcasecmp) and more restrictive on SPARC (i.e strcmp) > > I can't find anything in the spec to say which one is better. But I > think we want to stay compatible with Linux we have to keep > device_tree_node_compatible and use it in place of > fdt_node_check_compatible. Urk, what a mess. This patch was pretty tangential to the series, I'll just drop it. Ian. > We could also modify the latter function for our convenience. > > Regards. >