From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id A5AC8C7EE22 for ; Fri, 5 May 2023 14:40:17 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232376AbjEEOkQ (ORCPT ); Fri, 5 May 2023 10:40:16 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:35022 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229591AbjEEOkQ (ORCPT ); Fri, 5 May 2023 10:40:16 -0400 Received: from m228-4.mailgun.net (m228-4.mailgun.net [159.135.228.4]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 20BFF18911 for ; Fri, 5 May 2023 07:39:57 -0700 (PDT) DKIM-Signature: a=rsa-sha256; v=1; c=relaxed/relaxed; d=equiv.tech; q=dns/txt; s=mx; t=1683297596; x=1683304796; h=In-Reply-To: Content-Type: MIME-Version: References: Message-ID: Subject: Subject: Cc: To: To: From: From: Date: Sender: Sender; bh=1zV5HkaO4AcJ2oJf1urH6etlYKt5oTziBWscnFyDS8k=; b=n+LvbNTlTR2M84lzJEseOk1nD6juue+aeZkwijoJpEL9FbziPK70KE89+n3EyvMdrBdZnBBidJg+IXfcU5u7YW7nDGOWGVpqNuHzP0Vb8QOCp6sndu2sklYhImQTMf64nfUp3ehcVEO+oJKM+mHJ9IJWkSf4ewjwhzecAp0Aw+8PiQPOPpWnhHNhjy7XJMXyR86hhvcX8EOeMCQR5LW0PPYL4LHihipJMFqIon0mKhaI3xZlUVjL4Qr5vovp5Pr67rjIEtOIl/uKlmFEnMgju4EPwjrxnFnGjJNCE1oxq02G68us8SB5NWj26EEnWHTQKNXwgiMtSUmZ0RcBbranbQ== X-Mailgun-Sending-Ip: 159.135.228.4 X-Mailgun-Sid: WyIxNjU3YyIsImxpbnV4LWRvY0B2Z2VyLmtlcm5lbC5vcmciLCI5M2Q1YWIiXQ== Received: from mail.equiv.tech (equiv.tech [142.93.28.83]) by f5ac2268c446 with SMTP id 6455153cf77227a8301b0174 (version=TLS1.2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256); Fri, 05 May 2023 14:39:56 GMT Sender: james@equiv.tech Date: Fri, 5 May 2023 07:39:55 -0700 From: James Seo To: Guenter Roeck Cc: James Seo , Jean Delvare , Jonathan Corbet , linux-hwmon@vger.kernel.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [RFC 02/11] hwmon: (core) Rename last parameter of devm_hwmon_register_with_info() Message-ID: References: <20230504075752.1320967-1-james@equiv.tech> <20230504075752.1320967-3-james@equiv.tech> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-doc@vger.kernel.org On Fri, May 05, 2023 at 06:30:53AM -0700, Guenter Roeck wrote: > On 5/5/23 06:15, James Seo wrote: >> On Thu, May 04, 2023 at 08:29:57AM -0700, Guenter Roeck wrote: >> >> Hello, >> >> Of course arbitrarily changing variable names is pointless. But this >> patch fulfills the intent of 848ba0a2f20dc121a3ef5272a24641d2bd963d8b, >> which makes this change for devm_hwmon_device_register_with_info() in >> hwmon-kernel-api.txt and in hwmon.h - but not in hwmon.c. The same >> commit makes the same change for hwmon_device_register_with_info() in >> all three files, so it obviously should have been in tree already. >> >> The other reason for this patch is that for the purpose of generating >> function documentation from kerneldocs, it is not feasible to call >> this parameter "extra_groups" in the kerneldoc and still call it >> "groups" in the function itself. Doing so results in the lines >> "const struct attribute_group **groups / undescribed" and no mention >> of "extra_groups" in the generated document. Leaving things as is, so >> that [devm_]hwmon_device_register_with_info() have different names >> for this parameter, is potentially confusing and more noticeable to >> to the eye than I would like once rendered. >> >> Is this good enough to proceed? And as a subsystem maintainer, is >> there anything else, specifically or in general, that you would like > > Marginally. That should have been explained in more detail in the > description. OK, I will add more detail. > >> to see addressed? >> > > I don't know. There are changes which seem to be more based on POV > than real improvement (such as the removal of the credit from the > PMBus document). I'll have to verify each and every reference to determine > if the change is appropriate. Also, the changes are substantial. Yes, sorry. At some point comparing a local make htmldocs build to docs.kernel.org became much easier to follow than slogging through diffs, and some of the markup only makes sense once rendered next to the automatic cross-references that Sphinx adds. > It will take a lot of time for me to review, and right now I do not have > that time. I have a hard time keeping up with code reviews. > > Guenter > No rush. Your time is always appreciated. As I have gathered some feedback from Bagas, I will submit the smaller changes as a PATCH series in a day or two and an updated RFC series that you can tackle at your leisure. James