* Re: [PATCH 0/5] make *_gate_vma accept mm_struct instead of task_struct
From: H. Peter Anvin @ 2011-03-10 17:15 UTC (permalink / raw)
To: Stephen Wilson, Andi Kleen
Cc: linux-s390, Paul Mundt, linux-sh, x86, Heiko Carstens,
linux-kernel, linux-mm, Ingo Molnar, Paul Mackerras,
Alexander Viro, Martin Schwidefsky, linux390, Thomas Gleixner,
Michel Lespinasse, linuxppc-dev, Andrew Morton
In-Reply-To: <20110310164022.GA6242@fibrous.localdomain>
[-- Attachment #1: Type: text/plain, Size: 2062 bytes --]
TIF_IA32 is set during the execution of a 32-bit system call - so touched on each compat system call. Is this the actual flag you want? A 32-bit address space flag is different from TIF_IA32.
--
Sent from my mobile phone. Please pardon any lack of formatting.
Stephen Wilson <wilsons@start.ca> wrote:
On Thu, Mar 10, 2011 at 08:00:32AM -0800, Andi Kleen wrote: > On Tue, Mar 08, 2011 at 07:31:56PM -0500, Stephen Wilson wrote: > > > > Morally, the question of whether an address lies in a gate vma should be asked > > with respect to an mm, not a particular task. > > > > Practically, dropping the dependency on task_struct will help make current and > > future operations on mm's more flexible and convenient. In particular, it > > allows some code paths to avoid the need to hold task_lock. > > > > The only architecture this change impacts in any significant way is x86_64. > > The principle change on that architecture is to mirror TIF_IA32 via > > a new flag in mm_context_t. > > The problem is -- you're adding a likely cache miss on mm_struct for > every 32bit compat syscall now, even if they don't need mm_struct > currently (and a lot of them do not) Unless there's a very good > justification to make up for this performance issue elsewhere > (including numbers) this seems like !
a bad
idea. I do not think this will result in cache misses on the scale you suggest. I am simply mirroring the *state* of the TIF_IA32 flag in mm_struct, not testing/accessing it in the same way. The only place where this flag is accessed (outside the exec() syscall path) is in x86/mm/init_64.c, get_gate_vma(), which in turn is needed by a few, relatively heavy weight, page locking/pinning routines on the mm side (get_user_pages, for example). Patches 3 and 4 in the series show the extent of the change. Or am I missing something? > > /proc/pid/mem. I will be posting the second series to lkml shortly. These > > Making every syscall slower for /proc/pid/mem doesn't seem like a good > tradeoff to me. Please solve this in some other way. > > -Andi -- steve
[-- Attachment #2: Type: text/html, Size: 2484 bytes --]
^ permalink raw reply
* Re: fsl_udc_core not initializing properly?
From: Matthew L. Creech @ 2011-03-10 18:46 UTC (permalink / raw)
To: Anatolij Gustschin; +Cc: linuxppc-dev
In-Reply-To: <AANLkTikvPOak6mamoeBrDBS5j_M3KuPmQi6DR5Ng6vki@mail.gmail.com>
On Sat, Feb 19, 2011 at 1:01 PM, Matthew L. Creech <mlcreech@gmail.com> wro=
te:
>
> Yes, it's there. =A0Here's the DTS entry in case anything else sticks out=
:
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0usb@23000 {
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0compatible =3D "fsl-usb2-d=
r";
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0reg =3D <0x23000 0x1000>;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0#address-cells =3D <1>;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0#size-cells =3D <0>;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0interrupt-parent =3D <&ipi=
c>;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0interrupts =3D <38 0x8>;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0phy_type =3D "utmi_wide";
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0dr_mode =3D "peripheral";
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0sleep =3D <&pmc 0x00300000=
>;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0};
>
Hi Anatolij,
I tracked the problem down to a change made in September, which
happens to be yours:
http://git.kernel.org/?p=3Dlinux/kernel/git/torvalds/linux-2.6.git;a=3Dcomm=
itdiff;h=3D126512e3f274802ca65ebeca8660237f0361ad48
When I roll this back, everything works fine again.
First of all, I noticed that fsl-mph-dr-of.c isn't even compiling for
me (even though I have the option enabled in my .config), because it's
been placed in "usb/host/", and I'm only using device/gadget-mode USB.
I edited the top-level Makefile to just force it into "usb/host/", and
that makes sure that your driver gets built (and it's probed just fine
at runtime). But that still didn't solve the problem - as before,
fsl_udc_probe() is never being called.
Did you test this change in device mode? I'm wondering if there's
something different about my configuration that prevents it from
working. My config is uploaded here if it helps:
http://mcreech.com/work/linux.config
Thanks!
--=20
Matthew L. Creech
^ permalink raw reply
* Re: [PATCH v4 2/2] powerpc: make MPIC honor the "pic-no-reset" device tree property
From: Benjamin Herrenschmidt @ 2011-03-10 22:11 UTC (permalink / raw)
To: Meador Inge; +Cc: Hollis Blanchard, devicetree-discuss, linuxppc-dev
In-Reply-To: <4D790901.9000701@mentor.com>
On Thu, 2011-03-10 at 11:23 -0600, Meador Inge wrote:
> I agree. I shouldn't have cached that. We should probably introduce a
> helper function to get the cpuid, though. The:
>
> unsigned int cpu = 0;
>
> if (mpic->flags & MPIC_PRIMARY)
> cpu = hard_smp_processor_id();
>
> code is scattered in three places: '_mpic_cpu_write', '_mpic_cpu_read',
> and 'mpic_init'.
Right, but that code must act on the current CPU, not a cached per-MPIC
variant. Doing a helper to factor the above 2 lines is fine if you wish
to do so but then make it a separate patch.
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH v4 2/2] powerpc: make MPIC honor the "pic-no-reset" device tree property
From: Benjamin Herrenschmidt @ 2011-03-10 22:13 UTC (permalink / raw)
To: Meador Inge; +Cc: Hollis Blanchard, devicetree-discuss, linuxppc-dev
In-Reply-To: <4D790901.9000701@mentor.com>
On Thu, 2011-03-10 at 11:23 -0600, Meador Inge wrote:
> AFAIK, we can't rely on 'set_affinity' always being called. I don't
> think it is called at all when !defined(CONFIG_SMP) and if it was,
> then that would be an error:
>
> /* include/linux/irq.h */
>
> #else /* CONFIG_SMP */
>
> static inline int irq_set_affinity(unsigned int irq,
> const struct cpumask *m)
> {
> return -EINVAL;
> }
You are right. We do need to set a sane default then.
> > partially initialized in set_type, I'd say just modify set_type to
> > initialize the source as well, and problem solved, no ?
>
> The priority has to be initialized as well. They could both be done
> in
> 'mpic_set_irq_type', but that seems like a weird place since it has
> nothing to do with actually setting the type.
>
> Since we already have 'mpic_irq_set_priority' and 'mpic_set_vector',
> perhaps a better option is to add 'mpic_set_destination' and put the
> following in 'mpic_host_map' (using the cpuid helper function
> suggested
> above):
>
> /* Lazy source init when MPIC_NO_RESET */
> if (!mpic_is_ipi(mpic, hw) && (mpic->flags & MPIC_NO_RESET)) {
> mpic_set_vector(virq, hw);
> mpic_set_destination(virq, mpic_cpuid(mpic));
> mpic_irq_set_priority(virq, 8);
> }
>
> It is more overhead, but it reads well. Thoughts?
No objection.
Cheers,
Ben.
^ permalink raw reply
* RE: [PATCH] driver/FSL SATA: Update RX_WATER_MARK for TRANSCFG
From: Kushwaha Prabhakar-B32579 @ 2011-03-11 3:12 UTC (permalink / raw)
To: jgarzik@pobox.com
Cc: meet2prabhu@gmail.com, linuxppc-dev@lists.ozlabs.org,
linux-ide@vger.kernel.org
In-Reply-To: <1299472170-3580-1-git-send-email-prabhakar@freescale.com>
Hi Jeff,
I am not finding any comments on this.
Could you please ACK this patch so that it can be applied in external list.=
=20
--Prabhakar
> -----Original Message-----
> From: Kushwaha Prabhakar-B32579
> Sent: Monday, March 07, 2011 10:00 AM
> To: linux-ide@vger.kernel.org
> Cc: jgarzik@pobox.com; meet2prabhu@gmail.com; linuxppc-
> dev@lists.ozlabs.org; Kushwaha Prabhakar-B32579
> Subject: [PATCH] driver/FSL SATA: Update RX_WATER_MARK for TRANSCFG
>=20
> RX_WATER_MARK sets the number of locations in Rx FIFO that can be used
> before the transport layer instructs the link layer to transmit HOLDS.
> Note that it can take some time for the HOLDs to get to the other end,
> and that in the interim there must be enough room in the FIFO to absorb
> all data that could arrive.
>=20
> Update the new recommended value to 16.
>=20
> Signed-off-by: Prabhakar Kushwaha <prabhakar@freescale.com>
> ---
> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
> (branch master)
>=20
> This patch is already gone through review of linuxppc-dev mail list.
> Making CC linuxppc-dev@lists.ozlabs.org
>=20
> drivers/ata/sata_fsl.c | 12 ++++++++++++
> 1 files changed, 12 insertions(+), 0 deletions(-)
>=20
> diff --git a/drivers/ata/sata_fsl.c b/drivers/ata/sata_fsl.c index
> 895771c..29d2f29 100644
> --- a/drivers/ata/sata_fsl.c
> +++ b/drivers/ata/sata_fsl.c
> @@ -186,6 +186,11 @@ enum {
> COMMANDSTAT =3D 0x20,
> };
>=20
> +/* TRANSCFG (transport-layer) configuration control */ enum {
> + TRANSCFG_RX_WATER_MARK =3D (1 << 4),
> +};
> +
> /* PHY (link-layer) configuration control */ enum {
> PHY_BIST_ENABLE =3D 0x01,
> @@ -1305,6 +1310,7 @@ static int sata_fsl_probe(struct platform_device
> *ofdev,
> struct sata_fsl_host_priv *host_priv =3D NULL;
> int irq;
> struct ata_host *host;
> + u32 temp;
>=20
> struct ata_port_info pi =3D sata_fsl_port_info[0];
> const struct ata_port_info *ppi[] =3D { &pi, NULL }; @@ -1319,6
> +1325,12 @@ static int sata_fsl_probe(struct platform_device *ofdev,
> ssr_base =3D hcr_base + 0x100;
> csr_base =3D hcr_base + 0x140;
>=20
> + if (!of_device_is_compatible(ofdev->dev.of_node, "fsl,mpc8315-
> sata")) {
> + temp =3D ioread32(csr_base + TRANSCFG);
> + temp =3D temp & 0xffffffe0;
> + iowrite32(temp | TRANSCFG_RX_WATER_MARK, csr_base +
> TRANSCFG);
> + }
> +
> DPRINTK("@reset i/o =3D 0x%x\n", ioread32(csr_base + TRANSCFG));
> DPRINTK("sizeof(cmd_desc) =3D %d\n", sizeof(struct command_desc));
> DPRINTK("sizeof(#define cmd_desc) =3D %d\n", SATA_FSL_CMD_DESC_SIZE);
> --
> 1.7.3
^ permalink raw reply
* [PATCH] ppc, 83xx: rename and update kmeter1
From: Holger Brunck @ 2011-03-11 7:02 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Heiko Schocher, Holger Brunck
Beside the MPC 8360 based board kmeter1 other km83xx boards
from keymile will follow. Therefore the board specific naming
kmeter1 for functions and files were replaced with km83xx.
Additionally some updates were made:
- update defconfig for 2.6.38
- rework flash partitioning in dts file
- add gpio controller for qe_pio_c in dts
Signed-off-by: Holger Brunck <holger.brunck@keymile.com>
Acked-by: Heiko Schocher <hs@denx.de>
CC: Benjamin Herrenschmidt <benh@kernel.crashing.org>
CC: Kumar Gala <galak@kernel.crashing.org>
CC: Heiko Schocher <hs@denx.de>
---
arch/powerpc/boot/dts/kmeter1.dts | 69 +++++++++++---------
arch/powerpc/configs/83xx/kmeter1_defconfig | 7 +--
arch/powerpc/platforms/83xx/Makefile | 2 +-
.../powerpc/platforms/83xx/{kmeter1.c => km83xx.c} | 46 +++++++++----
4 files changed, 71 insertions(+), 53 deletions(-)
rename arch/powerpc/platforms/83xx/{kmeter1.c => km83xx.c} (80%)
diff --git a/arch/powerpc/boot/dts/kmeter1.dts b/arch/powerpc/boot/dts/kmeter1.dts
index d8b5d12..d16bae1 100644
--- a/arch/powerpc/boot/dts/kmeter1.dts
+++ b/arch/powerpc/boot/dts/kmeter1.dts
@@ -1,7 +1,7 @@
/*
* Keymile KMETER1 Device Tree Source
*
- * 2008 DENX Software Engineering GmbH
+ * 2008-2011 DENX Software Engineering GmbH
*
* 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
@@ -70,11 +70,11 @@
#address-cells = <1>;
#size-cells = <0>;
cell-index = <0>;
- compatible = "fsl-i2c";
+ compatible = "fsl,mpc8313-i2c","fsl-i2c";
reg = <0x3000 0x100>;
interrupts = <14 0x8>;
interrupt-parent = <&ipic>;
- dfsrr;
+ clock-frequency = <400000>;
};
serial0: serial@4500 {
@@ -137,6 +137,13 @@
compatible = "fsl,mpc8360-par_io";
num-ports = <7>;
+ qe_pio_c: gpio-controller@30 {
+ #gpio-cells = <2>;
+ compatible = "fsl,mpc8360-qe-pario-bank",
+ "fsl,mpc8323-qe-pario-bank";
+ reg = <0x1430 0x18>;
+ gpio-controller;
+ };
pio_ucc1: ucc_pin@0 {
reg = <0>;
@@ -472,7 +479,17 @@
#address-cells = <0>;
#interrupt-cells = <1>;
reg = <0x80 0x80>;
- interrupts = <32 8 33 8>;
+ big-endian;
+ interrupts = <
+ 32 0x8
+ 33 0x8
+ 34 0x8
+ 35 0x8
+ 40 0x8
+ 41 0x8
+ 42 0x8
+ 43 0x8
+ >;
interrupt-parent = <&ipic>;
};
};
@@ -484,43 +501,31 @@
compatible = "fsl,mpc8360-localbus", "fsl,pq2pro-localbus",
"simple-bus";
reg = <0xe0005000 0xd8>;
- ranges = <0 0 0xf0000000 0x04000000>; /* Filled in by U-Boot */
+ ranges = <0 0 0xf0000000 0x04000000 /* LB 0 */
+ 1 0 0xe8000000 0x01000000 /* LB 1 */
+ 3 0 0xa0000000 0x10000000>; /* LB 3 */
- flash@f0000000,0 {
+ flash@0,0 {
compatible = "cfi-flash";
- /*
- * The Intel P30 chip has 2 non-identical chips on
- * one die, so we need to define 2 separate regions
- * that are scanned by physmap_of independantly.
- */
- reg = <0 0x00000000 0x02000000
- 0 0x02000000 0x02000000>; /* Filled in by U-Boot */
- bank-width = <2>;
+ reg = <0 0 0x04000000>;
#address-cells = <1>;
#size-cells = <1>;
- partition@0 {
+ bank-width = <2>;
+ partition@0 { /* 768KB */
label = "u-boot";
- reg = <0 0x40000>;
+ reg = <0 0xC0000>;
};
- partition@40000 {
+ partition@c0000 { /* 128KB */
label = "env";
- reg = <0x40000 0x40000>;
- };
- partition@80000 {
- label = "dtb";
- reg = <0x80000 0x20000>;
- };
- partition@a0000 {
- label = "kernel";
- reg = <0xa0000 0x300000>;
+ reg = <0xC0000 0x20000>;
};
- partition@3a0000 {
- label = "ramdisk";
- reg = <0x3a0000 0x800000>;
+ partition@e0000 { /* 128KB */
+ label = "envred";
+ reg = <0xE0000 0x20000>;
};
- partition@ba0000 {
- label = "user";
- reg = <0xba0000 0x3460000>;
+ partition@100000 { /* 64512KB */
+ label = "ubi0";
+ reg = <0x100000 0x3F00000>;
};
};
};
diff --git a/arch/powerpc/configs/83xx/kmeter1_defconfig b/arch/powerpc/configs/83xx/kmeter1_defconfig
index 7a7b731..07e1bba 100644
--- a/arch/powerpc/configs/83xx/kmeter1_defconfig
+++ b/arch/powerpc/configs/83xx/kmeter1_defconfig
@@ -2,6 +2,7 @@ CONFIG_EXPERIMENTAL=y
# CONFIG_SWAP is not set
CONFIG_SYSVIPC=y
CONFIG_POSIX_MQUEUE=y
+CONFIG_SPARSE_IRQ=y
CONFIG_LOG_BUF_SHIFT=14
CONFIG_EXPERT=y
# CONFIG_HOTPLUG is not set
@@ -18,7 +19,6 @@ CONFIG_KMETER1=y
CONFIG_NO_HZ=y
CONFIG_HIGH_RES_TIMERS=y
CONFIG_PREEMPT=y
-CONFIG_SPARSE_IRQ=y
# CONFIG_SECCOMP is not set
CONFIG_NET=y
CONFIG_PACKET=y
@@ -37,7 +37,6 @@ CONFIG_MTD=y
CONFIG_MTD_CONCAT=y
CONFIG_MTD_PARTITIONS=y
CONFIG_MTD_CMDLINE_PARTS=y
-CONFIG_MTD_OF_PARTS=y
CONFIG_MTD_CHAR=y
CONFIG_MTD_BLOCK=y
CONFIG_MTD_CFI=y
@@ -49,13 +48,12 @@ CONFIG_MTD_UBI=y
CONFIG_MTD_UBI_GLUEBI=y
CONFIG_MTD_UBI_DEBUG=y
CONFIG_PROC_DEVICETREE=y
-# CONFIG_MISC_DEVICES is not set
CONFIG_NETDEVICES=y
CONFIG_DUMMY=y
CONFIG_TUN=y
+CONFIG_MII=y
CONFIG_MARVELL_PHY=y
CONFIG_NET_ETHERNET=y
-CONFIG_MII=y
CONFIG_UCC_GETH=y
# CONFIG_NETDEV_10000 is not set
CONFIG_WAN=y
@@ -77,7 +75,6 @@ CONFIG_I2C_MPC=y
# CONFIG_USB_SUPPORT is not set
CONFIG_UIO=y
# CONFIG_DNOTIFY is not set
-CONFIG_INOTIFY=y
CONFIG_TMPFS=y
CONFIG_JFFS2_FS=y
CONFIG_NFS_FS=y
diff --git a/arch/powerpc/platforms/83xx/Makefile b/arch/powerpc/platforms/83xx/Makefile
index 6e8bbbb..ed95bfc 100644
--- a/arch/powerpc/platforms/83xx/Makefile
+++ b/arch/powerpc/platforms/83xx/Makefile
@@ -16,4 +16,4 @@ obj-$(CONFIG_MPC837x_MDS) += mpc837x_mds.o
obj-$(CONFIG_SBC834x) += sbc834x.o
obj-$(CONFIG_MPC837x_RDB) += mpc837x_rdb.o
obj-$(CONFIG_ASP834x) += asp834x.o
-obj-$(CONFIG_KMETER1) += kmeter1.o
+obj-$(CONFIG_KMETER1) += km83xx.o
diff --git a/arch/powerpc/platforms/83xx/kmeter1.c b/arch/powerpc/platforms/83xx/km83xx.c
similarity index 80%
rename from arch/powerpc/platforms/83xx/kmeter1.c
rename to arch/powerpc/platforms/83xx/km83xx.c
index 903acfd..a2b9b9e 100644
--- a/arch/powerpc/platforms/83xx/kmeter1.c
+++ b/arch/powerpc/platforms/83xx/km83xx.c
@@ -1,5 +1,5 @@
/*
- * Copyright 2008 DENX Software Engineering GmbH
+ * Copyright 2008-2011 DENX Software Engineering GmbH
* Author: Heiko Schocher <hs@denx.de>
*
* Description:
@@ -49,12 +49,12 @@
* Setup the architecture
*
*/
-static void __init kmeter1_setup_arch(void)
+static void __init mpc83xx_km_setup_arch(void)
{
struct device_node *np;
if (ppc_md.progress)
- ppc_md.progress("kmeter1_setup_arch()", 0);
+ ppc_md.progress("kmpbec83xx_setup_arch()", 0);
#ifdef CONFIG_PCI
for_each_compatible_node(np, "pci", "fsl,mpc8349-pci")
@@ -69,6 +69,9 @@ static void __init kmeter1_setup_arch(void)
par_io_init(np);
of_node_put(np);
+ for_each_node_by_name(np, "spi")
+ par_io_of_config(np);
+
for (np = NULL; (np = of_find_node_by_name(np, "ucc")) != NULL;)
par_io_of_config(np);
}
@@ -119,7 +122,7 @@ static void __init kmeter1_setup_arch(void)
#endif /* CONFIG_QUICC_ENGINE */
}
-static struct of_device_id kmeter_ids[] = {
+static struct of_device_id kmpbec83xx_ids[] = {
{ .type = "soc", },
{ .compatible = "soc", },
{ .compatible = "simple-bus", },
@@ -131,13 +134,13 @@ static struct of_device_id kmeter_ids[] = {
static int __init kmeter_declare_of_platform_devices(void)
{
/* Publish the QE devices */
- of_platform_bus_probe(NULL, kmeter_ids, NULL);
+ of_platform_bus_probe(NULL, kmpbec83xx_ids, NULL);
return 0;
}
-machine_device_initcall(kmeter1, kmeter_declare_of_platform_devices);
+machine_device_initcall(mpc83xx_km, kmeter_declare_of_platform_devices);
-static void __init kmeter1_init_IRQ(void)
+static void __init mpc83xx_km_init_IRQ(void)
{
struct device_node *np;
@@ -168,21 +171,34 @@ static void __init kmeter1_init_IRQ(void)
#endif /* CONFIG_QUICC_ENGINE */
}
+/* list of the supported boards */
+static char *board[] __initdata = {
+ "Keymile,KMETER1",
+ "Keymile,kmpbec8321",
+ NULL
+};
+
/*
* Called very early, MMU is off, device-tree isn't unflattened
*/
-static int __init kmeter1_probe(void)
+static int __init mpc83xx_km_probe(void)
{
- unsigned long root = of_get_flat_dt_root();
+ unsigned long node = of_get_flat_dt_root();
+ int i = 0;
- return of_flat_dt_is_compatible(root, "keymile,KMETER1");
+ while (board[i]) {
+ if (of_flat_dt_is_compatible(node, board[i]))
+ break;
+ i++;
+ }
+ return (board[i] != NULL);
}
-define_machine(kmeter1) {
- .name = "KMETER1",
- .probe = kmeter1_probe,
- .setup_arch = kmeter1_setup_arch,
- .init_IRQ = kmeter1_init_IRQ,
+define_machine(mpc83xx_km) {
+ .name = "mpc83xx-km-platform",
+ .probe = mpc83xx_km_probe,
+ .setup_arch = mpc83xx_km_setup_arch,
+ .init_IRQ = mpc83xx_km_init_IRQ,
.get_irq = ipic_get_irq,
.restart = mpc83xx_restart,
.time_init = mpc83xx_time_init,
--
1.7.0.5
^ permalink raw reply related
* Re: fsl_udc_core not initializing properly?
From: Anatolij Gustschin @ 2011-03-11 13:27 UTC (permalink / raw)
To: Matthew L. Creech; +Cc: linuxppc-dev
In-Reply-To: <AANLkTi=B4O7u3S3qsa_zfDKWp33hXw3Yp5j6szRXDgfJ@mail.gmail.com>
On Thu, 10 Mar 2011 13:46:29 -0500
"Matthew L. Creech" <mlcreech@gmail.com> wrote:
> On Sat, Feb 19, 2011 at 1:01 PM, Matthew L. Creech <mlcreech@gmail.com> w=
rote:
> >
> > Yes, it's there. =C2=A0Here's the DTS entry in case anything else stick=
s out:
> >
> > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0usb@23000 {
> > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0compatible =3D "fsl-usb2-dr";
> > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0reg =3D <0x23000 0x1000>;
> > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0#address-cells =3D <1>;
> > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0#size-cells =3D <0>;
> > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0interrupt-parent =3D <&ipic>;
> > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0interrupts =3D <38 0x8>;
> > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0phy_type =3D "utmi_wide";
> > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0dr_mode =3D "peripheral";
> > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0sleep =3D <&pmc 0x00300000>;
> > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0};
> >
>=20
> Hi Anatolij,
Hi Matthew,
> I tracked the problem down to a change made in September, which
> happens to be yours:
>=20
> http://git.kernel.org/?p=3Dlinux/kernel/git/torvalds/linux-2.6.git;a=3Dco=
mmitdiff;h=3D126512e3f274802ca65ebeca8660237f0361ad48
>=20
> When I roll this back, everything works fine again.
>=20
> First of all, I noticed that fsl-mph-dr-of.c isn't even compiling for
> me (even though I have the option enabled in my .config), because it's
> been placed in "usb/host/", and I'm only using device/gadget-mode USB.
>=20
> I edited the top-level Makefile to just force it into "usb/host/", and
> that makes sure that your driver gets built (and it's probed just fine
> at runtime). But that still didn't solve the problem - as before,
> fsl_udc_probe() is never being called.
Thanks for reporting this bug.
> Did you test this change in device mode? I'm wondering if there's
> something different about my configuration that prevents it from
> working. My config is uploaded here if it helps:
>=20
> http://mcreech.com/work/linux.config
I did test in device mode with additional Patches for USB Device/OTG
support for MPC5121e, these patches still need rework to be acceptable in
mainline. Thanks for your config, I'll look at the issue this weekend
and will report the result.
Anatolij
^ permalink raw reply
* ongoing mesh saga ...
From: kevin diggs @ 2011-03-11 18:04 UTC (permalink / raw)
To: linuxppc-dev
Hi,
While trying to figure out why the MESH SCSI controller will not work
with the 4.3.5 compiler but will work when compiled with 4.1.2, I
noticed some ... unfortunate behavior from the 4.3.5 compiler. Before
I try to see if I can fix it (i.e. the compiler), it would be nice to
see if the "issue" still exists.
Is there any chance someone with a compiler newer than 4.3.5 would be
willing to get me -S output from a mesh compile (preferably not a
module unless it does not make any difference) for 2.6.36. Using:
head -1 <top>/drivers/scsi/.mesh.o.cmd
you can get a command line which can then be edited to get a script to
do a -S compile (watch out for the '\#' in KBUILD_STR(s)).
Thanks!
kevin
^ permalink raw reply
* Re: ongoing mesh saga ...
From: Segher Boessenkool @ 2011-03-11 20:25 UTC (permalink / raw)
To: kevin diggs; +Cc: linuxppc-dev
In-Reply-To: <AANLkTinfxdckX=sYk5fX4vRhnmJNTHnytWkUW0w_HMj4@mail.gmail.com>
> Is there any chance someone with a compiler newer than 4.3.5 would be
> willing to get me -S output from a mesh compile (preferably not a
> module unless it does not make any difference) for 2.6.36. Using:
>
> head -1 <top>/drivers/scsi/.mesh.o.cmd
>
> you can get a command line which can then be edited to get a script to
> do a -S compile (watch out for the '\#' in KBUILD_STR(s)).
make drivers/scsi/mesh.s
File sent separately, I doubt the list wants to see it.
Segher
^ permalink raw reply
* Re: ongoing mesh saga ...
From: kevin diggs @ 2011-03-12 1:27 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev
In-Reply-To: <56564.94.211.195.167.1299875156.squirrel@gate.crashing.org>
Hi,
On Fri, Mar 11, 2011 at 2:25 PM, Segher Boessenkool
<segher@kernel.crashing.org> wrote:
>
> make drivers/scsi/mesh.s
>
??? I thought I have tried this in the past and it did not work? The
make <path>/<file>.s thing?
Thanks for the tip!
kevin
^ permalink raw reply
* Re: ongoing mesh saga ...
From: Segher Boessenkool @ 2011-03-12 1:39 UTC (permalink / raw)
To: kevin diggs; +Cc: linuxppc-dev
In-Reply-To: <AANLkTinzpvV3Y7FXTPo8yPrE69CA1C1ejBMqC+O5o9zZ@mail.gmail.com>
>> make drivers/scsi/mesh.s
>>
> ??? I thought I have tried this in the past and it did not work? The
> make <path>/<file>.s thing?
>
> Thanks for the tip!
You need to have the driver in your kernel config, or things will
go weird.
Segher
^ permalink raw reply
* Re: ongoing mesh saga ...
From: kevin diggs @ 2011-03-12 1:43 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev
In-Reply-To: <56927.94.211.195.167.1299893950.squirrel@gate.crashing.org>
Hi,
Good to know. I just tried this on an x86 laptop. It was NOT happy!
And, obviously, I am not using a mesh SCSI controller on my Toshiba
A75.
And thanks again for your time!
kevin
On Fri, Mar 11, 2011 at 7:39 PM, Segher Boessenkool
<segher@kernel.crashing.org> wrote:
>>> make drivers/scsi/mesh.s
>>>
>> ??? I thought I have tried this in the past and it did not work? The
>> make <path>/<file>.s thing?
>>
>> Thanks for the tip!
>
> You need to have the driver in your kernel config, or things will
> go weird.
>
>
> Segher
>
^ permalink raw reply
* Anybody with a PowerBook3,3 or PowerBook3,4 ?
From: Benjamin Herrenschmidt @ 2011-03-12 5:11 UTC (permalink / raw)
To: linuxppc-dev
If anybody is around with one of these machines, any chance they
can send me a tarball of /proc/device-tree ?
Thanks !
Cheers,
Ben.
^ permalink raw reply
* Re: fsl_udc_core not initializing properly?
From: Anatolij Gustschin @ 2011-03-12 8:00 UTC (permalink / raw)
To: Matthew L. Creech; +Cc: linuxppc-dev
In-Reply-To: <AANLkTi=B4O7u3S3qsa_zfDKWp33hXw3Yp5j6szRXDgfJ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1243 bytes --]
Hi Matthew,
On Thu, 10 Mar 2011 13:46:29 -0500
"Matthew L. Creech" <mlcreech@gmail.com> wrote:
...
> I tracked the problem down to a change made in September, which
> happens to be yours:
>
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=126512e3f274802ca65ebeca8660237f0361ad48
>
> When I roll this back, everything works fine again.
>
> First of all, I noticed that fsl-mph-dr-of.c isn't even compiling for
> me (even though I have the option enabled in my .config), because it's
> been placed in "usb/host/", and I'm only using device/gadget-mode USB.
>
> I edited the top-level Makefile to just force it into "usb/host/", and
> that makes sure that your driver gets built (and it's probed just fine
> at runtime). But that still didn't solve the problem - as before,
> fsl_udc_probe() is never being called.
>
> Did you test this change in device mode? I'm wondering if there's
> something different about my configuration that prevents it from
> working. My config is uploaded here if it helps:
>
> http://mcreech.com/work/linux.config
Can you please apply the attached patch, then build with your
linux.config and send me the kernel boot log? It will help to
fix the issue.
Thanks,
Anatolij
[-- Attachment #2: usb-mph-dr-cfg.diff --]
[-- Type: text/x-patch, Size: 1269 bytes --]
diff --git a/drivers/Makefile b/drivers/Makefile
index f3ebb30..bf1ad90 100644
--- a/drivers/Makefile
+++ b/drivers/Makefile
@@ -67,6 +67,7 @@ obj-$(CONFIG_UWB) += uwb/
obj-$(CONFIG_USB_OTG_UTILS) += usb/otg/
obj-$(CONFIG_USB) += usb/
obj-$(CONFIG_USB_MUSB_HDRC) += usb/musb/
+obj-$(CONFIG_USB_FSL_MPH_DR_OF) += usb/host/
obj-$(CONFIG_PCI) += usb/
obj-$(CONFIG_USB_GADGET) += usb/gadget/
obj-$(CONFIG_SERIO) += input/serio/
diff --git a/drivers/usb/gadget/fsl_udc_core.c b/drivers/usb/gadget/fsl_udc_core.c
index 4c55eda..a3ba374 100644
--- a/drivers/usb/gadget/fsl_udc_core.c
+++ b/drivers/usb/gadget/fsl_udc_core.c
@@ -2240,6 +2240,7 @@ static int __init fsl_udc_probe(struct platform_device *pdev)
unsigned int i;
u32 dccparams;
+ printk("%s\n", __func__);
if (strcmp(pdev->name, driver_name)) {
VDBG("Wrong device");
return -ENODEV;
diff --git a/drivers/usb/host/fsl-mph-dr-of.c b/drivers/usb/host/fsl-mph-dr-of.c
index 574b99e..b8b3070 100644
--- a/drivers/usb/host/fsl-mph-dr-of.c
+++ b/drivers/usb/host/fsl-mph-dr-of.c
@@ -130,6 +130,7 @@ static int __devinit fsl_usb2_mph_dr_of_probe(struct platform_device *ofdev)
static unsigned int idx;
int i;
+ printk("%s\n", __func__);
if (!of_device_is_available(np))
return -ENODEV;
^ permalink raw reply related
* [PATCH] powerpc: dtc: remove obsolete .gitignore entries
From: Wolfram Sang @ 2011-03-12 16:44 UTC (permalink / raw)
To: linuxppc-dev
dtc was moved and .gitignores have been added to the new location. So, we can
delete the old, forgotten ones.
Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
arch/powerpc/boot/.gitignore | 1 -
arch/powerpc/boot/dtc-src/.gitignore | 3 ---
2 files changed, 0 insertions(+), 4 deletions(-)
delete mode 100644 arch/powerpc/boot/dtc-src/.gitignore
diff --git a/arch/powerpc/boot/.gitignore b/arch/powerpc/boot/.gitignore
index 3d80c3e..12da77e 100644
--- a/arch/powerpc/boot/.gitignore
+++ b/arch/powerpc/boot/.gitignore
@@ -1,5 +1,4 @@
addnote
-dtc
empty.c
hack-coff
infblock.c
diff --git a/arch/powerpc/boot/dtc-src/.gitignore b/arch/powerpc/boot/dtc-src/.gitignore
deleted file mode 100644
index a7c3f94..0000000
--- a/arch/powerpc/boot/dtc-src/.gitignore
+++ /dev/null
@@ -1,3 +0,0 @@
-dtc-lexer.lex.c
-dtc-parser.tab.c
-dtc-parser.tab.h
--
1.7.2.3
^ permalink raw reply related
* any chance to use a modern linux kernel on Pegasos1 G3 ?
From: nello martuscielli @ 2011-03-12 19:05 UTC (permalink / raw)
To: linuxppc-dev
hallo dear linuxppc kernel developers,
i'm looking for some tips to use a modern linux kernel on my old
Pegasos1 G3 600MHz (IBM PowerPC 750Cxe).
The last working one is 2.6.16.x with arch=ppc.
a picture of the screen when it freezes loading a modern kernel:
http://i52.tinypic.com/33uzgc8.jpg
thank you,
Nel
--
Power Mac G4 AGP 450MHz - CRUX PPC (32bit) 2.7
^ permalink raw reply
* Re: any chance to use a modern linux kernel on Pegasos1 G3 ?
From: kevin diggs @ 2011-03-12 19:38 UTC (permalink / raw)
To: nello martuscielli; +Cc: linuxppc-dev
In-Reply-To: <AANLkTimJwBfz=RksRtuj3M2VQoMjj1msUb78s1H=GfJM@mail.gmail.com>
Hi,
For what it is worth, I can boot 2.6.36 on a PowerMac 8600 with a
750GX processor in it. I have to compile the kernel with gcc 4.1.2.
Figuring out why 4.3.5 won't work is ... a work in progress (maybe an
exorcism will help?).
kevin
On Sat, Mar 12, 2011 at 1:05 PM, nello martuscielli <ppc.addon@gmail.com> wrote:
> hallo dear linuxppc kernel developers,
>
> i'm looking for some tips to use a modern linux kernel on my old
> Pegasos1 G3 600MHz (IBM PowerPC 750Cxe).
> The last working one is 2.6.16.x with arch=ppc.
>
> a picture of the screen when it freezes loading a modern kernel:
> http://i52.tinypic.com/33uzgc8.jpg
>
>
> thank you,
> Nel
> --
> Power Mac G4 AGP 450MHz - CRUX PPC (32bit) 2.7
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
>
^ permalink raw reply
* Re: [PATCH] crypto: add support for the Freescale SEC4/CAAM
From: Herbert Xu @ 2011-03-13 8:55 UTC (permalink / raw)
To: Kim Phillips
Cc: Steve Cornelius, devicetree-discuss, linuxppc-dev, linux-crypto
In-Reply-To: <20110308193421.67e2aea6.kim.phillips@freescale.com>
On Tue, Mar 08, 2011 at 07:34:21PM -0600, Kim Phillips wrote:
> The SEC4 supercedes the SEC2.x/3.x as Freescale's
> Integrated Security Engine. Its programming model is
> incompatible with all prior versions of the SEC (talitos).
>
> The SEC4 is also known as the Cryptographic Accelerator
> and Assurance Module (CAAM); this driver is named caam.
>
> This initial submission does not include support for Data Path
> mode operation - AEAD descriptors are submitted via the job
> ring interface, while the Queue Interface (QI) is enabled
> for use by others. Only AEAD algorithms are implemented
> at this time, for use with IPsec.
>
> Many thanks to the Freescale STC team for their contributions
> to this driver.
>
> Signed-off-by: Steve Cornelius <sec@pobox.com>
> Signed-off-by: Kim Phillips <kim.phillips@freescale.com>
Patch applied. Thanks a lot!
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH V12 3/4] ptp: Added a clock driver for the IXP46x.
From: Krzysztof Halasa @ 2011-03-13 23:40 UTC (permalink / raw)
To: Richard Cochran
Cc: Thomas Gleixner, Rodolfo Giometti, Arnd Bergmann, Peter Zijlstra,
linux-api, devicetree-discuss, linux-kernel, Russell King,
Paul Mackerras, John Stultz, Alan Cox, netdev, Mike Frysinger,
Christoph Lameter, linuxppc-dev, David Miller, linux-arm-kernel
In-Reply-To: <cd6ddff0dcca60ac88b35660505d7bf54ad32405.1298878618.git.richard.cochran@omicron.at>
Richard Cochran <richardcochran@gmail.com> writes:
> This patch adds a driver for the hardware time stamping unit found on the
> IXP465. The basic clock operations and an external trigger are implemented.
>
> Signed-off-by: Richard Cochran <richard.cochran@omicron.at>
> Acked-by: John Stultz <johnstul@us.ibm.com>
> ---
> arch/arm/mach-ixp4xx/include/mach/ixp46x_ts.h | 78 ++++++
> drivers/net/arm/ixp4xx_eth.c | 192 ++++++++++++++-
> drivers/ptp/Kconfig | 13 +
> drivers/ptp/Makefile | 1 +
> drivers/ptp/ptp_ixp46x.c | 332 +++++++++++++++++++++++++
I can't see any obvious problem in this code, though I don't have IXP46x
hardware.
Acked-by: Krzysztof Halasa <khc@pm.waw.pl>
--
Krzysztof Halasa
^ permalink raw reply
* Re: Mpc8315erdb openvpn segmentation fault
From: Vasanth Ragavendran @ 2011-03-14 2:46 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <31103965.post@talk.nabble.com>
Thanks scott! my question must have been very silly to u! thanks for replying
to it patiently!!!
Vasanth Ragavendran wrote:
>
> Thanks again Scott. That was really helpful. Actually i forgot to mention
> that i had created an ext2 ramdisk file system and it was non-persistent
> (the mount point was /dev/ram for this ext2 ramdisk filesystem). and then
> i changed the file system to jffs2 and it is persistent (and the mount
> point was /dev/mtdblock1 for jffs2 file system). so my question is why is
> that the ext2 ramdisk is non-persistent? is it because of the mount point
> /dev/ram and what needs to be changed in order to make it persistent.
> thanks again for prompt response..
>
>
> Scott Wood-2 wrote:
>>
>> On Mon, 7 Mar 2011 20:28:32 -0800
>> Vasanth Ragavendran <ragavendrapec@yahoo.co.in> wrote:
>>
>>>
>>> Thanks a ton Scott. Actually i was working with the same version of the
>>> kernel on both the boards.
>>> it was 2.6.29.6. neither i changed the u-boot. it was the same in both.
>>> however i recompiled the kernel and i installed on both the boards and
>>> it
>>> worked fine! :) thanks again for responding. however i've another
>>> question.
>>> my filesystem in the board is non-persistent i.e. the files i create are
>>> erased after i reboot i know the files are getting stored in RAM and i
>>> wish
>>> to make them persistent. what do i need to do for this? should i create
>>> a
>>> separate partition in the flash and load certain files into that
>>> partition?
>>> or how should i make it persistent so that files stay beyond reboot!
>>> thanks
>>> again! eagerly awaiting your response.
>>
>> Yes, you should create a filesystem (e.g. jffs2) on a flash partition.
>>
>> -Scott
>>
>> _______________________________________________
>> Linuxppc-dev mailing list
>> Linuxppc-dev@lists.ozlabs.org
>> https://lists.ozlabs.org/listinfo/linuxppc-dev
>>
>>
>
>
--
View this message in context: http://old.nabble.com/Mpc8315erdb-openvpn-segmentation-fault-tp31086738p31140838.html
Sent from the linuxppc-dev mailing list archive at Nabble.com.
^ permalink raw reply
* Re: [PATCH][v3] driver/FSL SATA:Fix wrong Device Error Register usage
From: Jeff Garzik @ 2011-03-14 7:05 UTC (permalink / raw)
To: Prabhakar Kushwaha; +Cc: linux-ide, Ashish Kalra, linuxppc-dev, meet2prabhu
In-Reply-To: <1299655038-727-1-git-send-email-prabhakar@freescale.com>
On 03/09/2011 02:17 AM, Prabhakar Kushwaha wrote:
> When a single device error is detected, the device under the error is indicated
> by the error bit set in the DER. There is a one to one mapping between register
> bit and devices on Port multiplier(PMP) i.e. bit 0 represents PMP device 0 and
> bit 1 represents PMP device 1 etc.
>
> Current implementation treats Device error register value as device number not
> set of bits representing multiple device on PMP. It is changed to consider bit
> level.
> No need to check for each set bit as all command is going to be aborted.
>
> Signed-off-by: Ashish Kalra<B00888@freescale.com>
> Signed-off-by: Prabhakar Kushwaha<prabhakar@freescale.com>
> ---
>
> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git (branch master)
>
> This patch is already gone through review of linuxppc-dev mail list.
> Making CC linuxppc-dev@lists.ozlabs.org
>
> Changes for v2: Incorporated Sergei Shtylyov's comment
> - Put space after -
> - added a line
> Changes for v3: Incorporated David Laight's comment
> - Condition check for dereg 0 for hardware error
>
> drivers/ata/sata_fsl.c | 7 +++++--
> 1 files changed, 5 insertions(+), 2 deletions(-)
applied
^ permalink raw reply
* Re: linux-next: build failure after merge of the final tree (block tree related)
From: Lars Ellenberg @ 2011-03-14 8:33 UTC (permalink / raw)
To: Jens Axboe
Cc: Stephen Rothwell, linux-s390, linux-kernel, Philipp Reisner,
linux-next, linuxppc-dev
In-Reply-To: <4D79CB66.2020302@kernel.dk>
On Fri, Mar 11, 2011 at 08:12:38AM +0100, Jens Axboe wrote:
> On 2011-03-11 07:58, Stephen Rothwell wrote:
> > Hi all,
> >
> > After merging the final tree, today's linux-next build (powerpc
> > allyesconfig) failed like this:
> >
> > drivers/char/tpm/tpm_tis.c:96: warning: 'is_itpm' defined but not used
> > drivers/block/drbd/drbd_bitmap.c: In function '__bm_change_bits_to':
> > drivers/block/drbd/drbd_bitmap.c:1287: error: implicit declaration of function 'generic___test_and_set_le_bit'
> > drivers/block/drbd/drbd_bitmap.c:1289: error: implicit declaration of function 'generic___test_and_clear_le_bit'
> > drivers/block/drbd/drbd_bitmap.c: In function 'drbd_bm_test_bit':
> > drivers/block/drbd/drbd_bitmap.c:1438: error: implicit declaration of function 'generic_test_le_bit'
> >
> > Caused by commit 4b0715f09655 ("drbd: allow petabyte storage on 64bit
> > arch").
> >
> > I have applied this patch for today (surely there is a better way):
>
> Thanks for not dropping it, I'll let the drbd guys send in a proper fix
> and get it committed.
Should that be fixed by adding
#include <asm-generic/bitops/le.h>
to
arch/powerpc/include/asm/bitops.h
(and arch/s390/include/asm/bitops.h, possibly others?)
Or are we expected to include that ourselves, directly?
We probably need to select CONFIG_GENERIC_FIND_NEXT_BIT
from our Kconfig as well?
Lars
^ permalink raw reply
* linux-next: build failure after merge of the final tree (powerpc tree related)
From: Stephen Rothwell @ 2011-03-14 9:38 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras, linuxppc-dev
Cc: linux-next, Lennert Buytenhek, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 689 bytes --]
Hi all,
After merging the final tree, today's linux-next build (powerpc
allyesconfig) failed like this:
drivers/gpio/langwell_gpio.c: In function 'lnw_irq_handler':
drivers/gpio/langwell_gpio.c:210: error: 'struct irq_desc' has no member named 'chip'
drivers/gpio/langwell_gpio.c:211: error: 'struct irq_desc' has no member named 'chip'
Caused by commit 17b9f9e2653a ("powerpc: Enable
GENERIC_HARDIRQS_NO_DEPRECATED") enabling
CONFIG_GENERIC_HARDIRQS_NO_DEPRECATED for powerpc without previously
fixing up the above driver.
I have reverted that commit for today.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* RE: [PATCH][v3] driver/FSL SATA:Fix wrong Device Error Register usage
From: Kushwaha Prabhakar-B32579 @ 2011-03-14 4:12 UTC (permalink / raw)
To: linux-ide@vger.kernel.org, jgarzik@pobox.com
Cc: meet2prabhu@gmail.com, Kalra Ashish-B00888,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <1299655038-727-1-git-send-email-prabhakar@freescale.com>
Hi Jeff,
I am not finding any new comments on this.
Could you please ACK this patch so that it can be applied on external list.=
=20
--Prabhakar
> -----Original Message-----
> From: Kushwaha Prabhakar-B32579
> Sent: Wednesday, March 09, 2011 12:47 PM
> To: linux-ide@vger.kernel.org
> Cc: linuxppc-dev@lists.ozlabs.org; jgarzik@pobox.com;
> meet2prabhu@gmail.com; Kushwaha Prabhakar-B32579; Kalra Ashish-B00888
> Subject: [PATCH][v3] driver/FSL SATA:Fix wrong Device Error Register
> usage
>=20
> When a single device error is detected, the device under the error is
> indicated by the error bit set in the DER. There is a one to one mapping
> between register bit and devices on Port multiplier(PMP) i.e. bit 0
> represents PMP device 0 and bit 1 represents PMP device 1 etc.
>=20
> Current implementation treats Device error register value as device
> number not set of bits representing multiple device on PMP. It is changed
> to consider bit level.
> No need to check for each set bit as all command is going to be aborted.
>=20
> Signed-off-by: Ashish Kalra <B00888@freescale.com>
> Signed-off-by: Prabhakar Kushwaha <prabhakar@freescale.com>
> ---
>=20
> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
> (branch master)
>=20
> This patch is already gone through review of linuxppc-dev mail list.
> Making CC linuxppc-dev@lists.ozlabs.org
>=20
> Changes for v2: Incorporated Sergei Shtylyov's comment
> - Put space after -
> - added a line
> Changes for v3: Incorporated David Laight's comment
> - Condition check for dereg 0 for hardware error
>=20
> drivers/ata/sata_fsl.c | 7 +++++--
> 1 files changed, 5 insertions(+), 2 deletions(-)
>=20
> diff --git a/drivers/ata/sata_fsl.c b/drivers/ata/sata_fsl.c index
> b0214d0..ad84ddc 100644
> --- a/drivers/ata/sata_fsl.c
> +++ b/drivers/ata/sata_fsl.c
> @@ -1040,12 +1040,15 @@ static void sata_fsl_error_intr(struct ata_port
> *ap)
>=20
> /* find out the offending link and qc */
> if (ap->nr_pmp_links) {
> + unsigned int dev_num;
> +
> dereg =3D ioread32(hcr_base + DE);
> iowrite32(dereg, hcr_base + DE);
> iowrite32(cereg, hcr_base + CE);
>=20
> - if (dereg < ap->nr_pmp_links) {
> - link =3D &ap->pmp_link[dereg];
> + dev_num =3D ffs(dereg) - 1;
> + if (dev_num < ap->nr_pmp_links && dereg !=3D 0) {
> + link =3D &ap->pmp_link[dev_num];
> ehi =3D &link->eh_info;
> qc =3D ata_qc_from_tag(ap, link->active_tag);
> /*
> --
> 1.7.3
^ permalink raw reply
* [PATCH] langwell_gpio: fix CONFIG_GENERIC_HARDIRQS_NO_DEPRECATED build
From: Lennert Buytenhek @ 2011-03-14 10:46 UTC (permalink / raw)
To: Grant Likely, linux-kernel
Cc: Stephen Rothwell, linux-next, Paul Mackerras, linuxppc-dev
When CONFIG_GENERIC_HARDIRQS_NO_DEPRECATED is defined, struct irq_desc
no longer contains a ->chip member pointing to the corresponding struct
irq_chip, leading to the following build error:
drivers/gpio/langwell_gpio.c: In function 'lnw_irq_handler':
drivers/gpio/langwell_gpio.c:210: error: 'struct irq_desc' has no member named 'chip'
drivers/gpio/langwell_gpio.c:211: error: 'struct irq_desc' has no member named 'chip'
Fix this up by using get_irq_desc_chip(desc) to get the irq_chip,
instead of trying to get it via desc->chip directly.
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Lennert Buytenhek <buytenh@secretlab.ca>
diff --git a/drivers/gpio/langwell_gpio.c b/drivers/gpio/langwell_gpio.c
index 54d70a4..56eb66a 100644
--- a/drivers/gpio/langwell_gpio.c
+++ b/drivers/gpio/langwell_gpio.c
@@ -191,6 +191,7 @@ static void lnw_irq_handler(unsigned irq, struct irq_desc *desc)
u32 base, gpio;
void __iomem *gedr;
u32 gedr_v;
+ struct irq_chip *chip;
/* check GPIO controller to check which pin triggered the interrupt */
for (base = 0; base < lnw->chip.ngpio; base += 32) {
@@ -207,8 +208,9 @@ static void lnw_irq_handler(unsigned irq, struct irq_desc *desc)
writel(gedr_v, gedr);
}
- if (desc->chip->irq_eoi)
- desc->chip->irq_eoi(irq_get_irq_data(irq));
+ chip = get_irq_desc_chip(desc);
+ if (chip->irq_eoi)
+ chip->irq_eoi(irq_get_irq_data(irq));
else
dev_warn(lnw->chip.dev, "missing EOI handler for irq %d\n", irq);
---
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox