Re: [PATCH 3/3] cpufreq: ppc: Fix handling of non-existent clocks

2014-04-21 Thread Viresh Kumar 
On 17 April 2014 15:23, Geert Uytterhoeven geert+rene...@glider.be wrote:
 If the clock doesn't exist, clk_get_rate() returns -EINVAL

You clk_get_rate() isn't written well then, it should return zero.
@Mike: I didn't see this clearly mentioned in clk.h, should we fix
that?

, which becomes
 a large number (freq is u32), failing the freq  min_cpufreq test.
 Explicitly test for (u32)-EINVAL to fix this.

That's a bad check. We should have done this instead:

(s32)freq  0; but that would be true for high values of clock. And that's
why clk_get_rate() must return zero for errors.

 Update the comment, and fix a grammer issue while we're at it.

 Signed-off-by: Geert Uytterhoeven geert+rene...@glider.be
 ---
  drivers/cpufreq/ppc-corenet-cpufreq.c |7 ---
  1 file changed, 4 insertions(+), 3 deletions(-)

 diff --git a/drivers/cpufreq/ppc-corenet-cpufreq.c 
 b/drivers/cpufreq/ppc-corenet-cpufreq.c
 index 53881d78a931..7027eab814ce 100644
 --- a/drivers/cpufreq/ppc-corenet-cpufreq.c
 +++ b/drivers/cpufreq/ppc-corenet-cpufreq.c
 @@ -179,10 +179,11 @@ static int corenet_cpufreq_cpu_init(struct 
 cpufreq_policy *policy)
 clk = of_clk_get(data-parent, i);
 freq = clk_get_rate(clk);
 /*
 -* the clock is valid if its frequency is not masked
 -* and large than minimum allowed frequency.
 +* the clock is valid if it exists, its frequency is not
 +* masked, and larger than minimum allowed frequency.
  */
 -   if (freq  min_cpufreq || (mask  (1  i)))
 +   if (freq == (u32)-EINVAL || freq  min_cpufreq ||
 +   (mask  (1  i)))
 table[i].frequency = CPUFREQ_ENTRY_INVALID;
 else
 table[i].frequency = freq / 1000;
 --
 1.7.9.5

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

Re: [PATCH 1/2] powerpc/powernv: clear the refcount for pci_dev on powernv platform

2014-04-21 Thread Wei Yang 
On Mon, Apr 21, 2014 at 01:35:34PM +1000, Benjamin Herrenschmidt wrote:
On Mon, 2014-04-21 at 10:25 +0800, Wei Yang wrote:
 When pcibios_remove_pci_devices() is removing pci devices, it will release
 pci device respectively. When the refcount of the device is 0, the pci_dev
 structure will be destroyed.
 
 On PowerNV platform, the pci_dev will not be destroyed since the refcount is
 not 0.
 
 After applying the patch, this warning is cleared during the EEH hotplug
 event.

You have to be careful here. We take a reference to the device in the
structure eeh_dev, that means we might access it after it's freed if
we don't increase the refcount.

Ben,

Thanks for reminding.

Hmm, I checked the eeh_dev structure, there is a field pdev in eeh_dev, which
is not a ref to the device.

Then I did a check in eeh hotplug code patch. The pci_dev remove/install
happens in eeh_reset_device(), between pcibios_remove_pci_devices() and
pcibios_add_pci_devices(). During this period, we will try to clear/set the PE
state and restore the BAR of a pci device. But the BAR is restored through the
device node instead of pci_dev structure. As my understanding the eeh code
here has the assumption that these pci devices in the same PE are removed.
Maybe I missed something, needs confirmation from Gavin.

The code I removed in this patch is introduced in commit
184cd4a3(powerpc/powernv: PCI support for p7IOC under OPAL v2).
Sounds the original purpose is to make sure a pci device is covered by a Bus
PE, so don't remove it. After booting up, Bus PE will always be there, which
means we will always hold a refcount to a pci device.

I didn't come up with a better idea, or leaving the warning is fine.

Any comments are welcome :)


Cheers,
Ben.


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

Re: [RFC PATCH 0/2] usb: Reuse fsl driver code for synopsys usb controller

2014-04-21 Thread punnaiah choudary kalluri 
On Mon, Apr 21, 2014 at 12:22 AM, Marc Kleine-Budde m...@pengutronix.de wrote:
 On 04/20/2014 06:27 PM, Punnaiah Choudary Kalluri wrote:
 Zynq soc contains a dual role usb controller and this IP is from synopsys. We
 observed that there is driver available for this controller from freescale 
 and
 decided to reuse this driver for zynq use.

 Have a look drivers/usb/chipidea. It's maintained by Peter Chen (Cc'ed)
 and is in better shape than the freescale driver.

Thanks. I will check this implementation and also check with Peter Chen if
i have any concerns about this implementation.

Punnaiah.

 Marc

 --
 Pengutronix e.K.  | Marc Kleine-Budde   |
 Industrial Linux Solutions| Phone: +49-231-2826-924 |
 Vertretung West/Dortmund  | Fax:   +49-5121-206917- |
 Amtsgericht Hildesheim, HRA 2686  | http://www.pengutronix.de   |

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

Re: [PATCH 2/2] powerpc/powernc: revert part of commit d905c5df(PPC: POWERNV: move iommu_add_device earlier)

2014-04-21 Thread Wei Yang 
On Mon, Apr 21, 2014 at 01:22:13PM +0800, Wei Yang wrote:
On Mon, Apr 21, 2014 at 01:37:32PM +1000, Benjamin Herrenschmidt wrote:
On Mon, 2014-04-21 at 10:25 +0800, Wei Yang wrote:
 Here is a draft call flow:
 
 pci_device_add
pcibios_add_device
   pci_dma_dev_setup
  pnv_pci_dma_dev_setup
 pnv_pci_ioda_dma_dev_setup
set_iommu_table_base_and_group --- here
 device_add
 
 When set_iommu_table_base_and_group() is invoked int
 pnv_pci_ioda_dma_dev_setup(), the dev-kobj-sd is not initialized. The
 dev-kobj-sd is initialized in device_add().
 
 After applying this patch, the error
 iommu_tce: 0003:05:00.0 has not been added, ret=-14
 is cleared.
 
 This patch revert the change for pnv_pci_ioda_dma_dev_setup() from commit
 d905c5df(PPC: POWERNV: move iommu_add_device earlier).

But in that case, is the group still set ?

I think so.

iommu_add_device() will be invoked when device_add() notify the pci bus.


Did a quick test, after applying this patch, the logic would be the same for
VF and PF hotplug, the iommu_group is created with corresponding device.

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

Re: [PATCH 3/3] cpufreq: ppc: Fix handling of non-existent clocks

2014-04-21 Thread Geert Uytterhoeven 
Hi Viresh,

On Mon, Apr 21, 2014 at 8:01 AM, Viresh Kumar viresh.ku...@linaro.org wrote:
 On 17 April 2014 15:23, Geert Uytterhoeven geert+rene...@glider.be wrote:
 If the clock doesn't exist, clk_get_rate() returns -EINVAL

 You clk_get_rate() isn't written well then, it should return zero.

You're right, thanks!
Once again I looked at the wrong clk_get_rate() implementation :-(
These non-CCF variants should die soon...

So the original code was correct: if the clock is not valid, freq == 0,
and thus freq  min_cpufreq is true.

 @Mike: I didn't see this clearly mentioned in clk.h, should we fix
 that?

, which becomes
 a large number (freq is u32), failing the freq  min_cpufreq test.
 Explicitly test for (u32)-EINVAL to fix this.

 That's a bad check. We should have done this instead:

 (s32)freq  0; but that would be true for high values of clock. And that's
 why clk_get_rate() must return zero for errors.

 Update the comment, and fix a grammer issue while we're at it.

 Signed-off-by: Geert Uytterhoeven geert+rene...@glider.be
 ---
  drivers/cpufreq/ppc-corenet-cpufreq.c |7 ---
  1 file changed, 4 insertions(+), 3 deletions(-)

 diff --git a/drivers/cpufreq/ppc-corenet-cpufreq.c 
 b/drivers/cpufreq/ppc-corenet-cpufreq.c
 index 53881d78a931..7027eab814ce 100644
 --- a/drivers/cpufreq/ppc-corenet-cpufreq.c
 +++ b/drivers/cpufreq/ppc-corenet-cpufreq.c
 @@ -179,10 +179,11 @@ static int corenet_cpufreq_cpu_init(struct 
 cpufreq_policy *policy)
 clk = of_clk_get(data-parent, i);
 freq = clk_get_rate(clk);
 /*
 -* the clock is valid if its frequency is not masked
 -* and large than minimum allowed frequency.
 +* the clock is valid if it exists, its frequency is not
 +* masked, and larger than minimum allowed frequency.
  */
 -   if (freq  min_cpufreq || (mask  (1  i)))
 +   if (freq == (u32)-EINVAL || freq  min_cpufreq ||
 +   (mask  (1  i)))
 table[i].frequency = CPUFREQ_ENTRY_INVALID;
 else
 table[i].frequency = freq / 1000;

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH] powerpc/mm: Fix tlbie to add AVAL fields for 64K pages

2014-04-21 Thread Aneesh Kumar K.V 
Benjamin Herrenschmidt b...@kernel.crashing.org writes:

 On Mon, 2014-04-21 at 10:37 +0530, Aneesh Kumar K.V wrote:
 The if condition check was based on a draft ISA doc. Remove the same.

 Is this a real bug ? Do we need to send that back to stable ?

