Re: [PATCH] gpio-ich: Share ownership of GPIO groups

Jean Delvare
2012-09-04T11:37:33Z

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@linux-fr.org>
> > > Cc: Peter Tyser <ptyser@xes-inc.com>
> > > Cc: Aaron Sierra <asierra@xes-inc.com>
> > > Cc: Grant Likely <grant.likely@secretlab.ca>
> > > Cc: Samuel Ortiz <sameo@linux.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