linux-kernel - Re: [PATCH 0/7] coresight: etm4x: Migrate AMBA devices to 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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20230321143356.w5era7et6lzxpte3@bogus>
Date:   Tue, 21 Mar 2023 14:33:56 +0000
From:   Sudeep Holla <sudeep.holla@....com>
To:     Rob Herring <robh+dt@...nel.org>
Cc:     Anshuman Khandual <anshuman.khandual@....com>,
        linux-arm-kernel@...ts.infradead.org, coresight@...ts.linaro.org,
        suzuki.poulose@....com, scclevenger@...amperecomputing.com,
        Frank Rowand <frowand.list@...il.com>,
        Russell King <linux@...linux.org.uk>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        "Rafael J. Wysocki" <rafael@...nel.org>,
        Len Brown <lenb@...nel.org>,
        Lorenzo Pieralisi <lpieralisi@...nel.org>,
        Mathieu Poirier <mathieu.poirier@...aro.org>,
        Mike Leach <mike.leach@...aro.org>,
        Leo Yan <leo.yan@...aro.org>, devicetree@...r.kernel.org,
        linux-acpi@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/7] coresight: etm4x: Migrate AMBA devices to platform
 driver

On Mon, Mar 20, 2023 at 09:17:16AM -0500, Rob Herring wrote:
>
> This sounds like an issue for any amba driver. If this is an issue,
> solve it for everyone, not just work around it in one driver.
>

Well it is an issue in general for power management. ACPI has specific
methods that can be executed for entering specific states.

The way AMBA was glue into ACPI bus scan IMO was a hack and PM wasn't
considered at the time. It was just hack to get AMBA drivers to work
with ACPI without any consideration about runtime PM or any methods that
comes as part of ACPI device. There is even some dummy clock handler to
deal with AMBA requesting APB clocks. AMBA device is added as companion
to the ACPI device created as part of the normal bus scan in ACPI which
adds its own PM callbacks and rely on clocks and power domains independent
of the ACPI standard methods(_ON/_OFF).

The default enumeration adds platform devices which adds no extra PM
callbacks and allows normal acpi_device probe flow.

> When someone puts another primecell device into an ACPI system, are we
> going to go do the same one-off change in that driver too? (We kind of
> already did with SBSA UART...)
>

I would prefer to move all the existing users of ACPI + AMBA to move away
from it and just use platform device. This list is not big today, bunch
of coresight, PL061/GPIO and PL330/DMA. And all these are assumed to be
working or actually working if there is no need for any power management.
E.g. on juno coresight needs PM to turn on before probing and AMBA fails
as dummy clocks are added but no power domains attached as ACPI doesn't
need deal with power domains in the OSPM if it is all well abstracted in
methods like _ON/_OFF. They are dealt with explicit power domain in the
DT which needs to be turned on and AMBA relies on that.

One possible further hacky solution is to add dummy genpd to satisfy AMBA
but not sure if we can guarantee ordering between ACPI device calling ON
and its companion AMBA device probing so that the power domain is ON before
AMBA uses the dummy clock and power domains in its pm callback hooks.

Even the UART would fail if it needed any PM methods, we just don't happen
to need that for SBSA and may be we could have made it work as amba device
(can't recollect the exact reason for not doing so now).

--
Regards,
Sudeep