backlight: Drop use of deprecated fb_blank property

From: Sam Ravnborg <[email protected]>

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 <[email protected]>

Cc Nicolas Ferre <[email protected]>

Cc Alexandre Belloni <[email protected]>

Cc Ludovic Desroches <[email protected]>

Cc [email protected]

Cc [email protected]

---
drivers/video/fbdev/atmel_lcdfb.c | 24 +++---------------------

1 file changed, 3 insertions(+), 21 deletions(-)

drivers/video/fbdev/atmel_lcdfb.c +3 -20

index 1fc8de4ecbeb..d297b3892637 100644
@@ -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;
 

Quoted 16 lines · On 7 January 2023 19:26:15 CET, Sam Ravnborg via B4 Submission Endpoint…

From: Sam Ravnborg <[email protected]>

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 <[email protected]>

Cc Nicolas Ferre <[email protected]>

Cc Alexandre Belloni <[email protected]>

Cc Ludovic Desroches <[email protected]>

Cc [email protected]

Cc [email protected]

---
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.

Hi Stephen.

Quoted 17 lines · Stephen Kitt

Quoted 16 lines · On 7 January 2023 19:26:15 CET, Sam Ravnborg via B4 Submission Endpoint…

From: Sam Ravnborg <[email protected]>

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 <[email protected]>

Cc Nicolas Ferre <[email protected]>

Cc Alexandre Belloni <[email protected]>

Cc Ludovic Desroches <[email protected]>

Cc [email protected]

Cc [email protected]

---
drivers/video/fbdev/atmel_lcdfb.c | 24 +++---------------------

1 file changed, 3 insertions(+), 21 deletions(-)

...

