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:   Wed, 12 Jul 2023 14:55:35 +0530
From:   Rohit Agarwal <quic_rohiagar@...cinc.com>
To:     Konrad Dybcio <konrad.dybcio@...aro.org>,
        Dmitry Baryshkov <dmitry.baryshkov@...aro.org>,
        <agross@...nel.org>, <andersson@...nel.org>, <robh+dt@...nel.org>,
        <krzysztof.kozlowski+dt@...aro.org>, <conor+dt@...nel.org>
CC:     <linux-arm-msm@...r.kernel.org>, <devicetree@...r.kernel.org>,
        <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v3 1/3] dt-bindings: power: rpmhpd: Add Generic RPMh PD
 indexes


On 7/12/2023 2:52 PM, Konrad Dybcio wrote:
> On 12.07.2023 10:24, Rohit Agarwal wrote:
>> On 7/11/2023 8:41 PM, Dmitry Baryshkov wrote:
>>> On 11/07/2023 08:42, Rohit Agarwal wrote:
>>>> Add Generic RPMh Power Domain indexes that can be used
>>>> for all the Qualcomm SoC henceforth.
>>>>
>>>> Signed-off-by: Rohit Agarwal <quic_rohiagar@...cinc.com>
>>>> Suggested-by: Konrad Dybcio <konrad.dybcio@...aro.org>
>>>> ---
>>>>    include/dt-bindings/power/qcom-rpmhpd.h | 30 ++++++++++++++++++++++++++++++
>>>>    1 file changed, 30 insertions(+)
>>>>    create mode 100644 include/dt-bindings/power/qcom-rpmhpd.h
>>>>
>>>> diff --git a/include/dt-bindings/power/qcom-rpmhpd.h b/include/dt-bindings/power/qcom-rpmhpd.h
>>>> new file mode 100644
>>>> index 0000000..4da2e04
>>>> --- /dev/null
>>>> +++ b/include/dt-bindings/power/qcom-rpmhpd.h
>>>> @@ -0,0 +1,30 @@
>>>> +/* SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) */
>>>> +/*
>>>> + * Copyright (c) 2023, Qualcomm Innovation Center, Inc. All rights reserved.
>>>> + */
>>>> +
>>>> +#ifndef _DT_BINDINGS_POWER_QCOM_RPMHPD_H
>>>> +#define _DT_BINDINGS_POWER_QCOM_RPMHPD_H
>>>> +
>>>> +/* Generic RPMH Power Domain Indexes */
>>>> +#define CX               0
>>>> +#define MX               1
>>>> +#define CX_AO            2
>>>> +#define MX_AO            3
>>>> +#define GFX              4
>>>> +#define MSS              5
>>>> +#define EBI              6
>>>> +#define LCX              7
>>>> +#define LMX              8
>>>> +#define MMCX             9
>>>> +#define MMCX_AO          10
>>>> +#define MXC              11
>>>> +#define MXC_AO           12
>>>> +#define NSP              13
>>>> +#define NSP0             14
>>>> +#define NSP1             15
>>>> +#define QPHY             16
>>>> +#define DDR              17
>>>> +#define XO               18
>>> I went through the existing defines. If we adopt the order of defines for sm8550, we can migrate that platform and all of sm8[234]50 without breaking ABI. This would be a minor gain, but still something.
>>>
>> Actually, I added them in the sequence based on the frequency with which they occur in the driver, so that there are less NULL entries created for any target additions. Shouldnt we keep it this way and ignore for previous targets then?
> Don't bother yourself with this, we've already dragged you through
> some bindings mess ;)
>
> Dmitry just noticed that a happy coincidence occured and we could
> swap out SM8[234]_50 indices with these ones and they would still
> match. It'd be a separate patch though.
Yes sure. Will make a separate patch updating entries for these targets.

Thanks,
Rohit.
> Konrad
>> Thanks,
>> Rohit.
>>>> +
>>>> +#endif

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