Re: [PATCH 00/12] of: overlay: clean up device tree overlay code

[Jyri Sarha]

ï
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

On 10/05/17 11:33, Jyri Sarha wrote:
> On 10/05/17 09:53, Tomi Valkeinen wrote:
>> On 04/10/17 17:56, Rob Herring wrote:
>>> On Mon, Oct 2, 2017 at 10:53 PM,  <frowand.list@xxxxxxxxx> wrote:
>>>> From: Frank Rowand <frank.rowand@xxxxxxxx>
>>>>
>>>> I have found the device tree overlay code to be difficult to read and
>>>> maintain.  This patch series attempts to improve that situation.
>>>>
>>>> The cleanup includes some changes visible to users of overlays.  The
>>>> only in kernel user of overlays is fixed up for those changes.  The
>>>> in kernel user is:
>>>>
>>>>    drivers/gpu/drm/tilcdc/tilcdc_slave_compat.c
>>>
>>> At what point can we remove this? I'm assuming at some point users
>>> will need to update their dtb's for other reasons and this becomes
>>> obsolete.
>>
>> To be honest, I have no idea, or how to find that out.
>>
> 
> I think the first approach could be setting the DRM_TILCDC_SLAVE_COMPAT
> default to n and listen if there is any reports about breakage.
> 

After giving it more thought. Maybe we can drop the
DRM_TILCDC_SLAVE_COMPAT in v4.16. 2017 LTS is out already, so there
should be plenty of time for whoever is still using the legacy DTBs to
get rid of them.

>> Do we need to get rid of it? Afaik, we haven't do much (or any?)
>> maintenance on tilcdc_slave_compat.c since it was written, so from our
>> perspective it's been a minimal burden. Is it creating burden for others?
>>
>> Is the approach done with tilcdc_slave_compat.c something that's not
>> recommended? I'm sure similar situations happen with other drivers too,
>> and I think it's a good idea to have a recommended way of keeping
>> compatibility.
>>
> 
> For tilcdc I would say that we soon need a similar mechanism to get rid
> off tilcdc internal panel driver and to start using generic panel
> drivers instead. That is, if we want to keep the kernel compatible with
> old devicetree blobs.
> 

Actually for tilcdc this is not that bad. The messy tilcdc slave
mechanism has been gotten rid of. The rest of tilcdc specific legacy
drivers - the tilcdc legacy panel support and the tilcdc legacy tfp410
driver - do not have any external dependencies and they can basically
remain there for ever for backward compatibility.

But in general, a generic mechanism to translate legacy DTBs to follow a
new binding would be a handy tool in keeping the drivers clean while
keeping up the support for legacy DTBs.

Best regards,
Jyri