* Re: [PATCH RFC v6 05/26] nova-core: mm: Add support to use PRAMIN windows to write to VRAM
From: Joel Fernandes @ 2026-01-30 21:14 UTC (permalink / raw)
To: John Hubbard
Cc: Danilo Krummrich, Zhi Wang, linux-kernel, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, David Airlie, Simona Vetter,
Jonathan Corbet, Alex Deucher, Christian Koenig, Jani Nikula,
Joonas Lahtinen, Rodrigo Vivi, Tvrtko Ursulin, Rui Huang,
Matthew Auld, Matthew Brost, Lucas De Marchi, Thomas Hellstrom,
Helge Deller, Alice Ryhl, Miguel Ojeda, Alex Gaynor, Boqun Feng,
Gary Guo, Bjorn Roy Baron, Benno Lossin, Andreas Hindborg,
Trevor Gross, Alistair Popple, Timur Tabi, Edwin Peer,
Alexandre Courbot, Andrea Righi, Andy Ritger, Alexey Ivanov,
Balbir Singh, 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: <c064fbdc-9202-437d-80ff-6134d2a33778@nvidia.com>
On 1/29/2026 10:38 PM, John Hubbard wrote:
> On 1/29/26 5:59 PM, Joel Fernandes wrote:
>> On 1/29/26 8:12 PM, John Hubbard wrote:
>>> On 1/29/26 4:26 PM, Joel Fernandes wrote:
>>>> Based on the below discussion and research, I came up with some deadlock
>>>> scenarios that we need to handle in the v6 series of these patches.
>>>> [...]
>>>> memory allocations under locks that we need in the dma-fence signaling
>>>> critical path (when doing the virtual memory map/unmap)
>>>
>>> unmap? Are you seeing any allocations happening during unmap? I don't
>>> immediately see any, but that sounds surprising.
>>
>> Not allocations but we are acquiring locks during unmap. My understanding
>> is (at least some) unmaps have to also be done in the dma fence signaling
>> critical path (the run stage), but Danilo/you can correct me if I am wrong
>> on that. We cannot avoid all locking but those same locks cannot be held in
>> any other paths which do a memory allocation (as mentioned in one of the
>> deadlock scenarios), that is probably the main thing to check for unmap.
>>
>
> Right, OK we are on the same page now: no allocations happening on unmap,
> but it can still deadlock, because the driver is typically going to
> use a single lock to protect calls both map and unmap-related calls
> to the buddy allocator.
Yes exactly!
>
> For the deadlock above, I think a good way to break that deadlock is
> to not allow taking that lock in a fence signaling calling path.
>
> So during an unmap, instead of "lock, unmap/free, unlock" it should
> move the item to a deferred-free list, which is processed separately.
> Of course, this is a little complex, because the allocation and reclaim
> has to be aware of such lists if they get large.
Yes, also avoiding GFP_KERNEL allocations while holding any of these mm locks
(whichever we take during map). The GPU buddy actually does GFP_KERNEL
allocations internally which is problematic.
Some solutions / next steps:
1. allocating (VRAM and system memory) outside mm locks just before acquiring them.
2. pre-allocating both VRAM and system memory needed, before the DMA fence
critical paths (The issue is also to figure out how much memory to pre-allocate
for the page table pages based on the VM_BIND request. I think we can analyze
the page tables in the submit stage to make an estimate).
3. Unfortunately, I am using gpu-buddy when allocating a VA range in the Vmm
(called virt_buddy), which itself does GFP_KERNEL memory allocations in the
allocate path. I am not sure what do yet about this. ISTR the maple tree also
has similar issues.
4. Using non-reclaimable memory allocations where pre-allocation or
pre-allocated memory pools is not possible (I'd like to avoid this #4 so we
don't fail allocations when memory is scarce).
Will work on these issues for the v7. Thanks,
--
Joel Fernandes
^ permalink raw reply
* Re: [PATCH RFC v6 05/26] nova-core: mm: Add support to use PRAMIN windows to write to VRAM
From: Dave Airlie @ 2026-01-31 3:00 UTC (permalink / raw)
To: Joel Fernandes
Cc: John Hubbard, Danilo Krummrich, Zhi Wang, linux-kernel,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
Simona Vetter, Jonathan Corbet, Alex Deucher, Christian Koenig,
Jani Nikula, Joonas Lahtinen, Rodrigo Vivi, Tvrtko Ursulin,
Rui Huang, Matthew Auld, Matthew Brost, Lucas De Marchi,
Thomas Hellstrom, Helge Deller, Alice Ryhl, Miguel Ojeda,
Alex Gaynor, Boqun Feng, Gary Guo, Bjorn Roy Baron, Benno Lossin,
Andreas Hindborg, Trevor Gross, Alistair Popple, Timur Tabi,
Edwin Peer, Alexandre Courbot, Andrea Righi, Andy Ritger,
Alexey Ivanov, Balbir Singh, 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: <70d88203-2fe1-4bde-b254-51e8107744eb@nvidia.com>
On Sat, 31 Jan 2026 at 07:14, Joel Fernandes <joelagnelf@nvidia.com> wrote:
>
>
>
> On 1/29/2026 10:38 PM, John Hubbard wrote:
> > On 1/29/26 5:59 PM, Joel Fernandes wrote:
> >> On 1/29/26 8:12 PM, John Hubbard wrote:
> >>> On 1/29/26 4:26 PM, Joel Fernandes wrote:
> >>>> Based on the below discussion and research, I came up with some deadlock
> >>>> scenarios that we need to handle in the v6 series of these patches.
> >>>> [...]
> >>>> memory allocations under locks that we need in the dma-fence signaling
> >>>> critical path (when doing the virtual memory map/unmap)
> >>>
> >>> unmap? Are you seeing any allocations happening during unmap? I don't
> >>> immediately see any, but that sounds surprising.
> >>
> >> Not allocations but we are acquiring locks during unmap. My understanding
> >> is (at least some) unmaps have to also be done in the dma fence signaling
> >> critical path (the run stage), but Danilo/you can correct me if I am wrong
> >> on that. We cannot avoid all locking but those same locks cannot be held in
> >> any other paths which do a memory allocation (as mentioned in one of the
> >> deadlock scenarios), that is probably the main thing to check for unmap.
> >>
> >
> > Right, OK we are on the same page now: no allocations happening on unmap,
> > but it can still deadlock, because the driver is typically going to
> > use a single lock to protect calls both map and unmap-related calls
> > to the buddy allocator.
>
> Yes exactly!
>
> >
> > For the deadlock above, I think a good way to break that deadlock is
> > to not allow taking that lock in a fence signaling calling path.
> >
> > So during an unmap, instead of "lock, unmap/free, unlock" it should
> > move the item to a deferred-free list, which is processed separately.
> > Of course, this is a little complex, because the allocation and reclaim
> > has to be aware of such lists if they get large.
> Yes, also avoiding GFP_KERNEL allocations while holding any of these mm locks
> (whichever we take during map). The GPU buddy actually does GFP_KERNEL
> allocations internally which is problematic.
>
> Some solutions / next steps:
>
> 1. allocating (VRAM and system memory) outside mm locks just before acquiring them.
>
> 2. pre-allocating both VRAM and system memory needed, before the DMA fence
> critical paths (The issue is also to figure out how much memory to pre-allocate
> for the page table pages based on the VM_BIND request. I think we can analyze
> the page tables in the submit stage to make an estimate).
>
> 3. Unfortunately, I am using gpu-buddy when allocating a VA range in the Vmm
> (called virt_buddy), which itself does GFP_KERNEL memory allocations in the
> allocate path. I am not sure what do yet about this. ISTR the maple tree also
> has similar issues.
>
> 4. Using non-reclaimable memory allocations where pre-allocation or
> pre-allocated memory pools is not possible (I'd like to avoid this #4 so we
> don't fail allocations when memory is scarce).
>
> Will work on these issues for the v7. Thanks,
The way this works on nouveau at least (and I haven't yet read the
nova code in depth).
Is we have 4 stages of vmm page table mgmt.
ref - locked with a ref lock - can allocate/free memory - just makes
sure the page tables exist and are reference counted
map - locked with a map lock - cannot allocate memory - fill in the
PTEs in the page table
unmap - locked with a map lock - cannot allocate memory - removes
entries in PTEs
unref - locked with a ref lock - can allocate/free memory - just drops
references and frees (not sure if it ever merges).
So maps and unmaps can be in fence signalling paths, but unrefs are
done in free job from a workqueue.
Dave.
>
> --
> Joel Fernandes
>
^ permalink raw reply
* Re: [PATCH RFC v6 05/26] nova-core: mm: Add support to use PRAMIN windows to write to VRAM
From: John Hubbard @ 2026-01-31 3:21 UTC (permalink / raw)
To: Dave Airlie, Joel Fernandes
Cc: Danilo Krummrich, Zhi Wang, linux-kernel, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, Simona Vetter, Jonathan Corbet,
Alex Deucher, Christian Koenig, Jani Nikula, Joonas Lahtinen,
Rodrigo Vivi, Tvrtko Ursulin, Rui Huang, Matthew Auld,
Matthew Brost, Lucas De Marchi, Thomas Hellstrom, Helge Deller,
Alice Ryhl, Miguel Ojeda, Alex Gaynor, Boqun Feng, Gary Guo,
Bjorn Roy Baron, Benno Lossin, Andreas Hindborg, Trevor Gross,
Alistair Popple, Timur Tabi, Edwin Peer, Alexandre Courbot,
Andrea Righi, Andy Ritger, Alexey Ivanov, Balbir Singh,
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: <CAPM=9twm1x9rH==uoGQLYa8b4feQMz=Ne14WPuhCPy9_H1u5Tw@mail.gmail.com>
On 1/30/26 7:00 PM, Dave Airlie wrote:
> On Sat, 31 Jan 2026 at 07:14, Joel Fernandes <joelagnelf@nvidia.com> wrote:
>> On 1/29/2026 10:38 PM, John Hubbard wrote:
>>> On 1/29/26 5:59 PM, Joel Fernandes wrote:
>>>> On 1/29/26 8:12 PM, John Hubbard wrote:
>>>>> On 1/29/26 4:26 PM, Joel Fernandes wrote:
>>>>>> [...]
>> Will work on these issues for the v7. Thanks,
>
> The way this works on nouveau at least (and I haven't yet read the
> nova code in depth).
>
> Is we have 4 stages of vmm page table mgmt.
>
> ref - locked with a ref lock - can allocate/free memory - just makes
> sure the page tables exist and are reference counted
> map - locked with a map lock - cannot allocate memory - fill in the
> PTEs in the page table
> unmap - locked with a map lock - cannot allocate memory - removes
> entries in PTEs
> unref - locked with a ref lock - can allocate/free memory - just drops
> references and frees (not sure if it ever merges).
>
> So maps and unmaps can be in fence signalling paths, but unrefs are
> done in free job from a workqueue.
>
Nice! Thanks Dave, I guess this is one time we really should have
taken a peek at nouveau for inspiration after all. :)
thanks,
--
John Hubbard
^ permalink raw reply
* [PATCH] video: of_display_timing: Fix device node reference leak in of_get_display_timings()
From: Felix Gu @ 2026-01-31 12:48 UTC (permalink / raw)
To: Helge Deller, Thierry Reding, Laurent Pinchart, Philipp Zabel,
Stephen Warren, Steffen Trumtrar
Cc: linux-fbdev, dri-devel, linux-kernel, Felix Gu
Use for_each_child_of_node_scoped instead of for_each_child_of_node
to ensure automatic of_node_put on early exit paths, preventing
device node reference leak.
Fixes: cc3f414cf2e4 ("video: add of helper for display timings/videomode")
Signed-off-by: Felix Gu <ustc.gu@gmail.com>
---
drivers/video/of_display_timing.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/video/of_display_timing.c b/drivers/video/of_display_timing.c
index 1940c9505dd3..a6ec392253c3 100644
--- a/drivers/video/of_display_timing.c
+++ b/drivers/video/of_display_timing.c
@@ -195,7 +195,7 @@ struct display_timings *of_get_display_timings(const struct device_node *np)
disp->num_timings = 0;
disp->native_mode = 0;
- for_each_child_of_node(timings_np, entry) {
+ for_each_child_of_node_scoped(timings_np, child) {
struct display_timing *dt;
int r;
@@ -206,7 +206,7 @@ struct display_timings *of_get_display_timings(const struct device_node *np)
goto timingfail;
}
- r = of_parse_display_timing(entry, dt);
+ r = of_parse_display_timing(child, dt);
if (r) {
/*
* to not encourage wrong devicetrees, fail in case of
@@ -218,7 +218,7 @@ struct display_timings *of_get_display_timings(const struct device_node *np)
goto timingfail;
}
- if (native_mode == entry)
+ if (native_mode == child)
disp->native_mode = disp->num_timings;
disp->timings[disp->num_timings] = dt;
---
base-commit: 33a647c659ffa5bdb94abc345c8c86768ff96215
change-id: 20260131-of_display_timging-ef874a2d049b
Best regards,
--
Felix Gu <ustc.gu@gmail.com>
^ permalink raw reply related
* Re: [PATCH RFC v6 05/26] nova-core: mm: Add support to use PRAMIN windows to write to VRAM
From: Joel Fernandes @ 2026-01-31 20:02 UTC (permalink / raw)
To: Dave Airlie
Cc: John Hubbard, Danilo Krummrich, Zhi Wang,
linux-kernel@vger.kernel.org, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Simona Vetter, Jonathan Corbet, Alex Deucher,
Christian Koenig, Jani Nikula, Joonas Lahtinen, Vivi Rodrigo,
Tvrtko Ursulin, Rui Huang, Matthew Auld, Matthew Brost,
Lucas De Marchi, Thomas Hellstrom, Helge Deller, Alice Ryhl,
Miguel Ojeda, Alex Gaynor, Boqun Feng, Gary Guo, Bjorn Roy Baron,
Benno Lossin, Andreas Hindborg, Trevor Gross, Alistair Popple,
Timur Tabi, Edwin Peer, Alexandre Courbot, Andrea Righi,
Andy Ritger, Alexey Ivanov, Balbir Singh, Philipp Stanner,
Elle Rhumsaa, Daniel Almeida, nouveau@lists.freedesktop.org,
dri-devel@lists.freedesktop.org, rust-for-linux@vger.kernel.org,
linux-doc@vger.kernel.org, amd-gfx@lists.freedesktop.org,
intel-gfx@lists.freedesktop.org, intel-xe@lists.freedesktop.org,
linux-fbdev@vger.kernel.org
In-Reply-To: <CAPM=9twm1x9rH==uoGQLYa8b4feQMz=Ne14WPuhCPy9_H1u5Tw@mail.gmail.com>
Hi Dave,
> On Jan 30, 2026, at 10:01 PM, Dave Airlie <airlied@gmail.com> wrote:
>
> On Sat, 31 Jan 2026 at 07:14, Joel Fernandes <joelagnelf@nvidia.com> wrote:
>>
>>
>>
>>> On 1/29/2026 10:38 PM, John Hubbard wrote:
>>> On 1/29/26 5:59 PM, Joel Fernandes wrote:
>>>> On 1/29/26 8:12 PM, John Hubbard wrote:
>>>>> On 1/29/26 4:26 PM, Joel Fernandes wrote:
>>>>>> Based on the below discussion and research, I came up with some deadlock
>>>>>> scenarios that we need to handle in the v6 series of these patches.
>>>>>> [...]
>>>>>> memory allocations under locks that we need in the dma-fence signaling
>>>>>> critical path (when doing the virtual memory map/unmap)
>>>>>
>>>>> unmap? Are you seeing any allocations happening during unmap? I don't
>>>>> immediately see any, but that sounds surprising.
>>>>
>>>> Not allocations but we are acquiring locks during unmap. My understanding
>>>> is (at least some) unmaps have to also be done in the dma fence signaling
>>>> critical path (the run stage), but Danilo/you can correct me if I am wrong
>>>> on that. We cannot avoid all locking but those same locks cannot be held in
>>>> any other paths which do a memory allocation (as mentioned in one of the
>>>> deadlock scenarios), that is probably the main thing to check for unmap.
>>>>
>>>
>>> Right, OK we are on the same page now: no allocations happening on unmap,
>>> but it can still deadlock, because the driver is typically going to
>>> use a single lock to protect calls both map and unmap-related calls
>>> to the buddy allocator.
>>
>> Yes exactly!
>>
>>>
>>> For the deadlock above, I think a good way to break that deadlock is
>>> to not allow taking that lock in a fence signaling calling path.
>>>
>>> So during an unmap, instead of "lock, unmap/free, unlock" it should
>>> move the item to a deferred-free list, which is processed separately.
>>> Of course, this is a little complex, because the allocation and reclaim
>>> has to be aware of such lists if they get large.
>> Yes, also avoiding GFP_KERNEL allocations while holding any of these mm locks
>> (whichever we take during map). The GPU buddy actually does GFP_KERNEL
>> allocations internally which is problematic.
>>
>> Some solutions / next steps:
>>
>> 1. allocating (VRAM and system memory) outside mm locks just before acquiring them.
>>
>> 2. pre-allocating both VRAM and system memory needed, before the DMA fence
>> critical paths (The issue is also to figure out how much memory to pre-allocate
>> for the page table pages based on the VM_BIND request. I think we can analyze
>> the page tables in the submit stage to make an estimate).
>>
>> 3. Unfortunately, I am using gpu-buddy when allocating a VA range in the Vmm
>> (called virt_buddy), which itself does GFP_KERNEL memory allocations in the
>> allocate path. I am not sure what do yet about this. ISTR the maple tree also
>> has similar issues.
>>
>> 4. Using non-reclaimable memory allocations where pre-allocation or
>> pre-allocated memory pools is not possible (I'd like to avoid this #4 so we
>> don't fail allocations when memory is scarce).
>>
>> Will work on these issues for the v7. Thanks,
>
> The way this works on nouveau at least (and I haven't yet read the
> nova code in depth).
>
> Is we have 4 stages of vmm page table mgmt.
>
> ref - locked with a ref lock - can allocate/free memory - just makes
> sure the page tables exist and are reference counted
> map - locked with a map lock - cannot allocate memory - fill in the
> PTEs in the page table
> unmap - locked with a map lock - cannot allocate memory - removes
> entries in PTEs
> unref - locked with a ref lock - can allocate/free memory - just drops
> references and frees (not sure if it ever merges).
Thanks for sharing this, yes this is similar to what I am coming up with.
One thing is OpenRM (and the Linux kernel) have finer grained locking.
But I think we can keep it simple initially like we do for Nouveau with additional complexity progressively added.
Joel Fernandes
>
> So maps and unmaps can be in fence signalling paths, but unrefs are
> done in free job from a workqueue.
>
> Dave.
>>
>> --
>> Joel Fernandes
>>
^ permalink raw reply
* Re: [PATCH RFC v6 05/26] nova-core: mm: Add support to use PRAMIN windows to write to VRAM
From: Joel Fernandes @ 2026-01-31 20:08 UTC (permalink / raw)
To: John Hubbard
Cc: Dave Airlie, Danilo Krummrich, Zhi Wang,
linux-kernel@vger.kernel.org, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Simona Vetter, Jonathan Corbet, Alex Deucher,
Christian Koenig, Jani Nikula, Joonas Lahtinen, Vivi Rodrigo,
Tvrtko Ursulin, Rui Huang, Matthew Auld, Matthew Brost,
Lucas De Marchi, Thomas Hellstrom, Helge Deller, Alice Ryhl,
Miguel Ojeda, Alex Gaynor, Boqun Feng, Gary Guo, Bjorn Roy Baron,
Benno Lossin, Andreas Hindborg, Trevor Gross, Alistair Popple,
Timur Tabi, Edwin Peer, Alexandre Courbot, Andrea Righi,
Andy Ritger, Alexey Ivanov, Balbir Singh, Philipp Stanner,
Elle Rhumsaa, Daniel Almeida, nouveau@lists.freedesktop.org,
dri-devel@lists.freedesktop.org, rust-for-linux@vger.kernel.org,
linux-doc@vger.kernel.org, amd-gfx@lists.freedesktop.org,
intel-gfx@lists.freedesktop.org, intel-xe@lists.freedesktop.org,
linux-fbdev@vger.kernel.org
In-Reply-To: <cea5ddbf-8a6f-409e-bd15-b838a1dd0f65@nvidia.com>
> On Jan 30, 2026, at 10:21 PM, John Hubbard <jhubbard@nvidia.com> wrote:
>
> On 1/30/26 7:00 PM, Dave Airlie wrote:
>>> On Sat, 31 Jan 2026 at 07:14, Joel Fernandes <joelagnelf@nvidia.com> wrote:
>>> On 1/29/2026 10:38 PM, John Hubbard wrote:
>>>> On 1/29/26 5:59 PM, Joel Fernandes wrote:
>>>>> On 1/29/26 8:12 PM, John Hubbard wrote:
>>>>>>> On 1/29/26 4:26 PM, Joel Fernandes wrote:
>>>>>>>> [...]
>>> Will work on these issues for the v7. Thanks,
>>
>> The way this works on nouveau at least (and I haven't yet read the
>> nova code in depth).
>>
>> Is we have 4 stages of vmm page table mgmt.
>>
>> ref - locked with a ref lock - can allocate/free memory - just makes
>> sure the page tables exist and are reference counted
>> map - locked with a map lock - cannot allocate memory - fill in the
>> PTEs in the page table
>> unmap - locked with a map lock - cannot allocate memory - removes
>> entries in PTEs
>> unref - locked with a ref lock - can allocate/free memory - just drops
>> references and frees (not sure if it ever merges).
>>
>> So maps and unmaps can be in fence signalling paths, but unrefs are
>> done in free job from a workqueue.
>>
>
> Nice! Thanks Dave
Indeed, thanks Dave and John.
> , I guess this is one time we really should have
> taken a peek at nouveau for inspiration after all. :)
I have actually been referring to Nouveau, OpenRM and also the core kernel mm code for my research in this area. These all have been a great reference in this respect :). Thanks,
Joel Fernandes
>
> thanks,
> --
> John Hubbard
>
^ permalink raw reply
* [PATCH] staging: sm750fb: make g_fbmode array const
From: James @ 2026-02-02 2:32 UTC (permalink / raw)
To: sudipm.mukherjee; +Cc: teddy.wang, linux-fbdev, linux-staging, gregkh, James
Add missing const qualifier to g_fbmode array to resolve a
checkpatch warning. No functional change intended.
Signed-off-by: James <supernitsuasnowpee@gmail.com>
---
drivers/staging/sm750fb/sm750.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/sm750fb/sm750.c b/drivers/staging/sm750fb/sm750.c
index fecd7457e615..15b5de33b8d9 100644
--- a/drivers/staging/sm750fb/sm750.c
+++ b/drivers/staging/sm750fb/sm750.c
@@ -33,7 +33,7 @@
static int g_hwcursor = 1;
static int g_noaccel;
static int g_nomtrr;
-static const char *g_fbmode[] = {NULL, NULL};
+static const char * const g_fbmode[] = {NULL, NULL};
static const char *g_def_fbmode = "1024x768-32@60";
static char *g_settings;
static int g_dualview;
--
2.52.0
^ permalink raw reply related
* Re: [PATCH] staging: sm750fb: make g_fbmode array const
From: kernel test robot @ 2026-02-02 7:50 UTC (permalink / raw)
To: James, sudipm.mukherjee
Cc: oe-kbuild-all, teddy.wang, linux-fbdev, linux-staging, gregkh,
James
In-Reply-To: <20260202023253.67552-1-supernitsuasnowpee@gmail.com>
Hi James,
kernel test robot noticed the following build errors:
[auto build test ERROR on staging/staging-testing]
url: https://github.com/intel-lab-lkp/linux/commits/James/staging-sm750fb-make-g_fbmode-array-const/20260202-103616
base: staging/staging-testing
patch link: https://lore.kernel.org/r/20260202023253.67552-1-supernitsuasnowpee%40gmail.com
patch subject: [PATCH] staging: sm750fb: make g_fbmode array const
config: parisc-allmodconfig (https://download.01.org/0day-ci/archive/20260202/202602021517.sqf68PlG-lkp@intel.com/config)
compiler: hppa-linux-gcc (GCC) 15.2.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260202/202602021517.sqf68PlG-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/202602021517.sqf68PlG-lkp@intel.com/
All errors (new ones prefixed by >>):
drivers/staging/sm750fb/sm750.c: In function 'lynxfb_set_fbinfo':
>> drivers/staging/sm750fb/sm750.c:795:33: error: assignment of read-only location 'g_fbmode[index]'
795 | g_fbmode[index] = g_def_fbmode;
| ^
drivers/staging/sm750fb/sm750.c:797:41: error: assignment of read-only location 'g_fbmode[index]'
797 | g_fbmode[index] = g_fbmode[0];
| ^
drivers/staging/sm750fb/sm750.c: In function 'sm750fb_setup':
>> drivers/staging/sm750fb/sm750.c:958:45: error: assignment of read-only location 'g_fbmode[0]'
958 | g_fbmode[0] = opt;
| ^
drivers/staging/sm750fb/sm750.c:962:45: error: assignment of read-only location 'g_fbmode[1]'
962 | g_fbmode[1] = opt;
| ^
vim +795 drivers/staging/sm750fb/sm750.c
81dee67e215b23 Sudip Mukherjee 2015-03-03 722
81dee67e215b23 Sudip Mukherjee 2015-03-03 723 static int lynxfb_set_fbinfo(struct fb_info *info, int index)
81dee67e215b23 Sudip Mukherjee 2015-03-03 724 {
81dee67e215b23 Sudip Mukherjee 2015-03-03 725 int i;
81dee67e215b23 Sudip Mukherjee 2015-03-03 726 struct lynxfb_par *par;
e359b6a863e19f Mike Rapoport 2015-10-26 727 struct sm750_dev *sm750_dev;
81dee67e215b23 Sudip Mukherjee 2015-03-03 728 struct lynxfb_crtc *crtc;
81dee67e215b23 Sudip Mukherjee 2015-03-03 729 struct lynxfb_output *output;
81dee67e215b23 Sudip Mukherjee 2015-03-03 730 struct fb_var_screeninfo *var;
81dee67e215b23 Sudip Mukherjee 2015-03-03 731 struct fb_fix_screeninfo *fix;
81dee67e215b23 Sudip Mukherjee 2015-03-03 732
81dee67e215b23 Sudip Mukherjee 2015-03-03 733 const struct fb_videomode *pdb[] = {
81dee67e215b23 Sudip Mukherjee 2015-03-03 734 lynx750_ext, NULL, vesa_modes,
81dee67e215b23 Sudip Mukherjee 2015-03-03 735 };
81dee67e215b23 Sudip Mukherjee 2015-03-03 736 int cdb[] = {ARRAY_SIZE(lynx750_ext), 0, VESA_MODEDB_SIZE};
d5d66cfea2ca28 Kelsey Skunberg 2019-04-27 737 static const char * const mdb_desc[] = {
81dee67e215b23 Sudip Mukherjee 2015-03-03 738 "driver prepared modes",
81dee67e215b23 Sudip Mukherjee 2015-03-03 739 "kernel prepared default modedb",
81dee67e215b23 Sudip Mukherjee 2015-03-03 740 "kernel HELPERS prepared vesa_modes",
81dee67e215b23 Sudip Mukherjee 2015-03-03 741 };
81dee67e215b23 Sudip Mukherjee 2015-03-03 742
8c475735085a7d Tim Wassink 2025-12-21 743 static const char *fix_id[2] = {
81dee67e215b23 Sudip Mukherjee 2015-03-03 744 "sm750_fb1", "sm750_fb2",
81dee67e215b23 Sudip Mukherjee 2015-03-03 745 };
81dee67e215b23 Sudip Mukherjee 2015-03-03 746
81dee67e215b23 Sudip Mukherjee 2015-03-03 747 int ret, line_length;
81dee67e215b23 Sudip Mukherjee 2015-03-03 748
81dee67e215b23 Sudip Mukherjee 2015-03-03 749 ret = 0;
81dee67e215b23 Sudip Mukherjee 2015-03-03 750 par = (struct lynxfb_par *)info->par;
e359b6a863e19f Mike Rapoport 2015-10-26 751 sm750_dev = par->dev;
81dee67e215b23 Sudip Mukherjee 2015-03-03 752 crtc = &par->crtc;
81dee67e215b23 Sudip Mukherjee 2015-03-03 753 output = &par->output;
81dee67e215b23 Sudip Mukherjee 2015-03-03 754 var = &info->var;
81dee67e215b23 Sudip Mukherjee 2015-03-03 755 fix = &info->fix;
81dee67e215b23 Sudip Mukherjee 2015-03-03 756
81dee67e215b23 Sudip Mukherjee 2015-03-03 757 /* set index */
81dee67e215b23 Sudip Mukherjee 2015-03-03 758 par->index = index;
81dee67e215b23 Sudip Mukherjee 2015-03-03 759 output->channel = &crtc->channel;
81dee67e215b23 Sudip Mukherjee 2015-03-03 760 sm750fb_set_drv(par);
81dee67e215b23 Sudip Mukherjee 2015-03-03 761
d11ac7cbcc266c Sudip Mukherjee 2015-08-07 762 /*
d11ac7cbcc266c Sudip Mukherjee 2015-08-07 763 * set current cursor variable and proc pointer,
d11ac7cbcc266c Sudip Mukherjee 2015-08-07 764 * must be set after crtc member initialized
d11ac7cbcc266c Sudip Mukherjee 2015-08-07 765 */
fdc234d85210d9 Benjamin Philip 2021-07-28 766 crtc->cursor.offset = crtc->o_screen + crtc->vidmem_size - 1024;
e359b6a863e19f Mike Rapoport 2015-10-26 767 crtc->cursor.mmio = sm750_dev->pvReg +
e359b6a863e19f Mike Rapoport 2015-10-26 768 0x800f0 + (int)crtc->channel * 0x140;
81dee67e215b23 Sudip Mukherjee 2015-03-03 769
81dee67e215b23 Sudip Mukherjee 2015-03-03 770 pr_info("crtc->cursor.mmio = %p\n", crtc->cursor.mmio);
cd33da26036ea5 Christopher Carbone 2022-08-23 771 crtc->cursor.max_h = 64;
cd33da26036ea5 Christopher Carbone 2022-08-23 772 crtc->cursor.max_w = 64;
39f9137268ee3d Benjamin Philip 2021-07-26 773 crtc->cursor.size = crtc->cursor.max_h * crtc->cursor.max_w * 2 / 8;
e359b6a863e19f Mike Rapoport 2015-10-26 774 crtc->cursor.vstart = sm750_dev->pvMem + crtc->cursor.offset;
81dee67e215b23 Sudip Mukherjee 2015-03-03 775
3de08a2d14ff8c Lorenzo Stoakes 2015-03-20 776 memset_io(crtc->cursor.vstart, 0, crtc->cursor.size);
f7c8a046577e09 Thomas Zimmermann 2023-11-27 777 if (!g_hwcursor)
52d0744d751d8f Arnd Bergmann 2016-11-09 778 sm750_hw_cursor_disable(&crtc->cursor);
81dee67e215b23 Sudip Mukherjee 2015-03-03 779
81dee67e215b23 Sudip Mukherjee 2015-03-03 780 /* set info->fbops, must be set before fb_find_mode */
e359b6a863e19f Mike Rapoport 2015-10-26 781 if (!sm750_dev->accel_off) {
81dee67e215b23 Sudip Mukherjee 2015-03-03 782 /* use 2d acceleration */
f7c8a046577e09 Thomas Zimmermann 2023-11-27 783 if (!g_hwcursor)
f7c8a046577e09 Thomas Zimmermann 2023-11-27 784 info->fbops = &lynxfb_ops_accel;
f7c8a046577e09 Thomas Zimmermann 2023-11-27 785 else
f7c8a046577e09 Thomas Zimmermann 2023-11-27 786 info->fbops = &lynxfb_ops_accel_with_cursor;
f7c8a046577e09 Thomas Zimmermann 2023-11-27 787 } else {
f7c8a046577e09 Thomas Zimmermann 2023-11-27 788 if (!g_hwcursor)
81dee67e215b23 Sudip Mukherjee 2015-03-03 789 info->fbops = &lynxfb_ops;
f7c8a046577e09 Thomas Zimmermann 2023-11-27 790 else
f7c8a046577e09 Thomas Zimmermann 2023-11-27 791 info->fbops = &lynxfb_ops_with_cursor;
f7c8a046577e09 Thomas Zimmermann 2023-11-27 792 }
81dee67e215b23 Sudip Mukherjee 2015-03-03 793
81dee67e215b23 Sudip Mukherjee 2015-03-03 794 if (!g_fbmode[index]) {
81dee67e215b23 Sudip Mukherjee 2015-03-03 @795 g_fbmode[index] = g_def_fbmode;
81dee67e215b23 Sudip Mukherjee 2015-03-03 796 if (index)
81dee67e215b23 Sudip Mukherjee 2015-03-03 797 g_fbmode[index] = g_fbmode[0];
81dee67e215b23 Sudip Mukherjee 2015-03-03 798 }
81dee67e215b23 Sudip Mukherjee 2015-03-03 799
81dee67e215b23 Sudip Mukherjee 2015-03-03 800 for (i = 0; i < 3; i++) {
81dee67e215b23 Sudip Mukherjee 2015-03-03 801 ret = fb_find_mode(var, info, g_fbmode[index],
81dee67e215b23 Sudip Mukherjee 2015-03-03 802 pdb[i], cdb[i], NULL, 8);
81dee67e215b23 Sudip Mukherjee 2015-03-03 803
81dee67e215b23 Sudip Mukherjee 2015-03-03 804 if (ret == 1) {
81dee67e215b23 Sudip Mukherjee 2015-03-03 805 pr_info("success! use specified mode:%s in %s\n",
81dee67e215b23 Sudip Mukherjee 2015-03-03 806 g_fbmode[index],
81dee67e215b23 Sudip Mukherjee 2015-03-03 807 mdb_desc[i]);
81dee67e215b23 Sudip Mukherjee 2015-03-03 808 break;
81dee67e215b23 Sudip Mukherjee 2015-03-03 809 } else if (ret == 2) {
81dee67e215b23 Sudip Mukherjee 2015-03-03 810 pr_warn("use specified mode:%s in %s,with an ignored refresh rate\n",
81dee67e215b23 Sudip Mukherjee 2015-03-03 811 g_fbmode[index],
81dee67e215b23 Sudip Mukherjee 2015-03-03 812 mdb_desc[i]);
81dee67e215b23 Sudip Mukherjee 2015-03-03 813 break;
81dee67e215b23 Sudip Mukherjee 2015-03-03 814 } else if (ret == 3) {
81dee67e215b23 Sudip Mukherjee 2015-03-03 815 pr_warn("wanna use default mode\n");
4bd9503d0becdb Michel von Czettritz 2015-03-26 816 /*break;*/
81dee67e215b23 Sudip Mukherjee 2015-03-03 817 } else if (ret == 4) {
81dee67e215b23 Sudip Mukherjee 2015-03-03 818 pr_warn("fall back to any valid mode\n");
81dee67e215b23 Sudip Mukherjee 2015-03-03 819 } else {
3318bb5e945f70 Michel von Czettritz 2015-03-26 820 pr_warn("ret = %d,fb_find_mode failed,with %s\n",
3318bb5e945f70 Michel von Czettritz 2015-03-26 821 ret,
3318bb5e945f70 Michel von Czettritz 2015-03-26 822 mdb_desc[i]);
81dee67e215b23 Sudip Mukherjee 2015-03-03 823 }
81dee67e215b23 Sudip Mukherjee 2015-03-03 824 }
81dee67e215b23 Sudip Mukherjee 2015-03-03 825
81dee67e215b23 Sudip Mukherjee 2015-03-03 826 /* some member of info->var had been set by fb_find_mode */
81dee67e215b23 Sudip Mukherjee 2015-03-03 827
271dbae3c6a1da Prasant Jalan 2017-04-01 828 pr_info("Member of info->var is :\n"
271dbae3c6a1da Prasant Jalan 2017-04-01 829 "xres=%d\n"
271dbae3c6a1da Prasant Jalan 2017-04-01 830 "yres=%d\n"
271dbae3c6a1da Prasant Jalan 2017-04-01 831 "xres_virtual=%d\n"
271dbae3c6a1da Prasant Jalan 2017-04-01 832 "yres_virtual=%d\n"
271dbae3c6a1da Prasant Jalan 2017-04-01 833 "xoffset=%d\n"
271dbae3c6a1da Prasant Jalan 2017-04-01 834 "yoffset=%d\n"
271dbae3c6a1da Prasant Jalan 2017-04-01 835 "bits_per_pixel=%d\n"
271dbae3c6a1da Prasant Jalan 2017-04-01 836 " ...\n",
3318bb5e945f70 Michel von Czettritz 2015-03-26 837 var->xres,
3318bb5e945f70 Michel von Czettritz 2015-03-26 838 var->yres,
3318bb5e945f70 Michel von Czettritz 2015-03-26 839 var->xres_virtual,
3318bb5e945f70 Michel von Czettritz 2015-03-26 840 var->yres_virtual,
3318bb5e945f70 Michel von Czettritz 2015-03-26 841 var->xoffset,
3318bb5e945f70 Michel von Czettritz 2015-03-26 842 var->yoffset,
3318bb5e945f70 Michel von Czettritz 2015-03-26 843 var->bits_per_pixel);
81dee67e215b23 Sudip Mukherjee 2015-03-03 844
81dee67e215b23 Sudip Mukherjee 2015-03-03 845 /* set par */
81dee67e215b23 Sudip Mukherjee 2015-03-03 846 par->info = info;
81dee67e215b23 Sudip Mukherjee 2015-03-03 847
81dee67e215b23 Sudip Mukherjee 2015-03-03 848 /* set info */
e3a3f9f5123683 Mike Rapoport 2015-10-26 849 line_length = ALIGN((var->xres_virtual * var->bits_per_pixel / 8),
e3a3f9f5123683 Mike Rapoport 2015-10-26 850 crtc->line_pad);
81dee67e215b23 Sudip Mukherjee 2015-03-03 851
81dee67e215b23 Sudip Mukherjee 2015-03-03 852 info->pseudo_palette = &par->pseudo_palette[0];
cc59bde1c920ab Benjamin Philip 2021-07-28 853 info->screen_base = crtc->v_screen;
81dee67e215b23 Sudip Mukherjee 2015-03-03 854 pr_debug("screen_base vaddr = %p\n", info->screen_base);
81dee67e215b23 Sudip Mukherjee 2015-03-03 855 info->screen_size = line_length * var->yres_virtual;
81dee67e215b23 Sudip Mukherjee 2015-03-03 856
81dee67e215b23 Sudip Mukherjee 2015-03-03 857 /* set info->fix */
81dee67e215b23 Sudip Mukherjee 2015-03-03 858 fix->type = FB_TYPE_PACKED_PIXELS;
81dee67e215b23 Sudip Mukherjee 2015-03-03 859 fix->type_aux = 0;
81dee67e215b23 Sudip Mukherjee 2015-03-03 860 fix->xpanstep = crtc->xpanstep;
81dee67e215b23 Sudip Mukherjee 2015-03-03 861 fix->ypanstep = crtc->ypanstep;
81dee67e215b23 Sudip Mukherjee 2015-03-03 862 fix->ywrapstep = crtc->ywrapstep;
81dee67e215b23 Sudip Mukherjee 2015-03-03 863 fix->accel = FB_ACCEL_SMI;
81dee67e215b23 Sudip Mukherjee 2015-03-03 864
8c475735085a7d Tim Wassink 2025-12-21 865 strscpy(fix->id, fix_id[index], sizeof(fix->id));
81dee67e215b23 Sudip Mukherjee 2015-03-03 866
fdc234d85210d9 Benjamin Philip 2021-07-28 867 fix->smem_start = crtc->o_screen + sm750_dev->vidmem_start;
81dee67e215b23 Sudip Mukherjee 2015-03-03 868 pr_info("fix->smem_start = %lx\n", fix->smem_start);
d11ac7cbcc266c Sudip Mukherjee 2015-08-07 869 /*
d11ac7cbcc266c Sudip Mukherjee 2015-08-07 870 * according to mmap experiment from user space application,
81dee67e215b23 Sudip Mukherjee 2015-03-03 871 * fix->mmio_len should not larger than virtual size
81dee67e215b23 Sudip Mukherjee 2015-03-03 872 * (xres_virtual x yres_virtual x ByPP)
81dee67e215b23 Sudip Mukherjee 2015-03-03 873 * Below line maybe buggy when user mmap fb dev node and write
81dee67e215b23 Sudip Mukherjee 2015-03-03 874 * data into the bound over virtual size
d11ac7cbcc266c Sudip Mukherjee 2015-08-07 875 */
81dee67e215b23 Sudip Mukherjee 2015-03-03 876 fix->smem_len = crtc->vidmem_size;
81dee67e215b23 Sudip Mukherjee 2015-03-03 877 pr_info("fix->smem_len = %x\n", fix->smem_len);
81dee67e215b23 Sudip Mukherjee 2015-03-03 878 info->screen_size = fix->smem_len;
81dee67e215b23 Sudip Mukherjee 2015-03-03 879 fix->line_length = line_length;
e359b6a863e19f Mike Rapoport 2015-10-26 880 fix->mmio_start = sm750_dev->vidreg_start;
81dee67e215b23 Sudip Mukherjee 2015-03-03 881 pr_info("fix->mmio_start = %lx\n", fix->mmio_start);
e359b6a863e19f Mike Rapoport 2015-10-26 882 fix->mmio_len = sm750_dev->vidreg_size;
81dee67e215b23 Sudip Mukherjee 2015-03-03 883 pr_info("fix->mmio_len = %x\n", fix->mmio_len);
b610e1193a917f Matej Dujava 2020-04-30 884
b610e1193a917f Matej Dujava 2020-04-30 885 lynxfb_set_visual_mode(info);
81dee67e215b23 Sudip Mukherjee 2015-03-03 886
81dee67e215b23 Sudip Mukherjee 2015-03-03 887 /* set var */
81dee67e215b23 Sudip Mukherjee 2015-03-03 888 var->activate = FB_ACTIVATE_NOW;
81dee67e215b23 Sudip Mukherjee 2015-03-03 889 var->accel_flags = 0;
81dee67e215b23 Sudip Mukherjee 2015-03-03 890 var->vmode = FB_VMODE_NONINTERLACED;
81dee67e215b23 Sudip Mukherjee 2015-03-03 891
81dee67e215b23 Sudip Mukherjee 2015-03-03 892 pr_debug("#1 show info->cmap :\nstart=%d,len=%d,red=%p,green=%p,blue=%p,transp=%p\n",
81dee67e215b23 Sudip Mukherjee 2015-03-03 893 info->cmap.start, info->cmap.len,
81dee67e215b23 Sudip Mukherjee 2015-03-03 894 info->cmap.red, info->cmap.green, info->cmap.blue,
81dee67e215b23 Sudip Mukherjee 2015-03-03 895 info->cmap.transp);
81dee67e215b23 Sudip Mukherjee 2015-03-03 896
61c507cf652da1 Michel von Czettritz 2015-03-26 897 ret = fb_alloc_cmap(&info->cmap, 256, 0);
61c507cf652da1 Michel von Czettritz 2015-03-26 898 if (ret < 0) {
008272072d61a8 Masanari Iida 2015-05-28 899 pr_err("Could not allocate memory for cmap.\n");
81dee67e215b23 Sudip Mukherjee 2015-03-03 900 goto exit;
81dee67e215b23 Sudip Mukherjee 2015-03-03 901 }
81dee67e215b23 Sudip Mukherjee 2015-03-03 902
81dee67e215b23 Sudip Mukherjee 2015-03-03 903 pr_debug("#2 show info->cmap :\nstart=%d,len=%d,red=%p,green=%p,blue=%p,transp=%p\n",
81dee67e215b23 Sudip Mukherjee 2015-03-03 904 info->cmap.start, info->cmap.len,
81dee67e215b23 Sudip Mukherjee 2015-03-03 905 info->cmap.red, info->cmap.green, info->cmap.blue,
81dee67e215b23 Sudip Mukherjee 2015-03-03 906 info->cmap.transp);
81dee67e215b23 Sudip Mukherjee 2015-03-03 907
81dee67e215b23 Sudip Mukherjee 2015-03-03 908 exit:
81dee67e215b23 Sudip Mukherjee 2015-03-03 909 lynxfb_ops_check_var(var, info);
81dee67e215b23 Sudip Mukherjee 2015-03-03 910 return ret;
81dee67e215b23 Sudip Mukherjee 2015-03-03 911 }
81dee67e215b23 Sudip Mukherjee 2015-03-03 912
81dee67e215b23 Sudip Mukherjee 2015-03-03 913 /* chip specific g_option configuration routine */
700591a9adc8b1 Mike Rapoport 2015-10-26 914 static void sm750fb_setup(struct sm750_dev *sm750_dev, char *src)
81dee67e215b23 Sudip Mukherjee 2015-03-03 915 {
81dee67e215b23 Sudip Mukherjee 2015-03-03 916 char *opt;
81dee67e215b23 Sudip Mukherjee 2015-03-03 917 int swap;
81dee67e215b23 Sudip Mukherjee 2015-03-03 918
81dee67e215b23 Sudip Mukherjee 2015-03-03 919 swap = 0;
81dee67e215b23 Sudip Mukherjee 2015-03-03 920
cc34db609ff98c Madhumitha Sundar 2026-01-27 921 sm750_dev->init_parm.chip_clk = 0;
cc34db609ff98c Madhumitha Sundar 2026-01-27 922 sm750_dev->init_parm.mem_clk = 0;
cc34db609ff98c Madhumitha Sundar 2026-01-27 923 sm750_dev->init_parm.master_clk = 0;
cc34db609ff98c Madhumitha Sundar 2026-01-27 924 sm750_dev->init_parm.powerMode = 0;
cc34db609ff98c Madhumitha Sundar 2026-01-27 925 sm750_dev->init_parm.setAllEngOff = 0;
cc34db609ff98c Madhumitha Sundar 2026-01-27 926 sm750_dev->init_parm.resetMemory = 1;
81dee67e215b23 Sudip Mukherjee 2015-03-03 927
81dee67e215b23 Sudip Mukherjee 2015-03-03 928 /* defaultly turn g_hwcursor on for both view */
81dee67e215b23 Sudip Mukherjee 2015-03-03 929 g_hwcursor = 3;
81dee67e215b23 Sudip Mukherjee 2015-03-03 930
81dee67e215b23 Sudip Mukherjee 2015-03-03 931 if (!src || !*src) {
c56de0967a658c Elise Lennion 2016-10-31 932 dev_warn(&sm750_dev->pdev->dev, "no specific g_option.\n");
81dee67e215b23 Sudip Mukherjee 2015-03-03 933 goto NO_PARAM;
81dee67e215b23 Sudip Mukherjee 2015-03-03 934 }
81dee67e215b23 Sudip Mukherjee 2015-03-03 935
0fa96e39279988 Sudip Mukherjee 2015-03-10 936 while ((opt = strsep(&src, ":")) != NULL && *opt != 0) {
c56de0967a658c Elise Lennion 2016-10-31 937 dev_info(&sm750_dev->pdev->dev, "opt=%s\n", opt);
c56de0967a658c Elise Lennion 2016-10-31 938 dev_info(&sm750_dev->pdev->dev, "src=%s\n", src);
81dee67e215b23 Sudip Mukherjee 2015-03-03 939
144634a6b42146 Katie Dunne 2017-02-19 940 if (!strncmp(opt, "swap", strlen("swap"))) {
81dee67e215b23 Sudip Mukherjee 2015-03-03 941 swap = 1;
144634a6b42146 Katie Dunne 2017-02-19 942 } else if (!strncmp(opt, "nocrt", strlen("nocrt"))) {
1757d106a9ce8c Mike Rapoport 2015-10-26 943 sm750_dev->nocrt = 1;
144634a6b42146 Katie Dunne 2017-02-19 944 } else if (!strncmp(opt, "36bit", strlen("36bit"))) {
1757d106a9ce8c Mike Rapoport 2015-10-26 945 sm750_dev->pnltype = sm750_doubleTFT;
144634a6b42146 Katie Dunne 2017-02-19 946 } else if (!strncmp(opt, "18bit", strlen("18bit"))) {
1757d106a9ce8c Mike Rapoport 2015-10-26 947 sm750_dev->pnltype = sm750_dualTFT;
144634a6b42146 Katie Dunne 2017-02-19 948 } else if (!strncmp(opt, "24bit", strlen("24bit"))) {
1757d106a9ce8c Mike Rapoport 2015-10-26 949 sm750_dev->pnltype = sm750_24TFT;
144634a6b42146 Katie Dunne 2017-02-19 950 } else if (!strncmp(opt, "nohwc0", strlen("nohwc0"))) {
81dee67e215b23 Sudip Mukherjee 2015-03-03 951 g_hwcursor &= ~0x1;
144634a6b42146 Katie Dunne 2017-02-19 952 } else if (!strncmp(opt, "nohwc1", strlen("nohwc1"))) {
81dee67e215b23 Sudip Mukherjee 2015-03-03 953 g_hwcursor &= ~0x2;
144634a6b42146 Katie Dunne 2017-02-19 954 } else if (!strncmp(opt, "nohwc", strlen("nohwc"))) {
81dee67e215b23 Sudip Mukherjee 2015-03-03 955 g_hwcursor = 0;
144634a6b42146 Katie Dunne 2017-02-19 956 } else {
81dee67e215b23 Sudip Mukherjee 2015-03-03 957 if (!g_fbmode[0]) {
81dee67e215b23 Sudip Mukherjee 2015-03-03 @958 g_fbmode[0] = opt;
cee9ba1c30d051 Abdul Rauf 2017-01-08 959 dev_info(&sm750_dev->pdev->dev,
cee9ba1c30d051 Abdul Rauf 2017-01-08 960 "find fbmode0 : %s\n", g_fbmode[0]);
81dee67e215b23 Sudip Mukherjee 2015-03-03 961 } else if (!g_fbmode[1]) {
81dee67e215b23 Sudip Mukherjee 2015-03-03 962 g_fbmode[1] = opt;
cee9ba1c30d051 Abdul Rauf 2017-01-08 963 dev_info(&sm750_dev->pdev->dev,
cee9ba1c30d051 Abdul Rauf 2017-01-08 964 "find fbmode1 : %s\n", g_fbmode[1]);
81dee67e215b23 Sudip Mukherjee 2015-03-03 965 } else {
c56de0967a658c Elise Lennion 2016-10-31 966 dev_warn(&sm750_dev->pdev->dev, "How many view you wann set?\n");
81dee67e215b23 Sudip Mukherjee 2015-03-03 967 }
81dee67e215b23 Sudip Mukherjee 2015-03-03 968 }
81dee67e215b23 Sudip Mukherjee 2015-03-03 969 }
81dee67e215b23 Sudip Mukherjee 2015-03-03 970
81dee67e215b23 Sudip Mukherjee 2015-03-03 971 NO_PARAM:
e359b6a863e19f Mike Rapoport 2015-10-26 972 if (sm750_dev->revid != SM750LE_REVISION_ID) {
a3f92cc94c6126 Mike Rapoport 2016-01-17 973 if (sm750_dev->fb_count > 1) {
81dee67e215b23 Sudip Mukherjee 2015-03-03 974 if (swap)
1757d106a9ce8c Mike Rapoport 2015-10-26 975 sm750_dev->dataflow = sm750_dual_swap;
81dee67e215b23 Sudip Mukherjee 2015-03-03 976 else
1757d106a9ce8c Mike Rapoport 2015-10-26 977 sm750_dev->dataflow = sm750_dual_normal;
81dee67e215b23 Sudip Mukherjee 2015-03-03 978 } else {
81dee67e215b23 Sudip Mukherjee 2015-03-03 979 if (swap)
1757d106a9ce8c Mike Rapoport 2015-10-26 980 sm750_dev->dataflow = sm750_simul_sec;
81dee67e215b23 Sudip Mukherjee 2015-03-03 981 else
1757d106a9ce8c Mike Rapoport 2015-10-26 982 sm750_dev->dataflow = sm750_simul_pri;
81dee67e215b23 Sudip Mukherjee 2015-03-03 983 }
81dee67e215b23 Sudip Mukherjee 2015-03-03 984 } else {
81dee67e215b23 Sudip Mukherjee 2015-03-03 985 /* SM750LE only have one crt channel */
1757d106a9ce8c Mike Rapoport 2015-10-26 986 sm750_dev->dataflow = sm750_simul_sec;
81dee67e215b23 Sudip Mukherjee 2015-03-03 987 /* sm750le do not have complex attributes */
1757d106a9ce8c Mike Rapoport 2015-10-26 988 sm750_dev->nocrt = 0;
81dee67e215b23 Sudip Mukherjee 2015-03-03 989 }
81dee67e215b23 Sudip Mukherjee 2015-03-03 990 }
81dee67e215b23 Sudip Mukherjee 2015-03-03 991
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* [PATCH] backlight: sky81452-backlight: Check return value of devm_gpiod_get_optional() in sky81452_bl_parse_dt()
From: Chen Ni @ 2026-02-02 7:54 UTC (permalink / raw)
To: lee, danielt, jingoohan1, deller, linusw
Cc: dri-devel, linux-fbdev, linux-kernel, Chen Ni
The devm_gpiod_get_optional() function may return an ERR_PTR in case of
genuine GPIO acquisition errors, not just NULL which indicates the
legitimate absence of an optional GPIO.
Add an IS_ERR() check after the call in sky81452_bl_parse_dt(). On
error, return the error code to ensure proper failure handling rather
than proceeding with invalid pointers.
Fixes: e1915eec54a6 ("backlight: sky81452: Convert to GPIO descriptors")
Signed-off-by: Chen Ni <nichen@iscas.ac.cn>
---
drivers/video/backlight/sky81452-backlight.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/video/backlight/sky81452-backlight.c b/drivers/video/backlight/sky81452-backlight.c
index 2749231f0385..e3e5306fab84 100644
--- a/drivers/video/backlight/sky81452-backlight.c
+++ b/drivers/video/backlight/sky81452-backlight.c
@@ -202,6 +202,10 @@ static struct sky81452_bl_platform_data *sky81452_bl_parse_dt(
pdata->dpwm_mode = of_property_read_bool(np, "skyworks,dpwm-mode");
pdata->phase_shift = of_property_read_bool(np, "skyworks,phase-shift");
pdata->gpiod_enable = devm_gpiod_get_optional(dev, NULL, GPIOD_OUT_HIGH);
+ if (IS_ERR(pdata->gpiod_enable)) {
+ dev_err(dev, "failed to get gpio\n");
+ return ERR_CAST(pdata->gpiod_enable);
+ }
ret = of_property_count_u32_elems(np, "led-sources");
if (ret < 0) {
--
2.25.1
^ permalink raw reply related
* Re: [PATCH] staging: sm750fb: make g_fbmode array const
From: kernel test robot @ 2026-02-02 9:02 UTC (permalink / raw)
To: James, sudipm.mukherjee
Cc: llvm, oe-kbuild-all, teddy.wang, linux-fbdev, linux-staging,
gregkh, James
In-Reply-To: <20260202023253.67552-1-supernitsuasnowpee@gmail.com>
Hi James,
kernel test robot noticed the following build errors:
[auto build test ERROR on staging/staging-testing]
url: https://github.com/intel-lab-lkp/linux/commits/James/staging-sm750fb-make-g_fbmode-array-const/20260202-103616
base: staging/staging-testing
patch link: https://lore.kernel.org/r/20260202023253.67552-1-supernitsuasnowpee%40gmail.com
patch subject: [PATCH] staging: sm750fb: make g_fbmode array const
config: riscv-allmodconfig (https://download.01.org/0day-ci/archive/20260202/202602021649.9bGhL8np-lkp@intel.com/config)
compiler: clang version 22.0.0git (https://github.com/llvm/llvm-project 9b8addffa70cee5b2acc5454712d9cf78ce45710)
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260202/202602021649.9bGhL8np-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/202602021649.9bGhL8np-lkp@intel.com/
All errors (new ones prefixed by >>):
>> drivers/staging/sm750fb/sm750.c:795:19: error: cannot assign to variable 'g_fbmode' with const-qualified type 'const char *const[2]'
795 | g_fbmode[index] = g_def_fbmode;
| ~~~~~~~~~~~~~~~ ^
drivers/staging/sm750fb/sm750.c:36:27: note: variable 'g_fbmode' declared const here
36 | static const char * const g_fbmode[] = {NULL, NULL};
| ~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~
drivers/staging/sm750fb/sm750.c:797:20: error: cannot assign to variable 'g_fbmode' with const-qualified type 'const char *const[2]'
797 | g_fbmode[index] = g_fbmode[0];
| ~~~~~~~~~~~~~~~ ^
drivers/staging/sm750fb/sm750.c:36:27: note: variable 'g_fbmode' declared const here
36 | static const char * const g_fbmode[] = {NULL, NULL};
| ~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~
drivers/staging/sm750fb/sm750.c:958:17: error: cannot assign to variable 'g_fbmode' with const-qualified type 'const char *const[2]'
958 | g_fbmode[0] = opt;
| ~~~~~~~~~~~ ^
drivers/staging/sm750fb/sm750.c:36:27: note: variable 'g_fbmode' declared const here
36 | static const char * const g_fbmode[] = {NULL, NULL};
| ~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~
drivers/staging/sm750fb/sm750.c:962:17: error: cannot assign to variable 'g_fbmode' with const-qualified type 'const char *const[2]'
962 | g_fbmode[1] = opt;
| ~~~~~~~~~~~ ^
drivers/staging/sm750fb/sm750.c:36:27: note: variable 'g_fbmode' declared const here
36 | static const char * const g_fbmode[] = {NULL, NULL};
| ~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~
4 errors generated.
vim +795 drivers/staging/sm750fb/sm750.c
81dee67e215b23 Sudip Mukherjee 2015-03-03 722
81dee67e215b23 Sudip Mukherjee 2015-03-03 723 static int lynxfb_set_fbinfo(struct fb_info *info, int index)
81dee67e215b23 Sudip Mukherjee 2015-03-03 724 {
81dee67e215b23 Sudip Mukherjee 2015-03-03 725 int i;
81dee67e215b23 Sudip Mukherjee 2015-03-03 726 struct lynxfb_par *par;
e359b6a863e19f Mike Rapoport 2015-10-26 727 struct sm750_dev *sm750_dev;
81dee67e215b23 Sudip Mukherjee 2015-03-03 728 struct lynxfb_crtc *crtc;
81dee67e215b23 Sudip Mukherjee 2015-03-03 729 struct lynxfb_output *output;
81dee67e215b23 Sudip Mukherjee 2015-03-03 730 struct fb_var_screeninfo *var;
81dee67e215b23 Sudip Mukherjee 2015-03-03 731 struct fb_fix_screeninfo *fix;
81dee67e215b23 Sudip Mukherjee 2015-03-03 732
81dee67e215b23 Sudip Mukherjee 2015-03-03 733 const struct fb_videomode *pdb[] = {
81dee67e215b23 Sudip Mukherjee 2015-03-03 734 lynx750_ext, NULL, vesa_modes,
81dee67e215b23 Sudip Mukherjee 2015-03-03 735 };
81dee67e215b23 Sudip Mukherjee 2015-03-03 736 int cdb[] = {ARRAY_SIZE(lynx750_ext), 0, VESA_MODEDB_SIZE};
d5d66cfea2ca28 Kelsey Skunberg 2019-04-27 737 static const char * const mdb_desc[] = {
81dee67e215b23 Sudip Mukherjee 2015-03-03 738 "driver prepared modes",
81dee67e215b23 Sudip Mukherjee 2015-03-03 739 "kernel prepared default modedb",
81dee67e215b23 Sudip Mukherjee 2015-03-03 740 "kernel HELPERS prepared vesa_modes",
81dee67e215b23 Sudip Mukherjee 2015-03-03 741 };
81dee67e215b23 Sudip Mukherjee 2015-03-03 742
8c475735085a7d Tim Wassink 2025-12-21 743 static const char *fix_id[2] = {
81dee67e215b23 Sudip Mukherjee 2015-03-03 744 "sm750_fb1", "sm750_fb2",
81dee67e215b23 Sudip Mukherjee 2015-03-03 745 };
81dee67e215b23 Sudip Mukherjee 2015-03-03 746
81dee67e215b23 Sudip Mukherjee 2015-03-03 747 int ret, line_length;
81dee67e215b23 Sudip Mukherjee 2015-03-03 748
81dee67e215b23 Sudip Mukherjee 2015-03-03 749 ret = 0;
81dee67e215b23 Sudip Mukherjee 2015-03-03 750 par = (struct lynxfb_par *)info->par;
e359b6a863e19f Mike Rapoport 2015-10-26 751 sm750_dev = par->dev;
81dee67e215b23 Sudip Mukherjee 2015-03-03 752 crtc = &par->crtc;
81dee67e215b23 Sudip Mukherjee 2015-03-03 753 output = &par->output;
81dee67e215b23 Sudip Mukherjee 2015-03-03 754 var = &info->var;
81dee67e215b23 Sudip Mukherjee 2015-03-03 755 fix = &info->fix;
81dee67e215b23 Sudip Mukherjee 2015-03-03 756
81dee67e215b23 Sudip Mukherjee 2015-03-03 757 /* set index */
81dee67e215b23 Sudip Mukherjee 2015-03-03 758 par->index = index;
81dee67e215b23 Sudip Mukherjee 2015-03-03 759 output->channel = &crtc->channel;
81dee67e215b23 Sudip Mukherjee 2015-03-03 760 sm750fb_set_drv(par);
81dee67e215b23 Sudip Mukherjee 2015-03-03 761
d11ac7cbcc266c Sudip Mukherjee 2015-08-07 762 /*
d11ac7cbcc266c Sudip Mukherjee 2015-08-07 763 * set current cursor variable and proc pointer,
d11ac7cbcc266c Sudip Mukherjee 2015-08-07 764 * must be set after crtc member initialized
d11ac7cbcc266c Sudip Mukherjee 2015-08-07 765 */
fdc234d85210d9 Benjamin Philip 2021-07-28 766 crtc->cursor.offset = crtc->o_screen + crtc->vidmem_size - 1024;
e359b6a863e19f Mike Rapoport 2015-10-26 767 crtc->cursor.mmio = sm750_dev->pvReg +
e359b6a863e19f Mike Rapoport 2015-10-26 768 0x800f0 + (int)crtc->channel * 0x140;
81dee67e215b23 Sudip Mukherjee 2015-03-03 769
81dee67e215b23 Sudip Mukherjee 2015-03-03 770 pr_info("crtc->cursor.mmio = %p\n", crtc->cursor.mmio);
cd33da26036ea5 Christopher Carbone 2022-08-23 771 crtc->cursor.max_h = 64;
cd33da26036ea5 Christopher Carbone 2022-08-23 772 crtc->cursor.max_w = 64;
39f9137268ee3d Benjamin Philip 2021-07-26 773 crtc->cursor.size = crtc->cursor.max_h * crtc->cursor.max_w * 2 / 8;
e359b6a863e19f Mike Rapoport 2015-10-26 774 crtc->cursor.vstart = sm750_dev->pvMem + crtc->cursor.offset;
81dee67e215b23 Sudip Mukherjee 2015-03-03 775
3de08a2d14ff8c Lorenzo Stoakes 2015-03-20 776 memset_io(crtc->cursor.vstart, 0, crtc->cursor.size);
f7c8a046577e09 Thomas Zimmermann 2023-11-27 777 if (!g_hwcursor)
52d0744d751d8f Arnd Bergmann 2016-11-09 778 sm750_hw_cursor_disable(&crtc->cursor);
81dee67e215b23 Sudip Mukherjee 2015-03-03 779
81dee67e215b23 Sudip Mukherjee 2015-03-03 780 /* set info->fbops, must be set before fb_find_mode */
e359b6a863e19f Mike Rapoport 2015-10-26 781 if (!sm750_dev->accel_off) {
81dee67e215b23 Sudip Mukherjee 2015-03-03 782 /* use 2d acceleration */
f7c8a046577e09 Thomas Zimmermann 2023-11-27 783 if (!g_hwcursor)
f7c8a046577e09 Thomas Zimmermann 2023-11-27 784 info->fbops = &lynxfb_ops_accel;
f7c8a046577e09 Thomas Zimmermann 2023-11-27 785 else
f7c8a046577e09 Thomas Zimmermann 2023-11-27 786 info->fbops = &lynxfb_ops_accel_with_cursor;
f7c8a046577e09 Thomas Zimmermann 2023-11-27 787 } else {
f7c8a046577e09 Thomas Zimmermann 2023-11-27 788 if (!g_hwcursor)
81dee67e215b23 Sudip Mukherjee 2015-03-03 789 info->fbops = &lynxfb_ops;
f7c8a046577e09 Thomas Zimmermann 2023-11-27 790 else
f7c8a046577e09 Thomas Zimmermann 2023-11-27 791 info->fbops = &lynxfb_ops_with_cursor;
f7c8a046577e09 Thomas Zimmermann 2023-11-27 792 }
81dee67e215b23 Sudip Mukherjee 2015-03-03 793
81dee67e215b23 Sudip Mukherjee 2015-03-03 794 if (!g_fbmode[index]) {
81dee67e215b23 Sudip Mukherjee 2015-03-03 @795 g_fbmode[index] = g_def_fbmode;
81dee67e215b23 Sudip Mukherjee 2015-03-03 796 if (index)
81dee67e215b23 Sudip Mukherjee 2015-03-03 797 g_fbmode[index] = g_fbmode[0];
81dee67e215b23 Sudip Mukherjee 2015-03-03 798 }
81dee67e215b23 Sudip Mukherjee 2015-03-03 799
81dee67e215b23 Sudip Mukherjee 2015-03-03 800 for (i = 0; i < 3; i++) {
81dee67e215b23 Sudip Mukherjee 2015-03-03 801 ret = fb_find_mode(var, info, g_fbmode[index],
81dee67e215b23 Sudip Mukherjee 2015-03-03 802 pdb[i], cdb[i], NULL, 8);
81dee67e215b23 Sudip Mukherjee 2015-03-03 803
81dee67e215b23 Sudip Mukherjee 2015-03-03 804 if (ret == 1) {
81dee67e215b23 Sudip Mukherjee 2015-03-03 805 pr_info("success! use specified mode:%s in %s\n",
81dee67e215b23 Sudip Mukherjee 2015-03-03 806 g_fbmode[index],
81dee67e215b23 Sudip Mukherjee 2015-03-03 807 mdb_desc[i]);
81dee67e215b23 Sudip Mukherjee 2015-03-03 808 break;
81dee67e215b23 Sudip Mukherjee 2015-03-03 809 } else if (ret == 2) {
81dee67e215b23 Sudip Mukherjee 2015-03-03 810 pr_warn("use specified mode:%s in %s,with an ignored refresh rate\n",
81dee67e215b23 Sudip Mukherjee 2015-03-03 811 g_fbmode[index],
81dee67e215b23 Sudip Mukherjee 2015-03-03 812 mdb_desc[i]);
81dee67e215b23 Sudip Mukherjee 2015-03-03 813 break;
81dee67e215b23 Sudip Mukherjee 2015-03-03 814 } else if (ret == 3) {
81dee67e215b23 Sudip Mukherjee 2015-03-03 815 pr_warn("wanna use default mode\n");
4bd9503d0becdb Michel von Czettritz 2015-03-26 816 /*break;*/
81dee67e215b23 Sudip Mukherjee 2015-03-03 817 } else if (ret == 4) {
81dee67e215b23 Sudip Mukherjee 2015-03-03 818 pr_warn("fall back to any valid mode\n");
81dee67e215b23 Sudip Mukherjee 2015-03-03 819 } else {
3318bb5e945f70 Michel von Czettritz 2015-03-26 820 pr_warn("ret = %d,fb_find_mode failed,with %s\n",
3318bb5e945f70 Michel von Czettritz 2015-03-26 821 ret,
3318bb5e945f70 Michel von Czettritz 2015-03-26 822 mdb_desc[i]);
81dee67e215b23 Sudip Mukherjee 2015-03-03 823 }
81dee67e215b23 Sudip Mukherjee 2015-03-03 824 }
81dee67e215b23 Sudip Mukherjee 2015-03-03 825
81dee67e215b23 Sudip Mukherjee 2015-03-03 826 /* some member of info->var had been set by fb_find_mode */
81dee67e215b23 Sudip Mukherjee 2015-03-03 827
271dbae3c6a1da Prasant Jalan 2017-04-01 828 pr_info("Member of info->var is :\n"
271dbae3c6a1da Prasant Jalan 2017-04-01 829 "xres=%d\n"
271dbae3c6a1da Prasant Jalan 2017-04-01 830 "yres=%d\n"
271dbae3c6a1da Prasant Jalan 2017-04-01 831 "xres_virtual=%d\n"
271dbae3c6a1da Prasant Jalan 2017-04-01 832 "yres_virtual=%d\n"
271dbae3c6a1da Prasant Jalan 2017-04-01 833 "xoffset=%d\n"
271dbae3c6a1da Prasant Jalan 2017-04-01 834 "yoffset=%d\n"
271dbae3c6a1da Prasant Jalan 2017-04-01 835 "bits_per_pixel=%d\n"
271dbae3c6a1da Prasant Jalan 2017-04-01 836 " ...\n",
3318bb5e945f70 Michel von Czettritz 2015-03-26 837 var->xres,
3318bb5e945f70 Michel von Czettritz 2015-03-26 838 var->yres,
3318bb5e945f70 Michel von Czettritz 2015-03-26 839 var->xres_virtual,
3318bb5e945f70 Michel von Czettritz 2015-03-26 840 var->yres_virtual,
3318bb5e945f70 Michel von Czettritz 2015-03-26 841 var->xoffset,
3318bb5e945f70 Michel von Czettritz 2015-03-26 842 var->yoffset,
3318bb5e945f70 Michel von Czettritz 2015-03-26 843 var->bits_per_pixel);
81dee67e215b23 Sudip Mukherjee 2015-03-03 844
81dee67e215b23 Sudip Mukherjee 2015-03-03 845 /* set par */
81dee67e215b23 Sudip Mukherjee 2015-03-03 846 par->info = info;
81dee67e215b23 Sudip Mukherjee 2015-03-03 847
81dee67e215b23 Sudip Mukherjee 2015-03-03 848 /* set info */
e3a3f9f5123683 Mike Rapoport 2015-10-26 849 line_length = ALIGN((var->xres_virtual * var->bits_per_pixel / 8),
e3a3f9f5123683 Mike Rapoport 2015-10-26 850 crtc->line_pad);
81dee67e215b23 Sudip Mukherjee 2015-03-03 851
81dee67e215b23 Sudip Mukherjee 2015-03-03 852 info->pseudo_palette = &par->pseudo_palette[0];
cc59bde1c920ab Benjamin Philip 2021-07-28 853 info->screen_base = crtc->v_screen;
81dee67e215b23 Sudip Mukherjee 2015-03-03 854 pr_debug("screen_base vaddr = %p\n", info->screen_base);
81dee67e215b23 Sudip Mukherjee 2015-03-03 855 info->screen_size = line_length * var->yres_virtual;
81dee67e215b23 Sudip Mukherjee 2015-03-03 856
81dee67e215b23 Sudip Mukherjee 2015-03-03 857 /* set info->fix */
81dee67e215b23 Sudip Mukherjee 2015-03-03 858 fix->type = FB_TYPE_PACKED_PIXELS;
81dee67e215b23 Sudip Mukherjee 2015-03-03 859 fix->type_aux = 0;
81dee67e215b23 Sudip Mukherjee 2015-03-03 860 fix->xpanstep = crtc->xpanstep;
81dee67e215b23 Sudip Mukherjee 2015-03-03 861 fix->ypanstep = crtc->ypanstep;
81dee67e215b23 Sudip Mukherjee 2015-03-03 862 fix->ywrapstep = crtc->ywrapstep;
81dee67e215b23 Sudip Mukherjee 2015-03-03 863 fix->accel = FB_ACCEL_SMI;
81dee67e215b23 Sudip Mukherjee 2015-03-03 864
8c475735085a7d Tim Wassink 2025-12-21 865 strscpy(fix->id, fix_id[index], sizeof(fix->id));
81dee67e215b23 Sudip Mukherjee 2015-03-03 866
fdc234d85210d9 Benjamin Philip 2021-07-28 867 fix->smem_start = crtc->o_screen + sm750_dev->vidmem_start;
81dee67e215b23 Sudip Mukherjee 2015-03-03 868 pr_info("fix->smem_start = %lx\n", fix->smem_start);
d11ac7cbcc266c Sudip Mukherjee 2015-08-07 869 /*
d11ac7cbcc266c Sudip Mukherjee 2015-08-07 870 * according to mmap experiment from user space application,
81dee67e215b23 Sudip Mukherjee 2015-03-03 871 * fix->mmio_len should not larger than virtual size
81dee67e215b23 Sudip Mukherjee 2015-03-03 872 * (xres_virtual x yres_virtual x ByPP)
81dee67e215b23 Sudip Mukherjee 2015-03-03 873 * Below line maybe buggy when user mmap fb dev node and write
81dee67e215b23 Sudip Mukherjee 2015-03-03 874 * data into the bound over virtual size
d11ac7cbcc266c Sudip Mukherjee 2015-08-07 875 */
81dee67e215b23 Sudip Mukherjee 2015-03-03 876 fix->smem_len = crtc->vidmem_size;
81dee67e215b23 Sudip Mukherjee 2015-03-03 877 pr_info("fix->smem_len = %x\n", fix->smem_len);
81dee67e215b23 Sudip Mukherjee 2015-03-03 878 info->screen_size = fix->smem_len;
81dee67e215b23 Sudip Mukherjee 2015-03-03 879 fix->line_length = line_length;
e359b6a863e19f Mike Rapoport 2015-10-26 880 fix->mmio_start = sm750_dev->vidreg_start;
81dee67e215b23 Sudip Mukherjee 2015-03-03 881 pr_info("fix->mmio_start = %lx\n", fix->mmio_start);
e359b6a863e19f Mike Rapoport 2015-10-26 882 fix->mmio_len = sm750_dev->vidreg_size;
81dee67e215b23 Sudip Mukherjee 2015-03-03 883 pr_info("fix->mmio_len = %x\n", fix->mmio_len);
b610e1193a917f Matej Dujava 2020-04-30 884
b610e1193a917f Matej Dujava 2020-04-30 885 lynxfb_set_visual_mode(info);
81dee67e215b23 Sudip Mukherjee 2015-03-03 886
81dee67e215b23 Sudip Mukherjee 2015-03-03 887 /* set var */
81dee67e215b23 Sudip Mukherjee 2015-03-03 888 var->activate = FB_ACTIVATE_NOW;
81dee67e215b23 Sudip Mukherjee 2015-03-03 889 var->accel_flags = 0;
81dee67e215b23 Sudip Mukherjee 2015-03-03 890 var->vmode = FB_VMODE_NONINTERLACED;
81dee67e215b23 Sudip Mukherjee 2015-03-03 891
81dee67e215b23 Sudip Mukherjee 2015-03-03 892 pr_debug("#1 show info->cmap :\nstart=%d,len=%d,red=%p,green=%p,blue=%p,transp=%p\n",
81dee67e215b23 Sudip Mukherjee 2015-03-03 893 info->cmap.start, info->cmap.len,
81dee67e215b23 Sudip Mukherjee 2015-03-03 894 info->cmap.red, info->cmap.green, info->cmap.blue,
81dee67e215b23 Sudip Mukherjee 2015-03-03 895 info->cmap.transp);
81dee67e215b23 Sudip Mukherjee 2015-03-03 896
61c507cf652da1 Michel von Czettritz 2015-03-26 897 ret = fb_alloc_cmap(&info->cmap, 256, 0);
61c507cf652da1 Michel von Czettritz 2015-03-26 898 if (ret < 0) {
008272072d61a8 Masanari Iida 2015-05-28 899 pr_err("Could not allocate memory for cmap.\n");
81dee67e215b23 Sudip Mukherjee 2015-03-03 900 goto exit;
81dee67e215b23 Sudip Mukherjee 2015-03-03 901 }
81dee67e215b23 Sudip Mukherjee 2015-03-03 902
81dee67e215b23 Sudip Mukherjee 2015-03-03 903 pr_debug("#2 show info->cmap :\nstart=%d,len=%d,red=%p,green=%p,blue=%p,transp=%p\n",
81dee67e215b23 Sudip Mukherjee 2015-03-03 904 info->cmap.start, info->cmap.len,
81dee67e215b23 Sudip Mukherjee 2015-03-03 905 info->cmap.red, info->cmap.green, info->cmap.blue,
81dee67e215b23 Sudip Mukherjee 2015-03-03 906 info->cmap.transp);
81dee67e215b23 Sudip Mukherjee 2015-03-03 907
81dee67e215b23 Sudip Mukherjee 2015-03-03 908 exit:
81dee67e215b23 Sudip Mukherjee 2015-03-03 909 lynxfb_ops_check_var(var, info);
81dee67e215b23 Sudip Mukherjee 2015-03-03 910 return ret;
81dee67e215b23 Sudip Mukherjee 2015-03-03 911 }
81dee67e215b23 Sudip Mukherjee 2015-03-03 912
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH RFC v6 05/26] nova-core: mm: Add support to use PRAMIN windows to write to VRAM
From: Christian König @ 2026-02-02 9:12 UTC (permalink / raw)
To: Dave Airlie, Joel Fernandes
Cc: John Hubbard, Danilo Krummrich, Zhi Wang, linux-kernel,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
Simona Vetter, Jonathan Corbet, Alex Deucher, Jani Nikula,
Joonas Lahtinen, Rodrigo Vivi, Tvrtko Ursulin, Rui Huang,
Matthew Auld, Matthew Brost, Lucas De Marchi, Thomas Hellstrom,
Helge Deller, Alice Ryhl, Miguel Ojeda, Alex Gaynor, Boqun Feng,
Gary Guo, Bjorn Roy Baron, Benno Lossin, Andreas Hindborg,
Trevor Gross, Alistair Popple, Timur Tabi, Edwin Peer,
Alexandre Courbot, Andrea Righi, Andy Ritger, Alexey Ivanov,
Balbir Singh, 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: <CAPM=9twm1x9rH==uoGQLYa8b4feQMz=Ne14WPuhCPy9_H1u5Tw@mail.gmail.com>
On 1/31/26 04:00, Dave Airlie wrote:
> On Sat, 31 Jan 2026 at 07:14, Joel Fernandes <joelagnelf@nvidia.com> wrote:
>>
>>
>>
>> On 1/29/2026 10:38 PM, John Hubbard wrote:
>>> On 1/29/26 5:59 PM, Joel Fernandes wrote:
>>>> On 1/29/26 8:12 PM, John Hubbard wrote:
>>>>> On 1/29/26 4:26 PM, Joel Fernandes wrote:
>>>>>> Based on the below discussion and research, I came up with some deadlock
>>>>>> scenarios that we need to handle in the v6 series of these patches.
>>>>>> [...]
>>>>>> memory allocations under locks that we need in the dma-fence signaling
>>>>>> critical path (when doing the virtual memory map/unmap)
>>>>>
>>>>> unmap? Are you seeing any allocations happening during unmap? I don't
>>>>> immediately see any, but that sounds surprising.
>>>>
>>>> Not allocations but we are acquiring locks during unmap. My understanding
>>>> is (at least some) unmaps have to also be done in the dma fence signaling
>>>> critical path (the run stage), but Danilo/you can correct me if I am wrong
>>>> on that. We cannot avoid all locking but those same locks cannot be held in
>>>> any other paths which do a memory allocation (as mentioned in one of the
>>>> deadlock scenarios), that is probably the main thing to check for unmap.
>>>>
>>>
>>> Right, OK we are on the same page now: no allocations happening on unmap,
>>> but it can still deadlock, because the driver is typically going to
>>> use a single lock to protect calls both map and unmap-related calls
>>> to the buddy allocator.
>>
>> Yes exactly!
>>
>>>
>>> For the deadlock above, I think a good way to break that deadlock is
>>> to not allow taking that lock in a fence signaling calling path.
>>>
>>> So during an unmap, instead of "lock, unmap/free, unlock" it should
>>> move the item to a deferred-free list, which is processed separately.
>>> Of course, this is a little complex, because the allocation and reclaim
>>> has to be aware of such lists if they get large.
>> Yes, also avoiding GFP_KERNEL allocations while holding any of these mm locks
>> (whichever we take during map). The GPU buddy actually does GFP_KERNEL
>> allocations internally which is problematic.
>>
>> Some solutions / next steps:
>>
>> 1. allocating (VRAM and system memory) outside mm locks just before acquiring them.
>>
>> 2. pre-allocating both VRAM and system memory needed, before the DMA fence
>> critical paths (The issue is also to figure out how much memory to pre-allocate
>> for the page table pages based on the VM_BIND request. I think we can analyze
>> the page tables in the submit stage to make an estimate).
>>
>> 3. Unfortunately, I am using gpu-buddy when allocating a VA range in the Vmm
>> (called virt_buddy), which itself does GFP_KERNEL memory allocations in the
>> allocate path. I am not sure what do yet about this. ISTR the maple tree also
>> has similar issues.
>>
>> 4. Using non-reclaimable memory allocations where pre-allocation or
>> pre-allocated memory pools is not possible (I'd like to avoid this #4 so we
>> don't fail allocations when memory is scarce).
>>
>> Will work on these issues for the v7. Thanks,
>
> The way this works on nouveau at least (and I haven't yet read the
> nova code in depth).
>
> Is we have 4 stages of vmm page table mgmt.
>
> ref - locked with a ref lock - can allocate/free memory - just makes
> sure the page tables exist and are reference counted
> map - locked with a map lock - cannot allocate memory - fill in the
> PTEs in the page table
> unmap - locked with a map lock - cannot allocate memory - removes
> entries in PTEs
> unref - locked with a ref lock - can allocate/free memory - just drops
> references and frees (not sure if it ever merges).
On amdgpu VM page tables are allocated and PTEs filled outside of the fence critical path.
Only invalidating PTEs to signal that a shader needs to be taken off the HW are inside the fence critical path and here no memory allocation is needed.
Keep in mind that you not only need to avoid having memory allocations inside the critical path, but also not take locks under which memory is allocated.
Simona added some dma_fence_begin_signalling() and dma_fence_end_signalling() helpers to add lockdep annotations to the fence signaling path. Those have proven to be extremely useful since they allow lockdep to point out mistakes immediately and not just after hours of running on a test system.
Regards,
Christian.
>
> So maps and unmaps can be in fence signalling paths, but unrefs are
> done in free job from a workqueue.
>
> Dave.
>>
>> --
>> Joel Fernandes
>>
^ permalink raw reply
* Re: [PATCH] backlight: sky81452-backlight: Check return value of devm_gpiod_get_optional() in sky81452_bl_parse_dt()
From: Daniel Thompson @ 2026-02-02 9:54 UTC (permalink / raw)
To: Chen Ni
Cc: lee, danielt, jingoohan1, deller, linusw, dri-devel, linux-fbdev,
linux-kernel
In-Reply-To: <20260202075410.155375-1-nichen@iscas.ac.cn>
On Mon, Feb 02, 2026 at 03:54:10PM +0800, Chen Ni wrote:
> The devm_gpiod_get_optional() function may return an ERR_PTR in case of
> genuine GPIO acquisition errors, not just NULL which indicates the
> legitimate absence of an optional GPIO.
>
> Add an IS_ERR() check after the call in sky81452_bl_parse_dt(). On
> error, return the error code to ensure proper failure handling rather
> than proceeding with invalid pointers.
>
> Fixes: e1915eec54a6 ("backlight: sky81452: Convert to GPIO descriptors")
> Signed-off-by: Chen Ni <nichen@iscas.ac.cn>
> ---
> drivers/video/backlight/sky81452-backlight.c | 4 ++++
> 1 file changed, 4 insertions(+)
Thanks for the fix.
Small review comment below:
> diff --git a/drivers/video/backlight/sky81452-backlight.c b/drivers/video/backlight/sky81452-backlight.c
> index 2749231f0385..e3e5306fab84 100644
> --- a/drivers/video/backlight/sky81452-backlight.c
> +++ b/drivers/video/backlight/sky81452-backlight.c
> @@ -202,6 +202,10 @@ static struct sky81452_bl_platform_data *sky81452_bl_parse_dt(
> pdata->dpwm_mode = of_property_read_bool(np, "skyworks,dpwm-mode");
> pdata->phase_shift = of_property_read_bool(np, "skyworks,phase-shift");
> pdata->gpiod_enable = devm_gpiod_get_optional(dev, NULL, GPIOD_OUT_HIGH);
> + if (IS_ERR(pdata->gpiod_enable)) {
> + dev_err(dev, "failed to get gpio\n");
> + return ERR_CAST(pdata->gpiod_enable);
> + }
Using dev_err_cast_probe() would make this change more compact and give
a better error message for the user.
>
> ret = of_property_count_u32_elems(np, "led-sources");
> if (ret < 0) {
Daniel.
^ permalink raw reply
* [PATCH] staging: fbtft: fix dev_info() device arguments
From: Arnd Bergmann @ 2026-02-02 9:57 UTC (permalink / raw)
To: Andy Shevchenko, Greg Kroah-Hartman, Thomas Petazzoni,
Noralf Tronnes, Helge Deller, Thomas Zimmermann, Chintan Patel
Cc: Arnd Bergmann, Abdun Nihaal, Dan Carpenter,
Matthew Wilcox (Oracle), Jianglei Nie, dri-devel, linux-fbdev,
linux-staging, linux-kernel
From: Arnd Bergmann <arnd@arndb.de>
When CONFIG_FB_DEVICE is disabled, the fbtft driver fails to
build with:
In file included from include/linux/device.h:15,
from drivers/staging/fbtft/fbtft-core.c:18:
drivers/staging/fbtft/fbtft-core.c: In function 'fbtft_fb_setcolreg':
drivers/staging/fbtft/fbtft-core.c:368:21: error: 'struct fb_info' has no member named 'dev'
368 | dev_dbg(info->dev,
drivers/staging/fbtft/fbtft-core.c:394:21: error: 'struct fb_info' has no member named 'dev'
394 | dev_dbg(info->dev, "%s(blank=%d)\n",
drivers/staging/fbtft/fbtft-core.c:796:25: error: 'struct fb_info' has no member named 'dev'
796 | dev_info(fb_info->dev,
drivers/staging/fbtft/fbtft-core.c:796:9: note: in expansion of macro 'dev_info'
796 | dev_info(fb_info->dev,
Use fb_info->device instead of fb_info->dev here, which appears
to be what was intended in the first place.
Fixes: c296d5f9957c ("staging: fbtft: core support")
Fixes: bc9f9cb85a7d ("staging: fbtft: Make FB_DEVICE dependency optional")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
drivers/staging/fbtft/fbtft-core.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/fbtft/fbtft-core.c b/drivers/staging/fbtft/fbtft-core.c
index 15affe6f1537..41326b1df733 100644
--- a/drivers/staging/fbtft/fbtft-core.c
+++ b/drivers/staging/fbtft/fbtft-core.c
@@ -365,7 +365,7 @@ static int fbtft_fb_setcolreg(unsigned int regno, unsigned int red,
unsigned int val;
int ret = 1;
- dev_dbg(info->dev,
+ dev_dbg(info->device,
"%s(regno=%u, red=0x%X, green=0x%X, blue=0x%X, trans=0x%X)\n",
__func__, regno, red, green, blue, transp);
@@ -391,7 +391,7 @@ static int fbtft_fb_blank(int blank, struct fb_info *info)
struct fbtft_par *par = info->par;
int ret = -EINVAL;
- dev_dbg(info->dev, "%s(blank=%d)\n",
+ dev_dbg(info->device, "%s(blank=%d)\n",
__func__, blank);
if (!par->fbtftops.blank)
@@ -793,7 +793,7 @@ int fbtft_register_framebuffer(struct fb_info *fb_info)
if (spi)
sprintf(text2, ", spi%d.%d at %d MHz", spi->controller->bus_num,
spi_get_chipselect(spi, 0), spi->max_speed_hz / 1000000);
- dev_info(fb_info->dev,
+ dev_info(fb_info->device,
"%s frame buffer, %dx%d, %d KiB video memory%s, fps=%lu%s\n",
fb_info->fix.id, fb_info->var.xres, fb_info->var.yres,
fb_info->fix.smem_len >> 10, text1,
--
2.39.5
^ permalink raw reply related
* Re: [PATCH v2 1/2] dt-bindings: backlight: gpio-backlight: allow multiple GPIOs
From: Daniel Thompson @ 2026-02-02 10:28 UTC (permalink / raw)
To: tessolveupstream
Cc: Krzysztof Kozlowski, lee, danielt, jingoohan1, deller, pavel,
robh, krzk+dt, conor+dt, dri-devel, linux-fbdev, linux-leds,
devicetree, linux-kernel
In-Reply-To: <304ef935-e82b-4556-be3c-6ec4f57cf68c@gmail.com>
On Thu, Jan 29, 2026 at 11:11:34AM +0530, tessolveupstream@gmail.com wrote:
> On 28-01-2026 16:50, Daniel Thompson wrote:
> > On Wed, Jan 28, 2026 at 11:11:33AM +0100, Krzysztof Kozlowski wrote:
> >> On 23/01/2026 12:11, tessolveupstream@gmail.com wrote:
> >>>
> >>>
> >>> On 20-01-2026 20:01, Krzysztof Kozlowski wrote:
> >>>> On 20/01/2026 13:50, Sudarshan Shetty wrote:
> >>>>> Update the gpio-backlight binding to support configurations that require
> >>>>> more than one GPIO for enabling/disabling the backlight.
> >>>>
> >>>>
> >>>> Why? Which devices need it? How a backlight would have three enable
> >>>> GPIOs? I really do not believe, so you need to write proper hardware
> >>>> justification.
> >>>>
> >>>
> >>> To clarify our hardware setup:
> >>> the panel requires one GPIO for the backlight enable signal, and it
> >>> also has a PWM input. Since the QCS615 does not provide a PWM controller
> >>> for this use case, the PWM input is connected to a GPIO that is driven
> >>> high to provide a constant 100% duty cycle, as explained in the link
> >>> below.
> >>> https://lore.kernel.org/all/20251028061636.724667-1-tessolveupstream@gmail.com/T/#m93ca4e5c7bf055715ed13316d91f0cd544244cf5
> >>
> >> That's not an enable gpio, but PWM.
> >>
> >> You write bindings for this device, not for something else - like your
> >> board.
> >
> > Sudarshan: I believe at one point the intent was to model this hardware
> > as a pwm-backlight (using enables GPIOs to drive the enable pin)
> > attached to a pwm-gpio (to drive the PWM pin). Did this approach work?
> >
>
> Yes, the original plan was to model this using pwm‑gpio, and that
> setup worked. But on the SOC there’s no actual PWM controller available
> for this path— the LED_PWM line is just tied to a GPIO that’s driven
> high (effectively a fixed 100% duty cycle). Because of that, describing
> it as a PWM in DT was flagged as incorrect.
>
> As pointed out during the SoC DTS review, the correct path forward is
> to extend gpio‑backlight to handle multiple GPIOs, rather than
> representing them as multiple separate backlight devices.
That not quite what I got from the link above. There is a suggestion to
use gpio-backlight, but the reason it was flagged is because pwm-gpio
was unused... it was not referenced by a pwm-backlight.
Having said that I suspect it is better to model this backlight controller
on this board as a gpio-backlight because from a backlight controller
point of this that is physically what the controller is composed of
(assuming there is not sufficient capacitance on the signal for a
software PWM to work at anything other than 0% and 100%). Even if those
GPIO signals are connected to the panel's PWM input I'm not sure that's
relevant because none of the backlight controller bindings model the
panel anyway.
Whatever route you select, you do need to make it clear in the patch
description *why* it is correct to model the system as a gpio-backlight.
Deferring to (potentially ambiguous) review comments is not sufficient
to explain why changing the gpio-backlight bindings are an improvement.
Daniel.
^ permalink raw reply
* Re: [PATCH] staging: fbtft: fix dev_info() device arguments
From: Thomas Zimmermann @ 2026-02-02 11:32 UTC (permalink / raw)
To: Arnd Bergmann, Andy Shevchenko, Greg Kroah-Hartman,
Thomas Petazzoni, Noralf Tronnes, Helge Deller, Chintan Patel
Cc: Arnd Bergmann, Abdun Nihaal, Dan Carpenter,
Matthew Wilcox (Oracle), Jianglei Nie, dri-devel, linux-fbdev,
linux-staging, linux-kernel
In-Reply-To: <20260202095743.1309162-1-arnd@kernel.org>
Hi,
there's already
https://patchwork.freedesktop.org/series/160468/
which no one picked up yet. This needs to go into the fbdev tree, but I
can also take into drm-misc-fixes.
Am 02.02.26 um 10:57 schrieb Arnd Bergmann:
> From: Arnd Bergmann <arnd@arndb.de>
>
> When CONFIG_FB_DEVICE is disabled, the fbtft driver fails to
> build with:
>
> In file included from include/linux/device.h:15,
> from drivers/staging/fbtft/fbtft-core.c:18:
> drivers/staging/fbtft/fbtft-core.c: In function 'fbtft_fb_setcolreg':
> drivers/staging/fbtft/fbtft-core.c:368:21: error: 'struct fb_info' has no member named 'dev'
> 368 | dev_dbg(info->dev,
> drivers/staging/fbtft/fbtft-core.c:394:21: error: 'struct fb_info' has no member named 'dev'
> 394 | dev_dbg(info->dev, "%s(blank=%d)\n",
> drivers/staging/fbtft/fbtft-core.c:796:25: error: 'struct fb_info' has no member named 'dev'
> 796 | dev_info(fb_info->dev,
> drivers/staging/fbtft/fbtft-core.c:796:9: note: in expansion of macro 'dev_info'
> 796 | dev_info(fb_info->dev,
>
> Use fb_info->device instead of fb_info->dev here, which appears
> to be what was intended in the first place.
>
> Fixes: c296d5f9957c ("staging: fbtft: core support")
> Fixes: bc9f9cb85a7d ("staging: fbtft: Make FB_DEVICE dependency optional")
These commit hashes differ from the other fix?
Best regards
Thomas
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> drivers/staging/fbtft/fbtft-core.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/staging/fbtft/fbtft-core.c b/drivers/staging/fbtft/fbtft-core.c
> index 15affe6f1537..41326b1df733 100644
> --- a/drivers/staging/fbtft/fbtft-core.c
> +++ b/drivers/staging/fbtft/fbtft-core.c
> @@ -365,7 +365,7 @@ static int fbtft_fb_setcolreg(unsigned int regno, unsigned int red,
> unsigned int val;
> int ret = 1;
>
> - dev_dbg(info->dev,
> + dev_dbg(info->device,
> "%s(regno=%u, red=0x%X, green=0x%X, blue=0x%X, trans=0x%X)\n",
> __func__, regno, red, green, blue, transp);
>
> @@ -391,7 +391,7 @@ static int fbtft_fb_blank(int blank, struct fb_info *info)
> struct fbtft_par *par = info->par;
> int ret = -EINVAL;
>
> - dev_dbg(info->dev, "%s(blank=%d)\n",
> + dev_dbg(info->device, "%s(blank=%d)\n",
> __func__, blank);
>
> if (!par->fbtftops.blank)
> @@ -793,7 +793,7 @@ int fbtft_register_framebuffer(struct fb_info *fb_info)
> if (spi)
> sprintf(text2, ", spi%d.%d at %d MHz", spi->controller->bus_num,
> spi_get_chipselect(spi, 0), spi->max_speed_hz / 1000000);
> - dev_info(fb_info->dev,
> + dev_info(fb_info->device,
> "%s frame buffer, %dx%d, %d KiB video memory%s, fps=%lu%s\n",
> fb_info->fix.id, fb_info->var.xres, fb_info->var.yres,
> fb_info->fix.smem_len >> 10, text1,
--
--
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] staging: fbtft: fix dev_info() device arguments
From: Arnd Bergmann @ 2026-02-02 12:12 UTC (permalink / raw)
To: Thomas Zimmermann, Arnd Bergmann, Andy Shevchenko,
Greg Kroah-Hartman, Thomas Petazzoni, Noralf Tronnes,
Helge Deller, Chintan Patel
Cc: Abdun Nihaal, Dan Carpenter, Matthew Wilcox, Jianglei Nie,
dri-devel, linux-fbdev, linux-staging, linux-kernel
In-Reply-To: <6580aa60-5f9d-49c7-8482-83bed12dfb0c@suse.de>
On Mon, Feb 2, 2026, at 12:32, Thomas Zimmermann wrote:
> Hi,
>
> there's already
>
> https://patchwork.freedesktop.org/series/160468/
>
> which no one picked up yet. This needs to go into the fbdev tree, but I
> can also take into drm-misc-fixes.
Ok, that looks fine as well. The output is of course
different, but I don't think that matters either way.
> Am 02.02.26 um 10:57 schrieb Arnd Bergmann:
>> From: Arnd Bergmann <arnd@arndb.de>
>>
>> Fixes: c296d5f9957c ("staging: fbtft: core support")
>> Fixes: bc9f9cb85a7d ("staging: fbtft: Make FB_DEVICE dependency optional")
>
> These commit hashes differ from the other fix?
No idea. The bc9f9cb85a7d commit is currently in linux-next,
the a06d03f9f238 is not.
Arnd
^ permalink raw reply
* Re: [PATCH] staging: fbtft: fix dev_info() device arguments
From: Helge Deller @ 2026-02-02 13:11 UTC (permalink / raw)
To: Arnd Bergmann, Thomas Zimmermann, Andy Shevchenko,
Greg Kroah-Hartman, Thomas Petazzoni, Noralf Tronnes,
Chintan Patel
Cc: Abdun Nihaal, Dan Carpenter, Matthew Wilcox, Jianglei Nie,
dri-devel, linux-fbdev, linux-staging, linux-kernel
In-Reply-To: <3384db41-0ddb-4c00-9af1-f194ec5dccc4@app.fastmail.com>
On 2/2/26 13:12, Arnd Bergmann wrote:
> On Mon, Feb 2, 2026, at 12:32, Thomas Zimmermann wrote:
>> Hi,
>>
>> there's already
>>
>> https://patchwork.freedesktop.org/series/160468/
>>
>> which no one picked up yet. This needs to go into the fbdev tree, but I
>> can also take into drm-misc-fixes.
>
> Ok, that looks fine as well. The output is of course
> different, but I don't think that matters either way.
I picked it up into fbdev now.
There might have been some conflicts with staging tree, which I haven't
done so earlier. Let's see...
Helge
^ permalink raw reply
* Re: [PATCH] staging: fbtft: fix dev_info() device arguments
From: Thomas Zimmermann @ 2026-02-02 13:29 UTC (permalink / raw)
To: Helge Deller, Arnd Bergmann, Andy Shevchenko, Greg Kroah-Hartman,
Thomas Petazzoni, Noralf Tronnes, Chintan Patel
Cc: Abdun Nihaal, Dan Carpenter, Matthew Wilcox, Jianglei Nie,
dri-devel, linux-fbdev, linux-staging, linux-kernel
In-Reply-To: <9de86cc9-a72a-4f84-9cc6-127fc0dbe006@gmx.de>
Hi
Am 02.02.26 um 14:11 schrieb Helge Deller:
> On 2/2/26 13:12, Arnd Bergmann wrote:
>> On Mon, Feb 2, 2026, at 12:32, Thomas Zimmermann wrote:
>>> Hi,
>>>
>>> there's already
>>>
>>> https://patchwork.freedesktop.org/series/160468/
>>>
>>> which no one picked up yet. This needs to go into the fbdev tree, but I
>>> can also take into drm-misc-fixes.
>>
>> Ok, that looks fine as well. The output is of course
>> different, but I don't think that matters either way.
>
> I picked it up into fbdev now.
Thanks a lot!
Best regards
Thomas
> There might have been some conflicts with staging tree, which I haven't
> done so earlier. Let's see...
>
> Helge
--
--
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
* [PATCH] staging: sm750fb: rename Bpp to bpp
From: yehudis9982 @ 2026-02-02 14:54 UTC (permalink / raw)
To: sudipm.mukherjee, teddy.wang, gregkh
Cc: linux-fbdev, linux-staging, linux-kernel, yehudis9982
Rename the Bpp parameter to bpp to avoid CamelCase, as reported by
checkpatch.pl.
Signed-off-by: yehudis9982 <y0533159982@gmail.com>
---
drivers/staging/sm750fb/sm750_accel.c | 22 +++++++++++-----------
1 file changed, 11 insertions(+), 11 deletions(-)
diff --git a/drivers/staging/sm750fb/sm750_accel.c b/drivers/staging/sm750fb/sm750_accel.c
index 046b9282b..866b12c2a 100644
--- a/drivers/staging/sm750fb/sm750_accel.c
+++ b/drivers/staging/sm750fb/sm750_accel.c
@@ -85,7 +85,7 @@ void sm750_hw_set2dformat(struct lynx_accel *accel, int fmt)
}
int sm750_hw_fillrect(struct lynx_accel *accel,
- u32 base, u32 pitch, u32 Bpp,
+ u32 base, u32 pitch, u32 bpp,
u32 x, u32 y, u32 width, u32 height,
u32 color, u32 rop)
{
@@ -102,14 +102,14 @@ int sm750_hw_fillrect(struct lynx_accel *accel,
write_dpr(accel, DE_WINDOW_DESTINATION_BASE, base); /* dpr40 */
write_dpr(accel, DE_PITCH,
- ((pitch / Bpp << DE_PITCH_DESTINATION_SHIFT) &
+ ((pitch / bpp << DE_PITCH_DESTINATION_SHIFT) &
DE_PITCH_DESTINATION_MASK) |
- (pitch / Bpp & DE_PITCH_SOURCE_MASK)); /* dpr10 */
+ (pitch / bpp & DE_PITCH_SOURCE_MASK)); /* dpr10 */
write_dpr(accel, DE_WINDOW_WIDTH,
- ((pitch / Bpp << DE_WINDOW_WIDTH_DST_SHIFT) &
+ ((pitch / bpp << DE_WINDOW_WIDTH_DST_SHIFT) &
DE_WINDOW_WIDTH_DST_MASK) |
- (pitch / Bpp & DE_WINDOW_WIDTH_SRC_MASK)); /* dpr44 */
+ (pitch / bpp & DE_WINDOW_WIDTH_SRC_MASK)); /* dpr44 */
write_dpr(accel, DE_FOREGROUND, color); /* DPR14 */
@@ -138,7 +138,7 @@ int sm750_hw_fillrect(struct lynx_accel *accel,
* @sy: Starting y coordinate of source surface
* @dBase: Address of destination: offset in frame buffer
* @dPitch: Pitch value of destination surface in BYTE
- * @Bpp: Color depth of destination surface
+ * @bpp: Color depth of destination surface
* @dx: Starting x coordinate of destination surface
* @dy: Starting y coordinate of destination surface
* @width: width of rectangle in pixel value
@@ -149,7 +149,7 @@ int sm750_hw_copyarea(struct lynx_accel *accel,
unsigned int sBase, unsigned int sPitch,
unsigned int sx, unsigned int sy,
unsigned int dBase, unsigned int dPitch,
- unsigned int Bpp, unsigned int dx, unsigned int dy,
+ unsigned int bpp, unsigned int dx, unsigned int dy,
unsigned int width, unsigned int height,
unsigned int rop2)
{
@@ -249,9 +249,9 @@ int sm750_hw_copyarea(struct lynx_accel *accel,
* pixel values. Need Byte to pixel conversion.
*/
write_dpr(accel, DE_PITCH,
- ((dPitch / Bpp << DE_PITCH_DESTINATION_SHIFT) &
+ ((dPitch / bpp << DE_PITCH_DESTINATION_SHIFT) &
DE_PITCH_DESTINATION_MASK) |
- (sPitch / Bpp & DE_PITCH_SOURCE_MASK)); /* dpr10 */
+ (sPitch / bpp & DE_PITCH_SOURCE_MASK)); /* dpr10 */
/*
* Screen Window width in Pixels.
@@ -259,9 +259,9 @@ int sm750_hw_copyarea(struct lynx_accel *accel,
* for a given point.
*/
write_dpr(accel, DE_WINDOW_WIDTH,
- ((dPitch / Bpp << DE_WINDOW_WIDTH_DST_SHIFT) &
+ ((dPitch / bpp << DE_WINDOW_WIDTH_DST_SHIFT) &
DE_WINDOW_WIDTH_DST_MASK) |
- (sPitch / Bpp & DE_WINDOW_WIDTH_SRC_MASK)); /* dpr3c */
+ (sPitch / bpp & DE_WINDOW_WIDTH_SRC_MASK)); /* dpr3c */
if (accel->de_wait() != 0)
return -1;
--
2.43.0
^ permalink raw reply related
* Re: [PATCH] staging: sm750fb: rename Bpp to bpp
From: Greg KH @ 2026-02-02 15:01 UTC (permalink / raw)
To: yehudis9982
Cc: sudipm.mukherjee, teddy.wang, linux-fbdev, linux-staging,
linux-kernel
In-Reply-To: <20260202145413.132435-1-y0533159982@gmail.com>
On Mon, Feb 02, 2026 at 04:54:13PM +0200, yehudis9982 wrote:
> Rename the Bpp parameter to bpp to avoid CamelCase, as reported by
> checkpatch.pl.
>
> Signed-off-by: yehudis9982 <y0533159982@gmail.com>
> ---
> drivers/staging/sm750fb/sm750_accel.c | 22 +++++++++++-----------
> 1 file changed, 11 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/staging/sm750fb/sm750_accel.c b/drivers/staging/sm750fb/sm750_accel.c
> index 046b9282b..866b12c2a 100644
> --- a/drivers/staging/sm750fb/sm750_accel.c
> +++ b/drivers/staging/sm750fb/sm750_accel.c
> @@ -85,7 +85,7 @@ void sm750_hw_set2dformat(struct lynx_accel *accel, int fmt)
> }
>
> int sm750_hw_fillrect(struct lynx_accel *accel,
> - u32 base, u32 pitch, u32 Bpp,
> + u32 base, u32 pitch, u32 bpp,
What does "bpp" stand for? Perhaps spell it out further?
thanks,
greg k-h
^ permalink raw reply
* [PATCH] staging: fbtft: fix macro flow control warning and empty macro argument in fbtft-bus.c
From: KrishnaAgarwal1308 @ 2026-02-02 16:28 UTC (permalink / raw)
To: Andy Shevchenko, Greg Kroah-Hartman
Cc: dri-devel, linux-fbdev, linux-staging, linux-kernel,
KrishnaAgarwal1308
Fix checkpatch warning by adding identity modifier for define_fbtft_write_reg().
No functional change.
Signed-off-by: KrishnaAgarwal1308 <krishnaworkemail1308@gmail.com>
---
drivers/staging/fbtft/fbtft-bus.c | 36 +++++++++++++++----------------
1 file changed, 18 insertions(+), 18 deletions(-)
diff --git a/drivers/staging/fbtft/fbtft-bus.c b/drivers/staging/fbtft/fbtft-bus.c
index 30e436ff19e4..0ab4f5c4f886 100644
--- a/drivers/staging/fbtft/fbtft-bus.c
+++ b/drivers/staging/fbtft/fbtft-bus.c
@@ -10,6 +10,7 @@
* void (*write_reg)(struct fbtft_par *par, int len, ...);
*
*****************************************************************************/
+#define fbtft_identity(x) (x)
#define define_fbtft_write_reg(func, buffer_type, data_type, modifier) \
void func(struct fbtft_par *par, int len, ...) \
@@ -42,29 +43,28 @@ void func(struct fbtft_par *par, int len, ...) \
*buf = modifier((data_type)va_arg(args, unsigned int)); \
ret = fbtft_write_buf_dc(par, par->buf, sizeof(data_type) + offset, \
0); \
- if (ret < 0) \
- goto out; \
- len--; \
- \
- if (par->startbyte) \
- *(u8 *)par->buf = par->startbyte | 0x2; \
- \
- if (len) { \
- i = len; \
- while (i--) \
- *buf++ = modifier((data_type)va_arg(args, \
- unsigned int)); \
- fbtft_write_buf_dc(par, par->buf, \
- len * (sizeof(data_type) + offset), 1); \
- } \
-out: \
+ if (ret >= 0) { \
+ len--; \
+ \
+ if (par->startbyte) \
+ *(u8 *)par->buf = par->startbyte | 0x2; \
+ \
+ if (len) { \
+ i = len; \
+ while (i--) \
+ *buf++ = modifier((data_type)va_arg(args, \
+ unsigned int)); \
+ fbtft_write_buf_dc(par, par->buf, \
+ len * (sizeof(data_type) + offset), 1); \
+ } \
+ } \
va_end(args); \
} \
EXPORT_SYMBOL(func);
-define_fbtft_write_reg(fbtft_write_reg8_bus8, u8, u8, )
+define_fbtft_write_reg(fbtft_write_reg8_bus8, u8, u8, fbtft_identity)
define_fbtft_write_reg(fbtft_write_reg16_bus8, __be16, u16, cpu_to_be16)
-define_fbtft_write_reg(fbtft_write_reg16_bus16, u16, u16, )
+define_fbtft_write_reg(fbtft_write_reg16_bus16, u16, u16, fbtft_identity)
void fbtft_write_reg8_bus9(struct fbtft_par *par, int len, ...)
{
--
2.43.0
^ permalink raw reply related
* [PATCH v2] staging: sm750fb: rename Bpp to bytes_per_pixel
From: yehudis9982 @ 2026-02-02 16:46 UTC (permalink / raw)
To: sudipm.mukherjee, teddy.wang, gregkh
Cc: linux-fbdev, linux-staging, linux-kernel, yehudis9982
In-Reply-To: <20260202145413.132435-1-y0533159982@gmail.com>
Rename the Bpp parameter to bytes_per_pixel for clarity and to avoid CamelCase, as reported by checkpatch.pl.
Signed-off-by: yehudis9982 <y0533159982@gmail.com>
---
drivers/staging/sm750fb/sm750_accel.c | 26 +++++++++++++-------------
1 file changed, 13 insertions(+), 13 deletions(-)
diff --git a/drivers/staging/sm750fb/sm750_accel.c b/drivers/staging/sm750fb/sm750_accel.c
index 046b9282b..3fe9429e1 100644
--- a/drivers/staging/sm750fb/sm750_accel.c
+++ b/drivers/staging/sm750fb/sm750_accel.c
@@ -48,7 +48,7 @@ void sm750_hw_de_init(struct lynx_accel *accel)
DE_STRETCH_FORMAT_ADDRESSING_MASK |
DE_STRETCH_FORMAT_SOURCE_HEIGHT_MASK;
- /* DE_STRETCH bpp format need be initialized in setMode routine */
+ /* DE_STRETCH bytes_per_pixel format need be initialized in setMode routine */
write_dpr(accel, DE_STRETCH_FORMAT,
(read_dpr(accel, DE_STRETCH_FORMAT) & ~clr) | reg);
@@ -76,7 +76,7 @@ void sm750_hw_set2dformat(struct lynx_accel *accel, int fmt)
{
u32 reg;
- /* fmt=0,1,2 for 8,16,32,bpp on sm718/750/502 */
+ /* fmt=0,1,2 for 8,16,32,bytes_per_pixel on sm718/750/502 */
reg = read_dpr(accel, DE_STRETCH_FORMAT);
reg &= ~DE_STRETCH_FORMAT_PIXEL_FORMAT_MASK;
reg |= ((fmt << DE_STRETCH_FORMAT_PIXEL_FORMAT_SHIFT) &
@@ -85,7 +85,7 @@ void sm750_hw_set2dformat(struct lynx_accel *accel, int fmt)
}
int sm750_hw_fillrect(struct lynx_accel *accel,
- u32 base, u32 pitch, u32 Bpp,
+ u32 base, u32 pitch, u32 bytes_per_pixel,
u32 x, u32 y, u32 width, u32 height,
u32 color, u32 rop)
{
@@ -102,14 +102,14 @@ int sm750_hw_fillrect(struct lynx_accel *accel,
write_dpr(accel, DE_WINDOW_DESTINATION_BASE, base); /* dpr40 */
write_dpr(accel, DE_PITCH,
- ((pitch / Bpp << DE_PITCH_DESTINATION_SHIFT) &
+ ((pitch / bytes_per_pixel << DE_PITCH_DESTINATION_SHIFT) &
DE_PITCH_DESTINATION_MASK) |
- (pitch / Bpp & DE_PITCH_SOURCE_MASK)); /* dpr10 */
+ (pitch / bytes_per_pixel & DE_PITCH_SOURCE_MASK)); /* dpr10 */
write_dpr(accel, DE_WINDOW_WIDTH,
- ((pitch / Bpp << DE_WINDOW_WIDTH_DST_SHIFT) &
+ ((pitch / bytes_per_pixel << DE_WINDOW_WIDTH_DST_SHIFT) &
DE_WINDOW_WIDTH_DST_MASK) |
- (pitch / Bpp & DE_WINDOW_WIDTH_SRC_MASK)); /* dpr44 */
+ (pitch / bytes_per_pixel & DE_WINDOW_WIDTH_SRC_MASK)); /* dpr44 */
write_dpr(accel, DE_FOREGROUND, color); /* DPR14 */
@@ -138,7 +138,7 @@ int sm750_hw_fillrect(struct lynx_accel *accel,
* @sy: Starting y coordinate of source surface
* @dBase: Address of destination: offset in frame buffer
* @dPitch: Pitch value of destination surface in BYTE
- * @Bpp: Color depth of destination surface
+ * @bytes_per_pixel: Bytes per pixel (color depth / 8) of destination surface
* @dx: Starting x coordinate of destination surface
* @dy: Starting y coordinate of destination surface
* @width: width of rectangle in pixel value
@@ -149,7 +149,7 @@ int sm750_hw_copyarea(struct lynx_accel *accel,
unsigned int sBase, unsigned int sPitch,
unsigned int sx, unsigned int sy,
unsigned int dBase, unsigned int dPitch,
- unsigned int Bpp, unsigned int dx, unsigned int dy,
+ unsigned int bytes_per_pixel, unsigned int dx, unsigned int dy,
unsigned int width, unsigned int height,
unsigned int rop2)
{
@@ -249,9 +249,9 @@ int sm750_hw_copyarea(struct lynx_accel *accel,
* pixel values. Need Byte to pixel conversion.
*/
write_dpr(accel, DE_PITCH,
- ((dPitch / Bpp << DE_PITCH_DESTINATION_SHIFT) &
+ ((dPitch / bytes_per_pixel << DE_PITCH_DESTINATION_SHIFT) &
DE_PITCH_DESTINATION_MASK) |
- (sPitch / Bpp & DE_PITCH_SOURCE_MASK)); /* dpr10 */
+ (sPitch / bytes_per_pixel & DE_PITCH_SOURCE_MASK)); /* dpr10 */
/*
* Screen Window width in Pixels.
@@ -259,9 +259,9 @@ int sm750_hw_copyarea(struct lynx_accel *accel,
* for a given point.
*/
write_dpr(accel, DE_WINDOW_WIDTH,
- ((dPitch / Bpp << DE_WINDOW_WIDTH_DST_SHIFT) &
+ ((dPitch / bytes_per_pixel << DE_WINDOW_WIDTH_DST_SHIFT) &
DE_WINDOW_WIDTH_DST_MASK) |
- (sPitch / Bpp & DE_WINDOW_WIDTH_SRC_MASK)); /* dpr3c */
+ (sPitch / bytes_per_pixel & DE_WINDOW_WIDTH_SRC_MASK)); /* dpr3c */
if (accel->de_wait() != 0)
return -1;
--
2.43.0
^ permalink raw reply related
* [PATCH v2] staging: sm750fb: rename Bpp to bytes_per_pixel
From: yehudis9982 @ 2026-02-02 16:57 UTC (permalink / raw)
To: sudipm.mukherjee, teddy.wang, gregkh
Cc: linux-fbdev, linux-staging, linux-kernel, yehudis9982
In-Reply-To: <20260202145413.132435-1-y0533159982@gmail.com>
Rename the Bpp parameter to bytes_per_pixel for clarity and to avoid CamelCase, as reported by checkpatch.pl.
Signed-off-by: yehudis9982 <y0533159982@gmail.com>
---
drivers/staging/sm750fb/sm750_accel.c | 26 +++++++++++++-------------
1 file changed, 13 insertions(+), 13 deletions(-)
diff --git a/drivers/staging/sm750fb/sm750_accel.c b/drivers/staging/sm750fb/sm750_accel.c
index 046b9282b..3fe9429e1 100644
--- a/drivers/staging/sm750fb/sm750_accel.c
+++ b/drivers/staging/sm750fb/sm750_accel.c
@@ -48,7 +48,7 @@ void sm750_hw_de_init(struct lynx_accel *accel)
DE_STRETCH_FORMAT_ADDRESSING_MASK |
DE_STRETCH_FORMAT_SOURCE_HEIGHT_MASK;
- /* DE_STRETCH bpp format need be initialized in setMode routine */
+ /* DE_STRETCH bytes_per_pixel format need be initialized in setMode routine */
write_dpr(accel, DE_STRETCH_FORMAT,
(read_dpr(accel, DE_STRETCH_FORMAT) & ~clr) | reg);
@@ -76,7 +76,7 @@ void sm750_hw_set2dformat(struct lynx_accel *accel, int fmt)
{
u32 reg;
- /* fmt=0,1,2 for 8,16,32,bpp on sm718/750/502 */
+ /* fmt=0,1,2 for 8,16,32,bytes_per_pixel on sm718/750/502 */
reg = read_dpr(accel, DE_STRETCH_FORMAT);
reg &= ~DE_STRETCH_FORMAT_PIXEL_FORMAT_MASK;
reg |= ((fmt << DE_STRETCH_FORMAT_PIXEL_FORMAT_SHIFT) &
@@ -85,7 +85,7 @@ void sm750_hw_set2dformat(struct lynx_accel *accel, int fmt)
}
int sm750_hw_fillrect(struct lynx_accel *accel,
- u32 base, u32 pitch, u32 Bpp,
+ u32 base, u32 pitch, u32 bytes_per_pixel,
u32 x, u32 y, u32 width, u32 height,
u32 color, u32 rop)
{
@@ -102,14 +102,14 @@ int sm750_hw_fillrect(struct lynx_accel *accel,
write_dpr(accel, DE_WINDOW_DESTINATION_BASE, base); /* dpr40 */
write_dpr(accel, DE_PITCH,
- ((pitch / Bpp << DE_PITCH_DESTINATION_SHIFT) &
+ ((pitch / bytes_per_pixel << DE_PITCH_DESTINATION_SHIFT) &
DE_PITCH_DESTINATION_MASK) |
- (pitch / Bpp & DE_PITCH_SOURCE_MASK)); /* dpr10 */
+ (pitch / bytes_per_pixel & DE_PITCH_SOURCE_MASK)); /* dpr10 */
write_dpr(accel, DE_WINDOW_WIDTH,
- ((pitch / Bpp << DE_WINDOW_WIDTH_DST_SHIFT) &
+ ((pitch / bytes_per_pixel << DE_WINDOW_WIDTH_DST_SHIFT) &
DE_WINDOW_WIDTH_DST_MASK) |
- (pitch / Bpp & DE_WINDOW_WIDTH_SRC_MASK)); /* dpr44 */
+ (pitch / bytes_per_pixel & DE_WINDOW_WIDTH_SRC_MASK)); /* dpr44 */
write_dpr(accel, DE_FOREGROUND, color); /* DPR14 */
@@ -138,7 +138,7 @@ int sm750_hw_fillrect(struct lynx_accel *accel,
* @sy: Starting y coordinate of source surface
* @dBase: Address of destination: offset in frame buffer
* @dPitch: Pitch value of destination surface in BYTE
- * @Bpp: Color depth of destination surface
+ * @bytes_per_pixel: Bytes per pixel (color depth / 8) of destination surface
* @dx: Starting x coordinate of destination surface
* @dy: Starting y coordinate of destination surface
* @width: width of rectangle in pixel value
@@ -149,7 +149,7 @@ int sm750_hw_copyarea(struct lynx_accel *accel,
unsigned int sBase, unsigned int sPitch,
unsigned int sx, unsigned int sy,
unsigned int dBase, unsigned int dPitch,
- unsigned int Bpp, unsigned int dx, unsigned int dy,
+ unsigned int bytes_per_pixel, unsigned int dx, unsigned int dy,
unsigned int width, unsigned int height,
unsigned int rop2)
{
@@ -249,9 +249,9 @@ int sm750_hw_copyarea(struct lynx_accel *accel,
* pixel values. Need Byte to pixel conversion.
*/
write_dpr(accel, DE_PITCH,
- ((dPitch / Bpp << DE_PITCH_DESTINATION_SHIFT) &
+ ((dPitch / bytes_per_pixel << DE_PITCH_DESTINATION_SHIFT) &
DE_PITCH_DESTINATION_MASK) |
- (sPitch / Bpp & DE_PITCH_SOURCE_MASK)); /* dpr10 */
+ (sPitch / bytes_per_pixel & DE_PITCH_SOURCE_MASK)); /* dpr10 */
/*
* Screen Window width in Pixels.
@@ -259,9 +259,9 @@ int sm750_hw_copyarea(struct lynx_accel *accel,
* for a given point.
*/
write_dpr(accel, DE_WINDOW_WIDTH,
- ((dPitch / Bpp << DE_WINDOW_WIDTH_DST_SHIFT) &
+ ((dPitch / bytes_per_pixel << DE_WINDOW_WIDTH_DST_SHIFT) &
DE_WINDOW_WIDTH_DST_MASK) |
- (sPitch / Bpp & DE_WINDOW_WIDTH_SRC_MASK)); /* dpr3c */
+ (sPitch / bytes_per_pixel & DE_WINDOW_WIDTH_SRC_MASK)); /* dpr3c */
if (accel->de_wait() != 0)
return -1;
--
2.43.0
^ permalink raw reply related
* [PATCH v2] staging: sm750fb: rename Bpp to bytes_per_pixel
From: yehudis9982 @ 2026-02-02 17:12 UTC (permalink / raw)
To: sudipm.mukherjee, teddy.wang, gregkh
Cc: linux-fbdev, linux-staging, linux-kernel, yehudis9982
In-Reply-To: <2026020201-monogamy-sash-4866@gregkh>
Rename the Bpp parameter to bytes_per_pixel for clarity and to avoid CamelCase, as reported by checkpatch.pl.
Signed-off-by: yehudis9982 <y0533159982@gmail.com>
---
drivers/staging/sm750fb/sm750_accel.c | 26 +++++++++++++-------------
1 file changed, 13 insertions(+), 13 deletions(-)
diff --git a/drivers/staging/sm750fb/sm750_accel.c b/drivers/staging/sm750fb/sm750_accel.c
index 046b9282b..3fe9429e1 100644
--- a/drivers/staging/sm750fb/sm750_accel.c
+++ b/drivers/staging/sm750fb/sm750_accel.c
@@ -48,7 +48,7 @@ void sm750_hw_de_init(struct lynx_accel *accel)
DE_STRETCH_FORMAT_ADDRESSING_MASK |
DE_STRETCH_FORMAT_SOURCE_HEIGHT_MASK;
- /* DE_STRETCH bpp format need be initialized in setMode routine */
+ /* DE_STRETCH bytes_per_pixel format need be initialized in setMode routine */
write_dpr(accel, DE_STRETCH_FORMAT,
(read_dpr(accel, DE_STRETCH_FORMAT) & ~clr) | reg);
@@ -76,7 +76,7 @@ void sm750_hw_set2dformat(struct lynx_accel *accel, int fmt)
{
u32 reg;
- /* fmt=0,1,2 for 8,16,32,bpp on sm718/750/502 */
+ /* fmt=0,1,2 for 8,16,32,bytes_per_pixel on sm718/750/502 */
reg = read_dpr(accel, DE_STRETCH_FORMAT);
reg &= ~DE_STRETCH_FORMAT_PIXEL_FORMAT_MASK;
reg |= ((fmt << DE_STRETCH_FORMAT_PIXEL_FORMAT_SHIFT) &
@@ -85,7 +85,7 @@ void sm750_hw_set2dformat(struct lynx_accel *accel, int fmt)
}
int sm750_hw_fillrect(struct lynx_accel *accel,
- u32 base, u32 pitch, u32 Bpp,
+ u32 base, u32 pitch, u32 bytes_per_pixel,
u32 x, u32 y, u32 width, u32 height,
u32 color, u32 rop)
{
@@ -102,14 +102,14 @@ int sm750_hw_fillrect(struct lynx_accel *accel,
write_dpr(accel, DE_WINDOW_DESTINATION_BASE, base); /* dpr40 */
write_dpr(accel, DE_PITCH,
- ((pitch / Bpp << DE_PITCH_DESTINATION_SHIFT) &
+ ((pitch / bytes_per_pixel << DE_PITCH_DESTINATION_SHIFT) &
DE_PITCH_DESTINATION_MASK) |
- (pitch / Bpp & DE_PITCH_SOURCE_MASK)); /* dpr10 */
+ (pitch / bytes_per_pixel & DE_PITCH_SOURCE_MASK)); /* dpr10 */
write_dpr(accel, DE_WINDOW_WIDTH,
- ((pitch / Bpp << DE_WINDOW_WIDTH_DST_SHIFT) &
+ ((pitch / bytes_per_pixel << DE_WINDOW_WIDTH_DST_SHIFT) &
DE_WINDOW_WIDTH_DST_MASK) |
- (pitch / Bpp & DE_WINDOW_WIDTH_SRC_MASK)); /* dpr44 */
+ (pitch / bytes_per_pixel & DE_WINDOW_WIDTH_SRC_MASK)); /* dpr44 */
write_dpr(accel, DE_FOREGROUND, color); /* DPR14 */
@@ -138,7 +138,7 @@ int sm750_hw_fillrect(struct lynx_accel *accel,
* @sy: Starting y coordinate of source surface
* @dBase: Address of destination: offset in frame buffer
* @dPitch: Pitch value of destination surface in BYTE
- * @Bpp: Color depth of destination surface
+ * @bytes_per_pixel: Bytes per pixel (color depth / 8) of destination surface
* @dx: Starting x coordinate of destination surface
* @dy: Starting y coordinate of destination surface
* @width: width of rectangle in pixel value
@@ -149,7 +149,7 @@ int sm750_hw_copyarea(struct lynx_accel *accel,
unsigned int sBase, unsigned int sPitch,
unsigned int sx, unsigned int sy,
unsigned int dBase, unsigned int dPitch,
- unsigned int Bpp, unsigned int dx, unsigned int dy,
+ unsigned int bytes_per_pixel, unsigned int dx, unsigned int dy,
unsigned int width, unsigned int height,
unsigned int rop2)
{
@@ -249,9 +249,9 @@ int sm750_hw_copyarea(struct lynx_accel *accel,
* pixel values. Need Byte to pixel conversion.
*/
write_dpr(accel, DE_PITCH,
- ((dPitch / Bpp << DE_PITCH_DESTINATION_SHIFT) &
+ ((dPitch / bytes_per_pixel << DE_PITCH_DESTINATION_SHIFT) &
DE_PITCH_DESTINATION_MASK) |
- (sPitch / Bpp & DE_PITCH_SOURCE_MASK)); /* dpr10 */
+ (sPitch / bytes_per_pixel & DE_PITCH_SOURCE_MASK)); /* dpr10 */
/*
* Screen Window width in Pixels.
@@ -259,9 +259,9 @@ int sm750_hw_copyarea(struct lynx_accel *accel,
* for a given point.
*/
write_dpr(accel, DE_WINDOW_WIDTH,
- ((dPitch / Bpp << DE_WINDOW_WIDTH_DST_SHIFT) &
+ ((dPitch / bytes_per_pixel << DE_WINDOW_WIDTH_DST_SHIFT) &
DE_WINDOW_WIDTH_DST_MASK) |
- (sPitch / Bpp & DE_WINDOW_WIDTH_SRC_MASK)); /* dpr3c */
+ (sPitch / bytes_per_pixel & DE_WINDOW_WIDTH_SRC_MASK)); /* dpr3c */
if (accel->de_wait() != 0)
return -1;
--
2.43.0
^ permalink raw reply related
* Re: [PATCH] staging: fbtft: fix macro flow control warning and empty macro argument in fbtft-bus.c
From: Dan Carpenter @ 2026-02-02 20:01 UTC (permalink / raw)
To: KrishnaAgarwal1308
Cc: Andy Shevchenko, Greg Kroah-Hartman, dri-devel, linux-fbdev,
linux-staging, linux-kernel
In-Reply-To: <20260202162826.116739-1-krishnaworkemail1308@gmail.com>
On Mon, Feb 02, 2026 at 09:58:26PM +0530, KrishnaAgarwal1308 wrote:
> Fix checkpatch warning by adding identity modifier for define_fbtft_write_reg().
> No functional change.
>
This commit does two things. It introduces fbtft_identity()
and it flips the if (ret < 0) condition around to avoid the goto
inside a macro. Only the first change is mentioned in the commit
message.
I have see the fbtft_identity() approach before and I don't like it.
https://lore.kernel.org/all/20250718191935.5918-2-abronzo@mac.com/
The name identity() doesn't mean anything. It's a real word and
it has a meaning but it doesn't have a meaning which is at all
related to this code.
I think I would be okay with this the macro were called nop_endian()
or cpu_to_cpu_endian() or something. Or another approach is to just
leave the code as-is. Or maybe we could add a comment?
Regarding the flipped condition, the new code is badly formatted and
uglier than the original. I would prefer to leave it as-is.
regards,
dan carpenter
^ 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