* [PATCH] Enable backlight when trigger is activated
From: Pavel Machek @ 2019-07-18 19:08 UTC (permalink / raw)
To: kernel list, linux-arm-kernel, linux-omap, tony, sre, nekit1000,
mpartap, merlijn, jacek.anaszewski, linux-leds, b.zolnierkie,
dri-devel, linux-fbdev
[-- Attachment #1: Type: text/plain, Size: 1147 bytes --]
Configuring backlight trigger from dts results in backlight off during
boot. Machine looks dead upon boot, which is not good.
Fix that by enabling LED on trigger activation.
Signed-off-by: Pavel Machek <pavel@ucw.cz>
diff --git a/drivers/leds/trigger/ledtrig-backlight.c b/drivers/leds/trigger/ledtrig-backlight.c
index 487577d..6e6bc78 100644
--- a/drivers/leds/trigger/ledtrig-backlight.c
+++ b/drivers/leds/trigger/ledtrig-backlight.c
@@ -114,6 +114,8 @@ static int bl_trig_activate(struct led_classdev *led)
n->old_status = UNBLANK;
n->notifier.notifier_call = fb_notifier_callback;
+ led_set_brightness(led, LED_ON);
+
ret = fb_register_client(&n->notifier);
if (ret)
dev_err(led->dev, "unable to register backlight trigger\n");
@@ -126,6 +128,7 @@ static void bl_trig_deactivate(struct led_classdev *led)
struct bl_trig_notifier *n = led_get_trigger_data(led);
fb_unregister_client(&n->notifier);
+ led_set_brightness(led, LED_OFF);
kfree(n);
}
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
^ permalink raw reply related
* [PATCH AUTOSEL 5.2 091/171] dt-bindings: backlight: lm3630a: correct schema validation
From: Sasha Levin @ 2019-07-19 3:55 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Brian Masney, Rob Herring, Daniel Thompson, Dan Murphy,
Rob Herring, Sasha Levin, dri-devel, linux-leds, devicetree
In-Reply-To: <20190719035643.14300-1-sashal@kernel.org>
From: Brian Masney <masneyb@onstation.org>
[ Upstream commit ef4db28c1f45cda6989bc8a8e45294894786d947 ]
The '#address-cells' and '#size-cells' properties were not defined in
the lm3630a bindings and would cause the following error when
attempting to validate the examples against the schema:
Documentation/devicetree/bindings/leds/backlight/lm3630a-backlight.example.dt.yaml:
'#address-cells', '#size-cells' do not match any of the regexes:
'^led@[01]$', 'pinctrl-[0-9]+'
Correct this by adding those two properties.
While we're here, move the ti,linear-mapping-mode property to the
led@[01] child nodes to correct the following validation error:
Documentation/devicetree/bindings/leds/backlight/lm3630a-backlight.example.dt.yaml:
led@0: 'ti,linear-mapping-mode' does not match any of the regexes:
'pinctrl-[0-9]+'
Fixes: 32fcb75c66a0 ("dt-bindings: backlight: Add lm3630a bindings")
Signed-off-by: Brian Masney <masneyb@onstation.org>
Reported-by: Rob Herring <robh+dt@kernel.org>
Acked-by: Daniel Thompson <daniel.thompson@linaro.org>
Acked-by: Dan Murphy <dmurphy@ti.com>
[robh: also drop maxItems from child reg]
Signed-off-by: Rob Herring <robh@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
.../leds/backlight/lm3630a-backlight.yaml | 21 ++++++++++++-------
1 file changed, 14 insertions(+), 7 deletions(-)
diff --git a/Documentation/devicetree/bindings/leds/backlight/lm3630a-backlight.yaml b/Documentation/devicetree/bindings/leds/backlight/lm3630a-backlight.yaml
index 4d61fe0a98a4..dc129d9a329e 100644
--- a/Documentation/devicetree/bindings/leds/backlight/lm3630a-backlight.yaml
+++ b/Documentation/devicetree/bindings/leds/backlight/lm3630a-backlight.yaml
@@ -23,16 +23,17 @@ properties:
reg:
maxItems: 1
- ti,linear-mapping-mode:
- description: |
- Enable linear mapping mode. If disabled, then it will use exponential
- mapping mode in which the ramp up/down appears to have a more uniform
- transition to the human eye.
- type: boolean
+ '#address-cells':
+ const: 1
+
+ '#size-cells':
+ const: 0
required:
- compatible
- reg
+ - '#address-cells'
+ - '#size-cells'
patternProperties:
"^led@[01]$":
@@ -48,7 +49,6 @@ patternProperties:
in this property. The two current sinks can be controlled
independently with both banks, or bank A can be configured to control
both sinks with the led-sources property.
- maxItems: 1
minimum: 0
maximum: 1
@@ -73,6 +73,13 @@ patternProperties:
minimum: 0
maximum: 255
+ ti,linear-mapping-mode:
+ description: |
+ Enable linear mapping mode. If disabled, then it will use exponential
+ mapping mode in which the ramp up/down appears to have a more uniform
+ transition to the human eye.
+ type: boolean
+
required:
- reg
--
2.20.1
^ permalink raw reply related
* [PATCH] leds: an30259a: Fix typo
From: Christophe JAILLET @ 2019-07-21 20:59 UTC (permalink / raw)
To: jacek.anaszewski, pavel, dmurphy
Cc: linux-leds, linux-kernel, kernel-janitors, Christophe JAILLET
All this file is about an30259a, including the reference to the datasheet
at the top of the file.
So change the 2 places where an32059a is used instead.
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
---
an32059a is another chip from panasonic
---
drivers/leds/leds-an30259a.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/leds/leds-an30259a.c b/drivers/leds/leds-an30259a.c
index 1c1f0c8c56f4..37e7c7998972 100644
--- a/drivers/leds/leds-an30259a.c
+++ b/drivers/leds/leds-an30259a.c
@@ -353,7 +353,7 @@ MODULE_DEVICE_TABLE(i2c, an30259a_id);
static struct i2c_driver an30259a_driver = {
.driver = {
- .name = "leds-an32059a",
+ .name = "leds-an30259a",
.of_match_table = of_match_ptr(an30259a_match_table),
},
.probe_new = an30259a_probe,
@@ -364,5 +364,5 @@ static struct i2c_driver an30259a_driver = {
module_i2c_driver(an30259a_driver);
MODULE_AUTHOR("Simon Shields <simon@lineageos.org>");
-MODULE_DESCRIPTION("AN32059A LED driver");
+MODULE_DESCRIPTION("AN30259A LED driver");
MODULE_LICENSE("GPL v2");
--
2.20.1
^ permalink raw reply related
* [PATCH] leds: ktd2692: Fix a typo in the name of a constant
From: Christophe JAILLET @ 2019-07-21 21:05 UTC (permalink / raw)
To: jacek.anaszewski, pavel, dmurphy
Cc: linux-leds, linux-kernel, kernel-janitors, Christophe JAILLET
There is a typo in KTD2962_MM_MIN_CURR_THRESHOLD_SCALE. 6 and 9 are
switched in 2962.
Define and use KTD2692_MM_MIN_CURR_THRESHOLD_SCALE instead.
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
---
drivers/leds/leds-ktd2692.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/leds/leds-ktd2692.c b/drivers/leds/leds-ktd2692.c
index 45296aaca9da..44db748c570e 100644
--- a/drivers/leds/leds-ktd2692.c
+++ b/drivers/leds/leds-ktd2692.c
@@ -22,7 +22,7 @@
/* Value related the movie mode */
#define KTD2692_MOVIE_MODE_CURRENT_LEVELS 16
#define KTD2692_MM_TO_FL_RATIO(x) ((x) / 3)
-#define KTD2962_MM_MIN_CURR_THRESHOLD_SCALE 8
+#define KTD2692_MM_MIN_CURR_THRESHOLD_SCALE 8
/* Value related the flash mode */
#define KTD2692_FLASH_MODE_TIMEOUT_LEVELS 8
@@ -253,7 +253,7 @@ static void ktd2692_setup(struct ktd2692_context *led)
ktd2692_expresswire_reset(led);
gpiod_direction_output(led->aux_gpio, KTD2692_LOW);
- ktd2692_expresswire_write(led, (KTD2962_MM_MIN_CURR_THRESHOLD_SCALE - 1)
+ ktd2692_expresswire_write(led, (KTD2692_MM_MIN_CURR_THRESHOLD_SCALE - 1)
| KTD2692_REG_MM_MIN_CURR_THRESHOLD_BASE);
ktd2692_expresswire_write(led, KTD2692_FLASH_MODE_CURR_PERCENT(45)
| KTD2692_REG_FLASH_CURRENT_BASE);
--
2.20.1
^ permalink raw reply related
* Re: [PATCH] leds: an30259a: Fix typo
From: Pavel Machek @ 2019-07-21 21:42 UTC (permalink / raw)
To: Christophe JAILLET, simon
Cc: jacek.anaszewski, dmurphy, linux-leds, linux-kernel,
kernel-janitors
In-Reply-To: <20190721205955.25317-1-christophe.jaillet@wanadoo.fr>
[-- Attachment #1: Type: text/plain, Size: 1464 bytes --]
Hi!
> All this file is about an30259a, including the reference to the datasheet
> at the top of the file.
>
> So change the 2 places where an32059a is used instead.
>
> Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
I see nothing wrong... But address listed as AUTHOR might be worth
Cc-ing? :-).
Acked-by: Pavel Machek <pavel@ucw.cz>
Pavel
> an32059a is another chip from panasonic
> ---
> drivers/leds/leds-an30259a.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/leds/leds-an30259a.c b/drivers/leds/leds-an30259a.c
> index 1c1f0c8c56f4..37e7c7998972 100644
> --- a/drivers/leds/leds-an30259a.c
> +++ b/drivers/leds/leds-an30259a.c
> @@ -353,7 +353,7 @@ MODULE_DEVICE_TABLE(i2c, an30259a_id);
>
> static struct i2c_driver an30259a_driver = {
> .driver = {
> - .name = "leds-an32059a",
> + .name = "leds-an30259a",
> .of_match_table = of_match_ptr(an30259a_match_table),
> },
> .probe_new = an30259a_probe,
> @@ -364,5 +364,5 @@ static struct i2c_driver an30259a_driver = {
> module_i2c_driver(an30259a_driver);
>
> MODULE_AUTHOR("Simon Shields <simon@lineageos.org>");
> -MODULE_DESCRIPTION("AN32059A LED driver");
> +MODULE_DESCRIPTION("AN30259A LED driver");
> MODULE_LICENSE("GPL v2");
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
^ permalink raw reply
* Re: [PATCH] leds: ktd2692: Fix a typo in the name of a constant
From: Pavel Machek @ 2019-07-21 21:43 UTC (permalink / raw)
To: Christophe JAILLET
Cc: jacek.anaszewski, dmurphy, linux-leds, linux-kernel,
kernel-janitors
In-Reply-To: <20190721210539.25669-1-christophe.jaillet@wanadoo.fr>
[-- Attachment #1: Type: text/plain, Size: 485 bytes --]
On Sun 2019-07-21 23:05:39, Christophe JAILLET wrote:
> There is a typo in KTD2962_MM_MIN_CURR_THRESHOLD_SCALE. 6 and 9 are
> switched in 2962.
>
> Define and use KTD2692_MM_MIN_CURR_THRESHOLD_SCALE instead.
>
> Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Acked-by: Pavel Machek <pavel@ucw.cz>
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
^ permalink raw reply
* Re: [PATCH] Enable backlight when trigger is activated
From: Ezequiel Garcia @ 2019-07-21 23:00 UTC (permalink / raw)
To: Pavel Machek, kernel list, linux-arm-kernel, linux-omap, tony,
sre, nekit1000, mpartap, merlijn, jacek.anaszewski, linux-leds,
b.zolnierkie, dri-devel, linux-fbdev
In-Reply-To: <20190718190849.GA11409@amd>
Hi Pavel,
The commit log is lacking the proper "leds: triggers: ".
Also...
On Thu, 2019-07-18 at 21:08 +0200, Pavel Machek wrote:
> Configuring backlight trigger from dts results in backlight off during
> boot. Machine looks dead upon boot, which is not good.
>
> Fix that by enabling LED on trigger activation.
>
> Signed-off-by: Pavel Machek <pavel@ucw.cz>
>
> diff --git a/drivers/leds/trigger/ledtrig-backlight.c b/drivers/leds/trigger/ledtrig-backlight.c
> index 487577d..6e6bc78 100644
> --- a/drivers/leds/trigger/ledtrig-backlight.c
> +++ b/drivers/leds/trigger/ledtrig-backlight.c
> @@ -114,6 +114,8 @@ static int bl_trig_activate(struct led_classdev *led)
> n->old_status = UNBLANK;
> n->notifier.notifier_call = fb_notifier_callback;
>
> + led_set_brightness(led, LED_ON);
> +
This looks fishy.
Maybe you should use a default-state = "keep" instead? (and you'll have
to support it in the LED driver).
That'll give you proper "don't touch the LED if it was turned on" behavior,
which is what you seem to want.
Regards,
Eze
^ permalink raw reply
* Re: [PATCH v4 0/4] Add a generic driver for LED-based backlight
From: Lee Jones @ 2019-07-22 7:06 UTC (permalink / raw)
To: Jacek Anaszewski
Cc: Jean-Jacques Hiblot, pavel, robh+dt, mark.rutland,
daniel.thompson, jingoohan1, dmurphy, linux-leds, linux-kernel,
dri-devel, tomi.valkeinen
In-Reply-To: <283d9044-df2d-b176-bea9-7e1520d9cf56@gmail.com>
On Thu, 18 Jul 2019, Jacek Anaszewski wrote:
> On 7/17/19 4:15 PM, Jean-Jacques Hiblot wrote:
> > This series aims to add a led-backlight driver, similar to pwm-backlight,
> > but using a LED class device underneath.
> >
> > A few years ago (2015), Tomi Valkeinen posted a series implementing a
> > backlight driver on top of a LED device:
> > https://patchwork.kernel.org/patch/7293991/
> > https://patchwork.kernel.org/patch/7294001/
> > https://patchwork.kernel.org/patch/7293981/
> >
> > The discussion stopped because Tomi lacked the time to work on it.
> >
> > changes in v4:
> > - fix dev_err() messages and commit logs following the advices of Pavel
> > - cosmetic changes (indents, getting rid of "? 1 : 0" in
> > led_match_led_node())
> >
> > changes in v3:
> > - dt binding: don't limit the brightness range to 0-255. Use the range of
> > the underlying LEDs. as a side-effect, all LEDs must now have the same
> > range
> > - driver: Adapt to dt binding update.
> > - driver: rework probe() for clarity and remove the remaining goto.
> >
> > changes in v2:
> > - handle more than one LED.
> > - don't make the backlight device a child of the LED controller.
> > - make brightness-levels and default-brightness-level optional
> > - removed the option to use a GPIO enable.
> > - removed the option to use a regulator. It should be handled by the LED
> > core
> > - don't make any change to the LED core (not needed anymore)
> >
> > Jean-Jacques Hiblot (2):
> > leds: Add managed API to get a LED from a device driver
> > dt-bindings: backlight: Add led-backlight binding
> >
> > Tomi Valkeinen (2):
> > leds: Add of_led_get() and led_put()
> > backlight: add led-backlight driver
> >
> > .../bindings/leds/backlight/led-backlight.txt | 28 ++
> > drivers/leds/led-class.c | 92 ++++++
> > drivers/video/backlight/Kconfig | 7 +
> > drivers/video/backlight/Makefile | 1 +
> > drivers/video/backlight/led_bl.c | 268 ++++++++++++++++++
> > include/linux/leds.h | 6 +
> > 6 files changed, 402 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/leds/backlight/led-backlight.txt
> > create mode 100644 drivers/video/backlight/led_bl.c
> >
>
> For the whole set:
>
> Acked-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
>
> Lee - we need to create immutable branch for this set since there will
> be some interfering changes in the LED core in this cycle.
>
> I can create the branch and send the pull request once we will
> obtain the ack from Rob for DT bindings, unless you have other
> preference.
We also require a review to be conducted by Daniel Thompson.
After which, an immutable branch sounds like a good idea. I'd like to
create this myself if you don't mind.
--
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* Re: [PATCH] Enable backlight when trigger is activated
From: Pavel Machek @ 2019-07-22 7:50 UTC (permalink / raw)
To: Ezequiel Garcia
Cc: kernel list, linux-arm-kernel, linux-omap, tony, sre, nekit1000,
mpartap, merlijn, jacek.anaszewski, linux-leds, b.zolnierkie,
dri-devel, linux-fbdev
In-Reply-To: <22d7eca4ad8aa2e73933c4f83c92221ce6e0945a.camel@collabora.com>
[-- Attachment #1: Type: text/plain, Size: 1154 bytes --]
Hi!
> > Configuring backlight trigger from dts results in backlight off during
> > boot. Machine looks dead upon boot, which is not good.
> >
> > Fix that by enabling LED on trigger activation.
> > +++ b/drivers/leds/trigger/ledtrig-backlight.c
> > @@ -114,6 +114,8 @@ static int bl_trig_activate(struct led_classdev *led)
> > n->old_status = UNBLANK;
> > n->notifier.notifier_call = fb_notifier_callback;
> >
> > + led_set_brightness(led, LED_ON);
> > +
>
> This looks fishy.
>
> Maybe you should use a default-state = "keep" instead? (and you'll have
> to support it in the LED driver).
>
> That'll give you proper "don't touch the LED if it was turned on" behavior,
> which is what you seem to want.
Actually no, that's not what I want. LED should go on if the display
is active, as soon as trigger is activated.
Unfortunately, I have see no good way to tell if the display is
active (and display is usually active when trigger is activated).
Thanks,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
^ permalink raw reply
* Re: [PATCH] leds: ktd2692: Fix a typo in the name of a constant
From: Enrico Weigelt, metux IT consult @ 2019-07-22 8:43 UTC (permalink / raw)
To: Christophe JAILLET, jacek.anaszewski, pavel, dmurphy
Cc: linux-leds, linux-kernel, kernel-janitors
In-Reply-To: <20190721210539.25669-1-christophe.jaillet@wanadoo.fr>
On 21.07.19 23:05, Christophe JAILLET wrote:
> There is a typo in KTD2962_MM_MIN_CURR_THRESHOLD_SCALE. 6 and 9 are
> switched in 2962.
>
> Define and use KTD2692_MM_MIN_CURR_THRESHOLD_SCALE instead.
>
> Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
> ---
> drivers/leds/leds-ktd2692.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/leds/leds-ktd2692.c b/drivers/leds/leds-ktd2692.c
> index 45296aaca9da..44db748c570e 100644
> --- a/drivers/leds/leds-ktd2692.c
> +++ b/drivers/leds/leds-ktd2692.c
> @@ -22,7 +22,7 @@
> /* Value related the movie mode */
> #define KTD2692_MOVIE_MODE_CURRENT_LEVELS 16
> #define KTD2692_MM_TO_FL_RATIO(x) ((x) / 3)
> -#define KTD2962_MM_MIN_CURR_THRESHOLD_SCALE 8
> +#define KTD2692_MM_MIN_CURR_THRESHOLD_SCALE 8
>
> /* Value related the flash mode */
> #define KTD2692_FLASH_MODE_TIMEOUT_LEVELS 8
> @@ -253,7 +253,7 @@ static void ktd2692_setup(struct ktd2692_context *led)
> ktd2692_expresswire_reset(led);
> gpiod_direction_output(led->aux_gpio, KTD2692_LOW);
>
> - ktd2692_expresswire_write(led, (KTD2962_MM_MIN_CURR_THRESHOLD_SCALE - 1)
> + ktd2692_expresswire_write(led, (KTD2692_MM_MIN_CURR_THRESHOLD_SCALE - 1)
> | KTD2692_REG_MM_MIN_CURR_THRESHOLD_BASE);
> ktd2692_expresswire_write(led, KTD2692_FLASH_MODE_CURR_PERCENT(45)
> | KTD2692_REG_FLASH_CURRENT_BASE);
>
Reviewed-By: Enrico Weigelt <info@metux.net>
--
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
info@metux.net -- +49-151-27565287
^ permalink raw reply
* [PATCH v2] leds: apu: fix error message on probing failure
From: Enrico Weigelt, metux IT consult @ 2019-07-22 12:08 UTC (permalink / raw)
To: linux-kernel; +Cc: jacek.anaszewski, pavel, dmurphy, linux-leds
In-Reply-To: <f54bb3f1-2699-1213-f568-b2c529488306@gmail.com>
From: Enrico Weigelt <info@metux.net>
The current error message on failed probing tends to be a bit
misleading. Fix it to tell exactly that an APU v1 was not found.
Signed-off-by: Enrico Weigelt <info@metux.net>
---
drivers/leds/leds-apu.c | 10 +++-------
1 file changed, 3 insertions(+), 7 deletions(-)
diff --git a/drivers/leds/leds-apu.c b/drivers/leds/leds-apu.c
index 451cb9f..d794f49 100644
--- a/drivers/leds/leds-apu.c
+++ b/drivers/leds/leds-apu.c
@@ -170,13 +170,9 @@ static int __init apu_led_init(void)
struct platform_device *pdev;
int err;
- if (!dmi_match(DMI_SYS_VENDOR, "PC Engines")) {
- pr_err("No PC Engines board detected\n");
- return -ENODEV;
- }
- if (!(dmi_match(DMI_PRODUCT_NAME, "APU"))) {
- pr_err("Unknown PC Engines board: %s\n",
- dmi_get_system_info(DMI_PRODUCT_NAME));
+ if (!(dmi_match(DMI_SYS_VENDOR, "PC Engines") &&
+ dmi_match(DMI_PRODUCT_NAME, "APU"))) {
+ pr_err("No PC Engines APUv1 board detected. For APUv2,3 support, enable CONFIG_PCENGINES_APU2\n");
return -ENODEV;
}
--
1.9.1
^ permalink raw reply related
* Re: [PATCH v2] leds: apu: fix error message on probing failure
From: Pavel Machek @ 2019-07-22 12:26 UTC (permalink / raw)
To: Enrico Weigelt, metux IT consult
Cc: linux-kernel, jacek.anaszewski, dmurphy, linux-leds
In-Reply-To: <1563797331-20993-1-git-send-email-info@metux.net>
[-- Attachment #1: Type: text/plain, Size: 483 bytes --]
On Mon 2019-07-22 14:08:51, Enrico Weigelt, metux IT consult wrote:
> From: Enrico Weigelt <info@metux.net>
>
> The current error message on failed probing tends to be a bit
> misleading. Fix it to tell exactly that an APU v1 was not found.
>
> Signed-off-by: Enrico Weigelt <info@metux.net>
Acked-by: Pavel Machek <pavel@ucw.cz>
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
^ permalink raw reply
* [PATCH v2 0/3] introduce LED block device activity trigger
From: Akinobu Mita @ 2019-07-22 14:59 UTC (permalink / raw)
To: linux-block, linux-leds, linux-nvme, linux-scsi
Cc: Akinobu Mita, Frank Steiner, Jacek Anaszewski, Pavel Machek,
Dan Murphy, Jens Axboe, James E.J. Bottomley, Martin K. Petersen
This work is inspired by the report on linux-nvme mailing list.
disk-activity trigger not working for nvme disk:
http://lists.infradead.org/pipermail/linux-nvme/2019-July/025253.html
This LED block device activity trigger works with any block devices.
* v2
- Remove "move declaration of led_stop_software_blink() to linux/leds.h" patch
- Move the trigger implementation to drivers/leds/trigger
- s/blk_ledtrig/ledtrig_blk/
- Add CONFIG_LEDS_TRIGGER_BLOCK
- Fix wrong bitops usages
- Add interface to stop and restart polling disk stats
- Stop polling disk stats for scsi disk during runtime suspend
Akinobu Mita (3):
block: introduce LED block device activity trigger
ledtrig-blk: add interface to stop and restart polling disk stats
scsi: sd: stop polling disk stats by ledtrig-blk during runtime
suspend
block/genhd.c | 2 +
drivers/leds/trigger/Kconfig | 7 +
drivers/leds/trigger/Makefile | 1 +
drivers/leds/trigger/ledtrig-blk.c | 258 +++++++++++++++++++++++++++++++++++++
drivers/scsi/sd.c | 40 +++---
include/linux/genhd.h | 3 +
include/linux/leds.h | 38 ++++++
7 files changed, 332 insertions(+), 17 deletions(-)
create mode 100644 drivers/leds/trigger/ledtrig-blk.c
Cc: Frank Steiner <fsteiner-mail1@bio.ifi.lmu.de>
Cc: Jacek Anaszewski <jacek.anaszewski@gmail.com>
Cc: Pavel Machek <pavel@ucw.cz>
Cc: Dan Murphy <dmurphy@ti.com>
Cc: Jens Axboe <axboe@kernel.dk>
Cc: "James E.J. Bottomley" <jejb@linux.ibm.com>
Cc: "Martin K. Petersen" <martin.petersen@oracle.com>
--
2.7.4
^ permalink raw reply
* [PATCH v2 1/3] block: introduce LED block device activity trigger
From: Akinobu Mita @ 2019-07-22 14:59 UTC (permalink / raw)
To: linux-block, linux-leds, linux-nvme, linux-scsi
Cc: Akinobu Mita, Frank Steiner, Jacek Anaszewski, Pavel Machek,
Dan Murphy, Jens Axboe, James E.J. Bottomley, Martin K. Petersen
In-Reply-To: <1563807552-23498-1-git-send-email-akinobu.mita@gmail.com>
This allows LEDs to be controlled by block device activity.
We already have ledtrig-disk (LED disk activity trigger), but the lower
level disk drivers need to utilize ledtrig_disk_activity() to make the
LED blink.
The LED block device trigger doesn't require the lower level drivers to
have any instrumentation. The activity is collected by polling the disk
stats.
Example:
echo block-nvme0n1 > /sys/class/leds/diy/trigger
Cc: Frank Steiner <fsteiner-mail1@bio.ifi.lmu.de>
Cc: Jacek Anaszewski <jacek.anaszewski@gmail.com>
Cc: Pavel Machek <pavel@ucw.cz>
Cc: Dan Murphy <dmurphy@ti.com>
Cc: Jens Axboe <axboe@kernel.dk>
Cc: "James E.J. Bottomley" <jejb@linux.ibm.com>
Cc: "Martin K. Petersen" <martin.petersen@oracle.com>
Signed-off-by: Akinobu Mita <akinobu.mita@gmail.com>
---
block/genhd.c | 2 +
drivers/leds/trigger/Kconfig | 7 ++
drivers/leds/trigger/Makefile | 1 +
drivers/leds/trigger/ledtrig-blk.c | 225 +++++++++++++++++++++++++++++++++++++
include/linux/genhd.h | 3 +
include/linux/leds.h | 27 +++++
6 files changed, 265 insertions(+)
create mode 100644 drivers/leds/trigger/ledtrig-blk.c
diff --git a/block/genhd.c b/block/genhd.c
index 54f1f0d3..1c68861 100644
--- a/block/genhd.c
+++ b/block/genhd.c
@@ -745,6 +745,7 @@ static void __device_add_disk(struct device *parent, struct gendisk *disk,
disk_add_events(disk);
blk_integrity_add(disk);
+ ledtrig_blk_register(disk);
}
void device_add_disk(struct device *parent, struct gendisk *disk,
@@ -766,6 +767,7 @@ void del_gendisk(struct gendisk *disk)
struct disk_part_iter piter;
struct hd_struct *part;
+ ledtrig_blk_unregister(disk);
blk_integrity_del(disk);
disk_del_events(disk);
diff --git a/drivers/leds/trigger/Kconfig b/drivers/leds/trigger/Kconfig
index ce9429c..74ce25d 100644
--- a/drivers/leds/trigger/Kconfig
+++ b/drivers/leds/trigger/Kconfig
@@ -144,4 +144,11 @@ config LEDS_TRIGGER_AUDIO
the audio mute and mic-mute changes.
If unsure, say N
+config LEDS_TRIGGER_BLOCK
+ bool "LED Block device Trigger"
+ depends on BLOCK
+ help
+ This allows LEDs to be controlled by block device activity.
+ If unsure, say Y.
+
endif # LEDS_TRIGGERS
diff --git a/drivers/leds/trigger/Makefile b/drivers/leds/trigger/Makefile
index 733a83e..60200eb 100644
--- a/drivers/leds/trigger/Makefile
+++ b/drivers/leds/trigger/Makefile
@@ -15,3 +15,4 @@ obj-$(CONFIG_LEDS_TRIGGER_PANIC) += ledtrig-panic.o
obj-$(CONFIG_LEDS_TRIGGER_NETDEV) += ledtrig-netdev.o
obj-$(CONFIG_LEDS_TRIGGER_PATTERN) += ledtrig-pattern.o
obj-$(CONFIG_LEDS_TRIGGER_AUDIO) += ledtrig-audio.o
+obj-$(CONFIG_LEDS_TRIGGER_BLOCK) += ledtrig-blk.o
diff --git a/drivers/leds/trigger/ledtrig-blk.c b/drivers/leds/trigger/ledtrig-blk.c
new file mode 100644
index 0000000..d5808c9
--- /dev/null
+++ b/drivers/leds/trigger/ledtrig-blk.c
@@ -0,0 +1,225 @@
+// SPDX-License-Identifier: GPL-2.0
+// LED Kernel Blockdev Trigger
+// Derived from ledtrig-netdev.c
+
+#include <linux/atomic.h>
+#include <linux/genhd.h>
+#include <linux/leds.h>
+#include <linux/workqueue.h>
+#include "../leds.h"
+
+enum ledtrig_blk_attr {
+ LEDTRIG_BLK_READ,
+ LEDTRIG_BLK_WRITE,
+ LEDTRIG_BLK_DISCARD
+};
+
+struct ledtrig_blk_data {
+ struct delayed_work work;
+ struct led_classdev *led_cdev;
+
+ atomic_t interval;
+ u64 last_activity;
+
+ unsigned long mode;
+};
+
+static ssize_t ledtrig_blk_attr_show(struct device *dev, char *buf,
+ enum ledtrig_blk_attr attr)
+{
+ struct ledtrig_blk_data *trig_data = led_trigger_get_drvdata(dev);
+
+ return sprintf(buf, "%u\n", test_bit(attr, &trig_data->mode));
+}
+
+static ssize_t ledtrig_blk_attr_store(struct device *dev, const char *buf,
+ size_t size, enum ledtrig_blk_attr attr)
+{
+ struct ledtrig_blk_data *trig_data = led_trigger_get_drvdata(dev);
+ unsigned long state;
+ int ret;
+
+ ret = kstrtoul(buf, 0, &state);
+ if (ret)
+ return ret;
+
+ if (state)
+ set_bit(attr, &trig_data->mode);
+ else
+ clear_bit(attr, &trig_data->mode);
+
+ return size;
+}
+
+static ssize_t read_show(struct device *dev, struct device_attribute *attr,
+ char *buf)
+{
+ return ledtrig_blk_attr_show(dev, buf, LEDTRIG_BLK_READ);
+}
+static ssize_t read_store(struct device *dev, struct device_attribute *attr,
+ const char *buf, size_t size)
+{
+ return ledtrig_blk_attr_store(dev, buf, size, LEDTRIG_BLK_READ);
+}
+static DEVICE_ATTR_RW(read);
+
+static ssize_t write_show(struct device *dev, struct device_attribute *attr,
+ char *buf)
+{
+ return ledtrig_blk_attr_show(dev, buf, LEDTRIG_BLK_WRITE);
+}
+static ssize_t write_store(struct device *dev, struct device_attribute *attr,
+ const char *buf, size_t size)
+{
+ return ledtrig_blk_attr_store(dev, buf, size, LEDTRIG_BLK_WRITE);
+}
+static DEVICE_ATTR_RW(write);
+
+static ssize_t discard_show(struct device *dev, struct device_attribute *attr,
+ char *buf)
+{
+ return ledtrig_blk_attr_show(dev, buf, LEDTRIG_BLK_DISCARD);
+}
+static ssize_t discard_store(struct device *dev, struct device_attribute *attr,
+ const char *buf, size_t size)
+{
+ return ledtrig_blk_attr_store(dev, buf, size, LEDTRIG_BLK_DISCARD);
+}
+static DEVICE_ATTR_RW(discard);
+
+static ssize_t interval_show(struct device *dev, struct device_attribute *attr,
+ char *buf)
+{
+ struct ledtrig_blk_data *trig_data = led_trigger_get_drvdata(dev);
+
+ return sprintf(buf, "%u\n",
+ jiffies_to_msecs(atomic_read(&trig_data->interval)));
+}
+static ssize_t interval_store(struct device *dev, struct device_attribute *attr,
+ const char *buf, size_t size)
+{
+ struct ledtrig_blk_data *trig_data = led_trigger_get_drvdata(dev);
+ unsigned long value;
+ int ret;
+
+ ret = kstrtoul(buf, 0, &value);
+ if (ret)
+ return ret;
+
+ /* impose some basic bounds on the timer interval */
+ if (value >= 5 && value <= 10000) {
+ cancel_delayed_work_sync(&trig_data->work);
+ atomic_set(&trig_data->interval, msecs_to_jiffies(value));
+ schedule_delayed_work(&trig_data->work,
+ atomic_read(&trig_data->interval) * 2);
+ }
+
+ return size;
+}
+static DEVICE_ATTR_RW(interval);
+
+static struct attribute *ledtrig_blk_attrs[] = {
+ &dev_attr_read.attr,
+ &dev_attr_write.attr,
+ &dev_attr_discard.attr,
+ &dev_attr_interval.attr,
+ NULL
+};
+ATTRIBUTE_GROUPS(ledtrig_blk);
+
+static void ledtrig_blk_work(struct work_struct *work)
+{
+ struct ledtrig_blk_data *trig_data =
+ container_of(work, struct ledtrig_blk_data, work.work);
+ struct gendisk *disk = container_of(trig_data->led_cdev->trigger,
+ struct gendisk, led.trig);
+ u64 activity = 0;
+
+ if (test_bit(LEDTRIG_BLK_READ, &trig_data->mode))
+ activity += part_stat_read(&disk->part0, ios[STAT_READ]);
+ if (test_bit(LEDTRIG_BLK_WRITE, &trig_data->mode))
+ activity += part_stat_read(&disk->part0, ios[STAT_WRITE]);
+ if (test_bit(LEDTRIG_BLK_DISCARD, &trig_data->mode))
+ activity += part_stat_read(&disk->part0, ios[STAT_DISCARD]);
+
+ if (trig_data->last_activity != activity) {
+ unsigned long interval;
+
+ led_stop_software_blink(trig_data->led_cdev);
+ interval = jiffies_to_msecs(atomic_read(&trig_data->interval));
+ led_blink_set_oneshot(trig_data->led_cdev, &interval, &interval,
+ 0);
+
+ trig_data->last_activity = activity;
+ }
+
+ schedule_delayed_work(&trig_data->work,
+ atomic_read(&trig_data->interval) * 2);
+}
+
+static int ledtrig_blk_activate(struct led_classdev *led_cdev)
+{
+ struct ledtrig_blk_data *trig_data;
+
+ trig_data = kzalloc(sizeof(*trig_data), GFP_KERNEL);
+ if (!trig_data)
+ return -ENOMEM;
+
+ trig_data->mode = BIT(LEDTRIG_BLK_READ) | BIT(LEDTRIG_BLK_WRITE) |
+ BIT(LEDTRIG_BLK_DISCARD);
+
+ atomic_set(&trig_data->interval, msecs_to_jiffies(50));
+ trig_data->last_activity = 0;
+ trig_data->led_cdev = led_cdev;
+
+ INIT_DELAYED_WORK(&trig_data->work, ledtrig_blk_work);
+
+ led_set_trigger_data(led_cdev, trig_data);
+
+ schedule_delayed_work(&trig_data->work,
+ atomic_read(&trig_data->interval) * 2);
+
+ return 0;
+}
+
+static void ledtrig_blk_deactivate(struct led_classdev *led_cdev)
+{
+ struct ledtrig_blk_data *trig_data = led_get_trigger_data(led_cdev);
+
+ cancel_delayed_work_sync(&trig_data->work);
+ kfree(trig_data);
+}
+
+int ledtrig_blk_register(struct gendisk *disk)
+{
+ int ret;
+
+ disk->led.trig.name = kasprintf(GFP_KERNEL, "block-%s",
+ disk->disk_name);
+ if (!disk->led.trig.name)
+ return -ENOMEM;
+
+ disk->led.trig.activate = ledtrig_blk_activate;
+ disk->led.trig.deactivate = ledtrig_blk_deactivate;
+ disk->led.trig.groups = ledtrig_blk_groups;
+
+ ret = led_trigger_register(&disk->led.trig);
+ if (ret) {
+ kfree(disk->led.trig.name);
+ disk->led.trig.name = NULL;
+ }
+
+ return ret;
+}
+EXPORT_SYMBOL_GPL(ledtrig_blk_register);
+
+void ledtrig_blk_unregister(struct gendisk *disk)
+{
+ if (!disk->led.trig.name)
+ return;
+
+ led_trigger_unregister(&disk->led.trig);
+ kfree(disk->led.trig.name);
+ disk->led.trig.name = NULL;
+}
+EXPORT_SYMBOL_GPL(ledtrig_blk_unregister);
diff --git a/include/linux/genhd.h b/include/linux/genhd.h
index 8b5330d..b2c934e 100644
--- a/include/linux/genhd.h
+++ b/include/linux/genhd.h
@@ -17,6 +17,7 @@
#include <linux/percpu-refcount.h>
#include <linux/uuid.h>
#include <linux/blk_types.h>
+#include <linux/leds.h>
#include <asm/local.h>
#ifdef CONFIG_BLOCK
@@ -219,6 +220,8 @@ struct gendisk {
int node_id;
struct badblocks *bb;
struct lockdep_map lockdep_map;
+
+ struct ledtrig_blk led;
};
static inline struct gendisk *part_to_disk(struct hd_struct *part)
diff --git a/include/linux/leds.h b/include/linux/leds.h
index 9b2bf57..395fa61 100644
--- a/include/linux/leds.h
+++ b/include/linux/leds.h
@@ -517,4 +517,31 @@ static inline void ledtrig_audio_set(enum led_audio type,
}
#endif
+struct gendisk;
+
+#ifdef CONFIG_LEDS_TRIGGER_BLOCK
+
+struct ledtrig_blk {
+ struct led_trigger trig;
+};
+
+int ledtrig_blk_register(struct gendisk *disk);
+void ledtrig_blk_unregister(struct gendisk *disk);
+
+#else
+
+struct ledtrig_blk {
+};
+
+static inline int ledtrig_blk_register(struct gendisk *disk)
+{
+ return 0;
+}
+
+static inline void ledtrig_blk_unregister(struct gendisk *disk)
+{
+}
+
+#endif /* CONFIG_LEDS_TRIGGER_BLOCK */
+
#endif /* __LINUX_LEDS_H_INCLUDED */
--
2.7.4
^ permalink raw reply related
* [PATCH v2 2/3] ledtrig-blk: add interface to stop and restart polling disk stats
From: Akinobu Mita @ 2019-07-22 14:59 UTC (permalink / raw)
To: linux-block, linux-leds, linux-nvme, linux-scsi
Cc: Akinobu Mita, Frank Steiner, Jacek Anaszewski, Pavel Machek,
Dan Murphy, Jens Axboe, James E.J. Bottomley, Martin K. Petersen
In-Reply-To: <1563807552-23498-1-git-send-email-akinobu.mita@gmail.com>
The LED block device activity trigger periodically polls the disk stats
to collect the activity. However, it is pointless to poll while the
block device is in quiescent state.
This provides an optional interface to stop and restart polling disk stats
for the lower-level block drivers.
Cc: Frank Steiner <fsteiner-mail1@bio.ifi.lmu.de>
Cc: Jacek Anaszewski <jacek.anaszewski@gmail.com>
Cc: Pavel Machek <pavel@ucw.cz>
Cc: Dan Murphy <dmurphy@ti.com>
Cc: Jens Axboe <axboe@kernel.dk>
Cc: "James E.J. Bottomley" <jejb@linux.ibm.com>
Cc: "Martin K. Petersen" <martin.petersen@oracle.com>
Signed-off-by: Akinobu Mita <akinobu.mita@gmail.com>
---
drivers/leds/trigger/ledtrig-blk.c | 37 +++++++++++++++++++++++++++++++++++--
include/linux/leds.h | 11 +++++++++++
2 files changed, 46 insertions(+), 2 deletions(-)
diff --git a/drivers/leds/trigger/ledtrig-blk.c b/drivers/leds/trigger/ledtrig-blk.c
index d5808c9..6b826ed 100644
--- a/drivers/leds/trigger/ledtrig-blk.c
+++ b/drivers/leds/trigger/ledtrig-blk.c
@@ -153,8 +153,9 @@ static void ledtrig_blk_work(struct work_struct *work)
trig_data->last_activity = activity;
}
- schedule_delayed_work(&trig_data->work,
- atomic_read(&trig_data->interval) * 2);
+ if (atomic_read(&disk->led.enable_count))
+ schedule_delayed_work(&trig_data->work,
+ atomic_read(&trig_data->interval) * 2);
}
static int ledtrig_blk_activate(struct led_classdev *led_cdev)
@@ -190,6 +191,36 @@ static void ledtrig_blk_deactivate(struct led_classdev *led_cdev)
kfree(trig_data);
}
+void ledtrig_blk_disable(struct gendisk *disk)
+{
+ if (disk)
+ atomic_dec(&disk->led.enable_count);
+}
+EXPORT_SYMBOL_GPL(ledtrig_blk_disable);
+
+void ledtrig_blk_enable(struct gendisk *disk)
+{
+ struct led_classdev *led_cdev;
+
+ if (!disk)
+ return;
+
+ atomic_inc(&disk->led.enable_count);
+
+ read_lock(&disk->led.trig.leddev_list_lock);
+
+ list_for_each_entry(led_cdev, &disk->led.trig.led_cdevs, trig_list) {
+ struct ledtrig_blk_data *trig_data =
+ led_get_trigger_data(led_cdev);
+
+ schedule_delayed_work(&trig_data->work,
+ atomic_read(&trig_data->interval) * 2);
+ }
+
+ read_unlock(&disk->led.trig.leddev_list_lock);
+}
+EXPORT_SYMBOL_GPL(ledtrig_blk_enable);
+
int ledtrig_blk_register(struct gendisk *disk)
{
int ret;
@@ -203,6 +234,8 @@ int ledtrig_blk_register(struct gendisk *disk)
disk->led.trig.deactivate = ledtrig_blk_deactivate;
disk->led.trig.groups = ledtrig_blk_groups;
+ atomic_set(&disk->led.enable_count, 1);
+
ret = led_trigger_register(&disk->led.trig);
if (ret) {
kfree(disk->led.trig.name);
diff --git a/include/linux/leds.h b/include/linux/leds.h
index 395fa61..fd2eb7c 100644
--- a/include/linux/leds.h
+++ b/include/linux/leds.h
@@ -523,8 +523,11 @@ struct gendisk;
struct ledtrig_blk {
struct led_trigger trig;
+ atomic_t enable_count;
};
+void ledtrig_blk_enable(struct gendisk *disk);
+void ledtrig_blk_disable(struct gendisk *disk);
int ledtrig_blk_register(struct gendisk *disk);
void ledtrig_blk_unregister(struct gendisk *disk);
@@ -533,6 +536,14 @@ void ledtrig_blk_unregister(struct gendisk *disk);
struct ledtrig_blk {
};
+static inline void ledtrig_blk_enable(struct gendisk *disk)
+{
+}
+
+static inline void ledtrig_blk_disable(struct gendisk *disk)
+{
+}
+
static inline int ledtrig_blk_register(struct gendisk *disk)
{
return 0;
--
2.7.4
^ permalink raw reply related
* [PATCH v2 3/3] scsi: sd: stop polling disk stats by ledtrig-blk during runtime suspend
From: Akinobu Mita @ 2019-07-22 14:59 UTC (permalink / raw)
To: linux-block, linux-leds, linux-nvme, linux-scsi
Cc: Akinobu Mita, Frank Steiner, Jacek Anaszewski, Pavel Machek,
Dan Murphy, Jens Axboe, James E.J. Bottomley, Martin K. Petersen
In-Reply-To: <1563807552-23498-1-git-send-email-akinobu.mita@gmail.com>
The LED block device activity trigger periodically polls the disk stats
to collect the activity. However, it is pointless to poll while the
scsi device is in runtime suspend.
This stops polling disk stats when the device is successfully runtime
suspended, and restarts polling when the device is successfully runtime
resumed.
Cc: Frank Steiner <fsteiner-mail1@bio.ifi.lmu.de>
Cc: Jacek Anaszewski <jacek.anaszewski@gmail.com>
Cc: Pavel Machek <pavel@ucw.cz>
Cc: Dan Murphy <dmurphy@ti.com>
Cc: Jens Axboe <axboe@kernel.dk>
Cc: "James E.J. Bottomley" <jejb@linux.ibm.com>
Cc: "Martin K. Petersen" <martin.petersen@oracle.com>
Signed-off-by: Akinobu Mita <akinobu.mita@gmail.com>
---
drivers/scsi/sd.c | 40 +++++++++++++++++++++++-----------------
1 file changed, 23 insertions(+), 17 deletions(-)
diff --git a/drivers/scsi/sd.c b/drivers/scsi/sd.c
index 149d406..5f73142 100644
--- a/drivers/scsi/sd.c
+++ b/drivers/scsi/sd.c
@@ -3538,7 +3538,7 @@ static int sd_suspend_common(struct device *dev, bool ignore_stop_errors)
{
struct scsi_disk *sdkp = dev_get_drvdata(dev);
struct scsi_sense_hdr sshdr;
- int ret = 0;
+ int ret;
if (!sdkp) /* E.g.: runtime suspend following sd_remove() */
return 0;
@@ -3550,18 +3550,16 @@ static int sd_suspend_common(struct device *dev, bool ignore_stop_errors)
if (ret) {
/* ignore OFFLINE device */
if (ret == -ENODEV)
- return 0;
-
- if (!scsi_sense_valid(&sshdr) ||
- sshdr.sense_key != ILLEGAL_REQUEST)
- return ret;
+ goto success;
/*
* sshdr.sense_key == ILLEGAL_REQUEST means this drive
* doesn't support sync. There's not much to do and
* suspend shouldn't fail.
*/
- ret = 0;
+ if (!scsi_sense_valid(&sshdr) ||
+ sshdr.sense_key != ILLEGAL_REQUEST)
+ return ret;
}
}
@@ -3569,11 +3567,14 @@ static int sd_suspend_common(struct device *dev, bool ignore_stop_errors)
sd_printk(KERN_NOTICE, sdkp, "Stopping disk\n");
/* an error is not worth aborting a system sleep */
ret = sd_start_stop_device(sdkp, 0);
- if (ignore_stop_errors)
- ret = 0;
+ if (ret && !ignore_stop_errors)
+ return ret;
}
- return ret;
+success:
+ ledtrig_blk_disable(sdkp->disk);
+
+ return 0;
}
static int sd_suspend_system(struct device *dev)
@@ -3589,19 +3590,24 @@ static int sd_suspend_runtime(struct device *dev)
static int sd_resume(struct device *dev)
{
struct scsi_disk *sdkp = dev_get_drvdata(dev);
- int ret;
if (!sdkp) /* E.g.: runtime resume at the start of sd_probe() */
return 0;
- if (!sdkp->device->manage_start_stop)
- return 0;
+ if (sdkp->device->manage_start_stop) {
+ int ret;
+
+ sd_printk(KERN_NOTICE, sdkp, "Starting disk\n");
+ ret = sd_start_stop_device(sdkp, 1);
+ if (ret)
+ return ret;
- sd_printk(KERN_NOTICE, sdkp, "Starting disk\n");
- ret = sd_start_stop_device(sdkp, 1);
- if (!ret)
opal_unlock_from_suspend(sdkp->opal_dev);
- return ret;
+ }
+
+ ledtrig_blk_enable(sdkp->disk);
+
+ return 0;
}
/**
--
2.7.4
^ permalink raw reply related
* [PATCH] leds: is31fl319x: simplify getting the adapter of a client
From: Wolfram Sang @ 2019-07-22 18:14 UTC (permalink / raw)
To: linux-i2c
Cc: Wolfram Sang, Jacek Anaszewski, Pavel Machek, Dan Murphy,
linux-leds, linux-kernel
We have a dedicated pointer for that, so use it. Much easier to read and
less computation involved.
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
---
drivers/leds/leds-is31fl319x.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/leds/leds-is31fl319x.c b/drivers/leds/leds-is31fl319x.c
index 2d077b8edd0e..ca6634b8683c 100644
--- a/drivers/leds/leds-is31fl319x.c
+++ b/drivers/leds/leds-is31fl319x.c
@@ -333,12 +333,11 @@ static int is31fl319x_probe(struct i2c_client *client,
{
struct is31fl319x_chip *is31;
struct device *dev = &client->dev;
- struct i2c_adapter *adapter = to_i2c_adapter(dev->parent);
int err;
int i = 0;
u32 aggregated_led_microamp = IS31FL319X_CURRENT_MAX;
- if (!i2c_check_functionality(adapter, I2C_FUNC_I2C))
+ if (!i2c_check_functionality(client->adapter, I2C_FUNC_I2C))
return -EIO;
is31 = devm_kzalloc(&client->dev, sizeof(*is31), GFP_KERNEL);
--
2.20.1
^ permalink raw reply related
* Re: leds: apu: drop obsolete support for apu>=2
From: Jacek Anaszewski @ 2019-07-22 20:12 UTC (permalink / raw)
To: Enrico Weigelt, metux IT consult, linux-kernel; +Cc: pavel, dmurphy, linux-leds
In-Reply-To: <1563202653-20994-1-git-send-email-info@metux.net>
Hi Enrico,
Thank you for the patch set.
On 7/15/19 4:57 PM, Enrico Weigelt, metux IT consult wrote:
> Hi folks,
>
>
> the legacy apu LEDs driver has been superseded by the more complete
> pcengines-apu2 platform driver, for APU >= 2. It only supports
> the three front LEDs, but lacks all the other GPIOs (eg. button
> or simsw), and conflicts with the pcengines-apu2 driver.
>
> Old APUv1 has a very different chipset.
>
> Therefore I propose dropping the apu>=2 support from the legacy
> driver, reducing it to only the old (obsolete) APUv1 boards.
Patch set applied along with the update for the patch 5/6.
--
Best regards,
Jacek Anaszewski
^ permalink raw reply
* Re: [PATCH] leds: an30259a: Fix typo
From: Jacek Anaszewski @ 2019-07-22 20:13 UTC (permalink / raw)
To: Christophe JAILLET, pavel, dmurphy
Cc: linux-leds, linux-kernel, kernel-janitors
In-Reply-To: <20190721205955.25317-1-christophe.jaillet@wanadoo.fr>
Hi Christophe,
Thank you for the patch.
On 7/21/19 10:59 PM, Christophe JAILLET wrote:
> All this file is about an30259a, including the reference to the datasheet
> at the top of the file.
>
> So change the 2 places where an32059a is used instead.
>
> Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
> ---
> an32059a is another chip from panasonic
> ---
> drivers/leds/leds-an30259a.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/leds/leds-an30259a.c b/drivers/leds/leds-an30259a.c
> index 1c1f0c8c56f4..37e7c7998972 100644
> --- a/drivers/leds/leds-an30259a.c
> +++ b/drivers/leds/leds-an30259a.c
> @@ -353,7 +353,7 @@ MODULE_DEVICE_TABLE(i2c, an30259a_id);
>
> static struct i2c_driver an30259a_driver = {
> .driver = {
> - .name = "leds-an32059a",
> + .name = "leds-an30259a",
> .of_match_table = of_match_ptr(an30259a_match_table),
> },
> .probe_new = an30259a_probe,
> @@ -364,5 +364,5 @@ static struct i2c_driver an30259a_driver = {
> module_i2c_driver(an30259a_driver);
>
> MODULE_AUTHOR("Simon Shields <simon@lineageos.org>");
> -MODULE_DESCRIPTION("AN32059A LED driver");
> +MODULE_DESCRIPTION("AN30259A LED driver");
> MODULE_LICENSE("GPL v2");
>
Applied.
--
Best regards,
Jacek Anaszewski
^ permalink raw reply
* Re: [PATCH] leds: ktd2692: Fix a typo in the name of a constant
From: Jacek Anaszewski @ 2019-07-22 20:13 UTC (permalink / raw)
To: Christophe JAILLET, pavel, dmurphy
Cc: linux-leds, linux-kernel, kernel-janitors
In-Reply-To: <20190721210539.25669-1-christophe.jaillet@wanadoo.fr>
Hi Christophe,
Thank you for the patch.
On 7/21/19 11:05 PM, Christophe JAILLET wrote:
> There is a typo in KTD2962_MM_MIN_CURR_THRESHOLD_SCALE. 6 and 9 are
> switched in 2962.
>
> Define and use KTD2692_MM_MIN_CURR_THRESHOLD_SCALE instead.
>
> Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
> ---
> drivers/leds/leds-ktd2692.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/leds/leds-ktd2692.c b/drivers/leds/leds-ktd2692.c
> index 45296aaca9da..44db748c570e 100644
> --- a/drivers/leds/leds-ktd2692.c
> +++ b/drivers/leds/leds-ktd2692.c
> @@ -22,7 +22,7 @@
> /* Value related the movie mode */
> #define KTD2692_MOVIE_MODE_CURRENT_LEVELS 16
> #define KTD2692_MM_TO_FL_RATIO(x) ((x) / 3)
> -#define KTD2962_MM_MIN_CURR_THRESHOLD_SCALE 8
> +#define KTD2692_MM_MIN_CURR_THRESHOLD_SCALE 8
>
> /* Value related the flash mode */
> #define KTD2692_FLASH_MODE_TIMEOUT_LEVELS 8
> @@ -253,7 +253,7 @@ static void ktd2692_setup(struct ktd2692_context *led)
> ktd2692_expresswire_reset(led);
> gpiod_direction_output(led->aux_gpio, KTD2692_LOW);
>
> - ktd2692_expresswire_write(led, (KTD2962_MM_MIN_CURR_THRESHOLD_SCALE - 1)
> + ktd2692_expresswire_write(led, (KTD2692_MM_MIN_CURR_THRESHOLD_SCALE - 1)
> | KTD2692_REG_MM_MIN_CURR_THRESHOLD_BASE);
> ktd2692_expresswire_write(led, KTD2692_FLASH_MODE_CURR_PERCENT(45)
> | KTD2692_REG_FLASH_CURRENT_BASE);
>
Applied.
--
Best regards,
Jacek Anaszewski
^ permalink raw reply
* Re: [PATCH] Enable backlight when trigger is activated
From: Jacek Anaszewski @ 2019-07-22 20:25 UTC (permalink / raw)
To: Pavel Machek, Ezequiel Garcia
Cc: kernel list, linux-arm-kernel, linux-omap, tony, sre, nekit1000,
mpartap, merlijn, linux-leds, b.zolnierkie, dri-devel,
linux-fbdev
In-Reply-To: <20190722075032.GA27524@amd>
Hi Pavel,
On 7/22/19 9:50 AM, Pavel Machek wrote:
> Hi!
>
>>> Configuring backlight trigger from dts results in backlight off during
>>> boot. Machine looks dead upon boot, which is not good.
>>>
>>> Fix that by enabling LED on trigger activation.
>
>>> +++ b/drivers/leds/trigger/ledtrig-backlight.c
>>> @@ -114,6 +114,8 @@ static int bl_trig_activate(struct led_classdev *led)
>>> n->old_status = UNBLANK;
>>> n->notifier.notifier_call = fb_notifier_callback;
>>>
>>> + led_set_brightness(led, LED_ON);
>>> +
>>
>> This looks fishy.
>>
>> Maybe you should use a default-state = "keep" instead? (and you'll have
>> to support it in the LED driver).
>>
>> That'll give you proper "don't touch the LED if it was turned on" behavior,
>> which is what you seem to want.
>
> Actually no, that's not what I want. LED should go on if the display
> is active, as soon as trigger is activated.
>
> Unfortunately, I have see no good way to tell if the display is
> active (and display is usually active when trigger is activated).
default-state DT property can be also set to "on"
(see Documentation/devicetree/bindings/leds/common.txt).
You could make use of LED_INIT_DEFAULT_TRIGGER flag and
parse DT property in the activate op. Similar approach has been
applied e.g. in ledtrig-pattern.c.
--
Best regards,
Jacek Anaszewski
^ permalink raw reply
* Backlight in motorola Droid 4
From: Pavel Machek @ 2019-07-22 20:59 UTC (permalink / raw)
To: Dan Murphy, linux-omap, tony, sre, nekit1000, mpartap, merlijn
Cc: jacek.anaszewski, linux-kernel, linux-leds
In-Reply-To: <20181219162626.12297-1-dmurphy@ti.com>
[-- Attachment #1: Type: text/plain, Size: 427 bytes --]
Hi!
So now the backlight LED can be controlled. Good. (And thanks!)
But I seem to remember that backlight had range from "is it really on?"
to "very bright"; now it seems to have range from "bright" to "very
bright".
Any ideas what goes on there?
Thanks,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
^ permalink raw reply
* Re: [PATCH] Enable backlight when trigger is activated
From: Pavel Machek @ 2019-07-22 21:04 UTC (permalink / raw)
To: Jacek Anaszewski
Cc: Ezequiel Garcia, kernel list, linux-arm-kernel, linux-omap, tony,
sre, nekit1000, mpartap, merlijn, linux-leds, b.zolnierkie,
dri-devel, linux-fbdev
In-Reply-To: <6fc6af89-1455-7665-47e7-0568ecd87c9c@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1074 bytes --]
Hi!
> >> This looks fishy.
> >>
> >> Maybe you should use a default-state = "keep" instead? (and you'll have
> >> to support it in the LED driver).
> >>
> >> That'll give you proper "don't touch the LED if it was turned on" behavior,
> >> which is what you seem to want.
> >
> > Actually no, that's not what I want. LED should go on if the display
> > is active, as soon as trigger is activated.
> >
> > Unfortunately, I have see no good way to tell if the display is
> > active (and display is usually active when trigger is activated).
>
> default-state DT property can be also set to "on"
> (see Documentation/devicetree/bindings/leds/common.txt).
Ok, thanks for the hint, that could work. (I thought we were using
default trigger to set the LED "on").
Now...this gives me option of 0% or 100% brightness, while best would
be 10% brightness.... but I guess we can live with that ;-).
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
^ permalink raw reply
* Re: [PATCH v4 0/4] Add a generic driver for LED-based backlight
From: Jacek Anaszewski @ 2019-07-22 21:23 UTC (permalink / raw)
To: Lee Jones
Cc: Jean-Jacques Hiblot, pavel, robh+dt, mark.rutland,
daniel.thompson, jingoohan1, dmurphy, linux-leds, linux-kernel,
dri-devel, tomi.valkeinen
In-Reply-To: <20190722070620.GD8402@dell>
On 7/22/19 9:06 AM, Lee Jones wrote:
> On Thu, 18 Jul 2019, Jacek Anaszewski wrote:
>
>> On 7/17/19 4:15 PM, Jean-Jacques Hiblot wrote:
>>> This series aims to add a led-backlight driver, similar to pwm-backlight,
>>> but using a LED class device underneath.
>>>
>>> A few years ago (2015), Tomi Valkeinen posted a series implementing a
>>> backlight driver on top of a LED device:
>>> https://patchwork.kernel.org/patch/7293991/
>>> https://patchwork.kernel.org/patch/7294001/
>>> https://patchwork.kernel.org/patch/7293981/
>>>
>>> The discussion stopped because Tomi lacked the time to work on it.
>>>
>>> changes in v4:
>>> - fix dev_err() messages and commit logs following the advices of Pavel
>>> - cosmetic changes (indents, getting rid of "? 1 : 0" in
>>> led_match_led_node())
>>>
>>> changes in v3:
>>> - dt binding: don't limit the brightness range to 0-255. Use the range of
>>> the underlying LEDs. as a side-effect, all LEDs must now have the same
>>> range
>>> - driver: Adapt to dt binding update.
>>> - driver: rework probe() for clarity and remove the remaining goto.
>>>
>>> changes in v2:
>>> - handle more than one LED.
>>> - don't make the backlight device a child of the LED controller.
>>> - make brightness-levels and default-brightness-level optional
>>> - removed the option to use a GPIO enable.
>>> - removed the option to use a regulator. It should be handled by the LED
>>> core
>>> - don't make any change to the LED core (not needed anymore)
>>>
>>> Jean-Jacques Hiblot (2):
>>> leds: Add managed API to get a LED from a device driver
>>> dt-bindings: backlight: Add led-backlight binding
>>>
>>> Tomi Valkeinen (2):
>>> leds: Add of_led_get() and led_put()
>>> backlight: add led-backlight driver
>>>
>>> .../bindings/leds/backlight/led-backlight.txt | 28 ++
>>> drivers/leds/led-class.c | 92 ++++++
>>> drivers/video/backlight/Kconfig | 7 +
>>> drivers/video/backlight/Makefile | 1 +
>>> drivers/video/backlight/led_bl.c | 268 ++++++++++++++++++
>>> include/linux/leds.h | 6 +
>>> 6 files changed, 402 insertions(+)
>>> create mode 100644 Documentation/devicetree/bindings/leds/backlight/led-backlight.txt
>>> create mode 100644 drivers/video/backlight/led_bl.c
>>>
>>
>> For the whole set:
>>
>> Acked-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
>>
>> Lee - we need to create immutable branch for this set since there will
>> be some interfering changes in the LED core in this cycle.
>>
>> I can create the branch and send the pull request once we will
>> obtain the ack from Rob for DT bindings, unless you have other
>> preference.
>
> We also require a review to be conducted by Daniel Thompson.
>
> After which, an immutable branch sounds like a good idea. I'd like to
> create this myself if you don't mind.
Sure, thanks.
--
Best regards,
Jacek Anaszewski
^ permalink raw reply
* Re: [PATCH v2 1/3] block: introduce LED block device activity trigger
From: kbuild test robot @ 2019-07-23 2:04 UTC (permalink / raw)
To: Akinobu Mita
Cc: kbuild-all, linux-block, linux-leds, linux-nvme, linux-scsi,
Akinobu Mita, Frank Steiner, Jacek Anaszewski, Pavel Machek,
Dan Murphy, Jens Axboe, James E.J. Bottomley, Martin K. Petersen
In-Reply-To: <1563807552-23498-2-git-send-email-akinobu.mita@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2122 bytes --]
Hi Akinobu,
I love your patch! Yet something to improve:
[auto build test ERROR on linus/master]
[also build test ERROR on v5.3-rc1 next-20190722]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Akinobu-Mita/block-introduce-LED-block-device-activity-trigger/20190723-074956
config: x86_64-fedora-25 (attached as .config)
compiler: gcc-7 (Debian 7.4.0-10) 7.4.0
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot <lkp@intel.com>
All error/warnings (new ones prefixed by >>):
In file included from drivers/block/umem.c:52:0:
>> drivers/block/umem.h:39:19: error: expected identifier before numeric constant
#define LED_OFF 0x00
^
>> include/linux/leds.h:27:2: note: in expansion of macro 'LED_OFF'
LED_OFF = 0,
^~~~~~~
vim +/LED_OFF +27 include/linux/leds.h
af410fc1 Johannes Berg 2006-09-29 19
c72a1d60 Richard Purdie 2006-03-31 20 struct device;
5fd752b6 Baolin Wang 2018-10-11 21 struct led_pattern;
c72a1d60 Richard Purdie 2006-03-31 22 /*
c72a1d60 Richard Purdie 2006-03-31 23 * LED Core
c72a1d60 Richard Purdie 2006-03-31 24 */
c72a1d60 Richard Purdie 2006-03-31 25
c72a1d60 Richard Purdie 2006-03-31 26 enum led_brightness {
c72a1d60 Richard Purdie 2006-03-31 @27 LED_OFF = 0,
4e552c8c Andi Shyti 2017-01-05 28 LED_ON = 1,
c72a1d60 Richard Purdie 2006-03-31 29 LED_HALF = 127,
c72a1d60 Richard Purdie 2006-03-31 30 LED_FULL = 255,
c72a1d60 Richard Purdie 2006-03-31 31 };
c72a1d60 Richard Purdie 2006-03-31 32
:::::: The code at line 27 was first introduced by commit
:::::: c72a1d608dd0eb3d553a08bfdf1c0041bebaa8a0 [PATCH] LED: add LED class
:::::: TO: Richard Purdie <rpurdie@rpsys.net>
:::::: CC: Linus Torvalds <torvalds@g5.osdl.org>
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 50846 bytes --]
^ 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