* Re: [PATCH 13/13] lib/fonts: Remove internal symbols and macros from public header file
From: kernel test robot @ 2026-02-19 2:08 UTC (permalink / raw)
To: Thomas Zimmermann, gregkh, deller, sam
Cc: oe-kbuild-all, linux-fbdev, dri-devel, linux-kernel,
Thomas Zimmermann
In-Reply-To: <20260218083855.10743-14-tzimmermann@suse.de>
Hi Thomas,
kernel test robot noticed the following build errors:
[auto build test ERROR on 0082025812a31eda451fb14f13f52683ed375c49]
url: https://github.com/intel-lab-lkp/linux/commits/Thomas-Zimmermann/fbdev-Declare-src-parameter-of-fb_pad_-helpers-as-constant/20260218-164243
base: 0082025812a31eda451fb14f13f52683ed375c49
patch link: https://lore.kernel.org/r/20260218083855.10743-14-tzimmermann%40suse.de
patch subject: [PATCH 13/13] lib/fonts: Remove internal symbols and macros from public header file
config: powerpc-allmodconfig (https://download.01.org/0day-ci/archive/20260219/202602191044.XKx5ACdn-lkp@intel.com/config)
compiler: powerpc64-linux-gcc (GCC) 15.2.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260219/202602191044.XKx5ACdn-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202602191044.XKx5ACdn-lkp@intel.com/
All errors (new ones prefixed by >>):
In file included from arch/powerpc/kernel/btext.c:23:
arch/powerpc/kernel/btext.c: In function 'draw_byte':
>> arch/powerpc/kernel/btext.c:467:46: error: 'font_sun_8x16' undeclared (first use in this function); did you mean 'font_vga_8x16'?
467 | const unsigned char *font = PTRRELOC(font_sun_8x16.data) + font_index;
| ^~~~~~~~~~~~~
arch/powerpc/include/asm/setup.h:19:34: note: in definition of macro 'PTRRELOC'
19 | #define PTRRELOC(x) ((typeof(x)) add_reloc_offset((unsigned long)(x)))
| ^
arch/powerpc/kernel/btext.c:467:46: note: each undeclared identifier is reported only once for each function it appears in
467 | const unsigned char *font = PTRRELOC(font_sun_8x16.data) + font_index;
| ^~~~~~~~~~~~~
arch/powerpc/include/asm/setup.h:19:34: note: in definition of macro 'PTRRELOC'
19 | #define PTRRELOC(x) ((typeof(x)) add_reloc_offset((unsigned long)(x)))
| ^
vim +467 arch/powerpc/kernel/btext.c
7191b615759ec1 Benjamin Herrenschmidt 2013-07-25 462
7191b615759ec1 Benjamin Herrenschmidt 2013-07-25 463 static noinline void draw_byte(unsigned char c, long locX, long locY)
7191b615759ec1 Benjamin Herrenschmidt 2013-07-25 464 {
7191b615759ec1 Benjamin Herrenschmidt 2013-07-25 465 unsigned char *base = calc_base(locX << 3, locY << 4);
0ebc7feae79ac0 Dr. David Alan Gilbert 2023-08-25 466 unsigned int font_index = c * 16;
b94b7356756164 Finn Thain 2025-11-10 @467 const unsigned char *font = PTRRELOC(font_sun_8x16.data) + font_index;
7191b615759ec1 Benjamin Herrenschmidt 2013-07-25 468 int rb = dispDeviceRowBytes;
7191b615759ec1 Benjamin Herrenschmidt 2013-07-25 469
7191b615759ec1 Benjamin Herrenschmidt 2013-07-25 470 rmci_maybe_on();
7191b615759ec1 Benjamin Herrenschmidt 2013-07-25 471 switch(dispDeviceDepth) {
7191b615759ec1 Benjamin Herrenschmidt 2013-07-25 472 case 24:
7191b615759ec1 Benjamin Herrenschmidt 2013-07-25 473 case 32:
7191b615759ec1 Benjamin Herrenschmidt 2013-07-25 474 draw_byte_32(font, (unsigned int *)base, rb);
7191b615759ec1 Benjamin Herrenschmidt 2013-07-25 475 break;
7191b615759ec1 Benjamin Herrenschmidt 2013-07-25 476 case 15:
7191b615759ec1 Benjamin Herrenschmidt 2013-07-25 477 case 16:
7191b615759ec1 Benjamin Herrenschmidt 2013-07-25 478 draw_byte_16(font, (unsigned int *)base, rb);
7191b615759ec1 Benjamin Herrenschmidt 2013-07-25 479 break;
7191b615759ec1 Benjamin Herrenschmidt 2013-07-25 480 case 8:
7191b615759ec1 Benjamin Herrenschmidt 2013-07-25 481 draw_byte_8(font, (unsigned int *)base, rb);
7191b615759ec1 Benjamin Herrenschmidt 2013-07-25 482 break;
7191b615759ec1 Benjamin Herrenschmidt 2013-07-25 483 }
7191b615759ec1 Benjamin Herrenschmidt 2013-07-25 484 rmci_maybe_off();
7191b615759ec1 Benjamin Herrenschmidt 2013-07-25 485 }
7191b615759ec1 Benjamin Herrenschmidt 2013-07-25 486
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH -next v9 1/3] rust: clist: Add support to interface with C linked lists
From: Alexandre Courbot @ 2026-02-19 2:47 UTC (permalink / raw)
To: Joel Fernandes
Cc: linux-kernel, Maarten Lankhorst, Maxime Ripard, Simona Vetter,
Jonathan Corbet, Alex Deucher, Christian König, Jani Nikula,
Joonas Lahtinen, Rodrigo Vivi, Tvrtko Ursulin, Huang Rui,
Matthew Auld, Matthew Brost, Lucas De Marchi,
Thomas Hellström, Helge Deller, Danilo Krummrich, Alice Ryhl,
Miguel Ojeda, Alex Gaynor, Boqun Feng, Gary Guo,
Björn Roy Baron, Benno Lossin, Andreas Hindborg,
Trevor Gross, Alistair Popple, Andrea Righi, Zhi Wang,
Philipp Stanner, Elle Rhumsaa, Daniel Almeida, nouveau, dri-devel,
rust-for-linux, linux-doc, amd-gfx, intel-gfx, intel-xe,
linux-fbdev
In-Reply-To: <1771462209.c70cb872032e4abe@nvidia.com>
On Thu Feb 19, 2026 at 9:59 AM JST, Joel Fernandes wrote:
> On Thu, 19 Feb 2026 09:35:31 +0900, Alexandre Courbot wrote:
>
> [...]
>
>> I asked this a couple of times ([1], [2]) but got no reply, so let me
>> try again. :) Given that `list_head` is doubly-linked, can we also
>> implement `DoubleEndedIterator`?
>>
>> This can be done in a follow-up patch but should be there eventually as
>> C lists are often parsed in both directions.
>>
>> [1] https://lore.kernel.org/all/DEGQCMSX1SGZ.2NQDPG5KUNA9D@nvidia.com/
>> [2] https://lore.kernel.org/all/DEOLRLCZQMBG.1WHBR4YL8SKYR@nvidia.com/
>
> There was a lot of redesign and you only mentioned it as an optional
> suggestion and there several higher priority comments.
>
> Anyway, I disagree. I don't think there's a use case for
> DoubleEndedIterator at the moment -- none of the current users of clist need
> reverse iteration. I'd prefer to keep the interface minimal and add it when
> there's an actual need for it, rather than adding API surface that nobody
> uses. If a usecase comes up, we can always trivially add it.
It's a double-linked list still, and `DoubleEndedIterator` a standard
Rust trait. Adding it now would spare us the trouble of deciding which
tree takes the feature when it eventually lands.
But even without it the series still stands, so your call.
^ permalink raw reply
* Re: [PATCH v10 2/8] gpu: Move DRM buddy allocator one level up (part two)
From: Alexandre Courbot @ 2026-02-19 3:18 UTC (permalink / raw)
To: Joel Fernandes
Cc: linux-kernel, David Airlie, Simona Vetter, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, Jonathan Corbet, Shuah Khan,
Matthew Auld, Arun Pravin, Christian Koenig, Alex Deucher,
Jani Nikula, Joonas Lahtinen, Rodrigo Vivi, Tvrtko Ursulin,
Huang Rui, Matthew Brost, Thomas Hellström, Helge Deller,
Danilo Krummrich, Miguel Ojeda, Dave Airlie, Gary Guo,
Daniel Almeida, Koen Koning, dri-devel, nouveau, rust-for-linux,
linux-doc, amd-gfx, intel-gfx, intel-xe, linux-fbdev
In-Reply-To: <20260218205507.689429-3-joelagnelf@nvidia.com>
On Thu Feb 19, 2026 at 5:55 AM JST, Joel Fernandes wrote:
> Move the DRM buddy allocator one level up so that it can be used by GPU
> drivers (example, nova-core) that have usecases other than DRM (such as
> VFIO vGPU support). Modify the API, structures and Kconfigs to use
> "gpu_buddy" terminology. Adapt the drivers and tests to use the new API.
>
> The commit cannot be split due to bisectability, however no functional
> change is intended. Verified by running K-UNIT tests and build tested
> various configurations.
Patches 1 and 2 have the exact same commit log, but each one does only
part of it. Let's only keep the part of the log that applies to each
patch.
>
> Signed-off-by: Joel Fernandes <joelagnelf@nvidia.com>
> Reviewed-by: Dave Airlie <airlied@redhat.com>
> [airlied: I've split this into two so git can find copies easier.
> I've also just nuked drm_random library, that stuff needs to be done
> elsewhere and only the buddy tests seem to be using it].
> Signed-off-by: Dave Airlie <airlied@redhat.com>
> ---
> Documentation/gpu/drm-mm.rst | 6 +
> MAINTAINERS | 8 +-
> drivers/gpu/Kconfig | 13 +
> drivers/gpu/Makefile | 1 +
> drivers/gpu/buddy.c | 556 +++++++++---------
> drivers/gpu/drm/Kconfig | 1 +
> drivers/gpu/drm/Makefile | 2 +-
> drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c | 2 +-
> .../gpu/drm/amd/amdgpu/amdgpu_res_cursor.h | 12 +-
> drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c | 79 +--
> drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.h | 18 +-
> drivers/gpu/drm/drm_buddy.c | 77 +++
> drivers/gpu/drm/i915/i915_scatterlist.c | 8 +-
> drivers/gpu/drm/i915/i915_ttm_buddy_manager.c | 55 +-
> drivers/gpu/drm/i915/i915_ttm_buddy_manager.h | 4 +-
> .../drm/i915/selftests/intel_memory_region.c | 20 +-
> .../gpu/drm/ttm/tests/ttm_bo_validate_test.c | 4 +-
> drivers/gpu/drm/ttm/tests/ttm_mock_manager.c | 18 +-
> drivers/gpu/drm/ttm/tests/ttm_mock_manager.h | 2 +-
> drivers/gpu/drm/xe/xe_res_cursor.h | 34 +-
> drivers/gpu/drm/xe/xe_svm.c | 12 +-
> drivers/gpu/drm/xe/xe_ttm_vram_mgr.c | 71 +--
> drivers/gpu/drm/xe/xe_ttm_vram_mgr_types.h | 2 +-
> drivers/gpu/tests/Makefile | 2 +-
> drivers/gpu/tests/gpu_buddy_test.c | 412 ++++++-------
> drivers/gpu/tests/gpu_random.c | 16 +-
> drivers/gpu/tests/gpu_random.h | 18 +-
> drivers/video/Kconfig | 1 +
> include/drm/drm_buddy.h | 18 +
> include/linux/gpu_buddy.h | 120 ++--
> 30 files changed, 853 insertions(+), 739 deletions(-)
> create mode 100644 drivers/gpu/Kconfig
> create mode 100644 drivers/gpu/drm/drm_buddy.c
> create mode 100644 include/drm/drm_buddy.h
>
> diff --git a/Documentation/gpu/drm-mm.rst b/Documentation/gpu/drm-mm.rst
> index ceee0e663237..32fb506db05b 100644
> --- a/Documentation/gpu/drm-mm.rst
> +++ b/Documentation/gpu/drm-mm.rst
> @@ -532,6 +532,12 @@ Buddy Allocator Function References (GPU buddy)
> .. kernel-doc:: drivers/gpu/buddy.c
> :export:
>
> +DRM Buddy Specific Logging Function References
> +----------------------------------------------
> +
> +.. kernel-doc:: drivers/gpu/drm/drm_buddy.c
> + :export:
> +
> DRM Cache Handling and Fast WC memcpy()
> =======================================
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index dc82a6bd1a61..14b4f9af0e36 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -8905,15 +8905,17 @@ T: git https://gitlab.freedesktop.org/drm/misc/kernel.git
> F: drivers/gpu/drm/ttm/
> F: include/drm/ttm/
>
> -DRM BUDDY ALLOCATOR
> +GPU BUDDY ALLOCATOR
> M: Matthew Auld <matthew.auld@intel.com>
> M: Arun Pravin <arunpravin.paneerselvam@amd.com>
> R: Christian Koenig <christian.koenig@amd.com>
> L: dri-devel@lists.freedesktop.org
> S: Maintained
> T: git https://gitlab.freedesktop.org/drm/misc/kernel.git
> -F: drivers/gpu/drm/drm_buddy.c
> -F: drivers/gpu/drm/tests/drm_buddy_test.c
> +F: drivers/gpu/drm_buddy.c
This line should be `drivers/gpu/drm/drm_buddy.c`.
> +F: drivers/gpu/buddy.c
> +F: drivers/gpu/tests/gpu_buddy_test.c
> +F: include/linux/gpu_buddy.h
These files have been moved in patch 1, so their MAINTAINERS entry
should also be modified there.
^ permalink raw reply
* Re: [PATCH v2] staging: sm750fb: add missing const to g_fbmode array
From: Dan Carpenter @ 2026-02-19 6:55 UTC (permalink / raw)
To: Eyüp Kerem Baş
Cc: Ethan Tidmore, sudipm.mukherjee, teddy.wang, gregkh, linux-fbdev,
linux-staging, linux-kernel
In-Reply-To: <20260216003939.206758-1-baseyupkerem@gmail.com>
On Mon, Feb 16, 2026 at 03:39:39AM +0300, Eyüp Kerem Baş wrote:
> Checkpatch reported a warning that the static const char * array should
> probably be static const char * const. This patch adds the missing const
> keyword to g_fbmode array, moving it to read-only memory.
>
> Signed-off-by: Eyüp Kerem Baş <baseyupkerem@gmail.com>
> ---
This beaks the build.
regards,
dan carpenter
^ permalink raw reply
* Re: [PATCH] staging: fbtft: fb_ra8875: replace udelay with usleep_range
From: Andy Shevchenko @ 2026-02-19 7:30 UTC (permalink / raw)
To: tomasz.unger
Cc: andy, gregkh, dri-devel, linux-fbdev, linux-staging, linux-kernel
In-Reply-To: <20260218174737.86994-1-tomasz.unger@yahoo.pl>
On Wed, Feb 18, 2026 at 06:47:37PM +0100, tomasz.unger@yahoo.pl wrote:
> From: Tomasz Unger <tomasz.unger@yahoo.pl>
We do not accept changes without explanations.
Also where did you get this idea to convert udelay() to usleep_range()?
The API (in case it's okay to use) should be fsleep() nowadays.
(Note as well that we refer to the functions as 'func()' in the text.)
And last, but not least: have you checked carefully that this is even
possible change? This is quite a change in the behaviour and needs very
good justification and testing.
TL;DR: if any tool suggested this change to you, go and fix that tool
to stop spreading misleading ARs!
P.S.
NAK to all your three patches. Also check https://lore.kernel.org ML
archives on the similar changes in the past, they were all NAKed
(rejected).
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH] staging: fbtft: fb_tinylcd: replace udelay with usleep_range
From: Andy Shevchenko @ 2026-02-19 7:30 UTC (permalink / raw)
To: tomasz.unger
Cc: andy, gregkh, dri-devel, linux-fbdev, linux-staging, linux-kernel
In-Reply-To: <20260218175517.87544-1-tomasz.unger@yahoo.pl>
On Wed, Feb 18, 2026 at 06:55:17PM +0100, tomasz.unger@yahoo.pl wrote:
> From: Tomasz Unger <tomasz.unger@yahoo.pl>
NAK.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH] staging: fbtft: fb_upd161704: replace udelay with usleep_range
From: Andy Shevchenko @ 2026-02-19 7:30 UTC (permalink / raw)
To: tomasz.unger
Cc: andy, gregkh, dri-devel, linux-fbdev, linux-staging, linux-kernel
In-Reply-To: <20260218180347.88034-1-tomasz.unger@yahoo.pl>
On Wed, Feb 18, 2026 at 07:03:47PM +0100, tomasz.unger@yahoo.pl wrote:
> From: Tomasz Unger <tomasz.unger@yahoo.pl>
NAK.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH] staging: fbtft: fb_tinylcd: replace udelay() with fsleep()
From: Andy Shevchenko @ 2026-02-19 11:03 UTC (permalink / raw)
To: tomasz.unger
Cc: andy, gregkh, dri-devel, linux-fbdev, linux-staging, linux-kernel
In-Reply-To: <20260219105628.43534-1-tomasz.unger@yahoo.pl>
On Thu, Feb 19, 2026 at 11:56:28AM +0100, tomasz.unger@yahoo.pl wrote:
> fsleep() is the preferred modern API for flexible sleeping as it
> automatically selects the best sleep mechanism based on the duration.
> Replace udelay() with fsleep() to improve power efficiency.
Is this sleeping context?
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH] staging: fbtft: fb_tinylcd: replace udelay() with fsleep()
From: Greg KH @ 2026-02-19 11:16 UTC (permalink / raw)
To: tomasz.unger; +Cc: andy, dri-devel, linux-fbdev, linux-staging, linux-kernel
In-Reply-To: <20260219105628.43534-1-tomasz.unger@yahoo.pl>
On Thu, Feb 19, 2026 at 11:56:28AM +0100, tomasz.unger@yahoo.pl wrote:
> From: Tomasz Unger <tomasz.unger@yahoo.pl>
>
> fsleep() is the preferred modern API for flexible sleeping as it
> automatically selects the best sleep mechanism based on the duration.
> Replace udelay() with fsleep() to improve power efficiency.
>
> Signed-off-by: Tomasz Unger <tomasz.unger@yahoo.pl>
> ---
> drivers/staging/fbtft/fb_tinylcd.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/staging/fbtft/fb_tinylcd.c b/drivers/staging/fbtft/fb_tinylcd.c
> index 9469248f2c50..3fb15df31592 100644
> --- a/drivers/staging/fbtft/fb_tinylcd.c
> +++ b/drivers/staging/fbtft/fb_tinylcd.c
> @@ -41,7 +41,7 @@ static int init_display(struct fbtft_par *par)
> 0x00, 0x35, 0x33, 0x00, 0x00, 0x00);
> write_reg(par, MIPI_DCS_SET_PIXEL_FORMAT, 0x55);
> write_reg(par, MIPI_DCS_EXIT_SLEEP_MODE);
> - udelay(250);
> + fsleep(250);
> write_reg(par, MIPI_DCS_SET_DISPLAY_ON);
>
> return 0;
> --
> 2.53.0
>
Hi,
This is the friendly patch-bot of Greg Kroah-Hartman. You have sent him
a patch that has triggered this response. He used to manually respond
to these common problems, but in order to save his sanity (he kept
writing the same thing over and over, yet to different people), I was
created. Hopefully you will not take offence and will fix the problem
in your patch and resubmit it so that it can be accepted into the Linux
kernel tree.
You are receiving this message because of the following common error(s)
as indicated below:
- This looks like a new version of a previously submitted patch, but you
did not list below the --- line any changes from the previous version.
Please read the section entitled "The canonical patch format" in the
kernel file, Documentation/process/submitting-patches.rst for what
needs to be done here to properly describe this.
- You sent a patch that has been sent multiple times in the past, and is
identical to ones that have been rejected. Please always look at the
mailing list traffic to determine if you are duplicating other
people's work.
If you wish to discuss this problem further, or you have questions about
how to resolve this issue, please feel free to respond to this email and
Greg will reply once he has dug out from the pending patches received
from other developers.
thanks,
greg k-h's patch email bot
^ permalink raw reply
* [PATCH] staging: fbtft: fb_tinylcd: replace udelay() with fsleep()
From: tomasz.unger @ 2026-02-19 10:56 UTC (permalink / raw)
To: andy, gregkh
Cc: dri-devel, linux-fbdev, linux-staging, linux-kernel, Tomasz Unger
In-Reply-To: <20260219105628.43534-1-tomasz.unger.ref@yahoo.pl>
From: Tomasz Unger <tomasz.unger@yahoo.pl>
fsleep() is the preferred modern API for flexible sleeping as it
automatically selects the best sleep mechanism based on the duration.
Replace udelay() with fsleep() to improve power efficiency.
Signed-off-by: Tomasz Unger <tomasz.unger@yahoo.pl>
---
drivers/staging/fbtft/fb_tinylcd.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/fbtft/fb_tinylcd.c b/drivers/staging/fbtft/fb_tinylcd.c
index 9469248f2c50..3fb15df31592 100644
--- a/drivers/staging/fbtft/fb_tinylcd.c
+++ b/drivers/staging/fbtft/fb_tinylcd.c
@@ -41,7 +41,7 @@ static int init_display(struct fbtft_par *par)
0x00, 0x35, 0x33, 0x00, 0x00, 0x00);
write_reg(par, MIPI_DCS_SET_PIXEL_FORMAT, 0x55);
write_reg(par, MIPI_DCS_EXIT_SLEEP_MODE);
- udelay(250);
+ fsleep(250);
write_reg(par, MIPI_DCS_SET_DISPLAY_ON);
return 0;
--
2.53.0
^ permalink raw reply related
* [PATCH v2] staging: fbtft: fb_tinylcd: replace udelay() with fsleep()
From: tomasz.unger @ 2026-02-19 14:29 UTC (permalink / raw)
To: andy, gregkh
Cc: dri-devel, linux-fbdev, linux-staging, linux-kernel, Tomasz Unger
In-Reply-To: <20260219142942.74087-1-tomasz.unger.ref@yahoo.pl>
From: Tomasz Unger <tomasz.unger@yahoo.pl>
fsleep() is the preferred modern API for flexible sleeping as it
automatically selects the best sleep mechanism based on the duration.
Replace udelay() with fsleep() to improve power efficiency.
init_display() is a driver initialization callback which runs in
sleeping context, so fsleep() is safe to use here.
Signed-off-by: Tomasz Unger <tomasz.unger@yahoo.pl>
---
Changes in v2:
- Added sleeping context justification to commit message
- Replaced usleep_range() with fsleep() as suggested by Andy Shevchenko
drivers/staging/fbtft/fb_tinylcd.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/fbtft/fb_tinylcd.c b/drivers/staging/fbtft/fb_tinylcd.c
index 9469248f2c50..3fb15df31592 100644
--- a/drivers/staging/fbtft/fb_tinylcd.c
+++ b/drivers/staging/fbtft/fb_tinylcd.c
@@ -41,7 +41,7 @@ static int init_display(struct fbtft_par *par)
0x00, 0x35, 0x33, 0x00, 0x00, 0x00);
write_reg(par, MIPI_DCS_SET_PIXEL_FORMAT, 0x55);
write_reg(par, MIPI_DCS_EXIT_SLEEP_MODE);
- udelay(250);
+ fsleep(250);
write_reg(par, MIPI_DCS_SET_DISPLAY_ON);
return 0;
--
2.53.0
^ permalink raw reply related
* Re: [PATCH v2] staging: fbtft: fb_tinylcd: replace udelay() with fsleep()
From: Andy Shevchenko @ 2026-02-19 14:55 UTC (permalink / raw)
To: tomasz.unger
Cc: andy, gregkh, dri-devel, linux-fbdev, linux-staging, linux-kernel
In-Reply-To: <20260219142942.74087-1-tomasz.unger@yahoo.pl>
On Thu, Feb 19, 2026 at 03:29:42PM +0100, tomasz.unger@yahoo.pl wrote:
> fsleep() is the preferred modern API for flexible sleeping as it
> automatically selects the best sleep mechanism based on the duration.
> Replace udelay() with fsleep() to improve power efficiency.
>
> init_display() is a driver initialization callback which runs in
> sleeping context, so fsleep() is safe to use here.
OK.
Acked-by: Andy Shevchenko <andriy.shevchenko@intel.com>
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v7 00/23] nova-core: Add memory management support
From: Alexandre Courbot @ 2026-02-19 15:20 UTC (permalink / raw)
To: Joel Fernandes
Cc: linux-kernel, Maarten Lankhorst, Maxime Ripard, Simona Vetter,
Jonathan Corbet, Alex Deucher, Christian König, Jani Nikula,
Joonas Lahtinen, Rodrigo Vivi, Tvrtko Ursulin, Huang Rui,
Matthew Auld, Matthew Brost, Lucas De Marchi,
Thomas Hellström, Helge Deller, Danilo Krummrich, Alice Ryhl,
Miguel Ojeda, Alex Gaynor, Boqun Feng, Gary Guo,
Björn Roy Baron, Benno Lossin, Andreas Hindborg,
Trevor Gross, Alistair Popple, Andrea Righi, Zhi Wang,
Philipp Stanner, Elle Rhumsaa, Daniel Almeida, Eliot Courtney,
joel, nouveau, dri-devel, rust-for-linux, linux-doc, amd-gfx,
intel-gfx, intel-xe, linux-fbdev
In-Reply-To: <20260218212020.800836-1-joelagnelf@nvidia.com>
Hi Joel,
On Thu Feb 19, 2026 at 6:19 AM JST, Joel Fernandes wrote:
> This series adds support for nova-core memory management, including VRAM
> allocation, PRAMIN, VMM, page table walking, and BAR 1 read/writes.
> These are critical for channel management, vGPU, and all memory
> management uses.
>
> These patches depend on the following preparatory patches:
> https://lore.kernel.org/all/20260218205507.689429-1-joelagnelf@nvidia.com/T/#t
>
> All patches (including the preparatory patches from the other series) can
> be found at:
> git://git.kernel.org/pub/scm/linux/kernel/git/jfern/linux.git (branch nova/mm or tag: nova-mm-v7-20260218)
>
> Earlier series of these patches:
> https://lore.kernel.org/linux-fbdev/DG0MRL6T7ACW.25G3GLJMP7PN1@kernel.org/T/#t
> https://lore.kernel.org/linux-fbdev/20260210233204.790524-1-joelagnelf@nvidia.com/
>
> Joel Fernandes (23):
> nova-core: mm: Add support to use PRAMIN windows to write to VRAM
> docs: gpu: nova-core: Document the PRAMIN aperture mechanism
> nova-core: Add BAR1 aperture type and size constant
> nova-core: gsp: Add BAR1 PDE base accessors
> nova-core: mm: Add common memory management types
> nova-core: mm: Add common types for all page table formats
> nova-core: mm: Add MMU v2 page table types
> nova-core: mm: Add MMU v3 page table types
> nova-core: mm: Add unified page table entry wrapper enums
> nova-core: mm: Add TLB flush support
> nova-core: mm: Add GpuMm centralized memory manager
> nova-core: mm: Add page table walker for MMU v2/v3
> nova-core: mm: Add Virtual Memory Manager
> nova-core: mm: Add virtual address range tracking to VMM
> nova-core: mm: Add multi-page mapping API to VMM
> nova-core: mm: Add BAR1 user interface
> nova-core: gsp: Return GspStaticInfo and FbLayout from boot()
> nova-core: mm: Add BAR1 memory management self-tests
> nova-core: mm: Add PRAMIN aperture self-tests
> nova-core: gsp: Extract usable FB region from GSP
> nova-core: fb: Add usable_vram field to FbLayout
> nova-core: mm: Use usable VRAM region for buddy allocator
> nova-core: mm: Add BarUser to struct Gpu and create at boot
Nice series, a few overall remarks before I dive deeper into each patch:
- Use `gpu: nova-core:` (not just `nova-core:`) as the patch prefix.
- There were a few clippy warnings/rustfmt diffs when I built it.
- There are build failures introduced in patches 11 and 18 - basically
the series doesn't build from 11 until the last patch.
- This patchset is using the `module/mod.rs` pattern instead of
`module.rs` for new modules. The latter is the preferred norm IIUC.
The end result of the series looks coherent, but the ordering of patches
makes it more tedious to review than it needs to be. We start with
PRAMIN, then add some BAR1 types that are not used until 10+ patches
later, switch to getting the framebuffer size from the GSP, add tests,
go back to GSP, etc. It is difficult to follow all these intertwined
topics (even though they eventually converge) and to know which of the
previous patches are relevant to the current one.
But there is a clear path, and after moving patches around (with only
very trivial conflicts) I got the following ordering which is more
logical IMHO:
Phase 1: GSP plumbing
- nova-core: gsp: Return GspStaticInfo and FbLayout from boot()
- nova-core: gsp: Extract usable FB region from GSP
- nova-core: fb: Add usable_vram field to FbLayout
These constitute a logical change by themselves, by getting more
information from the GSP to know how much VRAM we have. You could even
display the result as a dev_info of dev_dbg to remove the only remaining
`dead_code`.
Phase 2: PRAMIN support
- nova-core: mm: Add support to use PRAMIN windows to write to VRAM
- docs: gpu: nova-core: Document the PRAMIN aperture mechanism
PRAMIN is needed by everything that follows.
Phase 3: GpuMm
- nova-core: mm: Add common memory management types
- nova-core: mm: Add TLB flush support
- nova-core: mm: Add GpuMm centralized memory manager
- nova-core: mm: Use usable VRAM region for buddy allocator
The common memory management types patch and TLB give us all we need to
introduce GpuMm, which makes it more accessible that after going through
all the page table types which it doesn't depend on. This culminates
with using the result of phase 1, which also allows you to get rid of
the temporary 1MB window hack if you rearrange the code a bit.
Phase 4: page tables / VMM
- nova-core: mm: Add common types for all page table formats
- nova-core: mm: Add MMU v2 page table types
- nova-core: mm: Add MMU v3 page table types
- nova-core: mm: Add unified page table entry wrapper enums
- nova-core: mm: Add page table walker for MMU v2/v3
- nova-core: mm: Add Virtual Memory Manager
- nova-core: mm: Add virtual address range tracking to VMM
- nova-core: mm: Add multi-page mapping API to VMM
The main course, required for BAR1 - these follow the original order.
Phase 5: BAR1
- nova-core: Add BAR1 aperture type and size constant
- nova-core: gsp: Add BAR1 PDE base accessors
- nova-core: mm: Add BAR1 user interface
- nova-core: mm: Add BarUser to struct Gpu and create at boot
All the BAR1 stuff now happens in one place. There is certainly room for
merging a few patches to avoid introducing dead code and eliminating
just after.
Phase 6: tests
- nova-core: mm: Add PRAMIN aperture self-tests
- nova-core: mm: Add BAR1 memory management self-tests
I have done this reordering locally and it seems to build fine.
I'll do a patch-by-patch review following this order, but I wanted to
share it first for other reviewers of this revision as it makes the
series more accessible IMHO.
^ permalink raw reply
* Re: [PATCH v7 00/23] nova-core: Add memory management support
From: Joel Fernandes @ 2026-02-19 19:48 UTC (permalink / raw)
To: Alexandre Courbot
Cc: linux-kernel, Maarten Lankhorst, Maxime Ripard, Simona Vetter,
Jonathan Corbet, Alex Deucher, Christian König, Jani Nikula,
Joonas Lahtinen, Rodrigo Vivi, Tvrtko Ursulin, Huang Rui,
Matthew Auld, Matthew Brost, Lucas De Marchi,
Thomas Hellström, Helge Deller, Danilo Krummrich, Alice Ryhl,
Miguel Ojeda, Alex Gaynor, Boqun Feng, Gary Guo,
Björn Roy Baron, Benno Lossin, Andreas Hindborg,
Trevor Gross, Alistair Popple, Andrea Righi, Zhi Wang,
Philipp Stanner, Elle Rhumsaa, Daniel Almeida, Eliot Courtney,
joel, nouveau, dri-devel, rust-for-linux, linux-doc, amd-gfx,
intel-gfx, intel-xe, linux-fbdev
In-Reply-To: <DGJ1G3D32OMK.30HANB1W46XVL@nvidia.com>
Hi Alex,
Thanks for taking the time to go through the series and for the effort
of doing the reordering. Just to clarify, do you mean I should be
sending each of the phases separately for review instead of in one
series?
By any chance, do you have the tree after doing the rearrangement that I
could take a look at? That would be very helpful so I don't repeat your
rearrangement effort.
Some comments below:
> Nice series, a few overall remarks before I dive deeper into each patch:
>
> - Use `gpu: nova-core:` (not just `nova-core:`) as the patch prefix.
Done.
> - There were a few clippy warnings/rustfmt diffs when I built it.
> - There are build failures introduced in patches 11 and 18 - basically
> the series doesn't build from 11 until the last patch.
> - This patchset is using the `module/mod.rs` pattern instead of
> `module.rs` for new modules. The latter is the preferred norm IIUC.
I will work on fixing these based on the reordered patches for the next
spin.
> Phase 1: GSP plumbing
> - nova-core: gsp: Return GspStaticInfo and FbLayout from boot()
> - nova-core: gsp: Extract usable FB region from GSP
> - nova-core: fb: Add usable_vram field to FbLayout
>
> These constitute a logical change by themselves, by getting more
> information from the GSP to know how much VRAM we have. You could even
> display the result as a dev_info of dev_dbg to remove the only remaining
> `dead_code`.
This looks good to me.
> Phase 2: PRAMIN support
> - nova-core: mm: Add support to use PRAMIN windows to write to VRAM
> - docs: gpu: nova-core: Document the PRAMIN aperture mechanism
>
> PRAMIN is needed by everything that follows.
This looks good to me.
> Phase 3: GpuMm
> - nova-core: mm: Add common memory management types
> - nova-core: mm: Add TLB flush support
> - nova-core: mm: Add GpuMm centralized memory manager
> - nova-core: mm: Use usable VRAM region for buddy allocator
>
> The common memory management types patch and TLB give us all we need to
> introduce GpuMm, which makes it more accessible that after going through
> all the page table types which it doesn't depend on. This culminates
> with using the result of phase 1, which also allows you to get rid of
> the temporary 1MB window hack if you rearrange the code a bit.
Yeah, that is a nice advantage!
> Phase 4: page tables / VMM
> - nova-core: mm: Add common types for all page table formats
> - nova-core: mm: Add MMU v2 page table types
> - nova-core: mm: Add MMU v3 page table types
> - nova-core: mm: Add unified page table entry wrapper enums
> - nova-core: mm: Add page table walker for MMU v2/v3
> - nova-core: mm: Add Virtual Memory Manager
> - nova-core: mm: Add virtual address range tracking to VMM
> - nova-core: mm: Add multi-page mapping API to VMM
>
> The main course, required for BAR1 - these follow the original order.
Sounds good.
> Phase 5: BAR1
> - nova-core: Add BAR1 aperture type and size constant
> - nova-core: gsp: Add BAR1 PDE base accessors
> - nova-core: mm: Add BAR1 user interface
> - nova-core: mm: Add BarUser to struct Gpu and create at boot
These sound good to me.
> All the BAR1 stuff now happens in one place. There is certainly room for
> merging a few patches to avoid introducing dead code and eliminating
> just after.
Yeah, I tried to keep the commits at a reasonable size to make review
easier. I will look into merging a little more to see where it is possible.
> Phase 6: tests
> - nova-core: mm: Add PRAMIN aperture self-tests
> - nova-core: mm: Add BAR1 memory management self-tests
This sounds good to me.
> I have done this reordering locally and it seems to build fine.
Please share your reorder tree if you still have it. That would likely save
me a lot of effort. Thanks.
> I'll do a patch-by-patch review following this order, but I wanted to
> share it first for other reviewers of this revision as it makes the
> series more accessible IMHO.
Looking forward to it. Thanks!
--
Joel Fernandes
^ permalink raw reply
* [PATCH v2] gpu: ipu-v3: clean up kernel-doc warnings
From: Randy Dunlap @ 2026-02-19 21:52 UTC (permalink / raw)
To: dri-devel
Cc: Randy Dunlap, Philipp Zabel, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, imx,
linux-arm-kernel, Helge Deller, linux-fbdev
Correct all kernel-doc warnings:
- fix a typedef kernel-doc comment
- mark a list_head as private
- use Returns: for function return values
Warning: include/video/imx-ipu-image-convert.h:31 struct member 'list' not
described in 'ipu_image_convert_run'
Warning: include/video/imx-ipu-image-convert.h:40 function parameter
'ipu_image_convert_cb_t' not described in 'void'
Warning: include/video/imx-ipu-image-convert.h:40 expecting prototype for
ipu_image_convert_cb_t(). Prototype was for void() instead
Warning: include/video/imx-ipu-image-convert.h:66 No description found for
return value of 'ipu_image_convert_verify'
Warning: include/video/imx-ipu-image-convert.h:90 No description found for
return value of 'ipu_image_convert_prepare'
Warning: include/video/imx-ipu-image-convert.h:125 No description found for
return value of 'ipu_image_convert_queue'
Warning: include/video/imx-ipu-image-convert.h:163 No description found for
return value of 'ipu_image_convert'
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de>
---
v2: add Reviewed-by, update Cc: list, rebase, resend
Cc: Philipp Zabel <p.zabel@pengutronix.de>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Maxime Ripard <mripard@kernel.org>
Cc: Thomas Zimmermann <tzimmermann@suse.de>
Cc: David Airlie <airlied@gmail.com>
Cc: Simona Vetter <simona@ffwll.ch>
Cc: imx@lists.linux.dev
Cc: linux-arm-kernel@lists.infradead.org
Cc: Helge Deller <deller@gmx.de>
Cc: linux-fbdev@vger.kernel.org
include/video/imx-ipu-image-convert.h | 16 +++++++++++-----
1 file changed, 11 insertions(+), 5 deletions(-)
--- linux-next-20260218.orig/include/video/imx-ipu-image-convert.h
+++ linux-next-20260218/include/video/imx-ipu-image-convert.h
@@ -27,12 +27,13 @@ struct ipu_image_convert_run {
int status;
+ /* private: */
/* internal to image converter, callers don't touch */
struct list_head list;
};
/**
- * ipu_image_convert_cb_t - conversion callback function prototype
+ * typedef ipu_image_convert_cb_t - conversion callback function prototype
*
* @run: the completed conversion run pointer
* @ctx: a private context pointer for the callback
@@ -60,7 +61,7 @@ void ipu_image_convert_adjust(struct ipu
* @out: output image format
* @rot_mode: rotation mode
*
- * Returns 0 if the formats and rotation mode meet IPU restrictions,
+ * Returns: 0 if the formats and rotation mode meet IPU restrictions,
* -EINVAL otherwise.
*/
int ipu_image_convert_verify(struct ipu_image *in, struct ipu_image *out,
@@ -77,11 +78,11 @@ int ipu_image_convert_verify(struct ipu_
* @complete: run completion callback
* @complete_context: a context pointer for the completion callback
*
- * Returns an opaque conversion context pointer on success, error pointer
+ * In V4L2, drivers should call ipu_image_convert_prepare() at streamon.
+ *
+ * Returns: an opaque conversion context pointer on success, error pointer
* on failure. The input/output formats and rotation mode must already meet
* IPU retrictions.
- *
- * In V4L2, drivers should call ipu_image_convert_prepare() at streamon.
*/
struct ipu_image_convert_ctx *
ipu_image_convert_prepare(struct ipu_soc *ipu, enum ipu_ic_task ic_task,
@@ -122,6 +123,8 @@ void ipu_image_convert_unprepare(struct
* In V4L2, drivers should call ipu_image_convert_queue() while
* streaming to queue the conversion of a received input buffer.
* For example mem2mem devices this would be called in .device_run.
+ *
+ * Returns: 0 on success or -errno on error.
*/
int ipu_image_convert_queue(struct ipu_image_convert_run *run);
@@ -155,6 +158,9 @@ void ipu_image_convert_abort(struct ipu_
* On successful return the caller can queue more run requests if needed, using
* the prepared context in run->ctx. The caller is responsible for unpreparing
* the context when no more conversion requests are needed.
+ *
+ * Returns: pointer to the created &struct ipu_image_convert_run that has
+ * been queued on success; an ERR_PTR(errno) on error.
*/
struct ipu_image_convert_run *
ipu_image_convert(struct ipu_soc *ipu, enum ipu_ic_task ic_task,
^ permalink raw reply
* Re: [PATCH v7 00/23] nova-core: Add memory management support
From: Alexandre Courbot @ 2026-02-20 1:54 UTC (permalink / raw)
To: Joel Fernandes
Cc: linux-kernel, Maarten Lankhorst, Maxime Ripard, Simona Vetter,
Jonathan Corbet, Alex Deucher, Christian König, Jani Nikula,
Joonas Lahtinen, Rodrigo Vivi, Tvrtko Ursulin, Huang Rui,
Matthew Auld, Matthew Brost, Lucas De Marchi,
Thomas Hellström, Helge Deller, Danilo Krummrich, Alice Ryhl,
Miguel Ojeda, Alex Gaynor, Boqun Feng, Gary Guo,
Björn Roy Baron, Benno Lossin, Andreas Hindborg,
Trevor Gross, Alistair Popple, Andrea Righi, Zhi Wang,
Philipp Stanner, Elle Rhumsaa, Daniel Almeida, Eliot Courtney,
joel, nouveau, dri-devel, rust-for-linux, linux-doc, amd-gfx,
intel-gfx, intel-xe, linux-fbdev
In-Reply-To: <20260219194838.GA1013545@joelbox2>
On Fri Feb 20, 2026 at 4:48 AM JST, Joel Fernandes wrote:
> Hi Alex,
>
> Thanks for taking the time to go through the series and for the effort
> of doing the reordering. Just to clarify, do you mean I should be
> sending each of the phases separately for review instead of in one
> series?
>
> By any chance, do you have the tree after doing the rearrangement that I
> could take a look at? That would be very helpful so I don't repeat your
> rearrangement effort.
Sure: https://github.com/Gnurou/linux/tree/review/nova-mm-v10
I have rebased it on top of your `nova-mm-v7-20260218` tag, hopefully
that makes it easier to pick.
The top-of-trees of both my branch and your tag are identical, and I've
tried to limit the changes in each patch, but you will want to quickly
check them. I have fixed the transient build errors, but not the
formatting or clippy warnings to make sure my top-of-tree stayed
identical to yours and I haven't introduced any regression.
^ permalink raw reply
* Re: [PATCH v7 00/23] nova-core: Add memory management support
From: Alexandre Courbot @ 2026-02-20 3:25 UTC (permalink / raw)
To: Joel Fernandes
Cc: linux-kernel, Maarten Lankhorst, Maxime Ripard, Simona Vetter,
Jonathan Corbet, Alex Deucher, Christian König, Jani Nikula,
Joonas Lahtinen, Rodrigo Vivi, Tvrtko Ursulin, Huang Rui,
Matthew Auld, Matthew Brost, Lucas De Marchi,
Thomas Hellström, Helge Deller, Danilo Krummrich, Alice Ryhl,
Miguel Ojeda, Alex Gaynor, Boqun Feng, Gary Guo,
Björn Roy Baron, Benno Lossin, Andreas Hindborg,
Trevor Gross, Alistair Popple, Andrea Righi, Zhi Wang,
Philipp Stanner, Elle Rhumsaa, Daniel Almeida, Eliot Courtney,
joel, nouveau, dri-devel, rust-for-linux, linux-doc, amd-gfx,
intel-gfx, intel-xe, linux-fbdev
In-Reply-To: <20260219194838.GA1013545@joelbox2>
On Fri Feb 20, 2026 at 4:48 AM JST, Joel Fernandes wrote:
> Hi Alex,
>
> Thanks for taking the time to go through the series and for the effort
> of doing the reordering. Just to clarify, do you mean I should be
> sending each of the phases separately for review instead of in one
> series?
Sorry, forgot to reply to this. I think one series is fine now that
CList/buddy have been moved out, as it only spans one component
(nova-core) and forces us to keep the big picture in mind. The
reordering is just to enable a more granular review process and identify
the moving pieces more clearly.
^ permalink raw reply
* Re: [PATCH v3 0/9] arch,sysfb,efi: Support EDID on non-x86 EFI systems
From: patchwork-bot+linux-riscv @ 2026-02-20 4:10 UTC (permalink / raw)
To: Thomas Zimmermann
Cc: linux-riscv, ardb, javierm, arnd, richard.lyu, helgaas, x86,
linux-arm-kernel, linux-kernel, linux-efi, loongarch, dri-devel,
linux-hyperv, linux-pci, linux-fbdev
In-Reply-To: <20251126160854.553077-1-tzimmermann@suse.de>
Hello:
This series was applied to riscv/linux.git (fixes)
by Ard Biesheuvel <ardb@kernel.org>:
On Wed, 26 Nov 2025 17:03:17 +0100 you wrote:
> Replace screen_info and edid_info with sysfb_primary_device of type
> struct sysfb_display_info. Update all users. Then implement EDID support
> in the kernel EFI code.
>
> Sysfb DRM drivers currently fetch the global edid_info directly, when
> they should get that information together with the screen_info from their
> device. Wrapping screen_info and edid_info in sysfb_primary_display and
> passing this to drivers enables this.
>
> [...]
Here is the summary with links:
- [v3,1/9] efi: earlycon: Reduce number of references to global screen_info
https://git.kernel.org/riscv/c/b868070fbc02
- [v3,2/9] efi: sysfb_efi: Reduce number of references to global screen_info
(no matching commit)
- [v3,3/9] sysfb: Add struct sysfb_display_info
https://git.kernel.org/riscv/c/b945922619b7
- [v3,4/9] sysfb: Replace screen_info with sysfb_primary_display
(no matching commit)
- [v3,5/9] sysfb: Pass sysfb_primary_display to devices
https://git.kernel.org/riscv/c/08e583ad6857
- [v3,6/9] sysfb: Move edid_info into sysfb_primary_display
https://git.kernel.org/riscv/c/4fcae6358871
- [v3,7/9] efi: Refactor init_primary_display() helpers
(no matching commit)
- [v3,8/9] efi: Support EDID information
(no matching commit)
- [v3,9/9] efi: libstub: Simplify interfaces for primary_display
(no matching commit)
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* [GIT PULL] au1100fb fbdev updates for v7.0-rc1
From: Helge Deller @ 2026-02-20 7:49 UTC (permalink / raw)
To: Linus Torvalds, linux-kernel, linux-fbdev, dri-devel
Cc: Uwe Kleine-König
Hi Linus,
please pull a series of patches with code cleanups for the au1100fb driver.
Thanks!
Helge
----------------------------------------------------------------
The following changes since commit 26a4cfaff82a2dcb810f6bfd5f4842f9b6046c8a:
Merge tag 'docs-7.0-2' of git://git.kernel.org/pub/scm/linux/kernel/git/docs/linux (2026-02-15 10:47:59 -0800)
are available in the Git repository at:
http://git.kernel.org/pub/scm/linux/kernel/git/deller/linux-fbdev.git tags/fbdev-for-7.0-rc1-2
for you to fetch changes up to 0f967cb8ea04486953f85b249b42dda3de842053:
fbdev: au1100fb: Replace license boilerplate by SPDX header (2026-02-19 17:38:17 +0100)
----------------------------------------------------------------
fbdev enhancements for 7.0-rc1:
A series with code cleanups for the au1100fb fbdev driver [Uwe Kleine-König].
----------------------------------------------------------------
Uwe Kleine-König (7):
fbdev: au1100fb: Don't store device specific data in global variables
fbdev: au1100fb: Mark several local functions as static
fbdev: au1100fb: Use proper conversion specifiers in printk formats
fbdev: au1100fb: Make driver compilable on non-mips platforms
fbdev: au1100fb: Replace custom printk wrappers by pr_*
fbdev: au1100fb: Fold au1100fb.h into its only user
fbdev: au1100fb: Replace license boilerplate by SPDX header
drivers/video/fbdev/Kconfig | 3 +-
drivers/video/fbdev/au1100fb.c | 487 ++++++++++++++++++++++++++++++++++-------
drivers/video/fbdev/au1100fb.h | 379 --------------------------------
3 files changed, 406 insertions(+), 463 deletions(-)
delete mode 100644 drivers/video/fbdev/au1100fb.h
^ permalink raw reply
* Re: [GIT PULL] au1100fb fbdev updates for v7.0-rc1
From: pr-tracker-bot @ 2026-02-21 1:20 UTC (permalink / raw)
To: Helge Deller
Cc: Linus Torvalds, linux-kernel, linux-fbdev, dri-devel,
Uwe Kleine-König
In-Reply-To: <aZgSDyT2VcYM4R_Z@carbonx1>
The pull request you sent on Fri, 20 Feb 2026 08:49:35 +0100:
> http://git.kernel.org/pub/scm/linux/kernel/git/deller/linux-fbdev.git tags/fbdev-for-7.0-rc1-2
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/eee3666c92406fd8e5e3084b0b3129528dfe9557
Thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html
^ permalink raw reply
* Re: [PATCH 0/4] fbdev: defio: Protect against device/module removal
From: Thomas Zimmermann @ 2026-02-23 12:50 UTC (permalink / raw)
To: deller, simona, jayalk; +Cc: linux-fbdev, dri-devel
In-Reply-To: <20260122131213.992810-1-tzimmermann@suse.de>
ping for review
Am 22.01.26 um 14:08 schrieb Thomas Zimmermann:
> There's a long-standing bug in defio where the framebuffer device or
> module gets removed while mmap'ed areas of the framebuffer memory
> persists in userspace. Page faults in the area then operate on defined
> state.
>
> Patches 1 and 2 fix these problems. Patches 3 and 4 build upon the fix
> and put defio state into the correct places.
>
> Thomas Zimmermann (4):
> fbdev: defio: Disconnect deferred I/O from the lifetime of struct
> fb_info
> fbdev: defio: Keep module reference from VMAs
> fbdev: defio: Move variable state into struct fb_deferred_io_state
> fbdev: defio: Move pageref array to struct fb_deferred_io_state
>
> drivers/video/fbdev/core/fb_defio.c | 266 ++++++++++++++++++++--------
> include/linux/fb.h | 9 +-
> 2 files changed, 195 insertions(+), 80 deletions(-)
>
>
> base-commit: a3ecd278f9a05323fab7471760a7ea10081251d6
--
--
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)
^ permalink raw reply
* Re: [PATCH v4 1/2] staging: sm750fb: Fix CamelCase variable names
From: Greg KH @ 2026-02-23 14:12 UTC (permalink / raw)
To: Shreyas Ravi
Cc: sudipm.mukherjee, teddy.wang, linux-fbdev, linux-staging,
linux-kernel
In-Reply-To: <20260208184344.657617-1-shreyasravi320@gmail.com>
On Sun, Feb 08, 2026 at 10:43:43AM -0800, Shreyas Ravi wrote:
> Rename CamelCase variable names to snake_case to comply
> with kernel coding style.
You are changing different structures at the same time. Do it one
structure at a time please.
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH v4 2/2] staging: sm750fb: remove Hungarian notation prefixes
From: Greg KH @ 2026-02-23 14:13 UTC (permalink / raw)
To: Shreyas Ravi
Cc: sudipm.mukherjee, teddy.wang, linux-fbdev, linux-staging,
linux-kernel
In-Reply-To: <20260208184344.657617-2-shreyasravi320@gmail.com>
On Sun, Feb 08, 2026 at 10:43:44AM -0800, Shreyas Ravi wrote:
> Remove Hungarian notation prefixes from variable names to comply
> with kernel coding style.
>
> No functional changes.
>
> Signed-off-by: Shreyas Ravi <shreyasravi320@gmail.com>
> ---
> Changes in v4:
> - Fix merge conflicts (forgot to do in v3)
>
> Changes in v3:
> - Added changelog (was missing in v2)
>
> Changes in v2:
> - Split original patch into two patches per Greg's feedback
> - This patch addresses Hungarian prefix removal
> ---
> drivers/staging/sm750fb/sm750.c | 22 ++++++------
> drivers/staging/sm750fb/sm750.h | 6 ++--
> drivers/staging/sm750fb/sm750_accel.c | 48 +++++++++++++--------------
> drivers/staging/sm750fb/sm750_accel.h | 2 +-
> drivers/staging/sm750fb/sm750_hw.c | 20 +++++------
> 5 files changed, 49 insertions(+), 49 deletions(-)
>
> diff --git a/drivers/staging/sm750fb/sm750.c b/drivers/staging/sm750fb/sm750.c
> index 1ed7ff57c142..afcfc9e6c207 100644
> --- a/drivers/staging/sm750fb/sm750.c
> +++ b/drivers/staging/sm750fb/sm750.c
> @@ -624,27 +624,27 @@ static int sm750fb_set_drv(struct lynxfb_par *par)
> output->paths = sm750_pnc;
> crtc->channel = sm750_primary;
> crtc->o_screen = 0;
> - crtc->v_screen = sm750_dev->p_v_mem;
> + crtc->v_screen = sm750_dev->v_mem;
You are fixing up your patch 1 of this series, why not just do it
properly the first time?
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH v4 0/3] staging: sm750fb: clean up logging
From: Greg Kroah-Hartman @ 2026-02-23 14:36 UTC (permalink / raw)
To: Artem Lytkin
Cc: Sudip Mukherjee, Teddy Wang, linux-fbdev, linux-staging,
linux-kernel
In-Reply-To: <20260207153703.2049-1-iprintercanon@gmail.com>
On Sat, Feb 07, 2026 at 03:37:00PM +0000, Artem Lytkin wrote:
> This series cleans up the logging in the sm750fb driver.
>
> Changes since v3:
> - Dropped the strcat and strncmp patches as requested by Greg KH
> - Consistently removed all pr_info/pr_debug/pr_warn diagnostic prints
> in one patch (previously some fb_find_mode prints were kept)
> - Split dev_err conversions into two patches: one for sm750.c
> and one for sm750_hw.c
>
> Patch 1 removes all pr_info/pr_debug/pr_warn diagnostic prints
> from both sm750.c and sm750_hw.c. These include address dumps,
> debug variable prints, fb_find_mode result logging, and CH7301
> DVI chip status messages.
>
> Patches 2-3 convert the remaining pr_err() calls to dev_err()
> for proper device context.
>
> Artem Lytkin (3):
> staging: sm750fb: remove debug and diagnostic prints
> staging: sm750fb: convert logging to device-based in sm750.c
> staging: sm750fb: convert logging to device-based in sm750_hw.c
>
> drivers/staging/sm750fb/sm750.c | 88 +++---------------------------
> drivers/staging/sm750fb/sm750_hw.c | 26 ++-------
> 2 files changed, 14 insertions(+), 100 deletions(-)
>
> --
> 2.43.0
>
>
Does not apply to 7.0-rc1 :(
^ permalink raw reply
* Re: [PATCH 13/13] lib/fonts: Remove internal symbols and macros from public header file
From: Helge Deller @ 2026-02-23 15:05 UTC (permalink / raw)
To: Thomas Zimmermann, gregkh, sam; +Cc: linux-fbdev, dri-devel, linux-kernel
In-Reply-To: <20260218083855.10743-14-tzimmermann@suse.de>
On 2/18/26 09:16, Thomas Zimmermann wrote:
> diff --git a/include/linux/font.h b/include/linux/font.h
> index 4ff956a1cd0a..6e9a4c93b47b 100644
> --- a/include/linux/font.h
> +++ b/include/linux/font.h
> @@ -92,20 +92,12 @@ struct font_desc {
> #define FONT6x8_IDX 12
> #define TER10x18_IDX 13
>
> -extern const struct font_desc font_vga_8x8,
> - font_vga_8x16,
> - font_pearl_8x8,
> - font_vga_6x11,
> - font_7x14,
> - font_10x18,
> - font_sun_8x16,
> - font_sun_12x22,
> - font_acorn_8x8,
> - font_mini_4x6,
> - font_6x10,
> - font_ter_16x32,
> - font_6x8,
> - font_ter_10x18;
> +#if defined(CONFIG_FONT_8x8)
> +extern const struct font_desc font_vga_8x8;
> +#endif
> +#if defined(CONFIG_FONT_8x16)
> +extern const struct font_desc font_vga_8x16;
> +#endif
I suggest not to use all those #ifdef(CONFIG_XXX) in the header files.
They are not necessary, and trigger a rebuild of a whole lot C-files
in case one single CONFIG option is changed.
Instead use it in the C-files only.
That way (re-)compilation is faster and you still get a link/build error
when a symbol is used although the config option is not set.
> diff --git a/lib/fonts/font.h b/lib/fonts/font.h
> new file mode 100644
> index 000000000000..00f65a3da5c2
> --- /dev/null
> +++ b/lib/fonts/font.h
> @@ -0,0 +1,52 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +
> +#ifndef _LIB_FONTS_FONT_H
> +#define _LIB_FONTS_FONT_H
> +
> +#include <linux/font.h>
> +
> +#if defined(CONFIG_FONT_PEARL_8x8)
> +extern const struct font_desc font_pearl_8x8;
> +#endif
> +#if defined(CONFIG_FONT_6x11)
> +extern const struct font_desc font_vga_6x11;
> +#endif
...
same here...
Helge
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox