Re: [alsa-devel] [PATCHv1 1/8] ALSA: Add SAI SoC Digital Audio Interface driver.
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
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/85xx: typo in dts: interupt (four devices)
On Mon, Nov 11, 2013 at 09:52:07PM +, 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 kilob...@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.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH RFC v5 2/5] dma: mpc512x: add support for peripheral transfers
Hello, Gerhard! 2013/11/12 Gerhard Sittig g...@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. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc: book3s: PR: Enable Little Endian PR guest
Am 11.11.2013 um 09:08 schrieb Aneesh Kumar K.V
aneesh.ku...@linux.vnet.ibm.com:
From: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com
This patch make sure we inherit the LE bit correctly in different case
so that we can run Little Endian distro in PR mode
Signed-off-by: Aneesh Kumar K.V aneesh.ku...@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
---
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-...@fr.ibm.com
2) [PATCH] powerpc: book3s: kvm: Use the saved dsisr and dar values
http://mid.gmane.org/1384178577-23721-1-git-send-email-aneesh.ku...@linux.vnet.ibm.com
arch/powerpc/kvm/book3s_64_mmu.c | 2 +-
arch/powerpc/kvm/book3s_pr.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
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 @@
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));
}
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 = vcpu-arch.shared-msr;
/* Guest MSR values */
-smsr = MSR_FE0 | MSR_FE1 | MSR_SF | MSR_SE | MSR_BE;
+smsr = MSR_FE0 | MSR_FE1 | MSR_SF | MSR_SE | MSR_BE | MSR_LE;
/* Process MSR values */
smsr |= MSR_ME | MSR_RI | MSR_IR | MSR_DR | MSR_PR | MSR_EE;
/* External providers the guest reserved */
--
1.8.3.2
--
To unsubscribe from this list: send the line unsubscribe kvm-ppc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 08/11] powerpc: use generic fixmap.h
Signed-off-by: Mark Salter msal...@redhat.com
CC: Benjamin Herrenschmidt b...@kernel.crashing.org
CC: Paul Mackerras pau...@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
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 00/11] Consolidate asm/fixmap.h files
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 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 01/11] Add generic fixmap.h
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 msal...@redhat.com
CC: Arnd Bergmann a...@arndb.de
CC: linux-a...@vger.kernel.org
CC: Russell King li...@arm.linux.org.uk
CC: linux-arm-ker...@lists.infradead.org
CC: Richard Kuo r...@codeaurora.org
CC: linux-hexa...@vger.kernel.org
CC: James Hogan james.ho...@imgtec.com
CC: linux-me...@vger.kernel.org
CC: Michal Simek mon...@monstr.eu
CC: microblaze-ucli...@itee.uq.edu.au
CC: Ralf Baechle r...@linux-mips.org
CC: linux-m...@linux-mips.org
CC: Benjamin Herrenschmidt b...@kernel.crashing.org
CC: Paul Mackerras pau...@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 000..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
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 01/11] Add generic fixmap.h
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 a...@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
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH 2/4] phylib: Add generic 10G driver
Added more people and list.
Best Regards,
Shaohui Xie
-Original Message-
From: shh@gmail.com [mailto:shh@gmail.com]
Sent: Monday, November 11, 2013 7:07 PM
To: linuxppc-dev@lists.ozlabs.org; linux-ker...@vger.kernel.org
Cc: Bucur Madalin-Cristian-B32716; Kanetkar Shruti-B44454; Xie Shaohui-B21989
Subject: [PATCH 2/4] phylib: Add generic 10G driver
From: Andy Fleming
Very incomplete, but will allow for binding an ethernet controller to it.
Also, Add XGMII interface type
Signed-off-by: Andy Fleming
Signed-off-by: Shaohui Xie shaohui@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 = 1;
+ 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_1baseT_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);
+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 = 0x,
+ .phy_id_mask= 0x,
+ .name = Generic 10G PHY,
+ .config_init= gen10g_config_init,
+ .features = 0,
+ .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 =
RE: [PATCH 1/4] phylib: Add Clause 45 read/write functions
Added more people and list.
Best Regards,
Shaohui Xie
-Original Message-
From: shh@gmail.com [mailto:shh@gmail.com]
Sent: Monday, November 11, 2013 7:04 PM
To: linuxppc-dev@lists.ozlabs.org; linux-ker...@vger.kernel.org
Cc: Bucur Madalin-Cristian-B32716; Kanetkar Shruti-B44454; Xie Shaohui-B21989
Subject: [PATCH 1/4] phylib: Add Clause 45 read/write functions
From: Andy Fleming
You need an extra parameter to read or write Clause 45 PHYs, so we need a
different API with the extra parameter.
Signed-off-by: Andy Fleming
Signed-off-by: Shaohui Xie shaohui@freescale.com
---
include/linux/phy.h | 33 +
1 file changed, 33 insertions(+)
diff --git a/include/linux/phy.h b/include/linux/phy.h index 64ab823..684925a
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) }
/**
+ * 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 0x)); }
+
+/**
* 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;
}
+/**
+ * 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 = MII_ADDR_C45 | ((devad 0x1f) 16) | (regnum 0x);
+
+ 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
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH 4/4] phylib: Add of_phy_attach
Added more people and list.
Best Regards,
Shaohui Xie
-Original Message-
From: shh@gmail.com [mailto:shh@gmail.com]
Sent: Monday, November 11, 2013 7:08 PM
To: linuxppc-dev@lists.ozlabs.org; linux-ker...@vger.kernel.org
Cc: Bucur Madalin-Cristian-B32716; Kanetkar Shruti-B44454; Xie Shaohui-B21989
Subject: [PATCH 4/4] phylib: Add of_phy_attach
From: Andy Fleming
10G PHYs don't currently support running the state machine, which is
implicitly
setup via of_phy_connect(). Therefore, it is necessary to implement an OF
version of phy_attach(), which does everything except start the state machine.
Signed-off-by: Andy Fleming
Signed-off-by: Shaohui Xie shaohui@freescale.com
---
drivers/of/of_mdio.c| 22 --
include/linux/of_mdio.h | 8
2 files changed, 28 insertions(+), 2 deletions(-)
diff --git a/drivers/of/of_mdio.c b/drivers/of/of_mdio.c index
d5a57a9..a748274
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 = 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_device
*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 *dev,
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;
}
+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_device
*dev,
void (*hndlr)(struct
net_device
*),
phy_interface_t
iface)
--
1.8.4.1
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH 3/4] phylib: Support attaching to gen10g_driver
Added more people and list.
Best Regards,
Shaohui Xie
-Original Message-
From: shh@gmail.com [mailto:shh@gmail.com]
Sent: Monday, November 11, 2013 7:08 PM
To: linuxppc-dev@lists.ozlabs.org; linux-ker...@vger.kernel.org
Cc: Bucur Madalin-Cristian-B32716; Kanetkar Shruti-B44454; Xie Shaohui-B21989
Subject: [PATCH 3/4] phylib: Support attaching to gen10g_driver
From: Andy Fleming
phy_attach_direct() may now attach to a generic 10G driver. It can also be
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, which
is
currently irrelevant for 10G PHYs.
Signed-off-by: Andy Fleming
Signed-off-by: Shaohui Xie shaohui@freescale.com
---
drivers/net/phy/phy_device.c | 23 +++
include/linux/phy.h | 2 ++
2 files changed, 13 insertions(+), 12 deletions(-)
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) }
static struct phy_driver genphy_driver;
+static struct phy_driver gen10g_driver;
extern int mdio_bus_init(void);
extern void mdio_bus_exit(void);
static LIST_HEAD(phy_fixup_list);
static DEFINE_MUTEX(phy_fixup_lock);
-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 = 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 == d-driver) {
- if (phydev-is_c45) {
- pr_err(No driver for phy %x\n, phydev-phy_id);
- return -ENODEV;
- }
-
- d-driver = genphy_driver.driver;
+ if (phydev-is_c45)
+ d-driver = gen10g_driver.driver;
+ else
+ d-driver = genphy_driver.driver;
err = d-driver-probe(d);
if (err = 0)
@@ -573,6 +569,7 @@ static int phy_attach_direct(struct net_device *dev,
struct
phy_device *phydev,
return err;
}
+EXPORT_SYMBOL(phy_attach_direct);
/**
* phy_attach - attach a network device to a particular PHY device @@ -623,6
+620,8 @@ void phy_detach(struct phy_device *phydev)
* real driver could be loaded */
if (phydev-dev.driver == genphy_driver.driver)
device_release_driver(phydev-dev);
+ else if (phydev-dev.driver == gen10g_driver.driver)
+ device_release_driver(phydev-dev);
}
EXPORT_SYMBOL(phy_detach);
diff --git a/include/linux/phy.h b/include/linux/phy.h index f864004..f36a6f6
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
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 00/11] Consolidate asm/fixmap.h files
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 signature.asc Description: OpenPGP digital signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 00/11] Consolidate asm/fixmap.h files
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) ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH V2] powerpc/85xx: Merge 85xx/p1023_defconfig into mpc85xx_smp_defconfig and mpc85xx_defconfig
On Nov 11, 2013, at 1:25 PM, Lijun Pan lijun@freescale.com wrote: mpc85xx_smp_defconfig and mpc85xx_defconfig already have CONFIG_P1023RDS=y. Merge CONFIG_P1023RDB=y and other relevant configurations into mpc85xx_smp_defconfig and mpc85_defconfig. Signed-off-by: Lijun Pan lijun@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 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc/85xx: typo in dts: interupt (four devices)
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 kilob...@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
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/4] phylib: Add generic 10G driver
Hello Shaohui,
2013/11/11 shh@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@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 = 1;
Can you at least make this a little more proof? Something along:
if (phydev-supported (SUPPORTED_1baseT_Full))
phydev-speed = SPEED_1;
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_1baseT_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 = 0x,
+ .phy_id_mask= 0x,
+ .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.
Problem reading and programming memory location...
we have tried to read and program an 8bit register with 32bit address. we have mapped it with: ioremap, kmalloc etc… and then using: outb, iowrite8 etc.. but when we write to it, the value doesn’t change… with other memory location is ok. That is an 8 bit register, located at 0x1002 in a mpc5200b architecture. we are using kernel 2.6.33. what could be? Thank you Lorenzo ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 01/12] powerpc/windfarm: Remove superfluous name casts
wf_sensor.name is const char * Signed-off-by: Geert Uytterhoeven ge...@linux-m68k.org Cc: Benjamin Herrenschmidt b...@kernel.crashing.org Cc: linuxppc-dev@lists.ozlabs.org --- drivers/macintosh/windfarm_lm75_sensor.c|2 +- drivers/macintosh/windfarm_max6690_sensor.c |2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/macintosh/windfarm_lm75_sensor.c b/drivers/macintosh/windfarm_lm75_sensor.c index 9ef32b3df91f..590214ba736c 100644 --- a/drivers/macintosh/windfarm_lm75_sensor.c +++ b/drivers/macintosh/windfarm_lm75_sensor.c @@ -133,7 +133,7 @@ static int wf_lm75_probe(struct i2c_client *client, lm-inited = 0; lm-ds1775 = ds1775; lm-i2c = client; - lm-sens.name = (char *)name; /* XXX fix constness in structure */ + lm-sens.name = name; lm-sens.ops = wf_lm75_ops; i2c_set_clientdata(client, lm); diff --git a/drivers/macintosh/windfarm_max6690_sensor.c b/drivers/macintosh/windfarm_max6690_sensor.c index 945a25b2f31e..87e439b10318 100644 --- a/drivers/macintosh/windfarm_max6690_sensor.c +++ b/drivers/macintosh/windfarm_max6690_sensor.c @@ -95,7 +95,7 @@ static int wf_max6690_probe(struct i2c_client *client, } max-i2c = client; - max-sens.name = (char *)name; /* XXX fix constness in structure */ + max-sens.name = name; max-sens.ops = wf_max6690_ops; i2c_set_clientdata(client, max); -- 1.7.9.5 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH V2] powerpc/85xx: Merge 85xx/p1023_defconfig into mpc85xx_smp_defconfig and mpc85xx_defconfig
On Mon, Nov 11, 2013 at 1:25 PM, Lijun Pan lijun@freescale.com wrote: +CONFIG_P1023_RDB=y I think this is the only line you should be adding to the defconfigs. None of the others should be necessary. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/4] phylib: Add Clause 45 read/write functions
On Mon, 2013-11-11 at 19:04 +0800, shh@gmail.com wrote: From: Andy Fleming You need an extra parameter to read or write Clause 45 PHYs, so we need a different API with the extra parameter. Signed-off-by: Andy Fleming Signed-off-by: Shaohui Xie shaohui@freescale.com Why did you remove Andy's e-mail address? Even though it's no longer valid, it helps identify which specific person you're talking about. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH V2] powerpc/85xx: Merge 85xx/p1023_defconfig into mpc85xx_smp_defconfig and mpc85xx_defconfig
On Mon, 2013-11-11 at 13:25 -0600, Lijun Pan wrote: mpc85xx_smp_defconfig and mpc85xx_defconfig already have CONFIG_P1023RDS=y. Merge CONFIG_P1023RDB=y and other relevant configurations into mpc85xx_smp_defconfig and mpc85_defconfig. Signed-off-by: Lijun Pan lijun@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 Are we still going to want to have one defconfig if and when we finally get datapath support upstream? That's a lot of code to add to the 85xx config just for this one chip. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc: book3s: PR: Enable Little Endian PR guest
On Tue, Nov 12, 2013 at 07:37:24AM -0500, Alexander Graf wrote: Am 11.11.2013 um 09:08 schrieb Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com: From: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com This patch make sure we inherit the LE bit correctly in different case so that we can run Little Endian distro in PR mode Signed-off-by: Aneesh Kumar K.V aneesh.ku...@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? :) No, it isn't. What we should really be doing depends a bit on what CPU we're emulating. Older CPUs had an ILE bit in the MSR that got copied to LE on interrupt. Recent POWER CPUs moved the ILE bit to the LPCR, so for them we should have an emulated LPCR (and implement H_SET_MODE for pseries guests so they can control LPCR[ILE]). Embedded CPUs of course don't have an LE bit, or an ILE bit, since they control endianness on a per-page basis. Paul. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH V2] powerpc/85xx: Merge 85xx/p1023_defconfig into mpc85xx_smp_defconfig and mpc85xx_defconfig
On Tue, 2013-11-12 at 16:49 -0600, Zang Roy-R61911 wrote: -Original Message- From: Linuxppc-dev [mailto:linuxppc-dev-bounces+tie- fei.zang=freescale@lists.ozlabs.org] On Behalf Of Scott Wood Sent: Tuesday, November 12, 2013 4:05 PM To: Pan Lijun-B44306 Cc: linuxppc-...@ozlabs.org Subject: Re: [PATCH V2] powerpc/85xx: Merge 85xx/p1023_defconfig into mpc85xx_smp_defconfig and mpc85xx_defconfig On Mon, 2013-11-11 at 13:25 -0600, Lijun Pan wrote: mpc85xx_smp_defconfig and mpc85xx_defconfig already have CONFIG_P1023RDS=y. Merge CONFIG_P1023RDB=y and other relevant configurations into mpc85xx_smp_defconfig and mpc85_defconfig. Signed-off-by: Lijun Pan lijun@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 Are we still going to want to have one defconfig if and when we finally get datapath support upstream? That's a lot of code to add to the 85xx config just for this one chip. P1023 has dpaa. Will mpc85xx_defconfig or mpc85xx_smp_defconfig support dpaa? That's the question I'm asking. Though I suppose we could take a patch like this one for now, and then introduce mpc85xx_dpaa_defconfig when it becomes relevant (which would make clear why the defconfig is separate). p1023 would still work with the non-dpaa defconfigs, but without dpaa support. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH V2] powerpc/85xx: Merge 85xx/p1023_defconfig into mpc85xx_smp_defconfig and mpc85xx_defconfig
On Tue, 2013-11-12 at 17:05 -0600, Zang Roy-R61911 wrote: -Original Message- From: Wood Scott-B07421 Sent: Tuesday, November 12, 2013 4:52 PM To: Zang Roy-R61911 Cc: Pan Lijun-B44306; linuxppc-...@ozlabs.org Subject: Re: [PATCH V2] powerpc/85xx: Merge 85xx/p1023_defconfig into mpc85xx_smp_defconfig and mpc85xx_defconfig On Tue, 2013-11-12 at 16:49 -0600, Zang Roy-R61911 wrote: -Original Message- From: Linuxppc-dev [mailto:linuxppc-dev-bounces+tie- fei.zang=freescale@lists.ozlabs.org] On Behalf Of Scott Wood Sent: Tuesday, November 12, 2013 4:05 PM To: Pan Lijun-B44306 Cc: linuxppc-...@ozlabs.org Subject: Re: [PATCH V2] powerpc/85xx: Merge 85xx/p1023_defconfig into mpc85xx_smp_defconfig and mpc85xx_defconfig On Mon, 2013-11-11 at 13:25 -0600, Lijun Pan wrote: mpc85xx_smp_defconfig and mpc85xx_defconfig already have CONFIG_P1023RDS=y. Merge CONFIG_P1023RDB=y and other relevant configurations into mpc85xx_smp_defconfig and mpc85_defconfig. Signed-off-by: Lijun Pan lijun@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 Are we still going to want to have one defconfig if and when we finally get datapath support upstream? That's a lot of code to add to the 85xx config just for this one chip. P1023 has dpaa. Will mpc85xx_defconfig or mpc85xx_smp_defconfig support dpaa? That's the question I'm asking. Though I suppose we could take a patch like this one for now, and then introduce mpc85xx_dpaa_defconfig when it becomes relevant (which would make clear why the defconfig is separate). p1023 would still work with the non-dpaa defconfigs, but without dpaa support. It will be hard to find a seat for P1023 in mpc85xx_dpaa_defconfig. What do you mean? P1023 does not have corenet. It has e500v2 core. All the other DPAA SOCs have corenet. I suggest leaving p1023 defconfig standalone. I didn't say mpc85xx_corenet_defconfig, nor did I suggest that mpc85xx_dpaa_defconfig replace corenet32_defconfig. Perhaps e500v2_dpaa_defconfig would be a better name. It would effectively be a standalone p1023 defconfig, but with a name that reflects the reason for it, and which would accommodate future e500v2 dpaa chips in the unlikely case that such things are made. Do you know how large the current SDK datapath code is? Though perhaps the eventual upstream version will be smaller. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH V2] powerpc/85xx: Merge 85xx/p1023_defconfig into mpc85xx_smp_defconfig and mpc85xx_defconfig
Hello Scott, On 11/12/2013 04:04 PM, Scott Wood wrote: On Mon, 2013-11-11 at 13:25 -0600, Lijun Pan wrote: mpc85xx_smp_defconfig and mpc85xx_defconfig already have CONFIG_P1023RDS=y. Merge CONFIG_P1023RDB=y and other relevant configurations into mpc85xx_smp_defconfig and mpc85_defconfig. Signed-off-by: Lijun Pan lijun@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 Are we still going to want to have one defconfig if and when we finally get datapath support upstream? That's a lot of code to add to the 85xx config just for this one chip. Yes. But for mpc85xx_/smp_defconfig the datapath support shouldn't be enabled by default given that just one SoC in that family has the datapath (and we don't plan to put it in another e500v2 based SoC). For regression/automation purposes config fragments should be used Cheers, ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH V2] powerpc/85xx: Merge 85xx/p1023_defconfig into mpc85xx_smp_defconfig and mpc85xx_defconfig
-Original Message- From: Linuxppc-dev [mailto:linuxppc-dev-bounces+tie- fei.zang=freescale@lists.ozlabs.org] On Behalf Of Scott Wood Sent: Tuesday, November 12, 2013 4:05 PM To: Pan Lijun-B44306 Cc: linuxppc-...@ozlabs.org Subject: Re: [PATCH V2] powerpc/85xx: Merge 85xx/p1023_defconfig into mpc85xx_smp_defconfig and mpc85xx_defconfig On Mon, 2013-11-11 at 13:25 -0600, Lijun Pan wrote: mpc85xx_smp_defconfig and mpc85xx_defconfig already have CONFIG_P1023RDS=y. Merge CONFIG_P1023RDB=y and other relevant configurations into mpc85xx_smp_defconfig and mpc85_defconfig. Signed-off-by: Lijun Pan lijun@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 Are we still going to want to have one defconfig if and when we finally get datapath support upstream? That's a lot of code to add to the 85xx config just for this one chip. P1023 has dpaa. Will mpc85xx_defconfig or mpc85xx_smp_defconfig support dpaa? Thanks. Roy ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH V2] powerpc/85xx: Merge 85xx/p1023_defconfig into mpc85xx_smp_defconfig and mpc85xx_defconfig
-Original Message- From: Wood Scott-B07421 Sent: Tuesday, November 12, 2013 4:52 PM To: Zang Roy-R61911 Cc: Pan Lijun-B44306; linuxppc-...@ozlabs.org Subject: Re: [PATCH V2] powerpc/85xx: Merge 85xx/p1023_defconfig into mpc85xx_smp_defconfig and mpc85xx_defconfig On Tue, 2013-11-12 at 16:49 -0600, Zang Roy-R61911 wrote: -Original Message- From: Linuxppc-dev [mailto:linuxppc-dev-bounces+tie- fei.zang=freescale@lists.ozlabs.org] On Behalf Of Scott Wood Sent: Tuesday, November 12, 2013 4:05 PM To: Pan Lijun-B44306 Cc: linuxppc-...@ozlabs.org Subject: Re: [PATCH V2] powerpc/85xx: Merge 85xx/p1023_defconfig into mpc85xx_smp_defconfig and mpc85xx_defconfig On Mon, 2013-11-11 at 13:25 -0600, Lijun Pan wrote: mpc85xx_smp_defconfig and mpc85xx_defconfig already have CONFIG_P1023RDS=y. Merge CONFIG_P1023RDB=y and other relevant configurations into mpc85xx_smp_defconfig and mpc85_defconfig. Signed-off-by: Lijun Pan lijun@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 Are we still going to want to have one defconfig if and when we finally get datapath support upstream? That's a lot of code to add to the 85xx config just for this one chip. P1023 has dpaa. Will mpc85xx_defconfig or mpc85xx_smp_defconfig support dpaa? That's the question I'm asking. Though I suppose we could take a patch like this one for now, and then introduce mpc85xx_dpaa_defconfig when it becomes relevant (which would make clear why the defconfig is separate). p1023 would still work with the non-dpaa defconfigs, but without dpaa support. It will be hard to find a seat for P1023 in mpc85xx_dpaa_defconfig. P1023 does not have corenet. It has e500v2 core. All the other DPAA SOCs have corenet. I suggest leaving p1023 defconfig standalone. Roy ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH V2] powerpc/85xx: Merge 85xx/p1023_defconfig into mpc85xx_smp_defconfig and mpc85xx_defconfig
On Tue, 2013-11-12 at 16:57 -0600, Emil Medve wrote: Hello Scott, On 11/12/2013 04:04 PM, Scott Wood wrote: On Mon, 2013-11-11 at 13:25 -0600, Lijun Pan wrote: mpc85xx_smp_defconfig and mpc85xx_defconfig already have CONFIG_P1023RDS=y. Merge CONFIG_P1023RDB=y and other relevant configurations into mpc85xx_smp_defconfig and mpc85_defconfig. Signed-off-by: Lijun Pan lijun@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 Are we still going to want to have one defconfig if and when we finally get datapath support upstream? That's a lot of code to add to the 85xx config just for this one chip. Yes. But for mpc85xx_/smp_defconfig the datapath support shouldn't be enabled by default given that just one SoC in that family has the datapath (and we don't plan to put it in another e500v2 based SoC). For regression/automation purposes config fragments should be used Is there any way to specify a meta-config for p1023 (or e500v2-dpaa or whatever) that says to combine mpc85xx_smp_defconfig with a dpaa fragment? Do we have any config fragments in the tree so far? -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/3] powerpc/p1010rdb:add P1010RDB-PB platform support
On Thu, 2013-11-07 at 10:29 +0800, Zhao Qiang wrote: The P1010RDB-PB is similar to P1010RDB(P1010RDB-PA). So, P1010RDB-PB use the same platform file as P1010RDB. Then Add support for P1010RDB-PB platform. Signed-off-by: Zhao Qiang b45...@freescale.com --- arch/powerpc/platforms/85xx/p1010rdb.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/powerpc/platforms/85xx/p1010rdb.c b/arch/powerpc/platforms/85xx/p1010rdb.c index 0252961..d6a3dd3 100644 --- a/arch/powerpc/platforms/85xx/p1010rdb.c +++ b/arch/powerpc/platforms/85xx/p1010rdb.c @@ -66,6 +66,8 @@ static int __init p1010_rdb_probe(void) if (of_flat_dt_is_compatible(root, fsl,P1010RDB)) return 1; + if (of_flat_dt_is_compatible(root, fsl,P1010RDB-PB)) + return 1; return 0; } This had already been merged into Ben's tree when you reposted it (without any indication that it was a repost/respin), and is now in Linus's tree. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH 1/4] phylib: Add Clause 45 read/write functions
-Original Message- From: Wood Scott-B07421 Sent: Wednesday, November 13, 2013 5:58 AM To: shh@gmail.com Cc: linuxppc-dev@lists.ozlabs.org; linux-ker...@vger.kernel.org; Kanetkar Shruti-B44454; Xie Shaohui-B21989; Bucur Madalin-Cristian-B32716 Subject: Re: [PATCH 1/4] phylib: Add Clause 45 read/write functions On Mon, 2013-11-11 at 19:04 +0800, shh@gmail.com wrote: From: Andy Fleming You need an extra parameter to read or write Clause 45 PHYs, so we need a different API with the extra parameter. Signed-off-by: Andy Fleming Signed-off-by: Shaohui Xie shaohui@freescale.com Why did you remove Andy's e-mail address? Even though it's no longer valid, it helps identify which specific person you're talking about. [S.H] Andy's e-mail address is not valid and git-send-mail will fail, I have to remove it to make git work. Best Regards, Shaohui Xie ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/4] phylib: Add Clause 45 read/write functions
On Tue, 2013-11-12 at 19:51 -0600, Xie Shaohui-B21989 wrote: -Original Message- From: Wood Scott-B07421 Sent: Wednesday, November 13, 2013 5:58 AM To: shh@gmail.com Cc: linuxppc-dev@lists.ozlabs.org; linux-ker...@vger.kernel.org; Kanetkar Shruti-B44454; Xie Shaohui-B21989; Bucur Madalin-Cristian-B32716 Subject: Re: [PATCH 1/4] phylib: Add Clause 45 read/write functions On Mon, 2013-11-11 at 19:04 +0800, shh@gmail.com wrote: From: Andy Fleming You need an extra parameter to read or write Clause 45 PHYs, so we need a different API with the extra parameter. Signed-off-by: Andy Fleming Signed-off-by: Shaohui Xie shaohui@freescale.com Why did you remove Andy's e-mail address? Even though it's no longer valid, it helps identify which specific person you're talking about. [S.H] Andy's e-mail address is not valid and git-send-mail will fail, I have to remove it to make git work. Tell git send-email to not include that address, e.g. using --suppress-cc, --no-signed-off-by-cc, --suppress-from, etc. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/4] phylib: Add Clause 45 read/write functions
Hello Xiao-Hui, On 11/12/2013 07:51 PM, Shaohui Xie wrote: -Original Message- From: Wood Scott-B07421 Sent: Wednesday, November 13, 2013 5:58 AM To: shh@gmail.com Cc: linuxppc-dev@lists.ozlabs.org; linux-ker...@vger.kernel.org; Kanetkar Shruti-B44454; Xie Shaohui-B21989; Bucur Madalin-Cristian-B32716 Subject: Re: [PATCH 1/4] phylib: Add Clause 45 read/write functions On Mon, 2013-11-11 at 19:04 +0800, shh@gmail.com wrote: From: Andy Fleming You need an extra parameter to read or write Clause 45 PHYs, so we need a different API with the extra parameter. Signed-off-by: Andy Fleming Signed-off-by: Shaohui Xie shaohui@freescale.com Why did you remove Andy's e-mail address? Even though it's no longer valid, it helps identify which specific person you're talking about. [S.H] Andy's e-mail address is not valid and git-send-mail will fail, I have to remove it to make git work. Just use Andy's GMail address: aflem...@gmail.com Cheers, ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH 1/4] phylib: Add Clause 45 read/write functions
On Tue, 2013-11-12 at 19:51 -0600, Xie Shaohui-B21989 wrote: -Original Message- From: Wood Scott-B07421 Sent: Wednesday, November 13, 2013 5:58 AM To: shh@gmail.com Cc: linuxppc-dev@lists.ozlabs.org; linux-ker...@vger.kernel.org; Kanetkar Shruti-B44454; Xie Shaohui-B21989; Bucur Madalin-Cristian-B32716 Subject: Re: [PATCH 1/4] phylib: Add Clause 45 read/write functions On Mon, 2013-11-11 at 19:04 +0800, shh@gmail.com wrote: From: Andy Fleming You need an extra parameter to read or write Clause 45 PHYs, so we need a different API with the extra parameter. Signed-off-by: Andy Fleming Signed-off-by: Shaohui Xie shaohui@freescale.com Why did you remove Andy's e-mail address? Even though it's no longer valid, it helps identify which specific person you're talking about. [S.H] Andy's e-mail address is not valid and git-send-mail will fail, I have to remove it to make git work. Tell git send-email to not include that address, e.g. using --suppress-cc, --no- signed-off-by-cc, --suppress-from, etc. [S.H] OK. Thank you! Best Regards, Shaohui Xie ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH V2] powerpc/85xx: Merge 85xx/p1023_defconfig into mpc85xx_smp_defconfig and mpc85xx_defconfig
Hello Scott, On 11/12/2013 07:46 PM, Scott Wood wrote: On Tue, 2013-11-12 at 16:57 -0600, Emil Medve wrote: Hello Scott, On 11/12/2013 04:04 PM, Scott Wood wrote: On Mon, 2013-11-11 at 13:25 -0600, Lijun Pan wrote: mpc85xx_smp_defconfig and mpc85xx_defconfig already have CONFIG_P1023RDS=y. Merge CONFIG_P1023RDB=y and other relevant configurations into mpc85xx_smp_defconfig and mpc85_defconfig. Signed-off-by: Lijun Pan lijun@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 Are we still going to want to have one defconfig if and when we finally get datapath support upstream? That's a lot of code to add to the 85xx config just for this one chip. Yes. But for mpc85xx_/smp_defconfig the datapath support shouldn't be enabled by default given that just one SoC in that family has the datapath (and we don't plan to put it in another e500v2 based SoC). For regression/automation purposes config fragments should be used Is there any way to specify a meta-config for p1023 (or e500v2-dpaa or whatever) that says to combine mpc85xx_smp_defconfig with a dpaa fragment? Not aware of it Do we have any config fragments in the tree so far? Nope. However, just to make sure, the fragment was my secondary point and not necessarily as a candidate for upstreaming. My main point was that the datapath support should simply not be enabled by default in the mpc85xx_[smp_]defconfig Cheers, ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH] Add a vga alias node for P1022
-Original Message- From: Jin Zhengxiong-R64188 Sent: Friday, September 06, 2013 5:33 PM To: Wood Scott-B07421 Cc: linuxppc-dev@lists.ozlabs.org; ga...@kernel.crashing.org; Jin Zhengxiong-R64188 Subject: [PATCH] Add a vga alias node for P1022 From: Jason Jin jason@freescale.com When the vga was set as the stdout and stderr in u-boot, the stdout fixup code in u-boot need to find out the vga alias node in dtb. Signed-off-by: Jason Jin jason@freescale.com --- arch/powerpc/boot/dts/fsl/p1022si-post.dtsi | 2 +- arch/powerpc/boot/dts/fsl/p1022si-pre.dtsi | 1 + 2 files changed, 2 insertions(+), 1 deletion(-) [Jason Jin-R64188] Any comments about this patch? Thanks. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v9] PPC: POWERNV: move iommu_add_device earlier
The current implementation of IOMMU on sPAPR does not use iommu_ops
and therefore does not call IOMMU API's bus_set_iommu() which
1) sets iommu_ops for a bus
2) registers a bus notifier
Instead, PCI devices are added to IOMMU groups from
subsys_initcall_sync(tce_iommu_init) which does basically the same
thing without using iommu_ops callbacks.
However Freescale PAMU driver (https://lkml.org/lkml/2013/7/1/158)
implements iommu_ops and when tce_iommu_init is called, every PCI device
is already added to some group so there is a conflict.
This patch does 2 things:
1. removes the loop in which PCI devices were added to groups and
adds explicit iommu_add_device() calls to add devices as soon as they get
the iommu_table pointer assigned to them.
2. moves a bus notifier to powernv code in order to avoid conflict with
the notifier from Freescale driver.
iommu_add_device() and iommu_del_device() are public now.
Signed-off-by: Alexey Kardashevskiy a...@ozlabs.ru
---
Changes:
v9:
* removed KVM from the subject as it is not really a KVM patch so
PPC mainainter (hi Ben!) can review/include it into his tree
v8:
* added the check for iommu_group!=NULL before removing device from a group
as suggested by Wei Yang weiy...@linux.vnet.ibm.com
v2:
* added a helper - set_iommu_table_base_and_group - which does
set_iommu_table_base() and iommu_add_device()
---
arch/powerpc/include/asm/iommu.h| 9 +++
arch/powerpc/kernel/iommu.c | 41 +++--
arch/powerpc/platforms/powernv/pci-ioda.c | 8 +++---
arch/powerpc/platforms/powernv/pci-p5ioc2.c | 2 +-
arch/powerpc/platforms/powernv/pci.c| 33 ++-
arch/powerpc/platforms/pseries/iommu.c | 8 +++---
6 files changed, 55 insertions(+), 46 deletions(-)
diff --git a/arch/powerpc/include/asm/iommu.h b/arch/powerpc/include/asm/iommu.h
index c34656a..19ad77f 100644
--- a/arch/powerpc/include/asm/iommu.h
+++ b/arch/powerpc/include/asm/iommu.h
@@ -103,6 +103,15 @@ extern struct iommu_table *iommu_init_table(struct
iommu_table * tbl,
int nid);
extern void iommu_register_group(struct iommu_table *tbl,
int pci_domain_number, unsigned long pe_num);
+extern int iommu_add_device(struct device *dev);
+extern void iommu_del_device(struct device *dev);
+
+static inline void set_iommu_table_base_and_group(struct device *dev,
+ void *base)
+{
+ set_iommu_table_base(dev, base);
+ iommu_add_device(dev);
+}
extern int iommu_map_sg(struct device *dev, struct iommu_table *tbl,
struct scatterlist *sglist, int nelems,
diff --git a/arch/powerpc/kernel/iommu.c b/arch/powerpc/kernel/iommu.c
index 572bb5b..ecbf468 100644
--- a/arch/powerpc/kernel/iommu.c
+++ b/arch/powerpc/kernel/iommu.c
@@ -1105,7 +1105,7 @@ void iommu_release_ownership(struct iommu_table *tbl)
}
EXPORT_SYMBOL_GPL(iommu_release_ownership);
-static int iommu_add_device(struct device *dev)
+int iommu_add_device(struct device *dev)
{
struct iommu_table *tbl;
int ret = 0;
@@ -1134,46 +1134,13 @@ static int iommu_add_device(struct device *dev)
return ret;
}
+EXPORT_SYMBOL_GPL(iommu_add_device);
-static void iommu_del_device(struct device *dev)
+void iommu_del_device(struct device *dev)
{
iommu_group_remove_device(dev);
}
-
-static int iommu_bus_notifier(struct notifier_block *nb,
- unsigned long action, void *data)
-{
- struct device *dev = data;
-
- switch (action) {
- case BUS_NOTIFY_ADD_DEVICE:
- return iommu_add_device(dev);
- case BUS_NOTIFY_DEL_DEVICE:
- iommu_del_device(dev);
- return 0;
- default:
- return 0;
- }
-}
-
-static struct notifier_block tce_iommu_bus_nb = {
- .notifier_call = iommu_bus_notifier,
-};
-
-static int __init tce_iommu_init(void)
-{
- struct pci_dev *pdev = NULL;
-
- BUILD_BUG_ON(PAGE_SIZE IOMMU_PAGE_SIZE);
-
- for_each_pci_dev(pdev)
- iommu_add_device(pdev-dev);
-
- bus_register_notifier(pci_bus_type, tce_iommu_bus_nb);
- return 0;
-}
-
-subsys_initcall_sync(tce_iommu_init);
+EXPORT_SYMBOL_GPL(iommu_del_device);
#else
diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c
b/arch/powerpc/platforms/powernv/pci-ioda.c
index 084cdfa..614356c 100644
--- a/arch/powerpc/platforms/powernv/pci-ioda.c
+++ b/arch/powerpc/platforms/powernv/pci-ioda.c
@@ -460,7 +460,7 @@ static void pnv_pci_ioda_dma_dev_setup(struct pnv_phb *phb,
struct pci_dev *pdev
return;
pe = phb-ioda.pe_array[pdn-pe_number];
- set_iommu_table_base(pdev-dev, pe-tce32_table);
+ set_iommu_table_base_and_group(pdev-dev, pe-tce32_table);
}
static void pnv_ioda_setup_bus_dma(struct pnv_ioda_pe *pe, struct pci_bus *bus)
@@ -468,7 +468,7 @@ static void
Re: Problem reading and programming memory location...
On Tue, 12 Nov 2013 20:23:20 +0100 neorf3k neor...@gmail.com wrote: we have tried to read and program an 8bit register with 32bit address. we have mapped it with: ioremap, kmalloc etc… and then using: outb, iowrite8 etc.. but when we write to it, the value doesn’t change… with other memory location is ok. That is an 8 bit register, located at 0x1002 in a mpc5200b architecture. we are using kernel 2.6.33. what could be? 0x1002 is not in the internal register memory map, so it is probably a device on the LocalPlus bus. Did you configure the chip select parameters for this device and did you enable the associated chip select? HTH, Anatolij ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
