Re: powerpc: Add an inline function to update HID0
Hi Segher,
Thanks for the suggestions. I will rename the function to
update_power8_hid0() and use asm volatile.
On Tue, Aug 04, 2015 at 09:30:57PM -0500, Segher Boessenkool wrote:
> On Tue, Aug 04, 2015 at 08:08:58PM +1000, Michael Ellerman wrote:
> > > +static inline void update_hid0(unsigned long hid0)
> > > +{
> > > + /*
> > > + * The HID0 update should at the very least be preceded by a
> > > + * a SYNC instruction followed by an ISYNC instruction
> > > + */
> > > + mb();
> > > + mtspr(SPRN_HID0, hid0);
> > > + isync();
> >
> > That's going to turn into three separate inline asm blocks, which is maybe a
> > bit unfortunate. Have you checked the generated code is what we want, ie.
> > just
> > sync, mtspr, isync ?
>
> The "mb()" is not such a great name anyway: you don't want a memory
> barrier, you want an actual sync instruction ("sync 0", "hwsync",
> whatever the currently preferred spelling is).
>
> The function name should also say this is for POWER8 (the required
> sequences are different for some other processors; and some others
> might not even _have_ a HID0, or not at 1008). power8_write_hid0
> or such?
>
> For writing it as one asm, why not just
>
> asm volatile("sync ; mtspr %0,%1 ; isync" : : "i"(SPRN_HID0), "r"(hid0));
>
> instead of the stringify stuff?
>
>
> Segher
>
--
Thanks and Regards
gautham.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: GPMC in device tree
On Wed, Aug 5, 2015 at 6:56 AM, Ran Shalit wrote: > On Wed, Aug 5, 2015 at 12:25 AM, Scott Wood wrote: >> On Wed, 2015-08-05 at 00:22 +0300, Ran Shalit wrote: >>> On Tue, Aug 4, 2015 at 11:31 PM, Scott Wood wrote: >>> > On Tue, 2015-08-04 at 23:26 +0300, Ran Shalit wrote: >>> > > On Tue, Aug 4, 2015 at 9:54 PM, Scott Wood >>> > > wrote: >>> > > > On Tue, 2015-08-04 at 18:29 +0300, Ran Shalit wrote: >>> > > > > Hello, >>> > > > > >>> > > > > I would please like to ask if describing flash nor used with GPMC, >>> > > > > whould be done as described in: >>> > > > > https://www.kernel.org/doc/Documentation/devicetree/bindings/mtd/gpmc-nor.txt >>> > > > > It is described in the above link as "TI's GPMC", so I'm not sure if >>> > > > > it is relevent for powerpc too. >>> > > > >>> > > > That binding is for TI GPMC. >>> > > > >>> > > > Are you saying you have some PPC chip that has a flash controller >>> > > > called >>> > > > GPMC? >>> > > > >>> > > > -Scott >>> > > > >>> > > >>> > > Hi Scott, >>> > > >>> > > Thanks, I've worked with TI's chips, so I now understand that I made >>> > > here some confusion... >>> > > It is GPCM , not GPMC, my mistake. >>> > > We already configured it in u-boot, but on doing read/write from >>> > > kernel it doesn not work. >>> > > It seems that for the linux to use the correct driver, we need to >>> > > define the nor in the device tree. >>> > > Is there any example how to define nor GPCM in device tree ? Is it >>> > > possible not to override the existing GPCM configuration ? >>> > >>> > Pretty much all of the mpc8xxx/qoriq device trees have GPCM NOR defined. >>> > See >>> > Documentation/devicetree/bindings/powerpc/fsl/lbc.txt and examples such as >>> > arch/powerpc/boot/dts/p4080ds.dts (part of the lbc node is in >>> > arch/powerpc/boot/dts/fsl/p4080si-post.dtsi). >>> > >>> > Linux will not change the GPCM configuration. >>> > >>> > -Scott >>> > >>> >>> On more thing, if I may. >>> The localbus is also connected to nvram & cpld. >>> I've noticed that read/write works well, even though I didn't define >>> anything in device tree. >>> Is there any reasom to add these devices into device tree, or can we >>> use the cpld and nvram without the definition in device tree ? >> >> I don't know what you're doing in your kernel to access devices that aren't >> in the device tree. You should add the devices to the device tree, and have >> the kernel use it rather than hardcoded info. >> >> -Scott >> > Hi, > > Yes I understand. > But It is worse noting that I have no localbus entry in the device tree. > Yes, The nvram, cpld which are both connected to device tree, seems to > work without any issues. > > Thanks, > Ran I apologyze for the bad english, I meant "it worth to note" that there is no localbus entry at all in the device tree. So I wander how the nvram and cpld worked... If I may please ask, what should be the "compatible" for generic devices such as nvram/cpld ? I assume that if they worked without any entry, it means that there is no need for specific driver. Regards, Ran ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/5] powerpc/pseries: extract of_helpers module
Hi Andy,
On Tue, Aug 04, 2015 at 05:36:45PM +0300, Andy Shevchenko wrote:
> +struct device_node *pseries_of_derive_parent(const char *path)
> +{
> + struct device_node *parent = NULL;
> + char *parent_path = "/";
> + size_t parent_path_len = strrchr(path, '/') - path + 1;
> +
> + /* reject if path is "/" */
> + if (!strcmp(path, "/"))
> + return ERR_PTR(-EINVAL);
> +
> + if (strrchr(path, '/') != path) {
> + parent_path = kmalloc(parent_path_len, GFP_KERNEL);
If path doesn't contain any slash this will do interesting things;
you might want to fix that too while you're at it :-)
Segher
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [1/2] powerpc/config: enable teranetics PHY
> On Tue, 2015-08-04 at 19:24 -0500, Scott Wood wrote: > > On Tue, 2015-08-04 at 19:18 -0500, Scott Wood wrote: > > > On Fri, Jul 24, 2015 at 11:45:33AM +0800, shaohui xie wrote: > > > > From: Shaohui Xie > > > > > > > > The PHY uses XAUI interface to connect to MAC, mostly the PHY used > > > > on riser card. > > > > > > > > Signed-off-by: Shaohui Xie > > > > --- > > > > arch/powerpc/configs/corenet32_smp_defconfig | 1 + > > > > arch/powerpc/configs/corenet64_smp_defconfig | 1 + > > > > 2 files changed, 2 insertions(+) > > > > > > Next time, please use a subject line that lets me know that this is > > > a patch that I'd be picking up, such as "powerpc/85xx: ..." or > > > "powerpc/corenet: ..." > > > > More importantly, don't send patches to enable config options that > > don't exist. > > Sorry, this comment was meant for patch 2/2 (CONFIG_AQUANTIA_PHY). > CONFIG_TERANETICS_PHY does exist in linux-next (that it depends on a > patch in linux-next should be mentioned below the ---). Hi Scott, The CONFIG_AQUANTIA_PHY was added in another patch sent to net-next, it was not accepted when I sent the patch to enable this config, later the patch was accepted in net-next, https://git.kernel.org/cgit/linux/kernel/git/davem/net-next.git/commit/?id=bee8259dd31f419a883174556b11edc6f9a153d1 I should mention this below the ---. Sorry! Should I re-send the patch of enabling config option of CONFIG_AQUANTIA_PHY? Thanks! Shaohui ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: RFC: Reducing the number of non volatile GPRs in the ppc64 kernel
Hi Anton, On Wed, Aug 05, 2015 at 02:03:00PM +1000, Anton Blanchard wrote: > While looking at traces of kernel workloads, I noticed places where gcc > used a large number of non volatiles. Some of these functions > did very little work, and we spent most of our time saving the > non volatiles to the stack and reading them back. That is something that should be fixed in GCC -- do you have an example of such a function? > It made me wonder if we have the right ratio of volatile to non > volatile GPRs. Since the kernel is completely self contained, we could > potentially change that ratio. > > Attached is a quick hack to gcc and the kernel to decrease the number > of non volatile GPRs to 8. I'm not sure if this is a good idea (and if > the volatile to non volatile ratio is right), but this gives us > something to play with. Instead of the GCC hack you can add a bunch of -fcall-used-r14 etc. options; does that not work for you? Segher ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: windfarm: decrement client count when unregistering
On Fri, 2015-31-07 at 12:08:58 UTC, Paul Bolle wrote:
> wf_unregister_client() increments the client count when a client
> unregisters. That is obviously incorrect. Decrement that client count
> instead.
>
> Fixes: 75722d3992f5 ("[PATCH] ppc64: Thermal control for SMU based machines")
>
> Signed-off-by: Paul Bolle
> ---
> cross-compiled only. I don't have a PPC machine at hand, sorry. And this
> does need some run-time testing, I'd day.
>
> windfarm_corex_exit() contains:
> BUG_ON(wf_client_count != 0);
>
> I wonder why that, apparently. never triggered.
Hmm interesting.
A quick test here on an iMacG5 shows that we get into a state where we can't
remove windfarm_core:
$ lsmod
Module Size Used by
windfarm_smu_sensors7549 2
windfarm_core 15391 1 windfarm_smu_sensors
Which means we can't trigger windfarm_core_exit() and the BUG_ON().
I also get an oops when removing windfarm_lm75_sensor, so I suspect there are
gremlins in the module ref counting for windfarm.
I'll merge this as probably correct.
[ cut here ]
WARNING: at ../kernel/module.c:1116
Modules linked in: windfarm_lm75_sensor(-) windfarm_smu_sensors
windfarm_smu_controls windfarm_core [last unloaded: windfarm_cpufreq_clamp]
CPU: 0 PID: 2860 Comm: modprobe Not tainted
4.2.0-rc2-00043-gf4e908dd3cbe-dirty #2
task: c0003d9c4fe0 ti: c0003df2 task.ti: c0003df2
NIP: c00d62d0 LR: d04338bc CTR: c00d62a0
REGS: c0003df23660 TRAP: 0700 Not tainted
(4.2.0-rc2-00043-gf4e908dd3cbe-dirty)
MSR: 90029032 CR: 82002884 XER: 2000
SOFTE: 1
GPR00: d04338b0 c0003df238e0 c0b27800 d0474b00
GPR04: c0003d185900 0001 3e5de000 175c
GPR08: c0a2c068 0001 d04343c0
GPR12: c00d62a0 c000 0004 0001
GPR16: ffe108bc
GPR20: 209b0278 0001
GPR24: ffe11915 209b0008 209b02ac
GPR28: c0003d1b3c80 d0474b00
NIP [c00d62d0] .module_put+0x30/0x40
LR [d04338bc] .wf_put_sensor+0x9c/0xf0 [windfarm_core]
Call Trace:
[c0003df238e0] [d04338b0] .wf_put_sensor+0x90/0xf0
[windfarm_core] (unreliable)
[c0003df23960] [d0474020] .wf_lm75_remove+0x20/0x40
[windfarm_lm75_sensor]
[c0003df239d0] [c058cb8c] .i2c_device_remove+0x7c/0xb0
[c0003df23a50] [c0450dd4] .__device_release_driver+0xb4/0x180
[c0003df23ad0] [c0451a08] .driver_detach+0x138/0x180
[c0003df23b70] [c0450720] .bus_remove_driver+0x70/0xf0
[c0003df23bf0] [c04523a8] .driver_unregister+0x38/0x70
[c0003df23c70] [c058d718] .i2c_del_driver+0x28/0x40
[c0003df23cf0] [d04743fc] .wf_lm75_driver_exit+0x18/0x2cc
[windfarm_lm75_sensor]
[c0003df23d60] [c00d82bc] .SyS_delete_module+0x18c/0x250
[c0003df23e30] [c0007c98] system_call+0x38/0xd0
Instruction dump:
2c23 4d820020 392302e0 7c2004ac 7d404828 2c0a0001 394a 41c00010
7d40492d 40c2ffec 7c0004ac 55490ffe <0b09> 4e800020 6000 6000
---[ end trace 013348a741cf9320 ]---
cheers
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [1/2] powerpc/config: enable teranetics PHY
On Tue, 2015-08-04 at 22:06 -0500, Xie Shaohui-B21989 wrote: > > -Original Message- > > From: Xie Shaohui-B21989 > > Sent: Wednesday, August 05, 2015 11:00 AM > > To: Wood Scott-B07421 > > Cc: linuxppc-dev@lists.ozlabs.org > > Subject: RE: [1/2] powerpc/config: enable teranetics PHY > > > > > On Tue, 2015-08-04 at 19:24 -0500, Scott Wood wrote: > > > > On Tue, 2015-08-04 at 19:18 -0500, Scott Wood wrote: > > > > > On Fri, Jul 24, 2015 at 11:45:33AM +0800, shaohui xie wrote: > > > > > > From: Shaohui Xie > > > > > > > > > > > > The PHY uses XAUI interface to connect to MAC, mostly the PHY > > > > > > used on riser card. > > > > > > > > > > > > Signed-off-by: Shaohui Xie > > > > > > --- > > > > > > arch/powerpc/configs/corenet32_smp_defconfig | 1 + > > > > > > arch/powerpc/configs/corenet64_smp_defconfig | 1 + > > > > > > 2 files changed, 2 insertions(+) > > > > > > > > > > Next time, please use a subject line that lets me know that this > > > > > is a patch that I'd be picking up, such as "powerpc/85xx: ..." or > > > > > "powerpc/corenet: ..." > > > > > > > > More importantly, don't send patches to enable config options that > > > > don't exist. > > > > > > Sorry, this comment was meant for patch 2/2 (CONFIG_AQUANTIA_PHY). > > > CONFIG_TERANETICS_PHY does exist in linux-next (that it depends on a > > > patch in linux-next should be mentioned below the ---). > > Hi Scott, > > > > The CONFIG_AQUANTIA_PHY was added in another patch sent to net-next, it > > was not accepted when I sent the patch to enable this config, later the > > patch was accepted in net-next, > > https://git.kernel.org/cgit/linux/kernel/git/davem/net- > > next.git/commit/?id=bee8259dd31f419a883174556b11edc6f9a153d1 > [S.H] Just found the patch was also merged in Linux-next: > https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/?id=bee8259dd31f419a883174556b11edc6f9a153d1 OK, thanks for letting me know. I must have been looking at a linux-next that I fetched before that. No need to resend, just next time let me know about the dependency. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RFC: Reducing the number of non volatile GPRs in the ppc64 kernel
Hi, While looking at traces of kernel workloads, I noticed places where gcc used a large number of non volatiles. Some of these functions did very little work, and we spent most of our time saving the non volatiles to the stack and reading them back. It made me wonder if we have the right ratio of volatile to non volatile GPRs. Since the kernel is completely self contained, we could potentially change that ratio. Attached is a quick hack to gcc and the kernel to decrease the number of non volatile GPRs to 8. I'm not sure if this is a good idea (and if the volatile to non volatile ratio is right), but this gives us something to play with. Anton powerpc: Reduce the number of non volatiles GPRs to 8 This requires a hacked gcc. Signed-off-by: Anton Blanchard -- Index: linux.junk/arch/powerpc/include/asm/exception-64s.h === --- linux.junk.orig/arch/powerpc/include/asm/exception-64s.h +++ linux.junk/arch/powerpc/include/asm/exception-64s.h @@ -336,6 +336,7 @@ do_kvm_##n:\ std r2,GPR2(r1); /* save r2 in stackframe */ \ SAVE_4GPRS(3, r1); /* save r3 - r6 in stackframe */ \ SAVE_2GPRS(7, r1); /* save r7, r8 in stackframe */ \ + SAVE_10GPRS(14, r1); \ mflr r9; /* Get LR, later save to stack */ \ ld r2,PACATOC(r13); /* get kernel TOC into r2 */ \ std r9,_LINK(r1); \ Index: linux.junk/arch/powerpc/include/asm/ppc_asm.h === --- linux.junk.orig/arch/powerpc/include/asm/ppc_asm.h +++ linux.junk/arch/powerpc/include/asm/ppc_asm.h @@ -77,8 +77,8 @@ END_FW_FTR_SECTION_IFSET(FW_FEATURE_SPLP #ifdef __powerpc64__ #define SAVE_GPR(n, base) std n,GPR0+8*(n)(base) #define REST_GPR(n, base) ld n,GPR0+8*(n)(base) -#define SAVE_NVGPRS(base) SAVE_8GPRS(14, base); SAVE_10GPRS(22, base) -#define REST_NVGPRS(base) REST_8GPRS(14, base); REST_10GPRS(22, base) +#define SAVE_NVGPRS(base) SAVE_8GPRS(24, base) +#define REST_NVGPRS(base) REST_8GPRS(24, base) #else #define SAVE_GPR(n, base) stw n,GPR0+4*(n)(base) #define REST_GPR(n, base) lwz n,GPR0+4*(n)(base) Index: linux.junk/arch/powerpc/kernel/asm-offsets.c === --- linux.junk.orig/arch/powerpc/kernel/asm-offsets.c +++ linux.junk/arch/powerpc/kernel/asm-offsets.c @@ -289,7 +289,6 @@ int main(void) DEFINE(GPR11, STACK_FRAME_OVERHEAD+offsetof(struct pt_regs, gpr[11])); DEFINE(GPR12, STACK_FRAME_OVERHEAD+offsetof(struct pt_regs, gpr[12])); DEFINE(GPR13, STACK_FRAME_OVERHEAD+offsetof(struct pt_regs, gpr[13])); -#ifndef CONFIG_PPC64 DEFINE(GPR14, STACK_FRAME_OVERHEAD+offsetof(struct pt_regs, gpr[14])); DEFINE(GPR15, STACK_FRAME_OVERHEAD+offsetof(struct pt_regs, gpr[15])); DEFINE(GPR16, STACK_FRAME_OVERHEAD+offsetof(struct pt_regs, gpr[16])); @@ -308,7 +307,6 @@ int main(void) DEFINE(GPR29, STACK_FRAME_OVERHEAD+offsetof(struct pt_regs, gpr[29])); DEFINE(GPR30, STACK_FRAME_OVERHEAD+offsetof(struct pt_regs, gpr[30])); DEFINE(GPR31, STACK_FRAME_OVERHEAD+offsetof(struct pt_regs, gpr[31])); -#endif /* CONFIG_PPC64 */ /* * Note: these symbols include _ because they overlap with special * register names Index: linux.junk/arch/powerpc/kernel/entry_64.S === --- linux.junk.orig/arch/powerpc/kernel/entry_64.S +++ linux.junk/arch/powerpc/kernel/entry_64.S @@ -86,6 +86,18 @@ END_FTR_SECTION_IFSET(CPU_FTR_TM) std r11,_XER(r1) std r11,_CTR(r1) std r9,GPR13(r1) + + std r14,GPR14(r1) + std r15,GPR15(r1) + std r16,GPR16(r1) + std r17,GPR17(r1) + std r18,GPR18(r1) + std r19,GPR19(r1) + std r20,GPR20(r1) + std r21,GPR21(r1) + std r22,GPR22(r1) + std r23,GPR23(r1) + mflr r10 /* * This clears CR0.SO (bit 28), which is the error indication on @@ -112,6 +124,7 @@ BEGIN_FW_FTR_SECTION cmpd cr1,r11,r10 beq+ cr1,33f bl accumulate_stolen_time + trap REST_GPR(0,r1) REST_4GPRS(3,r1) REST_2GPRS(7,r1) @@ -225,7 +238,9 @@ END_FTR_SECTION_IFCLR(CPU_FTR_STCX_CHECK ACCOUNT_CPU_USER_EXIT(r11, r12) HMT_MEDIUM_LOW_HAS_PPR ld r13,GPR13(r1) /* only restore r13 if returning to usermode */ -1: ld r2,GPR2(r1) +1: + REST_10GPRS(14, r1) + ld r2,GPR2(r1) ld r1,GPR1(r1) mtlr r4 mtcr r5 @@ -405,10 +420,10 @@ _GLOBAL(ret_from_fork) _GLOBAL(ret_from_kernel_thread) bl schedule_tail REST_NVGPRS(r1) - mtlr r14 - mr r3,r15 + mtlr r24 + mr r3,r25 #if defined(_CALL_ELF) && _CALL_ELF == 2 - mr r12,r14 + mr r12,r24 #endif blrl li r3,0 @@ -540,8 +555,7 @@ END_MMU_FTR_SECTION_IFSET(MMU_FTR_1T_SEG mtcrf 0xFF,r6 /* r3-r13 are destroyed -- Cort */ - REST_8GPRS(14, r1) - REST_10GPRS(22, r1) + REST_8GPRS(24, r1) /* convert old thread to its task_struct for return value */ addi r3,r3,-THREAD @@ -771,6 +785,7 @@ fast_exception_return: mtspr SPRN_XER,r4 REST_8GPRS(5, r1) + REST_10GPRS(14, r1) andi. r0,r3,MSR_RI beq- unrecov_restore Index: linux.junk/arch/powerp
Re: GPMC in device tree
On Wed, Aug 5, 2015 at 12:25 AM, Scott Wood wrote: > On Wed, 2015-08-05 at 00:22 +0300, Ran Shalit wrote: >> On Tue, Aug 4, 2015 at 11:31 PM, Scott Wood wrote: >> > On Tue, 2015-08-04 at 23:26 +0300, Ran Shalit wrote: >> > > On Tue, Aug 4, 2015 at 9:54 PM, Scott Wood >> > > wrote: >> > > > On Tue, 2015-08-04 at 18:29 +0300, Ran Shalit wrote: >> > > > > Hello, >> > > > > >> > > > > I would please like to ask if describing flash nor used with GPMC, >> > > > > whould be done as described in: >> > > > > https://www.kernel.org/doc/Documentation/devicetree/bindings/mtd/gpmc-nor.txt >> > > > > It is described in the above link as "TI's GPMC", so I'm not sure if >> > > > > it is relevent for powerpc too. >> > > > >> > > > That binding is for TI GPMC. >> > > > >> > > > Are you saying you have some PPC chip that has a flash controller >> > > > called >> > > > GPMC? >> > > > >> > > > -Scott >> > > > >> > > >> > > Hi Scott, >> > > >> > > Thanks, I've worked with TI's chips, so I now understand that I made >> > > here some confusion... >> > > It is GPCM , not GPMC, my mistake. >> > > We already configured it in u-boot, but on doing read/write from >> > > kernel it doesn not work. >> > > It seems that for the linux to use the correct driver, we need to >> > > define the nor in the device tree. >> > > Is there any example how to define nor GPCM in device tree ? Is it >> > > possible not to override the existing GPCM configuration ? >> > >> > Pretty much all of the mpc8xxx/qoriq device trees have GPCM NOR defined. >> > See >> > Documentation/devicetree/bindings/powerpc/fsl/lbc.txt and examples such as >> > arch/powerpc/boot/dts/p4080ds.dts (part of the lbc node is in >> > arch/powerpc/boot/dts/fsl/p4080si-post.dtsi). >> > >> > Linux will not change the GPCM configuration. >> > >> > -Scott >> > >> >> On more thing, if I may. >> The localbus is also connected to nvram & cpld. >> I've noticed that read/write works well, even though I didn't define >> anything in device tree. >> Is there any reasom to add these devices into device tree, or can we >> use the cpld and nvram without the definition in device tree ? > > I don't know what you're doing in your kernel to access devices that aren't > in the device tree. You should add the devices to the device tree, and have > the kernel use it rather than hardcoded info. > > -Scott > Hi, Yes I understand. But It is worse noting that I have no localbus entry in the device tree. Yes, The nvram, cpld which are both connected to device tree, seems to work without any issues. Thanks, Ran ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [1/2] powerpc/config: enable teranetics PHY
> -Original Message- > From: Xie Shaohui-B21989 > Sent: Wednesday, August 05, 2015 11:00 AM > To: Wood Scott-B07421 > Cc: linuxppc-dev@lists.ozlabs.org > Subject: RE: [1/2] powerpc/config: enable teranetics PHY > > > On Tue, 2015-08-04 at 19:24 -0500, Scott Wood wrote: > > > On Tue, 2015-08-04 at 19:18 -0500, Scott Wood wrote: > > > > On Fri, Jul 24, 2015 at 11:45:33AM +0800, shaohui xie wrote: > > > > > From: Shaohui Xie > > > > > > > > > > The PHY uses XAUI interface to connect to MAC, mostly the PHY > > > > > used on riser card. > > > > > > > > > > Signed-off-by: Shaohui Xie > > > > > --- > > > > > arch/powerpc/configs/corenet32_smp_defconfig | 1 + > > > > > arch/powerpc/configs/corenet64_smp_defconfig | 1 + > > > > > 2 files changed, 2 insertions(+) > > > > > > > > Next time, please use a subject line that lets me know that this > > > > is a patch that I'd be picking up, such as "powerpc/85xx: ..." or > > > > "powerpc/corenet: ..." > > > > > > More importantly, don't send patches to enable config options that > > > don't exist. > > > > Sorry, this comment was meant for patch 2/2 (CONFIG_AQUANTIA_PHY). > > CONFIG_TERANETICS_PHY does exist in linux-next (that it depends on a > > patch in linux-next should be mentioned below the ---). > Hi Scott, > > The CONFIG_AQUANTIA_PHY was added in another patch sent to net-next, it > was not accepted when I sent the patch to enable this config, later the > patch was accepted in net-next, > https://git.kernel.org/cgit/linux/kernel/git/davem/net- > next.git/commit/?id=bee8259dd31f419a883174556b11edc6f9a153d1 [S.H] Just found the patch was also merged in Linux-next: https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/?id=bee8259dd31f419a883174556b11edc6f9a153d1 Thanks. Shaohui > > I should mention this below the ---. > Sorry! > > Should I re-send the patch of enabling config option of > CONFIG_AQUANTIA_PHY? > > Thanks! > Shaohui ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [1/2] powerpc/config: enable teranetics PHY
> -Original Message- > From: Wood Scott-B07421 > Sent: Wednesday, August 05, 2015 8:19 AM > To: shaohui xie > Cc: linuxppc-dev@lists.ozlabs.org; Xie Shaohui-B21989 > Subject: Re: [1/2] powerpc/config: enable teranetics PHY > > On Fri, Jul 24, 2015 at 11:45:33AM +0800, shaohui xie wrote: > > From: Shaohui Xie > > > > The PHY uses XAUI interface to connect to MAC, mostly the PHY used on > > riser card. > > > > Signed-off-by: Shaohui Xie > > --- > > arch/powerpc/configs/corenet32_smp_defconfig | 1 + > > arch/powerpc/configs/corenet64_smp_defconfig | 1 + > > 2 files changed, 2 insertions(+) > > Next time, please use a subject line that lets me know that this is a > patch that I'd be picking up, such as "powerpc/85xx: ..." or > "powerpc/corenet: ..." OK. Sorry for the inconvenience. Thanks. Shaohui ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: powerpc: Add an inline function to update HID0
On Tue, Aug 04, 2015 at 08:08:58PM +1000, Michael Ellerman wrote:
> > +static inline void update_hid0(unsigned long hid0)
> > +{
> > + /*
> > +* The HID0 update should at the very least be preceded by a
> > +* a SYNC instruction followed by an ISYNC instruction
> > +*/
> > + mb();
> > + mtspr(SPRN_HID0, hid0);
> > + isync();
>
> That's going to turn into three separate inline asm blocks, which is maybe a
> bit unfortunate. Have you checked the generated code is what we want, ie. just
> sync, mtspr, isync ?
The "mb()" is not such a great name anyway: you don't want a memory
barrier, you want an actual sync instruction ("sync 0", "hwsync",
whatever the currently preferred spelling is).
The function name should also say this is for POWER8 (the required
sequences are different for some other processors; and some others
might not even _have_ a HID0, or not at 1008). power8_write_hid0
or such?
For writing it as one asm, why not just
asm volatile("sync ; mtspr %0,%1 ; isync" : : "i"(SPRN_HID0), "r"(hid0));
instead of the stringify stuff?
Segher
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: powerpc: Add an inline function to update HID0
On Tue, 2015-08-04 at 19:36 +0530, Madhavan Srinivasan wrote: > > On Tuesday 04 August 2015 03:38 PM, Michael Ellerman wrote: > > On Tue, 2015-04-08 at 08:30:58 UTC, "Gautham R. Shenoy" wrote: > >> Section 3.7 of Version 1.2 of the Power8 Processor User's Manual > >> prescribes that updates to HID0 be preceded by a SYNC instruction and > >> followed by an ISYNC instruction (Page 91). > >> > >> Create a function name update_hid0() which follows this recipe and > >> invoke it from the static split core path. > >> > >> Signed-off-by: Gautham R. Shenoy > >> --- > >> arch/powerpc/include/asm/kvm_ppc.h | 11 +++ > > Why is it in there? It's not KVM related per se. > > > > Where should it go? I think reg.h would be best, ideally near the definition > > for HID0, though that's probably not possible because of ASSEMBLY > > requirements. > > So at the bottom of reg.h ? > > just to understand, Something like this will not do? > > #define update_hid0(x) __asm__ __volatile__( "sync\n"\ > "mtspr " > __stringify(SPRN_HID0)", %0\n"\ > "isync"::"r"(x)); > Yeah we could do that also. The static inline is less ugly though. cheers ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH V2 6/6] powerpc/powernv: allocate discrete PE# when using M64 BAR in Single PE mode
When M64 BAR is set to Single PE mode, the PE# assigned to VF could be
discrete.
This patch restructures the patch to allocate discrete PE# for VFs when M64
BAR is set to Single PE mode.
Signed-off-by: Wei Yang
---
arch/powerpc/include/asm/pci-bridge.h |2 +-
arch/powerpc/platforms/powernv/pci-ioda.c | 69 +
2 files changed, 51 insertions(+), 20 deletions(-)
diff --git a/arch/powerpc/include/asm/pci-bridge.h
b/arch/powerpc/include/asm/pci-bridge.h
index 8aeba4c..72415c7 100644
--- a/arch/powerpc/include/asm/pci-bridge.h
+++ b/arch/powerpc/include/asm/pci-bridge.h
@@ -213,7 +213,7 @@ struct pci_dn {
#ifdef CONFIG_PCI_IOV
u16 vfs_expanded; /* number of VFs IOV BAR expanded */
u16 num_vfs;/* number of VFs enabled*/
- int offset; /* PE# for the first VF PE */
+ int *offset;/* PE# for the first VF PE or array */
boolm64_single_mode;/* Use M64 BAR in Single Mode */
#define IODA_INVALID_M64(-1)
int (*m64_map)[PCI_SRIOV_NUM_BARS];
diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c
b/arch/powerpc/platforms/powernv/pci-ioda.c
index 4042303..9953829 100644
--- a/arch/powerpc/platforms/powernv/pci-ioda.c
+++ b/arch/powerpc/platforms/powernv/pci-ioda.c
@@ -1243,7 +1243,7 @@ static int pnv_pci_vf_assign_m64(struct pci_dev *pdev,
u16 num_vfs)
/* Map the M64 here */
if (pdn->m64_single_mode) {
- pe_num = pdn->offset + j;
+ pe_num = pdn->offset[j];
rc = opal_pci_map_pe_mmio_window(phb->opal_id,
pe_num, OPAL_M64_WINDOW_TYPE,
pdn->m64_map[j][i], 0);
@@ -1347,7 +1347,7 @@ void pnv_pci_sriov_disable(struct pci_dev *pdev)
struct pnv_phb*phb;
struct pci_dn *pdn;
struct pci_sriov *iov;
- u16 num_vfs;
+ u16num_vfs, i;
bus = pdev->bus;
hose = pci_bus_to_host(bus);
@@ -1361,14 +1361,18 @@ void pnv_pci_sriov_disable(struct pci_dev *pdev)
if (phb->type == PNV_PHB_IODA2) {
if (!pdn->m64_single_mode)
- pnv_pci_vf_resource_shift(pdev, -pdn->offset);
+ pnv_pci_vf_resource_shift(pdev, -*pdn->offset);
/* Release M64 windows */
pnv_pci_vf_release_m64(pdev, num_vfs);
/* Release PE numbers */
- bitmap_clear(phb->ioda.pe_alloc, pdn->offset, num_vfs);
- pdn->offset = 0;
+ if (pdn->m64_single_mode) {
+ for (i = 0; i < num_vfs; i++)
+ pnv_ioda_free_pe(phb, pdn->offset[i]);
+ } else
+ bitmap_clear(phb->ioda.pe_alloc, *pdn->offset, num_vfs);
+ kfree(pdn->offset);
}
}
@@ -1394,7 +1398,10 @@ static void pnv_ioda_setup_vf_PE(struct pci_dev *pdev,
u16 num_vfs)
/* Reserve PE for each VF */
for (vf_index = 0; vf_index < num_vfs; vf_index++) {
- pe_num = pdn->offset + vf_index;
+ if (pdn->m64_single_mode)
+ pe_num = pdn->offset[vf_index];
+ else
+ pe_num = *pdn->offset + vf_index;
pe = &phb->ioda.pe_array[pe_num];
pe->pe_number = pe_num;
@@ -1436,6 +1443,7 @@ int pnv_pci_sriov_enable(struct pci_dev *pdev, u16
num_vfs)
struct pnv_phb*phb;
struct pci_dn *pdn;
intret;
+ u16i;
bus = pdev->bus;
hose = pci_bus_to_host(bus);
@@ -1462,19 +1470,38 @@ int pnv_pci_sriov_enable(struct pci_dev *pdev, u16
num_vfs)
}
/* Calculate available PE for required VFs */
- mutex_lock(&phb->ioda.pe_alloc_mutex);
- pdn->offset = bitmap_find_next_zero_area(
- phb->ioda.pe_alloc, phb->ioda.total_pe,
- 0, num_vfs, 0);
- if (pdn->offset >= phb->ioda.total_pe) {
+ if (pdn->m64_single_mode) {
+ pdn->offset = kmalloc(sizeof(*pdn->offset) * num_vfs,
+ GFP_KERNEL);
+ if (!pdn->offset)
+ return -ENOMEM;
+ for (i = 0; i < num_vfs; i++)
+ pdn->offset[i] = IODA_INVALID_PE;
+ for (i = 0; i < num_vfs; i++) {
+ pdn->offset[i] = pnv_ioda_alloc_pe(phb);
+ if (pdn->offset[i] == IODA_INVALID_PE) {
+ ret = -EBUSY;
+ goto m64_f
[PATCH V2 5/6] powerpc/powernv: boundary the total vf bar size instead of the individual one
Each VF could have 6 BARs at most. When the total BAR size exceeds the
gate, after expanding it will also exhaust the M64 Window.
This patch limits the boundary by checking the total VF BAR size instead of
the individual BAR.
Signed-off-by: Wei Yang
---
arch/powerpc/platforms/powernv/pci-ioda.c | 13 +++--
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c
b/arch/powerpc/platforms/powernv/pci-ioda.c
index 31dcedc..4042303 100644
--- a/arch/powerpc/platforms/powernv/pci-ioda.c
+++ b/arch/powerpc/platforms/powernv/pci-ioda.c
@@ -2702,7 +2702,7 @@ static void pnv_pci_ioda_fixup_iov_resources(struct
pci_dev *pdev)
struct pnv_phb *phb;
struct resource *res;
int i;
- resource_size_t size, gate;
+ resource_size_t size, gate, total_vf_bar_sz;
struct pci_dn *pdn;
int mul, total_vfs;
@@ -2729,6 +2729,7 @@ static void pnv_pci_ioda_fixup_iov_resources(struct
pci_dev *pdev)
* Window and limit the system flexibility.
*/
gate = phb->ioda.m64_segsize >> 1;
+ total_vf_bar_sz = 0;
for (i = 0; i < PCI_SRIOV_NUM_BARS; i++) {
res = &pdev->resource[i + PCI_IOV_RESOURCES];
@@ -2741,13 +2742,13 @@ static void pnv_pci_ioda_fixup_iov_resources(struct
pci_dev *pdev)
return;
}
- size = pci_iov_resource_size(pdev, i + PCI_IOV_RESOURCES);
+ total_vf_bar_sz += pci_iov_resource_size(pdev,
+ i + PCI_IOV_RESOURCES);
/* bigger than or equal to gate */
- if (size >= gate) {
- dev_info(&pdev->dev, "PowerNV: VF BAR%d: %pR IOV size "
- "is bigger than %lld, roundup power2\n",
-i, res, gate);
+ if (total_vf_bar_sz >= gate) {
+ dev_info(&pdev->dev, "PowerNV: VF BAR Total IOV size "
+ "is bigger than %lld, roundup power2\n", gate);
mul = roundup_pow_of_two(total_vfs);
pdn->m64_single_mode = true;
break;
--
1.7.9.5
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH V2 4/6] powerpc/powernv: replace the hard coded boundary with gate
Based on the limitation of M64 Window size, when VF BAR size is bigger than
64MB, IOV BAR just round up power of 2 of the total_vfs. While the 64MB is
a magic boundary in code, which is hard to maintain.
This patch replaces the hard coded boundary with gate, which is calculated
from m64_segsize and adds comment to explain the reason for it.
Signed-off-by: Wei Yang
---
arch/powerpc/platforms/powernv/pci-ioda.c | 22 +-
1 file changed, 17 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c
b/arch/powerpc/platforms/powernv/pci-ioda.c
index f5d110c..31dcedc 100644
--- a/arch/powerpc/platforms/powernv/pci-ioda.c
+++ b/arch/powerpc/platforms/powernv/pci-ioda.c
@@ -2702,7 +2702,7 @@ static void pnv_pci_ioda_fixup_iov_resources(struct
pci_dev *pdev)
struct pnv_phb *phb;
struct resource *res;
int i;
- resource_size_t size;
+ resource_size_t size, gate;
struct pci_dn *pdn;
int mul, total_vfs;
@@ -2718,6 +2718,17 @@ static void pnv_pci_ioda_fixup_iov_resources(struct
pci_dev *pdev)
total_vfs = pci_sriov_get_totalvfs(pdev);
mul = phb->ioda.total_pe;
+ /*
+* If bigger than or equal to half of m64_segsize, just round up power
+* of two.
+*
+* Generally, one M64 BAR maps one IOV BAR. To avoid conflict with
+* other devices, IOV BAR size is expanded to be (total_pe * VF size).
+* When VF size is half of m64_segsize , the expanded size would equal
+* to half of the whole M64 Window size, which will exhaust the M64
+* Window and limit the system flexibility.
+*/
+ gate = phb->ioda.m64_segsize >> 1;
for (i = 0; i < PCI_SRIOV_NUM_BARS; i++) {
res = &pdev->resource[i + PCI_IOV_RESOURCES];
@@ -2732,10 +2743,11 @@ static void pnv_pci_ioda_fixup_iov_resources(struct
pci_dev *pdev)
size = pci_iov_resource_size(pdev, i + PCI_IOV_RESOURCES);
- /* bigger than 64M */
- if (size > (1 << 26)) {
- dev_info(&pdev->dev, "PowerNV: VF BAR%d: %pR IOV size
is bigger than 64M, roundup power2\n",
-i, res);
+ /* bigger than or equal to gate */
+ if (size >= gate) {
+ dev_info(&pdev->dev, "PowerNV: VF BAR%d: %pR IOV size "
+ "is bigger than %lld, roundup power2\n",
+i, res, gate);
mul = roundup_pow_of_two(total_vfs);
pdn->m64_single_mode = true;
break;
--
1.7.9.5
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH V2 1/6] powerpc/powernv: don't enable SRIOV when VF BAR contains non M64 BAR
On PHB_IODA2, we enable SRIOV devices by mapping IOV BAR with M64 BARs. If
a SRIOV device's BAR is not 64-bit prefetchable, this is not assigned from
M64 windwo, which means M64 BAR can't work on it.
This patch makes this explicit.
Signed-off-by: Wei Yang
---
arch/powerpc/platforms/powernv/pci-ioda.c | 25 +
1 file changed, 9 insertions(+), 16 deletions(-)
diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c
b/arch/powerpc/platforms/powernv/pci-ioda.c
index 5738d31..9b41dba 100644
--- a/arch/powerpc/platforms/powernv/pci-ioda.c
+++ b/arch/powerpc/platforms/powernv/pci-ioda.c
@@ -908,9 +908,6 @@ static int pnv_pci_vf_resource_shift(struct pci_dev *dev,
int offset)
if (!res->flags || !res->parent)
continue;
- if (!pnv_pci_is_mem_pref_64(res->flags))
- continue;
-
/*
* The actual IOV BAR range is determined by the start address
* and the actual size for num_vfs VFs BAR. This check is to
@@ -939,9 +936,6 @@ static int pnv_pci_vf_resource_shift(struct pci_dev *dev,
int offset)
if (!res->flags || !res->parent)
continue;
- if (!pnv_pci_is_mem_pref_64(res->flags))
- continue;
-
size = pci_iov_resource_size(dev, i + PCI_IOV_RESOURCES);
res2 = *res;
res->start += size * offset;
@@ -1221,9 +1215,6 @@ static int pnv_pci_vf_assign_m64(struct pci_dev *pdev,
u16 num_vfs)
if (!res->flags || !res->parent)
continue;
- if (!pnv_pci_is_mem_pref_64(res->flags))
- continue;
-
for (j = 0; j < vf_groups; j++) {
do {
win =
find_next_zero_bit(&phb->ioda.m64_bar_alloc,
@@ -1510,6 +1501,12 @@ int pnv_pci_sriov_enable(struct pci_dev *pdev, u16
num_vfs)
pdn = pci_get_pdn(pdev);
if (phb->type == PNV_PHB_IODA2) {
+ if (!pdn->vfs_expanded) {
+ dev_info(&pdev->dev, "don't support this SRIOV device"
+ " with non M64 VF BAR\n");
+ return -EBUSY;
+ }
+
/* Calculate available PE for required VFs */
mutex_lock(&phb->ioda.pe_alloc_mutex);
pdn->offset = bitmap_find_next_zero_area(
@@ -2774,9 +2771,10 @@ static void pnv_pci_ioda_fixup_iov_resources(struct
pci_dev *pdev)
if (!res->flags || res->parent)
continue;
if (!pnv_pci_is_mem_pref_64(res->flags)) {
- dev_warn(&pdev->dev, " non M64 VF BAR%d: %pR\n",
+ dev_warn(&pdev->dev, "Don't support SR-IOV with"
+ " non M64 VF BAR%d: %pR. \n",
i, res);
- continue;
+ return;
}
size = pci_iov_resource_size(pdev, i + PCI_IOV_RESOURCES);
@@ -2795,11 +2793,6 @@ static void pnv_pci_ioda_fixup_iov_resources(struct
pci_dev *pdev)
res = &pdev->resource[i + PCI_IOV_RESOURCES];
if (!res->flags || res->parent)
continue;
- if (!pnv_pci_is_mem_pref_64(res->flags)) {
- dev_warn(&pdev->dev, "Skipping expanding VF BAR%d:
%pR\n",
-i, res);
- continue;
- }
dev_dbg(&pdev->dev, " Fixing VF BAR%d: %pR to\n", i, res);
size = pci_iov_resource_size(pdev, i + PCI_IOV_RESOURCES);
--
1.7.9.5
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH V2 3/6] powerpc/powernv: use one M64 BAR in Single PE mode for one VF BAR
In current implementation, when VF BAR is bigger than 64MB, it uses 4 M64
BAR in Single PE mode to cover the number of VFs required to be enabled.
By doing so, several VFs would be in one VF Group and leads to interference
between VFs in the same group.
This patch changes the design by using one M64 BAR in Single PE mode for
one VF BAR. This gives absolute isolation for VFs.
Signed-off-by: Wei Yang
---
arch/powerpc/include/asm/pci-bridge.h |5 +-
arch/powerpc/platforms/powernv/pci-ioda.c | 180 -
2 files changed, 76 insertions(+), 109 deletions(-)
diff --git a/arch/powerpc/include/asm/pci-bridge.h
b/arch/powerpc/include/asm/pci-bridge.h
index 712add5..8aeba4c 100644
--- a/arch/powerpc/include/asm/pci-bridge.h
+++ b/arch/powerpc/include/asm/pci-bridge.h
@@ -214,10 +214,9 @@ struct pci_dn {
u16 vfs_expanded; /* number of VFs IOV BAR expanded */
u16 num_vfs;/* number of VFs enabled*/
int offset; /* PE# for the first VF PE */
-#define M64_PER_IOV 4
- int m64_per_iov;
+ boolm64_single_mode;/* Use M64 BAR in Single Mode */
#define IODA_INVALID_M64(-1)
- int m64_wins[PCI_SRIOV_NUM_BARS][M64_PER_IOV];
+ int (*m64_map)[PCI_SRIOV_NUM_BARS];
#endif /* CONFIG_PCI_IOV */
#endif
struct list_head child_list;
diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c
b/arch/powerpc/platforms/powernv/pci-ioda.c
index 7192e62..f5d110c 100644
--- a/arch/powerpc/platforms/powernv/pci-ioda.c
+++ b/arch/powerpc/platforms/powernv/pci-ioda.c
@@ -1148,29 +1148,36 @@ static void pnv_pci_ioda_setup_PEs(void)
}
#ifdef CONFIG_PCI_IOV
-static int pnv_pci_vf_release_m64(struct pci_dev *pdev)
+static int pnv_pci_vf_release_m64(struct pci_dev *pdev, u16 num_vfs)
{
struct pci_bus*bus;
struct pci_controller *hose;
struct pnv_phb*phb;
struct pci_dn *pdn;
inti, j;
+ intm64_bars;
bus = pdev->bus;
hose = pci_bus_to_host(bus);
phb = hose->private_data;
pdn = pci_get_pdn(pdev);
+ if (pdn->m64_single_mode)
+ m64_bars = num_vfs;
+ else
+ m64_bars = 1;
+
for (i = 0; i < PCI_SRIOV_NUM_BARS; i++)
- for (j = 0; j < M64_PER_IOV; j++) {
- if (pdn->m64_wins[i][j] == IODA_INVALID_M64)
+ for (j = 0; j < m64_bars; j++) {
+ if (pdn->m64_map[j][i] == IODA_INVALID_M64)
continue;
opal_pci_phb_mmio_enable(phb->opal_id,
- OPAL_M64_WINDOW_TYPE, pdn->m64_wins[i][j], 0);
- clear_bit(pdn->m64_wins[i][j],
&phb->ioda.m64_bar_alloc);
- pdn->m64_wins[i][j] = IODA_INVALID_M64;
+ OPAL_M64_WINDOW_TYPE, pdn->m64_map[j][i], 0);
+ clear_bit(pdn->m64_map[j][i], &phb->ioda.m64_bar_alloc);
+ pdn->m64_map[j][i] = IODA_INVALID_M64;
}
+ kfree(pdn->m64_map);
return 0;
}
@@ -1187,8 +1194,7 @@ static int pnv_pci_vf_assign_m64(struct pci_dev *pdev,
u16 num_vfs)
inttotal_vfs;
resource_size_tsize, start;
intpe_num;
- intvf_groups;
- intvf_per_group;
+ intm64_bars;
bus = pdev->bus;
hose = pci_bus_to_host(bus);
@@ -1196,26 +1202,26 @@ static int pnv_pci_vf_assign_m64(struct pci_dev *pdev,
u16 num_vfs)
pdn = pci_get_pdn(pdev);
total_vfs = pci_sriov_get_totalvfs(pdev);
- /* Initialize the m64_wins to IODA_INVALID_M64 */
- for (i = 0; i < PCI_SRIOV_NUM_BARS; i++)
- for (j = 0; j < M64_PER_IOV; j++)
- pdn->m64_wins[i][j] = IODA_INVALID_M64;
+ if (pdn->m64_single_mode)
+ m64_bars = num_vfs;
+ else
+ m64_bars = 1;
+
+ pdn->m64_map = kmalloc(sizeof(*pdn->m64_map) * m64_bars, GFP_KERNEL);
+ if (!pdn->m64_map)
+ return -ENOMEM;
+ /* Initialize the m64_map to IODA_INVALID_M64 */
+ for (i = 0; i < m64_bars ; i++)
+ for (j = 0; j < PCI_SRIOV_NUM_BARS; j++)
+ pdn->m64_map[i][j] = IODA_INVALID_M64;
- if (pdn->m64_per_iov == M64_PER_IOV) {
- vf_groups = (num_vfs <= M64_PER_IOV) ? num_vfs: M64_PER_IOV;
- vf_per_group = (num_vfs <= M64_PER_IOV)? 1:
- roundup_pow_of_two(num_vfs) / pdn->m64_per_iov;
- } else {
- vf_groups = 1;
- vf_per_group = 1;
- }
for (i = 0; i < PCI_SRIOV_NUM_BARS; i++) {
res = &pdev->resource[i + PCI_IOV_RESOURCES];
if (!res-
[PATCH V2 2/6] powerpc/powernv: simplify the calculation of iov resource
The alignment of IOV BAR on PowerNV platform is the total size of the IOV
BAR. No matter whether the IOV BAR is truncated or not, the total size
could be calculated by (vfs_expanded * VF size).
This patch simplifies the pnv_pci_iov_resource_alignment() by removing the
first case.
Signed-off-by: Wei Yang
---
arch/powerpc/platforms/powernv/pci-ioda.c | 14 +-
1 file changed, 9 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c
b/arch/powerpc/platforms/powernv/pci-ioda.c
index 9b41dba..7192e62 100644
--- a/arch/powerpc/platforms/powernv/pci-ioda.c
+++ b/arch/powerpc/platforms/powernv/pci-ioda.c
@@ -2987,12 +2987,16 @@ static resource_size_t
pnv_pci_iov_resource_alignment(struct pci_dev *pdev,
int resno)
{
struct pci_dn *pdn = pci_get_pdn(pdev);
- resource_size_t align, iov_align;
-
- iov_align = resource_size(&pdev->resource[resno]);
- if (iov_align)
- return iov_align;
+ resource_size_t align;
+ /*
+* On PowerNV platform, IOV BAR is mapped by M64 BAR to enable the
+* SR-IOV. While from hardware perspective, the range mapped by M64
+* BAR should be size aligned.
+*
+* This function return the total IOV BAR size if expanded or just the
+* individual size if not.
+*/
align = pci_iov_resource_size(pdev, resno);
if (pdn->vfs_expanded)
return pdn->vfs_expanded * align;
--
1.7.9.5
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH V2 0/6] Redesign SR-IOV on PowerNV
In original design, it tries to group VFs to enable more number of VFs in the system, when VF BAR is bigger than 64MB. This design has a flaw in which one error on a VF will interfere other VFs in the same group. This patch series change this design by using M64 BAR in Single PE mode to cover only one VF BAR. By doing so, it gives absolute isolation between VFs. v2: * clean up iov bar alignment calculation * change m64s to m64_bars * add a field to represent M64 Single PE mode will be used * change m64_wins to m64_map * calculate the gate instead of hard coded * dynamically allocate m64_map * dynamically allocate PE# * add a case to calculate iov bar alignment when M64 Single PE is used * when M64 Single PE is used, compare num_vfs with M64 BAR available number in system at first Wei Yang (6): powerpc/powernv: don't enable SRIOV when VF BAR contains non M64 BAR powerpc/powernv: simplify the calculation of iov resource powerpc/powernv: use one M64 BAR in Single PE mode for one VF BAR powerpc/powernv: replace the hard coded boundary with gate powerpc/powernv: boundary the total vf bar size instead of the individual one powerpc/powernv: allocate discrete PE# when using M64 BAR in Single PE mode arch/powerpc/include/asm/pci-bridge.h |7 +- arch/powerpc/platforms/powernv/pci-ioda.c | 311 +++-- 2 files changed, 163 insertions(+), 155 deletions(-) -- 1.7.9.5 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [1/2] powerpc/config: enable teranetics PHY
On Tue, 2015-08-04 at 19:24 -0500, Scott Wood wrote: > On Tue, 2015-08-04 at 19:18 -0500, Scott Wood wrote: > > On Fri, Jul 24, 2015 at 11:45:33AM +0800, shaohui xie wrote: > > > From: Shaohui Xie > > > > > > The PHY uses XAUI interface to connect to MAC, mostly the PHY used on > > > riser card. > > > > > > Signed-off-by: Shaohui Xie > > > --- > > > arch/powerpc/configs/corenet32_smp_defconfig | 1 + > > > arch/powerpc/configs/corenet64_smp_defconfig | 1 + > > > 2 files changed, 2 insertions(+) > > > > Next time, please use a subject line that lets me know that this is a > > patch that I'd be picking up, such as "powerpc/85xx: ..." or > > "powerpc/corenet: ..." > > More importantly, don't send patches to enable config options that don't > exist. Sorry, this comment was meant for patch 2/2 (CONFIG_AQUANTIA_PHY). CONFIG_TERANETICS_PHY does exist in linux-next (that it depends on a patch in linux-next should be mentioned below the ---). -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [1/2] powerpc/config: enable teranetics PHY
On Tue, 2015-08-04 at 19:18 -0500, Scott Wood wrote: > On Fri, Jul 24, 2015 at 11:45:33AM +0800, shaohui xie wrote: > > From: Shaohui Xie > > > > The PHY uses XAUI interface to connect to MAC, mostly the PHY used on > > riser card. > > > > Signed-off-by: Shaohui Xie > > --- > > arch/powerpc/configs/corenet32_smp_defconfig | 1 + > > arch/powerpc/configs/corenet64_smp_defconfig | 1 + > > 2 files changed, 2 insertions(+) > > Next time, please use a subject line that lets me know that this is a > patch that I'd be picking up, such as "powerpc/85xx: ..." or > "powerpc/corenet: ..." More importantly, don't send patches to enable config options that don't exist. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [1/2] powerpc/config: enable teranetics PHY
On Fri, Jul 24, 2015 at 11:45:33AM +0800, shaohui xie wrote: > From: Shaohui Xie > > The PHY uses XAUI interface to connect to MAC, mostly the PHY used on > riser card. > > Signed-off-by: Shaohui Xie > --- > arch/powerpc/configs/corenet32_smp_defconfig | 1 + > arch/powerpc/configs/corenet64_smp_defconfig | 1 + > 2 files changed, 2 insertions(+) Next time, please use a subject line that lets me know that this is a patch that I'd be picking up, such as "powerpc/85xx: ..." or "powerpc/corenet: ..." -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: powerpc/corenet: use the mixed mode of MPIC when enabling CPU hotplug
On Thu, Jul 23, 2015 at 11:55:45AM +0800, chenhui zhao wrote:
> Core reset may cause issue if using the proxy mode of MPIC.
> Use the mixed mode of MPIC if enabling CPU hotplug.
>
> Signed-off-by: Chenhui Zhao
> ---
> arch/powerpc/platforms/85xx/corenet_generic.c | 8
> 1 file changed, 8 insertions(+)
>
> diff --git a/arch/powerpc/platforms/85xx/corenet_generic.c
> b/arch/powerpc/platforms/85xx/corenet_generic.c
> index bd839dc..0119224 100644
> --- a/arch/powerpc/platforms/85xx/corenet_generic.c
> +++ b/arch/powerpc/platforms/85xx/corenet_generic.c
> @@ -212,7 +212,15 @@ define_machine(corenet_generic) {
> .pcibios_fixup_bus = fsl_pcibios_fixup_bus,
> .pcibios_fixup_phb = fsl_pcibios_fixup_phb,
> #endif
> +/*
> + * Core reset may cause issue if using the proxy mode of MPIC.
> + * So, use the mixed mode of MPIC if enabling CPU hotplug.
> + */
> +#ifdef CONFIG_HOTPLUG_CPU
> + .get_irq= mpic_get_irq,
> +#else
> .get_irq= mpic_get_coreint_irq,
> +#endif
Between this and kexec needing the same thing, I'm wondering if we should
just drop support for coreint. Do you have any benchmarks for the
performance impact of this patch?
Is there an erratum for the hardware problem?
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2 4/8] xen: Use the correctly the Xen memory terminologies
On 08/04/2015 02:12 PM, Julien Grall wrote:
/*
* We detect special mappings in one of two ways:
@@ -217,9 +232,13 @@ static inline unsigned long bfn_to_local_pfn(unsigned long
mfn)
/* VIRT <-> MACHINE conversion */
#define virt_to_machine(v)(phys_to_machine(XPADDR(__pa(v
-#define virt_to_pfn(v) (PFN_DOWN(__pa(v)))
#define virt_to_mfn(v)(pfn_to_mfn(virt_to_pfn(v)))
#define mfn_to_virt(m)(__va(mfn_to_pfn(m) << PAGE_SHIFT))
+#define virt_to_pfn(v) (PFN_DOWN(__pa(v)))
This looks like unnecessary change.
diff --git a/drivers/video/fbdev/xen-fbfront.c
b/drivers/video/fbdev/xen-fbfront.c
index 09dc447..25e3cce 100644
--- a/drivers/video/fbdev/xen-fbfront.c
+++ b/drivers/video/fbdev/xen-fbfront.c
@@ -539,7 +539,7 @@ static int xenfb_remove(struct xenbus_device *dev)
static unsigned long vmalloc_to_mfn(void *address)
{
- return pfn_to_mfn(vmalloc_to_pfn(address));
+ return pfn_to_gfn(vmalloc_to_pfn(address));
}
Are you sure? This will return vmalloc_to_pfn(address)).
-boris
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: GPMC in device tree
On Wed, 2015-08-05 at 00:22 +0300, Ran Shalit wrote: > On Tue, Aug 4, 2015 at 11:31 PM, Scott Wood wrote: > > On Tue, 2015-08-04 at 23:26 +0300, Ran Shalit wrote: > > > On Tue, Aug 4, 2015 at 9:54 PM, Scott Wood > > > wrote: > > > > On Tue, 2015-08-04 at 18:29 +0300, Ran Shalit wrote: > > > > > Hello, > > > > > > > > > > I would please like to ask if describing flash nor used with GPMC, > > > > > whould be done as described in: > > > > > https://www.kernel.org/doc/Documentation/devicetree/bindings/mtd/gpmc-nor.txt > > > > > It is described in the above link as "TI's GPMC", so I'm not sure if > > > > > it is relevent for powerpc too. > > > > > > > > That binding is for TI GPMC. > > > > > > > > Are you saying you have some PPC chip that has a flash controller > > > > called > > > > GPMC? > > > > > > > > -Scott > > > > > > > > > > Hi Scott, > > > > > > Thanks, I've worked with TI's chips, so I now understand that I made > > > here some confusion... > > > It is GPCM , not GPMC, my mistake. > > > We already configured it in u-boot, but on doing read/write from > > > kernel it doesn not work. > > > It seems that for the linux to use the correct driver, we need to > > > define the nor in the device tree. > > > Is there any example how to define nor GPCM in device tree ? Is it > > > possible not to override the existing GPCM configuration ? > > > > Pretty much all of the mpc8xxx/qoriq device trees have GPCM NOR defined. > > See > > Documentation/devicetree/bindings/powerpc/fsl/lbc.txt and examples such as > > arch/powerpc/boot/dts/p4080ds.dts (part of the lbc node is in > > arch/powerpc/boot/dts/fsl/p4080si-post.dtsi). > > > > Linux will not change the GPCM configuration. > > > > -Scott > > > > On more thing, if I may. > The localbus is also connected to nvram & cpld. > I've noticed that read/write works well, even though I didn't define > anything in device tree. > Is there any reasom to add these devices into device tree, or can we > use the cpld and nvram without the definition in device tree ? I don't know what you're doing in your kernel to access devices that aren't in the device tree. You should add the devices to the device tree, and have the kernel use it rather than hardcoded info. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: GPMC in device tree
On Tue, Aug 4, 2015 at 11:31 PM, Scott Wood wrote: > On Tue, 2015-08-04 at 23:26 +0300, Ran Shalit wrote: >> On Tue, Aug 4, 2015 at 9:54 PM, Scott Wood wrote: >> > On Tue, 2015-08-04 at 18:29 +0300, Ran Shalit wrote: >> > > Hello, >> > > >> > > I would please like to ask if describing flash nor used with GPMC, >> > > whould be done as described in: >> > > https://www.kernel.org/doc/Documentation/devicetree/bindings/mtd/gpmc-nor.txt >> > > It is described in the above link as "TI's GPMC", so I'm not sure if >> > > it is relevent for powerpc too. >> > >> > That binding is for TI GPMC. >> > >> > Are you saying you have some PPC chip that has a flash controller called >> > GPMC? >> > >> > -Scott >> > >> >> Hi Scott, >> >> Thanks, I've worked with TI's chips, so I now understand that I made >> here some confusion... >> It is GPCM , not GPMC, my mistake. >> We already configured it in u-boot, but on doing read/write from >> kernel it doesn not work. >> It seems that for the linux to use the correct driver, we need to >> define the nor in the device tree. >> Is there any example how to define nor GPCM in device tree ? Is it >> possible not to override the existing GPCM configuration ? > > Pretty much all of the mpc8xxx/qoriq device trees have GPCM NOR defined. See > Documentation/devicetree/bindings/powerpc/fsl/lbc.txt and examples such as > arch/powerpc/boot/dts/p4080ds.dts (part of the lbc node is in > arch/powerpc/boot/dts/fsl/p4080si-post.dtsi). > > Linux will not change the GPCM configuration. > > -Scott > On more thing, if I may. The localbus is also connected to nvram & cpld. I've noticed that read/write works well, even though I didn't define anything in device tree. Is there any reasom to add these devices into device tree, or can we use the cpld and nvram without the definition in device tree ? Thanks, Ran ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [v5,RESEND] IFC: Change IO accessor based on endianness
On Wed, 2015-05-27 at 20:19 -0500, Scott Wood wrote: > On Wed, May 20, 2015 at 09:17:11PM -0500, Scott Wood wrote: > > From: Jaiprakash Singh > > > > IFC IO accressor are set at run time based > > on IFC IP registers endianness.IFC node in > > DTS file contains information about > > endianness. > > > > Signed-off-by: Jaiprakash Singh > > Signed-off-by: Scott Wood > > --- > > v5: I'm assuming it's the same as v4, but I didn't send v4, and this > > comes from a versionless [RESEND] that never made it to the mailing list, > > so bumping the version just in case. > > > > .../bindings/memory-controllers/fsl/ifc.txt| 3 + > > drivers/memory/fsl_ifc.c | 43 ++-- > > drivers/mtd/nand/fsl_ifc_nand.c| 258 +++- > > - > > include/linux/fsl_ifc.h| 50 > > 4 files changed, 213 insertions(+), 141 deletions(-) > > Brian, can I get an ack for this? ping -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: GPMC in device tree
On Tue, 2015-08-04 at 23:26 +0300, Ran Shalit wrote: > On Tue, Aug 4, 2015 at 9:54 PM, Scott Wood wrote: > > On Tue, 2015-08-04 at 18:29 +0300, Ran Shalit wrote: > > > Hello, > > > > > > I would please like to ask if describing flash nor used with GPMC, > > > whould be done as described in: > > > https://www.kernel.org/doc/Documentation/devicetree/bindings/mtd/gpmc-nor.txt > > > It is described in the above link as "TI's GPMC", so I'm not sure if > > > it is relevent for powerpc too. > > > > That binding is for TI GPMC. > > > > Are you saying you have some PPC chip that has a flash controller called > > GPMC? > > > > -Scott > > > > Hi Scott, > > Thanks, I've worked with TI's chips, so I now understand that I made > here some confusion... > It is GPCM , not GPMC, my mistake. > We already configured it in u-boot, but on doing read/write from > kernel it doesn not work. > It seems that for the linux to use the correct driver, we need to > define the nor in the device tree. > Is there any example how to define nor GPCM in device tree ? Is it > possible not to override the existing GPCM configuration ? Pretty much all of the mpc8xxx/qoriq device trees have GPCM NOR defined. See Documentation/devicetree/bindings/powerpc/fsl/lbc.txt and examples such as arch/powerpc/boot/dts/p4080ds.dts (part of the lbc node is in arch/powerpc/boot/dts/fsl/p4080si-post.dtsi). Linux will not change the GPCM configuration. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: GPMC in device tree
On Tue, Aug 4, 2015 at 9:54 PM, Scott Wood wrote: > On Tue, 2015-08-04 at 18:29 +0300, Ran Shalit wrote: >> Hello, >> >> I would please like to ask if describing flash nor used with GPMC, >> whould be done as described in: >> https://www.kernel.org/doc/Documentation/devicetree/bindings/mtd/gpmc-nor.txt >> It is described in the above link as "TI's GPMC", so I'm not sure if >> it is relevent for powerpc too. > > That binding is for TI GPMC. > > Are you saying you have some PPC chip that has a flash controller called GPMC? > > -Scott > Hi Scott, Thanks, I've worked with TI's chips, so I now understand that I made here some confusion... It is GPCM , not GPMC, my mistake. We already configured it in u-boot, but on doing read/write from kernel it doesn not work. It seems that for the linux to use the correct driver, we need to define the nor in the device tree. Is there any example how to define nor GPCM in device tree ? Is it possible not to override the existing GPCM configuration ? Thank you! Ran ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Missing Linux patches
On Tue, 2015-08-04 at 11:07 +0200, leroy christophe wrote: > Le 02/08/2015 21:05, Markus Stockhausen a écrit : > > Hi Christophe, > > > > I saw that this patch from you is still missing in Linux mainline: > > https://lists.ozlabs.org/pipermail/linuxppc-dev/2014-September/121144.html > > > > Is there any reason for not using it? > > > > Markus > > Hi, > > I sent v3 of that Patch on 19 May 2015, taking into account all comments > I have received. > > I have not received any further comments so I expect it will be applied. > > Christophe Yes, I plan to apply it. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: GPMC in device tree
On Tue, 2015-08-04 at 18:29 +0300, Ran Shalit wrote: > Hello, > > I would please like to ask if describing flash nor used with GPMC, > whould be done as described in: > https://www.kernel.org/doc/Documentation/devicetree/bindings/mtd/gpmc-nor.txt > It is described in the above link as "TI's GPMC", so I'm not sure if > it is relevent for powerpc too. That binding is for TI GPMC. Are you saying you have some PPC chip that has a flash controller called GPMC? -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v5 40/46] usb: gadget: epautoconf: rework ep_matches() function
On Fri, Jul 31, 2015 at 04:00:52PM +0200, Robert Baldyga wrote: > Rework ep_matches() function to make it shorter and more readable. > > Signed-off-by: Robert Baldyga this regresses at least mass storage. How did you test it ? I'll keep all patches up to this one, please fix the problem, rebase on testing/next and resend the remaining patches. cheers -- balbi signature.asc Description: Digital signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v2 4/8] xen: Use the correctly the Xen memory terminologies
Based on include/xen/mm.h [1], Linux is mistakenly using MFN when GFN
is meant, I suspect this is because the first support for Xen was for
PV. This resulted in some misimplementation of helpers on ARM and
confused developers about the expected behavior.
For instance, with pfn_to_mfn, we expect to get an MFN based on the name.
Although, if we look at the implementation on x86, it's returning a GFN.
For clarity and avoid new confusion, replace any reference to mfn with
gfn in any helpers used by PV drivers. The x86 code will still keep some
reference of pfn_to_mfn but exclusively for PV (a BUG_ON has been added
to ensure this). No changes as been made in the hypercall field, even
though they may be invalid, in order to keep the same as the defintion
in xen repo.
Take also the opportunity to simplify simple construction such
as pfn_to_mfn(page_to_pfn(page)) into page_to_gfn. More complex clean up
will come in follow-up patches.
[1]
http://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=e758ed14f390342513405dd766e874934573e6cb
Signed-off-by: Julien Grall
Cc: Stefano Stabellini
Cc: Russell King
Cc: Konrad Rzeszutek Wilk
Cc: Boris Ostrovsky
Cc: David Vrabel
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: "H. Peter Anvin"
Cc: x...@kernel.org
Cc: "Roger Pau Monné"
Cc: Dmitry Torokhov
Cc: Ian Campbell
Cc: Wei Liu
Cc: Juergen Gross
Cc: "James E.J. Bottomley"
Cc: Greg Kroah-Hartman
Cc: Jiri Slaby
Cc: Jean-Christophe Plagniol-Villard
Cc: Tomi Valkeinen
Cc: linux-in...@vger.kernel.org
Cc: net...@vger.kernel.org
Cc: linux-s...@vger.kernel.org
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux-fb...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
---
Note that I've re-introduced mfn_to_pfn & co only for x86 PV code.
The helpers contain a BUG_ON to ensure that it's never called for
auto-translated guests. I did as best as my can to determine whether
mfn or gfn helpers should be used. Although, I haven't tried to boot
it.
It may be possible to do further cleanup in the mmu.c where I found
some check to auto-translated. I'm not sure why given that the pvmmu
callback are only used for non-auto translated guest.
Finally, given those changes, I didn't retain the Reviewed-by/Acked-by.
Changes in v2:
- Give directly the URL to the commit rather than the commit ID
- xenstored_local_init: keep the cast to void *
- Typoes
- Keep pfn_to_mfn for x86 and PV-only. The *mfn* helpers are
used in arch/x86/xen for enlighten.c, mmu.c, p2m.c, setup.c,
smp.c and mm.c
---
arch/arm/include/asm/xen/page.h | 13 +++--
arch/x86/include/asm/xen/page.h | 33 ++---
arch/x86/xen/smp.c | 2 +-
drivers/block/xen-blkfront.c| 6 +++---
drivers/input/misc/xen-kbdfront.c | 4 ++--
drivers/net/xen-netback/netback.c | 4 ++--
drivers/net/xen-netfront.c | 8
drivers/scsi/xen-scsifront.c| 8 +++-
drivers/tty/hvc/hvc_xen.c | 5 +++--
drivers/video/fbdev/xen-fbfront.c | 4 ++--
drivers/xen/balloon.c | 2 +-
drivers/xen/events/events_base.c| 2 +-
drivers/xen/events/events_fifo.c| 4 ++--
drivers/xen/gntalloc.c | 3 ++-
drivers/xen/manage.c| 2 +-
drivers/xen/tmem.c | 4 ++--
drivers/xen/xenbus/xenbus_client.c | 2 +-
drivers/xen/xenbus/xenbus_dev_backend.c | 2 +-
drivers/xen/xenbus/xenbus_probe.c | 8 +++-
include/xen/page.h | 4 ++--
20 files changed, 69 insertions(+), 51 deletions(-)
diff --git a/arch/arm/include/asm/xen/page.h b/arch/arm/include/asm/xen/page.h
index 087d86e..51e5bf1 100644
--- a/arch/arm/include/asm/xen/page.h
+++ b/arch/arm/include/asm/xen/page.h
@@ -34,14 +34,15 @@ typedef struct xpaddr {
unsigned long __pfn_to_mfn(unsigned long pfn);
extern struct rb_root phys_to_mach;
-static inline unsigned long pfn_to_mfn(unsigned long pfn)
+/* Pseudo-physical <-> Guest conversion */
+static inline unsigned long pfn_to_gfn(unsigned long pfn)
{
return pfn;
}
-static inline unsigned long mfn_to_pfn(unsigned long mfn)
+static inline unsigned long gfn_to_pfn(unsigned long gfn)
{
- return mfn;
+ return gfn;
}
/* Pseudo-physical <-> BUS conversion */
@@ -65,9 +66,9 @@ static inline unsigned long bfn_to_pfn(unsigned long bfn)
#define bfn_to_local_pfn(bfn) bfn_to_pfn(bfn)
-/* VIRT <-> MACHINE conversion */
-#define virt_to_mfn(v) (pfn_to_mfn(virt_to_pfn(v)))
-#define mfn_to_virt(m) (__va(mfn_to_pfn(m) << PAGE_SHIFT))
+/* VIRT <-> GUEST conversion */
+#define virt_to_gfn(v) (pfn_to_gfn(virt_to_pfn(v)))
+#define gfn_to_virt(m) (__va(gfn_to_pfn(m) << PAGE_SHIFT))
/* Only used in PV code. But ARM guests are always HVM. */
static inline xmaddr_t arbitrary_virt_to_machine(void *vaddr)
[PATCH v2 0/8] Use correctly the Xen memory terminologies in Linux
Hi all, This patch series aims to use the memory terminologies described in include/xen/mm.h [1] for Linux xen code. Linux is using mistakenly MFN when GFN is meant, I suspect this is because the first support of Xen was for PV. This has brought some misimplementation of memory helpers on ARM and make the developper confused about the expected behavior. For instance, with pfn_to_mfn, we expect to get a MFN based on the name. Although, if we look at the implementation on x86, it's returning a GFN. Most of the callers are also using it this way. The first 2 patches of this series is ARM related in order to remove PV specific helpers which should not be used and fixing the implementation of pfn_to_mfn. The rest of the series is here rename most of the usage in the common code of MFN to GFN. I also took the opportunity to replace most of the call to pfn_to_gfn in the common code by page_to_gfn avoid construction such as pfn_to_gfn(page_to_pfn(...). Note the one xen-blkfront will be dropped by 64K series [2], I can include it if necessary. Major changes in v2: - Use bfn rather than dfn for the DMA address - Re-introduced pfn_to_mfn for PV guests only - Typoes For all the changes see in each patch. This series is based on linus's branch. A branch with all the patches can be found here: git://xenbits.xen.org/people/julieng/linux-arm.git branch page-renaming-v2 It was been boot tested on ARM64 and only built for x86 and ARM32. I would be happy if someone can give a try on x86 as I don't have a x86 box setup with Xen. Sincerely yours, [1] http://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=e758ed14f390342513405dd766e874934573e6cb [2] https://lkml.org/lkml/2015/7/9/628 Cc: Boris Ostrovsky Cc: David Vrabel Cc: Dmitry Torokhov Cc: Greg Kroah-Hartman Cc: "H. Peter Anvin" Cc: Ian Campbell Cc: Ingo Molnar Cc: "James E.J. Bottomley" Cc: Jean-Christophe Plagniol-Villard Cc: Jiri Slaby Cc: Juergen Gross Cc: Konrad Rzeszutek Wilk Cc: linux-...@vger.kernel.org Cc: linux-arm-ker...@lists.infradead.org Cc: linux-fb...@vger.kernel.org Cc: linux-in...@vger.kernel.org Cc: linuxppc-dev@lists.ozlabs.org Cc: linux-s...@vger.kernel.org Cc: net...@vger.kernel.org Cc: "Roger Pau Monné" Cc: Russell King Cc: Stefano Stabellini Cc: Thomas Gleixner Cc: Tomi Valkeinen Cc: Wei Liu Cc: x...@kernel.org Julien Grall (8): arm/xen: Remove helpers which are PV specific xen: Make clear that swiotlb and biomerge are dealing with DMA address arm/xen: implement correctly pfn_to_mfn xen: Use the correctly the Xen memory terminologies xen/tmem: Use page_to_gfn rather than pfn_to_gfn video/xen-fbfront: Further s/MFN/GFN clean-up hvc/xen: Further s/MFN/GFN clean-up xen/privcmd: Further s/MFN/GFN/ clean-up arch/arm/include/asm/xen/page.h | 44 - arch/arm/xen/enlighten.c| 18 +++--- arch/arm/xen/mm.c | 4 +-- arch/x86/include/asm/xen/page.h | 37 +-- arch/x86/xen/mmu.c | 32 arch/x86/xen/smp.c | 2 +- drivers/block/xen-blkfront.c| 6 ++--- drivers/input/misc/xen-kbdfront.c | 4 +-- drivers/net/xen-netback/netback.c | 4 +-- drivers/net/xen-netfront.c | 8 +++--- drivers/scsi/xen-scsifront.c| 8 +++--- drivers/tty/hvc/hvc_xen.c | 18 ++ drivers/video/fbdev/xen-fbfront.c | 20 +++ drivers/xen/balloon.c | 2 +- drivers/xen/biomerge.c | 6 ++--- drivers/xen/events/events_base.c| 2 +- drivers/xen/events/events_fifo.c| 4 +-- drivers/xen/gntalloc.c | 3 ++- drivers/xen/manage.c| 2 +- drivers/xen/privcmd.c | 44 - drivers/xen/swiotlb-xen.c | 16 ++-- drivers/xen/tmem.c | 21 ++-- drivers/xen/xenbus/xenbus_client.c | 2 +- drivers/xen/xenbus/xenbus_dev_backend.c | 2 +- drivers/xen/xenbus/xenbus_probe.c | 8 +++--- drivers/xen/xlate_mmu.c | 18 +++--- include/uapi/xen/privcmd.h | 4 +++ include/xen/page.h | 4 +-- include/xen/xen-ops.h | 10 29 files changed, 183 insertions(+), 170 deletions(-) -- 2.1.4 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v2 7/8] hvc/xen: Further s/MFN/GFN clean-up
HVM_PARAM_CONSOLE_PFN is used to retrieved the console PFN for HVM
guest. It returns a PFN (aka GFN) and not a MFN.
Furthermore, use directly virt_to_gfn for both PV and HVM domain rather
than doing a special case for each of the them.
Signed-off-by: Julien Grall
Reviewed-by: David Vrabel
Cc: Greg Kroah-Hartman
Cc: Jiri Slaby
Cc: linuxppc-dev@lists.ozlabs.org
---
Changes in v2:
- Add David's reviewed-by
---
drivers/tty/hvc/hvc_xen.c | 15 +--
1 file changed, 5 insertions(+), 10 deletions(-)
diff --git a/drivers/tty/hvc/hvc_xen.c b/drivers/tty/hvc/hvc_xen.c
index efe5124..10beb15 100644
--- a/drivers/tty/hvc/hvc_xen.c
+++ b/drivers/tty/hvc/hvc_xen.c
@@ -200,7 +200,7 @@ static int xen_hvm_console_init(void)
{
int r;
uint64_t v = 0;
- unsigned long mfn;
+ unsigned long gfn;
struct xencons_info *info;
if (!xen_hvm_domain())
@@ -217,7 +217,7 @@ static int xen_hvm_console_init(void)
}
/*
* If the toolstack (or the hypervisor) hasn't set these values, the
-* default value is 0. Even though mfn = 0 and evtchn = 0 are
+* default value is 0. Even though gfn = 0 and evtchn = 0 are
* theoretically correct values, in practice they never are and they
* mean that a legacy toolstack hasn't initialized the pv console
correctly.
*/
@@ -229,8 +229,8 @@ static int xen_hvm_console_init(void)
r = hvm_get_parameter(HVM_PARAM_CONSOLE_PFN, &v);
if (r < 0 || v == 0)
goto err;
- mfn = v;
- info->intf = xen_remap(mfn << PAGE_SHIFT, PAGE_SIZE);
+ gfn = v;
+ info->intf = xen_remap(gfn << PAGE_SHIFT, PAGE_SIZE);
if (info->intf == NULL)
goto err;
info->vtermno = HVC_COOKIE;
@@ -375,7 +375,6 @@ static int xencons_connect_backend(struct xenbus_device
*dev,
int ret, evtchn, devid, ref, irq;
struct xenbus_transaction xbt;
grant_ref_t gref_head;
- unsigned long mfn;
ret = xenbus_alloc_evtchn(dev, &evtchn);
if (ret)
@@ -390,10 +389,6 @@ static int xencons_connect_backend(struct xenbus_device
*dev,
irq, &domU_hvc_ops, 256);
if (IS_ERR(info->hvc))
return PTR_ERR(info->hvc);
- if (xen_pv_domain())
- mfn = virt_to_gfn(info->intf);
- else
- mfn = __pa(info->intf) >> PAGE_SHIFT;
ret = gnttab_alloc_grant_references(1, &gref_head);
if (ret < 0)
return ret;
@@ -402,7 +397,7 @@ static int xencons_connect_backend(struct xenbus_device
*dev,
if (ref < 0)
return ref;
gnttab_grant_foreign_access_ref(ref, info->xbdev->otherend_id,
- mfn, 0);
+ virt_to_gfn(info->intf), 0);
again:
ret = xenbus_transaction_start(&xbt);
--
2.1.4
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v5 00/46] usb: gadget: rework ep matching and claiming mechanism
Hi, On Fri, Jul 31, 2015 at 04:00:12PM +0200, Robert Baldyga wrote: > Hello, > > This patch series reworks endpoint matching and claiming mechanism in > epautoconf. From v2 there are couple of new patches adding 'ep_match' > to usb_gadget_ops and removing chip-specific quirk handling from generic > code of autoconfig. > > I'm not sure if this patch set isn't too long, as it has 46 patches, > but I decided to send it as single series to avoid problems with patch > applying order. > > The aim of whole patchset is to rework epautoconf code to get rid of > things like name-based endpoint matching and UDC name-based quirks in > generic code. These needed to do some modifications in framework like > adding 'endpoint capabilities flags' feature or adding 'match_ep'. > > Following paragraphs contain brief description of what modifications are > done by particular parts of this patch set: > > Patch (1) introduces new safer endpoint claiming method, basing on new > 'claimed' flag. It was discussed here [1]. I proposed this solution over > year ago and it was accepted, but I apparently forgot to send the final > version of my patch. > > Patches (2-3) add the 'capabilities flags' structure and helper macros. > This solution is inspired by the 'feature flags' originally proposed > by Felipe Balbi in 2013 [2], but unfortunately implementation of this > feature has never been completed. > > Patches (4-36) add' capabilites flags' support to all UDC drivers present > in the kernel tree. It's needed to be done before replacing old endpoint > matching mechanism, otherwise UDC drivers which doesn't set 'capabilities > flags' won't work with new matching function. > > Patch (37) finally replaces old endpoint matching method with the new > one basing on capabilities flags. > > These changes aims to get rid of code, which guesses endpoint capabilities > basing on it's name, and introduce new better replacement. In result > we have better way to describe types and directions supported by each > endpoint. > > For example the old name-based method didn't allow to have endpoint > supporing two types of transfers - there were only ability to support > one or all of endpoint types. The 'capabilities flags' feature supply > precise, flexible and extensible mechanism of description of endpoint > hardware limitations, which is desired for proper endpoint matching. > > Patch (38) removes chip-specific quirk from ep_matches() function. > > Patches (39-40) remove code modifying endpoint and descriptor structures > from ep_matches() function and cleans it up to make it simpler and more > readable. > > Patch (41) add 'match_ep' callback to usb_gadget_ops and make use of > it in epautoconf. This callback allows UDC drivers to supply non-standard > endpoint matching algorithms. > > Patches (42-43) move ep_matches() and find_ep() functions outside > epautoconf and rename them to usb_gadget_ep_match_desc() and > gadget_find_ep_by_name(). It's because they may be useful in 'match_ep' > callbacks in UDC drivers to avoid writing repetitive code. > > Patches (44-46) move chip-specific enpoint matching algorithms from > generic code of usb_ep_autoconfig_ss() function to UDC controller drivers > using 'match_ep' callback. > > In the result we have epautoconf source free of chip-specific code, plus > two new mechanisms allowing to handle non-standard hardware limitations. > > [1] https://lkml.org/lkml/2014/6/16/94 > [2] http://www.spinics.net/lists/linux-usb/msg99662.html adding these to my testing/next after fixing a few build warnings and the comment I had on dwc3 patch. Let's hope it just works :-) -- balbi signature.asc Description: Digital signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v5 07/46] usb: dwc3: gadget: add ep capabilities support
On Fri, Jul 31, 2015 at 04:00:19PM +0200, Robert Baldyga wrote:
> Convert endpoint configuration to new capabilities model.
>
> Signed-off-by: Robert Baldyga
> ---
> drivers/usb/dwc3/gadget.c | 13 +
> 1 file changed, 13 insertions(+)
>
> diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
> index 2feed9e..bd4c3db 100644
> --- a/drivers/usb/dwc3/gadget.c
> +++ b/drivers/usb/dwc3/gadget.c
> @@ -1715,6 +1715,19 @@ static int dwc3_gadget_init_hw_endpoints(struct dwc3
> *dwc,
> return ret;
> }
>
> + if (epnum == 0 || epnum == 1) {
> + dep->endpoint.caps.type_control = true;
> + } else {
> + dep->endpoint.caps.type_iso = true;
> + dep->endpoint.caps.type_bulk = true;
> + dep->endpoint.caps.type_int = true;
> + }
> +
> + if (direction)
> + dep->endpoint.caps.dir_in = true;
> + else
> + dep->endpoint.caps.dir_out = true;
you can avoid the branch for the direction:
dep->endpoint.caps.dir_in = !!direction;
dep->endpoint.caps.dir_out = !direction;
--
balbi
signature.asc
Description: Digital signature
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
GPMC in device tree
Hello, I would please like to ask if describing flash nor used with GPMC, whould be done as described in: https://www.kernel.org/doc/Documentation/devicetree/bindings/mtd/gpmc-nor.txt It is described in the above link as "TI's GPMC", so I'm not sure if it is relevent for powerpc too. Thank you, Ran ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 3/5] powerpc/pseries: don't call strrchr() twice
There is no need to call strrchr() second time. We already know that in that
case parent_path_len either 1 ("/foo") or bigger ("/foo/bar").
Signed-off-by: Andy Shevchenko
---
arch/powerpc/platforms/pseries/of_helpers.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/platforms/pseries/of_helpers.c
b/arch/powerpc/platforms/pseries/of_helpers.c
index 2f363e3..027446a 100644
--- a/arch/powerpc/platforms/pseries/of_helpers.c
+++ b/arch/powerpc/platforms/pseries/of_helpers.c
@@ -23,7 +23,7 @@ struct device_node *pseries_of_derive_parent(const char *path)
if (!strcmp(path, "/"))
return ERR_PTR(-EINVAL);
- if (strrchr(path, '/') != path) {
+ if (parent_path_len > 1) {
parent_path = kmalloc(parent_path_len, GFP_KERNEL);
if (!parent_path)
return ERR_PTR(-ENOMEM);
--
2.4.6
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 4/5] powerpc/pseries: replace kmalloc + strlcpy
The helper kstrndup() will do the same in one line.
Signed-off-by: Andy Shevchenko
---
arch/powerpc/platforms/pseries/of_helpers.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/arch/powerpc/platforms/pseries/of_helpers.c
b/arch/powerpc/platforms/pseries/of_helpers.c
index 027446a..afa 100644
--- a/arch/powerpc/platforms/pseries/of_helpers.c
+++ b/arch/powerpc/platforms/pseries/of_helpers.c
@@ -24,10 +24,9 @@ struct device_node *pseries_of_derive_parent(const char
*path)
return ERR_PTR(-EINVAL);
if (parent_path_len > 1) {
- parent_path = kmalloc(parent_path_len, GFP_KERNEL);
+ parent_path = kstrndup(path, parent_path_len, GFP_KERNEL);
if (!parent_path)
return ERR_PTR(-ENOMEM);
- strlcpy(parent_path, path, parent_path_len);
}
parent = of_find_node_by_path(parent_path);
if (strcmp(parent_path, "/"))
--
2.4.6
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 5/5] powerpc/pseries: re-use code from of_helpers module
The derive_parent() has similar semantics to what we have in newly introduced
of_helpers module. The replacement reduces code base and propagates the actual
error code to the caller.
Signed-off-by: Andy Shevchenko
---
arch/powerpc/platforms/pseries/dlpar.c | 31 +--
1 file changed, 5 insertions(+), 26 deletions(-)
diff --git a/arch/powerpc/platforms/pseries/dlpar.c
b/arch/powerpc/platforms/pseries/dlpar.c
index 47d9cebe..b7f243c 100644
--- a/arch/powerpc/platforms/pseries/dlpar.c
+++ b/arch/powerpc/platforms/pseries/dlpar.c
@@ -18,6 +18,8 @@
#include
#include
#include
+
+#include "of_helpers.h"
#include "offline_states.h"
#include "pseries.h"
@@ -244,36 +246,13 @@ cc_error:
return first_dn;
}
-static struct device_node *derive_parent(const char *path)
-{
- struct device_node *parent;
- char *last_slash;
-
- last_slash = strrchr(path, '/');
- if (last_slash == path) {
- parent = of_find_node_by_path("/");
- } else {
- char *parent_path;
- int parent_path_len = last_slash - path + 1;
- parent_path = kmalloc(parent_path_len, GFP_KERNEL);
- if (!parent_path)
- return NULL;
-
- strlcpy(parent_path, path, parent_path_len);
- parent = of_find_node_by_path(parent_path);
- kfree(parent_path);
- }
-
- return parent;
-}
-
int dlpar_attach_node(struct device_node *dn)
{
int rc;
- dn->parent = derive_parent(dn->full_name);
- if (!dn->parent)
- return -ENOMEM;
+ dn->parent = pseries_of_derive_parent(dn->full_name);
+ if (IS_ERR(dn->parent))
+ return PTR_ERR(dn_parent);
rc = of_attach_node(dn);
if (rc) {
--
2.4.6
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 1/5] powerpc/pseries: extract of_helpers module
Extract a new module to share the code between other modules.
There is no functional change.
Signed-off-by: Andy Shevchenko
---
arch/powerpc/platforms/pseries/Makefile | 1 +
arch/powerpc/platforms/pseries/of_helpers.c | 38 +
arch/powerpc/platforms/pseries/of_helpers.h | 8 ++
arch/powerpc/platforms/pseries/reconfig.c | 34 ++
4 files changed, 49 insertions(+), 32 deletions(-)
create mode 100644 arch/powerpc/platforms/pseries/of_helpers.c
create mode 100644 arch/powerpc/platforms/pseries/of_helpers.h
diff --git a/arch/powerpc/platforms/pseries/Makefile
b/arch/powerpc/platforms/pseries/Makefile
index 0348079..2e857c2 100644
--- a/arch/powerpc/platforms/pseries/Makefile
+++ b/arch/powerpc/platforms/pseries/Makefile
@@ -2,6 +2,7 @@ ccflags-$(CONFIG_PPC64) := $(NO_MINIMAL_TOC)
ccflags-$(CONFIG_PPC_PSERIES_DEBUG)+= -DDEBUG
obj-y := lpar.o hvCall.o nvram.o reconfig.o \
+ of_helpers.o \
setup.o iommu.o event_sources.o ras.o \
firmware.o power.o dlpar.o mobility.o rng.o
obj-$(CONFIG_SMP) += smp.o
diff --git a/arch/powerpc/platforms/pseries/of_helpers.c
b/arch/powerpc/platforms/pseries/of_helpers.c
new file mode 100644
index 000..1cbd896
--- /dev/null
+++ b/arch/powerpc/platforms/pseries/of_helpers.c
@@ -0,0 +1,38 @@
+#include
+#include
+#include
+#include
+
+#include "of_helpers.h"
+
+/**
+ * pseries_of_derive_parent - basically like dirname(1)
+ * @path: the full_name of a node to be added to the tree
+ *
+ * Returns the node which should be the parent of the node
+ * described by path. E.g., for path = "/foo/bar", returns
+ * the node with full_name = "/foo".
+ */
+struct device_node *pseries_of_derive_parent(const char *path)
+{
+ struct device_node *parent = NULL;
+ char *parent_path = "/";
+ size_t parent_path_len = strrchr(path, '/') - path + 1;
+
+ /* reject if path is "/" */
+ if (!strcmp(path, "/"))
+ return ERR_PTR(-EINVAL);
+
+ if (strrchr(path, '/') != path) {
+ parent_path = kmalloc(parent_path_len, GFP_KERNEL);
+ if (!parent_path)
+ return ERR_PTR(-ENOMEM);
+ strlcpy(parent_path, path, parent_path_len);
+ }
+ parent = of_find_node_by_path(parent_path);
+ if (!parent)
+ return ERR_PTR(-EINVAL);
+ if (strcmp(parent_path, "/"))
+ kfree(parent_path);
+ return parent;
+}
diff --git a/arch/powerpc/platforms/pseries/of_helpers.h
b/arch/powerpc/platforms/pseries/of_helpers.h
new file mode 100644
index 000..bb83d39
--- /dev/null
+++ b/arch/powerpc/platforms/pseries/of_helpers.h
@@ -0,0 +1,8 @@
+#ifndef _PSERIES_OF_HELPERS_H
+#define _PSERIES_OF_HELPERS_H
+
+#include
+
+struct device_node *pseries_of_derive_parent(const char *path);
+
+#endif /* _PSERIES_OF_HELPERS_H */
diff --git a/arch/powerpc/platforms/pseries/reconfig.c
b/arch/powerpc/platforms/pseries/reconfig.c
index 0f31952..7c7fcc0 100644
--- a/arch/powerpc/platforms/pseries/reconfig.c
+++ b/arch/powerpc/platforms/pseries/reconfig.c
@@ -22,37 +22,7 @@
#include
#include
-/**
- * derive_parent - basically like dirname(1)
- * @path: the full_name of a node to be added to the tree
- *
- * Returns the node which should be the parent of the node
- * described by path. E.g., for path = "/foo/bar", returns
- * the node with full_name = "/foo".
- */
-static struct device_node *derive_parent(const char *path)
-{
- struct device_node *parent = NULL;
- char *parent_path = "/";
- size_t parent_path_len = strrchr(path, '/') - path + 1;
-
- /* reject if path is "/" */
- if (!strcmp(path, "/"))
- return ERR_PTR(-EINVAL);
-
- if (strrchr(path, '/') != path) {
- parent_path = kmalloc(parent_path_len, GFP_KERNEL);
- if (!parent_path)
- return ERR_PTR(-ENOMEM);
- strlcpy(parent_path, path, parent_path_len);
- }
- parent = of_find_node_by_path(parent_path);
- if (!parent)
- return ERR_PTR(-EINVAL);
- if (strcmp(parent_path, "/"))
- kfree(parent_path);
- return parent;
-}
+#include "of_helpers.h"
static int pSeries_reconfig_add_node(const char *path, struct property
*proplist)
{
@@ -71,7 +41,7 @@ static int pSeries_reconfig_add_node(const char *path, struct
property *proplist
of_node_set_flag(np, OF_DYNAMIC);
of_node_init(np);
- np->parent = derive_parent(path);
+ np->parent = pseries_of_derive_parent(path);
if (IS_ERR(np->parent)) {
err = PTR_ERR(np->parent);
goto out_err;
--
2.4.6
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/l
[PATCH 2/5] powerpc/pseries: fix a potential memory leak
In case we have a full node name like /foo/bar and /foo is not found the
parent_path left unfreed. So, free a memory before return to a caller.
Signed-off-by: Andy Shevchenko
---
arch/powerpc/platforms/pseries/of_helpers.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/platforms/pseries/of_helpers.c
b/arch/powerpc/platforms/pseries/of_helpers.c
index 1cbd896..2f363e3 100644
--- a/arch/powerpc/platforms/pseries/of_helpers.c
+++ b/arch/powerpc/platforms/pseries/of_helpers.c
@@ -15,7 +15,7 @@
*/
struct device_node *pseries_of_derive_parent(const char *path)
{
- struct device_node *parent = NULL;
+ struct device_node *parent;
char *parent_path = "/";
size_t parent_path_len = strrchr(path, '/') - path + 1;
@@ -30,9 +30,7 @@ struct device_node *pseries_of_derive_parent(const char *path)
strlcpy(parent_path, path, parent_path_len);
}
parent = of_find_node_by_path(parent_path);
- if (!parent)
- return ERR_PTR(-EINVAL);
if (strcmp(parent_path, "/"))
kfree(parent_path);
- return parent;
+ return parent ? parent : ERR_PTR(-EINVAL);
}
--
2.4.6
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: powerpc: Add an inline function to update HID0
On Tuesday 04 August 2015 03:38 PM, Michael Ellerman wrote:
> On Tue, 2015-04-08 at 08:30:58 UTC, "Gautham R. Shenoy" wrote:
>> Section 3.7 of Version 1.2 of the Power8 Processor User's Manual
>> prescribes that updates to HID0 be preceded by a SYNC instruction and
>> followed by an ISYNC instruction (Page 91).
>>
>> Create a function name update_hid0() which follows this recipe and
>> invoke it from the static split core path.
>>
>> Signed-off-by: Gautham R. Shenoy
>> ---
>> arch/powerpc/include/asm/kvm_ppc.h | 11 +++
> Why is it in there? It's not KVM related per se.
>
> Where should it go? I think reg.h would be best, ideally near the definition
> for HID0, though that's probably not possible because of ASSEMBLY
> requirements.
> So at the bottom of reg.h ?
just to understand, Something like this will not do?
#define update_hid0(x) __asm__ __volatile__(
"sync\n"\
"mtspr "
__stringify(SPRN_HID0)", %0\n"\
"isync"::"r"(x));
Maddy
>
>> diff --git a/arch/powerpc/include/asm/kvm_ppc.h
>> b/arch/powerpc/include/asm/kvm_ppc.h
>> index c6ef05b..325f1d6 100644
>> --- a/arch/powerpc/include/asm/kvm_ppc.h
>> +++ b/arch/powerpc/include/asm/kvm_ppc.h
>> @@ -685,4 +685,15 @@ static inline ulong kvmppc_get_ea_indexed(struct
>> kvm_vcpu *vcpu, int ra, int rb)
>>
>> extern void xics_wake_cpu(int cpu);
>>
>> +static inline void update_hid0(unsigned long hid0)
>> +{
>> +/*
>> + * The HID0 update should at the very least be preceded by a
>> + * a SYNC instruction followed by an ISYNC instruction
>> + */
>> +mb();
>> +mtspr(SPRN_HID0, hid0);
>> +isync();
> That's going to turn into three separate inline asm blocks, which is maybe a
> bit unfortunate. Have you checked the generated code is what we want, ie. just
> sync, mtspr, isync ?
>
> cheers
> ___
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [v3, 1/2] powerpc/mpc85xx: Create dts components for the FSL QorIQ DPAA FMan
Regards,
Igal Liberman
> -Original Message-
> From: Wood Scott-B07421
> Sent: Tuesday, August 04, 2015 8:00 AM
> To: Liberman Igal-B31950
> Cc: devicet...@vger.kernel.org; linuxppc-dev@lists.ozlabs.org; Bucur
> Madalin-Cristian-B32716 ; linux-
> ker...@vger.kernel.org
> Subject: Re: [v3,1/2] powerpc/mpc85xx: Create dts components for the FSL
> QorIQ DPAA FMan
>
> [Resending after bogofilter adjustment on vger.kernel.org]
>
> On Mon, Aug 03, 2015 at 09:44:01AM +0300, Igal.Liberman wrote:
> > + xmdio0: mdio@f1000{
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + compatible = "fsl,fman-xmdio";
> > + reg = <0xf1000 0x1000>;
> > + interrupts = <101 1 0 0>;
> > + };
>
> Why is this <101 1 0 0> and not <101 2 0 0>? Internal interrupts are active-
> high.
>
OK, I'll fix this issue. Thanks.
Igal.
> > + mdio0: mdio@e1120{
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + compatible = "fsl,fman-mdio";
> > + reg = <0xe1120 0xee0>;
> > + interrupts = <100 1 0 0>;
>
> Likewise.
>
> -Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powernv: Invoke opal_cec_reboot2() on unrecoverable HMI.
From: Mahesh Salgaonkar
Invoke new opal_cec_reboot2() call with reboot type
OPAL_REBOOT_PLATFORM_ERROR (for unrecoverable HMI interrupts) to inform
BMC/OCC about this error, so that BMC can collect relevant data for error
analysis and decide what component to de-configure before rebooting.
This patch depends on:
https://lists.ozlabs.org/pipermail/linuxppc-dev/2015-May/128341.html
https://lists.ozlabs.org/pipermail/linuxppc-dev/2015-May/128342.html
https://lists.ozlabs.org/pipermail/linuxppc-dev/2015-August/132045.html
Signed-off-by: Mahesh Salgaonkar
---
arch/powerpc/platforms/powernv/opal-hmi.c | 19 +++
1 file changed, 19 insertions(+)
diff --git a/arch/powerpc/platforms/powernv/opal-hmi.c
b/arch/powerpc/platforms/powernv/opal-hmi.c
index acefdf9..d000f4e 100644
--- a/arch/powerpc/platforms/powernv/opal-hmi.c
+++ b/arch/powerpc/platforms/powernv/opal-hmi.c
@@ -264,6 +264,8 @@ static void hmi_event_handler(struct work_struct *work)
spin_unlock_irqrestore(&opal_hmi_evt_lock, flags);
if (unrecoverable) {
+ int ret;
+
/* Pull all HMI events from OPAL before we panic. */
while (opal_get_msg(__pa(&msg), sizeof(msg)) == OPAL_SUCCESS) {
u32 type;
@@ -278,6 +280,23 @@ static void hmi_event_handler(struct work_struct *work)
hmi_evt = (struct OpalHMIEvent *)&msg.params[0];
print_hmi_event_info(hmi_evt);
}
+
+ /*
+* Unrecoverable HMI exception. We need to inform BMC/OCC
+* about this error so that it can collect relevant data
+* for error analysis before rebooting.
+*/
+ ret = opal_cec_reboot2(OPAL_REBOOT_PLATFORM_ERROR,
+ "Unrecoverable HMI exception");
+ if (ret == OPAL_UNSUPPORTED) {
+ pr_emerg("Reboot type %d not supported\n",
+ OPAL_REBOOT_PLATFORM_ERROR);
+ }
+
+ /*
+* Fall through and panic if opal_cec_reboot2() returns
+* OPAL_UNSUPPORTED.
+*/
panic("Unrecoverable HMI exception");
}
}
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v2] powerpc: Add an inline function to update HID0
Section 3.7 of Version 1.2 of the Power8 Processor User's Manual
prescribes that updates to HID0 be preceded by a SYNC instruction and
followed by an ISYNC instruction (Page 91).
Create an inline function name update_hid0() which follows this recipe
and invoke it from the static split core path.
Signed-off-by: Gautham R. Shenoy
---
[v1--> v2: Moved defn of update_hid0 to reg.h from kvm_ppc.h]
arch/powerpc/include/asm/reg.h | 13 +
arch/powerpc/platforms/powernv/subcore.c | 4 ++--
2 files changed, 15 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/include/asm/reg.h b/arch/powerpc/include/asm/reg.h
index af56b5c..beb98ac 100644
--- a/arch/powerpc/include/asm/reg.h
+++ b/arch/powerpc/include/asm/reg.h
@@ -12,6 +12,8 @@
#include
#include
+#include
+#include
/* Pickup Book E specific registers. */
#if defined(CONFIG_BOOKE) || defined(CONFIG_40x)
@@ -1281,6 +1283,17 @@ struct pt_regs;
extern void ppc_save_regs(struct pt_regs *regs);
+static inline void update_hid0(unsigned long hid0)
+{
+ /*
+* The HID0 update should at the very least be preceded by a
+* a SYNC instruction followed by an ISYNC instruction
+*/
+ mb();
+ mtspr(SPRN_HID0, hid0);
+ isync();
+}
+
#endif /* __ASSEMBLY__ */
#endif /* __KERNEL__ */
#endif /* _ASM_POWERPC_REG_H */
diff --git a/arch/powerpc/platforms/powernv/subcore.c
b/arch/powerpc/platforms/powernv/subcore.c
index f60f80a..37e77bf 100644
--- a/arch/powerpc/platforms/powernv/subcore.c
+++ b/arch/powerpc/platforms/powernv/subcore.c
@@ -190,7 +190,7 @@ static void unsplit_core(void)
hid0 = mfspr(SPRN_HID0);
hid0 &= ~HID0_POWER8_DYNLPARDIS;
- mtspr(SPRN_HID0, hid0);
+ update_hid0(hid0);
update_hid_in_slw(hid0);
while (mfspr(SPRN_HID0) & mask)
@@ -227,7 +227,7 @@ static void split_core(int new_mode)
/* Write new mode */
hid0 = mfspr(SPRN_HID0);
hid0 |= HID0_POWER8_DYNLPARDIS | split_parms[i].value;
- mtspr(SPRN_HID0, hid0);
+ update_hid0(hid0);
update_hid_in_slw(hid0);
/* Wait for it to happen */
--
1.9.3
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: powerpc: Add an inline function to update HID0
Hi Michael,
On Tue, Aug 04, 2015 at 08:08:58PM +1000, Michael Ellerman wrote:
> On Tue, 2015-04-08 at 08:30:58 UTC, "Gautham R. Shenoy" wrote:
> > Section 3.7 of Version 1.2 of the Power8 Processor User's Manual
> > prescribes that updates to HID0 be preceded by a SYNC instruction and
> > followed by an ISYNC instruction (Page 91).
> >
> > Create a function name update_hid0() which follows this recipe and
> > invoke it from the static split core path.
> >
> > Signed-off-by: Gautham R. Shenoy
> > ---
> > arch/powerpc/include/asm/kvm_ppc.h | 11 +++
>
> Why is it in there? It's not KVM related per se.
Ok. Will fix this.
>
> Where should it go? I think reg.h would be best, ideally near the definition
> for HID0, though that's probably not possible because of ASSEMBLY
> requirements.
> So at the bottom of reg.h ?
>
> > diff --git a/arch/powerpc/include/asm/kvm_ppc.h
> > b/arch/powerpc/include/asm/kvm_ppc.h
> > index c6ef05b..325f1d6 100644
> > --- a/arch/powerpc/include/asm/kvm_ppc.h
> > +++ b/arch/powerpc/include/asm/kvm_ppc.h
> > @@ -685,4 +685,15 @@ static inline ulong kvmppc_get_ea_indexed(struct
> > kvm_vcpu *vcpu, int ra, int rb)
> >
> > extern void xics_wake_cpu(int cpu);
> >
> > +static inline void update_hid0(unsigned long hid0)
> > +{
> > + /*
> > +* The HID0 update should at the very least be preceded by a
> > +* a SYNC instruction followed by an ISYNC instruction
> > +*/
> > + mb();
> > + mtspr(SPRN_HID0, hid0);
> > + isync();
>
> That's going to turn into three separate inline asm blocks, which is maybe a
> bit unfortunate. Have you checked the generated code is what we want, ie. just
> sync, mtspr, isync ?
>
Yes, the objdump of subcore.o shows exactly these three instructions:
7c 00 04 ac sync
7c 70 fb a6 mtspr 1008,r3
4c 00 01 2c isync
> cheers
>
--
Thanks and Regards
gautham.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: powerpc: Add an inline function to update HID0
On Tue, 2015-04-08 at 08:30:58 UTC, "Gautham R. Shenoy" wrote:
> Section 3.7 of Version 1.2 of the Power8 Processor User's Manual
> prescribes that updates to HID0 be preceded by a SYNC instruction and
> followed by an ISYNC instruction (Page 91).
>
> Create a function name update_hid0() which follows this recipe and
> invoke it from the static split core path.
>
> Signed-off-by: Gautham R. Shenoy
> ---
> arch/powerpc/include/asm/kvm_ppc.h | 11 +++
Why is it in there? It's not KVM related per se.
Where should it go? I think reg.h would be best, ideally near the definition
for HID0, though that's probably not possible because of ASSEMBLY requirements.
So at the bottom of reg.h ?
> diff --git a/arch/powerpc/include/asm/kvm_ppc.h
> b/arch/powerpc/include/asm/kvm_ppc.h
> index c6ef05b..325f1d6 100644
> --- a/arch/powerpc/include/asm/kvm_ppc.h
> +++ b/arch/powerpc/include/asm/kvm_ppc.h
> @@ -685,4 +685,15 @@ static inline ulong kvmppc_get_ea_indexed(struct
> kvm_vcpu *vcpu, int ra, int rb)
>
> extern void xics_wake_cpu(int cpu);
>
> +static inline void update_hid0(unsigned long hid0)
> +{
> + /*
> + * The HID0 update should at the very least be preceded by a
> + * a SYNC instruction followed by an ISYNC instruction
> + */
> + mb();
> + mtspr(SPRN_HID0, hid0);
> + isync();
That's going to turn into three separate inline asm blocks, which is maybe a
bit unfortunate. Have you checked the generated code is what we want, ie. just
sync, mtspr, isync ?
cheers
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [V3] powerpc/irq: Enable some more exceptions in /proc/interrupts interface
On Mon, 2015-13-07 at 08:16:06 UTC, Anshuman Khandual wrote: > This patch enables facility unavailable exceptions for generic facility, > FPU, ALTIVEC and VSX in /proc/interrupts listing by incrementing their > newly added IRQ statistical counters as and when these exceptions happen. > This also adds couple of helper functions which will be called from within > the interrupt handler context to update their statistics. Similarly this > patch also enables alignment and program check exceptions as well. ... > diff --git a/arch/powerpc/kernel/exceptions-64s.S > b/arch/powerpc/kernel/exceptions-64s.S > index 0a0399c2..a86180c 100644 > --- a/arch/powerpc/kernel/exceptions-64s.S > +++ b/arch/powerpc/kernel/exceptions-64s.S > @@ -1158,6 +1158,7 @@ BEGIN_FTR_SECTION > END_FTR_SECTION_IFSET(CPU_FTR_TM) > #endif > bl load_up_fpu > + bl fpu_unav_exceptions_count Is it safe to call C code here? > b fast_exception_return > #ifdef CONFIG_PPC_TRANSACTIONAL_MEM > 2: /* User process was in a transaction */ cheers ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Missing Linux patches
Le 02/08/2015 21:05, Markus Stockhausen a écrit : Hi Christophe, I saw that this patch from you is still missing in Linux mainline: https://lists.ozlabs.org/pipermail/linuxppc-dev/2014-September/121144.html Is there any reason for not using it? Markus Hi, I sent v3 of that Patch on 19 May 2015, taking into account all comments I have received. I have not received any further comments so I expect it will be applied. Christophe ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 6/6 v2] ASoC: fsl_ssi: adjust set DAI format in AC'97 mode
On Tue, Aug 04, 2015 at 12:42:48AM +0200, Maciej S. Szmigiero wrote: > In cases like this where only one patch of six patch series is updated > should other ones be resubmitted as well to keep the full patch series > together? Yes, any unapplied patches should be resubmitted. signature.asc Description: Digital signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc: Add an inline function to update HID0
Section 3.7 of Version 1.2 of the Power8 Processor User's Manual
prescribes that updates to HID0 be preceded by a SYNC instruction and
followed by an ISYNC instruction (Page 91).
Create a function name update_hid0() which follows this recipe and
invoke it from the static split core path.
Signed-off-by: Gautham R. Shenoy
---
arch/powerpc/include/asm/kvm_ppc.h | 11 +++
arch/powerpc/platforms/powernv/subcore.c | 4 ++--
2 files changed, 13 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/include/asm/kvm_ppc.h
b/arch/powerpc/include/asm/kvm_ppc.h
index c6ef05b..325f1d6 100644
--- a/arch/powerpc/include/asm/kvm_ppc.h
+++ b/arch/powerpc/include/asm/kvm_ppc.h
@@ -685,4 +685,15 @@ static inline ulong kvmppc_get_ea_indexed(struct kvm_vcpu
*vcpu, int ra, int rb)
extern void xics_wake_cpu(int cpu);
+static inline void update_hid0(unsigned long hid0)
+{
+ /*
+* The HID0 update should at the very least be preceded by a
+* a SYNC instruction followed by an ISYNC instruction
+*/
+ mb();
+ mtspr(SPRN_HID0, hid0);
+ isync();
+}
+
#endif /* __POWERPC_KVM_PPC_H__ */
diff --git a/arch/powerpc/platforms/powernv/subcore.c
b/arch/powerpc/platforms/powernv/subcore.c
index f60f80a..37e77bf 100644
--- a/arch/powerpc/platforms/powernv/subcore.c
+++ b/arch/powerpc/platforms/powernv/subcore.c
@@ -190,7 +190,7 @@ static void unsplit_core(void)
hid0 = mfspr(SPRN_HID0);
hid0 &= ~HID0_POWER8_DYNLPARDIS;
- mtspr(SPRN_HID0, hid0);
+ update_hid0(hid0);
update_hid_in_slw(hid0);
while (mfspr(SPRN_HID0) & mask)
@@ -227,7 +227,7 @@ static void split_core(int new_mode)
/* Write new mode */
hid0 = mfspr(SPRN_HID0);
hid0 |= HID0_POWER8_DYNLPARDIS | split_parms[i].value;
- mtspr(SPRN_HID0, hid0);
+ update_hid0(hid0);
update_hid_in_slw(hid0);
/* Wait for it to happen */
--
1.9.3
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
