Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1584076 > unrolled thread

Re: [PATCH] backlight: report error on failure

Started byDaniel Thompson <daniel.thompson@linaro.org>
First post2017-02-19 09:20 +0100
Last post2017-02-19 09:20 +0100
Articles 1 — 1 participant

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.


Contents

  Re: [PATCH] backlight: report error on failure Daniel Thompson <daniel.thompson@linaro.org> - 2017-02-19 09:20 +0100

#1584076 — Re: [PATCH] backlight: report error on failure

FromDaniel Thompson <daniel.thompson@linaro.org>
Date2017-02-19 09:20 +0100
SubjectRe: [PATCH] backlight: report error on failure
Message-ID<tcuSR-50f-11@gated-at.bofh.it>
On Wed, Jan 18, 2017 at 09:23:50PM +0000, Sudip Mukherjee wrote:
> It is possible to update the backlight power and the brightness using
> the sysfs and on writing it either returns the count or if the callback
> function does not exist then returns the error code 'ENXIO'.
> 
> We have a situation where the userspace client is writing to the sysfs
> to update the power and since the callback function exists the client
> receives the return value as count and considers the operation to be
> successful. That is correct as the write to the sysfs was successful.
> But there is no way to know if the actual operation was done or not.

For brightness there is the actual_brightness file... but I don't think
there's anything for power.


> backlight_update_status() returns the error code if it fails. Pass that
> to the userspace client who is trying to update the power so that the
> client knows that the operation failed.

Strictly speaking this is an ABI change. Its probably a harmless one
making it ok to change but I'm interested what testing or code review 
you've done to be sure the userspace doesn't do odd things if the kernel
starts to pass through errors.


> Signed-off-by: Sudip Mukherjee <sudip.mukherjee@codethink.co.uk>
> ---
>  drivers/video/backlight/backlight.c | 7 +++----
>  1 file changed, 3 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/video/backlight/backlight.c b/drivers/video/backlight/backlight.c
> index 288318a..74b72b5 100644
> --- a/drivers/video/backlight/backlight.c
> +++ b/drivers/video/backlight/backlight.c
> @@ -146,9 +146,9 @@ static ssize_t bl_power_store(struct device *dev, struct device_attribute *attr,
>  		pr_debug("set power to %lu\n", power);
>  		if (bd->props.power != power) {
>  			bd->props.power = power;
> -			backlight_update_status(bd);
> +			rc = backlight_update_status(bd);
>  		}
> -		rc = count;
> +		rc = rc ? rc : count;

Shouldn't bd->props,power be rolled back on error?

Without it we end up in an odd situation with the lazy updates, 
specifically if the userspace observes original error and retries then we
will spuriously succeed due to the lazy update (leaving us not much 
better off than without this change).


>  	mutex_unlock(&bd->ops_lock);
>  
> @@ -176,8 +176,7 @@ int backlight_device_set_brightness(struct backlight_device *bd,
>  		else {
>  			pr_debug("set brightness to %lu\n", brightness);
>  			bd->props.brightness = brightness;
> -			backlight_update_status(bd);
> -			rc = 0;
> +			rc = backlight_update_status(bd);

Again, there is no roll back on error.


Daniel.

[toc] | [standalone]


Back to top | Article view | linux.kernel


csiph-web