* Re: [RFC][PATCH 6/8] Walnut DTS
From: Segher Boessenkool @ 2007-07-19 16:54 UTC (permalink / raw)
To: Scott Wood; +Cc: Yoder Stuart-B08248, linuxppc-dev
In-Reply-To: <469E4432.5050900@freescale.com>
>> Yes indeed. The problem with your suggested "obvious way"
>
> I said it was obvious, not obviously correct. :-)
I know :-)
>> is that you wouldn't get a unit address included if your
>> interrupt-map points (for some entry) at your device tree
>> parent, either. Not all that hypothetical.
>
> Ah, good point. My inclination would be to, rather than check how
> we got to the node, check whether it's the device's parent. If
> not, then the presence of #address-cells (other than zero for
> compatibility) is an error. Otherwise, #address-cells is used, and
> defaults are handled the same as with reg/ranges translation.
This might work; it is less flexible than the actual interrupt
mapping definition though (and such flexibility is good, as long
as you don't abuse it ;-) ). Anyway, we're stuck with the actual
current imap recommended practice. It might not be perfect but
it does work, is proven in the field, and is the standard.
Segher
^ permalink raw reply
* Re: [PATCH 1/2] Fix error checking in Vitesse IRQ config
From: Jon Loeliger @ 2007-07-19 16:49 UTC (permalink / raw)
To: Andy Fleming; +Cc: netdev, linuxppc-dev@ozlabs.org
In-Reply-To: <11847405503115-git-send-email-afleming@freescale.com>
On Wed, 2007-07-18 at 01:35, Andy Fleming wrote:
> phy_read() returns a negative number if there's an error, but the
> error-checking code in the Vitesse driver's config_intr function
> triggers if phy_read() returns non-zero. Correct that.
>
> Signed-off-by: Andy Fleming <afleming@freescale.com>
> ---
> I made a really stupid mistake in the 4 patches I sent out, earlier. I
> thought those patches had been tested, but they hadn't been. This one
> corrects a tiny error in the patch, and they have now been tested. As before
> this change can be pulled from:
>
> http://opensource.freescale.com/pub/scm/linux-2.6-85xx.git netdev
>
> Really, REALLY sorry about that. I have been given a paper bag of appropriate
> size and shape to fit over my head.
>
> drivers/net/phy/vitesse.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/net/phy/vitesse.c b/drivers/net/phy/vitesse.c
> index 6a53856..8874497 100644
Acked-by: Jon Loeliger <jdl@freescale.com>
Tested on the 8641HPCN.
Thanks,
jdl
^ permalink raw reply
* Re: [PATCH] Treat ISI faults as read faults on classic 32-bit PowerPC
From: Jon Loeliger @ 2007-07-19 16:44 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev@ozlabs.org, Johannes Berg
In-Reply-To: <18078.43412.493174.590540@cargo.ozlabs.ibm.com>
On Wed, 2007-07-18 at 19:00, Paul Mackerras wrote:
> Hmmm. The dangling else clauses are pretty gross, and in fact we have
> the same problem on POWER3 and RS64 processors (to be fair, we had
> the problem before and didn't notice, but we should still fix it).
>
> How about this instead? Could people test it please? (Note that
> CPU_FTR_NOEXECUTE is 0 in 32-bit kernels.)
>
> Paul.
>
> diff --git a/arch/powerpc/mm/fault.c b/arch/powerpc/mm/fault.c
> index 0ece513..99c3093 100644
> --- a/arch/powerpc/mm/fault.c
> +++ b/arch/powerpc/mm/fault.c
Acked-by: Jon Loeliger <jdl@freescale.com>
Tested on 8641HPCN.
Thanks,
jdl
^ permalink raw reply
* Re: [2/2] 2.6.22-git: known regressions
From: Greg KH @ 2007-07-19 16:26 UTC (permalink / raw)
To: Michal Piotrowski
Cc: Andi Kleen, Theodore Tso, Bartlomiej Zolnierkiewicz, Jeff Garzik,
linuxppc-dev, LKML, Doug Chapman, Vasily Tarasov, linux-ide,
Tejun Heo, Mingming Cao, linux-fsdevel, Andrew Morton,
Jean Delvare, Linus Torvalds, Christoph Lameter
In-Reply-To: <469F92AF.10405@googlemail.com>
On Thu, Jul 19, 2007 at 06:34:55PM +0200, Michal Piotrowski wrote:
> SYSFS
>
> Subject : sysfs root link count broken in 2.6.22-git5
> References : http://lkml.org/lkml/2007/7/15/62
> Last known good : ?
> Submitter : Jean Delvare <khali@linux-fr.org>
> Caused-By : ?
> Handled-By : Tejun Heo <htejun@gmail.com>
> Status : unknown
This is now fixed in Linus's tree with a patch from Tejun.
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH 53/61] 82xx: Set NOT_COHERENT_CACHE on 8272 with PCI.
From: Scott Wood @ 2007-07-19 16:36 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, David Gibson
In-Reply-To: <97B4A805-6E2A-4F8E-BC56-5BDEE8D6F5F0@kernel.crashing.org>
Kumar Gala wrote:
> Can you dump the POCMRx registers and report their values and what /
> proc/iomem looks like.
POTAR0: 0x00080000
POTAR1: 0x000a0000
POTAR2: 0x00000000
POBAR0: 0x00080000
POBAR1: 0x000a0000
POBAR2: 0x000f6000
POCMR0: 0xa00e0000
POCMR1: 0x800e0000
POCMR2: 0xc00fe000
PITAR0: 0x00000000
PIBAR0: 0x00000000
PICMR0: 0xa00fc000
-sh-2.05b# cat /proc/iomem
80000000-9fffffff : /soc@f0000000/pci@10800
a0000000-bfffffff : /soc@f0000000/pci@10800
a0000000-a001ffff : 0000:00:17.0
a0000000-a001ffff : e1000
a0020000-a003ffff : 0000:00:17.0
a0020000-a003ffff : e1000
-Scott
^ permalink raw reply
* Re: [2/2] 2.6.22-git: known regressions
From: Michal Piotrowski @ 2007-07-19 16:34 UTC (permalink / raw)
To: Linus Torvalds
Cc: Andi Kleen, Theodore Tso, Bartlomiej Zolnierkiewicz, Jeff Garzik,
linuxppc-dev, Greg Kroah-Hartman, LKML, Doug Chapman,
Vasily Tarasov, linux-ide, Tejun Heo, Mingming Cao, linux-fsdevel,
Andrew Morton, Jean Delvare, Christoph Lameter
In-Reply-To: <469F9125.8040502@googlemail.com>
Hi all,
Here is a list of some known regressions in 2.6.22-git.
Feel free to add new regressions/remove fixed etc.
http://kernelnewbies.org/known_regressions
List of Aces
Name Regressions fixed since 21-Jun-2007
Adrian Bunk 3
Andi Kleen 2
Andrew Morton 2
David Woodhouse 2
Hugh Dickins 2
Jens Axboe 2
FS
Subject : ia64 build failure from recent diskquota patch
References : http://lkml.org/lkml/2007/7/18/407
Last known good : ?
Submitter : Doug Chapman <doug.chapman@hp.com>
Caused-By : Vasily Tarasov <vtaras@openvz.org>
commit b716395e2b8e450e294537de0c91476ded2f0395
Handled-By : ?
Status : unknown
Subject : ext4 build warnings
References : http://lkml.org/lkml/2007/7/18/420
Last known good : ?
Submitter : Jeff Garzik <jeff@garzik.org>
Caused-By : ?
Handled-By : Mingming Cao <cmm@us.ibm.com>
Status : unknown
IDE
Subject : compile error if CONFIG_BLOCK not enabled related to linux/ide.h include
References : http://lkml.org/lkml/2007/7/18/11
Last known good : ?
Submitter : Kumar Gala <galak@kernel.crashing.org>
Caused-By : ?
Handled-By : Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Status : unknown
Memory management
Subject : kmalloc zero size changes break i386
References : http://lkml.org/lkml/2007/7/19/172
Last known good : ?
Submitter : Andi Kleen <ak@suse.de>
Caused-By : Christoph Lameter <clameter@sgi.com>
commit 6cb8f91320d3e720351c21741da795fed580b21b
Handled-By : ?
Status : unknown
SYSFS
Subject : sysfs root link count broken in 2.6.22-git5
References : http://lkml.org/lkml/2007/7/15/62
Last known good : ?
Submitter : Jean Delvare <khali@linux-fr.org>
Caused-By : ?
Handled-By : Tejun Heo <htejun@gmail.com>
Status : unknown
Regards,
Michal
--
LOG
http://www.stardust.webpages.pl/log/
^ permalink raw reply
* Re: [PATCH] Add StorCenter DTS first draft.
From: Jon Loeliger @ 2007-07-19 16:05 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev@ozlabs.org, Jon Loeliger
In-Reply-To: <1184795678.25235.269.camel@localhost.localdomain>
On Wed, 2007-07-18 at 16:54, Benjamin Herrenschmidt wrote:
> Cache line size is used by the kernel on ppc64 for things like clearing
> memory (to get the stride between subsequent dcbz) or flushing the
> cache :-) It's also passed on to userland.
>
> If it's absent from the device-tree, we default to the values in the
> cputable, but if you're going to put the properties in the tree, don't
> put a 0 in there. As it is, the day I make the 64 bits code common, your
> DT will break unless I special case "0".
>
> Ben.
So, just to put this issue to rest some, I have
modified my DTS to have correct values here.
It was _easy_. ;-)
But, a followup patch should clean up _other_, existing
DTS files that have 0 there still.
jdl
^ permalink raw reply
* Re: [PATCH 03/12] Consolidate of_device_is_compatible
From: Stephen Rothwell @ 2007-07-19 16:02 UTC (permalink / raw)
To: Scott Wood; +Cc: sparclinux, ppc-dev, paulus, David S. Miller, wli
In-Reply-To: <20070719155207.GA28617@ld0162-tx32.am.freescale.net>
[-- Attachment #1: Type: text/plain, Size: 898 bytes --]
Hi Scott,
On Thu, 19 Jul 2007 10:52:07 -0500 Scott Wood <scottwood@freescale.com> wrote:
>
> On Fri, Jul 20, 2007 at 01:10:12AM +1000, Stephen Rothwell wrote:
> > The only difference here is that Sparc uses strncmp to match compatibility
> > names while PowerPC uses strncasecmp.
>
> Could we put a comment in saying that both should really just use
> strcmp(), and that this mechanism should go away once any compatibility
> issues are found and addressed?
That issue was discussed earlier and is high on the list of things to do
after this lot goes in. The priority here is to get the consolidation
started along with no (or few) visible changes.
> The PowerPC one will need to drop the 'n' soon, as well, but that should
> be a separate patch.
Yes, certainly.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Do we need to reset the master branch?
From: Mark A. Greer @ 2007-07-19 15:58 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <20070720014618.a6eec3eb.sfr@canb.auug.org.au>
On Fri, Jul 20, 2007 at 01:46:18AM +1000, Stephen Rothwell wrote:
> On Fri, 20 Jul 2007 01:44:32 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> > git remote add powerpc git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git
> > git fetch powerpc
> >
> > This will track the tree in branches called powerpc/<branch> and do
> > resets as necessary.
>
> You should not make any local commits to the powerpc/* branches, of course.
Right.
^ permalink raw reply
* Re: Do we need to reset the master branch?
From: Mark A. Greer @ 2007-07-19 15:58 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <20070720014432.a46164a8.sfr@canb.auug.org.au>
On Fri, Jul 20, 2007 at 01:44:32AM +1000, Stephen Rothwell wrote:
> On Thu, 19 Jul 2007 08:32:17 -0700 "Mark A. Greer" <mgreer@mvista.com> wrote:
> >
> > I was in the master branch of powerpc.git and did a 'git-pull'
>
> Sorry, I hadn't updated since this afternoon. Looks like Paul has reset
> his master tree to be the same as Linus', so you do need to do a reset.
> Or checkout a separate branch and use
>
> git fetch -f <powerpc.git tree> master:<whatever branch tracks master>
>
> Using recent git (after 1.5.something), you can track the whole powerpc
> tree like this:
>
> git remote add powerpc git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git
> git fetch powerpc
>
> This will track the tree in branches called powerpc/<branch> and do
> resets as necessary.
Oh, that's cool Thanks Stephen.
Mark
^ permalink raw reply
* [PATCH] powerpc: Allow smp_call_function_single() to current cpu
From: Avi Kivity @ 2007-07-19 15:33 UTC (permalink / raw)
To: paulus; +Cc: kvm-devel, linuxppc-dev, linux-kernel, Avi Kivity
This removes the requirement for callers to get_cpu() to check in simple
cases. i386 and x86_64 already received a similar treatment.
Signed-off-by: Avi Kivity <avi@qumranet.com>
---
arch/powerpc/kernel/smp.c | 7 ++++++-
1 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/kernel/smp.c b/arch/powerpc/kernel/smp.c
index d577b71..087c92f 100644
--- a/arch/powerpc/kernel/smp.c
+++ b/arch/powerpc/kernel/smp.c
@@ -284,7 +284,7 @@ int smp_call_function_single(int cpu, void (*func) (void *info), void *info, int
int wait)
{
cpumask_t map = CPU_MASK_NONE;
- int ret = -EBUSY;
+ int ret = 0;
if (!cpu_online(cpu))
return -EINVAL;
@@ -292,6 +292,11 @@ int smp_call_function_single(int cpu, void (*func) (void *info), void *info, int
cpu_set(cpu, map);
if (cpu != get_cpu())
ret = smp_call_function_map(func,info,nonatomic,wait,map);
+ else {
+ local_irq_disable();
+ func(info);
+ local_irq_enable();
+ }
put_cpu();
return ret;
}
--
1.5.2.4
^ permalink raw reply related
* Re: [PATCH 03/12] Consolidate of_device_is_compatible
From: Scott Wood @ 2007-07-19 15:52 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: sparclinux, ppc-dev, paulus, David S. Miller, wli
In-Reply-To: <20070720011012.4eca281d.sfr@canb.auug.org.au>
On Fri, Jul 20, 2007 at 01:10:12AM +1000, Stephen Rothwell wrote:
> The only difference here is that Sparc uses strncmp to match compatibility
> names while PowerPC uses strncasecmp.
Could we put a comment in saying that both should really just use
strcmp(), and that this mechanism should go away once any compatibility
issues are found and addressed?
The PowerPC one will need to drop the 'n' soon, as well, but that should
be a separate patch.
-Scott
^ permalink raw reply
* Re: [PATCH] Add 8548CDS with Arcadia 3.0 support
From: Segher Boessenkool @ 2007-07-19 15:51 UTC (permalink / raw)
To: Zang Roy-r61911; +Cc: linuxppc-dev list, Paul Mackerras
In-Reply-To: <1184750539.27603.7.camel@localhost.localdomain>
> + compatible = "MPC8548CDS", "MPC85xxCDS";
No new "xx" please.
> + memory {
> + device_type = "memory";
> + reg = <00000000 08000000>; // 128M at 0x0
memory@0. Simplified rule: whenever there is a "reg",
there is an "@".
> + soc8548@e0000000 {
soc@e0000000
> + #address-cells = <1>;
> + #size-cells = <1>;
> + device_type = "soc";
No "device_type". Missing "compatible".
> + ranges = <0 e0000000 00100000>;
> + reg = <e0000000 00100000>; // CCSRBAR 1M
"reg" and "ranges" overlap, that can't be right.
> + i2c@3000 {
> + device_type = "i2c";
> + compatible = "fsl-i2c";
Please put a more exact "compatible" entry in there. If
you need to keep "fsl-i2c" as well, for backwards compatibility
reasons, that's fine; but do put a better name in.
> + dfsrr;
This wins the prize for worst-name property ever! :-)
> + serial@4500 {
> + device_type = "serial";
> + compatible = "ns16550";
> + reg = <4500 100>; // reg base, size
I wonder how it can be NS16550-compatible if its register
bank is a completely different size.
> + pci1: pci@8000 {
> + interrupt-map-mask = <f800 0 0 7>;
> + interrupt-map = <
> +
> + /* IDSEL 0x2 (PCIX Tsi310 bridge) */
> + 1000 0 0 1 &mpic 0 1
> + 1000 0 0 2 &mpic 1 1
> + 1000 0 0 3 &mpic 2 1
> + 1000 0 0 4 &mpic 3 1
You map all dev#s' interrupts identically, you could just do
interrupt-map-mask = <0 0 0 7>
and do one set of four mappings in the interrupt-map, with the
device number field set to 0.
The mask exists to not have to write out lots of huge tables :-)
> + pci@9000 {
> + interrupt-map-mask = <f800 0 0 7>;
> + interrupt-map = <
> +
> + /* IDSEL 0x15 */
> + a800 0 0 1 &mpic b 1
> + a800 0 0 2 &mpic b 1
> + a800 0 0 3 &mpic b 1
> + a800 0 0 4 &mpic b 1>;
You can do a similar mask trick here.
> + mpic: pic@40000 {
interrupt-controller@40000
Segher
^ permalink raw reply
* [PATCH 3/4] ibmveth: Add ethtool TSO handlers
From: Brian King @ 2007-07-19 15:48 UTC (permalink / raw)
To: santil; +Cc: linuxppc-dev, rcjenn, brking, netdev
In-Reply-To: <1184860086366-patch-mail.ibm.com>
Add handlers for get_tso and get_ufo to prevent errors being printed
by ethtool.
Signed-off-by: Brian King <brking@linux.vnet.ibm.com>
---
linux-2.6-bjking1/drivers/net/ibmveth.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff -puN drivers/net/ibmveth.c~ibmveth_ethtool_get_tso drivers/net/ibmveth.c
--- linux-2.6/drivers/net/ibmveth.c~ibmveth_ethtool_get_tso 2007-07-19 08:39:31.000000000 -0500
+++ linux-2.6-bjking1/drivers/net/ibmveth.c 2007-07-19 08:39:31.000000000 -0500
@@ -761,7 +761,9 @@ static const struct ethtool_ops netdev_e
.get_tx_csum = ethtool_op_get_tx_csum,
.set_tx_csum = ibmveth_set_tx_csum,
.get_rx_csum = ibmveth_get_rx_csum,
- .set_rx_csum = ibmveth_set_rx_csum
+ .set_rx_csum = ibmveth_set_rx_csum,
+ .get_tso = ethtool_op_get_tso,
+ .get_ufo = ethtool_op_get_ufo
};
static int ibmveth_ioctl(struct net_device *dev, struct ifreq *ifr, int cmd)
_
^ permalink raw reply
* [PATCH 4/4] ibmveth: Add ethtool driver stats hooks
From: Brian King @ 2007-07-19 15:48 UTC (permalink / raw)
To: santil; +Cc: linuxppc-dev, rcjenn, brking, netdev
In-Reply-To: <1184860086366-patch-mail.ibm.com>
Add ethtool hooks to ibmveth to retrieve driver statistics.
Signed-off-by: Brian King <brking@linux.vnet.ibm.com>
---
linux-2.6-bjking1/drivers/net/ibmveth.c | 53 +++++++++++++++++++++++++++++++-
1 file changed, 52 insertions(+), 1 deletion(-)
diff -puN drivers/net/ibmveth.c~ibmveth_ethtool_driver_stats drivers/net/ibmveth.c
--- linux-2.6/drivers/net/ibmveth.c~ibmveth_ethtool_driver_stats 2007-07-19 08:39:35.000000000 -0500
+++ linux-2.6-bjking1/drivers/net/ibmveth.c 2007-07-19 08:39:35.000000000 -0500
@@ -112,6 +112,28 @@ MODULE_DESCRIPTION("IBM i/pSeries Virtua
MODULE_LICENSE("GPL");
MODULE_VERSION(ibmveth_driver_version);
+struct ibmveth_stat {
+ char name[ETH_GSTRING_LEN];
+ int offset;
+};
+
+#define IBMVETH_STAT_OFF(stat) offsetof(struct ibmveth_adapter, stat)
+#define IBMVETH_GET_STAT(a, off) *((u64 *)(((unsigned long)(a)) + off))
+
+struct ibmveth_stat ibmveth_stats[] = {
+ { "replenish_task_cycles", IBMVETH_STAT_OFF(replenish_task_cycles) },
+ { "replenish_no_mem", IBMVETH_STAT_OFF(replenish_no_mem) },
+ { "replenish_add_buff_failure", IBMVETH_STAT_OFF(replenish_add_buff_failure) },
+ { "replenish_add_buff_success", IBMVETH_STAT_OFF(replenish_add_buff_success) },
+ { "rx_invalid_buffer", IBMVETH_STAT_OFF(rx_invalid_buffer) },
+ { "rx_no_buffer", IBMVETH_STAT_OFF(rx_no_buffer) },
+ { "tx_multidesc_send", IBMVETH_STAT_OFF(tx_multidesc_send) },
+ { "tx_linearized", IBMVETH_STAT_OFF(tx_linearized) },
+ { "tx_linearize_failed", IBMVETH_STAT_OFF(tx_linearize_failed) },
+ { "tx_map_failed", IBMVETH_STAT_OFF(tx_map_failed) },
+ { "tx_send_failed", IBMVETH_STAT_OFF(tx_send_failed) }
+};
+
/* simple methods of getting data from the current rxq entry */
static inline int ibmveth_rxq_pending_buffer(struct ibmveth_adapter *adapter)
{
@@ -753,6 +775,32 @@ static u32 ibmveth_get_rx_csum(struct ne
return adapter->rx_csum;
}
+static void ibmveth_get_strings(struct net_device *dev, u32 stringset, u8 *data)
+{
+ int i;
+
+ if (stringset != ETH_SS_STATS)
+ return;
+
+ for (i = 0; i < ARRAY_SIZE(ibmveth_stats); i++, data += ETH_GSTRING_LEN)
+ memcpy(data, ibmveth_stats[i].name, ETH_GSTRING_LEN);
+}
+
+static int ibmveth_get_stats_count(struct net_device *dev)
+{
+ return ARRAY_SIZE(ibmveth_stats);
+}
+
+static void ibmveth_get_ethtool_stats(struct net_device *dev,
+ struct ethtool_stats *stats, u64 *data)
+{
+ int i;
+ struct ibmveth_adapter *adapter = dev->priv;
+
+ for (i = 0; i < ARRAY_SIZE(ibmveth_stats); i++)
+ data[i] = IBMVETH_GET_STAT(adapter, ibmveth_stats[i].offset);
+}
+
static const struct ethtool_ops netdev_ethtool_ops = {
.get_drvinfo = netdev_get_drvinfo,
.get_settings = netdev_get_settings,
@@ -763,7 +811,10 @@ static const struct ethtool_ops netdev_e
.get_rx_csum = ibmveth_get_rx_csum,
.set_rx_csum = ibmveth_set_rx_csum,
.get_tso = ethtool_op_get_tso,
- .get_ufo = ethtool_op_get_ufo
+ .get_ufo = ethtool_op_get_ufo,
+ .get_strings = ibmveth_get_strings,
+ .get_stats_count = ibmveth_get_stats_count,
+ .get_ethtool_stats = ibmveth_get_ethtool_stats
};
static int ibmveth_ioctl(struct net_device *dev, struct ifreq *ifr, int cmd)
diff -puN drivers/net/ibmveth.h~ibmveth_ethtool_driver_stats drivers/net/ibmveth.h
_
^ permalink raw reply
* [PATCH 2/4] ibmveth: Implement ethtool hooks to enable/disable checksum offload
From: Brian King @ 2007-07-19 15:48 UTC (permalink / raw)
To: santil; +Cc: linuxppc-dev, rcjenn, brking, netdev
In-Reply-To: <1184860086366-patch-mail.ibm.com>
This patch adds the appropriate ethtool hooks to allow for enabling/disabling
of hypervisor assisted checksum offload for TCP.
Signed-off-by: Brian King <brking@linux.vnet.ibm.com>
---
linux-2.6-bjking1/drivers/net/ibmveth.c | 120 +++++++++++++++++++++++++++++++-
linux-2.6-bjking1/drivers/net/ibmveth.h | 1
2 files changed, 119 insertions(+), 2 deletions(-)
diff -puN drivers/net/ibmveth.c~ibmveth_csum_offload_ethtool drivers/net/ibmveth.c
--- linux-2.6/drivers/net/ibmveth.c~ibmveth_csum_offload_ethtool 2007-07-19 08:38:27.000000000 -0500
+++ linux-2.6-bjking1/drivers/net/ibmveth.c 2007-07-19 08:39:08.000000000 -0500
@@ -641,12 +641,127 @@ static u32 netdev_get_link(struct net_de
return 1;
}
+static void ibmveth_set_rx_csum_flags(struct net_device *dev, u32 data)
+{
+ struct ibmveth_adapter *adapter = dev->priv;
+
+ if (data)
+ adapter->rx_csum = 1;
+ else {
+ adapter->rx_csum = 0;
+ dev->features &= ~NETIF_F_IP_CSUM;
+ }
+}
+
+static void ibmveth_set_tx_csum_flags(struct net_device *dev, u32 data)
+{
+ struct ibmveth_adapter *adapter = dev->priv;
+
+ if (data) {
+ dev->features |= NETIF_F_IP_CSUM;
+ adapter->rx_csum = 1;
+ } else
+ dev->features &= ~NETIF_F_IP_CSUM;
+}
+
+static int ibmveth_set_csum_offload(struct net_device *dev, u32 data,
+ void (*done) (struct net_device *, u32))
+{
+ struct ibmveth_adapter *adapter = dev->priv;
+ union ibmveth_illan_attributes set_attr, clr_attr, ret_attr;
+ long ret;
+ int rc1 = 0, rc2 = 0;
+ int restart = 0;
+
+ if (netif_running(dev)) {
+ restart = 1;
+ adapter->pool_config = 1;
+ ibmveth_close(dev);
+ adapter->pool_config = 0;
+ }
+
+ set_attr.desc = 0;
+ clr_attr.desc = 0;
+
+ if (data)
+ set_attr.fields.tcp_csum_offload_ipv4 = 1;
+ else
+ clr_attr.fields.tcp_csum_offload_ipv4 = 1;
+
+ ret = h_illan_attributes(adapter->vdev->unit_address, 0, 0, &ret_attr.desc);
+
+ if (ret == H_SUCCESS && !ret_attr.fields.active_trunk &&
+ !ret_attr.fields.trunk_priority &&
+ ret_attr.fields.csum_offload_padded_pkt_support) {
+ ret = h_illan_attributes(adapter->vdev->unit_address, clr_attr.desc,
+ set_attr.desc, &ret_attr.desc);
+
+ if (ret != H_SUCCESS) {
+ rc1 = -EIO;
+ ibmveth_error_printk("unable to change checksum offload settings."
+ " %d rc=%ld\n", data, ret);
+
+ ret = h_illan_attributes(adapter->vdev->unit_address,
+ set_attr.desc, clr_attr.desc, &ret_attr.desc);
+ } else
+ done(dev, data);
+ } else {
+ rc1 = -EIO;
+ ibmveth_error_printk("unable to change checksum offload settings."
+ " %d rc=%ld ret_attr=%lx\n", data, ret, ret_attr.desc);
+ }
+
+ if (restart)
+ rc2 = ibmveth_open(dev);
+
+ return rc1 ? rc1 : rc2;
+}
+
+static int ibmveth_set_rx_csum(struct net_device *dev, u32 data)
+{
+ struct ibmveth_adapter *adapter = dev->priv;
+
+ if (data && adapter->rx_csum)
+ return 0;
+ if (!data && !adapter->rx_csum)
+ return 0;
+
+ return ibmveth_set_csum_offload(dev, data, ibmveth_set_rx_csum_flags);
+}
+
+static int ibmveth_set_tx_csum(struct net_device *dev, u32 data)
+{
+ struct ibmveth_adapter *adapter = dev->priv;
+ int rc = 0;
+
+ if (data && (dev->features & NETIF_F_IP_CSUM))
+ return 0;
+ if (!data && !(dev->features & NETIF_F_IP_CSUM))
+ return 0;
+
+ if (data && !adapter->rx_csum)
+ rc = ibmveth_set_csum_offload(dev, data, ibmveth_set_tx_csum_flags);
+ else
+ ibmveth_set_tx_csum_flags(dev, data);
+
+ return rc;
+}
+
+static u32 ibmveth_get_rx_csum(struct net_device *dev)
+{
+ struct ibmveth_adapter *adapter = dev->priv;
+ return adapter->rx_csum;
+}
+
static const struct ethtool_ops netdev_ethtool_ops = {
.get_drvinfo = netdev_get_drvinfo,
.get_settings = netdev_get_settings,
.get_link = netdev_get_link,
.get_sg = ethtool_op_get_sg,
.get_tx_csum = ethtool_op_get_tx_csum,
+ .set_tx_csum = ibmveth_set_tx_csum,
+ .get_rx_csum = ibmveth_get_rx_csum,
+ .set_rx_csum = ibmveth_set_rx_csum
};
static int ibmveth_ioctl(struct net_device *dev, struct ifreq *ifr, int cmd)
@@ -1104,9 +1219,10 @@ static int __devinit ibmveth_probe(struc
ret = h_illan_attributes(dev->unit_address, 0, set_attr.desc,
&ret_attr.desc);
- if (ret == H_SUCCESS)
+ if (ret == H_SUCCESS) {
+ adapter->rx_csum = 1;
netdev->features |= NETIF_F_IP_CSUM;
- else
+ } else
ret = h_illan_attributes(dev->unit_address, set_attr.desc,
0, &ret_attr.desc);
}
diff -puN drivers/net/ibmveth.h~ibmveth_csum_offload_ethtool drivers/net/ibmveth.h
--- linux-2.6/drivers/net/ibmveth.h~ibmveth_csum_offload_ethtool 2007-07-19 08:38:27.000000000 -0500
+++ linux-2.6-bjking1/drivers/net/ibmveth.h 2007-07-19 08:38:27.000000000 -0500
@@ -140,6 +140,7 @@ struct ibmveth_adapter {
struct ibmveth_buff_pool rx_buff_pool[IbmVethNumBufferPools];
struct ibmveth_rx_q rx_queue;
int pool_config;
+ int rx_csum;
/* adapter specific stats */
u64 replenish_task_cycles;
_
^ permalink raw reply
* [PATCH 1/4] ibmveth: Enable TCP checksum offload
From: Brian King @ 2007-07-19 15:48 UTC (permalink / raw)
To: santil; +Cc: linuxppc-dev, rcjenn, brking, netdev
This patchset enables TCP checksum offload support for IPV4
on ibmveth. This completely eliminates the generation and checking of
the checksum for packets that are completely virtual and never
touch a physical network. A simple TCP_STREAM netperf run on
a virtual network with maximum mtu set yielded a ~30% increase
in throughput. This feature is enabled by default on systems that
support it, but can be disabled with a module option.
Signed-off-by: Brian King <brking@linux.vnet.ibm.com>
---
linux-2.6-bjking1/drivers/net/ibmveth.c | 53 ++++++++++++++++++++++++++++++++
linux-2.6-bjking1/drivers/net/ibmveth.h | 41 +++++++++++++++++++++++-
2 files changed, 92 insertions(+), 2 deletions(-)
diff -puN drivers/net/ibmveth.c~ibmveth_csum_offload drivers/net/ibmveth.c
--- linux-2.6/drivers/net/ibmveth.c~ibmveth_csum_offload 2007-07-18 16:55:06.000000000 -0500
+++ linux-2.6-bjking1/drivers/net/ibmveth.c 2007-07-19 08:36:05.000000000 -0500
@@ -47,6 +47,8 @@
#include <linux/mm.h>
#include <linux/ethtool.h>
#include <linux/proc_fs.h>
+#include <linux/in.h>
+#include <linux/ip.h>
#include <asm/semaphore.h>
#include <asm/hvcall.h>
#include <asm/atomic.h>
@@ -131,6 +133,11 @@ static inline int ibmveth_rxq_frame_leng
return (adapter->rx_queue.queue_addr[adapter->rx_queue.index].length);
}
+static inline int ibmveth_rxq_csum_good(struct ibmveth_adapter *adapter)
+{
+ return (adapter->rx_queue.queue_addr[adapter->rx_queue.index].csum_good);
+}
+
/* setup the initial settings for a buffer pool */
static void ibmveth_init_buffer_pool(struct ibmveth_buff_pool *pool, u32 pool_index, u32 pool_size, u32 buff_size, u32 pool_active)
{
@@ -684,6 +691,24 @@ static int ibmveth_start_xmit(struct sk_
desc[0].fields.length, DMA_TO_DEVICE);
desc[0].fields.valid = 1;
+ if (skb->ip_summed == CHECKSUM_PARTIAL &&
+ ip_hdr(skb)->protocol != IPPROTO_TCP && skb_checksum_help(skb)) {
+ ibmveth_error_printk("tx: failed to checksum packet\n");
+ tx_dropped++;
+ goto out;
+ }
+
+ if (skb->ip_summed == CHECKSUM_PARTIAL) {
+ unsigned char *buf = skb_transport_header(skb) + skb->csum_offset;
+
+ desc[0].fields.no_csum = 1;
+ desc[0].fields.csum_good = 1;
+
+ /* Need to zero out the checksum */
+ buf[0] = 0;
+ buf[1] = 0;
+ }
+
if(dma_mapping_error(desc[0].fields.address)) {
ibmveth_error_printk("tx: unable to map initial fragment\n");
tx_map_failed++;
@@ -702,6 +727,10 @@ static int ibmveth_start_xmit(struct sk_
frag->size, DMA_TO_DEVICE);
desc[curfrag+1].fields.length = frag->size;
desc[curfrag+1].fields.valid = 1;
+ if (skb->ip_summed == CHECKSUM_PARTIAL) {
+ desc[curfrag+1].fields.no_csum = 1;
+ desc[curfrag+1].fields.csum_good = 1;
+ }
if(dma_mapping_error(desc[curfrag+1].fields.address)) {
ibmveth_error_printk("tx: unable to map fragment %d\n", curfrag);
@@ -792,7 +821,11 @@ static int ibmveth_poll(struct net_devic
} else {
int length = ibmveth_rxq_frame_length(adapter);
int offset = ibmveth_rxq_frame_offset(adapter);
+ int csum_good = ibmveth_rxq_csum_good(adapter);
+
skb = ibmveth_rxq_get_buffer(adapter);
+ if (csum_good)
+ skb->ip_summed = CHECKSUM_UNNECESSARY;
ibmveth_rxq_harvest_buffer(adapter);
@@ -962,8 +995,10 @@ static void ibmveth_poll_controller(stru
static int __devinit ibmveth_probe(struct vio_dev *dev, const struct vio_device_id *id)
{
int rc, i;
+ long ret;
struct net_device *netdev;
struct ibmveth_adapter *adapter = NULL;
+ union ibmveth_illan_attributes set_attr, ret_attr;
unsigned char *mac_addr_p;
unsigned int *mcastFilterSize_p;
@@ -1058,6 +1093,24 @@ static int __devinit ibmveth_probe(struc
ibmveth_debug_printk("registering netdev...\n");
+ ret = h_illan_attributes(dev->unit_address, 0, 0, &ret_attr.desc);
+
+ if (ret == H_SUCCESS && !ret_attr.fields.active_trunk &&
+ !ret_attr.fields.trunk_priority &&
+ ret_attr.fields.csum_offload_padded_pkt_support) {
+ set_attr.desc = 0;
+ set_attr.fields.tcp_csum_offload_ipv4 = 1;
+
+ ret = h_illan_attributes(dev->unit_address, 0, set_attr.desc,
+ &ret_attr.desc);
+
+ if (ret == H_SUCCESS)
+ netdev->features |= NETIF_F_IP_CSUM;
+ else
+ ret = h_illan_attributes(dev->unit_address, set_attr.desc,
+ 0, &ret_attr.desc);
+ }
+
rc = register_netdev(netdev);
if(rc) {
diff -puN drivers/net/ibmveth.h~ibmveth_csum_offload drivers/net/ibmveth.h
--- linux-2.6/drivers/net/ibmveth.h~ibmveth_csum_offload 2007-07-18 16:55:06.000000000 -0500
+++ linux-2.6-bjking1/drivers/net/ibmveth.h 2007-07-19 08:35:25.000000000 -0500
@@ -67,6 +67,21 @@ static inline long h_send_logical_lan(un
return rc;
}
+static inline long h_illan_attributes(unsigned long unit_address,
+ unsigned long reset_mask, unsigned long set_mask,
+ unsigned long *ret_attributes)
+{
+ long rc;
+ unsigned long retbuf[PLPAR_HCALL_BUFSIZE];
+
+ rc = plpar_hcall(H_ILLAN_ATTRIBUTES, retbuf, unit_address,
+ reset_mask, set_mask);
+
+ *ret_attributes = retbuf[0];
+
+ return rc;
+}
+
#define h_multicast_ctrl(ua, cmd, mac) \
plpar_hcall_norets(H_MULTICAST_CTRL, ua, cmd, mac)
@@ -144,7 +159,9 @@ struct ibmveth_adapter {
struct ibmveth_buf_desc_fields {
u32 valid : 1;
u32 toggle : 1;
- u32 reserved : 6;
+ u32 reserved : 4;
+ u32 no_csum : 1;
+ u32 csum_good : 1;
u32 length : 24;
u32 address;
};
@@ -154,10 +171,30 @@ union ibmveth_buf_desc {
struct ibmveth_buf_desc_fields fields;
};
+struct ibmveth_illan_attributes_fields {
+ u32 reserved;
+ u32 reserved2 : 18;
+ u32 csum_offload_padded_pkt_support : 1;
+ u32 reserved3 : 1;
+ u32 trunk_priority : 4;
+ u32 reserved4 : 5;
+ u32 tcp_csum_offload_ipv6 : 1;
+ u32 tcp_csum_offload_ipv4 : 1;
+ u32 active_trunk : 1;
+};
+
+union ibmveth_illan_attributes {
+ u64 desc;
+ struct ibmveth_illan_attributes_fields fields;
+};
+
struct ibmveth_rx_q_entry {
u16 toggle : 1;
u16 valid : 1;
- u16 reserved : 14;
+ u16 reserved : 4;
+ u16 no_csum : 1;
+ u16 csum_good : 1;
+ u16 reserved2 : 8;
u16 offset;
u32 length;
u64 correlator;
_
^ permalink raw reply
* Re: Do we need to reset the master branch?
From: Stephen Rothwell @ 2007-07-19 15:46 UTC (permalink / raw)
To: Mark A. Greer; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <20070720014432.a46164a8.sfr@canb.auug.org.au>
[-- Attachment #1: Type: text/plain, Size: 485 bytes --]
On Fri, 20 Jul 2007 01:44:32 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> git remote add powerpc git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git
> git fetch powerpc
>
> This will track the tree in branches called powerpc/<branch> and do
> resets as necessary.
You should not make any local commits to the powerpc/* branches, of course.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Do we need to reset the master branch?
From: Stephen Rothwell @ 2007-07-19 15:44 UTC (permalink / raw)
To: Mark A. Greer; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <20070719153217.GC20538@mag.az.mvista.com>
[-- Attachment #1: Type: text/plain, Size: 814 bytes --]
On Thu, 19 Jul 2007 08:32:17 -0700 "Mark A. Greer" <mgreer@mvista.com> wrote:
>
> I was in the master branch of powerpc.git and did a 'git-pull'
Sorry, I hadn't updated since this afternoon. Looks like Paul has reset
his master tree to be the same as Linus', so you do need to do a reset.
Or checkout a separate branch and use
git fetch -f <powerpc.git tree> master:<whatever branch tracks master>
Using recent git (after 1.5.something), you can track the whole powerpc
tree like this:
git remote add powerpc git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git
git fetch powerpc
This will track the tree in branches called powerpc/<branch> and do
resets as necessary.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: ML403 Hard TEMAC, PLB and Linux 2.6
From: Grant Likely @ 2007-07-19 15:42 UTC (permalink / raw)
To: Mohammad Sadegh Sadri; +Cc: linuxppc-embedded
In-Reply-To: <fa686aa40707190840u2e2bd57dme1c4829c63a8280a@mail.gmail.com>
Gah! Sorry; ignore my reply; this is a very old thread.
g.
On 7/19/07, Grant Likely <grant.likely@secretlab.ca> wrote:
> On 2/7/07, Mohammad Sadegh Sadri <mamsadegh@hotmail.com> wrote:
> > 2- Simply, Is there any driver available for linux 2.6 , for PLB TEMAC and Hard TEMAC modules? If yes , can you put the link here, so that I can download it?
>
> You can grab my 2.6 git tree. It already has the TEMAC driver integrated.
>
> webview:
> http://git.secretlab.ca/cgi-bin/gitweb.cgi
>
> URLs for pulling
> git://git.secretlab.ca/git/linux-2.6.git
> http://git.secretlab.ca/git/linux-2.6.git
>
> Cheers,
> g.
>
>
> --
> Grant Likely, B.Sc., P.Eng.
> Secret Lab Technologies Ltd.
> grant.likely@secretlab.ca
> (403) 399-0195
>
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: ML403 Hard TEMAC, PLB and Linux 2.6
From: Grant Likely @ 2007-07-19 15:40 UTC (permalink / raw)
To: Mohammad Sadegh Sadri; +Cc: linuxppc-embedded
In-Reply-To: <BAY115-W1CC92C2510304D9E26E06B29E0@phx.gbl>
On 2/7/07, Mohammad Sadegh Sadri <mamsadegh@hotmail.com> wrote:
> 2- Simply, Is there any driver available for linux 2.6 , for PLB TEMAC and Hard TEMAC modules? If yes , can you put the link here, so that I can download it?
You can grab my 2.6 git tree. It already has the TEMAC driver integrated.
webview:
http://git.secretlab.ca/cgi-bin/gitweb.cgi
URLs for pulling
git://git.secretlab.ca/git/linux-2.6.git
http://git.secretlab.ca/git/linux-2.6.git
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: [PATCH 04/61] 8xx: Work around CPU15 erratum.
From: Scott Wood @ 2007-07-19 15:32 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev
In-Reply-To: <8503FAAA-42DF-4082-A755-773837490CA7@kernel.crashing.org>
Segher Boessenkool wrote:
>> The CPU15 erratum on MPC8xx chips can cause incorrect code execution
>> under certain circumstances, where there is a conditional or indirect
>> branch in the last word of a page, with a target in the last cache line
>> of the next page. This patch implements one of the suggested
>> workarounds, by forcing a TLB miss whenever execution crosses a page
>> boundary. This is done by invalidating the pages before and after the
>> one being loaded into the TLB in the ITLB miss handler.
>
>
> So you never found a bug workaround without the terrible
> overhead of this one? A shame :-(
The only lower-overhead workaround I know of requires compiler
modifications (and I made it configurable to allow for that possibility).
-Scott
^ permalink raw reply
* Re: [PATCH] powerpc: Add of_register_i2c_devices()
From: Segher Boessenkool @ 2007-07-19 15:32 UTC (permalink / raw)
To: Guennadi Liakhovetski; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <Pine.LNX.4.60.0707180010330.3535@poirot.grange>
>> Your device is an rs5c372b. So, that's what you put in
>> your device tree. Simple so far, right?
>>
>> Now some OF I2C code goes looking for IIC devices in the
>> device tree. It finds this thing, and from a table or
>> something it derives that it has to tell the kernel I2C
>> layer this is an "rtc-rs5c372". [It would be nicer if it
>> could just instantiate the correct driver directly, but
>> if that's how the Linux I2C layer works, so be it].
>>
>> No change in the I2C "core" needed, just an OF "compatible"
>> matching thing like is needed *everywhere else* too.
>
> How about the patch below?
Looks good. It should later be moved to a more generic
I2C OF matching layer, but fine for now. Thanks!
You might want to put vendor names in the "compatible"
entries, dunno though, maybe these are "cross-vendor"
ICs?
Segher
^ permalink raw reply
* Re: Do we need to reset the master branch?
From: Mark A. Greer @ 2007-07-19 15:32 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <20070720012708.91c77527.sfr@canb.auug.org.au>
On Fri, Jul 20, 2007 at 01:27:08AM +1000, Stephen Rothwell wrote:
> Hi Mark,
>
> On Thu, 19 Jul 2007 08:17:46 -0700 "Mark A. Greer" <mgreer@mvista.com> wrote:
> >
> > I did a git-pull this morning but it had a conflict. Should I have
> > reset it to something?
>
> What did you pull it into? There were conflicts with Linus' tree in the
> last merge, so there may be conflicts with master as well. I am sure
> Paul will pull Linus's tree back into his master branch when he returns
> which should resolve the conflicts.
I was in the master branch of powerpc.git and did a 'git-pull'
Mark
^ permalink raw reply
* Re: Do we need to reset the master branch?
From: Stephen Rothwell @ 2007-07-19 15:27 UTC (permalink / raw)
To: Mark A. Greer; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <20070719151746.GB20538@mag.az.mvista.com>
Hi Mark,
On Thu, 19 Jul 2007 08:17:46 -0700 "Mark A. Greer" <mgreer@mvista.com> wrote:
>
> I did a git-pull this morning but it had a conflict. Should I have
> reset it to something?
What did you pull it into? There were conflicts with Linus' tree in the
last merge, so there may be conflicts with master as well. I am sure
Paul will pull Linus's tree back into his master branch when he returns
which should resolve the conflicts.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
^ 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