On Fri, 2018-10-05 at 00:07 +0300, Mike Rapoport wrote:
> When a memblock allocation APIs are called with align = 0, the alignment is
> implicitly set to SMP_CACHE_BYTES.
>
> Replace all such uses of memblock APIs with the 'align' parameter explicitly
> set to SMP_CACHE_BYTES and stop implicit
On Wed, 2018-06-27 at 13:08 +1000, Michael Ellerman wrote:
> > I will rewrite patch 10/12 after Arnd's fixes and this series have all
> > made their way through both powerpc and m68k trees, and submit it
> > separately.
>
> drivers/macintosh is supposedly maintained by Ben, but I'm not sure
On Sun, 2018-06-10 at 21:12 +1200, Michael Schmitz wrote:
> Hi Geert,
Top posting, sorry ...
We are painting that bike shed with way too many coats..
We can keep the existing definitions, stick a comment on them stating
"obsolete" and use new number if/when needed.
Ben.
> Am 10.06.2018 um
On Sat, 2018-06-09 at 22:21 +1000, Finn Thain wrote:
> In anycase, the "v1" and "v2" scheme is obviously inadequate when you
> consider the range of m68k powerbook models. Also, consider the
> out-of-tree adaptation of via-pmu by the Nubus-PMac project, which has
> this ABI break:
>
> diff
On Tue, 2015-07-14 at 17:58 +1000, Finn Thain wrote:
Make use of arch_nvram_ops in device drivers so that the nvram_* function
exports can be removed.
Since they are no longer global symbols, rename the PPC32 nvram_*
functions appropriately.
Add the missing CONFIG_NVRAM test to imsttfb
On Mon, 2015-02-16 at 09:18 +0800, Yijing Wang wrote:
I tested this series on x86 (with or without ACPI).
Comments and tests are warmly welcome!
Can you push a public branch out rebased against mainline for us to pull
and test please ?
Hi Lorenzo, I rebased the series and you could
On Tue, 2011-12-13 at 00:34 +1100, Finn Thain wrote:
On Mon, 12 Dec 2011, Benjamin Herrenschmidt wrote:
Any chance you can test this patch ? I would not be surprised if it
broke m68k since I had to do some of the changes in there blind, so
let me know... with this, I can again suspend
On Mon, 2011-12-12 at 10:48 +1100, Benjamin Herrenschmidt wrote:
Any chance you can test this patch ? I would not be surprised if it
broke m68k since I had to do some of the changes in there blind,
so let me know... with this, I can again suspend/resume properly on
a Pismo while using
On Thu, 2011-12-08 at 22:26 +1100, Finn Thain wrote:
Maybe the modem wants a transition on DTR or similar, but it hasn't had
time to initialise when that happens during SCC resumption.
If so, calling pmz_shutdown() then pmz_startup() from the tail of
pmz_resume() without delay should
On Wed, 2011-12-07 at 14:49 +1100, Finn Thain wrote:
On most 68k Macs the SCC IRQ is an autovector interrupt and cannot be
masked. This can be a problem when pmac_zilog starts up.
Thanks. I'll test it on a powermac or two and will merge it via the
powerpc -next tree if it works out allright.
On Wed, 2011-12-07 at 14:49 +1100, Finn Thain wrote:
On most 68k Macs the SCC IRQ is an autovector interrupt and cannot be
masked. This can be a problem when pmac_zilog starts up.
For example, the serial debugging code in arch/m68k/kernel/head.S may be
used beforehand. It disables the SCC
On Thu, 2011-12-08 at 15:20 +1100, Benjamin Herrenschmidt wrote:
So basic operations seem to work, I've applied the patch to
powerpc-next.
However, the internal modem on my Pismo powerbook doesn't appear to
survive suspend/resume. I'll dig into that and merge a fixup patch asap.
BTW. I
Removing ifdefs makes the changes more invasive and the suspend/resume
code then has to be addressed, which I've avoided.
The suspend/resume code path can't be tested on m68k macs and the common
code paths I can't easily test on a powermac.
This patch should not be needed because the
On Thu, 2011-11-24 at 14:56 +, Alan Cox wrote:
This patch has been tested on a variety of m68k Macs but no
PowerMacs.
I am re-sending this patch Cc linux-serial. It still needs a
suitable ack
so that Geert can push it through his tree.
Given the change should work for all
On Thu, 2011-11-24 at 15:28 +, David Laight wrote:
On most 68k Macs the SCC IRQ is an autovector interrupt and cannot be
masked. This can be a problem when pmac_zilog starts up.
Wouldn't this also happen if the interrupt were shared?
Hopefully nothing vaguely modern uses the borked
which may also want to use this macro.
For arch/powerpc:
Acked-by: Benjamin Herrenschmidt b...@kernel.crashing.org
(Sorry for catching up late)
Cheers,
Ben.
diff --git a/arch/powerpc/include/asm/atomic.h
b/arch/powerpc/include/asm/atomic.h
index b8f152e..906f49a 100644
--- a/arch/powerpc
On Mon, 2011-02-21 at 14:30 +1030, Rusty Russell wrote:
Except that .long is 32-bit on ppc64 :-( You need .llong for 64-bit.
OK, all options suck. Do we want the workaround or not?
The only sane thing I can see is make sure that such structures that
we put into sections arrays like that are
On Tue, 2010-01-19 at 16:21 +0900, Paul Mundt wrote:
IE. I'd rather have them all duplicated into real syscalls than some of
them only in socketcall and some on both since that will make any kind
of userspace transition even more hellish.
Presumably you're going to have to support both
On Thu, 2010-01-14 at 09:33 +, Russell King wrote:
On ARM, we used to use socketcall exclusively. We've since added all
the direct socket and IPC calls to our syscall table as part of the
big EABI shakeup. They certainly get used on EABI, whereas OABI has
a choice.
They were made
On Wed, 2010-01-13 at 20:28 -0800, David Miller wrote:
Anything happening here ? We're getting that warning on ppc too
despite
the fact that we use socketcall like x86... Should checksyscall be
made
smarter or the syscall just removed from x86 ? :-)
I think it's better to trap directly
On Wed, 2009-11-04 at 00:46 +1100, Finn Thain wrote:
The valkyriefb driver needs the CUDA to work in order to set the video
mode at boot. Initialising the device earlier, and bring the m68k code
closer to the powermac code.
Signed-off-by: Finn Thain fth...@telegraphics.com.au
Hi Finn !
On Wed, 2009-11-04 at 00:40 +1100, Finn Thain wrote:
Remove the old 68k Mac serial port code and a lot of related cruft. Add
platform driver support to the pmac-zilog driver, putting the powermac-
specific bits inside #ifdef CONFIG_PPC_PMAC. Add new platform devices to
mac68k.
Tested on
,
- Kill rtc-ppc, as rtc-generic offers the same functionality in a more
generic way, and supports autoloading through udev.
Signed-off-by: Geert Uytterhoeven geert.uytterhoe...@sonycom.com
Acked-By: David Woodhouse david.woodho...@intel.com
Acked-by: Benjamin Herrenschmidt b
23 matches
Mail list logo
