Received-SPF: pass (google.com: domain of linux-kernel+bounces-173769-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.48.161 as permitted sender) client-ip=147.75.48.161;
Feedback-ID: i56a14606:Fastmail
User-Agent: Cyrus-JMAP/3.11.0-alpha0-443-g0dc955c2a-fm-20240507.001-g0dc955c2
Precedence: bulk
MIME-Version: 1.0
Message-Id: <41639d6b-a429-43f4-8568-12fcd1671cff@app.fastmail.com>
In-Reply-To: <fe156e32-8ce7-4ce5-99cb-6291ad4b83b0@broadcom.com>
References: <20240503192858.103640-1-florian.fainelli@broadcom.com>
 <8e1867fc-34da-457c-b95a-2d51ea97336a@app.fastmail.com>
 <05a5e893-12f7-49fd-9a9a-abd387571f9b@broadcom.com>
 <ZjjXtEwWWZX43c6l@phenom.ffwll.local>
 <47c63c4c-c657-4210-b476-c91c4f192483@app.fastmail.com>
 <ZjoMI5bJSlqhtOy1@phenom.ffwll.local>
 <41191296-0aa0-4010-b70f-efa80b9200d4@app.fastmail.com>
 <fe156e32-8ce7-4ce5-99cb-6291ad4b83b0@broadcom.com>
Date: Wed, 08 May 2024 21:35:38 +0200
From: "Arnd Bergmann" <arnd@arndb.de>
To: "Florian Fainelli" <florian.fainelli@broadcom.com>,
 "Daniel Vetter" <daniel@ffwll.ch>
Cc: linux-kernel@vger.kernel.org, "Helge Deller" <deller@gmx.de>,
 "Thomas Zimmermann" <tzimmermann@suse.de>,
 "Javier Martinez Canillas" <javierm@redhat.com>,
 "Sam Ravnborg" <sam@ravnborg.org>,
 "open list:FRAMEBUFFER LAYER" <linux-fbdev@vger.kernel.org>,
 "open list:FRAMEBUFFER LAYER" <dri-devel@lists.freedesktop.org>
Subject: Re: [PATCH] fbdev: Have CONFIG_FB_NOTIFY be tristate
Content-Type: text/plain

On Wed, May 8, 2024, at 20:37, Florian Fainelli wrote:
> On 5/7/24 04:44, Arnd Bergmann wrote:
>> On Tue, May 7, 2024, at 13:10, Daniel Vetter wrote:
>>> On Mon, May 06, 2024 at 04:53:47PM +0200, Arnd Bergmann wrote:

>> Right, let's wait for Florian to reply. From what he said earlier
>> though, the only reason that the notifiers are getting in the
>> way is the link error you get from trying to load a separately
>> built fb.ko module on a kernel that was built with FB=n / FB_CORE=n,
>> so I don't think he even cares about notifiers, only about
>> allowing the recovery application to mmap() the framebuffer.
>
> Right, we do not really care about notifiers AFAICT. Based upon this 
> discussion there has been an action on our side to stop making use of 
> the FB subsystem for recovery and use the full blow DRM driver instead.

Ok, sounds good.

> While we get there, though I still see some value into this patch (or a 
> v2, that is). I have a v2 ready if you think there is some value in 
> pursuing that route, if not, we can stop there.

I think if you want to do a new version, that is likely to run
into new problems, given that this part of fbdev is particularly
fragile and partly wrong. On the other hand, it would be nice to
have a patch to limit the use of the notifiers to the smallest
set of kernel configs that actually need it, and leave it turned
off for everything else.

These are the ones I could find:

- CONFIG_GUMSTIX_AM200EPD (FB_EVENT_FB_REGISTERED)
- CONFIG_LCD_CORGI, CONFIG_LCD_TDO24M (FB_EVENT_MODE_CHANGE)
- CONFIG_LEDS_TRIGGER_BACKLIGHT (FB_EVENT_BLANK)
- CONFIG_FB_OLPC_DCON (FB_EVENT_BLANK/BL_CORE_FBBLANK)
- CONFIG_FB_SH_MOBILE_LCDC, CONFIG_BACKLIGHT_PCF50633,
  CONFIG_BACKLIGHT_PANDORA, CONFIG_BACKLIGHT_LP855X (BL_CORE_FBBLANK)
- CONFIG_FB_CLPS711X, CONFIG_FB_IMX, CONFIG_MACH_AMS_DELTA
  (lcd BL_CORE_FBBLANK)
- CONFIG_LCD_AMS369FG06, CONFIG_LCD_CORGI, CONFIG_LCD_HX8357,
  CONFIG_LCD_ILI922X, CONFIG_LCD_ILI9320, CONFIG_LCD_HP700,
  CONFIG_LCD_L4F00242T03, CONFIG_LCD_LMS283GF05, CONFIG_LCD_LMS501KF03
  CONFIG_LCD_LTV350QV, CONFIG_LCD_OTM3225A, CONFIG_LCD_PLATFORM,
  CONFIG_LCD_TDO24M (lcd BL_CORE_FBBLANK)

Almost all of these are exclusive to ancient ARMv5 boards or
similar, so if we make the notifiers depend on the whole list,
this would leave it disabled even for most configurations
that enable CONFIG_FB=y.

This could be done with a 'select', but I'd prefer the
'default y; depends on LCD_FOO || LCD_BAR || ...'
variant because that makes it easier to spot if someone
tries to add another one.

      Arnd