From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756247AbdJQIom (ORCPT ); Tue, 17 Oct 2017 04:44:42 -0400 Received: from fllnx209.ext.ti.com ([198.47.19.16]:49426 "EHLO fllnx209.ext.ti.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753215AbdJQIoj (ORCPT ); Tue, 17 Oct 2017 04:44:39 -0400 Subject: Re: [PATCH 00/12] of: overlay: clean up device tree overlay code From: Jyri Sarha To: Tomi Valkeinen , Rob Herring , Frank Rowand CC: Pantelis Antoniou , David Airlie , "devicetree@vger.kernel.org" , "linux-kernel@vger.kernel.org" , Mark Rutland , dri-devel References: <1507002826-16393-1-git-send-email-frowand.list@gmail.com> <3eac16b0-fdd9-fd6c-e1ca-e0de49ce27cb@ti.com> <96045775-4142-1d2d-52f6-d76c0a982461@ti.com> Message-ID: <0de3ee8a-5dca-8f3b-67aa-6d7f405828f6@ti.com> Date: Tue, 17 Oct 2017 11:43:12 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <96045775-4142-1d2d-52f6-d76c0a982461@ti.com> Content-Type: text/plain; charset="utf-8" Content-Language: en-GB X-EXCLAIMER-MD-CONFIG: e1e8a2fd-e40a-4ac6-ac9b-f7e9cc9ee180 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by nfs id v9H8inVZ031811  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, wrote: >>>> From: Frank Rowand >>>> >>>> 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