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, 07 Aug 2014 18:30:47 +0900
From:	Jingoo Han <jg1.han@...sung.com>
To:	'Thierry Reding' <thierry.reding@...il.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,
	'Jingoo Han' <jg1.han@...sung.com>,
	'Ajay Kumar' <ajaykumar.rs@...sung.com>
Subject: Re: [RFC] pwm-backlight: Allow backlight to remain disabled on boot

On Thursday, July 31, 2014 8:55 PM, Thierry Reding wrote:
> 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.

(+cc Ajay Kumar)

Personally, I prefer not to call backlight_update_status(), when the
backlight was already turned on by bootloader. Also, it would be better
for subsystems such as DRM to handle the power of panel.

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

I also agree with the way to use DT.

Best regards,
Jingoo Han

> 
> Thierry

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists