* Re: CONFIG_ISA_DMA_API without CONFIG_GENERIC_ISA_DMA
From: Timur Tabi @ 2010-06-29 21:27 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev@ozlabs.org list
In-Reply-To: <4B86E05A.1080705@freescale.com>
On Thu, Feb 25, 2010 at 3:40 PM, Scott Wood <scottwood@freescale.com> wrote=
:
> Commit fb4f0e8832e0075849b41b65f6bb9fdfa7593b99 (Enable GENERIC_ISA_DMA i=
f
> FSL_ULI1575 to fix compile issue) tries to deal with this, but it ties it=
to
> CONFIG_FSL_ULI1575, which is not selected in a p4080ds-only config.
>
> It seems that ULI isn't really relevant to the actual problem, which is t=
hat
> we enable ISA DMA API support without selecting an implementation. =A0Whe=
ther
> a certain chip is on the board that has an actual ISA interface is
> irrelevant to the build breakage.
>
> Where did the dependency list for GENERIC_ISA_DMA come from? =A0Are there=
any
> legitimate cases on powerpc where we want to select ISA_DMA_API but not
> GENERIC_ISA_DMA (i.e. we have an alternate implementation)?
I've been bitten by this issue as well on the P1022DS. If I enable
ALSA, then some ISA support also gets compile (by itself, that's
probably a bug), and that code calls claim_dma_lock().
This problem's been around for a long time. I would have encountered
it on the MPC8610 HPCD, but that board has an ULI 1575. The P1022Ds
doesn't.
--=20
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* [PATCH 3/3] gianfar: Implement workaround for eTSEC-A002 erratum
From: Anton Vorontsov @ 2010-06-29 21:00 UTC (permalink / raw)
To: David Miller
Cc: linuxppc-dev, Andy Fleming, Sandeep Gopalpet, Manfred Rudigier,
netdev
MPC8313ECE says:
"If the controller receives a 1- or 2-byte frame (such as an illegal
runt packet or a packet with RX_ER asserted) before GRS is asserted
and does not receive any other frames, the controller may fail to set
GRSC even when the receive logic is completely idle. Any subsequent
receive frame that is larger than two bytes will reset the state so
the graceful stop can complete. A MAC receiver (Rx) reset will also
reset the state."
This patch implements the proposed workaround:
"If IEVENT[GRSC] is still not set after the timeout, read the eTSEC
register at offset 0xD1C. If bits 7-14 are the same as bits 23-30,
the eTSEC Rx is assumed to be idle and the Rx can be safely reset.
If the register fields are not equal, wait for another timeout
period and check again."
Signed-off-by: Anton Vorontsov <avorontsov@mvista.com>
---
drivers/net/gianfar.c | 40 +++++++++++++++++++++++++++++++++++++---
drivers/net/gianfar.h | 1 +
2 files changed, 38 insertions(+), 3 deletions(-)
diff --git a/drivers/net/gianfar.c b/drivers/net/gianfar.c
index f8b9693..f3da17a 100644
--- a/drivers/net/gianfar.c
+++ b/drivers/net/gianfar.c
@@ -947,6 +947,11 @@ static void gfar_detect_errata(struct gfar_private *priv)
(pvr == 0x80861010 && (mod & 0xfff9) == 0x80c0))
priv->errata |= GFAR_ERRATA_76;
+ /* MPC8313 and MPC837x all rev */
+ if ((pvr == 0x80850010 && mod == 0x80b0) ||
+ (pvr == 0x80861010 && (mod & 0xfff9) == 0x80c0))
+ priv->errata |= GFAR_ERRATA_A002;
+
if (priv->errata) {
#ifdef CONFIG_GIANFAR_ERRATA
dev_info(dev, "enabled errata workarounds, flags: 0x%x\n",
@@ -1577,6 +1582,29 @@ static void init_registers(struct net_device *dev)
gfar_write(®s->minflr, MINFLR_INIT_SETTINGS);
}
+static int __gfar_is_rx_idle(struct gfar_private *priv)
+{
+ u32 res;
+
+ /*
+ * Normaly TSEC should not hang on GRS commands, so we should
+ * actually wait for IEVENT_GRSC flag.
+ */
+ if (likely(!gfar_has_errata(priv, A002)))
+ return 0;
+
+ /*
+ * Read the eTSEC register at offset 0xD1C. If bits 7-14 are
+ * the same as bits 23-30, the eTSEC Rx is assumed to be idle
+ * and the Rx can be safely reset.
+ */
+ res = gfar_read((void __iomem *)priv->gfargrp[0].regs + 0xd1c);
+ res &= 0x7f807f80;
+ if ((res & 0xffff) == (res >> 16))
+ return 1;
+
+ return 0;
+}
/* Halt the receive and transmit queues */
static void gfar_halt_nodisable(struct net_device *dev)
@@ -1600,12 +1628,18 @@ static void gfar_halt_nodisable(struct net_device *dev)
tempval = gfar_read(®s->dmactrl);
if ((tempval & (DMACTRL_GRS | DMACTRL_GTS))
!= (DMACTRL_GRS | DMACTRL_GTS)) {
+ int ret;
+
tempval |= (DMACTRL_GRS | DMACTRL_GTS);
gfar_write(®s->dmactrl, tempval);
- spin_event_timeout(((gfar_read(®s->ievent) &
- (IEVENT_GRSC | IEVENT_GTSC)) ==
- (IEVENT_GRSC | IEVENT_GTSC)), -1, 0);
+ do {
+ ret = spin_event_timeout(((gfar_read(®s->ievent) &
+ (IEVENT_GRSC | IEVENT_GTSC)) ==
+ (IEVENT_GRSC | IEVENT_GTSC)), 1000000, 0);
+ if (!(gfar_read(®s->ievent) & IEVENT_GRSC))
+ ret = __gfar_is_rx_idle(priv);
+ } while (!ret);
}
}
diff --git a/drivers/net/gianfar.h b/drivers/net/gianfar.h
index fb308c8..e0907eb 100644
--- a/drivers/net/gianfar.h
+++ b/drivers/net/gianfar.h
@@ -1028,6 +1028,7 @@ struct gfar_priv_grp {
enum gfar_errata {
GFAR_ERRATA_74 = 0x01,
GFAR_ERRATA_76 = 0x02,
+ GFAR_ERRATA_A002 = 0x04,
};
#ifdef CONFIG_GIANFAR_ERRATA
--
1.7.0.5
^ permalink raw reply related
* [PATCH 2/3] gianfar: Implement workaround for eTSEC76 erratum
From: Anton Vorontsov @ 2010-06-29 21:00 UTC (permalink / raw)
To: David Miller
Cc: linuxppc-dev, Andy Fleming, Sandeep Gopalpet, Manfred Rudigier,
netdev
MPC8313ECE says:
"For TOE=1 huge or jumbo frames, the data required to generate the
checksum may exceed the 2500-byte threshold beyond which the controller
constrains itself to one memory fetch every 256 eTSEC system clocks.
This throttling threshold is supposed to trigger only when the
controller has sufficient data to keep transmit active for the duration
of the memory fetches. The state machine handling this threshold,
however, fails to take large TOE frames into account. As a result,
TOE=1 frames larger than 2500 bytes often see excess delays before start
of transmission."
This patch implements the workaround as suggested by the errata
document, i.e.:
"Limit TOE=1 frames to less than 2500 bytes to avoid excess delays due to
memory throttling.
When using packets larger than 2700 bytes, it is recommended to turn TOE
off."
To be sure, we limit the TOE frames to 2500 bytes, and do software
checksumming instead.
Signed-off-by: Anton Vorontsov <avorontsov@mvista.com>
---
drivers/net/gianfar.c | 19 +++++++++++++++++++
drivers/net/gianfar.h | 1 +
2 files changed, 20 insertions(+), 0 deletions(-)
diff --git a/drivers/net/gianfar.c b/drivers/net/gianfar.c
index 9c85d05..f8b9693 100644
--- a/drivers/net/gianfar.c
+++ b/drivers/net/gianfar.c
@@ -942,6 +942,11 @@ static void gfar_detect_errata(struct gfar_private *priv)
(pvr == 0x80861010 && (mod & 0xfff9) == 0x80c0))
priv->errata |= GFAR_ERRATA_74;
+ /* MPC8313 and MPC837x all rev */
+ if ((pvr == 0x80850010 && mod == 0x80b0) ||
+ (pvr == 0x80861010 && (mod & 0xfff9) == 0x80c0))
+ priv->errata |= GFAR_ERRATA_76;
+
if (priv->errata) {
#ifdef CONFIG_GIANFAR_ERRATA
dev_info(dev, "enabled errata workarounds, flags: 0x%x\n",
@@ -2018,6 +2023,20 @@ static int gfar_start_xmit(struct sk_buff *skb, struct net_device *dev)
unsigned int nr_frags, nr_txbds, length;
union skb_shared_tx *shtx;
+ /*
+ * TOE=1 frames larger than 2500 bytes may see excess delays
+ * before start of transmission.
+ */
+ if (unlikely(gfar_has_errata(priv, 76) &&
+ skb->ip_summed == CHECKSUM_PARTIAL &&
+ skb->len > 2500)) {
+ int ret;
+
+ ret = skb_checksum_help(skb);
+ if (ret)
+ return ret;
+ }
+
rq = skb->queue_mapping;
tx_queue = priv->tx_queue[rq];
txq = netdev_get_tx_queue(dev, rq);
diff --git a/drivers/net/gianfar.h b/drivers/net/gianfar.h
index d1e2986..fb308c8 100644
--- a/drivers/net/gianfar.h
+++ b/drivers/net/gianfar.h
@@ -1027,6 +1027,7 @@ struct gfar_priv_grp {
enum gfar_errata {
GFAR_ERRATA_74 = 0x01,
+ GFAR_ERRATA_76 = 0x02,
};
#ifdef CONFIG_GIANFAR_ERRATA
--
1.7.0.5
^ permalink raw reply related
* [PATCH 1/3] gianfar: Implement workaround for eTSEC74 erratum
From: Anton Vorontsov @ 2010-06-29 20:59 UTC (permalink / raw)
To: David Miller
Cc: linuxppc-dev, Andy Fleming, Sandeep Gopalpet, Manfred Rudigier,
netdev
MPC8313ECE says:
"If MACCFG2[Huge Frame]=0 and the Ethernet controller receives frames
which are larger than MAXFRM, the controller truncates the frames to
length MAXFRM and marks RxBD[TR]=1 to indicate the error. The controller
also erroneously marks RxBD[TR]=1 if the received frame length is MAXFRM
or MAXFRM-1, even though those frames are not truncated.
No truncation or truncation error occurs if MACCFG2[Huge Frame]=1."
There are two options to workaround the issue:
"1. Set MACCFG2[Huge Frame]=1, so no truncation occurs for invalid large
frames. Software can determine if a frame is larger than MAXFRM by
reading RxBD[LG] or RxBD[Data Length].
2. Set MAXFRM to 1538 (0x602) instead of the default 1536 (0x600), so
normal-length frames are not marked as truncated. Software can examine
RxBD[Data Length] to determine if the frame was larger than MAXFRM-2."
This patch implements the first workaround option by setting HUGEFRAME
bit, and gfar_clean_rx_ring() already checks the RxBD[Data Length].
Signed-off-by: Anton Vorontsov <avorontsov@mvista.com>
---
drivers/net/Kconfig | 10 ++++++++++
drivers/net/gianfar.c | 36 ++++++++++++++++++++++++++++++++++--
drivers/net/gianfar.h | 11 +++++++++++
3 files changed, 55 insertions(+), 2 deletions(-)
diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index ce2fcdd..d3fcaba 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -2400,6 +2400,16 @@ config GIANFAR
This driver supports the Gigabit TSEC on the MPC83xx, MPC85xx,
and MPC86xx family of chips, and the FEC on the 8540.
+config GIANFAR_ERRATA
+ bool "Gianfar Ethernet errata handling"
+ depends on GIANFAR && (PPC_MPC837x || PPC_MPC831x)
+ default y
+ help
+ With this option enabled, gianfar driver will able to cope with
+ some TSEC errata.
+
+ If unsure, say Y.
+
config UCC_GETH
tristate "Freescale QE Gigabit Ethernet"
depends on QUICC_ENGINE
diff --git a/drivers/net/gianfar.c b/drivers/net/gianfar.c
index 28b53d1..9c85d05 100644
--- a/drivers/net/gianfar.c
+++ b/drivers/net/gianfar.c
@@ -85,6 +85,7 @@
#include <linux/net_tstamp.h>
#include <asm/io.h>
+#include <asm/reg.h>
#include <asm/irq.h>
#include <asm/uaccess.h>
#include <linux/module.h>
@@ -928,6 +929,31 @@ static void gfar_init_filer_table(struct gfar_private *priv)
}
}
+static void gfar_detect_errata(struct gfar_private *priv)
+{
+ struct device *dev = &priv->ofdev->dev;
+ unsigned int pvr = mfspr(SPRN_PVR);
+ unsigned int svr = mfspr(SPRN_SVR);
+ unsigned int mod = (svr >> 16) & 0xfff6; /* w/o E suffix */
+ unsigned int rev = svr & 0xffff;
+
+ /* MPC8313 Rev 2.0 and higher; All MPC837x */
+ if ((pvr == 0x80850010 && mod == 0x80b0 && rev >= 0x0020) ||
+ (pvr == 0x80861010 && (mod & 0xfff9) == 0x80c0))
+ priv->errata |= GFAR_ERRATA_74;
+
+ if (priv->errata) {
+#ifdef CONFIG_GIANFAR_ERRATA
+ dev_info(dev, "enabled errata workarounds, flags: 0x%x\n",
+ priv->errata);
+#else
+ dev_warn(dev, "consider enabling CONFIG_GIANFAR_ERRATA, "
+ "flags: 0x%x\n", priv->errata);
+ WARN_ON(1);
+#endif /* CONFIG_GIANFAR_ERRATA */
+ }
+}
+
/* Set up the ethernet device structure, private data,
* and anything else we need before we start */
static int gfar_probe(struct of_device *ofdev,
@@ -960,6 +986,8 @@ static int gfar_probe(struct of_device *ofdev,
dev_set_drvdata(&ofdev->dev, priv);
regs = priv->gfargrp[0].regs;
+ gfar_detect_errata(priv);
+
/* Stop the DMA engine now, in case it was running before */
/* (The firmware could have used it, and left it running). */
gfar_halt(dev);
@@ -974,7 +1002,10 @@ static int gfar_probe(struct of_device *ofdev,
gfar_write(®s->maccfg1, tempval);
/* Initialize MACCFG2. */
- gfar_write(®s->maccfg2, MACCFG2_INIT_SETTINGS);
+ tempval = MACCFG2_INIT_SETTINGS;
+ if (gfar_has_errata(priv, 74))
+ tempval |= MACCFG2_HUGEFRAME | MACCFG2_LENGTHCHECK;
+ gfar_write(®s->maccfg2, tempval);
/* Initialize ECNTRL */
gfar_write(®s->ecntrl, ECNTRL_INIT_SETTINGS);
@@ -2300,7 +2331,8 @@ static int gfar_change_mtu(struct net_device *dev, int new_mtu)
* to allow huge frames, and to check the length */
tempval = gfar_read(®s->maccfg2);
- if (priv->rx_buffer_size > DEFAULT_RX_BUFFER_SIZE)
+ if (priv->rx_buffer_size > DEFAULT_RX_BUFFER_SIZE ||
+ gfar_has_errata(priv, 74))
tempval |= (MACCFG2_HUGEFRAME | MACCFG2_LENGTHCHECK);
else
tempval &= ~(MACCFG2_HUGEFRAME | MACCFG2_LENGTHCHECK);
diff --git a/drivers/net/gianfar.h b/drivers/net/gianfar.h
index ac4a92e..d1e2986 100644
--- a/drivers/net/gianfar.h
+++ b/drivers/net/gianfar.h
@@ -1025,6 +1025,16 @@ struct gfar_priv_grp {
char int_name_er[GFAR_INT_NAME_MAX];
};
+enum gfar_errata {
+ GFAR_ERRATA_74 = 0x01,
+};
+
+#ifdef CONFIG_GIANFAR_ERRATA
+#define gfar_has_errata(priv, err) ((priv)->errata & GFAR_ERRATA_##err)
+#else
+#define gfar_has_errata(priv, err) 0
+#endif /* CONFIG_GIANFAR_ERRATA */
+
/* Struct stolen almost completely (and shamelessly) from the FCC enet source
* (Ok, that's not so true anymore, but there is a family resemblence)
* The GFAR buffer descriptors track the ring buffers. The rx_bd_base
@@ -1049,6 +1059,7 @@ struct gfar_private {
struct device_node *node;
struct net_device *ndev;
struct of_device *ofdev;
+ enum gfar_errata errata;
struct gfar_priv_grp gfargrp[MAXGROUPS];
struct gfar_priv_tx_q *tx_queue[MAX_TX_QS];
--
1.7.0.5
^ permalink raw reply related
* CONFIG_NO_HZ causing poor console responsiveness
From: Timur Tabi @ 2010-06-29 19:54 UTC (permalink / raw)
To: Linuxppc-dev Development
I'm adding support for a new e500-based board (the P1022DS), and in
the process I've discovered that enabling CONFIG_NO_HZ (Tickless
System / Dynamic Ticks) causes significant responsiveness problems on
the serial console. When I type on the console, I see delays of up to
a half-second for almost every character. It acts as if there's a
background process eating all the CPU.
I don't have time to debug this thoroughly at the moment. The problem
occurs in the latest kernel, but it appears not to occur in 2.6.32.
Has anyone else seen anything like this?
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* [PATCH 2/2] powerpc/85xx platorms: kexec for SMP 85xx BookE systems
From: Matthew McClintock @ 2010-06-29 19:42 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <1277840547-19007-1-git-send-email-msm@freescale.com>
Adds support for kexec on 85xx machines for the BookE platform.
Including support for SMP machines
Based off work from Maxim Uvarov <muvarov@mvista.com>
Signed-off-by: Matthew McClintock <msm@freescale.com>
---
To test/use you will need to fetch kexec from GIT and apply the following
patch for kexec to work properply with uImages
http://lists.infradead.org/pipermail/kexec/2010-June/004163.html
arch/powerpc/Kconfig | 2 +-
arch/powerpc/platforms/85xx/smp.c | 57 +++++++++++++++++++++++++++++++++++++
2 files changed, 58 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 328774b..042f2f0 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -351,7 +351,7 @@ config ARCH_ENABLE_MEMORY_HOTREMOVE
config KEXEC
bool "kexec system call (EXPERIMENTAL)"
- depends on (PPC_BOOK3S || (FSL_BOOKE && !SMP)) && EXPERIMENTAL
+ depends on (PPC_BOOK3S || FSL_BOOKE) && EXPERIMENTAL
help
kexec is a system call that implements the ability to shutdown your
current kernel, and to start another kernel. It is like a reboot
diff --git a/arch/powerpc/platforms/85xx/smp.c b/arch/powerpc/platforms/85xx/smp.c
index a15f582..35c3d95 100644
--- a/arch/powerpc/platforms/85xx/smp.c
+++ b/arch/powerpc/platforms/85xx/smp.c
@@ -15,6 +15,7 @@
#include <linux/init.h>
#include <linux/delay.h>
#include <linux/of.h>
+#include <linux/kexec.h>
#include <asm/machdep.h>
#include <asm/pgtable.h>
@@ -24,6 +25,7 @@
#include <asm/dbell.h>
#include <sysdev/fsl_soc.h>
+#include <sysdev/mpic.h>
extern void __early_start(void);
@@ -103,8 +105,58 @@ smp_85xx_setup_cpu(int cpu_nr)
struct smp_ops_t smp_85xx_ops = {
.kick_cpu = smp_85xx_kick_cpu,
+#ifdef CONFIG_KEXEC
+ .give_timebase = smp_generic_give_timebase,
+ .take_timebase = smp_generic_take_timebase,
+#endif
};
+#ifdef CONFIG_KEXEC
+void mpc85xx_smp_kexec_cpu_down(int crash_shutdown, int secondary)
+{
+ mpic_teardown_this_cpu(1);
+}
+
+static int kexec_down_cpus = 0;
+
+static void mpc85xx_smp_kexec_down(void *arg)
+{
+ if (ppc_md.kexec_cpu_down)
+ ppc_md.kexec_cpu_down(0,1);
+
+ local_irq_disable();
+ kexec_down_cpus++;
+ while (1) ;
+}
+
+static void mpc85xx_smp_machine_kexec(struct kimage *image)
+{
+ int timeout = 1000;
+ int i;
+
+ set_cpus_allowed(current, cpumask_of_cpu(boot_cpuid));
+
+ smp_call_function(mpc85xx_smp_kexec_down, NULL, 0);
+
+ while ( (kexec_down_cpus != (num_present_cpus() - 1)) &&
+ ( timeout-- > 0 ) )
+ {
+ timeout--;
+ }
+
+ if ( !timeout )
+ printk(KERN_ERR "Unable to bring down secondary cpu(s)");
+
+ for (i = 0; i < num_present_cpus(); i++)
+ {
+ if ( i == smp_processor_id() ) continue;
+ mpic_reset_core(i);
+ }
+
+ default_machine_kexec(image);
+}
+#endif /* CONFIG_KEXEC */
+
void __init mpc85xx_smp_init(void)
{
struct device_node *np;
@@ -122,4 +174,9 @@ void __init mpc85xx_smp_init(void)
BUG_ON(!smp_85xx_ops.message_pass);
smp_ops = &smp_85xx_ops;
+
+#ifdef CONFIG_KEXEC
+ ppc_md.kexec_cpu_down = mpc85xx_smp_kexec_cpu_down;
+ ppc_md.machine_kexec = mpc85xx_smp_machine_kexec;
+#endif
}
--
1.6.6.1
^ permalink raw reply related
* [PATCH 1/2] powerpc/mpic: Add ability to reset a core via MPIC
From: Matthew McClintock @ 2010-06-29 19:42 UTC (permalink / raw)
To: linuxppc-dev
We need the ability to reset cores for use with kexec/kdump for
SMP systems. Calling this function with the specific core you want
to reset will cause the CPU to spin in reset.
Signed-off-by: Matthew McClintock <msm@freescale.com>
---
arch/powerpc/sysdev/mpic.c | 18 ++++++++++++++++++
arch/powerpc/sysdev/mpic.h | 1 +
2 files changed, 19 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/sysdev/mpic.c b/arch/powerpc/sysdev/mpic.c
index 20b73c0..7c13426 100644
--- a/arch/powerpc/sysdev/mpic.c
+++ b/arch/powerpc/sysdev/mpic.c
@@ -1636,6 +1636,24 @@ void __devinit smp_mpic_setup_cpu(int cpu)
{
mpic_setup_this_cpu();
}
+
+void mpic_reset_core(int cpu)
+{
+ struct mpic *mpic = mpic_primary;
+ u32 pir;
+ int cpuid = get_hard_smp_processor_id(cpu);
+
+ /* Set target bit for core reset */
+ pir = mpic_read(mpic->gregs, MPIC_INFO(GREG_PROCESSOR_INIT));
+ pir |= (1 << cpuid);
+ mpic_write(mpic->gregs, MPIC_INFO(GREG_PROCESSOR_INIT), pir);
+ mpic_read(mpic->gregs, MPIC_INFO(GREG_PROCESSOR_INIT));
+
+ /* Restore target bit after reset complete */
+ pir &= ~(1 << cpuid);
+ mpic_write(mpic->gregs, MPIC_INFO(GREG_PROCESSOR_INIT), pir);
+ mpic_read(mpic->gregs, MPIC_INFO(GREG_PROCESSOR_INIT));
+}
#endif /* CONFIG_SMP */
#ifdef CONFIG_PM
diff --git a/arch/powerpc/sysdev/mpic.h b/arch/powerpc/sysdev/mpic.h
index eff433c..e4a6df7 100644
--- a/arch/powerpc/sysdev/mpic.h
+++ b/arch/powerpc/sysdev/mpic.h
@@ -37,5 +37,6 @@ static inline int mpic_pasemi_msi_init(struct mpic *mpic)
extern int mpic_set_irq_type(unsigned int virq, unsigned int flow_type);
extern void mpic_set_vector(unsigned int virq, unsigned int vector);
extern int mpic_set_affinity(unsigned int irq, const struct cpumask *cpumask);
+extern void mpic_reset_core(int cpu);
#endif /* _POWERPC_SYSDEV_MPIC_H */
--
1.6.6.1
^ permalink raw reply related
* [PATCH] powerpc/fsl-booke: Fix address issue when using relocatable kernels
From: Matthew McClintock @ 2010-06-29 19:42 UTC (permalink / raw)
To: linuxppc-dev
When booting a relocatable kernel it needs to jump to the correct
start address, which for BookE parts is usually unchanged
regardless of the physical memory offset.
Recent changes cause problems with how we calculate the start
address, it was always adding the RMO into the start address
which is incorrect. This patch only adds in the RMO offset
if we are in the kexec code path, as it needs the RMO to work
correctly.
Instead of adding the RMO offset in in the common code path, we
can just set r6 to the RMO offset in the kexec code path instead
of to zero, and finally perform the masking in the common code
path
Signed-off-by: Matthew McClintock <msm@freescale.com>
---
arch/powerpc/kernel/fsl_booke_entry_mapping.S | 4 +---
1 files changed, 1 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/kernel/fsl_booke_entry_mapping.S b/arch/powerpc/kernel/fsl_booke_entry_mapping.S
index beb4d78..a92c79b 100644
--- a/arch/powerpc/kernel/fsl_booke_entry_mapping.S
+++ b/arch/powerpc/kernel/fsl_booke_entry_mapping.S
@@ -205,8 +205,7 @@ next_tlb_setup:
bdnz+ next_tlb_setup
/* 7. Jump to our 1:1 mapping */
- li r6, 0
-
+ mr r6, r25
#else
#error You need to specify the mapping or not use this at all.
#endif
@@ -217,7 +216,6 @@ next_tlb_setup:
1: mflr r9
rlwimi r6,r9,0,20,31
addi r6,r6,(2f - 1b)
- add r6, r6, r25
mtspr SPRN_SRR0,r6
mtspr SPRN_SRR1,r7
rfi /* start execution out of TLB1[0] entry */
--
1.6.6.1
^ permalink raw reply related
* Re: machine check in kernel for a mpc870 board
From: Scott Wood @ 2010-06-29 18:56 UTC (permalink / raw)
To: Shawn Jin; +Cc: ppcdev
In-Reply-To: <AANLkTinA2ghLxBU41aFAsLM1oXQ8HMASx1eQMDVvi56n@mail.gmail.com>
On Tue, Jun 29, 2010 at 12:59:56AM -0700, Shawn Jin wrote:
> I'm porting a mpc870 board to the powerpc arch. The base is the
> adder-875 board. My first try to boot the cuImage.my870 is
> experiencing a machine check. And I have no clue where to look. Any
> help?
>
> => bootm 1000000
> ## Booting image at 01000000 ...
> Image Name: Linux-2.6.33.5
> Image Type: PowerPC Linux Kernel Image (gzip compressed)
> Data Size: 747319 Bytes = 729.8 kB
> Load Address: 00400000
> Entry Point: 004004d4
> Verifying Checksum ... OK
> Uncompressing Kernel Image ... OK
> Bus Fault @ 0x00404c40, fixup 0x00000000
> Machine check in kernel mode.
> Caused by (from msr): regs 07d1cb80 Unknown values in msr
> NIP: 00404C40 XER: 00000000 LR: 00404C24 REGS: 07d1cb80 TRAP: 0200 DAR: 00000001
> MSR: 00001002 EE: 0 PR: 0 FP: 0 ME: 1 IR/DR: 00
Can you look up the source line/instruction corresponding to 0x404c40, in
the wrapper ELF file?
-Scott
^ permalink raw reply
* Re: [PATCH] arch/powerpc/lib/copy_32.S: Use alternate memcpy for MPC512x and MPC52xx
From: Segher Boessenkool @ 2010-06-29 16:58 UTC (permalink / raw)
To: Steve Deiters; +Cc: linuxppc-dev
In-Reply-To: <181804936ABC2349BE503168465576460F272CA4@exchserver.basler.com>
> These processors will corrupt data if accessing the local bus with
> unaligned
> addresses. This version fixes the typical case of copying from
> Flash on
> the
> local bus by keeping the source address always aligned.
On many platforms accessing ROM as RAM simply doesn't work(*). You
shouldn't
map ROM as if it is RAM, and shouldn't use the same access functions
on it.
Segher
(*) Example: any existing 970 system will checkstop as soon as you
try to
do any cacheable access to some ROM. Another example of course is
unaligned
accesses on pretty much any system, no matter whether it's called a
bug or
a feature on that system :-P
^ permalink raw reply
* [RFC Patch 1/1] Implement hardware breakpoint interfaces for PowerPC BookE processors
From: K.Prasad @ 2010-06-29 16:52 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20100628135631.332818538@linux.vnet.ibm.com>
Introduce support for generic hw-breakpoint interfaces for PowerPC
BookIII E processors.
Signed-off-by: K.Prasad <prasad@linux.vnet.ibm.com>
---
arch/powerpc/Kconfig | 2
arch/powerpc/include/asm/cputable.h | 4
arch/powerpc/include/asm/hw_breakpoint_booke.h | 46 ++
arch/powerpc/kernel/Makefile | 4
arch/powerpc/kernel/hw_breakpoint_booke.c | 429 +++++++++++++++++++++++++
arch/powerpc/kernel/process.c | 3
arch/powerpc/kernel/ptrace.c | 51 ++
arch/powerpc/kernel/traps.c | 9
include/linux/perf_event.h | 4
kernel/trace/trace_ksym.c | 4
10 files changed, 554 insertions(+), 2 deletions(-)
Index: linux-2.6.bookE/arch/powerpc/include/asm/hw_breakpoint_booke.h
===================================================================
--- /dev/null
+++ linux-2.6.bookE/arch/powerpc/include/asm/hw_breakpoint_booke.h
@@ -0,0 +1,46 @@
+#ifndef _I386_HW_BREAKPOINT_H
+#define _I386_HW_BREAKPOINT_H
+
+#ifdef __KERNEL__
+#define __ARCH_HW_BREAKPOINT_H
+
+struct arch_hw_breakpoint {
+ unsigned int len;
+ unsigned long address;
+ unsigned long type;
+};
+
+#include <linux/kdebug.h>
+#include <linux/percpu.h>
+#include <linux/list.h>
+
+/* Breakpoint length beyond which we should use 'range' breakpoints */
+#define DAC_LEN 8
+#define HW_BREAKPOINT_ALIGN 0x3
+
+static inline int hw_breakpoint_slots(int type)
+{
+ return HBP_NUM;
+}
+
+struct perf_event;
+struct perf_sample_data;
+struct pmu;
+
+extern int arch_check_bp_in_kernelspace(struct perf_event *bp);
+extern int arch_validate_hwbkpt_settings(struct perf_event *bp);
+extern int hw_breakpoint_exceptions_notify(struct notifier_block *unused,
+ unsigned long val, void *data);
+extern void hw_breakpoint_handler(struct pt_regs *regs,
+ unsigned long debug_status);
+int arch_install_hw_breakpoint(struct perf_event *bp);
+void arch_uninstall_hw_breakpoint(struct perf_event *bp);
+void hw_breakpoint_pmu_read(struct perf_event *bp);
+extern void ptrace_triggered(struct perf_event *bp, int nmi,
+ struct perf_sample_data *data, struct pt_regs *regs);
+
+extern struct pmu perf_ops_bp;
+
+#endif /* __KERNEL__ */
+#endif /* _I386_HW_BREAKPOINT_H */
+
Index: linux-2.6.bookE/arch/powerpc/kernel/hw_breakpoint_booke.c
===================================================================
--- /dev/null
+++ linux-2.6.bookE/arch/powerpc/kernel/hw_breakpoint_booke.c
@@ -0,0 +1,429 @@
+/*
+ * HW_breakpoint: a unified kernel/user-space hardware breakpoint facility,
+ * using the CPU's debug registers for PowerPC BookIII E. Derived from
+ * "arch/powerpc/kernel/hw_breakpoint.c"
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+ *
+ * Copyright 2010 IBM Corporation
+ * Author: K.Prasad <prasad@linux.vnet.ibm.com>
+ *
+ */
+
+#include <linux/perf_event.h>
+#include <linux/hw_breakpoint.h>
+#include <linux/notifier.h>
+#include <linux/percpu.h>
+#include <linux/kprobes.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/sched.h>
+#include <linux/init.h>
+#include <linux/smp.h>
+
+#include <asm/hw_breakpoint_booke.h>
+#include <asm/reg_booke.h>
+#include <asm/uaccess.h>
+#include <asm/sstep.h>
+#include <asm/reg.h>
+
+/*
+ * Stores the breakpoints currently in use on each debug register for each CPU
+ * register for each cpus
+ */
+static DEFINE_PER_CPU(struct perf_event *, bp_per_reg[HBP_NUM]);
+
+int hw_breakpoint_weight(struct perf_event *bp)
+{
+ return (bp->attr.bp_len > DAC_LEN) ? 2 : 1;
+}
+
+/*
+ * Install a perf counter breakpoint.
+ *
+ * We seek a free debug address register and use it for this
+ * breakpoint. Eventually we enable it in the debug control register.
+ *
+ * Atomic: we hold the counter->ctx->lock and we only handle variables
+ * and registers local to this cpu.
+ */
+int arch_install_hw_breakpoint(struct perf_event *bp)
+{
+ int i;
+ struct arch_hw_breakpoint *info = counter_arch_bp(bp);
+ unsigned long dbcr0 = mfspr(SPRN_DBCR0);
+
+ for (i = 0; i < HBP_NUM; i++) {
+ struct perf_event **slot = &__get_cpu_var(bp_per_reg[i]);
+
+ if (*slot)
+ continue;
+ *slot = bp;
+ mtspr(SPRN_DAC1, info->address);
+ /* Clean the 'type' fields from DBCR0 to erase old values */
+ dbcr0 &= ~(DBCR0_DAC1W | DBCR0_DAC1R | DBCR0_DAC2W | DBCR0_DAC2R);
+
+ mtspr(SPRN_DBCR0, dbcr0 |
+ (info->type > i) | DBCR0_IDM);
+ /*
+ * Use DAC2 register in 'range' mode if the length of the
+ * breakpoint request is 'large'
+ */
+ if (unlikely(info->len > DAC_LEN)) {
+ /* Check if there's a free debug register */
+ if (i > (HBP_NUM - hw_breakpoint_weight(bp))) {
+ *slot = NULL;
+ mtspr(SPRN_DBCR0, dbcr0);
+ return -EBUSY;
+ }
+ slot++;
+ i++;
+ /*
+ * In 'range' mode use two debug registers, but copy
+ * same breakpoint structure in both slots
+ */
+ *slot = bp;
+ mtspr(SPRN_DAC2, info->address + info->len);
+ mtspr(SPRN_DBCR0, mfspr(SPRN_DBCR0) |
+ (info->type >> i) | DBCR0_IDM);
+ /* We support only 'inclusive' range for now */
+ mtspr(SPRN_DBCR2, DBCR2_DAC12M);
+ }
+ break;
+ }
+
+ return 0;
+}
+
+/*
+ * Uninstall the breakpoint contained in the given counter.
+ *
+ * First we search the debug address register it uses and then we disable
+ * it.
+ *
+ * Atomic: we hold the counter->ctx->lock and we only handle variables
+ * and registers local to this cpu.
+ */
+void arch_uninstall_hw_breakpoint(struct perf_event *bp)
+{
+ struct arch_hw_breakpoint *info = counter_arch_bp(bp);
+ int i;
+ unsigned long dbcr0 = mfspr(SPRN_DBCR0);
+
+ for (i = 0; i < HBP_NUM; i++) {
+ struct perf_event **slot = &__get_cpu_var(bp_per_reg[i]);
+
+ if (*slot != bp)
+ continue;
+ *slot = NULL;
+ dbcr0 &= ~((DBCR0_DAC1W | DBCR0_DAC1R) >> i);
+ mtspr(SPRN_DBCR0, dbcr0);
+ if (info->len > DAC_LEN) {
+ slot++;
+ i++;
+ *slot = NULL;
+ dbcr0 &= ~((DBCR0_DAC1W | DBCR0_DAC1R) >> i);
+ mtspr(SPRN_DBCR0, dbcr0);
+ }
+ break;
+ }
+
+ if (WARN_ONCE(i == HBP_NUM, "Can't find any breakpoint slot"))
+ return;
+}
+
+/*
+ * Perform cleanup of arch-specific counters during unregistration
+ * of the perf-event
+ */
+void arch_unregister_hw_breakpoint(struct perf_event *bp)
+{
+ /*
+ * If the breakpoint is unregistered between a hw_breakpoint_handler()
+ * and the single_step_dabr_instruction(), then cleanup the breakpoint
+ * restoration variables to prevent dangling pointers.
+ */
+ if (bp->ctx->task)
+ bp->ctx->task->thread.last_hit_ubp = NULL;
+}
+
+/*
+ * Check for virtual address in kernel space.
+ */
+int arch_check_bp_in_kernelspace(struct perf_event *bp)
+{
+ unsigned long va;
+ struct arch_hw_breakpoint *info = counter_arch_bp(bp);
+
+ va = info->address;
+ return (va >= TASK_SIZE) && ((va + info->len - 1) >= TASK_SIZE);
+}
+
+/*
+ * Validate the arch-specific HW Breakpoint register settings
+ */
+int arch_validate_hwbkpt_settings(struct perf_event *bp)
+{
+ struct arch_hw_breakpoint *info = counter_arch_bp(bp);
+
+ switch (bp->attr.bp_type) {
+ case HW_BREAKPOINT_R:
+ info->type = DBCR0_DAC1R;
+ break;
+ case HW_BREAKPOINT_W:
+ info->type = DBCR0_DAC1W;
+ break;
+ case HW_BREAKPOINT_W | HW_BREAKPOINT_R:
+ info->type = (DBCR0_DAC1W | DBCR0_DAC1R);
+ break;
+ default:
+ return -EINVAL;
+ }
+
+ /* Verify if breakpoint length is less than 2^32 bytes */
+ if (bp->attr.bp_len == (unsigned int)bp->attr.bp_len)
+ info->len = bp->attr.bp_len;
+ else
+ return -EINVAL;
+ info->address = bp->attr.bp_addr;
+ return 0;
+}
+
+/*
+ * Release the user breakpoints used by ptrace
+ */
+void flush_ptrace_hw_breakpoint(struct task_struct *tsk)
+{
+ struct thread_struct *t = &tsk->thread;
+
+ unregister_hw_breakpoint(t->ptrace_bps[0]);
+ t->ptrace_bps[0] = NULL;
+}
+
+
+/*
+ * Invoke this function to populate DAC register with values corresponding
+ * to the registered breakpoints. The list of breakpoints is learnt from the
+ * per-CPU 'bp_per_reg' structure.
+ */
+static void restore_breakpoint_dac(struct perf_event *bp)
+{
+ unsigned int i;
+ unsigned long dbcr0 = mfspr(SPRN_DBCR0);
+ struct arch_hw_breakpoint *bp_info = counter_arch_bp(bp);
+
+ /*
+ * Loop through the slots to identify the appropriate DAC register
+ * and restore the breakpoint values
+ */
+ for (i = 0; i < HBP_NUM; i++) {
+ struct perf_event **slot = &__get_cpu_var(bp_per_reg[i]);
+
+ if (*slot != bp)
+ continue;
+
+ /* Restore the breakpoint */
+ dbcr0 |= DBCR0_IDM | (bp_info->type >> i);
+ i++;
+ if (unlikely((bp_info->len > DAC_LEN) && (i != HBP_NUM)))
+ dbcr0 |= (bp_info->type >> i);
+ mtspr(SPRN_DBCR0, dbcr0);
+ break;
+ }
+}
+
+/*
+ * Restores the breakpoint on the debug registers.
+ * Invoke this function if it is known that the execution context is about to
+ * change to cause loss of MSR_SE settings.
+ */
+void thread_change_pc(struct task_struct *tsk, struct pt_regs *regs)
+{
+ struct perf_event *bp = NULL;
+
+ if (likely(!tsk->thread.last_hit_ubp))
+ return;
+
+ restore_breakpoint_dac(bp);
+ tsk->thread.last_hit_ubp = NULL;
+}
+
+static void ptrace_deliver_signal(int regnum)
+{
+ siginfo_t sig_info;
+
+ sig_info.si_signo = SIGTRAP;
+ sig_info.si_errno = TRAP_HWBKPT;
+
+ switch(regnum) {
+ /* DAC1 */
+ case 0:
+ /* si_code values are as seen in handle_debug() function */
+ sig_info.si_code = 5;
+ sig_info.si_addr = (void __user *)mfspr(SPRN_DAC1);
+ break;
+ /* DAC2 */
+ case 1:
+ sig_info.si_code = 6;
+ sig_info.si_addr = (void __user *)mfspr(SPRN_DAC2);
+ break;
+ }
+ force_sig_info(SIGTRAP, &sig_info, current);
+}
+
+void __kprobes hw_breakpoint_handler(struct pt_regs *regs,
+ unsigned long debug_status)
+{
+ int i, stepped = 0;
+ struct perf_event *bp = NULL;
+ struct arch_hw_breakpoint *bp_info;
+ unsigned int instr = 0;
+ unsigned long dbcr0;
+
+ /*
+ * Disable breakpoints during exception handling. Disable both MSR_DE
+ * and DBCR0_IDM to prevent pending exceptions.
+ */
+ mtmsr(mfmsr() & ~MSR_DE);
+ mtspr(SPRN_DBCR0, mfspr(SPRN_DBCR0) & ~DBCR0_IDM);
+ dbcr0 = mfspr(SPRN_DBCR0);
+
+ /* Handle all the breakpoints that were triggered */
+ for (i = 0; i < HBP_NUM; ++i) {
+ if ((debug_status & ((DBSR_DAC1R | DBSR_DAC1W) >> i)) == 0)
+ continue;
+ /* Clear the debug status register by writing onto it */
+ mtspr(SPRN_DBSR, (DBSR_DAC1R | DBSR_DAC1W) >> i);
+ /* Clear DBSR for DAC2 if operating in 'range' mode */
+ if (mfspr(SPRN_DBCR2) & DBCR2_DAC12M)
+ mtspr(SPRN_DBSR, (DBSR_DAC1R | DBSR_DAC1W) >> (i + 1));
+
+ /*
+ * The counter may be concurrently released but that can only
+ * occur from a call_rcu() path. We can then safely fetch
+ * the breakpoint, use its callback, touch its counter
+ * while we are in an rcu_read_lock() path.
+ */
+ rcu_read_lock();
+ bp = __get_cpu_var(bp_per_reg[i]);
+ /*
+ * bp can be NULL due to lazy debug register switching
+ * or due to concurrent perf counter removing.
+ */
+ if (!bp)
+ goto out;
+ }
+ bp_info = counter_arch_bp(bp);
+
+ /*
+ * Return early after invoking user-callback function without restoring
+ * breakpoints if it originated from ptrace which always operates in
+ * one-shot mode.
+ */
+ if (bp->overflow_handler == ptrace_triggered) {
+ perf_bp_event(bp, regs);
+ ptrace_deliver_signal(i);
+ goto out;
+ }
+
+ /* Do not emulate user-mode instructions, instead, single-step them */
+ if (user_mode(regs)) {
+ bp->ctx->task->thread.last_hit_ubp = bp;
+ /*
+ * Clear the breakpoint register and single-step the
+ * causative instruction
+ */
+ dbcr0 &= ~((DBCR0_DAC1W | DBCR0_DAC1R) >> i);
+ /*
+ * Block-step and single-stepping (IC) is not supported
+ * simultaneously for now
+ */
+ dbcr0 &= ~DBCR0_BT;
+ mtspr(SPRN_DBCR0, dbcr0 | DBCR0_IC);
+ mtmsr(mfmsr() | MSR_DE);
+ goto out;
+ }
+ /*
+ * Attempt to emulate the causative instruction. If successful, then
+ * invoke the perf-callback and restore the breakpoint.
+ */
+ if (!__get_user_inatomic(instr, (unsigned int *) regs->nip))
+ stepped = emulate_step(regs, instr);
+ /*
+ * emulate_step() could not execute it. We've failed in reliably
+ * handling the hw-breakpoint. Unregister it and throw a warning
+ * message to let the user know about it.
+ */
+ if (!stepped) {
+ WARN(1, "Unable to handle hardware breakpoint. Breakpoint at "
+ "0x%lx will be disabled.", bp_info->address);
+ perf_event_disable(bp);
+ goto out;
+ }
+ perf_bp_event(bp, regs);
+ restore_breakpoint_dac(bp);
+ mtmsr(mfmsr() | MSR_DE);
+out:
+ rcu_read_unlock();
+}
+
+/*
+ * Handle single-step exceptions following a DAC hit
+ */
+int __kprobes single_step_dac_instruction(struct pt_regs *regs)
+{
+ struct arch_hw_breakpoint *bp_info;
+ struct perf_event *bp = NULL;
+
+ /* Disable single-stepping */
+ mtspr(SPRN_DBCR0, mfspr(SPRN_DBCR0) & ~DBCR0_IC);
+ mtmsr(mfmsr() & ~MSR_DE);
+
+ bp = current->thread.last_hit_ubp;
+ /*
+ * Check if we are single-stepping as a result of a
+ * previous HW Breakpoint exception
+ */
+ if (!bp)
+ return NOTIFY_DONE;
+ bp_info = counter_arch_bp(bp);
+ /*
+ * We shall invoke the user-defined callback function in the single
+ * stepping handler to confirm to 'trigger-after-execute' semantics
+ */
+ perf_bp_event(bp, regs);
+ restore_breakpoint_dac(bp);
+ mtmsr(mfmsr() | MSR_DE);
+
+ return NOTIFY_STOP;
+}
+
+/*
+ * Handle debug exception notifications.
+ */
+int __kprobes hw_breakpoint_exceptions_notify(
+ struct notifier_block *unused, unsigned long val, void *data)
+{
+ int ret = NOTIFY_DONE;
+
+ if (val == DIE_SSTEP)
+ ret = single_step_dac_instruction(data);
+ return ret;
+}
+
+void hw_breakpoint_pmu_read(struct perf_event *bp)
+{
+ /* TODO */
+}
Index: linux-2.6.bookE/arch/powerpc/kernel/traps.c
===================================================================
--- linux-2.6.bookE.orig/arch/powerpc/kernel/traps.c
+++ linux-2.6.bookE/arch/powerpc/kernel/traps.c
@@ -57,6 +57,9 @@
#ifdef CONFIG_FSL_BOOKE
#include <asm/dbell.h>
#endif
+#ifdef CONFIG_BOOKE
+#include <asm/hw_breakpoint_booke.h>
+#endif
#if defined(CONFIG_DEBUGGER) || defined(CONFIG_KEXEC)
int (*__debugger)(struct pt_regs *regs) __read_mostly;
@@ -1193,7 +1196,11 @@ void __kprobes DebugException(struct pt_
_exception(SIGTRAP, regs, TRAP_TRACE, regs->nip);
} else
- handle_debug(regs, debug_status);
+#ifdef CONFIG_HAVE_HW_BREAKPOINT
+ hw_breakpoint_handler(regs, debug_status);
+ return;
+#endif /* CONFIG_HAVE_HW_BREAKPOINT */
+ handle_debug(regs, debug_status);
}
#endif /* CONFIG_PPC_ADV_DEBUG_REGS */
Index: linux-2.6.bookE/arch/powerpc/Kconfig
===================================================================
--- linux-2.6.bookE.orig/arch/powerpc/Kconfig
+++ linux-2.6.bookE/arch/powerpc/Kconfig
@@ -141,7 +141,7 @@ config PPC
select GENERIC_ATOMIC64 if PPC32
select HAVE_PERF_EVENTS
select HAVE_REGS_AND_STACK_ACCESS_API
- select HAVE_HW_BREAKPOINT if PERF_EVENTS && PPC_BOOK3S_64
+ select HAVE_HW_BREAKPOINT if (PERF_EVENTS && (PPC_BOOK3S_64 || BOOKE))
config EARLY_PRINTK
bool
Index: linux-2.6.bookE/arch/powerpc/kernel/Makefile
===================================================================
--- linux-2.6.bookE.orig/arch/powerpc/kernel/Makefile
+++ linux-2.6.bookE/arch/powerpc/kernel/Makefile
@@ -34,7 +34,11 @@ obj-y += vdso32/
obj-$(CONFIG_PPC64) += setup_64.o sys_ppc32.o \
signal_64.o ptrace32.o \
paca.o nvram_64.o firmware.o
+ifeq ($(CONFIG_BOOKE),y)
+obj-$(CONFIG_HAVE_HW_BREAKPOINT) += hw_breakpoint_booke.o
+else
obj-$(CONFIG_HAVE_HW_BREAKPOINT) += hw_breakpoint.o
+endif
obj-$(CONFIG_PPC_BOOK3S_64) += cpu_setup_ppc970.o cpu_setup_pa6t.o
obj64-$(CONFIG_RELOCATABLE) += reloc_64.o
obj-$(CONFIG_PPC_BOOK3E_64) += exceptions-64e.o
Index: linux-2.6.bookE/arch/powerpc/kernel/ptrace.c
===================================================================
--- linux-2.6.bookE.orig/arch/powerpc/kernel/ptrace.c
+++ linux-2.6.bookE/arch/powerpc/kernel/ptrace.c
@@ -964,6 +964,56 @@ int ptrace_set_debugreg(struct task_stru
/* Move contents to the DABR register */
task->thread.dabr = data;
#else /* CONFIG_PPC_ADV_DEBUG_REGS */
+#ifdef CONFIG_HAVE_HW_BREAKPOINT
+ /*
+ * For compatibility with existing ptrace design which uses only one
+ * breakpoint slot, we will use only one DAC register.
+ */
+ bp = thread->ptrace_bps[0];
+ if (!data) {
+ if (bp) {
+ unregister_hw_breakpoint(bp);
+ thread->ptrace_bps[0] = NULL;
+ thread->dac1 = 0;
+ }
+ return 0;
+ }
+ if (bp) {
+ attr = bp->attr;
+ attr.bp_addr = data & ~HW_BREAKPOINT_ALIGN;
+ /*
+ * Check for write and read flags and set DBCR0
+ * accordingly
+ */
+ dbcr_dac(task) &= ~(DBCR_DAC1R|DBCR_DAC1W);
+ if (data & 0x1UL)
+ attr.bp_type |= HW_BREAKPOINT_R;
+ if (data & 0x2UL)
+ attr.bp_type |= HW_BREAKPOINT_R;
+ ret = modify_user_hw_breakpoint(bp, &attr);
+ if (ret)
+ return ret;
+ thread->ptrace_bps[0] = bp;
+ thread->dac1 = data;
+ return 0;
+ }
+
+ /* Create a new breakpoint request if one doesn't exist already */
+ hw_breakpoint_init(&attr);
+ attr.bp_addr = data & ~HW_BREAKPOINT_ALIGN;
+ if (data & 0x1UL)
+ attr.bp_type |= HW_BREAKPOINT_R;
+ if (data & 0x2UL)
+ attr.bp_type |= HW_BREAKPOINT_R;
+ thread->ptrace_bps[0] = bp = register_user_hw_breakpoint(&attr,
+ ptrace_triggered, task);
+ if (IS_ERR(bp)) {
+ thread->ptrace_bps[0] = NULL;
+ return PTR_ERR(bp);
+ }
+ thread->dac1 = data;
+
+#else /* CONFIG_HAVE_HW_BREAKPOINT */
/* As described above, it was assumed 3 bits were passed with the data
* address, but we will assume only the mode bits will be passed
* as to not cause alignment restrictions for DAC-based processors.
@@ -999,6 +1049,7 @@ int ptrace_set_debugreg(struct task_stru
if (data & 0x2UL)
dbcr_dac(task) |= DBCR_DAC1W;
task->thread.regs->msr |= MSR_DE;
+#endif /* CONFIG_HAVE_HW_BREAKPOINT */
#endif /* CONFIG_PPC_ADV_DEBUG_REGS */
return 0;
}
Index: linux-2.6.bookE/arch/powerpc/include/asm/cputable.h
===================================================================
--- linux-2.6.bookE.orig/arch/powerpc/include/asm/cputable.h
+++ linux-2.6.bookE/arch/powerpc/include/asm/cputable.h
@@ -517,7 +517,11 @@ static inline int cpu_has_feature(unsign
}
#ifdef CONFIG_HAVE_HW_BREAKPOINT
+#ifdef CONFIG_BOOKE
+#define HBP_NUM 2
+#else
#define HBP_NUM 1
+#endif /* CONFIG_BOOKE */
#endif /* CONFIG_HAVE_HW_BREAKPOINT */
#endif /* !__ASSEMBLY__ */
Index: linux-2.6.bookE/include/linux/perf_event.h
===================================================================
--- linux-2.6.bookE.orig/include/linux/perf_event.h
+++ linux-2.6.bookE/include/linux/perf_event.h
@@ -470,7 +470,11 @@ struct perf_guest_info_callbacks {
};
#ifdef CONFIG_HAVE_HW_BREAKPOINT
+#ifdef CONFIG_BOOKE
+#include <asm/hw_breakpoint_booke.h>
+#else
#include <asm/hw_breakpoint.h>
+#endif /* CONFIG_BOOKE */
#endif
#include <linux/list.h>
Index: linux-2.6.bookE/arch/powerpc/kernel/process.c
===================================================================
--- linux-2.6.bookE.orig/arch/powerpc/kernel/process.c
+++ linux-2.6.bookE/arch/powerpc/kernel/process.c
@@ -329,6 +329,7 @@ static void prime_debug_regs(struct thre
mtspr(SPRN_IAC3, thread->iac3);
mtspr(SPRN_IAC4, thread->iac4);
#endif
+#ifndef CONFIG_HAVE_HW_BREAKPOINT
mtspr(SPRN_DAC1, thread->dac1);
mtspr(SPRN_DAC2, thread->dac2);
#if CONFIG_PPC_ADV_DEBUG_DVCS > 0
@@ -340,7 +341,9 @@ static void prime_debug_regs(struct thre
#ifdef CONFIG_BOOKE
mtspr(SPRN_DBCR2, thread->dbcr2);
#endif
+#endif /* CONFIG_HAVE_HW_BREAKPOINT */
}
+
/*
* Unless neither the old or new thread are making use of the
* debug registers, set the debug registers from the values
Index: linux-2.6.bookE/kernel/trace/trace_ksym.c
===================================================================
--- linux-2.6.bookE.orig/kernel/trace/trace_ksym.c
+++ linux-2.6.bookE/kernel/trace/trace_ksym.c
@@ -30,7 +30,11 @@
#include "trace.h"
#include <linux/hw_breakpoint.h>
+#ifdef CONFIG_BOOKE
+#include <asm/hw_breakpoint_booke.h>
+#else /* CONFIG_BOOKE */
#include <asm/hw_breakpoint.h>
+#endif /* CONFIG_BOOKE */
#include <asm/atomic.h>
^ permalink raw reply
* Re: kernel init exception
From: Segher Boessenkool @ 2010-06-29 16:51 UTC (permalink / raw)
To: wilbur.chan; +Cc: linuxppc-dev
In-Reply-To: <AANLkTimV1AFEUrRf-2iEizXH4HQFMrrAumsRVDKxNfAv@mail.gmail.com>
> why there generated a signal 4 in init process?
That's SIGILL; sounds like you compiled init with the wrong (sub-)arch
or cpu flags.
Segher
^ permalink raw reply
* [RFC Patch 0/1] hw-breakpoint interfaces for BookE - ver II
From: K.Prasad @ 2010-06-29 16:51 UTC (permalink / raw)
To: linuxppc-dev
Hi All,
Please find a new version of the patch that implements generic
hw-breakpoint interfaces for PowerPC BookIII E.
While there are several improvements over the previous version in terms
of code placement, support for ptrace and fixes for incorrect issues, the
patch remains compile-tested (only)(against 44x/iss476-smp_defconfig config)
and is yet to be tested on hardware (for functionality).
Changelog Version II
(Version I:linuxppc-dev message-id: 20100427164029.GA8303@in.ibm.com)
-------------------------------------------------------------------------
- ptrace requests (through PTRACE_SET_DEBUGREG and PTRACE_GET_DEBUGREG) are
now supported.
- Changes in original arch/powerpc/kernel/hw_breakpoint.c have been percolated
down to hw_breakpoint_booke.c (such as introduction of thread_change_pc(),
arch_unregister_hw_breakpoint() and changes to hw_breakpoint_handler())
along with some code re-arrangement (for brevity/clarity).
The usage of CONFIG (in this patch) option doesn't largely represent a
form that it would turn into after enabling the use of DVCs, DACs by non-ptrace
breakpoint requests. They should turn correct as versions of this patch progress.
Kindly let me know your comments.
Thanks,
K.Prasad
^ permalink raw reply
* [PATCH] arch/powerpc/lib/copy_32.S: Use alternate memcpy for MPC512x and MPC52xx
From: Steve Deiters @ 2010-06-29 16:04 UTC (permalink / raw)
To: linuxppc-dev
These processors will corrupt data if accessing the local bus with
unaligned
addresses. This version fixes the typical case of copying from Flash on
the
local bus by keeping the source address always aligned.
Signed-off-by: Steve Deiters <SteveDeiters@basler.com>
---
arch/powerpc/lib/copy_32.S | 56
++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 56 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/lib/copy_32.S b/arch/powerpc/lib/copy_32.S
index 74a7f41..42e7df5 100644
--- a/arch/powerpc/lib/copy_32.S
+++ b/arch/powerpc/lib/copy_32.S
@@ -226,6 +226,60 @@ _GLOBAL(memmove)
bgt backwards_memcpy
/* fall through */
=20
+#if defined(CONFIG_PPC_MPC512x) || defined(CONFIG_PPC_MPC52xx)
+
+/*
+ * Alternate memcpy for MPC512x and MPC52xx to guarantee source
+ * address is always aligned to prevent corruption issues when
+ * copying unaligned from the local bus. This only fixes the usage
+ * when copying from the local bus (e.g. Flash) and will not fix
+ * issues copying to the local bus
+ */
+_GLOBAL(memcpy)
+ srwi. r7,r5,3
+ addi r6,r3,-4
+ addi r4,r4,-4
+ beq 2f /* if less than 8 bytes to do */
+ andi. r0,r4,3 /* get src word aligned */
+ mtctr r7
+ bne 5f
+1: lwz r7,4(r4)
+ lwzu r8,8(r4)
+ stw r7,4(r6)
+ stwu r8,8(r6)
+ bdnz 1b
+ andi. r5,r5,7
+2: cmplwi 0,r5,4
+ blt 3f
+ andi. r0,r4,3
+ bne 3f
+ lwzu r0,4(r4)
+ addi r5,r5,-4
+ stwu r0,4(r6)
+3: cmpwi 0,r5,0
+ beqlr
+ mtctr r5
+ addi r4,r4,3
+ addi r6,r6,3
+4: lbzu r0,1(r4)
+ stbu r0,1(r6)
+ bdnz 4b
+ blr
+5: subfic r0,r0,4
+ mtctr r0
+6: lbz r7,4(r4)
+ addi r4,r4,1
+ stb r7,4(r6)
+ addi r6,r6,1
+ bdnz 6b
+ subf r5,r0,r5
+ rlwinm. r7,r5,32-3,3,31
+ beq 2b
+ mtctr r7
+ b 1b
+
+#else
+
_GLOBAL(memcpy)
srwi. r7,r5,3
addi r6,r3,-4
@@ -267,6 +321,8 @@ _GLOBAL(memcpy)
mtctr r7
b 1b
=20
+#endif
+
_GLOBAL(backwards_memcpy)
rlwinm. r7,r5,32-3,3,31 /* r0 =3D r5 >> 3 */
add r6,r3,r5
--=20
1.5.4.3
^ permalink raw reply related
* RE: Using devices trees on X86
From: Stephen Neuendorffer @ 2010-06-29 15:56 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Michal Simek, microblaze-uclinux, devicetree-discuss,
Paul Mackerras, sparclinux, linuxppc-dev, David Miller
In-Reply-To: <20100629123843.5f94d477.sfr@canb.auug.org.au>
> -----Original Message-----
> From: Stephen Rothwell [mailto:sfr@canb.auug.org.au]
> Sent: Monday, June 28, 2010 7:39 PM
> To: Stephen Neuendorffer
> Cc: grant.likely@secretlab.ca; devicetree-discuss@lists.ozlabs.org;
David Miller;
> sparclinux@vger.kernel.org; Michal Simek;
microblaze-uclinux@itee.uq.edu.au; Benjamin Herrenschmidt;
> Paul Mackerras; linuxppc-dev@lists.ozlabs.org
> Subject: Re: Using devices trees on X86
> =
> Hi Stephen,
> =
> On Mon, 28 Jun 2010 10:57:33 -0700 Stephen Neuendorffer
<stephen.neuendorffer@xilinx.com> wrote:
> >
> > 2) config OF is currently implemented in the architecture code.
This
> > should be non-architecture dependent and selected by the arches that
> > need it.
> >
> > Comments greatly appreciated, in particular if you have
> > likely-to-be-easy-to-get-accepted suggestions for 3), or feel like
> > carefully solving 2) in
> > a way which doesn't bork the existing of-based arches.
> =
> See the following patch set. Parts 1, 2 and 3 could be applied to the
> respective architecture trees as well as Grant's tree to aleviate some
> conflict problems. Part 5 could wait until a later time if necessary.
> However, this is relatively trivial, so we could just collect ACKs and
> put it all in Grant's tree and live with any minor pain.
> =
> Having OF in more than one Kconfig file should not cause any problems
as
> long as they are all the same.
Ah, well, that simplifies things.. :) Thanks!
Steve
This email and any attachments are intended for the sole use of the named r=
ecipient(s) and contain(s) confidential information that may be proprietary=
, privileged or copyrighted under applicable law. If you are not the intend=
ed recipient, do not read, copy, or forward this email message or any attac=
hments. Delete this email message and any attachments immediately.
^ permalink raw reply
* kernel init exception
From: wilbur.chan @ 2010-06-29 15:21 UTC (permalink / raw)
To: linuxppc-dev
We are porting linux 2.6.21.7 to a powerpc e500mc board , p4080.
But something is wrong when loading init file:
log:
free init memory...
init has generated signal 4 but has no handler for it
I found it print in _exception --->
if (is_init(current)) {
if (handler == SIG_DFL) {
printk(KERN_CRIT "init has generated signal %d "
"but has no handler for it\n", signr);
do_exit(signr);
}
}
why there generated a signal 4 in init process?
Thanks
^ permalink raw reply
* ftp login problem using wu-ftpd
From: Stevan Ignjatovic @ 2010-06-29 14:16 UTC (permalink / raw)
To: linuxppc-dev
Hi all,
I ported Linux-2.6.30-rc8 on my custom mpc885 board. The filesystem I am
using is jffs2 which I created from
eldk-4.2/ppc_8xx/images/ramdisk_image.gz. Linux boots fine and I can
telnet to the board but I cannot ftp:
# ftp 10.8.1.5
Connected to 10.8.1.5.
220 10.8.1.5 FTP server (Version wu-2.6.2(1) Wed Apr 2 09:10:49 MEST
2008) ready.
530 Please login with USER and PASS.
530 Please login with USER and PASS.
KERBEROS_V4 rejected as an authentication type
Name (10.8.1.5:root): root
Here ftp connection hangs. Do I have to create another user (beside
root) in order to make ftp connection? Earlier, when I was using 2.4
linux I didn't have problems with ftp connection as root.
/etc/ftpaccess:
class all real,guest,anonymous *
email root@localhost
loginfails 5
readme README* login
readme README* cwd=*
message /welcome.msg login
message .message cwd=*
compress yes all
tar yes all
chmod no guest,anonymous
delete no guest,anonymous
overwrite no guest,anonymous
rename no guest,anonymous
log transfers anonymous,real inbound,outbound
shutdown /etc/shutmsg
passwd-check rfc822 warn
/etc/xinetd.d/wu-ftpd:
# default: on
# description: The wu-ftpd FTP server serves FTP connections. It uses \
# normal, unencrypted usernames and passwords for authentication.
service ftp
{
socket_type = stream
wait = no
user = root
server = /usr/sbin/in.ftpd
server_args = -l -a
log_on_success += DURATION USERID
log_on_failure += USERID
nice = 10
disable = no
}
/etc/pam.d/ftp:
#%PAM-1.0
auth include system-auth
auth required /lib/security/pam_listfile.so item=user sense=deny
file=/etc/ftpusers onerr=succeed
auth required /lib/security/pam_shells.so
account include system-auth
session include system-auth
Thanks in advance.
^ permalink raw reply
* Re: [PATCH] sched: fix spelling of sibling
From: David Howells @ 2010-06-29 14:14 UTC (permalink / raw)
To: Michael Neuling; +Cc: Peter Zijlstra, Ingo Molnar, linux-kernel, linuxppc-dev
In-Reply-To: <15249.1277776921@neuling.org>
Michael Neuling <mikey@neuling.org> wrote:
> No logic changes, only spelling.
>
> Signed-off-by: Michael Neuling <mikey@neuling.org>
Acked-by: David Howells <dhowells@redhat.com>
^ permalink raw reply
* Re: [PATCH] KVM: PPC: Add generic hpte management functions
From: Avi Kivity @ 2010-06-29 13:13 UTC (permalink / raw)
To: Alexander Graf; +Cc: linuxppc-dev, KVM list, kvm-ppc
In-Reply-To: <4C29EFCC.3030303@suse.de>
On 06/29/2010 04:06 PM, Alexander Graf wrote:
>
> Are we looking at the same link? Looks good to me there.
>
>
We're probably looking at the same link but looking at different
things. I'm whining about
static u64 f() {
...
}
as opposed to the more sober
static u64 f()
{
...
}
for f in [kvmppc_mmu_hash_pte, kvmppc_mmu_hash_vpte,
kvmppc_mmu_hash_vpte_long].
--
error compiling committee.c: too many arguments to function
^ permalink raw reply
* Re: [PATCH] KVM: PPC: Add generic hpte management functions
From: Alexander Graf @ 2010-06-29 13:06 UTC (permalink / raw)
To: Avi Kivity; +Cc: linuxppc-dev, KVM list, kvm-ppc
In-Reply-To: <4C29EF8A.4070508@redhat.com>
Avi Kivity wrote:
> On 06/29/2010 03:56 PM, Alexander Graf wrote:
>> Avi Kivity wrote:
>>
>>> On 06/28/2010 11:55 AM, Alexander Graf wrote:
>>>
>>>>
>>>>>> +
>>>>>> +static inline u64 kvmppc_mmu_hash_pte(u64 eaddr) {
>>>>>> + return hash_64(eaddr>> PTE_SIZE, HPTEG_HASH_BITS_PTE);
>>>>>> +}
>>>>>> +
>>>>>> +static inline u64 kvmppc_mmu_hash_vpte(u64 vpage) {
>>>>>> + return hash_64(vpage& 0xfffffffffULL, HPTEG_HASH_BITS_VPTE);
>>>>>> +}
>>>>>> +
>>>>>> +static inline u64 kvmppc_mmu_hash_vpte_long(u64 vpage) {
>>>>>> + return hash_64((vpage& 0xffffff000ULL)>> 12,
>>>>>> + HPTEG_HASH_BITS_VPTE_LONG);
>>>>>> +}
>>>>>>
>>>>>>
>>>>>>
>>>>> Still with the wierd coding style?
>>>>>
>>>>>
>>>> Not sure what's going on there. My editor displays it normally. Weird.
>>>>
>>>>
>>> Try hitting 'save'.
>>>
>> hexdump -C on the respective section in the exact patch file I submitted
>> above shows:
>>
>> 00000a80 75 72 6e 20 68 61 73 68 5f 36 34 28 65 61 64 64 |urn
>> hash_64(eadd|
>> 00000a90 72 20 3e 3e 20 50 54 45 5f 53 49 5a 45 2c 20 48 |r>>
>> PTE_SIZE, H|
>>
>>
>> Maybe your mail client breaks it?
>>
>
> The list archives too:
>
> http://www.mail-archive.com/kvm@vger.kernel.org/msg37093.html
>
> Looks like a cache coherency bug. What processor are you using?
Are we looking at the same link? Looks good to me there.
Alex
^ permalink raw reply
* Re: [PATCH] KVM: PPC: Add generic hpte management functions
From: Avi Kivity @ 2010-06-29 13:05 UTC (permalink / raw)
To: Alexander Graf; +Cc: linuxppc-dev, KVM list, kvm-ppc
In-Reply-To: <4C29ED94.6060904@suse.de>
On 06/29/2010 03:56 PM, Alexander Graf wrote:
> Avi Kivity wrote:
>
>> On 06/28/2010 11:55 AM, Alexander Graf wrote:
>>
>>>
>>>>> +
>>>>> +static inline u64 kvmppc_mmu_hash_pte(u64 eaddr) {
>>>>> + return hash_64(eaddr>> PTE_SIZE, HPTEG_HASH_BITS_PTE);
>>>>> +}
>>>>> +
>>>>> +static inline u64 kvmppc_mmu_hash_vpte(u64 vpage) {
>>>>> + return hash_64(vpage& 0xfffffffffULL, HPTEG_HASH_BITS_VPTE);
>>>>> +}
>>>>> +
>>>>> +static inline u64 kvmppc_mmu_hash_vpte_long(u64 vpage) {
>>>>> + return hash_64((vpage& 0xffffff000ULL)>> 12,
>>>>> + HPTEG_HASH_BITS_VPTE_LONG);
>>>>> +}
>>>>>
>>>>>
>>>>>
>>>> Still with the wierd coding style?
>>>>
>>>>
>>> Not sure what's going on there. My editor displays it normally. Weird.
>>>
>>>
>> Try hitting 'save'.
>>
> hexdump -C on the respective section in the exact patch file I submitted
> above shows:
>
> 00000a80 75 72 6e 20 68 61 73 68 5f 36 34 28 65 61 64 64 |urn
> hash_64(eadd|
> 00000a90 72 20 3e 3e 20 50 54 45 5f 53 49 5a 45 2c 20 48 |r>>
> PTE_SIZE, H|
>
>
> Maybe your mail client breaks it?
>
The list archives too:
http://www.mail-archive.com/kvm@vger.kernel.org/msg37093.html
Looks like a cache coherency bug. What processor are you using?
--
error compiling committee.c: too many arguments to function
^ permalink raw reply
* Re: [PATCH] KVM: PPC: Add generic hpte management functions
From: Alexander Graf @ 2010-06-29 12:56 UTC (permalink / raw)
To: Avi Kivity; +Cc: linuxppc-dev, KVM list, kvm-ppc
In-Reply-To: <4C286770.6010204@redhat.com>
Avi Kivity wrote:
> On 06/28/2010 11:55 AM, Alexander Graf wrote:
>>
>>>> +
>>>> +static inline u64 kvmppc_mmu_hash_pte(u64 eaddr) {
>>>> + return hash_64(eaddr>> PTE_SIZE, HPTEG_HASH_BITS_PTE);
>>>> +}
>>>> +
>>>> +static inline u64 kvmppc_mmu_hash_vpte(u64 vpage) {
>>>> + return hash_64(vpage& 0xfffffffffULL, HPTEG_HASH_BITS_VPTE);
>>>> +}
>>>> +
>>>> +static inline u64 kvmppc_mmu_hash_vpte_long(u64 vpage) {
>>>> + return hash_64((vpage& 0xffffff000ULL)>> 12,
>>>> + HPTEG_HASH_BITS_VPTE_LONG);
>>>> +}
>>>>
>>>>
>>> Still with the wierd coding style?
>>>
>> Not sure what's going on there. My editor displays it normally. Weird.
>>
>
> Try hitting 'save'.
hexdump -C on the respective section in the exact patch file I submitted
above shows:
00000a80 75 72 6e 20 68 61 73 68 5f 36 34 28 65 61 64 64 |urn
hash_64(eadd|
00000a90 72 20 3e 3e 20 50 54 45 5f 53 49 5a 45 2c 20 48 |r >>
PTE_SIZE, H|
Maybe your mail client breaks it?
Alex
^ permalink raw reply
* Re: [PATCH]460EX on-chip SATA driver<kernel 2.6.33><resubmission>
From: Anton Vorontsov @ 2010-06-29 12:44 UTC (permalink / raw)
To: Marek Vasut
Cc: linuxppc-dev, Rupjyoti Sarmah, linux-kernel, linux-ide, sr,
jgarzik
In-Reply-To: <201006290333.50673.marek.vasut@gmail.com>
On Tue, Jun 29, 2010 at 03:33:50AM +0200, Marek Vasut wrote:
> Dne Pá 4. června 2010 14:26:17 Rupjyoti Sarmah napsal(a):
> > This patch enables the on-chip DWC SATA controller of the AppliedMicro
> > processor 460EX.
> >
> > Signed-off-by: Rupjyoti Sarmah <rsarmah@appliedmicro.com>
> > Signed-off-by: Mark Miesfeld <mmiesfeld@appliedmicro.com>
> > Signed-off-by: Prodyut Hazarika <phazarika@appliedmicro.com>
> >
>
> --SNIP--
>
> > + dev_err(ap->dev, "%s: Command not pending cmd_issued=%d "
> > + "(tag=%d) DMA NOT started\n", __func__,
> > + hsdevp->cmd_issued[tag], tag);
>
> Just a nitpick, but don't break strings if possible.
Note that in this particular case breaking strings was OK, and
was actually done in a clever manner.
That is, I doubt that anyone grep for error messages with
regexps, so grep "Command not pending" or grep "DMA NOT started"
would work.
This makes the code more readable (literally, because you don't
have to scroll to see dev_err's arguments) without sacrificing
grep'ability.
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
^ permalink raw reply
* RE: [PATCH]460EX on-chip SATA driver<kernel 2.6.33><resubmission>
From: Rupjyoti Sarmah @ 2010-06-29 12:20 UTC (permalink / raw)
To: Marek Vasut, Rupjyoti Sarmah
Cc: linux-ide, sr, jgarzik, linux-kernel, linuxppc-dev
In-Reply-To: <201006290333.50673.marek.vasut@gmail.com>
Hi,
Thanks for your feedback. I submitted an updated version of this patch
later.
I tried to limit the lines within 80 characters.
Regards,
Rup
-----Original Message-----
From: Marek Vasut [mailto:marek.vasut@gmail.com]
Sent: Tuesday, June 29, 2010 7:04 AM
To: Rupjyoti Sarmah
Cc: linux-ide@vger.kernel.org; linux-kernel@vger.kernel.org;
jgarzik@pobox.com; sr@denx.de; linuxppc-dev@ozlabs.org
Subject: Re: [PATCH]460EX on-chip SATA driver<kernel 2.6.33><resubmission>
Dne P=C3=A1 4. =C4=8Dervna 2010 14:26:17 Rupjyoti Sarmah napsal(a):
> This patch enables the on-chip DWC SATA controller of the AppliedMicro
> processor 460EX.
>
> Signed-off-by: Rupjyoti Sarmah <rsarmah@appliedmicro.com>
> Signed-off-by: Mark Miesfeld <mmiesfeld@appliedmicro.com>
> Signed-off-by: Prodyut Hazarika <phazarika@appliedmicro.com>
>
--SNIP--
> + dev_err(ap->dev, "%s: Command not pending cmd_issued=3D%d "
> + "(tag=3D%d) DMA NOT started\n", __func__,
> + hsdevp->cmd_issued[tag], tag);
Just a nitpick, but don't break strings if possible.
^ permalink raw reply
* Re: [PATCH 01/26] KVM: PPC: Introduce shared page
From: Avi Kivity @ 2010-06-29 10:55 UTC (permalink / raw)
To: Alexander Graf; +Cc: linuxppc-dev, KVM list, kvm-ppc
In-Reply-To: <4C29C2E1.4000706@suse.de>
On 06/29/2010 12:54 PM, Alexander Graf wrote:
>
>> Code repeats 3x. Share please.
>>
> Looking at this again, I could combine the 3 lines of init code into 3
> lines of code that do a generic function call and then error checking.
> And I could convert the one free_page line with one function call that
> would free the page. Is there a real gain behind this?
>
>
Looks marginal, yes. It will help if initialization is expanded later,
but currently it doesn't help much.
--
error compiling committee.c: too many arguments to function
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox