Re: [PATCH V3] mmc:of_spi: Update the code of getting voltage-ranges

[Chris Ball]

Hi Haijun,

On Sun, Aug 11 2013, Haijun Zhang wrote:
> Using function mmc_of_parse_voltage() to get voltage-ranges.
>
> Signed-off-by: Haijun Zhang 

The patchset contains patches 1-3 of 3, and also this unnumbered patch
v3.  Which order should I use to apply this patch?

Thanks,

- Chris.
-- 
Chris Ball  
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH 2/2] ppc: kvm: use anon_inode_getfd() with O_CLOEXEC flag

[Yann Droneaud]

KVM uses anon_inode_get() to allocate file descriptors as part
of some of its ioctls. But those ioctls are lacking a flag argument
allowing userspace to choose options for the newly opened file descriptor.

In such case it's advised to use O_CLOEXEC by default so that
userspace is allowed to choose, without race, if the file descriptor
is going to be inherited across exec().

This patch set O_CLOEXEC flag on all file descriptors created
with anon_inode_getfd() to not leak file descriptors across exec().

Signed-off-by: Yann Droneaud 
Link: http://lkml.kernel.org/r/cover.1377372576.git.ydrone...@opteya.com

---
 arch/powerpc/kvm/book3s_64_mmu_hv.c | 2 +-
 arch/powerpc/kvm/book3s_64_vio.c| 2 +-
 arch/powerpc/kvm/book3s_hv.c| 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/powerpc/kvm/book3s_64_mmu_hv.c 
b/arch/powerpc/kvm/book3s_64_mmu_hv.c
index 710d313..f7c9e8a 100644
--- a/arch/powerpc/kvm/book3s_64_mmu_hv.c
+++ b/arch/powerpc/kvm/book3s_64_mmu_hv.c
@@ -1579,7 +1579,7 @@ int kvm_vm_ioctl_get_htab_fd(struct kvm *kvm, struct 
kvm_get_htab_fd *ghf)
ctx->first_pass = 1;
 
