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:	Tue, 4 Sep 2012 13:36:50 +0200
From:	Jean Delvare <khali@...ux-fr.org>
To:	Samuel Ortiz <sameo@...ux.intel.com>
Cc:	Grant Likely <grant.likely@...retlab.ca>,
	Linus Walleij <linus.walleij@...ricsson.com>,
	LKML <linux-kernel@...r.kernel.org>,
	Peter Tyser <ptyser@...-inc.com>,
	Aaron Sierra <asierra@...-inc.com>
Subject: Re: [PATCH] gpio-ich: Share ownership of GPIO groups

Hi Sam,

On Wed, 1 Aug 2012 12:16:46 +0200, Samuel Ortiz wrote:
> Hi Jean,
> 
> On Wed, Aug 01, 2012 at 11:13:59AM +0200, Jean Delvare wrote:
> > On Mon, 23 Jul 2012 17:34:15 +0200, Jean Delvare wrote:
> > > The ICH chips have their GPIO pins organized in 2 or 3 independent
> > > groups of 32 GPIO pins. It can happen that the ACPI BIOS wants to make
> > > use of pins in one group, preventing the OS to access these. This does
> > > not prevent the OS from accessing the other group(s).
> > > 
> > > This is the case for example on my Asus Z8NA-D6 board. The ACPI BIOS
> > > wants to control GPIO 18 (group 1), while I (the OS) need to control
> > > GPIO 52 and 53 (group 2) for SMBus multiplexing.
> > > 
> > > So instead of checking for ACPI resource conflict on the whole I/O
> > > range, check on a per-group basis, and consider it a success if at
> > > least one of the groups is available for the OS to use.
> > > 
> > > Signed-off-by: Jean Delvare <khali@...ux-fr.org>
> > > Cc: Peter Tyser <ptyser@...-inc.com>
> > > Cc: Aaron Sierra <asierra@...-inc.com>
> > > Cc: Grant Likely <grant.likely@...retlab.ca>
> > > Cc: Samuel Ortiz <sameo@...ux.intel.com>
> > > ---
> > > That's probably not the nicest code you've seen, but everything else I
> > > could think of either couldn't work or was looking worse. If anyone can
> > > think of a better approach, I'm all ears.
> > > 
> > >  drivers/gpio/gpio-ich.c     |   79 +++++++++++++++++++++++++++++++++++++------
> > >  drivers/mfd/lpc_ich.c       |   29 ++++++++++++++-
> > >  include/linux/mfd/lpc_ich.h |    1 
> > >  3 files changed, 97 insertions(+), 12 deletions(-)
> > 
> > Grant, Samuel, Linus (sorry for not including you on original
> > submission), any comment on this? I suppose it's too late for 3.6 but
> > can this be scheduled to be integrated in 3.7?
>
> I was planning to look at this one and queue it for 3.7 as I'll be working on
> my for-next branch once rc1 is tagged.
> As you said, this is not the nicest code ever, so I may have a few comments.
> No time for that right now though.

Any news on this? I'd like to get this patch (or an alternative
implementation of the same) into kernel 3.7, and its merge window is
approaching.

Thanks,
-- 
Jean Delvare
--
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