linux-kernel - Re: MFD cell structure and sharing of resources

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: <20101216103550.GA5946@sortiz-mobl>
Date:	Thu, 16 Dec 2010 11:35:50 +0100
From:	Samuel Ortiz <sameo@...ux.intel.com>
To:	Daniel Drake <dsd@...top.org>
Cc:	Paul Fox <pgf@...top.org>, Andres Salomon <dilinger@...ued.net>,
	linux-kernel@...r.kernel.org
Subject: Re: MFD cell structure and sharing of resources

Hi Daniel,

On Fri, Dec 10, 2010 at 03:37:30PM +0000, Daniel Drake wrote:
> A few options that spring to mind:
> 
> 1. Adjust the list of mfd cells in drivers/mfd/cs5535-mfd so that
> rather than being a list of resources, it is a list of drivers that
> rely on the mfd driver. The entries would be: gpio, mfgpt,
> olpc-xo1-pm, olpc-xo1-sci. olpc-xo1-pm would have the 2 resources it
> needs (pms & acpi), and the acpi resource would be duplicated into
> olpc-xo1-sci  too.
> 
> We'd then add a machine_is_olpc()  check inside cs5535-mfd so that the
> OLPC-specific cells are only passed to mfd_add_devices on OLPC
> laptops.
> 
> 2. Continue with Andres' olpc-xo1-pm patch that makes that driver act
> as a driver for both acpi & pms. When both resources are available, it
> could probe an olpc-xo1-sci platform device as a child of itself,
> having the ACPI resource shared on the platform_device level (similar
> to how MFD shares resources via cells).
This sounds like an acceptable solution to me.

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

I see a 4th solution though:

Define and export a set of I/O routines from the MFD driver, for the shared
resources. The routines would take as arguments one of the shared module
(ACPI, PMS, etc..) and a register (and obviously a value for the writing
parts...), and do the I/O operation for your driver. This is similar to what
the twl driver does, although over i2c.
That means requesting and releasing the shared regions from the MFD driver,
before knowing if there is a user for it or not. I realize this could lead to
some resource conflicts, although this is very unlikely. Potentially, we could
have a callback into the MFD driver from the subdevice to let it know that the
resource is requested. But then your #2 solution would look better to me.

Cheers,
Samuel.

-- 
Intel Open Source Technology Centre
http://oss.intel.com/
--
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/