linux-kernel - Re: [PATCH] Add VIA VX855 multi-function device support

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] [day] [month] [year] [list]

Message-ID: <AANLkTinK8KScJ6Ux69w_ou4bbjsk8phb_2cokB-ZniFm@mail.gmail.com>
Date:	Wed, 29 Sep 2010 19:26:12 +0100
From:	Daniel Drake <dsd@...top.org>
To:	Samuel Ortiz <sameo@...ux.intel.com>
Cc:	linux-kernel@...r.kernel.org, laforge@...monks.org
Subject: Re: [PATCH] Add VIA VX855 multi-function device support

Sorry, hit send too early.

On 29 September 2010 19:21, Daniel Drake <dsd@...top.org> wrote:
> Thanks. I've made the change locally but have run into a problem.
>
> mfd_add_devices calls acpi_check_resource_conflict() on each resource.
> And as noted in the earlier patch, ACPI also has a region reserved.
> Because acpi_check_resource_conflict() says there is a conflict,
> mfd_add_devices() bails out before registering the devices.
>
> So I've researched the conflict.
> The GPIO driver is trying to reserve region 0x420 - 0x452
> ACPI reports a conflict on "PRIE" 0x434
>
> Indeed, 0x434 is something ACPI-specific, so ACPI is right to say "get
> off my turf", and actually there are a whole host of non-GPIO things
> intermixed with GPIO things within the region 0x420 - 0x452.
>
> So, I thought about making the driver only reserve the 2 ports that it
> uses: 0x448,  0x44c
>
> However, ACPI has also reserved 0x448. This is because the XO-1.5 also
> uses GPIOs for the lid switch and ebook switch, which are basically
> presented to the OS as normal ACPI buttons. This particular byte
> includes a range of GPIOs including the ones that ACPI uses internally
> (the switches) plus the ones that we want to make available through
> the gpio driver.
>
> So, we're running into a limitation with Linux's model that

...an individual byte is either owned by one driver or another. In
this case, we want certain bits to belong to ACPI and other bits to
belong to the gpio driver. And given that these are "general purpose"
I/Os, this sharing even seems reasonable.

Any thoughts on what we can do?
Perhaps we could avoid using the mfd cell resource mechanism for the
GPIO ports, go back to passing them some other way, and attempting to
reserve the 2 needed ports but not bailing out if they can't be
reserved.

Thanks,
Daniel
--
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/