From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pj1-f52.google.com (mail-pj1-f52.google.com [209.85.216.52]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 1AF502236EB for ; Tue, 9 Dec 2025 04:28:08 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.216.52 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1765254490; cv=none; b=BofRyErz3pyqze2cS/SP2QisR0utrIV6InwDYyx2zfpkSDi9iK/pOdlxexhhUJkTdkUAEStGuvmhUpih+dqMtMz6PPCE+NSakvWsSpuKHLR8eTPwgNs1KZeY2ZOsaqVQSwQOSvl2VOzuf9bsxv0Dk9xGRQTyX1ygoL7QkAnYFec= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1765254490; c=relaxed/simple; bh=LsB2Rw1u+BAgI+Dke597qwki4yRQSIPkKWxz+iJXnKI=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=VKNE437xcHKbps6LvMPFO+J9y+dBnEv38MWX98IQDYf3A7BAZmffjK2qjQD3KvZPJW8kL5JIk2f/Nv1U2sg8MoZ5gP7RnWO2XimM1IQzAP3oXbjwwtSPHUKZaXV8pYxnHjmrt+w95Q3bwv8iJzzaplCEPcmiY9Uddaz4jnsWOaQ= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=iP0wR6bJ; arc=none smtp.client-ip=209.85.216.52 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="iP0wR6bJ" Received: by mail-pj1-f52.google.com with SMTP id 98e67ed59e1d1-343dd5aa6e7so5679371a91.0 for ; Mon, 08 Dec 2025 20:28:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1765254488; x=1765859288; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=OlS8NGZoUAbx3WVREmoqnUjbjOgDJ/P+b1vdg2wt/Bk=; b=iP0wR6bJhNO2gY/tLDMnaPxTUfxT3IY2A6qwLfRmR4lDwH2mxSx80g+NuX2fU5Avh2 RtMIaM1Ct5EbYwd8lBXHySUhbXEO76C6vzWSotMBnW5mEoTSpy8YYlG46DrJd+5AGEaW dc1Vo1t5beMYsJqIl8J6kZicAdBBpwTsLeBWtTgayKeluikViLXlY89Gjco/kcFpm3nC ymGpJwMNHTmz+S5SIH7DCrOmdBNA8pt1lTZ9EH4oVgtxHSgPSK2YeyPRBES2ejxXVKtA 7AwXDl70ZAEPcjciiIOO0Xo/U05w6s/n/s25iwawuacLqF76nzDt+GUK+wv+/5ARakW9 8Chg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1765254488; x=1765859288; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=OlS8NGZoUAbx3WVREmoqnUjbjOgDJ/P+b1vdg2wt/Bk=; b=XYuvcbhpVdqbLDarX9axkP15uhv1oEeEzrBxBa9z3iSBpT8tRYLr9F5HdZo2BB/nNA ZyzOQsBD6RUJEiKtBEWWxAJV4Su0bsDqSPQZzjZOE7Hwpm3GYAz5cihFEMjKiEPAgh1/ zCyEKjuW02hIxaH2XCEMb4g7m0l/E88sewI6iIZicucUOeiuDIzBcpIMjPw8nndWC+Kr hCXEfGxemmcNngPn71W+HiuOmnxqTzCtx0xAAleW95SCEl4EOxOBd+9KCCknr3PrXdrg dg8I0Km/zub/KBhgAm9bAUX6LTEatLEYJMU+l6CKJslwipPbQoxKyHTg+iR7Ulyu4Tff IZkg== X-Gm-Message-State: AOJu0YzerBum38zZAQnqkV2sCSokMMZlb+EqM6n5vo0rGE7csq/cOguY 0C29DDNwzLHuW6j4vggQBbeEQ+3jqjI/dhU5HmuGmLbyjGY9iQSucUkW X-Gm-Gg: ASbGncusL1hieilTPPjgsm5DAa/lwVrKrwlaQwC9l+hVRhHZYjuMlX5nykLU9ZC0bT7 Iw+FyfCZ2BPOcl9tcJrs7oZfdjn8EzmRTFoyvIT+tyFfxwcP2bVbitklEvpyxAWJHVYx9DKtIZQ 3PCxdAVY9HNJszJnAldTJ33BuhWF1y6CbAlFp7aqcCT6o1mH5VnViIGZFTK2jVQ5pffzt3saFjZ RCjzccqaY2zyDnWcqDbgh/5CXOzH+i6SVuR5muvyS9fwkjwnN6ygWi+Z1j2m1IZNK71Pu4ExgGT XV6mxy/WhEgeatoFgnuBGxnFGC3CYJJGGiwm/X40LMf8Rk5sVpUA63HQ0wUvaI+s13KSb4degle 3klQ2zhaohVQ550IF+jctP3hKlp5aPoUPMOK8sWme5v1iLMKA0NJ50IsTXmGbbXJJFmVVaJPx0z tliVYtmdG08skHn0aPnvDVxyXoia4O4rZTaQK+WNB3/8ZbpMI8e/VLvw== X-Google-Smtp-Source: AGHT+IFg1iIMyFLucr9uOHmmv9GE122UxHPeUmvBUIJroW50FItL/tqkSaQEcjZrl0Un6zQJ6OWfHQ== X-Received: by 2002:a17:90b:1e07:b0:340:c64d:38d3 with SMTP id 98e67ed59e1d1-349a2511cbdmr10578046a91.12.1765254488312; Mon, 08 Dec 2025 20:28:08 -0800 (PST) Received: from cmpatel-home.hsd1.or.comcast.net ([2601:1c0:5780:9200:b455:298d:48bb:1784]) by smtp.gmail.com with ESMTPSA id 98e67ed59e1d1-34a49b90fd5sm765185a91.10.2025.12.08.20.28.07 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 08 Dec 2025 20:28:07 -0800 (PST) From: Chintan Patel To: 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, tzimmermann@suse.de, andy@kernel.org, deller@gmx.de, gregkh@linuxfoundation.org, Chintan Patel Subject: [PATCH 0/3] fbdev: Guard sysfs interfaces under CONFIG_FB_DEVICE Date: Mon, 8 Dec 2025 20:27:41 -0800 Message-ID: <20251209042744.7875-1-chintanlike@gmail.com> X-Mailer: git-send-email 2.43.0 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit 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. 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(-) -- 2.43.0