m68k/for-2.6.34

m68k/for-2.6.34

[Geert Uytterhoeven]

I added the following to the m68k for-next branch, destined for 2.6.34:

 Finn Thain (13):
      mac68k: cleanup
      mac68k: rework SWIM platform device
      pmac-zilog: cleanup
      pmac-zilog: add platform driver
      mac68k: replace mac68k SCC code with platform device
      mac68k: move mac_esp platform device
      mac68k: move macsonic and macmace platform devices
      fbdev: mac_var_to_mode() fix
      valkyriefb: various fixes
      mac68k: start CUDA early
      fbdev: add some missing mac modes
      macfb: cleanup
      macfb: fix 24-bit visual and stuff

Geert Uytterhoeven (2):
      ataflop: Killl warning about unused variable flags
      m68k: Eliminate unused variable in page_to_phys()

Julia Lawall (1):
      m68k: Use DIV_ROUND_CLOSEST

Maxim Kuvyrkov (2):
      m68k: Fix asm/swab.h for ColdFire
      m68k: Switch to generic siginfo layout

Peter Huewe (1):
      m68k: vme_scc - __init annotations

Philippe De Muyter (2):
      m68k: Allow ioremapping top of memory
      m68k{,nommu}/h8300: Remove obsolete comment about map_chunk

If there's anything else in m68k-queue (or anyplace else :-) you
desperately want in 2.6.34, please let me know.

Should I add the NPTL support for m68k and m68knommu, or shall I wait
for 2.6.35?
I'd also like to `get rid' of the ARAnyM support by getting it
mainlined, for 2.6.35 (if I find time). Who's gonna sign off those
patches?

Thanks!

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

Re: m68k/for-2.6.34

[Maxim Kuvyrkov]

On 2/1/10 11:12 PM, Geert Uytterhoeven wrote:
...
> Should I add the NPTL support for m68k and m68knommu, or shall I wait
> for 2.6.35?

Notwithstanding the bias, I think you should merge the NPTL support. 
The NPTL changes don't touch any of the existing functionality, they 
only add the new syscalls, so the risk of breaking something is negligible.

-- 
Maxim Kuvyrkov
CodeSourcery
maxim@codesourcery.com
(650) 331-3385 x724
_______________________________________________
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev

Re: m68k/for-2.6.34

[Geert Uytterhoeven]

On Thu, Feb 4, 2010 at 21:54, Maxim Kuvyrkov <maxim@codesourcery.com> wrote:
> On 2/1/10 11:12 PM, Geert Uytterhoeven wrote:
> ...
>>
>> Should I add the NPTL support for m68k and m68knommu, or shall I wait
>> for 2.6.35?
>
> Notwithstanding the bias, I think you should merge the NPTL support. The
> NPTL changes don't touch any of the existing functionality, they only add
> the new syscalls, so the risk of breaking something is negligible.

OK for me. Greg, OK for m68knommu, too?

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

Re: m68k/for-2.6.34

[Greg Ungerer]

On 02/06/2010 07:44 PM, Geert Uytterhoeven wrote:
> On Thu, Feb 4, 2010 at 21:54, Maxim Kuvyrkov<maxim@codesourcery.com>  wrote:
>> On 2/1/10 11:12 PM, Geert Uytterhoeven wrote:
>> ...
>>>
>>> Should I add the NPTL support for m68k and m68knommu, or shall I wait
>>> for 2.6.35?
>>
>> Notwithstanding the bias, I think you should merge the NPTL support. The
>> NPTL changes don't touch any of the existing functionality, they only add
>> the new syscalls, so the risk of breaking something is negligible.
>
> OK for me. Greg, OK for m68knommu, too?

Yep, good for m68knommu too.

Regards
Greg


------------------------------------------------------------------------
Greg Ungerer  --  Principal Engineer        EMAIL:     gerg@snapgear.com
SnapGear Group, McAfee                      PHONE:       +61 7 3435 2888
8 Gardner Close,                            FAX:         +61 7 3891 3630
Milton, QLD, 4064, Australia                WEB: http://www.SnapGear.com
_______________________________________________
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev

Re: m68k/for-2.6.34

[Maxim Kuvyrkov]

On 2/1/10 11:12 PM, Geert Uytterhoeven wrote:
...
> If there's anything else in m68k-queue (or anyplace else :-) you
> desperately want in 2.6.34, please let me know.

Looking through the bug fixes I submitted while testing NPTL support, I 
noticed that I forgot the patches that address problems in signal 
handling for ColdFire.  Namely,

* Define sigcontext ABI for ColdFire
* Fix m68k-uclinux's rt_sigreturn trampoline

I just sent the updated patches against m68k/for-2.6.34 here 
<http://marc.info/?l=linux-m68k&m=126571455916199&w=2>.  Can we include 
these into 2.6.34?

Regards,

-- 
Maxim Kuvyrkov
CodeSourcery
maxim@codesourcery.com
(650) 331-3385 x724