linux-kernel - Re: [PATCHv6+ 01/13] of: introduce of_property_for_earch_phandle_with

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <52AF3503.3010302@wwwdotorg.org>
Date:	Mon, 16 Dec 2013 10:14:43 -0700
From:	Stephen Warren <swarren@...dotorg.org>
To:	Hiroshi Doyu <hdoyu@...dia.com>,
	Stephen Warren <swarren@...dia.com>
CC:	"thierry.reding@...il.com" <thierry.reding@...il.com>,
	"robherring2@...il.com" <robherring2@...il.com>,
	"joro@...tes.org" <joro@...tes.org>,
	"grant.likely@...aro.org" <grant.likely@...aro.org>,
	"will.deacon@....com" <will.deacon@....com>,
	"mark.rutland@....com" <mark.rutland@....com>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	"iommu@...ts.linux-foundation.org" <iommu@...ts.linux-foundation.org>,
	"linux-tegra@...r.kernel.org" <linux-tegra@...r.kernel.org>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	"lorenzo.pieralisi@....com" <lorenzo.pieralisi@....com>,
	"galak@...eaurora.org" <galak@...eaurora.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCHv6+ 01/13] of: introduce of_property_for_earch_phandle_with_args()

On 12/14/2013 08:51 AM, Hiroshi Doyu wrote:
> Hiroshi Doyu <hdoyu@...dia.com> wrote @ Thu, 12 Dec 2013 14:14:04 +0200 (EET):
> 
>>>> From 8f7c0404aa68f0e8dbe0babc240590f6528ecc1f Mon Sep 17 00:00:00 2001
>>>> From: Hiroshi Doyu <hdoyu@...dia.com>
>>>> Date: Fri, 15 Nov 2013 10:52:53 +0200
>>>> Subject: [PATCH] of: introduce of_property_for_each_phandle_with_args()
>>>>
>>>> Iterating over a property containing a list of phandles with arguments
>>>> is a common operation for device drivers. This patch adds a new
>>>> of_property_for_each_phandle_with_args() macro to make the iteration
>>>> simpler.
>>>>
>>>> Signed-off-by: Hiroshi Doyu <hdoyu@...dia.com>
>>>> Cc: Rob Herring <robherring2@...il.com>
> ....
>>>> ---
>>>>  drivers/of/base.c  | 46 ++++++++++++++++++++++++++++++++++++++++++++++
>>>>  include/linux/of.h | 32 ++++++++++++++++++++++++++++++++
>>>>  2 files changed, 78 insertions(+)
>>>>
>>>> diff --git a/drivers/of/base.c b/drivers/of/base.c
>>>> index f807d0e..cd4ab05 100644
>>>> --- a/drivers/of/base.c
>>>> +++ b/drivers/of/base.c
>>>> @@ -1201,6 +1201,52 @@ void of_print_phandle_args(const char *msg, const struct of_phandle_args *args)
>>>>       printk("\n");
>>>>  }
>>>>
>>>> +const __be32 *of_phandle_iter_next(const char *cells_name, int cell_count,
>>>> +                                const __be32 *cur, const __be32 *end,
>>>> +                                struct of_phandle_args *out_args)
>>>
>>> Having to pass in cells_name, cell_count, cur and end each time seems a
>>> little odd. Can a state structure be used instead?
>>>
>>> struct of_phandle_iter_state {
>>>         const char *cells_name;
>>>         int cells_count;
>>>         const __be32 *cur;
>>>         const __be32 *end;
>>>         struct of_phandle_args out_args;
>>> }
>>>
>>> Make the caller provide one of those and fill it in with the init
>>> function.
>>
>> I rewrote this a few times and so now I have a few version of this
>> implementations :-) The above proposal is similar to the version v6+++
>> mentioned in the above patch note:
>>
>>>> v6+++:
>>>> Introduced a new struct "of_phandle_iter" to keep the state when
>>>> iterating over the list.
>>
>> which is:
>>
>>   [RFC][PATCHv6+++ 01/13] of: introduce of_property_for_earch_phandle_with_args()
>>     http://lists.linuxfoundation.org/pipermail/iommu/2013-November/007087.html
>>
>> Stephen seemed to prefer the version without state struct. I like the
>> idea to not pass the same arguments repeatly. Instead, wrapping them
>> in a struct with state may look better.
>>
>> So if Stephen agrees, I'll rewrite the version with state struct
>> again.
> 
> Stephen, let me know what you think.

It's hard to follow there have been so many revisions. As long as the
result is reasonable, I'll be OK with it. IIRC, I objected to using a
state structure for values that weren't needed by both functions, but if
both functions need the values, that's fine. I suppose even if they
don't both need the values, putting them in a state structure is OK too
if it means the patch gets finished!

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/