Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Received-SPF: Pass (protection.outlook.com: domain of xilinx.com designates
 149.199.62.198 as permitted sender) receiver=protection.outlook.com;
 client-ip=149.199.62.198; helo=xsj-pvapexch02.xlnx.xilinx.com;
Envelope-to: git@xilinx.com,
 saikrishna12468@gmail.com,
 linux-gpio@vger.kernel.org,
 devicetree@vger.kernel.org,
 linux-kernel@vger.kernel.org,
 linux-arm-kernel@lists.infradead.org,
 gregkh@linuxfoundation.org,
 robh+dt@kernel.org,
 linus.walleij@linaro.org,
 joe@perches.com,
 andy.shevchenko@gmail.com
Subject: Re: [PATCH v6 3/3] pinctrl: Add Xilinx ZynqMP pinctrl driver support
To:     Andy Shevchenko <andy.shevchenko@gmail.com>,
        Michal Simek <michal.simek@xilinx.com>,
        Joe Perches <joe@perches.com>
CC:     Sai Krishna Potthuri <lakshmis@xilinx.com>,
        Linus Walleij <linus.walleij@linaro.org>,
        Rob Herring <robh+dt@kernel.org>,
        "Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
        linux-arm Mailing List <linux-arm-kernel@lists.infradead.org>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        devicetree <devicetree@vger.kernel.org>,
        "open list:GPIO SUBSYSTEM" <linux-gpio@vger.kernel.org>,
        git <git@xilinx.com>,
        "saikrishna12468@gmail.com" <saikrishna12468@gmail.com>
References: <1619080202-31924-1-git-send-email-lakshmi.sai.krishna.potthuri@xilinx.com>
 <1619080202-31924-4-git-send-email-lakshmi.sai.krishna.potthuri@xilinx.com>
 <CAHp75VfCbbnN-TBJiYFb=6Rhf30jA-Hz1p1UORsubF7UG6-ATw@mail.gmail.com>
 <DM5PR02MB3877B234F85F3B4887DF3A95BD429@DM5PR02MB3877.namprd02.prod.outlook.com>
 <CAHp75VfugGqLNU8LKJ_K3dPr=-eh6LHx75eV=33jH9OnryBoGA@mail.gmail.com>
 <d1220d39-4be4-a375-042f-e7bb0264ed35@xilinx.com>
 <CAHp75Vejqe3r6s5eoOfza0DjXEwN-hK73FWkxx6VNpx0y1ms2w@mail.gmail.com>
 <180ca47b-d627-2d7b-1d18-5557bfcf5875@xilinx.com>
 <CAHp75Ve1MY6wms7d1e2cByzV0Zy-rRs-qNMk=6X_fw=zu4rbgw@mail.gmail.com>
From:   Michal Simek <michal.simek@xilinx.com>
Message-ID: <67cef577-0965-2fad-7d61-17181d692003@xilinx.com>
Date:   Tue, 27 Apr 2021 11:59:40 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
 Thunderbird/78.10.0
MIME-Version: 1.0
In-Reply-To: <CAHp75Ve1MY6wms7d1e2cByzV0Zy-rRs-qNMk=6X_fw=zu4rbgw@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Apr 2021 09:59:49.8813
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 6362f5fa-4732-4be7-82a3-08d909633251
X-MS-Exchange-CrossTenant-Id: 657af505-d5df-48d0-8300-c31994686c5c
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=657af505-d5df-48d0-8300-c31994686c5c;Ip=[149.199.62.198];Helo=[xsj-pvapexch02.xlnx.xilinx.com]
X-MS-Exchange-CrossTenant-AuthSource: BL2NAM02FT038.eop-nam02.prod.protection.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR02MB5774
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org


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