Quoted 4 lines

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/[email protected]/
[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

Quoted 35 lines · Sam Ravnborg

Hi Stephen.

Quoted 17 lines · Stephen Kitt

Quoted 16 lines · On 7 January 2023 19:26:15 CET, Sam Ravnborg via B4 Submission Endpoint…

From: Sam Ravnborg <[email protected]>

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 <[email protected]>

Cc Nicolas Ferre <[email protected]>

Cc Alexandre Belloni <[email protected]>

Cc Ludovic Desroches <[email protected]>

Cc [email protected]

Cc [email protected]

---
drivers/video/fbdev/atmel_lcdfb.c | 24 +++---------------------

1 file changed, 3 insertions(+), 21 deletions(-)

...

Quoted 4 lines

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/[email protected]/
[This is the same mail as Stephen refer to above - looked up via lore].

Quoted 8 lines

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/[email protected]/
* https://lore.kernel.org/lkml/[email protected]/
* https://lore.kernel.org/lkml/[email protected]/
* https://lore.kernel.org/lkml/[email protected]/

I’ll send reviews of your other patches later today or tomorrow.

Regards,

Stephen

Here are my pending patches from last June on lore:

* https://lore.kernel.org/lkml/[email protected]/

Quoted 2 lines

Here are my pending patches from last June on lore:

All patches are handled I think except this:

Quoted 1 line

* https://lore.kernel.org/lkml/[email protected]/

Can I ask you to drop the assignment that is not needed, and resend with the collected acks/r-b.

With this, then all fbdev patches are handled.

Quoted 10 lines · Sam Ravnborg

Quoted 2 lines

Here are my pending patches from last June on lore:

All patches are handled I think except this:

Quoted 2 lines

* https://lore.kernel.org/lkml/[email protected]/

Can I ask you to drop the assignment that is not needed, and resend with the collected acks/r-b.

Quoted 1 line

With this, then all fbdev patches are handled.

Ah yes, it was revised as
https://lore.kernel.org/lkml/[email protected]/ which only got one ack (from you,
https://lore.kernel.org/lkml/[email protected]/). Should I resend that or is that usable as-is? Or would it be better if I sent all the fbdev patches again (collecting all the acks and reviews)?

Hi Stephen.

Quoted 17 lines · Stephen Kitt

Quoted 16 lines · On 7 January 2023 19:26:15 CET, Sam Ravnborg via B4 Submission Endpoint…

From: Sam Ravnborg <[email protected]>

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 <[email protected]>

Cc Nicolas Ferre <[email protected]>

Cc Alexandre Belloni <[email protected]>

Cc Ludovic Desroches <[email protected]>

Cc [email protected]

Cc [email protected]

---
drivers/video/fbdev/atmel_lcdfb.c | 24 +++---------------------

1 file changed, 3 insertions(+), 21 deletions(-)

...

Quoted 4 lines

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/[email protected]/
[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

Quoted 4 lines

Helge - could you pick the reviewed patches from:
https://lore.kernel.org/all/[email protected]/
[This is the same mail as Stephen refer to above - looked up via lore].

I just pulled those 7 patches into fbdev/for-next. If you need more, please let me know,

Quoted 38 lines · Sam Ravnborg

Hi Stephen.

Quoted 18 lines · Stephen Kitt

Quoted 16 lines · On 7 January 2023 19:26:15 CET, Sam Ravnborg via B4 Submission Endpoint…

From: Sam Ravnborg <[email protected]>

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 <[email protected]>

Cc Nicolas Ferre <[email protected]>

Cc Alexandre Belloni <[email protected]>

Cc Ludovic Desroches <[email protected]>

Cc [email protected]

Cc [email protected]

---
drivers/video/fbdev/atmel_lcdfb.c | 24 +++---------------------

1 file changed, 3 insertions(+), 21 deletions(-)  

...

Quoted 10 lines

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.

Quoted 3 lines

Helge - could you pick the reviewed patches from:
https://lore.kernel.org/all/[email protected]/
[This is the same mail as Stephen refer to above - looked up via lore].

I just pulled those 7 patches into fbdev/for-next. If you need more, please let me know,

Quoted 43 lines · Helge Deller

Quoted 41 lines · Sam Ravnborg

Hi Stephen.

Quoted 18 lines · Stephen Kitt

Quoted 16 lines · On 7 January 2023 19:26:15 CET, Sam Ravnborg via B4 Submission Endpoint…

From: Sam Ravnborg <[email protected]>

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 <[email protected]>

Cc Nicolas Ferre <[email protected]>

Cc Alexandre Belloni <[email protected]>

Cc Ludovic Desroches <[email protected]>

Cc [email protected]

Cc [email protected]

---
drivers/video/fbdev/atmel_lcdfb.c | 24 +++---------------------

1 file changed, 3 insertions(+), 21 deletions(-)

...

Quoted 10 lines

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/[email protected]/
[This is the same mail as Stephen refer to above - looked up via lore].

Quoted 2 lines

I just pulled those 7 patches into fbdev/for-next. If you need more, please let me know,

Please pull
https://lore.kernel.org/lkml/[email protected]/ too, it completes the fbdev set. (It’s a re-send of
https://lore.kernel.org/lkml/[email protected]/).

From: Sam Ravnborg <[email protected]>

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 <[email protected]>

Cc Nicolas Ferre <[email protected]>

Cc Alexandre Belloni <[email protected]>

Cc Ludovic Desroches <[email protected]>

Cc [email protected]

Cc [email protected]

---
 drivers/video/fbdev/atmel_lcdfb.c | 24 +++---------------------
 1 file changed, 3 insertions(+), 21 deletions(-)

drivers/video/fbdev/atmel_lcdfb.c +3 -21

index 1fc8de4ecbeb..d297b3892637 100644
@@ -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);
 }

From: Sam Ravnborg <[email protected]>

Introduce backlight_get_brightness() to simplify logic and avoid direct access to backlight properties.

Signed-off-by Sam Ravnborg <[email protected]>

Cc Bartlomiej Zolnierkiewicz <[email protected]>

