* [PATCH v2 13/13] mm/mremap: convert mremap code to use vma_flags_t
From: Lorenzo Stoakes @ 2026-07-11 18:45 UTC (permalink / raw)
To: Andrew Morton, David Hildenbrand, Liam R. Howlett,
Vlastimil Babka, Mike Rapoport, Suren Baghdasaryan, Michal Hocko,
Thomas Bogendoerfer, Benjamin LaHaise, Alexander Viro,
Christian Brauner, Jan Kara, Hugh Dickins, Baolin Wang, Jann Horn,
Pedro Falcato, Muchun Song, Oscar Salvador, Zi Yan, Nico Pache,
Ryan Roberts, Dev Jain, Barry Song, Lance Yang, Usama Arif,
Madhavan Srinivasan, Michael Ellerman, Nicholas Piggin,
Christophe Leroy (CS GROUP), Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Lucas Stach,
Russell King, Christian Gmeiner, Inki Dae, Seung-Woo Kim,
Kyungmin Park, Krzysztof Kozlowski, Peter Griffin, Alim Akhtar,
Jani Nikula, Joonas Lahtinen, Rodrigo Vivi, Tvrtko Ursulin,
Rob Clark, Dmitry Baryshkov, Abhinav Kumar, Jessica Zhang,
Sean Paul, Marijn Suijten, Lyude Paul, Danilo Krummrich,
Tomi Valkeinen, Sandy Huang, Heiko Stübner, Andy Yan,
Thierry Reding, Mikko Perttunen, Jonathan Hunter, Gerd Hoffmann,
Dmitry Osipenko, Gurchetan Singh, Chia-I Wu, Zack Rusin,
Broadcom internal kernel review list, Matthew Brost,
Thomas Hellström, Oleksandr Andrushchenko, Helge Deller,
Kees Cook, Jaroslav Kysela, Takashi Iwai, Boris Brezillon,
Steven Price, Liviu Dudau
Cc: Lorenzo Stoakes, linux-mm, linux-kernel, linux-mips, linux-aio,
linux-fsdevel, 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-sound
In-Reply-To: <20260711-b4-vma-flags-mm-v2-0-0fa2357d5431@kernel.org>
Replace use of the legacy vm_flags_t flags with vma_flags_t values
throughout the mremap logic.
Note that, in replacing vm_flags_clear() (which takes the VMA write lock)
with vma_clear_flags() and vma_clear_flags_mask() (which do not)
respectively in unmap_source_vma() and dontunmap_complete(), we do not add
a VMA write lock to account for htis.
This is because, in both cases, move_vma() is their calling function and
this has already acquired the VMA write lock on vrm->vma whose VMA flags
are being cleared.
In the case of vma_set_flags() in unmap_source_vma() we do need to do this
- as prev and next were not necessarily write locked at this point.
Additionally update comments to reflect the changes to be consistent.
No functional change intended.
Reviewed-by: Zi Yan <ziy@nvidia.com>
Signed-off-by: Lorenzo Stoakes <ljs@kernel.org>
---
mm/mremap.c | 38 ++++++++++++++++++++------------------
1 file changed, 20 insertions(+), 18 deletions(-)
diff --git a/mm/mremap.c b/mm/mremap.c
index 384ef4cc2195..b64aa1f6e07e 100644
--- a/mm/mremap.c
+++ b/mm/mremap.c
@@ -68,7 +68,7 @@ struct vma_remap_struct {
bool populate_expand; /* mlock()'d expanded, must populate. */
enum mremap_type remap_type; /* expand, shrink, etc. */
bool mmap_locked; /* Is mm currently write-locked? */
- unsigned long charged; /* If VM_ACCOUNT, # pages to account. */
+ unsigned long charged; /* If VMA_ACCOUNT_BIT, # pgs to account */
bool vmi_needs_invalidate; /* Is the VMA iterator invalidated? */
};
@@ -963,7 +963,7 @@ static unsigned long vrm_set_new_addr(struct vma_remap_struct *vrm)
if (vrm->flags & MREMAP_FIXED)
map_flags |= MAP_FIXED;
- if (vma->vm_flags & VM_MAYSHARE)
+ if (vma_test(vma, VMA_MAYSHARE_BIT))
map_flags |= MAP_SHARED;
res = get_unmapped_area(vma->vm_file, new_addr, vrm->new_len, pgoff,
@@ -985,7 +985,7 @@ static bool vrm_calc_charge(struct vma_remap_struct *vrm)
{
unsigned long charged;
- if (!(vrm->vma->vm_flags & VM_ACCOUNT))
+ if (!vma_test(vrm->vma, VMA_ACCOUNT_BIT))
return true;
/*
@@ -1012,7 +1012,7 @@ static bool vrm_calc_charge(struct vma_remap_struct *vrm)
*/
static void vrm_uncharge(struct vma_remap_struct *vrm)
{
- if (!(vrm->vma->vm_flags & VM_ACCOUNT))
+ if (!vma_test(vrm->vma, VMA_ACCOUNT_BIT))
return;
vm_unacct_memory(vrm->charged);
@@ -1032,7 +1032,7 @@ static void vrm_stat_account(struct vma_remap_struct *vrm,
struct vm_area_struct *vma = vrm->vma;
vm_stat_account(mm, vma->vm_flags, pages);
- if (vma->vm_flags & VM_LOCKED)
+ if (vma_test(vma, VMA_LOCKED_BIT))
mm->locked_vm += pages;
}
@@ -1176,7 +1176,7 @@ static void unmap_source_vma(struct vma_remap_struct *vrm)
* arose, in which case we _do_ wish to unmap the _new_ VMA, which means
* we actually _do_ want it be unaccounted.
*/
- bool accountable_move = (vma->vm_flags & VM_ACCOUNT) &&
+ bool accountable_move = vma_test(vma, VMA_ACCOUNT_BIT) &&
!(vrm->flags & MREMAP_DONTUNMAP);
/*
@@ -1195,7 +1195,7 @@ static void unmap_source_vma(struct vma_remap_struct *vrm)
* portions of the original VMA that remain.
*/
if (accountable_move) {
- vm_flags_clear(vma, VM_ACCOUNT);
+ vma_clear_flags(vma, VMA_ACCOUNT_BIT);
/* We are about to split vma, so store the start/end. */
vm_start = vma->vm_start;
vm_end = vma->vm_end;
@@ -1220,8 +1220,8 @@ static void unmap_source_vma(struct vma_remap_struct *vrm)
* | |
* |-------------|
*
- * Having cleared VM_ACCOUNT from the whole VMA, after we unmap above
- * we'll end up with:
+ * Having cleared VMA_ACCOUNT_BIT from the whole VMA, after we unmap
+ * above we'll end up with:
*
* addr end
* | |
@@ -1241,13 +1241,15 @@ static void unmap_source_vma(struct vma_remap_struct *vrm)
if (vm_start < addr) {
struct vm_area_struct *prev = vma_prev(&vmi);
- vm_flags_set(prev, VM_ACCOUNT); /* Acquires VMA lock. */
+ vma_start_write(prev);
+ vma_set_flags(prev, VMA_ACCOUNT_BIT);
}
if (vm_end > end) {
struct vm_area_struct *next = vma_next(&vmi);
- vm_flags_set(next, VM_ACCOUNT); /* Acquires VMA lock. */
+ vma_start_write(next);
+ vma_set_flags(next, VMA_ACCOUNT_BIT);
}
}
}
@@ -1330,8 +1332,8 @@ static void dontunmap_complete(struct vma_remap_struct *vrm,
unsigned long old_start = vrm->vma->vm_start;
unsigned long old_end = vrm->vma->vm_end;
- /* We always clear VM_LOCKED[ONFAULT] on the old VMA. */
- vm_flags_clear(vrm->vma, VM_LOCKED_MASK);
+ /* We always clear VMA_LOCKED[ONFAULT]_BIT on the old VMA. */
+ vma_clear_flags_mask(vrm->vma, VMA_LOCKED_MASK);
/*
* anon_vma links of the old vma is no longer needed after its page
@@ -1767,14 +1769,14 @@ static int check_prep_vma(struct vma_remap_struct *vrm)
* based on the original. There are no known use cases for this
* behavior. As a result, fail such attempts.
*/
- if (!old_len && !(vma->vm_flags & (VM_SHARED | VM_MAYSHARE))) {
+ if (!old_len && !vma_test_any(vma, VMA_SHARED_BIT, VMA_MAYSHARE_BIT)) {
pr_warn_once("%s (%d): attempted to duplicate a private mapping with mremap. This is not supported.\n",
current->comm, current->pid);
return -EINVAL;
}
if ((vrm->flags & MREMAP_DONTUNMAP) &&
- (vma->vm_flags & (VM_DONTEXPAND | VM_PFNMAP)))
+ vma_test_any(vma, VMA_DONTEXPAND_BIT, VMA_PFNMAP_BIT))
return -EINVAL;
/*
@@ -1804,7 +1806,7 @@ static int check_prep_vma(struct vma_remap_struct *vrm)
return 0;
/* We are expanding and the VMA is mlock()'d so we need to populate. */
- if (vma->vm_flags & VM_LOCKED)
+ if (vma_test(vma, VMA_LOCKED_BIT))
vrm->populate_expand = true;
/* Need to be careful about a growing mapping */
@@ -1812,10 +1814,10 @@ static int check_prep_vma(struct vma_remap_struct *vrm)
if (pgoff + (new_len >> PAGE_SHIFT) < pgoff)
return -EINVAL;
- if (vma->vm_flags & (VM_DONTEXPAND | VM_PFNMAP))
+ if (vma_test_any(vma, VMA_DONTEXPAND_BIT, VMA_PFNMAP_BIT))
return -EFAULT;
- if (!mlock_future_ok(mm, vma->vm_flags & VM_LOCKED, vrm->delta))
+ if (!mlock_future_ok(mm, vma_test(vma, VMA_LOCKED_BIT), vrm->delta))
return -EAGAIN;
if (!may_expand_vm(mm, &vma->flags, vrm->delta >> PAGE_SHIFT))
--
2.55.0
^ permalink raw reply related
* [PATCH] staging: sm750fb: fix CamelCase naming checks
From: toveno @ 2026-07-12 11:33 UTC (permalink / raw)
To: sudipm.mukherjee, teddy.wang, gregkh, teamakeads
Cc: linux-fbdev, linux-staging
Fix checkpatch.pl issues regarding CamelCase naming conventions by
converting internal driver variables to standard lowercase snake_case.
- Rename pvReg to pv_reg
- Rename setAllEngOff to set_all_eng_off
Signed-off-by: toveno <teamakeads@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 89c811e0806c..716a8935f58d 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 +
0x800f0 + (int)crtc->channel * 0x140;
crtc->cursor.max_h = 64;
@@ -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 */
@@ -1047,7 +1047,7 @@ static void lynxfb_pci_remove(struct pci_dev *pdev)
sm750fb_framebuffer_release(sm750_dev);
arch_phys_wc_del(sm750_dev->mtrr.vram);
- iounmap(sm750_dev->pvReg);
+ iounmap(sm750_dev->pv_reg);
iounmap(sm750_dev->vmem);
pci_release_region(pdev, 1);
kfree(g_settings);
diff --git a/drivers/staging/sm750fb/sm750.h b/drivers/staging/sm750fb/sm750.h
index d2c522e67f26..e8885133da2e 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;
};
@@ -97,7 +97,7 @@ struct sm750_dev {
unsigned long vidreg_start;
__u32 vidmem_size;
__u32 vidreg_size;
- void __iomem *pvReg;
+ void __iomem *pv_reg;
unsigned char __iomem *vmem;
/* locks*/
spinlock_t slock;
diff --git a/drivers/staging/sm750fb/sm750_hw.c b/drivers/staging/sm750fb/sm750_hw.c
index 34a837fb4b64..95f797e5776a 100644
--- a/drivers/staging/sm750fb/sm750_hw.c
+++ b/drivers/staging/sm750fb/sm750_hw.c
@@ -23,18 +23,18 @@ int hw_sm750_map(struct sm750_dev *sm750_dev, struct pci_dev *pdev)
}
/* now map mmio and vidmem */
- sm750_dev->pvReg =
+ sm750_dev->pv_reg =
ioremap(sm750_dev->vidreg_start, sm750_dev->vidreg_size);
- if (!sm750_dev->pvReg) {
+ if (!sm750_dev->pv_reg) {
dev_err(&pdev->dev, "mmio failed\n");
ret = -EFAULT;
goto err_release_region;
}
- sm750_dev->accel.dpr_base = sm750_dev->pvReg + DE_BASE_ADDR_TYPE1;
- sm750_dev->accel.dp_port_base = sm750_dev->pvReg + DE_PORT_ADDR_TYPE1;
+ sm750_dev->accel.dpr_base = sm750_dev->pv_reg + DE_BASE_ADDR_TYPE1;
+ sm750_dev->accel.dp_port_base = sm750_dev->pv_reg + DE_PORT_ADDR_TYPE1;
- mmio750 = sm750_dev->pvReg;
+ mmio750 = sm750_dev->pv_reg;
sm750_set_chip_type(sm750_dev->devid, sm750_dev->revid);
sm750_dev->vidmem_start = pci_resource_start(pdev, 0);
@@ -58,7 +58,7 @@ int hw_sm750_map(struct sm750_dev *sm750_dev, struct pci_dev *pdev)
return 0;
err_unmap_reg:
- iounmap(sm750_dev->pvReg);
+ iounmap(sm750_dev->pv_reg);
err_release_region:
pci_release_region(pdev, 1);
return ret;
--
2.55.0
^ permalink raw reply related
* Re: [PATCH] staging: sm750fb: fix CamelCase naming checks
From: Greg KH @ 2026-07-12 11:56 UTC (permalink / raw)
To: toveno; +Cc: sudipm.mukherjee, teddy.wang, linux-fbdev, linux-staging
In-Reply-To: <20260712113315.38615-1-teamakeads@gmail.com>
On Sun, Jul 12, 2026 at 02:33:15PM +0300, toveno wrote:
> Fix checkpatch.pl issues regarding CamelCase naming conventions by
> converting internal driver variables to standard lowercase snake_case.
> - Rename pvReg to pv_reg
Please read the email archives for why this type of rename is not
correct. (hint, think about the name you just picked...)
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH 09/16] ASoC: dt-bindings: add OpenPandora Sound Card
From: Krzysztof Kozlowski @ 2026-07-13 7:37 UTC (permalink / raw)
To: H. Nikolaus Schaller
Cc: Grond, Stefan Leichter, Grazvydas Ignotas, Tony Lindgren,
Ethan Nelson-Moore, Jarkko Nikula, Sascha Hauer, Andreas Kemnade,
Lee Jones, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Liam Girdwood, Mark Brown, Aaro Koskinen, Kevin Hilman,
Roger Quadros, Russell King, Daniel Thompson, Jingoo Han,
Helge Deller, Jaroslav Kysela, Takashi Iwai, Sen Wang,
Richard Fitzgerald, Arnd Bergmann, Srinivas Kandagatla,
Kuninori Morimoto, Charles Keepax, Niranjan H Y, letux-kernel,
devicetree, linux-kernel, linux-sound, linux-omap,
linux-arm-kernel, dri-devel, linux-fbdev, kernel, mfd
In-Reply-To: <7989e699de400c0fe3f0cb7af77a54077784df78.1783749722.git.hns@goldelico.com>
On Sat, Jul 11, 2026 at 08:01:56AM +0200, H. Nikolaus Schaller wrote:
> The OpenPandora audio subsystem describes the routing links between the
> OMAP3 McBSP interface, the external PCM1773 DAC, and the TWL4030 audio
> codec, alongside amplifiers and power supplies.
>
> Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com>
> ---
> .../sound/openpandora,omap3pandora-sound.yaml | 94 +++++++++++++++++++
> 1 file changed, 94 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/sound/openpandora,omap3pandora-sound.yaml
>
> diff --git a/Documentation/devicetree/bindings/sound/openpandora,omap3pandora-sound.yaml b/Documentation/devicetree/bindings/sound/openpandora,omap3pandora-sound.yaml
> new file mode 100644
> index 0000000000000..d3c747e5c58d6
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/sound/openpandora,omap3pandora-sound.yaml
> @@ -0,0 +1,94 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org
> +$schema: http://devicetree.org
This wasn't ever tested. Why?
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 07/16] ASoC: dt-bindings: add TI PCM1773
From: Krzysztof Kozlowski @ 2026-07-13 7:38 UTC (permalink / raw)
To: H. Nikolaus Schaller
Cc: Grond, Stefan Leichter, Grazvydas Ignotas, Tony Lindgren,
Ethan Nelson-Moore, Jarkko Nikula, Sascha Hauer, Andreas Kemnade,
Lee Jones, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Liam Girdwood, Mark Brown, Aaro Koskinen, Kevin Hilman,
Roger Quadros, Russell King, Daniel Thompson, Jingoo Han,
Helge Deller, Jaroslav Kysela, Takashi Iwai, Sen Wang,
Richard Fitzgerald, Arnd Bergmann, Srinivas Kandagatla,
Kuninori Morimoto, Charles Keepax, Niranjan H Y, letux-kernel,
devicetree, linux-kernel, linux-sound, linux-omap,
linux-arm-kernel, dri-devel, linux-fbdev, kernel, mfd
In-Reply-To: <a02383ea5907a677f4c61066d423efde2b9de48b.1783749722.git.hns@goldelico.com>
On Sat, Jul 11, 2026 at 08:01:54AM +0200, H. Nikolaus Schaller wrote:
> PCM1771/3 is a simple audio codec that can be enabled through an
> enable-gpio.
>
> Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com>
> ---
> .../devicetree/bindings/sound/pcm1773.yaml | 32 +++++++++++++++++++
> 1 file changed, 32 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/sound/pcm1773.yaml
>
> diff --git a/Documentation/devicetree/bindings/sound/pcm1773.yaml b/Documentation/devicetree/bindings/sound/pcm1773.yaml
> new file mode 100644
> index 0000000000000..f3e640705bf70
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/sound/pcm1773.yaml
> @@ -0,0 +1,32 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/bindings/sound/pcm1773.yaml#
You need to use latest existing bindings as starting point and test your
code.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 01/16] dt-bindings: twl-regulator: Add bindings for exposing ti,twl4030-regen
From: Krzysztof Kozlowski @ 2026-07-13 7:39 UTC (permalink / raw)
To: H. Nikolaus Schaller
Cc: Grond, Stefan Leichter, Grazvydas Ignotas, Tony Lindgren,
Ethan Nelson-Moore, Jarkko Nikula, Sascha Hauer, Andreas Kemnade,
Lee Jones, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Liam Girdwood, Mark Brown, Aaro Koskinen, Kevin Hilman,
Roger Quadros, Russell King, Daniel Thompson, Jingoo Han,
Helge Deller, Jaroslav Kysela, Takashi Iwai, Sen Wang,
Richard Fitzgerald, Arnd Bergmann, Srinivas Kandagatla,
Kuninori Morimoto, Charles Keepax, Niranjan H Y, letux-kernel,
devicetree, linux-kernel, linux-sound, linux-omap,
linux-arm-kernel, dri-devel, linux-fbdev, kernel, mfd
In-Reply-To: <00718b18253a764c2a7c9a2b95c3b8c411796583.1783749722.git.hns@goldelico.com>
On Sat, Jul 11, 2026 at 08:01:48AM +0200, H. Nikolaus Schaller wrote:
> From: Grond <grond66@riseup.net>
>
> FIXME: not reflected in the bindings
>
> +Reguired properties:
> +For twl3040 REGEN signal:
> + - regulator-min-microvolt:
> + - Same meaning as in bindings/regulator/regulator.yaml, but must match
> + regulator-max-microvolt.
> + - regulator-max-microvolt:
> + - Same meaning as in bindings/regulator/regulator.yaml, but must match
> + regulator-min-microvolt.
> + - startup-delay-us:
> + - Same meaning as in bindings/regulator/fixed-regulator.yaml.
I don't know what that means.
>
> Signed-off-by: Grond <grond66@riseup.net>
As explicitly written in submitting patches: we do not take anonymous
contributions.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 01/16] dt-bindings: twl-regulator: Add bindings for exposing ti,twl4030-regen
From: H. Nikolaus Schaller @ 2026-07-13 8:26 UTC (permalink / raw)
To: Krzysztof Kozlowski, Grond
Cc: Stefan Leichter, Grazvydas Ignotas, Tony Lindgren,
Ethan Nelson-Moore, Jarkko Nikula, Sascha Hauer, Andreas Kemnade,
Lee Jones, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Liam Girdwood, Mark Brown, Aaro Koskinen, Kevin Hilman,
Roger Quadros, Russell King, Daniel Thompson, Jingoo Han,
Helge Deller, Jaroslav Kysela, Takashi Iwai, Sen Wang,
Richard Fitzgerald, Arnd Bergmann, Srinivas Kandagatla,
Kuninori Morimoto, Charles Keepax, Niranjan H Y, letux-kernel,
devicetree, linux-kernel, linux-sound, linux-omap,
linux-arm-kernel, dri-devel, linux-fbdev, kernel, mfd
In-Reply-To: <20260713-aquatic-memorable-griffin-cf9e46@quoll>
Hi Krzysztof,
Thank you for the feedback.
> Am 13.07.2026 um 09:39 schrieb Krzysztof Kozlowski <krzk@kernel.org>:
>
> On Sat, Jul 11, 2026 at 08:01:48AM +0200, H. Nikolaus Schaller wrote:
>> From: Grond <grond66@riseup.net>
>>
>> FIXME: not reflected in the bindings
>>
>> +Reguired properties:
>> +For twl3040 REGEN signal:
>> + - regulator-min-microvolt:
>> + - Same meaning as in bindings/regulator/regulator.yaml, but must match
>> + regulator-max-microvolt.
>> + - regulator-max-microvolt:
>> + - Same meaning as in bindings/regulator/regulator.yaml, but must match
>> + regulator-min-microvolt.
>> + - startup-delay-us:
>> + - Same meaning as in bindings/regulator/fixed-regulator.yaml.
>
> I don't know what that means.
>
>>
>> Signed-off-by: Grond <grond66@riseup.net>
>
> As explicitly written in submitting patches: we do not take anonymous
> contributions.
Thanks for pointing this out. In more than 10 years of contributing, I actually have never run into this specific issue before.
To give some context: this is a contribution we received on our mailing list about 5 years ago. We do not know the author personally, but the code looks good and has been thoroughly tested by us. I kept their Signed-off-by because I didn't want to falsely claim authorship.
Unless he answers to this mail, what would be the best way to proceed?
Should I keep him as the Author: in the git metadata but remove the pseudo-anonymous Signed-off-by, and instead add my own Signed-off-by (and perhaps a Co-developed-by or From: note) to certify the Developer's Certificate of Origin (DCO) myself?
Anyways this will likely be reworked based on the sahiko-bot recommendations to make regen not a regulator but a gpio that can be controlled by a separate regulator-fixed. This will also clarify/remove the "same meaning" statements and ambiguities.
Thanks and BR,
Nikolaus
^ permalink raw reply
* Re: [PATCH 09/16] ASoC: dt-bindings: add OpenPandora Sound Card
From: H. Nikolaus Schaller @ 2026-07-13 8:27 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Grond, Stefan Leichter, Grazvydas Ignotas, Tony Lindgren,
Ethan Nelson-Moore, Jarkko Nikula, Sascha Hauer, Andreas Kemnade,
Lee Jones, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Liam Girdwood, Mark Brown, Aaro Koskinen, Kevin Hilman,
Roger Quadros, Russell King, Daniel Thompson, Jingoo Han,
Helge Deller, Jaroslav Kysela, Takashi Iwai, Sen Wang,
Richard Fitzgerald, Arnd Bergmann, Srinivas Kandagatla,
Kuninori Morimoto, Charles Keepax, Niranjan H Y, letux-kernel,
devicetree, linux-kernel, linux-sound, linux-omap,
linux-arm-kernel, dri-devel, linux-fbdev, kernel, mfd
In-Reply-To: <20260713-infallible-capable-dormouse-aaaebe@quoll>
Hi Krzysztof,
Thank you for the feedback.
> Am 13.07.2026 um 09:37 schrieb Krzysztof Kozlowski <krzk@kernel.org>:
>
> On Sat, Jul 11, 2026 at 08:01:56AM +0200, H. Nikolaus Schaller wrote:
>> The OpenPandora audio subsystem describes the routing links between the
>> OMAP3 McBSP interface, the external PCM1773 DAC, and the TWL4030 audio
>> codec, alongside amplifiers and power supplies.
>>
>> Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com>
>> ---
>> .../sound/openpandora,omap3pandora-sound.yaml | 94 +++++++++++++++++++
>> 1 file changed, 94 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/sound/openpandora,omap3pandora-sound.yaml
>>
>> diff --git a/Documentation/devicetree/bindings/sound/openpandora,omap3pandora-sound.yaml b/Documentation/devicetree/bindings/sound/openpandora,omap3pandora-sound.yaml
>> new file mode 100644
>> index 0000000000000..d3c747e5c58d6
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/sound/openpandora,omap3pandora-sound.yaml
>> @@ -0,0 +1,94 @@
>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>> +%YAML 1.2
>> +---
>> +$id: http://devicetree.org
>> +$schema: http://devicetree.org
>
> This wasn't ever tested. Why?
It does not emit any C compiler issues or runtime problems so it remained unnoticed.
It was notified by the sahiko-bot and will be fixed in v2.
Thanks and BR,
Nikolaus
^ permalink raw reply
* Re: [PATCH 07/16] ASoC: dt-bindings: add TI PCM1773
From: H. Nikolaus Schaller @ 2026-07-13 8:27 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: linux-fbdev, Kuninori Morimoto, Tony Lindgren, dri-devel,
Liam Girdwood, Niranjan H Y, Sen Wang, Rob Herring, Aaro Koskinen,
Kevin Hilman, Helge Deller, Lee Jones, Russell King, linux-omap,
Daniel Thompson, Grazvydas Ignotas, devicetree, Conor Dooley,
Charles Keepax, Arnd Bergmann, Sascha Hauer, mfd, linux-sound,
Richard Fitzgerald, Mark Brown, Takashi Iwai, Jaroslav Kysela,
Srinivas Kandagatla, linux-arm-kernel, Roger Quadros, Jingoo Han,
linux-kernel, kernel, Jarkko Nikula, Ethan Nelson-Moore,
Discussions about the Letux Kernel
In-Reply-To: <20260713-abiding-jumping-ape-7ce8ff@quoll>
Hi Krzysztof,
Thank you for the feedback.
> Am 13.07.2026 um 09:38 schrieb Krzysztof Kozlowski <krzk@kernel.org>:
>
> On Sat, Jul 11, 2026 at 08:01:54AM +0200, H. Nikolaus Schaller wrote:
>> PCM1771/3 is a simple audio codec that can be enabled through an
>> enable-gpio.
>>
>> Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com>
>> ---
>> .../devicetree/bindings/sound/pcm1773.yaml | 32 +++++++++++++++++++
>> 1 file changed, 32 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/sound/pcm1773.yaml
>>
>> diff --git a/Documentation/devicetree/bindings/sound/pcm1773.yaml b/Documentation/devicetree/bindings/sound/pcm1773.yaml
>> new file mode 100644
>> index 0000000000000..f3e640705bf70
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/sound/pcm1773.yaml
>> @@ -0,0 +1,32 @@
>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>> +%YAML 1.2
>> +---
>> +$id: http://devicetree.org/schemas/bindings/sound/pcm1773.yaml#
>
> You need to use latest existing bindings as starting point and test your
> code.
Resulting code from compiler was runtime tested.
Actually, we used the latest bindings of some other audio dac as a starting point.
However, we introduced errors into the finally submitted file.
We will verify and test the schema next time.
Regarding the checks: both the rob herring bot and the sashiko bot also reported several issues directly to us,
so we are already aware of some other remaining errors.
We are currently working on a v2 to clean everything up.
Thanks and BR,
Nikolaus
^ permalink raw reply
* Re: [PATCH 01/16] dt-bindings: twl-regulator: Add bindings for exposing ti,twl4030-regen
From: Krzysztof Kozlowski @ 2026-07-13 9:19 UTC (permalink / raw)
To: H. Nikolaus Schaller, Grond
Cc: Stefan Leichter, Grazvydas Ignotas, Tony Lindgren,
Ethan Nelson-Moore, Jarkko Nikula, Sascha Hauer, Andreas Kemnade,
Lee Jones, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Liam Girdwood, Mark Brown, Aaro Koskinen, Kevin Hilman,
Roger Quadros, Russell King, Daniel Thompson, Jingoo Han,
Helge Deller, Jaroslav Kysela, Takashi Iwai, Sen Wang,
Richard Fitzgerald, Arnd Bergmann, Srinivas Kandagatla,
Kuninori Morimoto, Charles Keepax, Niranjan H Y, letux-kernel,
devicetree, linux-kernel, linux-sound, linux-omap,
linux-arm-kernel, dri-devel, linux-fbdev, kernel, mfd
In-Reply-To: <3D58F644-3EAA-4BE7-88FB-1DCEAE7D5768@goldelico.com>
On 13/07/2026 10:26, H. Nikolaus Schaller wrote:
> Hi Krzysztof,
>
> Thank you for the feedback.
>
>> Am 13.07.2026 um 09:39 schrieb Krzysztof Kozlowski <krzk@kernel.org>:
>>
>> On Sat, Jul 11, 2026 at 08:01:48AM +0200, H. Nikolaus Schaller wrote:
>>> From: Grond <grond66@riseup.net>
>>>
>>> FIXME: not reflected in the bindings
>>>
>>> +Reguired properties:
>>> +For twl3040 REGEN signal:
>>> + - regulator-min-microvolt:
>>> + - Same meaning as in bindings/regulator/regulator.yaml, but must match
>>> + regulator-max-microvolt.
>>> + - regulator-max-microvolt:
>>> + - Same meaning as in bindings/regulator/regulator.yaml, but must match
>>> + regulator-min-microvolt.
>>> + - startup-delay-us:
>>> + - Same meaning as in bindings/regulator/fixed-regulator.yaml.
>>
>> I don't know what that means.
>>
>>>
>>> Signed-off-by: Grond <grond66@riseup.net>
>>
>> As explicitly written in submitting patches: we do not take anonymous
>> contributions.
>
> Thanks for pointing this out. In more than 10 years of contributing, I actually have never run into this specific issue before.
>
> To give some context: this is a contribution we received on our mailing list about 5 years ago. We do not know the author personally, but the code looks good and has been thoroughly tested by us. I kept their Signed-off-by because I didn't want to falsely claim authorship.
Take the authorship. You are allowed to do that by both DCO and common
sense (you are not doing something immoral, unless author shows
interest/hints to fix it by themself).
Commit msg also needs fixing/rewriting.
Beside, one more nit since there will be a new version:
A nit, subject: drop second/last, redundant "bindings for". The
"dt-bindings" prefix is already stating that these are bindings.
See also:
https://elixir.bootlin.com/linux/v7.1-rc7/source/Documentation/devicetree/bindings/submitting-patches.rst#L23
Also, please wrap your replies to mailing list wrapping style.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 09/16] ASoC: dt-bindings: add OpenPandora Sound Card
From: Krzysztof Kozlowski @ 2026-07-13 9:21 UTC (permalink / raw)
To: H. Nikolaus Schaller
Cc: Grond, Stefan Leichter, Grazvydas Ignotas, Tony Lindgren,
Ethan Nelson-Moore, Jarkko Nikula, Sascha Hauer, Andreas Kemnade,
Lee Jones, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Liam Girdwood, Mark Brown, Aaro Koskinen, Kevin Hilman,
Roger Quadros, Russell King, Daniel Thompson, Jingoo Han,
Helge Deller, Jaroslav Kysela, Takashi Iwai, Sen Wang,
Richard Fitzgerald, Arnd Bergmann, Srinivas Kandagatla,
Kuninori Morimoto, Charles Keepax, Niranjan H Y, letux-kernel,
devicetree, linux-kernel, linux-sound, linux-omap,
linux-arm-kernel, dri-devel, linux-fbdev, kernel, mfd
In-Reply-To: <BF2B6C4A-A4CC-48D7-9854-DC014950184B@goldelico.com>
On 13/07/2026 10:27, H. Nikolaus Schaller wrote:
> Hi Krzysztof,
>
> Thank you for the feedback.
>
>> Am 13.07.2026 um 09:37 schrieb Krzysztof Kozlowski <krzk@kernel.org>:
>>
>> On Sat, Jul 11, 2026 at 08:01:56AM +0200, H. Nikolaus Schaller wrote:
>>> The OpenPandora audio subsystem describes the routing links between the
>>> OMAP3 McBSP interface, the external PCM1773 DAC, and the TWL4030 audio
>>> codec, alongside amplifiers and power supplies.
>>>
>>> Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com>
>>> ---
>>> .../sound/openpandora,omap3pandora-sound.yaml | 94 +++++++++++++++++++
>>> 1 file changed, 94 insertions(+)
>>> create mode 100644 Documentation/devicetree/bindings/sound/openpandora,omap3pandora-sound.yaml
>>>
>>> diff --git a/Documentation/devicetree/bindings/sound/openpandora,omap3pandora-sound.yaml b/Documentation/devicetree/bindings/sound/openpandora,omap3pandora-sound.yaml
>>> new file mode 100644
>>> index 0000000000000..d3c747e5c58d6
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/sound/openpandora,omap3pandora-sound.yaml
>>> @@ -0,0 +1,94 @@
>>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>>> +%YAML 1.2
>>> +---
>>> +$id: http://devicetree.org
>>> +$schema: http://devicetree.org
>>
>> This wasn't ever tested. Why?
>
> It does not emit any C compiler issues or runtime problems so it remained unnoticed.
I do not believe.
There is a clear warning from Rob's bot.
You just did not follow the process of building the code (compiler has
nothing to do here). Read submitting patches in DT dir and then writing
schema for further instructions. This is ABSOLUTE MINIMUM. We are not
your build test service.
>
> It was notified by the sahiko-bot and will be fixed in v2.
Sashiko has nothing to do with that.
You DID NOT BUILD the code.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 09/16] ASoC: dt-bindings: add OpenPandora Sound Card
From: H. Nikolaus Schaller @ 2026-07-13 9:38 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Grond, Stefan Leichter, Grazvydas Ignotas, Tony Lindgren,
Ethan Nelson-Moore, Jarkko Nikula, Sascha Hauer, Andreas Kemnade,
Lee Jones, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Liam Girdwood, Mark Brown, Aaro Koskinen, Kevin Hilman,
Roger Quadros, Russell King, Daniel Thompson, Jingoo Han,
Helge Deller, Jaroslav Kysela, Takashi Iwai, Sen Wang,
Richard Fitzgerald, Arnd Bergmann, Srinivas Kandagatla,
Kuninori Morimoto, Charles Keepax, Niranjan H Y, letux-kernel,
devicetree, linux-kernel, linux-sound, linux-omap,
linux-arm-kernel, dri-devel, linux-fbdev, kernel, mfd
In-Reply-To: <5667350d-cc3f-421d-899f-f353b05c5ea1@kernel.org>
> Am 13.07.2026 um 11:21 schrieb Krzysztof Kozlowski <krzk@kernel.org>:
>
> On 13/07/2026 10:27, H. Nikolaus Schaller wrote:
>> Hi Krzysztof,
>>
>> Thank you for the feedback.
>>
>>
>> It does not emit any C compiler issues or runtime problems so it remained unnoticed.
>
> I do not believe.
>
> There is a clear warning from Rob's bot.
>
> You just did not follow the process of building the code (compiler has
> nothing to do here). Read submitting patches in DT dir and then writing
> schema for further instructions. This is ABSOLUTE MINIMUM. We are not
> your build test service.
>
>>
>> It was notified by the sahiko-bot and will be fixed in v2.
>
> Sashiko has nothing to do with that.
>
> You DID NOT BUILD the code.
Hm. You are confusing me. I did "make" and did not get any errors...
And the resulting code works as intended.
Best regards and thanks,
Nikolaus
^ permalink raw reply
* Re: [PATCH 01/16] dt-bindings: twl-regulator: Add bindings for exposing ti,twl4030-regen
From: H. Nikolaus Schaller @ 2026-07-13 9:36 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Grond, Stefan Leichter, Grazvydas Ignotas, Tony Lindgren,
Ethan Nelson-Moore, Jarkko Nikula, Sascha Hauer, Andreas Kemnade,
Lee Jones, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Liam Girdwood, Mark Brown, Aaro Koskinen, Kevin Hilman,
Roger Quadros, Russell King, Daniel Thompson, Jingoo Han,
Helge Deller, Jaroslav Kysela, Takashi Iwai, Sen Wang,
Richard Fitzgerald, Arnd Bergmann, Srinivas Kandagatla,
Kuninori Morimoto, Charles Keepax, Niranjan H Y, letux-kernel,
devicetree, linux-kernel, linux-sound, linux-omap,
linux-arm-kernel, dri-devel, linux-fbdev, kernel, mfd
In-Reply-To: <17497012-97d8-4c52-89b8-f433179f1eda@kernel.org>
> Am 13.07.2026 um 11:19 schrieb Krzysztof Kozlowski <krzk@kernel.org>:
>
> On 13/07/2026 10:26, H. Nikolaus Schaller wrote:
>> Hi Krzysztof,
>>
>> Thank you for the feedback.
>>
>>> Am 13.07.2026 um 09:39 schrieb Krzysztof Kozlowski <krzk@kernel.org>:
>>>
>>> On Sat, Jul 11, 2026 at 08:01:48AM +0200, H. Nikolaus Schaller wrote:
>>>> From: Grond <grond66@riseup.net>
>>>>
>>>
>>>>
>>>> Signed-off-by: Grond <grond66@riseup.net>
>>>
>>> As explicitly written in submitting patches: we do not take anonymous
>>> contributions.
>>
>> Thanks for pointing this out. In more than 10 years of contributing, I actually have never run into this specific issue before.
>>
>> To give some context: this is a contribution we received on our mailing list about 5 years ago. We do not know the author personally, but the code looks good and has been thoroughly tested by us. I kept their Signed-off-by because I didn't want to falsely claim authorship.
>
> Take the authorship. You are allowed to do that by both DCO and common
> sense (you are not doing something immoral, unless author shows
> interest/hints to fix it by themself).
Ok, let's give him some days to respond. Thanks for the procedure
to resolve a potential deadlock.
>
> Commit msg also needs fixing/rewriting.
>
> Beside, one more nit since there will be a new version:
>
> A nit, subject: drop second/last, redundant "bindings for". The
> "dt-bindings" prefix is already stating that these are bindings.
Ok.
> Best regards,
> Krzysztof
^ permalink raw reply
* Re: [PATCH 09/16] ASoC: dt-bindings: add OpenPandora Sound Card
From: Krzysztof Kozlowski @ 2026-07-13 9:42 UTC (permalink / raw)
To: H. Nikolaus Schaller
Cc: Grond, Stefan Leichter, Grazvydas Ignotas, Tony Lindgren,
Ethan Nelson-Moore, Jarkko Nikula, Sascha Hauer, Andreas Kemnade,
Lee Jones, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Liam Girdwood, Mark Brown, Aaro Koskinen, Kevin Hilman,
Roger Quadros, Russell King, Daniel Thompson, Jingoo Han,
Helge Deller, Jaroslav Kysela, Takashi Iwai, Sen Wang,
Richard Fitzgerald, Arnd Bergmann, Srinivas Kandagatla,
Kuninori Morimoto, Charles Keepax, Niranjan H Y, letux-kernel,
devicetree, linux-kernel, linux-sound, linux-omap,
linux-arm-kernel, dri-devel, linux-fbdev, kernel, mfd
In-Reply-To: <8A0C119B-7885-4538-8D4F-AC60E5C91B7E@goldelico.com>
On 13/07/2026 11:38, H. Nikolaus Schaller wrote:
>
>
>> Am 13.07.2026 um 11:21 schrieb Krzysztof Kozlowski <krzk@kernel.org>:
>>
>> On 13/07/2026 10:27, H. Nikolaus Schaller wrote:
>>> Hi Krzysztof,
>>>
>>> Thank you for the feedback.
>>>
>>>
>>> It does not emit any C compiler issues or runtime problems so it remained unnoticed.
>>
>> I do not believe.
>>
>> There is a clear warning from Rob's bot.
>>
>> You just did not follow the process of building the code (compiler has
>> nothing to do here). Read submitting patches in DT dir and then writing
>> schema for further instructions. This is ABSOLUTE MINIMUM. We are not
>> your build test service.
>>
>>>
>>> It was notified by the sahiko-bot and will be fixed in v2.
>>
>> Sashiko has nothing to do with that.
>>
>> You DID NOT BUILD the code.
>
> Hm. You are confusing me. I did "make" and did not get any errors...
> And the resulting code works as intended.
'make' alone does not build that, just like other pieces of code they
have own - well documented and always expected - build processes.
I don't know what is confusing in my message, since I pointed you to
SPECIFIC guide telling you EXACTLY what to do (and which you did not do).
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH] fbdev: arkfb: Move a variable assignment behind a condition check in ics5342_init()
From: Markus Elfring @ 2026-07-13 10:18 UTC (permalink / raw)
To: linux-fbdev, dri-devel, Helge Deller, Kees Cook,
Uwe Kleine-König
Cc: LKML, kernel-janitors
From: Markus Elfring <elfring@users.sourceforge.net>
Date: Mon, 13 Jul 2026 12:12:52 +0200
The address of a data structure member was determined before
a corresponding null pointer check in the implementation of
the function “ics5342_init”.
Thus avoid the risk for undefined behaviour by moving the assignment
for the variable “info” behind a condition check.
This issue was detected by using the Coccinelle software.
Fixes: ede481f6dad47d40b7e561cfbc6c04286a9faf1a ("fbdev: arkfb: Cast ics5342_init() allocation type")
Cc: stable@vger.kernel.org
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
drivers/video/fbdev/arkfb.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/arkfb.c b/drivers/video/fbdev/arkfb.c
index 195dbf4a5142..9658f407b79a 100644
--- a/drivers/video/fbdev/arkfb.c
+++ b/drivers/video/fbdev/arkfb.c
@@ -432,11 +432,12 @@ static struct dac_ops ics5342_ops = {
static struct dac_info * ics5342_init(dac_read_regs_t drr, dac_write_regs_t dwr, void *data)
{
struct ics5342_info *ics_info = kzalloc_obj(struct ics5342_info);
- struct dac_info *info = &ics_info->dac;
+ struct dac_info *info;
if (!ics_info)
return NULL;
+ info = &ics_info->dac;
info->dacops = &ics5342_ops;
info->dac_read_regs = drr;
info->dac_write_regs = dwr;
--
2.55.0
^ permalink raw reply related
* [PATCH] fbdev: pvr2fb: correct user pointer annotation and sentinel initializer
From: Florian Fuchs @ 2026-07-13 10:16 UTC (permalink / raw)
To: Helge Deller, John Paul Adrian Glaubitz
Cc: Uwe Kleine-König, linux-fbdev, dri-devel, linux-kernel,
Florian Fuchs, kernel test robot
Add __user annotation to buf, as it is passed as a user pointer in
pin_user_pages_fast(). Use an empty initializer for the sentinel
board-table entry to avoid initializing a function pointer with an
integer literal.
Fixes: 5f566c0ac51c ("fbdev: pvr2fb: Fix leftover reference to ONCHIP_NR_DMA_CHANNELS")
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202607131247.fpQ6eTc7-lkp@intel.com/
Signed-off-by: Florian Fuchs <fuchsfl@gmail.com>
---
Not sure, if we do such changes, but as I received a test robot email, I
leave it up to you all :) (I also compiled and tested the change)
drivers/video/fbdev/pvr2fb.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/video/fbdev/pvr2fb.c b/drivers/video/fbdev/pvr2fb.c
index 9428716e2dc4..a6e7abca7a06 100644
--- a/drivers/video/fbdev/pvr2fb.c
+++ b/drivers/video/fbdev/pvr2fb.c
@@ -639,7 +639,7 @@ static irqreturn_t __maybe_unused pvr2fb_interrupt(int irq, void *dev_id)
}
#ifdef CONFIG_PVR2_DMA
-static ssize_t pvr2fb_write(struct fb_info *info, const char *buf,
+static ssize_t pvr2fb_write(struct fb_info *info, const char __user *buf,
size_t count, loff_t *ppos)
{
unsigned long dst, start, end, len;
@@ -1077,7 +1077,7 @@ static struct pvr2_board {
#ifdef CONFIG_PCI
{ pvr2fb_pci_init, pvr2fb_pci_exit, "PCI PVR2" },
#endif
- { 0, },
+ { },
};
static int __init pvr2fb_init(void)
--
2.43.0
^ permalink raw reply related
* Re: [PATCH 09/16] ASoC: dt-bindings: add OpenPandora Sound Card
From: H. Nikolaus Schaller @ 2026-07-13 11:53 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Grond, Stefan Leichter, Grazvydas Ignotas, Tony Lindgren,
Ethan Nelson-Moore, Jarkko Nikula, Sascha Hauer, Andreas Kemnade,
Lee Jones, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Liam Girdwood, Mark Brown, Aaro Koskinen, Kevin Hilman,
Roger Quadros, Russell King, Daniel Thompson, Jingoo Han,
Helge Deller, Jaroslav Kysela, Takashi Iwai, Sen Wang,
Richard Fitzgerald, Arnd Bergmann, Srinivas Kandagatla,
Kuninori Morimoto, Charles Keepax, Niranjan H Y, letux-kernel,
devicetree, linux-kernel, linux-sound, linux-omap,
linux-arm-kernel, dri-devel, linux-fbdev, kernel, mfd
In-Reply-To: <741706c6-e6ff-4bc2-8ea1-28ebada6032c@kernel.org>
> Am 13.07.2026 um 11:42 schrieb Krzysztof Kozlowski <krzk@kernel.org>:
>
> On 13/07/2026 11:38, H. Nikolaus Schaller wrote:
>>
>>
>>> Am 13.07.2026 um 11:21 schrieb Krzysztof Kozlowski <krzk@kernel.org>:
>>>
>>> On 13/07/2026 10:27, H. Nikolaus Schaller wrote:
>>>> Hi Krzysztof,
>>>>
>>>> Thank you for the feedback.
>>>>
>>>>
>>>> It does not emit any C compiler issues or runtime problems so it remained unnoticed.
>>>
>>> I do not believe.
>>>
>>> There is a clear warning from Rob's bot.
>>>
>>> You just did not follow the process of building the code (compiler has
>>> nothing to do here). Read submitting patches in DT dir and then writing
>>> schema for further instructions. This is ABSOLUTE MINIMUM. We are not
>>> your build test service.
>>>
>>>>
>>>> It was notified by the sahiko-bot and will be fixed in v2.
>>>
>>> Sashiko has nothing to do with that.
>>>
>>> You DID NOT BUILD the code.
>>
>> Hm. You are confusing me. I did "make" and did not get any errors...
>> And the resulting code works as intended.
>
> 'make' alone does not build that, just like other pieces of code they
> have own - well documented and always expected - build processes.
>
> I don't know what is confusing in my message, since I pointed you to
> SPECIFIC guide telling you EXACTLY what to do (and which you did not do).
Confusing was the phrase "building the code". For my understanding
"building the code" is the process of building ("translating the code")
to get vmlinux or similar and a DTB and kernel modules.
As far as I understand the bindings they are used to check the DTS source
files against. So here is no translation of bindings into a real DTB that
finaly runs on a device. So I had assumed that schemas are "validated"
(not "built") by dt_binding_check.
This made me confused.
Back to topic:
It finally turned out that our script to run the required checks automatically
was no longer operational and silently ignored the validations. Therefore
nobody noticed before the bots did. Good to have a second and independent
check.
So sorry for the confusion we have introduced...
v2 will be checked as it previously was.
BR and thanks,
Nikolaus
^ permalink raw reply
* Re: [PATCH v2 00/13] mm: convert more vm_flags_t users to vma_flags_t
From: Andrew Morton @ 2026-07-14 2:25 UTC (permalink / raw)
To: Lorenzo Stoakes
Cc: David Hildenbrand, Liam R. Howlett, Vlastimil Babka,
Mike Rapoport, Suren Baghdasaryan, Michal Hocko,
Thomas Bogendoerfer, Benjamin LaHaise, Alexander Viro,
Christian Brauner, Jan Kara, Hugh Dickins, Baolin Wang, Jann Horn,
Pedro Falcato, Muchun Song, Oscar Salvador, Zi Yan, Nico Pache,
Ryan Roberts, Dev Jain, Barry Song, Lance Yang, Usama Arif,
Madhavan Srinivasan, Michael Ellerman, Nicholas Piggin,
Christophe Leroy (CS GROUP), Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Lucas Stach,
Russell King, Christian Gmeiner, Inki Dae, Seung-Woo Kim,
Kyungmin Park, Krzysztof Kozlowski, Peter Griffin, Alim Akhtar,
Jani Nikula, Joonas Lahtinen, Rodrigo Vivi, Tvrtko Ursulin,
Rob Clark, Dmitry Baryshkov, Abhinav Kumar, Jessica Zhang,
Sean Paul, Marijn Suijten, Lyude Paul, Danilo Krummrich,
Tomi Valkeinen, Sandy Huang, Heiko Stübner, Andy Yan,
Thierry Reding, Mikko Perttunen, Jonathan Hunter, Gerd Hoffmann,
Dmitry Osipenko, Gurchetan Singh, Chia-I Wu, Zack Rusin,
Broadcom internal kernel review list, Matthew Brost,
Thomas Hellström, Oleksandr Andrushchenko, Helge Deller,
Kees Cook, Jaroslav Kysela, Takashi Iwai, Boris Brezillon,
Steven Price, Liviu Dudau, linux-mm, linux-kernel, linux-mips,
linux-aio, linux-fsdevel, 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-sound, Jani Nikula
In-Reply-To: <20260711-b4-vma-flags-mm-v2-0-0fa2357d5431@kernel.org>
On Sat, 11 Jul 2026 19:44:57 +0100 Lorenzo Stoakes <ljs@kernel.org> wrote:
> This series makes further progress in converting usage of the deprecated
> vm_flags_t type to its replacement, vma_flags_t.
>
> It focuses on mm, though updates some users of mm APIs also.
>
> It updates:
>
> * The core do_mmap() code path for VMA mapping.
> * Unmapped area logic.
> * The usage of mm->def_vma_flags.
> * VMA page protection bit logic.
> * General usage of VMA flags in core mm code, mlock, mprotect, mremap.
Added to mm-new, thanks.
And oh my, what a lot of pre-existing issues:
https://sashiko.dev/#/patchset/20260711-b4-vma-flags-mm-v2-0-0fa2357d5431@kernel.org
^ permalink raw reply
* Re: [PATCH v2 12/13] mm/mprotect: convert mprotect code to use vma_flags_t
From: Zi Yan @ 2026-07-14 2:46 UTC (permalink / raw)
To: Lorenzo Stoakes
Cc: Andrew Morton, David Hildenbrand, Liam R. Howlett,
Vlastimil Babka, Mike Rapoport, Suren Baghdasaryan, Michal Hocko,
Thomas Bogendoerfer, Benjamin LaHaise, Alexander Viro,
Christian Brauner, Jan Kara, Hugh Dickins, Baolin Wang, Jann Horn,
Pedro Falcato, Muchun Song, Oscar Salvador, Nico Pache,
Ryan Roberts, Dev Jain, Barry Song, Lance Yang, Usama Arif,
Madhavan Srinivasan, Michael Ellerman, Nicholas Piggin,
Christophe Leroy (CS GROUP), Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Lucas Stach,
Russell King, Christian Gmeiner, Inki Dae, Seung-Woo Kim,
Kyungmin Park, Krzysztof Kozlowski, Peter Griffin, Alim Akhtar,
Jani Nikula, Joonas Lahtinen, Rodrigo Vivi, Tvrtko Ursulin,
Rob Clark, Dmitry Baryshkov, Abhinav Kumar, Jessica Zhang,
Sean Paul, Marijn Suijten, Lyude Paul, Danilo Krummrich,
Tomi Valkeinen, Sandy Huang, Heiko Stübner, Andy Yan,
Thierry Reding, Mikko Perttunen, Jonathan Hunter, Gerd Hoffmann,
Dmitry Osipenko, Gurchetan Singh, Chia-I Wu, Zack Rusin,
Broadcom internal kernel review list, Matthew Brost,
Thomas Hellström, Oleksandr Andrushchenko, Helge Deller,
Kees Cook, Jaroslav Kysela, Takashi Iwai, Boris Brezillon,
Steven Price, Liviu Dudau, linux-mm, linux-kernel, linux-mips,
linux-aio, linux-fsdevel, 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-sound
In-Reply-To: <20260711-b4-vma-flags-mm-v2-12-0fa2357d5431@kernel.org>
On 11 Jul 2026, at 14:45, Lorenzo Stoakes wrote:
> Replace use of the legacy vm_flags_t flags with vma_flags_t values
> throughout the mprotect logic.
>
> Note that we retain the legacy vm_flags_t bit shifting code in
> do_mprotect_pkey(), deferring a vma_flags_t approach to this for the time
> being.
>
> Additionally update comments to reflect the changes to be consistent.
>
> No functional change intended.
>
> Signed-off-by: Lorenzo Stoakes <ljs@kernel.org>
> ---
> mm/mprotect.c | 16 ++++++++--------
> 1 file changed, 8 insertions(+), 8 deletions(-)
>
LGTM.
Reviewed-by: Zi Yan <ziy@nvidia.com>
Best Regards,
Yan, Zi
^ permalink raw reply
* Re: [PATCH v5 02/14] mfd: lm3533: Remove driver specific regmap wrappers
From: Svyatoslav Ryhel @ 2026-07-14 13:26 UTC (permalink / raw)
To: Johan Hovold
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: <akeEd0GcHSqScGIl@hovoldconsulting.com>
пт, 3 лип. 2026 р. о 12:44 Johan Hovold <johan@kernel.org> пише:
>
> On Wed, Jun 17, 2026 at 11:00:19AM +0300, Svyatoslav Ryhel wrote:
> > Remove driver-specific regmap wrappers in favor of using regmap helpers
> > directly.
>
> The commit message should explain why you think this is a good idea.
>
Removing custom wrappers over standard regmap helpers is always a good
idea, that is self explanatory.
> Based on a quick look you lose the errnos that were logged on errors and
> also the register debugging provided by those helpers.
>
That is not true, regmap helpers will provide logging and you should
not include debug stuff into the final submitted driver unless you
have a extremely valid justification for this, debug logs should have
been removed once the driver development was completed.
> Johan
^ permalink raw reply
* Re: [PATCH v5 01/14] dt-bindings: leds: Document TI LM3533 LED controller
From: Svyatoslav Ryhel @ 2026-07-14 13:27 UTC (permalink / raw)
To: Johan Hovold
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: <akeFmMQ_S1Y18hlu@hovoldconsulting.com>
пт, 3 лип. 2026 р. о 12:49 Johan Hovold <johan@kernel.org> пише:
>
> On Wed, Jun 17, 2026 at 11:00:18AM +0300, Svyatoslav Ryhel wrote:
> > Document the LM3533 - a complete power source for backlight, keypad and
> > indicator LEDs in smartphone handsets. The high-voltage inductive boost
> > converter provides the power for two series LED strings display backlight
> > and keypad functions.
> >
> > Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
> > Reviewed-by: Jonathan Cameron <jic23@kernel.org> #for light sensor
> > Reviewed-by: Daniel Thompson (RISCstar) <danielt@kernel.org> #for backlight
> > Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
>
> > +examples:
> > + - |
> > + #include <dt-bindings/gpio/gpio.h>
> > + #include <dt-bindings/interrupt-controller/irq.h>
> > +
> > + i2c {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + led-controller@36 {
> > + compatible = "ti,lm3533";
> > + reg = <0x36>;
> > +
> > + enable-gpios = <&gpio 110 GPIO_ACTIVE_HIGH>;
> > + vin-supply = <&vdd_3v3_bat>;
> > +
> > + ti,boost-ovp-microvolt = <24000000>;
> > + ti,boost-freq-hz = <500000>;
> > +
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + backlight@0 {
> > + compatible = "ti,lm3533-backlight";
> > + reg = <0>;
> > +
> > + default-brightness = <113>;
> > +
> > + led-max-microamp = <23400>;
> > + led-sources = <0 1>;
> > + };
> > +
> > + led@2 {
> > + compatible = "ti,lm3533-leds";
> > + reg = <2>;
> > +
> > + led-max-microamp = <23400>;
> > + led-sources = <0 1>;
> > + };
> > +
> > + led@4 {
> > + compatible = "ti,lm3533-leds";
> > + reg = <4>;
> > +
> > + led-max-microamp = <23400>;
> > + led-sources = <2>;
> > + };
> > +
> > + led@5 {
> > + compatible = "ti,lm3533-leds";
> > + reg = <5>;
> > +
> > + led-max-microamp = <23400>;
> > + led-sources = <3 4>;
> > + };
> > +
> > + light-sensor {
>
> Doesn't the binding (or dts) checker complain about this node not having
> an address?
>
No it does not
> > + compatible = "ti,lm3533-als";
> > +
> > + interrupt-parent = <&gpio>;
> > + interrupts = <80 IRQ_TYPE_LEVEL_LOW>;
> > +
> > + ti,pwm-mode;
> > + };
> > + };
> > + };
> > +...
>
> Johan
^ permalink raw reply
* Re: [PATCH v5 04/14] mfd: lm3533: Pass only regmap and light sensor presence to child devices
From: Svyatoslav Ryhel @ 2026-07-14 13:28 UTC (permalink / raw)
To: Johan Hovold
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: <akeF_VrijPbebz3I@hovoldconsulting.com>
пт, 3 лип. 2026 р. о 12:50 Johan Hovold <johan@kernel.org> пише:
>
> On Wed, Jun 17, 2026 at 11:00:21AM +0300, Svyatoslav Ryhel wrote:
> > Instead of passing the entire lm3533 core data structure, only pass the
> > regmap and the light sensor presence flag to child devices.
>
> Again, why?
>
Because none of the child cells needs entire parents private
structure, regmap is all that is used.
> Johan
^ permalink raw reply
* Re: [PATCH v5 05/14] iio: light: lm3533-als: Remove redundant pdata helpers
From: Svyatoslav Ryhel @ 2026-07-14 13:31 UTC (permalink / raw)
To: Johan Hovold
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: <akeHC-OA8tqM941f@hovoldconsulting.com>
пт, 3 лип. 2026 р. о 12:55 Johan Hovold <johan@kernel.org> пише:
>
> 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.
>
Adding helpers to wrap custom regmap wrappers seems redundant twice.
> > 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.
>
Removing one level of indentations without obscuring readability is
always a good idea.
> Johan
^ permalink raw reply
* Re: [PATCH v5 06/14] mfd: lm3533-core: Remove redundant pdata helpers
From: Svyatoslav Ryhel @ 2026-07-14 13:32 UTC (permalink / raw)
To: Johan Hovold
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: <akeHfV45fs_wabFl@hovoldconsulting.com>
пт, 3 лип. 2026 р. о 12:57 Johan Hovold <johan@kernel.org> пише:
>
> 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?
>
Adding helpers to wrap custom regmap wrappers seems redundant. Regmap
operations are pretty self explanatory without need in one-time-use
helpers.
> Johan
^ permalink raw reply
* Re: [PATCH v5 08/14] mfd: lm3533: Convert to use OF bindings
From: Svyatoslav Ryhel @ 2026-07-14 13:57 UTC (permalink / raw)
To: Johan Hovold
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: <akeXAOpb13hupUGM@hovoldconsulting.com>
пт, 3 лип. 2026 р. о 14:03 Johan Hovold <johan@kernel.org> пише:
>
> 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?
>
Because every cell has its own binding now and using phandle to parent
when device has its own node is not a good practice.
> That's an ABI break.
>
This driver does not have any active users in the kernel and no
activity for more then 2 years.
> > +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.
>
Why?
> > 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?
>
lm3533-leds-2
> > + 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.
>
Agreed.
> > 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?
>
According to OF schema default lower margin is set to
LM3533_MAX_CURRENT_MIN so clamping seems a good option here, even
though it will clamp max value.
> > +
> > + 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.
>
Why?
> > 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.
>
Checkpatch does not complain on style issue, hence this is not prohibited.
> > 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?
>
Only if the tree is malformed, hence this check was added.
> > +
> > + 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().
>
of_platform_populate() is not a part of mfd framework.
> >
> > 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.
>
Checkpatch does not complain on style issue, hence this is not prohibited.
> > +
> > + 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?
>
According to OF schema default lower margin is set to
LM3533_BOOST_FREQ_MIN so clamping seems a good option here, even
though it will clamp max value.
> > 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)?
>
lm3533-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
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