linux-kernel - Re: [PATCH v2 RESEND 2/5] drivers: acpi: acpi_apd: Remove unused device property "is-rv"

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

Message-ID: <acc78695-9156-7f39-619f-75434bcb3a1f@amd.com>
Date:   Mon, 8 Nov 2021 13:36:56 +0530
From:   Ajit Kumar Pandey <AjitKumar.Pandey@....com>
To:     Stephen Boyd <sboyd@...nel.org>,
        "Rafael J. Wysocki" <rafael@...nel.org>
Cc:     linux-clk <linux-clk@...r.kernel.org>, Vijendar.Mukunda@....com,
        Alex Deucher <Alexander.Deucher@....com>,
        Basavaraj.Hiregoudar@....com, Sunil-kumar.Dommati@....com,
        Len Brown <lenb@...nel.org>, linux-acpi@...r.kernel.org,
        linux-kernel@...r.kernel.org,
        Mario Limonciello <mario.limonciello@....com>
Subject: Re: [PATCH v2 RESEND 2/5] drivers: acpi: acpi_apd: Remove unused
 device property "is-rv"



On 11/6/2021 3:52 AM, Stephen Boyd wrote:
> [CAUTION: External Email]
> 
> Quoting Rafael J. Wysocki (2021-11-05 08:02:26)
>> On Fri, Oct 29, 2021 at 8:33 AM Ajit Kumar Pandey
>> <AjitKumar.Pandey@....com> wrote:
>>>
>>> Initially "is-rv" device property is added for 48MHz fixed clock
>>> support on Raven or RV architecture. It's unused now as we moved
>>> to clock config based selection to extend such support on others
>>> architecture. This change removed unused code from acpi driver.
>>>
>>> Signed-off-by: Ajit Kumar Pandey <AjitKumar.Pandey@....com>
>>
>> Is this and the [3/5] applicable without the [1/5]?
>>
>> If so, I can pick them up once they are approved by some other AMD
>> folks, preferably Mario.
> 
> I'm still lost why we're putting this decision to have some clk or not
> into Kconfig.
> 
I agree it's kind of weird to select clock based on Kconfig but only 
reason to put Kconfig based selection is that this clk support required 
on some older platforms where BIOS or bootloader change isn't feasible.
We have only one consumer for this 48MHzclk i.e audio drivers and idea 
is that this config shouldn't be user-selectable one and automatically
select from audio machine driver which uses this clk.