* Re: Relocating bootwrapper causes kernel panic
From: Shawn Jin @ 2010-08-05 7:23 UTC (permalink / raw)
To: ppcdev
In-Reply-To: <AANLkTin3u=U-L2grncS_UtWqkGnb9bNUy4a4nqkRhQQ9@mail.gmail.com>
>> The flat tree located at 0xbe4300 as the kerne message showed. Why
>> cannot the kernel access this area? No TLB set for this area?
>>
>> <1>Unable to handle kernel paging request for data at address 0xc0be4308
>> <1>Faulting instruction address: 0xc01fdabc
>> <4>Oops: Kernel access of bad area, sig: 11 [#1]
>
> Before the flat tree was accessed, I checked the DTLB and didn't find
> any entry related to 0xc0be4300. After the exception, I found the
> following DTLBs.
>
> 30 : 02 =A0c0be4000 =A0 4KB ------ -> 00000000
> 31 : 00 =A0fa000000 =A0 8MB VI-S-M -> fa000000
>
> The DTLB#30 doesn't seem right. Why would it map to 0x0? I think this
> should be something like 00be4000?
When the early_debug is enabled, the kernel can boot successfully. I
checked the TLB settings and found the following.
28 : 00 c0000000 8MB V--S-M -> 00000000
29 : 00 fa000000 8MB VI-S-M -> fa000000
30 : 00 c0800000 8MB V--S-M -> 00800000
31 : 14 04919000 ?KB V---WM -> 00e45000
So the kernel can access the dtb at 0xbe4300 because of the pinned down DTL=
B#30.
I think the cause is clear now. But how to fix it? Two questions:
1. Should this DTLB miss exception properly set a new TLB entry for
the new dtb address 0xbe4300?
2. If the DTLB miss exception handler is not the right guy to load a
proper TLB entry, how can I set one entry based on the link_address
and the address of the flat dt blob?
Thanks a lot,
-Shawn.
^ permalink raw reply
* Re: [PATCH 00/27] KVM PPC PV framework v3
From: Avi Kivity @ 2010-08-05 7:57 UTC (permalink / raw)
To: Scott Wood; +Cc: kvm-ppc, linuxppc-dev, Alexander Graf, KVM list
In-Reply-To: <20100803111611.38ca87e6@schlenkerla.am.freescale.net>
On 08/03/2010 07:16 PM, Scott Wood wrote:
> On Sun, 1 Aug 2010 22:21:37 +0200
> Alexander Graf<agraf@suse.de> wrote:
>
>> On 01.08.2010, at 16:02, Avi Kivity wrote:
>>
>>> Looks reasonable. Since it's fair to say I understand nothing about powerpc, I'd like someone who does to review it and ack, please, with an emphasis on the interfaces.
>> Sounds good. Preferably someone with access to the ePAPR spec :).
> The ePAPR-relevant stuff in patches 7, 16, and 17 looks reasonable.
> Did I miss any ePAPR-relevant stuff in the other patches?
Shall I take this as an ACK?
--
error compiling committee.c: too many arguments to function
^ permalink raw reply
* [PATCH] powerpc/85xx: Fix compile error in mpc85xx_mds.c
From: Kumar Gala @ 2010-08-05 8:01 UTC (permalink / raw)
To: linuxppc-dev
arch/powerpc/platforms/85xx/mpc85xx_mds.c: In function 'mpc85xx_mds_setup_arch':
arch/powerpc/platforms/85xx/mpc85xx_mds.c:367: error: 'np' undeclared (first use in this function)
arch/powerpc/platforms/85xx/mpc85xx_mds.c:367: error: (Each undeclared identifier is reported only once
arch/powerpc/platforms/85xx/mpc85xx_mds.c:367: error: for each function it appears in.)
Some code cleaned dropped need decleration of 'np'.
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
---
arch/powerpc/platforms/85xx/mpc85xx_mds.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/platforms/85xx/mpc85xx_mds.c b/arch/powerpc/platforms/85xx/mpc85xx_mds.c
index c8be7b5..ebd2b2f 100644
--- a/arch/powerpc/platforms/85xx/mpc85xx_mds.c
+++ b/arch/powerpc/platforms/85xx/mpc85xx_mds.c
@@ -357,6 +357,7 @@ static void __init mpc85xx_mds_setup_arch(void)
{
#ifdef CONFIG_PCI
struct pci_controller *hose;
+ struct device_node *np = NULL;
#endif
dma_addr_t max = 0xffffffff;
--
1.6.0.6
^ permalink raw reply related
* Re: [PATCH 00/27] KVM PPC PV framework v3
From: Alexander Graf @ 2010-08-05 8:01 UTC (permalink / raw)
To: Avi Kivity; +Cc: Scott Wood, linuxppc-dev, kvm-ppc, KVM list
In-Reply-To: <4C5A6F01.6050705@redhat.com>
On 05.08.2010, at 09:57, Avi Kivity wrote:
> On 08/03/2010 07:16 PM, Scott Wood wrote:
>> On Sun, 1 Aug 2010 22:21:37 +0200
>> Alexander Graf<agraf@suse.de> wrote:
>>=20
>>> On 01.08.2010, at 16:02, Avi Kivity wrote:
>>>=20
>>>> Looks reasonable. Since it's fair to say I understand nothing =
about powerpc, I'd like someone who does to review it and ack, please, =
with an emphasis on the interfaces.
>>> Sounds good. Preferably someone with access to the ePAPR spec :).
>> The ePAPR-relevant stuff in patches 7, 16, and 17 looks reasonable.
>> Did I miss any ePAPR-relevant stuff in the other patches?
>=20
> Shall I take this as an ACK?
Hollis wanted to take a look at it too. But given the fact that I have =
another ~10 patches lying here I'd appreciate if things could get =
committed. If changes are so dramatic that they'd render things =
incompatible, we can always just release both patches for an actual =
kernel release, right?
Alex
^ permalink raw reply
* [PATCH] powerpc/fsl-pci: Fix MSI support on 83xx platforms
From: Kumar Gala @ 2010-08-05 8:02 UTC (permalink / raw)
To: linuxppc-dev; +Cc: wd, yanok
The following commit broke 83xx because it assumed the 83xx platforms
exposed the "IMMR" address in BAR0 like the 85xx/86xx/QoriQ devices do:
commit 3da34aae03d498ee62f75aa7467de93cce3030fd
Author: Kumar Gala <galak@kernel.crashing.org>
Date: Tue May 12 15:51:56 2009 -0500
powerpc/fsl: Support unique MSI addresses per PCIe Root Complex
However that is not true, so we have to search through the inbound
window settings on 83xx to find which one matches the IMMR address to
determine its PCI address.
Reported-by: Ilya Yanok <yanok@emcraft.com>
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
---
arch/powerpc/sysdev/fsl_msi.c | 9 +++----
arch/powerpc/sysdev/fsl_pci.c | 43 ++++++++++++++++++++++++++++++++++++++++-
arch/powerpc/sysdev/fsl_pci.h | 1 +
3 files changed, 47 insertions(+), 6 deletions(-)
diff --git a/arch/powerpc/sysdev/fsl_msi.c b/arch/powerpc/sysdev/fsl_msi.c
index 962c2d8..dcd244d 100644
--- a/arch/powerpc/sysdev/fsl_msi.c
+++ b/arch/powerpc/sysdev/fsl_msi.c
@@ -24,6 +24,7 @@
#include <asm/ppc-pci.h>
#include <asm/mpic.h>
#include "fsl_msi.h"
+#include "fsl_pci.h"
LIST_HEAD(msi_head);
@@ -125,13 +126,11 @@ static void fsl_compose_msi_msg(struct pci_dev *pdev, int hwirq,
{
struct fsl_msi *msi_data = fsl_msi_data;
struct pci_controller *hose = pci_bus_to_host(pdev->bus);
- u32 base = 0;
+ u64 base = fsl_pci_immrbar_base(hose);
- pci_bus_read_config_dword(hose->bus,
- PCI_DEVFN(0, 0), PCI_BASE_ADDRESS_0, &base);
+ msg->address_lo = msi_data->msi_addr_lo + lower_32_bits(base);
+ msg->address_hi = msi_data->msi_addr_hi + upper_32_bits(base);
- msg->address_lo = msi_data->msi_addr_lo + base;
- msg->address_hi = msi_data->msi_addr_hi;
msg->data = hwirq;
pr_debug("%s: allocated srs: %d, ibs: %d\n",
diff --git a/arch/powerpc/sysdev/fsl_pci.c b/arch/powerpc/sysdev/fsl_pci.c
index 7e900ec..0c28d93 100644
--- a/arch/powerpc/sysdev/fsl_pci.c
+++ b/arch/powerpc/sysdev/fsl_pci.c
@@ -1,7 +1,7 @@
/*
* MPC83xx/85xx/86xx PCI/PCIE support routing.
*
- * Copyright 2007-2009 Freescale Semiconductor, Inc.
+ * Copyright 2007-2010 Freescale Semiconductor, Inc.
* Copyright 2008-2009 MontaVista Software, Inc.
*
* Initial author: Xianghua Xiao <x.xiao@freescale.com>
@@ -310,6 +310,16 @@ void fsl_pcibios_fixup_bus(struct pci_bus *bus)
}
}
+u64 fsl_pci_immrbar_base(struct pci_controller *hose)
+{
+ u32 base;
+
+ pci_bus_read_config_dword(hose->bus,
+ PCI_DEVFN(0, 0), PCI_BASE_ADDRESS_0, &base);
+
+ return base;
+}
+
int __init fsl_add_bridge(struct device_node *dev, int is_primary)
{
int len;
@@ -428,6 +438,13 @@ struct mpc83xx_pcie_priv {
u32 dev_base;
};
+struct pex_inbound_window {
+ u32 ar;
+ u32 tar;
+ u32 barl;
+ u32 barh;
+};
+
/*
* With the convention of u-boot, the PCIE outbound window 0 serves
* as configuration transactions outbound.
@@ -435,6 +452,8 @@ struct mpc83xx_pcie_priv {
#define PEX_OUTWIN0_BAR 0xCA4
#define PEX_OUTWIN0_TAL 0xCA8
#define PEX_OUTWIN0_TAH 0xCAC
+#define PEX_RC_INWIN_BASE 0xE60
+#define PEX_RCIWARn_EN 0x1
static int mpc83xx_pcie_exclude_device(struct pci_bus *bus, unsigned int devfn)
{
@@ -461,6 +480,28 @@ static int mpc83xx_pcie_exclude_device(struct pci_bus *bus, unsigned int devfn)
return PCIBIOS_SUCCESSFUL;
}
+/* Walk the Root Complex Inbound windows to match IMMR base */
+u64 fsl_pci_immrbar_base(struct pci_controller *hose)
+{
+ struct mpc83xx_pcie_priv *pcie = hose->dn->data;
+ struct pex_inbound_window *in = pcie->cfg_type0 + PEX_RC_INWIN_BASE;
+ int i;
+
+ for (i = 0; i < 4; i++) {
+ /* not enabled, skip */
+ if (!in_le32(&in[i].ar) & PEX_RCIWARn_EN)
+ continue;
+
+ if (get_immrbase() == in_le32(&in[i].tar))
+ return (u64)in_le32(&in[i].barh) << 32 |
+ in_le32(&in[i].barl);
+ }
+
+ printk(KERN_WARNING "could not find PCI BAR matching IMMR\n");
+
+ return 0;
+}
+
static void __iomem *mpc83xx_pcie_remap_cfg(struct pci_bus *bus,
unsigned int devfn, int offset)
{
diff --git a/arch/powerpc/sysdev/fsl_pci.h b/arch/powerpc/sysdev/fsl_pci.h
index a9d8bbe..8ad72a1 100644
--- a/arch/powerpc/sysdev/fsl_pci.h
+++ b/arch/powerpc/sysdev/fsl_pci.h
@@ -88,6 +88,7 @@ struct ccsr_pci {
extern int fsl_add_bridge(struct device_node *dev, int is_primary);
extern void fsl_pcibios_fixup_bus(struct pci_bus *bus);
extern int mpc83xx_add_bridge(struct device_node *dev);
+u64 fsl_pci_immrbar_base(struct pci_controller *hose);
#endif /* __POWERPC_FSL_PCI_H */
#endif /* __KERNEL__ */
--
1.6.0.6
^ permalink raw reply related
* Re: [PATCH 00/27] KVM PPC PV framework v3
From: Avi Kivity @ 2010-08-05 8:05 UTC (permalink / raw)
To: Alexander Graf
Cc: Scott Wood, linuxppc-dev, kvm-ppc, KVM list, Hollis Blanchard
In-Reply-To: <55AD06CD-842E-49DC-97CD-AEE401F5B8C5@suse.de>
On 08/05/2010 11:01 AM, Alexander Graf wrote:
>
>> Shall I take this as an ACK?
> Hollis wanted to take a look at it too. But given the fact that I have another ~10 patches lying here I'd appreciate if things could get committed. If changes are so dramatic that they'd render things incompatible, we can always just release both patches for an actual kernel release, right?
That's true, we have some time to get it right.
Hollis, please let us know either way once you've reviewed things.
--
error compiling committee.c: too many arguments to function
^ permalink raw reply
* Re: Commit 3da34aa brakes MSI support on MPC8308 (possibly all MPC83xx) [REPOST]
From: Ilya Yanok @ 2010-08-05 8:24 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, Wolfgang Denk
In-Reply-To: <B6B3F33E-1A50-45A4-ADAE-2CA5C383B404@kernel.crashing.org>
Hi Kumar,
05.08.2010 11:01, Kumar Gala пишет:
> I have a fix, can you test?
Surely. Where can I find it?
Thanks.
Regards, Ilya.
^ permalink raw reply
* Re: [PATCH 00/27] KVM PPC PV framework v3
From: Avi Kivity @ 2010-08-05 8:25 UTC (permalink / raw)
To: Alexander Graf; +Cc: linuxppc-dev, KVM list, kvm-ppc
In-Reply-To: <1280407688-9815-1-git-send-email-agraf@suse.de>
On 07/29/2010 03:47 PM, Alexander Graf wrote:
> On PPC we run PR=0 (kernel mode) code in PR=1 (user mode) and don't use the
> hypervisor extensions.
>
> While that is all great to show that virtualization is possible, there are
> quite some cases where the emulation overhead of privileged instructions is
> killing performance.
>
> This patchset tackles exactly that issue. It introduces a paravirtual framework
> using which KVM and Linux share a page to exchange register state with. That
> way we don't have to switch to the hypervisor just to change a value of a
> privileged register.
>
> To prove my point, I ran the same test I did for the MMU optimizations against
> the PV framework. Here are the results:
>
> [without]
>
> debian-powerpc:~# time for i in {1..1000}; do /bin/echo hello> /dev/null; done
>
> real 0m14.659s
> user 0m8.967s
> sys 0m5.688s
>
> [with]
>
> debian-powerpc:~# time for i in {1..1000}; do /bin/echo hello> /dev/null; done
>
> real 0m7.557s
> user 0m4.121s
> sys 0m3.426s
>
>
> So this is a significant performance improvement! I'm quite happy how fast this
> whole thing becomes :)
>
> I tried to take all comments I've heard from people so far about such a PV
> framework into account. In case you told me something before that is a no-go
> and I still did it, please just tell me again.
>
> To make use of this whole thing you also need patches to qemu and openbios. I
> have them in my queue, but want to see this set upstream first before I start
> sending patches to the other projects.
>
> Now go and have fun with fast VMs on PPC! Get yourself a G5 on ebay and start
> experiencing the power yourself. - heh
>
Applied this and your follow on 7-part series, thanks.
--
error compiling committee.c: too many arguments to function
^ permalink raw reply
* Re: [PATCH v4 1/2] powerpc: cleanup APIs for cpu/thread/core mappings
From: Vaidyanathan Srinivasan @ 2010-08-05 11:00 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Michael Neuling, Paul Mackerras, Anton Blanchard, linuxppc-dev
In-Reply-To: <1280810653.1902.87.camel@pasglop>
* Benjamin Herrenschmidt <benh@kernel.crashing.org> [2010-08-03 14:44:13]:
> On Thu, 2010-07-22 at 06:27 +0530, Vaidyanathan Srinivasan wrote:
> > These APIs take logical cpu number as input
> > Change cpu_first_thread_in_core() to cpu_leftmost_thread_sibling()
> > Change cpu_last_thread_in_core() to cpu_rightmost_thread_sibling()
>
> I'm still not happy here.
>
> I don't find leftmost/rightmost to be a "progress" from the previous
> naming. If you really want to change to avoid in_core() at the end, then
> call them first_thread_sibling() and last_thread_sibling().
Hi Ben,
The naming is based on our discussion during the first RFC:
http://lists.ozlabs.org/pipermail/linuxppc-dev/2010-April/081610.html
I am fine with first_thread_sibling() name instead of
cpu_{left,right}most_thread_sibling(). The goal is to distinguish
between APIs returning logical cpu numbers and core indexes.
first_thread_sibling() implies that the parameter and return value are
logical cpu (thread) number.
I will change the name as per your suggestion and post an update.
> Then you change:
>
> > -static inline int cpu_thread_to_core(int cpu)
> > -{
> > - return cpu >> threads_shift;
> > -}
>
> .../... to:
>
> > -/* Must be called when no change can occur to cpu_present_mask,
> > +/* Helper routines for cpu to core mapping */
> > +int cpu_core_of_thread(int cpu)
> > +{
> > + return cpu >> threads_shift;
> > +}
> > +EXPORT_SYMBOL_GPL(cpu_core_of_thread);
The cpu_core_of_thread() name implies that the return type is a core index
and not a logical cpu number.
cpu_core_of_thread(5) = 1
cpu_first_thread_of_core(1) = 4
Do you think cpu_core_number_of_thread() will explain the return type
better?
> Any reason you are making it out of line other than gratuituous
> bloat ? :-)
>
> > +int cpu_first_thread_of_core(int core)
> > +{
> > + return core << threads_shift;
> > +}
> > +EXPORT_SYMBOL_GPL(cpu_first_thread_of_core);
>
> Same.
The reason behind out of line is to avoid exporting threads_shift or
other variables like threads_per_core and have this API exported so
that modules can read them. If we make these wrapper inline, then we
will have to export the variables themselves which is not a good idea.
Thanks for the review.
--Vaidy
^ permalink raw reply
* Re: [PATCH][RFC] preempt_count corruption across H_CEDE call with CONFIG_PREEMPT on pseries
From: Vaidyanathan Srinivasan @ 2010-08-05 11:06 UTC (permalink / raw)
To: Darren Hart
Cc: Stephen Rothwell, Gautham R Shenoy, Steven Rostedt, linuxppc-dev,
Will Schmidt, Paul Mackerras, Thomas Gleixner
In-Reply-To: <4C5A41FF.3000605@us.ibm.com>
* Darren Hart <dvhltc@us.ibm.com> [2010-08-04 21:45:51]:
> On 07/23/2010 12:07 AM, Vaidyanathan Srinivasan wrote:
> >* Benjamin Herrenschmidt<benh@kernel.crashing.org> [2010-07-23 15:11:00]:
> >
> >>On Fri, 2010-07-23 at 10:38 +0530, Vaidyanathan Srinivasan wrote:
> >>>Yes. extended_cede_processor() will return with interrupts enabled in
> >>>the cpu. (This is done by the hypervisor). Under normal cases we
> >>>cannot be interrupted because no IO interrupts are routed to us after
> >>>xics_teardown_cpu() and since the CPU is out of the map, nobody will
> >>>send us IPIs.
> >>
> >>What about decrementer ?
> >
> >Decrementer expiry event handling is bit complex. The event as such
> >may not bring back the extended_cede_processor() cpu, but may be
> >marked pending when we get out of this state eventually. I will find
> >more information on this event and update.
>
> Hi Vaidy, have you been able to dig anything up about the
> decrementer expiry?
Hi Darren,
Yes, it is possible that the cpu in extended_cede_processor() can be
woken up by the decrementer. But the expectation is that we will
return back to this context since we will not have any pending timers.
Our stack should not change even if we get the decrementer interrupts.
--Vaidy
^ permalink raw reply
* Re: [PATCH] asoc/multi-component: fsl: add support for disabled SSI nodes
From: Mark Brown @ 2010-08-05 11:42 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev, alsa-devel, kumar.gala, lrg
In-Reply-To: <1280962268-31407-1-git-send-email-timur@freescale.com>
On Wed, Aug 04, 2010 at 05:51:08PM -0500, Timur Tabi wrote:
> Add support for adding "status = disabled" to an SSI node to incidate that it
> is not wired on the board. This replaces the not-so-intuitive previous method
> of omitting a codec-handle property.
>
> Signed-off-by: Timur Tabi <timur@freescale.com>
Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
^ permalink raw reply
* Re: [PATCH][RFC] preempt_count corruption across H_CEDE call with CONFIG_PREEMPT on pseries
From: Thomas Gleixner @ 2010-08-05 12:26 UTC (permalink / raw)
To: Vaidyanathan Srinivasan
Cc: Stephen Rothwell, Darren Hart, Gautham R Shenoy, Steven Rostedt,
linuxppc-dev, Will Schmidt, Paul Mackerras
In-Reply-To: <20100805110625.GG3282@dirshya.in.ibm.com>
On Thu, 5 Aug 2010, Vaidyanathan Srinivasan wrote:
> * Darren Hart <dvhltc@us.ibm.com> [2010-08-04 21:45:51]:
>
> > On 07/23/2010 12:07 AM, Vaidyanathan Srinivasan wrote:
> > >* Benjamin Herrenschmidt<benh@kernel.crashing.org> [2010-07-23 15:11:00]:
> > >
> > >>On Fri, 2010-07-23 at 10:38 +0530, Vaidyanathan Srinivasan wrote:
> > >>>Yes. extended_cede_processor() will return with interrupts enabled in
> > >>>the cpu. (This is done by the hypervisor). Under normal cases we
> > >>>cannot be interrupted because no IO interrupts are routed to us after
> > >>>xics_teardown_cpu() and since the CPU is out of the map, nobody will
> > >>>send us IPIs.
> > >>
> > >>What about decrementer ?
> > >
> > >Decrementer expiry event handling is bit complex. The event as such
> > >may not bring back the extended_cede_processor() cpu, but may be
> > >marked pending when we get out of this state eventually. I will find
> > >more information on this event and update.
> >
> > Hi Vaidy, have you been able to dig anything up about the
> > decrementer expiry?
>
> Hi Darren,
>
> Yes, it is possible that the cpu in extended_cede_processor() can be
> woken up by the decrementer. But the expectation is that we will
> return back to this context since we will not have any pending timers.
The problem is that you might get woken _before_ the timers have been
migrated away.
> Our stack should not change even if we get the decrementer interrupts.
But you should not execute kernel code when you got offlined either.
Thanks,
tglx
^ permalink raw reply
* Re: [alsa-devel] [PATCH] asoc/multi-component: fsl: add support for disabled SSI nodes
From: Liam Girdwood @ 2010-08-05 12:43 UTC (permalink / raw)
To: Mark Brown; +Cc: linuxppc-dev, alsa-devel, Timur Tabi, kumar.gala
In-Reply-To: <20100805114215.GC13146@rakim.wolfsonmicro.main>
On Thu, 2010-08-05 at 12:42 +0100, Mark Brown wrote:
> On Wed, Aug 04, 2010 at 05:51:08PM -0500, Timur Tabi wrote:
> > Add support for adding "status = disabled" to an SSI node to incidate that it
> > is not wired on the board. This replaces the not-so-intuitive previous method
> > of omitting a codec-handle property.
> >
> > Signed-off-by: Timur Tabi <timur@freescale.com>
>
> Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Applied.
Thanks
Liam
^ permalink raw reply
* Re: [PATCH] powerpc: Add vmcoreinfo symbols to allow makdumpfile to filter core files properly
From: Neil Horman @ 2010-08-05 13:00 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Neil Horman, kexec, linux-kernel, linuxppc-dev, paulus, vgoyal
In-Reply-To: <1280973866.1902.168.camel@pasglop>
On Thu, Aug 05, 2010 at 12:04:26PM +1000, Benjamin Herrenschmidt wrote:
> On Wed, 2010-08-04 at 10:49 -0400, Neil Horman wrote:
> > Ping yet again. Ben, This needs review/acceptance from you or Paul
> > Neil
>
> Isn't it already in powerpc-next about to be pulled by Linus ?
>
Yes, there it is. Apologies. For whatever reason, I was looking on the main
branch of your tree. It didn't occur to me to check your next branch. Sorry.
> In general, I recommend you check the status of your patches on
> patchwork. I'm nagging Jeremy to add a feature so it emails the
> submitter when the patch status changes :-)
>
Noted, I'll remember that. Email from patchwork would be a nice feature. +1
from me.
Thanks & Regards
Neil
> Cheers,
> Ben.
>
>
> _______________________________________________
> kexec mailing list
> kexec@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply
* RE: [PATCH 0/2 v3] mpc5200 ac97 gpio reset
From: Eric Millbrandt @ 2010-08-05 12:59 UTC (permalink / raw)
To: 'Mark Brown', Grant Likely; +Cc: linuxppc-dev@lists.ozlabs.org
In-Reply-To: <20100803055216.GA25306@rakim.wolfsonmicro.main>
> -----Original Message-----
> From: linuxppc-dev-bounces+emillbrandt=3Ddekaresearch.com@lists.ozlabs.or=
g
> [mailto:linuxppc-dev-
> bounces+emillbrandt=3Ddekaresearch.com@lists.ozlabs.org] On Behalf Of Mar=
k
> Brown
> Sent: Tuesday, August 03, 2010 01:52
> To: Grant Likely
> Cc: linuxppc-dev@lists.ozlabs.org; Eric Millbrandt
> Subject: Re: [PATCH 0/2 v3] mpc5200 ac97 gpio reset
>
> On Sat, Jul 31, 2010 at 10:42:15PM -0600, Grant Likely wrote:
> > On Sun, Jun 27, 2010 at 4:01 PM, Mark Brown
>
> > > I'm a little concerned with a collision with multi codec here. It'd
> > > be handy if you could keep it separate in case it needs merging
> > > into both trees (or we could merge via ASoC only).
>
> > Hmmm. Yeah, probably better to take it via your tree then. I've
> > currently got patch 1 in linux-next, but I'll drop it before asking
> > benh to pull. Go ahead and add my acked-by.
>
> Looks like multi-component is slightly too late for .36 and I don't have
> the original patch any more since it looked like you were going to be
> carrying it... could you restore the patch to your tree please?
<ping> Grant, are you going to pick up this series for .36?
Eric
-DISCLAIMER: an automatically appended disclaimer may follow. By posting-
-to a public e-mail mailing list I hereby grant permission to distribute-
-and copy this message.-
This e-mail and the information, including any attachments, it contains are=
intended to be a confidential communication only to the person or entity t=
o whom it is addressed and may contain information that is privileged. If t=
he reader of this message is not the intended recipient, you are hereby not=
ified that any dissemination, distribution or copying of this communication=
is strictly prohibited. If you have received this communication in error, =
please immediately notify the sender and destroy the original message.
Thank you.
Please consider the environment before printing this email.
^ permalink raw reply
* Re: [PATCH] powerpc: ONLINE to OFFLINE CPU state transition during removal
From: Vaidyanathan Srinivasan @ 2010-08-05 13:31 UTC (permalink / raw)
To: Nathan Fontenot
Cc: Gautham R Shenoy, Julia Lawall, Paul Mackerras, linuxppc-dev
In-Reply-To: <4C4DDE5F.7090207@austin.ibm.com>
* Nathan Fontenot <nfont@austin.ibm.com> [2010-07-26 14:13:35]:
> On 07/22/2010 11:13 PM, Vaidyanathan Srinivasan wrote:
> > * Robert Jennings <rcj@linux.vnet.ibm.com> [2010-07-22 21:43:44]:
> >
> >> If a CPU remove is attempted using the 'release' interface on hardware
> >> which supports extended cede, the CPU will be put in the INACTIVE state
> >> rather than the OFFLINE state due to the default preferred_offline_state
> >> in that situation. In the INACTIVE state it will fail to be removed.
> >>
> >> This patch changes the preferred offline state to OFFLINE when an CPU is
> >> in the ONLINE state. After cpu_down() is called in dlpar_offline_cpu()
> >> the CPU will be OFFLINE and CPU removal can continue.
> >
> > Hi Robert,
> >
> > Thanks for the patch. In dlpar operation, we would offline the CPU
> > first using the sysfs online file and then write to the sysfs release
> > file to complete the sequence right? The current code in
> > dlpar_offline_cpu() would work as long as the cpu is in either
> > inactive state or offline state (in case of unsupported platform).
> >
> > Is the dlpar tools being changed to complete the operation with one
> > sysfs write to release file?
>
> The dlpar tools were updated so that a single write to the 'release' file
> would offline the cpu and remove it from the system. Given this, I think
> Robert's patch should go forward to maintain compatability.
Hi Nathan,
Thanks for clarifying. One concern that I have is that this change
could race with sysfs write to cpuN/online file.
dlpar_offline_cpu() is called with cpu_hotplug_driver_lock() held so
the sysfs operation on online file should wait. However by the time
the cpu_hotplug_driver_unlock() happens the dlpar operation should
have completed and we should not be able to online or offline the cpu
from sysfs online file.
I wanted to confirm whether any concurrent sysfs write will not cause
the dlpar operation to fail in the middle of the operation.
The previous code will work fine for platforms not supporting
cede_offline where we have only two states for the cpu.
When cede_offline is supported, we have three states and the state
transitions are controlled by online file and the release file in two
steps so that the failures can be retried in user space.
This patch will work and I do not see any problem as such, but we
still need to carefully evaluate the retry and error handling paths
before switching over to a single sysfs write based dlpar operation.
--Vaidy
^ permalink raw reply
* Re: Commit 3da34aa brakes MSI support on MPC8308 (possibly all MPC83xx) [REPOST]
From: Kumar Gala @ 2010-08-05 13:50 UTC (permalink / raw)
To: Ilya Yanok; +Cc: linuxppc-dev, Wolfgang Denk
In-Reply-To: <4C5A7525.10105@emcraft.com>
On Aug 5, 2010, at 3:24 AM, Ilya Yanok wrote:
> Hi Kumar,
>=20
> 05.08.2010 11:01, Kumar Gala =D0=BF=D0=B8=D1=88=D0=B5=D1=82:
>> I have a fix, can you test?
>=20
> Surely. Where can I find it?
>=20
> Thanks.
>=20
> Regards, Ilya.
http://patchwork.ozlabs.org/patch/60934/
- k
^ permalink raw reply
* Re: [PATCH] asoc/multi-component: fsl: add support for disabled SSI nodes
From: Kumar Gala @ 2010-08-05 13:51 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev, alsa-devel, broonie, lrg
In-Reply-To: <1280962268-31407-1-git-send-email-timur@freescale.com>
On Aug 4, 2010, at 5:51 PM, Timur Tabi wrote:
> Add support for adding "status =3D disabled" to an SSI node to =
incidate that it
> is not wired on the board. This replaces the not-so-intuitive =
previous method
> of omitting a codec-handle property.
>=20
> Signed-off-by: Timur Tabi <timur@freescale.com>
> ---
>=20
> Kumar, would you please ACK the device-tree portion of this patch? I =
want
> it to go through the ALSA tree.
>=20
> arch/powerpc/boot/dts/mpc8610_hpcd.dts | 1 +
> sound/soc/fsl/fsl_ssi.c | 13 ++++++++++---
> 2 files changed, 11 insertions(+), 3 deletions(-)
Acked-by: Kumar Gala <galak@kernel.crashing.org>
- k=
^ permalink raw reply
* [PATCH 2/3] powerpc: implement arch_setup_pdev_archdata
From: Kumar Gala @ 2010-08-05 15:15 UTC (permalink / raw)
To: gregkh; +Cc: linuxppc-dev, akpm, linux-kernel
In-Reply-To: <1281021347-1278-2-git-send-email-galak@kernel.crashing.org>
We have a long standing issues with platform devices not have a valid
dma_mask pointer. This hasn't been an issue to date as no platform
device has tried to set its dma_mask value to a non-default value.
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
---
arch/powerpc/include/asm/platform_device.h | 16 +++++++++++++++-
1 files changed, 15 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/include/asm/platform_device.h b/arch/powerpc/include/asm/platform_device.h
index 01452c3..a379500 100644
--- a/arch/powerpc/include/asm/platform_device.h
+++ b/arch/powerpc/include/asm/platform_device.h
@@ -1 +1,15 @@
-#include <asm-generic/platform_device.h>
+#ifndef __ASM_PLATFORM_DEVICE_H_
+#define __ASM_PLATFORM_DEVICE_H_
+
+#include <linux/platform_device.h>
+
+#define ARCH_HAS_PDEV_ARCHDATA_SETUP
+
+static inline void arch_setup_pdev_archdata(struct platform_device *pdev)
+{
+ pdev->dev.dma_mask = &pdev->archdata.dma_mask;
+
+ return;
+}
+
+#endif /* __ASM_GENERIC_PLATFORM_DEVICE_H_ */
--
1.6.0.6
^ permalink raw reply related
* [PATCH 3/3] powerpc: Dont require a dma_ops struct to set dma mask
From: Kumar Gala @ 2010-08-05 15:15 UTC (permalink / raw)
To: gregkh; +Cc: linuxppc-dev, akpm, linux-kernel
In-Reply-To: <1281021347-1278-3-git-send-email-galak@kernel.crashing.org>
The only reason to require a dma_ops struct is to see if it has
implemented set_dma_mask. If not we can fall back to setting the mask
directly.
This resolves an issue with how to sequence the setting of a DMA mask
for platform devices. Before we had an issue in that we have no way of
setting the DMA mask before the various low level bus notifiers get
called that might check it (swiotlb).
So now we can do:
pdev = platform_device_alloc("foobar", 0);
dma_set_mask(&pdev->dev, DMA_BIT_MASK(37));
platform_device_register(pdev);
And expect the right thing to happen with the bus notifiers get called
via platform_device_register.
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
---
arch/powerpc/include/asm/dma-mapping.h | 6 ++----
1 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/include/asm/dma-mapping.h b/arch/powerpc/include/asm/dma-mapping.h
index c85ef23..952208a 100644
--- a/arch/powerpc/include/asm/dma-mapping.h
+++ b/arch/powerpc/include/asm/dma-mapping.h
@@ -131,12 +131,10 @@ static inline int dma_set_mask(struct device *dev, u64 dma_mask)
{
struct dma_map_ops *dma_ops = get_dma_ops(dev);
- if (unlikely(dma_ops == NULL))
- return -EIO;
- if (dma_ops->set_dma_mask != NULL)
- return dma_ops->set_dma_mask(dev, dma_mask);
if (!dev->dma_mask || !dma_supported(dev, dma_mask))
return -EIO;
+ if (dma_ops && (dma_ops->set_dma_mask != NULL))
+ return dma_ops->set_dma_mask(dev, dma_mask);
*dev->dma_mask = dma_mask;
return 0;
}
--
1.6.0.6
^ permalink raw reply related
* [PATCH 1/3] driver core: Add ability for arch code to setup pdev_archdata
From: Kumar Gala @ 2010-08-05 15:15 UTC (permalink / raw)
To: gregkh; +Cc: linuxppc-dev, akpm, linux-kernel
In-Reply-To: <1281021347-1278-1-git-send-email-galak@kernel.crashing.org>
On some architectures we need to setup pdev_archdata before we add the
device. Waiting til a bus_notifier is too late since we might need the
pdev_archdata in the bus notifier. One example is setting up of dma_mask
pointers such that it can be used in a bus_notifier.
We add ARCH_HAS_PDEV_ARCHDATA_SETUP and a dummy <asm/platform_device.h>
header to allow the arch code to have an inline implementation of
arch_setup_pdev_archdata() and being able to access the full definitions
of struct device, struct platform_device, and struct pdev_archdata.
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
---
arch/alpha/include/asm/platform_device.h | 1 +
arch/arm/include/asm/platform_device.h | 1 +
arch/avr32/include/asm/platform_device.h | 1 +
arch/blackfin/include/asm/platform_device.h | 1 +
arch/cris/include/asm/platform_device.h | 1 +
arch/frv/include/asm/platform_device.h | 1 +
arch/h8300/include/asm/platform_device.h | 1 +
arch/ia64/include/asm/platform_device.h | 1 +
arch/m32r/include/asm/platform_device.h | 1 +
arch/m68k/include/asm/platform_device.h | 1 +
arch/microblaze/include/asm/platform_device.h | 1 +
arch/mips/include/asm/platform_device.h | 1 +
arch/mn10300/include/asm/platform_device.h | 1 +
arch/parisc/include/asm/platform_device.h | 1 +
arch/powerpc/include/asm/platform_device.h | 1 +
arch/s390/include/asm/platform_device.h | 1 +
arch/score/include/asm/platform_device.h | 1 +
arch/sh/include/asm/platform_device.h | 1 +
arch/sparc/include/asm/platform_device.h | 1 +
arch/x86/include/asm/platform_device.h | 1 +
arch/xtensa/include/asm/platform_device.h | 1 +
drivers/base/platform.c | 4 ++++
include/asm-generic/platform_device.h | 7 +++++++
23 files changed, 32 insertions(+), 0 deletions(-)
create mode 100644 arch/alpha/include/asm/platform_device.h
create mode 100644 arch/arm/include/asm/platform_device.h
create mode 100644 arch/avr32/include/asm/platform_device.h
create mode 100644 arch/blackfin/include/asm/platform_device.h
create mode 100644 arch/cris/include/asm/platform_device.h
create mode 100644 arch/frv/include/asm/platform_device.h
create mode 100644 arch/h8300/include/asm/platform_device.h
create mode 100644 arch/ia64/include/asm/platform_device.h
create mode 100644 arch/m32r/include/asm/platform_device.h
create mode 100644 arch/m68k/include/asm/platform_device.h
create mode 100644 arch/microblaze/include/asm/platform_device.h
create mode 100644 arch/mips/include/asm/platform_device.h
create mode 100644 arch/mn10300/include/asm/platform_device.h
create mode 100644 arch/parisc/include/asm/platform_device.h
create mode 100644 arch/powerpc/include/asm/platform_device.h
create mode 100644 arch/s390/include/asm/platform_device.h
create mode 100644 arch/score/include/asm/platform_device.h
create mode 100644 arch/sh/include/asm/platform_device.h
create mode 100644 arch/sparc/include/asm/platform_device.h
create mode 100644 arch/x86/include/asm/platform_device.h
create mode 100644 arch/xtensa/include/asm/platform_device.h
create mode 100644 include/asm-generic/platform_device.h
diff --git a/arch/alpha/include/asm/platform_device.h b/arch/alpha/include/asm/platform_device.h
new file mode 100644
index 0000000..01452c3
--- /dev/null
+++ b/arch/alpha/include/asm/platform_device.h
@@ -0,0 +1 @@
+#include <asm-generic/platform_device.h>
diff --git a/arch/arm/include/asm/platform_device.h b/arch/arm/include/asm/platform_device.h
new file mode 100644
index 0000000..01452c3
--- /dev/null
+++ b/arch/arm/include/asm/platform_device.h
@@ -0,0 +1 @@
+#include <asm-generic/platform_device.h>
diff --git a/arch/avr32/include/asm/platform_device.h b/arch/avr32/include/asm/platform_device.h
new file mode 100644
index 0000000..01452c3
--- /dev/null
+++ b/arch/avr32/include/asm/platform_device.h
@@ -0,0 +1 @@
+#include <asm-generic/platform_device.h>
diff --git a/arch/blackfin/include/asm/platform_device.h b/arch/blackfin/include/asm/platform_device.h
new file mode 100644
index 0000000..01452c3
--- /dev/null
+++ b/arch/blackfin/include/asm/platform_device.h
@@ -0,0 +1 @@
+#include <asm-generic/platform_device.h>
diff --git a/arch/cris/include/asm/platform_device.h b/arch/cris/include/asm/platform_device.h
new file mode 100644
index 0000000..01452c3
--- /dev/null
+++ b/arch/cris/include/asm/platform_device.h
@@ -0,0 +1 @@
+#include <asm-generic/platform_device.h>
diff --git a/arch/frv/include/asm/platform_device.h b/arch/frv/include/asm/platform_device.h
new file mode 100644
index 0000000..01452c3
--- /dev/null
+++ b/arch/frv/include/asm/platform_device.h
@@ -0,0 +1 @@
+#include <asm-generic/platform_device.h>
diff --git a/arch/h8300/include/asm/platform_device.h b/arch/h8300/include/asm/platform_device.h
new file mode 100644
index 0000000..01452c3
--- /dev/null
+++ b/arch/h8300/include/asm/platform_device.h
@@ -0,0 +1 @@
+#include <asm-generic/platform_device.h>
diff --git a/arch/ia64/include/asm/platform_device.h b/arch/ia64/include/asm/platform_device.h
new file mode 100644
index 0000000..01452c3
--- /dev/null
+++ b/arch/ia64/include/asm/platform_device.h
@@ -0,0 +1 @@
+#include <asm-generic/platform_device.h>
diff --git a/arch/m32r/include/asm/platform_device.h b/arch/m32r/include/asm/platform_device.h
new file mode 100644
index 0000000..01452c3
--- /dev/null
+++ b/arch/m32r/include/asm/platform_device.h
@@ -0,0 +1 @@
+#include <asm-generic/platform_device.h>
diff --git a/arch/m68k/include/asm/platform_device.h b/arch/m68k/include/asm/platform_device.h
new file mode 100644
index 0000000..01452c3
--- /dev/null
+++ b/arch/m68k/include/asm/platform_device.h
@@ -0,0 +1 @@
+#include <asm-generic/platform_device.h>
diff --git a/arch/microblaze/include/asm/platform_device.h b/arch/microblaze/include/asm/platform_device.h
new file mode 100644
index 0000000..01452c3
--- /dev/null
+++ b/arch/microblaze/include/asm/platform_device.h
@@ -0,0 +1 @@
+#include <asm-generic/platform_device.h>
diff --git a/arch/mips/include/asm/platform_device.h b/arch/mips/include/asm/platform_device.h
new file mode 100644
index 0000000..01452c3
--- /dev/null
+++ b/arch/mips/include/asm/platform_device.h
@@ -0,0 +1 @@
+#include <asm-generic/platform_device.h>
diff --git a/arch/mn10300/include/asm/platform_device.h b/arch/mn10300/include/asm/platform_device.h
new file mode 100644
index 0000000..01452c3
--- /dev/null
+++ b/arch/mn10300/include/asm/platform_device.h
@@ -0,0 +1 @@
+#include <asm-generic/platform_device.h>
diff --git a/arch/parisc/include/asm/platform_device.h b/arch/parisc/include/asm/platform_device.h
new file mode 100644
index 0000000..01452c3
--- /dev/null
+++ b/arch/parisc/include/asm/platform_device.h
@@ -0,0 +1 @@
+#include <asm-generic/platform_device.h>
diff --git a/arch/powerpc/include/asm/platform_device.h b/arch/powerpc/include/asm/platform_device.h
new file mode 100644
index 0000000..01452c3
--- /dev/null
+++ b/arch/powerpc/include/asm/platform_device.h
@@ -0,0 +1 @@
+#include <asm-generic/platform_device.h>
diff --git a/arch/s390/include/asm/platform_device.h b/arch/s390/include/asm/platform_device.h
new file mode 100644
index 0000000..01452c3
--- /dev/null
+++ b/arch/s390/include/asm/platform_device.h
@@ -0,0 +1 @@
+#include <asm-generic/platform_device.h>
diff --git a/arch/score/include/asm/platform_device.h b/arch/score/include/asm/platform_device.h
new file mode 100644
index 0000000..01452c3
--- /dev/null
+++ b/arch/score/include/asm/platform_device.h
@@ -0,0 +1 @@
+#include <asm-generic/platform_device.h>
diff --git a/arch/sh/include/asm/platform_device.h b/arch/sh/include/asm/platform_device.h
new file mode 100644
index 0000000..01452c3
--- /dev/null
+++ b/arch/sh/include/asm/platform_device.h
@@ -0,0 +1 @@
+#include <asm-generic/platform_device.h>
diff --git a/arch/sparc/include/asm/platform_device.h b/arch/sparc/include/asm/platform_device.h
new file mode 100644
index 0000000..01452c3
--- /dev/null
+++ b/arch/sparc/include/asm/platform_device.h
@@ -0,0 +1 @@
+#include <asm-generic/platform_device.h>
diff --git a/arch/x86/include/asm/platform_device.h b/arch/x86/include/asm/platform_device.h
new file mode 100644
index 0000000..01452c3
--- /dev/null
+++ b/arch/x86/include/asm/platform_device.h
@@ -0,0 +1 @@
+#include <asm-generic/platform_device.h>
diff --git a/arch/xtensa/include/asm/platform_device.h b/arch/xtensa/include/asm/platform_device.h
new file mode 100644
index 0000000..01452c3
--- /dev/null
+++ b/arch/xtensa/include/asm/platform_device.h
@@ -0,0 +1 @@
+#include <asm-generic/platform_device.h>
diff --git a/drivers/base/platform.c b/drivers/base/platform.c
index 4d99c8b..165b454 100644
--- a/drivers/base/platform.c
+++ b/drivers/base/platform.c
@@ -19,6 +19,7 @@
#include <linux/err.h>
#include <linux/slab.h>
#include <linux/pm_runtime.h>
+#include <asm/platform_device.h>
#include "base.h"
@@ -170,6 +171,9 @@ struct platform_device *platform_device_alloc(const char *name, int id)
pa->pdev.id = id;
device_initialize(&pa->pdev.dev);
pa->pdev.dev.release = platform_device_release;
+#ifdef ARCH_HAS_PDEV_ARCHDATA_SETUP
+ arch_setup_pdev_archdata(&pa->pdev);
+#endif
}
return pa ? &pa->pdev : NULL;
diff --git a/include/asm-generic/platform_device.h b/include/asm-generic/platform_device.h
new file mode 100644
index 0000000..64806dc
--- /dev/null
+++ b/include/asm-generic/platform_device.h
@@ -0,0 +1,7 @@
+#ifndef __ASM_GENERIC_PLATFORM_DEVICE_H_
+#define __ASM_GENERIC_PLATFORM_DEVICE_H_
+/*
+ * an architecture can override to define arch_setup_pdev_archdata
+ */
+
+#endif /* __ASM_GENERIC_PLATFORM_DEVICE_H_ */
--
1.6.0.6
^ permalink raw reply related
* [PATCH 0/3] driver core: Add ability for arch code to setup pdev_archdata
From: Kumar Gala @ 2010-08-05 15:15 UTC (permalink / raw)
To: gregkh; +Cc: linuxppc-dev, akpm, linux-kernel
On PPC we need to set the dma_mask pointer for platform_devices to point to
the pdev_archdata. We can't wait for a bus_notifier as we need the dma_mask
setup before the platform_device_add happens so that the bus_notifiers can
check the dma_mask to determine if we need things like the SWIOTLB dma_ops.
The patch series introduces an arch specific call out (arch_setup_pdev_archdata)
and provide an implementation on PPC to handle our specific issue.
- k
^ permalink raw reply
* Re: [PATCH 1/3] driver core: Add ability for arch code to setup pdev_archdata
From: Stephen Rothwell @ 2010-08-05 15:43 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, akpm, gregkh, linux-kernel
In-Reply-To: <1281021347-1278-2-git-send-email-galak@kernel.crashing.org>
[-- Attachment #1: Type: text/plain, Size: 1757 bytes --]
Hi Kumar,
On Thu, 5 Aug 2010 10:15:45 -0500 Kumar Gala <galak@kernel.crashing.org> wrote:
>
> --- a/drivers/base/platform.c
> +++ b/drivers/base/platform.c
> @@ -19,6 +19,7 @@
> #include <linux/err.h>
> #include <linux/slab.h>
> #include <linux/pm_runtime.h>
> +#include <asm/platform_device.h>
>
> #include "base.h"
>
> @@ -170,6 +171,9 @@ struct platform_device *platform_device_alloc(const char *name, int id)
> pa->pdev.id = id;
> device_initialize(&pa->pdev.dev);
> pa->pdev.dev.release = platform_device_release;
> +#ifdef ARCH_HAS_PDEV_ARCHDATA_SETUP
> + arch_setup_pdev_archdata(&pa->pdev);
> +#endif
> }
>
> return pa ? &pa->pdev : NULL;
> diff --git a/include/asm-generic/platform_device.h b/include/asm-generic/platform_device.h
> new file mode 100644
> index 0000000..64806dc
> --- /dev/null
> +++ b/include/asm-generic/platform_device.h
> @@ -0,0 +1,7 @@
> +#ifndef __ASM_GENERIC_PLATFORM_DEVICE_H_
> +#define __ASM_GENERIC_PLATFORM_DEVICE_H_
> +/*
> + * an architecture can override to define arch_setup_pdev_archdata
> + */
> +
> +#endif /* __ASM_GENERIC_PLATFORM_DEVICE_H_ */
Why not do:
#include <linux/platform_device.h>
#ifndef arch_setup_pdev_archdata
static inline void arch_setup_pdev_archdata(struct platform_device *pdev) { }
#endif
in asm-generic/platform-device.h
and the the call in platform_device_alloc() can be unconditional. If the arch wants to override arch_setup_pdev_archdata, it defines the function and then does
#define arch_setup_pdev_archdata arch_setup_pdev_archdata
before still including asm-generic/platform_device.h
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: [PATCH 2/3] powerpc: implement arch_setup_pdev_archdata
From: Stephen Rothwell @ 2010-08-05 15:44 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, akpm, gregkh, linux-kernel
In-Reply-To: <1281021347-1278-3-git-send-email-galak@kernel.crashing.org>
[-- Attachment #1: Type: text/plain, Size: 419 bytes --]
Hi Kumar,
On Thu, 5 Aug 2010 10:15:46 -0500 Kumar Gala <galak@kernel.crashing.org> wrote:
>
> +static inline void arch_setup_pdev_archdata(struct platform_device *pdev)
> +{
> + pdev->dev.dma_mask = &pdev->archdata.dma_mask;
> +
> + return;
> +}
The blank line and "return;" don't add anything.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: [PATCH 2/3] powerpc: implement arch_setup_pdev_archdata
From: Kumar Gala @ 2010-08-05 16:14 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linuxppc-dev, akpm, gregkh, linux-kernel
In-Reply-To: <20100806014455.8cab0ae9.sfr@canb.auug.org.au>
On Aug 5, 2010, at 10:44 AM, Stephen Rothwell wrote:
> Hi Kumar,
>=20
> On Thu, 5 Aug 2010 10:15:46 -0500 Kumar Gala =
<galak@kernel.crashing.org> wrote:
>>=20
>> +static inline void arch_setup_pdev_archdata(struct platform_device =
*pdev)
>> +{
>> + pdev->dev.dma_mask =3D &pdev->archdata.dma_mask;
>> +
>> + return;
>> +}
>=20
> The blank line and "return;" don't add anything.
Will fix.
- k=
^ 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