[PATCH v7 4/6] arm64: dts: imx8mp: convert 'aips5' to 'aipstz5'

[Laurentiu Mihalcea]

On 7/3/2025 6:25 PM, Mark Brown wrote:
> On Wed, Jul 02, 2025 at 10:54:09PM +0300, Laurentiu Mihalcea wrote:
>> On 7/2/2025 9:49 PM, Mark Brown wrote:
>>> On Tue, Jun 10, 2025 at 12:01:50PM -0400, Laurentiu Mihalcea wrote:
>>>> Finally, since AIPSTZ5 belongs to the AUDIOMIX power domain, add the
>>>> missing 'power-domains' property. The domain needs to be powered on before
>>>> attempting to configure the security-related registers.
>>> I'm seeing failures to probe the audio devices on the i.MX8MP Verdin
>>> system in -next which seem to bisect down to this commit,  I'm seeing
>>> separate boot failures on the EVK so haven't been able to confirm the
>>> status there.  There's no obvious logging, the dt selftest shows:
>> Thanks for catching this!
>> After browsing through the provided logs it would seem like no device under the
>> AIPSTZ bus gets probed. Right now, my guess is that the AIPSTZ driver is not being
>> compiled since CONFIG_IMX_AIPSTZ might be set to 'n'.
>> Which defconfig is the CI using? Is it arch/arm64/configs/defconfig?
> This also appears to be the source of the boot issues I mentioned on the
> EVK, affecting ramdisk only boots:
>
>    https://lava.sirena.org.uk/scheduler/job/1533032
>
> as well as NFS.  The board seems to get to userspace but then not
> respond to serial input, it looks like it's hit something while loading
> modules and locked up but ICBW.

OK, this is very odd. I've tried the ramdisk boot using the files from the CI job: Image,
modules, CPIO and my own flash.bin (u-boot and ATF hashes match those shown in
the CI job) on an EVK board and so far no hang.

What I've noticed though is that the bridge does indeed not get probed. So, for now,
I think I'm going to submit a patch to enable the driver config in the defconfig so
we can get the Verdin failures out of the way.