Re: [PATCH 4/4] powerpc/eeh: Avoid event on passed PE
Am 21.05.2014 um 02:13 schrieb Benjamin Herrenschmidt
b...@kernel.crashing.org:
On Tue, 2014-05-20 at 15:49 +0200, Alexander Graf wrote:
Instead of
if (passed_flag)
return;
you would do
if (trigger_irqfd) {
trigger_irqfd();
return;
}
which would be a much nicer, generic interface.
But that's not how PAPR works.
But it's what a non-QEMU VFIO user would want, and it should be easy to
implement.
Alex
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 4/4] powerpc/eeh: Avoid event on passed PE
Am 21.05.2014 um 02:19 schrieb Benjamin Herrenschmidt b...@kernel.crashing.org: On Tue, 2014-05-20 at 15:49 +0200, Alexander Graf wrote: So how about we just implement this whole thing properly as irqfd? Whether QEMU can actually do anything with the interrupt is a different question - we can leave it be for now. But we could model all the code with the assumption that it should either handle the error itself or trigger and irqfd write. I don't object to the idea... however this smells of Deja Vu... You often tend to want to turn something submitted that fills a specific gap and implements a specific spec/function into some kind of idealized grand design :-) And that means nothing gets upstream for weeks or monthes as we churn and churn... Sometimes it's probably worth it. Here I would argue against it and would advocate for doing the basic functionality first, as it is used by guests, and later add the irqfd option. I don't see any emergency here and adding the irqfd will not cause fundamental design changes: The passed flag (though I'm not fan of the name) is really something we want in the low level handlers to avoid triggering host side EEH in various places, regardless of whether we use irqfd or not. This is totally orthogonal from the mechanism used for notifications. Even in host, the detection path doesn't always involve interrupts, and we can detect some things as a result of a host side config space access for example etc... So let's keep things nice and separate here. The interrupt notification is just an optimization which will speed up discovery of the error in *some* cases later on (but adds its own complexity since we have multiple discovery path in host, so we need to keep track whether we have notified yet or not etc...) so let's keep it for later. EEH handling is your call, but I only see reduced complexity here. I won't nak the current approach though. Alex ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 3/4] drivers/vfio: New IOCTL command VFIO_EEH_INFO
Am 21.05.2014 um 02:23 schrieb Benjamin Herrenschmidt b...@kernel.crashing.org: On Tue, 2014-05-20 at 22:39 +1000, Gavin Shan wrote: Yeah. How about this? :-) - Move eeh-vfio.c to drivers/vfio/pci/ - From eeh-vfio.c, dereference arch/powerpc/kernel/eeh.c::eeh_ops, which is arch/powerpc/plaforms/powernv/eeh-powernv.c::powernv_eeh_ops. Call Hrm, I think it'd be nicer to just export individual functions that do thing you want to do from eeh.c. Ok. Got it. Thanks for your comments :) The interesting thing with this approach is that VFIO per-se can work with EEH RTAS backend too in the host. IE, with PR KVM for example or with non-KVM uses of VFIO, it would be possible to use a device in a user process and exploit EEH even when running under a PAPR hypervisor. That is, vfio-eeh uses generic exported EEH APIs from the EEH core that will work on both powernv and RTAS backends. Note to Alex: This definitely kills the notifier idea for now though, at least as a first class citizen of the design. We can add it as an optional optimization on top later. I don't think it does. The notifier would just get triggered on config space read failures for example :). It's really just an aid for the vfio user to have a common code path for error handling. Alex ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 3/3] powerpc: Document sysfs DSCR interface
Add some documentation about ... /sys/devices/system/cpu/dscr_default /sys/devices/system/cpu/cpuN/dscr ... to Documentation/ABI/stable. Signed-off-by: Sam Bobroff sam.bobr...@au1.ibm.com --- Documentation/ABI/stable/sysfs-devices-system-cpu | 25 + 1 file changed, 25 insertions(+) create mode 100644 Documentation/ABI/stable/sysfs-devices-system-cpu diff --git a/Documentation/ABI/stable/sysfs-devices-system-cpu b/Documentation/ABI/stable/sysfs-devices-system-cpu new file mode 100644 index 000..33c133e --- /dev/null +++ b/Documentation/ABI/stable/sysfs-devices-system-cpu @@ -0,0 +1,25 @@ +What: /sys/devices/system/cpu/dscr_default +Date: 13-May-2014 +KernelVersion: v3.15.0 +Contact: +Description: Writes are equivalent to writing to + /sys/devices/system/cpu/cpuN/dscr on all CPUs. + Reads return the last written value or 0. + This value is not a global default: it is a way to set + all per-CPU defaults at the same time. +Values:64 bit unsigned integer (bit field) + +What: /sys/devices/system/cpu/cpu[0-9]+/dscr +Date: 13-May-2014 +KernelVersion: v3.15.0 +Contact: +Description: Default value for the Data Stream Control Register (DSCR) on + a CPU. + This default value is used when the kernel is executing and + for any process that has not set the DSCR itself. + If a process ever sets the DSCR (via direct access to the + SPR) that value will be persisted for that process and used + on any CPU where it executes (overriding the value described + here). + If set by a process it will be inherited by child processes. +Values:64 bit unsigned integer (bit field) -- 1.7.10.4 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 2/3] powerpc: fix regression of per-CPU DSCR setting
Since commit efcac65 powerpc: Per process DSCR + some fixes (try#4)
it is no longer possible to set the DSCR on a per-CPU basis.
The old behaviour was to minipulate the DSCR SPR directly but this is no
longer sufficient: the value is quickly overwritten by context switching.
This patch stores the per-CPU DSCR value in a kernel variable rather than
directly in the SPR and it is used whenever a process has not set the DSCR
itself. The sysfs interface (/sys/devices/system/cpu/cpuN/dscr) is unchanged.
Writes to the old global default (/sys/devices/system/cpu/dscr_default)
now set all of the per-CPU values and reads return the last written value.
The new per-CPU default is added to the paca_struct and is used everywhere
outside of sysfs.c instead of the old global default.
Signed-off-by: Sam Bobroff sam.bobr...@au1.ibm.com
---
arch/powerpc/include/asm/paca.h |3 +++
arch/powerpc/kernel/asm-offsets.c |1 +
arch/powerpc/kernel/entry_64.S |9 +
arch/powerpc/kernel/sysfs.c | 32 ++-
arch/powerpc/kernel/tm.S| 16
arch/powerpc/kvm/book3s_hv_rmhandlers.S |3 +--
6 files changed, 29 insertions(+), 35 deletions(-)
diff --git a/arch/powerpc/include/asm/paca.h b/arch/powerpc/include/asm/paca.h
index 8e956a0..bb0bd25 100644
--- a/arch/powerpc/include/asm/paca.h
+++ b/arch/powerpc/include/asm/paca.h
@@ -92,7 +92,10 @@ struct paca_struct {
struct slb_shadow *slb_shadow_ptr;
struct dtl_entry *dispatch_log;
struct dtl_entry *dispatch_log_end;
+#endif /* CONFIG_PPC_STD_MMU_64 */
+ u64 dscr_default; /* per-CPU default DSCR */
+#ifdef CONFIG_PPC_STD_MMU_64
/*
* Now, starting in cacheline 2, the exception save areas
*/
diff --git a/arch/powerpc/kernel/asm-offsets.c
b/arch/powerpc/kernel/asm-offsets.c
index dba8140..cba2697 100644
--- a/arch/powerpc/kernel/asm-offsets.c
+++ b/arch/powerpc/kernel/asm-offsets.c
@@ -247,6 +247,7 @@ int main(void)
#endif
DEFINE(PACAHWCPUID, offsetof(struct paca_struct, hw_cpu_id));
DEFINE(PACAKEXECSTATE, offsetof(struct paca_struct, kexec_state));
+ DEFINE(PACA_DSCR, offsetof(struct paca_struct, dscr_default));
DEFINE(PACA_STARTTIME, offsetof(struct paca_struct, starttime));
DEFINE(PACA_STARTTIME_USER, offsetof(struct paca_struct,
starttime_user));
DEFINE(PACA_USER_TIME, offsetof(struct paca_struct, user_time));
diff --git a/arch/powerpc/kernel/entry_64.S b/arch/powerpc/kernel/entry_64.S
index 9fde8a1..911d453 100644
--- a/arch/powerpc/kernel/entry_64.S
+++ b/arch/powerpc/kernel/entry_64.S
@@ -387,12 +387,6 @@ _GLOBAL(ret_from_kernel_thread)
li r3,0
b syscall_exit
- .section.toc,aw
-DSCR_DEFAULT:
- .tc dscr_default[TC],dscr_default
-
- .section.text
-
/*
* This routine switches between two different tasks. The process
* state of one is saved on its kernel stack. Then the state
@@ -577,11 +571,10 @@ END_FTR_SECTION_IFSET(CPU_FTR_ALTIVEC)
#ifdef CONFIG_PPC64
BEGIN_FTR_SECTION
lwz r6,THREAD_DSCR_INHERIT(r4)
- ld r7,DSCR_DEFAULT@toc(2)
ld r0,THREAD_DSCR(r4)
cmpwi r6,0
bne 1f
- ld r0,0(r7)
+ ld r0,PACA_DSCR(r13)
1:
BEGIN_FTR_SECTION_NESTED(70)
mfspr r8, SPRN_FSCR
diff --git a/arch/powerpc/kernel/sysfs.c b/arch/powerpc/kernel/sysfs.c
index e2a1d6f..67fd2fd 100644
--- a/arch/powerpc/kernel/sysfs.c
+++ b/arch/powerpc/kernel/sysfs.c
@@ -484,7 +484,6 @@ SYSFS_PMCSETUP(pmc8, SPRN_PMC8);
SYSFS_PMCSETUP(mmcra, SPRN_MMCRA);
SYSFS_SPRSETUP(purr, SPRN_PURR);
SYSFS_SPRSETUP(spurr, SPRN_SPURR);
-SYSFS_SPRSETUP(dscr, SPRN_DSCR);
SYSFS_SPRSETUP(pir, SPRN_PIR);
/*
@@ -494,12 +493,27 @@ SYSFS_SPRSETUP(pir, SPRN_PIR);
*/
static DEVICE_ATTR(mmcra, 0600, show_mmcra, store_mmcra);
static DEVICE_ATTR(spurr, 0400, show_spurr, NULL);
-static DEVICE_ATTR(dscr, 0600, show_dscr, store_dscr);
static DEVICE_ATTR(purr, 0400, show_purr, store_purr);
static DEVICE_ATTR(pir, 0400, show_pir, NULL);
-unsigned long dscr_default = 0;
-EXPORT_SYMBOL(dscr_default);
+static unsigned long dscr_default;
+
+static void read_dscr(void *val)
+{
+ *(unsigned long *)val = get_paca()-dscr_default;
+}
+
+static void write_dscr(void *val)
+{
+ get_paca()-dscr_default = *(unsigned long *)val;
+ if (!current-thread.dscr_inherit) {
+ current-thread.dscr = *(unsigned long *)val;
+ mtspr(SPRN_DSCR, *(unsigned long *)val);
+ }
+}
+
+SYSFS_SPRSETUP_SHOW_STORE(dscr);
+static DEVICE_ATTR(dscr, 0600, show_dscr, store_dscr);
static void add_write_permission_dev_attr(struct device_attribute *attr)
{
@@ -512,14 +526,6 @@ static ssize_t show_dscr_default(struct device *dev,
return sprintf(buf, %lx\n, dscr_default);
}
-static void update_dscr(void *dummy)
-{
- if
[PATCH 0/3] powerpc: fix regression of per-CPU DSCR setting
Hello, This patch corrects a regression on PowerPC CPUs that causes their per-CPU DSCR SPR value (exposed via /sys/devices/system/cpuN/dscr) to be quickly lost during context switching, effectively meaning that the DSCR can no longer be set on a per-CPU basis. My intent is to restore the functionality of the per-CPU value in a way that is compatible with the newer global default and task-specific DSCR setting system. Users of either the old or new systems should now get pretty much what they expect. A couple of notes: I've split an existing ifdef CONFIG_PPC_STD_MMU_64 block in paca_struct into two parts because it allows dscr_default to be placed into a cache line hole. (This seems be the case even without CONFIG_PPC_STD_MMU_64 being defined.) Comments or ideas on alternative placements are welcome. PowerPC context switching is touched but there should not be any performance cost; if anything it should get slightly faster due to the per-CPU value being easier to access than the old global default. Sam Bobroff (3): powerpc: Split __SYSFS_SPRSETUP macro powerpc: fix regression of per-CPU DSCR setting powerpc: Document sysfs DSCR interface Documentation/ABI/stable/sysfs-devices-system-cpu | 25 ++ arch/powerpc/include/asm/paca.h |3 ++ arch/powerpc/kernel/asm-offsets.c |1 + arch/powerpc/kernel/entry_64.S|9 +--- arch/powerpc/kernel/sysfs.c | 51 + arch/powerpc/kernel/tm.S | 16 ++- arch/powerpc/kvm/book3s_hv_rmhandlers.S |3 +- 7 files changed, 67 insertions(+), 41 deletions(-) create mode 100644 Documentation/ABI/stable/sysfs-devices-system-cpu -- 1.7.10.4 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 1/3] powerpc: Split __SYSFS_SPRSETUP macro
Split the __SYSFS_SPRSETUP macro into two parts so that registers requiring
custom read and write functions can use common code for their show and store
functions.
Signed-off-by: Sam Bobroff sam.bobr...@au1.ibm.com
---
arch/powerpc/kernel/sysfs.c | 19 +--
1 file changed, 13 insertions(+), 6 deletions(-)
diff --git a/arch/powerpc/kernel/sysfs.c b/arch/powerpc/kernel/sysfs.c
index d90d4b7..e2a1d6f 100644
--- a/arch/powerpc/kernel/sysfs.c
+++ b/arch/powerpc/kernel/sysfs.c
@@ -404,7 +404,7 @@ void ppc_enable_pmcs(void)
}
EXPORT_SYMBOL(ppc_enable_pmcs);
-#define __SYSFS_SPRSETUP(NAME, ADDRESS, EXTRA) \
+#define __SYSFS_SPRSETUP_READ_WRITE(NAME, ADDRESS, EXTRA) \
static void read_##NAME(void *val) \
{ \
*(unsigned long *)val = mfspr(ADDRESS); \
@@ -413,7 +413,9 @@ static void write_##NAME(void *val) \
{ \
EXTRA; \
mtspr(ADDRESS, *(unsigned long *)val); \
-} \
+}
+
+#define __SYSFS_SPRSETUP_SHOW_STORE(NAME) \
static ssize_t show_##NAME(struct device *dev, \
struct device_attribute *attr, \
char *buf) \
@@ -436,10 +438,15 @@ static ssize_t __used \
return count; \
}
-#define SYSFS_PMCSETUP(NAME, ADDRESS) \
- __SYSFS_SPRSETUP(NAME, ADDRESS, ppc_enable_pmcs())
-#define SYSFS_SPRSETUP(NAME, ADDRESS) \
- __SYSFS_SPRSETUP(NAME, ADDRESS, )
+#define SYSFS_PMCSETUP(NAME, ADDRESS) \
+ __SYSFS_SPRSETUP_READ_WRITE(NAME, ADDRESS, ppc_enable_pmcs()) \
+ __SYSFS_SPRSETUP_SHOW_STORE(NAME)
+#define SYSFS_SPRSETUP(NAME, ADDRESS) \
+ __SYSFS_SPRSETUP_READ_WRITE(NAME, ADDRESS, ) \
+ __SYSFS_SPRSETUP_SHOW_STORE(NAME)
+
+#define SYSFS_SPRSETUP_SHOW_STORE(NAME) \
+ __SYSFS_SPRSETUP_SHOW_STORE(NAME)
/* Let's define all possible registers, we'll only hook up the ones
* that are implemented on the current processor
--
1.7.10.4
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v4 8/8] DMA: Freescale: add suspend resume functions for DMA driver
On 05/21/2014 11:45 AM, Vinod Koul wrote:
On Thu, May 08, 2014 at 05:52:37PM +0800, Hongbo Zhang wrote:
On 05/07/2014 04:31 PM, Shevchenko, Andriy wrote:
On Sun, 2014-05-04 at 18:22 +0800, Hongbo Zhang wrote:
On 05/03/2014 12:46 AM, Vinod Koul wrote:
On Fri, Apr 18, 2014 at 04:17:51PM +0800, hongbo.zh...@freescale.com wrote:
From: Hongbo Zhang hongbo.zh...@freescale.com
This patch adds suspend resume functions for Freescale DMA driver.
.prepare callback is used to stop further descriptors from being added into the
pending queue, and also issue pending queues into execution if there is any.
.suspend callback makes sure all the pending jobs are cleaned up and all the
channels are idle, and save the mode registers.
.resume callback re-initializes the channels by restore the mode registers.
+
+static const struct dev_pm_ops fsldma_pm_ops = {
+ .prepare= fsldma_prepare,
+ .suspend= fsldma_suspend,
+ .resume = fsldma_resume,
+};
I think this is not correct. We discussed this sometime back on list. The
DMAengine drivers should use late resume and early suspend to ensure they get
suspended after clients (who should use normal ones) and resume before them
OK, will update it like this:
use .suspend to take place of current .prepare
Could you remove this at all?
Answering to your previous statements I could say that.
Device drivers (DMAc users) that don't implement .suspend callback are
on their own with troubles, you have not to care about them in the DMA
driver.
Thanks for pointing out this issue.
Then how to handle the descriptors in the pending list if there is any?
a. let them finished.
but if the DMA user has already suspended prior DMA controller,
it is meaningless somehow and may even ask for trouble.
b. don't touch them.
after resume these pending descriptors could be executed, it is
also meaningless because the resumed DMA user may in different state
from before being suspended.
c. delete them.
should we do this? is is a bit crude?
d. return a non-success value
then the whole suspend process is reversed, e.g. suspend fails.
I've looked through some dma drivers, most of them is in case b.
Yes and that makese sense.
In calssic suspend case we maybe in middle so graceful behaviour would be to for
client to PAUSE or terminate and then suspend followed by DMA suspend.
You need to rely on client doing the right thing here
OK, will resend this 6/8, 7/8 and 8/8 for another iteration, and will
let the current 6/8 to be the last one for being reviewed and merged easier.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 3/4] drivers/vfio: New IOCTL command VFIO_EEH_INFO
On Wed, 2014-05-21 at 08:23 +0200, Alexander Graf wrote: Note to Alex: This definitely kills the notifier idea for now though, at least as a first class citizen of the design. We can add it as an optional optimization on top later. I don't think it does. The notifier would just get triggered on config space read failures for example :). It's really just an aid for the vfio user to have a common code path for error handling. I'll let Gavin make the final call on that one, if he thinks we can reliably trigger it and there isn't too much code churn as a consequence. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v5 1/3] DMA: Freescale: use spin_lock_bh instead of spin_lock_irqsave
From: Hongbo Zhang hongbo.zh...@freescale.com
The usage of spin_lock_irqsave() is a stronger locking mechanism than is
required throughout the driver. The minimum locking required should be used
instead. Interrupts will be turned off and context will be saved, it is
unnecessary to use irqsave.
This patch changes all instances of spin_lock_irqsave() to spin_lock_bh(). All
manipulation of protected fields is done using tasklet context or weaker, which
makes spin_lock_bh() the correct choice.
Signed-off-by: Hongbo Zhang hongbo.zh...@freescale.com
Signed-off-by: Qiang Liu qiang@freescale.com
---
drivers/dma/fsldma.c | 25 ++---
1 file changed, 10 insertions(+), 15 deletions(-)
diff --git a/drivers/dma/fsldma.c b/drivers/dma/fsldma.c
index e0fec68..b291e6c 100644
--- a/drivers/dma/fsldma.c
+++ b/drivers/dma/fsldma.c
@@ -396,10 +396,9 @@ static dma_cookie_t fsl_dma_tx_submit(struct
dma_async_tx_descriptor *tx)
struct fsldma_chan *chan = to_fsl_chan(tx-chan);
struct fsl_desc_sw *desc = tx_to_fsl_desc(tx);
struct fsl_desc_sw *child;
- unsigned long flags;
dma_cookie_t cookie = -EINVAL;
- spin_lock_irqsave(chan-desc_lock, flags);
+ spin_lock_bh(chan-desc_lock);
/*
* assign cookies to all of the software descriptors
@@ -412,7 +411,7 @@ static dma_cookie_t fsl_dma_tx_submit(struct
dma_async_tx_descriptor *tx)
/* put this transaction onto the tail of the pending queue */
append_ld_queue(chan, desc);
- spin_unlock_irqrestore(chan-desc_lock, flags);
+ spin_unlock_bh(chan-desc_lock);
return cookie;
}
@@ -617,13 +616,12 @@ static void fsldma_free_desc_list_reverse(struct
fsldma_chan *chan,
static void fsl_dma_free_chan_resources(struct dma_chan *dchan)
{
struct fsldma_chan *chan = to_fsl_chan(dchan);
- unsigned long flags;
chan_dbg(chan, free all channel resources\n);
- spin_lock_irqsave(chan-desc_lock, flags);
+ spin_lock_bh(chan-desc_lock);
fsldma_free_desc_list(chan, chan-ld_pending);
fsldma_free_desc_list(chan, chan-ld_running);
- spin_unlock_irqrestore(chan-desc_lock, flags);
+ spin_unlock_bh(chan-desc_lock);
dma_pool_destroy(chan-desc_pool);
chan-desc_pool = NULL;
@@ -842,7 +840,6 @@ static int fsl_dma_device_control(struct dma_chan *dchan,
{
struct dma_slave_config *config;
struct fsldma_chan *chan;
- unsigned long flags;
int size;
if (!dchan)
@@ -852,7 +849,7 @@ static int fsl_dma_device_control(struct dma_chan *dchan,
switch (cmd) {
case DMA_TERMINATE_ALL:
- spin_lock_irqsave(chan-desc_lock, flags);
+ spin_lock_bh(chan-desc_lock);
/* Halt the DMA engine */
dma_halt(chan);
@@ -862,7 +859,7 @@ static int fsl_dma_device_control(struct dma_chan *dchan,
fsldma_free_desc_list(chan, chan-ld_running);
chan-idle = true;
- spin_unlock_irqrestore(chan-desc_lock, flags);
+ spin_unlock_bh(chan-desc_lock);
return 0;
case DMA_SLAVE_CONFIG:
@@ -904,11 +901,10 @@ static int fsl_dma_device_control(struct dma_chan *dchan,
static void fsl_dma_memcpy_issue_pending(struct dma_chan *dchan)
{
struct fsldma_chan *chan = to_fsl_chan(dchan);
- unsigned long flags;
- spin_lock_irqsave(chan-desc_lock, flags);
+ spin_lock_bh(chan-desc_lock);
fsl_chan_xfer_ld_queue(chan);
- spin_unlock_irqrestore(chan-desc_lock, flags);
+ spin_unlock_bh(chan-desc_lock);
}
/**
@@ -998,11 +994,10 @@ static void dma_do_tasklet(unsigned long data)
struct fsldma_chan *chan = (struct fsldma_chan *)data;
struct fsl_desc_sw *desc, *_desc;
LIST_HEAD(ld_cleanup);
- unsigned long flags;
chan_dbg(chan, tasklet entry\n);
- spin_lock_irqsave(chan-desc_lock, flags);
+ spin_lock_bh(chan-desc_lock);
/* update the cookie if we have some descriptors to cleanup */
if (!list_empty(chan-ld_running)) {
@@ -1031,7 +1026,7 @@ static void dma_do_tasklet(unsigned long data)
* ahead and free the descriptors below.
*/
fsl_chan_xfer_ld_queue(chan);
- spin_unlock_irqrestore(chan-desc_lock, flags);
+ spin_unlock_bh(chan-desc_lock);
/* Run the callback for each descriptor, in order */
list_for_each_entry_safe(desc, _desc, ld_cleanup, node) {
--
1.7.9.5
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v5 2/3] DMA: Freescale: add suspend resume functions for DMA driver
From: Hongbo Zhang hongbo.zh...@freescale.com
This patch adds suspend and resume functions for Freescale DMA driver.
Signed-off-by: Hongbo Zhang hongbo.zh...@freescale.com
---
drivers/dma/fsldma.c | 77 ++
drivers/dma/fsldma.h | 15 ++
2 files changed, 92 insertions(+)
diff --git a/drivers/dma/fsldma.c b/drivers/dma/fsldma.c
index b291e6c..465f16d 100644
--- a/drivers/dma/fsldma.c
+++ b/drivers/dma/fsldma.c
@@ -400,6 +400,14 @@ static dma_cookie_t fsl_dma_tx_submit(struct
dma_async_tx_descriptor *tx)
spin_lock_bh(chan-desc_lock);
+#ifdef CONFIG_PM
+ if (unlikely(chan-pm_state != RUNNING)) {
+ chan_dbg(chan, cannot submit due to suspend\n);
+ spin_unlock_bh(chan-desc_lock);
+ return -1;
+ }
+#endif
+
/*
* assign cookies to all of the software descriptors
* that make up this transaction
@@ -1221,6 +1229,9 @@ static int fsl_dma_chan_probe(struct fsldma_device *fdev,
INIT_LIST_HEAD(chan-ld_pending);
INIT_LIST_HEAD(chan-ld_running);
chan-idle = true;
+#ifdef CONFIG_PM
+ chan-pm_state = RUNNING;
+#endif
chan-common.device = fdev-common;
dma_cookie_init(chan-common);
@@ -1360,6 +1371,69 @@ static int fsldma_of_remove(struct platform_device *op)
return 0;
}
+#ifdef CONFIG_PM
+static int fsldma_suspend_late(struct device *dev)
+{
+ struct platform_device *pdev = to_platform_device(dev);
+ struct fsldma_device *fdev = platform_get_drvdata(pdev);
+ struct fsldma_chan *chan;
+ int i;
+
+ for (i = 0; i FSL_DMA_MAX_CHANS_PER_DEVICE; i++) {
+ chan = fdev-chan[i];
+ if (!chan)
+ continue;
+
+ spin_lock_bh(chan-desc_lock);
+ if (unlikely(!chan-idle))
+ goto out;
+ chan-regs_save.mr = get_mr(chan);
+ chan-pm_state = SUSPENDED;
+ spin_unlock_bh(chan-desc_lock);
+ }
+ return 0;
+
+out:
+ for (; i = 0; i--) {
+ chan = fdev-chan[i];
+ if (!chan)
+ continue;
+ chan-pm_state = RUNNING;
+ spin_unlock_bh(chan-desc_lock);
+ }
+ return -EBUSY;
+}
+
+static int fsldma_resume_early(struct device *dev)
+{
+ struct platform_device *pdev = to_platform_device(dev);
+ struct fsldma_device *fdev = platform_get_drvdata(pdev);
+ struct fsldma_chan *chan;
+ u32 mode;
+ int i;
+
+ for (i = 0; i FSL_DMA_MAX_CHANS_PER_DEVICE; i++) {
+ chan = fdev-chan[i];
+ if (!chan)
+ continue;
+
+ spin_lock_bh(chan-desc_lock);
+ mode = chan-regs_save.mr
+~FSL_DMA_MR_CS ~FSL_DMA_MR_CC ~FSL_DMA_MR_CA;
+ set_mr(chan, mode);
+ chan-pm_state = RUNNING;
+ spin_unlock_bh(chan-desc_lock);
+ }
+
+ return 0;
+}
+
+static const struct dev_pm_ops fsldma_pm_ops = {
+ .suspend_late = fsldma_suspend_late,
+ .resume_early = fsldma_resume_early,
+};
+#endif
+
static const struct of_device_id fsldma_of_ids[] = {
{ .compatible = fsl,elo3-dma, },
{ .compatible = fsl,eloplus-dma, },
@@ -1372,6 +1446,9 @@ static struct platform_driver fsldma_of_driver = {
.name = fsl-elo-dma,
.owner = THIS_MODULE,
.of_match_table = fsldma_of_ids,
+#ifdef CONFIG_PM
+ .pm = fsldma_pm_ops,
+#endif
},
.probe = fsldma_of_probe,
.remove = fsldma_of_remove,
diff --git a/drivers/dma/fsldma.h b/drivers/dma/fsldma.h
index d56e835..f2e0c4d 100644
--- a/drivers/dma/fsldma.h
+++ b/drivers/dma/fsldma.h
@@ -134,6 +134,17 @@ struct fsldma_device {
#define FSL_DMA_CHAN_PAUSE_EXT 0x1000
#define FSL_DMA_CHAN_START_EXT 0x2000
+#ifdef CONFIG_PM
+struct fsldma_chan_regs_save {
+ u32 mr;
+};
+
+enum fsldma_pm_state {
+ RUNNING = 0,
+ SUSPENDED,
+};
+#endif
+
struct fsldma_chan {
char name[8]; /* Channel name */
struct fsldma_chan_regs __iomem *regs;
@@ -148,6 +159,10 @@ struct fsldma_chan {
struct tasklet_struct tasklet;
u32 feature;
bool idle; /* DMA controller is idle */
+#ifdef CONFIG_PM
+ struct fsldma_chan_regs_save regs_save;
+ enum fsldma_pm_state pm_state;
+#endif
void (*toggle_ext_pause)(struct fsldma_chan *fsl_chan, int enable);
void (*toggle_ext_start)(struct fsldma_chan *fsl_chan, int enable);
--
1.7.9.5
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v5 3/3] DMA: Freescale: change descriptor release process for supporting async_tx
From: Hongbo Zhang hongbo.zh...@freescale.com
Fix the potential risk when enable config NET_DMA and ASYNC_TX. Async_tx is
lack of support in current release process of dma descriptor, all descriptors
will be released whatever is acked or no-acked by async_tx, so there is a
potential race condition when dma engine is uesd by others clients (e.g. when
enable NET_DMA to offload TCP).
In our case, a race condition which is raised when use both of talitos and
dmaengine to offload xor is because napi scheduler will sync all pending
requests in dma channels, it affects the process of raid operations due to
ack_tx is not checked in fsl dma. The no-acked descriptor is freed which is
submitted just now, as a dependent tx, this freed descriptor trigger
BUG_ON(async_tx_test_ack(depend_tx)) in async_tx_submit().
TASK = ee1a94a0[1390] 'md0_raid5' THREAD: ecf4 CPU: 0
GPR00: 0001 ecf41ca0 ee44/921a94a0 003f 0001 c00593e4
0001
GPR08: a7a7a7a7 0001 045/92002 42028042 100a38d4 ed576d98
GPR16: ed5a11b0 2b162000 0200 046/92000 2d555000 ed3015e8
c15a7aa0
GPR24: c155fc40 ecb63220 ecf41d28 e47/92f640bb0 ef640c30
ecf41ca0
NIP [c02b048c] async_tx_submit+0x6c/0x2b4
LR [c02b068c] async_tx_submit+0x26c/0x2b4
Call Trace:
[ecf41ca0] [c02b068c] async_tx_submit+0x26c/0x2b448/92 (unreliable)
[ecf41cd0] [c02b0a4c] async_memcpy+0x240/0x25c
[ecf41d20] [c0421064] async_copy_data+0xa0/0x17c
[ecf41d70] [c0421cf4] __raid_run_ops+0x874/0xe10
[ecf41df0] [c0426ee4] handle_stripe+0x820/0x25e8
[ecf41e90] [c0429080] raid5d+0x3d4/0x5b4
[ecf41f40] [c04329b8] md_thread+0x138/0x16c
[ecf41f90] [c008277c] kthread+0x8c/0x90
[ecf41ff0] [c0011630] kernel_thread+0x4c/0x68
Another modification in this patch is the change of completed descriptors,
there is a potential risk which caused by exception interrupt, all descriptors
in ld_running list are seemed completed when an interrupt raised, it works fine
under normal condition, but if there is an exception occured, it cannot work as
our excepted. Hardware should not be depend on s/w list, the right way is to
read current descriptor address register to find the last completed descriptor.
If an interrupt is raised by an error, all descriptors in ld_running should not
be seemed finished, or these unfinished descriptors in ld_running will be
released wrongly.
A simple way to reproduce:
Enable dmatest first, then insert some bad descriptors which can trigger
Programming Error interrupts before the good descriptors. Last, the good
descriptors will be freed before they are processsed because of the exception
intrerrupt.
Note: the bad descriptors are only for simulating an exception interrupt. This
case can illustrate the potential risk in current fsl-dma very well.
Signed-off-by: Hongbo Zhang hongbo.zh...@freescale.com
Signed-off-by: Qiang Liu qiang@freescale.com
Signed-off-by: Ira W. Snyder i...@ovro.caltech.edu
---
drivers/dma/fsldma.c | 197 --
drivers/dma/fsldma.h | 17 -
2 files changed, 159 insertions(+), 55 deletions(-)
diff --git a/drivers/dma/fsldma.c b/drivers/dma/fsldma.c
index 465f16d..d5d6885 100644
--- a/drivers/dma/fsldma.c
+++ b/drivers/dma/fsldma.c
@@ -466,6 +466,88 @@ static struct fsl_desc_sw *fsl_dma_alloc_descriptor(struct
fsldma_chan *chan)
}
/**
+ * fsldma_clean_completed_descriptor - free all descriptors which
+ * has been completed and acked
+ * @chan: Freescale DMA channel
+ *
+ * This function is used on all completed and acked descriptors.
+ * All descriptors should only be freed in this function.
+ */
+static void fsldma_clean_completed_descriptor(struct fsldma_chan *chan)
+{
+ struct fsl_desc_sw *desc, *_desc;
+
+ /* Run the callback for each descriptor, in order */
+ list_for_each_entry_safe(desc, _desc, chan-ld_completed, node)
+ if (async_tx_test_ack(desc-async_tx))
+ fsl_dma_free_descriptor(chan, desc);
+}
+
+/**
+ * fsldma_run_tx_complete_actions - cleanup a single link descriptor
+ * @chan: Freescale DMA channel
+ * @desc: descriptor to cleanup and free
+ * @cookie: Freescale DMA transaction identifier
+ *
+ * This function is used on a descriptor which has been executed by the DMA
+ * controller. It will run any callbacks, submit any dependencies.
+ */
+static dma_cookie_t fsldma_run_tx_complete_actions(struct fsldma_chan *chan,
+ struct fsl_desc_sw *desc, dma_cookie_t cookie)
+{
+ struct dma_async_tx_descriptor *txd = desc-async_tx;
+ dma_cookie_t ret = cookie;
+
+ BUG_ON(txd-cookie 0);
+
+ if (txd-cookie 0) {
+ ret = txd-cookie;
+
+ /* Run the link descriptor callback function */
+ if (txd-callback) {
+ chan_dbg(chan, LD %p callback\n, desc);
+ txd-callback(txd-callback_param);
+ }
+ }
+
+ /* Run any dependencies */
[PATCH v5 0/3] DMA: Freescale: driver cleanups and enhancements
From: Hongbo Zhang hongbo.zh...@freescale.com Hi Dan, Please have a look at this 3/3 as Vinod mentioned. Hi Vinod Koul, Please have a look at the v5 patch set. v4 - v5 changes: - since previous 5 of 8 patches have been merged by Vinod, this iteration oly inludes the last 3 patches of v4. - patches order is changed for being reviewed and merged easier. - remove the .prepare functions, and use the suspend_late and resume_early in the suspend-and-resume patch. v3 - v4 changes: - Fixed a typo in [2/8] commit message. - There was a potential double call of list_del() when apply [4/8] only, although this defect is removed again in later [6/8]. This version eliminates this problem by updating [4/8] and [6/8] slightly. - Updated [8/8] to use register access method introduced by [2/8] v2 - v3 change: Only add chan-pm_state = RUNNING for patch[8/8]. v1 - v2 change: The only one change is introducing a new patch[1/7] to remove the unnecessary macro FSL_DMA_LD_DEBUG, thus the total patches number is 8 now (was 7) v1 notes: Note that patch 2~6 had beed sent out for upstream before, but were together with other storage patches at that time, that was not easy for being reviewed and merged, so I send them separately this time. Hongbo Zhang (3): DMA: Freescale: use spin_lock_bh instead of spin_lock_irqsave DMA: Freescale: add suspend resume functions for DMA driver DMA: Freescale: change descriptor release process for supporting async_tx drivers/dma/fsldma.c | 297 ++ drivers/dma/fsldma.h | 32 +- 2 files changed, 260 insertions(+), 69 deletions(-) -- 1.7.9.5 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 3/4] drivers/vfio: New IOCTL command VFIO_EEH_INFO
On Wed, May 21, 2014 at 05:24:22PM +1000, Benjamin Herrenschmidt wrote: On Wed, 2014-05-21 at 08:23 +0200, Alexander Graf wrote: Note to Alex: This definitely kills the notifier idea for now though, at least as a first class citizen of the design. We can add it as an optional optimization on top later. I don't think it does. The notifier would just get triggered on config space read failures for example :). It's really just an aid for the vfio user to have a common code path for error handling. I'll let Gavin make the final call on that one, if he thinks we can reliably trigger it and there isn't too much code churn as a consequence. Lets postpone it as future improvement. It's not hard to send the event (EEH errors) out, but I need think about how to extend the existing guest's infrastructure to accept event. As Ben mentioned, event-scan might be potential mechanism for that. We can discuss for more later :-) Thanks, Gavin ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 2/2] powerpc/corenet64_smp_defconfig: enable RTC support
Enable RTC support for DS1307, DS1374, DS3232, which is needed on some corenet boards. Signed-off-by: Shengzhou Liu shengzhou@freescale.com --- arch/powerpc/configs/corenet64_smp_defconfig | 5 + 1 file changed, 5 insertions(+) diff --git a/arch/powerpc/configs/corenet64_smp_defconfig b/arch/powerpc/configs/corenet64_smp_defconfig index 63508dd..e9c9f86 100644 --- a/arch/powerpc/configs/corenet64_smp_defconfig +++ b/arch/powerpc/configs/corenet64_smp_defconfig @@ -125,6 +125,11 @@ CONFIG_USB_EHCI_FSL=y CONFIG_USB_STORAGE=y CONFIG_MMC=y CONFIG_MMC_SDHCI=y +CONFIG_RTC_CLASS=y +CONFIG_RTC_DRV_CMOS=y +CONFIG_RTC_DRV_DS1307=y +CONFIG_RTC_DRV_DS1374=y +CONFIG_RTC_DRV_DS3232=y CONFIG_EDAC=y CONFIG_EDAC_MM_EDAC=y CONFIG_DMADEVICES=y -- 1.8.0 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 1/2] mtd/spi: support en25s64 device
Add support for EON en25s64 spi device.
Signed-off-by: Shengzhou Liu shengzhou@freescale.com
---
drivers/mtd/devices/m25p80.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/mtd/devices/m25p80.c b/drivers/mtd/devices/m25p80.c
index 7eda71d..6989311 100644
--- a/drivers/mtd/devices/m25p80.c
+++ b/drivers/mtd/devices/m25p80.c
@@ -745,6 +745,7 @@ static const struct spi_device_id m25p_ids[] = {
{ en25q32b, INFO(0x1c3016, 0, 64 * 1024, 64, 0) },
{ en25p64,INFO(0x1c2017, 0, 64 * 1024, 128, 0) },
{ en25q64,INFO(0x1c3017, 0, 64 * 1024, 128, SECT_4K) },
+ { en25s64,INFO(0x1c3817, 0, 64 * 1024, 128, 0) },
{ en25qh256, INFO(0x1c7019, 0, 64 * 1024, 512, 0) },
/* ESMT */
--
1.8.0
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v5 3/4] drivers/vfio: EEH support for VFIO PCI device
On 21.05.14 07:03, Gavin Shan wrote:
The patch adds new IOCTL command VFIO_EEH_OP to VFIO PCI device
to support EEH functionality for PCI devices, which have been
passed from host to guest via VFIO.
Signed-off-by: Gavin Shan gws...@linux.vnet.ibm.com
---
Documentation/vfio.txt | 6 +-
arch/powerpc/include/asm/eeh.h | 10 ++
arch/powerpc/kernel/eeh.c | 323 +
drivers/vfio/pci/vfio_pci.c| 99 -
include/uapi/linux/vfio.h | 43 ++
5 files changed, 474 insertions(+), 7 deletions(-)
diff --git a/Documentation/vfio.txt b/Documentation/vfio.txt
index b9ca023..bb17ec7 100644
--- a/Documentation/vfio.txt
+++ b/Documentation/vfio.txt
@@ -305,7 +305,10 @@ faster, the map/unmap handling has been implemented in
real mode which provides
an excellent performance which has limitations such as inability to do
locked pages accounting in real time.
-So 3 additional ioctls have been added:
+4) PPC64 guests detect PCI errors and recover from them via EEH RTAS services,
+which works on the basis of additional ioctl command VFIO_EEH_OP.
+
+So 4 additional ioctls have been added:
VFIO_IOMMU_SPAPR_TCE_GET_INFO - returns the size and the start
of the DMA window on the PCI bus.
@@ -316,6 +319,7 @@ So 3 additional ioctls have been added:
VFIO_IOMMU_DISABLE - disables the container.
+ VFIO_EEH_OP - EEH dependent operations
Please document exactly what the ioctl does. In an ideal world, a VFIO
user will just look at the documentation and be able to write a program
against the API with it.
The code flow from the example above should be slightly changed:
diff --git a/arch/powerpc/include/asm/eeh.h b/arch/powerpc/include/asm/eeh.h
index 34a2d83..93922ef 100644
--- a/arch/powerpc/include/asm/eeh.h
+++ b/arch/powerpc/include/asm/eeh.h
@@ -305,6 +305,16 @@ void eeh_add_device_late(struct pci_dev *);
void eeh_add_device_tree_late(struct pci_bus *);
void eeh_add_sysfs_files(struct pci_bus *);
void eeh_remove_device(struct pci_dev *);
+#ifdef CONFIG_VFIO_PCI_EEH
+int eeh_vfio_open(struct pci_dev *pdev);
+void eeh_vfio_release(struct pci_dev *pdev);
+int eeh_vfio_set_pe_option(struct pci_dev *pdev, int option, int *retval);
+int eeh_vfio_get_pe_addr(struct pci_dev *pdev, int option,
+int *retval, int *info);
+int eeh_vfio_get_pe_state(struct pci_dev *pdev, int *retval, int *state);
+int eeh_vfio_reset_pe(struct pci_dev *pdev, int option, int *retval);
+int eeh_vfio_configure_pe(struct pci_dev *pdev, int *retval);
+#endif
/**
* EEH_POSSIBLE_ERROR() -- test for possible MMIO failure.
diff --git a/arch/powerpc/kernel/eeh.c b/arch/powerpc/kernel/eeh.c
index 9c6b899..2aaf90e 100644
--- a/arch/powerpc/kernel/eeh.c
+++ b/arch/powerpc/kernel/eeh.c
@@ -1098,6 +1098,329 @@ void eeh_remove_device(struct pci_dev *dev)
edev-mode = ~EEH_DEV_SYSFS;
}
+#ifdef CONFIG_VFIO_PCI_EEH
+int eeh_vfio_open(struct pci_dev *pdev)
Why vfio? Also that config option will not be set if vfio is compiled as
a module.
+{
+ struct eeh_dev *edev;
+
+ /* No PCI device ? */
+ if (!pdev)
+ return -ENODEV;
+
+ /* No EEH device ? */
+ edev = pci_dev_to_eeh_dev(pdev);
+ if (!edev || !edev-pe)
+ return -ENODEV;
+
+ eeh_dev_set_passed(edev, true);
+ eeh_pe_set_passed(edev-pe, true);
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(eeh_vfio_open);
+
+void eeh_vfio_release(struct pci_dev *pdev)
+{
+ bool release_pe = true;
+ struct eeh_pe *pe = NULL;
+ struct eeh_dev *tmp, *edev;
+
+ /* No PCI device ? */
+ if (!pdev)
+ return;
+
+ /* No EEH device ? */
+ edev = pci_dev_to_eeh_dev(pdev);
+ if (!edev || !eeh_dev_passed(edev) ||
+ !edev-pe || !eeh_pe_passed(pe))
+ return;
+
+ /* Release device */
+ pe = edev-pe;
+ eeh_dev_set_passed(edev, false);
+
+ /* Release PE */
+ eeh_pe_for_each_dev(pe, edev, tmp) {
+ if (eeh_dev_passed(edev)) {
+ release_pe = false;
+ break;
+ }
+ }
+
+ if (release_pe)
+ eeh_pe_set_passed(pe, false);
+}
+EXPORT_SYMBOL(eeh_vfio_release);
+
+static int eeh_vfio_check_dev(struct pci_dev *pdev,
+ struct eeh_dev **pedev,
+ struct eeh_pe **ppe)
+{
+ struct eeh_dev *edev;
+
+ /* No device ? */
+ if (!pdev)
+ return -ENODEV;
+
+ edev = pci_dev_to_eeh_dev(pdev);
+ if (!edev || !eeh_dev_passed(edev) ||
+ !edev-pe || !eeh_pe_passed(edev-pe))
+ return -ENODEV;
+
+ if (pedev)
+ *pedev = edev;
+ if (ppe)
+ *ppe = edev-pe;
+
+ return 0;
+}
+
+int eeh_vfio_set_pe_option(struct pci_dev *pdev, int option, int *retval)
+{
+ struct
Re: [PATCH v5 4/4] powerpc/eeh: Avoid event on passed PE
On 21.05.14 07:03, Gavin Shan wrote:
If we detects frozen state on PE that has been passed to guest, we
needn't handle it. Instead, we rely on the guest to detect and recover
it. The patch avoid EEH event on the frozen passed PE so that the guest
can have chance to handle that.
Signed-off-by: Gavin Shan gws...@linux.vnet.ibm.com
---
arch/powerpc/kernel/eeh.c | 8
arch/powerpc/platforms/powernv/eeh-ioda.c | 3 ++-
2 files changed, 10 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/kernel/eeh.c b/arch/powerpc/kernel/eeh.c
index 2aaf90e..25fd12d 100644
--- a/arch/powerpc/kernel/eeh.c
+++ b/arch/powerpc/kernel/eeh.c
@@ -400,6 +400,14 @@ int eeh_dev_check_failure(struct eeh_dev *edev)
if (ret 0)
return ret;
+ /*
+* If the PE has been passed to guest, we won't check the
+* state. Instead, let the guest handle it if the PE has
What guest? The kernel doesn't care whether we use VFIO for a guest or not.
Alex
+* been frozen.
+*/
+ if (eeh_pe_passed(pe))
+ return 0;
+
/* If we already have a pending isolation event for this
* slot, we know it's bad already, we don't need to check.
* Do this checking under a lock; as multiple PCI devices
diff --git a/arch/powerpc/platforms/powernv/eeh-ioda.c
b/arch/powerpc/platforms/powernv/eeh-ioda.c
index 1b5982f..03a3ed2 100644
--- a/arch/powerpc/platforms/powernv/eeh-ioda.c
+++ b/arch/powerpc/platforms/powernv/eeh-ioda.c
@@ -890,7 +890,8 @@ static int ioda_eeh_next_error(struct eeh_pe **pe)
opal_pci_eeh_freeze_clear(phb-opal_id,
frozen_pe_no,
OPAL_EEH_ACTION_CLEAR_FREEZE_ALL);
ret = EEH_NEXT_ERR_NONE;
- } else if ((*pe)-state EEH_PE_ISOLATED) {
+ } else if ((*pe)-state EEH_PE_ISOLATED ||
+ eeh_pe_passed(*pe)) {
ret = EEH_NEXT_ERR_NONE;
} else {
pr_err(EEH: Frozen PHB#%x-PE#%x (%s)
detected\n,
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH V4 0/2] mm: FAULT_AROUND_ORDER patchset performance data for powerpc
Andrew Morton wrote:
On Tue, 20 May 2014 13:27:38 +0300 (EEST) Kirill A. Shutemov
kirill.shute...@linux.intel.com wrote:
Rusty Russell wrote:
Kirill A. Shutemov kirill.shute...@linux.intel.com writes:
Andrew Morton wrote:
On Mon, 19 May 2014 16:23:07 -0700 (PDT) Hugh Dickins
hu...@google.com wrote:
Shouldn't FAULT_AROUND_ORDER and fault_around_order be changed to be
the order of the fault-around size in bytes, and fault_around_pages()
use 1UL (fault_around_order - PAGE_SHIFT)
Yes. And shame on me for missing it (this time!) at review.
There's still time to fix this. Patches, please.
Here it is. Made at 3.30 AM, build tested only.
Prefer on top of Maddy's patch which makes it always a variable, rather
than CONFIG_DEBUG_FS. It's got enough hair as it is.
Something like this?
This appears to be against mainline, not against Madhavan's patch. As
mentioned previously, I'd prefer it that way but confused.
From: Kirill A. Shutemov kirill.shute...@linux.intel.com
Date: Tue, 20 May 2014 13:02:03 +0300
Subject: [PATCH] mm: nominate faultaround area in bytes rather then page
order
There are evidences that faultaround feature is less relevant on
architectures with page size bigger then 4k. Which makes sense since
page fault overhead per byte of mapped area should be less there.
Let's rework the feature to specify faultaround area in bytes instead of
page order. It's 64 kilobytes for now.
The patch effectively disables faultaround on architectures with
page size = 64k (like ppc64).
It's possible that some other size of faultaround area is relevant for a
platform. We can expose `fault_around_bytes' variable to arch-specific
code once such platforms will be found.
Signed-off-by: Kirill A. Shutemov kirill.shute...@linux.intel.com
---
mm/memory.c | 62
+++--
1 file changed, 23 insertions(+), 39 deletions(-)
diff --git a/mm/memory.c b/mm/memory.c
index 037b812a9531..252b319e8cdf 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -3402,63 +3402,47 @@ void do_set_pte(struct vm_area_struct *vma,
unsigned long address,
update_mmu_cache(vma, address, pte);
}
-#define FAULT_AROUND_ORDER 4
+static unsigned long fault_around_bytes = 65536;
+
+static inline unsigned long fault_around_pages(void)
+{
+ return rounddown_pow_of_two(fault_around_bytes) / PAGE_SIZE;
+}
I think we should round up, not down. So if the user asks for 1kb,
they get one page.
So this becomes
return PAGE_ALIGN(fault_around_bytes) / PAGE_SIZE;
See below.
+static inline unsigned long fault_around_mask(void)
+{
+ return ~(rounddown_pow_of_two(fault_around_bytes) - 1) PAGE_MASK;
+}
And this has me a bit stumped. It's not helpful that do_fault_around()
is undocumented. Does it fault in N/2 pages ahead and N/2 pages
behind? Or does it align the address down to the highest multiple of
fault_around_bytes? It appears to be the latter, so the location of
the faultaround window around the fault address is basically random,
depending on what address userspace happened to pick. I don't know why
we did this :(
When we call -map_pages() we need to make sure that we stay within VMA
and the page table. We don't want to cross page table boundary, because
page table is what ptlock covers in split ptlock case.
I've designed the feature with fault area nominated in page order in mind
and I found it's easier to make sure we don't cross boundaries, if we
would align virtual address of fault around area to PAGE_SIZE
FAULT_AROUND_ORDER.
And yes fault address may be anywhere within the area. You can think about
this as a virtual page with size PAGE_SIZE FAULT_AROUND_ORDER: no matter
what is fault address, we handle area naturally aligned to page size which
fault address belong to.
I've used rounddown_pow_of_two() in the patch to align to nearest page
order, not to page size, because that's what current do_fault_around()
expect to see. And roundup is not an option: nobody expects fault around
area to be 128k if fault_around_bytes set to 64k + 1 bytes.
If you think we need this I can rework do_fault_around() to handle
non-pow-of-two fault_around_pages(), but I don't think it's good idea to
do this for v3.15. Anyway, patch I've proposed allows change
fault_around_bytes only from DEBUG_FS and roundown should be good
enough there.
Or something. Can we please get some code commentary over
do_fault_around() describing this design decision and explaining the
reasoning behind it?
I'll do this. But if do_fault_around() rework is needed, I want to do that
first.
Also, neast is not a word.
:facepalm:
From: Kirill A. Shutemov kirill.shute...@linux.intel.com
Date: Wed, 21 May 2014 16:36:42 +0300
Subject: [PATCH] mm: fix typo in comment in do_fault_around()
Signed-off-by: Kirill A. Shutemov
Re: Node 0 not necessary for powerpc?
On Mon, 19 May 2014, Nishanth Aravamudan wrote: I'm seeing a panic at boot with this change on an LPAR which actually has no Node 0. Here's what I think is happening: start_kernel ... - setup_per_cpu_areas - pcpu_embed_first_chunk - pcpu_fc_alloc - ___alloc_bootmem_node(NODE_DATA(cpu_to_node(cpu), ... - smp_prepare_boot_cpu - set_numa_node(boot_cpuid) So we panic on the NODE_DATA call. It seems that ia64, at least, uses pcpu_alloc_first_chunk rather than embed. x86 has some code to handle early calls of cpu_to_node (early_cpu_to_node) and sets the mapping for all CPUs in setup_per_cpu_areas(). Maybe we can switch ia64 too embed? Tejun: Why are there these dependencies? Thoughts? Does that mean we need something similar to x86 for powerpc? Tejun is the expert in this area. CCing him. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc: fix typo 'CONFIG_PMAC'
Paul Bolle pebo...@tiscali.nl writes: Commit b0d278b7d3ae (powerpc/perf_event: Reduce latency of calling perf_event_do_pending) added a check for CONFIG_PMAC were a check for CONFIG_PPC_PMAC was clearly intended. Fixes: b0d278b7d3ae (powerpc/perf_event: Reduce latency of calling perf_event_do_pending) Signed-off-by: Paul Bolle pebo...@tiscali.nl --- Untested. Needs testing on 32 bit powermac, I guess. This typo was introduced in v2.6.36. No one noticed because very few people still use 32 bit powermacs? How does that bug manifest itself? Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 And now for something completely different. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Node 0 not necessary for powerpc?
Hello, On Wed, May 21, 2014 at 09:16:27AM -0500, Christoph Lameter wrote: On Mon, 19 May 2014, Nishanth Aravamudan wrote: I'm seeing a panic at boot with this change on an LPAR which actually has no Node 0. Here's what I think is happening: start_kernel ... - setup_per_cpu_areas - pcpu_embed_first_chunk - pcpu_fc_alloc - ___alloc_bootmem_node(NODE_DATA(cpu_to_node(cpu), ... - smp_prepare_boot_cpu - set_numa_node(boot_cpuid) So we panic on the NODE_DATA call. It seems that ia64, at least, uses pcpu_alloc_first_chunk rather than embed. x86 has some code to handle early calls of cpu_to_node (early_cpu_to_node) and sets the mapping for all CPUs in setup_per_cpu_areas(). Maybe we can switch ia64 too embed? Tejun: Why are there these dependencies? Thoughts? Does that mean we need something similar to x86 for powerpc? I'm missing context to properly understand what's going on but the specific allocator in use shouldn't matter. e.g. x86 can use both embed and page allocators. If the problem is that the arch is accessing percpu memory before percpu allocator is initialized and the problem was masked before somehow, the right thing to do would be removing those premature percpu accesses. If early percpu variables are really necessary, doing similar early_percpu thing as in x86 would be necessary. Thanks. -- tejun ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Node 0 not necessary for powerpc?
Hi Tejun, On 21.05.2014 [14:58:12 -0400], Tejun Heo wrote: Hello, On Wed, May 21, 2014 at 09:16:27AM -0500, Christoph Lameter wrote: On Mon, 19 May 2014, Nishanth Aravamudan wrote: I'm seeing a panic at boot with this change on an LPAR which actually has no Node 0. Here's what I think is happening: start_kernel ... - setup_per_cpu_areas - pcpu_embed_first_chunk - pcpu_fc_alloc - ___alloc_bootmem_node(NODE_DATA(cpu_to_node(cpu), ... - smp_prepare_boot_cpu - set_numa_node(boot_cpuid) So we panic on the NODE_DATA call. It seems that ia64, at least, uses pcpu_alloc_first_chunk rather than embed. x86 has some code to handle early calls of cpu_to_node (early_cpu_to_node) and sets the mapping for all CPUs in setup_per_cpu_areas(). Maybe we can switch ia64 too embed? Tejun: Why are there these dependencies? Thoughts? Does that mean we need something similar to x86 for powerpc? I'm missing context to properly understand what's going on but the specific allocator in use shouldn't matter. e.g. x86 can use both embed and page allocators. If the problem is that the arch is accessing percpu memory before percpu allocator is initialized and the problem was masked before somehow, the right thing to do would be removing those premature percpu accesses. If early percpu variables are really necessary, doing similar early_percpu thing as in x86 would be necessary. For context: I was looking at why N_ONLINE was statically setting Node 0 to be online, whether or not the topology is that way -- I've been getting several bugs lately where Node 0 is online, but has no CPUs and no memory on it, on powerpc. On powerpc, setup_per_cpu_areas calls into ___alloc_bootmem_node using NODE_DATA(cpu_to_node(cpu)). Currently, cpu_to_node() in arch/powerpc/include/asm/topology.h does: /* * During early boot, the numa-cpu lookup table might not have been * setup for all CPUs yet. In such cases, default to node 0. */ return (nid 0) ? 0 : nid; And so early at boot, if node 0 is not present, we end up accessing an unitialized NODE_DATA(). So this seems buggy (I'll contact the powerpc deveopers separately on that). I recently submitted patches to have powerpc turn on USE_PERCPU_NUMA_NODEID and HAVE_MEMORYLESS_NODES. But then, cpu_to_node will be accessing percpu data in setup_per_cpu_areas, which seems like a no-no. And more specifically, since we haven't yet run smp_prepare_boot_cpu() at this point, cpu_to_node has not yet been initialized to provide a sane value. Thanks, Nish ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
NUMA topology question wrt. d4edc5b6
Hi Srivatsa,
After d4edc5b6 (powerpc: Fix the setup of CPU-to-Node mappings during
CPU online), cpu_to_node() looks like:
static inline int cpu_to_node(int cpu)
{
int nid;
nid = numa_cpu_lookup_table[cpu];
/*
* During early boot, the numa-cpu lookup table might not have been
* setup for all CPUs yet. In such cases, default to node 0.
*/
return (nid 0) ? 0 : nid;
}
However, I'm curious if this is correct in all cases. I have seen
several LPARs that do not have any CPUs on node 0. In fact, because node
0 is statically set online in the initialization of the N_ONLINE
nodemask, 0 is always present to Linux, whether it is present on the
system. I'm not sure what the best thing to do here is, but I'm curious
if you have any ideas? I would like to remove the static initialization
of node 0, as it's confusing to users to see an empty node (particularly
when it's completely separate in the numbering from other nodes), but
we trip a panic (refer to:
http://www.spinics.net/lists/linux-mm/msg73321.html).
Thanks,
Nish
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH V4 0/2] mm: FAULT_AROUND_ORDER patchset performance data for powerpc
On Wed, 21 May 2014 16:40:27 +0300 (EEST) Kirill A. Shutemov kirill.shute...@linux.intel.com wrote: Or something. Can we please get some code commentary over do_fault_around() describing this design decision and explaining the reasoning behind it? I'll do this. But if do_fault_around() rework is needed, I want to do that first. This sort of thing should be at least partially driven by observation and I don't have the data for that. My seat of the pants feel is that after the first fault, accesses at higher addresses are more common/probable than accesses at lower addresses. In which case we should see improvements by centering the window at some higher address than the fault. Much instrumentation and downstream analysis is needed and the returns will be pretty small! But we don't need to do all that right now. Let's get the current implementation wrapped up for 3.15: get the interface finalized (bytes, not pages!) and get the current design decisions appropriately documented. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/2] mtd/spi: support en25s64 device
On Wed, 2014-05-21 at 18:05 +0800, Shengzhou Liu wrote:
Add support for EON en25s64 spi device.
Signed-off-by: Shengzhou Liu shengzhou@freescale.com
---
drivers/mtd/devices/m25p80.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/mtd/devices/m25p80.c b/drivers/mtd/devices/m25p80.c
index 7eda71d..6989311 100644
--- a/drivers/mtd/devices/m25p80.c
+++ b/drivers/mtd/devices/m25p80.c
@@ -745,6 +745,7 @@ static const struct spi_device_id m25p_ids[] = {
{ en25q32b, INFO(0x1c3016, 0, 64 * 1024, 64, 0) },
{ en25p64,INFO(0x1c2017, 0, 64 * 1024, 128, 0) },
{ en25q64,INFO(0x1c3017, 0, 64 * 1024, 128, SECT_4K) },
+ { en25s64,INFO(0x1c3817, 0, 64 * 1024, 128, 0) },
{ en25qh256, INFO(0x1c7019, 0, 64 * 1024, 512, 0) },
/* ESMT */
This needs to be sent to the mtd and/or spi maintainers, not here.
What does this have to do with patch 2/2? Don't put unrelated things in
the same patchset, especially when they're destined for different
maintainers.
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH RESEND 0/9 net-next] net: of_phy_connect_fixed_link removal
Hi all, This patch set removes of_phy_connect_fixed_link() from the tree now that we have a better solution for dealing with fixed PHY (emulated PHY) devices for drivers that require them. First two patches update the 'fixed-link' Device Tree binding and drivers to refere to it. Patches 3 to 7 update the in-tree network drivers that use of_phy_connect_fixed_link() Patch 8 removes of_phy_connect_fixed_link Patch 9 removes the PowerPC code that parsed the 'fixed-link' property. Patch 9 can be merged via the net-next tree if the PowerPC folks ack it, but it really has to be merged after the first 8 patches in order to avoid breakage. Florian Fainelli (9): Documentation: devicetree: add old and deprecated 'fixed-link' Documentation: devicetree: net: refer to fixed-link.txt net: bcmgenet: use the new fixed PHY helpers net: systemport: use the new fixed PHY helpers fs_enet: use the new fixed PHY helpers gianfar: use the new fixed PHY helpers ucc_geth: use the new fixed PHY helpers of: mdio: remove of_phy_connect_fixed_link powerpc/fsl: fsl_soc: remove 'fixed-link' parsing code .../devicetree/bindings/net/broadcom-bcmgenet.txt | 2 +- .../bindings/net/broadcom-systemport.txt | 2 +- .../devicetree/bindings/net/fixed-link.txt | 12 +++ .../devicetree/bindings/net/fsl-tsec-phy.txt | 5 +-- arch/powerpc/sysdev/fsl_soc.c | 32 -- drivers/net/ethernet/broadcom/bcmsysport.c | 17 -- drivers/net/ethernet/broadcom/bcmsysport.h | 1 + drivers/net/ethernet/broadcom/genet/bcmmii.c | 21 +++- .../net/ethernet/freescale/fs_enet/fs_enet-main.c | 16 + drivers/net/ethernet/freescale/gianfar.c | 14 ++-- drivers/net/ethernet/freescale/ucc_geth.c | 14 ++-- drivers/of/of_mdio.c | 38 -- include/linux/of_mdio.h| 10 -- 13 files changed, 75 insertions(+), 109 deletions(-) -- 1.9.1 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH RESEND net-next 1/9] Documentation: devicetree: add old and deprecated 'fixed-link'
Update the fixed-link Device Tree binding documentation to contain
information about the old and deprecated 5-digit 'fixed-link' property.
Signed-off-by: Florian Fainelli f.faine...@gmail.com
---
Documentation/devicetree/bindings/net/fixed-link.txt | 12
1 file changed, 12 insertions(+)
diff --git a/Documentation/devicetree/bindings/net/fixed-link.txt
b/Documentation/devicetree/bindings/net/fixed-link.txt
index e956de1be935..34a991eb213f 100644
--- a/Documentation/devicetree/bindings/net/fixed-link.txt
+++ b/Documentation/devicetree/bindings/net/fixed-link.txt
@@ -18,6 +18,18 @@ properties:
* 'asym-pause' (boolean, optional), to indicate that asym_pause should
be enabled.
+Old, deprecated 'fixed-link' binding:
+
+* A 'fixed-link' property in the EThernet MAC node, with 5 cells, of the
+ form a b c d e with the following accepted values:
+ - a: emulated phy id, choose any but but unique to the all specified
+fixed-links, from 0 to 31
+ - b: duplex configuration: 0 for half duplex, 1 for full duplex
+ - c: link speed in Mbits/sec, accepted values are: 10, 100 and 1000
+ - d: pause configuration: 0 for no pause, 1 for pause
+ - e: asymetric pause configuration: 0 for no asymetric pause, 1 for asymetric
+pause
+
Example:
ethernet@0 {
--
1.9.1
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH RESEND net-next 2/9] Documentation: devicetree: net: refer to fixed-link.txt
Update the Freescale TSEC PHY, Broadcom GENET SYSTEMPORT Device Tree binding documentation to refer to the fixed-link Device Tree binding in fixed-link.txt. Reviewed-by: Thomas Petazzoni thomas.petazz...@free-electrons.com Signed-off-by: Florian Fainelli f.faine...@gmail.com --- Documentation/devicetree/bindings/net/broadcom-bcmgenet.txt | 2 +- Documentation/devicetree/bindings/net/broadcom-systemport.txt | 2 +- Documentation/devicetree/bindings/net/fsl-tsec-phy.txt| 5 + 3 files changed, 3 insertions(+), 6 deletions(-) diff --git a/Documentation/devicetree/bindings/net/broadcom-bcmgenet.txt b/Documentation/devicetree/bindings/net/broadcom-bcmgenet.txt index f2febb94550e..451fef26b4df 100644 --- a/Documentation/devicetree/bindings/net/broadcom-bcmgenet.txt +++ b/Documentation/devicetree/bindings/net/broadcom-bcmgenet.txt @@ -24,7 +24,7 @@ Optional properties: - fixed-link: When the GENET interface is connected to a MoCA hardware block or when operating in a RGMII to RGMII type of connection, or when the MDIO bus is voluntarily disabled, this property should be used to describe the fixed link. - See Documentation/devicetree/bindings/net/fsl-tsec-phy.txt for information on + See Documentation/devicetree/bindings/net/fixed-link.txt for information on the property specifics Required child nodes: diff --git a/Documentation/devicetree/bindings/net/broadcom-systemport.txt b/Documentation/devicetree/bindings/net/broadcom-systemport.txt index 1b7600e022dd..c183ea90d9bc 100644 --- a/Documentation/devicetree/bindings/net/broadcom-systemport.txt +++ b/Documentation/devicetree/bindings/net/broadcom-systemport.txt @@ -8,7 +8,7 @@ Required properties: - local-mac-address: Ethernet MAC address (48 bits) of this adapter - phy-mode: Should be a string describing the PHY interface to the Ethernet switch/PHY, see Documentation/devicetree/bindings/net/ethernet.txt -- fixed-link: see Documentation/devicetree/bindings/net/fsl-tsec-phy.txt for +- fixed-link: see Documentation/devicetree/bindings/net/fixed-link.txt for the property specific details Optional properties: diff --git a/Documentation/devicetree/bindings/net/fsl-tsec-phy.txt b/Documentation/devicetree/bindings/net/fsl-tsec-phy.txt index 737cdef4f903..be6ea8960f20 100644 --- a/Documentation/devicetree/bindings/net/fsl-tsec-phy.txt +++ b/Documentation/devicetree/bindings/net/fsl-tsec-phy.txt @@ -42,10 +42,7 @@ Properties: interrupt. For TSEC and eTSEC devices, the first interrupt is transmit, the second is receive, and the third is error. - phy-handle : See ethernet.txt file in the same directory. - - fixed-link : a b c d e where a is emulated phy id - choose any, -but unique to the all specified fixed-links, b is duplex - 0 half, -1 full, c is link speed - d#10/d#100/d#1000, d is pause - 0 no -pause, 1 pause, e is asym_pause - 0 no asym_pause, 1 asym_pause. + - fixed-link : See fixed-link.txt in the same directory. - phy-connection-type : See ethernet.txt file in the same directory. This property is only really needed if the connection is of type rgmii-id, as all other connection types are detected by hardware. -- 1.9.1 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH RESEND net-next 3/9] net: bcmgenet: use the new fixed PHY helpers
of_phy_connect_fixed_link() is becoming obsolete, and also required
platform code to register the fixed PHYs at the specified addresses for
those to be usable. Get rid of it and use the new of_phy_is_fixed_link()
plus of_phy_register_fixed_link() helpers to transition over the new
scheme.
Signed-off-by: Florian Fainelli f.faine...@gmail.com
---
drivers/net/ethernet/broadcom/genet/bcmmii.c | 21 +
1 file changed, 13 insertions(+), 8 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/genet/bcmmii.c
b/drivers/net/ethernet/broadcom/genet/bcmmii.c
index 4608673beaff..add8d8596084 100644
--- a/drivers/net/ethernet/broadcom/genet/bcmmii.c
+++ b/drivers/net/ethernet/broadcom/genet/bcmmii.c
@@ -298,6 +298,7 @@ int bcmgenet_mii_config(struct net_device *dev)
static int bcmgenet_mii_probe(struct net_device *dev)
{
struct bcmgenet_priv *priv = netdev_priv(dev);
+ struct device_node *dn = priv-pdev-dev.of_node;
struct phy_device *phydev;
unsigned int phy_flags;
int ret;
@@ -307,15 +308,19 @@ static int bcmgenet_mii_probe(struct net_device *dev)
return 0;
}
- if (priv-phy_dn)
- phydev = of_phy_connect(dev, priv-phy_dn,
- bcmgenet_mii_setup, 0,
- priv-phy_interface);
- else
- phydev = of_phy_connect_fixed_link(dev,
- bcmgenet_mii_setup,
- priv-phy_interface);
+ /* In the case of a fixed PHY, the DT node associated
+* to the PHY is the Ethernet MAC DT node.
+*/
+ if (of_phy_is_fixed_link(dn)) {
+ ret = of_phy_register_fixed_link(dn);
+ if (ret)
+ return ret;
+
+ priv-phy_dn = dn;
+ }
+ phydev = of_phy_connect(dev, priv-phy_dn, bcmgenet_mii_setup, 0,
+ priv-phy_interface);
if (!phydev) {
pr_err(could not attach to PHY\n);
return -ENODEV;
--
1.9.1
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH RESEND net-next 4/9] net: systemport: use the new fixed PHY helpers
of_phy_connect_fixed_link() is becoming obsolete, and also required
platform code to register the fixed PHYs at the specified addresses for
those to be usable. Get rid of it and use the new of_phy_is_fixed_link()
plus of_phy_register_fixed_link() helpers to transition over the new
scheme.
Signed-off-by: Florian Fainelli f.faine...@gmail.com
---
drivers/net/ethernet/broadcom/bcmsysport.c | 17 +++--
drivers/net/ethernet/broadcom/bcmsysport.h | 1 +
2 files changed, 16 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/bcmsysport.c
b/drivers/net/ethernet/broadcom/bcmsysport.c
index d40c5b969e9e..dc708a888f80 100644
--- a/drivers/net/ethernet/broadcom/bcmsysport.c
+++ b/drivers/net/ethernet/broadcom/bcmsysport.c
@@ -1327,8 +1327,8 @@ static int bcm_sysport_open(struct net_device *dev)
/* Read CRC forward */
priv-crc_fwd = !!(umac_readl(priv, UMAC_CMD) CMD_CRC_FWD);
- priv-phydev = of_phy_connect_fixed_link(dev, bcm_sysport_adj_link,
- priv-phy_interface);
+ priv-phydev = of_phy_connect(dev, priv-phy_dn, bcm_sysport_adj_link,
+ 0, priv-phy_interface);
if (!priv-phydev) {
netdev_err(dev, could not attach to PHY\n);
return -ENODEV;
@@ -1551,6 +1551,19 @@ static int bcm_sysport_probe(struct platform_device
*pdev)
if (priv-phy_interface 0)
priv-phy_interface = PHY_INTERFACE_MODE_GMII;
+ /* In the case of a fixed PHY, the DT node associated
+* to the PHY is the Ethernet MAC DT node.
+*/
+ if (of_phy_is_fixed_link(dn)) {
+ ret = of_phy_register_fixed_link(dn);
+ if (ret) {
+ dev_err(pdev-dev, failed to register fixed PHY\n);
+ goto err;
+ }
+
+ priv-phy_dn = dn;
+ }
+
/* Initialize netdevice members */
macaddr = of_get_mac_address(dn);
if (!macaddr || !is_valid_ether_addr(macaddr)) {
diff --git a/drivers/net/ethernet/broadcom/bcmsysport.h
b/drivers/net/ethernet/broadcom/bcmsysport.h
index abdeb62616df..73fd04a94797 100644
--- a/drivers/net/ethernet/broadcom/bcmsysport.h
+++ b/drivers/net/ethernet/broadcom/bcmsysport.h
@@ -656,6 +656,7 @@ struct bcm_sysport_priv {
unsigned intrx_c_index;
/* PHY device */
+ struct device_node *phy_dn;
struct phy_device *phydev;
phy_interface_t phy_interface;
int old_pause;
--
1.9.1
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH RESEND net-next 5/9] fs_enet: use the new fixed PHY helpers
of_phy_connect_fixed_link() is becoming obsolete, and also required
platform code to register the fixed PHYs at the specified addresses for
those to be usable. Get rid of it and use the new of_phy_is_fixed_link()
plus of_phy_register_fixed_link() helpers to transition over the new
scheme.
Signed-off-by: Florian Fainelli f.faine...@gmail.com
---
drivers/net/ethernet/freescale/fs_enet/fs_enet-main.c | 16 +---
1 file changed, 9 insertions(+), 7 deletions(-)
diff --git a/drivers/net/ethernet/freescale/fs_enet/fs_enet-main.c
b/drivers/net/ethernet/freescale/fs_enet/fs_enet-main.c
index dc80db41d6b3..d602711e00e9 100644
--- a/drivers/net/ethernet/freescale/fs_enet/fs_enet-main.c
+++ b/drivers/net/ethernet/freescale/fs_enet/fs_enet-main.c
@@ -792,10 +792,6 @@ static int fs_init_phy(struct net_device *dev)
phydev = of_phy_connect(dev, fep-fpi-phy_node, fs_adjust_link, 0,
iface);
if (!phydev) {
- phydev = of_phy_connect_fixed_link(dev, fs_adjust_link,
- iface);
- }
- if (!phydev) {
dev_err(dev-dev, Could not attach to PHY\n);
return -ENODEV;
}
@@ -1029,9 +1025,15 @@ static int fs_enet_probe(struct platform_device *ofdev)
fpi-use_napi = 1;
fpi-napi_weight = 17;
fpi-phy_node = of_parse_phandle(ofdev-dev.of_node, phy-handle, 0);
- if ((!fpi-phy_node) (!of_get_property(ofdev-dev.of_node,
fixed-link,
- NULL)))
- goto out_free_fpi;
+ if (!fpi-phy_node) {
+ if (of_phy_is_fixed_link(ofdev-dev.of_node)) {
+ err = of_phy_register_fixed_link(ofdev-dev.of_node);
+ if (err)
+ goto out_free_fpi;
+
+ fpi-phy_node = ofdev-dev.of_node;
+ }
+ }
if (of_device_is_compatible(ofdev-dev.of_node, fsl,mpc5125-fec)) {
phy_connection_type = of_get_property(ofdev-dev.of_node,
--
1.9.1
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH RESEND net-next 6/9] gianfar: use the new fixed PHY helpers
of_phy_connect_fixed_link() is becoming obsolete, and also required
platform code to register the fixed PHYs at the specified addresses for
those to be usable. Get rid of it and use the new of_phy_is_fixed_link()
plus of_phy_register_fixed_link() helpers to transition over the new
scheme.
Signed-off-by: Florian Fainelli f.faine...@gmail.com
---
drivers/net/ethernet/freescale/gianfar.c | 14 +++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/freescale/gianfar.c
b/drivers/net/ethernet/freescale/gianfar.c
index e2d42475b006..282674027c92 100644
--- a/drivers/net/ethernet/freescale/gianfar.c
+++ b/drivers/net/ethernet/freescale/gianfar.c
@@ -889,6 +889,17 @@ static int gfar_of_init(struct platform_device *ofdev,
struct net_device **pdev)
priv-phy_node = of_parse_phandle(np, phy-handle, 0);
+ /* In the case of a fixed PHY, the DT node associated
+* to the PHY is the Ethernet MAC DT node.
+*/
+ if (of_phy_is_fixed_link(np)) {
+ err = of_phy_register_fixed_link(np);
+ if (err)
+ goto err_grp_init;
+
+ priv-phy_node = np;
+ }
+
/* Find the TBI PHY. If it's not there, we don't support SGMII */
priv-tbi_node = of_parse_phandle(np, tbi-handle, 0);
@@ -1660,9 +1671,6 @@ static int init_phy(struct net_device *dev)
priv-phydev = of_phy_connect(dev, priv-phy_node, adjust_link, 0,
interface);
- if (!priv-phydev)
- priv-phydev = of_phy_connect_fixed_link(dev, adjust_link,
-interface);
if (!priv-phydev) {
dev_err(dev-dev, could not attach to PHY\n);
return -ENODEV;
--
1.9.1
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH RESEND net-next 7/9] ucc_geth: use the new fixed PHY helpers
of_phy_connect_fixed_link() is becoming obsolete, and also required
platform code to register the fixed PHYs at the specified addresses for
those to be usable. Get rid of it and use the new of_phy_is_fixed_link()
plus of_phy_register_fixed_link() helpers to transition over the new
scheme.
Signed-off-by: Florian Fainelli f.faine...@gmail.com
---
drivers/net/ethernet/freescale/ucc_geth.c | 14 +++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/freescale/ucc_geth.c
b/drivers/net/ethernet/freescale/ucc_geth.c
index c8299c31b21f..fab39e295441 100644
--- a/drivers/net/ethernet/freescale/ucc_geth.c
+++ b/drivers/net/ethernet/freescale/ucc_geth.c
@@ -1728,9 +1728,6 @@ static int init_phy(struct net_device *dev)
phydev = of_phy_connect(dev, ug_info-phy_node, adjust_link, 0,
priv-phy_interface);
- if (!phydev)
- phydev = of_phy_connect_fixed_link(dev, adjust_link,
- priv-phy_interface);
if (!phydev) {
dev_err(dev-dev, Could not attach to PHY\n);
return -ENODEV;
@@ -3790,6 +3787,17 @@ static int ucc_geth_probe(struct platform_device* ofdev)
ug_info-uf_info.irq = irq_of_parse_and_map(np, 0);
ug_info-phy_node = of_parse_phandle(np, phy-handle, 0);
+ if (!ug_info-phy_node) {
+ /* In the case of a fixed PHY, the DT node associated
+* to the PHY is the Ethernet MAC DT node.
+*/
+ if (of_phy_is_fixed_link(np)) {
+ err = of_phy_register_fixed_link(np);
+ if (err)
+ return err;
+ }
+ ug_info-phy_node = np;
+ }
/* Find the TBI PHY node. If it's not there, we don't support SGMII */
ug_info-tbi_node = of_parse_phandle(np, tbi-handle, 0);
--
1.9.1
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH RESEND net-next 8/9] of: mdio: remove of_phy_connect_fixed_link
All in-tree drivers have been converted to use the new pair of
functions: of_is_fixed_phy_link() plus of_phy_register_fixed_link(), we
can now safely remove of_phy_connect_fixed_link.
Signed-off-by: Florian Fainelli f.faine...@gmail.com
---
drivers/of/of_mdio.c| 38 --
include/linux/of_mdio.h | 10 --
2 files changed, 48 deletions(-)
diff --git a/drivers/of/of_mdio.c b/drivers/of/of_mdio.c
index 1def0bb5cb37..4c1e01ed16dc 100644
--- a/drivers/of/of_mdio.c
+++ b/drivers/of/of_mdio.c
@@ -246,44 +246,6 @@ struct phy_device *of_phy_connect(struct net_device *dev,
EXPORT_SYMBOL(of_phy_connect);
/**
- * of_phy_connect_fixed_link - Parse fixed-link property and return a dummy phy
- * @dev: pointer to net_device claiming the phy
- * @hndlr: Link state callback for the network device
- * @iface: PHY data interface type
- *
- * This function is a temporary stop-gap and will be removed soon. It is
- * only to support the fs_enet, ucc_geth and gianfar Ethernet drivers. Do
- * not call this function from new drivers.
- */
-struct phy_device *of_phy_connect_fixed_link(struct net_device *dev,
-void (*hndlr)(struct net_device *),
-phy_interface_t iface)
-{
- struct device_node *net_np;
- char bus_id[MII_BUS_ID_SIZE + 3];
- struct phy_device *phy;
- const __be32 *phy_id;
- int sz;
-
- if (!dev-dev.parent)
- return NULL;
-
- net_np = dev-dev.parent-of_node;
- if (!net_np)
- return NULL;
-
- phy_id = of_get_property(net_np, fixed-link, sz);
- if (!phy_id || sz sizeof(*phy_id))
- return NULL;
-
- sprintf(bus_id, PHY_ID_FMT, fixed-0, be32_to_cpu(phy_id[0]));
-
- phy = phy_connect(dev, bus_id, hndlr, iface);
- return IS_ERR(phy) ? NULL : phy;
-}
-EXPORT_SYMBOL(of_phy_connect_fixed_link);
-
-/**
* of_phy_attach - Attach to a PHY without starting the state machine
* @dev: pointer to net_device claiming the phy
* @phy_np: Node pointer for the PHY
diff --git a/include/linux/of_mdio.h b/include/linux/of_mdio.h
index 0aa367e316cb..d449018d0726 100644
--- a/include/linux/of_mdio.h
+++ b/include/linux/of_mdio.h
@@ -22,9 +22,6 @@ extern struct phy_device *of_phy_connect(struct net_device
*dev,
struct phy_device *of_phy_attach(struct net_device *dev,
struct device_node *phy_np, u32 flags,
phy_interface_t iface);
-extern struct phy_device *of_phy_connect_fixed_link(struct net_device *dev,
-void (*hndlr)(struct net_device *),
-phy_interface_t iface);
extern struct mii_bus *of_mdio_find_bus(struct device_node *mdio_np);
@@ -59,13 +56,6 @@ static inline struct phy_device *of_phy_attach(struct
net_device *dev,
return NULL;
}
-static inline struct phy_device *of_phy_connect_fixed_link(struct net_device
*dev,
- void (*hndlr)(struct
net_device *),
- phy_interface_t
iface)
-{
- return NULL;
-}
-
static inline struct mii_bus *of_mdio_find_bus(struct device_node *mdio_np)
{
return NULL;
--
1.9.1
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH RESEND net-next 9/9] powerpc/fsl: fsl_soc: remove 'fixed-link' parsing code
Parsing and registration of fixed PHY devices was needed with the use of
of_phy_connect_fixed_link() because this function was using the
designated PHY address identifier (first cell of the property) as the
address to bind the PHY on the emulated bus.
Since commit 3be2a49e5c08d268f8af0dd4fe89a24ea8cdc339 (of: provide a
binding for fixed link PHYs) a new pair of functions has been
introduced which allows for dynamic address allocation of these fixed
PHY devices, but also parses the old 'fixed-link' 5-digit property.
Registration of fixed PHY early in platform code was needed because we
could not issue a fixed MDIO bus re-scan within network drivers. The
fixed PHYs had to be registered before the network drivers would call
of_phy_connect_fixed_link(). All of these caveats are solved now, such
that we can safely remove of_add_fixed_phys() now.
Signed-off-by: Florian Fainelli f.faine...@gmail.com
---
arch/powerpc/sysdev/fsl_soc.c | 32
1 file changed, 32 deletions(-)
diff --git a/arch/powerpc/sysdev/fsl_soc.c b/arch/powerpc/sysdev/fsl_soc.c
index 228cf91b91c1..ffd1169ebaab 100644
--- a/arch/powerpc/sysdev/fsl_soc.c
+++ b/arch/powerpc/sysdev/fsl_soc.c
@@ -25,7 +25,6 @@
#include linux/of.h
#include linux/of_platform.h
#include linux/phy.h
-#include linux/phy_fixed.h
#include linux/spi/spi.h
#include linux/fsl_devices.h
#include linux/fs_enet_pd.h
@@ -178,37 +177,6 @@ u32 get_baudrate(void)
EXPORT_SYMBOL(get_baudrate);
#endif /* CONFIG_CPM2 */
-#ifdef CONFIG_FIXED_PHY
-static int __init of_add_fixed_phys(void)
-{
- int ret;
- struct device_node *np;
- u32 *fixed_link;
- struct fixed_phy_status status = {};
-
- for_each_node_by_name(np, ethernet) {
- fixed_link = (u32 *)of_get_property(np, fixed-link, NULL);
- if (!fixed_link)
- continue;
-
- status.link = 1;
- status.duplex = fixed_link[1];
- status.speed = fixed_link[2];
- status.pause = fixed_link[3];
- status.asym_pause = fixed_link[4];
-
- ret = fixed_phy_add(PHY_POLL, fixed_link[0], status);
- if (ret) {
- of_node_put(np);
- return ret;
- }
- }
-
- return 0;
-}
-arch_initcall(of_add_fixed_phys);
-#endif /* CONFIG_FIXED_PHY */
-
#if defined(CONFIG_FSL_SOC_BOOKE) || defined(CONFIG_PPC_86xx)
static __be32 __iomem *rstcr;
--
1.9.1
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH RESEND net-next 1/9] Documentation: devicetree: add old and deprecated 'fixed-link'
Hello. On 05/22/2014 01:38 AM, Florian Fainelli wrote: Update the fixed-link Device Tree binding documentation to contain information about the old and deprecated 5-digit 'fixed-link' property. Signed-off-by: Florian Fainelli f.faine...@gmail.com --- Documentation/devicetree/bindings/net/fixed-link.txt | 12 1 file changed, 12 insertions(+) diff --git a/Documentation/devicetree/bindings/net/fixed-link.txt b/Documentation/devicetree/bindings/net/fixed-link.txt index e956de1be935..34a991eb213f 100644 --- a/Documentation/devicetree/bindings/net/fixed-link.txt +++ b/Documentation/devicetree/bindings/net/fixed-link.txt @@ -18,6 +18,18 @@ properties: * 'asym-pause' (boolean, optional), to indicate that asym_pause should be enabled. +Old, deprecated 'fixed-link' binding: + +* A 'fixed-link' property in the EThernet MAC node, with 5 cells, of the s/EThernet/Ethernet/ + form a b c d e with the following accepted values: + - a: emulated phy id, choose any but but unique to the all specified s/phy id/PHY ID/ +fixed-links, from 0 to 31 + - b: duplex configuration: 0 for half duplex, 1 for full duplex + - c: link speed in Mbits/sec, accepted values are: 10, 100 and 1000 + - d: pause configuration: 0 for no pause, 1 for pause + - e: asymetric pause configuration: 0 for no asymetric pause, 1 for asymetric Asymmetric. WBR, Sergei ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH RESEND net-next 4/9] net: systemport: use the new fixed PHY helpers
On 05/22/2014 01:38 AM, Florian Fainelli wrote: of_phy_connect_fixed_link() is becoming obsolete, and also required platform code to register the fixed PHYs at the specified addresses for those to be usable. Get rid of it and use the new of_phy_is_fixed_link() plus of_phy_register_fixed_link() helpers to transition over the new scheme. Signed-off-by: Florian Fainelli f.faine...@gmail.com --- drivers/net/ethernet/broadcom/bcmsysport.c | 17 +++-- drivers/net/ethernet/broadcom/bcmsysport.h | 1 + 2 files changed, 16 insertions(+), 2 deletions(-) diff --git a/drivers/net/ethernet/broadcom/bcmsysport.c b/drivers/net/ethernet/broadcom/bcmsysport.c index d40c5b969e9e..dc708a888f80 100644 --- a/drivers/net/ethernet/broadcom/bcmsysport.c +++ b/drivers/net/ethernet/broadcom/bcmsysport.c @@ -1327,8 +1327,8 @@ static int bcm_sysport_open(struct net_device *dev) /* Read CRC forward */ priv-crc_fwd = !!(umac_readl(priv, UMAC_CMD) CMD_CRC_FWD); - priv-phydev = of_phy_connect_fixed_link(dev, bcm_sysport_adj_link, - priv-phy_interface); + priv-phydev = of_phy_connect(dev, priv-phy_dn, bcm_sysport_adj_link, + 0, priv-phy_interface); The continuation line should start on the next character after ( on the above line, according to the networking coding style. [...] WBR, Sergei ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v5 3/4] drivers/vfio: EEH support for VFIO PCI device
On Wed, 2014-05-21 at 15:07 +0200, Alexander Graf wrote:
+#ifdef CONFIG_VFIO_PCI_EEH
+int eeh_vfio_open(struct pci_dev *pdev)
Why vfio? Also that config option will not be set if vfio is compiled as
a module.
+{
+ struct eeh_dev *edev;
+
+ /* No PCI device ? */
+ if (!pdev)
+ return -ENODEV;
+
+ /* No EEH device ? */
+ edev = pci_dev_to_eeh_dev(pdev);
+ if (!edev || !edev-pe)
+ return -ENODEV;
+
+ eeh_dev_set_passed(edev, true);
+ eeh_pe_set_passed(edev-pe, true);
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(eeh_vfio_open);
Additionally, shouldn't we have some locking here ? (and in release too)
I don't like relying on the caller locking (if it does it at all).
+ /* Device existing ? */
+ ret = eeh_vfio_check_dev(pdev, edev, pe);
+ if (ret) {
+ pr_debug(%s: Cannot find device %s\n,
+ __func__, pdev ? pci_name(pdev) : NULL);
+ *retval = -7;
What are these? Please use proper kernel internal return values for
errors. I don't want to see anything even remotely tied to RTAS in any
of these patches.
Hint: -ENODEV
Cheers,
Ben.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH RESEND net-next 5/9] fs_enet: use the new fixed PHY helpers
On 05/22/2014 01:38 AM, Florian Fainelli wrote:
of_phy_connect_fixed_link() is becoming obsolete, and also required
platform code to register the fixed PHYs at the specified addresses for
those to be usable. Get rid of it and use the new of_phy_is_fixed_link()
plus of_phy_register_fixed_link() helpers to transition over the new
scheme.
Signed-off-by: Florian Fainelli f.faine...@gmail.com
---
drivers/net/ethernet/freescale/fs_enet/fs_enet-main.c | 16 +---
1 file changed, 9 insertions(+), 7 deletions(-)
diff --git a/drivers/net/ethernet/freescale/fs_enet/fs_enet-main.c
b/drivers/net/ethernet/freescale/fs_enet/fs_enet-main.c
index dc80db41d6b3..d602711e00e9 100644
--- a/drivers/net/ethernet/freescale/fs_enet/fs_enet-main.c
+++ b/drivers/net/ethernet/freescale/fs_enet/fs_enet-main.c
[...]
@@ -1029,9 +1025,15 @@ static int fs_enet_probe(struct platform_device *ofdev)
fpi-use_napi = 1;
fpi-napi_weight = 17;
fpi-phy_node = of_parse_phandle(ofdev-dev.of_node, phy-handle, 0);
- if ((!fpi-phy_node) (!of_get_property(ofdev-dev.of_node,
fixed-link,
- NULL)))
- goto out_free_fpi;
+ if (!fpi-phy_node) {
+ if (of_phy_is_fixed_link(ofdev-dev.of_node)) {
These two *if* statements could be collapsed, reducing the indentation
level below.
+ err = of_phy_register_fixed_link(ofdev-dev.of_node);
+ if (err)
+ goto out_free_fpi;
+
+ fpi-phy_node = ofdev-dev.of_node;
+ }
+ }
WBR, Sergei
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH RESEND net-next 4/9] net: systemport: use the new fixed PHY helpers
2014-05-21 14:55 GMT-07:00 Sergei Shtylyov sergei.shtyl...@cogentembedded.com: On 05/22/2014 01:38 AM, Florian Fainelli wrote: of_phy_connect_fixed_link() is becoming obsolete, and also required platform code to register the fixed PHYs at the specified addresses for those to be usable. Get rid of it and use the new of_phy_is_fixed_link() plus of_phy_register_fixed_link() helpers to transition over the new scheme. Signed-off-by: Florian Fainelli f.faine...@gmail.com --- drivers/net/ethernet/broadcom/bcmsysport.c | 17 +++-- drivers/net/ethernet/broadcom/bcmsysport.h | 1 + 2 files changed, 16 insertions(+), 2 deletions(-) diff --git a/drivers/net/ethernet/broadcom/bcmsysport.c b/drivers/net/ethernet/broadcom/bcmsysport.c index d40c5b969e9e..dc708a888f80 100644 --- a/drivers/net/ethernet/broadcom/bcmsysport.c +++ b/drivers/net/ethernet/broadcom/bcmsysport.c @@ -1327,8 +1327,8 @@ static int bcm_sysport_open(struct net_device *dev) /* Read CRC forward */ priv-crc_fwd = !!(umac_readl(priv, UMAC_CMD) CMD_CRC_FWD); - priv-phydev = of_phy_connect_fixed_link(dev, bcm_sysport_adj_link, - priv-phy_interface); + priv-phydev = of_phy_connect(dev, priv-phy_dn, bcm_sysport_adj_link, + 0, priv-phy_interface); The continuation line should start on the next character after ( on the above line, according to the networking coding style. Unless I am once again not following the coding style, the patch in patchwork has this correctly, and so does my file locally: http://patchwork.ozlabs.org/patch/351323/ -- Florian ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v5 3/4] drivers/vfio: EEH support for VFIO PCI device
On Wed, May 21, 2014 at 03:07:26PM +0200, Alexander Graf wrote:
On 21.05.14 07:03, Gavin Shan wrote:
The patch adds new IOCTL command VFIO_EEH_OP to VFIO PCI device
to support EEH functionality for PCI devices, which have been
passed from host to guest via VFIO.
Signed-off-by: Gavin Shan gws...@linux.vnet.ibm.com
---
Documentation/vfio.txt | 6 +-
arch/powerpc/include/asm/eeh.h | 10 ++
arch/powerpc/kernel/eeh.c | 323
+
drivers/vfio/pci/vfio_pci.c| 99 -
include/uapi/linux/vfio.h | 43 ++
5 files changed, 474 insertions(+), 7 deletions(-)
diff --git a/Documentation/vfio.txt b/Documentation/vfio.txt
index b9ca023..bb17ec7 100644
--- a/Documentation/vfio.txt
+++ b/Documentation/vfio.txt
@@ -305,7 +305,10 @@ faster, the map/unmap handling has been implemented in
real mode which provides
an excellent performance which has limitations such as inability to do
locked pages accounting in real time.
-So 3 additional ioctls have been added:
+4) PPC64 guests detect PCI errors and recover from them via EEH RTAS
services,
+which works on the basis of additional ioctl command VFIO_EEH_OP.
+
+So 4 additional ioctls have been added:
VFIO_IOMMU_SPAPR_TCE_GET_INFO - returns the size and the start
of the DMA window on the PCI bus.
@@ -316,6 +319,7 @@ So 3 additional ioctls have been added:
VFIO_IOMMU_DISABLE - disables the container.
+ VFIO_EEH_OP - EEH dependent operations
Please document exactly what the ioctl does. In an ideal world, a
VFIO user will just look at the documentation and be able to write a
program against the API with it.
Ok. I'll amend it. Also, I'll split it to 5 ioctl commands in next revision.
The code flow from the example above should be slightly changed:
diff --git a/arch/powerpc/include/asm/eeh.h b/arch/powerpc/include/asm/eeh.h
index 34a2d83..93922ef 100644
--- a/arch/powerpc/include/asm/eeh.h
+++ b/arch/powerpc/include/asm/eeh.h
@@ -305,6 +305,16 @@ void eeh_add_device_late(struct pci_dev *);
void eeh_add_device_tree_late(struct pci_bus *);
void eeh_add_sysfs_files(struct pci_bus *);
void eeh_remove_device(struct pci_dev *);
+#ifdef CONFIG_VFIO_PCI_EEH
+int eeh_vfio_open(struct pci_dev *pdev);
+void eeh_vfio_release(struct pci_dev *pdev);
+int eeh_vfio_set_pe_option(struct pci_dev *pdev, int option, int *retval);
+int eeh_vfio_get_pe_addr(struct pci_dev *pdev, int option,
+ int *retval, int *info);
+int eeh_vfio_get_pe_state(struct pci_dev *pdev, int *retval, int *state);
+int eeh_vfio_reset_pe(struct pci_dev *pdev, int option, int *retval);
+int eeh_vfio_configure_pe(struct pci_dev *pdev, int *retval);
+#endif
/**
* EEH_POSSIBLE_ERROR() -- test for possible MMIO failure.
diff --git a/arch/powerpc/kernel/eeh.c b/arch/powerpc/kernel/eeh.c
index 9c6b899..2aaf90e 100644
--- a/arch/powerpc/kernel/eeh.c
+++ b/arch/powerpc/kernel/eeh.c
@@ -1098,6 +1098,329 @@ void eeh_remove_device(struct pci_dev *dev)
edev-mode = ~EEH_DEV_SYSFS;
}
+#ifdef CONFIG_VFIO_PCI_EEH
+int eeh_vfio_open(struct pci_dev *pdev)
Why vfio? Also that config option will not be set if vfio is compiled
as a module.
The interface is expected to be used by VFIO-PCI. I'll change the function
names to following ones in next revision. No VFIO will be seen :-)
eeh_dev_open();
eeh_dev_release();
static eeh_dev_check();
eeh_pe_set_option();
eeh_pe_get_addr();
eeh_pe_get_state();
eeh_pe_reset();
eeh_pe_configure();
Yeah, #ifdef CONFIG_VFIO_PCI_EEH can be removed safely in next revision.
+{
+ struct eeh_dev *edev;
+
+ /* No PCI device ? */
+ if (!pdev)
+ return -ENODEV;
+
+ /* No EEH device ? */
+ edev = pci_dev_to_eeh_dev(pdev);
+ if (!edev || !edev-pe)
+ return -ENODEV;
+
+ eeh_dev_set_passed(edev, true);
+ eeh_pe_set_passed(edev-pe, true);
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(eeh_vfio_open);
+
+void eeh_vfio_release(struct pci_dev *pdev)
+{
+ bool release_pe = true;
+ struct eeh_pe *pe = NULL;
+ struct eeh_dev *tmp, *edev;
+
+ /* No PCI device ? */
+ if (!pdev)
+ return;
+
+ /* No EEH device ? */
+ edev = pci_dev_to_eeh_dev(pdev);
+ if (!edev || !eeh_dev_passed(edev) ||
+ !edev-pe || !eeh_pe_passed(pe))
+ return;
+
+ /* Release device */
+ pe = edev-pe;
+ eeh_dev_set_passed(edev, false);
+
+ /* Release PE */
+ eeh_pe_for_each_dev(pe, edev, tmp) {
+ if (eeh_dev_passed(edev)) {
+ release_pe = false;
+ break;
+ }
+ }
+
+ if (release_pe)
+ eeh_pe_set_passed(pe, false);
+}
+EXPORT_SYMBOL(eeh_vfio_release);
+
+static int eeh_vfio_check_dev(struct pci_dev *pdev,
+ struct eeh_dev **pedev,
+ struct eeh_pe **ppe)
+{
+ struct eeh_dev *edev;
+
+ /* No device ? */
+ if (!pdev)
+
Re: [PATCH v5 4/4] powerpc/eeh: Avoid event on passed PE
On Wed, May 21, 2014 at 03:13:11PM +0200, Alexander Graf wrote:
On 21.05.14 07:03, Gavin Shan wrote:
If we detects frozen state on PE that has been passed to guest, we
needn't handle it. Instead, we rely on the guest to detect and recover
it. The patch avoid EEH event on the frozen passed PE so that the guest
can have chance to handle that.
Signed-off-by: Gavin Shan gws...@linux.vnet.ibm.com
---
arch/powerpc/kernel/eeh.c | 8
arch/powerpc/platforms/powernv/eeh-ioda.c | 3 ++-
2 files changed, 10 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/kernel/eeh.c b/arch/powerpc/kernel/eeh.c
index 2aaf90e..25fd12d 100644
--- a/arch/powerpc/kernel/eeh.c
+++ b/arch/powerpc/kernel/eeh.c
@@ -400,6 +400,14 @@ int eeh_dev_check_failure(struct eeh_dev *edev)
if (ret 0)
return ret;
+ /*
+ * If the PE has been passed to guest, we won't check the
+ * state. Instead, let the guest handle it if the PE has
What guest? The kernel doesn't care whether we use VFIO for a guest or not.
Ok. I'll not mention guest and vfio in next revision.
Thanks,
Gavin
Alex
+ * been frozen.
+ */
+ if (eeh_pe_passed(pe))
+ return 0;
+
/* If we already have a pending isolation event for this
* slot, we know it's bad already, we don't need to check.
* Do this checking under a lock; as multiple PCI devices
diff --git a/arch/powerpc/platforms/powernv/eeh-ioda.c
b/arch/powerpc/platforms/powernv/eeh-ioda.c
index 1b5982f..03a3ed2 100644
--- a/arch/powerpc/platforms/powernv/eeh-ioda.c
+++ b/arch/powerpc/platforms/powernv/eeh-ioda.c
@@ -890,7 +890,8 @@ static int ioda_eeh_next_error(struct eeh_pe **pe)
opal_pci_eeh_freeze_clear(phb-opal_id,
frozen_pe_no,
OPAL_EEH_ACTION_CLEAR_FREEZE_ALL);
ret = EEH_NEXT_ERR_NONE;
- } else if ((*pe)-state EEH_PE_ISOLATED) {
+ } else if ((*pe)-state EEH_PE_ISOLATED ||
+eeh_pe_passed(*pe)) {
ret = EEH_NEXT_ERR_NONE;
} else {
pr_err(EEH: Frozen PHB#%x-PE#%x (%s)
detected\n,
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH V2 2/3] powerpc, ptrace: Enable support for transactional memory register sets
On 05/20/2014 04:03 PM, Pedro Alves wrote:
On 05/20/2014 09:14 AM, Anshuman Khandual wrote:
On 05/19/2014 08:13 PM, Pedro Alves wrote:
On 05/19/2014 12:46 PM, Anshuman Khandual wrote:
I couldn't actually find any arch that currently returns -ENODEV in
the active hook. I see that binfmt_elf.c doesn't handle
regset-active() returning 0. Guess that may be why. Looks like
something that could be cleaned up, to me.
Also it does not consider the return value of regset-active(t-task,
regset)
(whose objective is to figure out whether we need to request regset-n
number
of elements or less than that) in the subsequent call to regset-get
function.
Indeed.
TBC, do you plan on fixing this? Otherwise ...
Sure, thinking something like this as mentioned below. But still not sure
how to use
the return type of -ENODEV from the function regset-active(). Right now if
any
regset does have the active hook and it returns anything but positive value,
it will
be ignored and the control moves to the next regset in view. This prevents
the thread
core note type being written to the core dump.
Looks to me that that's exactly what should happen for -ENODEV too. The
regset
should be ignored. If regset-active() returns -ENODEV, then the machine
doesn't have the registers at all, so what makes sense to me is to not write
the
corresponding core note in the dump. IOW, on such a machine, the kernel
generates a core exactly like if the support for these registers that don't
make sense for this machine wasn't compiled in at all. And generates a core
exactly like an older kernel that didn't know about that regset
(which is fine for that same machine) yet.
All of this happen right now even without specifically checking for the return
type
of -ENODEV and just checking for a positive value. I guess thats the reason
they had
omitted -ENODEV in the first place.
diff --git a/fs/binfmt_elf.c b/fs/binfmt_elf.c
index aa3cb62..80672fb 100644
--- a/fs/binfmt_elf.c
+++ b/fs/binfmt_elf.c
@@ -1553,7 +1553,15 @@ static int fill_thread_core_info(struct
elf_thread_core_info *t,
if (regset-core_note_type regset-get
(!regset-active || regset-active(t-task, regset))) {
int ret;
So, here, this ?
(!regset-active || regset-active(t-task, regset) 0))
{
- size_t size = regset-n * regset-size;
+ size_t size;
+
+ /* Request only the active elements in the regset */
+ if (!regset-active)
+ size = regset-n * regset-size;
+ else
+ size = regset-active(t-task, regset)
+ *
regset-size;
+
I wonder if it wouldn't be cleaner to add a function like:
int
regset_active (tast *task, regseg *regset)
{
if (!regset-active)
return regset-n * regset-size;
else
return regset-active(task, regset);
}
And then use it like
if (regset-core_note_type regset-get) {
int size = regset_active (t-task, regset);
if (size 0) {
...
}
Yeah this makes sense.
Though at this point, we don't actually make use of
the distinction between -ENODEV vs 0. Guess that's what
we should be thinking about. Seems like there some details that
need to be sorted out, and some verification that consumers aren't
broken by outputting smaller notes -- e.g., ia64 makes me
wonder that.
I agree.
Maybe we should leave this for another day, and have tm_spr_active
return 0 instead of -ENODEV when the machine doesn't have the hardware,
or not install that hook at all. Seems like the effect will be the same,
as the note isn't output if -get fails.
Agree. Active hooks which return 0 in case of -ENODEV sounds good to me and
shall
incorporate this in the next version.
void *data = kmalloc(size, GFP_KERNEL);
if (unlikely(!data))
return 0;
Now coming to the installation of the .active hooks part for all the new
regsets, it
should be pretty straight forward as well. Though its optional and used
for elf_core_dump
purpose only, its worth adding them here. Example of an active function
should be something
like this. The function is inexpensive as required.
+static int tm_spr_active(struct task_struct *target,
+ const struct user_regset *regset)
+{
+ if (!cpu_has_feature(CPU_FTR_TM))
+ return -ENODEV;
... unfortunately this will do the wrong thing.
I am not sure whether I understand this correctly. Are you saying that its
wrong to return
-ENODEV in this case as above ?
No, sorry for not being clear.
Re: [PATCH RFC v13 1/5] dmaengine: fix comment typo
On Thu, May 15, 2014 at 06:15:31PM +0400, Alexander Popov wrote: Fix comment typo. Applied, thanks -- ~Vinod ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH RFC v13 2/5] dma: mpc512x: add support for peripheral transfers
On Thu, May 15, 2014 at 06:15:32PM +0400, Alexander Popov wrote: Introduce support for slave s/g transfer preparation and the associated device control callback in the MPC512x DMA controller driver, which adds support for data transfers between memory and peripheral I/O to the previously supported mem-to-mem transfers. Applied, after fixing sybstem name to dmaengine -- ~Vinod ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH RFC v13 0/5] MPC512x DMA slave s/g support, OF DMA lookup
On Thu, May 15, 2014 at 06:15:30PM +0400, Alexander Popov wrote: 2013/7/14 Gerhard Sittig g...@denx.de: this series - introduces slave s/g support (that's support for DMA transfers which involve peripherals in contrast to mem-to-mem transfers) - adds device tree based lookup support for DMA channels - combines floating patches and related feedback which already covered several aspects of what the suggested LPB driver needs, to demonstrate how integration might be done ... Changes in v12: A new patch (part 2/7) is added to this series. Part 6/7: - change the description of 'compatible' property according part 2/7; - improve the document according Gerhard's feedback; Parts 1/7, 2/7 and 4/7 have been applied by Vinod Koul and are excluded from v13. Changes in v13: A new patch (part 1/5) is added to this series. Part 2/5: - fix style issue; - improve comments; You need to cc DT- list for 3 to 5 patches. Need ack before we can apply. I suspect 4/5 should come first out of these 3. Also in future pls use right subsystem name dmaengine. Also why are these tagged as RFC still? -- ~Vinod ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH V2 2/3] powerpc, ptrace: Enable support for transactional memory register sets
On Tue, 2014-05-13 at 18:21 +0100, Pedro Alves wrote: I wonder whether people are getting Roland's address from? It's frequent that ptrace related patches end up CCed to rol...@redhat.com, but, he's not been at Red Hat for a few years now. Roland, do you still want to be CCed on ptrace-related issues? If so, there's probably a script somewhere in the kernel that needs updating. If not, well, it'd be good if it were updated anyway. :-) In MAINTAINERS I see: PTRACE SUPPORT M: Roland McGrath rol...@redhat.com M: Oleg Nesterov o...@redhat.com S: Maintained cheers ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