rwflag = (ghf->flags & KVM_GET_HTAB_WRITE) ? O_WRONLY : O_RDONLY;
-   ret = anon_inode_getfd("kvm-htab", &kvm_htab_fops, ctx, rwflag);
+   ret = anon_inode_getfd("kvm-htab", &kvm_htab_fops, ctx, rwflag | 
O_CLOEXEC);
if (ret < 0) {
kvm_put_kvm(kvm);
return ret;
diff --git a/arch/powerpc/kvm/book3s_64_vio.c b/arch/powerpc/kvm/book3s_64_vio.c
index b2d3f3b..54cf9bc 100644
--- a/arch/powerpc/kvm/book3s_64_vio.c
+++ b/arch/powerpc/kvm/book3s_64_vio.c
@@ -136,7 +136,7 @@ long kvm_vm_ioctl_create_spapr_tce(struct kvm *kvm,
mutex_unlock(&kvm->lock);
 
return anon_inode_getfd("kvm-spapr-tce", &kvm_spapr_tce_fops,
-   stt, O_RDWR);
+   stt, O_RDWR | O_CLOEXEC);
 
 fail:
if (stt) {
diff --git a/arch/powerpc/kvm/book3s_hv.c b/arch/powerpc/kvm/book3s_hv.c
index e8d51cb..3503829 100644
--- a/arch/powerpc/kvm/book3s_hv.c
+++ b/arch/powerpc/kvm/book3s_hv.c
@@ -1556,7 +1556,7 @@ long kvm_vm_ioctl_allocate_rma(struct kvm *kvm, struct 
kvm_allocate_rma *ret)
if (!ri)
return -ENOMEM;
 
-   fd = anon_inode_getfd("kvm-rma", &kvm_rma_fops, ri, O_RDWR);
+   fd = anon_inode_getfd("kvm-rma", &kvm_rma_fops, ri, O_RDWR | O_CLOEXEC);
if (fd < 0)
kvm_release_rma(ri);
 
-- 
1.8.3.1

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH 0/2] kvm: use anon_inode_getfd() with O_CLOEXEC flag

[Yann Droneaud]

Hi,

Following a patchset asking to change calls to get_unused_flag() [1]
to use O_CLOEXEC, Alex Williamson [2][3] decided to change VFIO
to use the flag.

Since it's a related subsystem to KVM, using O_CLOEXEC for
file descriptors created by KVM might be applicable too.

I'm suggesting to change calls to anon_inode_getfd() to use O_CLOEXEC
as default flag.

This patchset should be reviewed to not break existing userspace program.

BTW, if it's not applicable, I would suggest that new ioctls be added to
KVM subsystem, those ioctls would have a "flag" field added to their arguments.
Such "flag" would let userspace choose the open flag to use.
See for example other APIs using anon_inode_getfd() such as fanotify,
inotify, signalfd and timerfd.

You might be interested to read:

- Secure File Descriptor Handling (Ulrich Drepper, 2008)
  http://udrepper.livejournal.com/20407.html

- Excuse me son, but your code is leaking !!! (Dan Walsh, March 2012) 
  http://danwalsh.livejournal.com/53603.html

Regards.

[1] http://lkml.kernel.org/r/cover.1376327678.git.ydrone...@opteya.com
[2] http://lkml.kernel.org/r/1377186804.25163.17.ca...@ul30vt.home
[3] http://lkml.kernel.org/r/20130822171744.1297.13711.st...@bling.home

Yann Droneaud (2):
  kvm: use anon_inode_getfd() with O_CLOEXEC flag
  ppc: kvm: use anon_inode_getfd() with O_CLOEXEC flag

 arch/powerpc/kvm/book3s_64_mmu_hv.c | 2 +-
 arch/powerpc/kvm/book3s_64_vio.c| 2 +-
 arch/powerpc/kvm/book3s_hv.c| 2 +-
 virt/kvm/kvm_main.c | 6 +++---
 4 files changed, 6 insertions(+), 6 deletions(-)

-- 
1.8.3.1

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: Loading kernel on MPC86x

[Martin Hinner]

Hello again,

  just a quick update: I have spent some more time on this and now I
can boot into kernel (it works even with initramfs and simple assembly
HelloWorld, so it's time to compile userland now). The problem was
that kernel must be at location 0. Another problem was that interrupts
got re-enabled during execution of my bootloader (I am doing some
syscalls -> goes  to Cisco rom), otherwise it crashed randomly. And
finally it seems that stack must be < 8M. After this kernel boots.

Anyway, I would still appreciate clarification on vmlinux:__start
entry conditions:

- must be loaded at 0 (but why arch/powerpc/boot/main.c has option to
allocate space for kernel at nonzero addr ?)
- stack? Does it really have to be < 8M ?
- interrupts disabled (really ;-) )
- MSR.PR=0/LE=0/EE=0, but what other bits (RI? IP=0? ME?)
- IMMR 0xff00
- and of course correct entry arguments in registers

anything else?

I am also curious why CONFIG_PPC_EARLY_DEBUG_CPM uses
CONFIG_PPC_EARLY_DEBUG_CPM_ADDR as pointer to transmit SMC buffer and
not address of CPM/SCM parameter RAM ? TX buffer address can be read
from SMC parameter RAM. Wouldn't this solution be more portable? At
least this way I do it when I take over console from Cisco
startup/rommon.

Martin
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Loading kernel on MPC86x

[Martin Hinner]

Hi,

  I am trying to load kernel 2.6.39 on MPC86x-based Cisco 8xx router
(I need development platform for another embedded project and this
router was first suitable device I have).

So far I have:

- built crosscompiler
- created simple bootloader based on CILO code that can load ELF
(zImage) into memory, relocate and start it
- Modified Linux kernel arch/powerpc/boot directory so as it can
decompress kernel into memory and start it (__start gets executed)
- Created dts for the device (arch/powerpc/boot/main.c is making
printf via correct device without any hacks)

Most of tasks were accomplished by creating temporary debug output to
cpm-uart and finding problems step-by-step, however I am a bit stuck
with kernel now and I would appreciate some help from someone who has
already done similar task.

Hardware info: The MPC86x has 32MB SDRAM located at 0x0 and
0x8000 (I have not checked how this is done but it looks like it's
alias as both memory regions have the same data). IMMR is 0xff00,
ROM is at 0xfff0. Initial stack is in first 64kB (I left it as
Cisco rommon has set it up).

I had to modify arch/powerpc/boot/main.c so as it loads kernel to a
different location than 0 and does not overwrite rommon's exception
vectors & stack.

arch/powerpc/boot/main.c starts succesfully kernel (I can see debug
output produced by modified '__start' at
arch/powerpc/kernel/head_8xx.S). Unfortunately call to "bl
initial_mmu" fails (there is no exception that rommon catches,
processor just freezes and as I do not have BDM attached to it I have
no idea what is going wrong).

My feeling is that I should load vmlinux to address 0 as there is no
relocation code anywhere. Is this correct? I can live with it (stack
will be relocated in my bootloader, but before I start doing this work
(more than stack relocation is involved) I would like to make sure it
is really my problem).

