when platform_driver_register broken, we should unregister ucc_uart_driver
Signed-off-by: Libo chen
---
drivers/tty/serial/ucc_uart.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/drivers/tty/serial/ucc_uart.c b/drivers/tty/serial/ucc_uart.c
index 7355303..f86f447
Libo Chen wrote:
when platform_driver_register broken, we should unregister ucc_uart_driver
Signed-off-by: Libo chen
Acked-by: Timur Tabi
Thanks for catching this.
--
Timur Tabi
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://l
On Tue, 2013-05-28 at 12:41 -0500, Scott Wood wrote:
> I believe Alex is staying far away from e-mail on his vacation. He's
> asked me to fill in for him while he's gone.
>
> The patch itself seems reasonable (though I don't know much about XICS,
> and do have one question...), but I'll leav
On 05/29/2013 02:32 AM, Scott Wood wrote:
> On 05/24/2013 09:45:24 PM, David Gibson wrote:
>> On Wed, May 22, 2013 at 04:06:57PM -0500, Scott Wood wrote:
>> > On 05/20/2013 10:06:46 PM, Alexey Kardashevskiy wrote:
>> > >diff --git a/arch/powerpc/kvm/powerpc.c b/arch/powerpc/kvm/powerpc.c
>> > >inde
On 05/29/2013 09:35 AM, Scott Wood wrote:
> On 05/28/2013 06:30:40 PM, Alexey Kardashevskiy wrote:
>> >> >>> @@ -939,6 +940,9 @@ struct kvm_s390_ucas_mapping {
>> >> >>> #define KVM_GET_DEVICE_ATTR _IOW(KVMIO, 0xe2, struct
>> >> >>> kvm_device_attr)
>> >> >>> #define KVM_HAS_DEVICE_ATTR
On 05/28/2013 06:30:40 PM, Alexey Kardashevskiy wrote:
>> >>> @@ -939,6 +940,9 @@ struct kvm_s390_ucas_mapping {
>> >>> #define KVM_GET_DEVICE_ATTR _IOW(KVMIO, 0xe2, struct
>> >>> kvm_device_attr)
>> >>> #define KVM_HAS_DEVICE_ATTR _IOW(KVMIO, 0xe3, struct
>> >>> kvm_device_attr)
>> >
On 05/29/2013 03:45 AM, Scott Wood wrote:
> On 05/26/2013 09:44:24 PM, Alexey Kardashevskiy wrote:
>> On 05/25/2013 12:45 PM, David Gibson wrote:
>> > On Wed, May 22, 2013 at 04:06:57PM -0500, Scott Wood wrote:
>> >> On 05/20/2013 10:06:46 PM, Alexey Kardashevskiy wrote:
>> >>> diff --git a/arch/po
Hi Geert,
On Fri, 2013-05-17 at 18:05 +0200, Geert Uytterhoeven wrote:
> On Thu, May 9, 2013 at 12:36 PM, Denis Efremov
> wrote:
> > -inline u64 ps3_get_spe_id(void *arg)
> > +u64 ps3_get_spe_id(void *arg)
> > {
> > return spu_pdata(arg)->spe_id;
> > }
>
> FYI, this symbol is not used
On 05/21/2013 07:04:58 AM, Kevin Hao wrote:
It also seems that we don't support ISA on all the current corenet ds
boards. So picking a primary bus seems useless, remove that function
too.
IIRC that was due to some bugs in the PPC PCI code in the absence of
any primary bus. fsl_pci_assign_pri
On 05/16/2013 01:29:45 AM, Kevin Hao wrote:
All these boards use the same configuration file p1_p2_rdb_pc.h in
u-boot. So they have the same pci bus address set by the u-boot.
But in some of these boards the bus address set in dtb don't match
the one used by u-boot. And this will trigger a kernel
Commit 37f02195b (powerpc/pci: fix PCI-e devices rescan issue on powerpc
platform) fixes a problem with interrupt and DMA initialization on hot
plugged devices. With this commit, interrupt and DMA initialization for
hot plugged devices is handled in the pci device enable function.
This approach ha
Maynard informed me that neither the oprofile kernel module nor oprofile
userspace has been updated to support that "legacy" oprofile module
interface for power8, which is indicated by "ppc64/power8." This results
in no samples. The solution is to default to the "timer" type, instead.
The raw entry
Jason,
Sorry, I meant to get back to this earlier and it slipped off of my
plate. :(
On Fri, May 24, 2013 at 11:33:06AM -0600, Jason Gunthorpe wrote:
> On Fri, May 24, 2013 at 12:46:36PM -0400, Jason Cooper wrote:
>
> > > Why are you not keen on this? It seems like normal device driver
> > > pra
On 05/26/2013 09:44:24 PM, Alexey Kardashevskiy wrote:
On 05/25/2013 12:45 PM, David Gibson wrote:
> On Wed, May 22, 2013 at 04:06:57PM -0500, Scott Wood wrote:
>> On 05/20/2013 10:06:46 PM, Alexey Kardashevskiy wrote:
>>> diff --git a/arch/powerpc/kvm/powerpc.c
b/arch/powerpc/kvm/powerpc.c
>>
On 05/23/2013 08:42:21 PM, Paul Mackerras wrote:
This adds the remaining two hypercalls defined by PAPR for
manipulating
the XICS interrupt controller, H_IPOLL and H_XIRR_X. H_IPOLL returns
information about the priority and pending interrupts for a virtual
cpu, without changing any state. H_
On Tuesday 28 May 2013, H. Peter Anvin wrote:
> On 05/28/2013 08:43 AM, Arnd Bergmann wrote:
> >
> > Right, that is what the patch I just posted does.
> >
> > On a related note, I found that WARN_ON() can no longer be compiled
> > out since there is already code that relies on the side-effects of
On 05/24/2013 09:45:24 PM, David Gibson wrote:
On Wed, May 22, 2013 at 04:06:57PM -0500, Scott Wood wrote:
> On 05/20/2013 10:06:46 PM, Alexey Kardashevskiy wrote:
> >diff --git a/arch/powerpc/kvm/powerpc.c
b/arch/powerpc/kvm/powerpc.c
> >index 8465c2a..da6bf61 100644
> >--- a/arch/powerpc/kvm
On 05/28/2013 08:43 AM, Arnd Bergmann wrote:
>
> Right, that is what the patch I just posted does.
>
> On a related note, I found that WARN_ON() can no longer be compiled
> out since there is already code that relies on the side-effects of
> the condition. I assume that was an intentional change
On Tuesday 28 May 2013, H. Peter Anvin wrote:
> On 05/28/2013 01:19 AM, Ingo Molnar wrote:
> >
> > So I think the same principle applies to it as to any other debugging
> > code: it's fine to be able to turn debugging off. It's a performance
> > versus kernel robustness/determinism trade-off.
>
On 05/28/2013 01:19 AM, Ingo Molnar wrote:
>
> So I think the same principle applies to it as to any other debugging
> code: it's fine to be able to turn debugging off. It's a performance
> versus kernel robustness/determinism trade-off.
>
I suspect, rather, that BUG() should turn into a trap
On Tuesday 28 May 2013 10:19:10 Ingo Molnar wrote:
>
> * Russell King - ARM Linux wrote:
>
> > So, if you want to use this, then you should update the CONFIG_BUG text
> > to include a warning to this effect:
> >
> > Warning: if CONFIG_BUG is turned off, and control flow reaches
> > a
On 05/28/2013 04:19 PM, Ingo Molnar wrote:
>> > And I come back to one of my previous arguments - is it not better to
>> > panic() if we hit one of these conditions so that the system can try to
>> > do a panic-reboot rather than continue blindly into the unknown?
> It will often continue blindly
* Russell King - ARM Linux wrote:
> So, if you want to use this, then you should update the CONFIG_BUG text
> to include a warning to this effect:
>
> Warning: if CONFIG_BUG is turned off, and control flow reaches
> a BUG(), the system behaviour will be undefined.
>
> so that people
Some features depend on the boot cpu, for instance, hibernate/suspend.
So disable hotplug for the boot cpu.
Signed-off-by: Zhao Chenhui
---
arch/powerpc/kernel/sysfs.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/kernel/sysfs.c b/arch/powerpc/kernel/sy
For the mpic with a flag MPIC_SINGLE_DEST_CPU, only one bit should be
set in interrupt destination registers.
The code is applicable to 64-bit platforms as well as 32-bit.
Signed-off-by: Zhao Chenhui
---
arch/powerpc/sysdev/mpic.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
d
25 matches
Mail list logo
