linux-kernel - Re: [PATCH 2/2] regulator: rt5759: Add support for Richtek RT5759 DCDC converter

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CADiBU38Jo8n3m-BQ_3aCnapc2X=boQQS2PEKcGjPNfGHLMT=gQ@mail.gmail.com>
Date:   Sat, 26 Mar 2022 16:24:22 +0800
From:   ChiYuan Huang <u0084500@...il.com>
To:     Krzysztof Kozlowski <krzk@...nel.org>
Cc:     Mark Brown <broonie@...nel.org>, Rob Herring <robh+dt@...nel.org>,
        Liam Girdwood <lgirdwood@...il.com>,
        cy_huang <cy_huang@...htek.com>, gene_chen@...htek.com,
        lkml <linux-kernel@...r.kernel.org>,
        "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" 
        <devicetree@...r.kernel.org>
Subject: Re: [PATCH 2/2] regulator: rt5759: Add support for Richtek RT5759
 DCDC converter

Krzysztof Kozlowski <krzk@...nel.org> 於 2022年3月26日 週六 下午4:13寫道：
>
> On 26/03/2022 08:55, ChiYuan Huang wrote:
> > Mark Brown <broonie@...nel.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).
>
Ok, I think the way to add 'of_match_ptr' and keep '__maybe_unused' is
more formal.
I'll choose that one.

Ack in next.
Thanks.
>
> Best regards,
> Krzysztof