linux-kernel - Re: [PATCH] tty: serial: qcom_geni: avoid duplicate struct member init

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]

Date:   Fri, 16 Dec 2022 07:21:55 -0800
From:   Doug Anderson <dianders@...omium.org>
To:     Arnd Bergmann <arnd@...db.de>
Cc:     Arnd Bergmann <arnd@...nel.org>, Andy Gross <agross@...nel.org>,
        Bjorn Andersson <andersson@...nel.org>,
        Konrad Dybcio <konrad.dybcio@...aro.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Jiri Slaby <jirislaby@...nel.org>,
        Vijaya Krishna Nivarthi <quic_vnivarth@...cinc.com>,
        Sai Prakash Ranjan <quic_saipraka@...cinc.com>,
        Aniket Randive <quic_arandive@...cinc.com>,
        linux-arm-msm@...r.kernel.org, linux-serial@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH] tty: serial: qcom_geni: avoid duplicate struct member init

Hi,

On Fri, Dec 16, 2022 at 2:41 AM Arnd Bergmann <arnd@...db.de> wrote:
>
> On Thu, Dec 15, 2022, at 21:46, Doug Anderson wrote:
> > On Thu, Dec 15, 2022 at 8:55 AM Arnd Bergmann <arnd@...nel.org> wrote:
>
> >> index b487823f0e61..03dda47184d9 100644
> >> --- a/drivers/tty/serial/qcom_geni_serial.c
> >> +++ b/drivers/tty/serial/qcom_geni_serial.c
> >> @@ -1516,7 +1516,7 @@ static int qcom_geni_serial_remove(struct platform_device *pdev)
> >>         return 0;
> >>  }
> >>
> >> -static int __maybe_unused qcom_geni_serial_sys_suspend(struct device *dev)
> >> +static int qcom_geni_serial_sys_suspend(struct device *dev)
> >
> > Officially the removal of "__maybe_unused" could be a totally
> > different patch, right? SET_SYSTEM_SLEEP_PM_OPS() already eventually
> > used pm_sleep_ptr() even without your change, so the removal of these
> > tags is unrelated to the rest of your change, right?
>
> It's a little more complicated: SYSTEM_SLEEP_PM_OPS() uses pm_sleep_ptr()
> to avoid the need for a __maybe_unused(). The depreacated
> SET_SYSTEM_SLEEP_PM_OPS() is based on SYSTEM_SLEEP_PM_OPS() these days,
> but still retains the old semantics of using an empty definition
> without CONFIG_PM_SLEEP, so it still leaves the function unused as
> far as gcc is concerned.
>
> There could be an intermediate step of open-coding the
> SET_SYSTEM_SLEEP_PM_OPS(), but that would result in the rather
> silly
>
>  static const struct dev_pm_ops qcom_geni_serial_pm_ops = {
> #ifdef CONFIG_PM_SLEEP
>        .suspend = qcom_geni_serial_sys_suspend,
>        .resume = qcom_geni_serial_sys_resume,
>        .freeze = qcom_geni_serial_sys_suspend,
>        .poweroff = qcom_geni_serial_sys_suspend,
> #endif
>        .restore = qcom_geni_serial_sys_hib_resume,
>        .thaw = qcom_geni_serial_sys_hib_resume,
> }
>
> which makes no sense to me, as I think you either want
> all the members or none of them.

Ah, I guess I didn't trace through all the similarly named macros
quite correctly. ;-) Thanks for explaining.


> >>  static const struct dev_pm_ops qcom_geni_serial_pm_ops = {
> >> -       SET_SYSTEM_SLEEP_PM_OPS(qcom_geni_serial_sys_suspend,
> >> -                                       qcom_geni_serial_sys_resume)
> >> -       .restore = qcom_geni_serial_sys_hib_resume,
> >> -       .thaw = qcom_geni_serial_sys_hib_resume,
> >> +       .suspend = pm_sleep_ptr(qcom_geni_serial_sys_suspend),
> >> +       .resume = pm_sleep_ptr(qcom_geni_serial_sys_resume),
> >> +       .freeze = pm_sleep_ptr(qcom_geni_serial_sys_suspend),
> >> +       .poweroff = pm_sleep_ptr(qcom_geni_serial_sys_suspend),
> >> +       .restore = pm_sleep_ptr(qcom_geni_serial_sys_hib_resume),
> >> +       .thaw = pm_sleep_ptr(qcom_geni_serial_sys_hib_resume),
> >
> > Personally, the order you listed them is less intuitive than the order
> > that SET_SYSTEM_SLEEP_PM_OPS() lists functions. IMO it's better to
> > consistently alternate matching suspend/resume functions. ;-)
>
> Makes sense. I kept the order that we already had here, but
> I could redo this patch if anyone cares.

I wouldn't worry about it.

-Doug