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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <0de3ee8a-5dca-8f3b-67aa-6d7f405828f6@ti.com>
Date:   Tue, 17 Oct 2017 11:43:12 +0300
From:   Jyri Sarha <jsarha@...com>
To:     Tomi Valkeinen <tomi.valkeinen@...com>,
        Rob Herring <robh+dt@...nel.org>,
        Frank Rowand <frowand.list@...il.com>
CC:     Pantelis Antoniou <pantelis.antoniou@...sulko.com>,
        David Airlie <airlied@...ux.ie>,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Mark Rutland <mark.rutland@....com>,
        dri-devel <dri-devel@...ts.freedesktop.org>
Subject: Re: [PATCH 00/12] of: overlay: clean up device tree overlay code


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@...il.com> wrote:
>>>> From: Frank Rowand <frank.rowand@...y.com>
>>>>
>>>> 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