We haven't found any issues without the patch. I found that by code
reading when implementing THP support for powerkvm guest.  Also that if 
condition
issue is only applicable for 64K base page size. ie, when base page size and
actual page size both are 64K. Now for 64K bits we have bits 58..61
already in AVA field of tlbie instruction. But ISA requires that we have
them also in AVAL field. Since they are duplicate bits may be we are
ok ?

-aneesh


 Ben.

 Signed-off-by: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com
 ---
  arch/powerpc/mm/hash_native_64.c | 38 --
  1 file changed, 16 insertions(+), 22 deletions(-)
 
 diff --git a/arch/powerpc/mm/hash_native_64.c 
 b/arch/powerpc/mm/hash_native_64.c
 index 3ea26c25590b..cf1d325eae8b 100644
 --- a/arch/powerpc/mm/hash_native_64.c
 +++ b/arch/powerpc/mm/hash_native_64.c
 @@ -82,17 +82,14 @@ static inline void __tlbie(unsigned long vpn, int psize, 
 int apsize, int ssize)
  va = ~((1ul  mmu_psize_defs[apsize].shift) - 1);
  va |= penc  12;
  va |= ssize  8;
 -/* Add AVAL part */
 -if (psize != apsize) {
 -/*
 - * MPSS, 64K base page size and 16MB parge page size
 - * We don't need all the bits, but rest of the bits
 - * must be ignored by the processor.
 - * vpn cover upto 65 bits of va. (0...65) and we need
 - * 58..64 bits of va.
 - */
 -va |= (vpn  0xfe);
 -}
 +/*
 + * AVAL bits:
 + * We don't need all the bits, but rest of the bits
 + * must be ignored by the processor.
 + * vpn cover upto 65 bits of va. (0...65) and we need
 + * 58..64 bits of va.
 + */
 +va |= (vpn  0xfe); /* AVAL */
  va |= 1; /* L */
  asm volatile(ASM_FTR_IFCLR(tlbie %0,1, PPC_TLBIE(%1,%0), %2)
   : : r (va), r(0), i (CPU_FTR_ARCH_206)
 @@ -133,17 +130,14 @@ static inline void __tlbiel(unsigned long vpn, int 
 psize, int apsize, int ssize)
  va = ~((1ul  mmu_psize_defs[apsize].shift) - 1);
  va |= penc  12;
  va |= ssize  8;
 -/* Add AVAL part */
 -if (psize != apsize) {
 -/*
 - * MPSS, 64K base page size and 16MB parge page size
 - * We don't need all the bits, but rest of the bits
 - * must be ignored by the processor.
 - * vpn cover upto 65 bits of va. (0...65) and we need
 - * 58..64 bits of va.
 - */
 -va |= (vpn  0xfe);
 -}
 +/*
 + * AVAL bits:
 + * We don't need all the bits, but rest of the bits
 + * must be ignored by the processor.
 + * vpn cover upto 65 bits of va. (0...65) and we need
 + * 58..64 bits of va.
 + */
 +va |= (vpn  0xfe);
  va |= 1; /* L */
  asm volatile(.long 0x7c000224 | (%0  11) | (1  21)
   : : r(va) : memory);

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

RE: [PATCH] mtd: m25p80: Modify the name of mtd_info

2014-04-21 Thread b48...@freescale.com 


 -Original Message-
 From: Brian Norris [mailto:computersforpe...@gmail.com]
 Sent: Wednesday, April 16, 2014 2:48 PM
 To: Hou Zhiqiang-B48286
 Cc: linux-...@lists.infradead.org; linuxppc-...@ozlabs.org; Wood Scott-
 B07421; Hu Mingkai-B21284; dw...@infradead.org
 Subject: Re: [PATCH] mtd: m25p80: Modify the name of mtd_info
 
 On Fri, Mar 21, 2014 at 07:16:18PM +0800, Hou Zhiqiang wrote:
  To specify spi flash layouts by mtdparts=... in cmdline, we must
  give mtd_info a fixed name,because the cmdlinepart's parser will match
  the name of mtd_info given in cmdline.
  Now, if use DT, the mtd_info's name will be spi-dev-name. It
  consists of spi_master-bus_num, and the spi_master-bus_num maybe
  dynamically fetched. So, in this case, replace the component bus_num
  with thei physical address of spi master.
 
  Signed-off-by: Hou Zhiqiang b48...@freescale.com
  ---
   drivers/mtd/devices/m25p80.c | 18 +++---
   1 file changed, 15 insertions(+), 3 deletions(-)
 
  diff --git a/drivers/mtd/devices/m25p80.c
  b/drivers/mtd/devices/m25p80.c index 7eda71d..64450a2 100644
  --- a/drivers/mtd/devices/m25p80.c
  +++ b/drivers/mtd/devices/m25p80.c
  @@ -30,6 +30,7 @@
   #include linux/mtd/cfi.h
   #include linux/mtd/mtd.h
   #include linux/mtd/partitions.h
  +#include linux/of_address.h
   #include linux/of_platform.h
 
   #include linux/spi/spi.h
  @@ -934,9 +935,11 @@ static int m25p_probe(struct spi_device *spi)
  struct flash_platform_data  *data;
  struct m25p *flash;
  struct flash_info   *info;
  -   unsignedi;
  +   unsignedi, ret;
  struct mtd_part_parser_data ppdata;
  struct device_node *np = spi-dev.of_node;
  +   struct resource res;
  +   struct device_node *mnp = spi-master-dev.of_node;
 
  /* Platform data helps sort out which chip type we have, as
   * well as how this board partitions it.  If we don't have @@
  -1009,8 +1012,17 @@ static int m25p_probe(struct spi_device *spi)
 
  if (data  data-name)
  flash-mtd.name = data-name;
  -   else
  -   flash-mtd.name = dev_name(spi-dev);
  +   else{
  +   ret = of_address_to_resource(mnp, 0, res);
 
 You're making a lot assumptions about the SPI master/device relationship
 -- that the master has a device-node; that the first resource of the
 master is its physical address (this is not guaranteed by DT semantics).
 Please do not do this.

Thank you for your tips, but I think it is right to get the physical address
of master using the API of_address_to_resource, because of_address_to_resource
just parse address-resource from device tree.

 
  +   if (ret) {
  +   dev_err(spi-dev, failed to get spi master
 resource\n);
  +   return ret;
 
 This is wrong. It breaks all !CONFIG_OF cases which didn't specify a name
 via platform data.
 

I will resend a patch to fix it.

  +   }
  +   flash-mtd.name = kasprintf(GFP_KERNEL, spi%x.%d,
  +   (unsigned)res.start, spi-chip_select);
  +   if (!flash-mtd.name)
  +   return -ENOMEM;
  +   }
 
  flash-mtd.type = MTD_NORFLASH;
  flash-mtd.writesize = 1;
 
 Brian
 

Thanks,
Zhiqiang

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

[PATCH V4] mtd: m25p80: Modify the name of mtd_info

2014-04-21 Thread Hou Zhiqiang 
To specify spi flash layouts by mtdparts=... in cmdline, we must
give mtd_info a fixed name,because the cmdlinepart's parser will
match the name of mtd_info given in cmdline.
Now, if use DT, the mtd_info's name will be spi-dev-name. It
consists of spi_master-bus_num, and the spi_master-bus_num maybe
dynamically fetched. So, in this case, replace the component bus_num
with thei physical address of spi master.

Signed-off-by: Hou Zhiqiang b48...@freescale.com
---
V4:
add check no-NULL for pointer of master's device node, and if it failed
to get physcial address of the master, then name the mtd_info by the
name of spi-dev.
V3:
Fix a bug, matching unsigned long long with %llx.
V2:
1. Fix some code style issue.
2. Cast physical address to unsigned long long.

 drivers/mtd/devices/m25p80.c | 16 ++--
 1 file changed, 14 insertions(+), 2 deletions(-)

diff --git a/drivers/mtd/devices/m25p80.c b/drivers/mtd/devices/m25p80.c
index 7eda71d..998b283 100644
--- a/drivers/mtd/devices/m25p80.c
+++ b/drivers/mtd/devices/m25p80.c
@@ -934,9 +934,11 @@ static int m25p_probe(struct spi_device *spi)
struct flash_platform_data  *data;
struct m25p *flash;
struct flash_info   *info;
-   unsignedi;
+   unsignedi, ret;
struct mtd_part_parser_data ppdata;
struct device_node *np = spi-dev.of_node;
+   struct resource res;
+   struct device_node *mnp = spi-master-dev.of_node;
 
/* Platform data helps sort out which chip type we have, as
 * well as how this board partitions it.  If we don't have
@@ -1009,7 +1011,17 @@ static int m25p_probe(struct spi_device *spi)
 
if (data  data-name)
flash-mtd.name = data-name;
-   else
+   else if (mnp) {
+   ret = of_address_to_resource(mnp, 0, res);
+   if (!ret) {
+   flash-mtd.name = kasprintf(GFP_KERNEL, spi%llx.%d,
+   (unsigned long long)res.start,
+   spi-chip_select);
+   if (!flash-mtd.name)
+   return -ENOMEM;
+   } else
+   dev_dbg(spi-dev, failed to get spi master 
resource\n);
+   } else
flash-mtd.name = dev_name(spi-dev);
 
flash-mtd.type = MTD_NORFLASH;
-- 
1.8.5

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

[PATCH][v10] powerpc/mpc85xx:Add initial device tree support of T104x

2014-04-21 Thread Prabhakar Kushwaha 
The QorIQ T1040/T1042 processor support four integrated 64-bit e5500 PA
processor cores with high-performance data path acceleration architecture
and network peripheral interfaces required for networking  telecommunications.

T1042 personality is a reduced personality of T1040 without Integrated 8-port
Gigabit Ethernet switch.

The T1040/T1042 SoC includes the following function and features:

 - Four e5500 cores, each with a private 256 KB L2 cache
 - 256 KB shared L3 CoreNet platform cache (CPC)
 - Interconnect CoreNet platform
 - 32-/64-bit DDR3L/DDR4 SDRAM memory controller with ECC and interleaving
   support
 - Data Path Acceleration Architecture (DPAA) incorporating acceleration
 for the following functions:
-  Packet parsing, classification, and distribution
-  Queue management for scheduling, packet sequencing, and congestion
management
-  Cryptography Acceleration (SEC 5.0)
- RegEx Pattern Matching Acceleration (PME 2.2)
- IEEE Std 1588 support
- Hardware buffer management for buffer allocation and deallocation
 - Ethernet interfaces
- Integrated 8-port Gigabit Ethernet switch (T1040 only)
- Four 1 Gbps Ethernet controllers
 - Two RGMII interfaces or one RGMII and one MII interfaces
 - High speed peripheral interfaces
   - Four PCI Express 2.0 controllers running at up to 5 GHz
   - Two SATA controllers supporting 1.5 and 3.0 Gb/s operation
   - Upto two QSGMII interface
   - Upto six SGMII interface supporting 1000 Mbps
   - One SGMII interface supporting upto 2500 Mbps
 - Additional peripheral interfaces
   - Two USB 2.0 controllers with integrated PHY
   - SD/eSDHC/eMMC
   -  eSPI controller
   - Four I2C controllers
   - Four UARTs
   - Four GPIO controllers
   - Integrated flash controller (IFC)
   - Change this to  LCD/ HDMI interface (DIU) with 12 bit dual data rate
   - TDM interface
 - Multicore programmable interrupt controller (PIC)
 - Two 8-channel DMA engines
 - Single source clocking implementation
 - Deep Sleep power implementaion (wakeup from GPIO/Timer/Ethernet/USB)

Signed-off-by: Poonam Aggrwal poonam.aggr...@freescale.com
Signed-off-by: Priyanka Jain priyanka.j...@freescale.com
Signed-off-by: Varun Sethi varun.se...@freescale.com
Signed-off-by: Prabhakar Kushwaha prabha...@freescale.com
---

Changes for v2: Incorporated Scott's comments
- Update t1040si-post.dtsi
- update clock device tree node as per
  http://patchwork.ozlabs.org/patch/274134/
- removed DMA node, It will be added later as per
  http://patchwork.ozlabs.org/patch/271238/
- Updated display compatible field
 
 Changes for v3: Incorporated Scott's comments
   - Updated soc compatible field
   - updated clock compatible field

 Changes for v4: Sending as it is 
 Changes for v5: Sending as it is 
 Changes for v6: Updated branch of creation 
 Changes for v7: Incororated Scott's commetns
- Create patch set
- remove whitespace
- Removed l2switch. It will be added later
 Changes for v8: Incorporated Scott's comments
- Added comment line in T1042si-post.dtsi
- removed extra lines
 Changes for v9:
- updated clock node as per new bindings
- removed extra line
- added dma node
 Changes for v10:
- update corenet compatible
- remove clock frequency from dts file
 - fix white space

 arch/powerpc/boot/dts/fsl/t1040si-post.dtsi |  430 +++
 arch/powerpc/boot/dts/fsl/t1042si-post.dtsi |   37 +++
 arch/powerpc/boot/dts/fsl/t104xsi-pre.dtsi  |  104 +++
 3 files changed, 571 insertions(+)
 create mode 100644 arch/powerpc/boot/dts/fsl/t1040si-post.dtsi
 create mode 100644 arch/powerpc/boot/dts/fsl/t1042si-post.dtsi
 create mode 100644 arch/powerpc/boot/dts/fsl/t104xsi-pre.dtsi

diff --git a/arch/powerpc/boot/dts/fsl/t1040si-post.dtsi 
b/arch/powerpc/boot/dts/fsl/t1040si-post.dtsi
new file mode 100644
index 000..2cae320
--- /dev/null
+++ b/arch/powerpc/boot/dts/fsl/t1040si-post.dtsi
@@ -0,0 +1,430 @@
+/*
+ * T1040 Silicon/SoC Device Tree Source (post include)
+ *
+ * Copyright 2013 Freescale Semiconductor Inc.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions are met:
+ * * Redistributions of source code must retain the above copyright
+ *  notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above copyright
+ *  notice, this list of conditions and the following disclaimer in the
+ *  documentation and/or other materials provided with the distribution.
+ * * Neither the name of Freescale Semiconductor nor the
+ *  names of its contributors may be used to endorse or promote products
+ *  derived from this software without specific prior written permission.
+ *
+ *
+ * ALTERNATIVELY, this software may be distributed under the terms of the
+ * GNU General Public License (GPL) as published by the Free

[PATCH][v10] powerpc/fsl-booke: Add initial T104x_QDS board support

2014-04-21 Thread Prabhakar Kushwaha 
 Add support for T104x board in board file t104x_qds.c, It is common for
 both T1040 and T1042 as they share same QDS board.

 T1040QDS board Overview
 ---
 - SERDES Connections, 8 lanes supporting:
  — PCI Express: supporting Gen 1 and Gen 2;
  — SGMII
  — QSGMII
  — SATA 2.0
  — Aurora debug with dedicated connectors (T1040 only)
 - DDR Controller
 - Supports rates of up to 1600 MHz data-rate
 - Supports one DDR3LP UDIMM/RDIMMs, of single-, dual- or quad-rank types.
 -IFC/Local Bus
 - NAND flash: 8-bit, async, up to 2GB.
 - NOR: 8-bit or 16-bit, non-multiplexed, up to 512MB
 - GASIC: Simple (minimal) target within Qixis FPGA
 - PromJET rapid memory download support
 - Ethernet
 - Two on-board RGMII 10/100/1G ethernet ports.
 - PHY #0 remains powered up during deep-sleep (T1040 only)
 - QIXIS System Logic FPGA
 - Clocks
 - System and DDR clock (SYSCLK, “DDRCLK”)
 - SERDES clocks
 - Power Supplies
 - Video
 - DIU supports video at up to 1280x1024x32bpp
 - USB
 - Supports two USB 2.0 ports with integrated PHYs
 — Two type A ports with 5V@1.5A per port.
 — Second port can be converted to OTG mini-AB
 - SDHC
 - SDHC port connects directly to an adapter card slot, featuring:
 - Supporting SD slots for: SD, SDHC (1x, 4x, 8x) and/or MMC
 — Supporting eMMC memory devices
 - SPI
-  On-board support of 3 different devices and sizes
 - Other IO
- Two Serial ports
- ProfiBus port
- Four I2C ports

Add T104xQDS support in Kconfig and Makefile. Also create device tree.
Following features are currently not implmented.
  - SerDes: Aurora
  - IFC: GASIC, Promjet
  - QIXIS
  - Ethernet
  - DIU
  - power supplies management
  - ProfiBus

Signed-off-by: Priyanka Jain priyanka.j...@freescale.com
Signed-off-by: Poonam Aggrwal poonam.aggr...@freescale.com
Signed-off-by: Prabhakar Kushwaha prabha...@freescale.com
---

 Changes for v2: Incorporated Scott's comments
- Created t104xqds.dtsi, both t1040qds  t1042qds include it
- Updated get_irq 
 Changes for v3: Sending as it is
 Changes for v4: Updated description
 Changes for v5: Incorporated Scott's comments
- Ported on top of Kevin's patch
 Changes for v6: Updated depedencies
 Changes for v7: Incororated Scott's commetns
- Create patch set
 Changes for v8: Sending as it is
 Changes for v9:
- removed partitions
- updated FPGA node
- Fix PCIe range fields
 Changes for v10:
- Updated SPI flash compatible

 arch/powerpc/boot/dts/t1040qds.dts|   46 +++
 arch/powerpc/boot/dts/t1042qds.dts|   46 +++
 arch/powerpc/boot/dts/t104xqds.dtsi   |  166 +
 arch/powerpc/platforms/85xx/Kconfig   |2 +-
 arch/powerpc/platforms/85xx/corenet_generic.c |4 +
 5 files changed, 263 insertions(+), 1 deletion(-)
 create mode 100644 arch/powerpc/boot/dts/t1040qds.dts
 create mode 100644 arch/powerpc/boot/dts/t1042qds.dts
 create mode 100644 arch/powerpc/boot/dts/t104xqds.dtsi

diff --git a/arch/powerpc/boot/dts/t1040qds.dts 
b/arch/powerpc/boot/dts/t1040qds.dts
new file mode 100644
index 000..973c29c
--- /dev/null
+++ b/arch/powerpc/boot/dts/t1040qds.dts
@@ -0,0 +1,46 @@
+/*
+ * T1040QDS Device Tree Source
+ *
+ * Copyright 2013 Freescale Semiconductor Inc.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions are met:
+ * * Redistributions of source code must retain the above copyright
+ *  notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above copyright
+ *  notice, this list of conditions and the following disclaimer in the
+ *  documentation and/or other materials provided with the distribution.
+ * * Neither the name of Freescale Semiconductor nor the
+ *  names of its contributors may be used to endorse or promote products
+ *  derived from this software without specific prior written permission.
+ *
+ *
+ * ALTERNATIVELY, this software may be distributed under the terms of the
+ * GNU General Public License (GPL) as published by the Free Software
+ * Foundation, either version 2 of that License or (at your option) any
+ * later version.
+ *
+ * THIS SOFTWARE IS PROVIDED BY Freescale Semiconductor AS IS AND ANY
+ * EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
+ * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
+ * DISCLAIMED. IN NO EVENT SHALL Freescale Semiconductor BE LIABLE FOR ANY
+ * DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
+ * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
+ * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
+ * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING

Re: [PATCH 3/3] of: Handle memory@0 node on PPC32 only

2014-04-21 Thread Rob Herring 
On Fri, Apr 18, 2014 at 7:59 AM, Leif Lindholm leif.lindh...@linaro.org wrote:
 Hi Geert,

 On Fri, Apr 18, 2014 at 10:04:15AM +0200, Geert Uytterhoeven wrote:
 On Thu, Apr 17, 2014 at 7:42 PM, Leif Lindholm leif.lindh...@linaro.org 
 wrote:
  In order to deal with an firmware bug on a specific ppc32 platform
  (longtrail), early_init_dt_scan_memory() looks for a node called
  memory@0 on all platforms. Restrict this quirk to ppc32 kernels only.

 This breaks backwards compatibilty with old DTSes (at least on ARM/MIPS,
 where you added the missing property in patches 1 and 2 of the series)?

 As Rob said in response to 0/3, the MIPSs would likely not be affected,
 since they embed the DT.

 For the Longtrail, I don't care much anymore, as mine died in 2004.
 AFAIK, there have never been many users anyway.

 There are still a few mentions of it under arch/powerpc/, so I wouldn't
 want to be the one to kill it off...

 How about the below v2 3/3 to address the ARM platform?

 Regards,

 Leif

 From 6fa0b837ad71780334eb97d63c507165b6c57add Mon Sep 17 00:00:00 2001
 From: Leif Lindholm leif.lindh...@linaro.org
 Date: Thu, 17 Apr 2014 14:24:47 +0100
 Subject: [PATCH] of: arm: powerpc: Restrict memory@0 node handling to
  affected platforms

 In order to deal with a firmware bug on a specific ppc32 platform
 (longtrail), early_init_dt_scan_memory() looks for a node called
 memory@0 on all platforms, for all nodes lacking a device_type.
 Restrict this quirk to ppc32 and the arm mach-ux500 platforms (one of
 which has depended on this special handling).


 diff --git a/drivers/of/Kconfig b/drivers/of/Kconfig
 index 889005f..230c747 100644
 --- a/drivers/of/Kconfig
 +++ b/drivers/of/Kconfig
 @@ -77,4 +77,7 @@ config OF_RESERVED_MEM
 help
   Helpers to allow for reservation of memory regions

 +config OF_MEMORY_AT_0_QUIRK
 +   def_bool n

I do not like this because it would not scale to many quirks. As I
said,, my preference here would be to just add a WARN.

The other option is get approval to break compatibility on the ST
platform. It may not be a concern on certain platforms.

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

Re: [PATCH 4/6] powerpc/corenet: Create the dts components for the DPAA FMan

2014-04-21 Thread Scott Wood 
On Fri, 2014-04-18 at 07:21 -0500, Shruti Kanetkar wrote:
 +fman@40 {
 + mdio@f1000 {
 + #address-cells = 1;
 + #size-cells = 0;
 + compatible = fsl,fman-xmdio;
 + reg = 0xf1000 0x1000;
 + };
 +};

I'd like to see a complete fman binding before we start adding pieces.

 +fman@40 {
 + mdio0: mdio@e1120 {
 + #address-cells = 1;
 + #size-cells = 0;
 + compatible = fsl,fman-mdio;
 + reg = 0xe1120 0xee0;
 + };
 +};

What is the difference between fsl,fman-mdio and fsl,fman-xmdio?  I
don't see the latter on the list of compatibles in patch 3/6.

Within each category, is the exact fman version discoverable from the
mdio registers?

 diff --git a/arch/powerpc/boot/dts/fsl/qoriq-fman3-1.dtsi 
 b/arch/powerpc/boot/dts/fsl/qoriq-fman3-1.dtsi
 new file mode 100644
 index 000..ced5786
 --- /dev/null
 +++ b/arch/powerpc/boot/dts/fsl/qoriq-fman3-1.dtsi
 @@ -0,0 +1,52 @@
 +/*
 + * QorIQ FMan v3 device tree stub [ controller @ offset 0x50 ]
 + *
 + * Copyright 2012 Freescale Semiconductor Inc.
 + *
 + * Redistribution and use in source and binary forms, with or without
 + * modification, are permitted provided that the following conditions are 
 met:
 + * * Redistributions of source code must retain the above copyright
 + *   notice, this list of conditions and the following disclaimer.
 + * * Redistributions in binary form must reproduce the above copyright
 + *   notice, this list of conditions and the following disclaimer in the
 + *   documentation and/or other materials provided with the distribution.
 + * * Neither the name of Freescale Semiconductor nor the
 + *   names of its contributors may be used to endorse or promote products
 + *   derived from this software without specific prior written 
 permission.
 + *
 + *
 + * ALTERNATIVELY, this software may be distributed under the terms of the
 + * GNU General Public License (GPL) as published by the Free Software
 + * Foundation, either version 2 of that License or (at your option) any
 + * later version.
 + *
 + * THIS SOFTWARE IS PROVIDED BY Freescale Semiconductor ``AS IS'' AND ANY
 + * EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
 + * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
 + * DISCLAIMED. IN NO EVENT SHALL Freescale Semiconductor BE LIABLE FOR ANY
 + * DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
 + * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR 
 SERVICES;
 + * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED 
 AND
 + * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
 + * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF 
 THIS
 + * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
 +*/
 +
 +fman@50 {
 + #address-cells = 1;
 + #size-cells = 1;
 + compatible = simple-bus;

Why is this simple-bus?

 +
 + /* mdio nodes for fman v3 @ 0x50 */
 + mdio@fc000 {
 + #address-cells = 1;
 + #size-cells = 0;
 + reg = 0xfc000 0x1000;
 + };
 +
 + mdio@fd000 {
 + #address-cells = 1;
 + #size-cells = 0;
 + reg = 0xfd000 0x1000;
 + };
 +};

Where's the compatible?  Why is this file different from all the others?

-Scott


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

Re: [PATCH 5/6] powerpc/corenet: Add DPAA FMan support to the SoC device tree(s)

2014-04-21 Thread Scott Wood 
On Fri, 2014-04-18 at 07:21 -0500, Shruti Kanetkar wrote:
 FMan 1 Gb/s MACs (dTSEC and mEMAC) have support for SGMII PHYs.
 Add support for the internal SerDes TBI PHYs
 
 Based on prior work by Andy Fleming aflem...@gmail.com
 
 Signed-off-by: Shruti Kanetkar shr...@freescale.com
 ---
  arch/powerpc/boot/dts/fsl/b4860si-post.dtsi |  28 +
  arch/powerpc/boot/dts/fsl/b4si-post.dtsi|  51 +
  arch/powerpc/boot/dts/fsl/p1023si-post.dtsi |  14 +++
  arch/powerpc/boot/dts/fsl/p2041si-post.dtsi |  64 
  arch/powerpc/boot/dts/fsl/p3041si-post.dtsi |  64 
  arch/powerpc/boot/dts/fsl/p4080si-post.dtsi | 104 +++
  arch/powerpc/boot/dts/fsl/p5020si-post.dtsi |  64 
  arch/powerpc/boot/dts/fsl/p5040si-post.dtsi | 128 +++
  arch/powerpc/boot/dts/fsl/t4240si-post.dtsi | 154 
 
  9 files changed, 671 insertions(+)
 
 diff --git a/arch/powerpc/boot/dts/fsl/b4860si-post.dtsi 
 b/arch/powerpc/boot/dts/fsl/b4860si-post.dtsi
 index cbc354b..45b0ff5 100644
 --- a/arch/powerpc/boot/dts/fsl/b4860si-post.dtsi
 +++ b/arch/powerpc/boot/dts/fsl/b4860si-post.dtsi
 @@ -172,6 +172,34 @@
   compatible = fsl,b4860-rcpm, fsl,qoriq-rcpm-2.0;
   };
  
 +/include/ qoriq-fman3-0-1g-4.dtsi
 +/include/ qoriq-fman3-0-1g-5.dtsi
 +/include/ qoriq-fman3-0-10g-0.dtsi
 +/include/ qoriq-fman3-0-10g-1.dtsi
 + fman@40 {
 + ethernet@e8000 {
 + tbi-handle = tbi4;
 + };

Binding needed

Where is the reg for these unit addresses?

 + mdio@e9000 {
 + tbi4: tbi-phy@8 {
 + reg = 0x8;
 + device_type = tbi-phy;
 + };
 + };

Binding needed for tbi-phy device_type.  Why are we using device_type at
all for this?

-Scott


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

Re: [PATCH 0/5] defconfigs: add MTD_SPI_NOR (dependency for M25P80)

2014-04-21 Thread Marek Vasut 
On Friday, April 18, 2014 at 08:30:54 AM, Brian Norris wrote:
 Hi,
 
 On Thu, Apr 17, 2014 at 12:53:03PM +0200, Thierry Reding wrote:
  On Thu, Apr 17, 2014 at 12:21:44AM -0700, Brian Norris wrote:
   We are introducing a new SPI-NOR library/framework for MTD, to support
   various types of SPI-NOR flash controllers which require (or benefit
   from) intimate knowledge of the flash interface, rather than just the
   relatively dumb SPI interface. This library borrows much of the m25p80
   driver for its abstraction and moves this code into a spi-nor module.
  
  If this is a common library, then the more common approach to solve this
  would be to have each driver that uses it to select MTD_SPI_NOR rather
  than depend on it. That way you can drop this whole series to update the
  default configurations.
 
 But does MTD_SPI_NOR (and drivers/mtd/spi-nor/) qualify as a library
 or as a subsystem? I thought the latter were typically expected to be
 user-selectable options, not automatically-selected.

I agree the subsystem is user-selectable while the library is to be 
'select'ed .

 I would say that, except for its age, MTD_SPI_NOR is very similar in to
 MTD_NAND (driver/mtd/nand/), which I'd consider a kind of subsystem, and
 which users must select before they are asked about drivers which fall
 under its category.
 
 Perhaps my usage of the word library in the description was a mistake,
 as I don't exactly consider it like a library in the sense of many other
 selected libraries.

It did look like a library to me at first, but it's rather a subsystem that 
contains a small library in it. Thus, I retract my previous comment about using 
'select' and add :

Acked-by: Marek Vasut ma...@denx.de

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

[PATCH v4 2/8] cpufreq: Use cpufreq_for_each_* macros for frequency table iteration

2014-04-21 Thread Stratos Karafotis 
The cpufreq core now supports the cpufreq_for_each_entry and
cpufreq_for_each_valid_entry macros helpers for iteration over the
cpufreq_frequency_table, so use them.

It should have no functional changes.

Signed-off-by: Stratos Karafotis strat...@semaphore.gr
---
 drivers/cpufreq/acpi-cpufreq.c   |  9 +++---
 drivers/cpufreq/arm_big_little.c | 16 +--
 drivers/cpufreq/cpufreq_stats.c  | 24 ++--
 drivers/cpufreq/dbx500-cpufreq.c |  8 ++
 drivers/cpufreq/elanfreq.c   |  9 +++---
 drivers/cpufreq/exynos-cpufreq.c | 11 ---
 drivers/cpufreq/exynos5440-cpufreq.c | 30 +--
 drivers/cpufreq/freq_table.c | 56 
 drivers/cpufreq/longhaul.c   | 13 -
 drivers/cpufreq/pasemi-cpufreq.c | 10 +++
 drivers/cpufreq/powernow-k6.c| 14 -
 drivers/cpufreq/ppc_cbe_cpufreq.c|  9 +++---
 drivers/cpufreq/s3c2416-cpufreq.c| 40 +++---
 drivers/cpufreq/s3c64xx-cpufreq.c| 15 --
 14 files changed, 117 insertions(+), 147 deletions(-)

diff --git a/drivers/cpufreq/acpi-cpufreq.c b/drivers/cpufreq/acpi-cpufreq.c
index 000e4e0..b0c18ed 100644
--- a/drivers/cpufreq/acpi-cpufreq.c
+++ b/drivers/cpufreq/acpi-cpufreq.c
@@ -213,7 +213,7 @@ static unsigned extract_io(u32 value, struct 
acpi_cpufreq_data *data)
 
 static unsigned extract_msr(u32 msr, struct acpi_cpufreq_data *data)
 {
-   int i;
+   struct cpufreq_frequency_table *pos;
struct acpi_processor_performance *perf;
 
if (boot_cpu_data.x86_vendor == X86_VENDOR_AMD)
@@ -223,10 +223,9 @@ static unsigned extract_msr(u32 msr, struct 
acpi_cpufreq_data *data)
 
perf = data-acpi_data;
 
-   for (i = 0; data-freq_table[i].frequency != CPUFREQ_TABLE_END; i++) {
-   if (msr == perf-states[data-freq_table[i].driver_data].status)
-   return data-freq_table[i].frequency;
-   }
+   cpufreq_for_each_entry(pos, data-freq_table)
+   if (msr == perf-states[pos-driver_data].status)
+   return pos-frequency;
return data-freq_table[0].frequency;
 }
 
diff --git a/drivers/cpufreq/arm_big_little.c b/drivers/cpufreq/arm_big_little.c
index bad2ed3..1f4d4e3 100644
--- a/drivers/cpufreq/arm_big_little.c
+++ b/drivers/cpufreq/arm_big_little.c
@@ -226,22 +226,22 @@ static inline u32 get_table_count(struct 
cpufreq_frequency_table *table)
 /* get the minimum frequency in the cpufreq_frequency_table */
 static inline u32 get_table_min(struct cpufreq_frequency_table *table)
 {
-   int i;
+   struct cpufreq_frequency_table *pos;
uint32_t min_freq = ~0;
-   for (i = 0; (table[i].frequency != CPUFREQ_TABLE_END); i++)
-   if (table[i].frequency  min_freq)
-   min_freq = table[i].frequency;
+   cpufreq_for_each_entry(pos, table)
+   if (pos-frequency  min_freq)
+   min_freq = pos-frequency;
return min_freq;
 }
 
 /* get the maximum frequency in the cpufreq_frequency_table */
 static inline u32 get_table_max(struct cpufreq_frequency_table *table)
 {
-   int i;
+   struct cpufreq_frequency_table *pos;
uint32_t max_freq = 0;
-   for (i = 0; (table[i].frequency != CPUFREQ_TABLE_END); i++)
-   if (table[i].frequency  max_freq)
-   max_freq = table[i].frequency;
+   cpufreq_for_each_entry(pos, table)
+   if (pos-frequency  max_freq)
+   max_freq = pos-frequency;
return max_freq;
 }
 
diff --git a/drivers/cpufreq/cpufreq_stats.c b/drivers/cpufreq/cpufreq_stats.c
index ecaaebf..0cd9b4d 100644
--- a/drivers/cpufreq/cpufreq_stats.c
+++ b/drivers/cpufreq/cpufreq_stats.c
@@ -182,11 +182,11 @@ static void cpufreq_stats_free_table(unsigned int cpu)
 
 static int __cpufreq_stats_create_table(struct cpufreq_policy *policy)
 {
-   unsigned int i, j, count = 0, ret = 0;
+   unsigned int i, count = 0, ret = 0;
struct cpufreq_stats *stat;
unsigned int alloc_size;
unsigned int cpu = policy-cpu;
-   struct cpufreq_frequency_table *table;
+   struct cpufreq_frequency_table *pos, *table;
 
table = cpufreq_frequency_get_table(cpu);
if (unlikely(!table))
@@ -205,12 +205,8 @@ static int __cpufreq_stats_create_table(struct 
cpufreq_policy *policy)
stat-cpu = cpu;
per_cpu(cpufreq_stats_table, cpu) = stat;
 
-   for (i = 0; table[i].frequency != CPUFREQ_TABLE_END; i++) {
-   unsigned int freq = table[i].frequency;
-   if (freq == CPUFREQ_ENTRY_INVALID)
-   continue;
+   cpufreq_for_each_valid_entry(pos, table)
count++;
-   }
 
alloc_size = count * sizeof(int) + count * sizeof(u64);
 
@@ -228,15 +224,11 @@ static int __cpufreq_stats_create_table(struct 
cpufreq_policy *policy)
 #ifdef

Re: [PATCH 1/2] powerpc/powernv: clear the refcount for pci_dev on powernv platform

2014-04-21 Thread Gavin Shan 
On Mon, Apr 21, 2014 at 10:25:18AM +0800, Wei Yang wrote:
When pcibios_remove_pci_devices() is removing pci devices, it will release
pci device respectively. When the refcount of the device is 0, the pci_dev
structure will be destroyed.

On PowerNV platform, the pci_dev will not be destroyed since the refcount is
not 0.


Richard, the above description is true. However, it's not relevant to the
issue (backtrace). I don't quite understand the scenario you had. You're
doing hotplug on VFs or PF? I guess it would be full-hotplug instead of
partial hotplug.

It seems that the IOMMU group wasn't detached correctly and then we tried
to attach it again. Or the IOMMU group was attached for towice? :-)

The IOMMU group is expected to be detached like this, please investigate
for more why it wasn't detached correctly.

pcibios_remove_pci_devices()
pci_stop_and_remove_bus_device()
pci_remove_bus_device()
pci_destroy_dev()

static void pci_destroy_dev(struct pci_dev *dev)
{
if (!dev-dev.kobj.parent)
return;

device_del(dev-dev);  /* It's calling iommu_del_device() 
*/

down_write(pci_bus_sem);
list_del(dev-bus_list);
up_write(pci_bus_sem);

pci_free_resources(dev);
put_device(dev-dev);  /* It's calling 
pcibios_release_device() */
}

Thanks,
Gavin

After applying the patch, this warning is cleared during the EEH hotplug
event.

[  204.123609] [ cut here ]
[  204.123645] WARNING: at arch/powerpc/kernel/iommu.c:1125
[  204.123680] Modules linked in: xt_CHECKSUM nf_conntrack_netbios_ns 
nf_conntrack_broadcast ipt_MASQUERADE ip6t_REJECT bnep bluetooth 6lowpan_iphc 
rfkill xt_conntrack ebtable_nat ebtable_broute bridge stp llc mlx4_ib ib_sa 
ib_mad ib_core ib_addr ebtable_filter ebtables ip6table_nat nf_conntrack_ipv6 
nf_defrag_ipv6 nf_nat_ipv6 ip6table_mangle ip6table_security ip6table_raw 
ip6table_filter ip6_tables iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 
nf_nat_ipv4 nf_nat nf_conntrack iptable_mangle iptable_security iptable_raw 
bnx2x tg3 mlx4_core nfsd ptp mdio ses libcrc32c nfs_acl enclosure be2net 
pps_core shpchp lockd kvm uinput sunrpc binfmt_misc lpfc scsi_transport_fc ipr 
scsi_tgt
[  204.124356] CPU: 18 PID: 650 Comm: eehd Not tainted 3.14.0-rc5yw+ #102
[  204.124400] task: c027ed485670 ti: c027ed50c000 task.ti: 
c027ed50c000
[  204.124453] NIP: c003cf80 LR: c006c648 CTR: c006c5c0
[  204.124506] REGS: c027ed50f440 TRAP: 0700   Not tainted  (3.14.0-rc5yw+)
[  204.124558] MSR: 90029032 SF,HV,EE,ME,IR,DR,RI  CR: 88008084  
XER: 2000
[  204.124682] CFAR: c006c644 SOFTE: 1
GPR00: c006c648 c027ed50f6c0 c1398380 c027ec260300
GPR04: c027ea92c000 c006ad00 c16e41b0 0110
GPR08: c12cd4c0 0001 c027ec2602ff 0062
GPR12: 28008084 cfdca200 c00d1d90 c027ec281a80
GPR16:    
GPR20:    0001
GPR24: 5342697b 2906 c01fe6ac9800 c01fe6ac9800
GPR28:  c16e3a80 c027ea92c090 c027ea92c000
[  204.125353] NIP [c003cf80] .iommu_add_device+0x30/0x1f0
[  204.125399] LR [c006c648] .pnv_pci_ioda_dma_dev_setup+0x88/0xb0
[  204.125443] Call Trace:
[  204.125464] [c027ed50f6c0] [c027ed50f750] 0xc027ed50f750 
(unreliable)
[  204.125526] [c027ed50f750] [c006c648] 
.pnv_pci_ioda_dma_dev_setup+0x88/0xb0
[  204.125588] [c027ed50f7d0] [c0069cc8] 
.pnv_pci_dma_dev_setup+0x78/0x340
[  204.125650] [c027ed50f870] [c0044408] 
.pcibios_setup_device+0x88/0x2f0
[  204.125712] [c027ed50f940] [c0046040] 
.pcibios_setup_bus_devices+0x60/0xd0
[  204.125774] [c027ed50f9c0] [c0043acc] 
.pcibios_add_pci_devices+0xdc/0x1c0
[  204.125837] [c027ed50fa50] [c086f970] 
.eeh_reset_device+0x36c/0x4f0
[  204.125939] [c027ed50fb20] [c003a2d8] 
.eeh_handle_normal_event+0x448/0x480
[  204.126068] [c027ed50fbc0] [c003a35c] 
.eeh_handle_event+0x4c/0x340
[  204.126192] [c027ed50fc80] [c003a74c] 
.eeh_event_handler+0xfc/0x1b0
[  204.126319] [c027ed50fd30] [c00d1ea0] .kthread+0x110/0x130
[  204.126430] [c027ed50fe30] [c000a460] 
.ret_from_kernel_thread+0x5c/0x7c
[  204.126556] Instruction dump:
[  204.126610] 7c0802a6 fba1ffe8 fbc1fff0 fbe1fff8 f8010010 f821ff71 7c7e1b78 
6000
[  204.126787] 6000 e87e0298 3143 7d2a1910 0b09 2fa9 
40de00c8 ebfe0218
[  204.126966] ---[ end trace 6e7aefd80add2973 ]---

This patch clear the step to get reference.

Signed-off-by: Wei Yang weiy...@linux.vnet.ibm.com
---
 arch/powerpc/platforms/powernv/pci-ioda.c |1 -
 1 file changed, 1 deletion(-)

diff --git

Re: [RFC PATCH 0/2] usb: Reuse fsl driver code for synopsys usb controller

2014-04-21 Thread Felipe Balbi 
On Sun, Apr 20, 2014 at 09:57:03PM +0530, Punnaiah Choudary Kalluri wrote:
 Zynq soc contains a dual role usb controller and this IP is from synopsys. We
 observed that there is driver available for this controller from freescale and
 decided to reuse this driver for zynq use.
 
 Here is the link for zynq soc TRM. Please refer chapter 15 for usb controller
 related information.
 http://www.xilinx.com/support/documentation/user_guides/ug585-Zynq-7000-TRM.pdf
 
 The following series of patches add initial support for zynq soc in fsl 
 gadget controller
 driver and fsl host controller driver.
 
 Based on these patches, I have the following concerns and sugesstions
 
 Since the freescale usb driver is for synopsys IP, Please consider rebranding
 this driver name and config options to reflect that it is a sysnopsys IP. So
 that other vendors who using this IP can reuse thie driver.
 
 Also the ehci-fsl.c is for powerpc based soc's, and zynq is ARM based, i have
 protected the code which is specifc to freescale with CONFIG_FSL_SOC. Please
 suggest if there is a better way of doing this?
 
 Punnaiah Choudary Kalluri (2):
   usb: gadget: fsl_udc: Add support for zynq usb device controller
   usb: ehci-fsl: Add support for zynq usb host controller
 
  drivers/usb/gadget/Kconfig|2 +-
  drivers/usb/gadget/Makefile   |1 +
  drivers/usb/gadget/fsl_mxc_udc.c  |   21 
  drivers/usb/gadget/fsl_udc_core.c |5 +++
  drivers/usb/gadget/fsl_usb2_udc.h |2 +-
  drivers/usb/host/Kconfig  |2 +-
  drivers/usb/host/ehci-fsl.c   |   63 
 -
  drivers/usb/host/fsl-mph-dr-of.c  |9 +
  8 files changed, 101 insertions(+), 4 deletions(-)

as somebody else already mentioned, chipidea is the way to go.


-- 
balbi


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

Re: [PATCH 3/4] ARCH: AUDIT: implement syscall_get_arch for all arches

2014-04-21 Thread Stephen Rothwell 
Hi Eric,

[I just noticed that this turned up in linux-next ...]

On Wed, 19 Mar 2014 18:04:02 -0400 Eric Paris epa...@redhat.com wrote:

 diff --git a/arch/powerpc/include/asm/syscall.h 
 b/arch/powerpc/include/asm/syscall.h
 index b54b2ad..4271544 100644
 --- a/arch/powerpc/include/asm/syscall.h
 +++ b/arch/powerpc/include/asm/syscall.h
 @@ -13,6 +13,8 @@
  #ifndef _ASM_SYSCALL_H
  #define _ASM_SYSCALL_H   1
  
 +#include uapi/linux/audit.h
 +#include linux/compat.h

You don't need linux/compat.h, I think, but you do need to include
linux/thread_info.h for is_32bit_task() below.

  #include linux/sched.h
  
  /* ftrace syscalls requires exporting the sys_call_table */
 @@ -86,4 +88,14 @@ static inline void syscall_set_arguments(struct 
 task_struct *task,
   memcpy(regs-gpr[3 + i], args, n * sizeof(args[0]));
  }
  
 +static inline int syscall_get_arch(void)
 +{
 + int arch = AUDIT_ARCH_PPC;
 +
 +#ifdef CONFIG_PPC64
 + if (!is_32bit_task())
 + arch = AUDIT_ARCH_PPC64;
 +#endif
 + return arch;

This could just be

return is_32bit_task() ? AUDIT_ARCH_PPC : AUDIT_ARCH_PPC64;

as is_32bit_task() is always defined (and is (1) for !CONFIG_PPC64).

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


pgpUi3J0iXeoX.pgp
Description: PGP signature
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH V4] mtd: m25p80: Modify the name of mtd_info

2014-04-21 Thread Huang Shijie 
On Mon, Apr 21, 2014 at 07:06:21PM +0800, Hou Zhiqiang wrote:
 To specify spi flash layouts by mtdparts=... in cmdline, we must
 give mtd_info a fixed name,because the cmdlinepart's parser will
 match the name of mtd_info given in cmdline.
 Now, if use DT, the mtd_info's name will be spi-dev-name. It
 consists of spi_master-bus_num, and the spi_master-bus_num maybe
 dynamically fetched. So, in this case, replace the component bus_num
 with thei physical address of spi master.
 
 Signed-off-by: Hou Zhiqiang b48...@freescale.com
 ---
 V4:
   add check no-NULL for pointer of master's device node, and if it failed
   to get physcial address of the master, then name the mtd_info by the
   name of spi-dev.
 V3:
   Fix a bug, matching unsigned long long with %llx.
 V2:
   1. Fix some code style issue.
   2. Cast physical address to unsigned long long.
 
  drivers/mtd/devices/m25p80.c | 16 ++--
please rebase this patch on the latest l2-mtd tree.

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

[PATCH 1/6] powerpc/powernv: Use uint64_t instead of size_t in OPAL APIs

2014-04-21 Thread Anton Blanchard 
Using size_t in our APIs is asking for trouble, especially
when some OPAL calls use size_t pointers.

Signed-off-by: Anton Blanchard an...@samba.org
Reviewed-by: Stewart Smith stew...@linux.vnet.ibm.com
---
 arch/powerpc/include/asm/opal.h| 12 ++--
 arch/powerpc/platforms/powernv/opal-elog.c |  2 +-
 2 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/arch/powerpc/include/asm/opal.h b/arch/powerpc/include/asm/opal.h
index a2efdaa..2a34485 100644
--- a/arch/powerpc/include/asm/opal.h
+++ b/arch/powerpc/include/asm/opal.h
@@ -858,8 +858,8 @@ int64_t opal_lpc_write(uint32_t chip_id, enum 
OpalLPCAddressType addr_type,
 int64_t opal_lpc_read(uint32_t chip_id, enum OpalLPCAddressType addr_type,
  uint32_t addr, __be32 *data, uint32_t sz);
 
-int64_t opal_read_elog(uint64_t buffer, size_t size, uint64_t log_id);
-int64_t opal_get_elog_size(uint64_t *log_id, size_t *size, uint64_t 
*elog_type);
+int64_t opal_read_elog(uint64_t buffer, uint64_t size, uint64_t log_id);
+int64_t opal_get_elog_size(uint64_t *log_id, uint64_t *size, uint64_t 
*elog_type);
 int64_t opal_write_elog(uint64_t buffer, uint64_t size, uint64_t offset);
 int64_t opal_send_ack_elog(uint64_t log_id);
 void opal_resend_pending_logs(void);
@@ -874,13 +874,13 @@ int64_t opal_dump_read(uint32_t dump_id, uint64_t buffer);
 int64_t opal_dump_ack(uint32_t dump_id);
 int64_t opal_dump_resend_notification(void);
 
-int64_t opal_get_msg(uint64_t buffer, size_t size);
-int64_t opal_check_completion(uint64_t buffer, size_t size, uint64_t token);
+int64_t opal_get_msg(uint64_t buffer, uint64_t size);
+int64_t opal_check_completion(uint64_t buffer, uint64_t size, uint64_t token);
 int64_t opal_sync_host_reboot(void);
 int64_t opal_get_param(uint64_t token, uint32_t param_id, uint64_t buffer,
-   size_t length);
+   uint64_t length);
 int64_t opal_set_param(uint64_t token, uint32_t param_id, uint64_t buffer,
-   size_t length);
+   uint64_t length);
 int64_t opal_sensor_read(uint32_t sensor_hndl, int token, __be32 *sensor_data);
 
 /* Internal functions */
diff --git a/arch/powerpc/platforms/powernv/opal-elog.c 
b/arch/powerpc/platforms/powernv/opal-elog.c
index ef7bc2a..7e3821e 100644
--- a/arch/powerpc/platforms/powernv/opal-elog.c
+++ b/arch/powerpc/platforms/powernv/opal-elog.c
@@ -238,7 +238,7 @@ static struct elog_obj *create_elog_obj(uint64_t id, size_t 
size, uint64_t type)
 
 static void elog_work_fn(struct work_struct *work)
 {
-   size_t elog_size;
+   uint64_t elog_size;
uint64_t log_id;
uint64_t elog_type;
int rc;
-- 
1.8.3.2

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

[PATCH 2/6] powerpc/powernv: Remove some OPAL function declaration duplication

2014-04-21 Thread Anton Blanchard 
We had some duplication of the internal OPAL functions.

Signed-off-by: Anton Blanchard an...@samba.org
---
 arch/powerpc/include/asm/opal.h | 12 ++--
 1 file changed, 2 insertions(+), 10 deletions(-)

diff --git a/arch/powerpc/include/asm/opal.h b/arch/powerpc/include/asm/opal.h
index 2a34485..cb7d52e 100644
--- a/arch/powerpc/include/asm/opal.h
+++ b/arch/powerpc/include/asm/opal.h
@@ -884,7 +884,8 @@ int64_t opal_set_param(uint64_t token, uint32_t param_id, 
uint64_t buffer,
 int64_t opal_sensor_read(uint32_t sensor_hndl, int token, __be32 *sensor_data);
 
 /* Internal functions */
-extern int early_init_dt_scan_opal(unsigned long node, const char *uname, int 
depth, void *data);
+extern int early_init_dt_scan_opal(unsigned long node, const char *uname,
+  int depth, void *data);
 extern int early_init_dt_scan_recoverable_ranges(unsigned long node,
 const char *uname, int depth, void *data);
 
@@ -893,10 +894,6 @@ extern int opal_put_chars(uint32_t vtermno, const char 
*buf, int total_len);
 
 extern void hvc_opal_init_early(void);
 
-/* Internal functions */
-extern int early_init_dt_scan_opal(unsigned long node, const char *uname,
-  int depth, void *data);
-
 extern int opal_notifier_register(struct notifier_block *nb);
 extern int opal_notifier_unregister(struct notifier_block *nb);
 
@@ -906,9 +903,6 @@ extern void opal_notifier_enable(void);
 extern void opal_notifier_disable(void);
 extern void opal_notifier_update_evt(uint64_t evt_mask, uint64_t evt_val);
 
-extern int opal_get_chars(uint32_t vtermno, char *buf, int count);
-extern int opal_put_chars(uint32_t vtermno, const char *buf, int total_len);
-
 extern int __opal_async_get_token(void);
 extern int opal_async_get_token_interruptible(void);
 extern int __opal_async_release_token(int token);
@@ -916,8 +910,6 @@ extern int opal_async_release_token(int token);
 extern int opal_async_wait_response(uint64_t token, struct opal_msg *msg);
 extern int opal_get_sensor_data(u32 sensor_hndl, u32 *sensor_data);
 
-extern void hvc_opal_init_early(void);
-
 struct rtc_time;
 extern int opal_set_rtc_time(struct rtc_time *tm);
 extern void opal_get_rtc_time(struct rtc_time *tm);
-- 
1.8.3.2

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

[PATCH 3/6] powerpc/powernv: Fix little endian issues with opal_do_notifier calls

2014-04-21 Thread Anton Blanchard 
The bitmap in opal_poll_events and opal_handle_interrupt is
big endian, so we need to byteswap it on little endian builds.

Signed-off-by: Anton Blanchard an...@samba.org
---
 arch/powerpc/platforms/powernv/opal.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/powerpc/platforms/powernv/opal.c 
b/arch/powerpc/platforms/powernv/opal.c
index 49d2f00..17cfc70 100644
--- a/arch/powerpc/platforms/powernv/opal.c
+++ b/arch/powerpc/platforms/powernv/opal.c
@@ -242,14 +242,14 @@ void opal_notifier_update_evt(uint64_t evt_mask,
 void opal_notifier_enable(void)
 {
int64_t rc;
-   uint64_t evt = 0;
+   __be64 evt = 0;
 
atomic_set(opal_notifier_hold, 0);
 
/* Process pending events */
rc = opal_poll_events(evt);
if (rc == OPAL_SUCCESS  evt)
-   opal_do_notifier(evt);
+   opal_do_notifier(be64_to_cpu(evt));
 }
 
 void opal_notifier_disable(void)
@@ -529,7 +529,7 @@ static irqreturn_t opal_interrupt(int irq, void *data)
 
opal_handle_interrupt(virq_to_hw(irq), events);
 
-   opal_do_notifier(events);
+   opal_do_notifier(be64_to_cpu(events));
 
return IRQ_HANDLED;
 }
-- 
1.8.3.2

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

[PATCH 5/6] powerpc/powernv: Create OPAL sglist helper functions and fix endian issues

2014-04-21 Thread Anton Blanchard 
We have two copies of code that creates an OPAL sg list. Consolidate
these into a common set of helpers and fix the endian issues.

The flash interface embedded a version number in the num_entries
field, whereas the dump interface did did not. Since versioning
wasn't added to the flash interface and it is impossible to add
this in a backwards compatible way, just remove it.

Signed-off-by: Anton Blanchard an...@samba.org
---
 arch/powerpc/include/asm/opal.h |  14 ++--
 arch/powerpc/platforms/powernv/opal-dump.c  |  81 +
 arch/powerpc/platforms/powernv/opal-flash.c | 106 +---
 arch/powerpc/platforms/powernv/opal.c   |  63 +
 4 files changed, 76 insertions(+), 188 deletions(-)

diff --git a/arch/powerpc/include/asm/opal.h b/arch/powerpc/include/asm/opal.h
index 1a752ac..afb0fed 100644
--- a/arch/powerpc/include/asm/opal.h
+++ b/arch/powerpc/include/asm/opal.h
@@ -41,14 +41,14 @@ struct opal_takeover_args {
  * size except the last one in the list to be as well.
  */
 struct opal_sg_entry {
-   void*data;
-   longlength;
+   __be64 data;
+   __be64 length;
 };
 
-/* sg list */
+/* SG list */
 struct opal_sg_list {
-   unsigned long num_entries;
-   struct opal_sg_list *next;
+   __be64 length;
+   __be64 next;
struct opal_sg_entry entry[];
 };
 
@@ -929,6 +929,10 @@ extern int opal_resync_timebase(void);
 
 extern void opal_lpc_init(void);
 
+struct opal_sg_list *opal_vmalloc_to_sg_list(void *vmalloc_addr,
+unsigned long vmalloc_size);
+void opal_free_sg_list(struct opal_sg_list *sg);
+
 #endif /* __ASSEMBLY__ */
 
 #endif /* __OPAL_H */
diff --git a/arch/powerpc/platforms/powernv/opal-dump.c 
b/arch/powerpc/platforms/powernv/opal-dump.c
index b9827b0..f0b4724 100644
--- a/arch/powerpc/platforms/powernv/opal-dump.c
+++ b/arch/powerpc/platforms/powernv/opal-dump.c
@@ -209,80 +209,6 @@ static struct kobj_type dump_ktype = {
.default_attrs = dump_default_attrs,
 };
 
-static void free_dump_sg_list(struct opal_sg_list *list)
-{
-   struct opal_sg_list *sg1;
-   while (list) {
-   sg1 = list-next;
-   kfree(list);
-   list = sg1;
-   }
-   list = NULL;
-}
-
-static struct opal_sg_list *dump_data_to_sglist(struct dump_obj *dump)
-{
-   struct opal_sg_list *sg1, *list = NULL;
-   void *addr;
-   int64_t size;
-
-   addr = dump-buffer;
-   size = dump-size;
-
-   sg1 = kzalloc(PAGE_SIZE, GFP_KERNEL);
-   if (!sg1)
-   goto nomem;
-
-   list = sg1;
-   sg1-num_entries = 0;
-   while (size  0) {
-   /* Translate virtual address to physical address */
-   sg1-entry[sg1-num_entries].data =
-   (void *)(vmalloc_to_pfn(addr)  PAGE_SHIFT);
-
-   if (size  PAGE_SIZE)
-   sg1-entry[sg1-num_entries].length = PAGE_SIZE;
-   else
-   sg1-entry[sg1-num_entries].length = size;
-
-   sg1-num_entries++;
-   if (sg1-num_entries = SG_ENTRIES_PER_NODE) {
-   sg1-next = kzalloc(PAGE_SIZE, GFP_KERNEL);
-   if (!sg1-next)
-   goto nomem;
-
-   sg1 = sg1-next;
-   sg1-num_entries = 0;
-   }
-   addr += PAGE_SIZE;
-   size -= PAGE_SIZE;
-   }
-   return list;
-
-nomem:
-   pr_err(%s : Failed to allocate memory\n, __func__);
-   free_dump_sg_list(list);
-   return NULL;
-}
-
-static void sglist_to_phy_addr(struct opal_sg_list *list)
-{
-   struct opal_sg_list *sg, *next;
-
-   for (sg = list; sg; sg = next) {
-   next = sg-next;
-   /* Don't translate NULL pointer for last entry */
-   if (sg-next)
-   sg-next = (struct opal_sg_list *)__pa(sg-next);
-   else
-   sg-next = NULL;
-
-   /* Convert num_entries to length */
-   sg-num_entries =
-   sg-num_entries * sizeof(struct opal_sg_entry) + 16;
-   }
-}
-
 static int64_t dump_read_info(uint32_t *id, uint32_t *size, uint32_t *type)
 {
int rc;
@@ -314,15 +240,12 @@ static int64_t dump_read_data(struct dump_obj *dump)
}
 
/* Generate SG list */
-   list = dump_data_to_sglist(dump);
+   list = opal_vmalloc_to_sg_list(dump-buffer, dump-size);
if (!list) {
rc = -ENOMEM;
goto out;
}
 
-   /* Translate sg list addr to real address */
-   sglist_to_phy_addr(list);
-
/* First entry address */
addr = __pa(list);
 
@@ -341,7 +264,7 @@ static int64_t dump_read_data(struct dump_obj *dump)
__func__, dump-id);
 
/* Free SG list */
-   free_dump_sg_list(list);
+

[PATCH 4/6] powerpc/powernv: Fix little endian issues in OPAL error log code

2014-04-21 Thread Anton Blanchard 
Fix little endian issues with the OPAL error log code.

Signed-off-by: Anton Blanchard an...@samba.org
Reviewed-by: Stewart Smith stew...@linux.vnet.ibm.com
---
 arch/powerpc/include/asm/opal.h| 2 +-
 arch/powerpc/platforms/powernv/opal-elog.c | 9 -
 2 files changed, 9 insertions(+), 2 deletions(-)

diff --git a/arch/powerpc/include/asm/opal.h b/arch/powerpc/include/asm/opal.h
index cb7d52e..1a752ac 100644
--- a/arch/powerpc/include/asm/opal.h
+++ b/arch/powerpc/include/asm/opal.h
@@ -859,7 +859,7 @@ int64_t opal_lpc_read(uint32_t chip_id, enum 
OpalLPCAddressType addr_type,
  uint32_t addr, __be32 *data, uint32_t sz);
 
 int64_t opal_read_elog(uint64_t buffer, uint64_t size, uint64_t log_id);
-int64_t opal_get_elog_size(uint64_t *log_id, uint64_t *size, uint64_t 
*elog_type);
+int64_t opal_get_elog_size(__be64 *log_id, __be64 *size, __be64 *elog_type);
 int64_t opal_write_elog(uint64_t buffer, uint64_t size, uint64_t offset);
 int64_t opal_send_ack_elog(uint64_t log_id);
 void opal_resend_pending_logs(void);
diff --git a/arch/powerpc/platforms/powernv/opal-elog.c 
b/arch/powerpc/platforms/powernv/opal-elog.c
index 7e3821e..10268c4 100644
--- a/arch/powerpc/platforms/powernv/opal-elog.c
+++ b/arch/powerpc/platforms/powernv/opal-elog.c
@@ -238,18 +238,25 @@ static struct elog_obj *create_elog_obj(uint64_t id, 
size_t size, uint64_t type)
 
 static void elog_work_fn(struct work_struct *work)
 {
+   __be64 size;
+   __be64 id;
+   __be64 type;
uint64_t elog_size;
uint64_t log_id;
uint64_t elog_type;
int rc;
char name[2+16+1];
 
-   rc = opal_get_elog_size(log_id, elog_size, elog_type);
+   rc = opal_get_elog_size(id, size, type);
if (rc != OPAL_SUCCESS) {
pr_err(ELOG: Opal log read failed\n);
return;
}
 
+   elog_size = be64_to_cpu(size);
+   log_id = be64_to_cpu(id);
+   elog_type = be64_to_cpu(type);
+
BUG_ON(elog_size  OPAL_MAX_ERRLOG_SIZE);
 
if (elog_size = OPAL_MAX_ERRLOG_SIZE)
-- 
1.8.3.2

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

[PATCH 6/6] powerpc/powernv: Fix little endian issues in OPAL dump code

2014-04-21 Thread Anton Blanchard 
Signed-off-by: Anton Blanchard an...@samba.org
---
 arch/powerpc/include/asm/opal.h|  4 ++--
 arch/powerpc/platforms/powernv/opal-dump.c | 13 +
 2 files changed, 11 insertions(+), 6 deletions(-)

diff --git a/arch/powerpc/include/asm/opal.h b/arch/powerpc/include/asm/opal.h
index afb0fed..66ad7a7 100644
--- a/arch/powerpc/include/asm/opal.h
+++ b/arch/powerpc/include/asm/opal.h
@@ -868,8 +868,8 @@ int64_t opal_validate_flash(uint64_t buffer, uint32_t 
*size, uint32_t *result);
 int64_t opal_manage_flash(uint8_t op);
 int64_t opal_update_flash(uint64_t blk_list);
 int64_t opal_dump_init(uint8_t dump_type);
-int64_t opal_dump_info(uint32_t *dump_id, uint32_t *dump_size);
-int64_t opal_dump_info2(uint32_t *dump_id, uint32_t *dump_size, uint32_t 
*dump_type);
+int64_t opal_dump_info(__be32 *dump_id, __be32 *dump_size);
+int64_t opal_dump_info2(__be32 *dump_id, __be32 *dump_size, __be32 *dump_type);
 int64_t opal_dump_read(uint32_t dump_id, uint64_t buffer);
 int64_t opal_dump_ack(uint32_t dump_id);
 int64_t opal_dump_resend_notification(void);
diff --git a/arch/powerpc/platforms/powernv/opal-dump.c 
b/arch/powerpc/platforms/powernv/opal-dump.c
index f0b4724..788a197 100644
--- a/arch/powerpc/platforms/powernv/opal-dump.c
+++ b/arch/powerpc/platforms/powernv/opal-dump.c
@@ -209,15 +209,20 @@ static struct kobj_type dump_ktype = {
.default_attrs = dump_default_attrs,
 };
 
-static int64_t dump_read_info(uint32_t *id, uint32_t *size, uint32_t *type)
+static int64_t dump_read_info(uint32_t *dump_id, uint32_t *dump_size, uint32_t 
*dump_type)
 {
+   __be32 id, size, type;
int rc;
-   *type = 0x;
 
-   rc = opal_dump_info2(id, size, type);
+   type = cpu_to_be32(0x);
 
+   rc = opal_dump_info2(id, size, type);
if (rc == OPAL_PARAMETER)
-   rc = opal_dump_info(id, size);
+   rc = opal_dump_info(id, size);
+
+   *dump_id = be32_to_cpu(id);
+   *dump_size = be32_to_cpu(size);
+   *dump_type = be32_to_cpu(type);
 
if (rc)
pr_warn(%s: Failed to get dump info (%d)\n,
-- 
1.8.3.2

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