* Re: [tip:irq/core] powerpc: eeh: Fixup the brown paperbag fallout of the "cleanup"
From: Benjamin Herrenschmidt @ 2014-03-04 23:18 UTC (permalink / raw)
To: linux-kernel, mingo, hpa, peterz, linuxppc-dev, tglx, shangw
Cc: linux-tip-commits
In-Reply-To: <tip-57310c3c99eb6fab2ecbd63aa3f7c323341ca77e@git.kernel.org>
On Tue, 2014-03-04 at 15:15 -0800, tip-bot for Thomas Gleixner wrote:
> Commit-ID: 57310c3c99eb6fab2ecbd63aa3f7c323341ca77e
> Gitweb: http://git.kernel.org/tip/57310c3c99eb6fab2ecbd63aa3f7c323341ca77e
> Author: Thomas Gleixner <tglx@linutronix.de>
> AuthorDate: Wed, 5 Mar 2014 00:06:11 +0100
> Committer: Thomas Gleixner <tglx@linutronix.de>
> CommitDate: Wed, 5 Mar 2014 00:13:33 +0100
>
> powerpc: eeh: Fixup the brown paperbag fallout of the "cleanup"
>
> Commit b8a9a11b9 (powerpc: eeh: Kill another abuse of irq_desc) is
> missing some brackets .....
>
> It's not a good idea to write patches in grumpy mode and then forget
> to at least compile test them or rely on the few eyeballs discussing
> that patch to spot it.....
Ouch :-)
Next time you have a series like that, if you want I'll throw it at my
build tester.
Cheers,
Ben.
> Reported-by: fengguang.wu@intel.com
> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
> Cc: Peter Zijlstra <peterz@infradead.org>
> Cc: Gavin Shan <shangw@linux.vnet.ibm.com>
> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Cc: ppc <linuxppc-dev@lists.ozlabs.org>
> ---
> arch/powerpc/kernel/eeh_driver.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/arch/powerpc/kernel/eeh_driver.c b/arch/powerpc/kernel/eeh_driver.c
> index 3e1d7de..bb61ca5 100644
> --- a/arch/powerpc/kernel/eeh_driver.c
> +++ b/arch/powerpc/kernel/eeh_driver.c
> @@ -166,8 +166,9 @@ static void eeh_enable_irq(struct pci_dev *dev)
> *
> * tglx
> */
> - if (irqd_irq_disabled(irq_get_irq_data(dev->irq))
> + if (irqd_irq_disabled(irq_get_irq_data(dev->irq)))
> enable_irq(dev->irq);
> + }
> }
>
> /**
^ permalink raw reply
* Re: [tip:irq/core] powerpc: eeh: Fixup the brown paperbag fallout of the "cleanup"
From: Thomas Gleixner @ 2014-03-04 23:29 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: shangw, linux-tip-commits, peterz, linux-kernel, hpa,
linuxppc-dev, mingo
In-Reply-To: <1393975112.10727.103.camel@pasglop>
On Wed, 5 Mar 2014, Benjamin Herrenschmidt wrote:
> On Tue, 2014-03-04 at 15:15 -0800, tip-bot for Thomas Gleixner wrote:
> > Commit-ID: 57310c3c99eb6fab2ecbd63aa3f7c323341ca77e
> > Gitweb: http://git.kernel.org/tip/57310c3c99eb6fab2ecbd63aa3f7c323341ca77e
> > Author: Thomas Gleixner <tglx@linutronix.de>
> > AuthorDate: Wed, 5 Mar 2014 00:06:11 +0100
> > Committer: Thomas Gleixner <tglx@linutronix.de>
> > CommitDate: Wed, 5 Mar 2014 00:13:33 +0100
> >
> > powerpc: eeh: Fixup the brown paperbag fallout of the "cleanup"
> >
> > Commit b8a9a11b9 (powerpc: eeh: Kill another abuse of irq_desc) is
> > missing some brackets .....
> >
> > It's not a good idea to write patches in grumpy mode and then forget
> > to at least compile test them or rely on the few eyeballs discussing
> > that patch to spot it.....
>
> Ouch :-)
>
> Next time you have a series like that, if you want I'll throw it at my
> build tester.
You simply could have been less lazy and picked up the whole ppc
related stuff instead of ignoring it....
Thanks,
tglx
^ permalink raw reply
* Re: [PATCH v3 03/11] perf: provide a common perf_event_nop_0() for use with .event_idx
From: Michael Ellerman @ 2014-03-05 1:19 UTC (permalink / raw)
To: Cody P Schafer
Cc: Peter Zijlstra, Peter Zijlstra, LKML, Ingo Molnar, Paul Mackerras,
Arnaldo Carvalho de Melo, scottwood, Linux PPC
In-Reply-To: <53157A45.4080600@linux.vnet.ibm.com>
On Mon, 2014-03-03 at 23:01 -0800, Cody P Schafer wrote:
> On 03/03/2014 09:19 PM, Michael Ellerman wrote:
> > On Thu, 2014-27-02 at 21:04:56 UTC, Cody P Schafer wrote:
> >> Rather an having every pmu that needs a function that just returns 0 for
> >> .event_idx define their own copy, reuse the one in kernel/events/core.c.
> >>
> >> Rename from perf_swevent_event_idx() because we're no longer using it
> >> for just software events. Naming is based on the perf_pmu_nop_*()
> >> functions.
> >
> > You could just use perf_pmu_nop_int() directly.
>
> No, .event_idx needs something that takes a (struct perf_event *),
> perf_pmu_nop_int() takes a (struct pmu *).
Yeah, duh.
cheers
^ permalink raw reply
* Re: [PATCH 2/3] dts: mpc512x: adjust clock specs for FEC nodes
From: Shawn Guo @ 2014-03-05 1:48 UTC (permalink / raw)
To: Gerhard Sittig
Cc: Mark Rutland, devicetree, Mike Turquette, Pawel Moll,
Ian Campbell, Rob Herring, Anatolij Gustschin, linuxppc-dev,
linux-arm-kernel
In-Reply-To: <20140303092231.GS3327@book.gsilab.sittig.org>
On Mon, Mar 03, 2014 at 10:22:31AM +0100, Gerhard Sittig wrote:
> On Mon, Feb 24, 2014 at 11:25 +0100, Gerhard Sittig wrote:
> >
> > a recent FEC binding document update that was motivated by i.MX
> > development revealed that ARM and PowerPC implementations in Linux
> > did not agree on the clock names to use for the FEC nodes
> >
> > change clock names from "per" to "ipg" in the FEC nodes of the
> > mpc5121.dtsi include file such that the .dts specs comply with
> > the common FEC binding
> >
> > this "incompatible" change does not break operation, because
> > - COMMON_CLK support for MPC5121/23/25 and adjusted .dts files
> > were only introduced in Linux v3.14-rc1, no mainline release
> > provided these specs before
> > - if this change won't make it for v3.14, the MPC512x CCF support
> > provides full backwards compability, and keeps operating with
> > device trees which lack clock specs or don't match in the names
> >
> > Signed-off-by: Gerhard Sittig <gsi@denx.de>
>
> ping
>
> Are there opinions about making PowerPC users of FEC use the same
> clock names as ARM users do, to re-use (actually: keep sharing)
> the FEC binding? The alternative would be to fragment the FEC
> binding into several bindings for ARM and PowerPC, which I feel
> would be undesirable, and is not necessary.
As I already said, Documentation/devicetree/bindings/net/fsl-fec.txt
was created specifically for i.MX FEC controller from day one. And even
as of today, it doesn't serve PowerPC, because for example the property
'phy-mode' documented as required one is not required by PowerPC FEC.
My opinion would be to patch fsl-fec.txt a little bit to make it clear
that it's a binding doc for i.MX FEC, and create the other one for
PowerPC FEC. This is the way less confusing to people and easier for
binding maintenance.
Shawn
^ permalink raw reply
* Re: [PATCH v3] powerpc/powernv Platform dump interface
From: Stewart Smith @ 2014-03-05 1:51 UTC (permalink / raw)
To: Vasant Hegde, benh, linuxppc-dev
In-Reply-To: <5315C592.4050605@linux.vnet.ibm.com>
Vasant Hegde <hegdevasant@linux.vnet.ibm.com> writes:
>> + Each dump has the following files:
>> + id: An ASCII representation of the dump ID
>> + in hex (e.g. '0x01')
>> + type: An ASCII representation of the type of
>> + dump in the format "0x%x %s" with the ID
>
> Better 0x%x - %s ?
I thought of that, but figured that a simple space is probably slightly
easier to parse programatically.
^ permalink raw reply
* Re: [PATCH v3] powerpc/powernv Platform dump interface
From: Stewart Smith @ 2014-03-05 1:55 UTC (permalink / raw)
To: Vasant Hegde, benh, linuxppc-dev
In-Reply-To: <5315C592.4050605@linux.vnet.ibm.com>
Vasant Hegde <hegdevasant@linux.vnet.ibm.com> writes:
>> index 0000000..32fe7f5
>> --- /dev/null
>> +++ b/Documentation/ABI/stable/sysfs-firmware-opal-dump
>> @@ -0,0 +1,41 @@
>> +What: /sys/firmware/opal/dump
>> +Date: Feb 2014
>> +Contact: Stewart Smith <stewart@linux.vnet.ibm.com>
>> +Description:
>> + This directory exposes interfaces for interacting with
>> + the FSP and platform dumps through OPAL firmware interface.
>> +
>> + This is only for the powerpc/powernv platform.
>> +
>> + initiate_dump: When '1' is written to it,
>> + we will initiate a dump.
>
> initiate FSP dump
ack. I can send subsequent patch that fixes up these bits.
>> --- /dev/null
>> +++ b/arch/powerpc/platforms/powernv/opal-dump.c
>> @@ -0,0 +1,525 @@
>> +/*
>> + * PowerNV OPAL Dump Interface
>> + *
>> + * Copyright 2013,2014 IBM Corp.
>> + *
>> + * This program is free software; you can redistribute it and/or
>> + * modify it under the terms of the GNU General Public License
>> + * as published by the Free Software Foundation; either version
>> + * 2 of the License, or (at your option) any later version.
>> + */
>> +
>> +#include <linux/kobject.h>
>> +#include <linux/mm.h>
>> +#include <linux/slab.h>
>> +#include <linux/vmalloc.h>
>> +#include <linux/pagemap.h>
>> +#include <linux/delay.h>
>> +
>> +#include <asm/opal.h>
>> +
>> +#define DUMP_TYPE_FSP 0x01
>
> Better define other dump type (sysdump etc) here and use it below ?
Likely yes, Is there a definitive list somewhere?
>> +static ssize_t init_dump_store(struct dump_obj *dump_obj,
>> + struct dump_attribute *attr,
>> + const char *buf,
>> + size_t count)
>> +{
>> + dump_fips_init(DUMP_TYPE_FSP);
>> + pr_info("%s: Initiated FSP dump\n", __func__);
>
> This might mislead if OPAL fails to initiate FSP dump.. Better move this to
> dump_fips_init () ?
good point. I don't think we actually process the response of FSP dump
init, which IIRC may actually be able to tell us if it failed to
initiate a dump.
^ permalink raw reply
* Re: [PATCH] powerpc/powernv: Read OPAL error log and export it through sysfs
From: Stewart Smith @ 2014-03-05 1:56 UTC (permalink / raw)
To: Vasant Hegde, Mahesh J Salgaonkar, benh, linuxppc-dev
In-Reply-To: <5315C7B6.1030602@linux.vnet.ibm.com>
Vasant Hegde <hegdevasant@linux.vnet.ibm.com> writes:
>> +int64_t opal_send_ack_elog(uint64_t log_id);
>
> Stewart,
>
> Why are you creating 64bit log ID when actual ID is 32bit ?
IIRC it's what OPAL gives us, even though FSP MBOX spec says 32bit.
^ permalink raw reply
* Re: [PATCH v3] powerpc/powernv Platform dump interface
From: Vasant Hegde @ 2014-03-05 3:25 UTC (permalink / raw)
To: Stewart Smith, benh, linuxppc-dev
In-Reply-To: <87y50pjto7.fsf@river.au.ibm.com>
On 03/05/2014 07:25 AM, Stewart Smith wrote:
> Vasant Hegde <hegdevasant@linux.vnet.ibm.com> writes:
>>> index 0000000..32fe7f5
>>> --- /dev/null
>>> +++ b/Documentation/ABI/stable/sysfs-firmware-opal-dump
>>> @@ -0,0 +1,41 @@
>>> +What: /sys/firmware/opal/dump
>>> +Date: Feb 2014
>>> +Contact: Stewart Smith <stewart@linux.vnet.ibm.com>
>>> +Description:
>>> + This directory exposes interfaces for interacting with
>>> + the FSP and platform dumps through OPAL firmware interface.
>>> +
>>> + This is only for the powerpc/powernv platform.
>>> +
>>> + initiate_dump: When '1' is written to it,
>>> + we will initiate a dump.
>>
>> initiate FSP dump
>
> ack. I can send subsequent patch that fixes up these bits.
>
>>> --- /dev/null
>>> +++ b/arch/powerpc/platforms/powernv/opal-dump.c
>>> @@ -0,0 +1,525 @@
>>> +/*
>>> + * PowerNV OPAL Dump Interface
>>> + *
>>> + * Copyright 2013,2014 IBM Corp.
>>> + *
>>> + * This program is free software; you can redistribute it and/or
>>> + * modify it under the terms of the GNU General Public License
>>> + * as published by the Free Software Foundation; either version
>>> + * 2 of the License, or (at your option) any later version.
>>> + */
>>> +
>>> +#include <linux/kobject.h>
>>> +#include <linux/mm.h>
>>> +#include <linux/slab.h>
>>> +#include <linux/vmalloc.h>
>>> +#include <linux/pagemap.h>
>>> +#include <linux/delay.h>
>>> +
>>> +#include <asm/opal.h>
>>> +
>>> +#define DUMP_TYPE_FSP 0x01
>>
>> Better define other dump type (sysdump etc) here and use it below ?
>
> Likely yes, Is there a definitive list somewhere?
List is depending on what OPAL gives to Linux...For now
#define DUMP_TYPE_FSP 0x01
#define DUMP_TYPE_SYS 0x02
#define DUMP_TYPE_SMA 0x03
>
>>> +static ssize_t init_dump_store(struct dump_obj *dump_obj,
>>> + struct dump_attribute *attr,
>>> + const char *buf,
>>> + size_t count)
>>> +{
>>> + dump_fips_init(DUMP_TYPE_FSP);
>>> + pr_info("%s: Initiated FSP dump\n", __func__);
>>
>> This might mislead if OPAL fails to initiate FSP dump.. Better move this to
>> dump_fips_init () ?
>
> good point. I don't think we actually process the response of FSP dump
> init, which IIRC may actually be able to tell us if it failed to
> initiate a dump.
>
Yes..
-Vasant
^ permalink raw reply
* Re: [PATCH] powerpc/powernv: Read OPAL error log and export it through sysfs
From: Vasant Hegde @ 2014-03-05 3:26 UTC (permalink / raw)
To: Stewart Smith, Mahesh J Salgaonkar, benh, linuxppc-dev
In-Reply-To: <87vbvtjtmh.fsf@river.au.ibm.com>
On 03/05/2014 07:26 AM, Stewart Smith wrote:
> Vasant Hegde <hegdevasant@linux.vnet.ibm.com> writes:
>>> +int64_t opal_send_ack_elog(uint64_t log_id);
>>
>> Stewart,
>>
>> Why are you creating 64bit log ID when actual ID is 32bit ?
>
> IIRC it's what OPAL gives us, even though FSP MBOX spec says 32bit.
>
Stewart,
Better ask OPAL folks to fix in firmware ?
-Vasant
^ permalink raw reply
* Re: [PATCH] powerpc/powernv: Read OPAL error log and export it through sysfs
From: Vasant Hegde @ 2014-03-05 3:26 UTC (permalink / raw)
To: Stewart Smith, Mahesh J Salgaonkar, benh, linuxppc-dev
In-Reply-To: <87vbvtjtmh.fsf@river.au.ibm.com>
On 03/05/2014 07:26 AM, Stewart Smith wrote:
> Vasant Hegde <hegdevasant@linux.vnet.ibm.com> writes:
>>> +int64_t opal_send_ack_elog(uint64_t log_id);
>>
>> Stewart,
>>
>> Why are you creating 64bit log ID when actual ID is 32bit ?
>
> IIRC it's what OPAL gives us, even though FSP MBOX spec says 32bit.
>
Stewart,
Better ask OPAL folks to fix in firmware ?
-Vasant
^ permalink raw reply
* ibmveth: Fix endian issues with MAC addresses
From: Anton Blanchard @ 2014-03-05 3:51 UTC (permalink / raw)
To: Joe Perches, Alexander Graf, Ben Herrenschmidt, Dinar Valeev,
Santiago Leon, tony
Cc: netdev, linuxppc-dev
In-Reply-To: <20131224125529.58970f1b@kryten>
The code to load a MAC address into a u64 for passing to the
hypervisor via a register is broken on little endian.
Create a helper function called ibmveth_encode_mac_addr
which does the right thing in both big and little endian.
We were storing the MAC address in a long in struct ibmveth_adapter.
It's never used so remove it - we don't need another place in the
driver where we create endian issues with MAC addresses.
Signed-off-by: Anton Blanchard <anton@samba.org>
Cc: stable@vger.kernel.org
---
Index: b/drivers/net/ethernet/ibm/ibmveth.c
===================================================================
--- a/drivers/net/ethernet/ibm/ibmveth.c
+++ b/drivers/net/ethernet/ibm/ibmveth.c
@@ -522,10 +522,21 @@ retry:
return rc;
}
+static u64 ibmveth_encode_mac_addr(u8 *mac)
+{
+ int i;
+ u64 encoded = 0;
+
+ for (i = 0; i < ETH_ALEN; i++)
+ encoded = (encoded << 8) | mac[i];
+
+ return encoded;
+}
+
static int ibmveth_open(struct net_device *netdev)
{
struct ibmveth_adapter *adapter = netdev_priv(netdev);
- u64 mac_address = 0;
+ u64 mac_address;
int rxq_entries = 1;
unsigned long lpar_rc;
int rc;
@@ -579,8 +590,7 @@ static int ibmveth_open(struct net_devic
adapter->rx_queue.num_slots = rxq_entries;
adapter->rx_queue.toggle = 1;
- memcpy(&mac_address, netdev->dev_addr, netdev->addr_len);
- mac_address = mac_address >> 16;
+ mac_address = ibmveth_encode_mac_addr(netdev->dev_addr);
rxq_desc.fields.flags_len = IBMVETH_BUF_VALID |
adapter->rx_queue.queue_len;
@@ -1183,8 +1193,8 @@ static void ibmveth_set_multicast_list(s
/* add the addresses to the filter table */
netdev_for_each_mc_addr(ha, netdev) {
/* add the multicast address to the filter table */
- unsigned long mcast_addr = 0;
- memcpy(((char *)&mcast_addr)+2, ha->addr, ETH_ALEN);
+ u64 mcast_addr;
+ mcast_addr = ibmveth_encode_mac_addr(ha->addr);
lpar_rc = h_multicast_ctrl(adapter->vdev->unit_address,
IbmVethMcastAddFilter,
mcast_addr);
@@ -1372,9 +1382,6 @@ static int ibmveth_probe(struct vio_dev
netif_napi_add(netdev, &adapter->napi, ibmveth_poll, 16);
- adapter->mac_addr = 0;
- memcpy(&adapter->mac_addr, mac_addr_p, ETH_ALEN);
-
netdev->irq = dev->irq;
netdev->netdev_ops = &ibmveth_netdev_ops;
netdev->ethtool_ops = &netdev_ethtool_ops;
@@ -1383,7 +1390,7 @@ static int ibmveth_probe(struct vio_dev
NETIF_F_IP_CSUM | NETIF_F_IPV6_CSUM;
netdev->features |= netdev->hw_features;
- memcpy(netdev->dev_addr, &adapter->mac_addr, netdev->addr_len);
+ memcpy(netdev->dev_addr, mac_addr_p, ETH_ALEN);
for (i = 0; i < IBMVETH_NUM_BUFF_POOLS; i++) {
struct kobject *kobj = &adapter->rx_buff_pool[i].kobj;
Index: b/drivers/net/ethernet/ibm/ibmveth.h
===================================================================
--- a/drivers/net/ethernet/ibm/ibmveth.h
+++ b/drivers/net/ethernet/ibm/ibmveth.h
@@ -138,7 +138,6 @@ struct ibmveth_adapter {
struct napi_struct napi;
struct net_device_stats stats;
unsigned int mcastFilterSize;
- unsigned long mac_addr;
void * buffer_list_addr;
void * filter_list_addr;
dma_addr_t buffer_list_dma;
^ permalink raw reply
* Re: [PATCH] powerpc/powernv: Read OPAL error log and export it through sysfs
From: Benjamin Herrenschmidt @ 2014-03-05 4:00 UTC (permalink / raw)
To: Vasant Hegde; +Cc: Stewart Smith, Mahesh J Salgaonkar, linuxppc-dev
In-Reply-To: <53169971.8050607@linux.vnet.ibm.com>
On Wed, 2014-03-05 at 08:56 +0530, Vasant Hegde wrote:
> On 03/05/2014 07:26 AM, Stewart Smith wrote:
> > Vasant Hegde <hegdevasant@linux.vnet.ibm.com> writes:
> >>> +int64_t opal_send_ack_elog(uint64_t log_id);
> >>
> >> Stewart,
> >>
> >> Why are you creating 64bit log ID when actual ID is 32bit ?
> >
> > IIRC it's what OPAL gives us, even though FSP MBOX spec says 32bit.
> >
>
> Stewart,
>
> Better ask OPAL folks to fix in firmware ?
Why bother ? That way if future versions of OPAL want to use 64-bit IDs,
they can.
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH] powerpc/powernv: Read OPAL error log and export it through sysfs
From: Stewart Smith @ 2014-03-05 4:05 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Vasant Hegde; +Cc: Mahesh J Salgaonkar, linuxppc-dev
In-Reply-To: <1393992008.11372.1.camel@pasglop>
Benjamin Herrenschmidt <benh@kernel.crashing.org> writes:
> On Wed, 2014-03-05 at 08:56 +0530, Vasant Hegde wrote:
>> On 03/05/2014 07:26 AM, Stewart Smith wrote:
>> > Vasant Hegde <hegdevasant@linux.vnet.ibm.com> writes:
>> >>> +int64_t opal_send_ack_elog(uint64_t log_id);
>> >>
>> >> Stewart,
>> >>
>> >> Why are you creating 64bit log ID when actual ID is 32bit ?
>> >
>> > IIRC it's what OPAL gives us, even though FSP MBOX spec says 32bit.
>> >
>>
>> Stewart,
>>
>> Better ask OPAL folks to fix in firmware ?
>
> Why bother ? That way if future versions of OPAL want to use 64-bit IDs,
> they can.
Yeah, that was my thought. The number of error logs on some POWER8
systems almost needs 64bit already :)
^ permalink raw reply
* Re: [PATCH 1/2] sched: Remove unused mc_capable() and smt_capable()
From: Benjamin Herrenschmidt @ 2014-03-05 4:36 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: linux-mips, linux-ia64, Peter Zijlstra, x86, linux-kernel,
Ingo Molnar, sparclinux, linuxppc-dev, linux-arm-kernel
In-Reply-To: <20140304210737.16893.54289.stgit@bhelgaas-glaptop.roam.corp.google.com>
On Tue, 2014-03-04 at 14:07 -0700, Bjorn Helgaas wrote:
> Remove mc_capable() and smt_capable(). Neither is used.
>
> Both were added by 5c45bf279d37 ("sched: mc/smt power savings sched
> policy"). Uses of both were removed by 8e7fbcbc22c1 ("sched: Remove stale
> power aware scheduling remnants and dysfunctional knobs").
>
> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
^ permalink raw reply
* [PATCh v2 1/2] QE: split function mpc85xx_qe_init() into two functions.
From: Zhao Qiang @ 2014-03-05 7:21 UTC (permalink / raw)
To: linuxppc-dev, B07421, galak; +Cc: Zhao Qiang, R63061
New QE doesn't have par_io, it doesn't need to init par_io
for new QE.
Split function mpc85xx_qe_init() into mpc85xx_qe_init()
and mpc85xx_qe_par_io_init().
Call mpc85xx_qe_init() for both new and old while
mpc85xx_qe_par_io_init() after mpc85xx_qe_init() for old.
Signed-off-by: Zhao Qiang <B45475@freescale.com>
---
Changes for v2:
-no
arch/powerpc/platforms/85xx/common.c | 6 ++++++
arch/powerpc/platforms/85xx/mpc85xx.h | 2 ++
arch/powerpc/platforms/85xx/mpc85xx_mds.c | 1 +
arch/powerpc/platforms/85xx/mpc85xx_rdb.c | 1 +
arch/powerpc/platforms/85xx/twr_p102x.c | 1 +
5 files changed, 11 insertions(+)
diff --git a/arch/powerpc/platforms/85xx/common.c b/arch/powerpc/platforms/85xx/common.c
index 3b085c7..b564b5e 100644
--- a/arch/powerpc/platforms/85xx/common.c
+++ b/arch/powerpc/platforms/85xx/common.c
@@ -107,6 +107,12 @@ void __init mpc85xx_qe_init(void)
qe_reset();
of_node_put(np);
+}
+
+void __init mpc85xx_qe_par_io_init(void)
+{
+ struct device_node *np;
+
np = of_find_node_by_name(NULL, "par_io");
if (np) {
struct device_node *ucc;
diff --git a/arch/powerpc/platforms/85xx/mpc85xx.h b/arch/powerpc/platforms/85xx/mpc85xx.h
index fc51dd4..39056f6 100644
--- a/arch/powerpc/platforms/85xx/mpc85xx.h
+++ b/arch/powerpc/platforms/85xx/mpc85xx.h
@@ -10,8 +10,10 @@ static inline void __init mpc85xx_cpm2_pic_init(void) {}
#ifdef CONFIG_QUICC_ENGINE
extern void mpc85xx_qe_init(void);
+extern void mpc85xx_qe_par_io_init(void);
#else
static inline void __init mpc85xx_qe_init(void) {}
+static inline void __init mpc85xx_qe_par_io_init(void) {}
#endif
#endif
diff --git a/arch/powerpc/platforms/85xx/mpc85xx_mds.c b/arch/powerpc/platforms/85xx/mpc85xx_mds.c
index 34f3c5e..3c190b4 100644
--- a/arch/powerpc/platforms/85xx/mpc85xx_mds.c
+++ b/arch/powerpc/platforms/85xx/mpc85xx_mds.c
@@ -239,6 +239,7 @@ static void __init mpc85xx_mds_qe_init(void)
struct device_node *np;
mpc85xx_qe_init();
+ mpc85xx_qe_par_io_init();
mpc85xx_mds_reset_ucc_phys();
if (machine_is(p1021_mds)) {
diff --git a/arch/powerpc/platforms/85xx/mpc85xx_rdb.c b/arch/powerpc/platforms/85xx/mpc85xx_rdb.c
index e15bdd1..f9668ed 100644
--- a/arch/powerpc/platforms/85xx/mpc85xx_rdb.c
+++ b/arch/powerpc/platforms/85xx/mpc85xx_rdb.c
@@ -99,6 +99,7 @@ static void __init mpc85xx_rdb_setup_arch(void)
#ifdef CONFIG_QUICC_ENGINE
mpc85xx_qe_init();
+ mpc85xx_qe_par_io_init();
#if defined(CONFIG_UCC_GETH) || defined(CONFIG_SERIAL_QE)
if (machine_is(p1025_rdb)) {
diff --git a/arch/powerpc/platforms/85xx/twr_p102x.c b/arch/powerpc/platforms/85xx/twr_p102x.c
index c25ff10..1eadb6d 100644
--- a/arch/powerpc/platforms/85xx/twr_p102x.c
+++ b/arch/powerpc/platforms/85xx/twr_p102x.c
@@ -77,6 +77,7 @@ static void __init twr_p1025_setup_arch(void)
#ifdef CONFIG_QUICC_ENGINE
mpc85xx_qe_init();
+ mpc85xx_qe_par_io_init();
#if defined(CONFIG_UCC_GETH) || defined(CONFIG_SERIAL_QE)
if (machine_is(twr_p1025)) {
--
1.8.5
^ permalink raw reply related
* [PATCh v2 2/2] Corenet: Add QE platform support for Corenet
From: Zhao Qiang @ 2014-03-05 7:21 UTC (permalink / raw)
To: linuxppc-dev, B07421, galak; +Cc: Zhao Qiang, R63061
In-Reply-To: <1394004092-4622-1-git-send-email-B45475@freescale.com>
There is QE on platform T104x, add support.
Call funcs qe_ic_init and qe_init if CONFIG_QUICC_ENGINE is defined.
Signed-off-by: Zhao Qiang <B45475@freescale.com>
---
Changes for v2:
- use mpc85xx_qe_init() instead
arch/powerpc/platforms/85xx/corenet_generic.c | 25 +++++++++++++++++++++++++
1 file changed, 25 insertions(+)
diff --git a/arch/powerpc/platforms/85xx/corenet_generic.c b/arch/powerpc/platforms/85xx/corenet_generic.c
index fbd871e..f1f4575 100644
--- a/arch/powerpc/platforms/85xx/corenet_generic.c
+++ b/arch/powerpc/platforms/85xx/corenet_generic.c
@@ -26,11 +26,14 @@
#include <asm/udbg.h>
#include <asm/mpic.h>
#include <asm/ehv_pic.h>
+#include <asm/qe.h>
+#include <asm/qe_ic.h>
#include <linux/of_platform.h>
#include <sysdev/fsl_soc.h>
#include <sysdev/fsl_pci.h>
#include "smp.h"
+#include "mpc85xx.h"
void __init corenet_gen_pic_init(void)
{
@@ -38,6 +41,10 @@ void __init corenet_gen_pic_init(void)
unsigned int flags = MPIC_BIG_ENDIAN | MPIC_SINGLE_DEST_CPU |
MPIC_NO_RESET;
+#ifdef CONFIG_QUICC_ENGINE
+ struct device_node *np;
+#endif
+
if (ppc_md.get_irq == mpic_get_coreint_irq)
flags |= MPIC_ENABLE_COREINT;
@@ -45,6 +52,16 @@ void __init corenet_gen_pic_init(void)
BUG_ON(mpic == NULL);
mpic_init(mpic);
+
+#ifdef CONFIG_QUICC_ENGINE
+ np = of_find_compatible_node(NULL, NULL, "fsl,qe-ic");
+ if (np) {
+ qe_ic_init(np, 0, qe_ic_cascade_low_mpic,
+ qe_ic_cascade_high_mpic);
+ of_node_put(np);
+ }
+#endif
+
}
/*
@@ -57,6 +74,11 @@ void __init corenet_gen_setup_arch(void)
swiotlb_detect_4g();
pr_info("%s board from Freescale Semiconductor\n", ppc_md.name);
+
+#ifdef CONFIG_QUICC_ENGINE
+ mpc85xx_qe_init();
+#endif
+
}
static const struct of_device_id of_device_ids[] = {
@@ -81,6 +103,9 @@ static const struct of_device_id of_device_ids[] = {
{
.compatible = "fsl,qoriq-pcie-v3.0",
},
+ {
+ .compatible = "fsl,qe",
+ },
/* The following two are for the Freescale hypervisor */
{
.name = "hypervisor",
--
1.8.5
^ permalink raw reply related
* [PATCH] net/phy: Add Cortina CS43xx PHY support
From: Shengzhou Liu @ 2014-03-05 8:16 UTC (permalink / raw)
To: linuxppc-dev, scottwood; +Cc: YongHua Cao, Shengzhou Liu
Add support for Cortina CS4315/CS4340 10G PHY.
(Tested with CS4315 on T2080RDB and CS4340 on T4240RDB).
Signed-off-by: YongHua Cao <B43619@freescale.com>
Signed-off-by: Shengzhou Liu <Shengzhou.Liu@freescale.com>
---
drivers/net/phy/Kconfig | 5 +++
drivers/net/phy/Makefile | 1 +
drivers/net/phy/cortina.c | 92 +++++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 98 insertions(+)
create mode 100644 drivers/net/phy/cortina.c
diff --git a/drivers/net/phy/Kconfig b/drivers/net/phy/Kconfig
index 1d18443..f7d6c8c 100644
--- a/drivers/net/phy/Kconfig
+++ b/drivers/net/phy/Kconfig
@@ -60,6 +60,11 @@ config VITESSE_PHY
---help---
Currently supports the vsc8244
+config CORTINA_PHY
+ tristate "Drivers for the Cortina PHYs"
+ ---help---
+ Currently supports the CS4315 and CS4340 PHY.
+
config SMSC_PHY
tristate "Drivers for SMSC PHYs"
---help---
diff --git a/drivers/net/phy/Makefile b/drivers/net/phy/Makefile
index a4f96b7..4047042 100644
--- a/drivers/net/phy/Makefile
+++ b/drivers/net/phy/Makefile
@@ -11,6 +11,7 @@ obj-$(CONFIG_LXT_PHY) += lxt.o
obj-$(CONFIG_QSEMI_PHY) += qsemi.o
obj-$(CONFIG_SMSC_PHY) += smsc.o
obj-$(CONFIG_VITESSE_PHY) += vitesse.o
+obj-$(CONFIG_CORTINA_PHY) += cortina.o
obj-$(CONFIG_BROADCOM_PHY) += broadcom.o
obj-$(CONFIG_BCM63XX_PHY) += bcm63xx.o
obj-$(CONFIG_BCM87XX_PHY) += bcm87xx.o
diff --git a/drivers/net/phy/cortina.c b/drivers/net/phy/cortina.c
new file mode 100644
index 0000000..154827c
--- /dev/null
+++ b/drivers/net/phy/cortina.c
@@ -0,0 +1,92 @@
+/* Driver for Cortina PHYs
+ *
+ * Copyright 2013-2014 Freescale Semiconductor, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ *
+ */
+
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/mii.h>
+#include <linux/ethtool.h>
+#include <linux/phy.h>
+
+#define PHY_ID_CS4340 0x13e51002
+
+MODULE_DESCRIPTION("Cortina PHY driver");
+MODULE_AUTHOR("Caoyh");
+MODULE_LICENSE("GPL");
+
+static int cs4340_config_init(struct phy_device *phydev)
+{
+ phydev->supported = SUPPORTED_10000baseT_Full;
+ phydev->advertising = SUPPORTED_10000baseT_Full;
+
+ return 0;
+}
+
+static int cs4340_config_aneg(struct phy_device *phydev)
+{
+ return 0;
+}
+
+static int cs4340_read_status(struct phy_device *phydev)
+{
+ phydev->link = 1;
+ phydev->speed = 10000;
+ phydev->duplex = DUPLEX_FULL;
+ return 0;
+}
+
+static int cs4340_ack_interrupt(struct phy_device *phydev)
+{
+ return 0;
+}
+
+static int cs4340_config_intr(struct phy_device *phydev)
+{
+ return 0;
+}
+
+static struct phy_driver cs4340_driver = {
+ .phy_id = PHY_ID_CS4340,
+ .phy_id_mask = 0xffffffff,
+ .name = "Cortina CS4315/CS4340",
+ .features = 0,
+ .config_init = &cs4340_config_init,
+ .config_aneg = &cs4340_config_aneg,
+ .read_status = &cs4340_read_status,
+ .ack_interrupt = &cs4340_ack_interrupt,
+ .config_intr = &cs4340_config_intr,
+ .driver = { .owner = THIS_MODULE,},
+};
+
+static int __init cs4340_init(void)
+{
+ int err;
+
+ err = phy_driver_register(&cs4340_driver);
+ if (err < 0)
+ return err;
+
+ return 0;
+}
+
+static void __exit cs4340_exit(void)
+{
+ phy_driver_unregister(&cs4340_driver);
+}
+
+module_init(cs4340_init);
+module_exit(cs4340_exit);
+
+static struct mdio_device_id __maybe_unused cortina_tbl[] = {
+ { PHY_ID_CS4340, 0xffffffff},
+ {},
+};
+
+MODULE_DEVICE_TABLE(mdio, cortina_tbl);
--
1.8.0
^ permalink raw reply related
* Re: [PATCH] net/phy: Add Cortina CS43xx PHY support
From: Kumar Gala @ 2014-03-05 9:29 UTC (permalink / raw)
To: Shengzhou Liu; +Cc: scottwood, linuxppc-dev, YongHua Cao
In-Reply-To: <1394007391-32256-1-git-send-email-Shengzhou.Liu@freescale.com>
On Mar 5, 2014, at 2:16 AM, Shengzhou Liu <Shengzhou.Liu@freescale.com> =
wrote:
> Add support for Cortina CS4315/CS4340 10G PHY.
> (Tested with CS4315 on T2080RDB and CS4340 on T4240RDB).
>=20
> Signed-off-by: YongHua Cao <B43619@freescale.com>
> Signed-off-by: Shengzhou Liu <Shengzhou.Liu@freescale.com>
> ---
> drivers/net/phy/Kconfig | 5 +++
> drivers/net/phy/Makefile | 1 +
> drivers/net/phy/cortina.c | 92 =
+++++++++++++++++++++++++++++++++++++++++++++++
> 3 files changed, 98 insertions(+)
> create mode 100644 drivers/net/phy/cortina.c
This patch really needs to be posted to the netdev list
- k=
^ permalink raw reply
* RE: [PATCH] net/phy: Add Cortina CS43xx PHY support
From: Shengzhou.Liu @ 2014-03-05 9:52 UTC (permalink / raw)
To: Kumar Gala
Cc: Scott Wood, linuxppc-dev@lists.ozlabs.org, B43619@freescale.com
In-Reply-To: <CFF70C14-23B1-45B9-AD84-C33E32F0B9A3@kernel.crashing.org>
Sure, will too post to netdev list.
Regards,
Shengzhou
> -----Original Message-----
> From: Kumar Gala [mailto:galak@kernel.crashing.org]
> Sent: Wednesday, March 05, 2014 5:30 PM
> To: Liu Shengzhou-B36685
> Cc: linuxppc-dev@lists.ozlabs.org; Wood Scott-B07421; Cao Yong Hua-B43619
> Subject: Re: [PATCH] net/phy: Add Cortina CS43xx PHY support
>=20
>=20
> On Mar 5, 2014, at 2:16 AM, Shengzhou Liu <Shengzhou.Liu@freescale.com>
> wrote:
>=20
> > Add support for Cortina CS4315/CS4340 10G PHY.
> > (Tested with CS4315 on T2080RDB and CS4340 on T4240RDB).
> >
> > Signed-off-by: YongHua Cao <B43619@freescale.com>
> > Signed-off-by: Shengzhou Liu <Shengzhou.Liu@freescale.com>
> > ---
> > drivers/net/phy/Kconfig | 5 +++
> > drivers/net/phy/Makefile | 1 +
> > drivers/net/phy/cortina.c | 92
> +++++++++++++++++++++++++++++++++++++++++++++++
> > 3 files changed, 98 insertions(+)
> > create mode 100644 drivers/net/phy/cortina.c
>=20
> This patch really needs to be posted to the netdev list
>=20
> - k
^ permalink raw reply
* Re: [PATCH 2/3] dts: mpc512x: adjust clock specs for FEC nodes
From: Gerhard Sittig @ 2014-03-05 10:52 UTC (permalink / raw)
To: Shawn Guo
Cc: Mark Rutland, devicetree, Mike Turquette, Pawel Moll,
Ian Campbell, Rob Herring, Anatolij Gustschin, linuxppc-dev,
linux-arm-kernel
In-Reply-To: <20140305014836.GC8784@S2101-09.ap.freescale.net>
On Wed, Mar 05, 2014 at 09:48 +0800, Shawn Guo wrote:
>
> On Mon, Mar 03, 2014 at 10:22:31AM +0100, Gerhard Sittig wrote:
> > On Mon, Feb 24, 2014 at 11:25 +0100, Gerhard Sittig wrote:
> > >
> > > a recent FEC binding document update that was motivated by i.MX
> > > development revealed that ARM and PowerPC implementations in Linux
> > > did not agree on the clock names to use for the FEC nodes
> > >
> > > change clock names from "per" to "ipg" in the FEC nodes of the
> > > mpc5121.dtsi include file such that the .dts specs comply with
> > > the common FEC binding
> > >
> > > this "incompatible" change does not break operation, because
> > > - COMMON_CLK support for MPC5121/23/25 and adjusted .dts files
> > > were only introduced in Linux v3.14-rc1, no mainline release
> > > provided these specs before
> > > - if this change won't make it for v3.14, the MPC512x CCF support
> > > provides full backwards compability, and keeps operating with
> > > device trees which lack clock specs or don't match in the names
> > >
> > > Signed-off-by: Gerhard Sittig <gsi@denx.de>
> >
> > ping
> >
> > Are there opinions about making PowerPC users of FEC use the same
> > clock names as ARM users do, to re-use (actually: keep sharing)
> > the FEC binding? The alternative would be to fragment the FEC
> > binding into several bindings for ARM and PowerPC, which I feel
> > would be undesirable, and is not necessary.
>
> As I already said, Documentation/devicetree/bindings/net/fsl-fec.txt
> was created specifically for i.MX FEC controller from day one. And even
> as of today, it doesn't serve PowerPC, because for example the property
> 'phy-mode' documented as required one is not required by PowerPC FEC.
> My opinion would be to patch fsl-fec.txt a little bit to make it clear
> that it's a binding doc for i.MX FEC, and create the other one for
> PowerPC FEC. This is the way less confusing to people and easier for
> binding maintenance.
Should we still try to have a common behaviour where possible?
Such that even if there are two bindings, they don't diverge in
"unnecessary" ways?
But given that we already are past -rc5, I guess the suggested
change is too late for v3.14 anyway. So we have to live with the
fact of a mainline release of different behaviour.
And the backwards compatibility support in the MPC512x CCF
implementation allows to cope with a potential future "ipg"
unification while still working with former "per" using device
trees. There's no blocker. So nevermind.
virtually yours
Gerhard Sittig
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr. 5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office@denx.de
^ permalink raw reply
* RE: [PATCH] net/phy: Add Cortina CS43xx PHY support
From: Shengzhou.Liu @ 2014-03-05 11:09 UTC (permalink / raw)
To: Kumar Gala
Cc: Scott Wood, linuxppc-dev@lists.ozlabs.org, B43619@freescale.com
In-Reply-To: <CFF70C14-23B1-45B9-AD84-C33E32F0B9A3@kernel.crashing.org>
Abandon this patch, in Kernel gen10g_driver can support Cortina PHY, we ne=
ed specific PHY driver just in u-boot.
-Shengzhou
^ permalink raw reply
* Re: [PATCH 0/2] sched: Removed unused mc_capable() and smt_capable()
From: Peter Zijlstra @ 2014-03-05 11:16 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: linux-mips, linux-ia64, x86, linux-kernel, Ingo Molnar,
sparclinux, linuxppc-dev, linux-arm-kernel
In-Reply-To: <20140304210621.16893.8772.stgit@bhelgaas-glaptop.roam.corp.google.com>
On Tue, Mar 04, 2014 at 02:07:31PM -0700, Bjorn Helgaas wrote:
> This is just cleanup of a couple unused interfaces and (for sparc64) a
> supporting variable.
>
Thanks!
^ permalink raw reply
* Re: [PATCh v2 2/2] Corenet: Add QE platform support for Corenet
From: Kumar Gala @ 2014-03-05 17:14 UTC (permalink / raw)
To: Zhao Qiang; +Cc: B07421, R63061, linuxppc-dev
In-Reply-To: <1394004092-4622-2-git-send-email-B45475@freescale.com>
On Mar 5, 2014, at 1:21 AM, Zhao Qiang <B45475@freescale.com> wrote:
> There is QE on platform T104x, add support.
> Call funcs qe_ic_init and qe_init if CONFIG_QUICC_ENGINE is defined.
>=20
> Signed-off-by: Zhao Qiang <B45475@freescale.com>
> ---
> Changes for v2:
> - use mpc85xx_qe_init() instead
> arch/powerpc/platforms/85xx/corenet_generic.c | 25 =
+++++++++++++++++++++++++
> 1 file changed, 25 insertions(+)
>=20
> diff --git a/arch/powerpc/platforms/85xx/corenet_generic.c =
b/arch/powerpc/platforms/85xx/corenet_generic.c
> index fbd871e..f1f4575 100644
> --- a/arch/powerpc/platforms/85xx/corenet_generic.c
> +++ b/arch/powerpc/platforms/85xx/corenet_generic.c
> @@ -26,11 +26,14 @@
> #include <asm/udbg.h>
> #include <asm/mpic.h>
> #include <asm/ehv_pic.h>
> +#include <asm/qe.h>
> +#include <asm/qe_ic.h>
>=20
> #include <linux/of_platform.h>
> #include <sysdev/fsl_soc.h>
> #include <sysdev/fsl_pci.h>
> #include "smp.h"
> +#include "mpc85xx.h"
>=20
> void __init corenet_gen_pic_init(void)
> {
> @@ -38,6 +41,10 @@ void __init corenet_gen_pic_init(void)
> unsigned int flags =3D MPIC_BIG_ENDIAN | MPIC_SINGLE_DEST_CPU |
> MPIC_NO_RESET;
>=20
> +#ifdef CONFIG_QUICC_ENGINE
> + struct device_node *np;
> +#endif
> +
> if (ppc_md.get_irq =3D=3D mpic_get_coreint_irq)
> flags |=3D MPIC_ENABLE_COREINT;
>=20
> @@ -45,6 +52,16 @@ void __init corenet_gen_pic_init(void)
> BUG_ON(mpic =3D=3D NULL);
>=20
> mpic_init(mpic);
> +
> +#ifdef CONFIG_QUICC_ENGINE
> + np =3D of_find_compatible_node(NULL, NULL, "fsl,qe-ic");
> + if (np) {
> + qe_ic_init(np, 0, qe_ic_cascade_low_mpic,
> + qe_ic_cascade_high_mpic);
> + of_node_put(np);
> + }
> +#endif
> +
remove the #ifdef, they aren=92t really needed.
> }
>=20
> /*
> @@ -57,6 +74,11 @@ void __init corenet_gen_setup_arch(void)
> swiotlb_detect_4g();
>=20
> pr_info("%s board from Freescale Semiconductor\n", ppc_md.name);
> +
> +#ifdef CONFIG_QUICC_ENGINE
> + mpc85xx_qe_init();
> +#endif
ifdef not needed
> +
> }
>=20
> static const struct of_device_id of_device_ids[] =3D {
> @@ -81,6 +103,9 @@ static const struct of_device_id of_device_ids[] =3D =
{
> {
> .compatible =3D "fsl,qoriq-pcie-v3.0",
> },
> + {
> + .compatible =3D "fsl,qe",
> + },
> /* The following two are for the Freescale hypervisor */
> {
> .name =3D "hypervisor",
> --=20
> 1.8.5
>=20
^ permalink raw reply
* [PATCH] powerpc/le: fix endianness of the arguments passed to the ppc_rtas() syscall
From: Greg Kurz @ 2014-03-05 17:20 UTC (permalink / raw)
To: benh, paulus; +Cc: linuxppc-dev, anton, linux-kernel
RTAS manipulates its input and output arguments in big endian order.
I have looked at factoring some lines with rtas_call() but it is not really
worth it because of the variable arguments.
Signed-off-by: Greg Kurz <gkurz@linux.vnet.ibm.com>
---
arch/powerpc/kernel/rtas.c | 15 +++++++++++++--
1 file changed, 13 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/kernel/rtas.c b/arch/powerpc/kernel/rtas.c
index 4cf674d..00dbe36 100644
--- a/arch/powerpc/kernel/rtas.c
+++ b/arch/powerpc/kernel/rtas.c
@@ -1020,6 +1020,7 @@ asmlinkage int ppc_rtas(struct rtas_args __user *uargs)
char *buff_copy, *errbuf = NULL;
int nargs;
int rc;
+ int i;
if (!capable(CAP_SYS_ADMIN))
return -EPERM;
@@ -1056,9 +1057,19 @@ asmlinkage int ppc_rtas(struct rtas_args __user *uargs)
flags = lock_rtas();
- rtas.args = args;
+ rtas.args.token = cpu_to_be32(args.token);
+ rtas.args.nargs = cpu_to_be32(args.nargs);
+ rtas.args.nret = cpu_to_be32(args.nret);
+ for (i = 0; i < nargs; ++i)
+ rtas.args.args[i] = cpu_to_be32(args.args[i]);
+ rtas.args.rets = &rtas.args.args[nargs];
+ for (i = 0; i < args.nret; ++i)
+ rtas.args.rets[i] = 0;
+
enter_rtas(__pa(&rtas.args));
- args = rtas.args;
+
+ for (i = 0; i < args.nret; ++i)
+ args.rets[i] = be32_to_cpu(rtas.args.rets[i]);
/* A -1 return code indicates that the last command couldn't
be completed due to a hardware error. */
^ permalink raw reply related
* Re: [PATCH] net/phy: Add Cortina CS43xx PHY support
From: Scott Wood @ 2014-03-05 18:08 UTC (permalink / raw)
To: Liu Shengzhou-B36685; +Cc: linuxppc-dev@lists.ozlabs.org, Cao Yong Hua-B43619
In-Reply-To: <3d2078f16eac4f59aa62e3bfb4e41d6f@DM2PR03MB398.namprd03.prod.outlook.com>
On Wed, 2014-03-05 at 05:09 -0600, Liu Shengzhou-B36685 wrote:
> Abandon this patch, in Kernel gen10g_driver can support Cortina PHY, we need specific PHY driver just in u-boot.
Why shouldn't U-Boot have a generic driver too?
-Scott
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox