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

[Rob Herring]

On Thu, Apr 30, 2026 at 12:12:55AM +0700, Bui Duc Phuc wrote:
> Hi,
> 
> > Yes. And the ABI. You cannot have ABI which has an incompatible
> > implementation. IOW, when implementation contradicts the ABI, something
> > is wrong.
> >
> > The question of course if read_bool() is here incompatible. From the
> > actual code point of view, it is compatible, but how it is documented
> > and how it is intended to use: it is not compatible.
> >
> > Also if future schema-kernel-ABI checker gets implemented, the tool
> > might report here a mistake for that reason. read_bool() means property
> > is bool.

It is doubtful such a tool would do per binding type checking given 
types are global and we've avoided making types per binding so far.

> >
> > > If the hardware supports wakeup functionality,
> > > referencing the core schema is sufficient. Hardware description should
> > > not be constrained by the current driver implementation
> > > ( e.g. the use of device_property_read_bool() ).
> > > Bindings should remain stable and generic, while drivers can evolve over time.
> > So you claim that bindings can define property as integer, but drivers
> > can evolve and for example read it as string?
> 
> I see your point regarding the ABI semantics and the intended use of
> read_bool().
> My understanding is that the I2C core currently uses of_property_read_bool()
> for wakeup-source as a presence check, even though it has no way to
> determine in advance whether a specific device will define the property as
> a boolean or a phandle-array in its DTS.

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.

> >From a behavioral point of view, switching to of_property_present() would
> not change anything, but it would better reflect that the driver only checks
> for the existence of the property without assuming its type.
> 
> If the expectation is to strictly follow the binding types, then
> of_property_present()
> seems more appropriate here.
> I can prepare a patch accordingly and send it to the I2C maintainers for
> review and feedback.
> 
> > >
> > > Re-defining the type locally duplicates the core definition. If the
> > > core schema evolves,
> >
> > There is no re-definition here. This is choice of subset of types.
> 
> The flow is: core schema → YAML binding (ABI) → DTS (actual usage).
> >From a high-level perspective, the binding may appear to redefine the
> property type by narrowing its scope, while the DTS selects one valid
> representation from the permitted set.
> 
> > Where is Rob's suggestion to do such cleanups for EXISTING code? I only
> > see that new code should come like that.
> >
> > Anyway, your commit msg is for me incorrect because it misses all this
> > points I made. Whether the schema code is correct, I'll defer to Rob,
> > although I still claim the same I claimed before at v2 or v3 of your
> > previous work - this should have defined type.
> 
> You are right that Rob did not explicitly request cleanups to existing code.
> I included them to improve consistency while working on the new parts,
> but for now, I will stop modifying the existing code and wait for
> Rob's feedback.
> Since there are differing perspectives, I would appreciate a consensus
> on the preferred
> approach before I send out the next version to avoid redundant rework.

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.

Rob