* Re: [PATCH] KVM: PPC: e500mc: Add support for single threaded vcpus on e6500 core
From: Scott Wood @ 2014-08-11 23:36 UTC (permalink / raw)
To: Mihai Caraman; +Cc: linuxppc-dev, kvm, kvm-ppc
In-Reply-To: <1407342808-15987-1-git-send-email-mihai.caraman@freescale.com>
On Wed, 2014-08-06 at 19:33 +0300, Mihai Caraman wrote:
> @@ -390,19 +400,30 @@ static void kvmppc_core_vcpu_free_e500mc(struct kvm_vcpu *vcpu)
>
> static int kvmppc_core_init_vm_e500mc(struct kvm *kvm)
> {
> - int lpid;
> + int i, lpid;
>
> - lpid = kvmppc_alloc_lpid();
> - if (lpid < 0)
> - return lpid;
> + /* The lpid pool supports only 2 entries now */
> + if (threads_per_core > 2)
> + return -ENOMEM;
> +
> + /* Each VM allocates one LPID per HW thread index */
> + for (i = 0; i < threads_per_core; i++) {
> + lpid = kvmppc_alloc_lpid();
> + if (lpid < 0)
> + return lpid;
> +
> + kvm->arch.lpid_pool[i] = lpid;
> + }
Wouldn't it be simpler to halve the size of the lpid pool that the
allocator sees, and just OR in the high bit based on the low bit of the
cpu number?
-Scott
^ permalink raw reply
* [PATCH 2/2] powerpc: Add ppc64 hard lockup detector support
From: Anton Blanchard @ 2014-08-11 23:31 UTC (permalink / raw)
To: benh, paulus, mpe, paulmck; +Cc: mikey, linuxppc-dev
In-Reply-To: <20140805145621.2fa2a372@kryten>
The hard lockup detector uses a PMU event as a periodic NMI to
detect if we are stuck (where stuck means no timer interrupts have
occurred).
Ben's rework of the ppc64 soft disable code has made ppc64 PMU
exceptions a partial NMI. They can get disabled if an external interrupt
comes in, but otherwise PMU interrupts will fire in interrupt disabled
regions.
I wrote a kernel module to test this patch and noticed we sometimes
missed hard lockup warnings. The RCU code detected the stall first and
issued an IPI to backtrace all CPUs. Unfortunately an IPI is an external
interrupt and that will hard disable interrupts, preventing the hard
lockup detector from going off.
If I reduced the hard lockup threshold to 5 seconds:
echo 5 > /proc/sys/kernel/watchdog_thresh
Then it would beat the RCU code in detecting a stall and get a
correct backtrace out.
Another downside is that our PMCs can only count to 2^31, so even when
we ask for 10 seconds of processor cycles, we end up taking a couple
of PMU exceptions a second.
Signed-off-by: Anton Blanchard <anton@samba.org>
---
v2: Mikey noticed a build issue with oprofile. Since our NMI is just
the PMU hardware it doesn't make any sense for oprofile to try and
use it.
Index: b/arch/powerpc/Kconfig
===================================================================
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -145,6 +145,7 @@ config PPC
select HAVE_IRQ_EXIT_ON_IRQ_STACK
select ARCH_USE_CMPXCHG_LOCKREF if PPC64
select HAVE_ARCH_AUDITSYSCALL
+ select HAVE_PERF_EVENTS_NMI if PPC64
config GENERIC_CSUM
def_bool CPU_LITTLE_ENDIAN
Index: b/arch/powerpc/include/asm/nmi.h
===================================================================
--- /dev/null
+++ b/arch/powerpc/include/asm/nmi.h
@@ -0,0 +1,4 @@
+#ifndef _ASM_NMI_H
+#define _ASM_NMI_H
+
+#endif /* _ASM_NMI_H */
Index: b/arch/powerpc/kernel/setup_64.c
===================================================================
--- a/arch/powerpc/kernel/setup_64.c
+++ b/arch/powerpc/kernel/setup_64.c
@@ -800,3 +800,10 @@ unsigned long memory_block_size_bytes(vo
struct ppc_pci_io ppc_pci_io;
EXPORT_SYMBOL(ppc_pci_io);
#endif
+
+#ifdef CONFIG_HARDLOCKUP_DETECTOR
+u64 hw_nmi_get_sample_period(int watchdog_thresh)
+{
+ return ppc_proc_freq * watchdog_thresh;
+}
+#endif
Index: b/arch/Kconfig
===================================================================
--- a/arch/Kconfig
+++ b/arch/Kconfig
@@ -32,7 +32,7 @@ config HAVE_OPROFILE
config OPROFILE_NMI_TIMER
def_bool y
- depends on PERF_EVENTS && HAVE_PERF_EVENTS_NMI
+ depends on (PERF_EVENTS && HAVE_PERF_EVENTS_NMI) && !PPC
config KPROBES
bool "Kprobes"
^ permalink raw reply
* Re: [PATCH 1/2] powerpc/booke: Restrict SPE exception handlers to e200/e500 cores
From: Scott Wood @ 2014-08-11 22:52 UTC (permalink / raw)
To: Mihai Caraman; +Cc: linuxppc-dev, kvm-ppc
In-Reply-To: <1407314358-17653-1-git-send-email-mihai.caraman@freescale.com>
On Wed, 2014-08-06 at 11:39 +0300, Mihai Caraman wrote:
> SPE exception handlers are now defined for 32-bit e500mc cores even though
> SPE unit is not present and CONFIG_SPE is undefined.
>
> Restrict SPE exception handlers to e200/e500 cores adding CONFIG_SPE_POSSIBLE
> and consequently guard __stup_ivors and __setup_cpu functions.
>
> Signed-off-by: Mihai Caraman <mihai.caraman@freescale.com>
> ---
> arch/powerpc/kernel/cpu_setup_fsl_booke.S | 12 +++++++++++-
> arch/powerpc/kernel/cputable.c | 5 +++++
> arch/powerpc/kernel/head_fsl_booke.S | 18 +++++++++++++-----
> arch/powerpc/platforms/Kconfig.cputype | 6 +++++-
> 4 files changed, 34 insertions(+), 7 deletions(-)
>
> diff --git a/arch/powerpc/kernel/cpu_setup_fsl_booke.S b/arch/powerpc/kernel/cpu_setup_fsl_booke.S
> index 4f1393d..44bb2c9 100644
> --- a/arch/powerpc/kernel/cpu_setup_fsl_booke.S
> +++ b/arch/powerpc/kernel/cpu_setup_fsl_booke.S
> @@ -91,6 +91,7 @@ _GLOBAL(setup_altivec_idle)
>
> blr
>
> +#if defined(CONFIG_E500) && defined(CONFIG_PPC_E500MC)
When would you ever have CONFIG_PPC_E500MC without CONFIG_E500?
> diff --git a/arch/powerpc/kernel/head_fsl_booke.S b/arch/powerpc/kernel/head_fsl_booke.S
> index b497188..4f8930f 100644
> --- a/arch/powerpc/kernel/head_fsl_booke.S
> +++ b/arch/powerpc/kernel/head_fsl_booke.S
> @@ -613,6 +613,7 @@ END_FTR_SECTION_IFSET(CPU_FTR_EMB_HV)
> mfspr r10, SPRN_SPRG_RSCRATCH0
> b InstructionStorage
>
> +/* Define SPE handlers for e200 and e500v2 */
> #ifdef CONFIG_SPE
> /* SPE Unavailable */
> START_EXCEPTION(SPEUnavailable)
> @@ -622,10 +623,10 @@ END_FTR_SECTION_IFSET(CPU_FTR_EMB_HV)
> b fast_exception_return
> 1: addi r3,r1,STACK_FRAME_OVERHEAD
> EXC_XFER_EE_LITE(0x2010, KernelSPE)
> -#else
> +#elif CONFIG_SPE_POSSIBLE
#elif defined(CONFIG_SPE_POSSIBLE)
Likewise elsewhere
-Scott
^ permalink raw reply
* Mpc5125 nfc hw ecc problems
From: Daniel Mosquera @ 2014-08-11 19:55 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 514 bytes --]
Hi,
I'm trying to port the nfc nand driver from 2.6.39.1 linux kernel to 3.14.4
using 4k nand blocks and 2k page size and 24bit hw ecc.
At the current time I have been able to make ecc, page read, and page write
to work but I cannot make oob read and write to work.
The main problem I'm facing is that I don't know how the ecc layout in the
spare area works in mpc5125.
Please, could anybody tell where I could get information about how to tell
linux the correct ecc oob parameters?
Thanks in advance,
Daniel
[-- Attachment #2: Type: text/html, Size: 627 bytes --]
^ permalink raw reply
* Re: [PATCH v2 2/2] PCI/MSI: Remove arch_msi_check_device()
From: Alexander Gordeev @ 2014-08-11 19:35 UTC (permalink / raw)
To: Bharat.Bhushan@freescale.com
Cc: Bjorn Helgaas, linux-pci@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org
In-Reply-To: <0a23568bd6eb4dfbb5f4acc96bba3706@BLUPR03MB566.namprd03.prod.outlook.com>
On Mon, Aug 11, 2014 at 02:33:25PM +0000, Bharat.Bhushan@freescale.com wrote:
>
>
> > -----Original Message-----
> > From: linux-pci-owner@vger.kernel.org [mailto:linux-pci-owner@vger.kernel.org]
> > On Behalf Of Alexander Gordeev
> > Sent: Monday, August 11, 2014 5:16 PM
> > To: Bjorn Helgaas
> > Cc: linux-kernel@vger.kernel.org; linuxppc-dev@lists.ozlabs.org; linux-
> > pci@vger.kernel.org
> > Subject: [PATCH v2 2/2] PCI/MSI: Remove arch_msi_check_device()
> >
> > There are no archs that override arch_msi_check_device() hook. Remove it as it
> > is completely redundant.
>
> Is not we are still overriding this in powerpc (not sure I missed some patch , if so please point to that).
Patch 1/2 ;)
> $ grep -r arch_msi_check_device arch/powerpc/
> Binary file arch/powerpc/kernel/msi.o matches
> arch/powerpc/kernel/msi.c:int arch_msi_check_device(struct pci_dev* dev, int nvec, int type)
> Binary file arch/powerpc/kernel/built-in.o matches
>
> Thanks
> -Bharat
>
> >
> > If an arch would need to check MSI/MSI-X possibility for a device it should make
> > it within arch_setup_msi_irqs() hook.
> >
> > Cc: linuxppc-dev@lists.ozlabs.org
> > Cc: linux-pci@vger.kernel.org
> > Signed-off-by: Alexander Gordeev <agordeev@redhat.com>
> > ---
> > drivers/pci/msi.c | 49 +++++++++++++------------------------------------
> > include/linux/msi.h | 3 ---
> > 2 files changed, 13 insertions(+), 39 deletions(-)
> >
> > diff --git a/drivers/pci/msi.c b/drivers/pci/msi.c index 5a40516..6c2cc41 100644
> > --- a/drivers/pci/msi.c
> > +++ b/drivers/pci/msi.c
> > @@ -56,16 +56,6 @@ void __weak arch_teardown_msi_irq(unsigned int irq)
> > chip->teardown_irq(chip, irq);
> > }
> >
> > -int __weak arch_msi_check_device(struct pci_dev *dev, int nvec, int type) -{
> > - struct msi_chip *chip = dev->bus->msi;
> > -
> > - if (!chip || !chip->check_device)
> > - return 0;
> > -
> > - return chip->check_device(chip, dev, nvec, type);
> > -}
> > -
> > int __weak arch_setup_msi_irqs(struct pci_dev *dev, int nvec, int type) {
> > struct msi_desc *entry;
> > @@ -806,22 +796,23 @@ out_free:
> > }
> >
> > /**
> > - * pci_msi_check_device - check whether MSI may be enabled on a device
> > + * pci_msi_supported - check whether MSI may be enabled on a device
> > * @dev: pointer to the pci_dev data structure of MSI device function
> > * @nvec: how many MSIs have been requested ?
> > - * @type: are we checking for MSI or MSI-X ?
> > *
> > * Look at global flags, the device itself, and its parent buses
> > * to determine if MSI/-X are supported for the device. If MSI/-X is
> > * supported return 0, else return an error code.
> > **/
> > -static int pci_msi_check_device(struct pci_dev *dev, int nvec, int type)
> > +static int pci_msi_supported(struct pci_dev *dev, int nvec)
> > {
> > struct pci_bus *bus;
> > - int ret;
> >
> > /* MSI must be globally enabled and supported by the device */
> > - if (!pci_msi_enable || !dev || dev->no_msi)
> > + if (!pci_msi_enable)
> > + return -EINVAL;
> > +
> > + if (!dev || dev->no_msi || dev->current_state != PCI_D0)
> > return -EINVAL;
> >
> > /*
> > @@ -843,10 +834,6 @@ static int pci_msi_check_device(struct pci_dev *dev, int
> > nvec, int type)
> > if (bus->bus_flags & PCI_BUS_FLAGS_NO_MSI)
> > return -EINVAL;
> >
> > - ret = arch_msi_check_device(dev, nvec, type);
> > - if (ret)
> > - return ret;
> > -
> > return 0;
> > }
> >
> > @@ -949,13 +936,13 @@ int pci_enable_msix(struct pci_dev *dev, struct msix_entry
> > *entries, int nvec)
> > int status, nr_entries;
> > int i, j;
> >
> > - if (!entries || !dev->msix_cap || dev->current_state != PCI_D0)
> > - return -EINVAL;
> > -
> > - status = pci_msi_check_device(dev, nvec, PCI_CAP_ID_MSIX);
> > + status = pci_msi_supported(dev, nvec);
> > if (status)
> > return status;
> >
> > + if (!entries)
> > + return -EINVAL;
> > +
> > nr_entries = pci_msix_vec_count(dev);
> > if (nr_entries < 0)
> > return nr_entries;
> > @@ -1062,8 +1049,9 @@ int pci_enable_msi_range(struct pci_dev *dev, int minvec,
> > int maxvec)
> > int nvec;
> > int rc;
> >
> > - if (dev->current_state != PCI_D0)
> > - return -EINVAL;
> > + rc = pci_msi_supported(dev, minvec);
> > + if (rc)
> > + return rc;
> >
> > WARN_ON(!!dev->msi_enabled);
> >
> > @@ -1086,17 +1074,6 @@ int pci_enable_msi_range(struct pci_dev *dev, int minvec,
> > int maxvec)
> > nvec = maxvec;
> >
> > do {
> > - rc = pci_msi_check_device(dev, nvec, PCI_CAP_ID_MSI);
> > - if (rc < 0) {
> > - return rc;
> > - } else if (rc > 0) {
> > - if (rc < minvec)
> > - return -ENOSPC;
> > - nvec = rc;
> > - }
> > - } while (rc);
> > -
> > - do {
> > rc = msi_capability_init(dev, nvec);
> > if (rc < 0) {
> > return rc;
> > diff --git a/include/linux/msi.h b/include/linux/msi.h index 8103f32..dbf7cc9
> > 100644
> > --- a/include/linux/msi.h
> > +++ b/include/linux/msi.h
> > @@ -60,7 +60,6 @@ int arch_setup_msi_irq(struct pci_dev *dev, struct msi_desc
> > *desc); void arch_teardown_msi_irq(unsigned int irq); int
> > arch_setup_msi_irqs(struct pci_dev *dev, int nvec, int type); void
> > arch_teardown_msi_irqs(struct pci_dev *dev); -int arch_msi_check_device(struct
> > pci_dev* dev, int nvec, int type); void arch_restore_msi_irqs(struct pci_dev
> > *dev);
> >
> > void default_teardown_msi_irqs(struct pci_dev *dev); @@ -77,8 +76,6 @@ struct
> > msi_chip {
> > int (*setup_irq)(struct msi_chip *chip, struct pci_dev *dev,
> > struct msi_desc *desc);
> > void (*teardown_irq)(struct msi_chip *chip, unsigned int irq);
> > - int (*check_device)(struct msi_chip *chip, struct pci_dev *dev,
> > - int nvec, int type);
> > };
> >
> > #endif /* LINUX_MSI_H */
> > --
> > 1.9.3
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body
> > of a message to majordomo@vger.kernel.org More majordomo info at
> > http://vger.kernel.org/majordomo-info.html
--
Regards,
Alexander Gordeev
agordeev@redhat.com
^ permalink raw reply
* Re: [PATCH] powerpc: Fix "attempt to move .org backwards" error
From: Guenter Roeck @ 2014-08-11 16:25 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linuxppc-dev, linux-kernel, Mahesh Salgaonkar
In-Reply-To: <20140811102052.6d9c28cb@canb.auug.org.au>
On 08/10/2014 05:20 PM, Stephen Rothwell wrote:
> Hi Guenter,
>
> On Fri, 8 Aug 2014 22:22:12 -0700 Guenter Roeck <linux@roeck-us.net> wrote:
>>
>> Once again, we see
>>
>> arch/powerpc/kernel/exceptions-64s.S: Assembler messages:
>> arch/powerpc/kernel/exceptions-64s.S:865: Error: attempt to move .org backwards
>> arch/powerpc/kernel/exceptions-64s.S:866: Error: attempt to move .org backwards
>> arch/powerpc/kernel/exceptions-64s.S:890: Error: attempt to move .org backwards
>>
>> when compiling ppc:allmodconfig.
>>
>> This time the problem has been caused by to commit 0869b6fd209bda
>> ("powerpc/book3s: Add basic infrastructure to handle HMI in Linux"),
>> which adds functions hmi_exception_early and hmi_exception_after_realmode
>> into a critical (size-limited) code area, even though that does not appear
>> to be necessary.
>>
>> Move those functions to a non-critical area of the file.
>>
>> Cc: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
>> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
>> ---
>> Compile tested with all ppc configurations.
>> The reported checkpatch error appears to be a false positive.
>
> Thanks.
>
> I have added that to my fixes tree for today.
>
Thanks!
Guenter
^ permalink raw reply
* RE: [PATCH v2 2/2] PCI/MSI: Remove arch_msi_check_device()
From: Bharat.Bhushan @ 2014-08-11 14:33 UTC (permalink / raw)
To: Alexander Gordeev, Bjorn Helgaas
Cc: linux-pci@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
linux-kernel@vger.kernel.org
In-Reply-To: <20140811114536.GA3427@dhcp-27-160.brq.redhat.com>
> -----Original Message-----
> From: linux-pci-owner@vger.kernel.org [mailto:linux-pci-owner@vger.kernel=
.org]
> On Behalf Of Alexander Gordeev
> Sent: Monday, August 11, 2014 5:16 PM
> To: Bjorn Helgaas
> Cc: linux-kernel@vger.kernel.org; linuxppc-dev@lists.ozlabs.org; linux-
> pci@vger.kernel.org
> Subject: [PATCH v2 2/2] PCI/MSI: Remove arch_msi_check_device()
>=20
> There are no archs that override arch_msi_check_device() hook. Remove it =
as it
> is completely redundant.
Is not we are still overriding this in powerpc (not sure I missed some patc=
h , if so please point to that).
$ grep -r arch_msi_check_device arch/powerpc/
Binary file arch/powerpc/kernel/msi.o matches
arch/powerpc/kernel/msi.c:int arch_msi_check_device(struct pci_dev* dev, in=
t nvec, int type)
Binary file arch/powerpc/kernel/built-in.o matches
Thanks
-Bharat
>=20
> If an arch would need to check MSI/MSI-X possibility for a device it shou=
ld make
> it within arch_setup_msi_irqs() hook.
>=20
> Cc: linuxppc-dev@lists.ozlabs.org
> Cc: linux-pci@vger.kernel.org
> Signed-off-by: Alexander Gordeev <agordeev@redhat.com>
> ---
> drivers/pci/msi.c | 49 +++++++++++++----------------------------------=
--
> include/linux/msi.h | 3 ---
> 2 files changed, 13 insertions(+), 39 deletions(-)
>=20
> diff --git a/drivers/pci/msi.c b/drivers/pci/msi.c index 5a40516..6c2cc41=
100644
> --- a/drivers/pci/msi.c
> +++ b/drivers/pci/msi.c
> @@ -56,16 +56,6 @@ void __weak arch_teardown_msi_irq(unsigned int irq)
> chip->teardown_irq(chip, irq);
> }
>=20
> -int __weak arch_msi_check_device(struct pci_dev *dev, int nvec, int type=
) -{
> - struct msi_chip *chip =3D dev->bus->msi;
> -
> - if (!chip || !chip->check_device)
> - return 0;
> -
> - return chip->check_device(chip, dev, nvec, type);
> -}
> -
> int __weak arch_setup_msi_irqs(struct pci_dev *dev, int nvec, int type) =
{
> struct msi_desc *entry;
> @@ -806,22 +796,23 @@ out_free:
> }
>=20
> /**
> - * pci_msi_check_device - check whether MSI may be enabled on a device
> + * pci_msi_supported - check whether MSI may be enabled on a device
> * @dev: pointer to the pci_dev data structure of MSI device function
> * @nvec: how many MSIs have been requested ?
> - * @type: are we checking for MSI or MSI-X ?
> *
> * Look at global flags, the device itself, and its parent buses
> * to determine if MSI/-X are supported for the device. If MSI/-X is
> * supported return 0, else return an error code.
> **/
> -static int pci_msi_check_device(struct pci_dev *dev, int nvec, int type)
> +static int pci_msi_supported(struct pci_dev *dev, int nvec)
> {
> struct pci_bus *bus;
> - int ret;
>=20
> /* MSI must be globally enabled and supported by the device */
> - if (!pci_msi_enable || !dev || dev->no_msi)
> + if (!pci_msi_enable)
> + return -EINVAL;
> +
> + if (!dev || dev->no_msi || dev->current_state !=3D PCI_D0)
> return -EINVAL;
>=20
> /*
> @@ -843,10 +834,6 @@ static int pci_msi_check_device(struct pci_dev *dev,=
int
> nvec, int type)
> if (bus->bus_flags & PCI_BUS_FLAGS_NO_MSI)
> return -EINVAL;
>=20
> - ret =3D arch_msi_check_device(dev, nvec, type);
> - if (ret)
> - return ret;
> -
> return 0;
> }
>=20
> @@ -949,13 +936,13 @@ int pci_enable_msix(struct pci_dev *dev, struct msi=
x_entry
> *entries, int nvec)
> int status, nr_entries;
> int i, j;
>=20
> - if (!entries || !dev->msix_cap || dev->current_state !=3D PCI_D0)
> - return -EINVAL;
> -
> - status =3D pci_msi_check_device(dev, nvec, PCI_CAP_ID_MSIX);
> + status =3D pci_msi_supported(dev, nvec);
> if (status)
> return status;
>=20
> + if (!entries)
> + return -EINVAL;
> +
> nr_entries =3D pci_msix_vec_count(dev);
> if (nr_entries < 0)
> return nr_entries;
> @@ -1062,8 +1049,9 @@ int pci_enable_msi_range(struct pci_dev *dev, int m=
invec,
> int maxvec)
> int nvec;
> int rc;
>=20
> - if (dev->current_state !=3D PCI_D0)
> - return -EINVAL;
> + rc =3D pci_msi_supported(dev, minvec);
> + if (rc)
> + return rc;
>=20
> WARN_ON(!!dev->msi_enabled);
>=20
> @@ -1086,17 +1074,6 @@ int pci_enable_msi_range(struct pci_dev *dev, int =
minvec,
> int maxvec)
> nvec =3D maxvec;
>=20
> do {
> - rc =3D pci_msi_check_device(dev, nvec, PCI_CAP_ID_MSI);
> - if (rc < 0) {
> - return rc;
> - } else if (rc > 0) {
> - if (rc < minvec)
> - return -ENOSPC;
> - nvec =3D rc;
> - }
> - } while (rc);
> -
> - do {
> rc =3D msi_capability_init(dev, nvec);
> if (rc < 0) {
> return rc;
> diff --git a/include/linux/msi.h b/include/linux/msi.h index 8103f32..dbf=
7cc9
> 100644
> --- a/include/linux/msi.h
> +++ b/include/linux/msi.h
> @@ -60,7 +60,6 @@ int arch_setup_msi_irq(struct pci_dev *dev, struct msi_=
desc
> *desc); void arch_teardown_msi_irq(unsigned int irq); int
> arch_setup_msi_irqs(struct pci_dev *dev, int nvec, int type); void
> arch_teardown_msi_irqs(struct pci_dev *dev); -int arch_msi_check_device(s=
truct
> pci_dev* dev, int nvec, int type); void arch_restore_msi_irqs(struct pci=
_dev
> *dev);
>=20
> void default_teardown_msi_irqs(struct pci_dev *dev); @@ -77,8 +76,6 @@ s=
truct
> msi_chip {
> int (*setup_irq)(struct msi_chip *chip, struct pci_dev *dev,
> struct msi_desc *desc);
> void (*teardown_irq)(struct msi_chip *chip, unsigned int irq);
> - int (*check_device)(struct msi_chip *chip, struct pci_dev *dev,
> - int nvec, int type);
> };
>=20
> #endif /* LINUX_MSI_H */
> --
> 1.9.3
>=20
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pci" in t=
he body
> of a message to majordomo@vger.kernel.org More majordomo info at
> http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 1/2] powerpc/pseries: Failure on removing device node
From: Nathan Fontenot @ 2014-08-11 14:16 UTC (permalink / raw)
To: Gavin Shan, linuxppc-dev; +Cc: stable
In-Reply-To: <1407748580-3412-1-git-send-email-gwshan@linux.vnet.ibm.com>
On 08/11/2014 04:16 AM, Gavin Shan wrote:
> While running command "drmgr -c phb -r -s 'PHB 528'", following
> backtrace jumped out because the target device node isn't marked
> with OF_DETACHED by of_detach_node(), which caused by error
> returned from memory hotplug related reconfig notifier when
> disabling CONFIG_MEMORY_HOTREMOVE. The patch fixes it.
>
Could you provide some more context here.
Your comment claims that you hit an error while trying to remove a PHB,
but the fix you provided is for memory hotplug. This changes the
rturn code to zero which usually inidcates success except that
your comment states you disabled memory hotplug remove.
I think the fix we need to have here is to update the version of
pseries_remove_mem_node() when CONFIG_MEMORY_HOTREMOVE is disabled
to validate that the node is a memory node and return the proper value
instead of just returning -EOPNOTSUPP in all cases.
The pseries_remove_mem_node() routine when memory removed is enabled
already does this.
-Nathan
> ERROR: Bad of_node_put() on /pci@800000020000210/ethernet@0
> CPU: 14 PID: 2252 Comm: drmgr Tainted: G W 3.16.0+ #427
> Call Trace:
> [c000000012a776a0] [c000000000013d9c] .show_stack+0x88/0x148 (unreliable)
> [c000000012a77750] [c00000000083cd34] .dump_stack+0x7c/0x9c
> [c000000012a777d0] [c0000000006807c4] .of_node_release+0x58/0xe0
> [c000000012a77860] [c00000000038a7d0] .kobject_release+0x174/0x1b8
> [c000000012a77900] [c00000000038a884] .kobject_put+0x70/0x78
> [c000000012a77980] [c000000000681680] .of_node_put+0x28/0x34
> [c000000012a77a00] [c000000000681ea8] .__of_get_next_child+0x64/0x70
> [c000000012a77a90] [c000000000682138] .of_find_node_by_path+0x1b8/0x20c
> [c000000012a77b40] [c000000000051840] .ofdt_write+0x308/0x688
> [c000000012a77c20] [c000000000238430] .proc_reg_write+0xb8/0xd4
> [c000000012a77cd0] [c0000000001cbeac] .vfs_write+0xec/0x1f8
> [c000000012a77d70] [c0000000001cc3b0] .SyS_write+0x58/0xa0
> [c000000012a77e30] [c00000000000a064] syscall_exit+0x0/0x98
>
> Cc: stable@vger.kernel.org
> Signed-off-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
> ---
> arch/powerpc/platforms/pseries/hotplug-memory.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/powerpc/platforms/pseries/hotplug-memory.c b/arch/powerpc/platforms/pseries/hotplug-memory.c
> index 7995135..24abc5c 100644
> --- a/arch/powerpc/platforms/pseries/hotplug-memory.c
> +++ b/arch/powerpc/platforms/pseries/hotplug-memory.c
> @@ -146,7 +146,7 @@ static inline int pseries_remove_memblock(unsigned long base,
> }
> static inline int pseries_remove_mem_node(struct device_node *np)
> {
> - return -EOPNOTSUPP;
> + return 0;
> }
> #endif /* CONFIG_MEMORY_HOTREMOVE */
>
>
^ permalink raw reply
* Re: [PATCH] KVM: PPC: e500mc: Add support for single threaded vcpus on e6500 core
From: Alexander Graf @ 2014-08-11 14:01 UTC (permalink / raw)
To: Mihai Caraman, kvm-ppc; +Cc: linuxppc-dev, kvm
In-Reply-To: <1407342808-15987-1-git-send-email-mihai.caraman@freescale.com>
On 06.08.14 18:33, Mihai Caraman wrote:
> ePAPR represents hardware threads as cpu node properties in device tree.
> So with existing QEMU, hardware threads are simply exposed as vcpus with
> one hardware thread.
>
> The e6500 core shares TLBs between hardware threads. Without tlb write
> conditional instruction, the Linux kernel uses per core mechanisms to
> protect against duplicate TLB entries.
>
> The guest is unable to detect real siblings threads, so it can't use a
> TLB protection mechanism. An alternative solution is to use the hypervisor
> to allocate different lpids to guest's vcpus running simultaneous on real
> siblings threads. This patch moves lpid to vcpu level and allocates a pool
> of lpids (equal to the number of threads per core) per VM.
>
> Signed-off-by: Mihai Caraman <mihai.caraman@freescale.com>
> ---
> Please rebase this patch before
> [PATCH v3 5/5] KVM: PPC: Book3E: Enable e6500 core
> to proper handle SMP guests.
>
> arch/powerpc/include/asm/kvm_host.h | 5 ++++
> arch/powerpc/kernel/asm-offsets.c | 4 +++
> arch/powerpc/kvm/e500_mmu_host.c | 15 +++++-----
> arch/powerpc/kvm/e500mc.c | 55 +++++++++++++++++++++++++------------
> 4 files changed, 55 insertions(+), 24 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/kvm_host.h b/arch/powerpc/include/asm/kvm_host.h
> index 98d9dd5..1b0bb4a 100644
> --- a/arch/powerpc/include/asm/kvm_host.h
> +++ b/arch/powerpc/include/asm/kvm_host.h
> @@ -227,7 +227,11 @@ struct kvm_arch_memory_slot {
> };
>
> struct kvm_arch {
> +#ifdef CONFIG_KVM_BOOKE_HV
> + unsigned int lpid_pool[2];
> +#else
> unsigned int lpid;
> +#endif
> #ifdef CONFIG_KVM_BOOK3S_HV_POSSIBLE
> unsigned long hpt_virt;
> struct revmap_entry *revmap;
> @@ -435,6 +439,7 @@ struct kvm_vcpu_arch {
> u32 eplc;
> u32 epsc;
> u32 oldpir;
> + u32 lpid;
> #endif
>
> #if defined(CONFIG_BOOKE)
> diff --git a/arch/powerpc/kernel/asm-offsets.c b/arch/powerpc/kernel/asm-offsets.c
> index ab9ae04..5a30b87 100644
> --- a/arch/powerpc/kernel/asm-offsets.c
> +++ b/arch/powerpc/kernel/asm-offsets.c
> @@ -483,7 +483,11 @@ int main(void)
> DEFINE(VCPU_SHARED_MAS6, offsetof(struct kvm_vcpu_arch_shared, mas6));
>
> DEFINE(VCPU_KVM, offsetof(struct kvm_vcpu, kvm));
> +#ifdef CONFIG_KVM_BOOKE_HV
> + DEFINE(KVM_LPID, offsetof(struct kvm_vcpu, arch.lpid));
This is a recipe for confusion. Please use a name that indicates that
we're looking at the vcpu - VCPU_LPID for example.
> +#else
> DEFINE(KVM_LPID, offsetof(struct kvm, arch.lpid));
> +#endif
>
> /* book3s */
> #ifdef CONFIG_KVM_BOOK3S_HV_POSSIBLE
> diff --git a/arch/powerpc/kvm/e500_mmu_host.c b/arch/powerpc/kvm/e500_mmu_host.c
> index 4150826..a233cc6 100644
> --- a/arch/powerpc/kvm/e500_mmu_host.c
> +++ b/arch/powerpc/kvm/e500_mmu_host.c
> @@ -69,7 +69,7 @@ static inline u32 e500_shadow_mas3_attrib(u32 mas3, int usermode)
> * writing shadow tlb entry to host TLB
> */
> static inline void __write_host_tlbe(struct kvm_book3e_206_tlb_entry *stlbe,
> - uint32_t mas0)
> + uint32_t mas0, uint32_t *lpid)
Why a pointer?
> {
> unsigned long flags;
>
> @@ -80,6 +80,8 @@ static inline void __write_host_tlbe(struct kvm_book3e_206_tlb_entry *stlbe,
> mtspr(SPRN_MAS3, (u32)stlbe->mas7_3);
> mtspr(SPRN_MAS7, (u32)(stlbe->mas7_3 >> 32));
> #ifdef CONFIG_KVM_BOOKE_HV
> + /* populate mas8 with latest LPID */
What is a "latest LPID"? Really all you're doing is you're populating
mas8 with the thread-specific lpid.
> + stlbe->mas8 = MAS8_TGS | *lpid;
> mtspr(SPRN_MAS8, stlbe->mas8);
Just ignore the value in stlbe and directly write MAS8_TGS | lpid into mas8.
> #endif
> asm volatile("isync; tlbwe" : : : "memory");
> @@ -129,11 +131,12 @@ static inline void write_host_tlbe(struct kvmppc_vcpu_e500 *vcpu_e500,
>
> if (tlbsel == 0) {
> mas0 = get_host_mas0(stlbe->mas2);
> - __write_host_tlbe(stlbe, mas0);
> + __write_host_tlbe(stlbe, mas0, &vcpu_e500->vcpu.arch.lpid);
> } else {
> __write_host_tlbe(stlbe,
> MAS0_TLBSEL(1) |
> - MAS0_ESEL(to_htlb1_esel(sesel)));
> + MAS0_ESEL(to_htlb1_esel(sesel)),
> + &vcpu_e500->vcpu.arch.lpid);
> }
> }
>
> @@ -318,9 +321,7 @@ static void kvmppc_e500_setup_stlbe(
> stlbe->mas7_3 = ((u64)pfn << PAGE_SHIFT) |
> e500_shadow_mas3_attrib(gtlbe->mas7_3, pr);
>
> -#ifdef CONFIG_KVM_BOOKE_HV
> - stlbe->mas8 = MAS8_TGS | vcpu->kvm->arch.lpid;
> -#endif
> + /* Set mas8 when executing tlbwe since LPID can change dynamically */
Please be more precise in this comment.
> }
>
> static inline int kvmppc_e500_shadow_map(struct kvmppc_vcpu_e500 *vcpu_e500,
> @@ -632,7 +633,7 @@ int kvmppc_load_last_inst(struct kvm_vcpu *vcpu, enum instruction_type type,
>
> local_irq_save(flags);
> mtspr(SPRN_MAS6, (vcpu->arch.pid << MAS6_SPID_SHIFT) | addr_space);
> - mtspr(SPRN_MAS5, MAS5_SGS | vcpu->kvm->arch.lpid);
> + mtspr(SPRN_MAS5, MAS5_SGS | vcpu->arch.lpid);
> asm volatile("tlbsx 0, %[geaddr]\n" : :
> [geaddr] "r" (geaddr));
> mtspr(SPRN_MAS5, 0);
> diff --git a/arch/powerpc/kvm/e500mc.c b/arch/powerpc/kvm/e500mc.c
> index aa48dc3..c0a0d9d 100644
> --- a/arch/powerpc/kvm/e500mc.c
> +++ b/arch/powerpc/kvm/e500mc.c
> @@ -24,6 +24,7 @@
> #include <asm/tlbflush.h>
> #include <asm/kvm_ppc.h>
> #include <asm/dbell.h>
> +#include <asm/cputhreads.h>
>
> #include "booke.h"
> #include "e500.h"
> @@ -48,10 +49,11 @@ void kvmppc_set_pending_interrupt(struct kvm_vcpu *vcpu, enum int_class type)
> return;
> }
>
> -
> - tag = PPC_DBELL_LPID(vcpu->kvm->arch.lpid) | vcpu->vcpu_id;
> + preempt_disable();
> + tag = PPC_DBELL_LPID(vcpu->arch.lpid) | vcpu->vcpu_id;
> mb();
> ppc_msgsnd(dbell_type, 0, tag);
> + preempt_enable();
> }
>
> /* gtlbe must not be mapped by more than one host tlb entry */
> @@ -60,12 +62,11 @@ void kvmppc_e500_tlbil_one(struct kvmppc_vcpu_e500 *vcpu_e500,
> {
> unsigned int tid, ts;
> gva_t eaddr;
> - u32 val, lpid;
> + u32 val;
> unsigned long flags;
>
> ts = get_tlb_ts(gtlbe);
> tid = get_tlb_tid(gtlbe);
> - lpid = vcpu_e500->vcpu.kvm->arch.lpid;
>
> /* We search the host TLB to invalidate its shadow TLB entry */
> val = (tid << 16) | ts;
> @@ -74,7 +75,7 @@ void kvmppc_e500_tlbil_one(struct kvmppc_vcpu_e500 *vcpu_e500,
> local_irq_save(flags);
>
> mtspr(SPRN_MAS6, val);
> - mtspr(SPRN_MAS5, MAS5_SGS | lpid);
> + mtspr(SPRN_MAS5, MAS5_SGS | vcpu_e500->vcpu.arch.lpid);
>
> asm volatile("tlbsx 0, %[eaddr]\n" : : [eaddr] "r" (eaddr));
> val = mfspr(SPRN_MAS1);
> @@ -95,7 +96,7 @@ void kvmppc_e500_tlbil_all(struct kvmppc_vcpu_e500 *vcpu_e500)
> unsigned long flags;
>
> local_irq_save(flags);
> - mtspr(SPRN_MAS5, MAS5_SGS | vcpu_e500->vcpu.kvm->arch.lpid);
> + mtspr(SPRN_MAS5, MAS5_SGS | vcpu_e500->vcpu.arch.lpid);
> asm volatile("tlbilxlpid");
> mtspr(SPRN_MAS5, 0);
> local_irq_restore(flags);
> @@ -115,10 +116,21 @@ static DEFINE_PER_CPU(struct kvm_vcpu *[KVMPPC_NR_LPIDS], last_vcpu_of_lpid);
> static void kvmppc_core_vcpu_load_e500mc(struct kvm_vcpu *vcpu, int cpu)
> {
> struct kvmppc_vcpu_e500 *vcpu_e500 = to_e500(vcpu);
> + int lpid_idx = 0;
>
> kvmppc_booke_vcpu_load(vcpu, cpu);
>
> - mtspr(SPRN_LPID, vcpu->kvm->arch.lpid);
> + /* Get current core's thread index */
> + lpid_idx = mfspr(SPRN_PIR) % threads_per_core;
smp_processor_id()? Also since you've already defined that we can only
have 2 threads, use & 1 instead of modulo - it's a lot faster. Just
guard it with firmware_has_feature(SMT) and default lpid_idx to 0.
> + vcpu->arch.lpid = vcpu->kvm->arch.lpid_pool[lpid_idx];
> + vcpu->arch.eplc = EPC_EGS | (vcpu->arch.lpid << EPC_ELPID_SHIFT);
> + vcpu->arch.epsc = vcpu->arch.eplc;
> +
> + if (vcpu->arch.oldpir != mfspr(SPRN_PIR))
> + pr_debug("vcpu 0x%p loaded on PID %d, lpid %d\n",
> + vcpu, smp_processor_id(), (int)vcpu->arch.lpid);
Do we really need this?
> +
> + mtspr(SPRN_LPID, vcpu->arch.lpid);
> mtspr(SPRN_EPCR, vcpu->arch.shadow_epcr);
> mtspr(SPRN_GPIR, vcpu->vcpu_id);
> mtspr(SPRN_MSRP, vcpu->arch.shadow_msrp);
> @@ -141,9 +153,9 @@ static void kvmppc_core_vcpu_load_e500mc(struct kvm_vcpu *vcpu, int cpu)
> mtspr(SPRN_GESR, vcpu->arch.shared->esr);
>
> if (vcpu->arch.oldpir != mfspr(SPRN_PIR) ||
> - __get_cpu_var(last_vcpu_of_lpid)[vcpu->kvm->arch.lpid] != vcpu) {
> + __get_cpu_var(last_vcpu_of_lpid)[vcpu->arch.lpid] != vcpu) {
> kvmppc_e500_tlbil_all(vcpu_e500);
> - __get_cpu_var(last_vcpu_of_lpid)[vcpu->kvm->arch.lpid] = vcpu;
> + __get_cpu_var(last_vcpu_of_lpid)[vcpu->arch.lpid] = vcpu;
> }
> }
>
> @@ -203,8 +215,6 @@ int kvmppc_core_vcpu_setup(struct kvm_vcpu *vcpu)
> vcpu->arch.shadow_epcr |= SPRN_EPCR_ICM;
> #endif
> vcpu->arch.shadow_msrp = MSRP_UCLEP | MSRP_DEP | MSRP_PMMP;
> - vcpu->arch.eplc = EPC_EGS | (vcpu->kvm->arch.lpid << EPC_ELPID_SHIFT);
> - vcpu->arch.epsc = vcpu->arch.eplc;
>
> vcpu->arch.pvr = mfspr(SPRN_PVR);
> vcpu_e500->svr = mfspr(SPRN_SVR);
> @@ -390,19 +400,30 @@ static void kvmppc_core_vcpu_free_e500mc(struct kvm_vcpu *vcpu)
>
> static int kvmppc_core_init_vm_e500mc(struct kvm *kvm)
> {
> - int lpid;
> + int i, lpid;
>
> - lpid = kvmppc_alloc_lpid();
> - if (lpid < 0)
> - return lpid;
> + /* The lpid pool supports only 2 entries now */
> + if (threads_per_core > 2)
> + return -ENOMEM;
Use a different error code please. How about -ENOTSUPP?
Alex
> +
> + /* Each VM allocates one LPID per HW thread index */
> + for (i = 0; i < threads_per_core; i++) {
> + lpid = kvmppc_alloc_lpid();
> + if (lpid < 0)
> + return lpid;
> +
> + kvm->arch.lpid_pool[i] = lpid;
> + }
>
> - kvm->arch.lpid = lpid;
> return 0;
> }
>
> static void kvmppc_core_destroy_vm_e500mc(struct kvm *kvm)
> {
> - kvmppc_free_lpid(kvm->arch.lpid);
> + int i;
> +
> + for (i = 0; i < threads_per_core; i++)
> + kvmppc_free_lpid(kvm->arch.lpid_pool[i]);
> }
>
> static struct kvmppc_ops kvm_ops_e500mc = {
^ permalink raw reply
* unsubscribe
From: Deepak Pandian @ 2014-08-11 13:19 UTC (permalink / raw)
To: linuxppc-dev
^ permalink raw reply
* [PATCH v2 2/2] PCI/MSI: Remove arch_msi_check_device()
From: Alexander Gordeev @ 2014-08-11 11:45 UTC (permalink / raw)
To: Bjorn Helgaas; +Cc: linux-pci, linuxppc-dev, linux-kernel
In-Reply-To: <20140716222024.GE14366@google.com>
There are no archs that override arch_msi_check_device()
hook. Remove it as it is completely redundant.
If an arch would need to check MSI/MSI-X possibility for a
device it should make it within arch_setup_msi_irqs() hook.
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux-pci@vger.kernel.org
Signed-off-by: Alexander Gordeev <agordeev@redhat.com>
---
drivers/pci/msi.c | 49 +++++++++++++------------------------------------
include/linux/msi.h | 3 ---
2 files changed, 13 insertions(+), 39 deletions(-)
diff --git a/drivers/pci/msi.c b/drivers/pci/msi.c
index 5a40516..6c2cc41 100644
--- a/drivers/pci/msi.c
+++ b/drivers/pci/msi.c
@@ -56,16 +56,6 @@ void __weak arch_teardown_msi_irq(unsigned int irq)
chip->teardown_irq(chip, irq);
}
-int __weak arch_msi_check_device(struct pci_dev *dev, int nvec, int type)
-{
- struct msi_chip *chip = dev->bus->msi;
-
- if (!chip || !chip->check_device)
- return 0;
-
- return chip->check_device(chip, dev, nvec, type);
-}
-
int __weak arch_setup_msi_irqs(struct pci_dev *dev, int nvec, int type)
{
struct msi_desc *entry;
@@ -806,22 +796,23 @@ out_free:
}
/**
- * pci_msi_check_device - check whether MSI may be enabled on a device
+ * pci_msi_supported - check whether MSI may be enabled on a device
* @dev: pointer to the pci_dev data structure of MSI device function
* @nvec: how many MSIs have been requested ?
- * @type: are we checking for MSI or MSI-X ?
*
* Look at global flags, the device itself, and its parent buses
* to determine if MSI/-X are supported for the device. If MSI/-X is
* supported return 0, else return an error code.
**/
-static int pci_msi_check_device(struct pci_dev *dev, int nvec, int type)
+static int pci_msi_supported(struct pci_dev *dev, int nvec)
{
struct pci_bus *bus;
- int ret;
/* MSI must be globally enabled and supported by the device */
- if (!pci_msi_enable || !dev || dev->no_msi)
+ if (!pci_msi_enable)
+ return -EINVAL;
+
+ if (!dev || dev->no_msi || dev->current_state != PCI_D0)
return -EINVAL;
/*
@@ -843,10 +834,6 @@ static int pci_msi_check_device(struct pci_dev *dev, int nvec, int type)
if (bus->bus_flags & PCI_BUS_FLAGS_NO_MSI)
return -EINVAL;
- ret = arch_msi_check_device(dev, nvec, type);
- if (ret)
- return ret;
-
return 0;
}
@@ -949,13 +936,13 @@ int pci_enable_msix(struct pci_dev *dev, struct msix_entry *entries, int nvec)
int status, nr_entries;
int i, j;
- if (!entries || !dev->msix_cap || dev->current_state != PCI_D0)
- return -EINVAL;
-
- status = pci_msi_check_device(dev, nvec, PCI_CAP_ID_MSIX);
+ status = pci_msi_supported(dev, nvec);
if (status)
return status;
+ if (!entries)
+ return -EINVAL;
+
nr_entries = pci_msix_vec_count(dev);
if (nr_entries < 0)
return nr_entries;
@@ -1062,8 +1049,9 @@ int pci_enable_msi_range(struct pci_dev *dev, int minvec, int maxvec)
int nvec;
int rc;
- if (dev->current_state != PCI_D0)
- return -EINVAL;
+ rc = pci_msi_supported(dev, minvec);
+ if (rc)
+ return rc;
WARN_ON(!!dev->msi_enabled);
@@ -1086,17 +1074,6 @@ int pci_enable_msi_range(struct pci_dev *dev, int minvec, int maxvec)
nvec = maxvec;
do {
- rc = pci_msi_check_device(dev, nvec, PCI_CAP_ID_MSI);
- if (rc < 0) {
- return rc;
- } else if (rc > 0) {
- if (rc < minvec)
- return -ENOSPC;
- nvec = rc;
- }
- } while (rc);
-
- do {
rc = msi_capability_init(dev, nvec);
if (rc < 0) {
return rc;
diff --git a/include/linux/msi.h b/include/linux/msi.h
index 8103f32..dbf7cc9 100644
--- a/include/linux/msi.h
+++ b/include/linux/msi.h
@@ -60,7 +60,6 @@ int arch_setup_msi_irq(struct pci_dev *dev, struct msi_desc *desc);
void arch_teardown_msi_irq(unsigned int irq);
int arch_setup_msi_irqs(struct pci_dev *dev, int nvec, int type);
void arch_teardown_msi_irqs(struct pci_dev *dev);
-int arch_msi_check_device(struct pci_dev* dev, int nvec, int type);
void arch_restore_msi_irqs(struct pci_dev *dev);
void default_teardown_msi_irqs(struct pci_dev *dev);
@@ -77,8 +76,6 @@ struct msi_chip {
int (*setup_irq)(struct msi_chip *chip, struct pci_dev *dev,
struct msi_desc *desc);
void (*teardown_irq)(struct msi_chip *chip, unsigned int irq);
- int (*check_device)(struct msi_chip *chip, struct pci_dev *dev,
- int nvec, int type);
};
#endif /* LINUX_MSI_H */
--
1.9.3
^ permalink raw reply related
* Re: [PATCH 3/5] mmc: sdhci-pltfm: Do not use parent as the host's device
From: Russell King - ARM Linux @ 2014-08-11 10:02 UTC (permalink / raw)
To: Pawel Moll
Cc: Ulf Hansson, Arnd Bergmann, Stephen Warren, Greg Kroah-Hartman,
Peter De Schrijver, Anton Vorontsov, linux-mmc@vger.kernel.org,
Chris Ball, linux-kernel@vger.kernel.org,
linux-tegra@vger.kernel.org, arm@kernel.org, Catalin Marinas,
Olof Johansson, linuxppc-dev@lists.ozlabs.org, paul@pwsan.com,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <1407748550.3680.10.camel@hornet>
On Mon, Aug 11, 2014 at 10:15:50AM +0100, Pawel Moll wrote:
> On Mon, 2014-08-11 at 10:07 +0100, Ulf Hansson wrote:
> > Sorry for the delay. I suppose this make sense, but I really don't
> > know for sure.
> >
> > I guess we need some testing in linux-next, to get some confidence.
>
> Would you take it into -next then? Unless I'm completely wrong there
> should be no impact on any in-tree driver...
But not until 3.17-rc1 has been released. linux-next should not receive
new material other than bug fixes while a merge window is open.
--
FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* Re: [PATCH 3/5] mmc: sdhci-pltfm: Do not use parent as the host's device
From: Ulf Hansson @ 2014-08-11 9:32 UTC (permalink / raw)
To: Pawel Moll
Cc: paul@pwsan.com, Arnd Bergmann, Stephen Warren, Greg Kroah-Hartman,
Peter De Schrijver, Anton Vorontsov, linux-mmc@vger.kernel.org,
Chris Ball, linux-kernel@vger.kernel.org,
linux-tegra@vger.kernel.org, arm@kernel.org, Catalin Marinas,
Olof Johansson, linuxppc-dev@lists.ozlabs.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <1407748550.3680.10.camel@hornet>
On 11 August 2014 11:15, Pawel Moll <pawel.moll@arm.com> wrote:
> On Mon, 2014-08-11 at 10:07 +0100, Ulf Hansson wrote:
>> On 8 August 2014 18:36, Pawel Moll <pawel.moll@arm.com> wrote:
>> > On Fri, 2014-07-25 at 15:23 +0100, Pawel Moll wrote:
>> >> The code selecting a device for the sdhci host has been
>> >> continuously tweaked (4b711cb13843f5082e82970dd1e8031383134a65
>> >> "mmc: sdhci-pltfm: Add structure for host-specific data" and
>> >> a4d2177f00a5252d825236c5124bc1e9918bdb41 "mmc: sdhci-pltfm: dt
>> >> device does not pass parent to sdhci_alloc_host") while there
>> >> does not seem to be any reason to use platform device's parent
>> >> in the first place.
>> >>
>> >> The comment saying "Some PCI-based MFD need the parent here"
>> >> seem to refer to Timberdale FPGA driver (the only MFD driver
>> >> registering SDHCI cell, drivers/mfd/timberdale.c) but again,
>> >> the only situation when parent device matter is runtime PM,
>> >> which is not implemented for Timberdale.
>> >>
>> >> Cc: Chris Ball <chris@printf.net>
>> >> Cc: Anton Vorontsov <anton@enomsg.org>
>> >> Cc: Ulf Hansson <ulf.hansson@linaro.org>
>> >> Cc: linux-mmc@vger.kernel.org
>> >> Cc: linuxppc-dev@lists.ozlabs.org
>> >> Signed-off-by: Pawel Moll <pawel.moll@arm.com>
>> >> ---
>> >>
>> >> This patch is a part of effort to remove references to platform_bus
>> >> and make it static.
>> >>
>> >> Chris, Anton, Ulf - could you please advise if the assumptions
>> >> above are correct or if I'm completely wrong? Do you know what
>> >> where the real reasons to use parent originally? The PCI comment
>> >> seems like a red herring to me...
>> >
>> > Can I take the silence as a suggestion that the change looks ok-ish for
>> > you?
>>
>> Sorry for the delay. I suppose this make sense, but I really don't
>> know for sure.
>>
>> I guess we need some testing in linux-next, to get some confidence.
>
> Would you take it into -next then? Unless I'm completely wrong there
> should be no impact on any in-tree driver...
I will take it; though I think it's best to queue it for 3.18 to get
some more testing.
Kind regards
Uffe
^ permalink raw reply
* [PATCH 2/2] powerpc/pseries: Avoid deadlock on removing ddw
From: Gavin Shan @ 2014-08-11 9:16 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Gavin Shan, stable
In-Reply-To: <1407748580-3412-1-git-send-email-gwshan@linux.vnet.ibm.com>
Function remove_ddw() could be called in of_reconfig_notifier and
we potentially remove the dynamic DMA window property, which invokes
of_reconfig_notifier again. Eventually, it leads to the deadlock as
following backtrace shows.
The patch fixes the above issue by deferring releasing the dynamic
DMA window property while releasing the device node.
=============================================
[ INFO: possible recursive locking detected ]
3.16.0+ #428 Tainted: G W
---------------------------------------------
drmgr/2273 is trying to acquire lock:
((of_reconfig_chain).rwsem){.+.+..}, at: [<c000000000091890>] \
.__blocking_notifier_call_chain+0x40/0x78
but task is already holding lock:
((of_reconfig_chain).rwsem){.+.+..}, at: [<c000000000091890>] \
.__blocking_notifier_call_chain+0x40/0x78
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0
----
lock((of_reconfig_chain).rwsem);
lock((of_reconfig_chain).rwsem);
*** DEADLOCK ***
May be due to missing lock nesting notation
2 locks held by drmgr/2273:
#0: (sb_writers#4){.+.+.+}, at: [<c0000000001cbe70>] \
.vfs_write+0xb0/0x1f8
#1: ((of_reconfig_chain).rwsem){.+.+..}, at: [<c000000000091890>] \
.__blocking_notifier_call_chain+0x40/0x78
stack backtrace:
CPU: 17 PID: 2273 Comm: drmgr Tainted: G W 3.16.0+ #428
Call Trace:
[c0000000137e7000] [c000000000013d9c] .show_stack+0x88/0x148 (unreliable)
[c0000000137e70b0] [c00000000083cd34] .dump_stack+0x7c/0x9c
[c0000000137e7130] [c0000000000b8afc] .__lock_acquire+0x128c/0x1c68
[c0000000137e7280] [c0000000000b9a4c] .lock_acquire+0xe8/0x104
[c0000000137e7350] [c00000000083588c] .down_read+0x4c/0x90
[c0000000137e73e0] [c000000000091890] .__blocking_notifier_call_chain+0x40/0x78
[c0000000137e7490] [c000000000091900] .blocking_notifier_call_chain+0x38/0x48
[c0000000137e7520] [c000000000682a28] .of_reconfig_notify+0x34/0x5c
[c0000000137e75b0] [c000000000682a9c] .of_property_notify+0x4c/0x54
[c0000000137e7650] [c000000000682bf0] .of_remove_property+0x30/0xd4
[c0000000137e76f0] [c000000000052a44] .remove_ddw+0x144/0x168
[c0000000137e7790] [c000000000053204] .iommu_reconfig_notifier+0x30/0xe0
[c0000000137e7820] [c00000000009137c] .notifier_call_chain+0x6c/0xb4
[c0000000137e78c0] [c0000000000918ac] .__blocking_notifier_call_chain+0x5c/0x78
[c0000000137e7970] [c000000000091900] .blocking_notifier_call_chain+0x38/0x48
[c0000000137e7a00] [c000000000682a28] .of_reconfig_notify+0x34/0x5c
[c0000000137e7a90] [c000000000682e14] .of_detach_node+0x44/0x1fc
[c0000000137e7b40] [c0000000000518e4] .ofdt_write+0x3ac/0x688
[c0000000137e7c20] [c000000000238430] .proc_reg_write+0xb8/0xd4
[c0000000137e7cd0] [c0000000001cbeac] .vfs_write+0xec/0x1f8
[c0000000137e7d70] [c0000000001cc3b0] .SyS_write+0x58/0xa0
[c0000000137e7e30] [c00000000000a064] syscall_exit+0x0/0x98
Cc: stable@vger.kernel.org
Signed-off-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
---
arch/powerpc/platforms/pseries/iommu.c | 20 ++++++++++++++------
1 file changed, 14 insertions(+), 6 deletions(-)
diff --git a/arch/powerpc/platforms/pseries/iommu.c b/arch/powerpc/platforms/pseries/iommu.c
index 33b552f..4642d6a 100644
--- a/arch/powerpc/platforms/pseries/iommu.c
+++ b/arch/powerpc/platforms/pseries/iommu.c
@@ -721,13 +721,13 @@ static int __init disable_ddw_setup(char *str)
early_param("disable_ddw", disable_ddw_setup);
-static void remove_ddw(struct device_node *np)
+static void remove_ddw(struct device_node *np, bool remove_prop)
{
struct dynamic_dma_window_prop *dwp;
struct property *win64;
const u32 *ddw_avail;
u64 liobn;
- int len, ret;
+ int len, ret = 0;
ddw_avail = of_get_property(np, "ibm,ddw-applicable", &len);
win64 = of_find_property(np, DIRECT64_PROPNAME, NULL);
@@ -761,7 +761,8 @@ static void remove_ddw(struct device_node *np)
np->full_name, ret, ddw_avail[2], liobn);
delprop:
- ret = of_remove_property(np, win64);
+ if (remove_prop)
+ ret = of_remove_property(np, win64);
if (ret)
pr_warning("%s: failed to remove direct window property: %d\n",
np->full_name, ret);
@@ -805,7 +806,7 @@ static int find_existing_ddw_windows(void)
window = kzalloc(sizeof(*window), GFP_KERNEL);
if (!window || len < sizeof(struct dynamic_dma_window_prop)) {
kfree(window);
- remove_ddw(pdn);
+ remove_ddw(pdn, true);
continue;
}
@@ -1045,7 +1046,7 @@ out_free_window:
kfree(window);
out_clear_window:
- remove_ddw(pdn);
+ remove_ddw(pdn, true);
out_free_prop:
kfree(win64->name);
@@ -1255,7 +1256,14 @@ static int iommu_reconfig_notifier(struct notifier_block *nb, unsigned long acti
switch (action) {
case OF_RECONFIG_DETACH_NODE:
- remove_ddw(np);
+ /*
+ * Removing the property will invoke the reconfig
+ * notifier again, which causes dead-lock on the
+ * read-write semaphore of the notifier chain. So
+ * we have to remove the property when releasing
+ * the device node.
+ */
+ remove_ddw(np, false);
if (pci && pci->iommu_table)
iommu_free_table(pci->iommu_table, np->full_name);
--
1.8.3.2
^ permalink raw reply related
* [PATCH 1/2] powerpc/pseries: Failure on removing device node
From: Gavin Shan @ 2014-08-11 9:16 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Gavin Shan, stable
While running command "drmgr -c phb -r -s 'PHB 528'", following
backtrace jumped out because the target device node isn't marked
with OF_DETACHED by of_detach_node(), which caused by error
returned from memory hotplug related reconfig notifier when
disabling CONFIG_MEMORY_HOTREMOVE. The patch fixes it.
ERROR: Bad of_node_put() on /pci@800000020000210/ethernet@0
CPU: 14 PID: 2252 Comm: drmgr Tainted: G W 3.16.0+ #427
Call Trace:
[c000000012a776a0] [c000000000013d9c] .show_stack+0x88/0x148 (unreliable)
[c000000012a77750] [c00000000083cd34] .dump_stack+0x7c/0x9c
[c000000012a777d0] [c0000000006807c4] .of_node_release+0x58/0xe0
[c000000012a77860] [c00000000038a7d0] .kobject_release+0x174/0x1b8
[c000000012a77900] [c00000000038a884] .kobject_put+0x70/0x78
[c000000012a77980] [c000000000681680] .of_node_put+0x28/0x34
[c000000012a77a00] [c000000000681ea8] .__of_get_next_child+0x64/0x70
[c000000012a77a90] [c000000000682138] .of_find_node_by_path+0x1b8/0x20c
[c000000012a77b40] [c000000000051840] .ofdt_write+0x308/0x688
[c000000012a77c20] [c000000000238430] .proc_reg_write+0xb8/0xd4
[c000000012a77cd0] [c0000000001cbeac] .vfs_write+0xec/0x1f8
[c000000012a77d70] [c0000000001cc3b0] .SyS_write+0x58/0xa0
[c000000012a77e30] [c00000000000a064] syscall_exit+0x0/0x98
Cc: stable@vger.kernel.org
Signed-off-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
---
arch/powerpc/platforms/pseries/hotplug-memory.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/platforms/pseries/hotplug-memory.c b/arch/powerpc/platforms/pseries/hotplug-memory.c
index 7995135..24abc5c 100644
--- a/arch/powerpc/platforms/pseries/hotplug-memory.c
+++ b/arch/powerpc/platforms/pseries/hotplug-memory.c
@@ -146,7 +146,7 @@ static inline int pseries_remove_memblock(unsigned long base,
}
static inline int pseries_remove_mem_node(struct device_node *np)
{
- return -EOPNOTSUPP;
+ return 0;
}
#endif /* CONFIG_MEMORY_HOTREMOVE */
--
1.8.3.2
^ permalink raw reply related
* Re: [PATCH 3/5] mmc: sdhci-pltfm: Do not use parent as the host's device
From: Pawel Moll @ 2014-08-11 9:15 UTC (permalink / raw)
To: Ulf Hansson
Cc: paul@pwsan.com, Arnd Bergmann, Stephen Warren, Greg Kroah-Hartman,
Peter De Schrijver, Anton Vorontsov, linux-mmc@vger.kernel.org,
Chris Ball, linux-kernel@vger.kernel.org,
linux-tegra@vger.kernel.org, arm@kernel.org, Catalin Marinas,
Olof Johansson, linuxppc-dev@lists.ozlabs.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <CAPDyKFoLU6pnJFmKe7CB0q-hKfwv4uCPSr0cE4aoYMvfhjMteQ@mail.gmail.com>
On Mon, 2014-08-11 at 10:07 +0100, Ulf Hansson wrote:
> On 8 August 2014 18:36, Pawel Moll <pawel.moll@arm.com> wrote:
> > On Fri, 2014-07-25 at 15:23 +0100, Pawel Moll wrote:
> >> The code selecting a device for the sdhci host has been
> >> continuously tweaked (4b711cb13843f5082e82970dd1e8031383134a65
> >> "mmc: sdhci-pltfm: Add structure for host-specific data" and
> >> a4d2177f00a5252d825236c5124bc1e9918bdb41 "mmc: sdhci-pltfm: dt
> >> device does not pass parent to sdhci_alloc_host") while there
> >> does not seem to be any reason to use platform device's parent
> >> in the first place.
> >>
> >> The comment saying "Some PCI-based MFD need the parent here"
> >> seem to refer to Timberdale FPGA driver (the only MFD driver
> >> registering SDHCI cell, drivers/mfd/timberdale.c) but again,
> >> the only situation when parent device matter is runtime PM,
> >> which is not implemented for Timberdale.
> >>
> >> Cc: Chris Ball <chris@printf.net>
> >> Cc: Anton Vorontsov <anton@enomsg.org>
> >> Cc: Ulf Hansson <ulf.hansson@linaro.org>
> >> Cc: linux-mmc@vger.kernel.org
> >> Cc: linuxppc-dev@lists.ozlabs.org
> >> Signed-off-by: Pawel Moll <pawel.moll@arm.com>
> >> ---
> >>
> >> This patch is a part of effort to remove references to platform_bus
> >> and make it static.
> >>
> >> Chris, Anton, Ulf - could you please advise if the assumptions
> >> above are correct or if I'm completely wrong? Do you know what
> >> where the real reasons to use parent originally? The PCI comment
> >> seems like a red herring to me...
> >
> > Can I take the silence as a suggestion that the change looks ok-ish for
> > you?
>
> Sorry for the delay. I suppose this make sense, but I really don't
> know for sure.
>
> I guess we need some testing in linux-next, to get some confidence.
Would you take it into -next then? Unless I'm completely wrong there
should be no impact on any in-tree driver...
Cheers!
Pawel
^ permalink raw reply
* Re: [PATCH v3] powerpc/kvm: support to handle sw breakpoint
From: Alexander Graf @ 2014-08-11 9:15 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linuxppc-dev, Madhavan Srinivasan, paulus, kvm-ppc, kvm
In-Reply-To: <1407747061.4508.75.camel@pasglop>
On 11.08.14 10:51, Benjamin Herrenschmidt wrote:
> On Mon, 2014-08-11 at 09:26 +0200, Alexander Graf wrote:
>>> diff --git a/arch/powerpc/kvm/emulate.c b/arch/powerpc/kvm/emulate.c
>>> index da86d9b..d95014e 100644
>>> --- a/arch/powerpc/kvm/emulate.c
>>> +++ b/arch/powerpc/kvm/emulate.c
>> This should be book3s_emulate.c.
> Any reason we can't make that 00dddd00 opcode as breakpoint common to
> all powerpc variants ?
I can't think of a good reason. We use a hypercall on booke (which traps
into an illegal instruction for pr) today, but I don't think it has to
be that way.
Given that the user space API allows us to change it dynamically, there
should be nothing blocking us from going with 00dddd00 always.
Alex
^ permalink raw reply
* Re: [PATCH 2/2] powerpc/powernv: Remove duplicate check in tce_iommu_bus_notifier()
From: Gavin Shan @ 2014-08-11 9:14 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, Gavin Shan
In-Reply-To: <1407726718.4508.60.camel@pasglop>
On Mon, Aug 11, 2014 at 01:11:58PM +1000, Benjamin Herrenschmidt wrote:
>On Wed, 2014-08-06 at 17:10 +1000, Gavin Shan wrote:
>> The called function iommu_del_device() checks if the device has
>> attached IOMMU group, we needn't check it again in the parent
>> function call tce_iommu_bus_notifier().
>
>The patch does more than that... it also refactors the function, which
>it should either not do or document.
>
Ben, please drop PATCH[2/2] for now.
Thanks,
Gavin
>> Signed-off-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
>> ---
>> arch/powerpc/platforms/powernv/pci.c | 13 +++++++------
>> 1 file changed, 7 insertions(+), 6 deletions(-)
>>
>> diff --git a/arch/powerpc/platforms/powernv/pci.c b/arch/powerpc/platforms/powernv/pci.c
>> index f91a4e5..b562b0d 100644
>> --- a/arch/powerpc/platforms/powernv/pci.c
>> +++ b/arch/powerpc/platforms/powernv/pci.c
>> @@ -820,17 +820,18 @@ static int tce_iommu_bus_notifier(struct notifier_block *nb,
>> unsigned long action, void *data)
>> {
>> struct device *dev = data;
>> + int ret = 0;
>>
>> switch (action) {
>> case BUS_NOTIFY_ADD_DEVICE:
>> - return iommu_add_device(dev);
>> + ret = iommu_add_device(dev);
>> + break;
>> case BUS_NOTIFY_DEL_DEVICE:
>> - if (dev->iommu_group)
>> - iommu_del_device(dev);
>> - return 0;
>> - default:
>> - return 0;
>> + iommu_del_device(dev);
>> + break;
>> }
>> +
>> + return ret;
>> }
>>
>> static struct notifier_block tce_iommu_bus_nb = {
>
>
^ permalink raw reply
* Re: [PATCH 3/5] mmc: sdhci-pltfm: Do not use parent as the host's device
From: Ulf Hansson @ 2014-08-11 9:07 UTC (permalink / raw)
To: Pawel Moll
Cc: paul@pwsan.com, Arnd Bergmann, Stephen Warren, Greg Kroah-Hartman,
Peter De Schrijver, Anton Vorontsov, linux-mmc@vger.kernel.org,
Chris Ball, linux-kernel@vger.kernel.org,
linux-tegra@vger.kernel.org, arm@kernel.org, Catalin Marinas,
Olof Johansson, linuxppc-dev@lists.ozlabs.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <1407515785.31897.28.camel@hornet>
On 8 August 2014 18:36, Pawel Moll <pawel.moll@arm.com> wrote:
> On Fri, 2014-07-25 at 15:23 +0100, Pawel Moll wrote:
>> The code selecting a device for the sdhci host has been
>> continuously tweaked (4b711cb13843f5082e82970dd1e8031383134a65
>> "mmc: sdhci-pltfm: Add structure for host-specific data" and
>> a4d2177f00a5252d825236c5124bc1e9918bdb41 "mmc: sdhci-pltfm: dt
>> device does not pass parent to sdhci_alloc_host") while there
>> does not seem to be any reason to use platform device's parent
>> in the first place.
>>
>> The comment saying "Some PCI-based MFD need the parent here"
>> seem to refer to Timberdale FPGA driver (the only MFD driver
>> registering SDHCI cell, drivers/mfd/timberdale.c) but again,
>> the only situation when parent device matter is runtime PM,
>> which is not implemented for Timberdale.
>>
>> Cc: Chris Ball <chris@printf.net>
>> Cc: Anton Vorontsov <anton@enomsg.org>
>> Cc: Ulf Hansson <ulf.hansson@linaro.org>
>> Cc: linux-mmc@vger.kernel.org
>> Cc: linuxppc-dev@lists.ozlabs.org
>> Signed-off-by: Pawel Moll <pawel.moll@arm.com>
>> ---
>>
>> This patch is a part of effort to remove references to platform_bus
>> and make it static.
>>
>> Chris, Anton, Ulf - could you please advise if the assumptions
>> above are correct or if I'm completely wrong? Do you know what
>> where the real reasons to use parent originally? The PCI comment
>> seems like a red herring to me...
>
> Can I take the silence as a suggestion that the change looks ok-ish for
> you?
Sorry for the delay. I suppose this make sense, but I really don't
know for sure.
I guess we need some testing in linux-next, to get some confidence.
Kind regards
Uffe
>
> Pawe=C5=82
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v3] powerpc/kvm: support to handle sw breakpoint
From: Benjamin Herrenschmidt @ 2014-08-11 8:51 UTC (permalink / raw)
To: Alexander Graf; +Cc: linuxppc-dev, Madhavan Srinivasan, paulus, kvm-ppc, kvm
In-Reply-To: <53E87023.6080200@suse.de>
On Mon, 2014-08-11 at 09:26 +0200, Alexander Graf wrote:
> > diff --git a/arch/powerpc/kvm/emulate.c b/arch/powerpc/kvm/emulate.c
> > index da86d9b..d95014e 100644
> > --- a/arch/powerpc/kvm/emulate.c
> > +++ b/arch/powerpc/kvm/emulate.c
>
> This should be book3s_emulate.c.
Any reason we can't make that 00dddd00 opcode as breakpoint common to
all powerpc variants ?
Cheers,
Ben.
^ permalink raw reply
* [PATCH 7/14 v2] powerpc/4xx/cpm: delete unneeded test before of_node_put
From: Julia Lawall @ 2014-08-11 7:56 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: kernel-janitors, linux-kernel, Paul Mackerras,
Uwe Kleine-König, linuxppc-dev
In-Reply-To: <1407725796.4508.54.camel@pasglop>
From: Julia Lawall <Julia.Lawall@lip6.fr>
Simplify the error path to avoid calling of_node_put when it is not needed.
The semantic patch that finds this problem is as follows:
(http://coccinelle.lip6.fr/)
// <smpl>
@@
expression e;
@@
-if (e)
of_node_put(e);
// </smpl>
Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
---
v2: new subject
arch/powerpc/sysdev/ppc4xx_cpm.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/sysdev/ppc4xx_cpm.c b/arch/powerpc/sysdev/ppc4xx_cpm.c
index 82e2cfe..ba95adf 100644
--- a/arch/powerpc/sysdev/ppc4xx_cpm.c
+++ b/arch/powerpc/sysdev/ppc4xx_cpm.c
@@ -281,7 +281,7 @@ static int __init cpm_init(void)
printk(KERN_ERR "cpm: could not parse dcr property for %s\n",
np->full_name);
ret = -EINVAL;
- goto out;
+ goto node_put;
}
cpm.dcr_host = dcr_map(np, dcr_base, dcr_len);
@@ -290,7 +290,7 @@ static int __init cpm_init(void)
printk(KERN_ERR "cpm: failed to map dcr property for %s\n",
np->full_name);
ret = -EINVAL;
- goto out;
+ goto node_put;
}
/* All 4xx SoCs with a CPM controller have one of two
@@ -330,9 +330,9 @@ static int __init cpm_init(void)
if (cpm.standby || cpm.suspend)
suspend_set_ops(&cpm_suspend_ops);
+node_put:
+ of_node_put(np);
out:
- if (np)
- of_node_put(np);
return ret;
}
^ permalink raw reply related
* Re: [PATCH v3] powerpc/kvm: support to handle sw breakpoint
From: Alexander Graf @ 2014-08-11 7:26 UTC (permalink / raw)
To: Madhavan Srinivasan, benh, paulus; +Cc: linuxppc-dev, kvm-ppc, kvm
In-Reply-To: <1406868643-26291-1-git-send-email-maddy@linux.vnet.ibm.com>
On 01.08.14 06:50, Madhavan Srinivasan wrote:
> This patch adds kernel side support for software breakpoint.
> Design is that, by using an illegal instruction, we trap to hypervisor
> via Emulation Assistance interrupt, where we check for the illegal instruction
> and accordingly we return to Host or Guest. Patch also adds support for
> software breakpoint in PR KVM.
>
> Changes v2->v3:
> Changed the debug instructions. Using the all zero opcode in the instruction word
> as illegal instruction as mentioned in Power ISA instead of ABS
> Removed reg updated in emulation assist and added a call to
> kvmppc_emulate_instruction for reg update.
>
> Changes v1->v2:
>
> Moved the debug instruction #def to kvm_book3s.h. This way PR_KVM can also share it.
> Added code to use KVM get one reg infrastructure to get debug opcode.
> Updated emulate.c to include emulation of debug instruction incase of PR_KVM.
> Made changes to commit message.
>
> Signed-off-by: Madhavan Srinivasan <maddy@linux.vnet.ibm.com>
> ---
> arch/powerpc/include/asm/kvm_book3s.h | 7 +++++++
> arch/powerpc/include/asm/ppc-opcode.h | 5 +++++
> arch/powerpc/kvm/book3s.c | 3 ++-
> arch/powerpc/kvm/book3s_hv.c | 12 ++++++++++--
> arch/powerpc/kvm/book3s_pr.c | 3 +++
> arch/powerpc/kvm/emulate.c | 9 +++++++++
> 6 files changed, 36 insertions(+), 3 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/kvm_book3s.h b/arch/powerpc/include/asm/kvm_book3s.h
> index f52f656..f17e3fd 100644
> --- a/arch/powerpc/include/asm/kvm_book3s.h
> +++ b/arch/powerpc/include/asm/kvm_book3s.h
> @@ -24,6 +24,13 @@
> #include <linux/kvm_host.h>
> #include <asm/kvm_book3s_asm.h>
>
> +/*
> + * KVMPPC_INST_BOOK3S_DEBUG is debug Instruction for supporting Software Breakpoint.
> + * Based on PowerISA v2.07, Instruction with opcode 0s will be treated as illegal
> + * instruction.
> + */
> +#define KVMPPC_INST_BOOK3S_DEBUG 0x00dddd00
> +
> struct kvmppc_bat {
> u64 raw;
> u32 bepi;
> diff --git a/arch/powerpc/include/asm/ppc-opcode.h b/arch/powerpc/include/asm/ppc-opcode.h
> index 3132bb9..56739b3 100644
> --- a/arch/powerpc/include/asm/ppc-opcode.h
> +++ b/arch/powerpc/include/asm/ppc-opcode.h
> @@ -111,6 +111,11 @@
> #define OP_31_XOP_LHBRX 790
> #define OP_31_XOP_STHBRX 918
>
> +/* KVMPPC_INST_BOOK3S_DEBUG -- Software breakpoint Instruction
> + * 0x00dddd00 -- Primary opcode is 0s
> + */
> +#define OP_ZERO 0x0
> +
> #define OP_LWZ 32
> #define OP_LD 58
> #define OP_LWZU 33
> diff --git a/arch/powerpc/kvm/book3s.c b/arch/powerpc/kvm/book3s.c
> index c254c27..b40fe5d 100644
> --- a/arch/powerpc/kvm/book3s.c
> +++ b/arch/powerpc/kvm/book3s.c
> @@ -789,7 +789,8 @@ int kvm_arch_vcpu_ioctl_translate(struct kvm_vcpu *vcpu,
> int kvm_arch_vcpu_ioctl_set_guest_debug(struct kvm_vcpu *vcpu,
> struct kvm_guest_debug *dbg)
> {
> - return -EINVAL;
> + vcpu->guest_debug = dbg->control;
> + return 0;
> }
>
> void kvmppc_decrementer_func(unsigned long data)
> diff --git a/arch/powerpc/kvm/book3s_hv.c b/arch/powerpc/kvm/book3s_hv.c
> index 7a12edb..7c16f4f 100644
> --- a/arch/powerpc/kvm/book3s_hv.c
> +++ b/arch/powerpc/kvm/book3s_hv.c
> @@ -725,8 +725,13 @@ static int kvmppc_handle_exit_hv(struct kvm_run *run, struct kvm_vcpu *vcpu,
> * we don't emulate any guest instructions at this stage.
> */
> case BOOK3S_INTERRUPT_H_EMUL_ASSIST:
> - kvmppc_core_queue_program(vcpu, SRR1_PROGILL);
> - r = RESUME_GUEST;
> + if (kvmppc_get_last_inst(vcpu) == KVMPPC_INST_BOOK3S_DEBUG) {
> + kvmppc_emulate_instruction(run, vcpu);
I changed the emulation code flow very recently, so while I advised you
to write it this way this won't work with recent git versions anymore :(.
Please just create a tiny static function that handles this particular
inst and duplicate the logic in book3s_emulate.c (for PR) as well as
here (for HV).
> + r = RESUME_HOST;
> + } else {
> + kvmppc_core_queue_program(vcpu, SRR1_PROGILL);
> + r = RESUME_GUEST;
> + }
> break;
> /*
> * This occurs if the guest (kernel or userspace), does something that
> @@ -831,6 +836,9 @@ static int kvmppc_get_one_reg_hv(struct kvm_vcpu *vcpu, u64 id,
> long int i;
>
> switch (id) {
> + case KVM_REG_PPC_DEBUG_INST:
> + *val = get_reg_val(id, KVMPPC_INST_BOOK3S_DEBUG);
> + break;
> case KVM_REG_PPC_HIOR:
> *val = get_reg_val(id, 0);
> break;
> diff --git a/arch/powerpc/kvm/book3s_pr.c b/arch/powerpc/kvm/book3s_pr.c
> index 8eef1e5..27f5234 100644
> --- a/arch/powerpc/kvm/book3s_pr.c
> +++ b/arch/powerpc/kvm/book3s_pr.c
> @@ -1229,6 +1229,9 @@ static int kvmppc_get_one_reg_pr(struct kvm_vcpu *vcpu, u64 id,
> int r = 0;
>
> switch (id) {
> + case KVM_REG_PPC_DEBUG_INST:
> + *val = get_reg_val(id, KVMPPC_INST_BOOK3S_DEBUG);
> + break;
> case KVM_REG_PPC_HIOR:
> *val = get_reg_val(id, to_book3s(vcpu)->hior);
> break;
> diff --git a/arch/powerpc/kvm/emulate.c b/arch/powerpc/kvm/emulate.c
> index da86d9b..d95014e 100644
> --- a/arch/powerpc/kvm/emulate.c
> +++ b/arch/powerpc/kvm/emulate.c
This should be book3s_emulate.c.
Alex
^ permalink raw reply
* [PATCH 2/2][v3] powerpc/fsl-booke: Add initial T1042RDB_PI board support
From: Priyanka Jain @ 2014-08-11 7:19 UTC (permalink / raw)
To: linuxppc-dev, devicetree, scottwood
Cc: Priyanka Jain, Poonam Aggrwal, Prabhakar Kushwaha
T1042RDB_PI is Freescale Reference Design Board supporting the T1042
QorIQ Power Architecture™ processor. T1042 is a reduced personality
of T1040 SoC without Integrated 8-port Gigabit. The board is designed
with low power features targeted for Printing Image Market.
T1042RDB_PI is similar to T1040RDB board with few differences like
it has video interface, supports T1042 personality only
T1042RDB_PI board Overview
-----------------------
- SERDES Connections, 8 lanes supporting:
- PCI
- SATA 2.0
- DDR Controller
- Supports rates of up to 1600 MHz data-rate
- Supports one DDR3LP UDIMM
-IFC/Local Bus
- NAND flash: 1GB 8-bit NAND flash
- NOR: 128MB 16-bit NOR Flash
- Ethernet
- Two on-board RGMII 10/100/1G ethernet ports.
- PHY #0 remains powered up during deep-sleep
- CPLD
- Clocks
- System and DDR clock (SYSCLK, “DDRCLK”)
- SERDES clocks
- Power Supplies
- USB
- Supports two USB 2.0 ports with integrated PHYs
- Two type A ports with 5V@1.5A per port.
- SDHC
- SDHC/SDXC connector
- SPI
- On-board 64MB SPI flash
- I2C
- Device connected: EEPROM, thermal monitor, VID controller, RTC
- Other IO
- Two Serial ports
- ProfiBus port
Add support for T1042RDB_PI board:
-add device tree
-Add entry in corenet_generic.c, as it is similar to other corenet platforms
Signed-off-by: Poonam Aggrwal <poonam.aggrwal@freescale.com>
Signed-off-by: Prabhakar Kushwaha <prabhakar@freescale.com>
Signed-off-by: Priyanka Jain <Priyanka.Jain@freescale.com>
---
changes for v3: Incorporated Scott comments on moving cpld compatible
field to board specific file as cpld binaries are different
changes for v2: Incorporated Scott comments on using common name
for compatible string for cpld as register set is same
arch/powerpc/boot/dts/t1042rdb_pi.dts | 57 +++++++++++++++++++++++++
arch/powerpc/platforms/85xx/corenet_generic.c | 1 +
2 files changed, 58 insertions(+), 0 deletions(-)
create mode 100644 arch/powerpc/boot/dts/t1042rdb_pi.dts
diff --git a/arch/powerpc/boot/dts/t1042rdb_pi.dts b/arch/powerpc/boot/dts/t1042rdb_pi.dts
new file mode 100644
index 0000000..b9d0877
--- /dev/null
+++ b/arch/powerpc/boot/dts/t1042rdb_pi.dts
@@ -0,0 +1,57 @@
+/*
+ * T1042RDB_PI Device Tree Source
+ *
+ * Copyright 2014 Freescale Semiconductor Inc.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions are met:
+ * * Redistributions of source code must retain the above copyright
+ * notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above copyright
+ * notice, this list of conditions and the following disclaimer in the
+ * documentation and/or other materials provided with the distribution.
+ * * Neither the name of Freescale Semiconductor nor the
+ * names of its contributors may be used to endorse or promote products
+ * derived from this software without specific prior written permission.
+ *
+ *
+ * ALTERNATIVELY, this software may be distributed under the terms of the
+ * GNU General Public License ("GPL") as published by the Free Software
+ * Foundation, either version 2 of that License or (at your option) any
+ * later version.
+ *
+ * THIS SOFTWARE IS PROVIDED BY Freescale Semiconductor "AS IS" AND ANY
+ * EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
+ * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
+ * DISCLAIMED. IN NO EVENT SHALL Freescale Semiconductor BE LIABLE FOR ANY
+ * DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
+ * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
+ * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
+ * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
+ * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+/include/ "fsl/t104xsi-pre.dtsi"
+/include/ "t104xrdb.dtsi"
+
+/ {
+ model = "fsl,T1042RDB_PI";
+ compatible = "fsl,T1042RDB_PI";
+ ifc: localbus@ffe124000 {
+ cpld@3,0 {
+ compatible = "fsl,t1040rdb-cpld";
+ };
+ };
+ soc: soc@ffe000000 {
+ i2c@118000 {
+ rtc@68 {
+ compatible = "dallas,ds1337";
+ reg = <0x68>;
+ interrupts = <0x2 0x1 0 0>;
+ };
+ };
+ };
+};
+
+/include/ "fsl/t1042si-post.dtsi"
diff --git a/arch/powerpc/platforms/85xx/corenet_generic.c b/arch/powerpc/platforms/85xx/corenet_generic.c
index c268f89..100e80d 100644
--- a/arch/powerpc/platforms/85xx/corenet_generic.c
+++ b/arch/powerpc/platforms/85xx/corenet_generic.c
@@ -130,6 +130,7 @@ static const char * const boards[] __initconst = {
"fsl,T1042QDS",
"fsl,T1040RDB",
"fsl,T1042RDB",
+ "fsl,T1042RDB_PI",
"keymile,kmcoge4",
NULL
};
--
1.7.4.1
^ permalink raw reply related
* [PATCH 1/2][v3] powerpc/fsl-booke: Add initial T1040/T1042 RDB board support
From: Priyanka Jain @ 2014-08-11 7:18 UTC (permalink / raw)
To: linuxppc-dev, devicetree, scottwood
Cc: Priyanka Jain, Poonam Aggrwal, Prabhakar Kushwaha
T1040/T1042RDB is Freescale Reference Design Board.
The board can support both T1040/T1042 QorIQ Power Architecture™ processor.
T1040/T1042RDB board Overview
-----------------------
- SERDES Connections, 8 lanes supporting:
- PCI
- SGMII
- QSGMII
- SATA 2.0
- DDR Controller
- Supports rates of up to 1600 MHz data-rate
- Supports one DDR3LP UDIMM
-IFC/Local Bus
- NAND flash: 1GB 8-bit NAND flash
- NOR: 128MB 16-bit NOR Flash
- Ethernet
- Two on-board RGMII 10/100/1G ethernet ports.
- PHY #0 remains powered up during deep-sleep
- CPLD
- Clocks
- System and DDR clock (SYSCLK, “DDRCLK”)
- SERDES clocks
- Power Supplies
- USB
- Supports two USB 2.0 ports with integrated PHYs
- Two type A ports with 5V@1.5A per port.
- SDHC
- SDHC/SDXC connector
- SPI
- On-board 64MB SPI flash
- I2C
- Devices connected: EEPROM, thermal monitor, VID controller
- Other IO
- Two Serial ports
- ProfiBus port
Add support for T1040/T1042 RDB board:
-add device tree
-add entry in Kconfig to build
-Add entry in corenet_generic.c, as it is similar to other corenet platforms
Signed-off-by: Priyanka Jain <Priyanka.Jain@freescale.com>
Signed-off-by: Poonam Aggrwal <poonam.aggrwal@freescale.com>
Signed-off-by: Prabhakar Kushwaha <prabhakar@freescale.com>
---
changes for v3: Incorporated Scott comments on moving cpld compatible
field to board specific file as cpld binaries are different
changes for v2: Incorporated Scott comments on using common name
for compatible string for cpld as register set is same
arch/powerpc/boot/dts/t1040rdb.dts | 48 ++++++++
arch/powerpc/boot/dts/t1042rdb.dts | 48 ++++++++
arch/powerpc/boot/dts/t104xrdb.dtsi | 156 +++++++++++++++++++++++++
arch/powerpc/platforms/85xx/Kconfig | 2 +-
arch/powerpc/platforms/85xx/corenet_generic.c | 2 +
5 files changed, 255 insertions(+), 1 deletions(-)
create mode 100644 arch/powerpc/boot/dts/t1040rdb.dts
create mode 100644 arch/powerpc/boot/dts/t1042rdb.dts
create mode 100644 arch/powerpc/boot/dts/t104xrdb.dtsi
diff --git a/arch/powerpc/boot/dts/t1040rdb.dts b/arch/powerpc/boot/dts/t1040rdb.dts
new file mode 100644
index 0000000..79a0bed
--- /dev/null
+++ b/arch/powerpc/boot/dts/t1040rdb.dts
@@ -0,0 +1,48 @@
+/*
+ * T1040RDB Device Tree Source
+ *
+ * Copyright 2014 Freescale Semiconductor Inc.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions are met:
+ * * Redistributions of source code must retain the above copyright
+ * notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above copyright
+ * notice, this list of conditions and the following disclaimer in the
+ * documentation and/or other materials provided with the distribution.
+ * * Neither the name of Freescale Semiconductor nor the
+ * names of its contributors may be used to endorse or promote products
+ * derived from this software without specific prior written permission.
+ *
+ *
+ * ALTERNATIVELY, this software may be distributed under the terms of the
+ * GNU General Public License ("GPL") as published by the Free Software
+ * Foundation, either version 2 of that License or (at your option) any
+ * later version.
+ *
+ * THIS SOFTWARE IS PROVIDED BY Freescale Semiconductor "AS IS" AND ANY
+ * EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
+ * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
+ * DISCLAIMED. IN NO EVENT SHALL Freescale Semiconductor BE LIABLE FOR ANY
+ * DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
+ * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
+ * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
+ * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
+ * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+/include/ "fsl/t104xsi-pre.dtsi"
+/include/ "t104xrdb.dtsi"
+
+/ {
+ model = "fsl,T1040RDB";
+ compatible = "fsl,T1040RDB";
+ ifc: localbus@ffe124000 {
+ cpld@3,0 {
+ compatible = "fsl,t1040rdb-cpld";
+ };
+ };
+};
+
+/include/ "fsl/t1040si-post.dtsi"
diff --git a/arch/powerpc/boot/dts/t1042rdb.dts b/arch/powerpc/boot/dts/t1042rdb.dts
new file mode 100644
index 0000000..228a635
--- /dev/null
+++ b/arch/powerpc/boot/dts/t1042rdb.dts
@@ -0,0 +1,48 @@
+/*
+ * T1042RDB Device Tree Source
+ *
+ * Copyright 2014 Freescale Semiconductor Inc.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions are met:
+ * * Redistributions of source code must retain the above copyright
+ * notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above copyright
+ * notice, this list of conditions and the following disclaimer in the
+ * documentation and/or other materials provided with the distribution.
+ * * Neither the name of Freescale Semiconductor nor the
+ * names of its contributors may be used to endorse or promote products
+ * derived from this software without specific prior written permission.
+ *
+ *
+ * ALTERNATIVELY, this software may be distributed under the terms of the
+ * GNU General Public License ("GPL") as published by the Free Software
+ * Foundation, either version 2 of that License or (at your option) any
+ * later version.
+ *
+ * THIS SOFTWARE IS PROVIDED BY Freescale Semiconductor "AS IS" AND ANY
+ * EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
+ * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
+ * DISCLAIMED. IN NO EVENT SHALL Freescale Semiconductor BE LIABLE FOR ANY
+ * DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
+ * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
+ * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
+ * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
+ * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+/include/ "fsl/t104xsi-pre.dtsi"
+/include/ "t104xrdb.dtsi"
+
+/ {
+ model = "fsl,T1042RDB";
+ compatible = "fsl,T1042RDB";
+ ifc: localbus@ffe124000 {
+ cpld@3,0 {
+ compatible = "fsl,t1040rdb-cpld";
+ };
+ };
+};
+
+/include/ "fsl/t1042si-post.dtsi"
diff --git a/arch/powerpc/boot/dts/t104xrdb.dtsi b/arch/powerpc/boot/dts/t104xrdb.dtsi
new file mode 100644
index 0000000..1cf0f3c
--- /dev/null
+++ b/arch/powerpc/boot/dts/t104xrdb.dtsi
@@ -0,0 +1,156 @@
+/*
+ * T1040RDB/T1042RDB Device Tree Source
+ *
+ * Copyright 2014 Freescale Semiconductor Inc.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions are met:
+ * * Redistributions of source code must retain the above copyright
+ * notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above copyright
+ * notice, this list of conditions and the following disclaimer in the
+ * documentation and/or other materials provided with the distribution.
+ * * Neither the name of Freescale Semiconductor nor the
+ * names of its contributors may be used to endorse or promote products
+ * derived from this software without specific prior written permission.
+ *
+ *
+ * ALTERNATIVELY, this software may be distributed under the terms of the
+ * GNU General Public License ("GPL") as published by the Free Software
+ * Foundation, either version 2 of that License or (at your option) any
+ * later version.
+ *
+ * THIS SOFTWARE IS PROVIDED BY Freescale Semiconductor "AS IS" AND ANY
+ * EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
+ * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
+ * DISCLAIMED. IN NO EVENT SHALL Freescale Semiconductor BE LIABLE FOR ANY
+ * DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
+ * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
+ * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
+ * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
+ * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+/ {
+
+ ifc: localbus@ffe124000 {
+ reg = <0xf 0xfe124000 0 0x2000>;
+ ranges = <0 0 0xf 0xe8000000 0x08000000
+ 2 0 0xf 0xff800000 0x00010000
+ 3 0 0xf 0xffdf0000 0x00008000>;
+
+ nor@0,0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "cfi-flash";
+ reg = <0x0 0x0 0x8000000>;
+ bank-width = <2>;
+ device-width = <1>;
+ };
+
+ nand@2,0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "fsl,ifc-nand";
+ reg = <0x2 0x0 0x10000>;
+ };
+
+ cpld@3,0 {
+ reg = <3 0 0x300>;
+ };
+ };
+
+ memory {
+ device_type = "memory";
+ };
+
+ dcsr: dcsr@f00000000 {
+ ranges = <0x00000000 0xf 0x00000000 0x01072000>;
+ };
+
+ soc: soc@ffe000000 {
+ ranges = <0x00000000 0xf 0xfe000000 0x1000000>;
+ reg = <0xf 0xfe000000 0 0x00001000>;
+
+ spi@110000 {
+ flash@0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "micron,n25q512a";
+ reg = <0>;
+ spi-max-frequency = <10000000>; /* input clock */
+ };
+ };
+
+ i2c@118100 {
+ pca9546@77 {
+ compatible = "nxp,pca9546";
+ reg = <0x77>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+ };
+
+ };
+
+ pci0: pcie@ffe240000 {
+ reg = <0xf 0xfe240000 0 0x10000>;
+ ranges = <0x02000000 0 0xe0000000 0xc 0x00000000 0x0 0x10000000
+ 0x01000000 0 0x00000000 0xf 0xf8000000 0x0 0x00010000>;
+ pcie@0 {
+ ranges = <0x02000000 0 0xe0000000
+ 0x02000000 0 0xe0000000
+ 0 0x10000000
+
+ 0x01000000 0 0x00000000
+ 0x01000000 0 0x00000000
+ 0 0x00010000>;
+ };
+ };
+
+ pci1: pcie@ffe250000 {
+ reg = <0xf 0xfe250000 0 0x10000>;
+ ranges = <0x02000000 0x0 0xe0000000 0xc 0x10000000 0x0 0x10000000
+ 0x01000000 0x0 0x00000000 0xf 0xf8010000 0x0 0x00010000>;
+ pcie@0 {
+ ranges = <0x02000000 0 0xe0000000
+ 0x02000000 0 0xe0000000
+ 0 0x10000000
+
+ 0x01000000 0 0x00000000
+ 0x01000000 0 0x00000000
+ 0 0x00010000>;
+ };
+ };
+
+ pci2: pcie@ffe260000 {
+ reg = <0xf 0xfe260000 0 0x10000>;
+ ranges = <0x02000000 0 0xe0000000 0xc 0x20000000 0 0x10000000
+ 0x01000000 0 0x00000000 0xf 0xf8020000 0 0x00010000>;
+ pcie@0 {
+ ranges = <0x02000000 0 0xe0000000
+ 0x02000000 0 0xe0000000
+ 0 0x10000000
+
+ 0x01000000 0 0x00000000
+ 0x01000000 0 0x00000000
+ 0 0x00010000>;
+ };
+ };
+
+ pci3: pcie@ffe270000 {
+ reg = <0xf 0xfe270000 0 0x10000>;
+ ranges = <0x02000000 0 0xe0000000 0xc 0x30000000 0 0x10000000
+ 0x01000000 0 0x00000000 0xf 0xf8030000 0 0x00010000>;
+ pcie@0 {
+ ranges = <0x02000000 0 0xe0000000
+ 0x02000000 0 0xe0000000
+ 0 0x10000000
+
+ 0x01000000 0 0x00000000
+ 0x01000000 0 0x00000000
+ 0 0x00010000>;
+ };
+ };
+};
diff --git a/arch/powerpc/platforms/85xx/Kconfig b/arch/powerpc/platforms/85xx/Kconfig
index 5063696..157a1a4 100644
--- a/arch/powerpc/platforms/85xx/Kconfig
+++ b/arch/powerpc/platforms/85xx/Kconfig
@@ -276,7 +276,7 @@ config CORENET_GENERIC
For 64bit kernel, the following boards are supported:
T208x QDS, T4240 QDS/RDB and B4 QDS
The following boards are supported for both 32bit and 64bit kernel:
- P5020 DS, P5040 DS and T104xQDS
+ P5020 DS, P5040 DS and T104xQDS/RDB
endif # FSL_SOC_BOOKE
diff --git a/arch/powerpc/platforms/85xx/corenet_generic.c b/arch/powerpc/platforms/85xx/corenet_generic.c
index 4f22ad1..c268f89 100644
--- a/arch/powerpc/platforms/85xx/corenet_generic.c
+++ b/arch/powerpc/platforms/85xx/corenet_generic.c
@@ -128,6 +128,8 @@ static const char * const boards[] __initconst = {
"fsl,B4220QDS",
"fsl,T1040QDS",
"fsl,T1042QDS",
+ "fsl,T1040RDB",
+ "fsl,T1042RDB",
"keymile,kmcoge4",
NULL
};
--
1.7.4.1
^ permalink raw reply related
* Re: [PATCH] net: ugg_geth: Fix build error in -next
From: Uwe Kleine-König @ 2014-08-11 5:35 UTC (permalink / raw)
To: Guenter Roeck; +Cc: netdev, linuxppc-dev, David S. Miller, linux-kernel
In-Reply-To: <53E7BD21.6010301@roeck-us.net>
Hello Guenter,
On Sun, Aug 10, 2014 at 11:42:41AM -0700, Guenter Roeck wrote:
> On 08/10/2014 11:36 AM, Uwe Kleine-König wrote:
> >On Sun, Aug 10, 2014 at 09:19:14AM -0700, Guenter Roeck wrote:
> >>powerpc:mpc83xx_defconfig and other builds fail with
> >>
> >>drivers/net/ethernet/freescale/ucc_geth.c: In function 'ucc_geth_remove':
> >>drivers/net/ethernet/freescale/ucc_geth.c:3927:19: error:
> >> 'struct ucc_geth_private' has no member named 'info'
> >> of_node_put(ugeth->info->tbi_node);
> >> ^
> >>drivers/net/ethernet/freescale/ucc_geth.c:3928:19: error:
> >> 'struct ucc_geth_private' has no member named 'info'
> >> of_node_put(ugeth->info->phy_node);
> >> ^
> >>
> >>Introduced by commit "net: ucc_geth: drop acquired references in probe error
> >>path and remove".
> >>
> >> From the context, it appears that the variable is named ug_info.
> >>
> >>Cc: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
> >>Signed-off-by: Guenter Roeck <linux@roeck-us.net>
> >>---
> >>Only seen in -next.
> >My patch was only sent just now, but it has the subject right:
> >
> Excellent.
>
> > http://mid.gmane.org/1407695525-32227-1-git-send-email-u.kleine-koenig@pengutronix.de
> >
> The link doesn't seem to work for some reason.
It didn't work for me when I sent the mail either. I thought gmane will
have indexed the mail in a few minutes though. Gmane is broken somehow,
when I follow the Subject link of
http://article.gmane.org/gmane.linux.network/326013 I also get a No such
article page?! :-(
http://patchwork.ozlabs.org/patch/378854/ is a link that works for me.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ 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