* [PATCH]qonverge/usb: Add first usb controller node
From: Ramneek Mehresh @ 2013-02-28 8:46 UTC (permalink / raw)
To: linuxppc-dev, devicetree-discuss; +Cc: kumar.gala, Ramneek Mehresh
Add first usb controller node for qonverge qoriq platforms like
B4860, etc
Signed-off-by: Ramneek Mehresh <ramneek.mehresh@freescale.com>
---
Applies on git://git.kernel.org/pub/scm/linux/kernel/git/galak/powerpc.git
(branch next)
arch/powerpc/boot/dts/fsl/qonverge-usb2-dr-0.dtsi | 41 +++++++++++++++++++++++
1 file changed, 41 insertions(+)
create mode 100644 arch/powerpc/boot/dts/fsl/qonverge-usb2-dr-0.dtsi
diff --git a/arch/powerpc/boot/dts/fsl/qonverge-usb2-dr-0.dtsi b/arch/powerpc/boot/dts/fsl/qonverge-usb2-dr-0.dtsi
new file mode 100644
index 0000000..29dad72
--- /dev/null
+++ b/arch/powerpc/boot/dts/fsl/qonverge-usb2-dr-0.dtsi
@@ -0,0 +1,41 @@
+/*
+ * QorIQ Qonverge USB Host device tree stub [ controller @ offset 0x210000 ]
+ *
+ * Copyright 2013 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.
+ */
+
+usb@210000 {
+ compatible = "fsl-usb2-dr";
+ reg = <0x210000 0x1000>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ interrupts = <44 0x2 0 0>;
+};
--
1.7.11.4
^ permalink raw reply related
* Re: [PATCH] Enhanced support for MPC8xx/8xxx watchdog
From: leroy christophe @ 2013-02-28 8:52 UTC (permalink / raw)
To: Wim Van Sebroeck; +Cc: linuxppc-dev, linux-kernel, linux-watchdog
In-Reply-To: <20130227195214.GC7867@spo001.leaseweb.com>
Hi Wim,
Le 27/02/2013 20:52, Wim Van Sebroeck a écrit :
> The rest of the code is OK and when above comments are corrected,
> I will add the patch to improve the userspace experience.
>
> Kind regards,
> Wim.
Ok, I'll fix and re-submit my patch according to your comments.
Best regards
Christophe
^ permalink raw reply
* [PATCH v2] Enhanced support for MPC8xx/8xxx watchdog
From: Christophe Leroy @ 2013-02-28 8:52 UTC (permalink / raw)
To: Wim Van Sebroeck; +Cc: linuxppc-dev, linux-kernel, linux-watchdog
This patch modifies the behaviour of the MPC8xx/8xxx watchdog. On the MPC8xx,
at 133Mhz, the maximum timeout of the watchdog timer is 1s, which means it must
be pinged twice a second. This is not in line with the Linux watchdog concept
which is based on a default watchdog timeout around 60s.
This patch introduces an intermediate layer between the CPU and the userspace.
The kernel pings the watchdog at the required frequency at the condition that
userspace tools refresh it regularly.
Existing parameter 'timeout' is renamed 'hw_time'.
The new parameter 'timeout' allows to set up the userspace timeout.
The driver also implements the WDIOC_SETTIMEOUT ioctl.
Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
diff -ur linux-3.7.9/drivers/watchdog/mpc8xxx_wdt.c linux/drivers/watchdog/mpc8xxx_wdt.c
--- linux-3.7.9/drivers/watchdog/mpc8xxx_wdt.c 2013-02-17 19:53:32.000000000 +0100
+++ linux/drivers/watchdog/mpc8xxx_wdt.c 2013-02-27 16:00:07.000000000 +0100
@@ -52,10 +52,17 @@
static struct mpc8xxx_wdt __iomem *wd_base;
static int mpc8xxx_wdt_init_late(void);
-static u16 timeout = 0xffff;
-module_param(timeout, ushort, 0);
+#define WD_TIMO 10 /* Default timeout = 10 seconds */
+
+static uint timeout = WD_TIMO;
+module_param(timeout, uint, 0);
MODULE_PARM_DESC(timeout,
- "Watchdog timeout in ticks. (0<timeout<65536, default=65535)");
+ "Watchdog SW timeout in seconds. (0 < timeout < 65536s, default = "
+ __MODULE_STRING(WD_TIMO) "s)");
+static u16 hw_timo = 0xffff;
+module_param(hw_timo, ushort, 0);
+MODULE_PARM_DESC(hw_timo,
+ "Watchdog HW timeout in ticks. (0 < hw_timo < 65536, default = 65535)");
static bool reset = 1;
module_param(reset, bool, 0);
@@ -72,10 +79,12 @@
* to 0
*/
static int prescale = 1;
-static unsigned int timeout_sec;
+static unsigned int hw_timo_sec;
+static int wdt_auto = 1;
static unsigned long wdt_is_open;
static DEFINE_SPINLOCK(wdt_spinlock);
+static unsigned long wdt_last_ping;
static void mpc8xxx_wdt_keepalive(void)
{
@@ -91,9 +100,20 @@
static void mpc8xxx_wdt_timer_ping(unsigned long arg)
{
- mpc8xxx_wdt_keepalive();
- /* We're pinging it twice faster than needed, just to be sure. */
- mod_timer(&wdt_timer, jiffies + HZ * timeout_sec / 2);
+ if (wdt_auto)
+ wdt_last_ping = jiffies;
+
+ if (jiffies - wdt_last_ping <= timeout * HZ) {
+ mpc8xxx_wdt_keepalive();
+ /* We're pinging it twice faster than needed, to be sure. */
+ mod_timer(&wdt_timer, jiffies + HZ * hw_timo_sec / 2);
+ }
+}
+
+static void mpc8xxx_wdt_sw_keepalive(void)
+{
+ wdt_last_ping = jiffies;
+ mpc8xxx_wdt_timer_ping(0);
}
static void mpc8xxx_wdt_pr_warn(const char *msg)
@@ -106,7 +126,7 @@
size_t count, loff_t *ppos)
{
if (count)
- mpc8xxx_wdt_keepalive();
+ mpc8xxx_wdt_sw_keepalive();
return count;
}
@@ -126,11 +146,11 @@
if (reset)
tmp |= SWCRR_SWRI;
- tmp |= timeout << 16;
+ tmp |= hw_timo << 16;
out_be32(&wd_base->swcrr, tmp);
- del_timer_sync(&wdt_timer);
+ wdt_auto = 0;
return nonseekable_open(inode, file);
}
@@ -138,7 +158,8 @@
static int mpc8xxx_wdt_release(struct inode *inode, struct file *file)
{
if (!nowayout)
- mpc8xxx_wdt_timer_ping(0);
+ wdt_auto = 1;
+
else
mpc8xxx_wdt_pr_warn("watchdog closed");
clear_bit(0, &wdt_is_open);
@@ -163,10 +184,12 @@
case WDIOC_GETBOOTSTATUS:
return put_user(0, p);
case WDIOC_KEEPALIVE:
- mpc8xxx_wdt_keepalive();
+ mpc8xxx_wdt_sw_keepalive();
return 0;
case WDIOC_GETTIMEOUT:
- return put_user(timeout_sec, p);
+ return put_user(timeout, p);
+ case WDIOC_SETTIMEOUT:
+ return get_user(timeout, p);
default:
return -ENOTTY;
}
@@ -215,12 +238,14 @@
ret = -ENOSYS;
goto err_unmap;
}
+ if (enabled)
+ hw_timo = in_be32(&wd_base->swcrr) >> 16;
/* Calculate the timeout in seconds */
if (prescale)
- timeout_sec = (timeout * wdt_type->prescaler) / freq;
+ hw_timo_sec = (hw_timo * wdt_type->prescaler) / freq;
else
- timeout_sec = timeout / freq;
+ hw_timo_sec = hw_timo / freq;
#ifdef MODULE
ret = mpc8xxx_wdt_init_late();
@@ -228,8 +253,8 @@
goto err_unmap;
#endif
- pr_info("WDT driver for MPC8xxx initialized. mode:%s timeout=%d (%d seconds)\n",
- reset ? "reset" : "interrupt", timeout, timeout_sec);
+ pr_info("WDT driver for MPC8xxx initialized. mode:%s timeout = %d (%d seconds)\n",
+ reset ? "reset" : "interrupt", hw_timo, hw_timo_sec);
/*
* If the watchdog was previously enabled or we're running on
@@ -273,6 +298,7 @@
.compatible = "fsl,mpc823-wdt",
.data = &(struct mpc8xxx_wdt_type) {
.prescaler = 0x800,
+ .hw_enabled = true,
},
},
{},
^ permalink raw reply
* Re: [PATCH] drivers/tty/hvc: using strlcpy instead of strncpy
From: Jiri Slaby @ 2013-02-28 10:41 UTC (permalink / raw)
To: Chen Gang, wfp5p, tklauser; +Cc: Greg KH, linuxppc-dev, alan
In-Reply-To: <512C2F5D.1080207@asianux.com>
On 02/26/2013 04:43 AM, Chen Gang wrote:
>
> when strlen pi->location_code is larger than HVCS_CLC_LENGTH + 1,
> original implementation can not let hvcsd->p_location_code NUL terminated.
> so need fix it (also can simplify the code)
It should never be larger because the +1 is exactly for NUL. But it is a
cleanup, so why not...
> Signed-off-by: Chen Gang <gang.chen@asianux.com>
> ---
> drivers/tty/hvc/hvcs.c | 9 ++-------
> 1 files changed, 2 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/tty/hvc/hvcs.c b/drivers/tty/hvc/hvcs.c
> index 1956593..81e939e 100644
> --- a/drivers/tty/hvc/hvcs.c
> +++ b/drivers/tty/hvc/hvcs.c
> @@ -881,17 +881,12 @@ static struct vio_driver hvcs_vio_driver = {
> /* Only called from hvcs_get_pi please */
> static void hvcs_set_pi(struct hvcs_partner_info *pi, struct hvcs_struct *hvcsd)
> {
> - int clclength;
> -
> hvcsd->p_unit_address = pi->unit_address;
> hvcsd->p_partition_ID = pi->partition_ID;
> - clclength = strlen(&pi->location_code[0]);
> - if (clclength > HVCS_CLC_LENGTH)
> - clclength = HVCS_CLC_LENGTH;
>
> /* copy the null-term char too */
> - strncpy(&hvcsd->p_location_code[0],
> - &pi->location_code[0], clclength + 1);
> + strlcpy(&hvcsd->p_location_code[0],
> + &pi->location_code[0], sizeof(hvcsd->p_location_code));
> }
>
> /*
>
--
js
suse labs
^ permalink raw reply
* Re: [PATCH] drivers/tty/hvc: using strlcpy instead of strncpy
From: Chen Gang @ 2013-02-28 11:13 UTC (permalink / raw)
To: Jiri Slaby; +Cc: Greg KH, tklauser, wfp5p, linuxppc-dev, alan
In-Reply-To: <512F343E.7010201@suse.cz>
于 2013年02月28日 18:41, Jiri Slaby 写道:
> On 02/26/2013 04:43 AM, Chen Gang wrote:
>> >
>> > when strlen pi->location_code is larger than HVCS_CLC_LENGTH + 1,
>> > original implementation can not let hvcsd->p_location_code NUL terminated.
>> > so need fix it (also can simplify the code)
> It should never be larger because the +1 is exactly for NUL. But it is a
> cleanup, so why not...
>
when strlen(&pi->location_code[0]) == HVCS_CLC_LENGTH + 2
then clclength will be reset to HVCS_CLC_LENGTH.
when call strncpy, the clclength + 1 == HVCS_CLS_LENGTH + 1
but the '\0' of src buf is located at HVCS_CLS_LENGTH + 2.
so no '\0' copied to dest buf.
then the dest buf will not be ended by '\0'.
is it correct ?
:-)
gchen.
>> > Signed-off-by: Chen Gang <gang.chen@asianux.com>
>> > ---
>> > drivers/tty/hvc/hvcs.c | 9 ++-------
>> > 1 files changed, 2 insertions(+), 7 deletions(-)
>> >
>> > diff --git a/drivers/tty/hvc/hvcs.c b/drivers/tty/hvc/hvcs.c
>> > index 1956593..81e939e 100644
>> > --- a/drivers/tty/hvc/hvcs.c
>> > +++ b/drivers/tty/hvc/hvcs.c
>> > @@ -881,17 +881,12 @@ static struct vio_driver hvcs_vio_driver = {
>> > /* Only called from hvcs_get_pi please */
>> > static void hvcs_set_pi(struct hvcs_partner_info *pi, struct hvcs_struct *hvcsd)
>> > {
>> > - int clclength;
>> > -
>> > hvcsd->p_unit_address = pi->unit_address;
>> > hvcsd->p_partition_ID = pi->partition_ID;
>> > - clclength = strlen(&pi->location_code[0]);
>> > - if (clclength > HVCS_CLC_LENGTH)
>> > - clclength = HVCS_CLC_LENGTH;
>> >
>> > /* copy the null-term char too */
>> > - strncpy(&hvcsd->p_location_code[0],
>> > - &pi->location_code[0], clclength + 1);
>> > + strlcpy(&hvcsd->p_location_code[0],
>> > + &pi->location_code[0], sizeof(hvcsd->p_location_code));
>> > }
>> >
>> > /*
>> >
--
Chen Gang
Asianux Corporation
^ permalink raw reply
* Re: [PATCH] drivers/tty/hvc: using strlcpy instead of strncpy
From: Chen Gang @ 2013-02-28 11:15 UTC (permalink / raw)
To: Jiri Slaby; +Cc: Greg KH, tklauser, wfp5p, linuxppc-dev, alan
In-Reply-To: <512F3BC5.8020903@asianux.com>
于 2013年02月28日 19:13, Chen Gang 写道:
> 于 2013年02月28日 18:41, Jiri Slaby 写道:
>> On 02/26/2013 04:43 AM, Chen Gang wrote:
>>>>
>>>> when strlen pi->location_code is larger than HVCS_CLC_LENGTH + 1,
>>>> original implementation can not let hvcsd->p_location_code NUL terminated.
>>>> so need fix it (also can simplify the code)
>> It should never be larger because the +1 is exactly for NUL. But it is a
>> cleanup, so why not...
>>
>
> when strlen(&pi->location_code[0]) == HVCS_CLC_LENGTH + 2
> then clclength will be reset to HVCS_CLC_LENGTH.
>
> when call strncpy, the clclength + 1 == HVCS_CLS_LENGTH + 1
> but the '\0' of src buf is located at HVCS_CLS_LENGTH + 2.
but the '\0' of src buf is located at HVCS_CLS_LENGTH + 3. (not + 2)
> so no '\0' copied to dest buf.
>
> then the dest buf will not be ended by '\0'.
>
> is it correct ?
>
> :-)
>
> gchen.
>
>>>> Signed-off-by: Chen Gang <gang.chen@asianux.com>
>>>> ---
>>>> drivers/tty/hvc/hvcs.c | 9 ++-------
>>>> 1 files changed, 2 insertions(+), 7 deletions(-)
>>>>
>>>> diff --git a/drivers/tty/hvc/hvcs.c b/drivers/tty/hvc/hvcs.c
>>>> index 1956593..81e939e 100644
>>>> --- a/drivers/tty/hvc/hvcs.c
>>>> +++ b/drivers/tty/hvc/hvcs.c
>>>> @@ -881,17 +881,12 @@ static struct vio_driver hvcs_vio_driver = {
>>>> /* Only called from hvcs_get_pi please */
>>>> static void hvcs_set_pi(struct hvcs_partner_info *pi, struct hvcs_struct *hvcsd)
>>>> {
>>>> - int clclength;
>>>> -
>>>> hvcsd->p_unit_address = pi->unit_address;
>>>> hvcsd->p_partition_ID = pi->partition_ID;
>>>> - clclength = strlen(&pi->location_code[0]);
>>>> - if (clclength > HVCS_CLC_LENGTH)
>>>> - clclength = HVCS_CLC_LENGTH;
>>>>
>>>> /* copy the null-term char too */
>>>> - strncpy(&hvcsd->p_location_code[0],
>>>> - &pi->location_code[0], clclength + 1);
>>>> + strlcpy(&hvcsd->p_location_code[0],
>>>> + &pi->location_code[0], sizeof(hvcsd->p_location_code));
>>>> }
>>>>
>>>> /*
>>>>
>
>
--
Chen Gang
Asianux Corporation
^ permalink raw reply
* Re: [PATCH v6 04/46] percpu_rwlock: Implement the core design of Per-CPU Reader-Writer Locks
From: Michel Lespinasse @ 2013-02-28 11:34 UTC (permalink / raw)
To: Oleg Nesterov
Cc: Lai Jiangshan, linux-doc, peterz, fweisbec, mingo, linux-arch,
linux, xiaoguangrong, wangyun, paulmck, nikunj, linux-pm, rusty,
rostedt, rjw, namhyung, tglx, linux-arm-kernel, netdev,
linux-kernel, vincent.guittot, sbw, Srivatsa S. Bhat, tj, akpm,
linuxppc-dev
In-Reply-To: <20130227192551.GA8333@redhat.com>
On Thu, Feb 28, 2013 at 3:25 AM, Oleg Nesterov <oleg@redhat.com> wrote:
> On 02/27, Michel Lespinasse wrote:
>>
>> +void lg_rwlock_local_read_lock(struct lgrwlock *lgrw)
>> +{
>> + preempt_disable();
>> +
>> + if (__this_cpu_read(*lgrw->local_refcnt) ||
>> + arch_spin_trylock(this_cpu_ptr(lgrw->lglock->lock))) {
>> + __this_cpu_inc(*lgrw->local_refcnt);
>
> Please look at __this_cpu_generic_to_op(). You need this_cpu_inc()
> to avoid the race with irs. The same for _read_unlock.
Hmmm, I was thinking that this was safe because while interrupts might
modify local_refcnt to acquire a nested read lock, they are expected
to release that lock as well which would set local_refcnt back to its
original value ???
--
Michel "Walken" Lespinasse
A program is never fully debugged until the last user dies.
^ permalink raw reply
* Re: [PATCH] drivers/tty/hvc: using strlcpy instead of strncpy
From: Jiri Slaby @ 2013-02-28 13:47 UTC (permalink / raw)
To: Chen Gang; +Cc: Greg KH, tklauser, wfp5p, linuxppc-dev, alan
In-Reply-To: <512F3C60.9070409@asianux.com>
On 02/28/2013 12:15 PM, Chen Gang wrote:
> 于 2013年02月28日 19:13, Chen Gang 写道:
>> 于 2013年02月28日 18:41, Jiri Slaby 写道:
>>> On 02/26/2013 04:43 AM, Chen Gang wrote:
>>>>>
>>>>> when strlen pi->location_code is larger than HVCS_CLC_LENGTH + 1,
>>>>> original implementation can not let hvcsd->p_location_code NUL terminated.
>>>>> so need fix it (also can simplify the code)
>>> It should never be larger because the +1 is exactly for NUL. But it is a
>>> cleanup, so why not...
>>>
>>
>> when strlen(&pi->location_code[0]) == HVCS_CLC_LENGTH + 2
It cannot, pi->location_code is defined as char[HVCS_CLC_LENGTH + 1].
--
js
suse labs
^ permalink raw reply
* [PATCH 014/139] uprobes/powerpc: Add dependency on single step emulation
From: Luis Henriques @ 2013-02-28 14:42 UTC (permalink / raw)
To: linux-kernel, stable, kernel-team
Cc: Luis Henriques, linuxppc-dev, Suzuki K. Poulose
In-Reply-To: <1362062689-2567-1-git-send-email-luis.henriques@canonical.com>
3.5.7.7 -stable review patch. If anyone has any objections, please let me know.
------------------
From: "Suzuki K. Poulose" <suzuki@in.ibm.com>
commit 5e249d4528528c9a77da051a89ec7f99d31b83eb upstream.
Uprobes uses emulate_step in sstep.c, but we haven't explicitly specified
the dependency. On pseries HAVE_HW_BREAKPOINT protects us, but 44x has no
such luxury.
Consolidate other users that depend on sstep and create a new config option.
Signed-off-by: Ananth N Mavinakayanahalli <ananth@in.ibm.com>
Signed-off-by: Suzuki K. Poulose <suzuki@in.ibm.com>
Cc: linuxppc-dev@ozlabs.org
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
[ luis: adjust context ]
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
---
arch/powerpc/Kconfig | 4 ++++
arch/powerpc/lib/Makefile | 4 +---
2 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 050cb37..4d8336c 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -264,6 +264,10 @@ config PPC_ADV_DEBUG_DAC_RANGE
depends on PPC_ADV_DEBUG_REGS && 44x
default y
+config PPC_EMULATE_SSTEP
+ bool
+ default y if KPROBES || UPROBES || XMON || HAVE_HW_BREAKPOINT
+
source "init/Kconfig"
source "kernel/Kconfig.freezer"
diff --git a/arch/powerpc/lib/Makefile b/arch/powerpc/lib/Makefile
index 7735a2c..3230bc1 100644
--- a/arch/powerpc/lib/Makefile
+++ b/arch/powerpc/lib/Makefile
@@ -18,9 +18,7 @@ obj-$(CONFIG_PPC64) += copypage_64.o copyuser_64.o \
memcpy_64.o usercopy_64.o mem_64.o string.o \
checksum_wrappers_64.o hweight_64.o \
copyuser_power7.o
-obj-$(CONFIG_XMON) += sstep.o ldstfp.o
-obj-$(CONFIG_KPROBES) += sstep.o ldstfp.o
-obj-$(CONFIG_HAVE_HW_BREAKPOINT) += sstep.o ldstfp.o
+obj-$(CONFIG_PPC_EMULATE_SSTEP) += sstep.o ldstfp.o
ifeq ($(CONFIG_PPC64),y)
obj-$(CONFIG_SMP) += locks.o
--
1.8.1.2
^ permalink raw reply related
* Re: [PATCH 2/6] powerpc/fsl_pci: Store the platform device information corresponding to the pci controller.
From: Kumar Gala @ 2013-02-28 15:45 UTC (permalink / raw)
To: Sethi Varun-B16395
Cc: Wood Scott-B07421, Stuart Yoder, Joerg Roedel,
linux-kernel@vger.kernel.org, Yoder Stuart-B08248,
iommu@lists.linux-foundation.org, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <C5ECD7A89D1DC44195F34B25E172658D3C24A9@039-SN2MPN1-013.039d.mgd.msft.net>
On Feb 27, 2013, at 4:56 AM, Sethi Varun-B16395 wrote:
> This patch is present in the "next branch" of linux ppc tree =
maintained by Kumar Gala.
> Following is the commit id:
> 52c5affc545053d37c0b05224bbf70f5336caa20
>=20
> I am not sure if this would be part of 3.9-rc1.
>=20
> Regards
> varun
This is now in Linus's tree so will be in 3.9-rc1
- k
^ permalink raw reply
* Re: [PATCH 3/6] powerpc/fsl_pci: Added defines for the FSL PCI controller BRR1 register.
From: Kumar Gala @ 2013-02-28 15:46 UTC (permalink / raw)
To: Joerg Roedel
Cc: linux-kernel, stuart.yoder, iommu, scottwood, Varun Sethi,
linuxppc-dev
In-Reply-To: <20130227113336.GI26252@8bytes.org>
On Feb 27, 2013, at 5:33 AM, Joerg Roedel wrote:
> On Mon, Feb 18, 2013 at 06:22:16PM +0530, Varun Sethi wrote:
>> Macros for checking FSL PCI controller version.
>>=20
>> Signed-off-by: Varun Sethi <Varun.Sethi@freescale.com>
>> ---
>> arch/powerpc/include/asm/pci-bridge.h | 4 ++++
>> 1 files changed, 4 insertions(+), 0 deletions(-)
>>=20
>> diff --git a/arch/powerpc/include/asm/pci-bridge.h =
b/arch/powerpc/include/asm/pci-bridge.h
>> index 025a130..c12ed78 100644
>> --- a/arch/powerpc/include/asm/pci-bridge.h
>> +++ b/arch/powerpc/include/asm/pci-bridge.h
>> @@ -14,6 +14,10 @@
>>=20
>> struct device_node;
>>=20
>> +/* FSL PCI controller BRR1 register */
>> +#define PCI_FSL_BRR1 0xbf8
>> +#define PCI_FSL_BRR1_VER 0xffff
>> +
>=20
>=20
> Please merge this patch with the one where you actually make use of
> these defines for the first time.
>=20
>=20
> Joerg
This also seems an odd place for these defines.
- k=
^ permalink raw reply
* Re: [PATCH 1/6 v8] iommu/fsl: Store iommu domain information pointer in archdata.
From: Kumar Gala @ 2013-02-28 15:51 UTC (permalink / raw)
To: Sethi Varun-B16395
Cc: Wood Scott-B07421, Alexey Kardashevskiy, Joerg Roedel,
linux-kernel@vger.kernel.org list, Yoder Stuart-B08248, iommu,
Paul Mackerras, linuxppc-dev@lists.ozlabs.org list
In-Reply-To: <C5ECD7A89D1DC44195F34B25E172658D3C26F6@039-SN2MPN1-013.039d.mgd.msft.net>
On Feb 27, 2013, at 6:04 AM, Sethi Varun-B16395 wrote:
> Hi Kumar,Ben,
> I am implementing the Freescale PAMU (IOMMU) driver using the Linux =
IOMMU API. In this particular patch, I have added a new field to =
dev_archdata structure to store the dma domain information.
> This field is updated whenever we attach a device to an iommu domain.
>=20
> Regards
> Varun
Would be good to see if this overlaps with Alexey's work for IOMMU =
driver for powernv.
- k
>=20
>> -----Original Message-----
>> From: Joerg Roedel [mailto:joro@8bytes.org]
>> Sent: Wednesday, February 27, 2013 5:01 PM
>> To: Sethi Varun-B16395
>> Cc: iommu@lists.linux-foundation.org; linuxppc-dev@lists.ozlabs.org;
>> linux-kernel@vger.kernel.org; Wood Scott-B07421; Yoder Stuart-B08248
>> Subject: Re: [PATCH 1/6 v8] iommu/fsl: Store iommu domain information
>> pointer in archdata.
>>=20
>> On Mon, Feb 18, 2013 at 06:22:14PM +0530, Varun Sethi wrote:
>>> Add a new field in the device (powerpc) archdata structure for =
storing
>>> iommu domain information pointer. This pointer is stored when the
>>> device is attached to a particular domain.
>>>=20
>>>=20
>>> Signed-off-by: Varun Sethi <Varun.Sethi@freescale.com>
>>> ---
>>> - no change.
>>> arch/powerpc/include/asm/device.h | 4 ++++
>>> 1 files changed, 4 insertions(+), 0 deletions(-)
>>>=20
>>> diff --git a/arch/powerpc/include/asm/device.h
>>> b/arch/powerpc/include/asm/device.h
>>> index 77e97dd..6dc79fe 100644
>>> --- a/arch/powerpc/include/asm/device.h
>>> +++ b/arch/powerpc/include/asm/device.h
>>> @@ -28,6 +28,10 @@ struct dev_archdata {
>>> void *iommu_table_base;
>>> } dma_data;
>>>=20
>>> + /* IOMMU domain information pointer. This would be set
>>> + * when this device is attached to an iommu_domain.
>>> + */
>>> + void *iommu_domain;
>>=20
>> Please Cc the PowerPC Maintainers on this, so that they can have a =
look
>> at it. This also must be put this into an #ifdef CONFIG_IOMMU_API.
>>=20
>>=20
>> Joerg
>>=20
>>=20
>=20
>=20
> --
> To unsubscribe from this list: send the line "unsubscribe =
linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply
* Re: [PATCH v6 04/46] percpu_rwlock: Implement the core design of Per-CPU Reader-Writer Locks
From: Oleg Nesterov @ 2013-02-28 18:00 UTC (permalink / raw)
To: Michel Lespinasse
Cc: Lai Jiangshan, linux-doc, peterz, fweisbec, mingo, linux-arch,
linux, xiaoguangrong, wangyun, paulmck, nikunj, linux-pm, rusty,
rostedt, rjw, namhyung, tglx, linux-arm-kernel, netdev,
linux-kernel, vincent.guittot, sbw, Srivatsa S. Bhat, tj, akpm,
linuxppc-dev
In-Reply-To: <CANN689EhqoQAKALR7WhT3YrQh3=VDA2Dq3QX1yLuYU_gZAo_Tg@mail.gmail.com>
On 02/28, Michel Lespinasse wrote:
>
> On Thu, Feb 28, 2013 at 3:25 AM, Oleg Nesterov <oleg@redhat.com> wrote:
> > On 02/27, Michel Lespinasse wrote:
> >>
> >> +void lg_rwlock_local_read_lock(struct lgrwlock *lgrw)
> >> +{
> >> + preempt_disable();
> >> +
> >> + if (__this_cpu_read(*lgrw->local_refcnt) ||
> >> + arch_spin_trylock(this_cpu_ptr(lgrw->lglock->lock))) {
> >> + __this_cpu_inc(*lgrw->local_refcnt);
> >
> > Please look at __this_cpu_generic_to_op(). You need this_cpu_inc()
> > to avoid the race with irs. The same for _read_unlock.
>
> Hmmm, I was thinking that this was safe because while interrupts might
> modify local_refcnt to acquire a nested read lock, they are expected
> to release that lock as well which would set local_refcnt back to its
> original value ???
Yes, yes, this is correct.
I meant that (in general, x86 is fine) __this_cpu_inc() itself is not
irq-safe. It simply does "pcp += 1".
this_cpu_inc() is fine, _this_cpu_generic_to_op() does cli/sti around.
I know this only because I did the same mistake recently, and Srivatsa
explained the problem to me ;)
Oleg.
^ permalink raw reply
* Re: [PATCH v6 04/46] percpu_rwlock: Implement the core design of Per-CPU Reader-Writer Locks
From: Oleg Nesterov @ 2013-02-28 18:20 UTC (permalink / raw)
To: Michel Lespinasse
Cc: Lai Jiangshan, linux-doc, peterz, fweisbec, mingo, linux-arch,
linux, xiaoguangrong, wangyun, paulmck, nikunj, linux-pm, rusty,
rostedt, rjw, namhyung, tglx, linux-arm-kernel, netdev,
linux-kernel, vincent.guittot, sbw, Srivatsa S. Bhat, tj, akpm,
linuxppc-dev
In-Reply-To: <20130228180007.GA3537@redhat.com>
On 02/28, Oleg Nesterov wrote:
> On 02/28, Michel Lespinasse wrote:
> >
> > On Thu, Feb 28, 2013 at 3:25 AM, Oleg Nesterov <oleg@redhat.com> wrote:
> > > On 02/27, Michel Lespinasse wrote:
> > >>
> > >> +void lg_rwlock_local_read_lock(struct lgrwlock *lgrw)
> > >> +{
> > >> + preempt_disable();
> > >> +
> > >> + if (__this_cpu_read(*lgrw->local_refcnt) ||
> > >> + arch_spin_trylock(this_cpu_ptr(lgrw->lglock->lock))) {
> > >> + __this_cpu_inc(*lgrw->local_refcnt);
> > >
> > > Please look at __this_cpu_generic_to_op(). You need this_cpu_inc()
> > > to avoid the race with irs. The same for _read_unlock.
> >
> > Hmmm, I was thinking that this was safe because while interrupts might
> > modify local_refcnt to acquire a nested read lock, they are expected
> > to release that lock as well which would set local_refcnt back to its
> > original value ???
>
> Yes, yes, this is correct.
>
> I meant that (in general, x86 is fine) __this_cpu_inc() itself is not
> irq-safe. It simply does "pcp += 1".
>
> this_cpu_inc() is fine, _this_cpu_generic_to_op() does cli/sti around.
Just in case, it is not that I really understand why __this_cpu_inc() can
race with irq in this particular case (given that irq handler should
restore the counter).
So perhaps I am wrong again. The comments in include/linux/percpu.h look
confusing to me, and I simply know nothing about !x86 architectures. But
since, say, preempt_disable() doesn't do anything special then probably
__this_cpu_inc() is fine too.
In short: please ignore me ;)
Oleg.
^ permalink raw reply
* Re: [PATCH 1/6 v8] iommu/fsl: Store iommu domain information pointer in archdata.
From: Alexey Kardashevskiy @ 2013-03-01 1:24 UTC (permalink / raw)
To: Kumar Gala
Cc: Wood Scott-B07421, Alex Williamson, Joerg Roedel,
linux-kernel@vger.kernel.org list, Yoder Stuart-B08248, iommu,
Paul Mackerras, Sethi Varun-B16395,
linuxppc-dev@lists.ozlabs.org list, David Gibson
In-Reply-To: <BAB98EA5-5324-4FB2-97C2-A28A96C569DC@kernel.crashing.org>
Hi!
On POWERNV we use only the part of IOMMU API which handles devices and
groups. We do not use IOMMU domains as VFIO containers do everything we
need for VFIO and we do not implement iommu_ops as it is not very relevant
to our architecture (does not give dma window properties, etc).
So your work does not overlap with my work :)
On 01/03/13 02:51, Kumar Gala wrote:
>
> On Feb 27, 2013, at 6:04 AM, Sethi Varun-B16395 wrote:
>
>> Hi Kumar,Ben,
>> I am implementing the Freescale PAMU (IOMMU) driver using the Linux IOMMU API. In this particular patch, I have added a new field to dev_archdata structure to store the dma domain information.
>> This field is updated whenever we attach a device to an iommu domain.
>>
>> Regards
>> Varun
>
> Would be good to see if this overlaps with Alexey's work for IOMMU driver for powernv.
>
> - k
>
>>
>>> -----Original Message-----
>>> From: Joerg Roedel [mailto:joro@8bytes.org]
>>> Sent: Wednesday, February 27, 2013 5:01 PM
>>> To: Sethi Varun-B16395
>>> Cc: iommu@lists.linux-foundation.org; linuxppc-dev@lists.ozlabs.org;
>>> linux-kernel@vger.kernel.org; Wood Scott-B07421; Yoder Stuart-B08248
>>> Subject: Re: [PATCH 1/6 v8] iommu/fsl: Store iommu domain information
>>> pointer in archdata.
>>>
>>> On Mon, Feb 18, 2013 at 06:22:14PM +0530, Varun Sethi wrote:
>>>> Add a new field in the device (powerpc) archdata structure for storing
>>>> iommu domain information pointer. This pointer is stored when the
>>>> device is attached to a particular domain.
>>>>
>>>>
>>>> Signed-off-by: Varun Sethi <Varun.Sethi@freescale.com>
>>>> ---
>>>> - no change.
>>>> arch/powerpc/include/asm/device.h | 4 ++++
>>>> 1 files changed, 4 insertions(+), 0 deletions(-)
>>>>
>>>> diff --git a/arch/powerpc/include/asm/device.h
>>>> b/arch/powerpc/include/asm/device.h
>>>> index 77e97dd..6dc79fe 100644
>>>> --- a/arch/powerpc/include/asm/device.h
>>>> +++ b/arch/powerpc/include/asm/device.h
>>>> @@ -28,6 +28,10 @@ struct dev_archdata {
>>>> void *iommu_table_base;
>>>> } dma_data;
>>>>
>>>> + /* IOMMU domain information pointer. This would be set
>>>> + * when this device is attached to an iommu_domain.
>>>> + */
>>>> + void *iommu_domain;
>>>
>>> Please Cc the PowerPC Maintainers on this, so that they can have a look
>>> at it. This also must be put this into an #ifdef CONFIG_IOMMU_API.
--
Alexey
^ permalink raw reply
* Re: [PATCH 0/3] Enable multiple MSI feature in pSeries
From: Mike @ 2013-03-01 3:08 UTC (permalink / raw)
To: linuxppc-dev; +Cc: tglx, linux-kernel
In-Reply-To: <1358235536-32741-1-git-send-email-qiudayu@linux.vnet.ibm.com>
Hi all
Any comments? or any questions about my patchset?
Thanks
Mike
在 2013-01-15二的 15:38 +0800，Mike Qiu写道：
> Currently, multiple MSI feature hasn't been enabled in pSeries,
> These patches try to enbale this feature.
>
> These patches have been tested by using ipr driver, and the driver patch
> has been made by Wen Xiong <wenxiong@linux.vnet.ibm.com>:
>
> [PATCH 0/7] Add support for new IBM SAS controllers
>
> Test platform: One partition of pSeries with one cpu core(4 SMTs) and
> RAID bus controller: IBM PCI-E IPR SAS Adapter (ASIC) in POWER7
> OS version: SUSE Linux Enterprise Server 11 SP2 (ppc64) with 3.8-rc3 kernel
>
> IRQ 21 and 22 are assigned to the ipr device which support 2 mutiple MSI.
>
> The test results is shown by 'cat /proc/interrups':
> CPU0 CPU1 CPU2 CPU3
> 16: 240458 261601 226310 200425 XICS Level IPI
> 17: 0 0 0 0 XICS Level RAS_EPOW
> 18: 10 0 3 2 XICS Level hvc_console
> 19: 122182 28481 28527 28864 XICS Level ibmvscsi
> 20: 506 7388226 108 118 XICS Level eth0
> 21: 6 5 5 5 XICS Level host1-0
> 22: 817 814 816 813 XICS Level host1-1
> LOC: 398077 316725 231882 203049 Local timer interrupts
> SPU: 1659 919 961 903 Spurious interrupts
> CNT: 0 0 0 0 Performance
> monitoring interrupts
> MCE: 0 0 0 0 Machine check exceptions
>
> Mike Qiu (3):
> irq: Set multiple MSI descriptor data for multiple IRQs
> irq: Add hw continuous IRQs map to virtual continuous IRQs support
> powerpc/pci: Enable pSeries multiple MSI feature
>
> arch/powerpc/kernel/msi.c | 4 --
> arch/powerpc/platforms/pseries/msi.c | 62 ++++++++++++++++++++++++++++++++-
> include/linux/irq.h | 4 ++
> include/linux/irqdomain.h | 3 ++
> kernel/irq/chip.c | 40 ++++++++++++++++-----
> kernel/irq/irqdomain.c | 61 +++++++++++++++++++++++++++++++++
> 6 files changed, 158 insertions(+), 16 deletions(-)
>
^ permalink raw reply
* Re: [PATCH 0/3] Enable multiple MSI feature in pSeries
From: Michael Ellerman @ 2013-03-01 3:54 UTC (permalink / raw)
To: Mike; +Cc: tglx, linuxppc-dev, linux-kernel
In-Reply-To: <1362107325.2712.2.camel@localhost>
On Fri, Mar 01, 2013 at 11:08:45AM +0800, Mike wrote:
> Hi all
>
> Any comments? or any questions about my patchset?
You were going to get some performance numbers that show a definite
benefit for using more than one MSI.
cheers
^ permalink raw reply
* RE: [PATCH 1/6 v8] iommu/fsl: Store iommu domain information pointer in archdata.
From: Sethi Varun-B16395 @ 2013-03-01 8:55 UTC (permalink / raw)
To: Alexey Kardashevskiy, Kumar Gala
Cc: Wood Scott-B07421, Alex Williamson, Joerg Roedel,
linux-kernel@vger.kernel.org list, Yoder Stuart-B08248,
iommu@lists.linux-foundation.org, Paul Mackerras,
linuxppc-dev@lists.ozlabs.org list, David Gibson
In-Reply-To: <51300367.6080300@ozlabs.ru>
Thanks for the clarification Alexey.
Kumar,
We are using this new field (for PAMU) to store the iommu domain (for iommu=
API) information for a device.
Regards
Varun
> -----Original Message-----
> From: Alexey Kardashevskiy [mailto:aik@ozlabs.ru]
> Sent: Friday, March 01, 2013 6:55 AM
> To: Kumar Gala
> Cc: Sethi Varun-B16395; Benjamin Herrenschmidt; iommu@lists.linux-
> foundation.org; linuxppc-dev@lists.ozlabs.org list; linux-
> kernel@vger.kernel.org list; Wood Scott-B07421; Yoder Stuart-B08248;
> Joerg Roedel; Paul Mackerras; David Gibson; Alex Williamson
> Subject: Re: [PATCH 1/6 v8] iommu/fsl: Store iommu domain information
> pointer in archdata.
>=20
> Hi!
>=20
> On POWERNV we use only the part of IOMMU API which handles devices and
> groups. We do not use IOMMU domains as VFIO containers do everything we
> need for VFIO and we do not implement iommu_ops as it is not very
> relevant to our architecture (does not give dma window properties, etc).
>=20
> So your work does not overlap with my work :)
>=20
>=20
> On 01/03/13 02:51, Kumar Gala wrote:
> >
> > On Feb 27, 2013, at 6:04 AM, Sethi Varun-B16395 wrote:
> >
> >> Hi Kumar,Ben,
> >> I am implementing the Freescale PAMU (IOMMU) driver using the Linux
> IOMMU API. In this particular patch, I have added a new field to
> dev_archdata structure to store the dma domain information.
> >> This field is updated whenever we attach a device to an iommu domain.
> >>
> >> Regards
> >> Varun
> >
> > Would be good to see if this overlaps with Alexey's work for IOMMU
> driver for powernv.
> >
> > - k
> >
> >>
> >>> -----Original Message-----
> >>> From: Joerg Roedel [mailto:joro@8bytes.org]
> >>> Sent: Wednesday, February 27, 2013 5:01 PM
> >>> To: Sethi Varun-B16395
> >>> Cc: iommu@lists.linux-foundation.org; linuxppc-dev@lists.ozlabs.org;
> >>> linux-kernel@vger.kernel.org; Wood Scott-B07421; Yoder Stuart-B08248
> >>> Subject: Re: [PATCH 1/6 v8] iommu/fsl: Store iommu domain
> >>> information pointer in archdata.
> >>>
> >>> On Mon, Feb 18, 2013 at 06:22:14PM +0530, Varun Sethi wrote:
> >>>> Add a new field in the device (powerpc) archdata structure for
> >>>> storing iommu domain information pointer. This pointer is stored
> >>>> when the device is attached to a particular domain.
> >>>>
> >>>>
> >>>> Signed-off-by: Varun Sethi <Varun.Sethi@freescale.com>
> >>>> ---
> >>>> - no change.
> >>>> arch/powerpc/include/asm/device.h | 4 ++++
> >>>> 1 files changed, 4 insertions(+), 0 deletions(-)
> >>>>
> >>>> diff --git a/arch/powerpc/include/asm/device.h
> >>>> b/arch/powerpc/include/asm/device.h
> >>>> index 77e97dd..6dc79fe 100644
> >>>> --- a/arch/powerpc/include/asm/device.h
> >>>> +++ b/arch/powerpc/include/asm/device.h
> >>>> @@ -28,6 +28,10 @@ struct dev_archdata {
> >>>> void *iommu_table_base;
> >>>> } dma_data;
> >>>>
> >>>> + /* IOMMU domain information pointer. This would be set
> >>>> + * when this device is attached to an iommu_domain.
> >>>> + */
> >>>> + void *iommu_domain;
> >>>
> >>> Please Cc the PowerPC Maintainers on this, so that they can have a
> >>> look at it. This also must be put this into an #ifdef
> CONFIG_IOMMU_API.
>=20
>=20
> --
> Alexey
^ permalink raw reply
* Re: [PATCH 1/6 v8] iommu/fsl: Store iommu domain information pointer in archdata.
From: Alexey Kardashevskiy @ 2013-03-01 10:07 UTC (permalink / raw)
To: Sethi Varun-B16395
Cc: Wood Scott-B07421, Alex Williamson, Joerg Roedel,
linux-kernel@vger.kernel.org list, Yoder Stuart-B08248,
iommu@lists.linux-foundation.org, Paul Mackerras,
linuxppc-dev@lists.ozlabs.org list, David Gibson
In-Reply-To: <C5ECD7A89D1DC44195F34B25E172658D3C802F@039-SN2MPN1-013.039d.mgd.msft.net>
btw the device struct already has a pointer to its iommu_group, and the
iommu_group struct itself has a pointer void *iommu_data which you could
use for anything you want (iommu_group_get_iommudata(),
iommu_group_set_iommudata()).
By design you are expected to add iommu groups to a domain but not devices
so I am not so sure that you really need a pointer to domain in the device
struct.
On 01/03/13 19:55, Sethi Varun-B16395 wrote:
> Thanks for the clarification Alexey.
>
> Kumar,
> We are using this new field (for PAMU) to store the iommu domain (for iommu API) information for a device.
>
> Regards
> Varun
>
>> -----Original Message-----
>> From: Alexey Kardashevskiy [mailto:aik@ozlabs.ru]
>> Sent: Friday, March 01, 2013 6:55 AM
>> To: Kumar Gala
>> Cc: Sethi Varun-B16395; Benjamin Herrenschmidt; iommu@lists.linux-
>> foundation.org; linuxppc-dev@lists.ozlabs.org list; linux-
>> kernel@vger.kernel.org list; Wood Scott-B07421; Yoder Stuart-B08248;
>> Joerg Roedel; Paul Mackerras; David Gibson; Alex Williamson
>> Subject: Re: [PATCH 1/6 v8] iommu/fsl: Store iommu domain information
>> pointer in archdata.
>>
>> Hi!
>>
>> On POWERNV we use only the part of IOMMU API which handles devices and
>> groups. We do not use IOMMU domains as VFIO containers do everything we
>> need for VFIO and we do not implement iommu_ops as it is not very
>> relevant to our architecture (does not give dma window properties, etc).
>>
>> So your work does not overlap with my work :)
>>
>>
>> On 01/03/13 02:51, Kumar Gala wrote:
>>>
>>> On Feb 27, 2013, at 6:04 AM, Sethi Varun-B16395 wrote:
>>>
>>>> Hi Kumar,Ben,
>>>> I am implementing the Freescale PAMU (IOMMU) driver using the Linux
>> IOMMU API. In this particular patch, I have added a new field to
>> dev_archdata structure to store the dma domain information.
>>>> This field is updated whenever we attach a device to an iommu domain.
>>>>
>>>> Regards
>>>> Varun
>>>
>>> Would be good to see if this overlaps with Alexey's work for IOMMU
>> driver for powernv.
>>>
>>> - k
>>>
>>>>
>>>>> -----Original Message-----
>>>>> From: Joerg Roedel [mailto:joro@8bytes.org]
>>>>> Sent: Wednesday, February 27, 2013 5:01 PM
>>>>> To: Sethi Varun-B16395
>>>>> Cc: iommu@lists.linux-foundation.org; linuxppc-dev@lists.ozlabs.org;
>>>>> linux-kernel@vger.kernel.org; Wood Scott-B07421; Yoder Stuart-B08248
>>>>> Subject: Re: [PATCH 1/6 v8] iommu/fsl: Store iommu domain
>>>>> information pointer in archdata.
>>>>>
>>>>> On Mon, Feb 18, 2013 at 06:22:14PM +0530, Varun Sethi wrote:
>>>>>> Add a new field in the device (powerpc) archdata structure for
>>>>>> storing iommu domain information pointer. This pointer is stored
>>>>>> when the device is attached to a particular domain.
>>>>>>
>>>>>>
>>>>>> Signed-off-by: Varun Sethi <Varun.Sethi@freescale.com>
>>>>>> ---
>>>>>> - no change.
>>>>>> arch/powerpc/include/asm/device.h | 4 ++++
>>>>>> 1 files changed, 4 insertions(+), 0 deletions(-)
>>>>>>
>>>>>> diff --git a/arch/powerpc/include/asm/device.h
>>>>>> b/arch/powerpc/include/asm/device.h
>>>>>> index 77e97dd..6dc79fe 100644
>>>>>> --- a/arch/powerpc/include/asm/device.h
>>>>>> +++ b/arch/powerpc/include/asm/device.h
>>>>>> @@ -28,6 +28,10 @@ struct dev_archdata {
>>>>>> void *iommu_table_base;
>>>>>> } dma_data;
>>>>>>
>>>>>> + /* IOMMU domain information pointer. This would be set
>>>>>> + * when this device is attached to an iommu_domain.
>>>>>> + */
>>>>>> + void *iommu_domain;
>>>>>
>>>>> Please Cc the PowerPC Maintainers on this, so that they can have a
>>>>> look at it. This also must be put this into an #ifdef
>> CONFIG_IOMMU_API.
--
Alexey
^ permalink raw reply
* Re: [PATCH v6 00/46] CPU hotplug: stop_machine()-free CPU hotplug
From: Vincent Guittot @ 2013-03-01 12:05 UTC (permalink / raw)
To: Srivatsa S. Bhat
Cc: linux-doc, peterz, fweisbec, linux-kernel, walken, mingo,
linux-arch, linux, xiaoguangrong, wangyun, paulmck, nikunj,
linux-pm, rusty, rostedt, rjw, namhyung, tglx, linux-arm-kernel,
netdev, oleg, sbw, tj, akpm, linuxppc-dev
In-Reply-To: <20130218123714.26245.61816.stgit@srivatsabhat.in.ibm.com>
Hi Srivatsa,
I have run some tests with genload on my ARM platform but even with
the mainline the cpu_down is quite short and stable ( around 4ms )
with 5 or 2 online cores. The duration is similar with your patches
I have maybe not used the right option for genload ? I have used
genload -m 10 which seems to generate the most system time. Which
command have you used for your tests ?
Vincent
On 18 February 2013 13:38, Srivatsa S. Bhat
<srivatsa.bhat@linux.vnet.ibm.com> wrote:
> Hi,
>
> This patchset removes CPU hotplug's dependence on stop_machine() from the CPU
> offline path and provides an alternative (set of APIs) to preempt_disable() to
> prevent CPUs from going offline, which can be invoked from atomic context.
> The motivation behind the removal of stop_machine() is to avoid its ill-effects
> and thus improve the design of CPU hotplug. (More description regarding this
> is available in the patches).
>
> All the users of preempt_disable()/local_irq_disable() who used to use it to
> prevent CPU offline, have been converted to the new primitives introduced in the
> patchset. Also, the CPU_DYING notifiers have been audited to check whether
> they can cope up with the removal of stop_machine() or whether they need to
> use new locks for synchronization (all CPU_DYING notifiers looked OK, without
> the need for any new locks).
>
> Applies on current mainline (v3.8-rc7+).
>
> This patchset is available in the following git branch:
>
> git://github.com/srivatsabhat/linux.git stop-machine-free-cpu-hotplug-v6
>
>
> Overview of the patches:
> -----------------------
>
> Patches 1 to 7 introduce a generic, flexible Per-CPU Reader-Writer Locking
> scheme.
>
> Patch 8 uses this synchronization mechanism to build the
> get/put_online_cpus_atomic() APIs which can be used from atomic context, to
> prevent CPUs from going offline.
>
> Patch 9 is a cleanup; it converts preprocessor macros to static inline
> functions.
>
> Patches 10 to 43 convert various call-sites to use the new APIs.
>
> Patch 44 is the one which actually removes stop_machine() from the CPU
> offline path.
>
> Patch 45 decouples stop_machine() and CPU hotplug from Kconfig.
>
> Patch 46 updates the documentation to reflect the new APIs.
>
>
> Changes in v6:
> --------------
>
> * Fixed issues related to memory barriers, as pointed out by Paul and Oleg.
> * Fixed the locking issue related to clockevents_lock, which was being
> triggered when cpu idle was enabled.
> * Some code restructuring to improve readability and to enhance some fastpath
> optimizations.
> * Randconfig build-fixes, reported by Fengguang Wu.
>
>
> Changes in v5:
> --------------
> Exposed a new generic locking scheme: Flexible Per-CPU Reader-Writer locks,
> based on the synchronization schemes already discussed in the previous
> versions, and used it in CPU hotplug, to implement the new APIs.
>
> Audited the CPU_DYING notifiers in the kernel source tree and replaced
> usages of preempt_disable() with the new get/put_online_cpus_atomic() APIs
> where necessary.
>
>
> Changes in v4:
> --------------
> The synchronization scheme has been simplified quite a bit, which makes it
> look a lot less complex than before. Some highlights:
>
> * Implicit ACKs:
>
> The earlier design required the readers to explicitly ACK the writer's
> signal. The new design uses implicit ACKs instead. The reader switching
> over to rwlock implicitly tells the writer to stop waiting for that reader.
>
> * No atomic operations:
>
> Since we got rid of explicit ACKs, we no longer have the need for a reader
> and a writer to update the same counter. So we can get rid of atomic ops
> too.
>
> Changes in v3:
> --------------
> * Dropped the _light() and _full() variants of the APIs. Provided a single
> interface: get/put_online_cpus_atomic().
>
> * Completely redesigned the synchronization mechanism again, to make it
> fast and scalable at the reader-side in the fast-path (when no hotplug
> writers are active). This new scheme also ensures that there is no
> possibility of deadlocks due to circular locking dependency.
> In summary, this provides the scalability and speed of per-cpu rwlocks
> (without actually using them), while avoiding the downside (deadlock
> possibilities) which is inherent in any per-cpu locking scheme that is
> meant to compete with preempt_disable()/enable() in terms of flexibility.
>
> The problem with using per-cpu locking to replace preempt_disable()/enable
> was explained here:
> https://lkml.org/lkml/2012/12/6/290
>
> Basically we use per-cpu counters (for scalability) when no writers are
> active, and then switch to global rwlocks (for lock-safety) when a writer
> becomes active. It is a slightly complex scheme, but it is based on
> standard principles of distributed algorithms.
>
> Changes in v2:
> -------------
> * Completely redesigned the synchronization scheme to avoid using any extra
> cpumasks.
>
> * Provided APIs for 2 types of atomic hotplug readers: "light" (for
> light-weight) and "full". We wish to have more "light" readers than
> the "full" ones, to avoid indirectly inducing the "stop_machine effect"
> without even actually using stop_machine().
>
> And the patches show that it _is_ generally true: 5 patches deal with
> "light" readers, whereas only 1 patch deals with a "full" reader.
>
> Also, the "light" readers happen to be in very hot paths. So it makes a
> lot of sense to have such a distinction and a corresponding light-weight
> API.
>
> Links to previous versions:
> v5: http://lwn.net/Articles/533553/
> v4: https://lkml.org/lkml/2012/12/11/209
> v3: https://lkml.org/lkml/2012/12/7/287
> v2: https://lkml.org/lkml/2012/12/5/322
> v1: https://lkml.org/lkml/2012/12/4/88
>
> --
> Paul E. McKenney (1):
> cpu: No more __stop_machine() in _cpu_down()
>
> Srivatsa S. Bhat (45):
> percpu_rwlock: Introduce the global reader-writer lock backend
> percpu_rwlock: Introduce per-CPU variables for the reader and the writer
> percpu_rwlock: Provide a way to define and init percpu-rwlocks at compile time
> percpu_rwlock: Implement the core design of Per-CPU Reader-Writer Locks
> percpu_rwlock: Make percpu-rwlocks IRQ-safe, optimally
> percpu_rwlock: Rearrange the read-lock code to fastpath nested percpu readers
> percpu_rwlock: Allow writers to be readers, and add lockdep annotations
> CPU hotplug: Provide APIs to prevent CPU offline from atomic context
> CPU hotplug: Convert preprocessor macros to static inline functions
> smp, cpu hotplug: Fix smp_call_function_*() to prevent CPU offline properly
> smp, cpu hotplug: Fix on_each_cpu_*() to prevent CPU offline properly
> sched/timer: Use get/put_online_cpus_atomic() to prevent CPU offline
> sched/migration: Use raw_spin_lock/unlock since interrupts are already disabled
> sched/rt: Use get/put_online_cpus_atomic() to prevent CPU offline
> tick: Use get/put_online_cpus_atomic() to prevent CPU offline
> time/clocksource: Use get/put_online_cpus_atomic() to prevent CPU offline
> clockevents: Use get/put_online_cpus_atomic() in clockevents_notify()
> softirq: Use get/put_online_cpus_atomic() to prevent CPU offline
> irq: Use get/put_online_cpus_atomic() to prevent CPU offline
> net: Use get/put_online_cpus_atomic() to prevent CPU offline
> block: Use get/put_online_cpus_atomic() to prevent CPU offline
> crypto: pcrypt - Protect access to cpu_online_mask with get/put_online_cpus()
> infiniband: ehca: Use get/put_online_cpus_atomic() to prevent CPU offline
> [SCSI] fcoe: Use get/put_online_cpus_atomic() to prevent CPU offline
> staging: octeon: Use get/put_online_cpus_atomic() to prevent CPU offline
> x86: Use get/put_online_cpus_atomic() to prevent CPU offline
> perf/x86: Use get/put_online_cpus_atomic() to prevent CPU offline
> KVM: Use get/put_online_cpus_atomic() to prevent CPU offline from atomic context
> kvm/vmx: Use get/put_online_cpus_atomic() to prevent CPU offline
> x86/xen: Use get/put_online_cpus_atomic() to prevent CPU offline
> alpha/smp: Use get/put_online_cpus_atomic() to prevent CPU offline
> blackfin/smp: Use get/put_online_cpus_atomic() to prevent CPU offline
> cris/smp: Use get/put_online_cpus_atomic() to prevent CPU offline
> hexagon/smp: Use get/put_online_cpus_atomic() to prevent CPU offline
> ia64: Use get/put_online_cpus_atomic() to prevent CPU offline
> m32r: Use get/put_online_cpus_atomic() to prevent CPU offline
> MIPS: Use get/put_online_cpus_atomic() to prevent CPU offline
> mn10300: Use get/put_online_cpus_atomic() to prevent CPU offline
> parisc: Use get/put_online_cpus_atomic() to prevent CPU offline
> powerpc: Use get/put_online_cpus_atomic() to prevent CPU offline
> sh: Use get/put_online_cpus_atomic() to prevent CPU offline
> sparc: Use get/put_online_cpus_atomic() to prevent CPU offline
> tile: Use get/put_online_cpus_atomic() to prevent CPU offline
> CPU hotplug, stop_machine: Decouple CPU hotplug from stop_machine() in Kconfig
> Documentation/cpu-hotplug: Remove references to stop_machine()
>
> Documentation/cpu-hotplug.txt | 17 +-
> arch/alpha/kernel/smp.c | 19 +-
> arch/arm/Kconfig | 1
> arch/blackfin/Kconfig | 1
> arch/blackfin/mach-common/smp.c | 6 -
> arch/cris/arch-v32/kernel/smp.c | 8 +
> arch/hexagon/kernel/smp.c | 5
> arch/ia64/Kconfig | 1
> arch/ia64/kernel/irq_ia64.c | 13 +
> arch/ia64/kernel/perfmon.c | 6 +
> arch/ia64/kernel/smp.c | 23 ++
> arch/ia64/mm/tlb.c | 6 -
> arch/m32r/kernel/smp.c | 12 +
> arch/mips/Kconfig | 1
> arch/mips/kernel/cevt-smtc.c | 8 +
> arch/mips/kernel/smp.c | 16 +-
> arch/mips/kernel/smtc.c | 3
> arch/mips/mm/c-octeon.c | 4
> arch/mn10300/Kconfig | 1
> arch/mn10300/kernel/smp.c | 2
> arch/mn10300/mm/cache-smp.c | 5
> arch/mn10300/mm/tlb-smp.c | 15 +
> arch/parisc/Kconfig | 1
> arch/parisc/kernel/smp.c | 4
> arch/powerpc/Kconfig | 1
> arch/powerpc/mm/mmu_context_nohash.c | 2
> arch/s390/Kconfig | 1
> arch/sh/Kconfig | 1
> arch/sh/kernel/smp.c | 12 +
> arch/sparc/Kconfig | 1
> arch/sparc/kernel/leon_smp.c | 2
> arch/sparc/kernel/smp_64.c | 9 -
> arch/sparc/kernel/sun4d_smp.c | 2
> arch/sparc/kernel/sun4m_smp.c | 3
> arch/tile/kernel/smp.c | 4
> arch/x86/Kconfig | 1
> arch/x86/include/asm/ipi.h | 5
> arch/x86/kernel/apic/apic_flat_64.c | 10 +
> arch/x86/kernel/apic/apic_numachip.c | 5
> arch/x86/kernel/apic/es7000_32.c | 5
> arch/x86/kernel/apic/io_apic.c | 7 -
> arch/x86/kernel/apic/ipi.c | 10 +
> arch/x86/kernel/apic/x2apic_cluster.c | 4
> arch/x86/kernel/apic/x2apic_uv_x.c | 4
> arch/x86/kernel/cpu/mcheck/therm_throt.c | 4
> arch/x86/kernel/cpu/perf_event_intel_uncore.c | 5
> arch/x86/kvm/vmx.c | 8 +
> arch/x86/mm/tlb.c | 14 +
> arch/x86/xen/mmu.c | 11 +
> arch/x86/xen/smp.c | 9 +
> block/blk-softirq.c | 4
> crypto/pcrypt.c | 4
> drivers/infiniband/hw/ehca/ehca_irq.c | 8 +
> drivers/scsi/fcoe/fcoe.c | 7 +
> drivers/staging/octeon/ethernet-rx.c | 3
> include/linux/cpu.h | 8 +
> include/linux/percpu-rwlock.h | 74 +++++++
> include/linux/stop_machine.h | 2
> init/Kconfig | 2
> kernel/cpu.c | 59 +++++-
> kernel/irq/manage.c | 7 +
> kernel/sched/core.c | 36 +++-
> kernel/sched/fair.c | 5
> kernel/sched/rt.c | 3
> kernel/smp.c | 65 ++++--
> kernel/softirq.c | 3
> kernel/time/clockevents.c | 3
> kernel/time/clocksource.c | 5
> kernel/time/tick-broadcast.c | 2
> kernel/timer.c | 2
> lib/Kconfig | 3
> lib/Makefile | 1
> lib/percpu-rwlock.c | 256 +++++++++++++++++++++++++
> net/core/dev.c | 9 +
> virt/kvm/kvm_main.c | 10 +
> 75 files changed, 776 insertions(+), 123 deletions(-)
> create mode 100644 include/linux/percpu-rwlock.h
> create mode 100644 lib/percpu-rwlock.c
>
>
>
> Regards,
> Srivatsa S. Bhat
> IBM Linux Technology Center
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pm" 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
* [PATCH 03/22] powerpc/eeh: Make eeh_phb_pe_get public
From: Gavin Shan @ 2013-03-01 14:17 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Gavin Shan
In-Reply-To: <1362147440-14096-1-git-send-email-shangw@linux.vnet.ibm.com>
While processing EEH event caused by interrupt sent from P7IOC,
we need function to retrieve the PE according to the indicated
PCI host controller (struct pci_controller).
The patch makes function eeh_phb_pe_get() public so that other
source files can call it.
Signed-off-by: Gavin Shan <shangw@linux.vnet.ibm.com>
---
arch/powerpc/include/asm/eeh.h | 1 +
arch/powerpc/platforms/pseries/eeh_pe.c | 2 +-
2 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/include/asm/eeh.h b/arch/powerpc/include/asm/eeh.h
index eeaeab6..4b48178 100644
--- a/arch/powerpc/include/asm/eeh.h
+++ b/arch/powerpc/include/asm/eeh.h
@@ -185,6 +185,7 @@ static inline void eeh_unlock(void)
typedef void *(*eeh_traverse_func)(void *data, void *flag);
typedef void *(*eeh_pci_traverse_func)(struct pci_dev *dev, void *flag);
int eeh_phb_pe_create(struct pci_controller *phb);
+struct eeh_pe *eeh_phb_pe_get(struct pci_controller *phb);
int eeh_add_to_parent_pe(struct eeh_dev *edev);
int eeh_rmv_from_parent_pe(struct eeh_dev *edev, int purge_pe);
void *eeh_pe_dev_traverse(struct eeh_pe *root,
diff --git a/arch/powerpc/platforms/pseries/eeh_pe.c b/arch/powerpc/platforms/pseries/eeh_pe.c
index fe43d1a..6e3eb43 100644
--- a/arch/powerpc/platforms/pseries/eeh_pe.c
+++ b/arch/powerpc/platforms/pseries/eeh_pe.c
@@ -95,7 +95,7 @@ int eeh_phb_pe_create(struct pci_controller *phb)
* hierarchy tree is composed of PHB PEs. The function is used
* to retrieve the corresponding PHB PE according to the given PHB.
*/
-static struct eeh_pe *eeh_phb_pe_get(struct pci_controller *phb)
+struct eeh_pe *eeh_phb_pe_get(struct pci_controller *phb)
{
struct eeh_pe *pe;
--
1.7.5.4
^ permalink raw reply related
* [PATCH 06/22] powerpc/eeh: Make eeh_init public
From: Gavin Shan @ 2013-03-01 14:17 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Gavin Shan
In-Reply-To: <1362147440-14096-1-git-send-email-shangw@linux.vnet.ibm.com>
For EEH on PowerNV platform, we will do EEH probe based on the
real PCI devices. The PCI devices are available after PCI probe.
So we have to call eeh_init() explicitly on PowerNV platform
after PCI probe.
The patch also enables eeh_init() to do EEH probe for PowerNV
platform.
Signed-off-by: Gavin Shan <shangw@linux.vnet.ibm.com>
---
arch/powerpc/include/asm/eeh.h | 6 ++++++
arch/powerpc/platforms/pseries/eeh.c | 23 +++++++++++++++++++++--
2 files changed, 27 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/include/asm/eeh.h b/arch/powerpc/include/asm/eeh.h
index 557d82a..1ff2aa9 100644
--- a/arch/powerpc/include/asm/eeh.h
+++ b/arch/powerpc/include/asm/eeh.h
@@ -199,6 +199,7 @@ void eeh_pci_dev_traverse(struct pci_bus *bus,
eeh_pci_traverse_func fn, void *flag);
void *eeh_dev_init(struct device_node *dn, void *data);
void eeh_dev_phb_init_dynamic(struct pci_controller *phb);
+int __init eeh_init(void);
int __init eeh_ops_register(struct eeh_ops *ops);
int __exit eeh_ops_unregister(const char *name);
unsigned long eeh_check_failure(const volatile void __iomem *token,
@@ -227,6 +228,11 @@ void eeh_remove_bus_device(struct pci_dev *, int);
#else /* !CONFIG_EEH */
+static inline int eeh_init(void)
+{
+ return 0;
+}
+
static inline void *eeh_dev_init(struct device_node *dn, void *data)
{
return NULL;
diff --git a/arch/powerpc/platforms/pseries/eeh.c b/arch/powerpc/platforms/pseries/eeh.c
index 6b73d6c..abe26f8 100644
--- a/arch/powerpc/platforms/pseries/eeh.c
+++ b/arch/powerpc/platforms/pseries/eeh.c
@@ -674,11 +674,21 @@ int __exit eeh_ops_unregister(const char *name)
* Even if force-off is set, the EEH hardware is still enabled, so that
* newer systems can boot.
*/
-static int __init eeh_init(void)
+int __init eeh_init(void)
{
struct pci_controller *hose, *tmp;
struct device_node *phb;
- int ret;
+ static int cnt = 0;
+ int ret = 0;
+
+ /*
+ * We have to delay the initialization on PowerNV after
+ * the PCI hierarchy tree has been built because the PEs
+ * are figured out based on PCI devices instead of device
+ * tree nodes
+ */
+ if (machine_is(powernv) && cnt++ <= 0)
+ return ret;
/* call platform initialization function */
if (!eeh_ops) {
@@ -700,6 +710,15 @@ static int __init eeh_init(void)
phb = hose->dn;
traverse_pci_devices(phb, eeh_ops->of_probe, NULL);
}
+ } else if (eeh_probe_mode_dev()) {
+ list_for_each_entry_safe(hose, tmp,
+ &hose_list, list_node) {
+ eeh_pci_dev_traverse(hose->bus, eeh_ops->dev_probe, NULL);
+ }
+ } else {
+ pr_warning("%s: Invalid probe mode %d\n",
+ __func__, eeh_probe_mode);
+ return -EINVAL;
}
if (eeh_subsystem_enabled)
--
1.7.5.4
^ permalink raw reply related
* [PATCH 05/22] powerpc/eeh: Trace PCI bus from PE
From: Gavin Shan @ 2013-03-01 14:17 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Gavin Shan
In-Reply-To: <1362147440-14096-1-git-send-email-shangw@linux.vnet.ibm.com>
There're several types of PEs can be supported for now: PHB, Bus
Device. For PCI bus dependent PE, tracing the corresponding PCI
bus from PE (struct eeh_pe) would make the code more efficient.
The patch also enables the retrieval of PCI bus based on the
PCI device dependent PE.
Signed-off-by: Gavin Shan <shangw@linux.vnet.ibm.com>
---
arch/powerpc/include/asm/eeh.h | 1 +
arch/powerpc/platforms/pseries/eeh_pe.c | 25 ++++++++++++++++++++++++-
2 files changed, 25 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/include/asm/eeh.h b/arch/powerpc/include/asm/eeh.h
index 9230aa4..557d82a 100644
--- a/arch/powerpc/include/asm/eeh.h
+++ b/arch/powerpc/include/asm/eeh.h
@@ -62,6 +62,7 @@ struct eeh_pe {
int check_count; /* Times of ignored error */
int freeze_count; /* Times of froze up */
int false_positives; /* Times of reported #ff's */
+ struct pci_bus *bus; /* Top PCI bus for bus PE */
struct eeh_pe *parent; /* Parent PE */
struct list_head child_list; /* Link PE to the child list */
struct list_head edevs; /* Link list of EEH devices */
diff --git a/arch/powerpc/platforms/pseries/eeh_pe.c b/arch/powerpc/platforms/pseries/eeh_pe.c
index 93ed9cb..03f8223 100644
--- a/arch/powerpc/platforms/pseries/eeh_pe.c
+++ b/arch/powerpc/platforms/pseries/eeh_pe.c
@@ -304,6 +304,7 @@ static struct eeh_pe *eeh_pe_get_parent(struct eeh_dev *edev)
int eeh_add_to_parent_pe(struct eeh_dev *edev)
{
struct eeh_pe *pe, *parent;
+ struct eeh_dev *first_edev;
eeh_lock();
@@ -326,6 +327,21 @@ int eeh_add_to_parent_pe(struct eeh_dev *edev)
pe->type = EEH_PE_BUS;
edev->pe = pe;
+ /*
+ * For PCI bus sensitive PE, we can reset the parent
+ * bridge in order for hot-reset. However, the PCI
+ * devices including the associated EEH devices might
+ * be removed when EEH core is doing recovery. So that
+ * won't safe to retrieve the bridge through downstream
+ * EEH device. We have to trace the parent PCI bus, then
+ * the parent bridge explicitly.
+ */
+ if (eeh_probe_mode_dev() && !pe->bus) {
+ first_edev = list_first_entry(&pe->edevs,
+ struct eeh_dev, list);
+ pe->bus = eeh_dev_to_pci_dev(first_edev)->bus;
+ }
+
/* Put the edev to PE */
list_add_tail(&edev->list, &pe->edevs);
eeh_unlock();
@@ -639,13 +655,20 @@ struct pci_bus *eeh_pe_bus_get(struct eeh_pe *pe)
if (pe->type & EEH_PE_PHB) {
bus = pe->phb->bus;
- } else if (pe->type & EEH_PE_BUS) {
+ } else if (pe->type & EEH_PE_BUS ||
+ pe->type & EEH_PE_DEVICE) {
+ if (pe->bus) {
+ bus = pe->bus;
+ goto out;
+ }
+
edev = list_first_entry(&pe->edevs, struct eeh_dev, list);
pdev = eeh_dev_to_pci_dev(edev);
if (pdev)
bus = pdev->bus;
}
+out:
eeh_unlock();
return bus;
--
1.7.5.4
^ permalink raw reply related
* [PATCH 02/22] powerpc/eeh: Function to tranverse PCI devices
From: Gavin Shan @ 2013-03-01 14:17 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Gavin Shan
In-Reply-To: <1362147440-14096-1-git-send-email-shangw@linux.vnet.ibm.com>
For EEH on PowerNV platform, the PCI devices will be probed to
check if they support EEH functionality. Different from the case
of EEH for pSeries platform, we will probe real PCI device instead
of device tree node for EEH capability on PowerNV platform.
The patch introduces function eeh_pci_dev_traverse() to traverse
PCI devices for the indicated PCI bus from top to bottom.
Signed-off-by: Gavin Shan <shangw@linux.vnet.ibm.com>
---
arch/powerpc/include/asm/eeh.h | 3 ++
arch/powerpc/platforms/pseries/eeh_dev.c | 35 ++++++++++++++++++++++++++++++
2 files changed, 38 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/include/asm/eeh.h b/arch/powerpc/include/asm/eeh.h
index e32c3c5..eeaeab6 100644
--- a/arch/powerpc/include/asm/eeh.h
+++ b/arch/powerpc/include/asm/eeh.h
@@ -183,6 +183,7 @@ static inline void eeh_unlock(void)
#define EEH_MAX_ALLOWED_FREEZES 5
typedef void *(*eeh_traverse_func)(void *data, void *flag);
+typedef void *(*eeh_pci_traverse_func)(struct pci_dev *dev, void *flag);
int eeh_phb_pe_create(struct pci_controller *phb);
int eeh_add_to_parent_pe(struct eeh_dev *edev);
int eeh_rmv_from_parent_pe(struct eeh_dev *edev, int purge_pe);
@@ -191,6 +192,8 @@ void *eeh_pe_dev_traverse(struct eeh_pe *root,
void eeh_pe_restore_bars(struct eeh_pe *pe);
struct pci_bus *eeh_pe_bus_get(struct eeh_pe *pe);
+void eeh_pci_dev_traverse(struct pci_bus *bus,
+ eeh_pci_traverse_func fn, void *flag);
void *eeh_dev_init(struct device_node *dn, void *data);
void eeh_dev_phb_init_dynamic(struct pci_controller *phb);
int __init eeh_ops_register(struct eeh_ops *ops);
diff --git a/arch/powerpc/platforms/pseries/eeh_dev.c b/arch/powerpc/platforms/pseries/eeh_dev.c
index 1efa28f..12c445d 100644
--- a/arch/powerpc/platforms/pseries/eeh_dev.c
+++ b/arch/powerpc/platforms/pseries/eeh_dev.c
@@ -41,6 +41,41 @@
#include <asm/pci-bridge.h>
#include <asm/ppc-pci.h>
+
+/**
+ * eeh_pci_dev_traverse - Traverse PCI devices for the indicated bus
+ * @bus: PCI bus
+ * @fn: callback function
+ * @flag: extra flag
+ *
+ * The function traverses the PCI devices for the indicated PCI bus
+ * from top to bottom fashion until the supplied callback function
+ * returns non-zero value on the specific PCI device.
+ */
+void eeh_pci_dev_traverse(struct pci_bus *bus,
+ eeh_pci_traverse_func fn, void *flag)
+{
+ struct pci_dev *dev;
+ void *ret;
+
+ if (!bus)
+ return;
+
+ /*
+ * We should make sure the parent devices are scanned
+ * prior to the child devices so that the parent PE
+ * could be created before the child PEs.
+ */
+ list_for_each_entry(dev, &bus->devices, bus_list) {
+ ret = fn(dev, flag);
+ if (ret)
+ return;
+
+ if (dev->subordinate)
+ eeh_pci_dev_traverse(dev->subordinate, fn, flag);
+ }
+}
+
/**
* eeh_dev_init - Create EEH device according to OF node
* @dn: device node
--
1.7.5.4
^ permalink raw reply related
* [PATCH 04/22] powerpc/eeh: Make eeh_pe_get public
From: Gavin Shan @ 2013-03-01 14:17 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Gavin Shan
In-Reply-To: <1362147440-14096-1-git-send-email-shangw@linux.vnet.ibm.com>
While processing EEH event caused by interrupt sent from P7IOC,
we need function to retrieve the PE according to the indicated
EEH device.
The patch makes function eeh_pe_get() public so that other source
files can call it. Also, the patch fixes referring to wrong BDF
(Bus/Device/Function) address while searching PE in function
__eeh_pe_get().
Signed-off-by: Gavin Shan <shangw@linux.vnet.ibm.com>
---
arch/powerpc/include/asm/eeh.h | 1 +
arch/powerpc/platforms/pseries/eeh_pe.c | 4 ++--
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/include/asm/eeh.h b/arch/powerpc/include/asm/eeh.h
index 4b48178..9230aa4 100644
--- a/arch/powerpc/include/asm/eeh.h
+++ b/arch/powerpc/include/asm/eeh.h
@@ -186,6 +186,7 @@ typedef void *(*eeh_traverse_func)(void *data, void *flag);
typedef void *(*eeh_pci_traverse_func)(struct pci_dev *dev, void *flag);
int eeh_phb_pe_create(struct pci_controller *phb);
struct eeh_pe *eeh_phb_pe_get(struct pci_controller *phb);
+struct eeh_pe *eeh_pe_get(struct eeh_dev *edev);
int eeh_add_to_parent_pe(struct eeh_dev *edev);
int eeh_rmv_from_parent_pe(struct eeh_dev *edev, int purge_pe);
void *eeh_pe_dev_traverse(struct eeh_pe *root,
diff --git a/arch/powerpc/platforms/pseries/eeh_pe.c b/arch/powerpc/platforms/pseries/eeh_pe.c
index 6e3eb43..93ed9cb 100644
--- a/arch/powerpc/platforms/pseries/eeh_pe.c
+++ b/arch/powerpc/platforms/pseries/eeh_pe.c
@@ -228,7 +228,7 @@ static void *__eeh_pe_get(void *data, void *flag)
return pe;
/* Try BDF address */
- if (edev->pe_config_addr &&
+ if (edev->config_addr &&
(edev->config_addr == pe->config_addr))
return pe;
@@ -246,7 +246,7 @@ static void *__eeh_pe_get(void *data, void *flag)
* which is composed of PCI bus/device/function number, or unified
* PE address.
*/
-static struct eeh_pe *eeh_pe_get(struct eeh_dev *edev)
+struct eeh_pe *eeh_pe_get(struct eeh_dev *edev)
{
struct eeh_pe *root = eeh_phb_pe_get(edev->phb);
struct eeh_pe *pe;
--
1.7.5.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