On Mon, 2007-12-10 at 17:15 +1100, Benjamin Herrenschmidt wrote:
> The current pci_assign_unassigned_resources() code doesn't work properly
> on 32 bits platforms with 64 bits resources. The main reason is the use
> of unsigned long in various places instead of resource_size_t.
>
> This fixes
The current pci_assign_unassigned_resources() code doesn't work properly
on 32 bits platforms with 64 bits resources. The main reason is the use
of unsigned long in various places instead of resource_size_t.
This fixes it, along with some tricks to avoid casting to 64 bits on
platforms that don't
The current pci_assign_unassigned_resources() code doesn't work properly
on 32 bits platforms with 64 bits resources. The main reason is the use
of unsigned long in various places instead of resource_size_t.
This fixes it, along with some tricks to avoid casting to 64 bits on
platforms that don't
On Mon, 2007-12-10 at 17:15 +1100, Benjamin Herrenschmidt wrote:
The current pci_assign_unassigned_resources() code doesn't work properly
on 32 bits platforms with 64 bits resources. The main reason is the use
of unsigned long in various places instead of resource_size_t.
This fixes it,
On Thu, 2007-12-06 at 17:00 -0800, Greg KH wrote:
> But that is how we already handle this today, in numerous places in
> the
> kernel for this very type.
>
> So, you can disagree that this is what we need to do, and if so, feel
> free to fix up a whole lot of files in the tree :)
Heh, ok,
On Thu, 2007-12-06 at 17:00 -0800, Greg KH wrote:
But that is how we already handle this today, in numerous places in
the
kernel for this very type.
So, you can disagree that this is what we need to do, and if so, feel
free to fix up a whole lot of files in the tree :)
Heh, ok, allright,
On Thu, Dec 06, 2007 at 06:58:54PM +1100, Benjamin Herrenschmidt wrote:
>
> On Wed, 2007-12-05 at 22:39 -0800, Greg KH wrote:
> > > that is it can be either unsigned int, unsigned long or unsigned
> > long
> > > long... and we have no way to reliably printk that.
> >
> > We do this already just
> It's been discussed before. Some of the solutions discussed:
>
> - Add something like PRI_RES which can be concatenated into a printk.
>Ugly.
> - Patch gcc to allow user-definable types. I think OpenBSD has a patch
>for this. Then we have to get that patch propagated to all the
>
Kumar Gala <[EMAIL PROTECTED]> writes:
> How does gcc deal with glibc extension to allow people to add their
> own specifiers?
It doesn't, gcc only knows about the standard specifiers. But it also
defines attributes that check other formats, like its own asm_fprintf
format specs.
Andreas.
On Dec 6, 2007, at 2:16 AM, Matthew Wilcox wrote:
On Thu, Dec 06, 2007 at 06:58:54PM +1100, Benjamin Herrenschmidt
wrote:
I was just hoping somebody had a better idea, like a way to add a new
format specifier to printk without losing gcc type checking :-)
It's been discussed before. Some
On Thu, Dec 06, 2007 at 06:58:54PM +1100, Benjamin Herrenschmidt wrote:
> I was just hoping somebody had a better idea, like a way to add a new
> format specifier to printk without losing gcc type checking :-)
It's been discussed before. Some of the solutions discussed:
- Add something like
On Thu, 6 Dec 2007, Benjamin Herrenschmidt wrote:
> On Wed, 2007-12-05 at 22:39 -0800, Greg KH wrote:
> > > that is it can be either unsigned int, unsigned long or unsigned
> > long
> > > long... and we have no way to reliably printk that.
> >
> > We do this already just fine. Take a look in
On Thu, 6 Dec 2007, Benjamin Herrenschmidt wrote:
On Wed, 2007-12-05 at 22:39 -0800, Greg KH wrote:
that is it can be either unsigned int, unsigned long or unsigned
long
long... and we have no way to reliably printk that.
We do this already just fine. Take a look in the kernel, I
On Thu, Dec 06, 2007 at 06:58:54PM +1100, Benjamin Herrenschmidt wrote:
I was just hoping somebody had a better idea, like a way to add a new
format specifier to printk without losing gcc type checking :-)
It's been discussed before. Some of the solutions discussed:
- Add something like
On Dec 6, 2007, at 2:16 AM, Matthew Wilcox wrote:
On Thu, Dec 06, 2007 at 06:58:54PM +1100, Benjamin Herrenschmidt
wrote:
I was just hoping somebody had a better idea, like a way to add a new
format specifier to printk without losing gcc type checking :-)
It's been discussed before. Some
Kumar Gala [EMAIL PROTECTED] writes:
How does gcc deal with glibc extension to allow people to add their
own specifiers?
It doesn't, gcc only knows about the standard specifiers. But it also
defines attributes that check other formats, like its own asm_fprintf
format specs.
Andreas.
--
It's been discussed before. Some of the solutions discussed:
- Add something like PRI_RES which can be concatenated into a printk.
Ugly.
- Patch gcc to allow user-definable types. I think OpenBSD has a patch
for this. Then we have to get that patch propagated to all the
On Thu, Dec 06, 2007 at 06:58:54PM +1100, Benjamin Herrenschmidt wrote:
On Wed, 2007-12-05 at 22:39 -0800, Greg KH wrote:
that is it can be either unsigned int, unsigned long or unsigned
long
long... and we have no way to reliably printk that.
We do this already just fine. Take a
On Wed, 2007-12-05 at 22:39 -0800, Greg KH wrote:
> > that is it can be either unsigned int, unsigned long or unsigned
> long
> > long... and we have no way to reliably printk that.
>
> We do this already just fine. Take a look in the kernel, I think we
> just always cast it to long long to be
On Thu, Dec 06, 2007 at 02:22:27PM +1100, Benjamin Herrenschmidt wrote:
>
> On Wed, 2007-12-05 at 17:40 +1100, Benjamin Herrenschmidt wrote:
> > The current pci_assign_unassigned_resources() code doesn't work properly
> > on 32 bits platforms with 64 bits resources. The main reason is the use
> >
On Wed, 2007-12-05 at 17:40 +1100, Benjamin Herrenschmidt wrote:
> The current pci_assign_unassigned_resources() code doesn't work properly
> on 32 bits platforms with 64 bits resources. The main reason is the use
> of unsigned long in various places instead of resource_size_t.
>
> This fixes
On Wed, 2007-12-05 at 17:40 +1100, Benjamin Herrenschmidt wrote:
The current pci_assign_unassigned_resources() code doesn't work properly
on 32 bits platforms with 64 bits resources. The main reason is the use
of unsigned long in various places instead of resource_size_t.
This fixes it,
On Thu, Dec 06, 2007 at 02:22:27PM +1100, Benjamin Herrenschmidt wrote:
On Wed, 2007-12-05 at 17:40 +1100, Benjamin Herrenschmidt wrote:
The current pci_assign_unassigned_resources() code doesn't work properly
on 32 bits platforms with 64 bits resources. The main reason is the use
of
On Wed, 2007-12-05 at 22:39 -0800, Greg KH wrote:
that is it can be either unsigned int, unsigned long or unsigned
long
long... and we have no way to reliably printk that.
We do this already just fine. Take a look in the kernel, I think we
just always cast it to long long to be
The current pci_assign_unassigned_resources() code doesn't work properly
on 32 bits platforms with 64 bits resources. The main reason is the use
of unsigned long in various places instead of resource_size_t.
This fixes it, along with some tricks to avoid casting to 64 bits on
platforms that don't
On Tue, 2007-12-04 at 17:08 +1100, Benjamin Herrenschmidt wrote:
> The current pci_assign_unassigned_resources() code doesn't work properly
> on 32 bits platforms with 64 bits resources. The main reason is the use
> of unsigned long in various places instead of resource_size_t.
>
> This fixes
On Tue, 2007-12-04 at 13:39 +0100, Geert Uytterhoeven wrote:
>
> Can we please have them in ? They look very useful to
> me
> elsewhere (other bus drivers, device drivers), too.
>
> What about naming the printf format specifier macros more like in C99,
> e.g.
> PRI*?
That's a can of worms I
On Tue, 4 Dec 2007, Benjamin Herrenschmidt wrote:
> The current pci_assign_unassigned_resources() code doesn't work properly
> on 32 bits platforms with 64 bits resources. The main reason is the use
> of unsigned long in various places instead of resource_size_t.
>
> This fixes it, along with
On Tue, 4 Dec 2007, Benjamin Herrenschmidt wrote:
The current pci_assign_unassigned_resources() code doesn't work properly
on 32 bits platforms with 64 bits resources. The main reason is the use
of unsigned long in various places instead of resource_size_t.
This fixes it, along with some
On Tue, 2007-12-04 at 13:39 +0100, Geert Uytterhoeven wrote:
Can we please have them in linux/ioport.h? They look very useful to
me
elsewhere (other bus drivers, device drivers), too.
What about naming the printf format specifier macros more like in C99,
e.g.
PRI*?
That's a can of
On Tue, 2007-12-04 at 17:08 +1100, Benjamin Herrenschmidt wrote:
The current pci_assign_unassigned_resources() code doesn't work properly
on 32 bits platforms with 64 bits resources. The main reason is the use
of unsigned long in various places instead of resource_size_t.
This fixes it,
The current pci_assign_unassigned_resources() code doesn't work properly
on 32 bits platforms with 64 bits resources. The main reason is the use
of unsigned long in various places instead of resource_size_t.
This fixes it, along with some tricks to avoid casting to 64 bits on
platforms that don't
The current pci_assign_unassigned_resources() code doesn't work properly
on 32 bits platforms with 64 bits resources. The main reason is the use
of unsigned long in various places instead of resource_size_t.
This fixes it, along with some tricks to avoid casting to 64 bits on
platforms that don't
The current pci_assign_unassigned_resources() code doesn't work properly
on 32 bits platforms with 64 bits resources. The main reason is the use
of unsigned long in various places instead of resource_size_t.
This fixes it, along with some tricks to avoid casting to 64 bits on
platforms that don't
34 matches
Mail list logo
