linux-kernel - Re: [PATCH] backlight: do not power off backlight when unregistering

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]

Message-ID: <20061106012610.GA9309@khazad-dum.debian.net>
Date:	Sun, 5 Nov 2006 23:26:10 -0200
From:	Henrique de Moraes Holschuh <hmh@....eng.br>
To:	Richard Purdie <rpurdie@...ys.net>
Cc:	linux-kernel@...r.kernel.org, linux-acpi@...r.kernel.org,
	Antonino Daplas <adaplas@....net>,
	Holger Macht <hmacht@...e.de>
Subject: Re: [PATCH] backlight: do not power off backlight when unregistering

On Mon, 06 Nov 2006, Richard Purdie wrote:
> that other devices would have a similar set of constraints (all the
> existing users at the time did). On such hardware, deinitialising
> anything you initialised is the norm and makes sense but the PC/ACPI
> world is different.

Yes, and we don't *init* the hardware with the backlight class either in
ACPI drivers...  AFAIK, anyway.

> Setting backlightdevice->props->update_status = NULL before
> unregistering is a horrible idea and I don't want to see hacks like that
> so yes, lets move it back into the drivers. 

Sure thing.  I am not at all interested into having such a horrible hack in
my local version of ibm-acpi for a second longer than strictly needed, so I
will help if I am able to.

> > Since the commit that introduced this behaviour (commit
> > 6ca017658b1f902c9bba2cc1017e301581f7728d) apparently did so because the
> > corgi_bl.c driver powered off the backlight, the attached patch also makes
> > sure that the corgi_bl.c driver will not have its behaviour changed.
> 
> Those commits were designed to standardise several behaviours amongst
> several drivers and this specific case was added to the core rather than
> coding it in each of several drivers. We therefore really need to update
> those other drivers too (locomo at the very least).

Do you have a list of them?  I can try to produce (untested) patches for
the ones in-tree, if you want me to.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh
-
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/