Re: [PATCH 01/15] video: fbdev: atmel_lcdfb: Rework backlight handling
On 8 January 2023 08:45:46 CET, Stephen Kitt wrote: >On 7 January 2023 21:53:46 CET, Sam Ravnborg wrote: >>Hi Stephen. >> >>On Sat, Jan 07, 2023 at 09:36:47PM +0100, Stephen Kitt wrote: >>> On 7 January 2023 19:26:15 CET, Sam Ravnborg via B4 Submission Endpoint >>> wrote: >>> >From: Sam Ravnborg >>> > >>> >The atmel_lcdfb had code to save/restore power state. >>> >This is not needed so drop it. >>> > >>> >Introduce backlight_is_brightness() to make logic simpler. >>> > >>> >Signed-off-by: Sam Ravnborg >>> >Cc: Nicolas Ferre >>> >Cc: Alexandre Belloni >>> >Cc: Ludovic Desroches >>> >Cc: linux-fb...@vger.kernel.org >>> >Cc: linux-arm-ker...@lists.infradead.org >>> >--- >>> > drivers/video/fbdev/atmel_lcdfb.c | 24 +++- >>> > 1 file changed, 3 insertions(+), 21 deletions(-) >>... >>> >>> Hi Sam, >>> >>> I’d submitted quite a few more of these previously (and you’d reviewed >>> them), see e.g. the thread starting at https://lkml.org/lkml/2022/6/7/4365, >>> and yesterday, https://lkml.org/lkml/2023/1/6/520, >>> https://lkml.org/lkml/2023/1/6/656, https://lkml.org/lkml/2023/1/6/970, >>> https://lkml.org/lkml/2023/1/6/643, and https://lkml.org/lkml/2023/1/6/680. >>> There are a few more, I can find them if it’s any use. >> >>The patches from yesterday was what triggered me to resurrect an old >>branch of mine where I had done something similar. I had lost all >>memory of reviewing similar patches from you. >> >> >>Helge - could you pick the reviewed patches from: >>https://lore.kernel.org/all/20220607192335.1137249-1-st...@sk2.org/ >>[This is the same mail as Stephen refer to above - looked up via lore]. >> >>Stephen - I expect Daniel/Lee to take care of the patches from yesterday. >>If you can look up other pending patches from you please do so, so we >>can have them applied. >>Preferably with links to lore - as this makes it easier to apply them. >> >>Review of what is unique in this set would be appreciated. >> >> Sam > >Hi Sam, > >Here are my pending patches from last June on lore: > >* https://lore.kernel.org/lkml/20220607190925.1134737-1-st...@sk2.org/ >* https://lore.kernel.org/lkml/20220608205623.2106113-1-st...@sk2.org/ >* https://lore.kernel.org/lkml/20220607192335.1137249-1-st...@sk2.org/ >* https://lore.kernel.org/lkml/20220616170425.1346081-1-st...@sk2.org/ > >I’ll send reviews of your other patches later today or tomorrow. > >Regards, > >Stephen And the auxdisplay patch, v1: https://lore.kernel.org/lkml/20220607180406.1116277-1-st...@sk2.org/ and v2: https://lore.kernel.org/lkml/20230106143002.1434266-1-st...@sk2.org/ Regards, Stephen
[PATCH 10/15] staging: fbtft: core: Introduce backlight_is_blank()
From: Sam Ravnborg
Avoiding direct access to backlight_properties.props.
Access to the deprecated props.fb_blank replaced by backlight_is_blank().
Access to props.power is dropped - it was only used for debug.
Signed-off-by: Sam Ravnborg
Cc: Thomas Zimmermann
Cc: Andy Shevchenko
Cc: Javier Martinez Canillas
Cc: Greg Kroah-Hartman
Cc: Sam Ravnborg
Cc: Stephen Kitt
Cc: Peter Suti
Cc: linux-fb...@vger.kernel.org
---
drivers/staging/fbtft/fbtft-core.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/staging/fbtft/fbtft-core.c
b/drivers/staging/fbtft/fbtft-core.c
index afaba94d1d1c..1746327e1939 100644
--- a/drivers/staging/fbtft/fbtft-core.c
+++ b/drivers/staging/fbtft/fbtft-core.c
@@ -132,15 +132,15 @@ static int fbtft_backlight_update_status(struct
backlight_device *bd)
{
struct fbtft_par *par = bl_get_data(bd);
bool polarity = par->polarity;
+ bool blank = backlight_is_blank(bd);
- fbtft_par_dbg(DEBUG_BACKLIGHT, par,
- "%s: polarity=%d, power=%d, fb_blank=%d\n",
- __func__, polarity, bd->props.power, bd->props.fb_blank);
+ fbtft_par_dbg(DEBUG_BACKLIGHT, par, "%s: polarity=%d, blank=%d\n",
+ __func__, polarity, blank);
- if (!backlight_is_blank(bd))
- gpiod_set_value(par->gpio.led[0], polarity);
- else
+ if (blank)
gpiod_set_value(par->gpio.led[0], !polarity);
+ else
+ gpiod_set_value(par->gpio.led[0], polarity);
return 0;
}
--
2.34.1
[PATCH 15/15] backlight: backlight: Drop the deprecated fb_blank property
From: Sam Ravnborg
With all users gone remove the deprecated fb_blank member in
backlight_properties.
Signed-off-by: Sam Ravnborg
Cc: Lee Jones
Cc: Daniel Thompson
Cc: Jingoo Han
---
drivers/video/backlight/backlight.c | 2 --
include/linux/backlight.h | 22 --
2 files changed, 24 deletions(-)
diff --git a/drivers/video/backlight/backlight.c
b/drivers/video/backlight/backlight.c
index b788ff3d0f45..9b0557d094c5 100644
--- a/drivers/video/backlight/backlight.c
+++ b/drivers/video/backlight/backlight.c
@@ -118,14 +118,12 @@ static int fb_notifier_callback(struct notifier_block
*self,
bd->fb_bl_on[node] = true;
if (!bd->use_count++) {
bd->props.state &= ~BL_CORE_FBBLANK;
- bd->props.fb_blank = FB_BLANK_UNBLANK;
backlight_update_status(bd);
}
} else if (fb_blank != FB_BLANK_UNBLANK && bd->fb_bl_on[node]) {
bd->fb_bl_on[node] = false;
if (!(--bd->use_count)) {
bd->props.state |= BL_CORE_FBBLANK;
- bd->props.fb_blank = fb_blank;
backlight_update_status(bd);
}
}
diff --git a/include/linux/backlight.h b/include/linux/backlight.h
index 614653e07e3a..c8622d6cc8c5 100644
--- a/include/linux/backlight.h
+++ b/include/linux/backlight.h
@@ -218,25 +218,6 @@ struct backlight_properties {
*/
int power;
- /**
-* @fb_blank: The power state from the FBIOBLANK ioctl.
-*
-* When the FBIOBLANK ioctl is called @fb_blank is set to the
-* blank parameter and the update_status() operation is called.
-*
-* When the backlight device is enabled @fb_blank is set
-* to FB_BLANK_UNBLANK. When the backlight device is disabled
-* @fb_blank is set to FB_BLANK_POWERDOWN.
-*
-* Backlight drivers should avoid using this property. It has been
-* replaced by state & BL_CORE_FBLANK (although most drivers should
-* use backlight_is_blank() as the preferred means to get the blank
-* state).
-*
-* fb_blank is deprecated and will be removed.
-*/
- int fb_blank;
-
/**
* @type: The type of backlight supported.
*
@@ -366,7 +347,6 @@ static inline int backlight_enable(struct backlight_device
*bd)
return 0;
bd->props.power = FB_BLANK_UNBLANK;
- bd->props.fb_blank = FB_BLANK_UNBLANK;
bd->props.state &= ~BL_CORE_FBBLANK;
return backlight_update_status(bd);
@@ -382,7 +362,6 @@ static inline int backlight_disable(struct backlight_device
*bd)
return 0;
bd->props.power = FB_BLANK_POWERDOWN;
- bd->props.fb_blank = FB_BLANK_POWERDOWN;
bd->props.state |= BL_CORE_FBBLANK;
return backlight_update_status(bd);
@@ -403,7 +382,6 @@ static inline int backlight_disable(struct backlight_device
*bd)
static inline bool backlight_is_blank(const struct backlight_device *bd)
{
return bd->props.power != FB_BLANK_UNBLANK ||
- bd->props.fb_blank != FB_BLANK_UNBLANK ||
bd->props.state & (BL_CORE_SUSPENDED | BL_CORE_FBBLANK);
}
--
2.34.1
[PATCH 12/15] auxdisplay: ht16k33: Introduce backlight_get_brightness()
From: Sam Ravnborg
Introduce backlight_get_brightness() to simplify logic
and avoid direct access to backlight properties.
Signed-off-by: Sam Ravnborg
Cc: Robin van der Gracht
Cc: Miguel Ojeda
Cc: Geert Uytterhoeven
---
drivers/auxdisplay/ht16k33.c | 7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/drivers/auxdisplay/ht16k33.c b/drivers/auxdisplay/ht16k33.c
index 02425991c159..15ab118c80f5 100644
--- a/drivers/auxdisplay/ht16k33.c
+++ b/drivers/auxdisplay/ht16k33.c
@@ -314,14 +314,9 @@ static int ht16k33_initialize(struct ht16k33_priv *priv)
static int ht16k33_bl_update_status(struct backlight_device *bl)
{
- int brightness = bl->props.brightness;
+ int brightness = backlight_get_brightness(bl);
struct ht16k33_priv *priv = bl_get_data(bl);
- if (bl->props.power != FB_BLANK_UNBLANK ||
- bl->props.fb_blank != FB_BLANK_UNBLANK ||
- bl->props.state & BL_CORE_FBBLANK)
- brightness = 0;
-
return ht16k33_brightness_set(priv, brightness);
}
--
2.34.1
[PATCH 13/15] backlight: omap1: Use backlight helpers
From: Sam Ravnborg
Rework backlight handling to avoid access to the deprecated
backlight_properties.fb_blank member.
The rework includes removal of get_brightness() operation,
because there was no read back from HW so no use for it.
Signed-off-by: Sam Ravnborg
Cc: Lee Jones
Cc: Daniel Thompson
Cc: Jingoo Han
---
drivers/video/backlight/omap1_bl.c | 67 +-
1 file changed, 9 insertions(+), 58 deletions(-)
diff --git a/drivers/video/backlight/omap1_bl.c
b/drivers/video/backlight/omap1_bl.c
index 69a49384b3de..49f37da857e7 100644
--- a/drivers/video/backlight/omap1_bl.c
+++ b/drivers/video/backlight/omap1_bl.c
@@ -20,9 +20,6 @@
#define OMAPBL_MAX_INTENSITY 0xff
struct omap_backlight {
- int powermode;
- int current_intensity;
-
struct device *dev;
struct omap_backlight_config *pdata;
};
@@ -37,82 +34,40 @@ static inline void omapbl_send_enable(int enable)
omap_writeb(enable, OMAP_PWL_CLK_ENABLE);
}
-static void omapbl_blank(struct omap_backlight *bl, int mode)
-{
- if (bl->pdata->set_power)
- bl->pdata->set_power(bl->dev, mode);
-
- switch (mode) {
- case FB_BLANK_NORMAL:
- case FB_BLANK_VSYNC_SUSPEND:
- case FB_BLANK_HSYNC_SUSPEND:
- case FB_BLANK_POWERDOWN:
- omapbl_send_intensity(0);
- omapbl_send_enable(0);
- break;
-
- case FB_BLANK_UNBLANK:
- omapbl_send_intensity(bl->current_intensity);
- omapbl_send_enable(1);
- break;
- }
-}
-
#ifdef CONFIG_PM_SLEEP
static int omapbl_suspend(struct device *dev)
{
struct backlight_device *bl_dev = dev_get_drvdata(dev);
- struct omap_backlight *bl = bl_get_data(bl_dev);
- omapbl_blank(bl, FB_BLANK_POWERDOWN);
+ backlight_disable(bl_dev);
return 0;
}
static int omapbl_resume(struct device *dev)
{
struct backlight_device *bl_dev = dev_get_drvdata(dev);
- struct omap_backlight *bl = bl_get_data(bl_dev);
- omapbl_blank(bl, bl->powermode);
+ backlight_enable(bl_dev);
return 0;
}
#endif
-static int omapbl_set_power(struct backlight_device *dev, int state)
-{
- struct omap_backlight *bl = bl_get_data(dev);
-
- omapbl_blank(bl, state);
- bl->powermode = state;
-
- return 0;
-}
-
static int omapbl_update_status(struct backlight_device *dev)
{
- struct omap_backlight *bl = bl_get_data(dev);
+ int brightness = backlight_get_brightness(dev);
- if (bl->current_intensity != dev->props.brightness) {
- if (bl->powermode == FB_BLANK_UNBLANK)
- omapbl_send_intensity(dev->props.brightness);
- bl->current_intensity = dev->props.brightness;
+ if (brightness > 0) {
+ omapbl_send_intensity(dev->props.brightness);
+ omapbl_send_enable(1);
+ } else {
+ omapbl_send_intensity(0);
+ omapbl_send_enable(0);
}
- if (dev->props.fb_blank != bl->powermode)
- omapbl_set_power(dev, dev->props.fb_blank);
-
return 0;
}
-static int omapbl_get_intensity(struct backlight_device *dev)
-{
- struct omap_backlight *bl = bl_get_data(dev);
-
- return bl->current_intensity;
-}
-
static const struct backlight_ops omapbl_ops = {
- .get_brightness = omapbl_get_intensity,
.update_status = omapbl_update_status,
};
@@ -139,9 +94,6 @@ static int omapbl_probe(struct platform_device *pdev)
if (IS_ERR(dev))
return PTR_ERR(dev);
- bl->powermode = FB_BLANK_POWERDOWN;
- bl->current_intensity = 0;
-
bl->pdata = pdata;
bl->dev = >dev;
@@ -149,7 +101,6 @@ static int omapbl_probe(struct platform_device *pdev)
omap_cfg_reg(PWL); /* Conflicts with UART3 */
- dev->props.fb_blank = FB_BLANK_UNBLANK;
dev->props.brightness = pdata->default_intensity;
omapbl_update_status(dev);
--
2.34.1
[PATCH 14/15] backlight: tosa: Use backlight helper
From: Stephen Kitt
Instead of retrieving the backlight brightness in struct
backlight_properties manually, and then checking whether the backlight
should be on at all, use backlight_get_brightness() which does all
this and insulates this from future changes.
Signed-off-by: Stephen Kitt
Signed-off-by: Sam Ravnborg
---
drivers/video/backlight/tosa_bl.c | 7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/drivers/video/backlight/tosa_bl.c
b/drivers/video/backlight/tosa_bl.c
index f55b3d616a87..cb07f13dd886 100644
--- a/drivers/video/backlight/tosa_bl.c
+++ b/drivers/video/backlight/tosa_bl.c
@@ -50,13 +50,8 @@ static void tosa_bl_set_backlight(struct tosa_bl_data *data,
int brightness)
static int tosa_bl_update_status(struct backlight_device *dev)
{
- struct backlight_properties *props = >props;
struct tosa_bl_data *data = bl_get_data(dev);
- int power = max(props->power, props->fb_blank);
- int brightness = props->brightness;
-
- if (power)
- brightness = 0;
+ int brightness = backlight_get_brightness(dev);
tosa_bl_set_backlight(data, brightness);
--
2.34.1
[PATCH 11/15] powerpc: via-pmu-backlight: Introduce backlight_get_brightness()
From: Sam Ravnborg
Introduce backlight_get_brightness() to simplify logic
and avoid direct access to backlight properties.
Signed-off-by: Sam Ravnborg
Cc: Benjamin Herrenschmidt
Cc: Sam Ravnborg
Cc: linuxppc-dev@lists.ozlabs.org
---
drivers/macintosh/via-pmu-backlight.c | 7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/drivers/macintosh/via-pmu-backlight.c
b/drivers/macintosh/via-pmu-backlight.c
index 2194016122d2..c2d87e7fa85b 100644
--- a/drivers/macintosh/via-pmu-backlight.c
+++ b/drivers/macintosh/via-pmu-backlight.c
@@ -71,12 +71,7 @@ static int pmu_backlight_get_level_brightness(int level)
static int __pmu_backlight_update_status(struct backlight_device *bd)
{
struct adb_request req;
- int level = bd->props.brightness;
-
-
- if (bd->props.power != FB_BLANK_UNBLANK ||
- bd->props.fb_blank != FB_BLANK_UNBLANK)
- level = 0;
+ int level = backlight_get_brightness(bd);
if (level > 0) {
int pmulevel = pmu_backlight_get_level_brightness(level);
--
2.34.1
[PATCH 08/15] video: fbdev: omap2: Introduce backlight_get_brightness()
From: Sam Ravnborg
Introduce backlight_get_brightness() to simplify logic
and avoid direct access to backlight properties.
Signed-off-by: Sam Ravnborg
Cc: Allison Randal
Cc: Sam Ravnborg
Cc: Greg Kroah-Hartman
Cc: Kate Stewart
Cc: Thomas Gleixner
Cc: Enrico Weigelt
Cc: Alexios Zavras
---
.../fbdev/omap2/omapfb/displays/panel-dsi-cm.c | 19 +-
.../omap2/omapfb/displays/panel-sony-acx565akm.c | 23 +++---
2 files changed, 8 insertions(+), 34 deletions(-)
diff --git a/drivers/video/fbdev/omap2/omapfb/displays/panel-dsi-cm.c
b/drivers/video/fbdev/omap2/omapfb/displays/panel-dsi-cm.c
index a2c7c5cb1523..bd73aa5328c9 100644
--- a/drivers/video/fbdev/omap2/omapfb/displays/panel-dsi-cm.c
+++ b/drivers/video/fbdev/omap2/omapfb/displays/panel-dsi-cm.c
@@ -330,14 +330,8 @@ static int dsicm_bl_update_status(struct backlight_device
*dev)
{
struct panel_drv_data *ddata = dev_get_drvdata(>dev);
struct omap_dss_device *in = ddata->in;
+ int level = backlight_get_brightness(dev);
int r;
- int level;
-
- if (dev->props.fb_blank == FB_BLANK_UNBLANK &&
- dev->props.power == FB_BLANK_UNBLANK)
- level = dev->props.brightness;
- else
- level = 0;
dev_dbg(>pdev->dev, "update brightness to %d\n", level);
@@ -360,17 +354,7 @@ static int dsicm_bl_update_status(struct backlight_device
*dev)
return r;
}
-static int dsicm_bl_get_intensity(struct backlight_device *dev)
-{
- if (dev->props.fb_blank == FB_BLANK_UNBLANK &&
- dev->props.power == FB_BLANK_UNBLANK)
- return dev->props.brightness;
-
- return 0;
-}
-
static const struct backlight_ops dsicm_bl_ops = {
- .get_brightness = dsicm_bl_get_intensity,
.update_status = dsicm_bl_update_status,
};
@@ -1251,7 +1235,6 @@ static int dsicm_probe(struct platform_device *pdev)
ddata->bldev = bldev;
- bldev->props.fb_blank = FB_BLANK_UNBLANK;
bldev->props.power = FB_BLANK_UNBLANK;
bldev->props.brightness = 255;
diff --git a/drivers/video/fbdev/omap2/omapfb/displays/panel-sony-acx565akm.c
b/drivers/video/fbdev/omap2/omapfb/displays/panel-sony-acx565akm.c
index c0965bee12c5..c9c8f10e2e2f 100644
--- a/drivers/video/fbdev/omap2/omapfb/displays/panel-sony-acx565akm.c
+++ b/drivers/video/fbdev/omap2/omapfb/displays/panel-sony-acx565akm.c
@@ -337,16 +337,10 @@ static int acx565akm_get_actual_brightness(struct
panel_drv_data *ddata)
static int acx565akm_bl_update_status(struct backlight_device *dev)
{
struct panel_drv_data *ddata = dev_get_drvdata(>dev);
- int level;
+ int level = backlight_get_brightness(dev);
dev_dbg(>spi->dev, "%s\n", __func__);
- if (dev->props.fb_blank == FB_BLANK_UNBLANK &&
- dev->props.power == FB_BLANK_UNBLANK)
- level = dev->props.brightness;
- else
- level = 0;
-
if (ddata->has_bc)
acx565akm_set_brightness(ddata, level);
else
@@ -364,15 +358,13 @@ static int acx565akm_bl_get_intensity(struct
backlight_device *dev)
if (!ddata->has_bc)
return -ENODEV;
- if (dev->props.fb_blank == FB_BLANK_UNBLANK &&
- dev->props.power == FB_BLANK_UNBLANK) {
- if (ddata->has_bc)
- return acx565akm_get_actual_brightness(ddata);
- else
- return dev->props.brightness;
- }
+ if (backlight_is_blank(dev))
+ return 0;
- return 0;
+ if (ddata->has_bc)
+ return acx565akm_get_actual_brightness(ddata);
+ else
+ return backlight_get_brightness(dev);
}
static int acx565akm_bl_update_status_locked(struct backlight_device *dev)
@@ -795,7 +787,6 @@ static int acx565akm_probe(struct spi_device *spi)
}
memset(, 0, sizeof(props));
- props.fb_blank = FB_BLANK_UNBLANK;
props.power = FB_BLANK_UNBLANK;
props.type = BACKLIGHT_RAW;
--
2.34.1
[PATCH 06/15] video: fbdev: aty128fb: Introduce backlight_get_brightness()
From: Sam Ravnborg
Introduce backlight_get_brightness() to simplify logic
and avoid direct access to backlight properties.
Signed-off-by: Sam Ravnborg
Cc: Paul Mackerras
Cc: linux-fb...@vger.kernel.org
---
drivers/video/fbdev/aty/aty128fb.c | 11 ++-
1 file changed, 2 insertions(+), 9 deletions(-)
diff --git a/drivers/video/fbdev/aty/aty128fb.c
b/drivers/video/fbdev/aty/aty128fb.c
index dd31b9d7d337..736126cc5049 100644
--- a/drivers/video/fbdev/aty/aty128fb.c
+++ b/drivers/video/fbdev/aty/aty128fb.c
@@ -1764,17 +1764,10 @@ static int aty128_bl_update_status(struct
backlight_device *bd)
{
struct aty128fb_par *par = bl_get_data(bd);
unsigned int reg = aty_ld_le32(LVDS_GEN_CNTL);
- int level;
-
- if (bd->props.power != FB_BLANK_UNBLANK ||
- bd->props.fb_blank != FB_BLANK_UNBLANK ||
- !par->lcd_on)
- level = 0;
- else
- level = bd->props.brightness;
+ int level = backlight_get_brightness(bd);
reg |= LVDS_BL_MOD_EN | LVDS_BLON;
- if (level > 0) {
+ if (level > 0 || par->lcd_on) {
reg |= LVDS_DIGION;
if (!(reg & LVDS_ON)) {
reg &= ~LVDS_BLON;
--
2.34.1
[PATCH 03/15] video: fbdev: nvidia: Introduce backlight_get_brightness()
From: Sam Ravnborg
Introduce backlight_get_brightness() to simplify logic
and avoid direct access to backlight properties.
Signed-off-by: Sam Ravnborg
Cc: Antonino Daplas
Cc: linux-fb...@vger.kernel.org
---
drivers/video/fbdev/nvidia/nv_backlight.c | 8 +---
1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/drivers/video/fbdev/nvidia/nv_backlight.c
b/drivers/video/fbdev/nvidia/nv_backlight.c
index 2ce53529f636..503a7a683855 100644
--- a/drivers/video/fbdev/nvidia/nv_backlight.c
+++ b/drivers/video/fbdev/nvidia/nv_backlight.c
@@ -49,17 +49,11 @@ static int nvidia_bl_update_status(struct backlight_device
*bd)
{
struct nvidia_par *par = bl_get_data(bd);
u32 tmp_pcrt, tmp_pmc, fpcontrol;
- int level;
+ int level = backlight_get_brightness(bd);
if (!par->FlatPanel)
return 0;
- if (bd->props.power != FB_BLANK_UNBLANK ||
- bd->props.fb_blank != FB_BLANK_UNBLANK)
- level = 0;
- else
- level = bd->props.brightness;
-
tmp_pmc = NV_RD32(par->PMC, 0x10F0) & 0x;
tmp_pcrt = NV_RD32(par->PCRTC0, 0x081C) & 0xFFFC;
fpcontrol = NV_RD32(par->PRAMDAC, 0x0848) & 0xCFCC;
--
2.34.1
[PATCH 00/15] backlight: Drop use of deprecated fb_blank property
This series refactor backlight users to avoid use of the deprecated backlight_properties.fb_blank member. Stephen Kitt and others already did a lot of work and this is the final touches. Patches 1-13 are independent and can be applied individually. Patch 14 was already sent by Stephen and included here to make the series complete. The last patch may have to wait to avoid breaking the build as it depends on all the other patches. The series touches several sub-systems, so with acks I could take them all in drm-misc. Or we can let the subsystems take them and wait until next merge window with the final removal. As new users of fb_blank do not pop up that often, waiting one merge cycle is fine. Sam To: Nicolas Ferre To: Helge Deller To: Alexandre Belloni To: Claudiu Beznea To: Antonino Daplas To: Benjamin Herrenschmidt To: Paul Mackerras To: Greg Kroah-Hartman To: Robin van der Gracht To: Miguel Ojeda To: Lee Jones To: Daniel Thompson To: Jingoo Han Cc: linux-fb...@vger.kernel.org Cc: dri-de...@lists.freedesktop.org Cc: linux-arm-ker...@lists.infradead.org Cc: linux-ker...@vger.kernel.org Cc: linux-o...@vger.kernel.org Cc: linux-stag...@lists.linux.dev Cc: linuxppc-dev@lists.ozlabs.org Cc: Stephen Kitt Signed-off-by: Sam Ravnborg --- Sam Ravnborg (14): video: fbdev: atmel_lcdfb: Rework backlight handling video: fbdev: atyfb: Introduce backlight_get_brightness() video: fbdev: nvidia: Introduce backlight_get_brightness() video: fbdev: radeon: Introduce backlight_get_brightness() video: fbdev: riva: Introduce backlight_get_brightness() video: fbdev: aty128fb: Introduce backlight_get_brightness() video: fbdev: mx3fb: Introduce backlight_get_brightness() video: fbdev: omap2: Introduce backlight_get_brightness() staging: fbtft: fb_ssd1351.c: Introduce backlight_is_blank() staging: fbtft: core: Introduce backlight_is_blank() powerpc: via-pmu-backlight: Introduce backlight_get_brightness() auxdisplay: ht16k33: Introduce backlight_get_brightness() backlight: omap1: Use backlight helpers backlight: backlight: Drop the deprecated fb_blank property Stephen Kitt (1): backlight: tosa: Use backlight helper drivers/auxdisplay/ht16k33.c | 7 +-- drivers/macintosh/via-pmu-backlight.c | 7 +-- drivers/staging/fbtft/fb_ssd1351.c | 9 +-- drivers/staging/fbtft/fbtft-core.c | 12 ++-- drivers/video/backlight/backlight.c| 2 - drivers/video/backlight/omap1_bl.c | 67 +++--- drivers/video/backlight/tosa_bl.c | 7 +-- drivers/video/fbdev/atmel_lcdfb.c | 24 +--- drivers/video/fbdev/aty/aty128fb.c | 11 +--- drivers/video/fbdev/aty/atyfb_base.c | 8 +-- drivers/video/fbdev/aty/radeon_backlight.c | 10 +--- drivers/video/fbdev/mx3fb.c| 8 +-- drivers/video/fbdev/nvidia/nv_backlight.c | 8 +-- .../fbdev/omap2/omapfb/displays/panel-dsi-cm.c | 19 +- .../omap2/omapfb/displays/panel-sony-acx565akm.c | 23 +++- drivers/video/fbdev/riva/fbdev.c | 8 +-- include/linux/backlight.h | 22 --- 17 files changed, 41 insertions(+), 211 deletions(-) --- base-commit: a53be8dae86fe5d3567db245177e814e58210632 change-id: 20230107-sam-video-backlight-drop-fb_blank-d6feb73572ff Best regards, -- Sam Ravnborg
[PATCH 01/15] video: fbdev: atmel_lcdfb: Rework backlight handling
From: Sam Ravnborg
The atmel_lcdfb had code to save/restore power state.
This is not needed so drop it.
Introduce backlight_is_brightness() to make logic simpler.
Signed-off-by: Sam Ravnborg
Cc: Nicolas Ferre
Cc: Alexandre Belloni
Cc: Ludovic Desroches
Cc: linux-fb...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
---
drivers/video/fbdev/atmel_lcdfb.c | 24 +++-
1 file changed, 3 insertions(+), 21 deletions(-)
diff --git a/drivers/video/fbdev/atmel_lcdfb.c
b/drivers/video/fbdev/atmel_lcdfb.c
index 1fc8de4ecbeb..d297b3892637 100644
--- a/drivers/video/fbdev/atmel_lcdfb.c
+++ b/drivers/video/fbdev/atmel_lcdfb.c
@@ -49,7 +49,6 @@ struct atmel_lcdfb_info {
struct clk *lcdc_clk;
struct backlight_device *backlight;
- u8 bl_power;
u8 saved_lcdcon;
u32 pseudo_palette[16];
@@ -109,32 +108,18 @@ static u32 contrast_ctr = ATMEL_LCDC_PS_DIV8
static int atmel_bl_update_status(struct backlight_device *bl)
{
struct atmel_lcdfb_info *sinfo = bl_get_data(bl);
- int power = sinfo->bl_power;
- int brightness = bl->props.brightness;
+ int brightness;
- /* REVISIT there may be a meaningful difference between
-* fb_blank and power ... there seem to be some cases
-* this doesn't handle correctly.
-*/
- if (bl->props.fb_blank != sinfo->bl_power)
- power = bl->props.fb_blank;
- else if (bl->props.power != sinfo->bl_power)
- power = bl->props.power;
-
- if (brightness < 0 && power == FB_BLANK_UNBLANK)
- brightness = lcdc_readl(sinfo, ATMEL_LCDC_CONTRAST_VAL);
- else if (power != FB_BLANK_UNBLANK)
- brightness = 0;
+ brightness = backlight_get_brightness(bl);
lcdc_writel(sinfo, ATMEL_LCDC_CONTRAST_VAL, brightness);
+
if (contrast_ctr & ATMEL_LCDC_POL_POSITIVE)
lcdc_writel(sinfo, ATMEL_LCDC_CONTRAST_CTR,
brightness ? contrast_ctr : 0);
else
lcdc_writel(sinfo, ATMEL_LCDC_CONTRAST_CTR, contrast_ctr);
- bl->props.fb_blank = bl->props.power = sinfo->bl_power = power;
-
return 0;
}
@@ -155,8 +140,6 @@ static void init_backlight(struct atmel_lcdfb_info *sinfo)
struct backlight_properties props;
struct backlight_device *bl;
- sinfo->bl_power = FB_BLANK_UNBLANK;
-
if (sinfo->backlight)
return;
@@ -173,7 +156,6 @@ static void init_backlight(struct atmel_lcdfb_info *sinfo)
sinfo->backlight = bl;
bl->props.power = FB_BLANK_UNBLANK;
- bl->props.fb_blank = FB_BLANK_UNBLANK;
bl->props.brightness = atmel_bl_get_brightness(bl);
}
--
2.34.1
[PATCH 02/15] video: fbdev: atyfb: Introduce backlight_get_brightness()
From: Sam Ravnborg
Introduce backlight_get_brightness() to simplify logic
and avoid direct access to backlight properties.
Signed-off-by: Sam Ravnborg
Cc: Bartlomiej Zolnierkiewicz
Cc: Sam Ravnborg
Cc: Daniel Vetter
Cc: Souptick Joarder
Cc: Maarten Lankhorst
Cc: Jason Yan
Cc: Jani Nikula
Cc: Arnd Bergmann
---
drivers/video/fbdev/aty/atyfb_base.c | 8 +---
1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/drivers/video/fbdev/aty/atyfb_base.c
b/drivers/video/fbdev/aty/atyfb_base.c
index 0ccf5d401ecb..ca361e215904 100644
--- a/drivers/video/fbdev/aty/atyfb_base.c
+++ b/drivers/video/fbdev/aty/atyfb_base.c
@@ -2219,13 +2219,7 @@ static int aty_bl_update_status(struct backlight_device
*bd)
{
struct atyfb_par *par = bl_get_data(bd);
unsigned int reg = aty_ld_lcd(LCD_MISC_CNTL, par);
- int level;
-
- if (bd->props.power != FB_BLANK_UNBLANK ||
- bd->props.fb_blank != FB_BLANK_UNBLANK)
- level = 0;
- else
- level = bd->props.brightness;
+ int level = backlight_get_brightness(bd);
reg |= (BLMOD_EN | BIASMOD_EN);
if (level > 0) {
--
2.34.1
[PATCH 07/15] video: fbdev: mx3fb: Introduce backlight_get_brightness()
From: Sam Ravnborg
Introduce backlight_get_brightness() to simplify logic
and avoid direct access to backlight properties.
Signed-off-by: Sam Ravnborg
Cc: Sam Ravnborg
Cc: Kate Stewart
Cc: Thomas Gleixner
Cc: Laurent Pinchart
Cc: Greg Kroah-Hartman
Cc: Arnd Bergmann
Cc: Jani Nikula
---
drivers/video/fbdev/mx3fb.c | 8 +---
1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/drivers/video/fbdev/mx3fb.c b/drivers/video/fbdev/mx3fb.c
index b945b68984b9..bc35f664cbff 100644
--- a/drivers/video/fbdev/mx3fb.c
+++ b/drivers/video/fbdev/mx3fb.c
@@ -283,12 +283,7 @@ static int mx3fb_bl_get_brightness(struct backlight_device
*bl)
static int mx3fb_bl_update_status(struct backlight_device *bl)
{
struct mx3fb_data *fbd = bl_get_data(bl);
- int brightness = bl->props.brightness;
-
- if (bl->props.power != FB_BLANK_UNBLANK)
- brightness = 0;
- if (bl->props.fb_blank != FB_BLANK_UNBLANK)
- brightness = 0;
+ int brightness = backlight_get_brightness(bl);
fbd->backlight_level = (fbd->backlight_level & ~0xFF) | brightness;
@@ -325,7 +320,6 @@ static void mx3fb_init_backlight(struct mx3fb_data *fbd)
fbd->bl = bl;
bl->props.power = FB_BLANK_UNBLANK;
- bl->props.fb_blank = FB_BLANK_UNBLANK;
bl->props.brightness = mx3fb_bl_get_brightness(bl);
}
--
2.34.1
[PATCH 04/15] video: fbdev: radeon: Introduce backlight_get_brightness()
From: Sam Ravnborg Introduce backlight_get_brightness() to simplify logic and avoid direct access to backlight properties. Signed-off-by: Sam Ravnborg Cc: Benjamin Herrenschmidt Cc: linux-fb...@vger.kernel.org --- drivers/video/fbdev/aty/radeon_backlight.c | 10 +++--- 1 file changed, 3 insertions(+), 7 deletions(-) diff --git a/drivers/video/fbdev/aty/radeon_backlight.c b/drivers/video/fbdev/aty/radeon_backlight.c index d2c1263ad260..22a39fea7b89 100644 --- a/drivers/video/fbdev/aty/radeon_backlight.c +++ b/drivers/video/fbdev/aty/radeon_backlight.c @@ -54,14 +54,10 @@ static int radeon_bl_update_status(struct backlight_device *bd) return 0; /* We turn off the LCD completely instead of just dimming the -* backlight. This provides some greater power saving and the display -* is useless without backlight anyway. +* backlight if level < 1. This provides some greater power saving +* and the display is useless without backlight anyway. */ -if (bd->props.power != FB_BLANK_UNBLANK || - bd->props.fb_blank != FB_BLANK_UNBLANK) - level = 0; - else - level = bd->props.brightness; + level = backlight_get_brightness(bd); del_timer_sync(>lvds_timer); radeon_engine_idle(); -- 2.34.1
[PATCH 09/15] staging: fbtft: fb_ssd1351.c: Introduce backlight_is_blank()
From: Sam Ravnborg
Avoiding direct access to backlight_properties.props.
Access to the deprecated props.fb_blank replaced by backlight_is_blank().
Access to props.power is dropped - it was only used for debug.
Signed-off-by: Sam Ravnborg
Cc: Stephen Kitt
Cc: Greg Kroah-Hartman
Cc: Daniel Thompson
Cc: Andy Shevchenko
Cc: linux-fb...@vger.kernel.org
---
drivers/staging/fbtft/fb_ssd1351.c | 9 +++--
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/drivers/staging/fbtft/fb_ssd1351.c
b/drivers/staging/fbtft/fb_ssd1351.c
index b8d55aa8c5c7..995fbd2f3dc6 100644
--- a/drivers/staging/fbtft/fb_ssd1351.c
+++ b/drivers/staging/fbtft/fb_ssd1351.c
@@ -190,15 +190,12 @@ static struct fbtft_display display = {
static int update_onboard_backlight(struct backlight_device *bd)
{
struct fbtft_par *par = bl_get_data(bd);
- bool on;
+ bool blank = backlight_is_blank(bd);
- fbtft_par_dbg(DEBUG_BACKLIGHT, par,
- "%s: power=%d, fb_blank=%d\n",
- __func__, bd->props.power, bd->props.fb_blank);
+ fbtft_par_dbg(DEBUG_BACKLIGHT, par, "%s: blank=%d\n", __func__, blank);
- on = !backlight_is_blank(bd);
/* Onboard backlight connected to GPIO0 on SSD1351, GPIO1 unused */
- write_reg(par, 0xB5, on ? 0x03 : 0x02);
+ write_reg(par, 0xB5, !blank ? 0x03 : 0x02);
return 0;
}
--
2.34.1
[PATCH 05/15] video: fbdev: riva: Introduce backlight_get_brightness()
From: Sam Ravnborg
Introduce backlight_get_brightness() to simplify logic
and avoid direct access to backlight properties.
Signed-off-by: Sam Ravnborg
Cc: Antonino Daplas
Cc: linux-fb...@vger.kernel.org
---
drivers/video/fbdev/riva/fbdev.c | 8 +---
1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/drivers/video/fbdev/riva/fbdev.c b/drivers/video/fbdev/riva/fbdev.c
index 644278146d3b..41edc6e79460 100644
--- a/drivers/video/fbdev/riva/fbdev.c
+++ b/drivers/video/fbdev/riva/fbdev.c
@@ -293,13 +293,7 @@ static int riva_bl_update_status(struct backlight_device
*bd)
{
struct riva_par *par = bl_get_data(bd);
U032 tmp_pcrt, tmp_pmc;
- int level;
-
- if (bd->props.power != FB_BLANK_UNBLANK ||
- bd->props.fb_blank != FB_BLANK_UNBLANK)
- level = 0;
- else
- level = bd->props.brightness;
+ int level = backlight_get_brightness(bd);
tmp_pmc = NV_RD32(par->riva.PMC, 0x10F0) & 0x;
tmp_pcrt = NV_RD32(par->riva.PCRTC0, 0x081C) & 0xFFFC;
--
2.34.1
Re: [PATCH 01/15] video: fbdev: atmel_lcdfb: Rework backlight handling
Hi Stephen. On Sat, Jan 07, 2023 at 09:36:47PM +0100, Stephen Kitt wrote: > On 7 January 2023 19:26:15 CET, Sam Ravnborg via B4 Submission Endpoint > wrote: > >From: Sam Ravnborg > > > >The atmel_lcdfb had code to save/restore power state. > >This is not needed so drop it. > > > >Introduce backlight_is_brightness() to make logic simpler. > > > >Signed-off-by: Sam Ravnborg > >Cc: Nicolas Ferre > >Cc: Alexandre Belloni > >Cc: Ludovic Desroches > >Cc: linux-fb...@vger.kernel.org > >Cc: linux-arm-ker...@lists.infradead.org > >--- > > drivers/video/fbdev/atmel_lcdfb.c | 24 +++- > > 1 file changed, 3 insertions(+), 21 deletions(-) ... > > Hi Sam, > > I’d submitted quite a few more of these previously (and you’d reviewed them), > see e.g. the thread starting at https://lkml.org/lkml/2022/6/7/4365, and > yesterday, https://lkml.org/lkml/2023/1/6/520, > https://lkml.org/lkml/2023/1/6/656, https://lkml.org/lkml/2023/1/6/970, > https://lkml.org/lkml/2023/1/6/643, and https://lkml.org/lkml/2023/1/6/680. > There are a few more, I can find them if it’s any use. The patches from yesterday was what triggered me to resurrect an old branch of mine where I had done something similar. I had lost all memory of reviewing similar patches from you. Helge - could you pick the reviewed patches from: https://lore.kernel.org/all/20220607192335.1137249-1-st...@sk2.org/ [This is the same mail as Stephen refer to above - looked up via lore]. Stephen - I expect Daniel/Lee to take care of the patches from yesterday. If you can look up other pending patches from you please do so, so we can have them applied. Preferably with links to lore - as this makes it easier to apply them. Review of what is unique in this set would be appreciated. Sam
Re: [PATCH 01/15] video: fbdev: atmel_lcdfb: Rework backlight handling
On 7 January 2023 19:26:15 CET, Sam Ravnborg via B4 Submission Endpoint
wrote:
>From: Sam Ravnborg
>
>The atmel_lcdfb had code to save/restore power state.
>This is not needed so drop it.
>
>Introduce backlight_is_brightness() to make logic simpler.
>
>Signed-off-by: Sam Ravnborg
>Cc: Nicolas Ferre
>Cc: Alexandre Belloni
>Cc: Ludovic Desroches
>Cc: linux-fb...@vger.kernel.org
>Cc: linux-arm-ker...@lists.infradead.org
>---
> drivers/video/fbdev/atmel_lcdfb.c | 24 +++-
> 1 file changed, 3 insertions(+), 21 deletions(-)
>
>diff --git a/drivers/video/fbdev/atmel_lcdfb.c
>b/drivers/video/fbdev/atmel_lcdfb.c
>index 1fc8de4ecbeb..d297b3892637 100644
>--- a/drivers/video/fbdev/atmel_lcdfb.c
>+++ b/drivers/video/fbdev/atmel_lcdfb.c
>@@ -49,7 +49,6 @@ struct atmel_lcdfb_info {
> struct clk *lcdc_clk;
>
> struct backlight_device *backlight;
>- u8 bl_power;
> u8 saved_lcdcon;
>
> u32 pseudo_palette[16];
>@@ -109,32 +108,18 @@ static u32 contrast_ctr = ATMEL_LCDC_PS_DIV8
> static int atmel_bl_update_status(struct backlight_device *bl)
> {
> struct atmel_lcdfb_info *sinfo = bl_get_data(bl);
>- int power = sinfo->bl_power;
>- int brightness = bl->props.brightness;
>+ int brightness;
>
>- /* REVISIT there may be a meaningful difference between
>- * fb_blank and power ... there seem to be some cases
>- * this doesn't handle correctly.
>- */
>- if (bl->props.fb_blank != sinfo->bl_power)
>- power = bl->props.fb_blank;
>- else if (bl->props.power != sinfo->bl_power)
>- power = bl->props.power;
>-
>- if (brightness < 0 && power == FB_BLANK_UNBLANK)
>- brightness = lcdc_readl(sinfo, ATMEL_LCDC_CONTRAST_VAL);
>- else if (power != FB_BLANK_UNBLANK)
>- brightness = 0;
>+ brightness = backlight_get_brightness(bl);
>
> lcdc_writel(sinfo, ATMEL_LCDC_CONTRAST_VAL, brightness);
>+
> if (contrast_ctr & ATMEL_LCDC_POL_POSITIVE)
> lcdc_writel(sinfo, ATMEL_LCDC_CONTRAST_CTR,
> brightness ? contrast_ctr : 0);
> else
> lcdc_writel(sinfo, ATMEL_LCDC_CONTRAST_CTR, contrast_ctr);
>
>- bl->props.fb_blank = bl->props.power = sinfo->bl_power = power;
>-
> return 0;
> }
>
>@@ -155,8 +140,6 @@ static void init_backlight(struct atmel_lcdfb_info *sinfo)
> struct backlight_properties props;
> struct backlight_device *bl;
>
>- sinfo->bl_power = FB_BLANK_UNBLANK;
>-
> if (sinfo->backlight)
> return;
>
>@@ -173,7 +156,6 @@ static void init_backlight(struct atmel_lcdfb_info *sinfo)
> sinfo->backlight = bl;
>
> bl->props.power = FB_BLANK_UNBLANK;
>- bl->props.fb_blank = FB_BLANK_UNBLANK;
> bl->props.brightness = atmel_bl_get_brightness(bl);
> }
>
>
Hi Sam,
I’d submitted quite a few more of these previously (and you’d reviewed them),
see e.g. the thread starting at https://lkml.org/lkml/2022/6/7/4365, and
yesterday, https://lkml.org/lkml/2023/1/6/520,
https://lkml.org/lkml/2023/1/6/656, https://lkml.org/lkml/2023/1/6/970,
https://lkml.org/lkml/2023/1/6/643, and https://lkml.org/lkml/2023/1/6/680.
There are a few more, I can find them if it’s any use.
Regards,
Stephen
Re: [PATCH 12/15] auxdisplay: ht16k33: Introduce backlight_get_brightness()
On Sat, Jan 7, 2023 at 7:26 PM Sam Ravnborg via B4 Submission Endpoint wrote: > > Introduce backlight_get_brightness() to simplify logic > and avoid direct access to backlight properties. Note: Stephen sent this one too a while ago (with some more details in the commit message, which is always nice); and then he sent yesterday v2 [1] (to mention the functional change with `BL_CORE_SUSPENDED` [2]). Anyway, if it goes via drm-misc, feel free to have my: Acked-by: Miguel Ojeda Though it would be nice to have Robin test the change. Thanks! [1] https://lore.kernel.org/lkml/20230106143002.1434266-1-st...@sk2.org/ [2] https://lore.kernel.org/lkml/caniq72krhmt37h1fagygny83onyxeqjuo8zpbym0ajqowky...@mail.gmail.com/ Cheers, Miguel
Re: [PATCH net-next 1/7] ethernet: Remove the Sun Cassini driver
On 1/7/2023 4:25 AM, Anatoly Pugachev wrote: On Sat, Jan 7, 2023 at 1:00 AM Anirudh Venkataramanan wrote: In a recent patch series that touched this driver [1], it was suggested that this driver should be removed completely. git logs suggest that there hasn't been any significant feature addition, improvement or fixes to user-visible bugs in a while. A web search didn't indicate any recent discussions or any evidence that there are users out there who care about this driver. Thus, remove this driver. Notes: checkpatch complains "WARNING: added, moved or deleted file(s), does MAINTAINERS need updating?". The files being removed don't have their own entries in the MAINTAINERS file, so there's nothing to remove. checkpatch also complains about the long lore link below. [1] https://lore.kernel.org/netdev/99629223-ac1b-0f82-50b8-ea307b3b0...@intel.com/T/#t Suggested-by: Leon Romanovsky Signed-off-by: Anirudh Venkataramanan Do we drop/delete a working functionality by only taking in account git activity ? No, but in some cases it's enough to at least start asking the "who uses this code? should we continue maintaining it?" type questions. In the cover letter I did say this: "The idea behind putting out this series is to either establish that these drivers are used and should be maintained, or remove them." We have established that these drivers are indeed used, and thus shouldn't be removed. What is a proper way to decline patch series (vs Acked-by) ? There's no tag that I am aware of. I have seen people say "NACK" or "please don't do this" followed by an explanation of why the patch/series is a bad idea. For example, see the other responses to this series. Ani
Re: [PATCH net-next 1/7] ethernet: Remove the Sun Cassini driver
On Sat, Jan 7, 2023 at 1:00 AM Anirudh Venkataramanan wrote: > > In a recent patch series that touched this driver [1], it was suggested > that this driver should be removed completely. git logs suggest that > there hasn't been any significant feature addition, improvement or fixes to > user-visible bugs in a while. A web search didn't indicate any recent > discussions or any evidence that there are users out there who care about > this driver. Thus, remove this driver. > > Notes: > > checkpatch complains "WARNING: added, moved or deleted file(s), does > MAINTAINERS need updating?". The files being removed don't have their > own entries in the MAINTAINERS file, so there's nothing to remove. > > checkpatch also complains about the long lore link below. > > [1] > https://lore.kernel.org/netdev/99629223-ac1b-0f82-50b8-ea307b3b0...@intel.com/T/#t > > Suggested-by: Leon Romanovsky > Signed-off-by: Anirudh Venkataramanan Do we drop/delete a working functionality by only taking in account git activity ? What is a proper way to decline patch series (vs Acked-by) ? Thanks.
Re: [PATCH net-next 7/7] sparc: configs: Remove references to CONFIG_SUNVNET and CONFIG_LDMVSW
On Sat, Jan 7, 2023 at 1:00 AM Anirudh Venkataramanan wrote: > > An earlier patch removed the Sun LDOM vswitch and sunvnet drivers. Remove > references to CONFIG_SUNVNET and CONFIG_LDMVSW from the sparc64 defconfig. > > Cc: Leon Romanovsky > Signed-off-by: Anirudh Venkataramanan > --- > arch/sparc/configs/sparc64_defconfig | 2 -- > 1 file changed, 2 deletions(-) > > diff --git a/arch/sparc/configs/sparc64_defconfig > b/arch/sparc/configs/sparc64_defconfig > index 1809909..a2c76e8 100644 > --- a/arch/sparc/configs/sparc64_defconfig > +++ b/arch/sparc/configs/sparc64_defconfig > @@ -95,8 +95,6 @@ CONFIG_MII=m > CONFIG_SUNLANCE=m > CONFIG_HAPPYMEAL=y > CONFIG_SUNGEM=m > -CONFIG_SUNVNET=m > -CONFIG_LDMVSW=m > CONFIG_NET_PCI=y > CONFIG_E1000=m > CONFIG_E1000E=m I wonder what is the reason for removing the perfectly working sunvnet driver which is used in LDOMs under sun hardware hypervisor? Can we please not remove drivers which are actually used? Or either drop sparc32/sparc64 (whole arch) from linux kernel as well. Thanks.
Re: [PATCH v3 3/8] sched, smp: Trace IPIs sent via send_call_function_single_ipi()
* Valentin Schneider wrote: > send_call_function_single_ipi() is the thing that sends IPIs at the bottom > of smp_call_function*() via either generic_exec_single() or > smp_call_function_many_cond(). Give it an IPI-related tracepoint. > > Note that this ends up tracing any IPI sent via __smp_call_single_queue(), > which covers __ttwu_queue_wakelist() and irq_work_queue_on() "for free". > > Signed-off-by: Valentin Schneider > Reviewed-by: Steven Rostedt (Google) Acked-by: Ingo Molnar Patch series logistics: - No objections from the scheduler side, this feature looks pretty useful. - Certain patches are incomplete, others are noted as being merged separately, so I presume you'll send an updated/completed series eventually? - We can merge this via the scheduler tree I suspect, as most callbacks affected relate to tip:sched/core and tmp:smp/core - but if you have some other preferred tree that's fine too. Thanks, Ingo
Re: [PATCH] objtool: continue if find_insn() fails in decode_instructions()
* Sathvika Vasireddy wrote:
> Currently, decode_instructions() is failing if it is not able to find
> instruction, and this is happening since commit dbcdbdfdf137b4
> ("objtool: Rework instruction -> symbol mapping") because it is
> expecting instruction for STT_NOTYPE symbols.
>
> Due to this, the following objtool warnings are seen:
> [1] arch/powerpc/kernel/optprobes_head.o: warning: objtool:
> optprobe_template_end(): can't find starting instruction
> [2] arch/powerpc/kernel/kvm_emul.o: warning: objtool: kvm_template_end():
> can't find starting instruction
> [3] arch/powerpc/kernel/head_64.o: warning: objtool: end_first_256B(): can't
> find starting instruction
>
> The warnings are thrown because find_insn() is failing for symbols that
> are at the end of the file, or at the end of the section. Given how
> STT_NOTYPE symbols are currently handled in decode_instructions(),
> continue if the instruction is not found, instead of throwing warning
> and returning.
>
> Signed-off-by: Naveen N. Rao
> Signed-off-by: Sathvika Vasireddy
The SOB chain doesn't look valid: is Naveen N. Rao, the first SOB line, the
author of the patch? If yes then a matching From: line is needed.
Or if two people developed the patch, then Co-developed-by should be used:
Co-developed-by: First Co-Author
Signed-off-by: First Co-Author
Co-developed-by: Second Co-Author
Signed-off-by: Second Co-Author
[ In this SOB sequence "Second Co-Author" is the one who submits the patch. ]
[ Please only use Co-developed-by if actual lines of code were written by
the co-author that created copyrightable material - it's not a courtesy
tag. Reviewed-by/Acked-by/Tested-by can be used to credit non-code
contributions. ]
Thanks,
Ingo