Second, I would like to ask what else do I have to set-up before
jumping to arch/powerpc/kernel/head_8xx.S ; is vmlinux sitting at
0x0 and "temporary" stack at safe place (end of mem) enough ? How
about interrupts ? What if some of them were enabled by Cisco
startup/rommon ?

Do I understand correctly that
arch/powerpc/kernel/head_8xx.S:initial_mmu (and then real mm handler)
sets-up MMU so as I can always access IMMR region and print debug
characters on console? (I am sorry I am not yet familiar with MPC8xx
MMU so the code is a bit confusing for me).

I do not understand how kernel base 0xC000 works; kernel is
normally loaded at 0, however all references go to 0xC000. Does
initial_mmu set-up "mapping" from 0xC000 to 0x0 or do I miss
anything? When switch from 0 to 0xC000 happens?

Maybe a link to document describing how kernel on PowerPC starts would
clarify all my question, but all I have found is focused on using
existing bootloaders (U-Boot) with no detailed description ...

Thank you,

Martin
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH V3] i2c: move of helpers into the core

[Mauro Carvalho Chehab]

Em Thu, 22 Aug 2013 18:00:14 +0200
Wolfram Sang  escreveu:

> I2C of helpers used to live in of_i2c.c but experience (from SPI) shows
> that it is much cleaner to have this in the core. This also removes a
> circular dependency between the helpers and the core, and so we can
> finally register child nodes in the core instead of doing this manually
> in each driver. So, fix the drivers and documentation, too.
> 
> Acked-by: Rob Herring 
> Reviewed-by: Felipe Balbi 
> Acked-by: Rafael J. Wysocki 
> Tested-by: Sylwester Nawrocki 
> Signed-off-by: Wolfram Sang 

Acked-by: Mauro Carvalho Chehab 

> ---
> 
> V2->V3: Was trying to be too smart by only fixing includes needed.
>   Took a more general approach this time, converting of_i2c.h
>   to i2c.h in case i2c.h was not already there. Otherwise
>   remove it. Improved my build scripts and no build failures,
>   no complaints from buildbot as well.
> 
> 
>  Documentation/acpi/enumeration.txt  |1 -
>  arch/powerpc/platforms/44x/warp.c   |1 -
>  drivers/gpu/drm/tilcdc/tilcdc_slave.c   |1 -
>  drivers/gpu/drm/tilcdc/tilcdc_tfp410.c  |1 -
>  drivers/gpu/host1x/drm/output.c |2 +-
>  drivers/i2c/busses/i2c-at91.c   |3 -
>  drivers/i2c/busses/i2c-cpm.c|6 --
>  drivers/i2c/busses/i2c-davinci.c|2 -
>  drivers/i2c/busses/i2c-designware-platdrv.c |2 -
>  drivers/i2c/busses/i2c-gpio.c   |3 -
>  drivers/i2c/busses/i2c-i801.c   |2 -
>  drivers/i2c/busses/i2c-ibm_iic.c|4 -
>  drivers/i2c/busses/i2c-imx.c|3 -
>  drivers/i2c/busses/i2c-mpc.c|2 -
>  drivers/i2c/busses/i2c-mv64xxx.c|3 -
>  drivers/i2c/busses/i2c-mxs.c|3 -
>  drivers/i2c/busses/i2c-nomadik.c|3 -
>  drivers/i2c/busses/i2c-ocores.c |3 -
>  drivers/i2c/busses/i2c-octeon.c |3 -
>  drivers/i2c/busses/i2c-omap.c   |3 -
>  drivers/i2c/busses/i2c-pnx.c|3 -
>  drivers/i2c/busses/i2c-powermac.c   |9 +-
>  drivers/i2c/busses/i2c-pxa.c|2 -
>  drivers/i2c/busses/i2c-s3c2410.c|2 -
>  drivers/i2c/busses/i2c-sh_mobile.c  |2 -
>  drivers/i2c/busses/i2c-sirf.c   |3 -
>  drivers/i2c/busses/i2c-stu300.c |2 -
>  drivers/i2c/busses/i2c-tegra.c  |3 -
>  drivers/i2c/busses/i2c-versatile.c  |2 -
>  drivers/i2c/busses/i2c-wmt.c|3 -
>  drivers/i2c/busses/i2c-xiic.c   |3 -
>  drivers/i2c/i2c-core.c  |  109 +-
>  drivers/i2c/i2c-mux.c   |3 -
>  drivers/i2c/muxes/i2c-arb-gpio-challenge.c  |1 -
>  drivers/i2c/muxes/i2c-mux-gpio.c|1 -
>  drivers/i2c/muxes/i2c-mux-pinctrl.c |1 -
>  drivers/media/platform/exynos4-is/fimc-is-i2c.c |4 +-
>  drivers/media/platform/exynos4-is/fimc-is.c |2 +-
>  drivers/media/platform/exynos4-is/media-dev.c   |1 -
>  drivers/of/Kconfig  |6 --
>  drivers/of/Makefile |1 -
>  drivers/of/of_i2c.c |  114 
> ---
>  drivers/staging/imx-drm/imx-tve.c   |2 +-
>  include/linux/i2c.h |   20 
>  include/linux/of_i2c.h  |   46 -
>  sound/soc/fsl/imx-sgtl5000.c|2 +-
>  sound/soc/fsl/imx-wm8962.c  |2 +-
>  47 files changed, 138 insertions(+), 262 deletions(-)
>  delete mode 100644 drivers/of/of_i2c.c
>  delete mode 100644 include/linux/of_i2c.h
> 
> diff --git a/Documentation/acpi/enumeration.txt 
> b/Documentation/acpi/enumeration.txt
> index d9be7a9..958266e 100644
> --- a/Documentation/acpi/enumeration.txt
> +++ b/Documentation/acpi/enumeration.txt
> @@ -238,7 +238,6 @@ An I2C bus (controller) driver does:
>   if (ret)
>   /* handle error */
>  
> - of_i2c_register_devices(adapter);
>   /* Enumerate the slave devices behind this bus via ACPI */
>   acpi_i2c_register_devices(adapter);
>  
> diff --git a/arch/powerpc/platforms/44x/warp.c 
> b/arch/powerpc/platforms/44x/warp.c
> index 4cfa499..534574a 100644
> --- a/arch/powerpc/platforms/44x/warp.c
> +++ b/arch/powerpc/platforms/44x/warp.c
> @@ -16,7 +16,6 @@
>  #include 
>  #include 
>  #include 
> -#include 
>  #include 
>  #include 
>  
> diff --git a/drivers/gpu/drm/tilcdc/tilcdc_slave.c 
> b/drivers/gpu/drm/tilcdc/tilcdc_slave.c
> index dfffaf0..a19f657 100644
> --- a/drivers/gpu/drm/tilcdc/tilcdc_slave.c
> +++ b/drivers/gpu/drm/tilcdc/tilcdc_slave.c
> @@ -16,7 +16,6 @@
>   */
>  
>

