On Tuesday 07 August 2012, Geert Uytterhoeven wrote:
>Don't you need an extra file in /proc, too (cfr. /proc/ioports and
>/proc/iomem)?
>
> And as Arnd pointed out, if resources will be used for various new buses,
> "IORESOURCE_FOO" or "IORESOURCE_OTHER" is a bit vague.
> What about conflicts
On Tue, Aug 07, 2012 at 04:44:58PM +0100, Russell King wrote:
> However, one issue that I hope has already been addressed is what space
> the ranges are in, and how does a sub-driver get to know that. To put
> it another way, how does a sub-driver get to know about the 'base' for
> these
On Tue, Aug 07, 2012 at 02:28:15PM +, Arnd Bergmann wrote:
> On Tuesday 07 August 2012, Mark Brown wrote:
> > As I said elsewhere 88pm* needs this as a stable bugfix and wm831x
> > should be converted over too.
> I've looked through the remaining MFD drivers and found one more,
>
On Tue, Aug 07, 2012 at 02:47:50PM +0100, Russell King wrote:
> If you want to be constructive, then actually take a bloody look at my
> suggestion, try it out and report back whether it works. Stop attacking
> my proposal in whatever weak ways you can, especially in ways that I've
> already
On Tue, Aug 07, 2012 at 04:45:55PM +0100, Alan Cox wrote:
> > #define IORESOURCE_TYPE_BITS 0x1f00 /* Resource type */
> > #define IORESOURCE_IO 0x0100
> > #define IORESOURCE_MEM 0x0200
> > +#define IORESOURCE_FOO 0x0300
>
> These
On Tue, Aug 07, 2012 at 05:22:45PM +0200, Geert Uytterhoeven wrote:
> And as Arnd pointed out, if resources will be used for various new buses,
> "IORESOURCE_FOO" or "IORESOURCE_OTHER" is a bit vague.
> What about conflicts where one driver means i2c addresses and another
> one means gpio
> #define IORESOURCE_TYPE_BITS 0x1f00 /* Resource type */
> #define IORESOURCE_IO0x0100
> #define IORESOURCE_MEM 0x0200
> +#define IORESOURCE_FOO 0x0300
These are bit masks and checked as such in many places. This makes no
sense
On Tue, Aug 7, 2012 at 1:51 PM, Russell King wrote:
> How can:
>
> #define IORESOURCE_FOO 0x0300
>
> in ioport.h be called "invasive" ? The best chance of error is that the
> identifier is already in use. So learn to use grep to check the whole
> sodding tree first to make sure that the
On Tue, Aug 07, 2012 at 02:28:15PM +, Arnd Bergmann wrote:
> On Tuesday 07 August 2012, Mark Brown wrote:
> > On Tue, Aug 07, 2012 at 01:11:57PM +0100, Russell King wrote:
> > > index 589e0e7..bfee885 100644
> > > --- a/include/linux/ioport.h
> > > +++ b/include/linux/ioport.h
> > > @@ -31,6
On Tuesday 07 August 2012, Mark Brown wrote:
> On Tue, Aug 07, 2012 at 01:11:57PM +0100, Russell King wrote:
>
> > The only open questions on this are:
> > 1. Is there another driver you are concerned about.
>
> As I said elsewhere 88pm* needs this as a stable bugfix and wm831x
> should be
On Tue, Aug 07, 2012 at 01:58:20PM +0100, Mark Brown wrote:
> On Tue, Aug 07, 2012 at 12:51:40PM +0100, Russell King wrote:
>
> > For fuck sake Mark. You are insane.
>
> Please take a step back from the ad hominem remarks.
Well, stop causing frustration at this end. Yes, you're the cause of
On Tue, Aug 07, 2012 at 01:11:57PM +0100, Russell King wrote:
> The only open questions on this are:
> 1. Is there another driver you are concerned about.
As I said elsewhere 88pm* needs this as a stable bugfix and wm831x
should be converted over too.
> 2. Choosing a better name.
I'm not sure
On Tue, Aug 07, 2012 at 12:51:40PM +0100, Russell King wrote:
> For fuck sake Mark. You are insane.
Please take a step back from the ad hominem remarks.
> How can:
> #define IORESOURCE_FOO 0x0300
> in ioport.h be called "invasive" ? The best chance of error is that the
> identifier is
On Tue, Aug 07, 2012 at 12:44:15PM +0100, Russell King wrote:
> On Tue, Aug 07, 2012 at 12:38:02PM +0100, Mark Brown wrote:
> > On Tue, Aug 07, 2012 at 12:31:21PM +0100, Russell King wrote:
> > > On Tue, Aug 07, 2012 at 12:28:44PM +0100, Mark Brown wrote:
> >
> > > > The changes you're suggesting
On Tue, Aug 07, 2012 at 12:45:57PM +0100, Mark Brown wrote:
> On Tue, Aug 07, 2012 at 12:36:52PM +0100, Russell King wrote:
>
> > And, for those hard of thinking, I'll tell you exactly how invasive it
> > is.
>
> > 1. You modify ioport.h to add the new type.
>
> > Yes, it's really that damned
On Tue, Aug 07, 2012 at 12:36:52PM +0100, Russell King wrote:
> And, for those hard of thinking, I'll tell you exactly how invasive it
> is.
> 1. You modify ioport.h to add the new type.
> Yes, it's really that damned simple. Not invasive at all.
Your step 1 is the bit that strikes me as
On Tue, Aug 07, 2012 at 12:38:02PM +0100, Mark Brown wrote:
> On Tue, Aug 07, 2012 at 12:31:21PM +0100, Russell King wrote:
> > On Tue, Aug 07, 2012 at 12:28:44PM +0100, Mark Brown wrote:
>
> > > The changes you're suggesting are extremely invasive for stable
> > > especially given that we have a
On Tue, Aug 07, 2012 at 12:35:22PM +0100, Mark Brown wrote:
> On Tue, Aug 07, 2012 at 11:28:27AM +, Arnd Bergmann wrote:
>
> > I've looked through the code some more and your solution sounds
> > like the best option to get this sorted quickly. The entire
>
> There's no disagreement here, if
On Tue, Aug 07, 2012 at 12:31:21PM +0100, Russell King wrote:
> On Tue, Aug 07, 2012 at 12:28:44PM +0100, Mark Brown wrote:
> > The changes you're suggesting are extremely invasive for stable
> > especially given that we have a simple, driver local, fix available
> *Rubbish*.
This isn't helpful
On Tue, Aug 07, 2012 at 12:31:21PM +0100, Russell King wrote:
> On Tue, Aug 07, 2012 at 12:28:44PM +0100, Mark Brown wrote:
> > On Tue, Aug 07, 2012 at 12:13:31PM +0100, Russell King wrote:
> > > On Tue, Aug 07, 2012 at 11:38:51AM +0100, Mark Brown wrote:
> >
> > > > If nothing else this seems
On Tue, Aug 07, 2012 at 11:28:27AM +, Arnd Bergmann wrote:
> I've looked through the code some more and your solution sounds
> like the best option to get this sorted quickly. The entire
There's no disagreement here, if someone actually wrote a patch we might
get somewhere here. That said,
On Tuesday 07 August 2012, Russell King wrote:
> On Tue, Aug 07, 2012 at 11:28:27AM +, Arnd Bergmann wrote:
> > If we introduce a new IORESOURCE_OTHER, I would actually prefer to
> > define it to 0x for purely aesthetic reasons, the effect
> > should be the same as using 0x0300.
>
On Tue, Aug 07, 2012 at 11:28:27AM +, Arnd Bergmann wrote:
> If we introduce a new IORESOURCE_OTHER, I would actually prefer to
> define it to 0x for purely aesthetic reasons, the effect
> should be the same as using 0x0300.
I'd suggest not, because we can use that to detect
On Tue, Aug 07, 2012 at 12:28:44PM +0100, Mark Brown wrote:
> On Tue, Aug 07, 2012 at 12:13:31PM +0100, Russell King wrote:
> > On Tue, Aug 07, 2012 at 11:38:51AM +0100, Mark Brown wrote:
>
> > > If nothing else this seems much more suitable for stable and -rc (the
> > > bug has been there since
On Tue, Aug 07, 2012 at 12:13:31PM +0100, Russell King wrote:
> On Tue, Aug 07, 2012 at 11:38:51AM +0100, Mark Brown wrote:
> > If nothing else this seems much more suitable for stable and -rc (the
> > bug has been there since v3.4).
> There is no need for such hacks.
Please read the text you
On Tuesday 07 August 2012, Russell King wrote:
> On Tue, Aug 07, 2012 at 06:22:22PM +1000, Benjamin Herrenschmidt wrote:
> > On Mon, 2012-08-06 at 22:31 +0100, Russell King wrote:
> > >
> > > So, if we made this a numeric index, then we have 32 resource types
> > > to deal with, and no need to
On Tue, Aug 07, 2012 at 11:38:51AM +0100, Mark Brown wrote:
> On Tue, Aug 07, 2012 at 09:47:25AM +0800, Haojian Zhuang wrote:
>
> > It's because IO_SPACE_LIMIT is set as 0 if there's no PCI devices. But
> > IORESOURCE_IO is also used in PMIC mfd drivers to distinguish
> > different components.
>
On Tue, Aug 07, 2012 at 09:47:25AM +0800, Haojian Zhuang wrote:
> It's because IO_SPACE_LIMIT is set as 0 if there's no PCI devices. But
> IORESOURCE_IO is also used in PMIC mfd drivers to distinguish
> different components.
The change to keep things working here (pending the other changes which
On Tue, Aug 07, 2012 at 06:22:22PM +1000, Benjamin Herrenschmidt wrote:
> On Mon, 2012-08-06 at 22:31 +0100, Russell King wrote:
> >
> > So, if we made this a numeric index, then we have 32 resource types
> > to deal with, and no need to bugger around with re-using an existing
> > type for
On Tue, 2012-08-07 at 09:47 +0800, Haojian Zhuang wrote:
> > Whoever looks at this would need to do some detective work, it does
> seem
> > like there must have been a reason to use a bitmask here...
>
> Changing bitmask to a value for IORESOURCE type is a risk. I agree on
> Mark
> that someone
On Mon, 2012-08-06 at 22:31 +0100, Russell King wrote:
>
> So, if we made this a numeric index, then we have 32 resource types
> to deal with, and no need to bugger around with re-using an existing
> type for something else.
>
> This makes sense, MEM, IRQ and DMA are all mutually exclusive, as
>
On Tue, Aug 07, 2012 at 09:47:25AM +0800, Haojian Zhuang wrote:
> On Tue, Aug 7, 2012 at 6:00 AM, Mark Brown
> wrote:
> > On Mon, Aug 06, 2012 at 10:31:24PM +0100, Russell King wrote:
> >
> >> Anyway, given that this thread is broken, there's no way for me to find
> >> out what the _original_
On Tue, Aug 07, 2012 at 09:47:25AM +0800, Haojian Zhuang wrote:
On Tue, Aug 7, 2012 at 6:00 AM, Mark Brown
broo...@opensource.wolfsonmicro.com wrote:
On Mon, Aug 06, 2012 at 10:31:24PM +0100, Russell King wrote:
Anyway, given that this thread is broken, there's no way for me to find
out
On Mon, 2012-08-06 at 22:31 +0100, Russell King wrote:
So, if we made this a numeric index, then we have 32 resource types
to deal with, and no need to bugger around with re-using an existing
type for something else.
This makes sense, MEM, IRQ and DMA are all mutually exclusive, as
should
On Tue, 2012-08-07 at 09:47 +0800, Haojian Zhuang wrote:
Whoever looks at this would need to do some detective work, it does
seem
like there must have been a reason to use a bitmask here...
Changing bitmask to a value for IORESOURCE type is a risk. I agree on
Mark
that someone will
On Tue, Aug 07, 2012 at 06:22:22PM +1000, Benjamin Herrenschmidt wrote:
On Mon, 2012-08-06 at 22:31 +0100, Russell King wrote:
So, if we made this a numeric index, then we have 32 resource types
to deal with, and no need to bugger around with re-using an existing
type for something else.
On Tue, Aug 07, 2012 at 09:47:25AM +0800, Haojian Zhuang wrote:
It's because IO_SPACE_LIMIT is set as 0 if there's no PCI devices. But
IORESOURCE_IO is also used in PMIC mfd drivers to distinguish
different components.
The change to keep things working here (pending the other changes which
On Tue, Aug 07, 2012 at 11:38:51AM +0100, Mark Brown wrote:
On Tue, Aug 07, 2012 at 09:47:25AM +0800, Haojian Zhuang wrote:
It's because IO_SPACE_LIMIT is set as 0 if there's no PCI devices. But
IORESOURCE_IO is also used in PMIC mfd drivers to distinguish
different components.
The
On Tuesday 07 August 2012, Russell King wrote:
On Tue, Aug 07, 2012 at 06:22:22PM +1000, Benjamin Herrenschmidt wrote:
On Mon, 2012-08-06 at 22:31 +0100, Russell King wrote:
So, if we made this a numeric index, then we have 32 resource types
to deal with, and no need to bugger around
On Tue, Aug 07, 2012 at 12:13:31PM +0100, Russell King wrote:
On Tue, Aug 07, 2012 at 11:38:51AM +0100, Mark Brown wrote:
If nothing else this seems much more suitable for stable and -rc (the
bug has been there since v3.4).
There is no need for such hacks.
Please read the text you quoted
On Tue, Aug 07, 2012 at 12:28:44PM +0100, Mark Brown wrote:
On Tue, Aug 07, 2012 at 12:13:31PM +0100, Russell King wrote:
On Tue, Aug 07, 2012 at 11:38:51AM +0100, Mark Brown wrote:
If nothing else this seems much more suitable for stable and -rc (the
bug has been there since v3.4).
On Tue, Aug 07, 2012 at 11:28:27AM +, Arnd Bergmann wrote:
If we introduce a new IORESOURCE_OTHER, I would actually prefer to
define it to 0x for purely aesthetic reasons, the effect
should be the same as using 0x0300.
I'd suggest not, because we can use that to detect
On Tuesday 07 August 2012, Russell King wrote:
On Tue, Aug 07, 2012 at 11:28:27AM +, Arnd Bergmann wrote:
If we introduce a new IORESOURCE_OTHER, I would actually prefer to
define it to 0x for purely aesthetic reasons, the effect
should be the same as using 0x0300.
I'd
On Tue, Aug 07, 2012 at 11:28:27AM +, Arnd Bergmann wrote:
I've looked through the code some more and your solution sounds
like the best option to get this sorted quickly. The entire
There's no disagreement here, if someone actually wrote a patch we might
get somewhere here. That said, as
On Tue, Aug 07, 2012 at 12:31:21PM +0100, Russell King wrote:
On Tue, Aug 07, 2012 at 12:28:44PM +0100, Mark Brown wrote:
On Tue, Aug 07, 2012 at 12:13:31PM +0100, Russell King wrote:
On Tue, Aug 07, 2012 at 11:38:51AM +0100, Mark Brown wrote:
If nothing else this seems much more
On Tue, Aug 07, 2012 at 12:31:21PM +0100, Russell King wrote:
On Tue, Aug 07, 2012 at 12:28:44PM +0100, Mark Brown wrote:
The changes you're suggesting are extremely invasive for stable
especially given that we have a simple, driver local, fix available
*Rubbish*.
This isn't helpful or
On Tue, Aug 07, 2012 at 12:35:22PM +0100, Mark Brown wrote:
On Tue, Aug 07, 2012 at 11:28:27AM +, Arnd Bergmann wrote:
I've looked through the code some more and your solution sounds
like the best option to get this sorted quickly. The entire
There's no disagreement here, if someone
On Tue, Aug 07, 2012 at 12:38:02PM +0100, Mark Brown wrote:
On Tue, Aug 07, 2012 at 12:31:21PM +0100, Russell King wrote:
On Tue, Aug 07, 2012 at 12:28:44PM +0100, Mark Brown wrote:
The changes you're suggesting are extremely invasive for stable
especially given that we have a simple,
On Tue, Aug 07, 2012 at 12:36:52PM +0100, Russell King wrote:
And, for those hard of thinking, I'll tell you exactly how invasive it
is.
1. You modify ioport.h to add the new type.
Yes, it's really that damned simple. Not invasive at all.
Your step 1 is the bit that strikes me as invasive
On Tue, Aug 07, 2012 at 12:45:57PM +0100, Mark Brown wrote:
On Tue, Aug 07, 2012 at 12:36:52PM +0100, Russell King wrote:
And, for those hard of thinking, I'll tell you exactly how invasive it
is.
1. You modify ioport.h to add the new type.
Yes, it's really that damned simple. Not
On Tue, Aug 07, 2012 at 12:44:15PM +0100, Russell King wrote:
On Tue, Aug 07, 2012 at 12:38:02PM +0100, Mark Brown wrote:
On Tue, Aug 07, 2012 at 12:31:21PM +0100, Russell King wrote:
On Tue, Aug 07, 2012 at 12:28:44PM +0100, Mark Brown wrote:
The changes you're suggesting are
On Tue, Aug 07, 2012 at 12:51:40PM +0100, Russell King wrote:
For fuck sake Mark. You are insane.
Please take a step back from the ad hominem remarks.
How can:
#define IORESOURCE_FOO 0x0300
in ioport.h be called invasive ? The best chance of error is that the
identifier is already
On Tue, Aug 07, 2012 at 01:11:57PM +0100, Russell King wrote:
The only open questions on this are:
1. Is there another driver you are concerned about.
As I said elsewhere 88pm* needs this as a stable bugfix and wm831x
should be converted over too.
2. Choosing a better name.
I'm not sure we
On Tue, Aug 07, 2012 at 01:58:20PM +0100, Mark Brown wrote:
On Tue, Aug 07, 2012 at 12:51:40PM +0100, Russell King wrote:
For fuck sake Mark. You are insane.
Please take a step back from the ad hominem remarks.
Well, stop causing frustration at this end. Yes, you're the cause of my
On Tuesday 07 August 2012, Mark Brown wrote:
On Tue, Aug 07, 2012 at 01:11:57PM +0100, Russell King wrote:
The only open questions on this are:
1. Is there another driver you are concerned about.
As I said elsewhere 88pm* needs this as a stable bugfix and wm831x
should be converted over
On Tue, Aug 07, 2012 at 02:28:15PM +, Arnd Bergmann wrote:
On Tuesday 07 August 2012, Mark Brown wrote:
On Tue, Aug 07, 2012 at 01:11:57PM +0100, Russell King wrote:
index 589e0e7..bfee885 100644
--- a/include/linux/ioport.h
+++ b/include/linux/ioport.h
@@ -31,6 +31,7 @@ struct
On Tue, Aug 7, 2012 at 1:51 PM, Russell King r...@arm.linux.org.uk wrote:
How can:
#define IORESOURCE_FOO 0x0300
in ioport.h be called invasive ? The best chance of error is that the
identifier is already in use. So learn to use grep to check the whole
sodding tree first to make sure
#define IORESOURCE_TYPE_BITS 0x1f00 /* Resource type */
#define IORESOURCE_IO0x0100
#define IORESOURCE_MEM 0x0200
+#define IORESOURCE_FOO 0x0300
These are bit masks and checked as such in many places. This makes no
sense at
On Tue, Aug 07, 2012 at 05:22:45PM +0200, Geert Uytterhoeven wrote:
And as Arnd pointed out, if resources will be used for various new buses,
IORESOURCE_FOO or IORESOURCE_OTHER is a bit vague.
What about conflicts where one driver means i2c addresses and another
one means gpio addresses? The
On Tue, Aug 07, 2012 at 04:45:55PM +0100, Alan Cox wrote:
#define IORESOURCE_TYPE_BITS 0x1f00 /* Resource type */
#define IORESOURCE_IO 0x0100
#define IORESOURCE_MEM 0x0200
+#define IORESOURCE_FOO 0x0300
These are bit
On Tue, Aug 07, 2012 at 02:47:50PM +0100, Russell King wrote:
If you want to be constructive, then actually take a bloody look at my
suggestion, try it out and report back whether it works. Stop attacking
my proposal in whatever weak ways you can, especially in ways that I've
already
On Tue, Aug 07, 2012 at 02:28:15PM +, Arnd Bergmann wrote:
On Tuesday 07 August 2012, Mark Brown wrote:
As I said elsewhere 88pm* needs this as a stable bugfix and wm831x
should be converted over too.
I've looked through the remaining MFD drivers and found one more,
max8925-core,
On Tue, Aug 07, 2012 at 04:44:58PM +0100, Russell King wrote:
However, one issue that I hope has already been addressed is what space
the ranges are in, and how does a sub-driver get to know that. To put
it another way, how does a sub-driver get to know about the 'base' for
these register
On Tuesday 07 August 2012, Geert Uytterhoeven wrote:
Don't you need an extra file in /proc, too (cfr. /proc/ioports and
/proc/iomem)?
And as Arnd pointed out, if resources will be used for various new buses,
IORESOURCE_FOO or IORESOURCE_OTHER is a bit vague.
What about conflicts where one
On Tue, Aug 7, 2012 at 6:00 AM, Mark Brown
wrote:
> On Mon, Aug 06, 2012 at 10:31:24PM +0100, Russell King wrote:
>
>> Anyway, given that this thread is broken, there's no way for me to find
>> out what the _original_ issue is that you're talking about. So I'm going
>> to guess that it's come up
On Mon, Aug 06, 2012 at 10:31:24PM +0100, Russell King wrote:
> So, the fact that platform devices will get any resource marked
> IORESOURCE_IO registered against ioport_resource isn't a problem
> then...
This is what providing a separate parent to ensure they're in a
different tree is there to
On Mon, Aug 06, 2012 at 08:53:52PM +0100, Mark Brown wrote:
> On Mon, Aug 06, 2012 at 08:22:09PM +0100, Russell King wrote:
> > On Mon, Aug 06, 2012 at 04:58:06PM +0100, Mark Brown wrote:
>
> > > That's one reason why I've not attacked this problem myself, but frankly
> > > I'm totally happy with
On Mon, Aug 06, 2012 at 08:22:09PM +0100, Russell King wrote:
> On Mon, Aug 06, 2012 at 04:58:06PM +0100, Mark Brown wrote:
> > That's one reason why I've not attacked this problem myself, but frankly
> > I'm totally happy with using _IO here so I've not looked particularly
> > closely.
> NO.
On Mon, Aug 06, 2012 at 04:58:06PM +0100, Mark Brown wrote:
> On Mon, Aug 06, 2012 at 11:56:47PM +0800, Haojian Zhuang wrote:
> > On Mon, Aug 6, 2012 at 11:46 PM, Mark Brown
>
> > > Right, but _MEM isn't terribly relevant either. If anything _IO is a
> > > bit better as ioports are *somewhat*
On Mon, Aug 06, 2012 at 11:56:47PM +0800, Haojian Zhuang wrote:
> On Mon, Aug 6, 2012 at 11:46 PM, Mark Brown
> > Right, but _MEM isn't terribly relevant either. If anything _IO is a
> > bit better as ioports are *somewhat* similar to registers.
> The problem is that each bit is already used in
On Mon, Aug 6, 2012 at 11:46 PM, Mark Brown
wrote:
> On Mon, Aug 06, 2012 at 10:42:12PM +0800, Haojian Zhuang wrote:
>> On Mon, Aug 6, 2012 at 10:30 PM, Mark Brown
>
>> > This isn't much more appropriate - _MEM is for memory ranges so isn't
>> > directly relevant to register addresses either. If
On Mon, Aug 06, 2012 at 10:42:12PM +0800, Haojian Zhuang wrote:
> On Mon, Aug 6, 2012 at 10:30 PM, Mark Brown
> > This isn't much more appropriate - _MEM is for memory ranges so isn't
> > directly relevant to register addresses either. If anything _IO is
> > slightly nearer.
> I use register
On Mon, Aug 6, 2012 at 10:30 PM, Mark Brown
wrote:
> On Mon, Aug 06, 2012 at 12:32:48AM +0800, Haojian Zhuang wrote:
>
>> Since IORESOURCE_IO is used for PCI devices, it doesn't fit on
>> 88PM860x PMIC device that lies on I2C bus. So use IORESOURCE_MEM
>> instead.
>
> This isn't much more
On Mon, Aug 06, 2012 at 12:32:48AM +0800, Haojian Zhuang wrote:
> Since IORESOURCE_IO is used for PCI devices, it doesn't fit on
> 88PM860x PMIC device that lies on I2C bus. So use IORESOURCE_MEM
> instead.
This isn't much more appropriate - _MEM is for memory ranges so isn't
directly relevant
On Mon, Aug 06, 2012 at 12:32:48AM +0800, Haojian Zhuang wrote:
Since IORESOURCE_IO is used for PCI devices, it doesn't fit on
88PM860x PMIC device that lies on I2C bus. So use IORESOURCE_MEM
instead.
This isn't much more appropriate - _MEM is for memory ranges so isn't
directly relevant to
On Mon, Aug 6, 2012 at 10:30 PM, Mark Brown
broo...@opensource.wolfsonmicro.com wrote:
On Mon, Aug 06, 2012 at 12:32:48AM +0800, Haojian Zhuang wrote:
Since IORESOURCE_IO is used for PCI devices, it doesn't fit on
88PM860x PMIC device that lies on I2C bus. So use IORESOURCE_MEM
instead.
On Mon, Aug 06, 2012 at 10:42:12PM +0800, Haojian Zhuang wrote:
On Mon, Aug 6, 2012 at 10:30 PM, Mark Brown
This isn't much more appropriate - _MEM is for memory ranges so isn't
directly relevant to register addresses either. If anything _IO is
slightly nearer.
I use register resource
On Mon, Aug 6, 2012 at 11:46 PM, Mark Brown
broo...@opensource.wolfsonmicro.com wrote:
On Mon, Aug 06, 2012 at 10:42:12PM +0800, Haojian Zhuang wrote:
On Mon, Aug 6, 2012 at 10:30 PM, Mark Brown
This isn't much more appropriate - _MEM is for memory ranges so isn't
directly relevant to
On Mon, Aug 06, 2012 at 11:56:47PM +0800, Haojian Zhuang wrote:
On Mon, Aug 6, 2012 at 11:46 PM, Mark Brown
Right, but _MEM isn't terribly relevant either. If anything _IO is a
bit better as ioports are *somewhat* similar to registers.
The problem is that each bit is already used in
On Mon, Aug 06, 2012 at 04:58:06PM +0100, Mark Brown wrote:
On Mon, Aug 06, 2012 at 11:56:47PM +0800, Haojian Zhuang wrote:
On Mon, Aug 6, 2012 at 11:46 PM, Mark Brown
Right, but _MEM isn't terribly relevant either. If anything _IO is a
bit better as ioports are *somewhat* similar to
On Mon, Aug 06, 2012 at 08:22:09PM +0100, Russell King wrote:
On Mon, Aug 06, 2012 at 04:58:06PM +0100, Mark Brown wrote:
That's one reason why I've not attacked this problem myself, but frankly
I'm totally happy with using _IO here so I've not looked particularly
closely.
NO. This is
On Mon, Aug 06, 2012 at 08:53:52PM +0100, Mark Brown wrote:
On Mon, Aug 06, 2012 at 08:22:09PM +0100, Russell King wrote:
On Mon, Aug 06, 2012 at 04:58:06PM +0100, Mark Brown wrote:
That's one reason why I've not attacked this problem myself, but frankly
I'm totally happy with using _IO
On Mon, Aug 06, 2012 at 10:31:24PM +0100, Russell King wrote:
So, the fact that platform devices will get any resource marked
IORESOURCE_IO registered against ioport_resource isn't a problem
then...
This is what providing a separate parent to ensure they're in a
different tree is there to
On Tue, Aug 7, 2012 at 6:00 AM, Mark Brown
broo...@opensource.wolfsonmicro.com wrote:
On Mon, Aug 06, 2012 at 10:31:24PM +0100, Russell King wrote:
Anyway, given that this thread is broken, there's no way for me to find
out what the _original_ issue is that you're talking about. So I'm going
Since IORESOURCE_IO is used for PCI devices, it doesn't fit on
88PM860x PMIC device that lies on I2C bus. So use IORESOURCE_MEM
instead.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at
Since IORESOURCE_IO is used for PCI devices, it doesn't fit on
88PM860x PMIC device that lies on I2C bus. So use IORESOURCE_MEM
instead.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at
86 matches
Mail list logo
