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

[Bui Duc Phuc]

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.
>
>
> > 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.

>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.

Best regards,
Phuc