linux-kernel - Re: [PATCH 2/2] pmdomain: add audio power island for Marvell PXA1908 SoC

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: <DELFWFLO1M8G.1AMPX0VKEOJND@matfyz.cz>
Date: Sat, 29 Nov 2025 20:53:05 +0100
From: "Karel Balej" <balejk@...fyz.cz>
To: Duje Mihanović <duje@...emihanovic.xyz>
Cc: <~postmarketos/upstreaming@...ts.sr.ht>, <phone-devel@...r.kernel.org>,
        "Ulf Hansson" <ulf.hansson@...aro.org>,
        "Rob Herring" <robh@...nel.org>,
        "Krzysztof Kozlowski" <krzk+dt@...nel.org>,
        "Conor Dooley"
 <conor+dt@...nel.org>,
        <linux-arm-kernel@...ts.infradead.org>, <linux-pm@...r.kernel.org>,
        <linux-kernel@...r.kernel.org>, <devicetree@...r.kernel.org>
Subject: Re: [PATCH 2/2] pmdomain: add audio power island for Marvell
 PXA1908 SoC

Duje Mihanović, 2025-11-28T22:30:55+01:00:
> On 11/27/2025 8:02 PM, Karel Balej wrote:
>> diff --git a/drivers/pmdomain/marvell/pxa1908-power-controller.c b/drivers/pmdomain/marvell/pxa1908-power-controller.c
>> index ff5e6e82d3f8..e32eb227f235 100644
>> --- a/drivers/pmdomain/marvell/pxa1908-power-controller.c
>> +++ b/drivers/pmdomain/marvell/pxa1908-power-controller.c
>> @@ -29,7 +29,10 @@
>>  #define POWER_POLL_TIMEOUT_US	(25 * USEC_PER_MSEC)
>>  #define POWER_POLL_SLEEP_US	6
>>  
>> -#define NR_DOMAINS	5
>> +#define APMU_AUD_CLK		0x80
>> +#define AUDIO_ULCX_ENABLE	0x0d
>
> I would group these with the other register definitions.
>
> Also, it's probably better to be more consistent with the naming, so I'd
> prefer APMU_AUDIO_CLK.

So would I, but this is how the downstream code calls it so my idea was
that it possibly matches the datasheet and it would seem preferable to
me to match that even though we don't have it available.

I could then do the reverse of what you say and call the other
definition AUD_ULCX_ENABLE but AUDIO seems nicer to me too and this one
is not defined in the downstream code.

What do you think?