Cc Sam Ravnborg <[email protected]>

Cc Daniel Vetter <[email protected]>

Cc Souptick Joarder <[email protected]>

Cc Maarten Lankhorst <[email protected]>

Cc Jason Yan <[email protected]>

Cc Jani Nikula <[email protected]>

Cc Arnd Bergmann <[email protected]>

---
  drivers/video/fbdev/aty/atyfb_base.c | 8 +-------
  1 file changed, 1 insertion(+), 7 deletions(-)

drivers/video/fbdev/aty/atyfb_base.c +1 -8

index 0ccf5d401ecb..ca361e215904 100644
@@ -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

Le 07/01/2023 à 19:26, Sam Ravnborg via B4 Submission Endpoint a écrit :

Quoted 2 lines

From: Sam Ravnborg <[email protected]>

Quoted 2 lines

Introduce backlight_get_brightness() to simplify logic and avoid direct access to backlight properties.

When I read 'introduce' I understand that you are adding a new function.

In fact backlight_get_brightness() already exists, so maybe replace 'introduce' by 'use'

From: Sam Ravnborg <[email protected]>

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 <[email protected]>

Cc Stephen Kitt <[email protected]>

Cc Greg Kroah-Hartman <[email protected]>

Cc Daniel Thompson <[email protected]>

Cc Andy Shevchenko <[email protected]>

Cc [email protected]

---
 drivers/staging/fbtft/fb_ssd1351.c | 9 +++------
 1 file changed, 3 insertions(+), 6 deletions(-)

(quoted diff) +0 -0

b/drivers/staging/fbtft/fb_ssd1351.c index b8d55aa8c5c7..995fbd2f3dc6 100644

drivers/staging/fbtft/fb_ssd1351.c +3 -6

@@ -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;
 }

Signature · 2 lines

-- 
2.34.1

Quoted 43 lines · On Sat, 07 Jan 2023 19:26:23 +0100, Sam Ravnborg via B4 Submission Endpoint…

From: Sam Ravnborg <[email protected]>

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 <[email protected]>

Cc Stephen Kitt <[email protected]>

Cc Greg Kroah-Hartman <[email protected]>

Cc Daniel Thompson <[email protected]>

Cc Andy Shevchenko <[email protected]>

Cc [email protected]

---
 drivers/staging/fbtft/fb_ssd1351.c | 9 +++------
 1 file changed, 3 insertions(+), 6 deletions(-)

(quoted diff) +0 -0

b/drivers/staging/fbtft/fb_ssd1351.c index b8d55aa8c5c7..995fbd2f3dc6 100644

drivers/staging/fbtft/fb_ssd1351.c +3 -6

@@ -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;
 }

Signature · 2 lines

-- 
2.34.1

For debugging purposes here, would there be any point in logging props.state? As in

fbtft_par_dbg(DEBUG_BACKLIGHT, par,

Quoted 53 lines · Stephen Kitt

Quoted 45 lines · On Sat, 07 Jan 2023 19:26:23 +0100, Sam Ravnborg via B4 Submission Endpoint…

From: Sam Ravnborg <[email protected]>

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 <[email protected]>

Cc Stephen Kitt <[email protected]>

Cc Greg Kroah-Hartman <[email protected]>

Cc Daniel Thompson <[email protected]>

Cc Andy Shevchenko <[email protected]>

Cc [email protected]

---
 drivers/staging/fbtft/fb_ssd1351.c | 9 +++------
 1 file changed, 3 insertions(+), 6 deletions(-)

(quoted diff) +0 -0

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

drivers/staging/fbtft/fb_ssd1351.c +2 -5

@@ -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 */

drivers/staging/fbtft/fb_ssd1351.c +1 -1

-	write_reg(par, 0xB5, on ? 0x03 : 0x02);
+	write_reg(par, 0xB5, !blank ? 0x03 : 0x02);
 
 	return 0;
 }

Signature · 2 lines

