From: John Garry <john.garry@huawei.com>
To: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
"Rafael J. Wysocki" <rafael.j.wysocki@intel.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v1 1/4] bus: hisi_lpc: Don't dereference fwnode handle
Date: Tue, 5 Jul 2022 16:38:17 +0100 [thread overview]
Message-ID: <08a2a92d-caac-2472-05e0-e6749bcdd15b@huawei.com> (raw)
In-Reply-To: <CAHp75Vf6S0sRSKx8wyhiS6o7c+yKHU_AkYDZXhN_npMDzgi9oA@mail.gmail.com>
On 05/07/2022 16:23, Andy Shevchenko wrote:
> On Tue, Jul 5, 2022 at 5:11 PM John Garry<john.garry@huawei.com> wrote:
>> On 05/07/2022 12:43, Andy Shevchenko wrote:
>>> Use dev_fwnode() and acpi_fwnode_handle() instead of dereferencing
>>> an fwnode handle directly.
>> ...which is a better coding practice, right? If so, it would be nice to
>> mention it - well at least I think so.
> Not only. In the case of fwnode it's a long story behind its corner
> case(s) where in the future we might switch from embedded structure to
> linked list, for example, in order to address those corner cases.
> Should I write a paragraph for that as well?
>
If you just say that it's a better coding practice to use available APIs
to access structure members rather than access them directly, then that
is good enough. Or maybe you can think of something better along the
lines of what you wrote above. My issue is that there was no reason. So
I'll leave it to you.
> ...
>
>> Apart from above and nit, below:
> See below my answer.
>
>> Acked-by: John Garry<john.garry@huawei.com>
> Thanks.
>
> ...
>
>>> - sys_port = logic_pio_trans_hwaddr(&host->fwnode, res->start, len);
>>> + sys_port = logic_pio_trans_hwaddr(acpi_fwnode_handle(host), res->start, len);
>> nit: currently the driver keeps to the old 80 character line limit.
>> While the rules may have been relaxed, I'd rather we still maintain it.
> First of all, even before the 100 characters era the rule had two exceptions:
> 1) the string literals;
Sure
> 2) the readability over strictness of the 80 characters rule.
>
> While I agree in general with you, in this case I think keeping
> strictness makes readability worse.
ok, fine. I was going to suggest introduce a varible to hold
acpi_fwnode_handle(host) but then we may not want a variable of
fwnode_handle* type hanging around. Anyway I don't feel too strongly
about it.
Thanks,
John
prev parent reply other threads:[~2022-07-05 15:38 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-07-05 11:43 Andy Shevchenko
2022-07-05 11:43 ` [PATCH v1 2/4] bus: hisi_lpc: Use devm_platform_ioremap_resource Andy Shevchenko
2022-07-05 14:38 ` Rafael J. Wysocki
2022-07-05 14:41 ` John Garry
2022-07-05 11:43 ` [PATCH v1 3/4] bus: hisi_lpc: Correct error code for timeout Andy Shevchenko
2022-07-05 14:39 ` Rafael J. Wysocki
2022-07-05 14:53 ` John Garry
2022-07-05 11:43 ` [PATCH v1 4/4] bus: hisi_lpc: Don't guard ACPI IDs with ACPI_PTR() Andy Shevchenko
2022-07-05 14:22 ` Rafael J. Wysocki
2022-07-05 14:51 ` John Garry
2022-07-05 15:15 ` Andy Shevchenko
2022-07-05 15:27 ` John Garry
2022-07-05 15:33 ` Andy Shevchenko
2022-07-05 14:17 ` [PATCH v1 1/4] bus: hisi_lpc: Don't dereference fwnode handle Rafael J. Wysocki
2022-07-05 15:02 ` John Garry
2022-07-05 15:23 ` Andy Shevchenko
2022-07-05 15:38 ` John Garry [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=08a2a92d-caac-2472-05e0-e6749bcdd15b@huawei.com \
--to=john.garry@huawei.com \
--cc=andriy.shevchenko@linux.intel.com \
--cc=andy.shevchenko@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=rafael.j.wysocki@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®