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, allri
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 o
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 PRI
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
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 it,
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,
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 jus
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
14 matches
Mail list logo
