Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Message-ID: <1d00ed48-0606-823c-58c4-e45948383c42@gmx.de>
Date:   Wed, 26 Jan 2022 12:51:46 +0100
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
 Thunderbird/91.3.0
Subject: Re: [PATCH v1 0/4] fbtft: Unorphan the driver for maintenance
Content-Language: en-US
To:     Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc:     Javier Martinez Canillas <javierm@redhat.com>,
        Andy Shevchenko <andy.shevchenko@gmail.com>,
        Thomas Zimmermann <tzimmermann@suse.de>,
        Andy Shevchenko <andy@kernel.org>, linux-fbdev@vger.kernel.org,
        Michael Hennerich <michael.hennerich@analog.com>,
        linux-staging@lists.linux.dev, linux-kernel@vger.kernel.org,
        dri-devel@lists.freedesktop.org,
        Phillip Potter <phil@philpotter.co.uk>,
        Carlis <zhangxuezhi1@yulong.com>,
        Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
        Lee Jones <lee.jones@linaro.org>,
        Heiner Kallweit <hkallweit1@gmail.com>
References: <20220125202118.63362-1-andriy.shevchenko@linux.intel.com>
 <991e988b-7225-881b-a59a-33c3eae044be@suse.de>
 <CAHp75Vc2cjHkJwNSiJ-HSWBG=DYy68uvD7QQzNdRp3mQxoY1nw@mail.gmail.com>
 <3877516e-3db3-f732-b44f-7fe12b175226@gmx.de>
 <b13c0634-e766-74db-ab1f-672f5d0c04d6@redhat.com>
 <6f508ff0-1807-7665-6c93-7f3eea4a1bdd@gmx.de> <YfEyo2xxfFyl2ADI@kroah.com>
From:   Helge Deller <deller@gmx.de>
In-Reply-To: <YfEyo2xxfFyl2ADI@kroah.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

On 1/26/22 12:38, Greg Kroah-Hartman wrote:
> On Wed, Jan 26, 2022 at 12:31:21PM +0100, Helge Deller wrote:
>> On 1/26/22 12:18, Javier Martinez Canillas wrote:
>>> On 1/26/22 11:59, Helge Deller wrote:
>>>> On 1/26/22 11:02, Andy Shevchenko wrote:
>>>
>>> [snip]
>>>
>>>>> P.S. For the record, I will personally NAK any attempts to remove th=
at
>>>>> driver from the kernel. And this is another point why it's better no=
t
>>>>> to be under the staging.
>>>>
>>>> I agree. Same as for me to NAK the disabling of fbcon's acceleration
>>>> features or even attempting to remove fbdev altogether (unless all
>>>> relevant drivers are ported to DRM).
>>>>
>>>
>>> But that will never happen if we keep moving the goal post.
>>>
>>> At some point new fbdev drivers should not be added anymore, otherwise
>>> the number of existing drivers that need conversion will keep growing.
>>
>> Good point, and yes you are right!
>>
>> I think the rule should be something like:
>>
>> New graphics devices (e.g. max. 3 years old from now) usually are
>> capable to be ported to DRM.
>> For those graphics cards we should put a hard stop and not include them
>> as new driver into the fbdev framework. Inclusion for those will only
>> happen as DRM driver.
>
> We made this rule 6 years ago already.

Very good.

Was there any decision how to handle drivers which can't use DRM,
or for which DRM doesn't make sense?

So the best way forward regarding those fbtft drivers is probably what
you suggested: Split them and move those DRM-capable drivers to DRM,
the others to fbdev, right?

Helge