linux-kernel - Re: [PATCH 1/7] of: base: Add of_count_phandle_with_fixed

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <474edf9d-e15a-cc20-1b56-2fe1d7fccf55@opensource.cirrus.com>
Date:   Fri, 16 Oct 2020 16:14:44 +0100
From:   Richard Fitzgerald <rf@...nsource.cirrus.com>
To:     Rob Herring <robh+dt@...nel.org>,
        Robin Murphy <robin.murphy@....com>
CC:     <devicetree@...r.kernel.org>,
        Linux-ALSA <alsa-devel@...a-project.org>,
        - <patches@...nsource.cirrus.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Mark Brown <broonie@...nel.org>,
        Nicolas Saenz Julienne <nsaenzjulienne@...e.de>,
        linux-arm-kernel <linux-arm-kernel@...ts.infradead.org>,
        "moderated list:BROADCOM BCM2835 ARM ARCHITECTURE" 
        <linux-rpi-kernel@...ts.infradead.org>
Subject: Re: [PATCH 1/7] of: base: Add of_count_phandle_with_fixed_args()

On 16/10/2020 14:31, Rob Herring wrote:
> On Thu, Oct 15, 2020 at 11:52 AM Robin Murphy <robin.murphy@....com> wrote:
>>
>> On 2020-10-14 19:39, Rob Herring wrote:
>>> On Wed, Oct 14, 2020 at 9:54 AM Richard Fitzgerald
>>> <rf@...nsource.cirrus.com> wrote:
>>>>
>>>> Add an equivalent of of_count_phandle_with_args() for fixed argument
>>>> sets, to pair with of_parse_phandle_with_fixed_args().
>>>>
>>>> Signed-off-by: Richard Fitzgerald <rf@...nsource.cirrus.com>
>>>> ---
>>>>    drivers/of/base.c  | 42 ++++++++++++++++++++++++++++++++++++++++++
>>>>    include/linux/of.h |  9 +++++++++
>>>>    2 files changed, 51 insertions(+)
>>>>
>>>> diff --git a/drivers/of/base.c b/drivers/of/base.c
>>>> index ea44fea99813..45d8b0e65345 100644
>>>> --- a/drivers/of/base.c
>>>> +++ b/drivers/of/base.c
>>>> @@ -1772,6 +1772,48 @@ int of_count_phandle_with_args(const struct device_node *np, const char *list_na
>>>>    }
>>>>    EXPORT_SYMBOL(of_count_phandle_with_args);
>>>>
>>>> +/**
>>>> + * of_count_phandle_with_fixed_args() - Find the number of phandles references in a property
>>>> + * @np:                pointer to a device tree node containing a list
>>>> + * @list_name: property name that contains a list
>>>> + * @cell_count: number of argument cells following the phandle
>>>> + *
>>>> + * Returns the number of phandle + argument tuples within a property. It
>>>> + * is a typical pattern to encode a list of phandle and variable
>>>> + * arguments into a single property.
>>>> + */
>>>> +int of_count_phandle_with_fixed_args(const struct device_node *np,
>>>> +                                    const char *list_name,
>>>> +                                    int cells_count)
>>>> +{
>>>
>>> Looks to me like you can refactor of_count_phandle_with_args to handle
>>> both case and then make this and of_count_phandle_with_args simple
>>> wrapper functions.
>>
>> Although for just counting the number of phandles each with n arguments
>> that a property contains, isn't that simply a case of dividing the
>> property length by n + 1? The phandles themselves will be validated by
>> any subsequent of_parse_phandle*() call anyway, so there doesn't seem
>> much point in doing more work then necessary here.
>>
>>>> +       struct of_phandle_iterator it;
>>>> +       int rc, cur_index = 0;
>>>> +
>>>> +       if (!cells_count) {
>>>> +               const __be32 *list;
>>>> +               int size;
>>>> +
>>>> +               list = of_get_property(np, list_name, &size);
>>>> +               if (!list)
>>>> +                       return -ENOENT;
>>>> +
>>>> +               return size / sizeof(*list);
>>
>> Case in point - if it's OK to do exactly that for n == 0, then clearly
>> we're *aren't* fussed about validating anything, so the n > 0 code below
>> is nothing more than a massively expensive way to check for a nonzero
>> remainder :/
> 
> Indeed. We should just generalize this. It can still be refactored to
> shared code.
> 
> It's probably worthwhile to check for a remainder here IMO.
>

Ok, I looked at the implementation of of_phandle_iterator_next() and
it is in fact simply incrementing by 'count' 32-bit words. So as Robin
said the count_phandle_with_x_args()functions could simply divide the
length by count+1.

However, may I suggest that should be done in a separate patch after my
patch to add count_phandle_with_fixed_args()? That way, if replacing the
iteration with the simple length divide causes any unforeseen problems
the patch can just be reverted.

> Rob
>