Re: Issue with USB Mass storage on P5020
Issue was with the USB mass storage i was using.. problem is specific to that device. -- View this message in context: http://linuxppc.10917.n7.nabble.com/Issue-with-USB-Mass-storage-on-P5020-tp67725p69102.html Sent from the linuxppc-dev mailing list archive at Nabble.com. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: PREMPT_RT
huh..My VDSO patch was not the culprit..! the issue was with spin_lock_irqsave calls...! modify the same to raw_spin_lock_irqsave..problem solved..! the rtpatch was not applied properly. -- View this message in context: http://linuxppc.10917.n7.nabble.com/PREMPT-RT-tp68107p69101.html Sent from the linuxppc-dev mailing list archive at Nabble.com. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] drivers/tty/hvc: fixup original commit: 9276dfd27897a0b29d8b5814f39a1f82f56b6b6b
于 2013年03月08日 13:08, Benjamin Herrenschmidt 写道: > Yes, the code is fine as it is now. ok, thanks. -- Chen Gang Asianux Corporation ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] drivers/tty/hvc: fixup original commit: 9276dfd27897a0b29d8b5814f39a1f82f56b6b6b
On Fri, 2013-03-08 at 12:40 +0800, Chen Gang wrote: > is it correct ? Yes, the code is fine as it is now. Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] drivers/tty/hvc: fixup original commit: 9276dfd27897a0b29d8b5814f39a1f82f56b6b6b
于 2013年03月08日 12:33, Benjamin Herrenschmidt 写道: > On Fri, 2013-03-08 at 12:23 +0800, Chen Gang wrote: >> > really it is: using strlcpy doesn't hurt. >> > >> > the comments and subject of original commit are not quite precision: >> > it is not for a bug issue (originally I say it is for bug issue) >> > it is really for beautify code. >> > >> > can I send a fixup patch only for the comments ? > No just drop it, it's fine as it is. I guess your meaning is: not need additional fix up patch (just drop it). original commit 9276dfd27897a0b29d8b5814f39a1f82f56b6b6b is valid (not need drop the original commit) is it correct ? thanks. -- Chen Gang Asianux Corporation ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] drivers/tty/hvc: fixup original commit: 9276dfd27897a0b29d8b5814f39a1f82f56b6b6b
On Fri, 2013-03-08 at 12:23 +0800, Chen Gang wrote: > really it is: using strlcpy doesn't hurt. > > the comments and subject of original commit are not quite precision: > it is not for a bug issue (originally I say it is for bug issue) > it is really for beautify code. > > can I send a fixup patch only for the comments ? No just drop it, it's fine as it is. Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] drivers/tty/hvc: fixup original commit: 9276dfd27897a0b29d8b5814f39a1f82f56b6b6b
于 2013年03月08日 11:46, Benjamin Herrenschmidt 写道: > strcpy is indeed safe but using strlcpy doesn't hurt does it ? really it is: using strlcpy doesn't hurt. the comments and subject of original commit are not quite precision: it is not for a bug issue (originally I say it is for bug issue) it is really for beautify code. can I send a fixup patch only for the comments ? thanks. -- Chen Gang Asianux Corporation ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] drivers/tty/hvc: fixup original commit: 9276dfd27897a0b29d8b5814f39a1f82f56b6b6b
On Fri, 2013-03-08 at 11:38 +0800, Chen Gang wrote: > originally I did not notice src buf len and dest buf len are the same. > so origianlly, it is not a bug issue, it is only for beautify code. > and now, using strcpy is better. Being the same len doesn't mean it's safe to use strcpy ... the source might be missing the 0 terminator. In this specific case though, I believe the source string comes was itself populated with strlcpy (at least since your patch 6b6680c4ea3952af8ae76915cbca41245147741b) so strcpy is indeed safe but using strlcpy doesn't hurt does it ? Ben. > Signed-off-by: Chen Gang > Signed-off-by: Jiri Slaby > --- > drivers/tty/hvc/hvcs.c |3 +-- > 1 files changed, 1 insertions(+), 2 deletions(-) > > diff --git a/drivers/tty/hvc/hvcs.c b/drivers/tty/hvc/hvcs.c > index 81e939e..9330a4b 100644 > --- a/drivers/tty/hvc/hvcs.c > +++ b/drivers/tty/hvc/hvcs.c > @@ -885,8 +885,7 @@ static void hvcs_set_pi(struct hvcs_partner_info > *pi, struct hvcs_struct *hvcsd) > hvcsd->p_partition_ID = pi->partition_ID; > > /* copy the null-term char too */ > - strlcpy(&hvcsd->p_location_code[0], > - &pi->location_code[0], sizeof(hvcsd->p_location_code)); > + strcpy(&hvcsd->p_location_code[0], &pi->location_code[0]); > } > > /* ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] drivers/tty/hvc: fixup original commit: 9276dfd27897a0b29d8b5814f39a1f82f56b6b6b
originally I did not notice src buf len and dest buf len are the same. so origianlly, it is not a bug issue, it is only for beautify code. and now, using strcpy is better. Signed-off-by: Chen Gang Signed-off-by: Jiri Slaby --- drivers/tty/hvc/hvcs.c |3 +-- 1 files changed, 1 insertions(+), 2 deletions(-) diff --git a/drivers/tty/hvc/hvcs.c b/drivers/tty/hvc/hvcs.c index 81e939e..9330a4b 100644 --- a/drivers/tty/hvc/hvcs.c +++ b/drivers/tty/hvc/hvcs.c @@ -885,8 +885,7 @@ static void hvcs_set_pi(struct hvcs_partner_info *pi, struct hvcs_struct *hvcsd) hvcsd->p_partition_ID = pi->partition_ID; /* copy the null-term char too */ - strlcpy(&hvcsd->p_location_code[0], - &pi->location_code[0], sizeof(hvcsd->p_location_code)); + strcpy(&hvcsd->p_location_code[0], &pi->location_code[0]); } /* -- 1.7.7.6 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH][V2] powerpc: remove the PPC_CLOCK dependency
> Subject: Re: [PATCH][V2] powerpc: remove the PPC_CLOCK dependency > > > On Mar 6, 2013, at 3:16 AM, > wrote: > > > From: Tang Yuantian > > > > config FSL_SOC and CPM do not really depend on PPC_CLOCK. So remove it. > > PPC_CLOCK also keeps powerpc archtecture from supporting COMMON_CLK. > > > > Signed-off-by: Tang Yuantian > > --- > > v2: correct the title > > > > arch/powerpc/Kconfig |1 - > > arch/powerpc/platforms/Kconfig |1 - > > 2 files changed, 0 insertions(+), 2 deletions(-) > > Does the Flexcan driver use this? > In SDK, Flexcan did select the PPC_CLOCK, in upstream, it didn't. Whatever it selects PPC_CLOCK or not, it doesn't use it. Added the patch author to this loop. - Yuantian > - k > > > > > diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig index > > 352f416..383485b 100644 > > --- a/arch/powerpc/Kconfig > > +++ b/arch/powerpc/Kconfig > > @@ -655,7 +655,6 @@ config SBUS > > config FSL_SOC > > bool > > select HAVE_CAN_FLEXCAN if NET && CAN > > - select PPC_CLOCK > > > > config FSL_PCI > > bool > > diff --git a/arch/powerpc/platforms/Kconfig > > b/arch/powerpc/platforms/Kconfig index e7a896a..aba81cd 100644 > > --- a/arch/powerpc/platforms/Kconfig > > +++ b/arch/powerpc/platforms/Kconfig > > @@ -343,7 +343,6 @@ config FSL_ULI1575 > > > > config CPM > > bool > > - select PPC_CLOCK > > > > config OF_RTC > > bool > > -- > > 1.7.0.4 > > > ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] mmc: sdhci-pltfm: Fix timeout on t4240's sdhci controller
On 03/08/2013 12:30 AM, Gala Kumar-B11780 wrote: On Mar 7, 2013, at 2:05 AM, Chunhe Lan wrote: This patch fixes timeout problems on t4240's sdhci controller: mmc0: Too large timeout requested for CMD25! mmc0: Too large timeout requested for CMD25! mmc0: Too large timeout requested for CMD25! Signed-off-by: Chunhe Lan --- drivers/mmc/host/sdhci-pltfm.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/mmc/host/sdhci-pltfm.c b/drivers/mmc/host/sdhci-pltfm.c index 3145a78..9db7b12 100644 --- a/drivers/mmc/host/sdhci-pltfm.c +++ b/drivers/mmc/host/sdhci-pltfm.c @@ -94,6 +94,7 @@ void sdhci_get_of_property(struct platform_device *pdev) if (of_device_is_compatible(np, "fsl,p2020-esdhc") || of_device_is_compatible(np, "fsl,p1010-esdhc") || + of_device_is_compatible(np, "fsl,t4240-esdhc") || of_device_is_compatible(np, "fsl,mpc8536-esdhc")) host->quirks |= SDHCI_QUIRK_BROKEN_TIMEOUT_VAL; -- 1.7.6.5 Why does this occur? Is it a board issue? Is it a silicon issue? Is it due to some erratum? Why T4 only? It would be the property of T4 hardware, and please see below the patch which locates the mail list of freescale: eSDHC: mmc:host host need long time to generate command complete interrupt According to Spec 2.0, command complete interrupt will generate within 150 SD-CLK. But this was not enough on T4240 board. So give it sufficient time to detect command timeout. 1000 * HZ will be enough, this value was test on all T4 board, all worked well. Signed-off-by: Jerry Huang Signed-off-by: Haijun Zhang Thanks, Chunhe - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: 3.9-rc1 powerpc ptrace.c: 'brk.len' is used uninitialized
Michael Neuling wrote: > Philippe De Muyter wrote: > > > Hello Mikey, > > > > On Thu, Mar 07, 2013 at 10:14:30AM +1100, Michael Neuling wrote: > > > Philippe De Muyter wrote: > > > > > > > On Thu, Mar 07, 2013 at 09:09:48AM +1100, Michael Neuling wrote: > > > > > > bisect tells me that since your commit > > > > > > 9422de3e953d0e60eb95f5430a9dd803eec1c6d7 > > > > > > "powerpc: Hardware breakpoints rewrite to handle non DABR > > > > > > breakpoint registers", > > > > > > compiling linux fails with : > > > > > > > > > > > > cc1: warnings being treated as errors > > > > > > arch/powerpc/kernel/ptrace.c: In function 'arch_ptrace': > > > > > > arch/powerpc/kernel/ptrace.c:1450: warning: 'brk.len' is used > > > > > > uninitialized in this function > > > > > > arch/powerpc/kernel/ptrace.c:1352: note: 'brk.len' was declared > > > > > > here > > > > > > > > > > > > could you look at that ? > > > > > > > > > > Sure. > > > > > > > > I use gcc-4.2.2, and my .config follows. > > > > > > I'm a bit lost. > > > > > > I don't have 4.2.2 (which is ancient BTW) and I can't hit this on > > > 4.3,4.5 or 4.6 with your config. It compiles fine. > > > > > > Also: > > > > > > > arch/powerpc/kernel/ptrace.c:1450: warning: 'brk.len' is used > > > > uninitialized in this function > > > > arch/powerpc/kernel/ptrace.c:1352: note: 'brk.len' was declared here > > > > > > These line numbers make no sense at all WRT v3.9-rc1. brk.len is neither > > > declared or used in those lines: > > > > those were the line numbers just after your commit > > > > In 3.9-rc1 they are : > > > > cc1: warnings being treated as errors > > arch/powerpc/kernel/ptrace.c: In function 'arch_ptrace': > > arch/powerpc/kernel/ptrace.c:1479: warning: 'brk.len' is used uninitialized > > in this function > > arch/powerpc/kernel/ptrace.c:1381: note: 'brk.len' was declared here > > > > if (child->thread.hw_brk.address) > > return -ENOSPC; > > > > 1479: child->thread.hw_brk = brk; > > > > return 1; > > #endif /* !CONFIG_PPC_ADV_DEBUG_DVCS */ > > Got it. I still can't replicate the issue here, so can you check if the > below works for you? Argh, scrap that. try this. diff --git a/arch/powerpc/kernel/ptrace.c b/arch/powerpc/kernel/ptrace.c index 245c1b6..8564515 100644 --- a/arch/powerpc/kernel/ptrace.c +++ b/arch/powerpc/kernel/ptrace.c @@ -1428,6 +1428,7 @@ static long ppc_set_hwdebug(struct task_struct *child, brk.address = bp_info->addr & ~7UL; brk.type = HW_BRK_TYPE_TRANSLATE; + brk.len = 0; if (bp_info->trigger_type & PPC_BREAKPOINT_TRIGGER_READ) brk.type |= HW_BRK_TYPE_READ; if (bp_info->trigger_type & PPC_BREAKPOINT_TRIGGER_WRITE) ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] pseries/iommu: close DDW race between functions of adapter
Given a PCI device with multiple functions in a DDW capable slot, the
following situation can be encountered: When the first function sets a
64-bit DMA mask, enable_ddw() will be called and we can fail to properly
configure DDW (the most common reason being the new DMA window's size is
not large enough to map all of an LPAR's memory). With the recent
changes to DDW, we remove the base window in order to determine if the
new window is of sufficient size to cover an LPAR's memory. We correctly
replace the base window if we find that not to be the case. However,
once we go through and re-configured 32-bit DMA via the IOMMU, the next
function of the adapter will go through the same process. And since DDW
is a characteristic of the slot itself, we are most likely going to fail
again. But to determine we are going to fail the second slot, we again
remove the base window -- but that is now in-use by the first
function/driver, which might be issuing I/O already.
To close this window, keep a list of all the failed struct device_nodes
that have failed to configure DDW. If the current device_node is in that
list, just fail out immediately and fall back to 32-bit DMA without
doing any DDW manipulation.
Signed-off-by: Nishanth Aravamudan
---
This is pretty ugly, but I couldn't immediately see a better solution.
In particular, I'm not sure there is much we can do if the kzalloc
fails, so I just have it return as normal.
diff --git a/arch/powerpc/platforms/pseries/iommu.c
b/arch/powerpc/platforms/pseries/iommu.c
index 1b2a174..86ae364 100644
--- a/arch/powerpc/platforms/pseries/iommu.c
+++ b/arch/powerpc/platforms/pseries/iommu.c
@@ -924,6 +924,13 @@ static void restore_default_window(struct pci_dev *dev,
__restore_default_window(pci_dev_to_eeh_dev(dev), ddw_restore_token);
}
+struct failed_ddw_pdn {
+ struct device_node *pdn;
+ struct list_head list;
+};
+
+static LIST_HEAD(failed_ddw_pdn_list);
+
/*
* If the PE supports dynamic dma windows, and there is space for a table
* that can map all pages in a linear offset, then setup such a table,
@@ -951,6 +958,7 @@ static u64 enable_ddw(struct pci_dev *dev, struct
device_node *pdn)
struct dynamic_dma_window_prop *ddwprop;
const void *dma_window = NULL;
unsigned long liobn, offset, size;
+ struct failed_ddw_pdn *fpdn;
mutex_lock(&direct_window_init_mutex);
@@ -959,6 +967,18 @@ static u64 enable_ddw(struct pci_dev *dev, struct
device_node *pdn)
goto out_unlock;
/*
+* If we already went through this for a previous function of
+* the same device and failed, we don't want to muck with the
+* DMA window again, as it will race with in-flight operations
+* and can lead to EEHs. The above mutex protects access to the
+* list.
+*/
+ list_for_each_entry(fpdn, &failed_ddw_pdn_list, list) {
+ if (!strcmp(fpdn->pdn->full_name, pdn->full_name))
+ goto out_unlock;
+ }
+
+ /*
* the ibm,ddw-applicable property holds the tokens for:
* ibm,query-pe-dma-window
* ibm,create-pe-dma-window
@@ -1114,6 +1134,12 @@ out_restore_window:
if (ddw_restore_token)
restore_default_window(dev, ddw_restore_token);
+ fpdn = kzalloc(sizeof(*fpdn), GFP_KERNEL);
+ if (!fpdn)
+ goto out_unlock;
+ fpdn->pdn = pdn;
+ list_add(&fpdn->list, &failed_ddw_pdn_list);
+
out_unlock:
mutex_unlock(&direct_window_init_mutex);
return dma_addr;
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: 3.9-rc1 powerpc ptrace.c: 'brk.len' is used uninitialized
Philippe De Muyter wrote: > Hello Mikey, > > On Thu, Mar 07, 2013 at 10:14:30AM +1100, Michael Neuling wrote: > > Philippe De Muyter wrote: > > > > > On Thu, Mar 07, 2013 at 09:09:48AM +1100, Michael Neuling wrote: > > > > > bisect tells me that since your commit > > > > > 9422de3e953d0e60eb95f5430a9dd803eec1c6d7 > > > > > "powerpc: Hardware breakpoints rewrite to handle non DABR breakpoint > > > > > registers", > > > > > compiling linux fails with : > > > > > > > > > > cc1: warnings being treated as errors > > > > > arch/powerpc/kernel/ptrace.c: In function 'arch_ptrace': > > > > > arch/powerpc/kernel/ptrace.c:1450: warning: 'brk.len' is used > > > > > uninitialized in this function > > > > > arch/powerpc/kernel/ptrace.c:1352: note: 'brk.len' was declared here > > > > > > > > > > could you look at that ? > > > > > > > > Sure. > > > > > > I use gcc-4.2.2, and my .config follows. > > > > I'm a bit lost. > > > > I don't have 4.2.2 (which is ancient BTW) and I can't hit this on > > 4.3,4.5 or 4.6 with your config. It compiles fine. > > > > Also: > > > > > arch/powerpc/kernel/ptrace.c:1450: warning: 'brk.len' is used > > > uninitialized in this function > > > arch/powerpc/kernel/ptrace.c:1352: note: 'brk.len' was declared here > > > > These line numbers make no sense at all WRT v3.9-rc1. brk.len is neither > > declared or used in those lines: > > those were the line numbers just after your commit > > In 3.9-rc1 they are : > > cc1: warnings being treated as errors > arch/powerpc/kernel/ptrace.c: In function 'arch_ptrace': > arch/powerpc/kernel/ptrace.c:1479: warning: 'brk.len' is used uninitialized > in this function > arch/powerpc/kernel/ptrace.c:1381: note: 'brk.len' was declared here > > if (child->thread.hw_brk.address) > return -ENOSPC; > > 1479: child->thread.hw_brk = brk; > > return 1; > #endif /* !CONFIG_PPC_ADV_DEBUG_DVCS */ Got it. I still can't replicate the issue here, so can you check if the below works for you? Thanks, Mikey diff --git a/arch/powerpc/kernel/ptrace.c b/arch/powerpc/kernel/ptrace.c index 245c1b6..3b5f9dc 100644 --- a/arch/powerpc/kernel/ptrace.c +++ b/arch/powerpc/kernel/ptrace.c @@ -1428,6 +1428,7 @@ static long ppc_set_hwdebug(struct task_struct *child, brk.address = bp_info->addr & ~7UL; brk.type = HW_BRK_TYPE_TRANSLATE; + brk.len = len; if (bp_info->trigger_type & PPC_BREAKPOINT_TRIGGER_READ) brk.type |= HW_BRK_TYPE_READ; if (bp_info->trigger_type & PPC_BREAKPOINT_TRIGGER_WRITE) ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc/wsp: drop "select PPC_WSP_COPRO"
There is no Kconfig symbol PPC_WSP_COPRO. The select statement for it is
a nop. Drop it.
Signed-off-by: Paul Bolle
---
A short treatise on the uneventful life of PPC_WSP_COPRO in the mainline
kernel tree
Release v3.0 included commit 76b4eda866c4936af8d696f040abea56bf688e16
("powerpc: Add A2 cpu support"). It added some code wrapped in an
"#ifdef CONFIG_PPC_WSP_COPRO" and "#endif" pair. It did not add a
Kconfig symbol PPC_WSP_COPRO. Neither did it add a preprocessor #define
for CONFIG_PPC_WSP_COPRO. There haS actually never been such a symbol or
such a macro in the mainline tree.
Release v3.3 included commit fac26ad4f9cb794c9d1032f55f40a31cb55be09a
("powerpc/book3e: Add ICSWX/ACOP support to Book3e cores like A2"). It
basically renamed CONFIG_PPC_WSP_COPRO to CONFIG_PPC_ICSWX. It did not
elaborate why it did that. But at least PPC_ICSWX was a valid Kconfig
symbol.
Release v3.3 also included commit
cc35b6766878e31accc95c3fdae945bdadc73a46 ("powerpc/book3e: Add Chroma as
a new WSP/PowerEN platform."). That commit added a Kconfig select
statement for PPC_WSP_COPRO. It is not clear why it did that. Current
opinion is that it served no purpose and that the kernel tree would be
better of without that statement.
arch/powerpc/platforms/wsp/Kconfig | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/powerpc/platforms/wsp/Kconfig
b/arch/powerpc/platforms/wsp/Kconfig
index 79d2225..56203a4 100644
--- a/arch/powerpc/platforms/wsp/Kconfig
+++ b/arch/powerpc/platforms/wsp/Kconfig
@@ -9,7 +9,6 @@ config PPC_WSP
select PCI
select PPC_IO_WORKAROUNDS if PCI
select PPC_INDIRECT_PIO if PCI
- select PPC_WSP_COPRO
default n
menu "WSP platform selection"
--
1.7.11.7
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Linux kernel 3.x problems on PowerMac G5
On 03/07/2013 09:22 PM, Benjamin Herrenschmidt wrote: On Thu, 2013-03-07 at 21:08 +0100, Phileas Fogg wrote: And the bisect couldn't find the commit which causes hangs on my machine. All commits which were provided by the bisect were bad. And the commit before tha last bad bisect commit was bad too. I did bisect several times, and got the same results. Fo testing i used linux-3.0.y branch of git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git. Did i miss something or do something wrong here ? Did git bisect go down a merge commit ? It does for me if I try that and asks to test that merge first. If you get that wrong it can get very confused. That's all I can think of... do you have the bisection log just in case ? Also you can use gitk -- arch/powerpc to look at the changes to powerpc code and try manually random points before/after that if you think bisect isn't doing the right thing. Cheers, Ben. Thanks. I'll try manually some commits then. And here is the bisect log: git bisect log # bad: [55922c9d1b84b89cb946c777fddccb3247e7df2c] Linux 3.0-rc1 # good: [61c4f2c81c61f73549928dfd9f3e8f26aa36a8cf] Linux 2.6.39 git bisect start '55922c9d1b84b89cb946c777fddccb3247e7df2c' '61c4f2c81c61f73549928dfd9f3e8f26aa36a8cf' # bad: [c44dead70a841d90ddc01968012f323c33217c9e] Merge branch 'usb-next' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb-2.6 git bisect bad c44dead70a841d90ddc01968012f323c33217c9e # bad: [d93515611bbc70c2fe4db232e5feb448ed8e4cc9] macvlan: fix panic if lowerdev in a bond git bisect bad d93515611bbc70c2fe4db232e5feb448ed8e4cc9 # bad: [9c6a02f41d10dc9fbf5dd42058e8846f38dd2d9a] sctp: make sctp over IPv6 work with IPsec git bisect bad 9c6a02f41d10dc9fbf5dd42058e8846f38dd2d9a # bad: [d30ee670f25ea8f265a2804e2a0a53804cac5185] net-bonding: Fix minor sparse complaints git bisect bad d30ee670f25ea8f265a2804e2a0a53804cac5185 # bad: [b37e3b6d64358604960b35e8ecbb7aed22e0926e] Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6 git bisect bad b37e3b6d64358604960b35e8ecbb7aed22e0926e # bad: [6c74608bd479bbe02ce330f83df43c3f535ed200] ssb: pci: trivial: drop useless pointer git bisect bad 6c74608bd479bbe02ce330f83df43c3f535ed200 # bad: [83860c594f65945b1a2c99e84338e1145cd34890] ath9k_hw: remove pCap->tx_triglevel_max git bisect bad 83860c594f65945b1a2c99e84338e1145cd34890 # bad: [f171760c558946c7a2e0ee310dfb968f9d4853c6] ath9k_hw: enable a BlockAck related fixup specific to AR9100 git bisect bad f171760c558946c7a2e0ee310dfb968f9d4853c6 # bad: [e600707b021efdc109e7becd467798da339ec26d] mwl8k: differentiate between WMM queues and AMPDU queues git bisect bad e600707b021efdc109e7becd467798da339ec26d # bad: [e7fc63388def06d2d1bdb6916748c92c037a42c6] ath9k_hw: Speedup register ops for HTC driver git bisect bad e7fc63388def06d2d1bdb6916748c92c037a42c6 # bad: [6d64ab7f9240e3201fde3fd16ce4227bd795d2ab] ath9k_htc: Fix LED pin for AR9287 HTC device git bisect bad 6d64ab7f9240e3201fde3fd16ce4227bd795d2ab # bad: [22dd2fd283ea96b4d45185d3e861ef46005082f4] iwlwifi: remove duplicate initialization in __iwl_down() git bisect bad 22dd2fd283ea96b4d45185d3e861ef46005082f4 Regards ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Linux kernel 3.x problems on PowerMac G5
On Thu, 2013-03-07 at 21:08 +0100, Phileas Fogg wrote: > And the bisect couldn't find the commit which causes hangs on my > machine. > All commits which were provided by the bisect were bad. > And the commit before tha last bad bisect commit was bad too. > I did bisect several times, and got the same results. > > Fo testing i used linux-3.0.y branch of > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git. > > Did i miss something or do something wrong here ? Did git bisect go down a merge commit ? It does for me if I try that and asks to test that merge first. If you get that wrong it can get very confused. That's all I can think of... do you have the bisection log just in case ? Also you can use gitk -- arch/powerpc to look at the changes to powerpc code and try manually random points before/after that if you think bisect isn't doing the right thing. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Linux kernel 3.x problems on PowerMac G5
On 03/03/2013 08:24 PM, Benjamin Herrenschmidt wrote: On Sun, 2013-03-03 at 20:16 +0100, Phileas Fogg wrote: Benjamin Herrenschmidt wrote: Thanks. It looks like a bisection might indeed be the way to go... Out of curiosity, have you tried without some of your additional drivers ? Maybe one of them is the culprit... Cheers, Ben. Not yet, will do. But I tested the official Debian Wheezy RC netinstall CD with Linux 3.2, it has the same problem and hangs at boot on my machine. Ok, so it's definitely something about your configuration. Maybe something in the 11,2 support code chokes on single-chip configs, I don't have one of them to test, both mines are dual chip (ie. quad core). But it does look like a regression that should be bisectable, so let me know went you're done there and what you get. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev Hi, i'm completely confused now. I did a bisect between the following 2 commits: 61c4f2c81c61f73549928dfd9f3e8f26aa36a8cf (good) Linux 2.6.39 and 55922c9d1b84b89cb946c777fddccb3247e7df2c (bad) Linux 3.0-rc1 Both commist were tested by me on my machine. And Linux 3.0-rc1 hangs on my machine but Linux 2.6.39 works fine. And the bisect couldn't find the commit which causes hangs on my machine. All commits which were provided by the bisect were bad. And the commit before tha last bad bisect commit was bad too. I did bisect several times, and got the same results. Fo testing i used linux-3.0.y branch of git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git. Did i miss something or do something wrong here ? Regards ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 5/8 v2] powerpc/fsl-booke: Add initial silicon device tree for
Enable a baseline T4240 SoC to boot. There are several things missing
from the device trees for T4240:
* Proper PAMU topology information
* DPAA related nodes (Qman, Bman, Fman, Rman, DCE)
* Prefetch Manager
* Thermal monitor unit
* Interlaken
Signed-off-by: Roy Zang
Signed-off-by: Minghuan Lian
Signed-off-by: Haiying Wang
Signed-off-by: Andy Fleming
Signed-off-by: Prabhakar Kushwaha
Signed-off-by: York Sun
Signed-off-by: Vakul Garg
Signed-off-by: Tang Yuantian
Signed-off-by: Zhao Chenhui
Signed-off-by: Li Yang
Signed-off-by: Ramneek Mehresh
Signed-off-by: Laurentiu Tudor
Signed-off-by: Kumar Gala
---
* Added thread ids to cpu nodes
* removed clock-frequency from PCI nodes as we dont use it
arch/powerpc/boot/dts/fsl/qoriq-gpio-1.dtsi | 41
arch/powerpc/boot/dts/fsl/qoriq-gpio-2.dtsi | 41
arch/powerpc/boot/dts/fsl/qoriq-gpio-3.dtsi | 41
arch/powerpc/boot/dts/fsl/t4240si-post.dtsi | 307 +++
arch/powerpc/boot/dts/fsl/t4240si-pre.dtsi | 127 +++
5 files changed, 557 insertions(+)
create mode 100644 arch/powerpc/boot/dts/fsl/qoriq-gpio-1.dtsi
create mode 100644 arch/powerpc/boot/dts/fsl/qoriq-gpio-2.dtsi
create mode 100644 arch/powerpc/boot/dts/fsl/qoriq-gpio-3.dtsi
create mode 100644 arch/powerpc/boot/dts/fsl/t4240si-post.dtsi
create mode 100644 arch/powerpc/boot/dts/fsl/t4240si-pre.dtsi
diff --git a/arch/powerpc/boot/dts/fsl/qoriq-gpio-1.dtsi
b/arch/powerpc/boot/dts/fsl/qoriq-gpio-1.dtsi
new file mode 100644
index 000..c2f9cda
--- /dev/null
+++ b/arch/powerpc/boot/dts/fsl/qoriq-gpio-1.dtsi
@@ -0,0 +1,41 @@
+/*
+ * QorIQ GPIO device tree stub [ controller @ offset 0x131000 ]
+ *
+ * Copyright 2013 Freescale Semiconductor Inc.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions are met:
+ * * Redistributions of source code must retain the above copyright
+ * notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above copyright
+ * notice, this list of conditions and the following disclaimer in the
+ * documentation and/or other materials provided with the distribution.
+ * * Neither the name of Freescale Semiconductor nor the
+ * names of its contributors may be used to endorse or promote products
+ * derived from this software without specific prior written permission.
+ *
+ *
+ * ALTERNATIVELY, this software may be distributed under the terms of the
+ * GNU General Public License ("GPL") as published by the Free Software
+ * Foundation, either version 2 of that License or (at your option) any
+ * later version.
+ *
+ * THIS SOFTWARE IS PROVIDED BY Freescale Semiconductor ``AS IS'' AND ANY
+ * EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
+ * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
+ * DISCLAIMED. IN NO EVENT SHALL Freescale Semiconductor BE LIABLE FOR ANY
+ * DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
+ * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
+ * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
+ * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
THIS
+ * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+gpio1: gpio@131000 {
+ compatible = "fsl,qoriq-gpio";
+ reg = <0x131000 0x1000>;
+ interrupts = <54 2 0 0>;
+ #gpio-cells = <2>;
+ gpio-controller;
+};
diff --git a/arch/powerpc/boot/dts/fsl/qoriq-gpio-2.dtsi
b/arch/powerpc/boot/dts/fsl/qoriq-gpio-2.dtsi
new file mode 100644
index 000..33f3ccb
--- /dev/null
+++ b/arch/powerpc/boot/dts/fsl/qoriq-gpio-2.dtsi
@@ -0,0 +1,41 @@
+/*
+ * QorIQ GPIO device tree stub [ controller @ offset 0x132000 ]
+ *
+ * Copyright 2013 Freescale Semiconductor Inc.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions are met:
+ * * Redistributions of source code must retain the above copyright
+ * notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above copyright
+ * notice, this list of conditions and the following disclaimer in the
+ * documentation and/or other materials provided with the distribution.
+ * * Neither the name of Freescale Semiconductor nor the
+ * names of its contributors may be used to endorse or promote products
+ * derived from this software without specific prior written permission.
+ *
+ *
+ * ALTERNATIVELY, this software may be distributed under the terms of the
+ * GNU General Public License ("GPL") as published by the Free Software
+ * Foundation, either version 2 o
Re: [PATCH 5/8] powerpc/fsl-booke: Add initial silicon device tree for
On Mar 7, 2013, at 11:47 AM, Scott Wood wrote: > On 03/07/2013 11:09:50 AM, Kumar Gala wrote: >> On Mar 5, 2013, at 6:15 PM, Scott Wood wrote: >> > On 03/05/2013 05:15:57 PM, Kumar Gala wrote: >> >> Enable a baseline T4240 SoC to boot. There are several things missing >> >> from the device trees for T4240: >> >> * Thread support on e6500 >> > >> > Why did threads get removed from the device tree? It's supposed to >> > describe hardware, not what Linux currently supports. >> will fix, was concerned if we'd be able to boot if they exited > > I don't think it'd be a problem (and if it is, then fix Linux). looks fine, so I'll add them in v2 patch. > >> >> + device_type = "pci"; >> >> + #size-cells = <2>; >> >> + #address-cells = <3>; >> >> + bus-range = <0x0 0xff>; >> >> + clock-frequency = <>; >> > >> > This clock-frequency is not correct (I doubt it's needed at all). >> I can zero the field, but its spec'd by pci binding > > If we aren't going to put a correct value in, is zero better than omitting it > entirely? > > There are other properties in the PCI binding that we don't have, such as > slot-names. I don't see any language in the PCI binding that says one is > required but the other isn't. > > And shouldn't we be using the PCI express binding (device_type = "pciex", or > just get rid of it since this isn't real OF)? I'll drop clock-frequency since we dont use it. - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 5/8] powerpc/fsl-booke: Add initial silicon device tree for
On 03/07/2013 11:09:50 AM, Kumar Gala wrote: On Mar 5, 2013, at 6:15 PM, Scott Wood wrote: > On 03/05/2013 05:15:57 PM, Kumar Gala wrote: >> Enable a baseline T4240 SoC to boot. There are several things missing >> from the device trees for T4240: >> * Thread support on e6500 > > Why did threads get removed from the device tree? It's supposed to describe hardware, not what Linux currently supports. will fix, was concerned if we'd be able to boot if they exited I don't think it'd be a problem (and if it is, then fix Linux). >> + device_type = "pci"; >> + #size-cells = <2>; >> + #address-cells = <3>; >> + bus-range = <0x0 0xff>; >> + clock-frequency = <>; > > This clock-frequency is not correct (I doubt it's needed at all). I can zero the field, but its spec'd by pci binding If we aren't going to put a correct value in, is zero better than omitting it entirely? There are other properties in the PCI binding that we don't have, such as slot-names. I don't see any language in the PCI binding that says one is required but the other isn't. And shouldn't we be using the PCI express binding (device_type = "pciex", or just get rid of it since this isn't real OF)? -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 5/8] powerpc/fsl-booke: Add initial silicon device tree for
On Mar 5, 2013, at 6:15 PM, Scott Wood wrote:
> On 03/05/2013 05:15:57 PM, Kumar Gala wrote:
>> Enable a baseline T4240 SoC to boot. There are several things missing
>> from the device trees for T4240:
>> * Thread support on e6500
>
> Why did threads get removed from the device tree? It's supposed to describe
> hardware, not what Linux currently supports.
will fix, was concerned if we'd be able to boot if they exited
>
>> * Proper PAMU topology information
>> * DPAA related nodes (Qman, Bman, Fman, Rman, DCE)
>> * Prefetch Manager
>> * Thermal monitor unit
>> * Interlaken
>
> The dts should be marked preliminary somehow -- we really should get out of
> the habit of letting device nodes trickle in as drivers get added.
agreed but forward progress always gets in the way
>
>> +/* controller at 0x24 */
>> +&pci0 {
>> +compatible = "fsl,t4240-pcie", "fsl,qoriq-pcie-v3.0";
>
> We have a version register -- do we really need to keep sticking the version
> number in the compatible? Note that we've had device trees that specified
> the version incorrectly in the past.
>
>> +device_type = "pci";
>> +#size-cells = <2>;
>> +#address-cells = <3>;
>> +bus-range = <0x0 0xff>;
>> +clock-frequency = <>;
>
> This clock-frequency is not correct (I doubt it's needed at all).
I can zero the field, but its spec'd by pci binding
>
>> +PowerPC,e6500@1 {
>> +device_type = "cpu";
>> +reg = <2>;
>> +next-level-cache = <&L2_1>;
>> +};
>> +PowerPC,e6500@2 {
>> +device_type = "cpu";
>> +reg = <4>;
>> +next-level-cache = <&L2_1>;
>> +};
>> +PowerPC,e6500@3 {
>> +device_type = "cpu";
>> +reg = <6>;
>> +next-level-cache = <&L2_1>;
>> +};
>> +
>> +PowerPC,e6500@4 {
>> +device_type = "cpu";
>> +reg = <8>;
>> +next-level-cache = <&L2_2>;
>> +};
>
> Inconsistent whitespace.
will kill the whitespace.
> As usual, the pre/post split is unnecessary. Everything in it can go in post.
>
> -Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH V4] powerpc/85xx: Add machine check handler to fix PCIe erratum on mpc85xx
On 03/07/2013 02:06:05 AM, Jia Hongtao-B38951 wrote:
Here is the ideas from Scott:
"
> + if (is_in_pci_mem_space(addr)) {
> + inst = *(unsigned int *)regs->nip;
Be careful about taking a fault here. A simple TLB miss should be
safe
given that we shouldn't be accessing PCIe in the middle of exception
code, but what if the mapping has gone away (e.g. a userspace driver
had
its code munmap()ed or swapped out)? What if permissions allow
execute
but not read (not sure if Linux will allow this, but the hardware
does)?
What if it happened in a KVM guest? You can't access guest addresses
directly.
"
That means you need to be careful about how you read the instruction,
not that you shouldn't do it at all.
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH][V2] powerpc: remove the PPC_CLOCK dependency
On Mar 6, 2013, at 3:16 AM, wrote: > From: Tang Yuantian > > config FSL_SOC and CPM do not really depend on PPC_CLOCK. So remove it. > PPC_CLOCK also keeps powerpc archtecture from supporting COMMON_CLK. > > Signed-off-by: Tang Yuantian > --- > v2: correct the title > > arch/powerpc/Kconfig |1 - > arch/powerpc/platforms/Kconfig |1 - > 2 files changed, 0 insertions(+), 2 deletions(-) Does the Flexcan driver use this? - k > > diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig > index 352f416..383485b 100644 > --- a/arch/powerpc/Kconfig > +++ b/arch/powerpc/Kconfig > @@ -655,7 +655,6 @@ config SBUS > config FSL_SOC > bool > select HAVE_CAN_FLEXCAN if NET && CAN > - select PPC_CLOCK > > config FSL_PCI > bool > diff --git a/arch/powerpc/platforms/Kconfig b/arch/powerpc/platforms/Kconfig > index e7a896a..aba81cd 100644 > --- a/arch/powerpc/platforms/Kconfig > +++ b/arch/powerpc/platforms/Kconfig > @@ -343,7 +343,6 @@ config FSL_ULI1575 > > config CPM > bool > - select PPC_CLOCK > > config OF_RTC > bool > -- > 1.7.0.4 > ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] mmc: sdhci-pltfm: Fix timeout on t4240's sdhci controller
On Mar 7, 2013, at 2:05 AM, Chunhe Lan wrote: > This patch fixes timeout problems on t4240's sdhci controller: > > mmc0: Too large timeout requested for CMD25! > mmc0: Too large timeout requested for CMD25! > mmc0: Too large timeout requested for CMD25! > > Signed-off-by: Chunhe Lan > --- > drivers/mmc/host/sdhci-pltfm.c |1 + > 1 files changed, 1 insertions(+), 0 deletions(-) > > diff --git a/drivers/mmc/host/sdhci-pltfm.c b/drivers/mmc/host/sdhci-pltfm.c > index 3145a78..9db7b12 100644 > --- a/drivers/mmc/host/sdhci-pltfm.c > +++ b/drivers/mmc/host/sdhci-pltfm.c > @@ -94,6 +94,7 @@ void sdhci_get_of_property(struct platform_device *pdev) > > if (of_device_is_compatible(np, "fsl,p2020-esdhc") || > of_device_is_compatible(np, "fsl,p1010-esdhc") || > + of_device_is_compatible(np, "fsl,t4240-esdhc") || > of_device_is_compatible(np, "fsl,mpc8536-esdhc")) > host->quirks |= SDHCI_QUIRK_BROKEN_TIMEOUT_VAL; > > -- > 1.7.6.5 > Why does this occur? Is it a board issue? Is it a silicon issue? Is it due to some erratum? Why T4 only? - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/4] Device tree entry for Freescale TDM controller
I know I'm probably missing something... but... why are these patches
copied to the ARM list? They appear to be PowerPC patches.
On Thu, Mar 07, 2013 at 04:57:45PM +0530, Sandeep Singh wrote:
> Added dtsi file for Freescale TDM controller.
> This controller is available on many Freescale SOCs like MPC8315, P1020,
> P1010,
> P1022 and P1024
> Signed-off-by: Sandeep Singh
> Signed-off-by: Poonam Aggrwal
> ---
> arch/powerpc/boot/dts/fsl/pq3-tdm1.0-0.dtsi | 42
> +++
> 1 files changed, 42 insertions(+), 0 deletions(-)
> create mode 100644 arch/powerpc/boot/dts/fsl/pq3-tdm1.0-0.dtsi
>
> diff --git a/arch/powerpc/boot/dts/fsl/pq3-tdm1.0-0.dtsi
> b/arch/powerpc/boot/dts/fsl/pq3-tdm1.0-0.dtsi
> new file mode 100644
> index 000..e89f637
> --- /dev/null
> +++ b/arch/powerpc/boot/dts/fsl/pq3-tdm1.0-0.dtsi
> @@ -0,0 +1,42 @@
> +/*
> + * PQ3 TDM device tree stub [ controller @ offset 0x16000 ]
> + *
> + * Copyright 2012 Freescale Semiconductor Inc.
> + *
> + * Redistribution and use in source and binary forms, with or without
> + * modification, are permitted provided that the following conditions are
> met:
> + * * Redistributions of source code must retain the above copyright
> + * notice, this list of conditions and the following disclaimer.
> + * * Redistributions in binary form must reproduce the above copyright
> + * notice, this list of conditions and the following disclaimer in the
> + * documentation and/or other materials provided with the distribution.
> + * * Neither the name of Freescale Semiconductor nor the
> + * names of its contributors may be used to endorse or promote products
> + * derived from this software without specific prior written
> permission.
> + *
> + *
> + * ALTERNATIVELY, this software may be distributed under the terms of the
> + * GNU General Public License ("GPL") as published by the Free Software
> + * Foundation, either version 2 of that License or (at your option) any
> + * later version.
> + *
> + * THIS SOFTWARE IS PROVIDED BY Freescale Semiconductor ``AS IS'' AND ANY
> + * EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
> + * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
> + * DISCLAIMED. IN NO EVENT SHALL Freescale Semiconductor BE LIABLE FOR ANY
> + * DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
> + * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
> SERVICES;
> + * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED
> AND
> + * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
> + * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
> THIS
> + * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
> + */
> +
> +tdm@16000 {
> + compatible = "fsl,tdm1.0";
> + reg = <0x16000 0x200 0x2c000 0x2000>;
> + clock-frequency = <0>;
> + tdm_tx_clk = <2048000>;
> + interrupts = <62 8 0 0>;
> + fsl,max-time-slots = <128>;
> +};
> --
> 1.7.6.GIT
>
>
>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 4/4] Added device tree entries for Legerity SLIC node on various Freescale Platforms
SLIC device is connected on SPI bus on these platforms
Signed-off-by: Sandeep Singh
Signed-off-by: Poonam Aggrwal
---
arch/powerpc/boot/dts/p1010rdb.dtsi| 13 -
arch/powerpc/boot/dts/p1020mbg-pc.dtsi | 19 +++
arch/powerpc/boot/dts/p1020rdb-pc.dtsi | 18 ++
arch/powerpc/boot/dts/p1020rdb.dtsi| 17 +
arch/powerpc/boot/dts/p1022ds.dtsi | 17 +
arch/powerpc/boot/dts/p1024rdb.dtsi| 18 ++
6 files changed, 101 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/boot/dts/p1010rdb.dtsi
b/arch/powerpc/boot/dts/p1010rdb.dtsi
index ec7c27a..b0a5908 100644
--- a/arch/powerpc/boot/dts/p1010rdb.dtsi
+++ b/arch/powerpc/boot/dts/p1010rdb.dtsi
@@ -1,7 +1,7 @@
/*
* P1010 RDB Device Tree Source stub (no addresses or top-level ranges)
*
- * Copyright 2011 Freescale Semiconductor Inc.
+ * Copyright 2011-2012 Freescale Semiconductor Inc.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions are met:
@@ -184,8 +184,19 @@
label = "SPI Flash JFFS2 RFS";
};
};
+
+ tdm_phy_0: slic@0 {
+ compatible = "zarlink,le88266", "tdm-phy-slic";
+ reg = <0>;
+ spi-max-frequency = <800>;
+ };
};
+tdm@16000 {
+ num-phy = <1>;
+ phy-handle = <&tdm_phy_0>;
+};
+
usb@22000 {
phy_type = "utmi";
dr_mode = "host";
diff --git a/arch/powerpc/boot/dts/p1020mbg-pc.dtsi
b/arch/powerpc/boot/dts/p1020mbg-pc.dtsi
index a24699c..9119387 100644
--- a/arch/powerpc/boot/dts/p1020mbg-pc.dtsi
+++ b/arch/powerpc/boot/dts/p1020mbg-pc.dtsi
@@ -93,6 +93,25 @@
};
};
+ spi@7000 {
+ tdm_phy_0: slic@0 {
+ compatible = "zarlink,le88266", "tdm-phy-slic";
+ reg = <1>;
+ spi-max-frequency = <800>;
+ };
+
+ tdm_phy_1: slic@1 {
+ compatible = "zarlink,le88266", "tdm-phy-slic";
+ reg = <2>;
+ spi-max-frequency = <800>;
+ };
+ };
+
+ tdm@16000 {
+ num-phy = <2>;
+ phy-handle = <&tdm_phy_0>, <&tdm_phy_1>;
+ };
+
mdio@24000 {
phy0: ethernet-phy@0 {
interrupts = <3 1 0 0>;
diff --git a/arch/powerpc/boot/dts/p1020rdb-pc.dtsi
b/arch/powerpc/boot/dts/p1020rdb-pc.dtsi
index c952cd3..3a7fdd9 100644
--- a/arch/powerpc/boot/dts/p1020rdb-pc.dtsi
+++ b/arch/powerpc/boot/dts/p1020rdb-pc.dtsi
@@ -186,6 +186,24 @@
label = "file system jffs2";
};
};
+
+ tdm_phy_0: slic@0 {
+ compatible = "zarlink,le88266", "tdm-phy-slic";
+ reg = <1>;
+ spi-max-frequency = <800>;
+ };
+
+ tdm_phy_1: slic@1 {
+ compatible = "zarlink,le88266", "tdm-phy-slic";
+ reg = <2>;
+ spi-max-frequency = <800>;
+ };
+
+ };
+
+ tdm@16000 {
+ num-phy = <2>;
+ phy-handle = <&tdm_phy_0>, <&tdm_phy_1>;
};
usb@22000 {
diff --git a/arch/powerpc/boot/dts/p1020rdb.dtsi
b/arch/powerpc/boot/dts/p1020rdb.dtsi
index 1fb7e0e..f1a3431 100644
--- a/arch/powerpc/boot/dts/p1020rdb.dtsi
+++ b/arch/powerpc/boot/dts/p1020rdb.dtsi
@@ -186,6 +186,23 @@
label = "file system jffs2";
};
};
+
+ tdm_phy_0: slic@0 {
+ compatible = "zarlink,le88266", "tdm-phy-slic";
+ reg = <1>;
+ spi-max-frequency = <800>;
+ };
+
+ tdm_phy_1: slic@1 {
+ compatible = "zarlink,le88266", "tdm-phy-slic";
+ reg = <2>;
+ spi-max-frequency = <800>;
+ };
+ };
+
+ tdm@16000 {
+ num-phy = <2>;
+ phy-handle = <&tdm_phy_0>, <&tdm_phy_1>;
};
usb@22000 {
diff --git a/arch/powerpc/boot/dts/p1022ds.dtsi
b/arch/powerpc/boot/dts/p1022ds.dtsi
index 873da35..af2d4e1 100644
--- a/arch/powerpc/boot/dts/p1022ds.dtsi
+++ b/arch/powerpc/boot/dts/p1022ds.dtsi
@@ -183,6 +183,18 @@
reg = <0x0070 0x0090>;
};
};
+
+ tdm_phy_0: slic@0 {
+ compatible = "zarlink,le88266", "tdm-phy-slic";
+ reg = <1>;
+ spi
[PATCH 3/4] TDM Device Tree entries for various Freescale Platforms
P1010RDB, P1020RDB, P1020MBG-PC, P1022DS, P1020RDB-PC and P1024RDB
In this Patch:
1. TDM node included in .dtsi files.
2. Disabled TDM in 36bit configurations because of limitations
in TDM hardware block, details mentioned below.
Details of 36bit h/w limitaion:
-
TDM DMAC IP does not support more than 32b address. To address memory regions
more than 4GB, 4 bits of address were provided in GUTs, which are appended to
txns initiated by TDM DMAC. These 4 bits are appended irrespective of the
region addressed. When TDM works in DMA mode, the DMA need to access DDR as
well as TDM FIFO in CCSR space. So this poses a restriction that if memory
region above 4GB need to be accessed, CCSR space should also be mapped into
that 4GB region.
In this case DDR is at at first 4G (starting from 0) and CCSR is at
different 4G (0xfffe0), hence the issue.
Signed-off-by: Sandeep Singh
Signed-off-by: Poonam Aggrwal
---
arch/powerpc/boot/dts/fsl/p1010si-post.dtsi |3 ++-
arch/powerpc/boot/dts/fsl/p1020si-post.dtsi |1 +
arch/powerpc/boot/dts/fsl/p1022si-post.dtsi |1 +
arch/powerpc/boot/dts/p1010rdb_36b.dts |3 +++
arch/powerpc/boot/dts/p1020mbg-pc_36b.dts |3 +++
arch/powerpc/boot/dts/p1020rdb-pc_36b.dts |3 +++
arch/powerpc/boot/dts/p1020rdb_36b.dts |3 +++
arch/powerpc/boot/dts/p1022ds_36b.dts |3 +++
arch/powerpc/boot/dts/p1024rdb_36b.dts |3 +++
9 files changed, 22 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/boot/dts/fsl/p1010si-post.dtsi
b/arch/powerpc/boot/dts/fsl/p1010si-post.dtsi
index 0bde9ee..15c74a2 100644
--- a/arch/powerpc/boot/dts/fsl/p1010si-post.dtsi
+++ b/arch/powerpc/boot/dts/fsl/p1010si-post.dtsi
@@ -1,7 +1,7 @@
/*
* P1010/P1014 Silicon/SoC Device Tree Source (post include)
*
- * Copyright 2011 Freescale Semiconductor Inc.
+ * Copyright 2011-2012 Freescale Semiconductor Inc.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions are met:
@@ -132,6 +132,7 @@
/include/ "pq3-gpio-0.dtsi"
/include/ "pq3-sata2-0.dtsi"
/include/ "pq3-sata2-1.dtsi"
+/include/ "pq3-tdm1.0-0.dtsi"
can0: can@1c000 {
compatible = "fsl,p1010-flexcan";
diff --git a/arch/powerpc/boot/dts/fsl/p1020si-post.dtsi
b/arch/powerpc/boot/dts/fsl/p1020si-post.dtsi
index 68cc5e7..684f664 100644
--- a/arch/powerpc/boot/dts/fsl/p1020si-post.dtsi
+++ b/arch/powerpc/boot/dts/fsl/p1020si-post.dtsi
@@ -131,6 +131,7 @@
};
/include/ "pq3-gpio-0.dtsi"
+/include/ "pq3-tdm1.0-0.dtsi"
L2: l2-cache-controller@2 {
compatible = "fsl,p1020-l2-cache-controller";
diff --git a/arch/powerpc/boot/dts/fsl/p1022si-post.dtsi
b/arch/powerpc/boot/dts/fsl/p1022si-post.dtsi
index 06216b8..4016e45 100644
--- a/arch/powerpc/boot/dts/fsl/p1022si-post.dtsi
+++ b/arch/powerpc/boot/dts/fsl/p1022si-post.dtsi
@@ -190,6 +190,7 @@
fsl,fifo-depth = <15>;
};
+/include/ "pq3-tdm1.0-0.dtsi"
/include/ "pq3-sata2-0.dtsi"
/include/ "pq3-sata2-1.dtsi"
diff --git a/arch/powerpc/boot/dts/p1010rdb_36b.dts
b/arch/powerpc/boot/dts/p1010rdb_36b.dts
index 64776f4..e159b42 100644
--- a/arch/powerpc/boot/dts/p1010rdb_36b.dts
+++ b/arch/powerpc/boot/dts/p1010rdb_36b.dts
@@ -52,6 +52,9 @@
board_soc: soc: soc@fffe0 {
ranges = <0x0 0xf 0xffe0 0x10>;
+ tdm@16000 {
+ status = "disabled";
+ };
};
pci0: pcie@fffe09000 {
diff --git a/arch/powerpc/boot/dts/p1020mbg-pc_36b.dts
b/arch/powerpc/boot/dts/p1020mbg-pc_36b.dts
index 9e9f401..416e1a7 100644
--- a/arch/powerpc/boot/dts/p1020mbg-pc_36b.dts
+++ b/arch/powerpc/boot/dts/p1020mbg-pc_36b.dts
@@ -52,6 +52,9 @@
soc: soc@fffe0 {
ranges = <0x0 0xf 0xffe0 0x10>;
+ tdm@16000 {
+ status = "disabled";
+ };
};
pci0: pcie@fffe09000 {
diff --git a/arch/powerpc/boot/dts/p1020rdb-pc_36b.dts
b/arch/powerpc/boot/dts/p1020rdb-pc_36b.dts
index 5237da7..a1861d6 100644
--- a/arch/powerpc/boot/dts/p1020rdb-pc_36b.dts
+++ b/arch/powerpc/boot/dts/p1020rdb-pc_36b.dts
@@ -53,6 +53,9 @@
soc: soc@fffe0 {
ranges = <0x0 0xf 0xffe0 0x10>;
+ tdm@16000 {
+ status = "disabled";
+ };
};
pci0: pcie@fffe09000 {
diff --git a/arch/powerpc/boot/dts/p1020rdb_36b.dts
b/arch/powerpc/boot/dts/p1020rdb_36b.dts
index bdbdb60..7bac196 100644
--- a/arch/powerpc/boot/dts/p1020rdb_36b.dts
+++ b/arch/powerpc/boot/dts/p1020rdb_36b.dts
@@ -29,6 +29,9 @@
board_soc: soc: soc@fffe0 {
ranges = <0x0 0xf 0xffe0 0x10>;
+ tdm@16000 {
+ status = "disabled";
+ };
};
pci0: pcie@fffe09000
[PATCH 2/4] Device Tree bindings for Freescale TDM controller
This controller is available on many Freescale SOCs like MPC8315, P1020, P1010,
P1022 and P1024
Signed-off-by: Sandeep Singh
Signed-off-by: Poonam Aggrwal
---
Documentation/devicetree/bindings/tdm/fsl-tdm.txt | 65 +
1 files changed, 65 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/tdm/fsl-tdm.txt
diff --git a/Documentation/devicetree/bindings/tdm/fsl-tdm.txt
b/Documentation/devicetree/bindings/tdm/fsl-tdm.txt
new file mode 100644
index 000..1258b89
--- /dev/null
+++ b/Documentation/devicetree/bindings/tdm/fsl-tdm.txt
@@ -0,0 +1,65 @@
+=
+TDM Device Tree Binding
+Copyright (C) 2012 Freescale Semiconductor Inc.
+
+NOTE: The bindings described in this document are preliminary
+and subject to change.
+
+=
+TDM (Time Division Multiplexing)
+
+DESCRIPTION
+
+The TDM is full duplex serial port designed to allow various devices including
+digital signal processors (DSPs) to communicate with a variety of serial
devices
+including industry standard framers, codecs, other DSPs and microprocessors.
+
+The below properties describe the device tree bindings for Freescale TDM
+controller.
+This TDM controller is available on various Freescale Processors like
+MPC8313, P1020, P1022 and P1010.
+
+PROPERTIES
+
+ - compatible
+ Usage: required
+ Value type:
+ Definition: Should contain "fsl,tdm1.0".
+
+ - reg
+ Usage: required
+ Definition: A standard property. The first reg specifier describes the
+ TDM registers, and the second describes the TDM DMAC registers.
+
+ - clock-frequency
+ Usage: optional
+ Value type:
+ Definition: The frequency at which the TDM block is operating.
+
+ - interrupts
+ Usage: required
+ Definition: Definition: Two interrupt specifiers. The first is TDM
+ error, and the second is TDM EMAC.
+
+ - phy-handle
+ Usage: optional
+ Value type:
+ Definition: Phandle of the line controller node or framer node eg. SLIC,
+ E1/T1 etc.
+
+ - fsl,max-time-slots
+ Usage: required
+ Value type:
+ Definition: Maximum number of 8-bit time slots in one TDM frame.
+ This is the maximum number which TDM hardware supports.
+
+EXAMPLE
+
+ tdm@16000 {
+ compatible = "fsl,tdm1.0";
+ reg = <0x16000 0x200 0x2c000 0x2000>;
+ clock-frequency = <0>;
+ interrupts = <16 8 62 8>;
+ phy-handle = <&zarlink1>;
+ fsl,max-time-slots = <128>;
+ };
--
1.7.6.GIT
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 1/4] Device tree entry for Freescale TDM controller
Added dtsi file for Freescale TDM controller.
This controller is available on many Freescale SOCs like MPC8315, P1020, P1010,
P1022 and P1024
Signed-off-by: Sandeep Singh
Signed-off-by: Poonam Aggrwal
---
arch/powerpc/boot/dts/fsl/pq3-tdm1.0-0.dtsi | 42 +++
1 files changed, 42 insertions(+), 0 deletions(-)
create mode 100644 arch/powerpc/boot/dts/fsl/pq3-tdm1.0-0.dtsi
diff --git a/arch/powerpc/boot/dts/fsl/pq3-tdm1.0-0.dtsi
b/arch/powerpc/boot/dts/fsl/pq3-tdm1.0-0.dtsi
new file mode 100644
index 000..e89f637
--- /dev/null
+++ b/arch/powerpc/boot/dts/fsl/pq3-tdm1.0-0.dtsi
@@ -0,0 +1,42 @@
+/*
+ * PQ3 TDM device tree stub [ controller @ offset 0x16000 ]
+ *
+ * Copyright 2012 Freescale Semiconductor Inc.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions are met:
+ * * Redistributions of source code must retain the above copyright
+ * notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above copyright
+ * notice, this list of conditions and the following disclaimer in the
+ * documentation and/or other materials provided with the distribution.
+ * * Neither the name of Freescale Semiconductor nor the
+ * names of its contributors may be used to endorse or promote products
+ * derived from this software without specific prior written permission.
+ *
+ *
+ * ALTERNATIVELY, this software may be distributed under the terms of the
+ * GNU General Public License ("GPL") as published by the Free Software
+ * Foundation, either version 2 of that License or (at your option) any
+ * later version.
+ *
+ * THIS SOFTWARE IS PROVIDED BY Freescale Semiconductor ``AS IS'' AND ANY
+ * EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
+ * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
+ * DISCLAIMED. IN NO EVENT SHALL Freescale Semiconductor BE LIABLE FOR ANY
+ * DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
+ * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
+ * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
+ * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
THIS
+ * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+tdm@16000 {
+ compatible = "fsl,tdm1.0";
+ reg = <0x16000 0x200 0x2c000 0x2000>;
+ clock-frequency = <0>;
+ tdm_tx_clk = <2048000>;
+ interrupts = <62 8 0 0>;
+ fsl,max-time-slots = <128>;
+};
--
1.7.6.GIT
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/6] powerpc/fsl_pci: Store the platform device information corresponding to the pci controller.
Yes, please base your patches on the latest upstream-tag. I will move my tree to v3.9-rc1 soon, there are some fixes that need to go upstream. On Thu, Mar 07, 2013 at 09:14:21AM +, Sethi Varun-B16395 wrote: > Hi Joerg, > I have to post the next version of my patchset, should I base it on top of > 3.9-rc1? > By when would you move the iommu git tree to 3.9-rc1? > > Regards > Varun > > > -Original Message- > > From: Kumar Gala [mailto:ga...@kernel.crashing.org] > > Sent: Thursday, February 28, 2013 9:15 PM > > To: Sethi Varun-B16395 > > Cc: Joerg Roedel; Stuart Yoder; io...@lists.linux-foundation.org; > > linuxppc-dev@lists.ozlabs.org; linux-ker...@vger.kernel.org; Wood Scott- > > B07421; Yoder Stuart-B08248 > > Subject: Re: [PATCH 2/6] powerpc/fsl_pci: Store the platform device > > information corresponding to the pci controller. > > > > > > On Feb 27, 2013, at 4:56 AM, Sethi Varun-B16395 wrote: > > > > > This patch is present in the "next branch" of linux ppc tree maintained > > by Kumar Gala. > > > Following is the commit id: > > > 52c5affc545053d37c0b05224bbf70f5336caa20 > > > > > > I am not sure if this would be part of 3.9-rc1. > > > > > > Regards > > > varun > > > > This is now in Linus's tree so will be in 3.9-rc1 > > > > - k > > > > ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH V4] powerpc/85xx: Add machine check handler to fix PCIe erratum on mpc85xx
> In my understanding filling the register could warn the executing process > an error occurred in some cases. But no way to fix the wrong behavior caused > by the instruction lost. So let's say that filling the register may benefit > a little. IIRC the only ppc instructions that should be accessing PCIe space are simple memory reads/writes, locked exchanges probably don't work. writes will be async - so we are talking about memory reads. > On the other side, we should not access to the addresses of unknown process > in Linux kernel. We must get the instruction before filling the register. > If the instruction is not in the cache we have to access to the unknown > addresses to get it. For system security I think this is strictly forbidden. Eh??? The kernel fault handler will know whether the fault is from kernel or userspace (in which case it must be the current process), and will almost certainly already have code that looks at the faulting instruction sequence. If the faulting code address is 'user', then the normal functions for reading user addresses have to be used. If the faulting address is 'kernel' it might be in an ISR - restricting what can be done - but the instruction is definitely readable. > Although I think filling the register have some advantages but it's should > be forbidden for security reason. I'm sure security would say exactly the opposite. David ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: 3.9-rc1 powerpc ptrace.c: 'brk.len' is used uninitialized
Hello Mikey, On Thu, Mar 07, 2013 at 10:14:30AM +1100, Michael Neuling wrote: > Philippe De Muyter wrote: > > > On Thu, Mar 07, 2013 at 09:09:48AM +1100, Michael Neuling wrote: > > > > bisect tells me that since your commit > > > > 9422de3e953d0e60eb95f5430a9dd803eec1c6d7 > > > > "powerpc: Hardware breakpoints rewrite to handle non DABR breakpoint > > > > registers", > > > > compiling linux fails with : > > > > > > > > cc1: warnings being treated as errors > > > > arch/powerpc/kernel/ptrace.c: In function 'arch_ptrace': > > > > arch/powerpc/kernel/ptrace.c:1450: warning: 'brk.len' is used > > > > uninitialized in this function > > > > arch/powerpc/kernel/ptrace.c:1352: note: 'brk.len' was declared here > > > > > > > > could you look at that ? > > > > > > Sure. > > > > I use gcc-4.2.2, and my .config follows. > > I'm a bit lost. > > I don't have 4.2.2 (which is ancient BTW) and I can't hit this on > 4.3,4.5 or 4.6 with your config. It compiles fine. > > Also: > > > arch/powerpc/kernel/ptrace.c:1450: warning: 'brk.len' is used > > uninitialized in this function > > arch/powerpc/kernel/ptrace.c:1352: note: 'brk.len' was declared here > > These line numbers make no sense at all WRT v3.9-rc1. brk.len is neither > declared or used in those lines: those were the line numbers just after your commit In 3.9-rc1 they are : cc1: warnings being treated as errors arch/powerpc/kernel/ptrace.c: In function 'arch_ptrace': arch/powerpc/kernel/ptrace.c:1479: warning: 'brk.len' is used uninitialized in this function arch/powerpc/kernel/ptrace.c:1381: note: 'brk.len' was declared here if (child->thread.hw_brk.address) return -ENOSPC; 1479: child->thread.hw_brk = brk; return 1; #endif /* !CONFIG_PPC_ADV_DEBUG_DVCS */ Philippe ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH 2/6] powerpc/fsl_pci: Store the platform device information corresponding to the pci controller.
Hi Joerg, I have to post the next version of my patchset, should I base it on top of 3.9-rc1? By when would you move the iommu git tree to 3.9-rc1? Regards Varun > -Original Message- > From: Kumar Gala [mailto:ga...@kernel.crashing.org] > Sent: Thursday, February 28, 2013 9:15 PM > To: Sethi Varun-B16395 > Cc: Joerg Roedel; Stuart Yoder; io...@lists.linux-foundation.org; > linuxppc-dev@lists.ozlabs.org; linux-ker...@vger.kernel.org; Wood Scott- > B07421; Yoder Stuart-B08248 > Subject: Re: [PATCH 2/6] powerpc/fsl_pci: Store the platform device > information corresponding to the pci controller. > > > On Feb 27, 2013, at 4:56 AM, Sethi Varun-B16395 wrote: > > > This patch is present in the "next branch" of linux ppc tree maintained > by Kumar Gala. > > Following is the commit id: > > 52c5affc545053d37c0b05224bbf70f5336caa20 > > > > I am not sure if this would be part of 3.9-rc1. > > > > Regards > > varun > > This is now in Linus's tree so will be in 3.9-rc1 > > - k > ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH V4] powerpc/85xx: Add machine check handler to fix PCIe erratum on mpc85xx
> -Original Message-
> From: David Laight [mailto:david.lai...@aculab.com]
> Sent: Wednesday, March 06, 2013 6:24 PM
> To: Jia Hongtao-B38951; Wood Scott-B07421
> Cc: linuxppc-dev@lists.ozlabs.org; Stuart Yoder
> Subject: RE: [PATCH V4] powerpc/85xx: Add machine check handler to fix
> PCIe erratum on mpc85xx
>
> > > Yes, that's (one reason) why you'd want to fill in a known value.
> > > Note the "for now". :-)
> > >
> > > -Scott
> >
> > I think there is no overwhelming reason to fill the destination
> > register with 0x.
> >
> > There's a small chance that 0x is treated as regular data
> > rather than an error sign.
> >
> > Also setting this register may influence the user space under certain
> > circumstance.
> >
> > So I think just ignore the skipped instruction is an acceptable option
> > for this fix.
>
> The 'random' value is just as likely to affect the reader, but only for
> some values - so you'll get almost impossible to repeat bugs.
> If a fixed value (0 or ~0) has an adverse effect, at least it will have
> the same every time.
>
> Read errors are also likely to affect device drivers reading status bits,
> since these are very likely 'write to clear' any driver would have to be
> willing to process the 'dummy' value in a manner that won't loop forever
> (especially in an ISR).
>
> You don't need every access to be via a function that explicitly
> (somehow) detects that the fault happened, but knowing that a specific
> value might be caused by a dead PCIe bus, and being able to find out
> whether that is true (to avoid looping forever) is probably useful.
>
> This is probably similar to what a driver needs to recover from an
> external PCIe list being unplugged.
>
> David
>
>
In my understanding filling the register could warn the executing process
an error occurred in some cases. But no way to fix the wrong behavior caused
by the instruction lost. So let's say that filling the register may benefit
a little.
On the other side, we should not access to the addresses of unknown process
in Linux kernel. We must get the instruction before filling the register.
If the instruction is not in the cache we have to access to the unknown
addresses to get it. For system security I think this is strictly forbidden.
Here is the ideas from Scott:
"
> + if (is_in_pci_mem_space(addr)) {
> + inst = *(unsigned int *)regs->nip;
Be careful about taking a fault here. A simple TLB miss should be safe
given that we shouldn't be accessing PCIe in the middle of exception
code, but what if the mapping has gone away (e.g. a userspace driver had
its code munmap()ed or swapped out)? What if permissions allow execute
but not read (not sure if Linux will allow this, but the hardware does)?
What if it happened in a KVM guest? You can't access guest addresses
directly.
"
Although I think filling the register have some advantages but it's should
be forbidden for security reason.
-Hongtao.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] mmc: sdhci-pltfm: Fix timeout on t4240's sdhci controller
This patch fixes timeout problems on t4240's sdhci controller: mmc0: Too large timeout requested for CMD25! mmc0: Too large timeout requested for CMD25! mmc0: Too large timeout requested for CMD25! Signed-off-by: Chunhe Lan --- drivers/mmc/host/sdhci-pltfm.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/mmc/host/sdhci-pltfm.c b/drivers/mmc/host/sdhci-pltfm.c index 3145a78..9db7b12 100644 --- a/drivers/mmc/host/sdhci-pltfm.c +++ b/drivers/mmc/host/sdhci-pltfm.c @@ -94,6 +94,7 @@ void sdhci_get_of_property(struct platform_device *pdev) if (of_device_is_compatible(np, "fsl,p2020-esdhc") || of_device_is_compatible(np, "fsl,p1010-esdhc") || + of_device_is_compatible(np, "fsl,t4240-esdhc") || of_device_is_compatible(np, "fsl,mpc8536-esdhc")) host->quirks |= SDHCI_QUIRK_BROKEN_TIMEOUT_VAL; -- 1.7.6.5 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
