On Wed, 2012-03-21 at 20:39 -0700, Greg KH wrote:
> On Thu, Mar 22, 2012 at 01:57:30PM +1100, Benjamin Herrenschmidt wrote:
> > +int __vio_register_driver(struct vio_driver *viodrv, struct module *owner,
> > + const char *mod_name)
> > {
> > viodrv->driver.bus = &vio_bus_type
On Thu, 2012-03-22 at 11:28 +0800, Gavin Shan wrote:
> > 1- ASAP so we can still get that into 3.4, move the eeh_dev pointer to
> >struct pci_dn instead of struct device_node. This structure is
> >accessible directly via dn->data and is ppc specific, that will be a
> >better temporary solution and
On Wed, 2012-03-21 at 19:02 -0700, Linus Torvalds wrote:
> On Wed, Mar 21, 2012 at 5:46 PM, Benjamin Herrenschmidt
> wrote:
> >
> > Here's the powerpc batch for this merge window. It is going to be a bit
> > more nasty than usual as in touching things outside of arch/powerpc
> > mostly due to the
> -Original Message-
> From: Kumar Gala [mailto:ga...@kernel.crashing.org]
> Sent: Wednesday, March 21, 2012 11:37 PM
> To: Aggrwal Poonam-B10812
> Cc: devicetree-disc...@lists.ozlabs.org; linuxppc-dev@lists.ozlabs.org;
> Singh Sandeep-B37400
> Subject: Re: [PATCH][v2] Device Tree Binding
BSC9131RDB is a Freescale reference design board for BSC9131 SoC.The BSC9131
is integrated SoC that targets Femto base station market. It combines Power
Architecture e500v2 and DSP StarCore SC3850 core technologies with MAPLE-B2F
baseband acceleration processing elements.
The BSC9131 SoC includes
Signed-off-by: Stephen Rothwell
---
arch/powerpc/boot/.gitignore|1 -
arch/powerpc/include/asm/iommu.h|1 -
arch/powerpc/include/asm/irq.h |2 +-
arch/powerpc/include/asm/mmu-hash64.h | 12
arch/powerpc/include/asm/smp.h |1 -
On Wed, Mar 21, 2012 at 19:02, Linus Torvalds
wrote:
> On Wed, Mar 21, 2012 at 5:46 PM, Benjamin Herrenschmidt
> wrote:
>> Here's the powerpc batch for this merge window. It is going to be a bit
>> more nasty than usual as in touching things outside of arch/powerpc
>> mostly due to the big iSeri
Now that legacy iSeries is gone, this is no longer used.
Signed-off-by: Stephen Rothwell
---
arch/powerpc/include/asm/irq.h |6 --
arch/powerpc/include/asm/machdep.h |4 +---
arch/powerpc/kernel/irq.c |4 ++--
3 files changed, 3 insertions(+), 11 deletions(-)
diff -
This function was copied over from the powerpc architecture but is not
used at all, so just remove it.
Signed-off-by: Stephen Rothwell
---
arch/c6x/include/asm/irq.h | 10 --
arch/c6x/kernel/irq.c |9 -
2 files changed, 0 insertions(+), 19 deletions(-)
This was found
On Thu, Mar 22, 2012 at 01:57:30PM +1100, Benjamin Herrenschmidt wrote:
> +int __vio_register_driver(struct vio_driver *viodrv, struct module *owner,
> + const char *mod_name)
> {
> viodrv->driver.bus = &vio_bus_type;
> + viodrv->driver.name = viodrv->name;
> + vi
>> Originally, the PCI sensitive OF node is tracing the eeh device
>> through struct device_node::edev. However, it was regarded as
>> bad idea.
>>
>> The patch removes struct device_node::edev. In addition, the
>> global list of eeh devices is introduced, and do retrival of
>> eeh device accordin
On Wed, Mar 21, 2012 at 07:02:00PM -0700, Linus Torvalds wrote:
> Ok, so this conflicted a bit with the generalized irq-domain stuff
> from Grant Likely, and while I tried to fix it up I can't even
> compile-test the end result, so you really need to verify my merge and
> perhaps send me fixups. O
On Thu, 2012-03-22 at 12:50 +1100, Benjamin Herrenschmidt wrote:
> On Wed, 2012-03-21 at 15:15 -0700, Greg KH wrote:
> >
> > Really? vio drivers are supposed to look like this with the .name and
> > .owner field manually being set in the static initialization of the
> > driver? That's sad, and s
On Wed, 2012-03-21 at 19:02 -0700, Linus Torvalds wrote:
>
> Ok, so this conflicted a bit with the generalized irq-domain stuff
> from Grant Likely, and while I tried to fix it up I can't even
> compile-test the end result, so you really need to verify my merge and
> perhaps send me fixups. Ok?
O
On Wed, Mar 21, 2012 at 5:46 PM, Benjamin Herrenschmidt
wrote:
>
> Here's the powerpc batch for this merge window. It is going to be a bit
> more nasty than usual as in touching things outside of arch/powerpc
> mostly due to the big iSeriesectomy :-) We finally got rid of the bugger
> (legacy iSer
So many defines for such a little file. Most of them can go.
Also remove the single entry changelog, we have git for that.
Signed-off-by: Anton Blanchard
---
Index: linux-build/arch/powerpc/platforms/pseries/ras.c
===
--- linux-bu
The RAS error interrupt is no longer used but we may as well
mirror the changes we made to the EPOW interrupt.
Signed-off-by: Anton Blanchard
---
Index: linux-build/arch/powerpc/platforms/pseries/ras.c
===
--- linux-build.orig/arch
IBM bit 2 in the rtas event-scan and check-exception calls is
marked reserved in the PAPR, so remove it from our RAS code.
Signed-off-by: Anton Blanchard
---
Index: linux-build/arch/powerpc/include/asm/rtas.h
===
--- linux-build.or
We have rtas_get_sensor so we may as well use it.
Signed-off-by: Anton Blanchard
---
Index: linux-build/arch/powerpc/platforms/pseries/ras.c
===
--- linux-build.orig/arch/powerpc/platforms/pseries/ras.c 2012-03-22
12:42:54.4
On Wed, 2012-03-21 at 15:15 -0700, Greg KH wrote:
>
> Really? vio drivers are supposed to look like this with the .name and
> .owner field manually being set in the static initialization of the
> driver? That's sad, and should be fixed, the vio core should do this
> type of thing for you.
Yeah
We have code to take environmental and power warning (EPOW)
interrupts but it simply prints a terse error message:
EPOW <0x624004000b8 0x0 0x0>
which tells us nothing about what happened. Even worse, if we
don't correctly respond to the interrupt we may get terminated
by firmware.
Add code
The IO event interrupt code has a function that finds specific
sections in an RTAS error log. We want to use it in the EPOW
code so make it global.
Rename things to make it less cryptic:
find_xelog_section() -> get_pseries_errorlog()
struct pseries_elog_section -> struct pseries_errorlog
Signed
The patch removes the eeh information from pci_dn since the eeh
device (struct eeh_dev) already contained those information.
Also, the pseries IOMMU mapping functions have been changed
for a little bit to retrieve PE address from eeh device instead
of pci_dn.
Signed-off-by: Gavin Shan
---
arch/p
Currently, the existing PHBs are retrieved from the FDT (Flat
Device Tree) based on the name of FDT node. Specificly, those
FDT nodes whose names have prefix "pci" are regarded as PHBs.
That's inappropriate because some PCI bridges possibilly have
names leading with "pci". It caused EEH is enabled
Originally, the PCI sensitive OF node is tracing the eeh device
through struct device_node::edev. However, it was regarded as
bad idea.
The patch removes struct device_node::edev and uses PCI_DN to
trace the corresponding eeh device according to BenH's comments.
Signed-off-by: Gavin Shan
---
ar
Hi Linus !
Here's the powerpc batch for this merge window. It is going to be a bit
more nasty than usual as in touching things outside of arch/powerpc
mostly due to the big iSeriesectomy :-) We finally got rid of the bugger
(legacy iSeries support) which was a PITA to maintain and that nobody
real
Hi Greg,
On Wed, 2012-03-21 at 15:11 -0700, Greg KH wrote:
> On Wed, Mar 21, 2012 at 04:41:20PM -0500, Kent Yoder wrote:
> > These routines add sysfs files supporting the Power7+ in-Nest encryption
> > accelerator driver.
> >
> > Signed-off-by: Kent Yoder
> > ---
> > Documentation/powerpc/pfo-n
Dear Tony,
In message <20120321221402.ga18...@thor.bakeyournoodle.com> you wrote:
>
> > What puzzles me is that also stuff for boards is being compiled which is
> > not really needed like treeboot-currituck.c even when I configure the
> > kernel for a kilauea board.
>
> Can you either propvide t
This patch adds the cas bits to advertise support for the Platform
Facilities Option (PFO) based encryption accelerator device. The nx
device driver provides support for this hardware feature.
Signed-off-by: Kent Yoder
---
arch/powerpc/kernel/prom_init.c |8 +++-
1 files changed, 7 inser
These routines add sysfs files supporting the Power7+ in-Nest encryption
accelerator driver.
Signed-off-by: Kent Yoder
---
Documentation/powerpc/pfo-nx-crypto.txt | 52
arch/powerpc/crypto/nx/nx_sysfs.c | 194 +++
2 files changed, 246 insertions(+),
These routines add the base device driver code supporting the Power7+
in-Nest encryption accelerator (nx) device.
Signed-off-by: Kent Yoder
---
arch/powerpc/crypto/nx/nx.c| 710
arch/powerpc/crypto/nx/nx.h| 190 ++
arch/powerpc/crypt
These files support configuring and building the nx device driver.
Signed-off-by: Kent Yoder
---
arch/powerpc/Makefile |1 +
arch/powerpc/crypto/nx/Makefile | 11 +++
drivers/crypto/Kconfig | 18 ++
3 files changed, 30 insertions(+), 0 deletions
These routines add support for SHA-256 hashing on the Power7+ CPU's
in-Nest accelerator driver.
Signed-off-by: Kent Yoder
---
arch/powerpc/crypto/nx/nx-sha256.c | 240
1 files changed, 240 insertions(+), 0 deletions(-)
create mode 100644 arch/powerpc/crypto
These routines add support for SHA-512 hashing on the Power7+ CPU's
in-Nest accelerator driver.
Signed-off-by: Kent Yoder
---
arch/powerpc/crypto/nx/nx-sha512.c | 259
1 files changed, 259 insertions(+), 0 deletions(-)
create mode 100644 arch/powerpc/crypto
These routines add support for AES in ECB mode on the Power7+ CPU's
in-Nest accelerator driver.
Signed-off-by: Kent Yoder
---
arch/powerpc/crypto/nx/nx-aes-ecb.c | 133 +++
1 files changed, 133 insertions(+), 0 deletions(-)
create mode 100644 arch/powerpc/crypto
These routines add support for AES in XCBC mode on the Power7+ CPU's
in-Nest accelerator driver.
Signed-off-by: Kent Yoder
---
arch/powerpc/crypto/nx/nx-aes-xcbc.c | 230 ++
1 files changed, 230 insertions(+), 0 deletions(-)
create mode 100644 arch/powerpc/crypt
These routines add support for AES in GCM mode on the Power7+ CPU's
in-Nest accelerator driver.
Signed-off-by: Kent Yoder
---
arch/powerpc/crypto/nx/nx-aes-gcm.c | 352 +++
1 files changed, 352 insertions(+), 0 deletions(-)
create mode 100644 arch/powerpc/crypto
These routines add support for AES in CTR mode on the Power7+ CPU's
in-Nest accelerator driver.
Signed-off-by: Kent Yoder
---
arch/powerpc/crypto/nx/nx-aes-ctr.c | 175 +++
1 files changed, 175 insertions(+), 0 deletions(-)
create mode 100644 arch/powerpc/crypto
These routines add support for AES in CCM mode on the Power7+ CPU's
in-Nest accelerator driver.
Signed-off-by: Kent Yoder
---
arch/powerpc/crypto/nx/nx-aes-ccm.c | 466 +++
1 files changed, 466 insertions(+), 0 deletions(-)
create mode 100644 arch/powerpc/crypto
These routines add support for AES in CBC mode on the Power7+ CPU's
in-Nest accelerator driver.
Signed-off-by: Kent Yoder
---
arch/powerpc/crypto/nx/nx-aes-cbc.c | 135 +++
1 files changed, 135 insertions(+), 0 deletions(-)
create mode 100644 arch/powerpc/crypto
From: Robert Jennings
This adds an update notifier mechanism for changes to properties in the
device tree. One use of this would be a device driver that needs to act
on changes to it's properties in the device tree after a live migration
or a dynamic activation that is triggered by updates to of
From: Robert Jennings
This patch adds the cas bits to advertise support for the Platform
Facilities Option (PFO) based random number generator accerator.
The pseries-rng driver provides support for this hardware feature.
Signed-off-by: Robert Jennings
Signed-off-by: Kent Yoder
---
arch/powerp
From: Michael Neuling
Adds support for the Platform Facilities Option (PFO)-based hardware
random number generator for POWER hardware.
Signed-off-by: Michael Neuling
Signed-off-by: Robert Jennings
Signed-off-by: Kent Yoder
---
drivers/char/hw_random/Kconfig | 13 +
drivers/char/h
From: Robert Jennings
The Platform Facilities Option (PFO) adds several new h_calls and
more return codes.
Signed-off-by: Robert Jennings
Signed-off-by: Kent Yoder
---
arch/powerpc/include/asm/hvcall.h | 25 +++--
1 files changed, 23 insertions(+), 2 deletions(-)
diff -
From: Robert Jennings
Add support for the Platform Facilities Option (PFO) to the VIO bus.
These devices have a separate root node in OpenFirmware which
requires additional parsing to map into the existing VIO device
structure fields. This adds the interface for PFO device drivers to
make synchr
This patch series adds support for a new device type, the Platform
Facilities Option (PFO). PFO resources are a set of accelerators that
share some system resources managed by the VIO bus. This patchset
includes the basic support for the devices in the VIO bus code along
with drivers for the rand
On Wed, Mar 21, 2012 at 04:41:08PM -0500, Kent Yoder wrote:
> +static int nx_register_algs(void)
> +{
> + int rc = -1;
> +
> + if (nx_driver.of.flags != NX_OF_FLAG_MASK_READY)
> + goto out;
> +
> + memset(&nx_driver.stats, 0, sizeof(struct nx_stats));
> +
> + rc = nx_sys
On Wed, Mar 21, 2012 at 02:10:59PM +0200, Robert Berger wrote:
> Hi,
>
> Up to 3.2.x I was able to compile a mainline kernel for the kilauea
> board, but...
>
> http://git.denx.de/?p=linux-denx.git;a=commitdiff;h=075bcf5879225d0c2a119c23d8046b890e051e81
>
> shows, that mfdcrx was introduced in t
On Wed, Mar 21, 2012 at 04:41:20PM -0500, Kent Yoder wrote:
> These routines add sysfs files supporting the Power7+ in-Nest encryption
> accelerator driver.
>
> Signed-off-by: Kent Yoder
> ---
> Documentation/powerpc/pfo-nx-crypto.txt | 52
Please put sysfs file information in Documen
On Wed, 2012-03-21 at 19:45 +, Florian Tobias Schandinat wrote:
> I finally found where we started to discuss this issue, for reference
> "sm501fb.c: support mmap on PPC440SPe/PPC440EPx" back in May 2010.
>
> The thing I don't remember is why we consider exporting the physical
> address to use
On Wed, 2012-03-21 at 11:58 -0700, Haren Myneni wrote:
>
> Yes, can be changed open or read/write calls and return -ENODEV,
> but /dev/port is no use on these systems.
>
> I am not sure whether any power systems have legacy ISA devices. If we
> do not have, CONFIG_DEVPORT can be disabled in Kconf
On Mar 21, 2012, at 1:19 PM, Scott Wood wrote:
> On 03/21/2012 01:04 PM, Kumar Gala wrote:
>>
>> On Feb 28, 2012, at 6:09 PM, Alexander Graf wrote:
>>
>>> From: Scott Wood
>>>
>>> DO_KVM will need to identify the particular exception type.
>>>
>>> There is an existing set of arbitrary number
On 03/19/2012 02:42 PM, Dmitry Eremin-Solenikov wrote:
> On Mon, Mar 19, 2012 at 12:49 AM, Benjamin Herrenschmidt
> wrote:
>> On Sun, 2012-03-18 at 18:04 +0400, Dmitry Eremin-Solenikov wrote:
>>> On Sun, Mar 18, 2012 at 4:46 AM, Benjamin Herrenschmidt
>>> wrote:
In fact, we could make the ne
On Wed, 2012-03-21 at 18:23 +1100, Benjamin Herrenschmidt wrote:
> On Tue, 2012-03-20 at 22:37 -0700, Haren Myneni wrote:
> > Some power systems do not have legacy ISA devices. So, /dev/port is not
> > a valid interface on these systems. User level tools such as kbdrate is
> > trying to access the
On 03/21/2012 01:04 PM, Kumar Gala wrote:
>
> On Feb 28, 2012, at 6:09 PM, Alexander Graf wrote:
>
>> From: Scott Wood
>>
>> DO_KVM will need to identify the particular exception type.
>>
>> There is an existing set of arbitrary numbers that Linux passes,
>> but it's an undocumented mess that so
On Mar 19, 2012, at 8:02 PM, Poonam Aggrwal wrote:
> This TDM controller is available in various Freescale SOCs like MPC8315,
> P1020,
> P1022, P1010.
>
> Signed-off-by: Sandeep Singh
> Signed-off-by: Poonam Aggrwal
> ---
> Changes in v2:
> - Incorporated Scott's Review comments
> Docum
On Feb 28, 2012, at 6:09 PM, Alexander Graf wrote:
> From: Scott Wood
>
> DO_KVM will need to identify the particular exception type.
>
> There is an existing set of arbitrary numbers that Linux passes,
> but it's an undocumented mess that sort of corresponds to server/classic
> exception vect
Thanks Kumar for clarifying my doubts.
> -Original Message-
> From: Kumar Gala [mailto:ga...@kernel.crashing.org]
> Sent: Wednesday, March 21, 2012 11:08 PM
> To: Kushwaha Prabhakar-B32579
> Cc: linuxppc-dev@lists.ozlabs.org; devicetree-disc...@lists.ozlabs.org;
> Jain Priyanka-B32167; Meh
On Mar 21, 2012, at 12:29 PM, Kushwaha Prabhakar-B32579 wrote:
>>
>>
>> [snip]
>>
>
> ??
> Not getting you..
Just meant, I was removing parts of the patch in the email to reduce things.
>
>>> diff --git a/arch/powerpc/platforms/85xx/bsc913x_rdb.c
>>> b/arch/powerpc/platforms/85xx/bsc913x_r
Hi Kumar,
Thanks for reviewing it.
Please find my response in-lined.
> -Original Message-
> From: Kumar Gala [mailto:ga...@kernel.crashing.org]
> Sent: Wednesday, March 21, 2012 10:51 PM
> To: Kushwaha Prabhakar-B32579
> Cc: linuxppc-dev@lists.ozlabs.org; devicetree-disc...@lists.ozlabs.o
On Mar 1, 2012, at 3:32 AM, Jia Hongtao wrote:
> This binding documents how the message register blocks found in some FSL
> MPIC implementations shall be represented in a device tree.
>
> Signed-off-by: Meador Inge
> Signed-off-by: Jia Hongtao
> ---
> Changes for v2:
> * Update compatible type
On Mar 20, 2012, at 1:24 AM,
wrote:
> From: Jerry Huang
>
> Signed-off-by: Jerry Huang
> ---
> changes for v2:
> - remove the lable "read-only" for DTB and kernel partition
> - remove the word "RO" or "RW" from the "lable" option
>
> arch/powerpc/boot/dts/p1020mbg-pc.dtsi|
On Mar 19, 2012, at 11:06 AM, Timur Tabi wrote:
> Remove the check for CONFIG_PPC_85xx and CONFIG_PPC_86xx from fsl_guts.h.
> The check was originally intended to allow the same header file to
> be used on 85xx and 86xx systems, even though the Global Utilities
> register could be different. It
On Mar 20, 2012, at 1:24 AM,
wrote:
> From: Jerry Huang
>
> Signed-off-by: Jerry Huang
> ---
> changes for v2:
> - remove the lable "read-only" for DTB and kernel partition
> - remove the word "RO" or "RW" from the "lable" option
>
> arch/powerpc/boot/dts/p1020utm-pc.dtsi|
On Feb 9, 2012, at 7:41 AM, Diana Craciun wrote:
> From: Diana CRACIUN
>
> The association in the decice tree between PCI and MSI
> using fsl,msi property was an artificial one and it does
> not reflect the actual hardware.
>
> Signed-off-by: Diana CRACIUN
> ---
> arch/powerpc/boot/dts/p2041r
On Feb 16, 2012, at 8:49 PM, Jia Hongtao wrote:
> Some MPIC implementations contain one or more blocks of message registers
> that are used to send messages between cores via IPIs. A simple API has
> been added to access (get/put, read, write, etc ...) these message registers.
> The available me
On Mar 15, 2012, at 5:41 PM, Timur Tabi wrote:
> The "memory" clobber tells the compiler to ensure that all writes to memory
> are committed before the hypercall is made.
>
> "memory" is only necessary for hcalls where the Hypervisor will read or
> write guest memory. However, we add it to all h
On Mar 17, 2012, at 3:58 AM, Shaveta Leekha wrote:
> Signed-off-by: Shaveta Leekha
> ---
> arch/powerpc/configs/corenet64_smp_defconfig |2 ++
> 1 files changed, 2 insertions(+), 0 deletions(-)
applied, squashed to a single commit for all 4 and updated commit message
- k
___
On Mar 17, 2012, at 3:39 AM, Prabhakar Kushwaha wrote:
> BSC9131RDB is a Freescale reference design board for BSC9131 SoC.The BSC9131
> is
> integrated SoC that targets Femto base station market. It combines Power
> Architecture e500v2 and DSP StarCore SC3850 core technologies with MAPLE-B2F
> b
Dear Josh,
In message
you wrote:
>
> > The problem is that for ppc-linux-gcc (GCC) 4.2.2 (which comes with the
> > ELDK 4.2) this assembly instruction is not known and the build breaks.
>
> Sigh. GCC 4.2 is pretty old at this point.
But still rock-solid ... We use it a lot, especially as ref
On 03/16/2012 09:33 PM, Kumar Gala wrote:
On Feb 9, 2012, at 7:41 AM, Diana Craciun wrote:
From: Diana CRACIUN
The association in the decice tree between PCI and MSI
using fsl,msi property was an artificial one and it does
not reflect the actual hardware.
Signed-off-by: Diana CRACIUN
---
arch
On Mar 17, 2012, at 12:37 AM, Aggrwal Poonam-B10812 wrote:
> Hello Pankaj, Rajan
>
> DO you have any comments on the below patch of gianfar?
>>> - fsl,num_rx_queues = <0x8>;
>>> - fsl,num_tx_queues = <0x8>;
> Have been removed from P1010RDB device tree to avoi
Timur Tabi wrote:
> They only problem I see with this is that I am thinking about modifying
> the drivers/dma driver to probe on "fsl,eloplus-dma-channel" channels
> directly. If I do that, then who should call of_platform_populate()?
Grant, could you tell me if there's anything actually work wit
On Mar 19, 2012, at 11:04 AM, Grant Likely wrote:
> On Fri, 16 Mar 2012 15:50:44 -0500, Timur Tabi wrote:
>> Kumar Gala wrote:
>>
>>> This seems like paper taping over the real issue. We should be able to
>>> call of_platform_bus_probe() multiple times.
>>
>> I tried debugging it, but I coul
Hi Anatolij,
On Wed, 21 Mar 2012 01:18:30 +0100 Anatolij Gustschin wrote:
>
> Yes. Stephen, could you please change linux-next to pull from my
> mpc5xxx tree
>
> git://git.denx.de/linux-2.6-agust.git next
I have replaced the 52xx-and-virtex tree with this (and called it simply
mpc5xxx). I hav
Hello,
On Tuesday, March 20, 2012 8:25 AM Marek Szyprowski wrote:
> Hi Linus,
>
> Please pull the dma-mapping framework updates for v3.4 since commit
> c16fa4f2ad19908a47c63d8fa436a1178438c7e7:
>
> Linux 3.3
>
> with the top-most commit e749a9f707f1102735e02338fa564be86be3bb69
>
> common:
On Wed, Mar 21, 2012 at 8:10 AM, Robert Berger
wrote:
> Hi,
>
> Up to 3.2.x I was able to compile a mainline kernel for the kilauea
> board, but...
>
> http://git.denx.de/?p=linux-denx.git;a=commitdiff;h=075bcf5879225d0c2a119c23d8046b890e051e81
>
> shows, that mfdcrx was introduced in the v3.3 ker
Hi,
Up to 3.2.x I was able to compile a mainline kernel for the kilauea
board, but...
http://git.denx.de/?p=linux-denx.git;a=commitdiff;h=075bcf5879225d0c2a119c23d8046b890e051e81
shows, that mfdcrx was introduced in the v3.3 kernel.
The problem is that for ppc-linux-gcc (GCC) 4.2.2 (which comes
Signed-off-by: Konstantin Khlebnikov
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Cc: linuxppc-dev@lists.ozlabs.org
---
arch/powerpc/include/asm/mman.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/include/asm/mman.h b/arch/powerpc/include/asm/mman.h
in
On Tue, 2012-03-20 at 22:37 -0700, Haren Myneni wrote:
> Some power systems do not have legacy ISA devices. So, /dev/port is not
> a valid interface on these systems. User level tools such as kbdrate is
> trying to access the device using this interface which is causing the
> system crash.
>
> Th
80 matches
Mail list logo
