[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5316F6ED.8040204@ti.com>
Date: Wed, 5 Mar 2014 12:05:33 +0200
From: Tomi Valkeinen <tomi.valkeinen@...com>
To: Philipp Zabel <p.zabel@...gutronix.de>
CC: Grant Likely <grant.likely@...aro.org>,
Mauro Carvalho Chehab <m.chehab@...sung.com>,
Russell King - ARM Linux <linux@....linux.org.uk>,
Rob Herring <robh+dt@...nel.org>,
Sylwester Nawrocki <s.nawrocki@...sung.com>,
Laurent Pinchart <laurent.pinchart@...asonboard.com>,
Guennadi Liakhovetski <g.liakhovetski@....de>,
Kyungmin Park <kyungmin.park@...sung.com>,
<linux-kernel@...r.kernel.org>, <linux-media@...r.kernel.org>,
<devicetree@...r.kernel.org>
Subject: Re: [PATCH v5 5/7] [media] of: move common endpoint parsing to drivers/of
On 04/03/14 17:47, Philipp Zabel wrote:
> Am Dienstag, den 04.03.2014, 14:21 +0200 schrieb Tomi Valkeinen:
>> On 04/03/14 13:36, Philipp Zabel wrote:
> [...]
>>>> Can port_node be NULL? Probably only if something is quite wrong, but
>>>> maybe it's safer to return error in that case.
>>>
>>> both of_property_read_u32 and of_node_put can handle port_node == NULL.
>>> I'll add a WARN_ONCE here as for of_graph_get_next_endpoint and continue
>>> on.
>>
>> Isn't it better to return an error?
>
> I am not sure. We can still correctly parse the endpoint properties of a
> parentless node. All current users ignore the return value anyway. So as
> long as we still do the memset and and set local_node and id, returning
> an error effectively won't change the current behaviour.
Is the parentless node case an error or not? If it's not, we can handle
it silently and return 0, no WARN needed. If it is an error, we should
return an error, even if nobody is currently handling that (which is a
bug in itself, as the function does return an error value, and callers
should handle it).
Tomi
Download attachment "signature.asc" of type "application/pgp-signature" (902 bytes)
Powered by blists - more mailing lists