linux-kernel - Re: [RFC] pwm-backlight: Allow backlight to remain disabled on boot

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 31 Jul 2014 13:54:31 +0200
From:	Thierry Reding <thierry.reding@...il.com>
To:	Jingoo Han <jg1.han@...sung.com>, Bryan Wu <cooloney@...il.com>,
	Lee Jones <lee.jones@...aro.org>
Cc:	Rob Herring <robh+dt@...nel.org>,
	Mark Rutland <mark.rutland@....com>,
	Pawel Moll <pawel.moll@....com>,
	Ian Campbell <ijc+devicetree@...lion.org.uk>,
	Kumar Gala <galak@...eaurora.org>,
	Jean-Christophe Plagniol-Villard <plagnioj@...osoft.com>,
	Tomi Valkeinen <tomi.valkeinen@...com>,
	Russell King <linux@....linux.org.uk>,
	Eric Miao <eric.y.miao@...il.com>, devicetree@...r.kernel.org,
	linux-arm-kernel@...ts.infradead.org, linux-fbdev@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [RFC] pwm-backlight: Allow backlight to remain disabled on boot

On Thu, Jul 31, 2014 at 01:42:50PM +0200, Thierry Reding wrote:
[...]
> @@ -317,6 +319,12 @@ static int pwm_backlight_probe(struct platform_device *pdev)
>  	}
>  
>  	bl->props.brightness = data->dft_brightness;
> +
> +	if (data->boot_off)
> +		bl->props.power = FB_BLANK_POWERDOWN;
> +	else
> +		bl->props.power = FB_BLANK_UNBLANK;
> +
>  	backlight_update_status(bl);

Looking at this again, perhaps a more sensible thing to do would be to
not call backlight_update_status() in the first place. For example if
the board defines that backlight should be kept off at boot, but the
bootloader had already enabled it, then this would effectively turn off
the backlight again.

I think it's safe to assume that if the bootloader sets up the backlight
then it would also set up the display. Therefore not touching the
backlight state at all at probe time seems like the safest default.

Of course that doesn't help people who use some dumb framebuffer driver
and therefore nothing explicitly enables the backlight. So it would
still be changing behaviour for people for whom the bootloader doesn't
set up the backlight at all and who therefore rely on the kernel to turn
it on.

We could perhaps alleviate that pain a little by making this dependent
on whether or not the board is booted using DT on the assumption that
anything that uses DT would be "modern" enough to provide a means to
automatically enable the backlight at the right moment.

Thierry

Content of type "application/pgp-signature" skipped