linux-kernel - Re: [PATCH 6/6] firmware: qcom_scm: Only compile legacy calls on ARM

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <161483844056.1478170.8701629037531614722@swboyd.mtv.corp.google.com>
Date:   Wed, 03 Mar 2021 22:14:00 -0800
From:   Stephen Boyd <swboyd@...omium.org>
To:     Andy Gross <agross@...nel.org>,
        Bjorn Andersson <bjorn.andersson@...aro.org>,
        Elliot Berman <eberman@...eaurora.org>
Cc:     linux-kernel@...r.kernel.org, linux-arm-msm@...r.kernel.org,
        Brian Masney <masneyb@...tation.org>,
        Stephan Gerhold <stephan@...hold.net>,
        Jeffrey Hugo <jhugo@...eaurora.org>,
        Douglas Anderson <dianders@...omium.org>
Subject: Re: [PATCH 6/6] firmware: qcom_scm: Only compile legacy calls on ARM

Quoting Elliot Berman (2021-03-03 19:35:08)
> 
> On 2/23/2021 1:45 PM, Stephen Boyd wrote:
> > These scm calls are never used outside of legacy ARMv7 based platforms.
> > That's because PSCI, mandated on arm64, implements them for modern SoCs
> > via the PSCI spec. Let's move them to the legacy file and only compile
> > the legacy file into the kernel when CONFIG_ARM=y. Otherwise provide
> > stubs and fail the calls. This saves a little bit of space in an
> > arm64 allmodconfig >
> >   $ ./scripts/bloat-o-meter vmlinux.before vmlinux.after
> >   add/remove: 0/8 grow/shrink: 5/7 up/down: 509/-4405 (-3896)
> >   Function                                     old     new   delta
> >   __qcom_scm_set_dload_mode.constprop          312     452    +140
> >   qcom_scm_qsmmu500_wait_safe_toggle           288     416    +128
> >   qcom_scm_io_writel                           288     408    +120
> >   qcom_scm_io_readl                            376     492    +116
> >   __param_str_download_mode                     23      28      +5
> >   __warned                                    4327    4326      -1
> >   qcom_iommu_init                              272     268      -4
> >   e843419@...f_00010432_324                      8       -      -8
> >   qcom_scm_call                                228     208     -20
> >   CSWTCH                                      5925    5877     -48
> >   _sub_I_65535_1                            163100  163040     -60
> >   _sub_D_65535_0                            163100  163040     -60
> >   qcom_scm_wb                                   64       -     -64
> >   qcom_scm_lock                                320     160    -160
> >   qcom_scm_call_atomic                         212       -    -212
> >   qcom_scm_cpu_power_down                      308       -    -308
> >   scm_legacy_call_atomic                       520       -    -520
> >   qcom_scm_set_warm_boot_addr                  720       -    -720
> >   qcom_scm_set_cold_boot_addr                  728       -    -728
> >   scm_legacy_call                             1492       -   -1492
> >   Total: Before=66737642, After=66733746, chg -0.01%
> > 
> > Commit 9a434cee773a ("firmware: qcom_scm: Dynamically support SMCCC and
> > legacy conventions") didn't mention any motivating factors for keeping
> > the legacy code around on arm64 kernels, i.e. presumably that commit
> > wasn't trying to support these legacy APIs on arm64 kernels.
> 
> There are arm targets which support SMCCC convention and use some of 
> these removed functions. Can these functions be kept in qcom-scm.c and 
> wrapped with #if IS_ENABLED(CONFIG_ARM)?
> 

It can be wrapped in qcom-scm.c, but why? It's all the same object file
so I'm lost why it matters. I suppose it would make it so the struct
doesn't have to be moved around and declared in the header? Any other
reason? I moved it to the legacy file so that it was very obvious that
the API wasn't to be used except for "legacy" platforms that don't use
PSCI.