Use shorter method to determine whether adapter has configured ports
Signed-off-by: Thomas Klein [EMAIL PROTECTED]
---
drivers/net/ehea/ehea_main.c | 18 ++
1 files changed, 6 insertions(+), 12 deletions(-)
diff --git a/drivers/net/ehea/ehea_main.c
Fixed wrongly casted pointers
Signed-off-by: Thomas Klein [EMAIL PROTECTED]
---
drivers/net/ehea/ehea_main.c | 25 ++---
1 files changed, 10 insertions(+), 15 deletions(-)
diff --git a/drivers/net/ehea/ehea_main.c b/drivers/net/ehea/ehea_main.c
index 36ca322..9756211
On Fri, Aug 03, 2007 at 04:29:48AM -0500, Kumar Gala wrote:
On Aug 2, 2007, at 4:47 PM, David Brownell wrote:
On Thursday 02 August 2007, Anton Vorontsov wrote:
Probably someday mpc83xx_spi-sysclk should be renamed to
mpc83xx_spi-spiclk to be less confusing.
Why not today, with this
On Sat, Aug 04, 2007 at 05:45:38PM +1000, David Gibson wrote:
On Fri, Aug 03, 2007 at 11:09:02AM -0500, Josh Boyer wrote:
Remove some leftover cruft in the 40x Kconfig file. Also make sure we
select WANT_DEVICE_TREE for 40x.
Signed-off-by: Josh Boyer [EMAIL PROTECTED]
---
On Mon, Aug 06, 2007 at 03:00:12PM +1000, David Gibson wrote:
On Fri, Aug 03, 2007 at 11:09:10AM -0500, Josh Boyer wrote:
Add a bootwrapper for the AMCC 440EP Bamboo Eval board. This also adds a
common fixup_clock function for all 440EP(x) chips.
Ok, you have a separate bamboo.c and
Long ago I've noticed (but didn't pay much attention) that
spi_mpc83xx using PM calculations that differs from what
specs describe. I.e.
u8 pm = mpc83xx_spi-spibrg / (spi-max_speed_hz * 4);
While specs says: The SPI baud rate generator clock source (either
system clock or system clock divided by
On Mon, Aug 06, Benjamin Herrenschmidt wrote:
BTW. Any reason why you don't set the DMA mask in the ohci driver rather
than the sbp2 one ?
I used this patch, and the attached CD was found.
What dma mask should be used in ohci_probe()?
---
drivers/ieee1394/ohci1394.c |2 ++
On Monday 06 August 2007, Anton Vorontsov wrote:
+
+ if (pm)
+ pm--;
+ else /* this floods dmesg if using mmc_spi, so dbg */
+ dev_dbg(spi-dev, Requested speed is too
+
More importantly, reg-shift doesn't say what part of
the bigger words to access. A common example is byte-wide
registers on a 32-bit-only bus; it's about 50%-50% between
connecting the registers to the low byte vs. connecting it
to the byte with the lowest address.
We already have
On Sun, 2007-08-05 at 23:53, David Gibson wrote:
+ *
+ * To build:
+ * dtc -I dts -O asm -o bamboo.S -b 0 bamboo.dts
+ * dtc -I dts -O dtb -o bamboo.dtb -b 0 bamboo.dts
Can we ditch this to build boilerplate. It's just another thing
people frequently forget to update as they copy
On Mon, 06 Aug 2007 13:01:28 -0500
Jon Loeliger [EMAIL PROTECTED] wrote:
On Sun, 2007-08-05 at 23:53, David Gibson wrote:
+ *
+ * To build:
+ * dtc -I dts -O asm -o bamboo.S -b 0 bamboo.dts
+ * dtc -I dts -O dtb -o bamboo.dtb -b 0 bamboo.dts
Can we ditch this to build
Hello.
David Gibson wrote:
Index: working-2.6/Documentation/powerpc/booting-without-of.txt
===
--- working-2.6.orig/Documentation/powerpc/booting-without-of.txt
2007-07-30 17:07:14.0 +1000
+++
The network address is passed to OF as (part of) the device
argument for the network device; and colons aren't legal
characters in a device argument,
yeah, pretty thoughtless of the IETF for not consulting the 1275WG. :)
Heh. That's not an issue; it just means that OF implementations
need
Second issue as reported earilier allmodconfig fails to build on imac
g3.
CC arch/powerpc/kernel/lparmap.s
AS arch/powerpc/kernel/head_64.o
lparmap.c: Assembler messages:
lparmap.c:84: Error: file number 1 already allocated
make[1]: *** [arch/powerpc/kernel/head_64.o] Blad 1
Maybe the best solution would be for 824[15] to not claim compatibility
with 8250 at all then.
Or at least it should have a more specific entry for this
special 16x50 UART, and that one should be probed first.
If the device tree contains an entry that matches
what the generic driver looks
This patch adds the appropriate ethtool hooks to allow for enabling/disabling
of hypervisor assisted checksum offload for TCP.
Signed-off-by: Brian King [EMAIL PROTECTED]
---
linux-2.6-bjking1/drivers/net/ibmveth.c | 118 +++-
Add ethtool hooks to ibmveth to retrieve driver statistics.
Signed-off-by: Brian King [EMAIL PROTECTED]
---
drivers/net/ibmveth.c | 53 +-
1 file changed, 52 insertions(+), 1 deletion(-)
diff -puN
+ PIC8259: interrupt-controller {
+ device_type = i8259;
device_type = interrupt-controller.
Is that really right? The MPIC binding, at least, has device_type =
open-pic rather than interrupt-controller.
I got confused. open-pic as device_type
Removes dead frag processing code from ibmveth. Since NETIF_F_SG was
not set, this code was never executed. Also, since the ibmveth
interface can only handle 6 fragments, core networking code would need
to be modified in order to efficiently enable this support.
Signed-off-by: Brian King [EMAIL
+ MPIC: [EMAIL PROTECTED] {
+ device_type = open-pic;
device_type = interrupt-controller.
Not according to the binding in booting-without-of.txt
My understanding here, though possibly flawed, is that the current
implementation has open-pic but _should_ have
It seems to me a flat device tree could leave out all those
properties that can be derived from the PVR (except for the
few that are really useful for bootloaders and such -- cache
line size, 64-bit-or-not, what kind of MMU). Linux doesn't
use it anyway. Existing DTSs already leave away
However, the interrupt mapping spec says that all interrupt
controller (regardless of device_type) must have a
property named interrupt-controller to identify
the device node as an interrupt controller and root of
a interrupt tree.
See:
O That's of course the smarter choice, _if_ we have a choice at
all -- on PowerPC, the PCI setup on certain platforms is done
by the firmware (and we don't want to mess with it for various
reasons), and some _do_ map PCI legacy I/O at 0.
Not in this case though, so let's just ignore that
+ - compatible : should contain the specific model of flash
chip(s) used
+ followed by either cfi-flash or jedec-flash
This compatible prop (and the node in whole) doesn't say a thing
about how the flash is mapped into the CPU address space.
...and it shouldn't. That's what
+ UIC0: interrupt-controller0 {
+ compatible = ibm,uic-440gp,ibm,uic;
The first compatible entry should always be the precise model, so in
this case ibm,uic-440epx. If it is (supposed to be) identical to
the UIC in the 440GP, it can also have an ibm,uic-440gp entry, but
since I
+ - compatible : should contain the specific model of flash
chip(s) used
+ followed by either cfi-flash or jedec-flash
This compatible prop (and the node in whole) doesn't say a
thing about how the flash is mapped into the CPU address space. I
strongly disagree that this
To be honest, I'm not sure that describing the mapping is really the
job of the compatible property. That the flash is mapped into the
address space is kind of implicit in the way the reg interacts with
the parents' ranges property.
Ah, I keep forgetting about implied 1:1 parent/child
+ - compatible : should contain the specific model of flash
chip(s) used
+ followed by either cfi-flash or jedec-flash
Duh, have nearly forgotten to complain about -flash suffix.
Isn't it superfluous?
No, it describes what kind of thing this is. cfi and jedec
don't say
Aha! Ok, now I understand the sorts of situations you're talking
about. By not direct mapped, I thought you were talking about some
kind of access via address/data registers on some indirect bus
controller, rather than weird variations on endianness and
bit-swizzling.
Hrm.. this is a
bit-swizzling or something which can be defined to describe some odd
connections. If absent we'd default to direct mapping. Segher, is
that idea going to cause you to scream?
Actually, checking for the presence of all possible perverted
mapping
props doesn't seem a good idea -- it's
Hello guys,
I'm just writting to know if someone have some opinion about the patch I
sent a week ago. I'm not sending it again cause I'm traveling and don't
have it here in this machine.
Tks,
Rodrigo (BSDaemon).___
Linuxppc-dev mailing list
Second issue as reported earilier allmodconfig fails to build on imac
g3.
CC arch/powerpc/kernel/lparmap.s
AS arch/powerpc/kernel/head_64.o
lparmap.c: Assembler messages:
lparmap.c:84: Error: file number 1 already allocated
make[1]: *** [arch/powerpc/kernel/head_64.o] Blad 1
Okay before you add to the nvramrc you also need to add probe-all to build the
device tree first; I assumed this was common knowledge.
probe-all
/pci/isa/8042 find-device
8042 encode-string device-type
install-console
banner
That should do it. Without probe-all/install-console/banner in the
On Mon, 2007-08-06 at 15:51 +0200, Olaf Hering wrote:
On Mon, Aug 06, Benjamin Herrenschmidt wrote:
BTW. Any reason why you don't set the DMA mask in the ohci driver rather
than the sbp2 one ?
I used this patch, and the attached CD was found.
What dma mask should be used in
2) The fix was in the wrong place anyway, if it was going to be done
anywhere
at all it needs to be in
arch/powerpc/kernel/prom_init.c:fixup_device_tree_chrp()
like the ISA ranges breakage (which is on Briq) and IDE IRQ
misnumbering fix.
Not the keyboard platform driver.
Yeah. In the
powerpc has a couple of bugs in the usage of dma_masks that tend to
break when drivers explicitely try to set a 32 bits mask for example.
First the code that generates the pci devices from the OF device-tree
doesn't initialize the mask properly, then our implementation of
set_dma_mask() was
+ max-speed-hz = bebc20; /* 1250 Hz
*/
Just max-speed.
Segher, how is this different from:
http://ozlabs.org/pipermail/linuxppc-dev/2007-April/034557.html
Not sure what you mean. I'm just saying that speed-hz is a
terrible name, I'm not saying that
On Mon, 2007-08-06 at 20:04 +0200, Segher Boessenkool wrote:
That's of course the smarter choice, _if_ we have a choice at
all -- on PowerPC, the PCI setup on certain platforms is done
by the firmware (and we don't want to mess with it for various
reasons), and some _do_ map PCI legacy I/O at
Benjamin Herrenschmidt wrote:
Oh and, don't do the set_dma_mask() in sbp2, it has nothing to do there.
It should be in the ohci1394 driver.
That's not quite right. OHCI-1394 implementations can go beyond 4GB bus
address space. (Although I don't know if there are such implementations
Paul Mackerras wrote:
diff --git a/arch/powerpc/mm/slb.c b/arch/powerpc/mm/slb.c
A couple of hunks fail in this file when applying to the current tree.
...
diff --git a/include/asm-powerpc/mmu-hash64.h
b/include/asm-powerpc/mmu-hash64.h
index 695962f..053f86b 100644
---
On Tue, 2007-08-07 at 00:22 +0200, Stefan Richter wrote:
Benjamin Herrenschmidt wrote:
Oh and, don't do the set_dma_mask() in sbp2, it has nothing to do there.
It should be in the ohci1394 driver.
That's not quite right. OHCI-1394 implementations can go beyond 4GB bus
address space.
On Tue, Aug 07, Benjamin Herrenschmidt wrote:
powerpc has a couple of bugs in the usage of dma_masks that tend to
break when drivers explicitely try to set a 32 bits mask for example.
First the code that generates the pci devices from the OF device-tree
doesn't initialize the mask properly,
On Mon, 2007-08-06 at 16:25 -0600, Robert Hancock wrote:
Anyway. For now I will simply go with what 2.6.23-rc has and what
2.6.21 had: No dma_set_mask anywhere in the 1394 subsystem. We can
revisit this whenever an actual need arises.
Not sure this is a very good idea. This seems
Robert Hancock wrote:
Stefan Richter wrote:
So that's the story why that dma_set_mask went into sbp2: Sbp2 wants
mappings in a _subset_ of the OHCI-1394 controllers DMA range.
Anyway. For now I will simply go with what 2.6.23-rc has and what
2.6.21 had: No dma_set_mask anywhere in the
Robert Hancock wrote:
I would agree, though, that sbp2 isn't really the place for setting
this, since the DMA mask is presently a property of the device, not of
the user..
The mask that sbp2 set was because sbp2 has (in theory, not yet in
practice) a _narrower requirement on address ranges
Benjamin Herrenschmidt wrote:
On Mon, 2007-08-06 at 16:25 -0600, Robert Hancock wrote:
Anyway. For now I will simply go with what 2.6.23-rc has and what
2.6.21 had: No dma_set_mask anywhere in the 1394 subsystem. We can
revisit this whenever an actual need arises.
Not sure this is a very
Actually, checking for the presence of all possible perverted
mapping
props doesn't seem a good idea -- it's simpler to check for the
presence of
one prop (like direct-mapped I was thinking about, or maybe
simple-map).
Or more simply... if it's not a direct mapping, it doesn't have a
It seems like things go wrong when lparmap.s is generated with
(DWARF) debug info; could you try building it (manually) with -g0
added on the end of the compile line, and see if head_64.o compiles
okay for you then? If so, I'll prepare a proper patch for it, I
have a similar one (also for
Stefan Richter wrote:
Benjamin Herrenschmidt wrote:
Oh and, don't do the set_dma_mask() in sbp2, it has nothing to do there.
It should be in the ohci1394 driver.
That's not quite right. OHCI-1394 implementations can go beyond 4GB bus
address space. (Although I don't know if there are such
On Mon, Aug 06, 2007 at 10:20:01PM +0200, Segher Boessenkool wrote:
+ - compatible : should contain the specific model of flash
chip(s) used
+ followed by either cfi-flash or jedec-flash
This compatible prop (and the node in whole) doesn't say a
thing about how the flash
On Mon, Aug 06, 2007 at 07:39:02AM -0500, Josh Boyer wrote:
On Mon, Aug 06, 2007 at 03:00:12PM +1000, David Gibson wrote:
On Fri, Aug 03, 2007 at 11:09:10AM -0500, Josh Boyer wrote:
Add a bootwrapper for the AMCC 440EP Bamboo Eval board. This also adds a
common fixup_clock function for
On Mon, Aug 06, 2007 at 07:36:03AM -0500, Josh Boyer wrote:
On Mon, Aug 06, 2007 at 02:38:55PM +1000, David Gibson wrote:
On Fri, Aug 03, 2007 at 11:09:04AM -0500, Josh Boyer wrote:
-#define SPRN_DBCR0 0x134
-#define DBCR0_RST_SYSTEM 0x3000
+#define
On Mon, Aug 06, 2007 at 07:31:44AM -0500, Josh Boyer wrote:
On Sat, Aug 04, 2007 at 05:45:38PM +1000, David Gibson wrote:
On Fri, Aug 03, 2007 at 11:09:02AM -0500, Josh Boyer wrote:
Remove some leftover cruft in the 40x Kconfig file. Also make sure we
select WANT_DEVICE_TREE for 40x.
On Mon, Aug 06, 2007 at 10:35:57PM +0200, Segher Boessenkool wrote:
To be honest, I'm not sure that describing the mapping is really the
job of the compatible property. That the flash is mapped into the
address space is kind of implicit in the way the reg interacts with
the parents'
On Mon, Aug 06, 2007 at 10:54:33PM +0200, Segher Boessenkool wrote:
Aha! Ok, now I understand the sorts of situations you're talking
about. By not direct mapped, I thought you were talking about some
kind of access via address/data registers on some indirect bus
controller, rather than
On Mon, Aug 06, 2007 at 10:15:39PM +0200, Segher Boessenkool wrote:
+ UIC0: interrupt-controller0 {
+ compatible = ibm,uic-440gp,ibm,uic;
The first compatible entry should always be the precise model, so in
this case ibm,uic-440epx. If it is (supposed to be) identical to
the
On Mon, Aug 06, 2007 at 07:08:25PM -0500, Josh Boyer wrote:
On Mon, Aug 06, 2007 at 06:10:29PM -0300, [EMAIL PROTECTED] wrote:
Hello guys,
I'm just writting to know if someone have some opinion about the patch I
sent a week ago. I'm not sending it again cause I'm traveling and don't
57 matches
Mail list logo
