From: arnd@arndb•de (Arnd Bergmann)
To: linux-arm-kernel@lists•infradead.org
Subject: [PATCH 1/2] mfd: max8925: request resource region
Date: Mon, 7 May 2012 15:09:54 +0000 [thread overview]
Message-ID: <201205071509.55166.arnd@arndb.de> (raw)
In-Reply-To: <20120507140634.GD17002@opensource.wolfsonmicro.com>
On Monday 07 May 2012, Mark Brown wrote:
> On Mon, May 07, 2012 at 01:14:51PM +0000, Arnd Bergmann wrote:
>
> > There are two distinct problems here:
>
> > * conflicts in request_resource() between stuff that is in fundamentally
> > different.
> > * defining the __io() address space to have a zero offset, which causes
> > NULL pointer dereferences in legacy ISA drivers.
>
> Right, though in the MFD case neither of these things should be relevant
> as the resources should never actually be used in this way.
Well, particularly patch 2 of this series introduces those problems,
but yes, it should be a separate issue.
> > My feeling is that the resource model is just hasn't moved along
> > with the times (predates and doesn't really map to the device model) and
> > is used in a consistent way (request_resource, allocate_resource and
> > request_region operate on the same types, but in different ways).
> > It's not clear to me whether it makes sense to continue this path
> > for new kinds of resources.
>
> This is true. On the other hand there's some infrastructure around
> resources which is pretty helpful, though now I look at it most of this
> is actually specific to platform devices rather than being a platform
> device wrapper for a generic thing. Things like platform_get_resource()
> are pretty good to use, and in the context of platform devices the whole
> resource conflict thing is normally pretty much irrelevant.
Right.
> > My understanding is also that the uses in MFD (e.g. max8925 and wm831x)
> > are only interested in the aspect of passing information to child devices
> > rather than arbitrating between conflicting accesses. If that's the case,
> > a separate mechanism that doesn't use a global numbering scheme might
> > be more appropriate.
>
> Given what I'm saying about platform devices above perhaps we should be
> factoring some of the platform device stuff up to struct device level.
> Another option would be to work on separating the management of the
> number spaces and the interfaces for getting the numbers back out to
> make it easier to add more number spaces.
Isn't that what devres is for? We should be able to just attach arbitrary
data to a device with this, e.g. a struct regmap to use for doing I/O
that a driver can use. Maybe we should add some wrappers around that
to make it more obvious to use.
Arnd
next prev parent reply other threads:[~2012-05-07 15:09 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-05-07 3:10 [PATCH 1/2] mfd: max8925: request resource region Haojian Zhuang
2012-05-07 3:10 ` [PATCH 2/2] ARM: mmp: add io head file Haojian Zhuang
2012-05-07 9:23 ` Arnd Bergmann
2012-05-07 7:58 ` [PATCH 1/2] mfd: max8925: request resource region Russell King - ARM Linux
2012-05-07 8:18 ` Haojian Zhuang
2012-05-07 8:59 ` Russell King - ARM Linux
2012-05-07 9:01 ` Mark Brown
2012-05-07 9:08 ` Russell King - ARM Linux
2012-05-07 9:47 ` Mark Brown
2012-05-07 10:14 ` Arnd Bergmann
2012-05-07 10:23 ` Haojian Zhuang
2012-05-07 11:21 ` Arnd Bergmann
2012-05-07 11:29 ` Mark Brown
[not found] ` <201205071319.48768.arnd@arndb.de>
2012-05-07 14:02 ` Samuel Ortiz
2012-05-07 14:15 ` Mark Brown
2012-05-07 15:15 ` Arnd Bergmann
2012-05-07 15:28 ` Mark Brown
2012-05-07 10:37 ` Mark Brown
[not found] ` <201205071314.51886.arnd@arndb.de>
2012-05-07 14:06 ` Mark Brown
2012-05-07 15:09 ` Arnd Bergmann [this message]
2012-05-07 15:17 ` Mark Brown
2012-05-07 19:26 ` Arnd Bergmann
2012-05-07 19:58 ` Mark Brown
2012-05-08 8:17 ` Mark Brown
2012-05-08 14:44 ` Arnd Bergmann
2012-05-08 15:31 ` Mark Brown
2012-05-09 12:43 ` Arnd Bergmann
2012-05-09 14:13 ` Mark Brown
2012-05-09 14:19 ` Arnd Bergmann
2012-05-09 14:42 ` Mark Brown
2012-05-09 15:03 ` Arnd Bergmann
2012-05-09 15:28 ` Mark Brown
2012-05-09 16:27 ` Arnd Bergmann
2012-05-09 16:18 ` Russell King - ARM Linux
2012-05-09 16:30 ` Mark Brown
2012-05-09 16:07 ` Russell King - ARM Linux
2012-05-09 16:26 ` Arnd Bergmann
2012-05-09 16:27 ` Russell King - ARM Linux
2012-05-07 18:57 ` Russell King - ARM Linux
2012-05-07 19:27 ` Mark Brown
2012-05-07 8:12 ` Samuel Ortiz
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=201205071509.55166.arnd@arndb.de \
--to=arnd@arndb$(echo .)de \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox