quoted hunk
Ok, i should have something working. adding here both sven2-dale.diff which is
a patch against linux-2.5-mv643xx-enet and sven2.diff which is a patch against
2.6.11.
There is still a bit of cleanup needed in arch/ppc/platforms/mv643xx_eth_pegasos.c
especially with regard the headers, and also the proper copyright/attibution
of it (since dale wrote it and i just pasted it and did the detection stuff
benh mentioned above.
I am unsure also about the :
@@ -44,6 +44,9 @@
#include <asm/pgtable.h>
#include <asm/system.h>
#include <asm/delay.h>
+#ifdef PPC_MULTIPLATEFORM
+#include <mv64x60.h>
+#endif
#include "mv643xx_eth.h"
/*
hunk. dale can you check it ?
Looks broken...
Comments are welcome, in particular benh, i guess my detection code will beak
horribly if there is another host node prior to the marvell one in the OF
tree, which is not the case currently on pegasos though.
Why are you looking at vid/did ? Isn't there some name string (model,
compatible, whatever) you can use ? Or is your OF too bad to even give
such info ?
You can also iterate after the find_devices() using np->next
Ben.
On Wed, Mar 09, 2005 at 09:31:26AM +1100, Benjamin Herrenschmidt wrote:
quoted
Ok, i should have something working. adding here both sven2-dale.diff which is
a patch against linux-2.5-mv643xx-enet and sven2.diff which is a patch against
2.6.11.
There is still a bit of cleanup needed in arch/ppc/platforms/mv643xx_eth_pegasos.c
especially with regard the headers, and also the proper copyright/attibution
of it (since dale wrote it and i just pasted it and did the detection stuff
benh mentioned above.
I am unsure also about the :
@@ -44,6 +44,9 @@
#include <asm/pgtable.h>
#include <asm/system.h>
#include <asm/delay.h>
+#ifdef PPC_MULTIPLATEFORM
+#include <mv64x60.h>
+#endif
#include "mv643xx_eth.h"
/*
hunk. dale can you check it ?
Looks broken...
Yep, removed it.
quoted
Comments are welcome, in particular benh, i guess my detection code will beak
horribly if there is another host node prior to the marvell one in the OF
tree, which is not the case currently on pegasos though.
Why are you looking at vid/did ? Isn't there some name string (model,
compatible, whatever) you can use ? Or is your OF too bad to even give
such info ?
You can also iterate after the find_devices() using np->next
Well, I have this :
vendor-id 0x11AB (4523)
device-id 0x6460 (25696)
revision-id 0x3 (3)
class-code 0x60000 (393216)
subsystem-id 0x0 (0)
subsystem-vendor-id 0x0 (0)
.vendor-name "Marvell"
.part-number "MV6436x"
.description "System Controller for PowerPC Processors"
.class "Bridge Device"
.subclass "Host/PCI"
devsel-speed 0x0 (0)
min-grant 0x0 (0)
max-latency 0x0 (0)
name "host"
reg 0:0
assigned-addresses
In the /pci/host node, i also have :
model "Pegasos2"
In the root node, and in the new OF, we even have a /discovery2/port@1 or
something such, but it is unreleased yet.
The thing is not that there is no info, just to chose which info is best.
Christoph suggested to not do that though, but use the normal pci stuff and
match on the host pci id with pci_dev_present. This is what i was thinking of
doing too, and may be more logical, no ?
Friendly,
Sven Luther
On Wed, 2005-03-09 at 08:17 +0100, Sven Luther wrote:
vendor-id 0x11AB (4523)
device-id 0x6460 (25696)
revision-id 0x3 (3)
class-code 0x60000 (393216)
subsystem-id 0x0 (0)
subsystem-vendor-id 0x0 (0)
.vendor-name "Marvell"
.part-number "MV6436x"
.description "System Controller for PowerPC Processors"
.class "Bridge Device"
.subclass "Host/PCI"
devsel-speed 0x0 (0)
min-grant 0x0 (0)
max-latency 0x0 (0)
name "host"
reg 0:0
assigned-addresses
Ok, teach them the interest in having a "model" and "compatible"
property in them for their next version...
In the /pci/host node, i also have :
model "Pegasos2"
In the root node, and in the new OF, we even have a /discovery2/port@1 or
something such, but it is unreleased yet.
Ugh ? What is that supposed to be ?
If it's an ethernet port, it should be called "ethernet".
The thing is not that there is no info, just to chose which info is best.
Christoph suggested to not do that though, but use the normal pci stuff and
match on the host pci id with pci_dev_present. This is what i was thinking of
doing too, and may be more logical, no ?
Yah, if there is no meaningful OF name, then probably.
Ben.
On Wed, Mar 09, 2005 at 06:39:27PM +1100, Benjamin Herrenschmidt wrote:
On Wed, 2005-03-09 at 08:17 +0100, Sven Luther wrote:
quoted
vendor-id 0x11AB (4523)
device-id 0x6460 (25696)
revision-id 0x3 (3)
class-code 0x60000 (393216)
subsystem-id 0x0 (0)
subsystem-vendor-id 0x0 (0)
.vendor-name "Marvell"
.part-number "MV6436x"
.description "System Controller for PowerPC Processors"
.class "Bridge Device"
.subclass "Host/PCI"
devsel-speed 0x0 (0)
min-grant 0x0 (0)
max-latency 0x0 (0)
name "host"
reg 0:0
assigned-addresses
Ok, teach them the interest in having a "model" and "compatible"
property in them for their next version...
You mean a model in /pci/host, ok, i can add that.
quoted
In the /pci/host node, i also have :
model "Pegasos2"
In the root node, and in the new OF, we even have a /discovery2/port@1 or
something such, but it is unreleased yet.
Ugh ? What is that supposed to be ?
As opposed to /ethernet/port1 as it is currently.
If it's an ethernet port, it should be called "ethernet".
In fact, we already did it, it is /discovery2/ethernet@1, which should make
yaboot happy, i think. Not released though.
quoted
The thing is not that there is no info, just to chose which info is best.
Christoph suggested to not do that though, but use the normal pci stuff and
match on the host pci id with pci_dev_present. This is what i was thinking of
doing too, and may be more logical, no ?
Yah, if there is no meaningful OF name, then probably.
Well, if there is both, what is the best way to do this ?
Friendly,
Sven Luther