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: <BY5PR12MB403418CCC56FE9E2EA3232D2DE380@BY5PR12MB4034.namprd12.prod.outlook.com>
Date:   Fri, 10 Jan 2020 14:54:37 +0000
From:   Eugeniy Paltsev <Eugeniy.Paltsev@...opsys.com>
To:     Vineet Gupta <Vineet.Gupta1@...opsys.com>,
        "linux-snps-arc@...ts.infradead.org" 
        <linux-snps-arc@...ts.infradead.org>
CC:     "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "Alexey Brodkin" <Alexey.Brodkin@...opsys.com>
Subject: Re: [PATCH 3/5] ARC: handle DSP presence in HW

Hi Vineet,

>From: Vineet Gupta <vgupta@...opsys.com>
>Sent: Tuesday, January 7, 2020 04:03
>To: Eugeniy Paltsev; linux-snps-arc@...ts.infradead.org
>Cc: linux-kernel@...r.kernel.org; Alexey Brodkin
>Subject: Re: [PATCH 3/5] ARC: handle DSP presence in HW
>[snip]
>> +static inline bool dsp_exist(void)
>> +{
>> +     struct bcr_generic bcr;
>> +
>> +     READ_BCR(ARC_AUX_DSP_BUILD, bcr);
>> +     return !!bcr.ver;
>
>open code these use once / one liners in the call site itself.
>
>>
>> @@ -444,6 +445,9 @@ static void arc_chk_core_config(void)
>>               /* Accumulator Low:High pair (r58:59) present if DSP MPY or FPU */
>>               present = cpu->extn_mpy.dsp | cpu->extn.fpu_sp | cpu->extn.fpu_dp;
>>               CHK_OPT_STRICT(CONFIG_ARC_HAS_ACCL_REGS, present);
>> +
>> +             present = dsp_exist();
>
>Open code as suggested above.
>
>> +             CHK_OPT_STRICT(CONFIG_ARC_DSP_KERNEL, present);
>>       }

My idea here is to encapsulate implementation of everything dsp-related in the
file with dsp code. So I'm even thinking about moving the config check itself
to some function like
'arc_chk_dsp_config' which will be located in dsp.x file
and call it from arc_chk_core_config in setup.c

This requires to move config check helpers to separate file/header from the setup.c
However this allows encapsulate all DSP code (and some new subsystems code later on) in its files instead of spread it across the arc code.

What do you think about it? If you really dislike this idea I can drop it.
---
 Eugeniy Paltsev

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