Right, that's the only sane way to do it, I just didn't remember off
hand what was said in the OF spec :-)
3.2.2.1.2 Property values
The property-encoding format is independent of hardware byte order and
alignment characteristics. The encoded byte order is well-defined (in
particular,
There was no way to set mapped memory as cacheable if the memory
is not managed by Linux kernel. It's not rare in real system to
allocate some dedicated memory to a certain application which is not
managed by kernel and then mmap'ed the memory to the application.
The memory should be cacheable
On Thu, Nov 26, 2009 at 03:36:56PM +1100, Benjamin Herrenschmidt wrote:
On Tue, 2009-11-24 at 22:00 +0100, Segher Boessenkool wrote:
Sure, the memory controllers don't do coherency. I'm slightly worried
about two things:
1) Will the generic code use M=0 as well? Is it a problem if it
Benjamin Herrenschmidt b...@kernel.crashing.org wrote on 24/11/2009 04:12:43:
On Tue, 2009-11-10 at 10:00 +0100, Joakim Tjernlund wrote:
JFFS2 uses lesser compression ratio and inflate always
ends up in copy direct from output case.
This patch tries to optimize the direct copy procedure.
eHEA driver fails to initialize on a power6 box while booting
20091125 next(f3645ca..). Following are the messages which gets
logged during failure.
Unable to handle kernel paging request for data at address 0x409d0148e8e40018
Faulting instruction address: 0xc003c0cc
Oops: Kernel access
On Thu, 2009-11-26 at 09:17 +0100, Gabriel Paubert wrote:
They should hopefully... as long as you don't rely on the reservation
blowing as a result of a DMA write.
Hmm, this really depends on whether the DMA transfers generate bus cycles
that require coherency or not. Not the other way
On Thu, 2009-11-26 at 09:30 +0100, Joakim Tjernlund wrote:
I'm not sure its going to work to use get_unaligned() like that on all
archs .. it might be definitely something to discuss on some more
appropriate mailing list.
Oh, why not? Is that because I am using it wrongly or because
Benjamin Herrenschmidt b...@kernel.crashing.org wrote on 26/11/2009 09:46:58:
On Thu, 2009-11-26 at 09:30 +0100, Joakim Tjernlund wrote:
I'm not sure its going to work to use get_unaligned() like that on all
archs .. it might be definitely something to discuss on some more
appropriate
On 11/26/2009 12:22 AM, Bernhard Walle wrote:
M. Mohan Kumar schrieb:
Reserve memory for kdump kernel within RMO region
When the kernel size exceeds 32MB(observed with some distros), memory
for kdump kernel can not be reserved as kdump kernel base is assumed to
be 32MB always. When the kernel
On Wed, Nov 25, 2009 at 03:11:57PM -0700, Grant Likely wrote:
On Wed, Nov 25, 2009 at 1:41 PM, Torsten Fleischer
to-fleisc...@t-online.de wrote:
On Wen, Nov 25, 2009 at 01:33:57 Grant Likely wrote:
Thanks. However, there needs to be a proper description of what this
patch does to go in
On Tue, Nov 24, 2009 at 01:17:41AM -0700, Grant Likely wrote:
Nothing much to say here other than mostly mechanical merging of OF
support code. Some of it remains a little ugly, but I'm taking the
approach of merging the code first, and refactoring it second.
I've pushed this series out to
On 11/26/2009 01:16 PM, Alexander Graf wrote:
Currently userspace has no chance to find out which virtual address space we're
in and resolve addresses. While that is a big problem for migration, it's also
unpleasent when debugging, as gdb and the monitor don't work on virtual
addresses.
This
Avi Kivity wrote:
On 11/26/2009 01:16 PM, Alexander Graf wrote:
Currently userspace has no chance to find out which virtual address
space we're
in and resolve addresses. While that is a big problem for migration,
it's also
unpleasent when debugging, as gdb and the monitor don't work on
On 11/26/2009 02:46 PM, Alexander Graf wrote:
Please avoid unnamed unions in user-visible headers - they're a gcc
extension.
Yes, we have them elsewhere, but let's not add to the pile.
I'm open to scalable suggestions that don't break existing userspace code.
If I name the union now,
Avi Kivity wrote:
On 11/26/2009 02:46 PM, Alexander Graf wrote:
Please avoid unnamed unions in user-visible headers - they're a gcc
extension.
Yes, we have them elsewhere, but let's not add to the pile.
I'm open to scalable suggestions that don't break existing userspace
code.
If I
On 11/26/2009 03:16 PM, Alexander Graf wrote:
You can keep pvr out of the (named) union.
So we'd have
sregs.padded.ppc64.slb?
or sregs.u.ppc64.slb.
I don't see how that is an improvement.
Buildability takes precedence.
(an alternative is to drop the union, and add a
Hi,
I am messing about with the fsl-diu-fb.c which handles the display on mpc512x
platforms.
The display panels we are using provide EDID information and I would like to
use that to setup
the display modes etc. The current fsl-diu-fb.c is hard coding display modes
into the driver.
I have
Benjamin Herrenschmidt wrote:
On Sun, 2009-11-22 at 23:01 +0100, Albert Herranz wrote:
+/memreserve/ 0x0180 0xe80; /* memory hole (includes I/O area) */
+/memreserve/ 0x1000 0x0004000; /* DSP RAM */
Weird layout... nothing you can do about I suppose.
Out of curiosity, what
Forgot the patch.
Kári Davíðsson wrote:
Hi,
I am messing about with the fsl-diu-fb.c which handles the display on mpc512x
platforms.
The display panels we are using provide EDID information and I would like to
use that to setup
the display modes etc. The current fsl-diu-fb.c is hard coding
Benjamin Herrenschmidt wrote:
On Wed, 2009-11-25 at 18:49 +0100, Segher Boessenkool wrote:
+/memreserve/ 0x0180 0xe80; /* memory hole (includes I/O area) */
Like others have said already, don't do this. If you need
a workaround, put it in the platform code.
+/memreserve/ 0x1000
Benjamin Herrenschmidt wrote:
On Wed, 2009-11-25 at 19:34 +0100, Albert Herranz wrote:
We need nobats (or a hack in the mmu_mapin_ram() code) because of the
discontiguous ram problem.
I would vote for a hack in mmu_mapin_ram() for now.
I'll cook that.
Cheers,
Ben.
Thanks,
Albert
Benjamin Herrenschmidt wrote:
On Tue, 2009-11-24 at 19:03 +0100, Albert Herranz wrote:
Segher Boessenkool wrote:
Add a config option GAMECUBE_COMMON to be used as a dependency for all
options common to the Nintendo GameCube and Wii video game consoles.
Maybe something like GAMECUBE_OR_WII
Benjamin Herrenschmidt wrote:
On Sun, 2009-11-22 at 23:01 +0100, Albert Herranz wrote:
Add support for using the USB Gecko adapter via the udbg facility on
the Nintendo GameCube and Wii video game consoles.
The USB Gecko is a 3rd party memory card interface adapter that provides
a EXI
Benjamin Herrenschmidt wrote:
On Sun, 2009-11-22 at 23:01 +0100, Albert Herranz wrote:
+static void flipper_pic_mask_and_ack(unsigned int virq)
+{
+int irq = virq_to_hw(virq);
+void __iomem *io_base = get_irq_chip_data(virq);
+
+clear_bit(irq, io_base + FLIPPER_IMR);
+
Benjamin Herrenschmidt wrote:
On Sun, 2009-11-22 at 16:28 -0700, Grant Likely wrote:
+unsigned int flipper_pic_get_irq(void)
+{
+ void __iomem *io_base = flipper_irq_host-host_data;
+ int irq;
+ u32 irq_status;
+
+ irq_status = in_be32(io_base + FLIPPER_ICR)
+
Benjamin Herrenschmidt wrote:
On Tue, 2009-11-24 at 18:09 +0100, Albert Herranz wrote:
I could use ppc_md.ioremap to duplicate ioremap except for the ioremap
ram check.
But calling the stock ioremap without modifying it is not possible
because it checks and bails out when ioremapping a region
Benjamin Herrenschmidt wrote:
On Sun, 2009-11-22 at 23:01 +0100, Albert Herranz wrote:
+static void hlwd_pic_mask_and_ack(unsigned int virq)
+{
+int irq = virq_to_hw(virq);
+void __iomem *io_base = get_irq_chip_data(virq);
+
+clear_bit(irq, io_base + HW_BROADWAY_IMR);
+
On Thu, Nov 26, 2009 at 13:12:04 Anton Vorontsov wrote:
[...]
Ah. I understand what you're doing now. Hmmm. This approach
concerns me because it relies on firmware or platform code to get CS
gpios set up properly before the driver is probed.
Yes, that was said at the very beginning of
On Thu, Nov 26, 2009 at 5:12 AM, Anton Vorontsov
avoront...@ru.mvista.com wrote:
On Wed, Nov 25, 2009 at 03:11:57PM -0700, Grant Likely wrote:
On Wed, Nov 25, 2009 at 1:41 PM, Torsten Fleischer
to-fleisc...@t-online.de wrote:
On Wen, Nov 25, 2009 at 01:33:57 Grant Likely wrote:
Thanks.
On Thu, Nov 26, 2009 at 10:27 AM, Torsten Fleischer
to-fleisc...@t-online.de wrote:
On Thu, Nov 26, 2009 at 13:12:04 Anton Vorontsov wrote:
[...]
Ah. I understand what you're doing now. Hmmm. This approach
concerns me because it relies on firmware or platform code to get CS
gpios set
On Thu, Nov 26, 2009 at 11:16:34AM -0700, Grant Likely wrote:
[...]
The spi-cs-high property is defined in
Documentation/powerpc/dts-bindings/spi-bus.txt, but it definitely was
a mistake
Yup.
Currently the spi-cs-high property is parsed in the
of_register_spi_devices() function, but the CS
On Thu, Nov 26, 2009 at 11:41 AM, Anton Vorontsov
avoront...@ru.mvista.com wrote:
On Thu, Nov 26, 2009 at 11:16:34AM -0700, Grant Likely wrote:
[...]
The spi-cs-high property is defined in
Documentation/powerpc/dts-bindings/spi-bus.txt, but it definitely was
a mistake
Yup.
Currently the
On Thu, Nov 26, 2009 at 11:50:05AM -0700, Grant Likely wrote:
On Thu, Nov 26, 2009 at 11:41 AM, Anton Vorontsov
avoront...@ru.mvista.com wrote:
On Thu, Nov 26, 2009 at 11:16:34AM -0700, Grant Likely wrote:
[...]
The spi-cs-high property is defined in
On Thu, Nov 26, 2009 at 12:01 PM, Anton Vorontsov
avoront...@ru.mvista.com wrote:
On Thu, Nov 26, 2009 at 11:50:05AM -0700, Grant Likely wrote:
On Thu, Nov 26, 2009 at 11:41 AM, Anton Vorontsov
avoront...@ru.mvista.com wrote:
On Thu, Nov 26, 2009 at 11:16:34AM -0700, Grant Likely wrote:
M. Mohan Kumar schrieb:
On 11/26/2009 12:22 AM, Bernhard Walle wrote:
M. Mohan Kumar schrieb:
Reserve memory for kdump kernel within RMO region
When the kernel size exceeds 32MB(observed with some distros), memory
for kdump kernel can not be reserved as kdump kernel base is assumed to
be
Hi,
This is version 6 of patch series that provides a framework to choose the state
a pseries CPU must be put to when it is offlined.
Previous versions can be found here:
Version 5: http://lkml.org/lkml/2009/10/30/6
Version 4: http://lkml.org/lkml/2009/10/9/59
Version 3:
From: Gautham R Shenoy e...@in.ibm.com
Currently the cpu-allocation/deallocation on pSeries is a
two step process from the Userspace.
- Set the indicators and update the device tree by writing to the sysfs
tunable probe during allocation and release during deallocation.
- Online / Offline the
From: Gautham R Shenoy e...@in.ibm.com
Currently the cpu-allocation/deallocation process comprises of two steps:
- Set the indicators and to update the device tree with DLPAR node
information.
- Online/offline the allocated/deallocated CPU.
This is achieved by writing to the sysfs tunables
On Thu, 2009-11-26 at 16:09 +0100, Albert Herranz wrote:
Are the above OHCI and EHCI special ? If not, there's an existing
binding for that sort of thing, which btw requires properties to
indicate the endianness of the registers and in-memory data structures
etc...
They are a bit
Good point. I can't even guarantee that the kernel will work reliably
with nobats :-) At least you really want the kernel .text to be fully
covered by an IBAT.
It works with nobats.
But does it work -reliably- ? :-)
I haven't looked at that for years, but we used to have a subtle
On Thu, 2009-11-26 at 16:28 +0100, Albert Herranz wrote:
Benjamin Herrenschmidt wrote:
On Sun, 2009-11-22 at 23:01 +0100, Albert Herranz wrote:
Add support for using the USB Gecko adapter via the udbg facility on
the Nintendo GameCube and Wii video game consoles.
The USB Gecko is a 3rd
On Thu, 2009-11-26 at 16:30 +0100, Albert Herranz wrote:
Benjamin Herrenschmidt wrote:
On Sun, 2009-11-22 at 23:01 +0100, Albert Herranz wrote:
+static void flipper_pic_mask_and_ack(unsigned int virq)
+{
+ int irq = virq_to_hw(virq);
+ void __iomem *io_base =
On Thu, 2009-11-26 at 16:33 +0100, Albert Herranz wrote:
Benjamin Herrenschmidt wrote:
On Sun, 2009-11-22 at 16:28 -0700, Grant Likely wrote:
+unsigned int flipper_pic_get_irq(void)
+{
+ void __iomem *io_base = flipper_irq_host-host_data;
+ int irq;
+ u32 irq_status;
On Thu, 2009-11-26 at 16:35 +0100, Albert Herranz wrote:
Benjamin Herrenschmidt wrote:
On Tue, 2009-11-24 at 18:09 +0100, Albert Herranz wrote:
I could use ppc_md.ioremap to duplicate ioremap except for the ioremap
ram check.
But calling the stock ioremap without modifying it is not
On Thu, 2009-11-26 at 16:42 +0100, Albert Herranz wrote:
Benjamin Herrenschmidt wrote:
On Sun, 2009-11-22 at 23:01 +0100, Albert Herranz wrote:
+static void hlwd_pic_mask_and_ack(unsigned int virq)
+{
+ int irq = virq_to_hw(virq);
+ void __iomem *io_base = get_irq_chip_data(virq);
So what you are saying is that if the kernel has mapped a physical
page as cacheable while user application is trying to map it as
non-cacheable, there will be machine checks and checkstops rather than
just performance drop? This is new to me. Could you elaborate a bit?
If some data is in
Benjamin Herrenschmidt wrote:
On Thu, 2009-11-26 at 16:09 +0100, Albert Herranz wrote:
Are the above OHCI and EHCI special ? If not, there's an existing
binding for that sort of thing, which btw requires properties to
indicate the endianness of the registers and in-memory data structures
You're right, it's not, but makes merging less complex, and then I
can
refactor properly.
Still, make them __be32 at least
There is no alignment guarantee at all either, better make it all u8
and use accessor functions everywhere.
Segher
___
Benjamin Herrenschmidt wrote:
Good point. I can't even guarantee that the kernel will work reliably
with nobats :-) At least you really want the kernel .text to be fully
covered by an IBAT.
It works with nobats.
But does it work -reliably- ? :-)
It does AFAICT. My Wii is a 24x7 linux
On Thu, 2009-11-26 at 22:36 +0100, Segher Boessenkool wrote:
You're right, it's not, but makes merging less complex, and then I
can
refactor properly.
Still, make them __be32 at least
There is no alignment guarantee at all either, better make it all u8
and use accessor functions
Maybe using FLIPPER (or GAMECUBE_FLIPPER) instead of GAMECUBE_COMMON
is a good name?
I'd prefer to not use a name that implies a specific hardware to
describe two (mostly) similar but different hardwares.
Hollywood is 100% compatible to Flipper though.
+/*
+ * Each interrupt has a
We need it as it currently doesn't match with the default bus ids.
Should I introduce a .type property matching any of those above in
the soc node, and get rid of the explicit bus probe?
You don't need any fake bus as far as I can see, just probe the devices
you want.
Segher
Add support for the BootMii 'mini' firmware replacement for the
Starlet processor.
'mini' is an open source IOS replacement written from scratch by
Team Twiizers.
It's not a replacement, it doesn't have any of the same
functionality.
I didn't know 'replacement' had that semantics.
It's
Am 26.11.2009 um 16:24 schrieb Alexander Graf ag...@suse.de:
Currently userspace has no chance to find out which virtual address
space we're
in and resolve addresses. While that is a big problem for migration,
it's also
unpleasent when debugging, as gdb and the monitor don't work on
+#ifdef CONFIG_STARLET_MINI
+
+#define HW_RESETS_OF_COMPATIBLEnintendo,hollywood-resets
+#define HW_GPIO_ALIAShw_gpio
This should be unconditional now I think? You access the hardware
directly.
Yes, at this stage direct hardware should be possible, but only if
'mini' support is
Segher Boessenkool wrote:
Maybe using FLIPPER (or GAMECUBE_FLIPPER) instead of GAMECUBE_COMMON
is a good name?
I'd prefer to not use a name that implies a specific hardware to
describe two (mostly) similar but different hardwares.
Hollywood is 100% compatible to Flipper though.
No.
Segher Boessenkool wrote:
We need it as it currently doesn't match with the default bus ids.
Should I introduce a .type property matching any of those above in the
soc node, and get rid of the explicit bus probe?
You don't need any fake bus as far as I can see, just probe the devices
you
If you have only one interrupt controller, like here, you don't
need to refer to it _at all_ :-)
I think Linux requires that you do though. It might be a mistake on
our
part but heh ...
Linux doesn't require it; (old) Macs are like this, for example,
and that works fine. Oh and all Maple
+ xfb-start = 0x01698000; /* end-of-ram - xfb-size */
+ xfb-size = 0x168000;
XFB address isn't fixed on the hardware, and the kernel might
want to move it, and you can easily probe for it anyway. Remove
these last two properties please.
Ok but you
So what's your proposal then? Placing it within a fake func?
Just do a .S file :-)
Yeah. You might be able to do one that handles both GC and Wii,
maybe it's easier/clearer to keep them separate though.
Ouch. I wouldn't be surprised if those guys don't do cache coherency
in the bridge
+ soc {
It would be better to rename this as IMMR or the bus type. This node
doesn't actually describe the entire chip, but describes the internal
memory mapped registers.
I would really just call it flipper :-)
Yeah, I came to the same conclusion.
Since you're only doing 1:1
On Thu, 2009-11-26 at 22:38 +0100, Albert Herranz wrote:
Yup. The idea is to map the first 16MB of MEM1 with a BAT.
Mapping the whole 24MB with BATs may not be possible because we want the
framebuffer
in MEM1 for performance reasons.
How big is the fb ? We have plenty of BATs on these
+/memreserve/ 0x0180 0xe80; /* memory hole (includes I/O
area) */
+/memreserve/ 0x1000 0x0004000; /* DSP RAM */
Weird layout... nothing you can do about I suppose.
Out of curiosity, what is that DSP RAM ? Some actual DSP core
somewhere
in the IO chip setup to use memory
On Thu, 2009-11-26 at 23:15 +0100, Segher Boessenkool wrote:
If you have only one interrupt controller, like here, you don't
need to refer to it _at all_ :-)
I think Linux requires that you do though. It might be a mistake on
our
part but heh ...
Linux doesn't require it; (old)
BTW. If we want to play with clocks, maybe you should look at
my proposed binding for clocks and implementing the clk API :-)
There are no clocks that are configurable from the PowerPC side
(well, maybe things like the USB clocks, but we do not know how).
+ /* Team Twiizers'
This will probably break other platforms if
CONFIG_PPC_EARLY_DEBUG_USBGECKO
is set. In general, we try hard to make it possible to build generic
kernels for multiple systems, so it would be better to also add a
runtime check here.
No Arnd. The whole point of EARLY_DEBUG is that it is -known- to
+unsigned int flipper_pic_get_irq(void)
+{
+ void __iomem *io_base = flipper_irq_host-host_data;
+ int irq;
+ u32 irq_status;
+
+ irq_status = in_be32(io_base + FLIPPER_ICR)
+in_be32(io_base + FLIPPER_IMR);
+ if (irq_status == 0)
+
+static void hlwd_pic_mask_and_ack(unsigned int virq)
+{
+ int irq = virq_to_hw(virq);
+ void __iomem *io_base = get_irq_chip_data(virq);
+
+ clear_bit(irq, io_base + HW_BROADWAY_IMR);
+ set_bit(irq, io_base + HW_BROADWAY_ICR);
+}
Same comment as with flipper. BTW. It
Sure, the memory controllers don't do coherency. I'm slightly
worried
about two things:
1) Will the generic code use M=0 as well? Is it a problem if it
doesn't?
We can make it not do it.
2) Do lwarx. etc. work in M=0?
They should hopefully... as long as you don't rely on the reservation
Segher Boessenkool wrote:
So what is at d000 ?
0c00 is the flipper-compatible stuff
0d00 is the hollywood new devices
0d80 is the same as part of 0d00, but with some extra bits
sometimes.
Also, when in Wii native mode, stuff like EXI, SI and AI (which is
The usbgecko is hotplugable and hotswappable.
But as this is mostly a developer feature, not normaly used by end
users, I think that we can just let it be as it is: autodetect it
on boot (now probing for it instead of using information from the
device tree).
If you unplug it later it causes
They are a bit special because registers are in reverse little
endian format,
must be written in 32-bit chunks, and (all things point to) they
have hardware bugs.
Well.. first what is reverse little endian ? :-) Big endian ?
Nah. Little-endian, with a 32-bit bus swizzle. This is not the
There you can find the hardware interface that supports the IPC
mechanism.
It is made up of a pair of registers to pass data between the
processors and a
pair of control/flags registers.
The hardware can interrupt the PowerPC side when there is data
available for it.
Ok. So the right way
On Thu, 2009-11-26 at 23:54 +0100, Segher Boessenkool wrote:
No Ben. The whole point of EARLY_DEBUG is that it _always works_,
because
it is such trivial code. Don't break that please, or we'll be forced to
add a REALLY_EARLY_DEBUG instead :-)
I do tend to agree but heh... temptation to
From: Segher Boessenkool seg...@kernel.crashing.org
Date: Thu, 26 Nov 2009 22:36:41 +0100
You're right, it's not, but makes merging less complex, and then I can
refactor properly.
Still, make them __be32 at least
There is no alignment guarantee at all either, better make it all u8
and use
On Fri, 2009-11-27 at 00:00 +0100, Segher Boessenkool wrote:
+unsigned int flipper_pic_get_irq(void)
+{
+ void __iomem *io_base = flipper_irq_host-host_data;
+ int irq;
+ u32 irq_status;
+
+ irq_status = in_be32(io_base + FLIPPER_ICR)
+
Maybe using FLIPPER (or GAMECUBE_FLIPPER) instead of
GAMECUBE_COMMON
is a good name?
I'd prefer to not use a name that implies a specific hardware to
describe two (mostly) similar but different hardwares.
Hollywood is 100% compatible to Flipper though.
No. There's no ARAM for example :)
We need it as it currently doesn't match with the default bus ids.
Should I introduce a .type property matching any of those above
in the
soc node, and get rid of the explicit bus probe?
You don't need any fake bus as far as I can see, just probe the
devices
you want.
But it's way
Yup. The idea is to map the first 16MB of MEM1 with a BAT.
Mapping the whole 24MB with BATs may not be possible because we
want the framebuffer
in MEM1 for performance reasons.
How big is the fb ?
A bit more than a megabyte, something like that.
We have plenty of BATs on these things...
If you have only one interrupt controller, like here, you don't
need to refer to it _at all_ :-)
I think Linux requires that you do though. It might be a mistake on
our
part but heh ...
Linux doesn't require it; (old) Macs are like this, for example,
and that works fine. Oh and all Maple
On Fri, 2009-11-27 at 01:16 +0100, Segher Boessenkool wrote:
In all code I have done for the XFB, I map it like any other RAM and
dcbst it after writing to it. Maybe that is slower though, WIMG=0100
might be better. Dunno.
Well, it depends also what you want to do with it. If you want to
Li Yang writes:
That's my concern too. But after all mmap without O_SYNC on I/O
devices should be deprecated.
It should? Why?
Shouldn't the onus rather be on those proposing an incompatible change
to the kernel ABI, such as this is, to show why the change is
absolutely essential?
A
Li Yang writes:
There was no way to set mapped memory as cacheable if the memory
is not managed by Linux kernel. It's not rare in real system to
allocate some dedicated memory to a certain application which is not
managed by kernel and then mmap'ed the memory to the application.
The memory
On Wed, 2009-11-18 at 17:05 +, Mel Gorman wrote:
diff --git a/arch/powerpc/platforms/Kconfig b/arch/powerpc/platforms/Kconfig
index 04a8061..a82c470 100644
--- a/arch/powerpc/platforms/Kconfig
+++ b/arch/powerpc/platforms/Kconfig
@@ -52,9 +52,9 @@ config PPC_UDBG_BEAT
default n
Oops, stupid compile bug in the !CONFIG_PPC_SUBPAGE_PROT case with the
last version. Fixed below.
Fix bug in pagetable cache cleanup with CONFIG_PPC_SUBPAGE_PROT
Commit a0668cdc154e54bf0c85182e0535eea237d53146 cleans up the handling
of kmem_caches for allocating various levels of pagetables.
Signed-off-by: Alexey Dobriyan adobri...@gmail.com
---
drivers/macintosh/via-pmu.c | 160 +---
1 file changed, 91 insertions(+), 69 deletions(-)
--- a/drivers/macintosh/via-pmu.c
+++ b/drivers/macintosh/via-pmu.c
@@ -36,6 +36,7 @@
#include
86 matches
Mail list logo
