linux-kernel - Re: [PATCH v2 3/4] ASoC: apple: mca: Start new platform driver

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: <6C89CA60-D0E2-4869-B21C-17AD4AA1974C@cutebit.org>
Date:   Tue, 23 Aug 2022 13:51:35 +0200
From:   Martin Povišer <povik+lin@...ebit.org>
To:     Mark Brown <broonie@...nel.org>
Cc:     Liam Girdwood <lgirdwood@...il.com>,
        Rob Herring <robh+dt@...nel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        Hector Martin <marcan@...can.st>,
        Sven Peter <sven@...npeter.dev>,
        Philipp Zabel <p.zabel@...gutronix.de>,
        Alyssa Rosenzweig <alyssa@...enzweig.io>,
        asahi@...ts.linux.dev, alsa-devel@...a-project.org,
        devicetree@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 3/4] ASoC: apple: mca: Start new platform driver



> On 23. 8. 2022, at 13:31, Mark Brown <broonie@...nel.org> wrote:
> 
> On Tue, Aug 23, 2022 at 09:33:36AM +0200, Martin Povišer wrote:
>>> On 22. 8. 2022, at 19:39, Mark Brown <broonie@...nel.org> wrote:
>>> On Fri, Aug 19, 2022 at 02:54:29PM +0200, Martin Povišer wrote:

>>>> +	/*
>>>> +	 * We can't power up the device earlier than this because
>>>> +	 * the power state driver would error out on seeing the device
>>>> +	 * as clock-gated.
>>>> +	 */
>>>> +	cl->pd_link = device_link_add(mca->dev, cl->pd_dev,
>>>> +				      DL_FLAG_STATELESS | DL_FLAG_PM_RUNTIME |
>>>> +					      DL_FLAG_RPM_ACTIVE);
> 
>>> I'm not clear on this dynamically adding and removing device links stuff
>>> - it looks like the main (only?) purpose is to take a runtime PM
>>> reference to the target device which is fine but it's not clear why
>>> device links are involved given that the links are created and destroyed
>>> every time the DAI is used, AFAICT always in the same fixed
>>> relationship.  It's not a problem, it's just unclear.
> 
>> Indeed the only purpose is powering up the cluster’s power domain (there’s
>> one domain for each cluster). Adding the links is the only way I know to
>> do it. They need to be added dynamically (as opposed to statically linking,
>> say, the DAI’s ->dev to the cluster’s ->pd_dev, which I guess may do
>> something similar), because we need to sequence the power-up/power-down
>> with the enablement of the clocks.
> 
> You could also just do the underlying runtime power management
> operations directly couldn't you?  It's not clear what the device link
> stuff is adding.

This seems to be the way to do it. Quoting from documentation of
dev_pm_domain_attach_by_id, by which we obtain the mca->dev and cl->pd_dev
the link is between:

 * This function should typically be invoked by a driver during the probe phase,
 * in case its device requires power management through multiple PM domains. The
 * driver may benefit from using the received device, to configure device-links
 * towards its original device. Depending on the use-case and if needed, the
 * links may be dynamically changed by the driver, which allows it to control
 * the power to the PM domains independently from each other.

--
Martin