Re: PROBLEM: USB isochronous urb leak on EHCI driver
On Wed, Jan 7, 2015 at 2:22 AM, Alan Stern wrote: > On Tue, 6 Jan 2015, Michael Tessier wrote: > >> > > > > That is interresting, however, I have an older kernel running an >> > > > > OHCI driver which is able to handle 4 codecs. Same usb hardware >> > > > > (codecs and hub), but older kernel on a different CPU, with much >> > > > > less power. This makes me believe that there's a solution to make it >> > > > > work... >> > > > >> > > > Of course there is: Install an OHCI host controller and use it to >> > > > drive your codecs. It should work fine. >> >> What do you mean by that? The host controller is embedded in the i.MX CPU... >> Changing the CPU is not really an option to me. Unless I am missing >> something? > > I didn't realize you were talking about an i.MX-based system. On a > computer with a free PCI slot, it's easy to add an OHCI controller. > iMX isn't as accomodating. > iMX uses chipidea controller which TT is build-in, and it does NOT support OHCI controller. > If there's no way to add an extra USB controller to your system then > the only choice is to upgrade the driver software. > > Alan Stern > > -- > To unsubscribe from this list: send the line "unsubscribe linux-usb" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- BR, Peter Chen ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] cxl: remove redundant increment of hwirq
Acked-By: Ian Munsie ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 2/2] powerpc: Add memcmp testcase
Add a testcase for the new ppc64 memcmp.
Signed-off-by: Anton Blanchard
---
.../testing/selftests/powerpc/stringloops/Makefile | 21 +
.../selftests/powerpc/stringloops/asm/ppc_asm.h| 7 ++
.../selftests/powerpc/stringloops/memcmp_64.S | 1 +
.../selftests/powerpc/stringloops/test_memcmp.c| 103 +
4 files changed, 132 insertions(+)
create mode 100644 tools/testing/selftests/powerpc/stringloops/Makefile
create mode 100644 tools/testing/selftests/powerpc/stringloops/asm/ppc_asm.h
create mode 12 tools/testing/selftests/powerpc/stringloops/memcmp_64.S
create mode 100644 tools/testing/selftests/powerpc/stringloops/test_memcmp.c
diff --git a/tools/testing/selftests/powerpc/stringloops/Makefile
b/tools/testing/selftests/powerpc/stringloops/Makefile
new file mode 100644
index 000..159a299
--- /dev/null
+++ b/tools/testing/selftests/powerpc/stringloops/Makefile
@@ -0,0 +1,21 @@
+# The loops are all 64-bit code
+CFLAGS += -m64
+CFLAGS += -I$(CURDIR)
+CFLAGS += -D SELFTEST
+
+PROGS := test_memcmp
+EXTRA_SOURCES := memcmp_64.S ../harness.c
+
+all: $(PROGS)
+
+$(PROGS): $(EXTRA_SOURCES)
+
+run_tests: all
+ @-for PROG in $(PROGS); do \
+ ./$$PROG; \
+ done;
+
+clean:
+ rm -f $(PROGS) *.o
+
+.PHONY: all run_tests clean
diff --git a/tools/testing/selftests/powerpc/stringloops/asm/ppc_asm.h
b/tools/testing/selftests/powerpc/stringloops/asm/ppc_asm.h
new file mode 100644
index 000..11bece8
--- /dev/null
+++ b/tools/testing/selftests/powerpc/stringloops/asm/ppc_asm.h
@@ -0,0 +1,7 @@
+#include
+
+#ifndef r1
+#define r1 sp
+#endif
+
+#define _GLOBAL(A) FUNC_START(test_ ## A)
diff --git a/tools/testing/selftests/powerpc/stringloops/memcmp_64.S
b/tools/testing/selftests/powerpc/stringloops/memcmp_64.S
new file mode 12
index 000..9bc87e4
--- /dev/null
+++ b/tools/testing/selftests/powerpc/stringloops/memcmp_64.S
@@ -0,0 +1 @@
+../../../../../arch/powerpc/lib/memcmp_64.S
\ No newline at end of file
diff --git a/tools/testing/selftests/powerpc/stringloops/test_memcmp.c
b/tools/testing/selftests/powerpc/stringloops/test_memcmp.c
new file mode 100644
index 000..17417dd
--- /dev/null
+++ b/tools/testing/selftests/powerpc/stringloops/test_memcmp.c
@@ -0,0 +1,103 @@
+#include
+#include
+#include
+#include "../utils.h"
+
+#define SIZE 256
+#define ITERATIONS 1
+
+int test_memcmp(const void *s1, const void *s2, size_t n);
+
+/* test all offsets and lengths */
+static void test_one(char *s1, char *s2)
+{
+ unsigned long offset, size;
+
+ for (offset = 0; offset < SIZE; offset++) {
+ for (size = 0; size < (SIZE-offset); size++) {
+ int x, y;
+ unsigned long i;
+
+ y = memcmp(s1+offset, s2+offset, size);
+ x = test_memcmp(s1+offset, s2+offset, size);
+
+ if (((x ^ y) < 0) &&/* Trick to compare sign */
+ ((x | y) != 0)) { /* check for zero */
+ printf("memcmp returned %d, should have
returned %d (offset %ld size %ld)\n", x, y, offset, size);
+
+ for (i = offset; i < offset+size; i++)
+ printf("%02x ", s1[i]);
+ printf("\n");
+
+ for (i = offset; i < offset+size; i++)
+ printf("%02x ", s2[i]);
+ printf("\n");
+ abort();
+ }
+ }
+ }
+}
+
+static int testcase(void)
+{
+ char *s1;
+ char *s2;
+ unsigned long i;
+
+ s1 = memalign(128, SIZE);
+ if (!s1) {
+ perror("memalign");
+ exit(1);
+ }
+
+ s2 = memalign(128, SIZE);
+ if (!s2) {
+ perror("memalign");
+ exit(1);
+ }
+
+ srandom(1);
+
+ for (i = 0; i < ITERATIONS; i++) {
+ unsigned long j;
+ unsigned long change;
+
+ for (j = 0; j < SIZE; j++)
+ s1[j] = random();
+
+ memcpy(s2, s1, SIZE);
+
+ /* change one byte */
+ change = random() % SIZE;
+ s2[change] = random() & 0xff;
+
+ test_one(s1, s2);
+ }
+
+ srandom(1);
+
+ for (i = 0; i < ITERATIONS; i++) {
+ unsigned long j;
+ unsigned long change;
+
+ for (j = 0; j < SIZE; j++)
+ s1[j] = random();
+
+ memcpy(s2, s1, SIZE);
+
+ /* change multiple bytes, 1/8 of total */
+ for (j = 0; j < SIZE / 8; j++) {
+ change = random() % SIZE;
+ s2[change] = random() & 0xff;
+ }
+
+ test_one(s1, s2);
+ }
+
+ return 0;
+}
+
+int mai
[PATCH 1/2] powerpc: Add 64bit optimised memcmp
I noticed ksm spending quite a lot of time in memcmp on a large KVM box. The current memcmp loop is very unoptimised - byte at a time compares with no loop unrolling. We can do much much better. Optimise the loop in a few ways: - Unroll the byte at a time loop - For large (at least 32 byte) comparisons that are also 8 byte aligned, use an unrolled modulo scheduled loop using 8 byte loads. This is similar to our glibc memcmp. A simple microbenchmark testing 1000 iterations of an 8192 byte memcmp was used to measure the performance: baseline: 29.93 s modified:1.70 s Just over 17x faster. Signed-off-by: Anton Blanchard --- arch/powerpc/lib/Makefile| 3 +- arch/powerpc/lib/memcmp_64.S | 233 +++ arch/powerpc/lib/string.S| 2 + 3 files changed, 237 insertions(+), 1 deletion(-) create mode 100644 arch/powerpc/lib/memcmp_64.S diff --git a/arch/powerpc/lib/Makefile b/arch/powerpc/lib/Makefile index 1b01159..5526156 100644 --- a/arch/powerpc/lib/Makefile +++ b/arch/powerpc/lib/Makefile @@ -15,7 +15,8 @@ obj-$(CONFIG_PPC32) += div64.o copy_32.o obj-$(CONFIG_PPC64)+= copypage_64.o copyuser_64.o \ usercopy_64.o mem_64.o hweight_64.o \ - copyuser_power7.o string_64.o copypage_power7.o + copyuser_power7.o string_64.o copypage_power7.o \ + memcmp_64.o ifeq ($(CONFIG_GENERIC_CSUM),) obj-y += checksum_$(CONFIG_WORD_SIZE).o obj-$(CONFIG_PPC64)+= checksum_wrappers_64.o diff --git a/arch/powerpc/lib/memcmp_64.S b/arch/powerpc/lib/memcmp_64.S new file mode 100644 index 000..d71880b --- /dev/null +++ b/arch/powerpc/lib/memcmp_64.S @@ -0,0 +1,233 @@ +/* + * Author: Author: Anton Blanchard + * Copyright 2015 IBM Corporation. + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License + * as published by the Free Software Foundation; either version + * 2 of the License, or (at your option) any later version. + */ +#include + +#define off8 r6 +#define off16 r7 +#define off24 r8 + +#define rA r9 +#define rB r10 +#define rC r11 +#define rD r27 +#define rE r28 +#define rF r29 +#define rG r30 +#define rH r31 + +#ifdef __LITTLE_ENDIAN__ +#define LD ldbrx +#else +#define LD ldx +#endif + +_GLOBAL(memcmp) + cmpdi cr1,r5,0 + + /* Use the short loop if both strings are not 8B aligned */ + or r6,r3,r4 + rldicl. r6,r6,0,(64-3) + + /* Use the short loop if length is less than 32B */ + cmpdi cr5,r5,31 + + beq cr1,.Lzero + bne .Lshort + bgt cr5,.Llong + +.Lshort: + mtctr r5 + +1: lbz rA,0(r3) + lbz rB,0(r4) + subf. rC,rB,rA + bne .Lnon_zero + bdz .Lzero + + lbz rA,1(r3) + lbz rB,1(r4) + subf. rC,rB,rA + bne .Lnon_zero + bdz .Lzero + + lbz rA,2(r3) + lbz rB,2(r4) + subf. rC,rB,rA + bne .Lnon_zero + bdz .Lzero + + lbz rA,3(r3) + lbz rB,3(r4) + subf. rC,rB,rA + bne .Lnon_zero + + addir3,r3,4 + addir4,r4,4 + + bdnzt eq,1b + +.Lzero: + li r3,0 + blr + +.Lnon_zero: + mr r3,rC + blr + +.Llong: + li off8,8 + li off16,16 + li off24,24 + + std r31,-8(r1) + std r30,-16(r1) + std r29,-24(r1) + std r28,-32(r1) + std r27,-40(r1) + + srdir0,r5,5 + mtctr r0 + andi. r5,r5,31 + + LD rA,0,r3 + LD rB,0,r4 + + LD rC,off8,r3 + LD rD,off8,r4 + + LD rE,off16,r3 + LD rF,off16,r4 + + LD rG,off24,r3 + LD rH,off24,r4 + cmpld cr0,rA,rB + + addir3,r3,32 + addir4,r4,32 + + bdz .Lfirst32 + + LD rA,0,r3 + LD rB,0,r4 + cmpld cr1,rC,rD + + LD rC,off8,r3 + LD rD,off8,r4 + cmpld cr5,rE,rF + + LD rE,off16,r3 + LD rF,off16,r4 + cmpld cr6,rG,rH + bne cr0,.LcmpAB + + LD rG,off24,r3 + LD rH,off24,r4 + cmpld cr0,rA,rB + bne cr1,.LcmpCD + + addir3,r3,32 + addir4,r4,32 + + bdz .Lsecond32 + + .balign 16 + +1: LD rA,0,r3 + LD rB,0,r4 + cmpld cr1,rC,rD + bne cr5,.LcmpEF + + LD rC,off8,r3 + LD rD,off8,r4 + cmpld cr5,rE,rF + bne cr6,.LcmpGH + + LD rE,off16,r3 + LD rF,off16,r4 + cmpld cr6,rG,rH + bne cr0,.LcmpAB + + LD rG,off24,r3 + LD rH,off24,r4 + cmpld cr0,rA,rB + bne cr1,.Lcmp
[PATCH] cxl: remove redundant increment of hwirq
From: Colin Ian King
hwirq has not been initialized, however it is being incremented
and also not being referenced in a loop. This error was detected with
cppcheck:
[drivers/misc/cxl/irq.c:439]: (error) Uninitialized variable: hwirq
Commit 80fa93fce37d ("cxl: Name interrupts in /proc/interrupt")
introduced this error.
This is a simple fix that removes the redundant increment.
Signed-off-by: Colin Ian King
---
drivers/misc/cxl/irq.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/misc/cxl/irq.c b/drivers/misc/cxl/irq.c
index c294925..68ab608 100644
--- a/drivers/misc/cxl/irq.c
+++ b/drivers/misc/cxl/irq.c
@@ -436,7 +436,7 @@ int afu_register_irqs(struct cxl_context *ctx, u32 count)
*/
INIT_LIST_HEAD(&ctx->irq_names);
for (r = 1; r < CXL_IRQ_RANGES; r++) {
- for (i = 0; i < ctx->irqs.range[r]; hwirq++, i++) {
+ for (i = 0; i < ctx->irqs.range[r]; i++) {
irq_name = kmalloc(sizeof(struct cxl_irq_name),
GFP_KERNEL);
if (!irq_name)
--
2.1.4
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] cxl: remove redundant increment of hwirq
On Thu, 2015-01-08 at 22:36 +, Colin King wrote:
> From: Colin Ian King
>
> hwirq has not been initialized, however it is being incremented
> and also not being referenced in a loop. This error was detected with
> cppcheck:
>
> [drivers/misc/cxl/irq.c:439]: (error) Uninitialized variable: hwirq
>
> Commit 80fa93fce37d ("cxl: Name interrupts in /proc/interrupt")
> introduced this error.
>
> This is a simple fix that removes the redundant increment.
>
> Signed-off-by: Colin Ian King
Thanks. Looks good.
Acked-By: Michael Neuling
> ---
> drivers/misc/cxl/irq.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/misc/cxl/irq.c b/drivers/misc/cxl/irq.c
> index c294925..68ab608 100644
> --- a/drivers/misc/cxl/irq.c
> +++ b/drivers/misc/cxl/irq.c
> @@ -436,7 +436,7 @@ int afu_register_irqs(struct cxl_context *ctx, u32 count)
>*/
> INIT_LIST_HEAD(&ctx->irq_names);
> for (r = 1; r < CXL_IRQ_RANGES; r++) {
> - for (i = 0; i < ctx->irqs.range[r]; hwirq++, i++) {
> + for (i = 0; i < ctx->irqs.range[r]; i++) {
> irq_name = kmalloc(sizeof(struct cxl_irq_name),
> GFP_KERNEL);
> if (!irq_name)
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC] PPC: MPIC: necessary readback after EOI?
On Wed, 2015-01-07 at 11:04 -0600, Scott Wood wrote: > On Wed, 2015-01-07 at 15:44 +0100, Benjamin Herrenschmidt wrote: > > On Mon, 2015-01-05 at 12:10 -0600, Scott Wood wrote: > > > It would have been nice if a code comment explained why it was doing the > > > readback... I don't see any particular need to wait for EOI completion > > > here (unlike when masking). > > > > The EOI is what causes the MPIC to drop it's EE output to the CPU, if the > > EOI is processed too slowly & asynchronously (posted write + 33Mhz MPIC) > > we observe cases of spurrious interrupts. We had some macs basically getting > > a spurrious irq for every MPIC interrupts... > > Shouldn't reading INTACK be what causes the MPIC to drop its EE output? Hrm, looks like I had too much wine or something, you are correct yes, it's the intack, so my explanation is bogus. So we are down to possibly delaying the raising back of the CPU priority which is not a big deal indeed, we could probably get rid of the read back. Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
How to make use of SPE instructions?
Hello, I developed a SHA224/256 kernel crypto module with SPE instructions. The result looks quite promising (~ +50% speedup). Nevertheless the flooding of kernel messages "SPE used in kernel" makes me feel uncomfortable. My findings so far: - I can configure the kernel with "SPE support". - arch/powerpc/kernel/head_fsl_booke.S suggests that the message is triggerd unconditionally whenwever we make use of SPE in kernel. - There exists a function enable_kernel_spe() but I don't know how this could help me in my work. I guess I need some kind of "brackets" around my coding to make sure the upper 32 bit of the registers are stored correctly during task switch. Or is the use of SPE instructions inside the kernel totally forbidden? Any expert with some helpful advise? Thanks in advance. Markus Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail ist nicht gestattet. Ãber das Internet versandte E-Mails können unter fremden Namen erstellt oder manipuliert werden. Deshalb ist diese als E-Mail verschickte Nachricht keine rechtsverbindliche Willenserklärung. Collogia Unternehmensberatung AG Ubierring 11 D-50678 Köln Vorstand: Kadir Akin Dr. Michael Höhnerbach Vorsitzender des Aufsichtsrates: Hans Kristian Langva Registergericht: Amtsgericht Köln Registernummer: HRB 52 497 This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. e-mails sent over the internet may have been written under a wrong name or been manipulated. That is why this message sent as an e-mail is not a legally binding declaration of intention. Collogia Unternehmensberatung AG Ubierring 11 D-50678 Köln executive board: Kadir Akin Dr. Michael Höhnerbach President of the supervisory board: Hans Kristian Langva Registry office: district court Cologne Register number: HRB 52 497 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v7 0/4] Add support for parametrized events
On Wed, Jan 07, 2015 at 05:13:49PM -0800, Sukadev Bhattiprolu wrote: > Description of "event parameters" from the documentation patch: > > Event parameters are a basic way for partial events to be specified in > sysfs with per-event names given to the fields that need to be filled in > when using a particular event. > > It is intended for supporting cases where the single 'cpu' parameter is > insufficient. For example, POWER 8 has events for physical > sockets/cores/cpus that are accessible from with virtual machines. To > keep using the single 'cpu' parameter we'd need to perform a mapping > between Linux's cpus and the physical machine's cpus (in this case > Linux is running under a hypervisor). This isn't possible because > bindings between our cpus and physical cpus may not be fixed, and we > probably won't have a "cpu" on each physical cpu. > > Description of the sysfs contents when events are parameterized (copied from > an > included patch): > > Examples: > > domain=0x1,offset=0x8,core=? > > In the case of the last example, a value replacing "?" would need > to be provided by the user selecting the particular event. This is > refered to as "event parameterization". All non-numerical values > indicate an event parameter. > > Notes on how perf-list displays parameterized events > > PARAMETERIZED EVENTS > > > Some pmu events listed by 'perf list' will be displayed with '$xyz' in > them. For example: > > hv_24x7/HPM_THREAD_NAP_CCYC__PHYS_CORE,core=?/ > > This means that when provided as an event, a value for ? must also > be supplied. For example: > > perf stat -e \ > 'hv_24x7/HPM_THREAD_NAP_CCYC__PHYS_CORE,core=2' ... > > Changelog[v7] > [Jiri Olsa] Nit: Add braces for clarity. > [Jiri Olsa] Add a check to make sure that sysfs entries have with > parameters exactly match '=?'. for the patchset: Acked-by: Jiri Olsa thanks, jirka ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] [v3] power/fsl: add MDIO dt binding for FMan
Hello Scott, On 01/07/2015 07:12 PM, Scott Wood wrote: > On Wed, 2015-01-07 at 13:44 -0600, Emil Medve wrote: >> Hello Scott, >> >> >> On 01/07/2015 12:05 PM, Scott Wood wrote: >>> On Tue, 2015-01-06 at 23:29 -0600, Xie Shaohui-B21989 wrote: >>> +- interrupts >>> + Usage: optional >>> + Value type: >>> + Definition: Event interrupt of external MDIO controller. >>> + 1 Gb/s MDIO and 10 Gb/s MDIO has one interrupt >>> respectively. > > I'm confused by "respectively" here. Does fsl,fman-memac-mdio have two > interrupts (one for 1 Gb/s and one for 10 Gb/s)? [S.H] We use two MDIO controllers for external PHY management. One for 1 Gb/s, One for 10 Gb/s, and two MDIO interrupts connected to MPIC. >>> >>> If there can be two interrupts you need to make that clear and specify >>> the order. >>> >>> Is it possible for one MDIO controller to have an interrupt connected >>> but not the other, on the same system? How would you represent that in >>> the device tree? If there are two MDIO controllers why are they in the >>> same node? >> >> Historically (FMan v2 and even before/legacy) we've had each MAC include >> an MDIO controller, but only one MDIO controller per MAC type/speed (1 >> Gb/s vs 10 Gb/s) is pinned out and all the same speed PHY(s) are >> connected to the respective MDIO controllers. As such the first 1 Gb/s >> MAC/MDIO controller is used to manage all the 1 Gb/s PHY(s) and the >> first 10 Gb/s MAC/MDIO controller is used to manage all the 10 Gb/s >> PHY(s). Each MDIO controller has the ability to generate interrupts but >> only pinned out MDIO controllers are hooked up to the MPIC (as such the >> talk about two interrupts) >> >> (Each MAC has also integrated a SERDES/TBI/"internal" PHY that is >> connected to the "local" MDIO controller) >> >> As you can imagine this creates a number of problems in a partitioning >> scenario (and not just, imagine RCWs where the first MAC is not >> used/enabled). In order to help a bit (but not quite enough), in FMan >> v3, two additional MDIO controllers (one for 1 the Gb/s PHY(s) and one >> for 1 the 10 Gb/s PHY(s)) have been integrated that are not associated >> with any MAC and these are the pinned out MDIO controllers on such >> SoC(s) (chassis v2) > > I'm happy to hear that. Is that what is meant by "external" here? "External" doesn't mean external to the MAC nodes. "External" doesn't even properly apply to the MDIO controller(s) at all but to the PHY(s). > I thought it meant external to the SoC. Is this the term used by > hardware documentation? The documentation (mostly chip errata documents) refers to external/internal MDIO accesses and as on FMan v3 external PHY accesses are always made via these extra MDIO controllers (pinned oud) and the internal SERDES PHY accesses are always made via the in-MAC MDIO controllers some level of confusion is easy to be achieved. All the MDIO controllers are identical whether they are in-MAC or standalone > I'd have called it "independent" or similar. To make things even more confusing, some documents call these extra MDIO controllers "dedicated" Cheers, Does "optional" mean it's used if and > only if external MDIO is used, or is it optional even with external MDIO? > I see > it's not present in the example -- do we not have a real example that has > the > interrupt? [S.H] "optional" means it's available on hardware, but MDIO driver does not use interrupt. So we don't have a real example. >>> >>> The device tree describes the hardware, not the >>> driver >> >> Anyway, only two MDIO nodes (out of 4 to 14) would have an interrupt >> property describing exactly one interrupt. What language should we use >> to convey this situation > > So the answer is that there will not be more than one MDIO controller > per MDIO node, or more than one interrupt per MDIO node? In that case > just get rid of the confusing "respectively" sentence -- and always > describe the interrupt if it exists in hardware. > > -Scott > > > . > ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH RFT/RFC] powerpc: move cacheinfo sysfs to generic cacheinfo infrastructure
This patch removes the redundant sysfs cacheinfo code by reusing
the newly introduced generic cacheinfo infrastructure through the
commit 246246cbde5e ("drivers: base: support cpu cache information
interface to userspace via sysfs")
Signed-off-by: Sudeep Holla
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Cc: Michael Ellerman
Cc: Anshuman Khandual
Cc: linuxppc-dev@lists.ozlabs.org
---
arch/powerpc/kernel/cacheinfo.c | 812 +---
arch/powerpc/kernel/cacheinfo.h | 8 -
arch/powerpc/kernel/sysfs.c | 12 +-
3 files changed, 90 insertions(+), 742 deletions(-)
delete mode 100644 arch/powerpc/kernel/cacheinfo.h
Hi,
This patch is not tested. Last time Anshuman tested, he had seen issues.
The core driver has changed a lot after that. Since PPC depends a lot
on DT for cache information, there might be issues in the core later
which I could not identify with ARM/ARM64. It would be much appreciable
if someone help me in testing and fixing those so that PPC can migrate
to new/common cacheinfo infrastructure.
Regards,
Sudeep
diff --git a/arch/powerpc/kernel/cacheinfo.c b/arch/powerpc/kernel/cacheinfo.c
index 40198d50b4c2..6845eb7fcc18 100644
--- a/arch/powerpc/kernel/cacheinfo.c
+++ b/arch/powerpc/kernel/cacheinfo.c
@@ -10,38 +10,10 @@
* 2 as published by the Free Software Foundation.
*/
+#include
#include
-#include
#include
-#include
-#include
-#include
#include
-#include
-#include
-#include
-
-#include "cacheinfo.h"
-
-/* per-cpu object for tracking:
- * - a "cache" kobject for the top-level directory
- * - a list of "index" objects representing the cpu's local cache hierarchy
- */
-struct cache_dir {
- struct kobject *kobj; /* bare (not embedded) kobject for cache
- * directory */
- struct cache_index_dir *index; /* list of index objects */
-};
-
-/* "index" object: each cpu's cache directory has an index
- * subdirectory corresponding to a cache object associated with the
- * cpu. This object's lifetime is managed via the embedded kobject.
- */
-struct cache_index_dir {
- struct kobject kobj;
- struct cache_index_dir *next; /* next index in parent directory */
- struct cache *cache;
-};
/* Template for determining which OF properties to query for a given
* cache type */
@@ -60,11 +32,6 @@ struct cache_type_info {
const char *nr_sets_prop;
};
-/* These are used to index the cache_type_info array. */
-#define CACHE_TYPE_UNIFIED 0
-#define CACHE_TYPE_INSTRUCTION 1
-#define CACHE_TYPE_DATA2
-
static const struct cache_type_info cache_type_info[] = {
{
/* PowerPC Processor binding says the [di]-cache-*
@@ -92,231 +59,82 @@ static const struct cache_type_info cache_type_info[] = {
},
};
-/* Cache object: each instance of this corresponds to a distinct cache
- * in the system. There are separate objects for Harvard caches: one
- * each for instruction and data, and each refers to the same OF node.
- * The refcount of the OF node is elevated for the lifetime of the
- * cache object. A cache object is released when its shared_cpu_map
- * is cleared (see cache_cpu_clear).
- *
- * A cache object is on two lists: an unsorted global list
- * (cache_list) of cache objects; and a singly-linked list
- * representing the local cache hierarchy, which is ordered by level
- * (e.g. L1d -> L1i -> L2 -> L3).
- */
-struct cache {
- struct device_node *ofnode;/* OF node for this cache, may be cpu */
- struct cpumask shared_cpu_map; /* online CPUs using this cache */
- int type; /* split cache disambiguation */
- int level; /* level not explicit in device tree */
- struct list_head list; /* global list of cache objects */
- struct cache *next_local; /* next cache of >= level */
-};
-
-static DEFINE_PER_CPU(struct cache_dir *, cache_dir_pcpu);
-
-/* traversal/modification of this list occurs only at cpu hotplug time;
- * access is serialized by cpu hotplug locking
- */
-static LIST_HEAD(cache_list);
-
-static struct cache_index_dir *kobj_to_cache_index_dir(struct kobject *k)
-{
- return container_of(k, struct cache_index_dir, kobj);
-}
-
-static const char *cache_type_string(const struct cache *cache)
+static inline int get_cacheinfo_idx(enum cache_type type)
{
- return cache_type_info[cache->type].name;
-}
-
-static void cache_init(struct cache *cache, int type, int level,
- struct device_node *ofnode)
-{
- cache->type = type;
- cache->level = level;
- cache->ofnode = of_node_get(ofnode);
- INIT_LIST_HEAD(&cache->list);
- list_add(&cache->list, &cache_list);
-}
-
-static struct cache *new_cache(int type, int level, struct device_node *ofnode)
-{
- struct cache *cache;
-
- cache = kzalloc(sizeof(*cache), GFP_KERNEL);
- if (cache)
- cache_init(cache, type, lev