-- 
2.34.1  

For debugging purposes here, would there be any point in logging props.state? As in

fbtft_par_dbg(DEBUG_BACKLIGHT, par,

drivers/staging/fbtft/fb_ssd1351.c static struct fbtft_display display = {

Quoted 4 lines

drivers/staging/fbtft/fb_ssd1351.c +2 -2

-                     "%s: power=%d, fb_blank=%d\n",
-                     __func__, bd->props.power, bd->props.fb_blank);
+                     "%s: power=%d, state=%u\n",
+                     __func__, bd->props.power, bd->props.state);  

Thanks for the suggestion - and the reviews!

I was tempted to just remove the debugging.
If we require debugging, then this could be added in the backlight core, thus everyone would benefit from it.

The solution above avoid any direct use of backlight_properties which I consider a layer violation outside the backlight core. (We cannot avoid it today with the current interface - but we can minimize it).

Hi Stephen,

Quoted 51 lines · Stephen Kitt

Quoted 42 lines · On Sat, 07 Jan 2023 19:26:23 +0100, Sam Ravnborg via B4 Submission Endpoint…

From: Sam Ravnborg <[email protected]>

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 <[email protected]>

Cc Stephen Kitt <[email protected]>

Cc Greg Kroah-Hartman <[email protected]>

Cc Daniel Thompson <[email protected]>

Cc Andy Shevchenko <[email protected]>

Cc [email protected]

---
 drivers/staging/fbtft/fb_ssd1351.c | 9 +++------
 1 file changed, 3 insertions(+), 6 deletions(-)

(quoted diff) +0 -0

b/drivers/staging/fbtft/fb_ssd1351.c index b8d55aa8c5c7..995fbd2f3dc6 100644

drivers/staging/fbtft/fb_ssd1351.c +3 -7

@@ -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;
 }
 
--

Quoted 1 line

2.34.1

For debugging purposes here, would there be any point in logging props.state? As in

fbtft_par_dbg(DEBUG_BACKLIGHT, par,

drivers/staging/fbtft/fb_ssd1351.c static struct fbtft_display display = {

Quoted 4 lines

drivers/staging/fbtft/fb_ssd1351.c +2 -2

-                     "%s: power=%d, fb_blank=%d\n",
-                     __func__, bd->props.power, bd->props.fb_blank);
+                     "%s: power=%d, state=%u\n",
+                     __func__, bd->props.power, bd->props.state);

Thanks for the suggestion - and the reviews!

I was tempted to just remove the debugging.
If we require debugging, then this could be added in the backlight core, thus everyone would benefit from it.

From: Sam Ravnborg <[email protected]>

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 <[email protected]>

Cc Stephen Kitt <[email protected]>

Cc Greg Kroah-Hartman <[email protected]>

Cc Daniel Thompson <[email protected]>

Cc Andy Shevchenko <[email protected]>

Cc [email protected]

From: Sam Ravnborg <[email protected]>

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 <[email protected]>

Cc Thomas Zimmermann <[email protected]>

Cc Andy Shevchenko <[email protected]>

Cc Javier Martinez Canillas <[email protected]>

Cc Greg Kroah-Hartman <[email protected]>

Cc Sam Ravnborg <[email protected]>

Cc Stephen Kitt <[email protected]>

Cc Peter Suti <[email protected]>

Cc [email protected]

---
 drivers/staging/fbtft/fbtft-core.c | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

(quoted diff) +0 -0

b/drivers/staging/fbtft/fbtft-core.c index afaba94d1d1c..1746327e1939 100644

drivers/staging/fbtft/fbtft-core.c +6 -6

@@ -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;

}

Signature · 1 line

2.34.1

From: Sam Ravnborg <[email protected]>

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.

From: Sam Ravnborg <[email protected]>

Introduce backlight_get_brightness() to simplify logic and avoid direct access to backlight properties.

