linux-kernel - Re: [PATCH v3 07/14] software_node: Add support for fwnode

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: <46c23435-e32e-9de1-5055-efebc001ebad@gmail.com>
Date:   Mon, 28 Dec 2020 21:37:22 +0000
From:   Daniel Scally <djrscally@...il.com>
To:     Sakari Ailus <sakari.ailus@...ux.intel.com>
Cc:     Andy Shevchenko <andy.shevchenko@...il.com>,
        Laurent Pinchart <laurent.pinchart@...asonboard.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        ACPI Devel Maling List <linux-acpi@...r.kernel.org>,
        Linux Media Mailing List <linux-media@...r.kernel.org>,
        devel@...ica.org, "Rafael J. Wysocki" <rjw@...ysocki.net>,
        Len Brown <lenb@...nel.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Yong Zhi <yong.zhi@...el.com>,
        Bingbu Cao <bingbu.cao@...el.com>,
        Tian Shu Qiu <tian.shu.qiu@...el.com>,
        Mauro Carvalho Chehab <mchehab@...nel.org>,
        Robert Moore <robert.moore@...el.com>,
        Erik Kaneda <erik.kaneda@...el.com>,
        Petr Mladek <pmladek@...e.com>,
        Steven Rostedt <rostedt@...dmis.org>,
        Sergey Senozhatsky <sergey.senozhatsky@...il.com>,
        Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
        Rasmus Villemoes <linux@...musvillemoes.dk>,
        Laurent Pinchart <laurent.pinchart+renesas@...asonboard.com>,
        Jacopo Mondi <jacopo+renesas@...ndi.org>,
        kieran.bingham+renesas@...asonboard.com,
        Hans Verkuil <hverkuil-cisco@...all.nl>,
        Marco Felsch <m.felsch@...gutronix.de>,
        niklas.soderlund+renesas@...natech.se,
        Steve Longerbeam <slongerbeam@...il.com>,
        "Krogerus, Heikki" <heikki.krogerus@...ux.intel.com>,
        Linus Walleij <linus.walleij@...aro.org>
Subject: Re: [PATCH v3 07/14] software_node: Add support for fwnode_graph*()
 family of functions

Hi Sakari

On 28/12/2020 16:41, Sakari Ailus wrote:
> Hi Daniel,
> 
> On Thu, Dec 24, 2020 at 02:21:15PM +0000, Daniel Scally wrote:
>> Hi Andy, Laurent
>>
>>> On Thu, Dec 24, 2020 at 2:55 PM Laurent Pinchart
>>> <laurent.pinchart@...asonboard.com> wrote:
>>>> On Thu, Dec 24, 2020 at 02:24:12PM +0200, Andy Shevchenko wrote:
>>>>> On Thu, Dec 24, 2020 at 3:14 AM Daniel Scally wrote:
>>>
>>> ...
>>>
>>>>>> +               if (!strncmp(to_swnode(port)->node->name, "port@",
>>>>>
>>>>> You may use here corresponding _FMT macro.
>>>>>
>>>>>> +                            FWNODE_GRAPH_PORT_NAME_PREFIX_LEN))
>>>>>> +                       return port;
>>>
>>> ...
>>>
>>>>>> +       /* Ports have naming style "port@n", we need to select the n */
>>>>>
>>>>>> +       ret = kstrtou32(swnode->parent->node->name + FWNODE_GRAPH_PORT_NAME_PREFIX_LEN,
>>>>>
>>>>> Maybe a temporary variable?
>>>>>
>>>>>   unsigned int prefix_len = FWNODE_GRAPH_PORT_NAME_PREFIX_LEN;
>>>>>   ...
>>>>>   ret = kstrtou32(swnode->parent->node->name + prefix_len,
>>>>
>>>> Honestly I'm wondering if those macros don't hinder readability. I'd
>>>> rather write
>>>>
>>>>         + strlen("port@")
>>>
>>> Works for me, since the compiler optimizes this away to be a plain constant.
>>
>> Well, how about instead of the LEN macro, we have:
>>
>> #define FWNODE_GRAPH_PORT_NAME_PREFIX	"port@"
>> #define FWNODE_GRAPH_PORT_NAME_FMT FWNODE_GRAPH_PORT_NAME_PREFIX "%u"
>>
>> And then it's still maintainable in one place but (I think) slightly
>> less clunky, since we can do strlen(FWNODE_GRAPH_PORT_NAME_PREFIX)
>>
>> Or we can do strlen("port@"), I'm good either way :)
> 
> I'd be in favour of using strlen("port@") here.
> 
> At least for now. I think refactoring the use of such strings could be a
> separate set at another time, if that's seen as the way to go.

Alright - thanks. In that case I'll switch to strlen("port@0"), and
FWNODE_GRAPH_PORT_NAME_LEN can be dropped then I think.