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] [thread-next>] [day] [month] [year] [list]

Message-ID: <96045775-4142-1d2d-52f6-d76c0a982461@ti.com>
Date:   Thu, 5 Oct 2017 11:33:32 +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 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.

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

Best regards,
Jyri