* Re: [PATCH v5 0/2] backlight: Add SY7758 6-channel High Efficiency LED Driver support
From: Lee Jones @ 2026-07-02 16:31 UTC (permalink / raw)
To: Lee Jones, Daniel Thompson, Jingoo Han, Pavel Machek, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Helge Deller, Neil Armstrong
Cc: dri-devel, linux-leds, devicetree, linux-kernel, linux-fbdev,
KancyJoe, Krzysztof Kozlowski
In-Reply-To: <20260529-topic-sm8650-ayaneo-pocket-s2-sy7758-v5-0-03aacd49747c@linaro.org>
On Fri, 29 May 2026 21:23:07 +0200, Neil Armstrong wrote:
> Implement support for the Silergy SY7758 6-channel High Efficiency LED Driver
> used for backlight brightness control in the Ayaneo Pocket S2 dual-DSI panel.
Applied, thanks!
[1/2] dt-bindings: leds: backlight: document the SY7758 6-channel High Efficiency LED Driver
commit: 2019a2a7268f6f7387f052110558b9f90b500324
[2/2] backlight: Add SY7758 6-channel High Efficiency LED Driver support
commit: 110d67699a430daf0316f941254c46221e3f0914
--
Lee Jones [李琼斯]
^ permalink raw reply
* Re: [PATCH 13/13] mm/mremap: convert mremap code to use vma_flags_t
From: Lorenzo Stoakes @ 2026-07-02 16:31 UTC (permalink / raw)
To: Lance Yang
Cc: akpm, tsbogend, maddy, mpe, maarten.lankhorst, mripard,
tzimmermann, airlied, simona, l.stach, inki.dae, sw0312.kim,
kyungmin.park, krzk, peter.griffin, jani.nikula, joonas.lahtinen,
rodrigo.vivi, tursulin, robin.clark, lumag, lyude, dakr,
tomi.valkeinen, hjc, heiko, andy.yan, thierry.reding, mperttunen,
jonathanh, kraxel, dmitry.osipenko, zack.rusin, matthew.brost,
thomas.hellstrom, oleksandr_andrushchenko, deller, bcrl, viro,
brauner, muchun.song, osalvador, david, ziy, baolin.wang, liam,
npache, ryan.roberts, dev.jain, baohua, hughd, vbabka, rppt,
surenb, mhocko, jannh, pfalcato, kees, perex, tiwai, 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: <2f36a2da-0686-485f-b4b9-ae699bef4fd4@linux.dev>
On Fri, Jul 03, 2026 at 12:17:29AM +0800, Lance Yang wrote:
>
>
> On 2026/7/3 00:07, Lorenzo Stoakes wrote:
> > On Thu, Jul 02, 2026 at 09:49:47PM +0800, Lance Yang wrote:
> > >
> > > On Mon, Jun 29, 2026 at 08:25:36PM +0100, Lorenzo Stoakes wrote:
> > > > Replace use of the legacy vm_flags_t flags with vma_flags_t values
> > > > throughout the mremap logic.
> > > >
> > > > Additionally update comments to reflect the changes to be consistent.
> > > >
> > > > No functional change intended.
> > > >
> > > > Signed-off-by: Lorenzo Stoakes <ljs@kernel.org>
> > > > ---
> > >
> > > The vm_flags_set() cases below spell out vma_start_write(), but the
> > > vm_flags_clear() cases don't?
> >
> > Yep as I said elsewhere, implicitly taking the lock is terrible and me doing
> > this is completely on purpose to get rid of that :)
> >
> > But I haven't been clear enough clearly, so I should put the argument as to why
> > that's ok in the commit message.
> >
> > Will do so on respin.
>
> Makes sense, thanks for spelling it out! A short changelog note
> should clear it up for me :D
Yeah absolutely, that's necessary and was an oversight on my part, will correct!
Thanks for your great review here, much appreciated! :)
>
> [...]
Cheers, Lorenzo
^ permalink raw reply
* Re: [PATCH v5 05/14] iio: light: lm3533-als: Remove redundant pdata helpers
From: Jonathan Cameron @ 2026-07-03 0:57 UTC (permalink / raw)
To: Svyatoslav Ryhel
Cc: Lee Jones, Daniel Thompson, Jingoo Han, Pavel Machek, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, David Lechner, Nuno Sá,
Andy Shevchenko, Helge Deller, Johan Hovold, dri-devel,
linux-leds, devicetree, linux-kernel, linux-iio, linux-fbdev
In-Reply-To: <20260617080031.99156-6-clamor95@gmail.com>
On Wed, 17 Jun 2026 11:00:22 +0300
Svyatoslav Ryhel <clamor95@gmail.com> 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.
>
> Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
LGTM
Reviewed-by: Jonathan Cameron <jic23@kernel.org>
^ permalink raw reply
* Re: [PATCH v5 00/14] mfd: lm3533: convert to OF bindings, improve support
From: Svyatoslav Ryhel @ 2026-07-03 8:50 UTC (permalink / raw)
To: Lee Jones
Cc: Daniel Thompson, Jingoo Han, Pavel Machek, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Jonathan Cameron,
David Lechner, Nuno Sá, Andy Shevchenko, Helge Deller,
Johan Hovold, dri-devel, linux-leds, devicetree, linux-kernel,
linux-iio, linux-fbdev
In-Reply-To: <20260702161828.GB2108533@google.com>
чт, 2 лип. 2026 р. о 19:18 Lee Jones <lee@kernel.org> пише:
>
> On Wed, 17 Jun 2026, Svyatoslav Ryhel wrote:
>
> > Convert LM3533 to OF bindings, add missing VIN supply, add support for
> > setting mapping mode and LED sources based on device tree.
> >
> > ---
> > Changes in v2:
> >
> > schema
> > - maximum led sources for leds set to 4
> > - anyOf > oneOf in ALS
> > - improved ALS descriptions
> > - adjusted example
> > drivers
> > - dropped devm convertion of irq and mfd helpers
> > - all als configuration moved into lm3533_als_setup
> > - added regulator/consumer.h
> > - lm3533_bl_setup set before sysfs_create_group in backlight
> > - added check if LVLED is valid
> > - LM3533_REG_OUTPUT_CONF1 > LM3533_REG_OUTPUT_CONF2 for LVLED4 and LVLED5
>
> This set looks good to me now.
>
> Let me know when you have all of the Acks and I'll merge it via MFD.
>
Hello there!
Jonathan and Daniel added their Reviewed-by for IIO and backlight
subsystems, so I assume that should be all required.
Best regards,
Svyatoslav R.
> --
> Lee Jones
^ permalink raw reply
* Re: [PATCH v5 02/14] mfd: lm3533: Remove driver specific regmap wrappers
From: Johan Hovold @ 2026-07-03 9:44 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-3-clamor95@gmail.com>
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.
Based on a quick look you lose the errnos that were logged on errors and
also the register debugging provided by those helpers.
Johan
^ permalink raw reply
* Re: [PATCH v5 01/14] dt-bindings: leds: Document TI LM3533 LED controller
From: Johan Hovold @ 2026-07-03 9:49 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-2-clamor95@gmail.com>
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?
> + 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: Johan Hovold @ 2026-07-03 9:50 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-5-clamor95@gmail.com>
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?
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
* 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 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 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 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 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 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
* [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
* [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
* 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
* 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 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 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 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: 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] 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 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 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
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