linux-kernel - Re: [PATCH v2] drivers/perf: riscv_pmu_sbi: add support for PMU variant on T-Head C9xx cores

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] [day] [month] [year] [list]

Date:   Tue, 30 Aug 2022 15:32:07 +0000
From:   <Conor.Dooley@...rochip.com>
To:     <heiko@...ech.de>, <atishp@...shpatra.org>, <anup@...infault.org>,
        <will@...nel.org>, <mark.rutland@....com>,
        <paul.walmsley@...ive.com>, <palmer@...belt.com>,
        <aou@...s.berkeley.edu>
CC:     <linux-riscv@...ts.infradead.org>, <linux-kernel@...r.kernel.org>,
        <philipp.tomsich@...ll.eu>, <cmuellner@...ux.com>,
        <samuel@...lland.org>, <guoren@...nel.org>
Subject: Re: [PATCH v2] drivers/perf: riscv_pmu_sbi: add support for PMU
 variant on T-Head C9xx cores

On 30/08/2022 16:02, Heiko Stübner wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> 
> Am Dienstag, 30. August 2022, 16:33:27 CEST schrieb Heiko Stübner:
>> Am Freitag, 26. August 2022, 19:57:33 CEST schrieb Conor.Dooley@...rochip.com:
>>> On 26/08/2022 17:35, Heiko Stuebner wrote:
>>>> diff --git a/arch/riscv/errata/thead/errata.c b/arch/riscv/errata/thead/errata.c
>>>> index 202c83f677b2..e6101eab25c8 100644
>>>> --- a/arch/riscv/errata/thead/errata.c
>>>> +++ b/arch/riscv/errata/thead/errata.c
>>>> @@ -44,6 +44,22 @@ static bool errata_probe_cmo(unsigned int stage,
>>>>  #endif
>>>>  }
>>>>
>>>> +static bool errata_probe_pmu(unsigned int stage,
>>>> +                            unsigned long arch_id, unsigned long impid)
>>>> +{
>>>> +#ifdef CONFIG_ERRATA_THEAD_PMU
>>>
>>> Is there a reason that all the alternatives use ifdef
>>> rather than if(IS_ENABLED())?
>>
>> no real reason I guess - more like not enough thinking :-)
>>
>> Using IS_ENABLED also makes it way nicer as we can just do
>>
>>       if (!IS_ENABLED(CONFIG_ERRATA_THEAD_PMU))
>>               return false;
> 
> Though at least for the CMO this is not possible, as the
>         riscv_noncoherent_supported()
> is not defined in that case.
> 
> Though it might be nice to define a stub for the
> not-CONFIG_RISCV_DMA_NONCOHERENT case
> so that we don't need to #ifdef around it.

Personally, I really like IS_ENABLED() & stubs as all the code
gets compile tested at the very least. Maybe that is a future
work item though, no need to rework the world for this series...

I'd take up arms along side you though, if you decided to wage
war on ifdefs-that-could-be-IS_ENABLED() ;)

Conor.