lkml.org 
[lkml]   [2021]   [Apr]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH v6 3/3] pinctrl: Add Xilinx ZynqMP pinctrl driver support
From
Date


On 4/27/21 10:39 AM, Andy Shevchenko wrote:
> On Tue, Apr 27, 2021 at 10:38 AM Michal Simek <michal.simek@xilinx.com> wrote:
>> On 4/27/21 9:31 AM, Andy Shevchenko wrote:
>>> On Tue, Apr 27, 2021 at 10:23 AM Michal Simek <michal.simek@xilinx.com> wrote:
>>>> On 4/26/21 4:04 PM, Andy Shevchenko wrote:
>>>>> On Mon, Apr 26, 2021 at 4:20 PM Sai Krishna Potthuri
>>>>> <lakshmis@xilinx.com> wrote:
>>>>>>> From: Andy Shevchenko <andy.shevchenko@gmail.com>
>>>>>>> Sent: Friday, April 23, 2021 9:24 PM
>>>>>>> On Thu, Apr 22, 2021 at 11:31 AM Sai Krishna Potthuri
>>>>>>> <lakshmi.sai.krishna.potthuri@xilinx.com> wrote:
>
> ...
>
>>>>>>>> + help
>>>>>>>> + This selects the pinctrl driver for Xilinx ZynqMP platform.
>>>>>>>> + This driver will query the pin information from the firmware
>>>>>>>> + and allow configuring the pins.
>>>>>>>> + Configuration can include the mux function to select on those
>>>>>>>> + pin(s)/group(s), and various pin configuration parameters
>>>>>>>> + such as pull-up, slew rate, etc.
>>>>>>>
>>>>>>> Missed module name.
>>>>>> Is this (module name) a configuration option in Kconfig?
>>>>>
>>>>> It's a text in a free form that sheds light on how the module will be
>>>>> named in case the user will choose "m".
>>>>
>>>> Is this described somewhere in documentation that module name should be
>>>> the part of symbol description? I was looking at pinctrl Kconfig and I
>>>> can't see any description like this there that's why I want to double
>>>> check.
>>>
>>> I dunno if it is described, the group of maintainers require that for some time.
>>> I personally found this as a good practice.
>>
>> I don't think it is a big deal to add it but it is a question if this
>> information is useful because module names should correspond target in
>> Makefile which can be considered as additional information.
>
> For you as a *developer* — yes, for me as a *user* — no. You are
> telling me something like "hey, if you want to know more you must dig
> into kernel sources". No, this is not how we should treat users,
> should we?

As I said it is not big deal but we should care about consistency on
this. Adding Joe here if we can extend checkpatch to report a warning
about it. Then it will be visible and can be checked.

>>>> Also if this is a rule checkpatch should be extended to checking this.
>>>
>>> There was a discussion at some point to add a check that help
>>> description shouldn't be less than 3 lines. Not sure what the outcome
>>> of it.
>>
>> This check is likely there because I have definitely seen these messages
>> coming but never seen any name checking.
>
> Yeah, it was about insisting developers to be more verbose in the help
> descriptions, but the name is, as I said, an activity "de facto"
> rather than "de jure". Just look around for the latest new driver
> contributions (I follow IIO, I2C, SPI, GPIO, pin control) for how they
> provide their help descriptions (I admit that not everybody follows
> that practice).
>

I have seen some on linux-next but really when any rule/recommendation
like this is introduced it should be more visible and checked by
standard tools (checkpatch or by bots) then people will start to do it.

Thanks,
Michal

\
 
 \ /
  Last update: 2021-04-27 12:01    [W:2.402 / U:0.008 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site