Re: Detecting LD/ST instruction

[Sukadev Bhattiprolu]

Michael Neuling [mi...@neuling.org] wrote:
| > I am working on implementing the 'perf mem' command for Power
| > systems. This would for instance, let us know where in the memory
| > hierarchy (L1, L2, Local RAM etc) the data for a load/store
| > instruction was found (hit).
| > 
| > On Power7, if the mcmcra[DCACHE_MISS] is clear _and_ the
| > instruction is a load/store, then it implies a L1-hit.
| > 
| > Unlike on Power8, the Power7 event vector has no indication
| > if the instruction was load/store.
| > 
| > In the context of a PMU interrupt, is there any way to determine
| > if an instruction is a load/store ?
| 
| You could read the instruction from memory and work it out.  
| 
| We do something similar to this in power_pmu_bhrb_to() where we read the
| instruction and work out where the branch is going to.
| 
| If you do this, please use and/or extend the functions in
| arch/powerpc/lib/code-patching.c

Here is a draft of what I could come up with.  With this patch, 
the number of L1 hits on Power7 matches that on Power8 for one
application.

But, wondering if there is a more efficient way to do this - there
are over 50 flavors of load and store!

(btw, I will resend my whole patchset after some time-off).
---

>From db90cd382f4c1c0d84a0cfb07c9ffdb05d529456 Mon Sep 17 00:00:00 2001
From: Sukadev Bhattiprolu 
Date: Fri, 23 Aug 2013 18:35:02 -0700
Subject: [PATCH 1/1] Try to detect load/store instruction on Power7

Signed-off-by: Sukadev Bhattiprolu 
---
 arch/powerpc/include/asm/code-patching.h |1 +
 arch/powerpc/lib/code-patching.c |   97 ++
 arch/powerpc/perf/power7-pmu.c   |   21 +++
 3 files changed, 119 insertions(+)

