* [PATCH 4/7] tty: powerpc: remove hvc_iseries
From: Stephen Rothwell @ 2012-03-08 4:37 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Greg Kroah-Hartman, ppc-dev, LKML
In-Reply-To: <20120308152853.b5010336abbb8f90e8a2500c@canb.auug.org.au>
[-- Attachment #1: Type: text/plain, Size: 1728 bytes --]
The PowerPC legacy iSeries platform is being removed, so this code is no
longer needed.
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
drivers/tty/hvc/Kconfig | 10 -
drivers/tty/hvc/Makefile | 1 -
drivers/tty/hvc/hvc_iseries.c | 599 -----------------------------------------
3 files changed, 0 insertions(+), 610 deletions(-)
delete mode 100644 drivers/tty/hvc/hvc_iseries.c
diff --git a/drivers/tty/hvc/Kconfig b/drivers/tty/hvc/Kconfig
index 4222035..8ea7f07 100644
--- a/drivers/tty/hvc/Kconfig
+++ b/drivers/tty/hvc/Kconfig
@@ -24,16 +24,6 @@ config HVC_OLD_HVSI
depends on HVC_CONSOLE
default n
-config HVC_ISERIES
- bool "iSeries Hypervisor Virtual Console support"
- depends on PPC_ISERIES
- default y
- select HVC_DRIVER
- select HVC_IRQ
- select VIOPATH
- help
- iSeries machines support a hypervisor virtual console.
-
config HVC_OPAL
bool "OPAL Console support"
depends on PPC_POWERNV
diff --git a/drivers/tty/hvc/Makefile b/drivers/tty/hvc/Makefile
index 89abf40b..4ca3723 100644
--- a/drivers/tty/hvc/Makefile
+++ b/drivers/tty/hvc/Makefile
@@ -1,7 +1,6 @@
obj-$(CONFIG_HVC_CONSOLE) += hvc_vio.o hvsi_lib.o
obj-$(CONFIG_HVC_OPAL) += hvc_opal.o hvsi_lib.o
obj-$(CONFIG_HVC_OLD_HVSI) += hvsi.o
-obj-$(CONFIG_HVC_ISERIES) += hvc_iseries.o
obj-$(CONFIG_HVC_RTAS) += hvc_rtas.o
obj-$(CONFIG_HVC_TILE) += hvc_tile.o
obj-$(CONFIG_HVC_DCC) += hvc_dcc.o
diff --git a/drivers/tty/hvc/hvc_iseries.c b/drivers/tty/hvc/hvc_iseries.c
deleted file mode 100644
index 3f4a897..0000000
--
1.7.9.1
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply related
* [PATCH 5/7] tty: powerpc: remove SERIAL_ICOM dependency on PPC_ISERIES
From: Stephen Rothwell @ 2012-03-08 4:39 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Greg Kroah-Hartman, ppc-dev, LKML, linux-serial, Alan Cox
In-Reply-To: <20120308152853.b5010336abbb8f90e8a2500c@canb.auug.org.au>
[-- Attachment #1: Type: text/plain, Size: 880 bytes --]
The PowerPC legacy iSeries platform is being removed so this is no
longer selectable.
Cc: Alan Cox <alan@linux.intel.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: linux-serial@vger.kernel.org
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
drivers/tty/serial/Kconfig | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig
index 2de9924..59e7983 100644
--- a/drivers/tty/serial/Kconfig
+++ b/drivers/tty/serial/Kconfig
@@ -853,7 +853,7 @@ config SERIAL_MPC52xx_CONSOLE_BAUD
config SERIAL_ICOM
tristate "IBM Multiport Serial Adapter"
- depends on PCI && (PPC_ISERIES || PPC_PSERIES)
+ depends on PCI && PPC_PSERIES
select SERIAL_CORE
select FW_LOADER
help
--
1.7.9.1
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply related
* [PATCH 6/7] driver-core: remove legacy iSeries hack
From: Stephen Rothwell @ 2012-03-08 4:41 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Greg Kroah-Hartman, ppc-dev, LKML
In-Reply-To: <20120308152853.b5010336abbb8f90e8a2500c@canb.auug.org.au>
[-- Attachment #1: Type: text/plain, Size: 2259 bytes --]
The PowerPC legacy iSeries plateform is being removed along with the
"one looney iseries driver", so this code can now be removed as well.
cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
drivers/base/driver.c | 30 ------------------------------
include/linux/device.h | 4 ----
2 files changed, 0 insertions(+), 34 deletions(-)
diff --git a/drivers/base/driver.c b/drivers/base/driver.c
index b631f7c..db4f54c 100644
--- a/drivers/base/driver.c
+++ b/drivers/base/driver.c
@@ -124,36 +124,6 @@ void driver_remove_file(struct device_driver *drv,
EXPORT_SYMBOL_GPL(driver_remove_file);
/**
- * driver_add_kobj - add a kobject below the specified driver
- * @drv: requesting device driver
- * @kobj: kobject to add below this driver
- * @fmt: format string that names the kobject
- *
- * You really don't want to do this, this is only here due to one looney
- * iseries driver, go poke those developers if you are annoyed about
- * this...
- */
-int driver_add_kobj(struct device_driver *drv, struct kobject *kobj,
- const char *fmt, ...)
-{
- va_list args;
- char *name;
- int ret;
-
- va_start(args, fmt);
- name = kvasprintf(GFP_KERNEL, fmt, args);
- va_end(args);
-
- if (!name)
- return -ENOMEM;
-
- ret = kobject_add(kobj, &drv->p->kobj, "%s", name);
- kfree(name);
- return ret;
-}
-EXPORT_SYMBOL_GPL(driver_add_kobj);
-
-/**
* get_driver - increment driver reference count.
* @drv: driver.
*/
diff --git a/include/linux/device.h b/include/linux/device.h
index b63fb39..46baa1f 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -264,10 +264,6 @@ extern int __must_check driver_create_file(struct device_driver *driver,
extern void driver_remove_file(struct device_driver *driver,
const struct driver_attribute *attr);
-extern int __must_check driver_add_kobj(struct device_driver *drv,
- struct kobject *kobj,
- const char *fmt, ...);
-
extern int __must_check driver_for_each_device(struct device_driver *drv,
struct device *start,
void *data,
--
1.7.9.1
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply related
* [PATCH 7/7] powerpc: clean up vio.c
From: Stephen Rothwell @ 2012-03-08 4:43 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: ppc-dev, LKML
In-Reply-To: <20120308152853.b5010336abbb8f90e8a2500c@canb.auug.org.au>
[-- Attachment #1: Type: text/plain, Size: 3704 bytes --]
This cleans up vio.c after the removal of the legacy iSeries platform.
It also removes some no longer referenced include files.
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
arch/powerpc/include/asm/iseries/hv_call_event.h | 201 ----------------
arch/powerpc/include/asm/iseries/hv_lp_event.h | 162 -------------
arch/powerpc/include/asm/iseries/iommu.h | 37 ---
arch/powerpc/include/asm/iseries/vio.h | 265 ----------------------
arch/powerpc/kernel/vio.c | 18 +--
5 files changed, 1 insertions(+), 682 deletions(-)
delete mode 100644 arch/powerpc/include/asm/iseries/hv_call_event.h
delete mode 100644 arch/powerpc/include/asm/iseries/hv_lp_event.h
delete mode 100644 arch/powerpc/include/asm/iseries/iommu.h
delete mode 100644 arch/powerpc/include/asm/iseries/vio.h
diff --git a/arch/powerpc/include/asm/iseries/hv_call_event.h b/arch/powerpc/include/asm/iseries/hv_call_event.h
deleted file mode 100644
index cc029d3..0000000
diff --git a/arch/powerpc/include/asm/iseries/hv_lp_event.h b/arch/powerpc/include/asm/iseries/hv_lp_event.h
deleted file mode 100644
index 8f5da7d..0000000
diff --git a/arch/powerpc/include/asm/iseries/iommu.h b/arch/powerpc/include/asm/iseries/iommu.h
deleted file mode 100644
index 1b9692c..0000000
diff --git a/arch/powerpc/include/asm/iseries/vio.h b/arch/powerpc/include/asm/iseries/vio.h
deleted file mode 100644
index f9ac0d0..0000000
diff --git a/arch/powerpc/kernel/vio.c b/arch/powerpc/kernel/vio.c
index 8b08629..bca3fc4 100644
--- a/arch/powerpc/kernel/vio.c
+++ b/arch/powerpc/kernel/vio.c
@@ -34,11 +34,6 @@
#include <asm/abs_addr.h>
#include <asm/page.h>
#include <asm/hvcall.h>
-#include <asm/iseries/vio.h>
-#include <asm/iseries/hv_types.h>
-#include <asm/iseries/hv_lp_config.h>
-#include <asm/iseries/hv_call_xm.h>
-#include <asm/iseries/iommu.h>
static struct bus_type vio_bus_type;
@@ -1042,7 +1037,6 @@ static void vio_cmo_sysfs_init(void)
vio_bus_type.bus_attrs = vio_cmo_bus_attrs;
}
#else /* CONFIG_PPC_SMLPAR */
-/* Dummy functions for iSeries platform */
int vio_cmo_entitlement_update(size_t new_entitlement) { return 0; }
void vio_cmo_set_dev_desired(struct vio_dev *viodev, size_t desired) {}
static int vio_cmo_bus_probe(struct vio_dev *viodev) { return 0; }
@@ -1060,9 +1054,6 @@ static struct iommu_table *vio_build_iommu_table(struct vio_dev *dev)
struct iommu_table *tbl;
unsigned long offset, size;
- if (firmware_has_feature(FW_FEATURE_ISERIES))
- return vio_build_iommu_table_iseries(dev);
-
dma_window = of_get_property(dev->dev.of_node,
"ibm,my-dma-window", NULL);
if (!dma_window)
@@ -1195,8 +1186,7 @@ static void __devinit vio_dev_release(struct device *dev)
{
struct iommu_table *tbl = get_iommu_table_base(dev);
- /* iSeries uses a common table for all vio devices */
- if (!firmware_has_feature(FW_FEATURE_ISERIES) && tbl)
+ if (tbl)
iommu_free_table(tbl, dev->of_node ?
dev->of_node->full_name : dev_name(dev));
of_node_put(dev->of_node);
@@ -1244,12 +1234,6 @@ struct vio_dev *vio_register_device_node(struct device_node *of_node)
viodev->name = of_node->name;
viodev->type = of_node->type;
viodev->unit_address = *unit_address;
- if (firmware_has_feature(FW_FEATURE_ISERIES)) {
- unit_address = of_get_property(of_node,
- "linux,unit_address", NULL);
- if (unit_address != NULL)
- viodev->unit_address = *unit_address;
- }
viodev->dev.of_node = of_node_get(of_node);
if (firmware_has_feature(FW_FEATURE_CMO))
--
1.7.9.1
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply related
* Re: linux-next: manual merge of the powerpc tree with the arm tree
From: Benjamin Herrenschmidt @ 2012-03-08 5:52 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Michael Neuling, linux-kernel, Rob Herring, linux-next,
Paul Mackerras, linuxppc-dev, Russell King
In-Reply-To: <20120308145131.fad50bbc79c36f0b0b12d101@canb.auug.org.au>
On Thu, 2012-03-08 at 14:51 +1100, Stephen Rothwell wrote:
> Hi Mikey,
>
> On Thu, 08 Mar 2012 13:33:56 +1100 Michael Neuling <mikey@neuling.org> wrote:
> >
> > Surely we only need SPARSE_IRQ now and not MAY_HAVE_SPARSE_IRQ.
> >
> > In fact, keeping MAY_HAVE_SPARSE_IRQ seems to make SPARSE_IRQ user
> > selectable, which we don't want anymore since ad5b7f1350c2.
>
> Yes, indeed. I will fix up the merge resolution for tomorrow.
This is my fault. Grant's patch had a collision and I manually fixed it
up. While doing that, I put back MAY_HAVE_SPARSE_IRQ which the patch
originally took out.
Cheers,
Ben.
^ permalink raw reply
* RE: [PATCH v2] powerpc/srio: Fix the compile errors when building with 64bit
From: Liu Gang @ 2012-03-08 6:31 UTC (permalink / raw)
To: David Laight
Cc: r58472, paul.gortmaker, r61911, linux-kernel, Alexandre.Bounine,
akpm, linuxppc-dev, Shaohui Xie
In-Reply-To: <AE90C24D6B3A694183C094C60CF0A2F6026B6E91@saturn3.aculab.com>
Hi, David,
On Wed, 2012-03-07 at 13:18 +0000, David Laight wrote:
> > pr_debug("RIO: fsl_add_outb_message(): destid %4.4x mbox %d
> buffer " \
> > - "%8.8x len %8.8x\n", rdev->destid, mbox, (int)buffer,
> len);
> > + "%8.8lx len %8.8zx\n", rdev->destid, mbox,
> > + (unsigned long)buffer, len);
>
> Should 'buffer' be printed with %p ??
Yes, printing with "%p" can get rid of the cast, although they have the
same print results.
Thanks a lot.
Liu Gang
^ permalink raw reply
* Re: [PATCH 2/7] net: powerpc: remove the legacy iSeries ethernet driver
From: David Miller @ 2012-03-08 6:53 UTC (permalink / raw)
To: sfr; +Cc: linuxppc-dev, linux-kernel, netdev
In-Reply-To: <20120308153353.ee2ff35c8ebe7ee66fa374e9@canb.auug.org.au>
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Thu, 8 Mar 2012 15:33:53 +1100
> This driver is specific to the PowerPC legcay iSeries platform which is
> being removed.
>
> Cc: David Miller <davem@davemloft.net>
> Cc: <netdev@vger.kernel.org>
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
Acked-by: David S. Miller <davem@davemloft.net>
^ permalink raw reply
* Re: [PATCH 0/7] powerpc: remove the legacy iSeries platform specific drivers
From: David Miller @ 2012-03-08 6:53 UTC (permalink / raw)
To: sfr
Cc: axboe, linux-scsi, gregkh, linux-kernel, JBottomley, linux-serial,
netdev, brking, linuxppc-dev, alan
In-Reply-To: <20120308152853.b5010336abbb8f90e8a2500c@canb.auug.org.au>
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Thu, 8 Mar 2012 15:28:53 +1100
> It would probably be easiest if all these patches were merged via the
> powerpc tree to eliminate any dependencies between them. Their impact on
> generic code is very small.
No objections.
^ permalink raw reply
* RE: [PATCH 1/9] pci_ids: Add device ID for IBM PCI-X bridge
From: Zang Roy-R61911 @ 2012-03-08 7:55 UTC (permalink / raw)
To: Kumar Gala, Zhao Chenhui-B35336
Cc: linux-pci@vger.kernel.org, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <08B5FFBF-FFF7-45FF-A98D-181CC0E6CEBC@kernel.crashing.org>
> -----Original Message-----
> From: linuxppc-dev-bounces+tie-fei.zang=3Dfreescale.com@lists.ozlabs.org
> [mailto:linuxppc-dev-bounces+tie-fei.zang=3Dfreescale.com@lists.ozlabs.or=
g]
> On Behalf Of Kumar Gala
> Sent: Tuesday, March 06, 2012 20:14 PM
> To: Zhao Chenhui-B35336
> Cc: linux-pci@vger.kernel.org; linuxppc-dev@lists.ozlabs.org
> Subject: Re: [PATCH 1/9] pci_ids: Add device ID for IBM PCI-X bridge
>=20
>=20
> On Mar 6, 2012, at 3:05 AM, Zhao Chenhui wrote:
>=20
> > Signed-off-by: Zhao Chenhui <chenhui.zhao@freescale.com>
> > ---
> > include/linux/pci_ids.h | 1 +
> > 1 files changed, 1 insertions(+), 0 deletions(-)
>=20
> Just merge this with the 2nd patch that actually uses the ID.
Why does this necessary?
I'd prefer using a separate patch for the PCI ID.
Roy
^ permalink raw reply
* Re: [PATCH 0/7] powerpc: remove the legacy iSeries platform specific drivers
From: Jens Axboe @ 2012-03-08 10:37 UTC (permalink / raw)
To: Stephen Rothwell
Cc: linux-scsi, Greg Kroah-Hartman, LKML, James E.J. Bottomley,
linux-serial, netdev, Brian King, ppc-dev, David Miller, Alan Cox
In-Reply-To: <20120308152853.b5010336abbb8f90e8a2500c@canb.auug.org.au>
On 03/08/2012 05:28 AM, Stephen Rothwell wrote:
> It would probably be easiest if all these patches were merged via the
> powerpc tree to eliminate any dependencies between them. Their impact on
> generic code is very small.
Go ahead, no point in doing otherwise.
--
Jens Axboe
^ permalink raw reply
* Re: [PATCH 5/7] tty: powerpc: remove SERIAL_ICOM dependency on PPC_ISERIES
From: Alan Cox @ 2012-03-08 11:18 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: ppc-dev, LKML, linux-serial, Greg Kroah-Hartman
In-Reply-To: <20120308153931.b1b8b4f27d8e4a94b219bf4c@canb.auug.org.au>
On Thu, 8 Mar 2012 15:39:31 +1100
Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> The PowerPC legacy iSeries platform is being removed so this is no
> longer selectable.
Fine by me
^ permalink raw reply
* RE: [PATCH 2/4] fsl_pci: Add a workaround for PCI 5 errata in MPC8548
From: Zhao Chenhui-B35336 @ 2012-03-08 11:21 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev@lists.ozlabs.org
In-Reply-To: <9449E54A-E134-45B9-A012-C824753D0C97@kernel.crashing.org>
> On Mar 6, 2012, at 3:10 AM, Zhao Chenhui wrote:
>=20
> > + if ((fsl_svr_is(SVR_8548) || fsl_svr_is(SVR_8548_E)) &&
>=20
> Should this also have 8547, 8547E, 8545, 8545E, 8543, & 8543E?
Yes. I will include these chips.
-Chenhui
>=20
> > + !early_find_capability(hose, 0, 0, PCI_CAP_ID_PCIX)) {
> > + early_read_config_word(hose, 0, 0,
> > + PCI_BUS_FUNCTION, &temp);
> > + temp |=3D PCI_BUS_FUNCTION_MDS;
> > + early_write_config_word(hose, 0, 0,
> > + PCI_BUS_FUNCTION, temp);
> > + }
> > }
>=20
^ permalink raw reply
* Re: [PATCH] PPC: Don't sync timebase when inside VM
From: McClintock Matthew-B29882 @ 2012-03-08 17:31 UTC (permalink / raw)
To: Wood Scott-B07421
Cc: <kvm-ppc@vger.kernel.org>, linuxppc-dev, Alexander Graf,
kvm list
In-Reply-To: <4F5100A0.8040802@freescale.com>
On Fri, Mar 2, 2012 at 11:17 AM, Scott Wood <scottwood@freescale.com> wrote=
:
> On 03/02/2012 10:30 AM, Alexander Graf wrote:
>>
>> On 02.03.2012, at 17:20, Scott Wood wrote:
>>
>>> On Fri, Mar 02, 2012 at 03:12:33PM +0100, Alexander Graf wrote:
>>>> When running inside a virtual machine, we can not modify timebase, so
>>>> let's just not call the functions for it then.
>>>>
>>>> This resolves hangs when booting e500 SMP guests on overcommitted host=
s.
>>>>
>>>> Reported-by: Stuart Yoder <B08248@freescale.com>
>>>> Signed-off-by: Alexander Graf <agraf@suse.de>
>>>> ---
>>>> arch/powerpc/platforms/85xx/smp.c | =A0 =A07 +++++++
>>>> 1 files changed, 7 insertions(+), 0 deletions(-)
>>>>
>>>> diff --git a/arch/powerpc/platforms/85xx/smp.c b/arch/powerpc/platform=
s/85xx/smp.c
>>>> index ff42490..d4b6c1f 100644
>>>> --- a/arch/powerpc/platforms/85xx/smp.c
>>>> +++ b/arch/powerpc/platforms/85xx/smp.c
>>>> @@ -249,6 +249,13 @@ void __init mpc85xx_smp_init(void)
>>>> =A0 =A0 =A0 =A0 =A0 =A0 smp_85xx_ops.cause_ipi =3D doorbell_cause_ipi;
>>>> =A0 =A0 }
>>>>
>>>> + =A0 /* When running under a hypervisor, we can not modify tb */
>>>> + =A0 np =3D of_find_node_by_path("/hypervisor");
>>>> + =A0 if (np) {
>>>> + =A0 =A0 =A0 =A0 =A0 smp_85xx_ops.give_timebase =3D NULL;
>>>> + =A0 =A0 =A0 =A0 =A0 smp_85xx_ops.take_timebase =3D NULL;
>>>> + =A0 }
>>>> +
>>>> =A0 =A0 smp_ops =3D &smp_85xx_ops;
>>>
>>> Again, for 85xx we should *never* sync the timebase in the kernel,
>>> hypervisor or no.
>>
>> The code says "if the kexec config option is enabled, do the sync". I'm =
fairly sure it's there for a reason.
>
> Sigh. =A0I forgot about that. =A0It's because instead of doing kexec the
> simple way, we actually physically reset the core. =A0We really shouldn't
> do that. =A0And we *really* shouldn't do it just because CONFIG_KEXEC is
> defined, regardless of whether we're actually booting from kexec.
How would one rocver a core that's off in the weeds? We need to at
least stop it somehow before we restart into the kdump kernel. kexec
seems feasible since we have all the cores in a known state...
-M=
^ permalink raw reply
* Re: [PATCH 0/7] powerpc: remove the legacy iSeries platform specific drivers
From: Greg Kroah-Hartman @ 2012-03-08 17:59 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Jens Axboe, linux-scsi, LKML, James E.J. Bottomley, linux-serial,
netdev, Brian King, ppc-dev, David Miller, Alan Cox
In-Reply-To: <20120308152853.b5010336abbb8f90e8a2500c@canb.auug.org.au>
On Thu, Mar 08, 2012 at 03:28:53PM +1100, Stephen Rothwell wrote:
> Hi all,
>
> This series of patches removes all the legacy iSeries platform specific
> drivers (and the iSeries specific part of one). The legacy iSeries
> platform main code has already bee removed along with CONFIG_PPC_ISERIES,
> so none of this code is selectable or needed any more.
>
> It would probably be easiest if all these patches were merged via the
> powerpc tree to eliminate any dependencies between them. Their impact on
> generic code is very small.
No objection from me at all.
greg k-h
^ permalink raw reply
* Re: [PATCH] PPC: Don't sync timebase when inside VM
From: Scott Wood @ 2012-03-08 18:20 UTC (permalink / raw)
To: McClintock Matthew-B29882
Cc: <kvm-ppc@vger.kernel.org>, Wood Scott-B07421, linuxppc-dev,
Alexander Graf, kvm list
In-Reply-To: <CAEsOVNczPUdfUK6oZ7WOTGUQbA135HgrntwvnydbYd-Eo4joLg@mail.gmail.com>
On 03/08/2012 11:31 AM, McClintock Matthew-B29882 wrote:
> On Fri, Mar 2, 2012 at 11:17 AM, Scott Wood <scottwood@freescale.com> wrote:
>> On 03/02/2012 10:30 AM, Alexander Graf wrote:
>>>
>>> On 02.03.2012, at 17:20, Scott Wood wrote:
>>>> Again, for 85xx we should *never* sync the timebase in the kernel,
>>>> hypervisor or no.
>>>
>>> The code says "if the kexec config option is enabled, do the sync". I'm fairly sure it's there for a reason.
>>
>> Sigh. I forgot about that. It's because instead of doing kexec the
>> simple way, we actually physically reset the core. We really shouldn't
>> do that. And we *really* shouldn't do it just because CONFIG_KEXEC is
>> defined, regardless of whether we're actually booting from kexec.
>
> How would one rocver a core that's off in the weeds?
System reset?
I thought kexec was for upgrading your kernel, not recovering from crashes.
> We need to at least stop it somehow before we restart into the kdump kernel. kexec
> seems feasible since we have all the cores in a known state...
Stop, yes. Reset, no.
-Scott
^ permalink raw reply
* Re: [PATCH] PPC: Don't sync timebase when inside VM
From: McClintock Matthew-B29882 @ 2012-03-08 18:24 UTC (permalink / raw)
To: Wood Scott-B07421
Cc: Wood Scott-B07421, kvm list, Alexander Graf,
<kvm-ppc@vger.kernel.org>, McClintock Matthew-B29882,
linuxppc-dev
In-Reply-To: <4F58F85F.8090604@freescale.com>
On Thu, Mar 8, 2012 at 12:20 PM, Scott Wood <scottwood@freescale.com> wrote=
:
> On 03/08/2012 11:31 AM, McClintock Matthew-B29882 wrote:
>> On Fri, Mar 2, 2012 at 11:17 AM, Scott Wood <scottwood@freescale.com> wr=
ote:
>>> On 03/02/2012 10:30 AM, Alexander Graf wrote:
>>>>
>>>> On 02.03.2012, at 17:20, Scott Wood wrote:
>>>>> Again, for 85xx we should *never* sync the timebase in the kernel,
>>>>> hypervisor or no.
>>>>
>>>> The code says "if the kexec config option is enabled, do the sync". I'=
m fairly sure it's there for a reason.
>>>
>>> Sigh. =A0I forgot about that. =A0It's because instead of doing kexec th=
e
>>> simple way, we actually physically reset the core. =A0We really shouldn=
't
>>> do that. =A0And we *really* shouldn't do it just because CONFIG_KEXEC i=
s
>>> defined, regardless of whether we're actually booting from kexec.
>>
>> How would one rocver a core that's off in the weeds?
>
> System reset?
kdump restarts a kernel using a reserved memory region to inspect the
memory of the crashed kernel. Wouldn't system reset cause issues here?
> I thought kexec was for upgrading your kernel, not recovering from crashe=
s.
>
>> We need to at least stop it somehow before we restart into the kdump ker=
nel. kexec
>> seems feasible since we have all the cores in a known state...
>
> Stop, yes. =A0Reset, no.
How would we stop the remaining cores assuming they could be in any state?
-M=
^ permalink raw reply
* Re: [PATCH] PPC: Don't sync timebase when inside VM
From: Scott Wood @ 2012-03-08 18:43 UTC (permalink / raw)
To: McClintock Matthew-B29882
Cc: <kvm-ppc@vger.kernel.org>, Wood Scott-B07421, linuxppc-dev,
Alexander Graf, kvm list
In-Reply-To: <CAEsOVNcqSBh0hmgUQcJJjD28JbreBqYygHF7Q6Y8uaFzdj2PYw@mail.gmail.com>
On 03/08/2012 12:24 PM, McClintock Matthew-B29882 wrote:
> On Thu, Mar 8, 2012 at 12:20 PM, Scott Wood <scottwood@freescale.com> wrote:
>> On 03/08/2012 11:31 AM, McClintock Matthew-B29882 wrote:
>>> On Fri, Mar 2, 2012 at 11:17 AM, Scott Wood <scottwood@freescale.com> wrote:
>>>> On 03/02/2012 10:30 AM, Alexander Graf wrote:
>>>>>
>>>>> On 02.03.2012, at 17:20, Scott Wood wrote:
>>>>>> Again, for 85xx we should *never* sync the timebase in the kernel,
>>>>>> hypervisor or no.
>>>>>
>>>>> The code says "if the kexec config option is enabled, do the sync". I'm fairly sure it's there for a reason.
>>>>
>>>> Sigh. I forgot about that. It's because instead of doing kexec the
>>>> simple way, we actually physically reset the core. We really shouldn't
>>>> do that. And we *really* shouldn't do it just because CONFIG_KEXEC is
>>>> defined, regardless of whether we're actually booting from kexec.
>>>
>>> How would one rocver a core that's off in the weeds?
>>
>> System reset?
>
> kdump restarts a kernel using a reserved memory region to inspect the
> memory of the crashed kernel. Wouldn't system reset cause issues here?
Oh, kdump.
Maybe in that case, go ahead and reset the other cores (or halt them via
some other means), but don't do anything with them. Just boot a single
core in the dump kernel, do the dumping, then reset the system?
Or if you must sync the timebase in Linux, do it the way U-Boot does
(and skip it if you don't have access to the relevant CCSR bits).
Are I/O devices a problem with kdump and not resetting the system,
especially on some of our chips where certain I/O devices are difficult
to reset?
-Scott
^ permalink raw reply
* Re: [PATCH] PPC: Don't sync timebase when inside VM
From: McClintock Matthew-B29882 @ 2012-03-08 18:46 UTC (permalink / raw)
To: Wood Scott-B07421
Cc: Wood Scott-B07421, kvm list, Alexander Graf,
<kvm-ppc@vger.kernel.org>, McClintock Matthew-B29882,
linuxppc-dev
In-Reply-To: <4F58FDC4.2080909@freescale.com>
On Thu, Mar 8, 2012 at 12:43 PM, Scott Wood <scottwood@freescale.com> wrote=
:
> On 03/08/2012 12:24 PM, McClintock Matthew-B29882 wrote:
>> On Thu, Mar 8, 2012 at 12:20 PM, Scott Wood <scottwood@freescale.com> wr=
ote:
>>> On 03/08/2012 11:31 AM, McClintock Matthew-B29882 wrote:
>>>> On Fri, Mar 2, 2012 at 11:17 AM, Scott Wood <scottwood@freescale.com> =
wrote:
>>>>> On 03/02/2012 10:30 AM, Alexander Graf wrote:
>>>>>>
>>>>>> On 02.03.2012, at 17:20, Scott Wood wrote:
>>>>>>> Again, for 85xx we should *never* sync the timebase in the kernel,
>>>>>>> hypervisor or no.
>>>>>>
>>>>>> The code says "if the kexec config option is enabled, do the sync". =
I'm fairly sure it's there for a reason.
>>>>>
>>>>> Sigh. =A0I forgot about that. =A0It's because instead of doing kexec =
the
>>>>> simple way, we actually physically reset the core. =A0We really shoul=
dn't
>>>>> do that. =A0And we *really* shouldn't do it just because CONFIG_KEXEC=
is
>>>>> defined, regardless of whether we're actually booting from kexec.
>>>>
>>>> How would one rocver a core that's off in the weeds?
>>>
>>> System reset?
>>
>> kdump restarts a kernel using a reserved memory region to inspect the
>> memory of the crashed kernel. Wouldn't system reset cause issues here?
>
> Oh, kdump.
>
> Maybe in that case, go ahead and reset the other cores (or halt them via
> some other means), but don't do anything with them. =A0Just boot a single
> core in the dump kernel, do the dumping, then reset the system?
Yes, we could do one core here... but is it worthwhile to do kexec and
kdump differently?
> Or if you must sync the timebase in Linux, do it the way U-Boot does
> (and skip it if you don't have access to the relevant CCSR bits).
Ok - I've never even looked at how the timebase sync was done in Linux
or u-boot. Just enabled the timebase sync
> Are I/O devices a problem with kdump and not resetting the system,
> especially on some of our chips where certain I/O devices are difficult
> to reset?
Anything still occurring will be problematic and *possibly* prevent us
from determining what caused the actual crash.
-M=
^ permalink raw reply
* Re: [PATCH 19/38] KVM: PPC: e500mc: add load inst fixup
From: Marcelo Tosatti @ 2012-03-08 22:36 UTC (permalink / raw)
To: Alexander Graf; +Cc: Scott Wood, linuxppc-dev, kvm, kvm-ppc
In-Reply-To: <1330474206-14794-20-git-send-email-agraf@suse.de>
On Wed, Feb 29, 2012 at 01:09:47AM +0100, Alexander Graf wrote:
> There's always a chance we're unable to read a guest instruction. The guest
> could have its TLB mapped execute-, but not readable, something odd happens
> and our TLB gets flushed. So it's a good idea to be prepared for that case
> and have a fallback that allows us to fix things up in that case.
>
> Add fixup code that keeps guest code from potentially crashing our host kernel.
>
> Signed-off-by: Alexander Graf <agraf@suse.de>
>
> ---
>
> v1 -> v2:
>
> - fix whitespace
Still broken.
> - use explicit preempt counts
> ---
> arch/powerpc/kvm/bookehv_interrupts.S | 30 +++++++++++++++++++++++++++++-
> 1 files changed, 29 insertions(+), 1 deletions(-)
>
> diff --git a/arch/powerpc/kvm/bookehv_interrupts.S b/arch/powerpc/kvm/bookehv_interrupts.S
> index 63023ae..f7dc3f6 100644
> --- a/arch/powerpc/kvm/bookehv_interrupts.S
> +++ b/arch/powerpc/kvm/bookehv_interrupts.S
> @@ -28,6 +28,7 @@
> #include <asm/asm-compat.h>
> #include <asm/asm-offsets.h>
> #include <asm/bitsperlong.h>
> +#include <asm/thread_info.h>
>
> #include "../kernel/head_booke.h" /* for THREAD_NORMSAVE() */
>
> @@ -171,9 +172,36 @@
> PPC_STL r30, VCPU_GPR(r30)(r4)
> PPC_STL r31, VCPU_GPR(r31)(r4)
> mtspr SPRN_EPLC, r8
> +
> + /* disable preemption, so we are sure we hit the fixup handler */
> +#ifdef CONFIG_PPC64
> + clrrdi r8,r1,THREAD_SHIFT
> +#else
> + rlwinm r8,r1,0,0,31-THREAD_SHIFT /* current thread_info */
> +#endif
> + li r7, 1
> + stw r7, TI_PREEMPT(r8)
> +
> isync
> - lwepx r9, 0, r5
> +
> + /*
> + * In case the read goes wrong, we catch it and write an invalid value
> + * in LAST_INST instead.
> + */
> +1: lwepx r9, 0, r5
> +2:
> +.section .fixup, "ax"
> +3: li r9, KVM_INST_FETCH_FAILED
> + b 2b
> +.previous
> +.section __ex_table,"a"
> + PPC_LONG_ALIGN
> + PPC_LONG 1b,3b
> +.previous
> +
> mtspr SPRN_EPLC, r3
> + li r7, 0
> + stw r7, TI_PREEMPT(r8)
> stw r9, VCPU_LAST_INST(r4)
> .endif
^ permalink raw reply
* Re: linux-next: manual merge of the powerpc tree with the arm tree
From: Benjamin Herrenschmidt @ 2012-03-08 23:35 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Michael Neuling, linux-kernel, Rob Herring, linux-next,
Paul Mackerras, linuxppc-dev, Russell King
In-Reply-To: <1331185951.3105.29.camel@pasglop>
On Thu, 2012-03-08 at 16:52 +1100, Benjamin Herrenschmidt wrote:
> On Thu, 2012-03-08 at 14:51 +1100, Stephen Rothwell wrote:
> > Hi Mikey,
> >
> > On Thu, 08 Mar 2012 13:33:56 +1100 Michael Neuling <mikey@neuling.org> wrote:
> > >
> > > Surely we only need SPARSE_IRQ now and not MAY_HAVE_SPARSE_IRQ.
> > >
> > > In fact, keeping MAY_HAVE_SPARSE_IRQ seems to make SPARSE_IRQ user
> > > selectable, which we don't want anymore since ad5b7f1350c2.
> >
> > Yes, indeed. I will fix up the merge resolution for tomorrow.
>
> This is my fault. Grant's patch had a collision and I manually fixed it
> up. While doing that, I put back MAY_HAVE_SPARSE_IRQ which the patch
> originally took out.
Actually, I didn't keep MAY_HAVE_SPARSE_IRQ, I kept HAVE_SPARSE_IRQ. If
I remove it, then I get Kconfig warnings:
warning: (PPC) selects SPARSE_IRQ which has unmet direct dependencies (HAVE_GENERIC_HARDIRQS && HAVE_SPARSE_IRQ)
Cheers,
Ben.
^ permalink raw reply
* Re: linux-next: manual merge of the powerpc tree with the arm tree
From: Russell King @ 2012-03-09 0:39 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Stephen Rothwell, Michael Neuling, linux-kernel, Rob Herring,
linux-next, Paul Mackerras, linuxppc-dev
In-Reply-To: <1331249746.3105.40.camel@pasglop>
On Fri, Mar 09, 2012 at 10:35:46AM +1100, Benjamin Herrenschmidt wrote:
> Actually, I didn't keep MAY_HAVE_SPARSE_IRQ, I kept HAVE_SPARSE_IRQ. If
> I remove it, then I get Kconfig warnings:
>
> warning: (PPC) selects SPARSE_IRQ which has unmet direct dependencies
> (HAVE_GENERIC_HARDIRQS && HAVE_SPARSE_IRQ)
Do you have commit 2ed86b16eabe4efbf80cc725a8cbb5310746a2fc ?
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of:
^ permalink raw reply
* linux-next: manual merge of the pci tree with the powerpc tree
From: Stephen Rothwell @ 2012-03-09 1:32 UTC (permalink / raw)
To: Jesse Barnes
Cc: linux-kernel, linux-next, Paul Mackerras, Bjorn Helgaas,
linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 440 bytes --]
Hi Jesse,
Today's linux-next merge of the pci tree got a conflict in
arch/powerpc/platforms/iseries/pci.c between commit 8ee3e0d69623
("powerpc: Remove the main legacy iSerie platform code") from the powerpc
tree and commit 673c97562489 ("powerpc/PCI: replace pci_probe_only with
pci_flags") from the pci tree.
The former removed the file, so I did that.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* linux-next: manual merge of the net-next tree with the powerpc tree
From: Stephen Rothwell @ 2012-03-09 2:36 UTC (permalink / raw)
To: David Miller, netdev
Cc: linux-kernel, linux-next, Paul Mackerras, Joe Perches,
linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 432 bytes --]
Hi all,
Today's linux-next merge of the net-next tree got a conflict in
drivers/net/ethernet/ibm/iseries_veth.c between commit e92a665949f6
("net: powerpc: remove the legacy iSeries ethernet driver") from the
powerpc tree and commit 41de8d4cff21 ("drivers/net: Remove alloc_etherdev
error messages") from the net-next tree.
I just removed the file.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: linux-next: manual merge of the powerpc tree with the arm tree
From: Benjamin Herrenschmidt @ 2012-03-09 3:13 UTC (permalink / raw)
To: Russell King
Cc: Stephen Rothwell, Michael Neuling, linux-kernel, Rob Herring,
linux-next, Paul Mackerras, linuxppc-dev
In-Reply-To: <20120309003937.GC8680@flint.arm.linux.org.uk>
On Fri, 2012-03-09 at 00:39 +0000, Russell King wrote:
> On Fri, Mar 09, 2012 at 10:35:46AM +1100, Benjamin Herrenschmidt wrote:
> > Actually, I didn't keep MAY_HAVE_SPARSE_IRQ, I kept HAVE_SPARSE_IRQ. If
> > I remove it, then I get Kconfig warnings:
> >
> > warning: (PPC) selects SPARSE_IRQ which has unmet direct dependencies
> > (HAVE_GENERIC_HARDIRQS && HAVE_SPARSE_IRQ)
>
> Do you have commit 2ed86b16eabe4efbf80cc725a8cbb5310746a2fc ?
Nope, Grant patch didn't mention a dependency.
Cheers,
Ben.
^ permalink raw reply
* [PATCH 1/2] powerpc/44x: Fix PCI MSI support for Maui APM821xx SoC and Bluestone board
From: Mai La @ 2012-03-09 3:17 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras, Josh Boyer, Matt Porter,
Tirumala R Marri, Grant Likely, Michael Neuling, Kumar Gala,
Anton Blanchard, linuxppc-dev, linux-kernel
Cc: open-source-review, Mai La
This patch consists of:
- Enable PCI MSI as default for Bluestone board
- Define number of MSI interrupt for Maui APM821xx SoC using in Bluestone board
- Fix returning ENODEV as finding MSI node
- Fix MSI physical high and low address
- Keep MSI data logically
Signed-off-by: Mai La <mla@apm.com>
---
arch/powerpc/platforms/44x/Kconfig | 2 ++
arch/powerpc/sysdev/Kconfig | 6 ++++++
arch/powerpc/sysdev/ppc4xx_msi.c | 27 ++++++++++++++++-----------
3 files changed, 24 insertions(+), 11 deletions(-)
diff --git a/arch/powerpc/platforms/44x/Kconfig b/arch/powerpc/platforms/44x/Kconfig
index fcf6bf2..9f04ce3 100644
--- a/arch/powerpc/platforms/44x/Kconfig
+++ b/arch/powerpc/platforms/44x/Kconfig
@@ -23,6 +23,8 @@ config BLUESTONE
default n
select PPC44x_SIMPLE
select APM821xx
+ select PCI_MSI
+ select PPC4xx_MSI
select IBM_EMAC_RGMII
help
This option enables support for the APM APM821xx Evaluation board.
diff --git a/arch/powerpc/sysdev/Kconfig b/arch/powerpc/sysdev/Kconfig
index 7b4df37..c86231e 100644
--- a/arch/powerpc/sysdev/Kconfig
+++ b/arch/powerpc/sysdev/Kconfig
@@ -20,6 +20,12 @@ config PPC_MSI_BITMAP
default y if FSL_PCI
default y if PPC4xx_MSI
+config PPC4xx_NR_MSI_IRQS
+ int "Number of PCI MSI interrupts"
+ depends on PCI_MSI && PPC4xx_MSI
+ default "4" if !APM821xx
+ default "8" if APM821xx
+
source "arch/powerpc/sysdev/xics/Kconfig"
config PPC_SCOM
diff --git a/arch/powerpc/sysdev/ppc4xx_msi.c b/arch/powerpc/sysdev/ppc4xx_msi.c
index 1c2d7af..3359237 100644
--- a/arch/powerpc/sysdev/ppc4xx_msi.c
+++ b/arch/powerpc/sysdev/ppc4xx_msi.c
@@ -28,10 +28,11 @@
#include <linux/of_platform.h>
#include <linux/interrupt.h>
#include <linux/export.h>
+#include <linux/kernel.h>
#include <asm/prom.h>
#include <asm/hw_irq.h>
#include <asm/ppc-pci.h>
-#include <boot/dcr.h>
+#include <asm/dcr.h>
#include <asm/dcr-regs.h>
#include <asm/msi_bitmap.h>
@@ -43,7 +44,8 @@
#define PEIH_FLUSH0 0x30
#define PEIH_FLUSH1 0x38
#define PEIH_CNTRST 0x48
-#define NR_MSI_IRQS 4
+
+#define NR_MSI_IRQS CONFIG_PPC4xx_NR_MSI_IRQS
struct ppc4xx_msi {
u32 msi_addr_lo;
@@ -150,12 +152,11 @@ static int ppc4xx_setup_pcieh_hw(struct platform_device *dev,
if (!sdr_addr)
return -1;
- SDR0_WRITE(sdr_addr, (u64)res.start >> 32); /*HIGH addr */
- SDR0_WRITE(sdr_addr + 1, res.start & 0xFFFFFFFF); /* Low addr */
-
+ mtdcri(SDR0, *sdr_addr, upper_32_bits(res.start)); /*HIGH addr */
+ mtdcri(SDR0, *sdr_addr + 1, lower_32_bits(res.start)); /* Low addr */
msi->msi_dev = of_find_node_by_name(NULL, "ppc4xx-msi");
- if (msi->msi_dev)
+ if (!msi->msi_dev)
return -ENODEV;
msi->msi_regs = of_iomap(msi->msi_dev, 0);
@@ -167,9 +168,12 @@ static int ppc4xx_setup_pcieh_hw(struct platform_device *dev,
(u32) (msi->msi_regs + PEIH_TERMADH), (u32) (msi->msi_regs));
msi_virt = dma_alloc_coherent(&dev->dev, 64, &msi_phys, GFP_KERNEL);
- msi->msi_addr_hi = 0x0;
- msi->msi_addr_lo = (u32) msi_phys;
- dev_dbg(&dev->dev, "PCIE-MSI: msi address 0x%x\n", msi->msi_addr_lo);
+ if (!msi_virt)
+ return -ENOMEM;
+ msi->msi_addr_hi = (u32)(msi_phys >> 32);
+ msi->msi_addr_lo = (u32)(msi_phys & 0xffffffff);
+ dev_dbg(&dev->dev, "PCIE-MSI: msi address high 0x%x, low 0x%x\n",
+ msi->msi_addr_hi, msi->msi_addr_lo);
/* Progam the Interrupt handler Termination addr registers */
out_be32(msi->msi_regs + PEIH_TERMADH, msi->msi_addr_hi);
@@ -185,6 +189,8 @@ static int ppc4xx_setup_pcieh_hw(struct platform_device *dev,
out_be32(msi->msi_regs + PEIH_MSIED, *msi_data);
out_be32(msi->msi_regs + PEIH_MSIMK, *msi_mask);
+ dma_free_coherent(&dev->dev, 64, msi_virt, msi_phys);
+
return 0;
}
@@ -215,8 +221,6 @@ static int __devinit ppc4xx_msi_probe(struct platform_device *dev)
struct resource res;
int err = 0;
- msi = &ppc4xx_msi;/*keep the msi data for further use*/
-
dev_dbg(&dev->dev, "PCIE-MSI: Setting up MSI support...\n");
msi = kzalloc(sizeof(struct ppc4xx_msi), GFP_KERNEL);
@@ -242,6 +246,7 @@ static int __devinit ppc4xx_msi_probe(struct platform_device *dev)
dev_err(&dev->dev, "Error allocating MSI bitmap\n");
goto error_out;
}
+ ppc4xx_msi = *msi;
ppc_md.setup_msi_irqs = ppc4xx_setup_msi_irqs;
ppc_md.teardown_msi_irqs = ppc4xx_teardown_msi_irqs;
--
1.7.3.4
^ permalink raw reply related
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