Re: [patch 1/1] acpi: cleanup u32 flags in spin_lock calls

Re: [patch 1/1] acpi: cleanup u32 flags in spin_lock calls

[Steven Rostedt]

On Tue, 3 Jan 2006, Andrew Morton wrote:

> Steven Rostedt <rostedt-nx8X9YLhiw1AfugRpC6u6w@public.gmane.org> wrote:
> >
> >  So as long as this is 64 bits
> >  on a 64 bit machine, I'm fine with it.
>
> No, it's wrong.  We cannot assume that a 64-bit platform defines u64 as
> `unsigned long'.  For example, one architecture (sh64) defines u64 as
> `unsigned long long', so we'll get warnings when mixing pointers to u64
> and to the arg to local_irq_*().
>
> Please don't invent new stuff.  Linux uses `unsigned long' and that's that.

OK, it was fine with me, but I guess it's not fine with Linus ;)

-- Steve

-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [patch 1/1] acpi: cleanup u32 flags in spin_lock calls

[Brown, Len]

 
>Updated..

Andrew, Steven,

(and I'm sorry I have to bother you by asking this...)

Please acknowldge that you license this patch back to Intel
according either license appearing at the top of the acpi files changed.

Doing so means that we can apply this patch or a derivative of it "upstream"
in the ACPICA core, which Linux shares with FreeBSD etc.

Not doing so means that your path is licensed as GPL only, and if
I check it into Linux, then I have created a permanent divergence between
Linux and the shared ACPICA interpreter -- not a disaster, but
a headache for me when I don't really need more headaches.

thanks,
-Len
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [patch 1/1] acpi: cleanup u32 flags in spin_lock calls

[Andrew Morton]

"Brown, Len" <len.brown-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> wrote:
>
>  
> >Updated..
> 
> Andrew, Steven,
> 
> (and I'm sorry I have to bother you by asking this...)
> 
> Please acknowldge that you license this patch back to Intel
> according either license appearing at the top of the acpi files changed.

So acknowledged.

> Doing so means that we can apply this patch or a derivative of it "upstream"
> in the ACPICA core, which Linux shares with FreeBSD etc.

Understood.

> Not doing so means that your path is licensed as GPL only, and if
> I check it into Linux, then I have created a permanent divergence between
> Linux and the shared ACPICA interpreter -- not a disaster, but
> a headache for me when I don't really need more headaches.

-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [patch 1/1] acpi: cleanup u32 flags in spin_lock calls

[Steven Rostedt]

On Wed, 4 Jan 2006, Brown, Len wrote:

>
> >Updated..
>
> Andrew, Steven,
>
> (and I'm sorry I have to bother you by asking this...)
>
> Please acknowldge that you license this patch back to Intel
> according either license appearing at the top of the acpi files changed.

No problem.  I license that patch back to Intel.

Steven Rostedt.

-- Steve

>
> Doing so means that we can apply this patch or a derivative of it "upstream"
> in the ACPICA core, which Linux shares with FreeBSD etc.
>
> Not doing so means that your path is licensed as GPL only, and if
> I check it into Linux, then I have created a permanent divergence between
> Linux and the shared ACPICA interpreter -- not a disaster, but
> a headache for me when I don't really need more headaches.
>
> thanks,
> -Len
>
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html