* Re: recommended method of netbooting kernel/dtb in u-boot?
From: Kumar Gala @ 2013-04-11 18:12 UTC (permalink / raw)
To: Chris Friesen; +Cc: linuxppc-dev
In-Reply-To: <5166DA49.5000907@genband.com>
On Apr 11, 2013, at 10:44 AM, Chris Friesen wrote:
>=20
> Hi all,
>=20
> We've got a powerpc system that uses u-boot. In our environment on =
bootup u-boot does a DHCP to get networking info, then uses TFTP to get =
the kernel, which then does DHCP again and NFS-mounts the initial root =
filesystem.
>=20
> What's the standard practice for this sort of thing when using device =
tree blobs? Do most people use multi-file images or do they TFTP =
scripts to load and execute separate kernel/dtb files?
>=20
> For multi-part images is there an in-kernel way of generating a file =
containing a kernel and dtb combined? I saw a patch proposed in 2008 to =
add a uImage.<dt> build target but it was shot down because it used the =
legacy multi-file format. Is there an equivalent build target that uses =
the FIT format?
We've normally just done multiple tftp fetches and one grabs dtb and one =
grabs kernel.
- k=
^ permalink raw reply
* Re: [PATCH] net: mv643xx_eth: Add GRO support
From: Sebastian Hesselbarth @ 2013-04-11 18:07 UTC (permalink / raw)
To: Ben Hutchings
Cc: Andrew Lunn, Jason Cooper, linux-kernel, David S. Miller,
Soeren Moch, Paul Mackerras, linux-arm-kernel, Dale Farnsworth,
netdev, linuxppc-dev, Florian Fainelli, Lennert Buytenhek
In-Reply-To: <1365702955.7355.5.camel@bwh-desktop.uk.solarflarecom.com>
On 04/11/2013 07:55 PM, Ben Hutchings wrote:
> On Thu, 2013-04-11 at 14:40 +0200, Sebastian Hesselbarth wrote:
>> This patch adds GRO support to mv643xx_eth by making it invoke
>> napi_gro_receive instead of netif_receive_skb.
>
> The inet_lro support should be removed at the same time; inet_lro is now
> deprecated and there should be no need to keep both of them.
Ben,
I agree on removing it asap, but I also like to see GRO support
in. Maybe, we postpone lro removal just a little bit. I have just
started to look at mv643xx_eth and remember Marvell Orion SoCs are
not the only platform using it. I haven't heard a single word from
ppc guys, yet.
Willy just posted an experimental patch to remove lro. I'll have
a look at it and test it out on Dove.
Sebastian
^ permalink raw reply
* Re: [PATCH] net: mv643xx_eth: Add GRO support
From: Willy Tarreau @ 2013-04-11 18:02 UTC (permalink / raw)
To: Eric Dumazet
Cc: andrew, jason, linux-kernel, florian, smoch, paulus,
linux-arm-kernel, dale, netdev, linuxppc-dev, David Miller,
buytenh, sebastian.hesselbarth
In-Reply-To: <1365703155.3887.184.camel@edumazet-glaptop>
On Thu, Apr 11, 2013 at 10:59:15AM -0700, Eric Dumazet wrote:
> On Thu, 2013-04-11 at 19:51 +0200, Willy Tarreau wrote:
>
> > Eric provided me with one such experimental patch in the past for this
> > driver. It worked for me but we never tried to clean it up to propose
> > it for inclusion.
> >
> > If anyone is interested, I might still have it in experimental shape.
>
> We are interested a lot ;)
Just found it in one of my local branches :-)
Here it is. It was experimental. At first glance, I'm seeing it does not
remove NETIF_F_LRO as we used it for experimentation only, but that's
a trivial thing to fix.
Original work by you Eric, tested by me on 3.6.
diff --git a/drivers/net/ethernet/marvell/mv643xx_eth.c b/drivers/net/ethernet/marvell/mv643xx_eth.c
index ea2cedc..81a6cb0 100644
--- a/drivers/net/ethernet/marvell/mv643xx_eth.c
+++ b/drivers/net/ethernet/marvell/mv643xx_eth.c
@@ -55,9 +55,9 @@
#include <linux/mv643xx_eth.h>
#include <linux/io.h>
#include <linux/types.h>
-#include <linux/inet_lro.h>
#include <linux/slab.h>
#include <linux/clk.h>
+#include <linux/interrupt.h>
static char mv643xx_eth_driver_name[] = "mv643xx_eth";
static char mv643xx_eth_driver_version[] = "1.4";
@@ -343,12 +343,6 @@ struct mib_counters {
u32 rx_overrun;
};
-struct lro_counters {
- u32 lro_aggregated;
- u32 lro_flushed;
- u32 lro_no_desc;
-};
-
struct rx_queue {
int index;
@@ -363,8 +357,6 @@ struct rx_queue {
int rx_desc_area_size;
void **rx_data;
unsigned int frag_size;
- struct net_lro_mgr lro_mgr;
- struct net_lro_desc lro_arr[8];
};
struct tx_queue {
@@ -400,8 +392,6 @@ struct mv643xx_eth_private {
spinlock_t mib_counters_lock;
struct mib_counters mib_counters;
- struct lro_counters lro_counters;
-
struct work_struct tx_timeout_task;
struct napi_struct napi;
@@ -533,33 +523,6 @@ static void txq_maybe_wake(struct tx_queue *txq)
}
-/* rx napi ******************************************************************/
-static int
-mv643xx_get_skb_header(struct sk_buff *skb, void **iphdr, void **tcph,
- u64 *hdr_flags, void *priv)
-{
- unsigned long cmd_sts = (unsigned long)priv;
-
- /*
- * Make sure that this packet is Ethernet II, is not VLAN
- * tagged, is IPv4, has a valid IP header, and is TCP.
- */
- if ((cmd_sts & (RX_IP_HDR_OK | RX_PKT_IS_IPV4 |
- RX_PKT_IS_ETHERNETV2 | RX_PKT_LAYER4_TYPE_MASK |
- RX_PKT_IS_VLAN_TAGGED)) !=
- (RX_IP_HDR_OK | RX_PKT_IS_IPV4 |
- RX_PKT_IS_ETHERNETV2 | RX_PKT_LAYER4_TYPE_TCP_IPV4))
- return -1;
-
- skb_reset_network_header(skb);
- skb_set_transport_header(skb, ip_hdrlen(skb));
- *iphdr = ip_hdr(skb);
- *tcph = tcp_hdr(skb);
- *hdr_flags = LRO_IPV4 | LRO_TCP;
-
- return 0;
-}
-
static void mv_frag_free(const struct rx_queue *rxq, void *data)
{
if (rxq->frag_size)
@@ -568,14 +531,12 @@ static void mv_frag_free(const struct rx_queue *rxq, void *data)
kfree(data);
}
-static int rxq_process(struct rx_queue *rxq, int budget)
+static int rxq_process(struct napi_struct *napi, struct rx_queue *rxq, int budget)
{
struct mv643xx_eth_private *mp = rxq_to_mp(rxq);
struct net_device_stats *stats = &mp->dev->stats;
- int lro_flush_needed;
int rx;
- lro_flush_needed = 0;
rx = 0;
while (rx < budget && rxq->rx_desc_count) {
struct rx_desc *rx_desc;
@@ -646,12 +607,7 @@ static int rxq_process(struct rx_queue *rxq, int budget)
skb->ip_summed = CHECKSUM_UNNECESSARY;
skb->protocol = eth_type_trans(skb, mp->dev);
- if (skb->dev->features & NETIF_F_LRO &&
- skb->ip_summed == CHECKSUM_UNNECESSARY) {
- lro_receive_skb(&rxq->lro_mgr, skb, (void *)cmd_sts);
- lro_flush_needed = 1;
- } else
- netif_receive_skb(skb);
+ napi_gro_receive(napi, skb);
continue;
@@ -671,9 +627,6 @@ err:
dev_kfree_skb(skb);
}
- if (lro_flush_needed)
- lro_flush_all(&rxq->lro_mgr);
-
if (rx < budget)
mp->work_rx &= ~(1 << rxq->index);
@@ -723,7 +676,6 @@ static int rxq_refill(struct rx_queue *rxq, int budget)
rxq->rx_data[rx] = data;
wmb();
rx_desc->cmd_sts = BUFFER_OWNED_BY_DMA | RX_ENABLE_INTERRUPT;
-
}
if (refilled < budget)
@@ -1214,26 +1166,6 @@ static struct net_device_stats *mv643xx_eth_get_stats(struct net_device *dev)
return stats;
}
-static void mv643xx_eth_grab_lro_stats(struct mv643xx_eth_private *mp)
-{
- u32 lro_aggregated = 0;
- u32 lro_flushed = 0;
- u32 lro_no_desc = 0;
- int i;
-
- for (i = 0; i < mp->rxq_count; i++) {
- struct rx_queue *rxq = mp->rxq + i;
-
- lro_aggregated += rxq->lro_mgr.stats.aggregated;
- lro_flushed += rxq->lro_mgr.stats.flushed;
- lro_no_desc += rxq->lro_mgr.stats.no_desc;
- }
-
- mp->lro_counters.lro_aggregated = lro_aggregated;
- mp->lro_counters.lro_flushed = lro_flushed;
- mp->lro_counters.lro_no_desc = lro_no_desc;
-}
-
static inline u32 mib_read(struct mv643xx_eth_private *mp, int offset)
{
return rdl(mp, MIB_COUNTERS(mp->port_num) + offset);
@@ -1397,10 +1329,6 @@ struct mv643xx_eth_stats {
{ #m, FIELD_SIZEOF(struct mib_counters, m), \
-1, offsetof(struct mv643xx_eth_private, mib_counters.m) }
-#define LROSTAT(m) \
- { #m, FIELD_SIZEOF(struct lro_counters, m), \
- -1, offsetof(struct mv643xx_eth_private, lro_counters.m) }
-
static const struct mv643xx_eth_stats mv643xx_eth_stats[] = {
SSTAT(rx_packets),
SSTAT(tx_packets),
@@ -1442,9 +1370,6 @@ static const struct mv643xx_eth_stats mv643xx_eth_stats[] = {
MIBSTAT(late_collision),
MIBSTAT(rx_discard),
MIBSTAT(rx_overrun),
- LROSTAT(lro_aggregated),
- LROSTAT(lro_flushed),
- LROSTAT(lro_no_desc),
};
static int
@@ -1642,7 +1567,6 @@ static void mv643xx_eth_get_ethtool_stats(struct net_device *dev,
mv643xx_eth_get_stats(dev);
mib_counters_update(mp);
- mv643xx_eth_grab_lro_stats(mp);
for (i = 0; i < ARRAY_SIZE(mv643xx_eth_stats); i++) {
const struct mv643xx_eth_stats *stat;
@@ -1915,19 +1839,6 @@ static int rxq_init(struct mv643xx_eth_private *mp, int index)
nexti * sizeof(struct rx_desc);
}
- rxq->lro_mgr.dev = mp->dev;
- memset(&rxq->lro_mgr.stats, 0, sizeof(rxq->lro_mgr.stats));
- rxq->lro_mgr.features = LRO_F_NAPI;
- rxq->lro_mgr.ip_summed = CHECKSUM_UNNECESSARY;
- rxq->lro_mgr.ip_summed_aggr = CHECKSUM_UNNECESSARY;
- rxq->lro_mgr.max_desc = ARRAY_SIZE(rxq->lro_arr);
- rxq->lro_mgr.max_aggr = 32;
- rxq->lro_mgr.frag_align_pad = 0;
- rxq->lro_mgr.lro_arr = rxq->lro_arr;
- rxq->lro_mgr.get_skb_header = mv643xx_get_skb_header;
-
- memset(&rxq->lro_arr, 0, sizeof(rxq->lro_arr));
-
return 0;
@@ -2192,7 +2103,7 @@ static int mv643xx_eth_poll(struct napi_struct *napi, int budget)
work_done += txq_reclaim(mp->txq + queue, work_tbd, 0);
txq_maybe_wake(mp->txq + queue);
} else if (mp->work_rx & queue_mask) {
- work_done += rxq_process(mp->rxq + queue, work_tbd);
+ work_done += rxq_process(napi, mp->rxq + queue, work_tbd);
} else if (!mp->oom && (mp->work_rx_refill & queue_mask)) {
work_done += rxq_refill(mp->rxq + queue, work_tbd);
} else {
Regards,
Willy
^ permalink raw reply related
* Re: [PATCH] net: mv643xx_eth: Add GRO support
From: Ben Hutchings @ 2013-04-11 17:55 UTC (permalink / raw)
To: Sebastian Hesselbarth
Cc: Andrew Lunn, Jason Cooper, linux-kernel, David S. Miller,
Soeren Moch, Paul Mackerras, linux-arm-kernel, Dale Farnsworth,
netdev, linuxppc-dev, Florian Fainelli, Lennert Buytenhek
In-Reply-To: <1365684023-9967-1-git-send-email-sebastian.hesselbarth@gmail.com>
On Thu, 2013-04-11 at 14:40 +0200, Sebastian Hesselbarth wrote:
> This patch adds GRO support to mv643xx_eth by making it invoke
> napi_gro_receive instead of netif_receive_skb.
The inet_lro support should be removed at the same time; inet_lro is now
deprecated and there should be no need to keep both of them.
Ben.
> Signed-off-by: Soeren Moch <smoch@web.de>
> Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
> ---
> Cc: "David S. Miller" <davem@davemloft.net>
> Cc: Lennert Buytenhek <buytenh@wantstofly.org>
> Cc: Andrew Lunn <andrew@lunn.ch>
> Cc: Jason Cooper <jason@lakedaemon.net>
> Cc: Florian Fainelli <florian@openwrt.org>
> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Cc: Paul Mackerras <paulus@samba.org>
> Cc: Dale Farnsworth <dale@farnsworth.org>
> Cc: netdev@vger.kernel.org
> Cc: linux-arm-kernel@lists.infradead.org
> Cc: linuxppc-dev@lists.ozlabs.org
> Cc: linux-kernel@vger.kernel.org
> ---
> drivers/net/ethernet/marvell/mv643xx_eth.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/marvell/mv643xx_eth.c b/drivers/net/ethernet/marvell/mv643xx_eth.c
> index 305038f..c850d04 100644
> --- a/drivers/net/ethernet/marvell/mv643xx_eth.c
> +++ b/drivers/net/ethernet/marvell/mv643xx_eth.c
> @@ -604,7 +604,7 @@ static int rxq_process(struct rx_queue *rxq, int budget)
> lro_receive_skb(&rxq->lro_mgr, skb, (void *)cmd_sts);
> lro_flush_needed = 1;
> } else
> - netif_receive_skb(skb);
> + napi_gro_receive(&mp->napi, skb);
>
> continue;
>
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: [PATCH] net: mv643xx_eth: Add GRO support
From: Eric Dumazet @ 2013-04-11 17:59 UTC (permalink / raw)
To: Willy Tarreau
Cc: andrew, jason, linux-kernel, florian, smoch, paulus,
linux-arm-kernel, dale, netdev, linuxppc-dev, David Miller,
buytenh, sebastian.hesselbarth
In-Reply-To: <20130411175147.GN1910@1wt.eu>
On Thu, 2013-04-11 at 19:51 +0200, Willy Tarreau wrote:
> Eric provided me with one such experimental patch in the past for this
> driver. It worked for me but we never tried to clean it up to propose
> it for inclusion.
>
> If anyone is interested, I might still have it in experimental shape.
We are interested a lot ;)
Thanks !
^ permalink raw reply
* Re: [PATCH] net: mv643xx_eth: Add GRO support
From: Willy Tarreau @ 2013-04-11 17:51 UTC (permalink / raw)
To: David Miller
Cc: andrew, jason, linux-kernel, smoch, paulus, linux-arm-kernel,
dale, netdev, linuxppc-dev, florian, buytenh,
sebastian.hesselbarth
In-Reply-To: <20130411.133119.913809939413807690.davem@davemloft.net>
On Thu, Apr 11, 2013 at 01:31:19PM -0400, David Miller wrote:
> From: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
> Date: Thu, 11 Apr 2013 17:27:03 +0200
>
> > On Thu, Apr 11, 2013 at 5:03 PM, Willy Tarreau <w@1wt.eu> wrote:
> >> On Thu, Apr 11, 2013 at 04:47:49PM +0200, Sebastian Hesselbarth wrote:
> >>> I tried todays net-next on top of 3.9-rc6 without any gro patch, with
> >>> the initial
> >>> patch (Soeren) and your proposed patch (Willy). The results show that
> >>> both patches
> >>> allow a significant increase in throughput compared to
> >>> netif_receive_skb (!gro, !lro)
> >>> alone. Having gro with lro disabled gives some 2% more throughput
> >>> compared to lro only.
> >>
> >> Indeed this is consistent with my memories, since Eric improved the
> >> GRO path, it became faster than LRO on this chip.
> >
> > I don't have a strong opinion on whether Soeren's or your proposal should
> > be submitted. But I insist on having one of them in, as GRO significantly
> > improves the common use case, is enabled by default, and not as
> > constrained as LRO.
>
> I think, as per other drivers, LRO should be eliminated completely from
> all drivers, including this one, and GRO used exclusively instead.
Eric provided me with one such experimental patch in the past for this
driver. It worked for me but we never tried to clean it up to propose
it for inclusion.
If anyone is interested, I might still have it in experimental shape.
Willy
^ permalink raw reply
* Re: [PATCH] net: mv643xx_eth: Add GRO support
From: Eric Dumazet @ 2013-04-11 17:35 UTC (permalink / raw)
To: David Miller
Cc: andrew, jason, linux-kernel, florian, smoch, paulus,
linux-arm-kernel, dale, netdev, linuxppc-dev, w, buytenh,
sebastian.hesselbarth
In-Reply-To: <20130411.133119.913809939413807690.davem@davemloft.net>
On Thu, 2013-04-11 at 13:31 -0400, David Miller wrote:
> I think, as per other drivers, LRO should be eliminated completely from
> all drivers, including this one, and GRO used exclusively instead.
This would be awesome.
AFAIK current LRO users are :
drivers/infiniband/hw/nes/nes_hw.c
drivers/net/ethernet/marvell/mv643xx_eth.c
drivers/net/ethernet/pasemi/pasemi_mac.c
^ permalink raw reply
* Re: [PATCH] net: mv643xx_eth: Add GRO support
From: David Miller @ 2013-04-11 17:31 UTC (permalink / raw)
To: sebastian.hesselbarth
Cc: andrew, jason, linux-kernel, w, smoch, paulus, linux-arm-kernel,
dale, netdev, linuxppc-dev, florian, buytenh
In-Reply-To: <CABJ1b_TRxm97DKJLP_h0VwMJvcYmSpjoJvtg1KvBNGah=VzqMQ@mail.gmail.com>
From: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
Date: Thu, 11 Apr 2013 17:27:03 +0200
> On Thu, Apr 11, 2013 at 5:03 PM, Willy Tarreau <w@1wt.eu> wrote:
>> On Thu, Apr 11, 2013 at 04:47:49PM +0200, Sebastian Hesselbarth wrote:
>>> I tried todays net-next on top of 3.9-rc6 without any gro patch, with
>>> the initial
>>> patch (Soeren) and your proposed patch (Willy). The results show that
>>> both patches
>>> allow a significant increase in throughput compared to
>>> netif_receive_skb (!gro, !lro)
>>> alone. Having gro with lro disabled gives some 2% more throughput
>>> compared to lro only.
>>
>> Indeed this is consistent with my memories, since Eric improved the
>> GRO path, it became faster than LRO on this chip.
>
> I don't have a strong opinion on whether Soeren's or your proposal should
> be submitted. But I insist on having one of them in, as GRO significantly
> improves the common use case, is enabled by default, and not as
> constrained as LRO.
I think, as per other drivers, LRO should be eliminated completely from
all drivers, including this one, and GRO used exclusively instead.
^ permalink raw reply
* Re: [PATCH] net: mv643xx_eth: Add GRO support
From: Willy Tarreau @ 2013-04-11 17:13 UTC (permalink / raw)
To: Sebastian Hesselbarth
Cc: Andrew Lunn, Jason Cooper, linux-kernel, David S. Miller,
Soeren Moch, Paul Mackerras, linux-arm-kernel, Dale Farnsworth,
netdev, linuxppc-dev, Florian Fainelli, Lennert Buytenhek
In-Reply-To: <CABJ1b_QaEJbuBsqx+J1Pkc7o66S_Rboa7Trnko1mXSK6-UZhfg@mail.gmail.com>
On Thu, Apr 11, 2013 at 06:59:11PM +0200, Sebastian Hesselbarth wrote:
> On Thu, Apr 11, 2013 at 5:32 PM, Willy Tarreau <w@1wt.eu> wrote:
> > On Thu, Apr 11, 2013 at 05:27:03PM +0200, Sebastian Hesselbarth wrote:
> >> I don't have a strong opinion on whether Soeren's or your proposal should
> >> be submitted. But I insist on having one of them in, as GRO significantly
> >> improves the common use case, is enabled by default, and not as
> >> constrained as LRO.
> >
> > I agree, use yours first, but we should keep an eye on this. Since you have
> > everything to run a test, please try to see if you can get netperf to run
> > over IPv6, I'm sure the NIC doesn't handle it.
>
> Willy,
>
> out of curiosity I replayed all tests using netperf/netserver with -6 which
> enables ipv6. The overall results remain quite the same here:
> enabling support for GRO gives a huge improvement in achievable
> throughput, and the difference between Soeren's and your patch is
> neglectible.
Perfect, thank you for testing this !
Best regards,
Willy
^ permalink raw reply
* Re: [PATCH] net: mv643xx_eth: Add GRO support
From: Sebastian Hesselbarth @ 2013-04-11 16:59 UTC (permalink / raw)
To: Willy Tarreau
Cc: Andrew Lunn, Jason Cooper, linux-kernel, David S. Miller,
Soeren Moch, Paul Mackerras, linux-arm-kernel, Dale Farnsworth,
netdev, linuxppc-dev, Florian Fainelli, Lennert Buytenhek
In-Reply-To: <20130411153256.GH1910@1wt.eu>
On Thu, Apr 11, 2013 at 5:32 PM, Willy Tarreau <w@1wt.eu> wrote:
> On Thu, Apr 11, 2013 at 05:27:03PM +0200, Sebastian Hesselbarth wrote:
>> I don't have a strong opinion on whether Soeren's or your proposal should
>> be submitted. But I insist on having one of them in, as GRO significantly
>> improves the common use case, is enabled by default, and not as
>> constrained as LRO.
>
> I agree, use yours first, but we should keep an eye on this. Since you have
> everything to run a test, please try to see if you can get netperf to run
> over IPv6, I'm sure the NIC doesn't handle it.
Willy,
out of curiosity I replayed all tests using netperf/netserver with -6 which
enables ipv6. The overall results remain quite the same here:
enabling support for GRO gives a huge improvement in achievable
throughput, and the difference between Soeren's and your patch is
neglectible.
Sebastian
^ permalink raw reply
* Re: [PATCH] net: mv643xx_eth: Add GRO support
From: Eric Dumazet @ 2013-04-11 16:10 UTC (permalink / raw)
To: Willy Tarreau
Cc: Andrew Lunn, Jason Cooper, linux-kernel, David S. Miller,
Soeren Moch, Paul Mackerras, linux-arm-kernel, Dale Farnsworth,
netdev, linuxppc-dev, Florian Fainelli, Lennert Buytenhek,
Sebastian Hesselbarth
In-Reply-To: <20130411160258.GI1910@1wt.eu>
On Thu, 2013-04-11 at 18:02 +0200, Willy Tarreau wrote:
> OK, that makes sense indeed, I didn't think about this case. All
> I remember was that the old call achieved a higher packet rate
> than napi_gro_receive, but it was on an older kernel and I can't
> be more specifics after several months :-/
Its probably true that the GRO handler consumes more cpu for packets
that cant be aggregated in the end.
Thats a trade off, and maybe we could add in the core stack a device
feature to instruct gro handler to do a short cut for packets with no
checksum. Or better a sysctl so that a static_branch can be used.
^ permalink raw reply
* Re: [PATCH] net: mv643xx_eth: Add GRO support
From: Willy Tarreau @ 2013-04-11 16:02 UTC (permalink / raw)
To: Eric Dumazet
Cc: Andrew Lunn, Jason Cooper, linux-kernel, David S. Miller,
Soeren Moch, Paul Mackerras, linux-arm-kernel, Dale Farnsworth,
netdev, linuxppc-dev, Florian Fainelli, Lennert Buytenhek,
Sebastian Hesselbarth
In-Reply-To: <1365695675.3887.165.camel@edumazet-glaptop>
On Thu, Apr 11, 2013 at 08:54:35AM -0700, Eric Dumazet wrote:
> On Thu, 2013-04-11 at 17:32 +0200, Willy Tarreau wrote:
> > On Thu, Apr 11, 2013 at 05:27:03PM +0200, Sebastian Hesselbarth wrote:
> > > I don't have a strong opinion on whether Soeren's or your proposal should
> > > be submitted. But I insist on having one of them in, as GRO significantly
> > > improves the common use case, is enabled by default, and not as
> > > constrained as LRO.
> >
> > I agree, use yours first, but we should keep an eye on this. Since you have
> > everything to run a test, please try to see if you can get netperf to run
> > over IPv6, I'm sure the NIC doesn't handle it.
>
> Willy, testing the checksum in the NIC driver itself prevents the stack
> doing GRO even if the NIC could not checksum the packet, as in GRE
> tunneling for example.
>
> So Sebastien patch is better IMHO : Just call the napi gro handler and
> let core stack handles the details ;)
OK, that makes sense indeed, I didn't think about this case. All
I remember was that the old call achieved a higher packet rate
than napi_gro_receive, but it was on an older kernel and I can't
be more specifics after several months :-/
Cheers,
Willy
^ permalink raw reply
* Re: [PATCH] net: mv643xx_eth: Add GRO support
From: Eric Dumazet @ 2013-04-11 15:54 UTC (permalink / raw)
To: Sebastian Hesselbarth
Cc: Andrew Lunn, Jason Cooper, linux-kernel, David S. Miller,
Soeren Moch, Paul Mackerras, linux-arm-kernel, Dale Farnsworth,
netdev, linuxppc-dev, Florian Fainelli, Lennert Buytenhek
In-Reply-To: <1365684023-9967-1-git-send-email-sebastian.hesselbarth@gmail.com>
On Thu, 2013-04-11 at 14:40 +0200, Sebastian Hesselbarth wrote:
> This patch adds GRO support to mv643xx_eth by making it invoke
> napi_gro_receive instead of netif_receive_skb.
>
> Signed-off-by: Soeren Moch <smoch@web.de>
> Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
> ---
> Cc: "David S. Miller" <davem@davemloft.net>
> Cc: Lennert Buytenhek <buytenh@wantstofly.org>
> Cc: Andrew Lunn <andrew@lunn.ch>
> Cc: Jason Cooper <jason@lakedaemon.net>
> Cc: Florian Fainelli <florian@openwrt.org>
> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Cc: Paul Mackerras <paulus@samba.org>
> Cc: Dale Farnsworth <dale@farnsworth.org>
> Cc: netdev@vger.kernel.org
> Cc: linux-arm-kernel@lists.infradead.org
> Cc: linuxppc-dev@lists.ozlabs.org
> Cc: linux-kernel@vger.kernel.org
> ---
> drivers/net/ethernet/marvell/mv643xx_eth.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/marvell/mv643xx_eth.c b/drivers/net/ethernet/marvell/mv643xx_eth.c
> index 305038f..c850d04 100644
> --- a/drivers/net/ethernet/marvell/mv643xx_eth.c
> +++ b/drivers/net/ethernet/marvell/mv643xx_eth.c
> @@ -604,7 +604,7 @@ static int rxq_process(struct rx_queue *rxq, int budget)
> lro_receive_skb(&rxq->lro_mgr, skb, (void *)cmd_sts);
> lro_flush_needed = 1;
> } else
> - netif_receive_skb(skb);
> + napi_gro_receive(&mp->napi, skb);
>
> continue;
>
Acked-by: Eric Dumazet <edumazet@google.com>
^ permalink raw reply
* Re: [PATCH] net: mv643xx_eth: Add GRO support
From: Eric Dumazet @ 2013-04-11 15:54 UTC (permalink / raw)
To: Willy Tarreau
Cc: Andrew Lunn, Jason Cooper, linux-kernel, David S. Miller,
Soeren Moch, Paul Mackerras, linux-arm-kernel, Dale Farnsworth,
netdev, linuxppc-dev, Florian Fainelli, Lennert Buytenhek,
Sebastian Hesselbarth
In-Reply-To: <20130411153256.GH1910@1wt.eu>
On Thu, 2013-04-11 at 17:32 +0200, Willy Tarreau wrote:
> On Thu, Apr 11, 2013 at 05:27:03PM +0200, Sebastian Hesselbarth wrote:
> > I don't have a strong opinion on whether Soeren's or your proposal should
> > be submitted. But I insist on having one of them in, as GRO significantly
> > improves the common use case, is enabled by default, and not as
> > constrained as LRO.
>
> I agree, use yours first, but we should keep an eye on this. Since you have
> everything to run a test, please try to see if you can get netperf to run
> over IPv6, I'm sure the NIC doesn't handle it.
Willy, testing the checksum in the NIC driver itself prevents the stack
doing GRO even if the NIC could not checksum the packet, as in GRE
tunneling for example.
So Sebastien patch is better IMHO : Just call the napi gro handler and
let core stack handles the details ;)
^ permalink raw reply
* recommended method of netbooting kernel/dtb in u-boot?
From: Chris Friesen @ 2013-04-11 15:44 UTC (permalink / raw)
To: linuxppc-dev
Hi all,
We've got a powerpc system that uses u-boot. In our environment on
bootup u-boot does a DHCP to get networking info, then uses TFTP to get
the kernel, which then does DHCP again and NFS-mounts the initial root
filesystem.
What's the standard practice for this sort of thing when using device
tree blobs? Do most people use multi-file images or do they TFTP
scripts to load and execute separate kernel/dtb files?
For multi-part images is there an in-kernel way of generating a file
containing a kernel and dtb combined? I saw a patch proposed in 2008 to
add a uImage.<dt> build target but it was shot down because it used the
legacy multi-file format. Is there an equivalent build target that uses
the FIT format?
Chris
--
Chris Friesen
Software Designer
500 Palladium Drive, Suite 2100
Ottawa, Ontario K2N 1C2, Canada
www.genband.com
office:+1.343.883.2717
chris.friesen@genband.com
^ permalink raw reply
* Re: [PATCH] net: mv643xx_eth: Add GRO support
From: Willy Tarreau @ 2013-04-11 15:32 UTC (permalink / raw)
To: Sebastian Hesselbarth
Cc: Andrew Lunn, Jason Cooper, linux-kernel, David S. Miller,
Soeren Moch, Paul Mackerras, linux-arm-kernel, Dale Farnsworth,
netdev, linuxppc-dev, Florian Fainelli, Lennert Buytenhek
In-Reply-To: <CABJ1b_TRxm97DKJLP_h0VwMJvcYmSpjoJvtg1KvBNGah=VzqMQ@mail.gmail.com>
On Thu, Apr 11, 2013 at 05:27:03PM +0200, Sebastian Hesselbarth wrote:
> I don't have a strong opinion on whether Soeren's or your proposal should
> be submitted. But I insist on having one of them in, as GRO significantly
> improves the common use case, is enabled by default, and not as
> constrained as LRO.
I agree, use yours first, but we should keep an eye on this. Since you have
everything to run a test, please try to see if you can get netperf to run
over IPv6, I'm sure the NIC doesn't handle it.
Willy
^ permalink raw reply
* Re: [PATCH] net: mv643xx_eth: Add GRO support
From: Sebastian Hesselbarth @ 2013-04-11 15:27 UTC (permalink / raw)
To: Willy Tarreau
Cc: Andrew Lunn, Jason Cooper, linux-kernel, David S. Miller,
Soeren Moch, Paul Mackerras, linux-arm-kernel, Dale Farnsworth,
netdev, linuxppc-dev, Florian Fainelli, Lennert Buytenhek
In-Reply-To: <20130411150326.GA19978@1wt.eu>
On Thu, Apr 11, 2013 at 5:03 PM, Willy Tarreau <w@1wt.eu> wrote:
> On Thu, Apr 11, 2013 at 04:47:49PM +0200, Sebastian Hesselbarth wrote:
>> I tried todays net-next on top of 3.9-rc6 without any gro patch, with
>> the initial
>> patch (Soeren) and your proposed patch (Willy). The results show that
>> both patches
>> allow a significant increase in throughput compared to
>> netif_receive_skb (!gro, !lro)
>> alone. Having gro with lro disabled gives some 2% more throughput
>> compared to lro only.
>
> Indeed this is consistent with my memories, since Eric improved the
> GRO path, it became faster than LRO on this chip.
I don't have a strong opinion on whether Soeren's or your proposal should
be submitted. But I insist on having one of them in, as GRO significantly
improves the common use case, is enabled by default, and not as
constrained as LRO.
Sebastian
^ permalink raw reply
* Re: [PATCH] net: mv643xx_eth: Add GRO support
From: Willy Tarreau @ 2013-04-11 15:03 UTC (permalink / raw)
To: Sebastian Hesselbarth
Cc: Andrew Lunn, Jason Cooper, linux-kernel, David S. Miller,
Soeren Moch, Paul Mackerras, linux-arm-kernel, Dale Farnsworth,
netdev, linuxppc-dev, Florian Fainelli, Lennert Buytenhek
In-Reply-To: <CABJ1b_TQDabT1J7ffo5cb1Th=71bcSduifMJaDpfVRiiHvtWDw@mail.gmail.com>
Hi Sebastian,
On Thu, Apr 11, 2013 at 04:47:49PM +0200, Sebastian Hesselbarth wrote:
> I did some simple tests on Dove/Cubox with 'netperf -cCD' and
> gso/gro/lro options on
> mv643xx_eth. The tests may not be sufficient, as I am not that into
> net performance testing.
In fact the difference only happens when the NIC has not verified the
checksum itself IIRC, which should be for non-IPv4 traffic. I agree
that it's not easy to test a bridge with a cubox which has a single
port :-) Maybe you'll see a difference in IPv6 traffic or with VLAN
traffic, as I seem to remember this chip does not do cksum offloading
on VLANs, but I could be wrong.
> I tried todays net-next on top of 3.9-rc6 without any gro patch, with
> the initial
> patch (Soeren) and your proposed patch (Willy). The results show that
> both patches
> allow a significant increase in throughput compared to
> netif_receive_skb (!gro, !lro)
> alone. Having gro with lro disabled gives some 2% more throughput
> compared to lro only.
Indeed this is consistent with my memories, since Eric improved the
GRO path, it became faster than LRO on this chip.
Regards,
Willy
^ permalink raw reply
* Re: [PATCH] net: mv643xx_eth: Add GRO support
From: Sebastian Hesselbarth @ 2013-04-11 14:47 UTC (permalink / raw)
To: Willy Tarreau
Cc: Andrew Lunn, Jason Cooper, linux-kernel, Florian Fainelli,
Soeren Moch, Paul Mackerras, Lennert Buytenhek, Dale Farnsworth,
netdev, linuxppc-dev, David S. Miller, linux-arm-kernel
In-Reply-To: <20130411131333.GD1910@1wt.eu>
On Thu, Apr 11, 2013 at 3:13 PM, Willy Tarreau <w@1wt.eu> wrote:
> On Thu, Apr 11, 2013 at 02:40:23PM +0200, Sebastian Hesselbarth wrote:
>> This patch adds GRO support to mv643xx_eth by making it invoke
>> napi_gro_receive instead of netif_receive_skb.
>>
>> Signed-off-by: Soeren Moch <smoch@web.de>
>> Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
>> ---
>> Cc: "David S. Miller" <davem@davemloft.net>
>> Cc: Lennert Buytenhek <buytenh@wantstofly.org>
>> Cc: Andrew Lunn <andrew@lunn.ch>
>> Cc: Jason Cooper <jason@lakedaemon.net>
>> Cc: Florian Fainelli <florian@openwrt.org>
>> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
>> Cc: Paul Mackerras <paulus@samba.org>
>> Cc: Dale Farnsworth <dale@farnsworth.org>
>> Cc: netdev@vger.kernel.org
>> Cc: linux-arm-kernel@lists.infradead.org
>> Cc: linuxppc-dev@lists.ozlabs.org
>> Cc: linux-kernel@vger.kernel.org
>> ---
>> drivers/net/ethernet/marvell/mv643xx_eth.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/net/ethernet/marvell/mv643xx_eth.c b/drivers/net/ethernet/marvell/mv643xx_eth.c
>> index 305038f..c850d04 100644
>> --- a/drivers/net/ethernet/marvell/mv643xx_eth.c
>> +++ b/drivers/net/ethernet/marvell/mv643xx_eth.c
>> @@ -604,7 +604,7 @@ static int rxq_process(struct rx_queue *rxq, int budget)
>> lro_receive_skb(&rxq->lro_mgr, skb, (void *)cmd_sts);
>> lro_flush_needed = 1;
>> } else
>> - netif_receive_skb(skb);
>> + napi_gro_receive(&mp->napi, skb);
>>
>> continue;
>
> I remember having experimented with this on 3.6 a few months ago with this
> driver and finally switching back to something like this instead which
> showed better performance on my tests :
>
> if (skb->ip_summed == CHECKSUM_UNNECESSARY)
> napi_gro_receive(napi, skb);
> else
> netif_receive_skb(skb);
>
> Unfortunately I don't have more details as my commit message was rather
> short due to this resulting from experimentation. Did you verify that
> you did not lose any performance in various workloads ? I was playing
> with bridges at this time, it's possible that I got better performance
> on bridging with netif_receive_skb() than with napi_gro_receive().
Hi Willy,
I did some simple tests on Dove/Cubox with 'netperf -cCD' and
gso/gro/lro options on
mv643xx_eth. The tests may not be sufficient, as I am not that into
net performance
testing.
I tried todays net-next on top of 3.9-rc6 without any gro patch, with
the initial
patch (Soeren) and your proposed patch (Willy). The results show that
both patches
allow a significant increase in throughput compared to
netif_receive_skb (!gro, !lro)
alone. Having gro with lro disabled gives some 2% more throughput
compared to lro only.
Sebastian
Recv Send Send Utilization Service Demand
Socket Socket Message Elapsed Send Recv Send Recv
Size Size Size Time Throughput local remote local remote
bytes bytes bytes secs. 10^6bits/s % S % S us/KB us/KB
87380 16384 16384 10.02 615.65 19.15 99.90 5.097
13.293 (3.9-rc6: gso)
87380 16384 16384 10.02 615.82 19.05 99.90 5.067
13.289 (3.9-rc6: gso, gro)
87380 16384 16384 10.03 747.44 23.17 99.80 5.079
10.938 (3.9-rc6: gso, lro)
87380 16384 16384 10.02 745.28 22.57 99.80 4.963
10.970 (3.9.rc6: gso, gro, lro)
87380 16384 16384 10.02 600.34 19.10 99.90 5.211
13.632 (3.9-rc6+soeren: gso)
87380 16384 16384 10.02 764.23 23.42 99.80 5.021
10.698 (3.9-rc6+soeren: gso, gro)
87380 16384 16384 10.02 749.81 23.13 99.80 5.055
10.904 (3.9-rc6+soeren: gso, lro)
87380 16384 16384 10.02 745.84 22.34 99.80 4.907
10.962 (3.9.rc6+soeren: gso, gro, lro)
87380 16384 16384 10.02 605.79 18.79 100.00 5.082
13.523 (3.9-rc6+willy: gso)
87380 16384 16384 10.02 765.64 24.68 99.80 5.281
10.678 (3.9-rc6+willy: gso, gro)
87380 16384 16384 10.02 750.30 26.02 99.80 5.682
10.897 (3.9-rc6+willy: gso, lro)
87380 16384 16384 10.03 749.40 21.86 99.80 4.778
10.910 (3.9.rc6+willy: gso, gro, lro)
^ permalink raw reply
* Re: [PATCH V5] powerpc/85xx: Add machine check handler to fix PCIe erratum on mpc85xx
From: Scott Wood @ 2013-04-11 14:47 UTC (permalink / raw)
To: Jia Hongtao-B38951
Cc: Wood Scott-B07421, linuxppc-dev@lists.ozlabs.org, Li Yang-R58472
In-Reply-To: <412C8208B4A0464FA894C5F0C278CD5D01C35D42@039-SN1MPN1-003.039d.mgd.msft.net>
On 04/11/2013 04:14:51 AM, Jia Hongtao-B38951 wrote:
>=20
>=20
> > -----Original Message-----
> > From: Wood Scott-B07421
> > Sent: Thursday, April 11, 2013 5:52 AM
> > To: Jia Hongtao-B38951
> > Cc: linuxppc-dev@lists.ozlabs.org; galak@kernel.crashing.org; Wood =20
> Scott-
> > B07421; Li Yang-R58472; Jia Hongtao-B38951
> > Subject: Re: [PATCH V5] powerpc/85xx: Add machine check handler to =20
> fix
> > PCIe erratum on mpc85xx
> >
> > The X and (especially for PCI) BRX versions are important -- =20
> probably
> > more so than the U versions. I doubt we need the A variant.
>=20
> Then I will add X and BRX variant and remove A variant.
>=20
> >
> > If you do support the A variant, why are you not sign-extending the
> > value?
>=20
> Just curious, sign-extending the value means fill rd with 0xffffffff?
Or 0xffffffffffffffff on 64-bit (even if you're not going to implement =20
64-bit instructions, the ones you do implement shouldn't misbehave =20
there). You could write it as "regs->gpr[rd] =3D ~0UL".
-Scott=
^ permalink raw reply
* [PATCH] Enable CONFIG_DEVTMPFS_MOUNT to ensure /dev can be mounted correctly
From: Zhenhua Luo @ 2013-04-11 13:56 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Zhenhua Luo
When using recent udev, the /dev node mount requires CONFIG_DEVTMPFS_MOUNT
is enabled in Kernel. The patch enables the option in defconfig of Freescale
QorIQ targets.
Changed defconfig list:
arch/powerpc/configs/85xx/p1023rds_defconfig
arch/powerpc/configs/corenet32_smp_defconfig
arch/powerpc/configs/corenet64_smp_defconfig
arch/powerpc/configs/mpc85xx_smp_defconfig
Signed-off-by: Zhenhua Luo <zhenhua.luo@freescale.com>
---
arch/powerpc/configs/85xx/p1023rds_defconfig | 1 +
arch/powerpc/configs/corenet32_smp_defconfig | 1 +
arch/powerpc/configs/corenet64_smp_defconfig | 1 +
arch/powerpc/configs/mpc85xx_smp_defconfig | 1 +
4 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/configs/85xx/p1023rds_defconfig b/arch/powerpc/configs/85xx/p1023rds_defconfig
index b80bcc6..18badca 100644
--- a/arch/powerpc/configs/85xx/p1023rds_defconfig
+++ b/arch/powerpc/configs/85xx/p1023rds_defconfig
@@ -63,6 +63,7 @@ CONFIG_IPV6=y
CONFIG_IP_SCTP=m
CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug"
CONFIG_DEVTMPFS=y
+CONFIG_DEVTMPFS_MOUNT=y
CONFIG_PROC_DEVICETREE=y
CONFIG_BLK_DEV_LOOP=y
CONFIG_BLK_DEV_RAM=y
diff --git a/arch/powerpc/configs/corenet32_smp_defconfig b/arch/powerpc/configs/corenet32_smp_defconfig
index 60027c2..3dfab4c 100644
--- a/arch/powerpc/configs/corenet32_smp_defconfig
+++ b/arch/powerpc/configs/corenet32_smp_defconfig
@@ -70,6 +70,7 @@ CONFIG_IPV6=y
CONFIG_IP_SCTP=m
CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug"
CONFIG_DEVTMPFS=y
+CONFIG_DEVTMPFS_MOUNT=y
CONFIG_MTD=y
CONFIG_MTD_CMDLINE_PARTS=y
CONFIG_MTD_CHAR=y
diff --git a/arch/powerpc/configs/corenet64_smp_defconfig b/arch/powerpc/configs/corenet64_smp_defconfig
index 3d139fa..914dd3f 100644
--- a/arch/powerpc/configs/corenet64_smp_defconfig
+++ b/arch/powerpc/configs/corenet64_smp_defconfig
@@ -57,6 +57,7 @@ CONFIG_IPV6=y
CONFIG_IP_SCTP=m
CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug"
CONFIG_DEVTMPFS=y
+CONFIG_DEVTMPFS_MOUNT=y
CONFIG_MTD=y
CONFIG_MTD_CMDLINE_PARTS=y
CONFIG_MTD_CHAR=y
diff --git a/arch/powerpc/configs/mpc85xx_smp_defconfig b/arch/powerpc/configs/mpc85xx_smp_defconfig
index 8d00ea5b..d2d5135 100644
--- a/arch/powerpc/configs/mpc85xx_smp_defconfig
+++ b/arch/powerpc/configs/mpc85xx_smp_defconfig
@@ -80,6 +80,7 @@ CONFIG_IPV6=y
CONFIG_IP_SCTP=m
CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug"
CONFIG_DEVTMPFS=y
+CONFIG_DEVTMPFS_MOUNT=y
CONFIG_MTD=y
CONFIG_MTD_CMDLINE_PARTS=y
CONFIG_MTD_CHAR=y
--
1.7.5.4
^ permalink raw reply related
* Re: [PATCH V6] powerpc/85xx: Add machine check handler to fix PCIe erratum on mpc85xx
From: Kumar Gala @ 2013-04-11 13:46 UTC (permalink / raw)
To: Jia Hongtao; +Cc: B07421, linuxppc-dev
In-Reply-To: <1365669382-18534-1-git-send-email-hongtao.jia@freescale.com>
On Apr 11, 2013, at 3:36 AM, Jia Hongtao wrote:
> A PCIe erratum of mpc85xx may causes a core hang when a link of PCIe
> goes down. when the link goes down, Non-posted transactions issued
> via the ATMU requiring completion result in an instruction stall.
> At the same time a machine-check exception is generated to the core
> to allow further processing by the handler. We implements the handler
> which skips the instruction caused the stall.
>=20
> This patch depends on patch:
> powerpc/85xx: Add platform_device declaration to fsl_pci.h
>=20
> Signed-off-by: Zhao Chenhui <b35336@freescale.com>
> Signed-off-by: Li Yang <leoli@freescale.com>
> Signed-off-by: Liu Shuo <soniccat.liu@gmail.com>
> Signed-off-by: Jia Hongtao <hongtao.jia@freescale.com>
> ---
> V5:
> * Move OP and XOP defines to a new header file: asm/ppc-disassemble.h
> * Add X UX BRX variant of load instruction emulation
> * Remove A variant of load instruction emulation
>=20
> V4:
> * Fill rd with all-Fs if the skipped instruction is load and emulate =
the
> instruction.
> * Let KVM/QEMU deal with the exception if the machine check comes from =
KVM.
>=20
> arch/powerpc/include/asm/ppc-disassemble.h | 31 +++++++
> arch/powerpc/kernel/cpu_setup_fsl_booke.S | 2 +-
> arch/powerpc/kernel/traps.c | 3 +
> arch/powerpc/sysdev/fsl_pci.c | 140 =
+++++++++++++++++++++++++++++
> arch/powerpc/sysdev/fsl_pci.h | 6 ++
> 5 files changed, 181 insertions(+), 1 deletion(-)
> create mode 100644 arch/powerpc/include/asm/ppc-disassemble.h
>=20
> diff --git a/arch/powerpc/include/asm/ppc-disassemble.h =
b/arch/powerpc/include/asm/ppc-disassemble.h
> new file mode 100644
> index 0000000..f9782b8
> --- /dev/null
> +++ b/arch/powerpc/include/asm/ppc-disassemble.h
> @@ -0,0 +1,31 @@
> +/*
> + * Copyright 2012-2013 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.
> + *
> + * provides opcode and xopcode images for use by emulating
> + * instructions
> + */
> +#ifndef _ASM_POWERPC_PPC_DISASSEMBLE_H
> +#define _ASM_POWERPC_PPC_DISASSEMBLE_H
> +
This should really just be in asm/ppc-opcode.h
> +#define OP_LWZ 32
> +#define OP_LWZU 33
> +#define OP_LBZ 34
> +#define OP_LBZU 35
> +#define OP_LHZ 40
> +#define OP_LHZU 41
> +
> +#define OP_31_XOP_LWZX 23
> +#define OP_31_XOP_LWZUX 55
> +#define OP_31_XOP_LBZX 87
> +#define OP_31_XOP_LBZUX 119
> +#define OP_31_XOP_LHZX 279
> +#define OP_31_XOP_LHZUX 311
> +#define OP_31_XOP_LWBRX 534
> +#define OP_31_XOP_LHBRX 790
> +
Also, submit a patch to extract these from existing code so we stop =
duplicating them everywhere.
> +#endif
> diff --git a/arch/powerpc/kernel/cpu_setup_fsl_booke.S =
b/arch/powerpc/kernel/cpu_setup_fsl_booke.S
> index dcd8819..f1bde90 100644
> --- a/arch/powerpc/kernel/cpu_setup_fsl_booke.S
> +++ b/arch/powerpc/kernel/cpu_setup_fsl_booke.S
> @@ -66,7 +66,7 @@ _GLOBAL(__setup_cpu_e500v2)
> bl __e500_icache_setup
> bl __e500_dcache_setup
> bl __setup_e500_ivors
> -#ifdef CONFIG_FSL_RIO
> +#if defined(CONFIG_FSL_RIO) || defined(CONFIG_FSL_PCI)
> /* Ensure that RFXE is set */
> mfspr r3,SPRN_HID1
> oris r3,r3,HID1_RFXE@h
> diff --git a/arch/powerpc/kernel/traps.c b/arch/powerpc/kernel/traps.c
> index a008cf5..dd275a4 100644
> --- a/arch/powerpc/kernel/traps.c
> +++ b/arch/powerpc/kernel/traps.c
> @@ -59,6 +59,7 @@
> #include <asm/fadump.h>
> #include <asm/switch_to.h>
> #include <asm/debug.h>
> +#include <sysdev/fsl_pci.h>
>=20
> #if defined(CONFIG_DEBUGGER) || defined(CONFIG_KEXEC)
> int (*__debugger)(struct pt_regs *regs) __read_mostly;
> @@ -556,6 +557,8 @@ int machine_check_e500(struct pt_regs *regs)
> if (reason & MCSR_BUS_RBERR) {
> if (fsl_rio_mcheck_exception(regs))
> return 1;
> + if (fsl_pci_mcheck_exception(regs))
> + return 1;
> }
>=20
> printk("Machine check in kernel mode.\n");
> diff --git a/arch/powerpc/sysdev/fsl_pci.c =
b/arch/powerpc/sysdev/fsl_pci.c
> index 682084d..aaa54c5 100644
> --- a/arch/powerpc/sysdev/fsl_pci.c
> +++ b/arch/powerpc/sysdev/fsl_pci.c
> @@ -26,11 +26,15 @@
> #include <linux/memblock.h>
> #include <linux/log2.h>
> #include <linux/slab.h>
> +#include <linux/uaccess.h>
>=20
> #include <asm/io.h>
> #include <asm/prom.h>
> #include <asm/pci-bridge.h>
> +#include <asm/ppc-pci.h>
what are you pulling in from ppc-pci.h?
> #include <asm/machdep.h>
> +#include <asm/disassemble.h>
> +#include <asm/ppc-disassemble.h>
> #include <sysdev/fsl_soc.h>
> #include <sysdev/fsl_pci.h>
>=20
> @@ -826,6 +830,142 @@ u64 fsl_pci_immrbar_base(struct pci_controller =
*hose)
> return 0;
> }
>=20
> +#ifdef CONFIG_E500
> +static int mcheck_handle_load(struct pt_regs *regs, u32 inst)
> +{
> + unsigned int rd, ra, rb, d;
> +
> + rd =3D get_rt(inst);
> + ra =3D get_ra(inst);
> + rb =3D get_rb(inst);
> + d =3D get_d(inst);
> +
> + switch (get_op(inst)) {
> + case 31:
What about 64-bit loads (LD...)?
> + switch (get_xop(inst)) {
> + case OP_31_XOP_LWZX:
> + case OP_31_XOP_LWBRX:
> + regs->gpr[rd] =3D 0xffffffff;
> + break;
> +
> + case OP_31_XOP_LWZUX:
> + regs->gpr[rd] =3D 0xffffffff;
> + regs->gpr[ra] +=3D regs->gpr[rb];
> + break;
> +
> + case OP_31_XOP_LBZX:
> + regs->gpr[rd] =3D 0xff;
> + break;
> +
> + case OP_31_XOP_LBZUX:
> + regs->gpr[rd] =3D 0xff;
> + regs->gpr[ra] +=3D regs->gpr[rb];
> + break;
> +
> + case OP_31_XOP_LHZX:
> + case OP_31_XOP_LHBRX:
> + regs->gpr[rd] =3D 0xffff;
> + break;
> +
> + case OP_31_XOP_LHZUX:
> + regs->gpr[rd] =3D 0xffff;
> + regs->gpr[ra] +=3D regs->gpr[rb];
> + break;
> +
> + default:
> + return 0;
> + }
> + break;
> +
> + case OP_LWZ:
> + regs->gpr[rd] =3D 0xffffffff;
> + break;
> +
> + case OP_LWZU:
> + regs->gpr[rd] =3D 0xffffffff;
> + regs->gpr[ra] +=3D (s16)d;
> + break;
> +
> + case OP_LBZ:
> + regs->gpr[rd] =3D 0xff;
> + break;
> +
> + case OP_LBZU:
> + regs->gpr[rd] =3D 0xff;
> + regs->gpr[ra] +=3D (s16)d;
> + break;
> +
> + case OP_LHZ:
> + regs->gpr[rd] =3D 0xffff;
> + break;
> +
> + case OP_LHZU:
> + regs->gpr[rd] =3D 0xffff;
> + regs->gpr[ra] +=3D (s16)d;
> + break;
> +
> + default:
> + return 0;
> + }
> +
> + return 1;
> +}
> +
> +static int is_in_pci_mem_space(phys_addr_t addr)
> +{
> + struct pci_controller *hose;
> + struct resource *res;
> + int i;
> +
> + list_for_each_entry(hose, &hose_list, list_node) {
> + if (!early_find_capability(hose, 0, 0, PCI_CAP_ID_EXP))
> + continue;
> +
> + for (i =3D 0; i < 3; i++) {
> + res =3D &hose->mem_resources[i];
> + if ((res->flags & IORESOURCE_MEM) &&
> + addr >=3D res->start && addr <=3D =
res->end)
> + return 1;
> + }
> + }
> + return 0;
> +}
> +
> +int fsl_pci_mcheck_exception(struct pt_regs *regs)
> +{
> + u32 inst;
> + int ret;
> + phys_addr_t addr =3D 0;
> +
> + /* Let KVM/QEMU deal with the exception */
> + if (regs->msr & MSR_GS)
> + return 0;
> +
> +#ifdef CONFIG_PHYS_64BIT
> + addr =3D mfspr(SPRN_MCARU);
> + addr <<=3D 32;
> +#endif
> + addr +=3D mfspr(SPRN_MCAR);
> +
> + if (is_in_pci_mem_space(addr)) {
> + if (user_mode(regs)) {
> + pagefault_disable();
> + ret =3D get_user(regs->nip, &inst);
> + pagefault_enable();
> + } else {
> + ret =3D probe_kernel_address(regs->nip, inst);
> + }
> +
> + if (mcheck_handle_load(regs, inst)) {
> + regs->nip +=3D 4;
> + return 1;
> + }
> + }
> +
> + return 0;
> +}
> +#endif
> +
> #if defined(CONFIG_FSL_SOC_BOOKE) || defined(CONFIG_PPC_86xx)
> static const struct of_device_id pci_ids[] =3D {
> { .compatible =3D "fsl,mpc8540-pci", },
> diff --git a/arch/powerpc/sysdev/fsl_pci.h =
b/arch/powerpc/sysdev/fsl_pci.h
> index 851dd56..b0d01ea 100644
> --- a/arch/powerpc/sysdev/fsl_pci.h
> +++ b/arch/powerpc/sysdev/fsl_pci.h
> @@ -115,5 +115,11 @@ static inline int mpc85xx_pci_err_probe(struct =
platform_device *op)
> }
> #endif
>=20
> +#ifdef CONFIG_FSL_PCI
> +extern int fsl_pci_mcheck_exception(struct pt_regs *);
> +#else
> +static inline int fsl_pci_mcheck_exception(struct pt_regs *regs) =
{return 0; }
> +#endif
> +
> #endif /* __POWERPC_FSL_PCI_H */
> #endif /* __KERNEL__ */
> --=20
> 1.8.0
>=20
^ permalink raw reply
* Re: [PATCH] powerpc/85xx: Fix MPC8536DS 36-bit device tree
From: Kumar Gala @ 2013-04-11 13:34 UTC (permalink / raw)
To: Kim Phillips; +Cc: linuxppc-dev
In-Reply-To: <20130410165828.ec0378afc7e7f17e8e47850e@freescale.com>
On Apr 10, 2013, at 4:58 PM, Kim Phillips wrote:
> From: Kumar Gala <galak@kernel.crashing.org>
>
> The localbus node should be in at 0xfffe05000 not 0xffe05000. Also
> fixed the names of the localbus and pci nodes to reflect the addresses
> they are actually at.
>
> Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
> Signed-off-by: Kim Phillips <kim.phillips@freescale.com>
> ---
> note: this upstream submission extended to fix pci1.
>
> arch/powerpc/boot/dts/mpc8536ds_36b.dts | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
applied to next
- k
^ permalink raw reply
* Re: [PATCH] powerpc/85xx: enable Silicon image 3132 PCIe to SATA controller
From: Kumar Gala @ 2013-04-11 13:34 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <1365633649-27046-1-git-send-email-scottwood@freescale.com>
On Apr 10, 2013, at 5:40 PM, Scott Wood wrote:
> From: Roy ZANG <tie-fei.zang@freescale.com>
>
> Some 85xx board, for example, P1020RDB-PC has on board silicon image
> PCIe to SATA controller and when booting up, the filesystem will auto mount
> to the SATA disk. So enable silicon image 3132 pcie to sata controller
> by default
>
> Signed-off-by: Roy Zang <tie-fei.zang@freescale.com>
> Signed-off-by: Scott Wood <scottwood@freescale.com>
> ---
> arch/powerpc/configs/mpc85xx_defconfig | 1 +
> arch/powerpc/configs/mpc85xx_smp_defconfig | 1 +
> 2 files changed, 2 insertions(+)
applied to next
- k
^ permalink raw reply
* Re: [PATCHv2] powerpc/crypto: Add property for 'era' in SEC dts crypto node
From: Kumar Gala @ 2013-04-11 13:34 UTC (permalink / raw)
To: Vakul Garg
Cc: Shaveta Leekha, linux-kernel, Andy Fleming, Paul Mackerras,
linuxppc-dev
In-Reply-To: <1365651923-24017-1-git-send-email-vakul@freescale.com>
On Apr 10, 2013, at 10:45 PM, Vakul Garg wrote:
> The crypto node now contains a new property 'fsl,sec-era'.
> This is required so that applications can retrieve era info without
> having to be able to read SEC's register space.
>
> Signed-off-by: Vakul Garg <vakul@freescale.com>
> ---
> Changelog:
>
> v2: Added era in p1023si-post.dtsi as per Kim's comments.
>
> arch/powerpc/boot/dts/fsl/p1023si-post.dtsi | 1 +
> arch/powerpc/boot/dts/fsl/pq3-sec4.4-0.dtsi | 1 +
> arch/powerpc/boot/dts/fsl/qoriq-sec4.0-0.dtsi | 1 +
> arch/powerpc/boot/dts/fsl/qoriq-sec4.2-0.dtsi | 1 +
> arch/powerpc/boot/dts/fsl/qoriq-sec5.0-0.dtsi | 1 +
> arch/powerpc/boot/dts/fsl/qoriq-sec5.2-0.dtsi | 1 +
> arch/powerpc/boot/dts/fsl/qoriq-sec5.3-0.dtsi | 1 +
> 7 files changed, 7 insertions(+), 0 deletions(-)
applied to next
- k
^ 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