* Re: [RFC/PATCH] mm/futex: Fix futex writes on archs with SW tracking of dirty & young
From: Benjamin Herrenschmidt @ 2011-07-21 22:57 UTC (permalink / raw)
To: Andrew Morton
Cc: tony.luck, Peter Zijlstra, Shan Hai, Peter Zijlstra, linux-kernel,
cmetcalf, dhowells, paulus, tglx, walken, linuxppc-dev
In-Reply-To: <1311288726.25044.545.camel@pasglop>
On Fri, 2011-07-22 at 08:52 +1000, Benjamin Herrenschmidt wrote:
> > um, what problem. There's no description here of the user-visible
> > effects of the bug hence it's hard to work out what kernel version(s)
> > should receive this patch.
>
> Shan could give you an actual example (it was in the previous thread),
> but basically, livelock as the kernel keeps trying and trying the
> in_atomic op and never resolves it.
>
> > What kernel version(s) should receive this patch?
>
> I haven't dug. Probably anything it applies on as far as we did that
> trick of atomic + gup() for futex.
Oops, I just realize I didn't document the problem at all in the
changelog .. sorry. I meant to say:
On archs who use SW tracking of dirty & young, a page without dirty is
effectively mapped read-only and a page without young unaccessible in
the PTE.
Additionally, some architectures might lazily flush the TLB when
relaxing write protection (by doing only a local flush), and expect a
fault to invalidate the stale entry if it's still present on another
processor.
The futex code assumes that if the "in_atomic()" access -EFAULT's, it
can "fix it up" by causing get_user_pages() which would then be
equivalent to taking the fault.
However that isn't the case. get_user_pages() will not call
handle_mm_fault() in the case where the PTE seems to have the right
permissions, regardless of the dirty and young state. It will eventually
update those bits ... in the struct page, but not in the PTE.
Additionally, it will not handle the lazy TLB flushing that can be
required by some architectures in the fault case.
Basically, gup is the wrong interface for the job. The patch provides a
more appropriate one which boils down to just calling handle_mm_fault()
since what we are trying to do is simulate a real page fault.
Cheers,
Ben.
> > > since I'm
> > > starting to have the nasty feeling that you are hitting what is
> > > somewhat a subtly different issue or my previous patch should
> > > have worked (but then I might have done a stupid mistake as well)
> > > but let us know anyway.
> >
> > I assume that Shan reported the secret problem so I added the
> > reported-by to the changelog.
>
> He did :-) Shan, care to provide a rough explanation of what you
> observed ?
>
> Also Russell confirmed that ARM should be affected as well.
>
> Cheers,
> Ben.
^ permalink raw reply
* Re: [RFC/PATCH] mm/futex: Fix futex writes on archs with SW tracking of dirty & young
From: Andrew Morton @ 2011-07-21 22:59 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: tony.luck, Peter Zijlstra, Shan Hai, Peter Zijlstra, linux-kernel,
cmetcalf, dhowells, paulus, tglx, walken, linuxppc-dev
In-Reply-To: <1311288726.25044.545.camel@pasglop>
On Fri, 22 Jul 2011 08:52:06 +1000
Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> On Thu, 2011-07-21 at 15:36 -0700, Andrew Morton wrote:
> > On Tue, 19 Jul 2011 14:29:22 +1000
> > Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> >
> > > The futex code currently attempts to write to user memory within
> > > a pagefault disabled section, and if that fails, tries to fix it
> > > up using get_user_pages().
> > >
> > > This doesn't work on archs where the dirty and young bits are
> > > maintained by software, since they will gate access permission
> > > in the TLB, and will not be updated by gup().
> > >
> > > In addition, there's an expectation on some archs that a
> > > spurious write fault triggers a local TLB flush, and that is
> > > missing from the picture as well.
> > >
> > > I decided that adding those "features" to gup() would be too much
> > > for this already too complex function, and instead added a new
> > > simpler fixup_user_fault() which is essentially a wrapper around
> > > handle_mm_fault() which the futex code can call.
> > >
> > > Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> > > ---
> > >
> > > Shan, can you test this ? It might not fix the problem
> >
> > um, what problem. There's no description here of the user-visible
> > effects of the bug hence it's hard to work out what kernel version(s)
> > should receive this patch.
>
> Shan could give you an actual example (it was in the previous thread),
> but basically, livelock as the kernel keeps trying and trying the
> in_atomic op and never resolves it.
>
> > What kernel version(s) should receive this patch?
>
> I haven't dug. Probably anything it applies on as far as we did that
> trick of atomic + gup() for futex.
You're not understanding me.
I need a good reason to merge this into 3.0.
The -stable maintainers need even better reasons to merge this into
earlier kernels.
Please provide those reasons!
(Documentation/stable_kernel_rules.txt, 4th bullet)
(And it's not just me and -stable maintainers. Distro maintainers will
also look at this patch and wonder whether they should merge it)
^ permalink raw reply
* Re: [RFC/PATCH] mm/futex: Fix futex writes on archs with SW tracking of dirty & young
From: Benjamin Herrenschmidt @ 2011-07-22 1:40 UTC (permalink / raw)
To: Andrew Morton
Cc: tony.luck, Peter Zijlstra, Shan Hai, Peter Zijlstra, linux-kernel,
cmetcalf, dhowells, paulus, tglx, walken, linuxppc-dev
In-Reply-To: <20110721155938.2ff2dab5.akpm@linux-foundation.org>
> You're not understanding me.
>
> I need a good reason to merge this into 3.0.
>
> The -stable maintainers need even better reasons to merge this into
> earlier kernels.
>
> Please provide those reasons!
>
> (Documentation/stable_kernel_rules.txt, 4th bullet)
>
> (And it's not just me and -stable maintainers. Distro maintainers will
> also look at this patch and wonder whether they should merge it)
Well, as an arch maintainer, I can get stable maintainers to merge
anything I CC to stable :-)
Now, the good reason should have been rather obvious... it's a user
exploitable kernel lockup.
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH 08/14] 85xx/sbc8560: declare that localbus is compatbile with simple-bus
From: Paul Gortmaker @ 2011-07-22 1:53 UTC (permalink / raw)
To: Dmitry Eremin-Solenikov; +Cc: Paul Mackerras, Linux PPC Development
In-Reply-To: <1311065631-3429-9-git-send-email-dbaryshkov@gmail.com>
Something has gone off the rails with getmaintainer.pl or similar --
I'm guessing that
PaulM doesn't care about dts patches for some aging sbc8560 board,
P.
On Tue, Jul 19, 2011 at 4:53 AM, Dmitry Eremin-Solenikov
<dbaryshkov@gmail.com> wrote:
> Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
> ---
> =A0arch/powerpc/boot/dts/sbc8560.dts | =A0 =A02 +-
> =A01 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/arch/powerpc/boot/dts/sbc8560.dts b/arch/powerpc/boot/dts/sb=
c8560.dts
> index 9e13ed8..72078eb 100644
> --- a/arch/powerpc/boot/dts/sbc8560.dts
> +++ b/arch/powerpc/boot/dts/sbc8560.dts
> @@ -331,7 +331,7 @@
> =A0 =A0 =A0 =A0};
>
> =A0 =A0 =A0 =A0localbus@ff705000 {
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 compatible =3D "fsl,mpc8560-localbus";
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 compatible =3D "fsl,mpc8560-localbus", "sim=
ple-bus";
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0#address-cells =3D <2>;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0#size-cells =3D <1>;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0reg =3D <0xff705000 0x100>; =A0 =A0 =A0 //=
BRx, ORx, etc.
> --
> 1.7.2.5
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
>
^ permalink raw reply
* Re: [RFC/PATCH] mm/futex: Fix futex writes on archs with SW tracking of dirty & young
From: Shan Hai @ 2011-07-22 1:54 UTC (permalink / raw)
To: Andrew Morton
Cc: tony.luck, Peter Zijlstra, Peter Zijlstra, linux-kernel, cmetcalf,
dhowells, paulus, tglx, walken, linuxppc-dev
In-Reply-To: <20110721155938.2ff2dab5.akpm@linux-foundation.org>
On 07/22/2011 06:59 AM, Andrew Morton wrote:
> On Fri, 22 Jul 2011 08:52:06 +1000
> Benjamin Herrenschmidt<benh@kernel.crashing.org> wrote:
>
>> On Thu, 2011-07-21 at 15:36 -0700, Andrew Morton wrote:
>>> On Tue, 19 Jul 2011 14:29:22 +1000
>>> Benjamin Herrenschmidt<benh@kernel.crashing.org> wrote:
>>>
>>>> The futex code currently attempts to write to user memory within
>>>> a pagefault disabled section, and if that fails, tries to fix it
>>>> up using get_user_pages().
>>>>
>>>> This doesn't work on archs where the dirty and young bits are
>>>> maintained by software, since they will gate access permission
>>>> in the TLB, and will not be updated by gup().
>>>>
>>>> In addition, there's an expectation on some archs that a
>>>> spurious write fault triggers a local TLB flush, and that is
>>>> missing from the picture as well.
>>>>
>>>> I decided that adding those "features" to gup() would be too much
>>>> for this already too complex function, and instead added a new
>>>> simpler fixup_user_fault() which is essentially a wrapper around
>>>> handle_mm_fault() which the futex code can call.
>>>>
>>>> Signed-off-by: Benjamin Herrenschmidt<benh@kernel.crashing.org>
>>>> ---
>>>>
>>>> Shan, can you test this ? It might not fix the problem
>>> um, what problem. There's no description here of the user-visible
>>> effects of the bug hence it's hard to work out what kernel version(s)
>>> should receive this patch.
>> Shan could give you an actual example (it was in the previous thread),
>> but basically, livelock as the kernel keeps trying and trying the
>> in_atomic op and never resolves it.
>>
>>> What kernel version(s) should receive this patch?
>> I haven't dug. Probably anything it applies on as far as we did that
>> trick of atomic + gup() for futex.
> You're not understanding me.
>
> I need a good reason to merge this into 3.0.
>
> The -stable maintainers need even better reasons to merge this into
> earlier kernels.
>
> Please provide those reasons!
>
Summary:
- Encountered a 100% CPU system usage problem on pthread_mutex allocated
in a
shared memory region, and the problem occurs only on setting
PRIORITY_INHERITANCE
to the pthread_mutex.
- ftrace result reveals that an infinite loop in the futex_lock_pi
caused high CPU usage.
- The powerpc e500 was affected but the x86 was not.
I have not tested on other archs so I am not sure whether the other
archs are attacked
by the problem.
- Tested it on 2.6.34 and 3.0-rc7, both are affected, earlier versions
might be affected.
Please refer the threads "[PATCH 0/1] Fixup write permission of TLB on
powerpc e500 core"
and "[PATCH 1/1] Fixup write permission of TLB on powerpc e500 core" for
the whole story.
Provided the test case code in the [PATH 0/1].
Thanks
Shan Hai
> (Documentation/stable_kernel_rules.txt, 4th bullet)
>
> (And it's not just me and -stable maintainers. Distro maintainers will
> also look at this patch and wonder whether they should merge it)
^ permalink raw reply
* Re: [PATCH 09/14] 85xx/sbc8548: read hardware revision when it's required for first time
From: Paul Gortmaker @ 2011-07-22 1:59 UTC (permalink / raw)
To: Kumar Gala; +Cc: Dmitry Eremin-Solenikov, Paul Mackerras, Linux PPC Development
In-Reply-To: <EBAEF199-2D62-477F-BD40-861149AB1CFA@kernel.crashing.org>
On Tue, Jul 19, 2011 at 10:12 AM, Kumar Gala <galak@kernel.crashing.org> wr=
ote:
>
> On Jul 19, 2011, at 3:53 AM, Dmitry Eremin-Solenikov wrote:
>
>> Currently sbc8548 reads hardware revision during bootup. To simplify
>> things read it when it's first required when the kernel is up and
>> running.
>>
>> Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
>> ---
>> arch/powerpc/platforms/85xx/sbc8548.c | =A0 =A08 +++++---
>> 1 files changed, 5 insertions(+), 3 deletions(-)
>
> How is this simplifying things, seems more complicated to add an addition=
al if() check.
Agreed -- I don't see what this is meant to achieve.
Paul.
>
> - k
>
>>
>> diff --git a/arch/powerpc/platforms/85xx/sbc8548.c b/arch/powerpc/platfo=
rms/85xx/sbc8548.c
>> index ecdd8c0..2eeb376 100644
>> --- a/arch/powerpc/platforms/85xx/sbc8548.c
>> +++ b/arch/powerpc/platforms/85xx/sbc8548.c
>> @@ -49,7 +49,7 @@
>> #include <sysdev/fsl_soc.h>
>> #include <sysdev/fsl_pci.h>
>>
>> -static int sbc_rev;
>> +static int sbc_rev =3D -EINVAL;
>>
>> static void __init sbc8548_pic_init(void)
>> {
>> @@ -82,7 +82,7 @@ static void __init sbc8548_pic_init(void)
>> }
>>
>> /* Extract the HW Rev from the EPLD on the board */
>> -static int __init sbc8548_hw_rev(void)
>> +static int sbc8548_hw_rev(void)
>> {
>> =A0 =A0 =A0 struct device_node *np;
>> =A0 =A0 =A0 struct resource res;
>> @@ -130,7 +130,6 @@ static void __init sbc8548_setup_arch(void)
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 }
>> =A0 =A0 =A0 }
>> #endif
>> - =A0 =A0 sbc_rev =3D sbc8548_hw_rev();
>> }
>>
>> static void sbc8548_show_cpuinfo(struct seq_file *m)
>> @@ -140,6 +139,9 @@ static void sbc8548_show_cpuinfo(struct seq_file *m)
>> =A0 =A0 =A0 pvid =3D mfspr(SPRN_PVR);
>> =A0 =A0 =A0 svid =3D mfspr(SPRN_SVR);
>>
>> + =A0 =A0 if (sbc_rev =3D=3D -EINVAL)
>> + =A0 =A0 =A0 =A0 =A0 =A0 sbc_rev =3D sbc8548_hw_rev();
>> +
>> =A0 =A0 =A0 seq_printf(m, "Vendor\t\t: Wind River\n");
>> =A0 =A0 =A0 seq_printf(m, "Machine\t\t: SBC8548 v%d\n", sbc_rev);
>> =A0 =A0 =A0 seq_printf(m, "PVR\t\t: 0x%x\n", pvid);
>> --
>> 1.7.2.5
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
>
^ permalink raw reply
* RE: [PATCH 1/4] powerpc/85xx: fix interrupt number of memory-controller for P4080
From: Xie Shaohui-B21989 @ 2011-07-22 2:04 UTC (permalink / raw)
To: Gala Kumar-B11780; +Cc: linuxppc-dev@lists.ozlabs.org
In-Reply-To: <65C49D37-A103-494D-AD8E-7C8FC6E3716E@freescale.com>
>-----Original Message-----
>From: Gala Kumar-B11780
>Sent: Thursday, July 21, 2011 8:13 PM
>To: Xie Shaohui-B21989
>Cc: linuxppc-dev@lists.ozlabs.org
>Subject: Re: [PATCH 1/4] powerpc/85xx: fix interrupt number of memory-
>controller for P4080
>
>
>On Jul 21, 2011, at 5:24 AM, Shaohui Xie wrote:
>
>> Signed-off-by: Shaohui Xie <Shaohui.Xie@freescale.com>
>> ---
>> arch/powerpc/boot/dts/p4080ds.dts | 4 ++--
>> 1 files changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/arch/powerpc/boot/dts/p4080ds.dts
>b/arch/powerpc/boot/dts/p4080ds.dts
>> index 927f94d..9c37a85 100644
>> --- a/arch/powerpc/boot/dts/p4080ds.dts
>> +++ b/arch/powerpc/boot/dts/p4080ds.dts
>> @@ -131,14 +131,14 @@
>> compatible =3D "fsl,p4080-memory-controller";
>> reg =3D <0x8000 0x1000>;
>> interrupt-parent =3D <&mpic>;
>> - interrupts =3D <0x12 2>;
>> + interrupts =3D <16 2>;
>> };
>>
>> memory-controller@9000 {
>> compatible =3D "fsl,p4080-memory-controller";
>> reg =3D <0x9000 0x1000>;
>> interrupt-parent =3D <&mpic>;
>> - interrupts =3D <0x12 2>;
>> + interrupts =3D <16 2>;
>> };
>>
>> corenet-cf@18000 {
>> --
>> 1.6.4
>
>What code base / tree is this against?
>
[Xie Shaohui] This patch is based on v3.0-rc7.
Best Regards,=20
Shaohui Xie
^ permalink raw reply
* RE: [PATCH 1/4] powerpc/85xx: fix interrupt number of memory-controller for P4080
From: Xie Shaohui-B21989 @ 2011-07-22 2:12 UTC (permalink / raw)
To: Tabi Timur-B04825; +Cc: Gala Kumar-B11780, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <CAOZdJXVL_iFPBb-D+c6UxLnvu7yqY3-yx5NQ8+SSAEQyaFdehQ@mail.gmail.com>
>From: Tabi Timur-B04825
>Sent: Thursday, July 21, 2011 11:58 PM
>To: Xie Shaohui-B21989
>Cc: linuxppc-dev@lists.ozlabs.org; Gala Kumar-B11780
>Subject: Re: [PATCH 1/4] powerpc/85xx: fix interrupt number of memory-
>controller for P4080
>
>On Thu, Jul 21, 2011 at 5:24 AM, Shaohui Xie <Shaohui.Xie@freescale.com>
>wrote:
>> Signed-off-by: Shaohui Xie <Shaohui.Xie@freescale.com>
>> ---
>
>Can you provide an explanation as to why the current numbers are wrong?
>
[Xie Shaohui] This irq number is used by edac/mc, the edac/mc will handle t=
he error interrupt
Issued by memory-controllers, but the error interrupt on p4080 is 16.
Best Regards,=20
Shaohui Xie
^ permalink raw reply
* RE: [PATCH 3/4] powerpc/85xx: Merge PCI/PCI Express error management registers
From: Xie Shaohui-B21989 @ 2011-07-22 2:56 UTC (permalink / raw)
To: Tabi Timur-B04825
Cc: Gala Kumar-B11780, linuxppc-dev@lists.ozlabs.org,
Jiang Kai-B18973
In-Reply-To: <CAOZdJXVFakNCpQk6CPB_V7WVtkfREwuUMqs31XfjuKZnc3-ARA@mail.gmail.com>
>From: Tabi Timur-B04825
>Sent: Thursday, July 21, 2011 11:59 PM
>To: Xie Shaohui-B21989
>Cc: linuxppc-dev@lists.ozlabs.org; Gala Kumar-B11780; Jiang Kai-B18973
>Subject: Re: [PATCH 3/4] powerpc/85xx: Merge PCI/PCI Express error
>management registers
>
>On Thu, Jul 21, 2011 at 5:29 AM, Shaohui Xie <Shaohui.Xie@freescale.com>
>wrote:
>
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 /* - PCIE has no this register
>*/
>
>I don't understand this sentence.
>
[Xie Shaohui] this patch intend to merge PCI and PCIe error management regi=
sters into a unit
Structure, some register offsets where PCI has definitions while PCIe are r=
eserved. For ex. On
MPC8536, PCI has a register ERR_CAP_DR (PCI error capture disabled register=
) at offset 0xe04,=20
But this offset is reserved in PCIe.
Best Regards,=20
Shaohui Xie
^ permalink raw reply
* [git pull] Please pull powerpc.git of-pci branch
From: Benjamin Herrenschmidt @ 2011-07-22 3:44 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linuxppc-dev list, Andrew Morton, Linux Kernel list
Hi Linus !
This branch contains some rework and consolidation of the code
to establish the mapping between device-tree nodes for PCI
devices (if they exist) and the corresponding Linux struct device.
It moves it all to generic code in a way that is a lot cleaner
than any of the previous implementations. It specifically allows
me to get rid of a two subtly different ways of doing the same
thing I had in powerpc between 32-bit and 64-bit, and updates
microblaze and x86 to use that common code as well.
This has been in -next for a while with no complaints so far
and is completely orthogonal to the powerpc changes I will send
you in a couple of days (I want to wait for some other trees
to go in first to address a couple of known collisions).
Cheers,
Ben.
The following changes since commit 620917de59eeb934b9f8cf35cc2d95c1ac8ed0fc:
Linux 3.0-rc7 (2011-07-11 16:51:52 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git of-pci
Benjamin Herrenschmidt (6):
pci/of: Match PCI devices to OF nodes dynamically
microblaze/pci: Remove powermac originated cruft
microblaze/pci: Move the remains of pci_32.c to pci-common.c
x86/devicetree: Use generic PCI <-> OF matching
pci/of: Consolidate pci_device_to_OF_node()
pci/of: Consolidate pci_bus_to_OF_node()
arch/microblaze/include/asm/pci-bridge.h | 13 -
arch/microblaze/include/asm/pci.h | 3 +-
arch/microblaze/include/asm/prom.h | 15 -
arch/microblaze/pci/Makefile | 2 +-
arch/microblaze/pci/pci-common.c | 112 ++++++++
arch/microblaze/pci/pci_32.c | 432 ------------------------------
arch/powerpc/include/asm/pci-bridge.h | 29 +--
arch/powerpc/include/asm/pci.h | 3 +-
arch/powerpc/include/asm/prom.h | 14 -
arch/powerpc/kernel/pci-common.c | 11 +-
arch/powerpc/kernel/pci_32.c | 150 +----------
arch/powerpc/kernel/pci_dn.c | 47 ----
arch/powerpc/kernel/pci_of_scan.c | 9 +-
arch/powerpc/platforms/powermac/pci.c | 3 +-
arch/sparc/include/asm/pci_32.h | 3 -
arch/sparc/include/asm/pci_64.h | 3 -
arch/sparc/kernel/pci.c | 8 +-
arch/sparc/kernel/pcic.c | 8 -
arch/x86/include/asm/prom.h | 11 -
arch/x86/kernel/devicetree.c | 60 ++---
drivers/of/Kconfig | 8 +-
drivers/of/Makefile | 1 +
drivers/of/of_pci.c | 112 ++------
drivers/of/of_pci_irq.c | 92 +++++++
drivers/pci/Makefile | 2 +
drivers/pci/hotplug/rpadlpar_core.c | 2 +-
drivers/pci/of.c | 61 +++++
drivers/pci/probe.c | 7 +-
include/linux/of_pci.h | 5 +
include/linux/pci.h | 28 ++
30 files changed, 395 insertions(+), 859 deletions(-)
delete mode 100644 arch/microblaze/pci/pci_32.c
create mode 100644 drivers/of/of_pci_irq.c
create mode 100644 drivers/pci/of.c
^ permalink raw reply
* Re: [PATCH 1/4] powerpc/85xx: fix interrupt number of memory-controller for P4080
From: Kumar Gala @ 2011-07-22 6:00 UTC (permalink / raw)
To: Xie Shaohui-B21989; +Cc: Gala Kumar-B11780, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <267A3B246C22C34A8E574051858E077010E0F7@039-SN1MPN1-003.039d.mgd.msft.net>
On Jul 21, 2011, at 9:04 PM, Xie Shaohui-B21989 wrote:
>=20
>=20
>=20
>> -----Original Message-----
>> From: Gala Kumar-B11780
>> Sent: Thursday, July 21, 2011 8:13 PM
>> To: Xie Shaohui-B21989
>> Cc: linuxppc-dev@lists.ozlabs.org
>> Subject: Re: [PATCH 1/4] powerpc/85xx: fix interrupt number of =
memory-
>> controller for P4080
>>=20
>>=20
>> On Jul 21, 2011, at 5:24 AM, Shaohui Xie wrote:
>>=20
>>> Signed-off-by: Shaohui Xie <Shaohui.Xie@freescale.com>
>>> ---
>>> arch/powerpc/boot/dts/p4080ds.dts | 4 ++--
>>> 1 files changed, 2 insertions(+), 2 deletions(-)
>>>=20
>>> diff --git a/arch/powerpc/boot/dts/p4080ds.dts
>> b/arch/powerpc/boot/dts/p4080ds.dts
>>> index 927f94d..9c37a85 100644
>>> --- a/arch/powerpc/boot/dts/p4080ds.dts
>>> +++ b/arch/powerpc/boot/dts/p4080ds.dts
>>> @@ -131,14 +131,14 @@
>>> compatible =3D "fsl,p4080-memory-controller";
>>> reg =3D <0x8000 0x1000>;
>>> interrupt-parent =3D <&mpic>;
>>> - interrupts =3D <0x12 2>;
>>> + interrupts =3D <16 2>;
>>> };
>>>=20
>>> memory-controller@9000 {
>>> compatible =3D "fsl,p4080-memory-controller";
>>> reg =3D <0x9000 0x1000>;
>>> interrupt-parent =3D <&mpic>;
>>> - interrupts =3D <0x12 2>;
>>> + interrupts =3D <16 2>;
>>> };
>>>=20
>>> corenet-cf@18000 {
>>> --
>>> 1.6.4
>>=20
>> What code base / tree is this against?
>>=20
>=20
> [Xie Shaohui] This patch is based on v3.0-rc7.
Please use galak/powerpc.git 'next' branch.
It has the following:
=
http://git.kernel.org/?p=3Dlinux/kernel/git/galak/powerpc.git;a=3Dblob;f=3D=
arch/powerpc/boot/dts/p4080si.dtsi;h=3Db71051f506c1763fbb911a0df62b58577ed=
a2ce0;hb=3Drefs/heads/next
- k=
^ permalink raw reply
* Re: [PATCH 2/4] powerpc/85xx: enable pcie initialization for P4080
From: Kumar Gala @ 2011-07-22 6:06 UTC (permalink / raw)
To: Shaohui Xie; +Cc: linuxppc-dev
In-Reply-To: <1311243914-4349-1-git-send-email-Shaohui.Xie@freescale.com>
On Jul 21, 2011, at 5:25 AM, Shaohui Xie wrote:
> Signed-off-by: Shaohui Xie <Shaohui.Xie@freescale.com>
> ---
> arch/powerpc/platforms/85xx/corenet_ds.c | 3 +++
> 1 files changed, 3 insertions(+), 0 deletions(-)
>=20
> diff --git a/arch/powerpc/platforms/85xx/corenet_ds.c =
b/arch/powerpc/platforms/85xx/corenet_ds.c
> index 2ab338c..15247b0 100644
> --- a/arch/powerpc/platforms/85xx/corenet_ds.c
> +++ b/arch/powerpc/platforms/85xx/corenet_ds.c
> @@ -114,6 +114,9 @@ static const struct of_device_id of_device_ids[] =
__devinitconst =3D {
> .compatible =3D "simple-bus"
> },
> {
> + .compatible =3D "fsl,p4080-pcie"
> + },
> + {
> .compatible =3D "fsl,rapidio-delta",
> },
> {}
> --=20
> 1.6.4
>=20
What about p204x, p3041 & p5020 boards?
- k=
^ permalink raw reply
* RE: [PATCH 1/4] powerpc/85xx: fix interrupt number of memory-controller for P4080
From: Xie Shaohui-B21989 @ 2011-07-22 6:22 UTC (permalink / raw)
To: Kumar Gala; +Cc: Gala Kumar-B11780, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <D1A417CC-2514-4103-8D0E-96F16724BCEF@kernel.crashing.org>
=20
>-----Original Message-----
>From: Kumar Gala [mailto:galak@kernel.crashing.org]
>Sent: Friday, July 22, 2011 2:01 PM
>To: Xie Shaohui-B21989
>Cc: Gala Kumar-B11780; linuxppc-dev@lists.ozlabs.org
>Subject: Re: [PATCH 1/4] powerpc/85xx: fix interrupt number of memory-
>controller for P4080
>
>
>On Jul 21, 2011, at 9:04 PM, Xie Shaohui-B21989 wrote:
>
>>
>>
>>
>>> -----Original Message-----
>>> From: Gala Kumar-B11780
>>> Sent: Thursday, July 21, 2011 8:13 PM
>>> To: Xie Shaohui-B21989
>>> Cc: linuxppc-dev@lists.ozlabs.org
>>> Subject: Re: [PATCH 1/4] powerpc/85xx: fix interrupt number of
>>> memory- controller for P4080
>>>
>>>
>>> On Jul 21, 2011, at 5:24 AM, Shaohui Xie wrote:
>>>
>>>> Signed-off-by: Shaohui Xie <Shaohui.Xie@freescale.com>
>>>> ---
>>>> arch/powerpc/boot/dts/p4080ds.dts | 4 ++--
>>>> 1 files changed, 2 insertions(+), 2 deletions(-)
>>>>
>>>> diff --git a/arch/powerpc/boot/dts/p4080ds.dts
>>> b/arch/powerpc/boot/dts/p4080ds.dts
>>>> index 927f94d..9c37a85 100644
>>>> --- a/arch/powerpc/boot/dts/p4080ds.dts
>>>> +++ b/arch/powerpc/boot/dts/p4080ds.dts
>>>> @@ -131,14 +131,14 @@
>>>> compatible =3D "fsl,p4080-memory-controller";
>>>> reg =3D <0x8000 0x1000>;
>>>> interrupt-parent =3D <&mpic>;
>>>> - interrupts =3D <0x12 2>;
>>>> + interrupts =3D <16 2>;
>>>> };
>>>>
>>>> memory-controller@9000 {
>>>> compatible =3D "fsl,p4080-memory-controller";
>>>> reg =3D <0x9000 0x1000>;
>>>> interrupt-parent =3D <&mpic>;
>>>> - interrupts =3D <0x12 2>;
>>>> + interrupts =3D <16 2>;
>>>> };
>>>>
>>>> corenet-cf@18000 {
>>>> --
>>>> 1.6.4
>>>
>>> What code base / tree is this against?
>>>
>>
>> [Xie Shaohui] This patch is based on v3.0-rc7.
>
>Please use galak/powerpc.git 'next' branch.
>
>It has the following:
>
>http://git.kernel.org/?p=3Dlinux/kernel/git/galak/powerpc.git;a=3Dblob;f=
=3Darch/
>powerpc/boot/dts/p4080si.dtsi;h=3Db71051f506c1763fbb911a0df62b58577eda2ce0=
;h
>b=3Drefs/heads/next
>
[Xie Shaohui] OK, thanks!
I'll rebase these patches on 'next' branch.
Best Regards,=20
Shaohui Xie
^ permalink raw reply
* Re: [PATCH v2] powerpc/85xx: fix mpic configuration in CAMP mode
From: Kumar Gala @ 2011-07-22 8:28 UTC (permalink / raw)
To: Fabio Baltieri; +Cc: Scott Wood, Poonam Aggrwal, linuxppc-dev, linux-kernel
In-Reply-To: <1310456983-1473-1-git-send-email-fabio.baltieri@gmail.com>
On Jul 12, 2011, at 2:49 AM, Fabio Baltieri wrote:
> Change the string to check for CAMP mode boot on MPC85xx (eg. P2020) =
to match
> the one in the corresponding dts files (p2020rdb_camp_core{0,1}.dts).
>=20
> Without this fix the mpic is configured as in the SMP boot mode, which =
causes
> the first core to report a protected source interrupt error for =
devices
> of the other core and lock up.
>=20
> Also add MPIC_SINGLE_DEST_CPU on both P2020 based architectures in =
CAMP
> mode as suggested by Scott Wood. Thanks.
>=20
> Cc: Scott Wood <scottwood@freescale.com>
> Cc: Poonam Aggrwal <poonam.aggrwal@freescale.com>
> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Signed-off-by: Fabio Baltieri <fabio.baltieri@gmail.com>
> ---
> arch/powerpc/platforms/85xx/mpc85xx_ds.c | 3 ++-
> arch/powerpc/platforms/85xx/mpc85xx_rdb.c | 5 +++--
> 2 files changed, 5 insertions(+), 3 deletions(-)
applied to next
- k=
^ permalink raw reply
* [PATCH 1/2 v2] eSDHC: Access Freescale eSDHC registers by 32-bit
From: Roy Zang @ 2011-07-22 10:15 UTC (permalink / raw)
To: linux-mmc; +Cc: Xu lei, linuxppc-dev, akpm
From: Xu lei <B33228@freescale.com>
For Freescale eSDHC registers only support 32-bit accesses,
this patch ensure that all Freescale eSDHC register accesses
are 32-bit.
Signed-off-by: Xu lei <B33228@freescale.com>
Signed-off-by: Roy Zang <tie-fei.zang@freescale.com>
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
---
this patch set replaces previous patches:
https://patchwork.kernel.org/patch/943332/
https://patchwork.kernel.org/patch/943342/
https://patchwork.kernel.org/patch/943322/
The last one is discarded according to the comment from Anton.
just resend with the new patch set. no change for this patch comparing
to previous version.
drivers/mmc/host/sdhci-of-esdhc.c | 18 ++++++++++++++----
1 files changed, 14 insertions(+), 4 deletions(-)
diff --git a/drivers/mmc/host/sdhci-of-esdhc.c b/drivers/mmc/host/sdhci-of-esdhc.c
index ba40d6d..c9a8519 100644
--- a/drivers/mmc/host/sdhci-of-esdhc.c
+++ b/drivers/mmc/host/sdhci-of-esdhc.c
@@ -1,7 +1,7 @@
/*
* Freescale eSDHC controller driver.
*
- * Copyright (c) 2007 Freescale Semiconductor, Inc.
+ * Copyright (c) 2007, 2010 Freescale Semiconductor, Inc.
* Copyright (c) 2009 MontaVista Software, Inc.
*
* Authors: Xiaobo Xie <X.Xie@freescale.com>
@@ -23,11 +23,21 @@
static u16 esdhc_readw(struct sdhci_host *host, int reg)
{
u16 ret;
+ int base = reg & ~0x3;
+ int shift = (reg & 0x2) * 8;
if (unlikely(reg == SDHCI_HOST_VERSION))
- ret = in_be16(host->ioaddr + reg);
+ ret = in_be32(host->ioaddr + base) & 0xffff;
else
- ret = sdhci_be32bs_readw(host, reg);
+ ret = (in_be32(host->ioaddr + base) >> shift) & 0xffff;
+ return ret;
+}
+
+static u8 esdhc_readb(struct sdhci_host *host, int reg)
+{
+ int base = reg & ~0x3;
+ int shift = (reg & 0x3) * 8;
+ u8 ret = (in_be32(host->ioaddr + base) >> shift) & 0xff;
return ret;
}
@@ -79,7 +89,7 @@ struct sdhci_of_data sdhci_esdhc = {
.ops = {
.read_l = sdhci_be32bs_readl,
.read_w = esdhc_readw,
- .read_b = sdhci_be32bs_readb,
+ .read_b = esdhc_readb,
.write_l = sdhci_be32bs_writel,
.write_w = esdhc_writew,
.write_b = esdhc_writeb,
--
1.6.0.6
^ permalink raw reply related
* [PATCH 2/2 v2] eSDHC: Fix errors when booting kernel with fsl esdhc
From: Roy Zang @ 2011-07-22 10:15 UTC (permalink / raw)
To: linux-mmc; +Cc: Xu lei, linuxppc-dev, akpm
In-Reply-To: <1311329717-13954-1-git-send-email-tie-fei.zang@freescale.com>
From: Xu lei <B33228@freescale.com>
When esdhc module was enabled in p5020, there were following errors:
mmc0: Timeout waiting for hardware interrupt.
mmc0: error -110 whilst initialising SD card
mmc0: Unexpected interrupt 0x02000000.
mmc0: Timeout waiting for hardware interrupt.
mmc0: error -110 whilst initialising SD card
mmc0: Unexpected interrupt 0x02000000.
It is because ESDHC controller has different bit setting for PROCTL
register, when kernel sets Power Control Register by method for standard
SD Host Specification, it would overwritten FSL ESDHC PROCTL[DMAS];
when it set Host Control Registers[DMAS], it sets PROCTL[EMODE] and
PROCTL[D3CD]. These operations will set bad bits for PROCTL Register
on FSL ESDHC Controller and cause errors, so this patch will make esdhc
driver access FSL PROCTL Register according to block guide instead of
standard SD Host Specification.
For some FSL chips, such as MPC8536/P2020, PROCTL[VOLT_SEL] and PROCTL[DMAS]
bits are reserved and even if they are set to wrong bits there is no error.
But considering that all FSL ESDHC Controller register map is not fully
compliant to standard SD Host Specification, we put the patch to all of
FSL ESDHC Controllers.
Signed-off-by: Lei Xu <B33228@freescale.com>
Signed-off-by: Roy Zang <tie-fei.zang@freescale.com>
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
---
v2:v1 some minor code style fix according to Venkatraman's comment.
drivers/mmc/host/sdhci-of-core.c | 3 ++
drivers/mmc/host/sdhci.c | 64 ++++++++++++++++++++++++++++++-------
include/linux/mmc/sdhci.h | 6 ++-
3 files changed, 59 insertions(+), 14 deletions(-)
diff --git a/drivers/mmc/host/sdhci-of-core.c b/drivers/mmc/host/sdhci-of-core.c
index 60e4186..fede43d 100644
--- a/drivers/mmc/host/sdhci-of-core.c
+++ b/drivers/mmc/host/sdhci-of-core.c
@@ -179,6 +179,9 @@ static int __devinit sdhci_of_probe(struct platform_device *ofdev)
if (sdhci_of_wp_inverted(np))
host->quirks |= SDHCI_QUIRK_INVERTED_WRITE_PROTECT;
+ if (of_device_is_compatible(np, "fsl,esdhc"))
+ host->quirks |= SDHCI_QUIRK_QORIQ_PROCTL_WEIRD;
+
clk = of_get_property(np, "clock-frequency", &size);
if (clk && size == sizeof(*clk) && *clk)
of_host->clock = be32_to_cpup(clk);
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index 58d5436..855fbe8 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -674,7 +674,7 @@ static void sdhci_set_transfer_irqs(struct sdhci_host *host)
static void sdhci_prepare_data(struct sdhci_host *host, struct mmc_command *cmd)
{
u8 count;
- u8 ctrl;
+ u32 ctrl;
struct mmc_data *data = cmd->data;
int ret;
@@ -807,14 +807,28 @@ static void sdhci_prepare_data(struct sdhci_host *host, struct mmc_command *cmd)
* is ADMA.
*/
if (host->version >= SDHCI_SPEC_200) {
- ctrl = sdhci_readb(host, SDHCI_HOST_CONTROL);
- ctrl &= ~SDHCI_CTRL_DMA_MASK;
- if ((host->flags & SDHCI_REQ_USE_DMA) &&
- (host->flags & SDHCI_USE_ADMA))
- ctrl |= SDHCI_CTRL_ADMA32;
- else
- ctrl |= SDHCI_CTRL_SDMA;
- sdhci_writeb(host, ctrl, SDHCI_HOST_CONTROL);
+ if (host->quirks & SDHCI_QUIRK_QORIQ_PROCTL_WEIRD) {
+#define ESDHCI_PROCTL_DMAS_MASK 0x00000300
+#define ESDHCI_PROCTL_ADMA32 0x00000200
+#define ESDHCI_PROCTL_SDMA 0x00000000
+ ctrl = sdhci_readl(host, SDHCI_HOST_CONTROL);
+ ctrl &= ~ESDHCI_PROCTL_DMAS_MASK;
+ if ((host->flags & SDHCI_REQ_USE_DMA) &&
+ (host->flags & SDHCI_USE_ADMA))
+ ctrl |= ESDHCI_PROCTL_ADMA32;
+ else
+ ctrl |= ESDHCI_PROCTL_SDMA;
+ sdhci_writel(host, ctrl, SDHCI_HOST_CONTROL);
+ } else {
+ ctrl = sdhci_readb(host, SDHCI_HOST_CONTROL);
+ ctrl &= ~SDHCI_CTRL_DMA_MASK;
+ if ((host->flags & SDHCI_REQ_USE_DMA) &&
+ (host->flags & SDHCI_USE_ADMA))
+ ctrl |= SDHCI_CTRL_ADMA32;
+ else
+ ctrl |= SDHCI_CTRL_SDMA;
+ sdhci_writeb(host, ctrl, SDHCI_HOST_CONTROL);
+ }
}
if (!(host->flags & SDHCI_REQ_USE_DMA)) {
@@ -1138,19 +1152,32 @@ out:
static void sdhci_set_power(struct sdhci_host *host, unsigned short power)
{
u8 pwr = 0;
+ u8 volt = 0;
if (power != (unsigned short)-1) {
switch (1 << power) {
+#define ESDHCI_FSL_POWER_MASK 0x40
+#define ESDHCI_FSL_POWER_180 0x00
+#define ESDHCI_FSL_POWER_300 0x40
case MMC_VDD_165_195:
- pwr = SDHCI_POWER_180;
+ if (host->quirks & SDHCI_QUIRK_QORIQ_PROCTL_WEIRD)
+ pwr = ESDHCI_FSL_POWER_180;
+ else
+ pwr = SDHCI_POWER_180;
break;
case MMC_VDD_29_30:
case MMC_VDD_30_31:
- pwr = SDHCI_POWER_300;
+ if (host->quirks & SDHCI_QUIRK_QORIQ_PROCTL_WEIRD)
+ pwr = ESDHCI_FSL_POWER_300;
+ else
+ pwr = SDHCI_POWER_300;
break;
case MMC_VDD_32_33:
case MMC_VDD_33_34:
- pwr = SDHCI_POWER_330;
+ if (host->quirks & SDHCI_QUIRK_QORIQ_PROCTL_WEIRD)
+ pwr = ESDHCI_FSL_POWER_300;
+ else
+ pwr = SDHCI_POWER_330;
break;
default:
BUG();
@@ -1162,6 +1189,19 @@ static void sdhci_set_power(struct sdhci_host *host, unsigned short power)
host->pwr = pwr;
+ /*
+ * FSL ESDHC Controller has no Bus Power bit,
+ * and PROCTL[21] bit is for voltage selection.
+ */
+ if (host->quirks & SDHCI_QUIRK_QORIQ_PROCTL_WEIRD) {
+ volt = sdhci_readb(host, SDHCI_POWER_CONTROL);
+ volt &= ~ESDHCI_FSL_POWER_MASK;
+ volt |= pwr;
+ sdhci_writeb(host, volt, SDHCI_POWER_CONTROL);
+
+ return;
+ }
+
if (pwr == 0) {
sdhci_writeb(host, 0, SDHCI_POWER_CONTROL);
return;
diff --git a/include/linux/mmc/sdhci.h b/include/linux/mmc/sdhci.h
index 6a68c4e..d87abc7 100644
--- a/include/linux/mmc/sdhci.h
+++ b/include/linux/mmc/sdhci.h
@@ -21,7 +21,7 @@ struct sdhci_host {
/* Data set by hardware interface driver */
const char *hw_name; /* Hardware bus name */
- unsigned int quirks; /* Deviations from spec. */
+ u64 quirks; /* Deviations from spec. */
/* Controller doesn't honor resets unless we touch the clock register */
#define SDHCI_QUIRK_CLOCK_BEFORE_RESET (1<<0)
@@ -86,7 +86,9 @@ struct sdhci_host {
/* Controller treats ADMA descriptors with length 0000h incorrectly */
#define SDHCI_QUIRK_BROKEN_ADMA_ZEROLEN_DESC (1<<30)
/* The read-only detection via SDHCI_PRESENT_STATE register is unstable */
-#define SDHCI_QUIRK_UNSTABLE_RO_DETECT (1<<31)
+#define SDHCI_QUIRK_UNSTABLE_RO_DETECT (1U<<31)
+/* Controller has weird bit setting for Protocol Control Register */
+#define SDHCI_QUIRK_QORIQ_PROCTL_WEIRD (0x100000000U)
int irq; /* Device IRQ */
void __iomem *ioaddr; /* Mapped address */
--
1.6.0.6
^ permalink raw reply related
* RE: [PATCH 2/4] powerpc/85xx: enable pcie initialization for P4080
From: Xie Shaohui-B21989 @ 2011-07-22 10:09 UTC (permalink / raw)
To: Gala Kumar-B11780; +Cc: linuxppc-dev@lists.ozlabs.org
In-Reply-To: <D08A7FEC-DF4F-4EF3-B064-13E91242EF91@freescale.com>
>-----Original Message-----
>From: Gala Kumar-B11780
>Sent: Friday, July 22, 2011 2:06 PM
>To: Xie Shaohui-B21989
>Cc: linuxppc-dev@lists.ozlabs.org
>Subject: Re: [PATCH 2/4] powerpc/85xx: enable pcie initialization for
>P4080
>
>
>On Jul 21, 2011, at 5:25 AM, Shaohui Xie wrote:
>
>> Signed-off-by: Shaohui Xie <Shaohui.Xie@freescale.com>
>> ---
>> arch/powerpc/platforms/85xx/corenet_ds.c | 3 +++
>> 1 files changed, 3 insertions(+), 0 deletions(-)
>>
>> diff --git a/arch/powerpc/platforms/85xx/corenet_ds.c
>b/arch/powerpc/platforms/85xx/corenet_ds.c
>> index 2ab338c..15247b0 100644
>> --- a/arch/powerpc/platforms/85xx/corenet_ds.c
>> +++ b/arch/powerpc/platforms/85xx/corenet_ds.c
>> @@ -114,6 +114,9 @@ static const struct of_device_id of_device_ids[]
>__devinitconst =3D {
>> .compatible =3D "simple-bus"
>> },
>> {
>> + .compatible =3D "fsl,p4080-pcie"
>> + },
>> + {
>> .compatible =3D "fsl,rapidio-delta",
>> },
>> {}
>> --
>> 1.6.4
>>
>
>What about p204x, p3041 & p5020 boards?
>
[Xie Shaohui] I've check the galak/powerpc.git 'next' branch, this patch is=
not needed, please ignore it.
Best Regards,=20
Shaohui Xie
^ permalink raw reply
* Re: [PATCH 2/2 v2] eSDHC: Fix errors when booting kernel with fsl esdhc
From: Anton Vorontsov @ 2011-07-22 10:15 UTC (permalink / raw)
To: Roy Zang; +Cc: linuxppc-dev, akpm, linux-mmc, Xu lei
In-Reply-To: <1311329717-13954-2-git-send-email-tie-fei.zang@freescale.com>
On Fri, Jul 22, 2011 at 06:15:17PM +0800, Roy Zang wrote:
[...]
> if (host->version >= SDHCI_SPEC_200) {
> - ctrl = sdhci_readb(host, SDHCI_HOST_CONTROL);
> - ctrl &= ~SDHCI_CTRL_DMA_MASK;
> - if ((host->flags & SDHCI_REQ_USE_DMA) &&
> - (host->flags & SDHCI_USE_ADMA))
> - ctrl |= SDHCI_CTRL_ADMA32;
> - else
> - ctrl |= SDHCI_CTRL_SDMA;
> - sdhci_writeb(host, ctrl, SDHCI_HOST_CONTROL);
> + if (host->quirks & SDHCI_QUIRK_QORIQ_PROCTL_WEIRD) {
> +#define ESDHCI_PROCTL_DMAS_MASK 0x00000300
> +#define ESDHCI_PROCTL_ADMA32 0x00000200
> +#define ESDHCI_PROCTL_SDMA 0x00000000
> + ctrl = sdhci_readl(host, SDHCI_HOST_CONTROL);
> + ctrl &= ~ESDHCI_PROCTL_DMAS_MASK;
> + if ((host->flags & SDHCI_REQ_USE_DMA) &&
> + (host->flags & SDHCI_USE_ADMA))
> + ctrl |= ESDHCI_PROCTL_ADMA32;
> + else
> + ctrl |= ESDHCI_PROCTL_SDMA;
> + sdhci_writel(host, ctrl, SDHCI_HOST_CONTROL);
> + } else {
> + ctrl = sdhci_readb(host, SDHCI_HOST_CONTROL);
> + ctrl &= ~SDHCI_CTRL_DMA_MASK;
> + if ((host->flags & SDHCI_REQ_USE_DMA) &&
> + (host->flags & SDHCI_USE_ADMA))
> + ctrl |= SDHCI_CTRL_ADMA32;
> + else
> + ctrl |= SDHCI_CTRL_SDMA;
> + sdhci_writeb(host, ctrl, SDHCI_HOST_CONTROL);
We try to not pollute generic sdhci.c driver with chip-specific
quirks.
Maybe you can do the fixups via IO accessors? Or by introducing
some additional sdhci op?
[...]
> if (power != (unsigned short)-1) {
> switch (1 << power) {
> +#define ESDHCI_FSL_POWER_MASK 0x40
> +#define ESDHCI_FSL_POWER_180 0x00
> +#define ESDHCI_FSL_POWER_300 0x40
Same here. The driver will rot quickly if everyone would start
putting chip-specific quirks into sdhci.c. Please don't.
Thanks,
--
Anton Vorontsov
Email: cbouatmailru@gmail.com
^ permalink raw reply
* [PATCH 0/1] Remove obsolete HCU4 board
From: Niklaus Giger @ 2011-07-22 10:40 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Paul Mackerras
I left Netstal Maschinen a couple of months ago. As I could never convince
my boss to give embedded Linux a real try, I would like to remove support
for this embedded board. I was the only user.
Many thanks for the friendly help I received on this list when I submitted
the patches for this board!
Patch is based on
git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git
Niklaus Giger (1):
Remove obsolete HCU4 board
arch/powerpc/boot/dts/hcu4.dts | 168
-------------------------------
arch/powerpc/configs/40x/hcu4_defconfig | 80 ---------------
arch/powerpc/platforms/40x/hcu4.c | 61 -----------
3 files changed, 0 insertions(+), 309 deletions(-)
delete mode 100644 arch/powerpc/boot/dts/hcu4.dts
delete mode 100644 arch/powerpc/configs/40x/hcu4_defconfig
delete mode 100644 arch/powerpc/platforms/40x/hcu4.c
--
1.7.5.4
^ permalink raw reply
* [PATCH 1/1] Remove obsolete HCU4 board
From: Niklaus Giger @ 2011-07-22 10:41 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Paul Mackerras
Signed-off-by: Niklaus Giger <niklaus.giger@member.fsf.org>
---
arch/powerpc/boot/dts/hcu4.dts | 168
-------------------------------
arch/powerpc/configs/40x/hcu4_defconfig | 80 ---------------
arch/powerpc/platforms/40x/hcu4.c | 61 -----------
3 files changed, 0 insertions(+), 309 deletions(-)
delete mode 100644 arch/powerpc/boot/dts/hcu4.dts
delete mode 100644 arch/powerpc/configs/40x/hcu4_defconfig
delete mode 100644 arch/powerpc/platforms/40x/hcu4.c
diff --git a/arch/powerpc/boot/dts/hcu4.dts b/arch/powerpc/boot/dts/hcu4.dts
deleted file mode 100644
index 7988598..0000000
--- a/arch/powerpc/boot/dts/hcu4.dts
+++ /dev/null
@@ -1,168 +0,0 @@
-/*
-* Device Tree Source for Netstal Maschinen HCU4
-* based on the IBM Walnut
-*
-* Copyright 2008
-* Niklaus Giger <niklaus.giger@member.fsf.org>
-*
-* Copyright 2007 IBM Corp.
-* Josh Boyer <jwboyer@linux.vnet.ibm.com>
-*
-* This file is licensed under the terms of the GNU General Public
-* License version 2. This program is licensed "as is" without
-* any warranty of any kind, whether express or implied.
-*/
-
-/dts-v1/;
-
-/ {
- #address-cells = <0x1>;
- #size-cells = <0x1>;
- model = "netstal,hcu4";
- compatible = "netstal,hcu4";
- dcr-parent = <0x1>;
-
- aliases {
- ethernet0 = "/plb/opb/ethernet@ef600800";
- serial0 = "/plb/opb/serial@ef600300";
- };
-
- cpus {
- #address-cells = <0x1>;
- #size-cells = <0x0>;
-
- cpu@0 {
- device_type = "cpu";
- model = "PowerPC,405GPr";
- reg = <0x0>;
- clock-frequency = <0>; /* Filled in by U-Boot */
- timebase-frequency = <0x0>; /* Filled in by U-Boot */
- i-cache-line-size = <0x20>;
- d-cache-line-size = <0x20>;
- i-cache-size = <0x4000>;
- d-cache-size = <0x4000>;
- dcr-controller;
- dcr-access-method = "native";
- linux,phandle = <0x1>;
- };
- };
-
- memory {
- device_type = "memory";
- reg = <0x0 0x0>; /* Filled in by U-Boot */
- };
-
- UIC0: interrupt-controller {
- compatible = "ibm,uic";
- interrupt-controller;
- cell-index = <0x0>;
- dcr-reg = <0xc0 0x9>;
- #address-cells = <0x0>;
- #size-cells = <0x0>;
- #interrupt-cells = <0x2>;
- linux,phandle = <0x2>;
- };
-
- plb {
- compatible = "ibm,plb3";
- #address-cells = <0x1>;
- #size-cells = <0x1>;
- ranges;
- clock-frequency = <0x0>; /* Filled in by U-Boot */
-
- SDRAM0: memory-controller {
- compatible = "ibm,sdram-405gp";
- dcr-reg = <0x10 0x2>;
- };
-
- MAL: mcmal {
- compatible = "ibm,mcmal-405gp", "ibm,mcmal";
- dcr-reg = <0x180 0x62>;
- num-tx-chans = <0x1>;
- num-rx-chans = <0x1>;
- interrupt-parent = <0x2>;
- interrupts = <0xb 0x4 0xc 0x4 0xa 0x4 0xd 0x4 0xe 0x4>;
- linux,phandle = <0x3>;
- };
-
- POB0: opb {
- compatible = "ibm,opb-405gp", "ibm,opb";
- #address-cells = <0x1>;
- #size-cells = <0x1>;
- ranges = <0xef600000 0xef600000 0xa00000>;
- dcr-reg = <0xa0 0x5>;
- clock-frequency = <0x0>; /* Filled in by U-Boot */
-
- UART0: serial@ef600300 {
- device_type = "serial";
- compatible = "ns16550";
- reg = <0xef600300 0x8>;
- virtual-reg = <0xef600300>;
- clock-frequency = <0x0>;/* Filled in by U-Boot */
- current-speed = <0>; /* Filled in by U-Boot */
- interrupt-parent = <0x2>;
- interrupts = <0x0 0x4>;
- };
-
- IIC: i2c@ef600500 {
- compatible = "ibm,iic-405gp", "ibm,iic";
- reg = <0xef600500 0x11>;
- interrupt-parent = <0x2>;
- interrupts = <0x2 0x4>;
- };
-
- GPIO: gpio@ef600700 {
- compatible = "ibm,gpio-405gp";
- reg = <0xef600700 0x20>;
- };
-
- EMAC: ethernet@ef600800 {
- device_type = "network";
- compatible = "ibm,emac-405gp", "ibm,emac";
- interrupt-parent = <0x2>;
- interrupts = <0xf 0x4 0x9 0x4>;
- local-mac-address = [00 00 00 00 00 00];
- reg = <0xef600800 0x70>;
- mal-device = <0x3>;
- mal-tx-channel = <0x0>;
- mal-rx-channel = <0x0>;
- cell-index = <0x0>;
- max-frame-size = <0x5dc>;
- rx-fifo-size = <0x1000>;
- tx-fifo-size = <0x800>;
- phy-mode = "rmii";
- phy-map = <0x1>;
- };
- };
-
- EBC0: ebc {
- compatible = "ibm,ebc-405gp", "ibm,ebc";
- dcr-reg = <0x12 0x2>;
- #address-cells = <0x2>;
- #size-cells = <0x1>;
- clock-frequency = <0x0>; /* Filled in by U-Boot */
-
- sram@0,0 {
- reg = <0x0 0x0 0x80000>;
- };
-
- flash@0,80000 {
- compatible = "jedec-flash";
- bank-width = <0x1>;
- reg = <0x0 0x80000 0x80000>;
- #address-cells = <0x1>;
- #size-cells = <0x1>;
-
- partition@0 {
- label = "OpenBIOS";
- reg = <0x0 0x80000>;
- read-only;
- };
- };
- };
- };
-
- chosen {
- linux,stdout-path = "/plb/opb/serial@ef600300";
- };
-};
diff --git a/arch/powerpc/configs/40x/hcu4_defconfig
b/arch/powerpc/configs/40x/hcu4_defconfig
deleted file mode 100644
index ebeb4ac..0000000
--- a/arch/powerpc/configs/40x/hcu4_defconfig
+++ /dev/null
@@ -1,80 +0,0 @@
-CONFIG_40x=y
-CONFIG_EXPERIMENTAL=y
-CONFIG_SYSVIPC=y
-CONFIG_POSIX_MQUEUE=y
-CONFIG_LOG_BUF_SHIFT=14
-CONFIG_BLK_DEV_INITRD=y
-# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
-CONFIG_EXPERT=y
-CONFIG_KALLSYMS_ALL=y
-CONFIG_KALLSYMS_EXTRA_PASS=y
-CONFIG_MODULES=y
-CONFIG_MODULE_UNLOAD=y
-# CONFIG_BLK_DEV_BSG is not set
-CONFIG_HCU4=y
-# CONFIG_WALNUT is not set
-CONFIG_SPARSE_IRQ=y
-CONFIG_PCI=y
-CONFIG_NET=y
-CONFIG_PACKET=y
-CONFIG_UNIX=y
-CONFIG_INET=y
-CONFIG_IP_PNP=y
-CONFIG_IP_PNP_DHCP=y
-CONFIG_IP_PNP_BOOTP=y
-# CONFIG_INET_XFRM_MODE_TRANSPORT is not set
-# CONFIG_INET_XFRM_MODE_TUNNEL is not set
-# CONFIG_INET_XFRM_MODE_BEET is not set
-# CONFIG_INET_LRO is not set
-# CONFIG_IPV6 is not set
-CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug"
-CONFIG_CONNECTOR=y
-CONFIG_MTD=y
-CONFIG_MTD_PARTITIONS=y
-CONFIG_MTD_CMDLINE_PARTS=y
-CONFIG_MTD_OF_PARTS=y
-CONFIG_MTD_CHAR=y
-CONFIG_MTD_BLOCK=m
-CONFIG_MTD_CFI=y
-CONFIG_MTD_JEDECPROBE=y
-CONFIG_MTD_CFI_AMDSTD=y
-CONFIG_MTD_PHYSMAP_OF=y
-CONFIG_PROC_DEVICETREE=y
-CONFIG_BLK_DEV_RAM=y
-CONFIG_BLK_DEV_RAM_SIZE=35000
-CONFIG_NETDEVICES=y
-CONFIG_NET_ETHERNET=y
-CONFIG_IBM_NEW_EMAC=y
-# CONFIG_INPUT is not set
-# CONFIG_SERIO is not set
-# CONFIG_VT is not set
-CONFIG_SERIAL_8250=y
-CONFIG_SERIAL_8250_CONSOLE=y
-CONFIG_SERIAL_8250_EXTENDED=y
-CONFIG_SERIAL_8250_SHARE_IRQ=y
-CONFIG_SERIAL_OF_PLATFORM=y
-# CONFIG_HW_RANDOM is not set
-# CONFIG_HWMON is not set
-CONFIG_VIDEO_OUTPUT_CONTROL=m
-# CONFIG_USB_SUPPORT is not set
-CONFIG_EXT2_FS=y
-CONFIG_INOTIFY=y
-CONFIG_PROC_KCORE=y
-CONFIG_TMPFS=y
-CONFIG_CRAMFS=y
-CONFIG_NFS_FS=y
-CONFIG_NFS_V3=y
-CONFIG_ROOT_NFS=y
-CONFIG_MAGIC_SYSRQ=y
-CONFIG_DEBUG_FS=y
-CONFIG_DEBUG_KERNEL=y
-CONFIG_DETECT_HUNG_TASK=y
-# CONFIG_RCU_CPU_STALL_DETECTOR is not set
-CONFIG_SYSCTL_SYSCALL_CHECK=y
-CONFIG_CRYPTO=y
-CONFIG_CRYPTO_CBC=y
-CONFIG_CRYPTO_ECB=y
-CONFIG_CRYPTO_PCBC=y
-CONFIG_CRYPTO_MD5=y
-CONFIG_CRYPTO_DES=y
-# CONFIG_CRYPTO_ANSI_CPRNG is not set
diff --git a/arch/powerpc/platforms/40x/hcu4.c
b/arch/powerpc/platforms/40x/hcu4.c
deleted file mode 100644
index 60b2afe..0000000
--- a/arch/powerpc/platforms/40x/hcu4.c
+++ /dev/null
@@ -1,61 +0,0 @@
-/*
- * Architecture- / platform-specific boot-time initialization code for
- * IBM PowerPC 4xx based boards. Adapted from original
- * code by Gary Thomas, Cort Dougan <cort@fsmlabs.com>, and Dan Malek
- * <dan@net4x.com>.
- *
- * Copyright(c) 1999-2000 Grant Erickson <grant@lcse.umn.edu>
- *
- * Rewritten and ported to the merged powerpc tree:
- * Copyright 2007 IBM Corporation
- * Josh Boyer <jwboyer@linux.vnet.ibm.com>
- *
- * 2002 (c) MontaVista, Software, Inc. This file is licensed under
- * the terms of the GNU General Public License version 2. This program
- * is licensed "as is" without any warranty of any kind, whether express
- * or implied.
- */
-
-#include <linux/init.h>
-#include <linux/of_platform.h>
-
-#include <asm/machdep.h>
-#include <asm/prom.h>
-#include <asm/udbg.h>
-#include <asm/time.h>
-#include <asm/uic.h>
-#include <asm/ppc4xx.h>
-
-static __initdata struct of_device_id hcu4_of_bus[] = {
- { .compatible = "ibm,plb3", },
- { .compatible = "ibm,opb", },
- { .compatible = "ibm,ebc", },
- {},
-};
-
-static int __init hcu4_device_probe(void)
-{
- of_platform_bus_probe(NULL, hcu4_of_bus, NULL);
- return 0;
-}
-machine_device_initcall(hcu4, hcu4_device_probe);
-
-static int __init hcu4_probe(void)
-{
- unsigned long root = of_get_flat_dt_root();
-
- if (!of_flat_dt_is_compatible(root, "netstal,hcu4"))
- return 0;
-
- return 1;
-}
-
-define_machine(hcu4) {
- .name = "HCU4",
- .probe = hcu4_probe,
- .progress = udbg_progress,
- .init_IRQ = uic_init_tree,
- .get_irq = uic_get_irq,
- .restart = ppc4xx_reset_system,
- .calibrate_decr = generic_calibrate_decr,
-};
--
1.7.5.4
^ permalink raw reply related
* Re: [PATCH 0/1] Remove obsolete HCU4 board
From: Josh Boyer @ 2011-07-22 10:55 UTC (permalink / raw)
To: Niklaus Giger; +Cc: Paul Mackerras, linuxppc-dev
In-Reply-To: <201107221240.59517.niklaus.giger@member.fsf.org>
On Fri, Jul 22, 2011 at 6:40 AM, Niklaus Giger
<niklaus.giger@member.fsf.org> wrote:
>
> I left Netstal Maschinen a couple of months ago. As I could never convince
> my boss to give embedded Linux a real try, I would like to remove support
> for this embedded board. I was the only user.
>
> Many thanks for the friendly help I received on this list when I submitted
> the patches for this board!
I'll add this to my tree shortly.
josh
^ permalink raw reply
* Re: [PATCH 4/4] edac/85xx: PCI/PCIE error interrupt edac support.
From: Stijn Devriendt @ 2011-07-22 11:23 UTC (permalink / raw)
To: Shaohui Xie
Cc: mm-commits, kumar.gala, avorontsov, Kai.Jiang, akpm, linuxppc-dev,
davem
In-Reply-To: <1311244404-4463-1-git-send-email-Shaohui.Xie@freescale.com>
On Thu, Jul 21, 2011 at 12:33 PM, Shaohui Xie <Shaohui.Xie@freescale.com> wrote:
> From: Kai.Jiang <Kai.Jiang@freescale.com>
>
> Add pcie error interrupt edac support for mpc85xx and p4080.
> mpc85xx uses the legacy interrupt report mechanism - the error
> interrupts are reported directly to mpic. While, p4080 attaches
> most of error interrupts to interrupt 0. And report error interrupt
> to mpic via interrupt 0. This patch can handle both of them.
>
> Due to the error management register offset and definition
>
> difference between pci and pcie, use ccsr_pci structure to merge
> pci and pcie edac code into one.
>
This code has been posted a couple of months ago, if I'm not mistaken.
I'm currently testing it on a P2020 based design.
One of the failures I'm trying to cope with is a PCIe device that does not
send back a completion with data. e.g. a userspace process reads memory
through a memory map, but the PCIe device is not responding.
In this case the P2020 will stall due to the core_fault_in being asserted.
If configured, this interrupt will be called, but it does nothing to cure the
root cause (e.g. kill the process). End result is that the processor still
hangs.
I've been hacking my way around the kernel for a while and ended up a lot
closer to a working solution to recover from such a failure.
The issue I'm facing now is that the PIC can be configured to send the
interrupt as a critical interrupt to one of both cores, but that may not
be the core that is running the process that initiated the read.
I've done 2 test-runs and both killed the right process, but I'd like to make
sure that it's not by accident.
Bottom-line: what mechanisms are in place (or are required) to ensure
that the the right process (on the same core or on another core) is killed
regardless of how the PIC is configured?
Regards,
Stijn
^ permalink raw reply
* RFC fsl_elbc_nand.c does not update mtd->ecc_stats
From: Michael Hench @ 2011-07-22 13:06 UTC (permalink / raw)
To: linux-mtd, linuxppc-dev; +Cc: MatthewLCreech, mhench
when using the fsl_elbc_nand driver, mtd->ecc_stats does not appear to
get updated
UBI uses this to determine when to scrub blocks
the patch below appears to fix this (draft 0)
am I missing anything?
does this look reasonable?
diff -purN orig/drivers/mtd/nand/fsl_elbc_nand.c
linux-3.0-rc7/drivers/mtd/nand/fsl_elbc_nand.c
--- orig/drivers/mtd/nand/fsl_elbc_nand.c 2011-07-22 07:02:37.908778052 -0500
+++ linux-3.0-rc7/drivers/mtd/nand/fsl_elbc_nand.c 2011-07-22
06:56:09.655002047 -0500
@@ -748,12 +748,43 @@ static int fsl_elbc_read_page(struct mtd
uint8_t *buf,
int page)
{
+ struct fsl_elbc_mtd *priv = chip->priv;
+ struct fsl_lbc_ctrl *ctrl = priv->ctrl;
+ struct fsl_lbc_regs __iomem *lbc = ctrl->regs;
+ uint32_t lteccr;
+
fsl_elbc_read_buf(mtd, buf, mtd->writesize);
fsl_elbc_read_buf(mtd, chip->oob_poi, mtd->oobsize);
if (fsl_elbc_wait(mtd, chip) & NAND_STATUS_FAIL)
mtd->ecc_stats.failed++;
+ if(chip->ecc.mode != NAND_ECC_HW)
+ return(0);
+
+ /* get the hardware ECC results */
+ lteccr = in_be32(&lbc->lteccr);
+ if(lteccr & 0x000F000F) {
+ int i;
+
+ out_be32(&lbc->lteccr, -1); /* clear lteccr */
+ printk(KERN_ERR "ECC RESULT %x n=%d",
+ lteccr, mtd->ecc_stats.corrected);
+ /*
+ * 4 bits, one for each 512 byte subpage
+ * 12-15 (ppc order) are for successfully corrected
+ * 28-31 are for failed
+ * small page nand has 3 bits set to zero in each field
+ */
+ for(i=0; i < 4; i++) {
+ if(lteccr & 0x10000)
+ mtd->ecc_stats.corrected++;
+ if(lteccr & 0x1)
+ mtd->ecc_stats.failed++;
+ lteccr >>= 1;
+ }
+ }
+
return 0;
}
^ permalink raw reply
* Re: RFC fsl_elbc_nand.c does not update mtd->ecc_stats
From: Scott Wood @ 2011-07-22 18:49 UTC (permalink / raw)
To: Michael Hench; +Cc: linuxppc-dev, MatthewLCreech, linux-mtd, mhench
In-Reply-To: <CAHyXW60RcO4poP8VXkm5Q0+9ACui1i_og2kDis8RKs=pxKB18w@mail.gmail.com>
On Fri, 22 Jul 2011 08:06:53 -0500
Michael Hench <michaelhench@gmail.com> wrote:
> when using the fsl_elbc_nand driver, mtd->ecc_stats does not appear to
> get updated
It gets updated for uncorrectable errors (so no need to use lteccr for
that), but not correctable.
> diff -purN orig/drivers/mtd/nand/fsl_elbc_nand.c
> linux-3.0-rc7/drivers/mtd/nand/fsl_elbc_nand.c
> --- orig/drivers/mtd/nand/fsl_elbc_nand.c 2011-07-22 07:02:37.908778052 -0500
> +++ linux-3.0-rc7/drivers/mtd/nand/fsl_elbc_nand.c 2011-07-22
> 06:56:09.655002047 -0500
> @@ -748,12 +748,43 @@ static int fsl_elbc_read_page(struct mtd
> uint8_t *buf,
> int page)
> {
> + struct fsl_elbc_mtd *priv = chip->priv;
> + struct fsl_lbc_ctrl *ctrl = priv->ctrl;
> + struct fsl_lbc_regs __iomem *lbc = ctrl->regs;
> + uint32_t lteccr;
> +
> fsl_elbc_read_buf(mtd, buf, mtd->writesize);
> fsl_elbc_read_buf(mtd, chip->oob_poi, mtd->oobsize);
>
> if (fsl_elbc_wait(mtd, chip) & NAND_STATUS_FAIL)
> mtd->ecc_stats.failed++;
>
> + if(chip->ecc.mode != NAND_ECC_HW)
> + return(0);
> +
> + /* get the hardware ECC results */
> + lteccr = in_be32(&lbc->lteccr);
Older versions of eLBC have LTECCR, though on the ones that don't have it,
it appears to read as zero and not be modifyable, so it shouldn't make
anything worse.
> + if(lteccr & 0x000F000F) {
> + int i;
> +
> + out_be32(&lbc->lteccr, -1); /* clear lteccr */
We should read and clear lteccr in fsl_elbc_run_command, and test the
stored value here. That way we don't have leftover bits set in lteccr from
a read that didn't use read_page (such as MTD_OOB_RAW).
> + printk(KERN_ERR "ECC RESULT %x n=%d",
> + lteccr, mtd->ecc_stats.corrected);
I assume this is temporary?
-Scott
^ permalink raw reply
* Re: [PATCH] [v3] tty/powerpc: introduce the ePAPR embedded hypervisor byte channel driver
From: Tabi Timur-B04825 @ 2011-07-22 19:00 UTC (permalink / raw)
To: greg@kroah.com
Cc: linuxppc-dev@ozlabs.org, linux-kernel@vger.kernel.org,
linux-console@vger.kernel.org
In-Reply-To: <1310169972-13756-1-git-send-email-timur@freescale.com>
On Fri, Jul 8, 2011 at 7:06 PM, Timur Tabi <timur@freescale.com> wrote:
> The ePAPR embedded hypervisor specification provides an API for "byte
> channels", which are serial-like virtual devices for sending and receivin=
g
> streams of bytes. =A0This driver provides Linux kernel support for byte
> channels via three distinct interfaces:
>
> 1) An early-console (udbg) driver. =A0This provides early console output
> through a byte channel. =A0The byte channel handle must be specified in a
> Kconfig option.
>
> 2) A normal console driver. =A0Output is sent to the byte channel designa=
ted
> for stdout in the device tree. =A0The console driver is for handling kern=
el
> printk calls.
>
> 3) A tty driver, which is used to handle user-space input and output. =A0=
The
> byte channel used for the console is designated as the default tty.
>
> Signed-off-by: Timur Tabi <timur@freescale.com>
> ---
Greg,
I just want to make sure you haven't forgotten this patch. Will you
be picking it up for 3.1?
--=20
Timur Tabi
Linux kernel developer at Freescale=
^ 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