Signed-off-by Sam Ravnborg <[email protected]>

Cc Benjamin Herrenschmidt <[email protected]>

Cc Sam Ravnborg <[email protected]>

Cc [email protected]

---
 drivers/macintosh/via-pmu-backlight.c | 7 +------
 1 file changed, 1 insertion(+), 6 deletions(-)

(quoted diff) +0 -0

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

drivers/macintosh/via-pmu-backlight.c +1 -6

@@ -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);

Signature · 2 lines

-- 
2.34.1

Introduce backlight_get_brightness() to simplify logic and avoid direct access to backlight properties.

Quoted 3 lines · On Sat, Jan 7, 2023 at 7:26 PM Sam Ravnborg via B4 Submission Endpoint…

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 <[email protected]>

Though it would be nice to have Robin test the change.

Thanks!

[1] https://lore.kernel.org/lkml/[email protected]/
[2] https://lore.kernel.org/lkml/CANiq72kRhmT37H1FAGYGny83ONYXeqJuO8ZPbym0ajQOWKY4Kw@mail.gmail.com/

Cheers,
Miguel

Hi Robin.

Quoted 10 lines · Miguel Ojeda

Quoted 3 lines · On Sat, Jan 7, 2023 at 7:26 PM Sam Ravnborg via B4 Submission Endpoint…

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]).

Thanks for the pointers. I will try to move forward with Stephen's patches.

Quoted 1 line

Quoted 5 lines

Anyway, if it goes via drm-misc, feel free to have my:

Acked-by Miguel Ojeda <[email protected]>

Though it would be nice to have Robin test the change.

Robin - can I get your ack to apply Stephen's original v2 patch to drm-misc?

Quoted 18 lines · Sam Ravnborg

Quoted 10 lines · Miguel Ojeda

Quoted 3 lines · On Sat, Jan 7, 2023 at 7:26 PM Sam Ravnborg via B4 Submission Endpoint…

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]).

Thanks for the pointers. I will try to move forward with Stephen's patches.

Quoted 5 lines

Anyway, if it goes via drm-misc, feel free to have my:

Acked-by Miguel Ojeda <[email protected]>

Quoted 4 lines

Quoted 1 line

Though it would be nice to have Robin test the change.

Robin - can I get your ack to apply Stephen's original v2 patch to drm-misc?

done! see:
https://lore.kernel.org/lkml/[email protected]/

Hi,

Quoted 21 lines · Robin van der Gracht

Quoted 20 lines · Sam Ravnborg

Quoted 10 lines · Miguel Ojeda

Quoted 3 lines · On Sat, Jan 7, 2023 at 7:26 PM Sam Ravnborg via B4 Submission Endpoint…

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]).

Thanks for the pointers. I will try to move forward with Stephen's patches.

Quoted 6 lines

Anyway, if it goes via drm-misc, feel free to have my:

Acked-by Miguel Ojeda <[email protected]>

Though it would be nice to have Robin test the change.

Quoted 5 lines

Quoted 2 lines

Robin - can I get your ack to apply Stephen's original v2 patch to drm-misc?

done! see:
https://lore.kernel.org/lkml/[email protected]/

As far as I can tell, this never got applied to drm-misc, and I don’t see it anywhere else. I guess it slipped through the cracks ;-)

From: Sam Ravnborg <[email protected]>

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 <[email protected]>

Cc Lee Jones <[email protected]>

Cc Daniel Thompson <[email protected]>

Cc Jingoo Han <[email protected]>

---
 drivers/video/backlight/omap1_bl.c | 67

+++++--------------------------------- 1 file changed, 9 insertions(+), 58 deletions(-)

(quoted diff) +0 -0

b/drivers/video/backlight/omap1_bl.c index 69a49384b3de..49f37da857e7 100644

drivers/video/backlight/omap1_bl.c +9 -58

@@ -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 = &pdev->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);
 

Signature · 2 lines

-- 
2.34.1

From: Sam Ravnborg <[email protected]>

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 <[email protected]>

Cc Lee Jones <[email protected]>

Cc Daniel Thompson <[email protected]>

Cc Jingoo Han <[email protected]>

From: Sam Ravnborg <[email protected]>

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 <[email protected]>

Cc Lee Jones <[email protected]>

Cc Daniel Thompson <[email protected]>

Cc Jingoo Han <[email protected]>

---
 drivers/video/backlight/omap1_bl.c | 67 +++++---------------------------------
 1 file changed, 9 insertions(+), 58 deletions(-)

My tools appear to dislike the line break in the Message-Id header. This isn't something I've encountered before. Is this a B4 thing?

Is this standard? Should I adapt my tooling to scan over line breaks?

Quoted 2 lines · Lee Jones

My tools appear to dislike the line break in the Message-Id header. This isn't something I've encountered before. Is this a B4 thing?

It's more like it's a Python thing. The upcoming version of b4 will avoid this (by not relying on Python to do message generation).

Quoted 1 line

Is this standard? Should I adapt my tooling to scan over line breaks?

This is RFC conformant, so if your tools are not able to deal with this situation, you should consider modifying them.

From: Stephen Kitt <[email protected]>

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 <[email protected]>

Signed-off-by Sam Ravnborg <[email protected]>

From: Sam Ravnborg <[email protected]>

With all users gone remove the deprecated fb_blank member in backlight_properties.

Signed-off-by Sam Ravnborg <[email protected]>

Cc Lee Jones <[email protected]>

Cc Daniel Thompson <[email protected]>

Cc Jingoo Han <[email protected]>

---
 drivers/video/backlight/backlight.c |  2 --
 include/linux/backlight.h           | 22 ----------------------
 2 files changed, 24 deletions(-)

(quoted diff) +0 -0

b/drivers/video/backlight/backlight.c index b788ff3d0f45..9b0557d094c5 100644 --- a/drivers/video/backlight/backlight.c
+++ b/drivers/video/backlight/backlight.c

drivers/video/backlight/backlight.c +0 -2

@@ -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);
 		}
 	}

include/linux/backlight.h +0 -21

index 614653e07e3a..c8622d6cc8c5 100644
@@ -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) {

include/linux/backlight.h +0 -1

 	return bd->props.power != FB_BLANK_UNBLANK ||
-	       bd->props.fb_blank != FB_BLANK_UNBLANK ||
 	       bd->props.state & (BL_CORE_SUSPENDED | BL_CORE_FBBLANK);
 }

Signature · 2 lines

-- 
2.34.1

From: Sam Ravnborg <[email protected]>

With all users gone remove the deprecated fb_blank member in backlight_properties.

Signed-off-by Sam Ravnborg <[email protected]>

Cc Lee Jones <[email protected]>

Cc Daniel Thompson <[email protected]>

Cc Jingoo Han <[email protected]>

Quoted 5 lines · On Sat, Jan 07, 2023 at 07:26:29PM +0100, Sam Ravnborg via B4 Submission…

From: Sam Ravnborg <[email protected]>

With all users gone remove the deprecated fb_blank member in backlight_properties.

Quoted 4 lines

Signed-off-by Sam Ravnborg <[email protected]>

Cc Lee Jones <[email protected]>

Cc Daniel Thompson <[email protected]>

Cc Jingoo Han <[email protected]>

Reviewed-by Daniel Thompson <[email protected]>

