* Re: [PATCH 03/13] mm: convert __get_unmapped_area() to use vma_flags_t
From: Lorenzo Stoakes @ 2026-07-07 10:16 UTC (permalink / raw)
To: Zi Yan
Cc: Andrew Morton, Thomas Bogendoerfer, Madhavan Srinivasan,
Michael Ellerman, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Lucas Stach,
Inki Dae, Seung-Woo Kim, Kyungmin Park, Krzysztof Kozlowski,
Peter Griffin, Jani Nikula, Joonas Lahtinen, Rodrigo Vivi,
Tvrtko Ursulin, Rob Clark, Dmitry Baryshkov, Lyude Paul,
Danilo Krummrich, Tomi Valkeinen, Sandy Huang, Heiko Stübner,
Andy Yan, Thierry Reding, Mikko Perttunen, Jonathan Hunter,
Gerd Hoffmann, Dmitry Osipenko, Zack Rusin, Matthew Brost,
Thomas Hellstrom, Oleksandr Andrushchenko, Helge Deller,
Benjamin LaHaise, Alexander Viro, Christian Brauner, Muchun Song,
Oscar Salvador, David Hildenbrand, Baolin Wang, Liam R . Howlett,
Nico Pache, Ryan Roberts, Dev Jain, Barry Song, Lance Yang,
Hugh Dickins, Vlastimil Babka, Mike Rapoport, Suren Baghdasaryan,
Michal Hocko, Jann Horn, Pedro Falcato, Kees Cook,
Jaroslav Kysela, Takashi Iwai, linux-mips, linux-kernel,
linuxppc-dev, dri-devel, etnaviv, linux-arm-kernel,
linux-samsung-soc, intel-gfx, linux-arm-msm, freedreno, nouveau,
linux-rockchip, linux-tegra, virtualization, intel-xe, xen-devel,
linux-fbdev, linux-aio, linux-fsdevel, linux-mm, linux-sound
In-Reply-To: <DJRZGEZU5ESV.3IP5LEAUQJCBK@nvidia.com>
On Mon, Jul 06, 2026 at 10:28:24PM -0400, Zi Yan wrote:
> On Mon Jun 29, 2026 at 3:25 PM EDT, Lorenzo Stoakes wrote:
> > Update __get_unmapped_area() to be parameterised by vma_flags_t rather than
> > vm_flags_t as part of the effort to move VMA flags from a system word to a
> > bitmap.
> >
> > We cascade the changes up to arch_get_unmapped_area_topdown() and
> > arch_get_unmapped_area(), where, for now, we use vma_flags_to_legacy() in
> > order to propagate the VMA flags.
> >
> > No functional change intended.
> >
> > Signed-off-by: Lorenzo Stoakes <ljs@kernel.org>
> > ---
> > fs/hugetlbfs/inode.c | 3 ++-
> > include/linux/huge_mm.h | 10 +++++-----
> > include/linux/mm.h | 6 ++++--
> > include/linux/sched/mm.h | 12 ++++++------
> > mm/huge_memory.c | 21 ++++++++++++---------
> > mm/mmap.c | 27 ++++++++++++++-------------
> > 6 files changed, 43 insertions(+), 36 deletions(-)
> >
> <snip>
>
> > diff --git a/include/linux/sched/mm.h b/include/linux/sched/mm.h
> > index 95d0040df584..b301ec90740a 100644
> > --- a/include/linux/sched/mm.h
> > +++ b/include/linux/sched/mm.h
> > @@ -193,12 +193,12 @@ unsigned long mm_get_unmapped_area(struct file *filp, unsigned long addr,
> > unsigned long len, unsigned long pgoff,
> > unsigned long flags);
> >
> > -unsigned long mm_get_unmapped_area_vmflags(struct file *filp,
> > - unsigned long addr,
> > - unsigned long len,
> > - unsigned long pgoff,
> > - unsigned long flags,
> > - vm_flags_t vm_flags);
> > +unsigned long mm_get_unmapped_area_vmaflags(struct file *filp,
> > + unsigned long addr,
> > + unsigned long len,
> > + unsigned long pgoff,
> > + unsigned long flags,
> > + vma_flags_t vma_flags);
>
> Want to use two-tab indentation while at it?
Yeah sure will fix on respin!
>
> <snip>
>
> > @@ -812,19 +811,20 @@ arch_get_unmapped_area_topdown(struct file *filp, unsigned long addr,
> > }
> > #endif
> >
> > -unsigned long mm_get_unmapped_area_vmflags(struct file *filp, unsigned long addr,
> > - unsigned long len, unsigned long pgoff,
> > - unsigned long flags, vm_flags_t vm_flags)
> > +unsigned long mm_get_unmapped_area_vmaflags(struct file *filp, unsigned long addr,
> > + unsigned long len, unsigned long pgoff,
> > + unsigned long flags, vma_flags_t vma_flags)
>
> Ditto.
Ack will fix!
>
> LGTM.
>
> Reviewed-by: Zi Yan <ziy@nvidia.com>
Thanks!
>
>
> --
> Best Regards,
> Yan, Zi
>
Cheers, Lorenzo
^ permalink raw reply
* Re: [PATCH 02/13] mm/vma: update do_mmap() to use vma_flags_t
From: Lorenzo Stoakes @ 2026-07-07 10:15 UTC (permalink / raw)
To: Zi Yan
Cc: Andrew Morton, Thomas Bogendoerfer, Madhavan Srinivasan,
Michael Ellerman, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Lucas Stach,
Inki Dae, Seung-Woo Kim, Kyungmin Park, Krzysztof Kozlowski,
Peter Griffin, Jani Nikula, Joonas Lahtinen, Rodrigo Vivi,
Tvrtko Ursulin, Rob Clark, Dmitry Baryshkov, Lyude Paul,
Danilo Krummrich, Tomi Valkeinen, Sandy Huang, Heiko Stübner,
Andy Yan, Thierry Reding, Mikko Perttunen, Jonathan Hunter,
Gerd Hoffmann, Dmitry Osipenko, Zack Rusin, Matthew Brost,
Thomas Hellstrom, Oleksandr Andrushchenko, Helge Deller,
Benjamin LaHaise, Alexander Viro, Christian Brauner, Muchun Song,
Oscar Salvador, David Hildenbrand, Baolin Wang, Liam R . Howlett,
Nico Pache, Ryan Roberts, Dev Jain, Barry Song, Lance Yang,
Hugh Dickins, Vlastimil Babka, Mike Rapoport, Suren Baghdasaryan,
Michal Hocko, Jann Horn, Pedro Falcato, Kees Cook,
Jaroslav Kysela, Takashi Iwai, linux-mips, linux-kernel,
linuxppc-dev, dri-devel, etnaviv, linux-arm-kernel,
linux-samsung-soc, intel-gfx, linux-arm-msm, freedreno, nouveau,
linux-rockchip, linux-tegra, virtualization, intel-xe, xen-devel,
linux-fbdev, linux-aio, linux-fsdevel, linux-mm, linux-sound
In-Reply-To: <DJRZ2QCEIVA6.1AZF5S891NKS4@nvidia.com>
On Mon, Jul 06, 2026 at 10:10:32PM -0400, Zi Yan wrote:
> On Mon Jun 29, 2026 at 3:25 PM EDT, Lorenzo Stoakes wrote:
> > The core do_mmap() function accepts a vm_flags_t parameter which it then
> > manipulates before passing to mmap_region() to do the heavy lifting of the
> > memory mapping.
> >
> > Update do_mmap() to instead accept a vma_flags_t parameter, and adjust all
> > the logic within do_mmap() to manipulate this instead.
> >
> > This is as part of the ongoing effort to convert VMA flags from a system
> > word size to a bitmap type which allows us to unrestrict the number of VMA
> > flags, as well as gain control over how VMA flag manipulation occurs.
> >
> > We do not cascade these changes to all functions which accept vm_flags_t,
> > but rather use vma_flags_to_legacy() where necessary, specifically
> > deferring converting calc_vm_prot_bits(), calc_vm_flag_bits() and
> > __get_unmapped_area() to vma_flags_t.
> >
> > Also utilise the new vma_flags_can_grow() predicate which correctly handles
> > the case of architectures without upward growing stacks.
> >
> > As part of this change, introduce VMA_SHADOW_STACK so we can correctly
> > handle the case of the shadow stack not being defined.
> >
> > No functional change intended.
> >
> > Signed-off-by: Lorenzo Stoakes <ljs@kernel.org>
> > ---
> > arch/mips/kernel/vdso.c | 4 +--
> > fs/aio.c | 2 +-
> > include/linux/memfd.h | 6 ++--
> > include/linux/mm.h | 6 ++--
> > ipc/shm.c | 3 +-
> > mm/memfd.c | 15 ++++-----
> > mm/mmap.c | 67 ++++++++++++++++++++++++-----------------
> > mm/nommu.c | 3 +-
> > mm/util.c | 10 +++---
> > mm/vma.c | 7 ++---
> > mm/vma.h | 2 +-
> > 11 files changed, 69 insertions(+), 56 deletions(-)
> >
>
> <snip>
>
> >
> > -static int check_write_seal(vm_flags_t *vm_flags_ptr)
> > +static int check_write_seal(vma_flags_t *vma_flags_ptr)
> > {
> > - vm_flags_t vm_flags = *vm_flags_ptr;
> > - vm_flags_t mask = vm_flags & (VM_SHARED | VM_WRITE);
> > -
> > /* If a private mapping then writability is irrelevant. */
> > - if (!(mask & VM_SHARED))
> > + if (!vma_flags_test(vma_flags_ptr, VMA_SHARED_BIT))
> > return 0;
> >
> > /*
> > * New PROT_WRITE and MAP_SHARED mmaps are not allowed when
> > * write seals are active.
> > */
> > - if (mask & VM_WRITE)
> > + if (vma_flags_test(vma_flags_ptr, VMA_WRITE_BIT))
> > return -EPERM;
> >
> > /*
> > * This is a read-only mapping, disallow mprotect() from making a
> > * write-sealed mapping writable in future.
> > */
> > - *vm_flags_ptr &= ~VM_MAYWRITE;
> > + vma_flags_clear(vma_flags_ptr, VMA_MAYWRITE_BIT);
> >
> > return 0;
> > }
>
> This function alone changed its original behavior, since vm_flags is a
> snapshot of *vm_flags_ptr, but after the change this snapshot is gone.
> But its only caller memfd_check_seals_mmap() gets vm_flags_ptr from the
> input parameter of do_mmap(), so the overall behavior does not change.
Right yeah, the snapshot was always just a convenience thing :)
>
> <snip>
>
> > + case MAP_DROPPABLE: {
> > + vma_flags_t droppable = VMA_DROPPABLE;
> > +
> > + if (vma_flags_empty(&droppable))
> > return -EOPNOTSUPP;
> > + vma_flags_set_mask(&vma_flags, droppable);
> > +
> > /*
> > * A locked or stack area makes no sense to be droppable.
> > *
> > @@ -515,23 +527,24 @@ unsigned long do_mmap(struct file *file, unsigned long addr,
> > */
> > if (flags & (MAP_LOCKED | MAP_HUGETLB))
> > return -EINVAL;
> > - if (vm_flags & (VM_GROWSDOWN | VM_GROWSUP))
> > + if (vma_flags_can_grow(&vma_flags))
> > return -EINVAL;
> >
> > - vm_flags |= VM_DROPPABLE;
> > -
>
> Lance pointed out the reordering of setting VMA_DROPPABLE and checking
> of can_grow, but these flags are not overlapped and there is no parallel
> writer to vma_flags. So it is still no functional change, just not
> mechanical changes. :)
Right yes exactly :)
>
> Otherwise, LGTM.
>
> Reviewed-by: Zi Yan <ziy@nvidia.com>
Thanks!
>
> --
> Best Regards,
> Yan, Zi
>
Cheers, Lorenzo
^ permalink raw reply
* Re: [PATCH v2] staging: fbtft: use %pe for backlight errors
From: Greg KH @ 2026-07-07 9:22 UTC (permalink / raw)
To: Keefe Reeves
Cc: andy, abdun.nihaal, error27, chintanlike, namcao, niejianglei2021,
dri-devel, linux-fbdev, linux-staging, linux-kernel
In-Reply-To: <20260614201551.20542-1-reeveskeefe@gmail.com>
On Sun, Jun 14, 2026 at 05:15:51PM -0300, Keefe Reeves wrote:
> Coccinelle found two places where backlight registration errors are
> printed by passing PTR_ERR() to dev_err().
>
> Use %pe instead so the error pointer can be printed directly. This keeps
> the behavior the same and just makes the error printing cleaner.
>
> Signed-off-by: Keefe Reeves <reeveskeefe@gmail.com>
> ---
> Changes in v2:
> - Use reachable Gmail address for author and Signed-off-by.
Does not apply to my tree :(
^ permalink raw reply
* Re: [PATCH] staging: sm750fb: convert camelCase parameters to snake_case
From: Greg Kroah-Hartman @ 2026-07-07 9:13 UTC (permalink / raw)
To: Noah Adkins
Cc: Sudip Mukherjee, Teddy Wang,
open list:STAGING - SILICON MOTION SM750 FRAME BUFFER DRIVER,
open list:STAGING SUBSYSTEM, open list
In-Reply-To: <20260615012837.90113-2-noahcadkins@gmail.com>
On Sun, Jun 14, 2026 at 09:28:38PM -0400, Noah Adkins wrote:
> Convert the camelCase parameters in the 2D acceleration helper
> prototypes to snake_case to conform to the kernel coding style
> and to make them consistent with the parameter names in the
> corresponding implementations.
But they don't seem to match up with what the .c file says, right? Why
not?
For example:
> int sm750_hw_copyarea(struct lynx_accel *accel,
> - unsigned int sBase, unsigned int sPitch,
> + unsigned int source_base, unsigned int source_pitch,
> unsigned int sx, unsigned int sy,
> - unsigned int dBase, unsigned int dPitch,
> + unsigned int d_base, unsigned int d_pitch,
"d_base" is "dest_base" in the .c file.
Same for some other variables.
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH] staging: sm750fb: rename variables to avoid CamelCase
From: Greg KH @ 2026-07-07 9:11 UTC (permalink / raw)
To: André Moreira
Cc: sudipm.mukherjee, teddy.wang, linux-fbdev, linux-staging,
linux-kernel
In-Reply-To: <20260623220614.29682-1-andrem.33333@gmail.com>
On Tue, Jun 23, 2026 at 07:06:14PM -0300, André Moreira wrote:
> Rename 'pvReg' to 'pv_reg' and 'setAllEngOff' to 'set_all_eng_off'
> throughout the driver to comply with the Linux kernel coding style.
>
> Signed-off-by: André Moreira <andrem.33333@gmail.com>
> ---
> drivers/staging/sm750fb/sm750.c | 6 +++---
> drivers/staging/sm750fb/sm750.h | 4 ++--
> drivers/staging/sm750fb/sm750_hw.c | 12 ++++++------
> 3 files changed, 11 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/staging/sm750fb/sm750.c b/drivers/staging/sm750fb/sm750.c
> index 89c811e0806c4..716a8935f58d1 100644
> --- a/drivers/staging/sm750fb/sm750.c
> +++ b/drivers/staging/sm750fb/sm750.c
> @@ -743,7 +743,7 @@ static int lynxfb_set_fbinfo(struct fb_info *info, int index)
> * must be set after crtc member initialized
> */
> crtc->cursor.offset = crtc->o_screen + crtc->vidmem_size - 1024;
> - crtc->cursor.mmio = sm750_dev->pvReg +
> + crtc->cursor.mmio = sm750_dev->pv_reg +
This variable name is still in hungarian notation, which is not allowed
in kernel variable names.
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH v3 4/4] staging: sm750fb: deduplicate fbinfo loop in suspend/resume
From: Greg KH @ 2026-07-07 9:09 UTC (permalink / raw)
To: Ahmet Sezgin Duran; +Cc: error27, linux-fbdev, linux-staging, linux-kernel
In-Reply-To: <20260525085808.171974-5-ahmet@sezginduran.net>
On Mon, May 25, 2026 at 08:58:08AM +0000, Ahmet Sezgin Duran wrote:
> lynxfb_suspend() and lynxfb_resume() both walk sm750_dev->fbinfo[]
> via duplicated per-index blocks for fbinfo[0] and fbinfo[1].
>
> Replace each pair of blocks with a for-loop bounded by
> sm750_dev->fb_count, the number of successfully registered
> framebuffers.
>
> No functional changes intended.
Do you have the hardware to test changes like this?
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH v2 1/2] staging: sm750fb: rename setAllEngOff to set_all_eng_off
From: Greg KH @ 2026-07-07 9:08 UTC (permalink / raw)
To: Michail Tatas
Cc: sudipm.mukherjee, teddy.wang, linux-fbdev, linux-staging,
linux-kernel
In-Reply-To: <438a9a516955be8cbd7144e95f494663c8c99e23.1779661132.git.michail.tatas@gmail.com>
On Mon, May 25, 2026 at 02:15:37AM +0300, Michail Tatas wrote:
> Rename variable setAllEngOff to set_all_eng_off as
> per the Linux coding standards
>
> Signed-off-by: Michail Tatas <michail.tatas@gmail.com>
> ---
> drivers/staging/sm750fb/sm750.c | 2 +-
> drivers/staging/sm750fb/sm750.h | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/staging/sm750fb/sm750.c b/drivers/staging/sm750fb/sm750.c
> index 89c811e0806c..00c293430a7d 100644
> --- a/drivers/staging/sm750fb/sm750.c
> +++ b/drivers/staging/sm750fb/sm750.c
> @@ -848,7 +848,7 @@ static void sm750fb_setup(struct sm750_dev *sm750_dev, char *src)
> sm750_dev->init_parm.mem_clk = 0;
> sm750_dev->init_parm.master_clk = 0;
> sm750_dev->init_parm.power_mode = 0;
> - sm750_dev->init_parm.setAllEngOff = 0;
> + sm750_dev->init_parm.set_all_eng_off = 0;
> sm750_dev->init_parm.reset_memory = 1;
>
> /* defaultly turn g_hwcursor on for both view */
> diff --git a/drivers/staging/sm750fb/sm750.h b/drivers/staging/sm750fb/sm750.h
> index d2c522e67f26..589ae51444f8 100644
> --- a/drivers/staging/sm750fb/sm750.h
> +++ b/drivers/staging/sm750fb/sm750.h
> @@ -44,7 +44,7 @@ struct init_status {
> ushort chip_clk;
> ushort mem_clk;
> ushort master_clk;
> - ushort setAllEngOff;
> + ushort set_all_eng_off;
> ushort reset_memory;
> };
If this is only set and never read, why is it needed at all?
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH v2 2/2] staging: sm750fb: rename pvReg to pv_reg
From: Greg KH @ 2026-07-07 9:08 UTC (permalink / raw)
To: Michail Tatas
Cc: sudipm.mukherjee, teddy.wang, linux-fbdev, linux-staging,
linux-kernel
In-Reply-To: <fae018f80f61acea030d9893f3085998a78e4edf.1779661132.git.michail.tatas@gmail.com>
On Mon, May 25, 2026 at 02:15:38AM +0300, Michail Tatas wrote:
> Rename variable pvReg to pv_reg as per
> the Linux coding standards
But "pv_reg" is not a correct name, right? It's still in "hungarian"
notataion, which is not what we use in the kernel.
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH v2] staging: sm750fb: fix CamelCase variables name in sm750
From: Greg KH @ 2026-07-07 9:07 UTC (permalink / raw)
To: eamanu
Cc: sudipm.mukherjee, teddy.wang, linux-fbdev, linux-staging,
linux-kernel, kernel test robot
In-Reply-To: <b69100263ea16141b31a7dc240ccdc91@riseup.net>
On Tue, May 26, 2026 at 08:30:56PM +0000, eamanu@riseup.net wrote:
> Hi,
>
> thanks for your reply
>
> On 2026-05-26 13:20, Greg KH wrote:
> > On Tue, May 26, 2026 at 10:16:31AM -0300, Emmanuel Arias wrote:
> >> Replace CamelCase variable name with snake_case:
> >> - pvReg -> pv_reg
> >
> > Why are you keeping the "pv_"? What does that mean?
>
> Sorry, I'm trying to start contributing in the kernel. I run
>
> scripts/checkpatch.pl --file drivers/staging/sm750fb/*.c
>
> And the output was:
>
> drivers/staging/sm750fb/sm750.c
> -------------------------------
> WARNING: static const char * array should probably be static const char
> * const
> #36: FILE: drivers/staging/sm750fb/sm750.c:36:
> +static const char *g_fbmode[] = {NULL, NULL};
>
> CHECK: Avoid CamelCase: <pvReg>
> #758: FILE: drivers/staging/sm750fb/sm750.c:758:
> + crtc->cursor.mmio = sm750_dev->pvReg +
>
> CHECK: Avoid CamelCase: <setAllEngOff>
> #863: FILE: drivers/staging/sm750fb/sm750.c:863:
> + sm750_dev->init_parm.setAllEngOff = 0;
>
> total: 0 errors, 1 warnings, 2 checks, 1171 lines checked
>
> NOTE: For some of the reported defects, checkpatch may be able to
> mechanically convert to the typical style using --fix or
> --fix-inplace.
>
> So I tried to change pvReg for pv_reg and the same for setAllEngOff.
>
> >
> >> - setAllEngOff -> set_all_eng_off
> >>
> >> Reported-by: kernel test robot <lkp@intel.com>
> >
> > The test robot told you to make this change?
>
> As I understand the test robot failed because:
>
>
> drivers/staging/sm750fb/sm750_hw.c: In function 'hw_sm750_map':
> >> drivers/staging/sm750fb/sm750_hw.c:43:13: error: 'struct sm750_dev' has no member named 'pvReg'; did you mean 'pv_reg'?
> sm750_dev->pvReg =
> ^~~~~
> pv_reg
>
> >
> >> Closes: https://lore.kernel.org/oe-kbuild-all/202605171049.KbaBnrJV-lkp@intel.com/
> >> Signed-off-by: Emmanuel Arias <eamanu@riseup.net>
> >> ---
> >> drivers/staging/sm750fb/sm750.c | 6 +++---
> >> drivers/staging/sm750fb/sm750.h | 4 ++--
> >> drivers/staging/sm750fb/sm750_hw.c | 12 ++++++------
> >> 3 files changed, 11 insertions(+), 11 deletions(-)
> >
> > What changed from v1?
>
> So, in this v2 I added sm750_hw.c.
>
> Please let me know if I misunderstood the workflow
The workflow is good, but you changed the name without thinking about
why checkpatch was telling you the current name was bad, and so you need
to pick a correct name for it instead.
Look on the mailing list archives for the many times people have
attempted to do this same thing recently for why this name change is not
the correct one.
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH] staging: sm750fb: rename Bpp parameter to bpp
From: gregkh @ 2026-07-07 9:06 UTC (permalink / raw)
To: Gabry
Cc: sudipm.mukherjee@gmail.com, teddy.wang@siliconmotion.com,
linux-fbdev@vger.kernel.org, linux-staging@lists.linux.dev,
linux-kernel@vger.kernel.org
In-Reply-To: <hpslpD7esY-xE37Tvrz0V8gD8YoZwdu6IlQ8LjUz5fY5mevEeDxM-dLC64t43G4mpVfHB_xCDUESoNFZ7ua9k7B_k2NrY2u-P6NYIJSuGt4=@proton.me>
On Thu, May 28, 2026 at 06:36:45PM +0000, Gabry wrote:
> The Linux kernel coding style prefers snake_case over CamelCase foridentifier names.
>
> Rename the 'Bpp' parameter (bytes per pixel) of sm750_hw_fillrect()
> and sm750_hw_copyarea() to 'bpp' to comply with this standard. Update
> the function prototypes in sm750_accel.h and the corresponding
> kernel-doc descriptions accordingly.
>
> This is a pure rename with no functional change, and addresses a
> checkpatch.pl warning:
>
> CHECK: Avoid CamelCase: <Bpp>
>
> Signed-off-by: Gabriele Rizzo <gabry.256@proton.me>
Does not match up with your "From:" line :(
Also, this is the second version of this patch you sent out, what
changed from the first?
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH v2] staging: sm750fb: fix remaining CamelCase issues
From: Krzysztof Kozlowski @ 2026-07-07 6:25 UTC (permalink / raw)
To: Arnav Kapoor, Sudip Mukherjee, Teddy Wang, Greg Kroah-Hartman
Cc: linux-fbdev, linux-staging, linux-kernel
In-Reply-To: <20260624042543.38925-1-kapoorarnav43@gmail.com>
On 24/06/2026 06:25, Arnav Kapoor wrote:
> Rename the remaining CamelCase variables and constants
> to follow kernel coding style.
>
> Rename:
>
> * powerMode -> power_mode
> * setAllEngOff -> set_all_eng_off
> * resetMemory -> reset_memory
> * sm750_doubleTFT -> SM750_DOUBLE_TFT
> * sm750_dualTFT -> SM750_DUAL_TFT
>
> Fix build errors by renaming the corresponding
> declarations and enum values as well.
>
> Reported-by: kernel test robot [lkp@intel.com](mailto:lkp@intel.com)
> Closes: https://lore.kernel.org/oe-kbuild-all/202606240916.wIIrdOzC-lkp@intel.com/
> Signed-off-by: Arnav Kapoor <kapoorarnav43@gmail.com>
Same comments.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2] staging: sm750fb: rename CamelCase pvMem and pvReg
From: Krzysztof Kozlowski @ 2026-07-07 6:25 UTC (permalink / raw)
To: Arnav Kapoor, Sudip Mukherjee, Teddy Wang, Greg Kroah-Hartman
Cc: linux-fbdev, linux-staging, linux-kernel, kernel test robot
In-Reply-To: <20260624044412.67464-1-kapoorarnav43@gmail.com>
On 24/06/2026 06:44, Arnav Kapoor wrote:
> Rename the remaining CamelCase structure members
> to follow kernel coding style.
>
> Rename:
>
> * pvMem -> vram
> * pvReg -> reg
>
> Fix build errors by renaming the corresponding
> structure members in sm750.h as well.
>
> Reported-by: kernel test robot <lkp@intel.com>
> Closes: https://lore.kernel.org/oe-kbuild-all/202606240823.hWXfYyPf-lkp@intel.com/
Please stop sending multiple duplicates of the same patch.
Same comments.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2] staging: sm750fb: rename CamelCase pvMem and pvReg
From: Krzysztof Kozlowski @ 2026-07-07 6:25 UTC (permalink / raw)
To: Arnav Kapoor, Sudip Mukherjee, Teddy Wang, Greg Kroah-Hartman
Cc: linux-fbdev, linux-staging, linux-kernel, kernel test robot
In-Reply-To: <20260624044610.69708-1-kapoorarnav43@gmail.com>
On 24/06/2026 06:46, Arnav Kapoor wrote:
> Rename the remaining CamelCase structure members
> to follow kernel coding style.
>
> Rename:
>
> * pvMem -> vram
> * pvReg -> reg
>
> Fix build errors by renaming the corresponding
> structure members in sm750.h as well.
>
> Reported-by: kernel test robot <lkp@intel.com>
> Closes: https://lore.kernel.org/oe-kbuild-all/202606240823.hWXfYyPf-lkp@intel.com/
Nothing to be reported here. Did you read the email from lkp?
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 04/13] mm: update generic_get_unmapped_area[_topdown]() to use vma_flags_t
From: Zi Yan @ 2026-07-07 2:29 UTC (permalink / raw)
To: Lorenzo Stoakes, Andrew Morton
Cc: Thomas Bogendoerfer, Madhavan Srinivasan, Michael Ellerman,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, Lucas Stach, Inki Dae, Seung-Woo Kim,
Kyungmin Park, Krzysztof Kozlowski, Peter Griffin, Jani Nikula,
Joonas Lahtinen, Rodrigo Vivi, Tvrtko Ursulin, Rob Clark,
Dmitry Baryshkov, Lyude Paul, Danilo Krummrich, Tomi Valkeinen,
Sandy Huang, Heiko Stübner, Andy Yan, Thierry Reding,
Mikko Perttunen, Jonathan Hunter, Gerd Hoffmann, Dmitry Osipenko,
Zack Rusin, Matthew Brost, Thomas Hellstrom,
Oleksandr Andrushchenko, Helge Deller, Benjamin LaHaise,
Alexander Viro, Christian Brauner, Muchun Song, Oscar Salvador,
David Hildenbrand, Baolin Wang, Liam R . Howlett, Nico Pache,
Ryan Roberts, Dev Jain, Barry Song, Lance Yang, Hugh Dickins,
Vlastimil Babka, Mike Rapoport, Suren Baghdasaryan, Michal Hocko,
Jann Horn, Pedro Falcato, Kees Cook, Jaroslav Kysela,
Takashi Iwai, linux-mips, linux-kernel, linuxppc-dev, dri-devel,
etnaviv, linux-arm-kernel, linux-samsung-soc, intel-gfx,
linux-arm-msm, freedreno, nouveau, linux-rockchip, linux-tegra,
virtualization, intel-xe, xen-devel, linux-fbdev, linux-aio,
linux-fsdevel, linux-mm, linux-sound
In-Reply-To: <cef55b19f86c110952f13829aefa4859db3a70ed.1782760670.git.ljs@kernel.org>
On Mon Jun 29, 2026 at 3:25 PM EDT, Lorenzo Stoakes wrote:
> As part of the changes converting VMA flags from a system word size to a
> bitmap, extend this change to generic_get_unmapped_area() and
> generic_get_unmapped_area_topdown(), which also allows us to convert
> stack_guard_placement() as well.
>
> We retain arch_get_unmapped_area() and arch_get_unmapped_area_topdown()
> as-is for now, using legacy_to_vma_flags() as necessary to do so.
>
> No functional change intended.
>
> Signed-off-by: Lorenzo Stoakes <ljs@kernel.org>
> ---
> arch/powerpc/mm/book3s64/slice.c | 6 ++++--
> include/linux/sched/mm.h | 4 ++--
> mm/mmap.c | 16 ++++++++--------
> 3 files changed, 14 insertions(+), 12 deletions(-)
>
LGTM.
Reviewed-by: Zi Yan <ziy@nvidia.com>
--
Best Regards,
Yan, Zi
^ permalink raw reply
* Re: [PATCH 03/13] mm: convert __get_unmapped_area() to use vma_flags_t
From: Zi Yan @ 2026-07-07 2:28 UTC (permalink / raw)
To: Lorenzo Stoakes, Andrew Morton
Cc: Thomas Bogendoerfer, Madhavan Srinivasan, Michael Ellerman,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, Lucas Stach, Inki Dae, Seung-Woo Kim,
Kyungmin Park, Krzysztof Kozlowski, Peter Griffin, Jani Nikula,
Joonas Lahtinen, Rodrigo Vivi, Tvrtko Ursulin, Rob Clark,
Dmitry Baryshkov, Lyude Paul, Danilo Krummrich, Tomi Valkeinen,
Sandy Huang, Heiko Stübner, Andy Yan, Thierry Reding,
Mikko Perttunen, Jonathan Hunter, Gerd Hoffmann, Dmitry Osipenko,
Zack Rusin, Matthew Brost, Thomas Hellstrom,
Oleksandr Andrushchenko, Helge Deller, Benjamin LaHaise,
Alexander Viro, Christian Brauner, Muchun Song, Oscar Salvador,
David Hildenbrand, Baolin Wang, Liam R . Howlett, Nico Pache,
Ryan Roberts, Dev Jain, Barry Song, Lance Yang, Hugh Dickins,
Vlastimil Babka, Mike Rapoport, Suren Baghdasaryan, Michal Hocko,
Jann Horn, Pedro Falcato, Kees Cook, Jaroslav Kysela,
Takashi Iwai, linux-mips, linux-kernel, linuxppc-dev, dri-devel,
etnaviv, linux-arm-kernel, linux-samsung-soc, intel-gfx,
linux-arm-msm, freedreno, nouveau, linux-rockchip, linux-tegra,
virtualization, intel-xe, xen-devel, linux-fbdev, linux-aio,
linux-fsdevel, linux-mm, linux-sound
In-Reply-To: <b1ad7c4443f5cba622e4c48c5a9ef15427001a93.1782760670.git.ljs@kernel.org>
On Mon Jun 29, 2026 at 3:25 PM EDT, Lorenzo Stoakes wrote:
> Update __get_unmapped_area() to be parameterised by vma_flags_t rather than
> vm_flags_t as part of the effort to move VMA flags from a system word to a
> bitmap.
>
> We cascade the changes up to arch_get_unmapped_area_topdown() and
> arch_get_unmapped_area(), where, for now, we use vma_flags_to_legacy() in
> order to propagate the VMA flags.
>
> No functional change intended.
>
> Signed-off-by: Lorenzo Stoakes <ljs@kernel.org>
> ---
> fs/hugetlbfs/inode.c | 3 ++-
> include/linux/huge_mm.h | 10 +++++-----
> include/linux/mm.h | 6 ++++--
> include/linux/sched/mm.h | 12 ++++++------
> mm/huge_memory.c | 21 ++++++++++++---------
> mm/mmap.c | 27 ++++++++++++++-------------
> 6 files changed, 43 insertions(+), 36 deletions(-)
>
<snip>
> diff --git a/include/linux/sched/mm.h b/include/linux/sched/mm.h
> index 95d0040df584..b301ec90740a 100644
> --- a/include/linux/sched/mm.h
> +++ b/include/linux/sched/mm.h
> @@ -193,12 +193,12 @@ unsigned long mm_get_unmapped_area(struct file *filp, unsigned long addr,
> unsigned long len, unsigned long pgoff,
> unsigned long flags);
>
> -unsigned long mm_get_unmapped_area_vmflags(struct file *filp,
> - unsigned long addr,
> - unsigned long len,
> - unsigned long pgoff,
> - unsigned long flags,
> - vm_flags_t vm_flags);
> +unsigned long mm_get_unmapped_area_vmaflags(struct file *filp,
> + unsigned long addr,
> + unsigned long len,
> + unsigned long pgoff,
> + unsigned long flags,
> + vma_flags_t vma_flags);
Want to use two-tab indentation while at it?
<snip>
> @@ -812,19 +811,20 @@ arch_get_unmapped_area_topdown(struct file *filp, unsigned long addr,
> }
> #endif
>
> -unsigned long mm_get_unmapped_area_vmflags(struct file *filp, unsigned long addr,
> - unsigned long len, unsigned long pgoff,
> - unsigned long flags, vm_flags_t vm_flags)
> +unsigned long mm_get_unmapped_area_vmaflags(struct file *filp, unsigned long addr,
> + unsigned long len, unsigned long pgoff,
> + unsigned long flags, vma_flags_t vma_flags)
Ditto.
LGTM.
Reviewed-by: Zi Yan <ziy@nvidia.com>
--
Best Regards,
Yan, Zi
^ permalink raw reply
* Re: [PATCH 02/13] mm/vma: update do_mmap() to use vma_flags_t
From: Zi Yan @ 2026-07-07 2:10 UTC (permalink / raw)
To: Lorenzo Stoakes, Andrew Morton
Cc: Thomas Bogendoerfer, Madhavan Srinivasan, Michael Ellerman,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, Lucas Stach, Inki Dae, Seung-Woo Kim,
Kyungmin Park, Krzysztof Kozlowski, Peter Griffin, Jani Nikula,
Joonas Lahtinen, Rodrigo Vivi, Tvrtko Ursulin, Rob Clark,
Dmitry Baryshkov, Lyude Paul, Danilo Krummrich, Tomi Valkeinen,
Sandy Huang, Heiko Stübner, Andy Yan, Thierry Reding,
Mikko Perttunen, Jonathan Hunter, Gerd Hoffmann, Dmitry Osipenko,
Zack Rusin, Matthew Brost, Thomas Hellstrom,
Oleksandr Andrushchenko, Helge Deller, Benjamin LaHaise,
Alexander Viro, Christian Brauner, Muchun Song, Oscar Salvador,
David Hildenbrand, Baolin Wang, Liam R . Howlett, Nico Pache,
Ryan Roberts, Dev Jain, Barry Song, Lance Yang, Hugh Dickins,
Vlastimil Babka, Mike Rapoport, Suren Baghdasaryan, Michal Hocko,
Jann Horn, Pedro Falcato, Kees Cook, Jaroslav Kysela,
Takashi Iwai, linux-mips, linux-kernel, linuxppc-dev, dri-devel,
etnaviv, linux-arm-kernel, linux-samsung-soc, intel-gfx,
linux-arm-msm, freedreno, nouveau, linux-rockchip, linux-tegra,
virtualization, intel-xe, xen-devel, linux-fbdev, linux-aio,
linux-fsdevel, linux-mm, linux-sound
In-Reply-To: <e0ac58ad2b88ff7e2f0024e3286b2e786f79ca32.1782760670.git.ljs@kernel.org>
On Mon Jun 29, 2026 at 3:25 PM EDT, Lorenzo Stoakes wrote:
> The core do_mmap() function accepts a vm_flags_t parameter which it then
> manipulates before passing to mmap_region() to do the heavy lifting of the
> memory mapping.
>
> Update do_mmap() to instead accept a vma_flags_t parameter, and adjust all
> the logic within do_mmap() to manipulate this instead.
>
> This is as part of the ongoing effort to convert VMA flags from a system
> word size to a bitmap type which allows us to unrestrict the number of VMA
> flags, as well as gain control over how VMA flag manipulation occurs.
>
> We do not cascade these changes to all functions which accept vm_flags_t,
> but rather use vma_flags_to_legacy() where necessary, specifically
> deferring converting calc_vm_prot_bits(), calc_vm_flag_bits() and
> __get_unmapped_area() to vma_flags_t.
>
> Also utilise the new vma_flags_can_grow() predicate which correctly handles
> the case of architectures without upward growing stacks.
>
> As part of this change, introduce VMA_SHADOW_STACK so we can correctly
> handle the case of the shadow stack not being defined.
>
> No functional change intended.
>
> Signed-off-by: Lorenzo Stoakes <ljs@kernel.org>
> ---
> arch/mips/kernel/vdso.c | 4 +--
> fs/aio.c | 2 +-
> include/linux/memfd.h | 6 ++--
> include/linux/mm.h | 6 ++--
> ipc/shm.c | 3 +-
> mm/memfd.c | 15 ++++-----
> mm/mmap.c | 67 ++++++++++++++++++++++++-----------------
> mm/nommu.c | 3 +-
> mm/util.c | 10 +++---
> mm/vma.c | 7 ++---
> mm/vma.h | 2 +-
> 11 files changed, 69 insertions(+), 56 deletions(-)
>
<snip>
>
> -static int check_write_seal(vm_flags_t *vm_flags_ptr)
> +static int check_write_seal(vma_flags_t *vma_flags_ptr)
> {
> - vm_flags_t vm_flags = *vm_flags_ptr;
> - vm_flags_t mask = vm_flags & (VM_SHARED | VM_WRITE);
> -
> /* If a private mapping then writability is irrelevant. */
> - if (!(mask & VM_SHARED))
> + if (!vma_flags_test(vma_flags_ptr, VMA_SHARED_BIT))
> return 0;
>
> /*
> * New PROT_WRITE and MAP_SHARED mmaps are not allowed when
> * write seals are active.
> */
> - if (mask & VM_WRITE)
> + if (vma_flags_test(vma_flags_ptr, VMA_WRITE_BIT))
> return -EPERM;
>
> /*
> * This is a read-only mapping, disallow mprotect() from making a
> * write-sealed mapping writable in future.
> */
> - *vm_flags_ptr &= ~VM_MAYWRITE;
> + vma_flags_clear(vma_flags_ptr, VMA_MAYWRITE_BIT);
>
> return 0;
> }
This function alone changed its original behavior, since vm_flags is a
snapshot of *vm_flags_ptr, but after the change this snapshot is gone.
But its only caller memfd_check_seals_mmap() gets vm_flags_ptr from the
input parameter of do_mmap(), so the overall behavior does not change.
<snip>
> + case MAP_DROPPABLE: {
> + vma_flags_t droppable = VMA_DROPPABLE;
> +
> + if (vma_flags_empty(&droppable))
> return -EOPNOTSUPP;
> + vma_flags_set_mask(&vma_flags, droppable);
> +
> /*
> * A locked or stack area makes no sense to be droppable.
> *
> @@ -515,23 +527,24 @@ unsigned long do_mmap(struct file *file, unsigned long addr,
> */
> if (flags & (MAP_LOCKED | MAP_HUGETLB))
> return -EINVAL;
> - if (vm_flags & (VM_GROWSDOWN | VM_GROWSUP))
> + if (vma_flags_can_grow(&vma_flags))
> return -EINVAL;
>
> - vm_flags |= VM_DROPPABLE;
> -
Lance pointed out the reordering of setting VMA_DROPPABLE and checking
of can_grow, but these flags are not overlapped and there is no parallel
writer to vma_flags. So it is still no functional change, just not
mechanical changes. :)
Otherwise, LGTM.
Reviewed-by: Zi Yan <ziy@nvidia.com>
--
Best Regards,
Yan, Zi
^ permalink raw reply
* [PATCH] fbdev: udlfb: validate vendor descriptor items
From: Pengpeng Hou @ 2026-07-06 9:30 UTC (permalink / raw)
To: Bernie Thompson
Cc: Pengpeng Hou, Helge Deller, linux-fbdev, dri-devel, linux-kernel
dlfb_parse_vendor_descriptor() walks key-length-value items inside the
DisplayLink vendor descriptor.
Require each item to contain its key, length and declared value bytes
before reading item-specific fields such as max_area.
Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>
---
drivers/video/fbdev/udlfb.c | 22 ++++++++++++++++------
1 file changed, 16 insertions(+), 6 deletions(-)
diff --git a/drivers/video/fbdev/udlfb.c b/drivers/video/fbdev/udlfb.c
index fdbb8671a810..e78d6f95c9c5 100644
--- a/drivers/video/fbdev/udlfb.c
+++ b/drivers/video/fbdev/udlfb.c
@@ -1586,19 +1586,29 @@ static int dlfb_parse_vendor_descriptor(struct dlfb_data *dlfb,
desc += 5; /* the fixed header we've already parsed */
while (desc < desc_end) {
+ char *value;
u8 length;
u16 key;
- key = *desc++;
- key |= (u16)*desc++ << 8;
+ if (desc_end - desc < sizeof(key) + sizeof(length))
+ goto unrecognized;
+
+ key = get_unaligned_le16(desc);
+ desc += sizeof(key);
length = *desc++;
+ if (length > desc_end - desc)
+ goto unrecognized;
+
+ value = desc;
switch (key) {
case 0x0200: { /* max_area */
- u32 max_area = *desc++;
- max_area |= (u32)*desc++ << 8;
- max_area |= (u32)*desc++ << 16;
- max_area |= (u32)*desc++ << 24;
+ u32 max_area;
+
+ if (length < sizeof(max_area))
+ goto unrecognized;
+
+ max_area = get_unaligned_le32(value);
dev_warn(&intf->dev,
"DL chip limited to %d pixel modes\n",
max_area);
--
2.43.0
^ permalink raw reply related
* [PATCH] fbdev: sstfb: add missing MODULE_DEVICE_TABLE()
From: Pengpeng Hou @ 2026-07-05 0:14 UTC (permalink / raw)
To: Helge Deller; +Cc: Pengpeng Hou, linux-fbdev, dri-devel, linux-kernel
The driver has a match table for the pci bus wired into its driver
structure, but the table is not exported with MODULE_DEVICE_TABLE().
Add the missing MODULE_DEVICE_TABLE() entry so module alias information
is generated for automatic module loading.
This is a source-level fix. It does not claim dynamic hardware
reproduction; the evidence is the driver-owned match table, its use by
the driver registration structure, and the missing module alias
publication.
Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>
---
drivers/video/fbdev/sstfb.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/video/fbdev/sstfb.c b/drivers/video/fbdev/sstfb.c
index 2ea947f57efb..2745557822f7 100644
--- a/drivers/video/fbdev/sstfb.c
+++ b/drivers/video/fbdev/sstfb.c
@@ -1492,6 +1492,7 @@ static const struct pci_device_id sstfb_id_tbl[] = {
.driver_data = ID_VOODOO2, },
{ 0 },
};
+MODULE_DEVICE_TABLE(pci, sstfb_id_tbl);
static struct pci_driver sstfb_driver = {
.name = "sstfb",
--
2.53.0
^ permalink raw reply related
* Re: [PATCH 01/13] mm: introduce vma_flags_can_grow() and vma_can_grow()
From: Zi Yan @ 2026-07-03 15:19 UTC (permalink / raw)
To: Lorenzo Stoakes, Andrew Morton
Cc: Thomas Bogendoerfer, Madhavan Srinivasan, Michael Ellerman,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, Lucas Stach, Inki Dae, Seung-Woo Kim,
Kyungmin Park, Krzysztof Kozlowski, Peter Griffin, Jani Nikula,
Joonas Lahtinen, Rodrigo Vivi, Tvrtko Ursulin, Rob Clark,
Dmitry Baryshkov, Lyude Paul, Danilo Krummrich, Tomi Valkeinen,
Sandy Huang, Heiko Stübner, Andy Yan, Thierry Reding,
Mikko Perttunen, Jonathan Hunter, Gerd Hoffmann, Dmitry Osipenko,
Zack Rusin, Matthew Brost, Thomas Hellstrom,
Oleksandr Andrushchenko, Helge Deller, Benjamin LaHaise,
Alexander Viro, Christian Brauner, Muchun Song, Oscar Salvador,
David Hildenbrand, Baolin Wang, Liam R . Howlett, Nico Pache,
Ryan Roberts, Dev Jain, Barry Song, Lance Yang, Hugh Dickins,
Vlastimil Babka, Mike Rapoport, Suren Baghdasaryan, Michal Hocko,
Jann Horn, Pedro Falcato, Kees Cook, Jaroslav Kysela,
Takashi Iwai, linux-mips, linux-kernel, linuxppc-dev, dri-devel,
etnaviv, linux-arm-kernel, linux-samsung-soc, intel-gfx,
linux-arm-msm, freedreno, nouveau, linux-rockchip, linux-tegra,
virtualization, intel-xe, xen-devel, linux-fbdev, linux-aio,
linux-fsdevel, linux-mm, linux-sound
In-Reply-To: <f2e8c32515d328db62279cc8bab8398ea278d74f.1782760670.git.ljs@kernel.org>
On Mon Jun 29, 2026 at 3:25 PM EDT, Lorenzo Stoakes wrote:
> These test whether the VMA has stack sematics, i.e. is able to grow upwards
> or downwards depending on the architecture.
>
> In order to account for arches which do not support upward-growing stacks,
> introduce VMA_GROWSUP whose definition depends on the architecture
> supporting it, and use vma_flags_test_single_mask() in vma_flags_can_grow()
> to account for this.
>
> Update the VMA userland tests to reflect the changes
>
> No functional change intended.
>
> Signed-off-by: Lorenzo Stoakes <ljs@kernel.org>
> ---
> include/linux/mm.h | 21 ++++++++++++++++++---
> tools/testing/vma/include/dup.h | 4 ++++
> 2 files changed, 22 insertions(+), 3 deletions(-)
>
Reviewed-by: Zi Yan <ziy@nvidia.com>
--
Best Regards,
Yan, Zi
^ permalink raw reply
* Re: [PATCH v5 10/14] mfd: lm3533: Set DMA mask
From: Johan Hovold @ 2026-07-03 11:18 UTC (permalink / raw)
To: Svyatoslav Ryhel
Cc: Lee Jones, Daniel Thompson, Jingoo Han, Pavel Machek, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Jonathan Cameron,
David Lechner, Nuno Sá, Andy Shevchenko, Helge Deller,
dri-devel, linux-leds, devicetree, linux-kernel, linux-iio,
linux-fbdev
In-Reply-To: <20260617080031.99156-11-clamor95@gmail.com>
On Wed, Jun 17, 2026 at 11:00:27AM +0300, Svyatoslav Ryhel wrote:
> Missing coherent_dma_mask assigning triggers the following warning in
> dmesg:
>
> [ 3.287872] platform lm3533-backlight.0: DMA mask not set
>
> Since this warning might be elevated to an error in the future, set
> coherent_dma_mask to zero because both the core and cells do not utilize
> DMA.
IIUC this warning is introduced by the OF conversion and should
therefore be moved before it as a preparatory patch.
But you need to describe the problem in more detail here as this looks
fishy.
Johan
^ permalink raw reply
* Re: [PATCH v5 09/14] mfd: lm3533: Add support for VIN power supply
From: Johan Hovold @ 2026-07-03 11:09 UTC (permalink / raw)
To: Svyatoslav Ryhel
Cc: Lee Jones, Daniel Thompson, Jingoo Han, Pavel Machek, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Jonathan Cameron,
David Lechner, Nuno Sá, Andy Shevchenko, Helge Deller,
dri-devel, linux-leds, devicetree, linux-kernel, linux-iio,
linux-fbdev
In-Reply-To: <20260617080031.99156-10-clamor95@gmail.com>
On Wed, Jun 17, 2026 at 11:00:26AM +0300, Svyatoslav Ryhel wrote:
> Add support for 2.7V-5.5V VIN power supply.
>
> Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
> -static void lm3533_enable(struct lm3533 *lm3533)
> +static int lm3533_enable(struct lm3533 *lm3533)
> {
> + int ret;
> +
> + ret = regulator_enable(lm3533->vin_supply);
> + if (ret) {
> + dev_err(lm3533->dev, "failed to enable vin power supply\n");
> + return ret;
> + }
> +
No delay needed?
> gpiod_set_value(lm3533->hwen, 1);
> +
> + return 0;
> }
Johan
^ permalink raw reply
* Re: [PATCH v5 08/14] mfd: lm3533: Convert to use OF bindings
From: Johan Hovold @ 2026-07-03 11:03 UTC (permalink / raw)
To: Svyatoslav Ryhel
Cc: Lee Jones, Daniel Thompson, Jingoo Han, Pavel Machek, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Jonathan Cameron,
David Lechner, Nuno Sá, Andy Shevchenko, Helge Deller,
dri-devel, linux-leds, devicetree, linux-kernel, linux-iio,
linux-fbdev
In-Reply-To: <20260617080031.99156-9-clamor95@gmail.com>
On Wed, Jun 17, 2026 at 11:00:25AM +0300, Svyatoslav Ryhel wrote:
> Since there are no users of this driver via platform data, remove the
> platform data support and switch to using Device Tree bindings.
>
> Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
> Reviewed-by: Daniel Thompson (RISCstar) <danielt@kernel.org> #for backlight
> ---
> drivers/iio/light/lm3533-als.c | 67 +++++---
> drivers/leds/leds-lm3533.c | 50 ++++--
> drivers/mfd/lm3533-core.c | 236 ++++++++++++----------------
> drivers/mfd/lm3533-ctrlbank.c | 5 -
> drivers/video/backlight/lm3533_bl.c | 55 +++++--
> include/linux/mfd/lm3533.h | 52 +-----
> 6 files changed, 220 insertions(+), 245 deletions(-)
> static int lm3533_als_probe(struct platform_device *pdev)
> {
> - const struct lm3533_als_platform_data *pdata;
> struct lm3533 *lm3533;
> struct lm3533_als *als;
> struct iio_dev *indio_dev;
> @@ -803,12 +817,6 @@ static int lm3533_als_probe(struct platform_device *pdev)
> if (!lm3533)
> return -EINVAL;
>
> - pdata = dev_get_platdata(&pdev->dev);
> - if (!pdata) {
> - dev_err(&pdev->dev, "no platform data\n");
> - return -EINVAL;
> - }
> -
> indio_dev = devm_iio_device_alloc(&pdev->dev, sizeof(*als));
> if (!indio_dev)
> return -ENOMEM;
> @@ -817,25 +825,27 @@ static int lm3533_als_probe(struct platform_device *pdev)
> indio_dev->channels = lm3533_als_channels;
> indio_dev->num_channels = ARRAY_SIZE(lm3533_als_channels);
> indio_dev->name = dev_name(&pdev->dev);
> - iio_device_set_parent(indio_dev, pdev->dev.parent);
Why are you reparenting the iio device here?
That's an ABI break.
> +static const struct of_device_id lm3533_als_match_table[] = {
> + { .compatible = "ti,lm3533-als" },
> + { }
> +};
> +MODULE_DEVICE_TABLE(of, lm3533_als_match_table);
> +
> static struct platform_driver lm3533_als_driver = {
> .driver = {
> .name = "lm3533-als",
> + .of_match_table = lm3533_als_match_table,
> },
> .probe = lm3533_als_probe,
> .remove = lm3533_als_remove,
You should also remove the platform module alias below.
> diff --git a/drivers/leds/leds-lm3533.c b/drivers/leds/leds-lm3533.c
> index 0cb0585eb960..ed810c23f30f 100644
> --- a/drivers/leds/leds-lm3533.c
> +++ b/drivers/leds/leds-lm3533.c
> @@ -10,8 +10,10 @@
> #include <linux/module.h>
> #include <linux/leds.h>
> #include <linux/mfd/core.h>
> +#include <linux/mod_devicetable.h>
> #include <linux/mutex.h>
> #include <linux/platform_device.h>
> +#include <linux/property.h>
> #include <linux/regmap.h>
> #include <linux/slab.h>
>
> @@ -50,6 +52,9 @@ struct lm3533_led {
> struct mutex mutex;
> unsigned long flags;
>
> + u32 max_current;
> + u32 pwm;
> +
> bool have_als;
> };
>
> @@ -616,22 +621,20 @@ static const struct attribute_group *lm3533_led_attribute_groups[] = {
> NULL
> };
>
> -static int lm3533_led_setup(struct lm3533_led *led,
> - struct lm3533_led_platform_data *pdata)
> +static int lm3533_led_setup(struct lm3533_led *led)
> {
> int ret;
>
> - ret = lm3533_ctrlbank_set_max_current(&led->cb, pdata->max_current);
> + ret = lm3533_ctrlbank_set_max_current(&led->cb, led->max_current);
> if (ret)
> return ret;
>
> - return lm3533_ctrlbank_set_pwm(&led->cb, pdata->pwm);
> + return lm3533_ctrlbank_set_pwm(&led->cb, led->pwm);
> }
>
> static int lm3533_led_probe(struct platform_device *pdev)
> {
> struct lm3533 *lm3533;
> - struct lm3533_led_platform_data *pdata;
> struct lm3533_led *led;
> int ret;
>
> @@ -641,12 +644,6 @@ static int lm3533_led_probe(struct platform_device *pdev)
> if (!lm3533)
> return -EINVAL;
>
> - pdata = dev_get_platdata(&pdev->dev);
> - if (!pdata) {
> - dev_err(&pdev->dev, "no platform data\n");
> - return -EINVAL;
> - }
> -
> if (pdev->id < 0 || pdev->id >= LM3533_LVCTRLBANK_COUNT) {
> dev_err(&pdev->dev, "illegal LED id %d\n", pdev->id);
> return -EINVAL;
> @@ -659,8 +656,6 @@ static int lm3533_led_probe(struct platform_device *pdev)
> led->regmap = lm3533->regmap;
> led->have_als = lm3533->have_als;
>
> - led->cdev.name = pdata->name;
> - led->cdev.default_trigger = pdata->default_trigger;
> led->cdev.brightness_set_blocking = lm3533_led_set;
> led->cdev.brightness_get = lm3533_led_get;
> led->cdev.blink_set = lm3533_led_blink_set;
> @@ -668,6 +663,15 @@ static int lm3533_led_probe(struct platform_device *pdev)
> led->cdev.groups = lm3533_led_attribute_groups;
> led->id = pdev->id;
>
> + led->cdev.name = devm_kasprintf(&pdev->dev, GFP_KERNEL, "%s-%d",
> + pdev->name, led->id);
Is "led-2", etc. unique enough here?
> + if (!led->cdev.name)
> + return -ENOMEM;
> +
> + led->cdev.default_trigger = "none";
> + device_property_read_string(&pdev->dev, "linux,default-trigger",
> + &led->cdev.default_trigger);
> +
> mutex_init(&led->mutex);
>
> /* The class framework makes a callback to get brightness during
> @@ -680,15 +684,22 @@ static int lm3533_led_probe(struct platform_device *pdev)
>
> platform_set_drvdata(pdev, led);
>
> - ret = led_classdev_register(pdev->dev.parent, &led->cdev);
> + ret = led_classdev_register(&pdev->dev, &led->cdev);
Here too you appear to be reparenting the class devices.
> if (ret) {
> - dev_err(&pdev->dev, "failed to register LED %d\n", pdev->id);
> + dev_err(&pdev->dev, "failed to register LED %d\n", led->id);
This does not seem to be necessary.
> return ret;
> }
>
> led->cb.dev = led->cdev.dev;
>
> - ret = lm3533_led_setup(led, pdata);
> + device_property_read_u32(&pdev->dev, "led-max-microamp",
> + &led->max_current);
> + led->max_current = clamp(led->max_current, LM3533_MAX_CURRENT_MIN,
> + LM3533_MAX_CURRENT_MAX);
Why clamp instead of having lm3533_led_setup() fail below?
> +
> + device_property_read_u32(&pdev->dev, "ti,pwm-config-mask", &led->pwm);
> +
> + ret = lm3533_led_setup(led);
> if (ret)
> goto err_deregister;
>
> @@ -725,9 +736,16 @@ static void lm3533_led_shutdown(struct platform_device *pdev)
> lm3533_led_set(&led->cdev, LED_OFF); /* disable blink */
> }
>
> +static const struct of_device_id lm3533_led_match_table[] = {
> + { .compatible = "ti,lm3533-leds" },
> + { }
> +};
> +MODULE_DEVICE_TABLE(of, lm3533_led_match_table);
> +
> static struct platform_driver lm3533_led_driver = {
> .driver = {
> .name = "lm3533-leds",
> + .of_match_table = lm3533_led_match_table,
> },
> .probe = lm3533_led_probe,
> .remove = lm3533_led_remove,
Remove platform alias below as well.
> diff --git a/drivers/mfd/lm3533-core.c b/drivers/mfd/lm3533-core.c
> index b03a3ae96c10..a5aa7da9668b 100644
> --- a/drivers/mfd/lm3533-core.c
> +++ b/drivers/mfd/lm3533-core.c
> @@ -14,19 +14,26 @@
> #include <linux/gpio/consumer.h>
> #include <linux/i2c.h>
> #include <linux/mfd/core.h>
> +#include <linux/mod_devicetable.h>
> +#include <linux/property.h>
> #include <linux/regmap.h>
> #include <linux/seq_file.h>
> #include <linux/slab.h>
> #include <linux/uaccess.h>
> +#include <linux/units.h>
>
> #include <linux/mfd/lm3533.h>
>
>
> #define LM3533_BOOST_OVP_MASK 0x06
> #define LM3533_BOOST_OVP_SHIFT 1
> +#define LM3533_BOOST_OVP_MIN (16 * MICRO)
> +#define LM3533_BOOST_OVP_MAX (40 * MICRO)
>
> #define LM3533_BOOST_FREQ_MASK 0x01
> #define LM3533_BOOST_FREQ_SHIFT 0
> +#define LM3533_BOOST_FREQ_MIN (500 * HZ_PER_KHZ)
> +#define LM3533_BOOST_FREQ_MAX (1000 * HZ_PER_KHZ)
>
> #define LM3533_BL_ID_MASK 1
> #define LM3533_LED_ID_MASK 3
> @@ -35,6 +42,7 @@
>
> #define LM3533_HVLED_ID_MAX 2
> #define LM3533_LVLED_ID_MAX 5
> +#define LM3533_CELLS_MAX 7
>
> #define LM3533_REG_OUTPUT_CONF1 0x10
> #define LM3533_REG_OUTPUT_CONF2 0x11
> @@ -42,44 +50,6 @@
>
> #define LM3533_REG_MAX 0xb2
>
> -
> -static struct mfd_cell lm3533_als_devs[] = {
> - {
> - .name = "lm3533-als",
> - .id = -1,
> - },
> -};
> -
> -static struct mfd_cell lm3533_bl_devs[] = {
> - {
> - .name = "lm3533-backlight",
> - .id = 0,
> - },
> - {
> - .name = "lm3533-backlight",
> - .id = 1,
> - },
> -};
> -
> -static struct mfd_cell lm3533_led_devs[] = {
> - {
> - .name = "lm3533-leds",
> - .id = 0,
> - },
> - {
> - .name = "lm3533-leds",
> - .id = 1,
> - },
> - {
> - .name = "lm3533-leds",
> - .id = 2,
> - },
> - {
> - .name = "lm3533-leds",
> - .id = 3,
> - },
> -};
> -
> /*
> * HVLED output config -- output hvled controlled by backlight bl
> */
> @@ -301,125 +271,91 @@ static const struct attribute_group *lm3533_attribute_groups[] = {
> NULL,
> };
>
> -static int lm3533_device_als_init(struct lm3533 *lm3533)
> -{
> - struct lm3533_platform_data *pdata = dev_get_platdata(lm3533->dev);
> - int ret;
> -
> - if (!pdata->als)
> - return 0;
> -
> - lm3533_als_devs[0].platform_data = pdata->als;
> - lm3533_als_devs[0].pdata_size = sizeof(*pdata->als);
> -
> - ret = mfd_add_devices(lm3533->dev, 0, lm3533_als_devs, 1, NULL,
> - 0, NULL);
> - if (ret) {
> - dev_err(lm3533->dev, "failed to add ALS device\n");
> - return ret;
> - }
> -
> - lm3533->have_als = 1;
> -
> - return 0;
> -}
> -
> -static int lm3533_device_bl_init(struct lm3533 *lm3533)
> -{
> - struct lm3533_platform_data *pdata = dev_get_platdata(lm3533->dev);
> - int i;
> - int ret;
> -
> - if (!pdata->backlights || pdata->num_backlights == 0)
> - return 0;
> -
> - if (pdata->num_backlights > ARRAY_SIZE(lm3533_bl_devs))
> - pdata->num_backlights = ARRAY_SIZE(lm3533_bl_devs);
> -
> - for (i = 0; i < pdata->num_backlights; ++i) {
> - lm3533_bl_devs[i].platform_data = &pdata->backlights[i];
> - lm3533_bl_devs[i].pdata_size = sizeof(pdata->backlights[i]);
> - }
> -
> - ret = mfd_add_devices(lm3533->dev, 0, lm3533_bl_devs,
> - pdata->num_backlights, NULL, 0, NULL);
> - if (ret) {
> - dev_err(lm3533->dev, "failed to add backlight devices\n");
> - return ret;
> - }
> -
> - lm3533->have_backlights = 1;
> -
> - return 0;
> -}
> -
> -static int lm3533_device_led_init(struct lm3533 *lm3533)
> -{
> - struct lm3533_platform_data *pdata = dev_get_platdata(lm3533->dev);
> - int i;
> - int ret;
> -
> - if (!pdata->leds || pdata->num_leds == 0)
> - return 0;
> -
> - if (pdata->num_leds > ARRAY_SIZE(lm3533_led_devs))
> - pdata->num_leds = ARRAY_SIZE(lm3533_led_devs);
> -
> - for (i = 0; i < pdata->num_leds; ++i) {
> - lm3533_led_devs[i].platform_data = &pdata->leds[i];
> - lm3533_led_devs[i].pdata_size = sizeof(pdata->leds[i]);
> - }
> -
> - ret = mfd_add_devices(lm3533->dev, 0, lm3533_led_devs,
> - pdata->num_leds, NULL, 0, NULL);
> - if (ret) {
> - dev_err(lm3533->dev, "failed to add LED devices\n");
> - return ret;
> - }
> -
> - lm3533->have_leds = 1;
> -
> - return 0;
> -}
> -
> static int lm3533_device_init(struct lm3533 *lm3533)
> {
> - struct lm3533_platform_data *pdata = dev_get_platdata(lm3533->dev);
> + struct device *dev = lm3533->dev;
> + struct mfd_cell *lm3533_devices;
> + u32 count = 0, reg, nchilds;
Don't mix multiple declarations with initialisation like this.
> int ret;
>
> - dev_dbg(lm3533->dev, "%s\n", __func__);
> + nchilds = device_get_child_node_count(dev);
> + if (!nchilds || nchilds > LM3533_CELLS_MAX)
> + return dev_err_probe(dev, -ENODEV,
> + "num of child nodes is not supported\n");
>
> - if (!pdata) {
> - dev_err(lm3533->dev, "no platform data\n");
> - return -EINVAL;
> - }
> + lm3533_devices = devm_kcalloc(dev, nchilds, sizeof(*lm3533_devices),
> + GFP_KERNEL);
> + if (!lm3533_devices)
> + return -ENOMEM;
>
> - lm3533->hwen = devm_gpiod_get(lm3533->dev, NULL, GPIOD_OUT_LOW);
> - if (IS_ERR(lm3533->hwen))
> - return dev_err_probe(lm3533->dev, PTR_ERR(lm3533->hwen), "failed to request HWEN GPIO\n");
> - gpiod_set_consumer_name(lm3533->hwen, "lm3533-hwen");
> + device_for_each_child_node_scoped(dev, child) {
> + if (count >= nchilds)
> + break;
How could count be larger than nchilds?
> +
> + if (fwnode_device_is_compatible(child, "ti,lm3533-als")) {
> + lm3533_devices[count].name = "lm3533-als";
> + lm3533_devices[count].of_compatible = "ti,lm3533-als";
> + lm3533_devices[count].id = PLATFORM_DEVID_NONE;
> +
> + lm3533->have_als = true;
> + count++;
> + } else if (fwnode_device_is_compatible(child, "ti,lm3533-backlight")) {
> + ret = fwnode_property_read_u32(child, "reg", ®);
> + if (ret || reg >= LM3533_HVLED_ID_MAX) {
> + dev_err(dev, "invalid backlight node %pfw\n", child);
> + continue;
> + }
> +
> + lm3533_devices[count].name = "lm3533-backlight";
> + lm3533_devices[count].of_compatible = "ti,lm3533-backlight";
> + lm3533_devices[count].id = reg;
> + lm3533_devices[count].of_reg = reg;
> + lm3533_devices[count].use_of_reg = true;
> +
> + lm3533->have_backlights = true;
> + count++;
> + } else if (fwnode_device_is_compatible(child, "ti,lm3533-leds")) {
> + ret = fwnode_property_read_u32(child, "reg", ®);
> + if (ret || reg < LM3533_HVLED_ID_MAX ||
> + reg > LM3533_LVLED_ID_MAX) {
> + dev_err(dev, "invalid LED node %pfw\n", child);
> + continue;
> + }
> +
> + lm3533_devices[count].name = "lm3533-leds";
> + lm3533_devices[count].of_compatible = "ti,lm3533-leds";
> + lm3533_devices[count].id = reg - LM3533_HVLED_ID_MAX;
> + lm3533_devices[count].of_reg = reg;
> + lm3533_devices[count].use_of_reg = true;
> +
> + lm3533->have_leds = true;
> + count++;
> + }
> + }
Why do you need the above at all? Shouldn't you be able to just use
of_platform_populate().
>
> lm3533_enable(lm3533);
>
> ret = regmap_update_bits(lm3533->regmap, LM3533_REG_BOOST_PWM,
> LM3533_BOOST_FREQ_MASK,
> - pdata->boost_freq << LM3533_BOOST_FREQ_SHIFT);
> + lm3533->boost_freq << LM3533_BOOST_FREQ_SHIFT);
> if (ret) {
> - dev_err(lm3533->dev, "failed to set boost frequency\n");
> + dev_err(dev, "failed to set boost frequency\n");
> goto err_disable;
> }
>
> ret = regmap_update_bits(lm3533->regmap, LM3533_REG_BOOST_PWM,
> LM3533_BOOST_OVP_MASK,
> - pdata->boost_ovp << LM3533_BOOST_OVP_SHIFT);
> + lm3533->boost_ovp << LM3533_BOOST_OVP_SHIFT);
> if (ret) {
> - dev_err(lm3533->dev, "failed to set boost ovp\n");
> + dev_err(dev, "failed to set boost ovp\n");
> goto err_disable;
> }
>
> - lm3533_device_als_init(lm3533);
> - lm3533_device_bl_init(lm3533);
> - lm3533_device_led_init(lm3533);
> + ret = mfd_add_devices(dev, 0, lm3533_devices, count, NULL, 0, NULL);
> + if (ret) {
> + dev_err(dev, "failed to add MFD devices: %d\n", ret);
> + goto err_disable;
> + }
>
> return 0;
>
> @@ -504,7 +440,26 @@ static int lm3533_i2c_probe(struct i2c_client *i2c)
> return PTR_ERR(lm3533->regmap);
>
> lm3533->dev = &i2c->dev;
> - lm3533->irq = i2c->irq;
> +
> + lm3533->hwen = devm_gpiod_get_optional(lm3533->dev, "enable",
> + GPIOD_OUT_LOW);
> + if (IS_ERR(lm3533->hwen))
> + return dev_err_probe(lm3533->dev, PTR_ERR(lm3533->hwen),
> + "failed to get HWEN GPIO\n");
Please use brackets around multline statements for readability
throughout.
> +
> + device_property_read_u32(lm3533->dev, "ti,boost-ovp-microvolt",
> + &lm3533->boost_ovp);
> +
> + lm3533->boost_ovp = clamp(lm3533->boost_ovp, LM3533_BOOST_OVP_MIN,
> + LM3533_BOOST_OVP_MAX);
> + lm3533->boost_ovp = lm3533->boost_ovp / (8 * MICRO) - 2;
> +
> + device_property_read_u32(lm3533->dev, "ti,boost-freq-hz",
> + &lm3533->boost_freq);
> +
> + lm3533->boost_freq = clamp(lm3533->boost_freq, LM3533_BOOST_FREQ_MIN,
> + LM3533_BOOST_FREQ_MAX);
> + lm3533->boost_freq = lm3533->boost_freq / (500 * KILO) - 1;
Again, why clamp instead of failing probe?
> return lm3533_device_init(lm3533);
> }
> @@ -518,6 +473,12 @@ static void lm3533_i2c_remove(struct i2c_client *i2c)
> lm3533_device_exit(lm3533);
> }
>
> +static const struct of_device_id lm3533_match_table[] = {
> + { .compatible = "ti,lm3533" },
> + { }
> +};
> +MODULE_DEVICE_TABLE(of, lm3533_match_table);
> +
> static const struct i2c_device_id lm3533_i2c_ids[] = {
> { "lm3533" },
> { }
> @@ -528,6 +489,7 @@ static struct i2c_driver lm3533_i2c_driver = {
> .driver = {
> .name = "lm3533",
> .dev_groups = lm3533_attribute_groups,
> + .of_match_table = lm3533_match_table,
> },
> .id_table = lm3533_i2c_ids,
> .probe = lm3533_i2c_probe,
> diff --git a/drivers/mfd/lm3533-ctrlbank.c b/drivers/mfd/lm3533-ctrlbank.c
> index 91e13cfa3cf0..3aab8ece4e8c 100644
> --- a/drivers/mfd/lm3533-ctrlbank.c
> +++ b/drivers/mfd/lm3533-ctrlbank.c
> @@ -13,11 +13,6 @@
>
> #include <linux/mfd/lm3533.h>
>
> -
> -#define LM3533_MAX_CURRENT_MIN 5000
> -#define LM3533_MAX_CURRENT_MAX 29800
> -#define LM3533_MAX_CURRENT_STEP 800
> -
> #define LM3533_PWM_MAX 0x3f
>
> #define LM3533_REG_PWM_BASE 0x14
> diff --git a/drivers/video/backlight/lm3533_bl.c b/drivers/video/backlight/lm3533_bl.c
> index 9ef171d3aaea..2c24647fc17a 100644
> --- a/drivers/video/backlight/lm3533_bl.c
> +++ b/drivers/video/backlight/lm3533_bl.c
> @@ -9,7 +9,9 @@
>
> #include <linux/module.h>
> #include <linux/init.h>
> +#include <linux/mod_devicetable.h>
> #include <linux/platform_device.h>
> +#include <linux/property.h>
> #include <linux/backlight.h>
> #include <linux/regmap.h>
> #include <linux/slab.h>
> @@ -29,6 +31,9 @@ struct lm3533_bl {
> struct backlight_device *bd;
> int id;
>
> + u32 max_current;
> + u32 pwm;
> +
> bool have_als;
> };
>
> @@ -242,25 +247,25 @@ static const struct attribute_group *lm3533_bl_attribute_groups[] = {
> NULL,
> };
>
> -static int lm3533_bl_setup(struct lm3533_bl *bl,
> - struct lm3533_bl_platform_data *pdata)
> +static int lm3533_bl_setup(struct lm3533_bl *bl)
> {
> int ret;
>
> - ret = lm3533_ctrlbank_set_max_current(&bl->cb, pdata->max_current);
> + ret = lm3533_ctrlbank_set_max_current(&bl->cb, bl->max_current);
> if (ret)
> return ret;
>
> - return lm3533_ctrlbank_set_pwm(&bl->cb, pdata->pwm);
> + return lm3533_ctrlbank_set_pwm(&bl->cb, bl->pwm);
> }
>
> static int lm3533_bl_probe(struct platform_device *pdev)
> {
> struct lm3533 *lm3533;
> - struct lm3533_bl_platform_data *pdata;
> struct lm3533_bl *bl;
> struct backlight_device *bd;
> struct backlight_properties props;
> + char *name = NULL;
> + u32 default_brightness = LM3533_BL_MAX_BRIGHTNESS;
> int ret;
>
> dev_dbg(&pdev->dev, "%s\n", __func__);
> @@ -269,12 +274,6 @@ static int lm3533_bl_probe(struct platform_device *pdev)
> if (!lm3533)
> return -EINVAL;
>
> - pdata = dev_get_platdata(&pdev->dev);
> - if (!pdata) {
> - dev_err(&pdev->dev, "no platform data\n");
> - return -EINVAL;
> - }
> -
> if (pdev->id < 0 || pdev->id >= LM3533_HVCTRLBANK_COUNT) {
> dev_err(&pdev->dev, "illegal backlight id %d\n", pdev->id);
> return -EINVAL;
> @@ -292,13 +291,21 @@ static int lm3533_bl_probe(struct platform_device *pdev)
> bl->cb.id = lm3533_bl_get_ctrlbank_id(bl);
> bl->cb.dev = NULL; /* until registered */
>
> + name = devm_kasprintf(&pdev->dev, GFP_KERNEL, "%s-%d",
> + pdev->name, pdev->id);
Unique enough (e.g. backlight-0)?
> + if (!name)
> + return -ENOMEM;
> +
> + device_property_read_u32(&pdev->dev, "default-brightness",
> + &default_brightness);
> +
> memset(&props, 0, sizeof(props));
> props.type = BACKLIGHT_RAW;
> props.max_brightness = LM3533_BL_MAX_BRIGHTNESS;
> - props.brightness = pdata->default_brightness;
> - bd = devm_backlight_device_register(&pdev->dev, pdata->name,
> - pdev->dev.parent, bl, &lm3533_bl_ops,
> - &props);
> + props.brightness = default_brightness;
> +
> + bd = devm_backlight_device_register(&pdev->dev, name, &pdev->dev,
> + bl, &lm3533_bl_ops, &props);
Here too you are reparenting, which results in an ABI break.
> if (IS_ERR(bd)) {
> dev_err(&pdev->dev, "failed to register backlight device\n");
> return PTR_ERR(bd);
> @@ -309,12 +316,19 @@ static int lm3533_bl_probe(struct platform_device *pdev)
>
> platform_set_drvdata(pdev, bl);
>
> - backlight_update_status(bd);
> + device_property_read_u32(&pdev->dev, "led-max-microamp",
> + &bl->max_current);
> + bl->max_current = clamp(bl->max_current, LM3533_MAX_CURRENT_MIN,
> + LM3533_MAX_CURRENT_MAX);
Clamping instead of failing.
>
> - ret = lm3533_bl_setup(bl, pdata);
> + device_property_read_u32(&pdev->dev, "ti,pwm-config-mask", &bl->pwm);
> +
> + ret = lm3533_bl_setup(bl);
> if (ret)
> return ret;
>
> + backlight_update_status(bd);
> +
> ret = lm3533_ctrlbank_enable(&bl->cb);
> if (ret)
> return ret;
> @@ -366,11 +380,18 @@ static void lm3533_bl_shutdown(struct platform_device *pdev)
> lm3533_ctrlbank_disable(&bl->cb);
> }
>
> +static const struct of_device_id lm3533_bl_match_table[] = {
> + { .compatible = "ti,lm3533-backlight" },
> + { }
> +};
> +MODULE_DEVICE_TABLE(of, lm3533_bl_match_table);
> +
> static struct platform_driver lm3533_bl_driver = {
> .driver = {
> .name = "lm3533-backlight",
> .pm = &lm3533_bl_pm_ops,
> .dev_groups = lm3533_bl_attribute_groups,
> + .of_match_table = lm3533_bl_match_table,
> },
> .probe = lm3533_bl_probe,
> .remove = lm3533_bl_remove,
Drop platform module alias below.
Johan
^ permalink raw reply
* Re: [PATCH v5 07/14] mfd: lm3533: Use dev_groups in struct device_driver
From: Johan Hovold @ 2026-07-03 10:11 UTC (permalink / raw)
To: Svyatoslav Ryhel
Cc: Lee Jones, Daniel Thompson, Jingoo Han, Pavel Machek, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Jonathan Cameron,
David Lechner, Nuno Sá, Andy Shevchenko, Helge Deller,
dri-devel, linux-leds, devicetree, linux-kernel, linux-iio,
linux-fbdev
In-Reply-To: <20260617080031.99156-8-clamor95@gmail.com>
On Wed, Jun 17, 2026 at 11:00:24AM +0300, Svyatoslav Ryhel wrote:
> Instead of creating and removing the device sysfs attributes directly
> during probe and remove of the driver, respectively, use dev_groups in
> struct device_driver to point to the attribute definitions and let the
> core take care of creating and removing them.
>
> No intentional functional impact.
>
> Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
Reviewed-by: Johan Hovold <johan@kernel.org>
^ permalink raw reply
* Re: [PATCH v5 06/14] mfd: lm3533-core: Remove redundant pdata helpers
From: Johan Hovold @ 2026-07-03 9:57 UTC (permalink / raw)
To: Svyatoslav Ryhel
Cc: Lee Jones, Daniel Thompson, Jingoo Han, Pavel Machek, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Jonathan Cameron,
David Lechner, Nuno Sá, Andy Shevchenko, Helge Deller,
dri-devel, linux-leds, devicetree, linux-kernel, linux-iio,
linux-fbdev
In-Reply-To: <20260617080031.99156-7-clamor95@gmail.com>
On Wed, Jun 17, 2026 at 11:00:23AM +0300, Svyatoslav Ryhel wrote:
> The lm3533_set_boost_freq() and lm3533_set_boost_ovp() functions are used
> only in lm3533_device_setup(), which in turn is only called by
> lm3533_device_init(). Incorporate their code directly into
> lm3533_device_init() to simplify driver readability.
Again, this isn't needed. Why are you removing abstraction that improve
readability?
Johan
^ permalink raw reply
* Re: [PATCH v5 05/14] iio: light: lm3533-als: Remove redundant pdata helpers
From: Johan Hovold @ 2026-07-03 9:55 UTC (permalink / raw)
To: Svyatoslav Ryhel
Cc: Lee Jones, Daniel Thompson, Jingoo Han, Pavel Machek, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Jonathan Cameron,
David Lechner, Nuno Sá, Andy Shevchenko, Helge Deller,
dri-devel, linux-leds, devicetree, linux-kernel, linux-iio,
linux-fbdev
In-Reply-To: <20260617080031.99156-6-clamor95@gmail.com>
On Wed, Jun 17, 2026 at 11:00:22AM +0300, Svyatoslav Ryhel wrote:
> The lm3533_als_set_input_mode() and lm3533_als_set_resistor() functions
> are used only in lm3533_als_setup(). Incorporate their code into
> lm3533_als_setup() directly to simplify driver readability.
That's a debatable claim.
> Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
> ---
> drivers/iio/light/lm3533-als.c | 56 ++++++++++------------------------
> 1 file changed, 16 insertions(+), 40 deletions(-)
>
> diff --git a/drivers/iio/light/lm3533-als.c b/drivers/iio/light/lm3533-als.c
> index a9af8e2b965f..69bac1b202f1 100644
> --- a/drivers/iio/light/lm3533-als.c
> +++ b/drivers/iio/light/lm3533-als.c
> -static int lm3533_als_setup(struct lm3533_als *als,
> - const struct lm3533_als_platform_data *pdata)
> -{
> - int ret;
> -
> - ret = lm3533_als_set_input_mode(als, pdata->pwm_mode);
> + pdata->r_select);
> if (ret)
> - return ret;
> -
> - /* ALS input is always high impedance in PWM-mode. */
> - if (!pdata->pwm_mode) {
> - ret = lm3533_als_set_resistor(als, pdata->r_select);
> - if (ret)
> - return ret;
> - }
> + return dev_err_probe(dev, ret, "failed to set resistor\n");
> return 0;
> }
There's nothing hard to read about the above. To the contrary the logic
is more obvious this way.
You also remove the high-impedance comment for no good reason.
Johan
^ 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