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: <20120312150717.GA13211@srcf.ucam.org>
Date:	Mon, 12 Mar 2012 15:07:17 +0000
From:	Matthew Garrett <mjg59@...f.ucam.org>
To:	platform-driver-x86@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2] platform/x86: Add driver for Apple gmux device

On Mon, Mar 12, 2012 at 09:57:01AM -0500, Seth Forshee wrote:
> On Mon, Mar 12, 2012 at 02:21:26PM +0000, Matthew Garrett wrote:
> > apple_bl probably needs some matching work to disable itself if there's 
> > a gmux present? Otherwise, this looks good.
> 
> How do you suggest doing this? The tricky point is that the gmux object
> can be present in ACPI when the gmux hardware isn't really present
> (which is what the version check really does, verifies the hardware is
> actually there). So apple_bl can't just look for the ACPI object; it
> needs to either communicate with apple-gmux or duplicate some of its
> logic.

The alternative is for apple_bl to export its unregister function and 
have gmux call that - downside is obviously that that results in gmux 
depending on apple_bl. Maybe some sort of notification list in the 
backlight core?

> We also have the problem of gmux_backlight versus acpi_video. On most
> machines with a gmux the acpi_video backlight interface is present but
> just doesn't work. This problem isn't just limited to Apples. I'm of the
> opinion that we need a more generalized solution for arbitrating between
> the backlight interfaces present on a given machine, but I haven't had a
> chance to really think about what that would look like.

The ACPI code appears to be trapping into system management mode, so 
figuring out what it's meant to do is going to be awkward. I think 
having a hook in the ACPI video driver to deregister it in cases where 
we know it doesn't work is legitimate, but since it presumably works 
under Windows it'd be nice to figure out what's broken about it.

-- 
Matthew Garrett | mjg59@...f.ucam.org
--
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