diff --git a/arch/powerpc/include/asm/code-patching.h 
b/arch/powerpc/include/asm/code-patching.h
index a6f8c7a..3e47fe0 100644
--- a/arch/powerpc/include/asm/code-patching.h
+++ b/arch/powerpc/include/asm/code-patching.h
@@ -34,6 +34,7 @@ int instr_is_branch_to_addr(const unsigned int *instr, 
unsigned long addr);
 unsigned long branch_target(const unsigned int *instr);
 unsigned int translate_branch(const unsigned int *dest,
  const unsigned int *src);
+int instr_is_load_store(const unsigned int *instr);
 
 static inline unsigned long ppc_function_entry(void *func)
 {
diff --git a/arch/powerpc/lib/code-patching.c b/arch/powerpc/lib/code-patching.c
index 17e5b23..10e7839 100644
--- a/arch/powerpc/lib/code-patching.c
+++ b/arch/powerpc/lib/code-patching.c
@@ -159,6 +159,103 @@ unsigned int translate_branch(const unsigned int *dest, 
const unsigned int *src)
return 0;
 }
 
+/*
+ * TODO: this is same as branch_opcode(). Rename that function
+ * and re-use it ?
+ */
+static unsigned int load_store_opcode(const unsigned int instr)
+{
+   return (instr >> 26) & 0X3F;
+}
+
+static unsigned int load_store_xval(const unsigned int instr)
+{
+   return (instr >> 1) & 0x3FF;/* bits 21..30 */
+}
+
+/*
+ * Values of bits 21:30 of Fixed-point load and store instructions
+ * Reference: PowerISA_V2.06B_Public.pdf, Sections 3.3.2 through 3.3.6
+ * 4.6.2 through 4.6.4.
+ */
+#definex_lbzx  87
+#definex_lbzux 119
+#definex_lhzx  279
+#definex_lhzux 311
+#definex_lhax  343
+#definex_lhaux 375
+#definex_lwzx  23
+#definex_lwzux 55
+#definex_lwax  341
+#definex_lwaux 373
+#definex_ldx   21
+#definex_ldux  53
+#definex_stbx  215
+#definex_stbux 247
+#definex_sthx  407
+#definex_sthux 439
+#definex_stwx  151
+#definex_stwux 183
+#definex_stdx  149
+#definex_stdux 181
+#definex_lhbrx 790
+#definex_lwbrx 534
+#definex_sthbrx918
+#definex_stwbrx662
+#definex_ldbrx 532
+#definex_stdbrx660
+#definex_lswi  597
+#definex_lswx  533
+#definex_stswi 725
+#definex_stswx 661
+#definex_lfsx  535
+#definex_lfsux 567
+#definex_lfdx  599
+#definex_lfdux 631
+#definex_lfiwax855
+#definex_lfiwzx887
+#definex_stfsx 663
+#definex_stfsux695
+#definex_stfdx 727
+#definex_stfdux759
+#definex_stfiwax   983
+#definex_lfdpx 791
+#definex_stfdpx919
+
+static unsigned int x_form_load_store[] = {
+   x_lbzx, x_lbzux,x_lhzx, x_lhzux,x_lhax,
+   x_lhaux,x_lwzx, x_lwzux,x_lwax, x_lwaux,
+   x_ldx,  x_ldux, x_stbx, x_stbux,x_sthx,
+   x_sthux,x_stwx, x_stwux,x_stdx, x_stdux,
+   x_lhbrx

Re: ppc/sata-fsl: orphan config value: CONFIG_MPC8315_DS

[Anthony Foiani]

Scott Wood  writes:

> On Fri, 2013-08-23 at 17:41 -0600, Anthony Foiani wrote:
> > In my original patch [...]  I used "fsl,sata-max-gen".  I thought
> > Jeff disliked it, so I changed it be more generic -- but maybe I
> > misread his complaint.  (And while his opinions are still
> > respected, new maintainers might have different tastes.)
>
> I didn't see anything to that effect from Jeff in that thread -- maybe
> it was elsewhere.

I think I'm referring to this message:

  http://article.gmane.org/gmane.linux.ports.ppc.embedded/58720

As he was referring me to generic methods, I inferred that I should be
providing generic knobs...

> The device tree describes the hardware, not the driver -- and thus
> should be free to use clearer wording. :-)

*nod*

> As for fsl-specific versus generic, generic is fine but then it
> needs to be documented in a generic place.

Agreed.  I actually prefer the "generation" nomenclature, as it has a
more direct/straightforward interpretation.  ("speed=1" vs
"generation=1"; the latter is a much bigger clue, IMHO.)

> Sorry, linux-ide.

Ok, thanks.

I'll wait a few days to see if there are any other comments or
concerns, then I'll spin a final version

As always, thanks for the review and insight!

Best regards,
Anthony Foiani
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev