[PATCH 2/2] ASoC: dt-bindings: drop redundant wakeup-source definitions

[Bui Duc Phuc]

Hi Rob, Krzysztof,

On Wed, May 6, 2026 at 4:10 AM Rob Herring <robh at kernel.org> wrote:
>
> If this was a problem, then it probably would have been fixed already
> because it generates a warning. An I2C device probably isn't all that
> coupled to SoC power states, so boolean is probably always going to be
> used here. But maybe not.
>
> If we do any cleanup here, I think that should have exactly 1 location
> that reads this property instead of 77. Perhaps the driver core can just
> handle everything and drivers don't have to deal with it.
>

Yes, the I2C core already handles the 'wakeup-source' property centrally;
therefore, individual device drivers do not need to implement their
own handling.

While no I2C devices currently utilize the 'phandle-array' type for
this property,
we should ensure the infrastructure is future-proof. In cases where a
phandle is used,
additional firmware-level handling might be required depending on the
SoC architecture,
similar to how the m_can driver operates on TI SoCs.

References for that implementation can be found here:
Firmware: https://elixir.bootlin.com/linux/v7.1-rc2/source/drivers/firmware/ti_sci.c
DTS: https://elixir.bootlin.com/linux/v7.1-rc2/source/arch/arm64/boot/dts/ti/k3-am62a7-sk.dts

To address this and align the code with the core schema, I have
previously submitted patches
to transition the I2C core and clean up the m_can driver:

I2C core patch:
https://lore.kernel.org/all/20260505043145.33284-1-phucduc.bui@gmail.com/
m_can patch: https://lore.kernel.org/all/20260504050702.34013-1-phucduc.bui@gmail.com/


> It's really outside the scope of a device binding what is used for
> wakeup-source as that depends on the platform. So I think just
> 'wakeup-source: true' in device bindings is fine. I don't think we have
> to change all the existing cases either, but the patches are already
> written so I don't have an issue applying them.

Understood. I will update the commit message wording in the next
version.

Best regards,
Phuc