* Re: [PATCH 5/5] PCI fixes for the MPC8641 Rev 2.0 silicon and Rev 1.02hardware
From: Scott Wood @ 2007-05-17 18:53 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev, Zhang Wei-r63237
In-Reply-To: <464CA380.2020705@freescale.com>
Timur Tabi wrote:
> One more thing - I think each DTS file should specify which revision of the board it
> supports, and there should be code in U-Boot and/or Linux to check that revision and
> reject the device tree if there's a mismatch. We don't want people accidentally using the
> wrong device tree and wondering why it doesn't work.
We also don't want people using a perfectly good device tree on a newer
revision of the board that just fixes things and doesn't make any
device-tree-relevant changes, and wondering why it doesn't work due to a
failed revision check.
-Scott
^ permalink raw reply
* Re: [PATCH 5/5] PCI fixes for the MPC8641 Rev 2.0 silicon and Rev 1.02hardware
From: Timur Tabi @ 2007-05-17 18:59 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, Zhang Wei-r63237
In-Reply-To: <464CA4B4.7070202@freescale.com>
Scott Wood wrote:
> We also don't want people using a perfectly good device tree on a newer
> revision of the board that just fixes things and doesn't make any
> device-tree-relevant changes,
Well, either one device tree is okay, or we need two. If we do need two, then it would be
bad to load the wrong one on a particular board and have only 90% functionality. If he
have the ability to prevent customers from getting confused, then we should do that. I
wish this was standard behavior for all device trees. I've frequently loaded the wrong
device tree and wondered why nothing worked.
--
Timur Tabi
Linux Kernel Developer @ Freescale
^ permalink raw reply
* Re: [PATCH 5/5] PCI fixes for the MPC8641 Rev 2.0 silicon and Rev 1.02hardware
From: Jerry Van Baren @ 2007-05-17 19:16 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev, Zhang Wei-r63237
In-Reply-To: <464CA610.1050504@freescale.com>
Timur Tabi wrote:
> Scott Wood wrote:
>
>> We also don't want people using a perfectly good device tree on a newer
>> revision of the board that just fixes things and doesn't make any
>> device-tree-relevant changes,
>
> Well, either one device tree is okay, or we need two. If we do need two, then it would be
> bad to load the wrong one on a particular board and have only 90% functionality. If he
> have the ability to prevent customers from getting confused, then we should do that. I
> wish this was standard behavior for all device trees. I've frequently loaded the wrong
> device tree and wondered why nothing worked.
Wolfgang Grandegger and Detlev Zundel are working on using fdts for
configuring u-boot itself (I'm only indirectly involved: I am custodian
for u-boot-fdt).
I envision the likely progression of this and other activities will be
to make fdt properties (variables) first class citizens of u-boot:
substantially and possibly entirely replacing the traditional u-boot
environment variables. This would imply that you could write a hush
script that u-boot executed that would pick the right fdt, or at least
complain if you had the wrong fdt.
Theoretically. Some assembly required. :-/
I see Timur just sent an email on the u-boot list proposing a
"fdt_checkboard()" function. Hmmm, something to think about...
Best regards,
gvb
^ permalink raw reply
* Re: [PATCH 3/5] powerpc: Document device nodes for I2C devices.
From: Segher Boessenkool @ 2007-05-17 19:18 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, i2c
In-Reply-To: <20070517143846.GC29795@ld0162-tx32.am.freescale.net>
> + Required properties :
> +
> + - reg : Unshifted 7-bit I2C address for the device
What about 10-bit addressing, etc.?
> + Recommended properties :
> +
> + - compatible : The name of the Linux device driver that
> + handles this device. If unspecified, the name of the
> + node will be used.
NO WAY
> + - interrupts : <a b> where a is the interrupt number and b is a
I2C doesn't do interrupts, this doesn't belong in
an I2C binding; it's redundant anyway (and incorrect
as well).
I second most of Kumar's sentiments, too.
Segher
^ permalink raw reply
* Re: [PATCH 2.6.21-rt2] PowerPC: decrementer clockevent driver
From: Segher Boessenkool @ 2007-05-17 19:27 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: linuxppc-dev, mingo, tglx, linux-kernel
In-Reply-To: <200705172142.26739.sshtylyov@ru.mvista.com>
> + * We must write a positive value to the decrementer to clear
> + * the interrupt on the IBM 970 CPU series. In periodic mode,
> + * this happens when the decrementer gets reloaded later, but
> + * in one-shot mode, we have to do it here since an event handler
> + * may skip loading the new value...
Nothing special about 970 here -- on *every* PowerPC,
a decrementer exception exists as long as the high
bit of the decrementer equals 1. BookE is different
of course. Some other CPUs might deviate from the
architecture as well.
Segher
^ permalink raw reply
* Re: [PATCH 3/5] powerpc: Document device nodes for I2C devices.
From: Scott Wood @ 2007-05-17 19:32 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev, i2c
In-Reply-To: <8183195dad79296e3986f561bf929067@kernel.crashing.org>
Segher Boessenkool wrote:
>> + Required properties :
>> +
>> + - reg : Unshifted 7-bit I2C address for the device
>
> What about 10-bit addressing, etc.?
I specified 7-bit to address someone's question back when this first
came up of whether it was 7-bit unshifted or 8-bit shifted. Perhaps it
should just say "Unshifted I2C address for the device"?
>> + Recommended properties :
>> +
>> + - compatible : The name of the Linux device driver that
>> + handles this device. If unspecified, the name of the
>> + node will be used.
>
> NO WAY
Sorry, that was left in there from a while ago and I missed it. It
should be defined the same way as any other compatible property (and the
i2c code in Linux should be fixed to allow drivers to specify multiple
match names). No need for shouting. :-)
>> + - interrupts : <a b> where a is the interrupt number and b is a
>
> I2C doesn't do interrupts,
...but some I2C devices do.
> this doesn't belong in an I2C binding; it's redundant anyway
I guess it's implicit that any device that generates interrupts will
have an interrupts property, though there are many other examples of
this sort of redundancy in booting-without-of.txt. Its inclusion was
mainly an example.
> (and incorrect as well).
How is it incorrect?
-Scott
^ permalink raw reply
* Re: [PATCH 2.6.21-rt2] PowerPC: decrementer clockevent driver
From: Sergei Shtylyov @ 2007-05-17 19:43 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev, mingo, tglx, linux-kernel
In-Reply-To: <f9afbdb49bc1f935153305315770bccd@kernel.crashing.org>
Segher Boessenkool wrote:
>> + * We must write a positive value to the decrementer to clear
>> + * the interrupt on the IBM 970 CPU series. In periodic mode,
>> + * this happens when the decrementer gets reloaded later, but
>> + * in one-shot mode, we have to do it here since an event handler
>> + * may skip loading the new value...
> Nothing special about 970 here -- on *every* PowerPC,
> a decrementer exception exists as long as the high
> bit of the decrementer equals 1. BookE is different
> of course. Some other CPUs might deviate from the
> architecture as well.
Quoting "PowerPC Operating Environment Architecture":
The Decrementer counts down. On POWER4, a Decrementer exception occurs when
DEC0 changes from 0 to 1. On POWER4+, operation is as follows.
The exception effects of the Decrementer are said to be consistent with the
contents of the Decrementer if one of the following statements is true.
* DEC0=0 and a Decrementer exception does not exist.
* DEC0=1 and a Decrementer exception exists.
If DEC0=0, a context synchronizing instruction or event ensures that the
exception effects of the Decrementer are consistent with the contents of the
Decrementer. Otherwise, when the contents of DEC0 change, the exception
effects of the Decrementer become consistent with the new contents of the
Decrementer reasonably soon after the change.
> Segher
WBR, Sergei
^ permalink raw reply
* Re: [PATCH 3/5] powerpc: Document device nodes for I2C devices.
From: Segher Boessenkool @ 2007-05-17 19:44 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, i2c
In-Reply-To: <464CADBB.9050500@freescale.com>
>>> + - reg : Unshifted 7-bit I2C address for the device
>> What about 10-bit addressing, etc.?
>
> I specified 7-bit to address someone's question back when this first
> came up of whether it was 7-bit unshifted or 8-bit shifted. Perhaps
> it should just say "Unshifted I2C address for the device"?
Better, yes.
>>> + - compatible : The name of the Linux device driver that
>>> + handles this device. If unspecified, the name of the
>>> + node will be used.
>> NO WAY
>
> Sorry, that was left in there from a while ago and I missed it. It
> should be defined the same way as any other compatible property (and
> the i2c code in Linux should be fixed to allow drivers to specify
> multiple match names). No need for shouting. :-)
Oh yes there is :-)
>>> + - interrupts : <a b> where a is the interrupt number and b is a
>> I2C doesn't do interrupts,
>
> ...but some I2C devices do.
So? They do that outside of the I2C domain.
>> this doesn't belong in an I2C binding; it's redundant anyway
>
> I guess it's implicit that any device that generates interrupts will
> have an interrupts property,
This is defined in the base spec as well as in the interrupt
mapping spec, yes. The exact format of the "interrupts"
property for a device is defined in the binding for the
interrupt domain that interrupt lives in.
> though there are many other examples of this sort of redundancy in
> booting-without-of.txt. Its inclusion was mainly an example.
>
> > (and incorrect as well).
>
> How is it incorrect?
You specified that an interrupt specifier consists of two
cells. This is wrong.
Segher
^ permalink raw reply
* Re: [PATCH 2.6.21-rt2] PowerPC: decrementer clockevent driver
From: Segher Boessenkool @ 2007-05-17 19:50 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: linuxppc-dev, tglx, mingo, linux-kernel
In-Reply-To: <464CB071.5050504@ru.mvista.com>
>>> + * We must write a positive value to the decrementer to clear
>>> + * the interrupt on the IBM 970 CPU series. In periodic mode,
>>> + * this happens when the decrementer gets reloaded later, but
>>> + * in one-shot mode, we have to do it here since an event
>>> handler
>>> + * may skip loading the new value...
>
>> Nothing special about 970 here -- on *every* PowerPC,
>> a decrementer exception exists as long as the high
>> bit of the decrementer equals 1. BookE is different
>> of course. Some other CPUs might deviate from the
>> architecture as well.
>
> Quoting "PowerPC Operating Environment Architecture":
<snip>
> Otherwise, when the contents of DEC0 change, the exception effects of
> the Decrementer become consistent with the new contents of the
> Decrementer reasonably soon after the change.
And that is guaranteed on all PowerPC as far as I can see.
The main thing is that a decrementer exception won't go
away until the high bit becomes 0.
Segher
^ permalink raw reply
* Re: [PATCH 2/2]: PCI Error Recovery: Symbios SCSI First Failure
From: Linas Vepstas @ 2007-05-17 19:53 UTC (permalink / raw)
To: matthew; +Cc: linuxppc-dev, linux-pci, linux-kernel, linux-scsi
In-Reply-To: <20070509202621.GA4452@austin.ibm.com>
On Wed, May 09, 2007 at 03:26:21PM -0500, Linas Vepstas wrote:
> Hi Matthew,
>
> I had been hoping these patches might make it into 2.6.22,
> ... this is a nag note; please forward upstream.
... should I repost the patches?
--linas
^ permalink raw reply
* Re: [PATCH 2.6.21-rt2] PowerPC: decrementer clockevent driver
From: Sergei Shtylyov @ 2007-05-17 20:00 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev, tglx, mingo, linux-kernel
In-Reply-To: <9095839480a9686d9c40aa6143edb804@kernel.crashing.org>
Segher Boessenkool wrote:
>>>> + * We must write a positive value to the decrementer to clear
>>>> + * the interrupt on the IBM 970 CPU series. In periodic mode,
>>>> + * this happens when the decrementer gets reloaded later, but
>>>> + * in one-shot mode, we have to do it here since an event handler
>>>> + * may skip loading the new value...
>>
>>
>>> Nothing special about 970 here -- on *every* PowerPC,
>>> a decrementer exception exists as long as the high
>>> bit of the decrementer equals 1. BookE is different
>>> of course. Some other CPUs might deviate from the
>>> architecture as well.
>>
>>
>> Quoting "PowerPC Operating Environment Architecture":
> <snip>
>> Otherwise, when the contents of DEC0 change, the exception effects of
>> the Decrementer become consistent with the new contents of the
>> Decrementer reasonably soon after the change.
> And that is guaranteed on all PowerPC as far as I can see.
> The main thing is that a decrementer exception won't go
> away until the high bit becomes 0.
On both POWER4 and POWER4+, the Decrementer must be implemented such that
requirements 1 to 3 below are satisfied. On POWER4, requirements 4 and 5 must
also be satisfied.
1. The operation of the Time Base and the Decrementer is coherent, i.e., the
counters are driven by the same fundamental time base.
2. Loading a GPR from the Decrementer shall have no effect on the accuracy of
the Decrementer.
3. Storing a GPR to the Decrementer shall replace the value in the Decrementer
with the value in the GPR.
4. Whenever bit 0 of the Decrementer changes from 0 to 1, an interrupt request
is signaled. If multiple Decrementer interrupt requests are received before
the first can be reported, only one interrupt is reported. The occurrence of a
Decrementer interrupt cancels the request.
5. If the Decrementer is altered by software and the contents of bit 0 are
changed from 0 to 1, an interrupt request is signaled.
(4) clearly contradicts your point. I don't mind changing #ifdef though
(so it'll cover all non Book E cases)
> Segher
WBR, Sergei
^ permalink raw reply
* Re: [PATCH] fix 440-related Kconfig warnings
From: Josh Boyer @ 2007-05-17 20:00 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: linuxppc-dev
In-Reply-To: <20070517132434.GA26230@lst.de>
On Thu, 2007-05-17 at 15:24 +0200, Christoph Hellwig wrote:
> Currently there is no IBM_NEW_EMAC_ZMII in the tree, so we shouldn't
> selected it.
>
Someone else already submitted a patch for this last week, but yours is
more complete.
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
Acked-by: Josh Boyer <jwboyer@linux.vnet.ibm.com>
^ permalink raw reply
* Re: [PATCH 2.6.21-rt2] PowerPC: decrementer clockevent driver
From: Segher Boessenkool @ 2007-05-17 20:53 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: linuxppc-dev, tglx, mingo, linux-kernel
In-Reply-To: <464CB460.40905@ru.mvista.com>
>>> Otherwise, when the contents of DEC0 change, the exception effects
>>> of the Decrementer become consistent with the new contents of the
>>> Decrementer reasonably soon after the change.
>
>> And that is guaranteed on all PowerPC as far as I can see.
>> The main thing is that a decrementer exception won't go
>> away until the high bit becomes 0.
>
> On both POWER4 and POWER4+, the Decrementer must be implemented such
> that requirements 1 to 3 below are satisfied. On POWER4, requirements
> 4 and 5 must also be satisfied.
<snip>
> 4. Whenever bit 0 of the Decrementer changes from 0 to 1, an interrupt
> request is signaled. If multiple Decrementer interrupt requests are
> received before the first can be reported, only one interrupt is
> reported. The occurrence of a Decrementer interrupt cancels the
> request.
>
> 5. If the Decrementer is altered by software and the contents of bit 0
> are changed from 0 to 1, an interrupt request is signaled.
From the POWER ISA 2.03, the latest public version of the
architecture definition:
When the contents of DEC32 change from 0 to 1, a Decrementer
exception will come into existence within a reasonable period
or time. When the contents of DEC32 change from 1 to 0, an
existing Decrementer exception will cease to exist within a
reasonable period of time, but not later than the completion
of the next context synchronizing instruction or event.
> (4) clearly contradicts your point.
Yes, on some implementations there can be other conditions that
make a decrementer exception go away; there is no contradiction
here (thankfully). My wording was sloppy.
> I don't mind changing #ifdef though (so it'll cover all non Book E
> cases)
That was exactly my point; thank you.
Segher
^ permalink raw reply
* Re: [PATCH 3/5] powerpc: Document device nodes for I2C devices.
From: Scott Wood @ 2007-05-17 21:15 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev, i2c
In-Reply-To: <1e7cedebed6b67737c68fa01d832c3f3@kernel.crashing.org>
Segher Boessenkool wrote:
>> How is it incorrect?
>
>
> You specified that an interrupt specifier consists of two
> cells. This is wrong.
Oops... Apparently, that was copied from other bindings with the same
problem.
Next time I'll look more carefully at a patch from 6 months ago before
resending it. :-P
-Scott
^ permalink raw reply
* Re: [PATCH 5/5] PCI fixes for the MPC8641 Rev 2.0 silicon and Rev 1.02hardware
From: Wade Farnsworth @ 2007-05-17 22:34 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev, Zhang Wei-r63237
In-Reply-To: <464CA302.9060707@freescale.com>
On Thu, 2007-05-17 at 13:46 -0500, Timur Tabi wrote:
> Wade Farnsworth wrote:
>
> > Yes. On rev 1.0 boards, all of the devices on the south bridge are on
> > bus 0, while on rev 1.02, the devices on the southbridge are on bus 2.
> >
> > I'd like to use the same dts for both rev's if possible. But if there
> > is a reason why they shouldn't, I suppose I could create a separate dts.
>
> I think two DTS files is the best approach for now. A few of us had an idea to introduce
> conditional statements in to the DTS, and U-Boot would examine the board and/or
> environment variables and then apply the conditions to the device tree before booting the
> kernel. This would allow you to merge the two DTS files into one, but we're quite a ways
> off from implementing this feature. In the meantime, two DTS files is okay.
>
OK. I'll create a separate dts for the new rev.
--Wade
^ permalink raw reply
* Re: eeh bug
From: Benjamin Herrenschmidt @ 2007-05-17 22:43 UTC (permalink / raw)
To: Linas Vepstas; +Cc: linuxppc-dev list
In-Reply-To: <20070517164438.GD4325@austin.ibm.com>
On Thu, 2007-05-17 at 11:44 -0500, Linas Vepstas wrote:
> I'll take a look. Usually, there's no pci_dev only when its a slot
> with no device plugged into it; these can still receive EEH errors
> during config space i/o to the bridge (I presume that the
> justification
> is when aluminum scrap shorts out a pci connector or something like
> that). In all other cases, there's a pci_dev, which is why the
> bug slipped by.
Hrm... in that case, there's a device in. I'll try to track down why we
don't get it.
Ben.
^ permalink raw reply
* Re: RT patches expose netdev race [was Re: [RFC] [patch 2/2] powerpc 2.6.21-rt1: fix kernel hang and/or panic
From: Linas Vepstas @ 2007-05-17 23:52 UTC (permalink / raw)
To: David Miller; +Cc: linuxppc-dev, netdev, mingo, tglx
In-Reply-To: <20070516.174101.45179259.davem@davemloft.net>
On Wed, May 16, 2007 at 05:41:01PM -0700, David Miller wrote:
> From: linas@austin.ibm.com (Linas Vepstas)
> Date: Wed, 16 May 2007 19:18:02 -0500
>
> > Since this is a long email; let me put a summary up front:
> > I think the RT/premption patches are exposing some sort
> > of race in the ip header handling code. The rest of the
> > note is forensics pointing to this.
>
> skb->head should never ever be NULL.
The stack trace from Owa-san showed a null pointer deref at
ip_hdr(skb)->protocol for an skb passed in via hard_start_xmit()
I dunno, memory corruption?
Tsutomu, can you reproduce this with something similr to the following
patch?
--linas
drivers/net/spider_net.c | 16 +++++++++++++++-
1 file changed, 15 insertions(+), 1 deletion(-)
Index: linux-2.6.22-rc1/drivers/net/spider_net.c
===================================================================
--- linux-2.6.22-rc1.orig/drivers/net/spider_net.c 2007-05-17 18:31:40.000000000 -0500
+++ linux-2.6.22-rc1/drivers/net/spider_net.c 2007-05-17 18:51:49.000000000 -0500
@@ -720,7 +720,19 @@ spider_net_prepare_tx_descr(struct spide
SPIDER_NET_DESCR_CARDOWNED | SPIDER_NET_DMAC_NOCS;
spin_unlock_irqrestore(&chain->lock, flags);
- if (skb->protocol == htons(ETH_P_IP) && skb->ip_summed == CHECKSUM_PARTIAL)
+ if (skb->protocol == htons(ETH_P_IP) && skb->ip_summed == CHECKSUM_PARTIAL) {
+ struct iphdr *hp=ip_hdr(skb);
+ if (((unsigned long) hp < 0x100000) ||
+ ((unsigned long)hp > 0xffff000000000000UL)) {
+ printk(KERN_ERROR "spidernet: bad ip header! "
+ "skb=%p ip_hdr=%p head=%p data=%p net=%x\n", skb, hp,
+ skb->head, skb->data, skb->network_header);
+ int i;
+ unsinged long *s=(unsigned long*) skb;
+ for (i=0; i<20; i++) {
+ printk("%d %lx %lx\n", i, s[2*i],s[2*i+1]);
+ }
+ } else {
switch (ip_hdr(skb)->protocol) {
case IPPROTO_TCP:
hwdescr->dmac_cmd_status |= SPIDER_NET_DMAC_TCP;
@@ -728,6 +740,8 @@ spider_net_prepare_tx_descr(struct spide
case IPPROTO_UDP:
hwdescr->dmac_cmd_status |= SPIDER_NET_DMAC_UDP;
break;
+ }
+ }
}
/* Chain the bus address, so that the DMA engine finds this descr. */
^ permalink raw reply
* Re: [PATCH 4/5] powerpc: Add of_register_i2c_devices().
From: Stephen Rothwell @ 2007-05-18 0:09 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, i2c
In-Reply-To: <20070517143856.GD29795@ld0162-tx32.am.freescale.net>
[-- Attachment #1: Type: text/plain, Size: 342 bytes --]
On Thu, 17 May 2007 09:38:56 -0500 Scott Wood <scottwood@freescale.com> wrote:
>
> + addr = get_property(node, "reg", &len);
get_property has been replaced by of_get_property.
> + name = get_property(node, "compatible", NULL);
ditto.
--
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: [PATCH 1/3] ibm_emac: fix section mismatch warnings
From: Jeff Garzik @ 2007-05-18 0:45 UTC (permalink / raw)
To: ebs; +Cc: netdev, linuxppc-embedded
In-Reply-To: <20070516185737.GA14704@gate.ebshome.net>
Eugene Surovegin wrote:
> Fix "Section mismatch" warnings
>
> Signed-off-by: Eugene Surovegin <ebs@ebshome.net>
>
> ---
> drivers/net/ibm_emac/ibm_emac_mal.c | 3 +--
> drivers/net/ibm_emac/ibm_emac_mal.h | 3 +--
> drivers/net/ibm_emac/ibm_emac_rgmii.c | 2 +-
> drivers/net/ibm_emac/ibm_emac_rgmii.h | 2 +-
> drivers/net/ibm_emac/ibm_emac_tah.c | 2 +-
> drivers/net/ibm_emac/ibm_emac_tah.h | 2 +-
> drivers/net/ibm_emac/ibm_emac_zmii.c | 2 +-
> drivers/net/ibm_emac/ibm_emac_zmii.h | 2 +-
> 8 files changed, 8 insertions(+), 10 deletions(-)
applied 1-3
Please fix your incorrect Mail-Followup-To headers. They cause mailers
to NOT direct replies to you, and CC lists, which is contra to normal
LKML behavior.
^ permalink raw reply
* Re: [PATCH] gianfar: Add I/O barriers when touching buffer descriptor ownership.
From: Jeff Garzik @ 2007-05-18 0:45 UTC (permalink / raw)
To: Scott Wood; +Cc: netdev, linuxppc-dev
In-Reply-To: <20070516200659.GA23548@ld0162-tx32.am.freescale.net>
Scott Wood wrote:
> The hardware must not see that is given ownership of a buffer until it is
> completely written, and when the driver receives ownership of a buffer,
> it must ensure that any other reads to the buffer reflect its final
> state. Thus, I/O barriers are added where required.
>
> Without this patch, I have observed GCC reordering the setting of
> bdp->length and bdp->status in gfar_new_skb. Hardware reordering
> was also theoretically possible.
>
> Signed-off-by: Scott Wood <scottwood@freescale.com>
> ---
> I've added the requested comments to the source code about
> the use of eieio(). Jeff, please consider for 2.6.22, as it
> fixes a bug that has been observed.
>
> drivers/net/gianfar.c | 11 +++++++++++
> 1 files changed, 11 insertions(+), 0 deletions(-)
applied
^ permalink raw reply
* Re: [PATCH 5/5] PCI fixes for the MPC8641 Rev 2.0 silicon and Rev 1.02hardware
From: David Gibson @ 2007-05-18 0:56 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev, Zhang Wei-r63237
In-Reply-To: <464CA302.9060707@freescale.com>
On Thu, May 17, 2007 at 01:46:26PM -0500, Timur Tabi wrote:
> Wade Farnsworth wrote:
>
> > Yes. On rev 1.0 boards, all of the devices on the south bridge are on
> > bus 0, while on rev 1.02, the devices on the southbridge are on bus 2.
> >
> > I'd like to use the same dts for both rev's if possible. But if there
> > is a reason why they shouldn't, I suppose I could create a separate dts.
>
> I think two DTS files is the best approach for now. A few of us had
> an idea to introduce conditional statements in to the DTS, and
Erm... how would you encode such conditionals in the dtb? I really
don't like the idea of having a generalized conditional
parser/evaluator built into the bootwrapper.
What I'd been thinking for situations like this is to fold two dtbs
into the bootwrapper and have it select between them based on on board
revision (assuming that can be deduced from registers somehow).
> U-Boot would examine the board and/or environment variables and then
> apply the conditions to the device tree before booting the kernel.
> This would allow you to merge the two DTS files into one, but we're
> quite a ways off from implementing this feature. In the meantime,
> two DTS files is okay.
>
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [PATCH 2.6.21-rt2] PowerPC: decrementer clockevent driver
From: Albert Cahalan @ 2007-05-18 3:24 UTC (permalink / raw)
To: galak, tglx, mingo, linuxppc-dev, linux-kernel, sshtylyov
Sergei Shtylyov writes:
> Kumar Gala wrote:
>> [Sergei Shtylyov]
>>> Kumar Gala wrote:
>>>> I haven't looked at all the new clock/timer code, is there any
>>>> utility in having support for more than one clock source?
>>>
>>> Of course, you may register as many as you like.
>>
>> Sure, but is there any utility in registering more than the
>> decrementer on PPC?
>
> Not yet. I'm not sure I know any other PPC CPU facility fitting
> for clockevents. In theory, FIT could be used -- but its period
> is measured in powers of 2, IIRC.
I'd really like to have that as an option. It would allow oprofile
to safely use hardware events on the MPC74xx "G4" processors.
Alternately it would allow thermal events. It is safe to use at
most one of the three (decrementer,profiling,thermal) interrupts.
If two were to hit at the same time, badness happens.
It's possible to wrapper the interrupt in something that divides
down, calling the normal code only some of the time. I think one
of the FIT choices is about 4 kHz on my system, which would be OK.
Full oprofile functionality would be wonderful.
^ permalink raw reply
* Re: [PATCH 5/5] PCI fixes for the MPC8641 Rev 2.0 silicon and Rev 1.02hardware
From: Jerry Van Baren @ 2007-05-18 3:49 UTC (permalink / raw)
To: Timur Tabi, Wade Farnsworth, linuxppc-dev, Zhang Wei-r63237
In-Reply-To: <20070518005641.GA27350@localhost.localdomain>
David Gibson wrote:
> On Thu, May 17, 2007 at 01:46:26PM -0500, Timur Tabi wrote:
>> Wade Farnsworth wrote:
>>
>>> Yes. On rev 1.0 boards, all of the devices on the south bridge are on
>>> bus 0, while on rev 1.02, the devices on the southbridge are on bus 2.
>>>
>>> I'd like to use the same dts for both rev's if possible. But if there
>>> is a reason why they shouldn't, I suppose I could create a separate dts.
>> I think two DTS files is the best approach for now. A few of us had
>> an idea to introduce conditional statements in to the DTS, and
>
> Erm... how would you encode such conditionals in the dtb? I really
> don't like the idea of having a generalized conditional
> parser/evaluator built into the bootwrapper.
I hear forth is a really neat language, and can do conditionals. ;-)
> What I'd been thinking for situations like this is to fold two dtbs
> into the bootwrapper and have it select between them based on on board
> revision (assuming that can be deduced from registers somehow).
>
>> U-Boot would examine the board and/or environment variables and then
>> apply the conditions to the device tree before booting the kernel.
>> This would allow you to merge the two DTS files into one, but we're
>> quite a ways off from implementing this feature. In the meantime,
>> two DTS files is okay.
WRT u-boot:
a) With the libfdt changes, we're making good progress on updating the
fdt based on the board-specific information. This gives us the
capability of creating a semi-generic DTS and have u-boot augment the
fdt with the necessary board-specific property settings.
b) I also have a dream of allowing the hush parser to test fdt
properties, which would allow us to write u-boot/hush scripts that
validate that a given fdt is a proper one for the board and/or select
the proper one out of several in memory. So many fun ideas, so little
time...
Best regards,
gvb
^ permalink raw reply
* Re: [PATCH 2.6.21-rt2] PowerPC: decrementer clockevent driver
From: Benjamin Herrenschmidt @ 2007-05-18 5:04 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev, tglx, mingo, linux-kernel
In-Reply-To: <97d47c2261fe9cd3f1a6c864278a6ab6@kernel.crashing.org>
>
> Yes, on some implementations there can be other conditions that
> make a decrementer exception go away; there is no contradiction
> here (thankfully). My wording was sloppy.
Some CPUs have the DEC exceptions basically edge triggered (yeah I know
it sucks). That's why, among others, the IRQ soft-disable code has code
to re-trigger DEC exceptions ASAP (by setting it to 1.. note that we
could probably use 0 here, we've been a bit conservative).
Ben.
^ permalink raw reply
* Re: RT patches expose netdev race [was Re: [RFC] [patch 2/2] powerpc 2.6.21-rt1: fix kernel hang and/or panic
From: Tsutomu OWA @ 2007-05-18 5:36 UTC (permalink / raw)
To: Linas Vepstas; +Cc: David Miller, linuxppc-dev, netdev, mingo, tglx
In-Reply-To: <20070517235247.GJ4325@austin.ibm.com>
At Thu, 17 May 2007 18:52:47 -0500, Linas Vepstas wrote:
> The stack trace from Owa-san showed a null pointer deref at
> ip_hdr(skb)->protocol for an skb passed in via hard_start_xmit()
>
> I dunno, memory corruption?
It turns out that there was a mistake in my report, sorry.
The error occurs on 2.6.21-rc5 + patch-2.6.21-rc5-rt12 + my patches,
but it does not on 2.6.21 + patch-2.6.21-rt1 + my patches (except spindernet one).
I thought I had checked it before sending the patch, but looks like I didn't.
My appologies...
-- owa
^ 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