From: Krzysztof Kozlowski <krzk@kernel.org>
To: ChiYuan Huang <u0084500@gmail.com>, Mark Brown <broonie@kernel.org>
Cc: Rob Herring <robh+dt@kernel.org>,
Liam Girdwood <lgirdwood@gmail.com>,
cy_huang <cy_huang@richtek.com>,
gene_chen@richtek.com, lkml <linux-kernel@vger.kernel.org>,
"open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS"
<devicetree@vger.kernel.org>
Subject: Re: [PATCH 2/2] regulator: rt5759: Add support for Richtek RT5759 DCDC converter
Date: Sat, 26 Mar 2022 09:13:32 +0100 [thread overview]
Message-ID: <de9ff5a7-ebcf-d08f-486b-5334be8fb703@kernel.org> (raw)
In-Reply-To: <CADiBU38O6zdp5KYt90KgrZKJwAzBqPoaYQYehAJ=wS42NyVcjQ@mail.gmail.com>
On 26/03/2022 08:55, ChiYuan Huang wrote:
> Mark Brown <broonie@kernel.org> 於 2022年3月26日 週六 上午9:07寫道:
>>
>> On Sat, Mar 26, 2022 at 08:58:47AM +0800, ChiYuan Huang wrote:
>>
>>> I tried to remove only __maybe_unused and build with x86 config that
>>> CONFIG_OF=n.
>>> There's no warning or error message when compiling the rt5759 source code.
>>
>>> If so, I will remove only '__maybe_unused'.
>>> May I ask whether 'of_match_ptr' need to be added or not?
>>
>> If you add of_match_ptr() (which is a little better, though it's
>> a tiny different either way) then you shouldn't remove
>> __maybe_unused - the thing here is that the __maybe_unused is
>> needed because of_match_ptr() is used.
>
> Sorry, I'm confused.
> Originally, Krzysztof's opinion is to tell me why 'of_device_id' is
> declared as '__maybe_unused'.
> That's why I mentioned that the return value about of_device_get_match_data'
Your answer is not related to my question. of_device_get_match_data()
has nothing to do with __maybe_unused...
> And now we're talking about to add 'of_match_ptr' in struct driver
> of_match_table.
Because this is one of the solutions.
>
> Back to the original topic, two ways can solve this.
> 1) only remove '__maybe_unused' in of_device_id
> 2) keep '__maybe_unused' in of_device_id, and add of_match_ptr for
> of_match_table.
> But option 2 seems conflict with Krzysztof's gueestion.
>
> May I ask which option you suggested?
Option two does not conflict my suggestion. I pointed out that having
ONLY maybe_unused is incorrect. I pointed the mistake. Nothing more... I
said that there are two ways to solve it later, just choose one. I don't
know why do we talk about such basic issue for so long. This should be
one email from my side and one confirmation from you...
Obviously maybe_unused it has to be removed if you do not add
of_match_ptr. But if you intend to add of_match_ptr, then things change...
Just for the record of choosing between options (which I also mentioned
that there are two solutions) - having no of_match_ptr allows to match
with ACPI PRP0001 (AFAIU also when !OF).
Best regards,
Krzysztof
next prev parent reply other threads:[~2022-03-26 8:13 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-25 1:06 [PATCH 0/2] Add Richtek RT5759 buck converter support cy_huang
2022-03-25 1:06 ` [PATCH 1/2] dt-bindings: regulator: Add binding for Richtek RT5759 DCDC converter cy_huang
2022-03-25 12:14 ` Krzysztof Kozlowski
2022-03-25 13:44 ` ChiYuan Huang
2022-03-25 14:46 ` Krzysztof Kozlowski
2022-03-25 14:53 ` ChiYuan Huang
2022-03-25 1:06 ` [PATCH 2/2] regulator: rt5759: Add support " cy_huang
2022-03-25 12:17 ` Krzysztof Kozlowski
2022-03-25 14:10 ` ChiYuan Huang
2022-03-25 14:47 ` Krzysztof Kozlowski
2022-03-25 14:59 ` ChiYuan Huang
2022-03-25 15:37 ` Krzysztof Kozlowski
2022-03-25 15:50 ` ChiYuan Huang
2022-03-25 15:55 ` Krzysztof Kozlowski
2022-03-25 16:05 ` Mark Brown
2022-03-25 16:08 ` Krzysztof Kozlowski
2022-03-26 0:58 ` ChiYuan Huang
2022-03-26 1:07 ` Mark Brown
2022-03-26 7:55 ` ChiYuan Huang
2022-03-26 8:13 ` Krzysztof Kozlowski [this message]
2022-03-26 8:24 ` ChiYuan Huang
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=de9ff5a7-ebcf-d08f-486b-5334be8fb703@kernel.org \
--to=krzk@kernel.org \
--cc=broonie@kernel.org \
--cc=cy_huang@richtek.com \
--cc=devicetree@vger.kernel.org \
--cc=gene_chen@richtek.com \
--cc=lgirdwood@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=robh+dt@kernel.org \
--cc=u0084500@gmail.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;
as well as URLs for NNTP newsgroup(s).