[PATCH v1 02/17] Revert "ARM: dts: imx6qdl-apalis: Avoid underscore in node name"
Ahmad Fatoum
a.fatoum at pengutronix.de
Mon May 16 08:07:50 PDT 2022
Hello Francesco,
On 16.05.22 16:53, Francesco Dolcini wrote:
> On Mon, May 16, 2022 at 02:49:12PM +0200, Ahmad Fatoum wrote:
>> On 16.05.22 13:58, Max Krummenacher wrote:
>>> From: Max Krummenacher <max.krummenacher at toradex.com>
>>>
>>> The STMPE MFD device binding requires the child node to have a fixed
>>> name, i.e. with '_', not '-'. Otherwise the stmpe_adc, stmpe_touchscreen
>>> drivers will not be probed.
>>
>> IMO, the Linux driver should be fixed and the requirement to use a fixed
>> node name be dropped from the binding. The driver itself already probes
>> by compatible, the node name seems only to be used by the MFD driver to
>> detect which functions to enable. It could do the same by checking for
>> compatibles. Otherwise you invite a game of cat and mouse, where in
>> future, this is changed back again reintroducing the regression..
>
> How would you handle in general such kind of change? Would you keep the
> driver probing for both the old name with the `_` and the compatible or
> you just break the compatibility?
The Binding requires child nodes to have both a specific node name and
compatible. So if we remove the node name restriction, we stay compliant
to the binding.
The MFD driver requires specific node names, while the MFD cell drivers
seem to be matched by compatibles. It's thus should be safe to replace
the node name readout in the MFD driver with a compatible check.
Existing device trees will continue to work. Newer device trees can use
dashes. Once the binding is converted to YAML, we could enforce a name
to get everyone aligned, but it will be just a binding checker warning,
not a breakage on update.
Cheers,
Ahmad
>
> Francesco
>
>
--
Pengutronix e.K. | |
Steuerwalder Str. 21 | http://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
More information about the linux-arm-kernel
mailing list