From: Thomas Zimmermann <tzimmermann@suse.de>
To: Chintan Patel <chintanlike@gmail.com>,
linux-fbdev@vger.kernel.org, linux-staging@lists.linux.dev,
linux-omap@vger.kernel.org
Cc: linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org,
andy@kernel.org, deller@gmx.de, gregkh@linuxfoundation.org
Subject: Re: [PATCH 0/3] fbdev: Guard sysfs interfaces under CONFIG_FB_DEVICE
Date: Tue, 9 Dec 2025 08:27:26 +0100 [thread overview]
Message-ID: <19e8a1b0-75e3-4c8d-911a-15fd70f60bea@suse.de> (raw)
In-Reply-To: <20251209042744.7875-1-chintanlike@gmail.com>
Hi
Am 09.12.25 um 05:27 schrieb Chintan Patel:
> Hi all,
>
> This small series makes several legacy fbdev drivers buildable with
> CONFIG_FB_DEVICE=n. Currently, multiple fbdev drivers rely on fb_info->dev
> and sysfs attribute registration unconditionally, which leads to build
> failures whenever FB_DEVICE is disabled.
>
> Thomas previously noted that FB_DEVICE should eventually become optional
> and that drivers should not depend on sysfs or fb_info->dev being present
> unless the Kconfig explicitly selects it. This series pushes in that
> direction by tightening the FB_DEVICE dependency boundary without changing
> any runtime behaviour when FB_DEVICE=y.
>
> What this series does *not* change
>
> - No functional behaviour changes when FB_DEVICE=y.
> - No removal of sysfs interfaces.
> - No changes to fbops, memory allocation, or display update paths.
>
> Build & test coverage
>
> Tested with the following combinations:
>
> 1. **FB=y, FB_DEVICE=y**
> - Baseline configuration; no regressions expected.
>
> 2. **FB=y, FB_DEVICE=n**
> - Drivers build successfully.
> - No sysfs attributes are created.
> - fbdev devices operate normally (where applicable).
>
> 3. **FB=n**
> - Drivers depend on FB, so they properly do not build, unchanged.
>
> Motivation
>
> This moves fbdev closer to supporting FB_DEVICE as truly optional, helps
> reduce Kconfig entanglement, and clears several long-standing TODO items
> as suggested by Thomas Zimmermann around legacy sysfs usage inside fbdev
> drivers.
>
> Feedback is welcome, especially on whether the guard boundaries around
> sysfs are placed correctly or whether more logic should be pulled under
> CONFIG_FB_DEVICE.
I left a comment on the first patch. If things still build nicely, then
Acked-by: Thomas Zimmermann <tzimmermann@suse.de>
for the series.
Best regards
Thomas
>
> Thanks,
> Chintan
>
> Chintan Patel (3):
> fbtft: Make sysfs and dev_*() logging conditional on FB_DEVICE
> omapfb: Guard sysfs code under CONFIG_FB_DEVICE
> sh_mobile_lcdc: Guard overlay sysfs interfaces under CONFIG_FB_DEVICE
>
> drivers/staging/fbtft/fbtft-core.c | 20 +++++++++++++++++--
> drivers/staging/fbtft/fbtft-sysfs.c | 8 ++++++++
> drivers/video/fbdev/omap2/omapfb/Kconfig | 2 +-
> .../video/fbdev/omap2/omapfb/omapfb-sysfs.c | 11 ++++++++++
> drivers/video/fbdev/sh_mobile_lcdcfb.c | 4 ++++
> 5 files changed, 42 insertions(+), 3 deletions(-)
>
--
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstr. 146, 90461 Nürnberg, Germany, www.suse.com
GF: Jochen Jaser, Andrew McDonald, Werner Knoblich, (HRB 36809, AG Nürnberg)
next prev parent reply other threads:[~2025-12-09 7:27 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-12-09 4:27 [PATCH 0/3] fbdev: Guard sysfs interfaces under CONFIG_FB_DEVICE Chintan Patel
2025-12-09 4:27 ` [PATCH 1/3] fbtft: Make sysfs and dev_*() logging conditional on FB_DEVICE Chintan Patel
2025-12-09 7:25 ` Thomas Zimmermann
2025-12-10 4:24 ` Chintan Patel
2025-12-09 4:27 ` [PATCH 2/3] omapfb: Guard sysfs code under CONFIG_FB_DEVICE Chintan Patel
2025-12-09 4:27 ` [PATCH 3/3] sh_mobile_lcdc: Guard overlay sysfs interfaces " Chintan Patel
2025-12-09 7:27 ` Thomas Zimmermann [this message]
2025-12-09 8:22 ` [PATCH 0/3] fbdev: Guard " Helge Deller
2025-12-09 8:42 ` Thomas Zimmermann
2025-12-09 14:25 ` Andy Shevchenko
2025-12-10 4:26 ` Chintan Patel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=19e8a1b0-75e3-4c8d-911a-15fd70f60bea@suse.de \
--to=tzimmermann@suse.de \
--cc=andy@kernel.org \
--cc=chintanlike@gmail.com \
--cc=deller@gmx.de \
--cc=dri-devel@lists.freedesktop.org \
--cc=gregkh@linuxfoundation.org \
--cc=linux-fbdev@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-omap@vger.kernel.org \
--cc=linux-staging@lists.linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).