PS Please don't treat this like a maintainer Acked-by: and merge it
(Lee's not on holiday so work with Lee to figure out the merge strategy ;-) ).

Hi Daniel.

Quoted 6 lines · Daniel Thompson

Quoted 5 lines · On Sat, Jan 07, 2023 at 07:26:29PM +0100, Sam Ravnborg via B4 Submission…

From: Sam Ravnborg <[email protected]>

With all users gone remove the deprecated fb_blank member in backlight_properties.

Quoted 7 lines

Quoted 4 lines

Signed-off-by Sam Ravnborg <[email protected]>

Cc Lee Jones <[email protected]>

Cc Daniel Thompson <[email protected]>

Cc Jingoo Han <[email protected]>

Reviewed-by Daniel Thompson <[email protected]>

Thanks for the follow-up on all the backlight related patches.

Quoted 2 lines

Quoted 3 lines

PS Please don't treat this like a maintainer Acked-by: and merge it
(Lee's not on holiday so work with Lee to figure out the merge strategy ;-) ).

Nope, I am aware that the usual pattern here and wait for Lee to show up.

For this patch there is a bug as I need to update a comment. I will fix this when I resend after all the patches in flight has landed. So likely after the next merge window,

From: Sam Ravnborg <[email protected]>

With all users gone remove the deprecated fb_blank member in backlight_properties.

Signed-off-by Sam Ravnborg <[email protected]>

Cc Lee Jones <[email protected]>

Cc Daniel Thompson <[email protected]>

Cc Jingoo Han <[email protected]>

---
 drivers/video/backlight/backlight.c |  2 --
 include/linux/backlight.h           | 22 ----------------------
 2 files changed, 24 deletions(-)

Quoted 5 lines · On Sat, 07 Jan 2023, Sam Ravnborg via B4 Submission Endpoint wrote:

From: Sam Ravnborg <[email protected]>

With all users gone remove the deprecated fb_blank member in backlight_properties.

Quoted 8 lines

Signed-off-by Sam Ravnborg <[email protected]>

Cc Lee Jones <[email protected]>

Cc Daniel Thompson <[email protected]>

Cc Jingoo Han <[email protected]>

---
 drivers/video/backlight/backlight.c |  2 --
 include/linux/backlight.h           | 22 ----------------------
 2 files changed, 24 deletions(-)

Applied, thanks

Hi Lee,

Quoted 16 lines · Lee Jones

Quoted 5 lines · On Sat, 07 Jan 2023, Sam Ravnborg via B4 Submission Endpoint wrote:

From: Sam Ravnborg <[email protected]>

With all users gone remove the deprecated fb_blank member in backlight_properties.

Quoted 8 lines

Signed-off-by Sam Ravnborg <[email protected]>

Cc Lee Jones <[email protected]>

Cc Daniel Thompson <[email protected]>

Cc Jingoo Han <[email protected]>

---
 drivers/video/backlight/backlight.c |  2 --
 include/linux/backlight.h           | 22 ----------------------
 2 files changed, 24 deletions(-)

Quoted 1 line

Applied, thanks

Some of the dependent patches in this series are not yet applied. I have them queued up for processing this weekend, but I missed the -rc6 window for drm-misc so they will likely not hit upstream in the upcoming merge window.
I can try to expedite it.

But if you have not yet pushed it, please revert this patch. Then I will resend only when the remaining patches are upstream.

This series refactor backlight users to avoid use of the deprecated backlight_properties.fb_blank member.

Stephen Kitt <[email protected]> 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 <[email protected]>
To: Helge Deller <[email protected]>
To: Alexandre Belloni <[email protected]>
To: Claudiu Beznea <[email protected]>
To: Antonino Daplas <[email protected]>
To: Benjamin Herrenschmidt <[email protected]>
To: Paul Mackerras <[email protected]>
To: Greg Kroah-Hartman <[email protected]>
To: Robin van der Gracht <[email protected]>
To: Miguel Ojeda <[email protected]>
To: Lee Jones <[email protected]>
To: Daniel Thompson <[email protected]>
To: Jingoo Han <[email protected]>

Cc [email protected]

Cc [email protected]

Cc [email protected]

Cc [email protected]

Cc [email protected]

Cc [email protected]

Cc Stephen Kitt <[email protected]>

Signed-off-by Sam Ravnborg <[email protected]>