* Problem reading and programming memory location...
From: neorf3k @ 2013-11-12 19:23 UTC (permalink / raw)
To: Linux Ppc Dev List Dev List
we have tried to read and program an 8bit register with 32bit address. =
we have mapped it with: ioremap, kmalloc etc=85 and then using: outb, =
iowrite8 etc.. but when we write to it, the value doesn=92t change=85 =
with other memory location is ok.
That is an 8 bit register, located at 0x10020000 in a mpc5200b =
architecture. we are using kernel 2.6.33.=20
what could be?
Thank you
Lorenzo=
^ permalink raw reply
* Re: [PATCH 2/4] phylib: Add generic 10G driver
From: Florian Fainelli @ 2013-11-12 17:53 UTC (permalink / raw)
To: shh.xie
Cc: Shaohui Xie, Shruti, linuxppc-dev, linux-kernel@vger.kernel.org,
madalin.bucur
In-Reply-To: <1384168049-2899-1-git-send-email-shh.xie@gmail.com>
Hello Shaohui,
2013/11/11 <shh.xie@gmail.com>:
> From: Andy Fleming
>
> Very incomplete, but will allow for binding an ethernet controller
> to it.
>
> Also, Add XGMII interface type
So that should be two separate patches, and
drivers/of/of_net.c::of_get_phy_mode() must be updated to know about
XMGII.
>
> Signed-off-by: Andy Fleming
Missing Andy's Signed-off-by tag.
> Signed-off-by: Shaohui Xie <Shaohui.Xie@freescale.com>
> ---
> drivers/net/phy/phy_device.c | 101 ++++++++++++++++++++++++++++++++++++++++++-
> include/linux/phy.h | 1 +
> 2 files changed, 101 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
> index 74630e9..30bf2d5 100644
> --- a/drivers/net/phy/phy_device.c
> +++ b/drivers/net/phy/phy_device.c
> @@ -32,6 +32,7 @@
> #include <linux/module.h>
> #include <linux/mii.h>
> #include <linux/ethtool.h>
> +#include <linux/mdio.h>
> #include <linux/phy.h>
>
> #include <asm/io.h>
> @@ -689,6 +690,13 @@ static int genphy_config_advert(struct phy_device *phydev)
> return changed;
> }
>
> +int gen10g_config_advert(struct phy_device *dev)
> +{
> + return 0;
> +}
> +EXPORT_SYMBOL(gen10g_config_advert);
> +
> +
> /**
> * genphy_setup_forced - configures/forces speed/duplex from @phydev
> * @phydev: target phy_device struct
> @@ -742,6 +750,12 @@ int genphy_restart_aneg(struct phy_device *phydev)
> }
> EXPORT_SYMBOL(genphy_restart_aneg);
>
> +int gen10g_restart_aneg(struct phy_device *phydev)
> +{
> + return 0;
> +}
> +EXPORT_SYMBOL(gen10g_restart_aneg);
> +
>
> /**
> * genphy_config_aneg - restart auto-negotiation or write BMCR
> @@ -784,6 +798,13 @@ int genphy_config_aneg(struct phy_device *phydev)
> }
> EXPORT_SYMBOL(genphy_config_aneg);
>
> +int gen10g_config_aneg(struct phy_device *phydev)
> +{
> + return 0;
> +}
> +EXPORT_SYMBOL(gen10g_config_aneg);
> +
> +
> /**
> * genphy_update_link - update link status in @phydev
> * @phydev: target phy_device struct
> @@ -913,6 +934,35 @@ int genphy_read_status(struct phy_device *phydev)
> }
> EXPORT_SYMBOL(genphy_read_status);
>
> +int gen10g_read_status(struct phy_device *phydev)
> +{
> + int devad, reg;
> + u32 mmd_mask = phydev->c45_ids.devices_in_package;
> +
> + phydev->link = 1;
> +
> + /* For now just lie and say it's 10G all the time */
> + phydev->speed = 10000;
Can you at least make this a little more proof? Something along:
if (phydev->supported & (SUPPORTED_10000baseT_Full))
phydev->speed = SPEED_10000;
else if (phydev->supported & (SUPPORTED_1000baseT_Full)
phydev->speed = SPEED_1000;
Although ideally we should be reading the relevant registers to figure
out what to do.
> + phydev->duplex = DUPLEX_FULL;
> +
> + for (devad = 0; mmd_mask; devad++, mmd_mask = mmd_mask >> 1) {
> + if (!(mmd_mask & 1))
> + continue;
> +
> + /* Read twice because link state is latched and a
> + * read moves the current state into the register
> + */
> + phy_read_mmd(phydev, devad, MDIO_STAT1);
> + reg = phy_read_mmd(phydev, devad, MDIO_STAT1);
> + if (reg < 0 || !(reg & MDIO_STAT1_LSTATUS))
> + phydev->link = 0;
> + }
> +
> + return 0;
> +}
> +EXPORT_SYMBOL(gen10g_read_status);
> +
> +
> static int genphy_config_init(struct phy_device *phydev)
> {
> int val;
> @@ -959,6 +1009,15 @@ static int genphy_config_init(struct phy_device *phydev)
>
> return 0;
> }
> +
> +static int gen10g_config_init(struct phy_device *phydev)
> +{
> + /* Temporarily just say we support everything */
> + phydev->supported = phydev->advertising = SUPPORTED_10000baseT_Full;
For consistency you should set SUPPORTED_TP, 1000baseT_Full does not
make sense for anything but twisted pairs AFAIR.
> +
> + return 0;
> +}
> +
> int genphy_suspend(struct phy_device *phydev)
> {
> int value;
> @@ -974,6 +1033,13 @@ int genphy_suspend(struct phy_device *phydev)
> }
> EXPORT_SYMBOL(genphy_suspend);
>
> +int gen10g_suspend(struct phy_device *phydev)
> +{
> + return 0;
> +}
> +EXPORT_SYMBOL(gen10g_suspend);
> +
> +
> int genphy_resume(struct phy_device *phydev)
> {
> int value;
> @@ -989,6 +1055,13 @@ int genphy_resume(struct phy_device *phydev)
> }
> EXPORT_SYMBOL(genphy_resume);
>
> +int gen10g_resume(struct phy_device *phydev)
> +{
> + return 0;
> +}
> +EXPORT_SYMBOL(gen10g_resume);
> +
> +
> /**
> * phy_probe - probe and init a PHY device
> * @dev: device to probe and init
> @@ -1129,6 +1202,20 @@ static struct phy_driver genphy_driver = {
> .driver = {.owner= THIS_MODULE, },
> };
>
> +static struct phy_driver gen10g_driver = {
> + .phy_id = 0xffffffff,
> + .phy_id_mask = 0xffffffff,
> + .name = "Generic 10G PHY",
> + .config_init = gen10g_config_init,
> + .features = 0,
This should be updated to be PHY_10GBIT_FEATURES where
PHY_10GBIT_FEATURES is defined to contain at least PHY_GBIT_FEATURES.
> + .config_aneg = gen10g_config_aneg,
> + .read_status = gen10g_read_status,
> + .suspend = gen10g_suspend,
> + .resume = gen10g_resume,
> + .driver = {.owner = THIS_MODULE, },
> +};
> +
> +
> static int __init phy_init(void)
> {
> int rc;
> @@ -1139,13 +1226,25 @@ static int __init phy_init(void)
>
> rc = phy_driver_register(&genphy_driver);
> if (rc)
> - mdio_bus_exit();
> + goto genphy_register_failed;
> +
> + rc = phy_driver_register(&gen10g_driver);
> + if (rc)
> + goto gen10g_register_failed;
> +
> + return rc;
> +
> +gen10g_register_failed:
> + phy_driver_unregister(&genphy_driver);
> +genphy_register_failed:
> + mdio_bus_exit();
As a subsequent patch you could use phy_drivers_register()
>
> return rc;
> }
>
> static void __exit phy_exit(void)
> {
> + phy_driver_unregister(&gen10g_driver);
> phy_driver_unregister(&genphy_driver);
And phy_drivers_unregister() here.
> mdio_bus_exit();
> }
> diff --git a/include/linux/phy.h b/include/linux/phy.h
> index 684925a..f864004 100644
> --- a/include/linux/phy.h
> +++ b/include/linux/phy.h
> @@ -66,6 +66,7 @@ typedef enum {
> PHY_INTERFACE_MODE_RGMII_TXID,
> PHY_INTERFACE_MODE_RTBI,
> PHY_INTERFACE_MODE_SMII,
> + PHY_INTERFACE_MODE_XGMII,
> } phy_interface_t;
>
>
> --
> 1.8.4.1
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
Florian
^ permalink raw reply
* [PATCH] powerpc/85xx: typo in dts: "interupt" (four devices)
From: Adam Borowski @ 2013-11-12 16:56 UTC (permalink / raw)
To: Mark Rutland, rob.herring, Pawel Moll, Stephen Warren,
Ian Campbell, devicetree, linuxppc-dev
Cc: Adam Borowski
In-Reply-To: <20131112091128.GA2976@e106331-lin.cambridge.arm.com>
These lines were inoperative for four years, which puts some doubt into
their importance, and it's possible the fixed version will regress, but
at the very least they should be removed instead.
Signed-off-by: Adam Borowski <kilobyte@angband.pl>
---
arch/powerpc/boot/dts/xcalibur1501.dts | 4 ++--
arch/powerpc/boot/dts/xpedite5301.dts | 4 ++--
arch/powerpc/boot/dts/xpedite5330.dts | 4 ++--
arch/powerpc/boot/dts/xpedite5370.dts | 4 ++--
4 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/arch/powerpc/boot/dts/xcalibur1501.dts b/arch/powerpc/boot/dts/xcalibur1501.dts
index cc00f4d..c409cba 100644
--- a/arch/powerpc/boot/dts/xcalibur1501.dts
+++ b/arch/powerpc/boot/dts/xcalibur1501.dts
@@ -637,14 +637,14 @@
tlu@2f000 {
compatible = "fsl,mpc8572-tlu", "fsl_tlu";
reg = <0x2f000 0x1000>;
- interupts = <61 2 >;
+ interrupts = <61 2>;
interrupt-parent = <&mpic>;
};
tlu@15000 {
compatible = "fsl,mpc8572-tlu", "fsl_tlu";
reg = <0x15000 0x1000>;
- interupts = <75 2>;
+ interrupts = <75 2>;
interrupt-parent = <&mpic>;
};
};
diff --git a/arch/powerpc/boot/dts/xpedite5301.dts b/arch/powerpc/boot/dts/xpedite5301.dts
index 53c1c6a..04cb410 100644
--- a/arch/powerpc/boot/dts/xpedite5301.dts
+++ b/arch/powerpc/boot/dts/xpedite5301.dts
@@ -547,14 +547,14 @@
tlu@2f000 {
compatible = "fsl,mpc8572-tlu", "fsl_tlu";
reg = <0x2f000 0x1000>;
- interupts = <61 2 >;
+ interrupts = <61 2>;
interrupt-parent = <&mpic>;
};
tlu@15000 {
compatible = "fsl,mpc8572-tlu", "fsl_tlu";
reg = <0x15000 0x1000>;
- interupts = <75 2>;
+ interrupts = <75 2>;
interrupt-parent = <&mpic>;
};
};
diff --git a/arch/powerpc/boot/dts/xpedite5330.dts b/arch/powerpc/boot/dts/xpedite5330.dts
index 2152259..73f8620 100644
--- a/arch/powerpc/boot/dts/xpedite5330.dts
+++ b/arch/powerpc/boot/dts/xpedite5330.dts
@@ -583,14 +583,14 @@
tlu@2f000 {
compatible = "fsl,mpc8572-tlu", "fsl_tlu";
reg = <0x2f000 0x1000>;
- interupts = <61 2 >;
+ interrupts = <61 2>;
interrupt-parent = <&mpic>;
};
tlu@15000 {
compatible = "fsl,mpc8572-tlu", "fsl_tlu";
reg = <0x15000 0x1000>;
- interupts = <75 2>;
+ interrupts = <75 2>;
interrupt-parent = <&mpic>;
};
};
diff --git a/arch/powerpc/boot/dts/xpedite5370.dts b/arch/powerpc/boot/dts/xpedite5370.dts
index 11dbda1..cd0ea2b 100644
--- a/arch/powerpc/boot/dts/xpedite5370.dts
+++ b/arch/powerpc/boot/dts/xpedite5370.dts
@@ -545,14 +545,14 @@
tlu@2f000 {
compatible = "fsl,mpc8572-tlu", "fsl_tlu";
reg = <0x2f000 0x1000>;
- interupts = <61 2 >;
+ interrupts = <61 2>;
interrupt-parent = <&mpic>;
};
tlu@15000 {
compatible = "fsl,mpc8572-tlu", "fsl_tlu";
reg = <0x15000 0x1000>;
- interupts = <75 2>;
+ interrupts = <75 2>;
interrupt-parent = <&mpic>;
};
};
--
1.8.5.rc0
^ permalink raw reply related
* Re: [PATCH V2] powerpc/85xx: Merge 85xx/p1023_defconfig into mpc85xx_smp_defconfig and mpc85xx_defconfig
From: Kumar Gala @ 2013-11-12 16:27 UTC (permalink / raw)
To: Lijun Pan; +Cc: linuxppc-dev
In-Reply-To: <1384197913-24610-1-git-send-email-Lijun.Pan@freescale.com>
On Nov 11, 2013, at 1:25 PM, Lijun Pan <Lijun.Pan@freescale.com> wrote:
> mpc85xx_smp_defconfig and mpc85xx_defconfig already have =
CONFIG_P1023RDS=3Dy.
> Merge CONFIG_P1023RDB=3Dy and other relevant configurations into =
mpc85xx_smp_defconfig and mpc85_defconfig.
>=20
> Signed-off-by: Lijun Pan <Lijun.Pan@freescale.com>
> ---
> arch/powerpc/configs/85xx/p1023_defconfig | 188 =
----------------------------
> arch/powerpc/configs/mpc85xx_defconfig | 18 +++
> arch/powerpc/configs/mpc85xx_smp_defconfig | 17 +++
> 3 files changed, 35 insertions(+), 188 deletions(-)
> delete mode 100644 arch/powerpc/configs/85xx/p1023_defconfig
How much of the changes to mpc85xx_defconfig & mpc85xx_smp_defconfig are =
based on just updating them vs changes for p1023?
Can we do this as two patches. One that updates mpc85xx_defconfig & =
mpc85xx_smp_defconfig and one that makes the p1023 changes. That is =
much easier to review as well.
- k=
^ permalink raw reply
* Re: [PATCH 00/11] Consolidate asm/fixmap.h files
From: Mark Salter @ 2013-11-12 15:55 UTC (permalink / raw)
To: monstr
Cc: linux-arch, linux-mips, James Hogan, Russell King, Arnd Bergmann,
linux-hexagon, linux-kernel, Ralf Baechle, Richard Kuo,
microblaze-uclinux, Paul Mackerras, linuxppc-dev, linux-metag,
linux-arm-kernel
In-Reply-To: <52824BBC.9020401@monstr.eu>
On Tue, 2013-11-12 at 16:39 +0100, Michal Simek wrote:
> On 11/12/2013 02:22 PM, Mark Salter wrote:
> >
> > arch/arm/include/asm/fixmap.h | 25 ++------
> > arch/hexagon/include/asm/fixmap.h | 40 +------------
> > arch/metag/include/asm/fixmap.h | 32 +----------
> > arch/microblaze/include/asm/fixmap.h | 44 +-------------
> > arch/mips/include/asm/fixmap.h | 33 +----------
> > arch/powerpc/include/asm/fixmap.h | 44 +-------------
> > arch/sh/include/asm/fixmap.h | 39 +------------
> > arch/tile/include/asm/fixmap.h | 33 +----------
> > arch/um/include/asm/fixmap.h | 40 +------------
> > arch/x86/include/asm/fixmap.h | 59 +------------------
> > include/asm-generic/fixmap.h | 107 +++++++++++++++++++++++++++++++++++
> > 11 files changed, 125 insertions(+), 371 deletions(-)
> > create mode 100644 include/asm-generic/fixmap.h
>
> Any repo/branch with all these patches will be helpful.
https://github.com/mosalter/linux (fixmap branch)
^ permalink raw reply
* Re: [PATCH 00/11] Consolidate asm/fixmap.h files
From: Michal Simek @ 2013-11-12 15:39 UTC (permalink / raw)
To: Mark Salter
Cc: linux-arch, linux-mips, James Hogan, Russell King, Arnd Bergmann,
linux-hexagon, linux-kernel, Ralf Baechle, Richard Kuo,
microblaze-uclinux, Paul Mackerras, linuxppc-dev, linux-metag,
linux-arm-kernel
In-Reply-To: <1384262545-20875-1-git-send-email-msalter@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 2135 bytes --]
On 11/12/2013 02:22 PM, Mark Salter wrote:
> Many architectures provide an asm/fixmap.h which defines support for
> compile-time 'special' virtual mappings which need to be made before
> paging_init() has run. This suport is also used for early ioremap
> on x86. Much of this support is identical across the architectures.
> This patch consolidates all of the common bits into asm-generic/fixmap.h
> which is intended to be included from arch/*/include/asm/fixmap.h.
>
> This has been compiled on x86, arm, powerpc, and sh, but tested
> on x86 only.
>
> Mark Salter (11):
> Add generic fixmap.h
> x86: use generic fixmap.h
> arm: use generic fixmap.h
> hexagon: use generic fixmap.h
> metag: use generic fixmap.h
> microblaze: use generic fixmap.h
> mips: use generic fixmap.h
> powerpc: use generic fixmap.h
> sh: use generic fixmap.h
> tile: use generic fixmap.h
> um: use generic fixmap.h
>
> arch/arm/include/asm/fixmap.h | 25 ++------
> arch/hexagon/include/asm/fixmap.h | 40 +------------
> arch/metag/include/asm/fixmap.h | 32 +----------
> arch/microblaze/include/asm/fixmap.h | 44 +-------------
> arch/mips/include/asm/fixmap.h | 33 +----------
> arch/powerpc/include/asm/fixmap.h | 44 +-------------
> arch/sh/include/asm/fixmap.h | 39 +------------
> arch/tile/include/asm/fixmap.h | 33 +----------
> arch/um/include/asm/fixmap.h | 40 +------------
> arch/x86/include/asm/fixmap.h | 59 +------------------
> include/asm-generic/fixmap.h | 107 +++++++++++++++++++++++++++++++++++
> 11 files changed, 125 insertions(+), 371 deletions(-)
> create mode 100644 include/asm-generic/fixmap.h
Any repo/branch with all these patches will be helpful.
Thanks,
Michal
--
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/
Maintainer of Linux kernel - Xilinx Zynq ARM architecture
Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 263 bytes --]
^ permalink raw reply
* Re: [PATCH 01/11] Add generic fixmap.h
From: Arnd Bergmann @ 2013-11-12 13:46 UTC (permalink / raw)
To: Mark Salter
Cc: linux-arch, linux-mips, Michal Simek, James Hogan, Russell King,
linux-hexagon, linux-kernel, Ralf Baechle, Richard Kuo,
microblaze-uclinux, Paul Mackerras, linuxppc-dev, linux-metag,
linux-arm-kernel
In-Reply-To: <1384262545-20875-2-git-send-email-msalter@redhat.com>
On Tuesday 12 November 2013, Mark Salter wrote:
> Many architectures provide an asm/fixmap.h which defines support for
> compile-time 'special' virtual mappings which need to be made before
> paging_init() has run. This suport is also used for early ioremap
> on x86. Much of this support is identical across the architectures.
> This patch consolidates all of the common bits into asm-generic/fixmap.h
> which is intended to be included from arch/*/include/asm/fixmap.h.
Good idea,
Acked-by: Arnd Bergmann <arnd@arndb.de>
On Tuesday 12 November 2013, Mark Salter wrote:
> +static __always_inline unsigned long fix_to_virt(const unsigned int idx)
> +{
> + /*
> + * this branch gets completely eliminated after inlining,
> + * except when someone tries to use fixaddr indices in an
> + * illegal way. (such as mixing up address types or using
> + * out-of-range indices).
> + *
> + * If it doesn't get removed, the linker will complain
> + * loudly with a reasonably clear error message..
> + */
> + if (idx >= __end_of_fixed_addresses)
> + __this_fixmap_does_not_exist();
> +
You might be able to turn this into the more readable BUILD_BUG_ON().
Arnd
^ permalink raw reply
* [PATCH 01/11] Add generic fixmap.h
From: Mark Salter @ 2013-11-12 13:22 UTC (permalink / raw)
To: linux-kernel
Cc: linux-arch, linux-mips, Michal Simek, James Hogan, Russell King,
Arnd Bergmann, linux-hexagon, microblaze-uclinux, Ralf Baechle,
Richard Kuo, Mark Salter, Paul Mackerras, linuxppc-dev,
linux-metag, linux-arm-kernel
In-Reply-To: <1384262545-20875-1-git-send-email-msalter@redhat.com>
Many architectures provide an asm/fixmap.h which defines support for
compile-time 'special' virtual mappings which need to be made before
paging_init() has run. This suport is also used for early ioremap
on x86. Much of this support is identical across the architectures.
This patch consolidates all of the common bits into asm-generic/fixmap.h
which is intended to be included from arch/*/include/asm/fixmap.h.
Signed-off-by: Mark Salter <msalter@redhat.com>
CC: Arnd Bergmann <arnd@arndb.de>
CC: linux-arch@vger.kernel.org
CC: Russell King <linux@arm.linux.org.uk>
CC: linux-arm-kernel@lists.infradead.org
CC: Richard Kuo <rkuo@codeaurora.org>
CC: linux-hexagon@vger.kernel.org
CC: James Hogan <james.hogan@imgtec.com>
CC: linux-metag@vger.kernel.org
CC: Michal Simek <monstr@monstr.eu>
CC: microblaze-uclinux@itee.uq.edu.au
CC: Ralf Baechle <ralf@linux-mips.org>
CC: linux-mips@linux-mips.org
CC: Benjamin Herrenschmidt <benh@kernel.crashing.org>
CC: Paul Mackerras <paulus@samba.org>
CC: linuxppc-dev@lists.ozlabs.org
---
include/asm-generic/fixmap.h | 107 +++++++++++++++++++++++++++++++++++++++++++
1 file changed, 107 insertions(+)
create mode 100644 include/asm-generic/fixmap.h
diff --git a/include/asm-generic/fixmap.h b/include/asm-generic/fixmap.h
new file mode 100644
index 0000000..8d453db
--- /dev/null
+++ b/include/asm-generic/fixmap.h
@@ -0,0 +1,107 @@
+/*
+ * fixmap.h: compile-time virtual memory allocation
+ *
+ * This file is subject to the terms and conditions of the GNU General Public
+ * License. See the file "COPYING" in the main directory of this archive
+ * for more details.
+ *
+ * Copyright (C) 1998 Ingo Molnar
+ *
+ * Support of BIGMEM added by Gerhard Wichert, Siemens AG, July 1999
+ * x86_32 and x86_64 integration by Gustavo F. Padovan, February 2009
+ */
+
+#ifndef __ASM_GENERIC_FIXMAP_H
+#define __ASM_GENERIC_FIXMAP_H
+
+#define __fix_to_virt(x) (FIXADDR_TOP - ((x) << PAGE_SHIFT))
+#define __virt_to_fix(x) ((FIXADDR_TOP - ((x)&PAGE_MASK)) >> PAGE_SHIFT)
+
+#ifndef __ASSEMBLY__
+extern void __this_fixmap_does_not_exist(void);
+
+/*
+ * 'index to address' translation. If anyone tries to use the idx
+ * directly without translation, we catch the bug with a NULL-deference
+ * kernel oops. Illegal ranges of incoming indices are caught too.
+ */
+static __always_inline unsigned long fix_to_virt(const unsigned int idx)
+{
+ /*
+ * this branch gets completely eliminated after inlining,
+ * except when someone tries to use fixaddr indices in an
+ * illegal way. (such as mixing up address types or using
+ * out-of-range indices).
+ *
+ * If it doesn't get removed, the linker will complain
+ * loudly with a reasonably clear error message..
+ */
+ if (idx >= __end_of_fixed_addresses)
+ __this_fixmap_does_not_exist();
+
+ return __fix_to_virt(idx);
+}
+
+static inline unsigned long virt_to_fix(const unsigned long vaddr)
+{
+ BUG_ON(vaddr >= FIXADDR_TOP || vaddr < FIXADDR_START);
+ return __virt_to_fix(vaddr);
+}
+
+/*
+ * Provide some reasonable defaults for page flags.
+ * Not all architectures use all of these different types and some
+ * architectures use different names.
+ */
+#ifndef FIXMAP_PAGE_NORMAL
+#define FIXMAP_PAGE_NORMAL PAGE_KERNEL
+#endif
+#ifndef FIXMAP_PAGE_NOCACHE
+#define FIXMAP_PAGE_NOCACHE PAGE_KERNEL_NOCACHE
+#endif
+#ifndef FIXMAP_PAGE_IO
+#define FIXMAP_PAGE_IO PAGE_KERNEL_IO
+#endif
+#ifndef FIXMAP_PAGE_CLEAR
+#define FIXMAP_PAGE_CLEAR __pgprot(0)
+#endif
+
+#ifndef set_fixmap
+#define set_fixmap(idx, phys) \
+ __set_fixmap(idx, phys, FIXMAP_PAGE_NORMAL)
+#endif
+
+#ifndef clear_fixmap
+#define clear_fixmap(idx) \
+ __set_fixmap(idx, 0, FIXMAP_PAGE_CLEAR)
+#endif
+
+/* Return an pointer with offset calculated */
+#define __set_fixmap_offset(idx, phys, flags) \
+({ \
+ unsigned long addr; \
+ __set_fixmap(idx, phys, flags); \
+ addr = fix_to_virt(idx) + ((phys) & (PAGE_SIZE - 1)); \
+ addr; \
+})
+
+#define set_fixmap_offset(idx, phys) \
+ __set_fixmap_offset(idx, phys, FIXMAP_PAGE_NORMAL)
+
+/*
+ * Some hardware wants to get fixmapped without caching.
+ */
+#define set_fixmap_nocache(idx, phys) \
+ __set_fixmap(idx, phys, FIXMAP_PAGE_NOCACHE)
+
+#define set_fixmap_offset_nocache(idx, phys) \
+ __set_fixmap_offset(idx, phys, FIXMAP_PAGE_NOCACHE)
+
+/*
+ * Some fixmaps are for IO
+ */
+#define set_fixmap_io(idx, phys) \
+ __set_fixmap(idx, phys, FIXMAP_PAGE_IO)
+
+#endif /* __ASSEMBLY__ */
+#endif /* __ASM_GENERIC_FIXMAP_H */
--
1.8.3.1
^ permalink raw reply related
* [PATCH 00/11] Consolidate asm/fixmap.h files
From: Mark Salter @ 2013-11-12 13:22 UTC (permalink / raw)
To: linux-kernel
Cc: linux-arch, linux-mips, Michal Simek, James Hogan, Russell King,
Arnd Bergmann, linux-hexagon, microblaze-uclinux, Ralf Baechle,
Richard Kuo, Mark Salter, Paul Mackerras, linuxppc-dev,
linux-metag, linux-arm-kernel
Many architectures provide an asm/fixmap.h which defines support for
compile-time 'special' virtual mappings which need to be made before
paging_init() has run. This suport is also used for early ioremap
on x86. Much of this support is identical across the architectures.
This patch consolidates all of the common bits into asm-generic/fixmap.h
which is intended to be included from arch/*/include/asm/fixmap.h.
This has been compiled on x86, arm, powerpc, and sh, but tested
on x86 only.
Mark Salter (11):
Add generic fixmap.h
x86: use generic fixmap.h
arm: use generic fixmap.h
hexagon: use generic fixmap.h
metag: use generic fixmap.h
microblaze: use generic fixmap.h
mips: use generic fixmap.h
powerpc: use generic fixmap.h
sh: use generic fixmap.h
tile: use generic fixmap.h
um: use generic fixmap.h
arch/arm/include/asm/fixmap.h | 25 ++------
arch/hexagon/include/asm/fixmap.h | 40 +------------
arch/metag/include/asm/fixmap.h | 32 +----------
arch/microblaze/include/asm/fixmap.h | 44 +-------------
arch/mips/include/asm/fixmap.h | 33 +----------
arch/powerpc/include/asm/fixmap.h | 44 +-------------
arch/sh/include/asm/fixmap.h | 39 +------------
arch/tile/include/asm/fixmap.h | 33 +----------
arch/um/include/asm/fixmap.h | 40 +------------
arch/x86/include/asm/fixmap.h | 59 +------------------
include/asm-generic/fixmap.h | 107 +++++++++++++++++++++++++++++++++++
11 files changed, 125 insertions(+), 371 deletions(-)
create mode 100644 include/asm-generic/fixmap.h
--
1.8.3.1
^ permalink raw reply
* [PATCH 08/11] powerpc: use generic fixmap.h
From: Mark Salter @ 2013-11-12 13:22 UTC (permalink / raw)
To: linux-kernel; +Cc: Paul Mackerras, linuxppc-dev, Mark Salter
In-Reply-To: <1384262545-20875-1-git-send-email-msalter@redhat.com>
Signed-off-by: Mark Salter <msalter@redhat.com>
CC: Benjamin Herrenschmidt <benh@kernel.crashing.org>
CC: Paul Mackerras <paulus@samba.org>
CC: linuxppc-dev@lists.ozlabs.org
---
arch/powerpc/include/asm/fixmap.h | 44 ++-------------------------------------
1 file changed, 2 insertions(+), 42 deletions(-)
diff --git a/arch/powerpc/include/asm/fixmap.h b/arch/powerpc/include/asm/fixmap.h
index 5c2c023..90f604b 100644
--- a/arch/powerpc/include/asm/fixmap.h
+++ b/arch/powerpc/include/asm/fixmap.h
@@ -58,52 +58,12 @@ enum fixed_addresses {
extern void __set_fixmap (enum fixed_addresses idx,
phys_addr_t phys, pgprot_t flags);
-#define set_fixmap(idx, phys) \
- __set_fixmap(idx, phys, PAGE_KERNEL)
-/*
- * Some hardware wants to get fixmapped without caching.
- */
-#define set_fixmap_nocache(idx, phys) \
- __set_fixmap(idx, phys, PAGE_KERNEL_NCG)
-
-#define clear_fixmap(idx) \
- __set_fixmap(idx, 0, __pgprot(0))
-
#define __FIXADDR_SIZE (__end_of_fixed_addresses << PAGE_SHIFT)
#define FIXADDR_START (FIXADDR_TOP - __FIXADDR_SIZE)
-#define __fix_to_virt(x) (FIXADDR_TOP - ((x) << PAGE_SHIFT))
-#define __virt_to_fix(x) ((FIXADDR_TOP - ((x)&PAGE_MASK)) >> PAGE_SHIFT)
-
-extern void __this_fixmap_does_not_exist(void);
-
-/*
- * 'index to address' translation. If anyone tries to use the idx
- * directly without tranlation, we catch the bug with a NULL-deference
- * kernel oops. Illegal ranges of incoming indices are caught too.
- */
-static __always_inline unsigned long fix_to_virt(const unsigned int idx)
-{
- /*
- * this branch gets completely eliminated after inlining,
- * except when someone tries to use fixaddr indices in an
- * illegal way. (such as mixing up address types or using
- * out-of-range indices).
- *
- * If it doesn't get removed, the linker will complain
- * loudly with a reasonably clear error message..
- */
- if (idx >= __end_of_fixed_addresses)
- __this_fixmap_does_not_exist();
-
- return __fix_to_virt(idx);
-}
+#define FIXMAP_PAGE_NOCACHE PAGE_KERNEL_NCG
-static inline unsigned long virt_to_fix(const unsigned long vaddr)
-{
- BUG_ON(vaddr >= FIXADDR_TOP || vaddr < FIXADDR_START);
- return __virt_to_fix(vaddr);
-}
+#include <asm-generic/fixmap.h>
#endif /* !__ASSEMBLY__ */
#endif
--
1.8.3.1
^ permalink raw reply related
* Re: [PATCH] powerpc: book3s: PR: Enable Little Endian PR guest
From: Alexander Graf @ 2013-11-12 12:37 UTC (permalink / raw)
To: Aneesh Kumar K.V
Cc: kvm@vger.kernel.org, kvm-ppc@vger.kernel.org, paulus@samba.org,
Aneesh Kumar K.V, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <1384178898-24673-1-git-send-email-aneesh.kumar@linux.vnet.ibm.com>
Am 11.11.2013 um 09:08 schrieb "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.i=
bm.com>:
> From: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
>=20
> This patch make sure we inherit the LE bit correctly in different case
> so that we can run Little Endian distro in PR mode
>=20
> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
This is not how real hardware works, is it? Could you please point me to the=
bits in the ISA that indicate that we should preserve the LE bit anywhere? :=
)
Alex
> ---
>=20
> This patch depends on the below two changes
> 1) [PATCH v5 0/6] KVM: PPC: Book3S: MMIO support for Little Endian guests=
(kvm-ppc)
> http://mid.gmane.org/1383672128-26795-1-git-send-email-clg@fr.ibm.c=
om
> 2) [PATCH] powerpc: book3s: kvm: Use the saved dsisr and dar values
> http://mid.gmane.org/1384178577-23721-1-git-send-email-aneesh.kumar@=
linux.vnet.ibm.com
>=20
> arch/powerpc/kvm/book3s_64_mmu.c | 2 +-
> arch/powerpc/kvm/book3s_pr.c | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>=20
> diff --git a/arch/powerpc/kvm/book3s_64_mmu.c b/arch/powerpc/kvm/book3s_64=
_mmu.c
> index 83da1f8..d339096 100644
> --- a/arch/powerpc/kvm/book3s_64_mmu.c
> +++ b/arch/powerpc/kvm/book3s_64_mmu.c
> @@ -38,7 +38,7 @@
>=20
> static void kvmppc_mmu_book3s_64_reset_msr(struct kvm_vcpu *vcpu)
> {
> - kvmppc_set_msr(vcpu, MSR_SF);
> + kvmppc_set_msr(vcpu, MSR_SF | (vcpu->arch.shared->msr & MSR_LE));
> }
>=20
> static struct kvmppc_slb *kvmppc_mmu_book3s_64_find_slbe(
> diff --git a/arch/powerpc/kvm/book3s_pr.c b/arch/powerpc/kvm/book3s_pr.c
> index a7fe87a..cf9362c 100644
> --- a/arch/powerpc/kvm/book3s_pr.c
> +++ b/arch/powerpc/kvm/book3s_pr.c
> @@ -226,7 +226,7 @@ static void kvmppc_recalc_shadow_msr(struct kvm_vcpu *=
vcpu)
> ulong smsr =3D vcpu->arch.shared->msr;
>=20
> /* Guest MSR values */
> - smsr &=3D MSR_FE0 | MSR_FE1 | MSR_SF | MSR_SE | MSR_BE;
> + smsr &=3D MSR_FE0 | MSR_FE1 | MSR_SF | MSR_SE | MSR_BE | MSR_LE;
> /* Process MSR values */
> smsr |=3D MSR_ME | MSR_RI | MSR_IR | MSR_DR | MSR_PR | MSR_EE;
> /* External providers the guest reserved */
> --=20
> 1.8.3.2
>=20
> --
> To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* RE: [PATCH 4/4] phylib: Add of_phy_attach
From: Shaohui Xie @ 2013-11-12 12:32 UTC (permalink / raw)
To: shh.xie@gmail.com, linuxppc-dev@lists.ozlabs.org,
linux-kernel@vger.kernel.org
Cc: f.fainelli@gmail.com, netdev@vger.kernel.org, Shruti Kanetkar,
jg1.han@samsung.com, michal.simek@xilinx.com,
peppe.cavallaro@st.com, davem@davemloft.net,
Madalin-Cristian Bucur
In-Reply-To: <1384168100-3046-1-git-send-email-shh.xie@gmail.com>
Added more people and list.
Best Regards,=20
Shaohui Xie
> -----Original Message-----
> From: shh.xie@gmail.com [mailto:shh.xie@gmail.com]
> Sent: Monday, November 11, 2013 7:08 PM
> To: linuxppc-dev@lists.ozlabs.org; linux-kernel@vger.kernel.org
> Cc: Bucur Madalin-Cristian-B32716; Kanetkar Shruti-B44454; Xie Shaohui-B2=
1989
> Subject: [PATCH 4/4] phylib: Add of_phy_attach
>=20
> From: Andy Fleming
>=20
> 10G PHYs don't currently support running the state machine, which is impl=
icitly
> setup via of_phy_connect(). Therefore, it is necessary to implement an OF
> version of phy_attach(), which does everything except start the state mac=
hine.
>=20
> Signed-off-by: Andy Fleming
> Signed-off-by: Shaohui Xie <Shaohui.Xie@freescale.com>
> ---
> drivers/of/of_mdio.c | 22 ++++++++++++++++++++--
> include/linux/of_mdio.h | 8 ++++++++
> 2 files changed, 28 insertions(+), 2 deletions(-)
>=20
> diff --git a/drivers/of/of_mdio.c b/drivers/of/of_mdio.c index d5a57a9..a=
748274
> 100644
> --- a/drivers/of/of_mdio.c
> +++ b/drivers/of/of_mdio.c
> @@ -221,8 +221,7 @@ EXPORT_SYMBOL(of_phy_connect);
> * not call this function from new drivers.
> */
> struct phy_device *of_phy_connect_fixed_link(struct net_device *dev,
> - void (*hndlr)(struct net_device *),
> - phy_interface_t iface)
> + void (*hndlr)(struct net_device *), phy_interface_t iface)
> {
> struct device_node *net_np;
> char bus_id[MII_BUS_ID_SIZE + 3];
> @@ -247,3 +246,22 @@ struct phy_device *of_phy_connect_fixed_link(struct
> net_device *dev,
> return IS_ERR(phy) ? NULL : phy;
> }
> EXPORT_SYMBOL(of_phy_connect_fixed_link);
> +
> +/**
> + * of_phy_attach - Attach to a PHY without starting the state machine
> + * @dev: pointer to net_device claiming the phy
> + * @phy_np: Node pointer for the PHY
> + * @flags: flags to pass to the PHY
> + * @iface: PHY data interface type
> + */
> +struct phy_device *of_phy_attach(struct net_device *dev,
> + struct device_node *phy_np, u32 flags, phy_interface_t iface) {
> + struct phy_device *phy =3D of_phy_find_device(phy_np);
> +
> + if (!phy)
> + return NULL;
> +
> + return phy_attach_direct(dev, phy, flags, iface) ? NULL : phy; }
> +EXPORT_SYMBOL(of_phy_attach);
> diff --git a/include/linux/of_mdio.h b/include/linux/of_mdio.h index
> 8163107..dcda44d 100644
> --- a/include/linux/of_mdio.h
> +++ b/include/linux/of_mdio.h
> @@ -19,6 +19,8 @@ extern struct phy_device *of_phy_connect(struct net_dev=
ice
> *dev,
> struct device_node *phy_np,
> void (*hndlr)(struct net_device *),
> u32 flags, phy_interface_t iface);
> +extern struct phy_device *of_phy_attach(struct net_device *dev,
> + struct device_node *phy_np, u32 flags, phy_interface_t iface);
> extern struct phy_device *of_phy_connect_fixed_link(struct net_device *d=
ev,
> void (*hndlr)(struct net_device *),
> phy_interface_t iface);
> @@ -44,6 +46,12 @@ static inline struct phy_device *of_phy_connect(struct
> net_device *dev,
> return NULL;
> }
>=20
> +static inline struct phy_device *of_phy_attach(struct net_device *dev,
> + struct device_node *phy_np, u32 flags, phy_interface_t iface) {
> + return NULL;
> +}
> +
> static inline struct phy_device *of_phy_connect_fixed_link(struct net_de=
vice
> *dev,
> void (*hndlr)(struct net_device
> *),
> phy_interface_t iface)
> --
> 1.8.4.1
^ permalink raw reply
* RE: [PATCH 3/4] phylib: Support attaching to gen10g_driver
From: Shaohui Xie @ 2013-11-12 12:31 UTC (permalink / raw)
To: shh.xie@gmail.com, linuxppc-dev@lists.ozlabs.org,
linux-kernel@vger.kernel.org
Cc: f.fainelli@gmail.com, netdev@vger.kernel.org, Shruti Kanetkar,
jg1.han@samsung.com, michal.simek@xilinx.com,
peppe.cavallaro@st.com, davem@davemloft.net,
Madalin-Cristian Bucur
In-Reply-To: <1384168079-3002-1-git-send-email-shh.xie@gmail.com>
Added more people and list.
Best Regards,=20
Shaohui Xie
> -----Original Message-----
> From: shh.xie@gmail.com [mailto:shh.xie@gmail.com]
> Sent: Monday, November 11, 2013 7:08 PM
> To: linuxppc-dev@lists.ozlabs.org; linux-kernel@vger.kernel.org
> Cc: Bucur Madalin-Cristian-B32716; Kanetkar Shruti-B44454; Xie Shaohui-B2=
1989
> Subject: [PATCH 3/4] phylib: Support attaching to gen10g_driver
>=20
> From: Andy Fleming
>=20
> phy_attach_direct() may now attach to a generic 10G driver. It can also b=
e used
> exactly as phy_connect_direct(), which will be useful when using of_mdio,=
as
> phy_connect (and therefore of_phy_connect) start the PHY state machine, w=
hich is
> currently irrelevant for 10G PHYs.
>=20
> Signed-off-by: Andy Fleming
> Signed-off-by: Shaohui Xie <Shaohui.Xie@freescale.com>
> ---
> drivers/net/phy/phy_device.c | 23 +++++++++++------------
> include/linux/phy.h | 2 ++
> 2 files changed, 13 insertions(+), 12 deletions(-)
>=20
> diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c =
index
> 30bf2d5..f51ea2e 100644
> --- a/drivers/net/phy/phy_device.c
> +++ b/drivers/net/phy/phy_device.c
> @@ -55,15 +55,13 @@ static void phy_device_release(struct device *dev) }
>=20
> static struct phy_driver genphy_driver;
> +static struct phy_driver gen10g_driver;
> extern int mdio_bus_init(void);
> extern void mdio_bus_exit(void);
>=20
> static LIST_HEAD(phy_fixup_list);
> static DEFINE_MUTEX(phy_fixup_lock);
>=20
> -static int phy_attach_direct(struct net_device *dev, struct phy_device *=
phydev,
> - u32 flags, phy_interface_t interface);
> -
> /*
> * Creates a new phy_fixup and adds it to the list
> * @bus_id: A string which matches phydev->dev.bus_id (or PHY_ANY_ID) @@=
-
> 521,12 +519,12 @@ int phy_init_hw(struct phy_device *phydev)
> *
> * Description: Called by drivers to attach to a particular PHY
> * device. The phy_device is found, and properly hooked up
> - * to the phy_driver. If no driver is attached, then the
> - * genphy_driver is used. The phy_device is given a ptr to
> + * to the phy_driver. If no driver is attached, then a
> + * generic driver is used. The phy_device is given a ptr to
> * the attaching device, and given a callback for link status
> * change. The phy_device is returned to the attaching driver.
> */
> -static int phy_attach_direct(struct net_device *dev, struct phy_device *=
phydev,
> +int phy_attach_direct(struct net_device *dev, struct phy_device
> +*phydev,
> u32 flags, phy_interface_t interface) {
> struct device *d =3D &phydev->dev;
> @@ -535,12 +533,10 @@ static int phy_attach_direct(struct net_device *dev=
,
> struct phy_device *phydev,
> /* Assume that if there is no driver, that it doesn't
> * exist, and we should use the genphy driver. */
> if (NULL =3D=3D d->driver) {
> - if (phydev->is_c45) {
> - pr_err("No driver for phy %x\n", phydev->phy_id);
> - return -ENODEV;
> - }
> -
> - d->driver =3D &genphy_driver.driver;
> + if (phydev->is_c45)
> + d->driver =3D &gen10g_driver.driver;
> + else
> + d->driver =3D &genphy_driver.driver;
>=20
> err =3D d->driver->probe(d);
> if (err >=3D 0)
> @@ -573,6 +569,7 @@ static int phy_attach_direct(struct net_device *dev, =
struct
> phy_device *phydev,
>=20
> return err;
> }
> +EXPORT_SYMBOL(phy_attach_direct);
>=20
> /**
> * phy_attach - attach a network device to a particular PHY device @@ -6=
23,6
> +620,8 @@ void phy_detach(struct phy_device *phydev)
> * real driver could be loaded */
> if (phydev->dev.driver =3D=3D &genphy_driver.driver)
> device_release_driver(&phydev->dev);
> + else if (phydev->dev.driver =3D=3D &gen10g_driver.driver)
> + device_release_driver(&phydev->dev);
> }
> EXPORT_SYMBOL(phy_detach);
>=20
> diff --git a/include/linux/phy.h b/include/linux/phy.h index f864004..f36=
a6f6
> 100644
> --- a/include/linux/phy.h
> +++ b/include/linux/phy.h
> @@ -575,6 +575,8 @@ int phy_init_hw(struct phy_device *phydev); struct
> phy_device * phy_attach(struct net_device *dev,
> const char *bus_id, phy_interface_t interface); struct phy_device
> *phy_find_first(struct mii_bus *bus);
> +int phy_attach_direct(struct net_device *dev, struct phy_device *phydev,
> + u32 flags, phy_interface_t interface);
> int phy_connect_direct(struct net_device *dev, struct phy_device *phydev=
,
> void (*handler)(struct net_device *),
> phy_interface_t interface);
> --
> 1.8.4.1
^ permalink raw reply
* RE: [PATCH 2/4] phylib: Add generic 10G driver
From: Shaohui Xie @ 2013-11-12 12:31 UTC (permalink / raw)
To: shh.xie@gmail.com, linuxppc-dev@lists.ozlabs.org,
linux-kernel@vger.kernel.org
Cc: f.fainelli@gmail.com, netdev@vger.kernel.org, Shruti Kanetkar,
jg1.han@samsung.com, michal.simek@xilinx.com,
peppe.cavallaro@st.com, davem@davemloft.net,
Madalin-Cristian Bucur
In-Reply-To: <1384168049-2899-1-git-send-email-shh.xie@gmail.com>
Added more people and list.
Best Regards,=20
Shaohui Xie
> -----Original Message-----
> From: shh.xie@gmail.com [mailto:shh.xie@gmail.com]
> Sent: Monday, November 11, 2013 7:07 PM
> To: linuxppc-dev@lists.ozlabs.org; linux-kernel@vger.kernel.org
> Cc: Bucur Madalin-Cristian-B32716; Kanetkar Shruti-B44454; Xie Shaohui-B2=
1989
> Subject: [PATCH 2/4] phylib: Add generic 10G driver
>=20
> From: Andy Fleming
>=20
> Very incomplete, but will allow for binding an ethernet controller to it.
>=20
> Also, Add XGMII interface type
>=20
> Signed-off-by: Andy Fleming
> Signed-off-by: Shaohui Xie <Shaohui.Xie@freescale.com>
> ---
> drivers/net/phy/phy_device.c | 101 +++++++++++++++++++++++++++++++++++++=
+++++-
> include/linux/phy.h | 1 +
> 2 files changed, 101 insertions(+), 1 deletion(-)
>=20
> diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c =
index
> 74630e9..30bf2d5 100644
> --- a/drivers/net/phy/phy_device.c
> +++ b/drivers/net/phy/phy_device.c
> @@ -32,6 +32,7 @@
> #include <linux/module.h>
> #include <linux/mii.h>
> #include <linux/ethtool.h>
> +#include <linux/mdio.h>
> #include <linux/phy.h>
>=20
> #include <asm/io.h>
> @@ -689,6 +690,13 @@ static int genphy_config_advert(struct phy_device *p=
hydev)
> return changed;
> }
>=20
> +int gen10g_config_advert(struct phy_device *dev) {
> + return 0;
> +}
> +EXPORT_SYMBOL(gen10g_config_advert);
> +
> +
> /**
> * genphy_setup_forced - configures/forces speed/duplex from @phydev
> * @phydev: target phy_device struct
> @@ -742,6 +750,12 @@ int genphy_restart_aneg(struct phy_device *phydev) =
}
> EXPORT_SYMBOL(genphy_restart_aneg);
>=20
> +int gen10g_restart_aneg(struct phy_device *phydev) {
> + return 0;
> +}
> +EXPORT_SYMBOL(gen10g_restart_aneg);
> +
>=20
> /**
> * genphy_config_aneg - restart auto-negotiation or write BMCR @@ -784,6
> +798,13 @@ int genphy_config_aneg(struct phy_device *phydev) }
> EXPORT_SYMBOL(genphy_config_aneg);
>=20
> +int gen10g_config_aneg(struct phy_device *phydev) {
> + return 0;
> +}
> +EXPORT_SYMBOL(gen10g_config_aneg);
> +
> +
> /**
> * genphy_update_link - update link status in @phydev
> * @phydev: target phy_device struct
> @@ -913,6 +934,35 @@ int genphy_read_status(struct phy_device *phydev) }
> EXPORT_SYMBOL(genphy_read_status);
>=20
> +int gen10g_read_status(struct phy_device *phydev) {
> + int devad, reg;
> + u32 mmd_mask =3D phydev->c45_ids.devices_in_package;
> +
> + phydev->link =3D 1;
> +
> + /* For now just lie and say it's 10G all the time */
> + phydev->speed =3D 10000;
> + phydev->duplex =3D DUPLEX_FULL;
> +
> + for (devad =3D 0; mmd_mask; devad++, mmd_mask =3D mmd_mask >> 1) {
> + if (!(mmd_mask & 1))
> + continue;
> +
> + /* Read twice because link state is latched and a
> + * read moves the current state into the register
> + */
> + phy_read_mmd(phydev, devad, MDIO_STAT1);
> + reg =3D phy_read_mmd(phydev, devad, MDIO_STAT1);
> + if (reg < 0 || !(reg & MDIO_STAT1_LSTATUS))
> + phydev->link =3D 0;
> + }
> +
> + return 0;
> +}
> +EXPORT_SYMBOL(gen10g_read_status);
> +
> +
> static int genphy_config_init(struct phy_device *phydev) {
> int val;
> @@ -959,6 +1009,15 @@ static int genphy_config_init(struct phy_device *ph=
ydev)
>=20
> return 0;
> }
> +
> +static int gen10g_config_init(struct phy_device *phydev) {
> + /* Temporarily just say we support everything */
> + phydev->supported =3D phydev->advertising =3D SUPPORTED_10000baseT_Full=
;
> +
> + return 0;
> +}
> +
> int genphy_suspend(struct phy_device *phydev) {
> int value;
> @@ -974,6 +1033,13 @@ int genphy_suspend(struct phy_device *phydev) }
> EXPORT_SYMBOL(genphy_suspend);
>=20
> +int gen10g_suspend(struct phy_device *phydev) {
> + return 0;
> +}
> +EXPORT_SYMBOL(gen10g_suspend);
> +
> +
> int genphy_resume(struct phy_device *phydev) {
> int value;
> @@ -989,6 +1055,13 @@ int genphy_resume(struct phy_device *phydev) }
> EXPORT_SYMBOL(genphy_resume);
>=20
> +int gen10g_resume(struct phy_device *phydev) {
> + return 0;
> +}
> +EXPORT_SYMBOL(gen10g_resume);
> +
> +
> /**
> * phy_probe - probe and init a PHY device
> * @dev: device to probe and init
> @@ -1129,6 +1202,20 @@ static struct phy_driver genphy_driver =3D {
> .driver =3D {.owner=3D THIS_MODULE, },
> };
>=20
> +static struct phy_driver gen10g_driver =3D {
> + .phy_id =3D 0xffffffff,
> + .phy_id_mask =3D 0xffffffff,
> + .name =3D "Generic 10G PHY",
> + .config_init =3D gen10g_config_init,
> + .features =3D 0,
> + .config_aneg =3D gen10g_config_aneg,
> + .read_status =3D gen10g_read_status,
> + .suspend =3D gen10g_suspend,
> + .resume =3D gen10g_resume,
> + .driver =3D {.owner =3D THIS_MODULE, },
> +};
> +
> +
> static int __init phy_init(void)
> {
> int rc;
> @@ -1139,13 +1226,25 @@ static int __init phy_init(void)
>=20
> rc =3D phy_driver_register(&genphy_driver);
> if (rc)
> - mdio_bus_exit();
> + goto genphy_register_failed;
> +
> + rc =3D phy_driver_register(&gen10g_driver);
> + if (rc)
> + goto gen10g_register_failed;
> +
> + return rc;
> +
> +gen10g_register_failed:
> + phy_driver_unregister(&genphy_driver);
> +genphy_register_failed:
> + mdio_bus_exit();
>=20
> return rc;
> }
>=20
> static void __exit phy_exit(void)
> {
> + phy_driver_unregister(&gen10g_driver);
> phy_driver_unregister(&genphy_driver);
> mdio_bus_exit();
> }
> diff --git a/include/linux/phy.h b/include/linux/phy.h index 684925a..f86=
4004
> 100644
> --- a/include/linux/phy.h
> +++ b/include/linux/phy.h
> @@ -66,6 +66,7 @@ typedef enum {
> PHY_INTERFACE_MODE_RGMII_TXID,
> PHY_INTERFACE_MODE_RTBI,
> PHY_INTERFACE_MODE_SMII,
> + PHY_INTERFACE_MODE_XGMII,
> } phy_interface_t;
>=20
>=20
> --
> 1.8.4.1
^ permalink raw reply
* RE: [PATCH 1/4] phylib: Add Clause 45 read/write functions
From: Shaohui Xie @ 2013-11-12 12:30 UTC (permalink / raw)
To: shh.xie@gmail.com, linuxppc-dev@lists.ozlabs.org,
linux-kernel@vger.kernel.org
Cc: f.fainelli@gmail.com, netdev@vger.kernel.org, Shruti Kanetkar,
jg1.han@samsung.com, michal.simek@xilinx.com,
peppe.cavallaro@st.com, davem@davemloft.net,
Madalin-Cristian Bucur
In-Reply-To: <1384167864-2457-1-git-send-email-shh.xie@gmail.com>
Added more people and list.
Best Regards,=20
Shaohui Xie
> -----Original Message-----
> From: shh.xie@gmail.com [mailto:shh.xie@gmail.com]
> Sent: Monday, November 11, 2013 7:04 PM
> To: linuxppc-dev@lists.ozlabs.org; linux-kernel@vger.kernel.org
> Cc: Bucur Madalin-Cristian-B32716; Kanetkar Shruti-B44454; Xie Shaohui-B2=
1989
> Subject: [PATCH 1/4] phylib: Add Clause 45 read/write functions
>=20
> From: Andy Fleming
>=20
> You need an extra parameter to read or write Clause 45 PHYs, so we need a
> different API with the extra parameter.
>=20
> Signed-off-by: Andy Fleming
> Signed-off-by: Shaohui Xie <Shaohui.Xie@freescale.com>
> ---
> include/linux/phy.h | 33 +++++++++++++++++++++++++++++++++
> 1 file changed, 33 insertions(+)
>=20
> diff --git a/include/linux/phy.h b/include/linux/phy.h index 64ab823..684=
925a
> 100644
> --- a/include/linux/phy.h
> +++ b/include/linux/phy.h
> @@ -498,6 +498,21 @@ static inline int phy_read(struct phy_device *phydev=
, u32
> regnum) }
>=20
> /**
> + * phy_read_mmd - Convenience function for reading a register
> + * from an MMD on a given PHY.
> + * @phydev: The phy_device struct
> + * @devad: The MMD to read from
> + * @regnum: The register on the MMD to read
> + *
> + * Same rules as for phy_read();
> + */
> +static inline int phy_read_mmd(struct phy_device *phydev, int devad,
> +u32 regnum) {
> + return mdiobus_read(phydev->bus, phydev->addr,
> + MII_ADDR_C45 | (devad << 16) | (regnum & 0xffff)); }
> +
> +/**
> * phy_write - Convenience function for writing a given PHY register
> * @phydev: the phy_device struct
> * @regnum: register number to write
> @@ -533,6 +548,24 @@ static inline bool phy_is_internal(struct phy_device
> *phydev)
> return phydev->is_internal;
> }
>=20
> +/**
> + * phy_write_mmd - Convenience function for writing a register
> + * on an MMD on a given PHY.
> + * @phydev: The phy_device struct
> + * @devad: The MMD to read from
> + * @regnum: The register on the MMD to read
> + * @val: value to write to @regnum
> + *
> + * Same rules as for phy_write();
> + */
> +static inline int phy_write_mmd(struct phy_device *phydev, int devad,
> + u32 regnum, u16 val)
> +{
> + regnum =3D MII_ADDR_C45 | ((devad & 0x1f) << 16) | (regnum & 0xffff);
> +
> + return mdiobus_write(phydev->bus, phydev->addr, regnum, val); }
> +
> struct phy_device *phy_device_create(struct mii_bus *bus, int addr, int =
phy_id,
> bool is_c45, struct phy_c45_device_ids *c45_ids); struct
> phy_device *get_phy_device(struct mii_bus *bus, int addr, bool is_c45);
> --
> 1.8.4.1
^ permalink raw reply
* Re: [PATCH RFC v5 2/5] dma: mpc512x: add support for peripheral transfers
From: Alexander Popov @ 2013-11-12 12:23 UTC (permalink / raw)
To: Gerhard Sittig, Dan Williams, Vinod Koul, Lars-Peter Clausen,
Arnd Bergmann, Anatolij Gustschin, linuxppc-dev, devicetree,
Alexander Popov
In-Reply-To: <20131111201024.GR17929@book.gsilab.sittig.org>
Hello, Gerhard!
2013/11/12 Gerhard Sittig <gsi@denx.de>:
> Alexander, there is outstanding review feedback for a previous
> version of the series that you haven't addressed yet. Can you
> please either look into those issues, or state that it's OK to
> leave them and why this is so?
Excuse me for misunderstanding, Gerhard.
I have thoroughly worked on your feedback to RFCv4
and agreed to your points. So I've just wrote RFCv5.
And all the improvements and known issues based on your feedback
are listed in the cover letter [PATCH RFC v5 0/5].
> It would be nice to get a
> response to the feedback that you are given. It may be
> appropriate not to obey to the feedback, but at least it should
> get considered.
Yes, I see. My implicit response by RFCv5 was not efficient, sorry.
Now should I write a detailed answer in the thread with your feedback
for improving readability of the discussion?
> Have you noticed the recent introduction of the dmaengine@vger
> ML?
No, I didn't.
>Make sure to include it upon the next submission.
Ok, I will.
Thanks.
Best regards,
Alexander.
^ permalink raw reply
* Re: [PATCH] powerpc/85xx: typo in dts: "interupt" (four devices)
From: Mark Rutland @ 2013-11-12 9:11 UTC (permalink / raw)
To: Adam Borowski
Cc: devicetree@vger.kernel.org, Pawel Moll, Ian Campbell,
Stephen Warren, rob.herring@calxeda.com,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <1384206727-11880-1-git-send-email-kilobyte@angband.pl>
On Mon, Nov 11, 2013 at 09:52:07PM +0000, Adam Borowski wrote:
> These lines were inoperative for four years, which puts some doubt into
> their importance, and it's possible the fixed version will regress, but
> at the very least they should be removed instead.
>
> Signed-off-by: Adam Borowski <kilobyte@angband.pl>
> ---
> arch/powerpc/boot/dts/xcalibur1501.dts | 4 ++--
> arch/powerpc/boot/dts/xpedite5301.dts | 4 ++--
> arch/powerpc/boot/dts/xpedite5330.dts | 4 ++--
> arch/powerpc/boot/dts/xpedite5370.dts | 4 ++--
> 4 files changed, 8 insertions(+), 8 deletions(-)
>
> diff --git a/arch/powerpc/boot/dts/xcalibur1501.dts b/arch/powerpc/boot/dts/xcalibur1501.dts
> index cc00f4d..f151426 100644
> --- a/arch/powerpc/boot/dts/xcalibur1501.dts
> +++ b/arch/powerpc/boot/dts/xcalibur1501.dts
> @@ -637,14 +637,14 @@
> tlu@2f000 {
> compatible = "fsl,mpc8572-tlu", "fsl_tlu";
> reg = <0x2f000 0x1000>;
> - interupts = <61 2 >;
> + interrupts = <61 2 >;
While you're fixing the typo, could you get rid of the extraneous space
before the closing bracket? It seems to be duplicated across the other 3
dts fragments you fix up also.
Cheers,
Mark.
^ permalink raw reply
* Re: [alsa-devel] [PATCHv1 1/8] ALSA: Add SAI SoC Digital Audio Interface driver.
From: Lars-Peter Clausen @ 2013-11-12 7:59 UTC (permalink / raw)
To: Li Xiubo
Cc: mark.rutland@arm.com, alsa-devel@alsa-project.org,
linux-doc@vger.kernel.org, tiwai@suse.de, timur@tabi.org,
linux-kernel@vger.kernel.org, Huan Wang, LW@KARO-electronics.de,
linux@arm.linux.org.uk, Vinod Koul,
linux-arm-kernel@lists.infradead.org, grant.likely@linaro.org,
devicetree@vger.kernel.org, ian.campbell@citrix.com,
pawel.moll@arm.com, swarren@wwwdotorg.org, Shawn Guo, djbw@fb.com,
rob.herring@calxeda.com, broonie@kernel.org, Zhengxiong Jin,
oskar@scara.com, Fabio Estevam, lgirdwood@gmail.com,
rob@landley.net, Guangyu Chen, shawn.guo@linaro.org,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <1DD289F6464F0949A2FCA5AA6DC23F8287E87B@039-SN2MPN1-013.039d.mgd.msft.net>
On 11/12/2013 08:35 AM, Li Xiubo wrote:
>>>>> +static int fsl_sai_probe(struct platform_device *pdev) {
>>>> [...]
>>>>> +
>>>>> + sai->dma_params_rx.addr = res->start + SAI_RDR;
>>>>> + sai->dma_params_rx.maxburst = 6;
>>>>> + index = of_property_match_string(np, "dma-names", "rx");
>>>>> + ret = of_parse_phandle_with_args(np, "dmas", "#dma-cells",
>> index,
>>>>> + &dma_args);
>>>>> + if (ret)
>>>>> + return ret;
>>>>> + sai->dma_params_rx.slave_id = dma_args.args[1];
>>>>> +
>>>>> + sai->dma_params_tx.addr = res->start + SAI_TDR;
>>>>> + sai->dma_params_tx.maxburst = 6;
>>>>> + index = of_property_match_string(np, "dma-names", "tx");
>>>>> + ret = of_parse_phandle_with_args(np, "dmas", "#dma-cells",
>> index,
>>>>> + &dma_args);
>>>>> + if (ret)
>>>>> + return ret;
>>>>> + sai->dma_params_tx.slave_id = dma_args.args[1];
>>>>
>>>> The driver should not have to manually parse the dma devicetree
>>>> properties, this is something that should be handled by the dma
>>>> engine driver.
>>>>
>>>
>>> What do you think about the DMA slave_id ?
>>> I have been noticed by one colleague that this should be parsed here,
>>> which is from your opinions ?
>> Sure slave_id can be parsed here, but IMO it should be programmed via the
>> dma_slave_confog into the respective channel
>>
>
> Actually, these are parsed for cpu_dai->playback_dma_data and cpu_dai->capture_dma_data dynamically, whose type is struct dma_slave_config.
>
> And now I must parse them here, because the platform eDMA driver's newest version will check and use the slave_ids to select and configure the eDMA channels via dma_device->device_control().
Parsing them here is a layering violation. The format of the DMA specifier
depends on the DMA controller. A DMA slave should not make any assumptions
about how the specifier looks like, it should not even look at them. You should
fix the DMA controller driver to work without slave_id in the devicetree case.
- Lars
^ permalink raw reply
* Re: BookE "branch taken" behavior vis-a-vis updating the NIP register
From: pegasus @ 2013-11-12 7:37 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <alpine.LRH.2.00.1311111312390.25474@ra8135-ec1.am.freescale.net>
I re-read the link you posted earlier and this time it made more sense to me.
The kind of questions which are coming into my mind were being discussed.
So, off I went and downloaded the latest version of
arch/powerpc/kernel/traps.c hoping to see those very changes in them.
However it didn't match one on one with what was written in that thread.
Ditto for the other files in your patch. Looks like your patch didn't make
it to upstream but it looks exactly like what I need here. So allow me to
discuss certain finer points of it, to make sure I understand what it does
correctly.
In that thread you say
James Yang wrote
> BookE ISA's branch taken exception triggers before a branch that will be
> taken executes. This allows software to examine the branch and the
> conditions under which it will be taken. It also means software can tell
> where basic blocks end (at least the ones which are terminated by taken
> branches).
*
> There are no architected registers that report the address of the branch
> instruction after it has executed.
*
My thoughts exactly!
In the first patch's description, you say
James Yang wrote
> This patch makes available the unmodified BookE branch taken debug
> exception through PTRACE_SINGLEBLOCK if the ptrace() addr parameter is set
> to 2. (The existing behavior of PTRACE_SINGLEBLOCK is retained for any
> other addr parameter value, e.g., 0.)
*
> SIGTRAP will be signaled with the NIP pointing to the branch instruction
> before it has executed. The ptrace-calling program can then examine the
> program state.
*
>
/
> It should then request a PTRACE_SINGLESTEP in order to advance the program
> to the next instruction or a PTRACE_CONT to resume normal program
> execution.
/
> The si_code now also reports TRAP_BRANCH.
So requesting PTRACE_CONT has to happen inside the SIGTRAP signal handler
right? So as to advance the branch instruction (and since we are talking
BookE here, we are dead sure this branch will be taken). Now as for the
second patch, as far as I can see, implements the same functionality.
However it makes the change permanent and any tool which is used to the NIP
pointing to the branch target will be broken.
Anyways, for me either of them will work. But I think the first patch makes
everyone happy by using the 'addr' field of ptrace. This also means I will
have to make my (broken) ptrace working which, it seems is not as easy
adding an enum field as you suggested. May be theres a check somewhere in
the actual ptrace code which checks for illegal values and hence even after
adding an enum, it is being reported as illegal in my case. However getting
that to work is another story.
Please confirm my understanding of your patches and since these patches have
not made their way to the upstream kernel, will have to use them myself
directly. By the way, I'm using 2.6.32.10 (you know..the long-term kernel)
and I couldn't find any of your changes in them but then again I couldn't
find it in the latest 3.12 version either.
--
View this message in context: http://linuxppc.10917.n7.nabble.com/BookE-branch-taken-behavior-vis-a-vis-updating-the-NIP-register-tp77960p78036.html
Sent from the linuxppc-dev mailing list archive at Nabble.com.
^ permalink raw reply
* RE: [alsa-devel] [PATCHv1 1/8] ALSA: Add SAI SoC Digital Audio Interface driver.
From: Li Xiubo @ 2013-11-12 7:35 UTC (permalink / raw)
To: Vinod Koul, lars@metafoo.de
Cc: mark.rutland@arm.com, alsa-devel@alsa-project.org,
linux-doc@vger.kernel.org, tiwai@suse.de, timur@tabi.org,
linux-kernel@vger.kernel.org, Huan Wang, LW@KARO-electronics.de,
Lars-Peter Clausen, linux@arm.linux.org.uk,
linux-arm-kernel@lists.infradead.org, grant.likely@linaro.org,
devicetree@vger.kernel.org, ian.campbell@citrix.com,
pawel.moll@arm.com, swarren@wwwdotorg.org, Shawn Guo, djbw@fb.com,
rob.herring@calxeda.com, broonie@kernel.org, Zhengxiong Jin,
oskar@scara.com, Fabio Estevam, lgirdwood@gmail.com,
rob@landley.net, Guangyu Chen, shawn.guo@linaro.org,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <20131112050226.GK8834@intel.com>
> > > > +static int fsl_sai_probe(struct platform_device *pdev) {
> > > [...]
> > > > +
> > > > + sai->dma_params_rx.addr =3D res->start + SAI_RDR;
> > > > + sai->dma_params_rx.maxburst =3D 6;
> > > > + index =3D of_property_match_string(np, "dma-names", "rx");
> > > > + ret =3D of_parse_phandle_with_args(np, "dmas", "#dma-cells",
> index,
> > > > + &dma_args);
> > > > + if (ret)
> > > > + return ret;
> > > > + sai->dma_params_rx.slave_id =3D dma_args.args[1];
> > > > +
> > > > + sai->dma_params_tx.addr =3D res->start + SAI_TDR;
> > > > + sai->dma_params_tx.maxburst =3D 6;
> > > > + index =3D of_property_match_string(np, "dma-names", "tx");
> > > > + ret =3D of_parse_phandle_with_args(np, "dmas", "#dma-cells",
> index,
> > > > + &dma_args);
> > > > + if (ret)
> > > > + return ret;
> > > > + sai->dma_params_tx.slave_id =3D dma_args.args[1];
> > >
> > > The driver should not have to manually parse the dma devicetree
> > > properties, this is something that should be handled by the dma
> > > engine driver.
> > >
> >
> > What do you think about the DMA slave_id ?
> > I have been noticed by one colleague that this should be parsed here,
> > which is from your opinions ?
> Sure slave_id can be parsed here, but IMO it should be programmed via the
> dma_slave_confog into the respective channel
>=20
Actually, these are parsed for cpu_dai->playback_dma_data and cpu_dai->capt=
ure_dma_data dynamically, whose type is struct dma_slave_config.
And now I must parse them here, because the platform eDMA driver's newest v=
ersion will check and use the slave_ids to select and configure the eDMA ch=
annels via dma_device->device_control().=20
--
Xiubo
^ permalink raw reply
* Re: [PATCH v11 3/3] DMA: Freescale: update driver to support 8-channel DMA engine
From: Hongbo Zhang @ 2013-11-12 7:05 UTC (permalink / raw)
To: Dan Williams
Cc: mark.rutland, devicetree, ian.campbell, pawel.moll,
Stephen Warren, Koul, Vinod, Linux Kernel Mailing List,
rob.herring, dmaengine, linuxppc-dev
In-Reply-To: <CAPcyv4h00zGc2=ZLwnCpP3WTQ8JbFteV-torU+qCo98YXrfq5A@mail.gmail.com>
On 11/12/2013 08:09 AM, Dan Williams wrote:
> On Mon, Nov 11, 2013 at 1:12 AM, Hongbo Zhang
> <hongbo.zhang@freescale.com> wrote:
>>>>>> diff --git a/drivers/dma/fsldma.c b/drivers/dma/fsldma.c
>>>>>> index 49e8fbd..16a9a48 100644
>>>>>> --- a/drivers/dma/fsldma.c
>>>>>> +++ b/drivers/dma/fsldma.c
>>>>>> @@ -1261,7 +1261,9 @@ static int fsl_dma_chan_probe(struct
>>>>>> fsldma_device
>>>>>> *fdev,
>>>>>> WARN_ON(fdev->feature != chan->feature);
>>>>>> chan->dev = fdev->dev;
>>>>>> - chan->id = ((res.start - 0x100) & 0xfff) >> 7;
>>>>>> + chan->id = (res.start & 0xfff) < 0x300 ?
>>>>>> + ((res.start - 0x100) & 0xfff) >> 7 :
>>>>>> + ((res.start - 0x200) & 0xfff) >> 7;
>>>>>> if (chan->id >= FSL_DMA_MAX_CHANS_PER_DEVICE) {
>>> Isn't it a bit fragile to have this based on the resource address?
>>> Can't device tree tell you the channel id directly by an index into
>>> the "dma0: dma@100300" node?
>>
>> Yes, both this way and putting a "cell-index" into device tree work.
>> This won't be fragile, because the resource address should always be defined
>> correctly, otherwise even if we can tell a channel id by "cell-index" but
>> with wrong resource address, nothing will work.
>> This piece of code only doesn't seem as neat as using "cell-index", but we
>> prefer the style that let the device tree describes as true as what hardware
>> really has. This doesn't mean "cell-index" isn't acceptable, if it is
>> necessary and unavoidable, we can send another patch to add it, but
>> currently there is no need and we don't have to do this.
>>
> I'm pointing it out because we just had a bug fix to another driver
> motivated by the fact that resource addresses may move from one
> implementation to another, whereas the cell index provided by device
> tree is static. Just a note, no need to fix it now.
Get it, and will remember it, thank you Dan.
> --
> Dan
>
^ permalink raw reply
* [PATCH 2/2] powerpc/eeh: More accurate log
From: Gavin Shan @ 2013-11-12 6:49 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Gavin Shan
In-Reply-To: <1384238962-13170-1-git-send-email-shangw@linux.vnet.ibm.com>
We possibly has fenced PHB except frozen PE. So the output log
doesn't cover all cases and the patch fixes it.
Signed-off-by: Gavin Shan <shangw@linux.vnet.ibm.com>
---
arch/powerpc/kernel/eeh_event.c | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/kernel/eeh_event.c b/arch/powerpc/kernel/eeh_event.c
index d27c5af..72d748b 100644
--- a/arch/powerpc/kernel/eeh_event.c
+++ b/arch/powerpc/kernel/eeh_event.c
@@ -74,8 +74,13 @@ static int eeh_event_handler(void * dummy)
pe = event->pe;
if (pe) {
eeh_pe_state_mark(pe, EEH_PE_RECOVERING);
- pr_info("EEH: Detected PCI bus error on PHB#%d-PE#%x\n",
- pe->phb->global_number, pe->addr);
+ if (pe->type & EEH_PE_PHB)
+ pr_info("EEH: Detected error on PHB#%d\n",
+ pe->phb->global_number);
+ else
+ pr_info("EEH: Detected PCI bus error on "
+ "PHB#%d-PE#%x\n",
+ pe->phb->global_number, pe->addr);
eeh_handle_event(pe);
eeh_pe_state_clear(pe, EEH_PE_RECOVERING);
} else {
--
1.7.9.5
^ permalink raw reply related
* [PATCH 1/2] powerpc/eeh: Enable PCI_COMMAND_MASTER for PCI bridges
From: Gavin Shan @ 2013-11-12 6:49 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Gavin Shan
On PHB3, we will fail to fetch IODA tables without PCI_COMMAND_MASTER
on PCI bridges. According to one experiment I had, the MSIx interrupts
didn't raise from the adapter without the bit applied to all upstream
PCI bridges including root port of the adapter. The patch forces to
have that bit enabled accordingly.
Signed-off-by: Gavin Shan <shangw@linux.vnet.ibm.com>
---
arch/powerpc/kernel/eeh.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/arch/powerpc/kernel/eeh.c b/arch/powerpc/kernel/eeh.c
index 1fb331d..180af13 100644
--- a/arch/powerpc/kernel/eeh.c
+++ b/arch/powerpc/kernel/eeh.c
@@ -687,6 +687,15 @@ void eeh_save_bars(struct eeh_dev *edev)
for (i = 0; i < 16; i++)
eeh_ops->read_config(dn, i * 4, 4, &edev->config_space[i]);
+
+ /*
+ * For PCI bridges including root port, we need enable bus
+ * master explicitly. Otherwise, it can't fetch IODA table
+ * entries correctly. So we cache the bit in advance so that
+ * we can restore it after reset, either PHB range or PE range.
+ */
+ if (edev->mode & EEH_DEV_BRIDGE)
+ edev->config_space[1] |= PCI_COMMAND_MASTER;
}
/**
--
1.7.9.5
^ permalink raw reply related
* Re: [alsa-devel] [PATCHv1 1/8] ALSA: Add SAI SoC Digital Audio Interface driver.
From: Vinod Koul @ 2013-11-12 5:02 UTC (permalink / raw)
To: Xiubo Li-B47053
Cc: mark.rutland@arm.com, alsa-devel@alsa-project.org,
linux-doc@vger.kernel.org, tiwai@suse.de, Wang Huan-B18965,
timur@tabi.org, linux-kernel@vger.kernel.org, Guo Shawn-R65073,
LW@KARO-electronics.de, Lars-Peter Clausen,
linux@arm.linux.org.uk, Chen Guangyu-B42378, oskar@scara.com,
grant.likely@linaro.org, devicetree@vger.kernel.org,
ian.campbell@citrix.com, pawel.moll@arm.com,
swarren@wwwdotorg.org, rob.herring@calxeda.com,
broonie@kernel.org, linux-arm-kernel@lists.infradead.org,
Estevam Fabio-R49496, lgirdwood@gmail.com, rob@landley.net,
djbw@fb.com, Jin Zhengxiong-R64188, shawn.guo@linaro.org,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <1DD289F6464F0949A2FCA5AA6DC23F8286A385@039-SN2MPN1-013.039d.mgd.msft.net>
On Mon, Oct 28, 2013 at 05:58:42AM +0000, Xiubo Li-B47053 wrote:
> Hi Dan, Vinod,
>
>
> > > +static int fsl_sai_probe(struct platform_device *pdev) {
> > [...]
> > > +
> > > + sai->dma_params_rx.addr = res->start + SAI_RDR;
> > > + sai->dma_params_rx.maxburst = 6;
> > > + index = of_property_match_string(np, "dma-names", "rx");
> > > + ret = of_parse_phandle_with_args(np, "dmas", "#dma-cells", index,
> > > + &dma_args);
> > > + if (ret)
> > > + return ret;
> > > + sai->dma_params_rx.slave_id = dma_args.args[1];
> > > +
> > > + sai->dma_params_tx.addr = res->start + SAI_TDR;
> > > + sai->dma_params_tx.maxburst = 6;
> > > + index = of_property_match_string(np, "dma-names", "tx");
> > > + ret = of_parse_phandle_with_args(np, "dmas", "#dma-cells", index,
> > > + &dma_args);
> > > + if (ret)
> > > + return ret;
> > > + sai->dma_params_tx.slave_id = dma_args.args[1];
> >
> > The driver should not have to manually parse the dma devicetree
> > properties, this is something that should be handled by the dma engine
> > driver.
> >
>
> What do you think about the DMA slave_id ?
> I have been noticed by one colleague that this should be parsed here, which
> is from your opinions ?
Sure slave_id can be parsed here, but IMO it should be programmed via the
dma_slave_confog into the respective channel
--
~Vinod
>
>
> > > +
> > > + ret = snd_soc_register_component(&pdev->dev, &fsl_component,
> > > + &fsl_sai_dai, 1);
> > > + if (ret)
> > > + return ret;
> > > +
> > > + ret = fsl_pcm_dma_init(pdev);
> > > + if (ret)
> > > + goto out;
>
>
--
^ permalink raw reply
* Re: [PATCH] powerpc: add explicit OF includes for ppc4xx
From: Vinod Koul @ 2013-11-12 4:52 UTC (permalink / raw)
To: Rob Herring
Cc: linux-ide, linux-kernel, Rob Herring, Herbert Xu, Paul Mackerras,
linux-crypto, Matt Mackall, Tejun Heo, Dan Williams, linuxppc-dev,
David S. Miller
In-Reply-To: <1384148143-14335-1-git-send-email-robherring2@gmail.com>
On Sun, Nov 10, 2013 at 11:35:43PM -0600, Rob Herring wrote:
> From: Rob Herring <rob.herring@calxeda.com>
>
> Commit b5b4bb3f6a11f9 (of: only include prom.h on sparc) removed implicit
> includes of of_*.h headers by powerpc's prom.h. Some PPC4xx components
> were missed in initial clean-up patch, so add the necessary includes
> to fix ppc4xx builds.
>
> Signed-off-by: Rob Herring <rob.herring@calxeda.com>
> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Cc: Paul Mackerras <paulus@samba.org>
> Cc: Tejun Heo <tj@kernel.org>
> Cc: Matt Mackall <mpm@selenic.com>
> Cc: Herbert Xu <herbert@gondor.apana.org.au>
> Cc: "David S. Miller" <davem@davemloft.net>
> Cc: Vinod Koul <vinod.koul@intel.com>
> Cc: Dan Williams <dan.j.williams@intel.com>
> Cc: linuxppc-dev@lists.ozlabs.org
> Cc: linux-ide@vger.kernel.org
> Cc: linux-crypto@vger.kernel.org
> ---
> I intend to send this patch to Linus with the rest of the DT clean-up
> series.
>
> Rob
>
> arch/powerpc/sysdev/ppc4xx_ocm.c | 1 +
> arch/powerpc/sysdev/xilinx_intc.c | 1 +
> drivers/ata/sata_dwc_460ex.c | 2 ++
> drivers/char/hw_random/ppc4xx-rng.c | 1 +
> drivers/crypto/amcc/crypto4xx_core.c | 3 +++
> drivers/dma/ppc4xx/adma.c | 2 ++
For this:
Acked-by Vinod Koul <vinod.koul@intel.com>
--
~Vinod
> 6 files changed, 10 insertions(+)
>
> diff --git a/arch/powerpc/sysdev/ppc4xx_ocm.c b/arch/powerpc/sysdev/ppc4xx_ocm.c
> index 1b15f93..b7c4345 100644
> --- a/arch/powerpc/sysdev/ppc4xx_ocm.c
> +++ b/arch/powerpc/sysdev/ppc4xx_ocm.c
> @@ -26,6 +26,7 @@
> #include <linux/kernel.h>
> #include <linux/dma-mapping.h>
> #include <linux/of.h>
> +#include <linux/of_address.h>
> #include <asm/rheap.h>
> #include <asm/ppc4xx_ocm.h>
> #include <linux/slab.h>
> diff --git a/arch/powerpc/sysdev/xilinx_intc.c b/arch/powerpc/sysdev/xilinx_intc.c
> index f4fdc94..83f943a 100644
> --- a/arch/powerpc/sysdev/xilinx_intc.c
> +++ b/arch/powerpc/sysdev/xilinx_intc.c
> @@ -24,6 +24,7 @@
> #include <linux/irq.h>
> #include <linux/of.h>
> #include <linux/of_address.h>
> +#include <linux/of_irq.h>
> #include <asm/io.h>
> #include <asm/processor.h>
> #include <asm/i8259.h>
> diff --git a/drivers/ata/sata_dwc_460ex.c b/drivers/ata/sata_dwc_460ex.c
> index 2e39173..523524b 100644
> --- a/drivers/ata/sata_dwc_460ex.c
> +++ b/drivers/ata/sata_dwc_460ex.c
> @@ -31,6 +31,8 @@
> #include <linux/module.h>
> #include <linux/init.h>
> #include <linux/device.h>
> +#include <linux/of_address.h>
> +#include <linux/of_irq.h>
> #include <linux/of_platform.h>
> #include <linux/platform_device.h>
> #include <linux/libata.h>
> diff --git a/drivers/char/hw_random/ppc4xx-rng.c b/drivers/char/hw_random/ppc4xx-rng.c
> index 732c330..521f76b 100644
> --- a/drivers/char/hw_random/ppc4xx-rng.c
> +++ b/drivers/char/hw_random/ppc4xx-rng.c
> @@ -13,6 +13,7 @@
> #include <linux/platform_device.h>
> #include <linux/hw_random.h>
> #include <linux/delay.h>
> +#include <linux/of_address.h>
> #include <linux/of_platform.h>
> #include <asm/io.h>
>
> diff --git a/drivers/crypto/amcc/crypto4xx_core.c b/drivers/crypto/amcc/crypto4xx_core.c
> index f88e3d8..efaf630 100644
> --- a/drivers/crypto/amcc/crypto4xx_core.c
> +++ b/drivers/crypto/amcc/crypto4xx_core.c
> @@ -27,6 +27,9 @@
> #include <linux/dma-mapping.h>
> #include <linux/platform_device.h>
> #include <linux/init.h>
> +#include <linux/module.h>
> +#include <linux/of_address.h>
> +#include <linux/of_irq.h>
> #include <linux/of_platform.h>
> #include <linux/slab.h>
> #include <asm/dcr.h>
> diff --git a/drivers/dma/ppc4xx/adma.c b/drivers/dma/ppc4xx/adma.c
> index 370ff82..e24b5ef 100644
> --- a/drivers/dma/ppc4xx/adma.c
> +++ b/drivers/dma/ppc4xx/adma.c
> @@ -42,6 +42,8 @@
> #include <linux/uaccess.h>
> #include <linux/proc_fs.h>
> #include <linux/of.h>
> +#include <linux/of_address.h>
> +#include <linux/of_irq.h>
> #include <linux/of_platform.h>
> #include <asm/dcr.h>
> #include <asm/dcr-regs.h>
> --
> 1.8.1.2
>
--
^ 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