At the same time, we are working on other improvements to olpc-xo1(adding suspend/resume support). Due to review comments we are goingto rename this to olpc-xo1-pm and make it builtin only.

Then we are going to add a new driver, perhaps named olpc-xo1-sci,which deals with things like power button input device, lid switch,etc. This driver needs to use the "cs5536-acpi" resource which is alsoused by olpc-xo1-pm.

So the question is: how can 2 drivers share this MFD resource?

We do not want to merge olpc-xo1-sci and olpc-xo1-pm, becauseolpc-xo1-pm can only be builtin (but thankfully is small), andolpc-xo1-sci will become a bit more bloated and we'd like to make thatmodular (in the interests of generic distros).

A few options that spring to mind:

1. Adjust the list of mfd cells in drivers/mfd/cs5535-mfd so thatrather than being a list of resources, it is a list of drivers thatrely on the mfd driver. The entries would be: gpio, mfgpt,olpc-xo1-pm, olpc-xo1-sci. olpc-xo1-pm would have the 2 resources itneeds (pms & acpi), and the acpi resource would be duplicated intoolpc-xo1-sci too.

We'd then add a machine_is_olpc() check inside cs5535-mfd so that theOLPC-specific cells are only passed to mfd_add_devices on OLPClaptops.

2. Continue with Andres' olpc-xo1-pm patch that makes that driver actas a driver for both acpi & pms. When both resources are available, itcould probe an olpc-xo1-sci platform device as a child of itself,having the ACPI resource shared on the platform_device level (similarto how MFD shares resources via cells).

3. For olpc-xo1-pm and olpc-xo1-sci, forget about hooking into MFD andgo back to the route of looking for the appropriate device on the PCIbus and accessing the regions that way.