* Re: [RFC][PATCH] Kexec support for PPC440x
From: Suzuki Poulose @ 2011-06-02 7:30 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linux ppc dev, Sebastian Andrzej Siewior,
kexec@lists.infradead.org, lkml
In-Reply-To: <1306999551.29297.57.camel@pasglop>
On 06/02/11 12:55, Benjamin Herrenschmidt wrote:
> On Tue, 2011-05-31 at 17:15 +0200, Sebastian Andrzej Siewior wrote:
>> Suzuki Poulose wrote:
>>> Index: powerpc/arch/powerpc/kernel/44x_kexec_mapping.S
>>> ===================================================================
>>> --- /dev/null
>>> +++ powerpc/arch/powerpc/kernel/44x_kexec_mapping.S
>> ....
>>
>>> + *
>>> + */
>>> + bl nxtins /* Find our address */
>>> +nxtins: mflr r5 /* Make it accessible */
>>
>> Please don't mix labels and instructions.
>
> With proper indent it's fine as long as he uses numerical relative
> labels which should be the case here. For example, the above, it should
> look like:
>
> bl 1f
> 1: mflr r5
>
>>> + tlbsx r23,0,r5 /* Find entry we are in */
>>
>> using tabs instead of spaces would make it look nice. Please also separate
>> the arguments of the instruction i.e.
>> tlbsx r23, 0, r5
>
> That's arguable. If you look at arch/powerpc, we tend not to separate
> the arguments ;-)
>
> Actually I used to, others didn't and I changed my own style.
>
>>> Index: powerpc/arch/powerpc/kernel/misc_32.S
>>> ===================================================================
>>> --- powerpc.orig/arch/powerpc/kernel/misc_32.S
>>> +++ powerpc/arch/powerpc/kernel/misc_32.S
>>> @@ -736,6 +736,28 @@ relocate_new_kernel:
>>> mr r5, r31
>>>
>>> li r0, 0
>>> +#elif defined(CONFIG_44x)&& !defined(CONFIG_47x)
>>> +
>>> + mr r29, r3
>>> + mr r30, r4
>>> + mr r31, r5
>>> +
>>> +#include "44x_kexec_mapping.S"
>>
>> The way you setup the 1:1 mapping should be close to what you are doing on
>> kernel entry. Isn't it possible to include the file here and in the entry
>> code?
>
> It should just not be #included, what about branching out instead ?
This code, i.e, relocate_new_kernel is copied into the control buffer, which will
get the first chance to execute before the purgatory. So we may not be able to
branch to the code, since we are executing this from a different address and we
would invalidate the mapping for the code except the control buffer.
Thanks
Suzuki
^ permalink raw reply
* Re: [RFC][PATCH] Kexec support for PPC440x
From: Benjamin Herrenschmidt @ 2011-06-02 7:25 UTC (permalink / raw)
To: Sebastian Andrzej Siewior
Cc: kexec@lists.infradead.org, Suzuki Poulose, linux ppc dev, lkml
In-Reply-To: <4DE50617.7090509@linutronix.de>
On Tue, 2011-05-31 at 17:15 +0200, Sebastian Andrzej Siewior wrote:
> Suzuki Poulose wrote:
> > Index: powerpc/arch/powerpc/kernel/44x_kexec_mapping.S
> > ===================================================================
> > --- /dev/null
> > +++ powerpc/arch/powerpc/kernel/44x_kexec_mapping.S
> ....
>
> > + *
> > + */
> > + bl nxtins /* Find our address */
> > +nxtins: mflr r5 /* Make it accessible */
>
> Please don't mix labels and instructions.
With proper indent it's fine as long as he uses numerical relative
labels which should be the case here. For example, the above, it should
look like:
bl 1f
1: mflr r5
> > + tlbsx r23,0,r5 /* Find entry we are in */
>
> using tabs instead of spaces would make it look nice. Please also separate
> the arguments of the instruction i.e.
> tlbsx r23, 0, r5
That's arguable. If you look at arch/powerpc, we tend not to separate
the arguments ;-)
Actually I used to, others didn't and I changed my own style.
> > Index: powerpc/arch/powerpc/kernel/misc_32.S
> > ===================================================================
> > --- powerpc.orig/arch/powerpc/kernel/misc_32.S
> > +++ powerpc/arch/powerpc/kernel/misc_32.S
> > @@ -736,6 +736,28 @@ relocate_new_kernel:
> > mr r5, r31
> >
> > li r0, 0
> > +#elif defined(CONFIG_44x) && !defined(CONFIG_47x)
> > +
> > + mr r29, r3
> > + mr r30, r4
> > + mr r31, r5
> > +
> > +#include "44x_kexec_mapping.S"
>
> The way you setup the 1:1 mapping should be close to what you are doing on
> kernel entry. Isn't it possible to include the file here and in the entry
> code?
It should just not be #included, what about branching out instead ?
Cheers,
Ben.
^ permalink raw reply
* Re: [RFC][PATCH] Kexec support for PPC440x
From: Suzuki Poulose @ 2011-06-02 6:34 UTC (permalink / raw)
To: Sebastian Andrzej Siewior; +Cc: kexec@lists.infradead.org, linux ppc dev, lkml
In-Reply-To: <4DE50617.7090509@linutronix.de>
On 05/31/11 20:45, Sebastian Andrzej Siewior wrote:
>
> Suzuki Poulose wrote:
>> Index: powerpc/arch/powerpc/kernel/44x_kexec_mapping.S
>> ===================================================================
>> --- /dev/null
>> +++ powerpc/arch/powerpc/kernel/44x_kexec_mapping.S
> ....
>
>> + *
>> + */
>> + bl nxtins /* Find our address */
>> +nxtins: mflr r5 /* Make it accessible */
>
> Please don't mix labels and instructions.
OK.
>
>> + tlbsx r23,0,r5 /* Find entry we are in */
>
> using tabs instead of spaces would make it look nice. Please also separate the arguments of the instruction i.e.
> tlbsx r23, 0, r5
Sure.
>
>
>> Index: powerpc/arch/powerpc/kernel/misc_32.S
>> ===================================================================
>> --- powerpc.orig/arch/powerpc/kernel/misc_32.S
>> +++ powerpc/arch/powerpc/kernel/misc_32.S
>> @@ -736,6 +736,28 @@ relocate_new_kernel:
>> mr r5, r31
>>
>> li r0, 0
>> +#elif defined(CONFIG_44x) && !defined(CONFIG_47x)
>> +
>> + mr r29, r3
>> + mr r30, r4
>> + mr r31, r5
>> +
>> +#include "44x_kexec_mapping.S"
>
> The way you setup the 1:1 mapping should be close to what you are doing on
> kernel entry.Isn't it possible to include the file here and in the entry
> code?
I will make this change and resend the patch.
Thanks
Suzuki
^ permalink raw reply
* Re: [RFT][PATCH 3.0] ssb: fix PCI(e) driver regression causing oops on PCI cards
From: Christian Kujau @ 2011-06-02 6:20 UTC (permalink / raw)
To: Rafał Miłecki
Cc: linux-wireless, linuxppc-dev, Andreas Schwab, b43-dev,
Michael Büsch
In-Reply-To: <BANLkTi=mbBiSOGbEZ4AEYqZgyvgW0oXKtw@mail.gmail.com>
On Thu, 2 Jun 2011 at 08:13, Rafał Miłecki wrote:
> John, I'm afraid more and more people get angry at me because of this ;)
Erm, I'm not angry at anyone :-) On the contrary, I'm happy about the fix
so quickly available!
Though I'm a bit afraid of the next git bisect session, as it might not be
so straightforward than this one...
Thanks to all involved,
Christian.
--
BOFH excuse #230:
Lusers learning curve appears to be fractal
^ permalink raw reply
* Re: 3.0-rc1: powerpc hangs at Kernel virtual memory layout
From: Christian Kujau @ 2011-06-02 6:16 UTC (permalink / raw)
To: Rafał Miłecki; +Cc: linux ppc dev, LKML
In-Reply-To: <BANLkTi=JRDrzn=-d8jVqZLPGtV1osa1eiw@mail.gmail.com>
On Thu, 2 Jun 2011 at 08:07, Rafał Miłecki wrote:
> 1) You didn't see (like Andres):
> Machine check in kernel mode.
> Caused by (from SRR1=149030): Transfer error ack signal
> Oops: Machine check, sig: 7 [#1]
> But, OK, maybe machine check requires something additional in kernel,
> I don't know...
>
> 2) You didn't see SSB messages
> This is confusing. You should see SSB messages that appear before my
> invalid read happens. Did you somehow disable most of the important
> logs, or sth? Having ssb messages and the end of hung boot would
> directly point you to ssb module.
BenH advised to boot with udbg-immortal and out came:
http://nerdbynature.de/bits/3.0-rc1/linux-3.0_powerpc_2.jpg
http://nerdbynature.de/bits/3.0-rc1/linux-3.0_powerpc_2.mp4
(watch it at very slow speed, as it's only 3sec long)
I've enabled[0] FB_NVIDIA and during normal booting the screen flickers
after the "... : fixmap" message and the screen clears and is filled again
from the top - maybe the messages would've been there if booted w/o the
framebuffer enabled.
Right now I'm happy that Ben's fix helped to get past this message, but
the system remains unsuable[1] with the latest -git, but more debugging
has to wait until tomorrow...
Thanks,
Christian.
[0] http://nerdbynature.de/bits/3.0-rc1/config-2.6.39.txt
[1] https://lkml.org/lkml/2011/6/2/6
--
BOFH excuse #230:
Lusers learning curve appears to be fractal
^ permalink raw reply
* Re: [RFT][PATCH 3.0] ssb: fix PCI(e) driver regression causing oops on PCI cards
From: Rafał Miłecki @ 2011-06-02 6:13 UTC (permalink / raw)
To: Andreas Schwab, linux-wireless, John W. Linville,
Michael Büsch, Christian Kujau
Cc: linuxppc-dev, Rafał Miłecki, b43-dev
In-Reply-To: <BANLkTinSdDZv7gshYfi4mK5N9K-E7vk3Yw@mail.gmail.com>
2011/6/1 Rafa=C5=82 Mi=C5=82ecki <zajec5@gmail.com>:
> 2011/6/1 Rafa=C5=82 Mi=C5=82ecki <zajec5@gmail.com>:
>> We were incorrectly executing PCIe specific workarounds on PCI cards.
>> This resulted in:
>> Machine check in kernel mode.
>> Caused by (from SRR1=3D149030): Transfer error ack signal
>> Oops: Machine check, sig: 7 [#1]
>
> John, I've tested this patch myself on my PCI BCM4318, including
> checking for 0xFFFFFFFF reads in MMIO dumps.
>
> The patch is correct, please take it for 3.0.
John, I'm afraid more and more people get angry at me because of this ;)
Christian Kujau confirmed this problem and fix.
--=20
Rafa=C5=82
^ permalink raw reply
* Re: 3.0-rc1: powerpc hangs at Kernel virtual memory layout
From: Rafał Miłecki @ 2011-06-02 6:07 UTC (permalink / raw)
To: Christian Kujau; +Cc: linux ppc dev, LKML
In-Reply-To: <alpine.DEB.2.01.1106011712270.21697@trent.utfs.org>
On Tue, 31 May 2011 at 16:50, Christian Kujau wrote:
> trying to boot 3.0-rc1 on powerpc32 only progresses until:
>
> =C2=A0 > Kernel virtual memory layout:
> =C2=A0 > =C2=A0 * 0xfffcf000..0xfffff000 =C2=A0: fixmap
The weird thing is that:
1) You didn't see (like Andres):
Machine check in kernel mode.
Caused by (from SRR1=3D149030): Transfer error ack signal
Oops: Machine check, sig: 7 [#1]
But, OK, maybe machine check requires something additional in kernel,
I don't know...
2) You didn't see SSB messages
This is confusing. You should see SSB messages that appear before my
invalid read happens. Did you somehow disable most of the important
logs, or sth? Having ssb messages and the end of hung boot would
directly point you to ssb module.
--=20
Rafa=C5=82
^ permalink raw reply
* Re: 3.0-rc1: powerpc hangs at Kernel virtual memory layout
From: Rafał Miłecki @ 2011-06-02 6:00 UTC (permalink / raw)
To: Christian Kujau; +Cc: linux ppc dev, LKML
In-Reply-To: <alpine.DEB.2.01.1106011712270.21697@trent.utfs.org>
2011/6/2 Christian Kujau <lists@nerdbynature.de>:
> On Tue, 31 May 2011 at 16:50, Christian Kujau wrote:
>> trying to boot 3.0-rc1 on powerpc32 only progresses until:
>>
>> =C2=A0 > Kernel virtual memory layout:
>> =C2=A0 > =C2=A0 * 0xfffcf000..0xfffff000 =C2=A0: fixmap
>
> After hours (and hours!) of git-bisecting, it said:
>
> -----------------------
> ccc7c28af205888798b51b6cbc0b557ac1170a49 is the first bad commit
> commit ccc7c28af205888798b51b6cbc0b557ac1170a49
> Author: Rafa=C5=82 Mi=C5=82ecki <zajec5@gmail.com>
> Date: =C2=A0 Fri Apr 1 13:26:52 2011 +0200
>
> =C2=A0 =C2=A0ssb: pci: implement serdes workaround
>
> =C2=A0 =C2=A0Signed-off-by: Rafa=C5=82 Mi=C5=82ecki <zajec5@gmail.com>
> =C2=A0 =C2=A0Signed-off-by: John W. Linville <linville@tuxdriver.com>
> -----------------------
I'm for the problem :(
Patch was already send yesterday, I've even CCed linuxppc-dev:
[RFT][PATCH 3.0] ssb: fix PCI(e) driver regression causing oops on PCI card=
s
--=20
Rafa=C5=82
^ permalink raw reply
* Re: [PATCH] Fix build warning of the defconfigs
From: Paul Mundt @ 2011-06-02 5:24 UTC (permalink / raw)
To: Wanlong Gao
Cc: linux-mips, david.woodhouse, linux-sh, paulus, gxt, sam, linux,
manuel.lauss, rientjes, mingo, vapier, arnd, u.kleine-koenig,
anton, linux-arm-kernel, linux-kernel, ralf, uclinux-dist-devel,
akpm, linuxppc-dev, hans-christian.egtvedt
In-Reply-To: <1306945763-6583-1-git-send-email-wanlong.gao@gmail.com>
On Thu, Jun 02, 2011 at 12:29:23AM +0800, Wanlong Gao wrote:
> RTC_CLASS is changed to bool.
> So value 'm' is invalid.
>
> Signed-off-by: Wanlong Gao <wanlong.gao@gmail.com>
> arch/sh/configs/titan_defconfig | 2 +-
Acked-by: Paul Mundt <lethal@linux-sh.org>
^ permalink raw reply
* Re: 3.0-rc1: powerpc hangs at Kernel virtual memory layout
From: Christian Kujau @ 2011-06-02 4:27 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: zajec5, linux ppc dev, LKML
In-Reply-To: <1306983467.29297.51.camel@pasglop>
On Thu, 2 Jun 2011 at 12:57, Benjamin Herrenschmidt wrote:
> Ok, thanks a lot, It looks rather trivial actually: That new workaround
> is PCIe specific but is called unconditionally, and will do bad things
> non-PCIe implementations.
OK, with your patch applied to Linus' latest git tree the machine
continues to boot. Also, with the latest tree, the "machine is stuck after
ide-cd init" problem[0] went away.
For this particular problem and patch, feel free to add:
Tested-by: Christian Kujau <lists@nerdbynature.de>
However, shortly after boot and loggin in to the box remotely, the bux did
not respond any more. I'm not sure if these are related to those SSB/PCIe
changes, but somehow I hope they are - bisecting those would take much
longer, as it's not an "instant" death:
* http://nerdbynature.de/bits/3.0-rc1/linux-3.0-rc1_stuck1.jpg
* http://nerdbynature.de/bits/3.0-rc1/linux-3.0-rc1_stuck2.jpg
This is what an OCR program made of it:
irq euent stamp: 185804850
hardirqs last enabled at (185904849): [<c04005b0>] _raw_spin_unlock_irqrestore+0x40/0x?e
hardirqs last disabled at (185904850): [<c00120b8>] reenable_mmu+0x24/0x78
Softirqs last enabled at (185892414): [<c000fe8c>] call_do_softirq+0x14/0x24
softirqs last disabled at (18589240?): [<c000fe8c>] call_do_softirq+0x14/0x24
NIP: e04005b4 LR: e04005b0 CTR: 00000000
REGS: ef92be10 TRHP: 0901 Not tainted (3.0.0-rel-00049-g1fa?b6a-dirtg)
MSB: 00009032 <EE.ME.IR.DR> CR: 42002084
TRSK = ef8d0000[38B] ’kuorker/0:2’ THREAD:
GPR00: c04005b0 ef92bec0 efBd0000 00000001
GPR08: 00000000 0b14aed0 0049a306 00030600
HIP [c01005b1] _rau_spin_unlock_irqrestore+0x44/0x?c
LR [c04005b0] _rau_spin_unlock_irqrestore+0x40/0x?c
Call Trace:
[ef92bec0] [c04005b0] _raw_spin_unlock_irqrestore+0x40/0x?c (unreliable)
[ef92bed0] [c029c504] flush_tu_ldisc+0x121/0x230
[ef92bf10] [c001c86c] process_one_uork+0x1c1/0x4cB
[ef92bfS0] [c004efac] worker_thread+0x1?8/0x3c1
[ef92bf90] [c0051148] kthread+0x81/0x88
[ef92hff0] [c0810390] kernel_thread+0x1c/0x68
XER: 20000000
ef92a000 ef8d0660 00000006 00000000 18614000 22002088
Instruction dump:
??? 93e1060c ?c9f23?B 38800001 90010011 4bc6e9a9 ?fc3i`3?8 4be61a69
?3e08080 11820021 1bc6b515 ?fe00124
B8c16008 ?c0803a6 83c1000c
Well, the picture is way better :-\
Thanks,
Christian.
[0] http://nerdbynature.de/bits/3.0-rc1/linux-3.0-rc1-cdrom.jpg
--
BOFH excuse #399:
We are a 100% Microsoft Shop.
^ permalink raw reply
* Re: 3.0-rc1: powerpc hangs at Kernel virtual memory layout
From: Christian Kujau @ 2011-06-02 3:06 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: zajec5, linux ppc dev, LKML
In-Reply-To: <1306983467.29297.51.camel@pasglop>
On Thu, 2 Jun 2011 at 12:57, Benjamin Herrenschmidt wrote:
> Ok, thanks a lot, It looks rather trivial actually: That new workaround
> is PCIe specific but is called unconditionally, and will do bad things
> non-PCIe implementations.
Indeed. This PowerBook G4 does not has PCIe, yet the whole SSB thingy gets
enabled in my .config somehow. Thanks for the quick fix, I tried to revert
ccc7c28af2... from Linus' current tree, but I had to rip out some more to
make it compile.
I'll try your fix in a minute and get back to you with those cdrom init
problems as well.
Thanks,
Christian.
--
BOFH excuse #166:
/pub/lunch
^ permalink raw reply
* Re: 3.0-rc1: powerpc hangs at Kernel virtual memory layout
From: Benjamin Herrenschmidt @ 2011-06-02 2:57 UTC (permalink / raw)
To: Christian Kujau, linville; +Cc: zajec5, linux ppc dev, LKML
In-Reply-To: <alpine.DEB.2.01.1106011712270.21697@trent.utfs.org>
On Wed, 2011-06-01 at 17:16 -0700, Christian Kujau wrote:
> On Tue, 31 May 2011 at 16:50, Christian Kujau wrote:
> > trying to boot 3.0-rc1 on powerpc32 only progresses until:
> >
> > > Kernel virtual memory layout:
> > > * 0xfffcf000..0xfffff000 : fixmap
>
> After hours (and hours!) of git-bisecting, it said:
>
> -----------------------
> ccc7c28af205888798b51b6cbc0b557ac1170a49 is the first bad commit
> commit ccc7c28af205888798b51b6cbc0b557ac1170a49
> Author: Rafał Miłecki <zajec5@gmail.com>
> Date: Fri Apr 1 13:26:52 2011 +0200
>
> ssb: pci: implement serdes workaround
>
> Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
> Signed-off-by: John W. Linville <linville@tuxdriver.com>
> -----------------------
Ok, thanks a lot, It looks rather trivial actually: That new workaround
is PCIe specific but is called unconditionally, and will do bad things
non-PCIe implementations.
John, care to send the patch below to Linus ASAP ? I could reproduce and
verify it fixes it. Thanks !
ssb: pci: Don't call PCIe specific workarounds on PCI cores
Otherwise it can/will crash....
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
diff --git a/drivers/ssb/driver_pcicore.c b/drivers/ssb/driver_pcicore.c
index 82feb34..eddf1b9 100644
--- a/drivers/ssb/driver_pcicore.c
+++ b/drivers/ssb/driver_pcicore.c
@@ -540,7 +540,8 @@ void ssb_pcicore_init(struct ssb_pcicore *pc)
ssb_pcicore_init_clientmode(pc);
/* Additional always once-executed workarounds */
- ssb_pcicore_serdes_workaround(pc);
+ if (dev->id.coreid == SSB_DEV_PCIE)
+ ssb_pcicore_serdes_workaround(pc);
/* TODO: ASPM */
/* TODO: Clock Request Update */
}
^ permalink raw reply related
* Re: [PATCH] Fix build warning of the defconfigs
From: Guan Xuetao @ 2011-06-02 9:49 UTC (permalink / raw)
To: Wanlong Gao
Cc: linux-mips, david.woodhouse, linux-sh, paulus, sam, linux,
manuel.lauss, rientjes, mingo, vapier, arnd, u.kleine-koenig,
anton, linux-arm-kernel, linux-kernel, ralf, lethal,
uclinux-dist-devel, akpm, linuxppc-dev, hans-christian.egtvedt
In-Reply-To: <1306945763-6583-1-git-send-email-wanlong.gao@gmail.com>
On Thu, 2011-06-02 at 00:29 +0800, Wanlong Gao wrote:
> RTC_CLASS is changed to bool.
> So value 'm' is invalid.
>
> Signed-off-by: Wanlong Gao <wanlong.gao@gmail.com>
> ---
> arch/arm/configs/davinci_all_defconfig | 2 +-
> arch/arm/configs/mxs_defconfig | 2 +-
> arch/arm/configs/netx_defconfig | 2 +-
> arch/arm/configs/viper_defconfig | 2 +-
> arch/arm/configs/xcep_defconfig | 2 +-
> arch/arm/configs/zeus_defconfig | 2 +-
> arch/avr32/configs/atngw100_mrmt_defconfig | 2 +-
> arch/blackfin/configs/CM-BF548_defconfig | 2 +-
> arch/mips/configs/mtx1_defconfig | 2 +-
> arch/powerpc/configs/52xx/pcm030_defconfig | 2 +-
> arch/powerpc/configs/ps3_defconfig | 2 +-
> arch/sh/configs/titan_defconfig | 2 +-
> arch/unicore32/configs/debug_defconfig | 2 +-
> 13 files changed, 13 insertions(+), 13 deletions(-)
>
> diff --git a/arch/unicore32/configs/debug_defconfig b/arch/unicore32/configs/debug_defconfig
> index b5fbde9..1c367f0 100644
> --- a/arch/unicore32/configs/debug_defconfig
> +++ b/arch/unicore32/configs/debug_defconfig
> @@ -168,7 +168,7 @@ CONFIG_LEDS_TRIGGER_HEARTBEAT=y
>
> # Real Time Clock
> CONFIG_RTC_LIB=m
> -CONFIG_RTC_CLASS=m
> +CONFIG_RTC_CLASS=y
>
> ### File systems
> CONFIG_EXT2_FS=m
I adjust this config option recently, and enable it with y.
So please just drop the modification in unicore32 config file.
Thanks & Regards.
Guan Xuetao
^ permalink raw reply
* Re: 3.0-rc1: powerpc hangs at Kernel virtual memory layout
From: Benjamin Herrenschmidt @ 2011-06-02 0:47 UTC (permalink / raw)
To: Christian Kujau; +Cc: zajec5, linux ppc dev, LKML
In-Reply-To: <alpine.DEB.2.01.1106011712270.21697@trent.utfs.org>
On Wed, 2011-06-01 at 17:16 -0700, Christian Kujau wrote:
> ccc7c28af205888798b51b6cbc0b557ac1170a49 is the first bad commit
> commit ccc7c28af205888798b51b6cbc0b557ac1170a49
> Author: Rafał Miłecki <zajec5@gmail.com>
> Date: Fri Apr 1 13:26:52 2011 +0200
>
> ssb: pci: implement serdes workaround
>
> Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
> Signed-off-by: John W. Linville <linville@tuxdriver.com>
> -----------------------
>
> When I reverted this one from the gi-bisected tree, the box continued to
> boot (until it got stuck again during IDE/CDROM init, but that may be a
> different story). I'l; try to revert this from a vanilla 3.0-rc1 and see
> if it helps
Thanks. I'll have a look later today. As for the IDE/CDROM init, have
you tried the very latest linus snapshot ? Does that still happens ?
What kind of error do you observe ?
There was some time during the 3.0 merge window process when interrupts
were broken on some PowerBooks, but that should be fixed now.
Cheers,
Ben.
^ permalink raw reply
* Re: 3.0-rc1: powerpc hangs at Kernel virtual memory layout
From: Christian Kujau @ 2011-06-02 0:16 UTC (permalink / raw)
To: LKML; +Cc: zajec5, linux ppc dev
In-Reply-To: <alpine.DEB.2.01.1105311644010.21697@trent.utfs.org>
On Tue, 31 May 2011 at 16:50, Christian Kujau wrote:
> trying to boot 3.0-rc1 on powerpc32 only progresses until:
>
> > Kernel virtual memory layout:
> > * 0xfffcf000..0xfffff000 : fixmap
After hours (and hours!) of git-bisecting, it said:
-----------------------
ccc7c28af205888798b51b6cbc0b557ac1170a49 is the first bad commit
commit ccc7c28af205888798b51b6cbc0b557ac1170a49
Author: Rafał Miłecki <zajec5@gmail.com>
Date: Fri Apr 1 13:26:52 2011 +0200
ssb: pci: implement serdes workaround
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
-----------------------
When I reverted this one from the gi-bisected tree, the box continued to
boot (until it got stuck again during IDE/CDROM init, but that may be a
different story). I'l; try to revert this from a vanilla 3.0-rc1 and see
if it helps
Thanks,
Christian.
Full gist-bisect-log: http://nerdbynature.de/bits/3.0-rc1/
> And then the system hangs, does not respond to keyboard (sysrq does not
> seem to work on this PowerBook G4). But after a while the system reboots
> itself, so I guess the machine panicked but did not print anything on the
> screen.
>
> Full messages (picture), config & (working) dmesg:
>
> http://nerdbynature.de/bits/3.0-rc1/
>
--
BOFH excuse #406:
Bad cafeteria food landed all the sysadmins in the hospital.
^ permalink raw reply
* Re: [PATCH 7/7] [v2] drivers/misc: introduce Freescale hypervisor management driver
From: Scott Wood @ 2011-06-01 22:24 UTC (permalink / raw)
To: Arnd Bergmann
Cc: greg, kumar.gala, linux-kernel, akpm, linux-console, linuxppc-dev,
Timur Tabi
In-Reply-To: <201106012340.14237.arnd@arndb.de>
On Wed, 1 Jun 2011 23:40:14 +0200
Arnd Bergmann <arnd@arndb.de> wrote:
> > +static long ioctl_dtprop(struct fsl_hv_ioctl_prop __user *p, int set)
> > +{
> > + struct fsl_hv_ioctl_prop param;
> > + char __user *upath, *upropname;
> > + void __user *upropval;
> > + char *path = NULL, *propname = NULL;
> > + void *propval = NULL;
> > + int ret = 0;
> > +
>
> I'm not convinced that an ioctl interface is the right way to work with
> device tree properties. A more natural way would be to export it as
> a file system, or maybe as a flattened device tree blob (the latter option
> would require changing the hypervisor interface, which might not be
> possible).
I wanted to have the hypervisor take an update dtb (we already have special
meta-properties for things like deletion as part of the hv config
mechanism). But others on the project wanted to keep it simple, and so
get/set property it was. :-/
It's unlikely to change at this point without a real need.
As for a filesystem interface, it's not a good match either. You can't
iterate over anything to read out the full tree from the hv. You can't
delete anything. You can't create empty nodes. The hv interface was meant
to enable some specific management actions, rather than to provide general
device tree access. This driver is a thin wrapper around the management
hcalls.
There would still be other ioctls needed for starting/stopping the
partition, etc.
> > +/**
> > + * fsl_hv_ioctl: ioctl main entry point
> > + */
> > +static long fsl_hv_ioctl(struct file *file, unsigned int cmd,
> > + unsigned long argaddr)
> > +{
> > + union fsl_hv_ioctl_param __user *arg =
> > + (union fsl_hv_ioctl_param __user *)argaddr;
> > + long ret;
> > +
>
> For an ioctl, please follow the normal pattern of defining a separate
> structure for each case, no union.
And have fsl_hypervisor.h provide the full set of proper ioctl numbers, with
the specific struct for each ioctl referenced, rather than having the client program do
"ioctl(f, _IOWR(0, cmd, union fsl_hv_ioctl_param), p)".
-Scott
^ permalink raw reply
* Re: [PATCH] document udbg-immortal
From: Jesse Larrew @ 2011-06-01 22:03 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <alpine.DEB.2.01.1105311817240.21697@trent.utfs.org>
On 05/31/2011 08:22 PM, Christian Kujau wrote:
> + udbg-immortal [PPC] When debugging early kernel crashes that
> + happen after console_init() and before a proper
> + console driver takes over, this boot options might
> + help "seeing" what's going on.
> +
Thanks for documenting this!
Suggested grammatical tweaks:
s/options/option/
s/help "seeing"/help to "see"/
--
Jesse Larrew
Software Engineer, Linux on Power Kernel Team
IBM Linux Technology Center
Phone: (512) 973-2052 (T/L: 363-2052)
jlarrew@linux.vnet.ibm.com
^ permalink raw reply
* Re: [git pull] Please pull powerpc.git merge branch
From: Tabi Timur-B04825 @ 2011-06-01 21:56 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <alpine.LFD.2.00.1105200934580.11641@right.am.freescale.net>
On Fri, May 20, 2011 at 9:35 AM, Kumar Gala <galak@kernel.crashing.org> wro=
te:
> Shaohui Xie (2):
> =A0 =A0 =A0powerpc/fsl_rio: move machine_check handler
This patch causes a build failure if CONFIG_FSL_RIO is not defined:
arch/powerpc/kernel/built-in.o: In function `machine_check_e500mc':
/home/b04825/git/linux.hv/arch/powerpc/kernel/traps.c:429: undefined
reference to `fsl_rio_mcheck_exception'
arch/powerpc/kernel/built-in.o: In function `machine_check_e500':
/home/b04825/git/linux.hv/arch/powerpc/kernel/traps.c:519: undefined
reference to `fsl_rio_mcheck_exception'
--=20
Timur Tabi
Linux kernel developer at Freescale=
^ permalink raw reply
* Re: [PATCH 7/7] [v2] drivers/misc: introduce Freescale hypervisor management driver
From: Alan Cox @ 2011-06-01 21:45 UTC (permalink / raw)
To: Scott Wood
Cc: greg, kumar.gala, linux-kernel, akpm, linux-console, linuxppc-dev,
Timur Tabi
In-Reply-To: <20110601155430.4d5aa6de@schlenkerla.am.freescale.net>
> There's a check for -ENOIOCTLCMD in vfs_ioctl() -- though it generates
> -EINVAL rather than -ENOTTY (why?).
Good question - perhaps someone didn't read the spec 8)
^ permalink raw reply
* Re: [PATCH 7/7] [v2] drivers/misc: introduce Freescale hypervisor management driver
From: Arnd Bergmann @ 2011-06-01 21:40 UTC (permalink / raw)
To: Timur Tabi
Cc: kumar.gala, linux-kernel, akpm, linux-console, greg, linuxppc-dev
In-Reply-To: <1306953337-15698-1-git-send-email-timur@freescale.com>
On Wednesday 01 June 2011, Timur Tabi wrote:
> The Freescale hypervisor management driver provides several services to
> drivers and applications related to the Freescale hypervisor:
>
> 1. An ioctl interface for querying and managing partitions
>
> 2. A file interface to reading incoming doorbells
>
> 3. An interrupt handler for shutting down the partition upon receiving the
> shutdown doorbell from a manager partition
>
> 4. An interface for receiving callbacks when a managed partition shuts down.
>
> Signed-off-by: Timur Tabi <timur@freescale.com>
> ---
> drivers/misc/Kconfig | 7 +
> drivers/misc/Makefile | 1 +
> drivers/misc/fsl_hypervisor.c | 941 ++++++++++++++++++++++++++++++++++++++++
> include/linux/Kbuild | 1 +
> include/linux/fsl_hypervisor.h | 203 +++++++++
> 5 files changed, 1153 insertions(+), 0 deletions(-)
> create mode 100644 drivers/misc/fsl_hypervisor.c
> create mode 100644 include/linux/fsl_hypervisor.h
I think drivers/misc is not the right place for this, but I'm not completely
sure what is. drivers/firmware would be better at least, but virt/fsl might
also be ok.
> +static long ioctl_dtprop(struct fsl_hv_ioctl_prop __user *p, int set)
> +{
> + struct fsl_hv_ioctl_prop param;
> + char __user *upath, *upropname;
> + void __user *upropval;
> + char *path = NULL, *propname = NULL;
> + void *propval = NULL;
> + int ret = 0;
> +
I'm not convinced that an ioctl interface is the right way to work with
device tree properties. A more natural way would be to export it as
a file system, or maybe as a flattened device tree blob (the latter option
would require changing the hypervisor interface, which might not be
possible).
> +/**
> + * fsl_hv_ioctl: ioctl main entry point
> + */
> +static long fsl_hv_ioctl(struct file *file, unsigned int cmd,
> + unsigned long argaddr)
> +{
> + union fsl_hv_ioctl_param __user *arg =
> + (union fsl_hv_ioctl_param __user *)argaddr;
> + long ret;
> +
For an ioctl, please follow the normal pattern of defining a separate
structure for each case, no union.
You can use a void __user * in the common ioctl function, and pass that
to the typed argument list in the specific functions.
Arnd
^ permalink raw reply
* Re: [PATCH 7/7] [v2] drivers/misc: introduce Freescale hypervisor management driver
From: Scott Wood @ 2011-06-01 20:54 UTC (permalink / raw)
To: Alan Cox
Cc: greg, kumar.gala, linux-kernel, akpm, linux-console, linuxppc-dev,
Timur Tabi
In-Reply-To: <20110601204618.32190be9@lxorguk.ukuu.org.uk>
On Wed, 1 Jun 2011 20:46:18 +0100
Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
> > +static char *strdup_from_user(const char __user *ustr, size_t max)
> > +{
> > + size_t len;
> > + char *str;
> > +
> > + len = strnlen_user(ustr, max);
> > + if (len > max)
> > + return ERR_PTR(-ENAMETOOLONG);
if (len >= max)
> > + str = kmalloc(len, GFP_KERNEL);
> > + if (!str)
> > + return ERR_PTR(-ENOMEM);
> > +
> > + if (copy_from_user(str, ustr, len))
> > + return ERR_PTR(-EFAULT);
> > +
> > + return str;
> > +}
Memory leak on the EFAULT path
If strnlen_user gets an exception, it'll return zero, causing a
zero-length kmalloc. Will kmalloc(0, ...) return NULL? If so, a bad
user pointer would result in -ENOMEM rather than -EFAULT.
> > + default:
> > + pr_debug("fsl-hv: unknown ioctl %u\n", cmd);
> > + ret = -ENOIOCTLCMD;
>
> -ENOTTY
>
> (-ENOIOCTLCMD is an internal indicator designed so driver layers can say
> 'dunno, try the next layer up')
There's a check for -ENOIOCTLCMD in vfs_ioctl() -- though it generates
-EINVAL rather than -ENOTTY (why?).
Using -ENOIOCTLCMD consistently would make it easier to refactor a
toplevel ioctl handler into a nested one, plus consistency is good in
general.
> > + * We use the same interrupt handler for all doorbells. Whenever a doorbell
> > + * is rung, and we receive an interrupt, we just put the handle for that
> > + * doorbell (passed to us as *data) into all of the queues.
>
> I wonder if these should be presented as IRQs or whether that makes no
> sense ?
They are presented as IRQs. This driver registers the same handler for all
doorbell IRQs, and pipes the notifications up to userspace, but you could
also directly register a kernel handler for an individual doorbell IRQ.
> > +static irqreturn_t fsl_hv_shutdown_isr(int irq, void *data)
> > +{
> > + schedule_work(&power_off);
> > +
> > + /* We should never get here */
>
> Probably worth printing something if you do (panic(...) ?)
I don't think the comment is accurate. We've just scheduled the workqueue,
not waited for it to complete.
Timur, shouldn't this schedule orderly_poweroff rather than
kernel_power_off?
-Scott
^ permalink raw reply
* Re: [PATCH 7/7] [v2] drivers/misc: introduce Freescale hypervisor management driver
From: Alan Cox @ 2011-06-01 20:34 UTC (permalink / raw)
To: Timur Tabi
Cc: kumar.gala, linux-kernel, akpm, linux-console, greg, linuxppc-dev
In-Reply-To: <4DE6A013.409@freescale.com>
On Wed, 1 Jun 2011 15:24:51 -0500
Timur Tabi <timur@freescale.com> wrote:
> Alan Cox wrote:
> > O> + /* One partition must be local, the other must be remote. In other
> >> + words, if source and target are both -1, or are both not -1, then
> >> + return an error. */
> >> + if ((param.source == -1) == (param.target == -1))
> >> + return -EINVAL;
> >
> > Excess brackets (I just mention that one in passing)'
>
> Do you mean excess parentheses? If so, then I don't see how. "(param.source ==
> -1)" and "(param.target == -1)" are expressions that return a boolean. I'm
> comparing the two boolean results to see if they're equal
Ok - it's a bit non obvious but yes fair enough and it is commented.
> Where exactly in lib/ should it go? lib/strings.c seems too low-level for a
> function like this. lib/string_helpers.c is for sprintf-like functions. And
> it's too generic for lib/powerpc/
I'd submit it to lib/string personally but I'm not sure where would be
better. If someone doesn't like lib/string they can suggest a better
place 8)
> Well, the "handles" are supposed to be just unique numbers. In this case, they
> are IRQs, but we don't want to expose that. The application is supposed to scan
> the device tree looking for the doorbell nodes that it wants, and in those nodes
> there is a 'reg' property that contains the handle for that doorbell. So the
> numbers just need to match. What they represent is not relevant.
Ok so they are always going to be exposed to users not to drivers, in
which case yes it makes sense. If they are going to get used by kernel
drivers as well an IRQ interface would probably also make sense.
Alan
^ permalink raw reply
* Re: [PATCH 7/7] [v2] drivers/misc: introduce Freescale hypervisor management driver
From: Timur Tabi @ 2011-06-01 20:24 UTC (permalink / raw)
To: Alan Cox
Cc: kumar.gala, linux-kernel, akpm, linux-console, greg, linuxppc-dev
In-Reply-To: <20110601204618.32190be9@lxorguk.ukuu.org.uk>
Alan Cox wrote:
> O> + /* One partition must be local, the other must be remote. In other
>> + words, if source and target are both -1, or are both not -1, then
>> + return an error. */
>> + if ((param.source == -1) == (param.target == -1))
>> + return -EINVAL;
>
> Excess brackets (I just mention that one in passing)'
Do you mean excess parentheses? If so, then I don't see how. "(param.source ==
-1)" and "(param.target == -1)" are expressions that return a boolean. I'm
comparing the two boolean results to see if they're equal. I want to make sure
that the compiler doesn't do something like this:
if (param.source == (-1 == (param.target == -1)))
I don't even know what that means, but it's not what I want.
>> +static char *strdup_from_user(const char __user *ustr, size_t max)
>> +{
>> + size_t len;
>> + char *str;
>> +
>> + len = strnlen_user(ustr, max);
>> + if (len > max)
>> + return ERR_PTR(-ENAMETOOLONG);
>> +
>> + str = kmalloc(len, GFP_KERNEL);
>> + if (!str)
>> + return ERR_PTR(-ENOMEM);
>> +
>> + if (copy_from_user(str, ustr, len))
>> + return ERR_PTR(-EFAULT);
>> +
>> + return str;
>> +}
>
> This belongs on lib/ if its of general use which I think it perhaps is
> and if we don't have one already.
Where exactly in lib/ should it go? lib/strings.c seems too low-level for a
function like this. lib/string_helpers.c is for sprintf-like functions. And
it's too generic for lib/powerpc/
>> + default:
>> + pr_debug("fsl-hv: unknown ioctl %u\n", cmd);
>> + ret = -ENOIOCTLCMD;
>
> -ENOTTY
>
> (-ENOIOCTLCMD is an internal indicator designed so driver layers can say
> 'dunno, try the next layer up')
>
>> +/* Linked list of processes that have us open */
>> +struct list_head db_list;
>
> static ?
>
>
>> + * We use the same interrupt handler for all doorbells. Whenever a doorbell
>> + * is rung, and we receive an interrupt, we just put the handle for that
>> + * doorbell (passed to us as *data) into all of the queues.
>
> I wonder if these should be presented as IRQs or whether that makes no
> sense ?
Well, the "handles" are supposed to be just unique numbers. In this case, they
are IRQs, but we don't want to expose that. The application is supposed to scan
the device tree looking for the doorbell nodes that it wants, and in those nodes
there is a 'reg' property that contains the handle for that doorbell. So the
numbers just need to match. What they represent is not relevant.
>> +static irqreturn_t fsl_hv_state_change_isr(int irq, void *data)
>> +{
>> + unsigned int status;
>> + struct doorbell_isr *dbisr = data;
>> + int ret;
>> +
>> + /* Determine the new state, and if it's stopped, notify the clients. */
>> + ret = fh_partition_get_status(dbisr->partition, &status);
>> + if (!ret && (status == FH_PARTITION_STOPPED))
>> + schedule_work(&dbisr->work);
>> +
>> + /* Call the normal handler */
>> + return fsl_hv_isr(irq, (void *) (uintptr_t) dbisr->doorbell);
>> +}
>
> Would a threaded IRQ clean this up by avoiding the queue/work stuff ?
Yes, I think so. V3 coming up.
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* [patch 13/14] PCSPKR: Cleanup Kconfig dependencies
From: ralf @ 2011-06-01 18:05 UTC (permalink / raw)
To: linux-kernel, linux-arch
Cc: linux-mips, linux-alpha, x86, Ingo Molnar, Ivan Kokshaysky,
H. Peter Anvin, Paul Mackerras, Matt Turner, linuxppc-dev,
Thomas Gleixner, Richard Henderson
In-Reply-To: <20110601180456.801265664@duck.linux-mips.net>
Lenghty lists of the kind "depends on ARCH1 || ARCH2 ... || ARCH123" are
usually either wrong or too coarse grained. Or plain an ugly sin.
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
To: linux-kernel@vger.kernel.org
Cc: Richard Henderson <rth@twiddle.net>
Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
Cc: Matt Turner <mattst88@gmail.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: x86@kernel.org
Cc: linux-alpha@vger.kernel.org
Cc: linux-mips@linux-mips.org
Cc: linuxppc-dev@lists.ozlabs.org
arch/alpha/Kconfig | 1 +
arch/mips/Kconfig | 1 +
arch/powerpc/platforms/chrp/Kconfig | 1 +
arch/powerpc/platforms/prep/Kconfig | 1 +
arch/powerpc/platforms/pseries/Kconfig | 1 +
arch/x86/Kconfig | 1 +
init/Kconfig | 5 ++++-
7 files changed, 10 insertions(+), 1 deletion(-)
Index: linux-mips/arch/alpha/Kconfig
===================================================================
--- linux-mips.orig/arch/alpha/Kconfig
+++ linux-mips/arch/alpha/Kconfig
@@ -6,6 +6,7 @@ config ALPHA
select HAVE_OPROFILE
select HAVE_SYSCALL_WRAPPERS
select HAVE_IRQ_WORK
+ select HAVE_PCSPKR_PLATFORM
select HAVE_PERF_EVENTS
select HAVE_DMA_ATTRS
select HAVE_GENERIC_HARDIRQS
Index: linux-mips/arch/mips/Kconfig
===================================================================
--- linux-mips.orig/arch/mips/Kconfig
+++ linux-mips/arch/mips/Kconfig
@@ -5,6 +5,7 @@ config MIPS
select HAVE_IDE
select HAVE_OPROFILE
select HAVE_IRQ_WORK
+ select HAVE_PCSPKR_PLATFORM
select HAVE_PERF_EVENTS
select PERF_USE_VMALLOC
select HAVE_ARCH_KGDB
Index: linux-mips/arch/powerpc/platforms/chrp/Kconfig
===================================================================
--- linux-mips.orig/arch/powerpc/platforms/chrp/Kconfig
+++ linux-mips/arch/powerpc/platforms/chrp/Kconfig
@@ -1,6 +1,7 @@
config PPC_CHRP
bool "Common Hardware Reference Platform (CHRP) based machines"
depends on 6xx
+ select HAVE_PCSPKR_PLATFORM
select MPIC
select PPC_I8259
select PPC_INDIRECT_PCI
Index: linux-mips/arch/powerpc/platforms/prep/Kconfig
===================================================================
--- linux-mips.orig/arch/powerpc/platforms/prep/Kconfig
+++ linux-mips/arch/powerpc/platforms/prep/Kconfig
@@ -1,6 +1,7 @@
config PPC_PREP
bool "PowerPC Reference Platform (PReP) based machines"
depends on 6xx && BROKEN
+ select HAVE_PCSPKR_PLATFORM
select MPIC
select PPC_I8259
select PPC_INDIRECT_PCI
Index: linux-mips/arch/powerpc/platforms/pseries/Kconfig
===================================================================
--- linux-mips.orig/arch/powerpc/platforms/pseries/Kconfig
+++ linux-mips/arch/powerpc/platforms/pseries/Kconfig
@@ -1,6 +1,7 @@
config PPC_PSERIES
depends on PPC64 && PPC_BOOK3S
bool "IBM pSeries & new (POWER5-based) iSeries"
+ select HAVE_PCSPKR_PLATFORM
select MPIC
select PCI_MSI
select PPC_XICS
Index: linux-mips/arch/x86/Kconfig
===================================================================
--- linux-mips.orig/arch/x86/Kconfig
+++ linux-mips/arch/x86/Kconfig
@@ -20,6 +20,7 @@ config X86
select HAVE_UNSTABLE_SCHED_CLOCK
select HAVE_IDE
select HAVE_OPROFILE
+ select HAVE_PCSPKR_PLATFORM
select HAVE_PERF_EVENTS
select HAVE_IRQ_WORK
select HAVE_IOREMAP_PROT
Index: linux-mips/init/Kconfig
===================================================================
--- linux-mips.orig/init/Kconfig
+++ linux-mips/init/Kconfig
@@ -1001,12 +1001,15 @@ config ELF_CORE
config PCSPKR_PLATFORM
bool "Enable PC-Speaker support" if EXPERT
- depends on ALPHA || X86 || MIPS || PPC_PREP || PPC_CHRP || PPC_PSERIES
+ depends on HAVE_PCSPKR_PLATFORM
default y
help
This option allows to disable the internal PC-Speaker
support, saving some memory.
+config HAVE_PCSPKR_PLATFORM
+ bool
+
config BASE_FULL
default y
bool "Enable full-sized data structures for core" if EXPERT
^ permalink raw reply
* [patch 09/14] i8253: Alpha, PowerPC: Remove unused <asm/8253pit.h> header.
From: ralf @ 2011-06-01 18:05 UTC (permalink / raw)
To: linux-kernel, linux-arch
Cc: Ivan Kokshaysky, linux-alpha, Paul Mackerras, Matt Turner,
linuxppc-dev, Richard Henderson
In-Reply-To: <20110601180456.801265664@duck.linux-mips.net>
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
To: linux-kernel@vger.kernel.org
Cc: Richard Henderson <rth@twiddle.net>
Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
Cc: Matt Turner <mattst88@gmail.com>
Cc: linux-alpha@vger.kernel.org
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: linuxppc-dev@lists.ozlabs.org
arch/alpha/include/asm/8253pit.h | 3 ---
arch/powerpc/include/asm/8253pit.h | 3 ---
2 files changed, 6 deletions(-)
Index: linux-mips/arch/alpha/include/asm/8253pit.h
===================================================================
--- linux-mips.orig/arch/alpha/include/asm/8253pit.h
+++ /dev/null
@@ -1,3 +0,0 @@
-/*
- * 8253/8254 Programmable Interval Timer
- */
Index: linux-mips/arch/powerpc/include/asm/8253pit.h
===================================================================
--- linux-mips.orig/arch/powerpc/include/asm/8253pit.h
+++ /dev/null
@@ -1,3 +0,0 @@
-/*
- * 8253/8254 Programmable Interval Timer
- */
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox