On 04/23/2014 03:01 AM, Anton Blanchard wrote:
Hi,
-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(__be3
Hi Ben,
Here are the ABIv2 patches rebased against 3.15-rc2.
The main changes since the last posting:
powerpc: Don't build assembly files with ABIv2
Added so each patch in the series builds and we don't have any
bisect issues.
selftests/powerpc: Update for ABIv2
Fixes b
On PowerNV platform, we are holding an unnecessary refcount on a pci_dev, which
leads to the pci_dev is not destroyed when hotplugging a pci device.
This patch release the unnecessary refcount.
Signed-off-by: Wei Yang
---
arch/powerpc/platforms/powernv/pci-ioda.c |1 -
1 file changed, 1 del
During the EEH hotplug event, iommu_add_device() will be invoked three times
and two of them will trigger warning or error.
The three times to invoke the iommu_add_device() are:
pci_device_add
...
set_iommu_table_base_and_group <- 1st time, fail
device_add
...
On Wed, Apr 23, 2014 at 10:26:18AM +1000, Benjamin Herrenschmidt wrote:
>On Wed, 2014-04-23 at 09:00 +1000, Gavin Shan wrote:
>> The side effect of holding pci_dev refcount is the pci_dev, eeh_dev,
>> eeh_pe instance can't be free'ed during fully hotplug though EEH can
>> survive. It's reasonable t
From: Rob Herring
Now powerpc is the only user of struct boot_param_header and FDT defines,
so they can be moved into the powerpc architecture code.
Signed-off-by: Rob Herring
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Cc: linuxppc-dev@lists.ozlabs.org
---
v2: no change
arch/powerpc/incl
From: Rob Herring
Both powerpc and microblaze have the same FDT blob in debugfs feature.
Move this to common location and remove the powerpc and microblaze
implementations. This feature could become more useful when FDT
overlay support is added.
This changes the path of the blob from "$arch/flat
From: Rob Herring
This is a series of clean-ups of architecture FDT code and converts the
core FDT code over to using libfdt functions. This is in preparation
to add FDT based address translation parsing functions for early
console support. This series removes direct access to FDT data from all
a
On Wed, 2014-04-23 at 09:00 +1000, Gavin Shan wrote:
> The side effect of holding pci_dev refcount is the pci_dev, eeh_dev,
> eeh_pe instance can't be free'ed during fully hotplug though EEH can
> survive. It's reasonable to remove it.
Allright. Can you guys refresh that patch with an updated cset
On Tue, Apr 22, 2014 at 06:25:09PM +1000, Benjamin Herrenschmidt wrote:
>On Tue, 2014-04-22 at 15:44 +0800, Wei Yang wrote:
>> So this patch(the 2nd one) doesn't contribute to clear the warning and
>> error.
>> Only the first patch did it. Please ignore this one.
>
>But is it correct ? It's not rig
On Tue, 2014-04-22 at 17:31 -0500, Scott Wood wrote:
> On Tue, 2014-04-22 at 05:43 -0700, shiva7 wrote:
> > I have the same question as like above posted by Mr. Chirs.
>
> I had to google the subject to find what e-mail you were talking about
> -- it was posted a year ago:
>
> http://marc.info/?
On Tue, 2014-04-22 at 05:43 -0700, shiva7 wrote:
> I have the same question as like above posted by Mr. Chirs.
I had to google the subject to find what e-mail you were talking about
-- it was posted a year ago:
http://marc.info/?l=linuxppc-embedded&m=136572252330650&w=2
Next time please quote t
Hi Alan,
> > The linker fixes up TOC. relocations, so prom_init_check.sh should
> > ignore them.
>
> Err, .TOC. you mean. Presumably something strips off the leading dot
> somewhere?
Yeah, the script strips them:
# On 64-bit nm gives us the function descriptors, which have
# a
Hi,
> Shouldn't we convert addr and id before passing to opal_dump_read()
> here ?
int64_t opal_dump_read(uint32_t dump_id, uint64_t buffer);
All arguments are passed via register, so byteswaping the arguments
would break it.
Anton
___
Linuxppc-dev m
Hi,
> -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
>
On Fri, 2014-04-18 at 15:29 +0400, Alexander Popov wrote:
>
> 2014-04-17 0:44 GMT+04:00 Gerhard Sittig :
> > On Tue, 2014-04-15 at 14:54 +0400, Alexander Popov wrote:
> >>
> >> +- reg: Address and size of the DMA controller's register set
> >> +- interrupts: Interrupt for the DMA controller. Gener
On Tue, Apr 22, 2014 at 02:08:29PM +0100, Grant Likely wrote:
> > I would prefer to see a "WARN_ON(!IS_ENABLED(CONFIG_PPC32));" added here.
>
> I completely agree.
OK. So do we keep this around on unaffected architectures in perpetuity?
Or can there be some cut-off date when the majority of DT-e
On Fri, 18 Apr 2014 13:59:24 +0100, Leif Lindholm
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
> > wrote:
> > > In order to deal with an firmware bug on a specific ppc32 platform
> > > (longtrail),
I have the same question as like above posted by Mr. Chirs.
Could someone help to understand why the debug BRT bit not handled in debug
context sys call? Intentional or need volunteer to finish up this part :)
--
View this message in context:
http://linuxppc.10917.n7.nabble.com/questions-on-C
On Fri, 18 Apr 2014 10:37:58 -0500, Rob Herring wrote:
> On Fri, Apr 18, 2014 at 7:48 AM, Leif Lindholm
> wrote:
> > On Thu, Apr 17, 2014 at 07:43:13PM -0500, Rob Herring wrote:
> >> On Thu, Apr 17, 2014 at 12:41 PM, Leif Lindholm
> >> wrote:
> >> > drivers/of/fdt.c contains a workaround for a
On Sat, Apr 12, 2014 at 7:41 AM, Alexander Shiyan wrote:
> This patch converts GE I/O FPGA GPIO driver to platform driver.
>
> Signed-off-by: Alexander Shiyan
No further comments, so this v2 patch is applied.
Yours,
Linus Walleij
___
Linuxppc-dev mai
On Tue, Apr 22, 2014 at 06:25:09PM +1000, Benjamin Herrenschmidt wrote:
>On Tue, 2014-04-22 at 15:44 +0800, Wei Yang wrote:
>> So this patch(the 2nd one) doesn't contribute to clear the warning and
>> error.
>> Only the first patch did it. Please ignore this one.
>
>But is it correct ? It's not rig
This patch introduces the support for Keymile's kmcoge4 board which is
the internal reference design for boards based on Freescale's
P2040/P2041 SoCs. This internal reference design is named kmp204x.
The peripherals used on this board are:
- SPI NOR Flash as bootloader medium
- NAND Flash with a u
Even though the company belongs to Microsemi, many chips are still
labeled as Zarlink. Among them is the family of network clock generators,
the zl3034x.
Signed-off-by: Valentin Longchamp
---
Changes in v4: None
Changes in v3: None
Changes in v2:
- add a patch so that the Zarlink vendor prefix
This series adds support for Keymile's COGE4 board, called kmcoge4. This
board is the reference design for further designs at Keymile around the
P2040/P2041 SoCs from Freescale. This reference design is internally
called kmp204x.
Changes in v4:
- remove the addition of the KEYMILE vendor-prefix as
These are the bindings for 2 MFD devices used on some of the Keymile boards.
The first one is the chassis managmenet bfticu FPGA.
The second one is the board controller (reset, LEDs, GPIOs) QRIO CPDL.
These FPGAs are used in the kmcoge4 board.
Signed-off-by: Valentin Longchamp
---
Changes in v4
On 04/22/2014 10:31 AM, Anton Blanchard wrote:
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
On 04/22/2014 10:31 AM, Anton Blanchard wrote:
Signed-off-by: Anton Blanchard
---
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
On Tue, 2014-04-22 at 15:44 +0800, Wei Yang wrote:
> So this patch(the 2nd one) doesn't contribute to clear the warning and
> error.
> Only the first patch did it. Please ignore this one.
But is it correct ? It's not right to keep a refcount elevated if we
don't have to.
Gavin, can you get to the
On 04/22/2014 10:31 AM, Anton Blanchard wrote:
Fix little endian issues with the OPAL error log code.
Signed-off-by: Anton Blanchard
Reviewed-by: Stewart Smith
---
arch/powerpc/include/asm/opal.h| 2 +-
arch/powerpc/platforms/powernv/opal-elog.c | 9 -
2 files changed,
On Tue, Apr 22, 2014 at 09:34:23AM +1000, Gavin Shan wrote:
>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 destro
Anton Blanchard writes:
> Now we have is_module_trampoline() and module_trampoline_target()
> we can remove a bunch of intimate kernel module trampoline
> knowledge from ftrace.
>
> Signed-off-by: Anton Blanchard
Oh god, I had no idea this code existed.
I really wanted to implement the R_PPC64_
Dave Hansen writes:
> On 04/08/2014 06:32 PM, Madhavan Srinivasan wrote:
>>> > In mm/Kconfig, put
>>> >
>>> > config FAULT_AROUND_ORDER
>>> > int
>>> > default 1234 if POWERPC
>>> > default 4
>>> >
>>> > The way you have it now, every single architecture that need
33 matches
Mail list logo
