From: Benjamin Herrenschmidt <benh@kernel.crashing.org> Date: 2007-02-14 05:30:36
2.6.20 has been released and (I think) it is the time of merge-window
for 2.6.21. I want this patch to be merged at this time.
Please tell me if there are anything I should do.
FYI, Jeff, we have merged the rest of the celleb platform support in the
2.6.21 merge window, so it would be annoying if that didn't make it
(that and some spidernet fixes).
Ben.
From: Jeff Garzik <hidden> Date: 2007-02-15 05:08:05
Benjamin Herrenschmidt wrote:
quoted
2.6.20 has been released and (I think) it is the time of merge-window
for 2.6.21. I want this patch to be merged at this time.
Please tell me if there are anything I should do.
FYI, Jeff, we have merged the rest of the celleb platform support in the
2.6.21 merge window, so it would be annoying if that didn't make it
agreed, that's on the list to get pushed
(that and some spidernet fixes).
I'm totally confused about who the heck is the spidernet maintainer. My
inbox is pelted by spidernet driver updates from multiple people, and
often the spidernet patches (regardless of author) receive comments that
give me pause. The MAINTAINERS file says
SPIDERNET NETWORK DRIVER for CELL
P: Jim Lewis
M: jim@jklewis.com
L: netdev@vger.kernel.org
S: Supported
but I do not see patch roll-ups or much activity from him at all. In
practice, it seems like Linas does patchsets for spidernet, but there is
also Jakob Osterkemp(sp?) and Ishizaki and....
My overall impression of spidernet development is that EVERYBODY is
submitting patches at once, and expecting me to sort out the mess. No
thanks.
Speaking with one voice would be much appreciated. And said speaker
should patch the MAINTAINERS file to reflect reality.
Jeff
From: Jeff Garzik <hidden> Date: 2007-02-15 05:12:32
My overall impression of spidernet development is that EVERYBODY is submitting patches at once, and expecting me to sort out the mess. No thanks.
Speaking with one voice would be much appreciated. And said speaker should patch the MAINTAINERS file to reflect reality.
To be specific, I have dropped -all- spidernet patches I had pending in
email, and at the present time there are no unsent spidernet commits in
netdev-2.6.git.
I'll await the resend of any pending patches from the driver maintainer,
once you guys sort out who that is.
Jeff
From: Benjamin Herrenschmidt <benh@kernel.crashing.org> Date: 2007-02-15 07:52:55
On Thu, 2007-02-15 at 00:12 -0500, Jeff Garzik wrote:
quoted
My overall impression of spidernet development is that EVERYBODY is submitting patches at once, and expecting me to sort out the mess. No thanks.
Speaking with one voice would be much appreciated. And said speaker should patch the MAINTAINERS file to reflect reality.
To be specific, I have dropped -all- spidernet patches I had pending in
email, and at the present time there are no unsent spidernet commits in
netdev-2.6.git.
I'll await the resend of any pending patches from the driver maintainer,
once you guys sort out who that is.
From: Benjamin Herrenschmidt <benh@kernel.crashing.org> Date: 2007-02-15 07:54:56
I'm totally confused about who the heck is the spidernet maintainer.
Me too :-)
My
inbox is pelted by spidernet driver updates from multiple people, and
often the spidernet patches (regardless of author) receive comments that
give me pause. The MAINTAINERS file says
quoted
SPIDERNET NETWORK DRIVER for CELL
P: Jim Lewis
M: jim@jklewis.com
L: netdev@vger.kernel.org
S: Supported
but I do not see patch roll-ups or much activity from him at all. In
practice, it seems like Linas does patchsets for spidernet, but there is
also Jakob Osterkemp(sp?) and Ishizaki and....
I think Jens Osterkampf should be the final ACK/NAK'er as he has all the
hardware to test except the Toshiba gear :-) In fact, Jens, if you are
ok with that, I'd like to have you be the maintainer of that driver,
unless you think it's better for Linas to do it.
My overall impression of spidernet development is that EVERYBODY is
submitting patches at once, and expecting me to sort out the mess. No
thanks.
It's been a bit of a mess. I suggest we get our gear together (Linas,
Jens, Kou) and provide you a single patch set from a single source in
the upcoming couple of days coming from the designated maintainer.
Jens ? Linas ? Is that ok with you guys ? Who gets to be that
maintainer ?
_ALSO_ since spidernet uses (and modifies) sungem_phy.c, we need either
DaveM or my ack there (DaveM is sungem maintainer but I wrote sungem_phy
and most of it is only used on powermacs).
Thus let's move that back to the cbe-oss-dev mailing list, our
designated maintainer will post there a candidate patch set, I will
verify the sungem_phy change is ok with powermac (I myself haven't
followed enough to figure out what patch is the latest there), we'll all
test on our respective hardware, and then that maintainer will send you
one patch set to apply.
That shouldn't take more than a few days. If we miss -rc1, well, then it
will be in -rc2, as most of the patches have been around for long enough
etc... it's really mostly a matter of getting our gear together.
Speaking with one voice would be much appreciated. And said speaker
should patch the MAINTAINERS file to reflect reality.
On Thursday 15 February 2007, Benjamin Herrenschmidt wrote:
quoted
I'm totally confused about who the heck is the spidernet maintainer.
Me too :-)
quoted
My
inbox is pelted by spidernet driver updates from multiple people, and
often the spidernet patches (regardless of author) receive comments that
give me pause. The MAINTAINERS file says
quoted
SPIDERNET NETWORK DRIVER for CELL
P: Jim Lewis
M: jim@jklewis.com
L: netdev@vger.kernel.org
S: Supported
but I do not see patch roll-ups or much activity from him at all. In
practice, it seems like Linas does patchsets for spidernet, but there is
also Jakob Osterkemp(sp?) and Ishizaki and....
I think Jens Osterkampf should be the final ACK/NAK'er as he has all the
hardware to test except the Toshiba gear :-) In fact, Jens, if you are
ok with that, I'd like to have you be the maintainer of that driver,
unless you think it's better for Linas to do it.
quoted
My overall impression of spidernet development is that EVERYBODY is
submitting patches at once, and expecting me to sort out the mess. No
thanks.
It's been a bit of a mess. I suggest we get our gear together (Linas,
Jens, Kou) and provide you a single patch set from a single source in
the upcoming couple of days coming from the designated maintainer.
Jens ? Linas ? Is that ok with you guys ? Who gets to be that
maintainer ?
_ALSO_ since spidernet uses (and modifies) sungem_phy.c, we need either
DaveM or my ack there (DaveM is sungem maintainer but I wrote sungem_phy
and most of it is only used on powermacs).
Thus let's move that back to the cbe-oss-dev mailing list, our
designated maintainer will post there a candidate patch set, I will
verify the sungem_phy change is ok with powermac (I myself haven't
followed enough to figure out what patch is the latest there), we'll all
test on our respective hardware, and then that maintainer will send you
one patch set to apply.
That shouldn't take more than a few days. If we miss -rc1, well, then it
will be in -rc2, as most of the patches have been around for long enough
etc... it's really mostly a matter of getting our gear together.
quoted
Speaking with one voice would be much appreciated. And said speaker
should patch the MAINTAINERS file to reflect reality.
Sounds reasonable. I fully agree.
Linas has done a pretty good job on improving the driver in the last half
year or so and he also has access to all the necessary hardware so I think
he would be the right person for the job.
Jens
From: Jim Lewis <hidden> Date: 2007-02-15 16:20:52
We have had some discussions previously about Linas Vepstas taking over
the maintainership of Spidernet from me. I will look into this and see
if we can make it happen.
Jim Lewis
On Thu, 2007-02-15 at 11:41 +0100, Jens Osterkamp wrote:
On Thursday 15 February 2007, Benjamin Herrenschmidt wrote:
quoted
quoted
I'm totally confused about who the heck is the spidernet maintainer.
Me too :-)
quoted
My
inbox is pelted by spidernet driver updates from multiple people, and
often the spidernet patches (regardless of author) receive comments that
give me pause. The MAINTAINERS file says
quoted
SPIDERNET NETWORK DRIVER for CELL
P: Jim Lewis
M: jim@jklewis.com
L: netdev@vger.kernel.org
S: Supported
but I do not see patch roll-ups or much activity from him at all. In
practice, it seems like Linas does patchsets for spidernet, but there is
also Jakob Osterkemp(sp?) and Ishizaki and....
I think Jens Osterkampf should be the final ACK/NAK'er as he has all the
hardware to test except the Toshiba gear :-) In fact, Jens, if you are
ok with that, I'd like to have you be the maintainer of that driver,
unless you think it's better for Linas to do it.
quoted
My overall impression of spidernet development is that EVERYBODY is
submitting patches at once, and expecting me to sort out the mess. No
thanks.
It's been a bit of a mess. I suggest we get our gear together (Linas,
Jens, Kou) and provide you a single patch set from a single source in
the upcoming couple of days coming from the designated maintainer.
Jens ? Linas ? Is that ok with you guys ? Who gets to be that
maintainer ?
_ALSO_ since spidernet uses (and modifies) sungem_phy.c, we need either
DaveM or my ack there (DaveM is sungem maintainer but I wrote sungem_phy
and most of it is only used on powermacs).
Thus let's move that back to the cbe-oss-dev mailing list, our
designated maintainer will post there a candidate patch set, I will
verify the sungem_phy change is ok with powermac (I myself haven't
followed enough to figure out what patch is the latest there), we'll all
test on our respective hardware, and then that maintainer will send you
one patch set to apply.
That shouldn't take more than a few days. If we miss -rc1, well, then it
will be in -rc2, as most of the patches have been around for long enough
etc... it's really mostly a matter of getting our gear together.
quoted
Speaking with one voice would be much appreciated. And said speaker
should patch the MAINTAINERS file to reflect reality.
Sounds reasonable. I fully agree.
Linas has done a pretty good job on improving the driver in the last half
year or so and he also has access to all the necessary hardware so I think
he would be the right person for the job.
Jens
On Thu, Feb 15, 2007 at 11:41:49AM +0100, Jens Osterkamp wrote:
On Thursday 15 February 2007, Benjamin Herrenschmidt wrote:
quoted
quoted
I'm totally confused about who the heck is the spidernet maintainer.
Me too :-)
It's been a bit of a mess. I suggest we get our gear together (Linas,
Jens, Kou) and provide you a single patch set from a single source in
the upcoming couple of days coming from the designated maintainer.
OK.
However, I think the blast of paches is a statistical anomoly,
I'm expecting future activity on spidernet to drop to just about zero.
quoted
Jens ? Linas ? Is that ok with you guys ? Who gets to be that
maintainer ?
Linas has done a pretty good job on improving the driver in the last half
year or so and he also has access to all the necessary hardware so I think
he would be the right person for the job.
It seems I've been nominated twice. Since I'm expecting future activity
to drop to zero, how hard can this be? :-)
I can send a tested patch series (merging all three sources)
immediately, assuming you like the tree these would be based on.
Any special instructions or proceedures to follow, any secret
initiation rites, hazing, or change of citizenship required?
--linas
On Thursday 15 February 2007 18:14, Linas Vepstas wrote:
quoted
Linas has done a pretty good job on improving the driver in the last half
year or so and he also has access to all the necessary hardware so I think
he would be the right person for the job.
It seems I've been nominated twice. Since I'm expecting future activity
to drop to zero, how hard can this be? :-)
I fear that the hardest part is yet to come, when we integrate the
driver for the the PS3 (currently called gelic_net) into spidernet.
The trouble is that the hardware is sufficiently similar to share
all the high-level mechanisms like the DMA data structures and
descriptor chains, but the low-level mechanisms are hidden in the
hypervisor on the PS3. Someone will have to invest a significant
amount of time coordinating this so we don't break celleb and qs20
in the process.
I also think that you'd do a good job doing this, but it may be
more that what you are willing to do without official funding of the
time you spend on it. Of course the actual amount of work will
depend a lot on the quality of the spidernet patches coming from
Sony to the spidernet maintainer.
Arnd <><
On Thu, Feb 15, 2007 at 07:09:25PM +0100, Arnd Bergmann wrote:
On Thursday 15 February 2007 18:14, Linas Vepstas wrote:
quoted
quoted
Linas has done a pretty good job on improving the driver in the last half
year or so and he also has access to all the necessary hardware so I think
he would be the right person for the job.
It seems I've been nominated twice. Since I'm expecting future activity
to drop to zero, how hard can this be? :-)
I fear that the hardest part is yet to come,
Well, then, its a good thing I put a smiley face at the end of the
sentence, eh?
when we integrate the
driver for the the PS3 (currently called gelic_net) into spidernet.
The trouble is that the hardware is sufficiently similar to share
all the high-level mechanisms like the DMA data structures and
descriptor chains, but the low-level mechanisms are hidden in the
hypervisor on the PS3. Someone will have to invest a significant
amount of time coordinating this so we don't break celleb and qs20
in the process.
Since I've got the driver more or less memorized, I don't expect this
to be an intellectual challenge. Which sometimes has the side effect
of my getting bored, and dropping things on the floor.
I also think that you'd do a good job doing this, but it may be
more that what you are willing to do without official funding of the
time you spend on it.
(Ardnt knows that my spidernet work is "moonlighting", off-the-books
work.) I'll ask my employer.
Of course the actual amount of work will
depend a lot on the quality of the spidernet patches coming from
Sony to the spidernet maintainer.
I guess I'll have to ask my employer for a ps3 that I can do
some "research" on.
--linas
From: Benjamin Herrenschmidt <benh@kernel.crashing.org> Date: 2007-02-15 20:52:32
I can send a tested patch series (merging all three sources)
immediately, assuming you like the tree these would be based on.
Any special instructions or proceedures to follow, any secret
initiation rites, hazing, or change of citizenship required?
Just send the blast to our list first so I can verify that the
sungem_phy doesn't adversely affect sungem and everybody (especially Kou
sine you dn't have the Toshiba hardware, do you ?) can verify it all
works fine.
Cheers,
Ben
On Fri, Feb 16, 2007 at 07:46:32AM +1100, Benjamin Herrenschmidt wrote:
quoted
I can send a tested patch series (merging all three sources)
Just send the blast to our list first so I can verify that the
sungem_phy doesn't adversely affect sungem and everybody
By "our list", I assume you mean "linuxppc-dev@ozlabs.org".
I'm going to severely trim the cc list at this point, and
send a patch series of 12 shortly. I'm going to pretend
as if I was maintainer (formalities on this side pending)
and attach a "signed-off-by" to each. Ben, it'll be up to
you to go/no-go; if you say "go", I'll repost to eff Garzik
(right?)
(especially Kou
sine you dn't have the Toshiba hardware, do you ?) can verify it all
works fine.
I don't have Toshiba hardware. FWIW, I also don't have a ps3.
--linas
This version moves the medium variable to the card specific structure and
changes the GMII_* to BCM54XX_* #defines.
This patch adds improved version of enable_fiber for both the 5421 and
the 5461 phy. It is now possible to specify with these wether you want
autonegotiation or not. This is needed for bladecenter switches where
some expect autonegotiation and some dont seem to like this at all.
Depending on this flag it sets phy->autoneg accordingly for the fiber mode.
More importantly it implements proper read_link and poll_link functions
for both phys which can handle both copper and fiber mode by determining
the medium first and then branching to the required functions. For fiber
they all work fine, for copper they are not tested but return the result
of the genmii_* function anyway which is supposed to work.
The patch moves the genmii_* functions around to avoid foreward declarations.
Signed-off-by: Jens Osterkamp <redacted>
Signed-off-by: Arnd Bergmann <redacted>
Signed-off-by: Linas Vepstas <redacted>
----
drivers/net/sungem_phy.c | 389 ++++++++++++++++++++++++++++++-----------------
drivers/net/sungem_phy.h | 10 +
2 files changed, 263 insertions(+), 136 deletions(-)
Index: linux-2.6.20-git4/drivers/net/sungem_phy.c
===================================================================
@@ -311,6 +311,107 @@ static int bcm5411_init(struct mii_phy* return0;}+staticintgenmii_setup_aneg(structmii_phy*phy,u32advertise)+{+u16ctl,adv;++phy->autoneg=1;+phy->speed=SPEED_10;+phy->duplex=DUPLEX_HALF;+phy->pause=0;+phy->advertising=advertise;++/* Setup standard advertise */+adv=phy_read(phy,MII_ADVERTISE);+adv&=~(ADVERTISE_ALL|ADVERTISE_100BASE4);+if(advertise&ADVERTISED_10baseT_Half)+adv|=ADVERTISE_10HALF;+if(advertise&ADVERTISED_10baseT_Full)+adv|=ADVERTISE_10FULL;+if(advertise&ADVERTISED_100baseT_Half)+adv|=ADVERTISE_100HALF;+if(advertise&ADVERTISED_100baseT_Full)+adv|=ADVERTISE_100FULL;+phy_write(phy,MII_ADVERTISE,adv);++/* Start/Restart aneg */+ctl=phy_read(phy,MII_BMCR);+ctl|=(BMCR_ANENABLE|BMCR_ANRESTART);+phy_write(phy,MII_BMCR,ctl);++return0;+}++staticintgenmii_setup_forced(structmii_phy*phy,intspeed,intfd)+{+u16ctl;++phy->autoneg=0;+phy->speed=speed;+phy->duplex=fd;+phy->pause=0;++ctl=phy_read(phy,MII_BMCR);+ctl&=~(BMCR_FULLDPLX|BMCR_SPEED100|BMCR_ANENABLE);++/* First reset the PHY */+phy_write(phy,MII_BMCR,ctl|BMCR_RESET);++/* Select speed & duplex */+switch(speed){+caseSPEED_10:+break;+caseSPEED_100:+ctl|=BMCR_SPEED100;+break;+caseSPEED_1000:+default:+return-EINVAL;+}+if(fd==DUPLEX_FULL)+ctl|=BMCR_FULLDPLX;+phy_write(phy,MII_BMCR,ctl);++return0;+}++staticintgenmii_poll_link(structmii_phy*phy)+{+u16status;++(void)phy_read(phy,MII_BMSR);+status=phy_read(phy,MII_BMSR);+if((status&BMSR_LSTATUS)==0)+return0;+if(phy->autoneg&&!(status&BMSR_ANEGCOMPLETE))+return0;+return1;+}++staticintgenmii_read_link(structmii_phy*phy)+{+u16lpa;++if(phy->autoneg){+lpa=phy_read(phy,MII_LPA);++if(lpa&(LPA_10FULL|LPA_100FULL))+phy->duplex=DUPLEX_FULL;+else+phy->duplex=DUPLEX_HALF;+if(lpa&(LPA_100FULL|LPA_100HALF))+phy->speed=SPEED_100;+else+phy->speed=SPEED_10;+phy->pause=0;+}+/* On non-aneg, we assume what we put in BMCR is the speed,+*thoughmagic-anegshouldn'tpreventthiscasefromoccurring+*/++return0;+}+staticintgeneric_suspend(structmii_phy*phy){phy_write(phy,MII_BMCR,BMCR_PDOWN);
@@ -365,30 +466,6 @@ static int bcm5421_init(struct mii_phy* return0;}-staticintbcm5421_enable_fiber(structmii_phy*phy)-{-/* enable fiber mode */-phy_write(phy,MII_NCONFIG,0x9020);-/* LEDs active in both modes, autosense prio = fiber */-phy_write(phy,MII_NCONFIG,0x945f);--/* switch off fibre autoneg */-phy_write(phy,MII_NCONFIG,0xfc01);-phy_write(phy,0x0b,0x0004);--return0;-}--staticintbcm5461_enable_fiber(structmii_phy*phy)-{-phy_write(phy,MII_NCONFIG,0xfc0c);-phy_write(phy,MII_BMCR,0x4140);-phy_write(phy,MII_NCONFIG,0xfc0b);-phy_write(phy,MII_BMCR,0x0140);--return0;-}-staticintbcm54xx_setup_aneg(structmii_phy*phy,u32advertise){u16ctl,adv;
@@ -516,6 +593,155 @@ static int marvell88e1111_init(struct mireturn0;}+#define BCM5421_MODE_MASK (1 << 5)++staticintbcm5421_poll_link(structmii_phy*phy)+{+u32phy_reg;+intmode;++/* find out in what mode we are */+phy_write(phy,MII_NCONFIG,0x1000);+phy_reg=phy_read(phy,MII_NCONFIG);++mode=(phy_reg&BCM5421_MODE_MASK)>>5;++if(mode==BCM54XX_COPPER)+returngenmii_poll_link(phy);++/* try to find out wether we have a link */+phy_write(phy,MII_NCONFIG,0x2000);+phy_reg=phy_read(phy,MII_NCONFIG);++if(phy_reg&0x0020)+return0;+else+return1;+}++staticintbcm5421_read_link(structmii_phy*phy)+{+u32phy_reg;+intmode;++/* find out in what mode we are */+phy_write(phy,MII_NCONFIG,0x1000);+phy_reg=phy_read(phy,MII_NCONFIG);++mode=(phy_reg&BCM5421_MODE_MASK)>>5;++if(mode==BCM54XX_COPPER)+returnbcm54xx_read_link(phy);++phy->speed=SPEED_1000;++/* find out wether we are running half- or full duplex */+phy_write(phy,MII_NCONFIG,0x2000);+phy_reg=phy_read(phy,MII_NCONFIG);++if((phy_reg&0x0080)>>7)+phy->duplex|=DUPLEX_HALF;+else+phy->duplex|=DUPLEX_FULL;++return0;+}++staticintbcm5421_enable_fiber(structmii_phy*phy,intautoneg)+{+/* enable fiber mode */+phy_write(phy,MII_NCONFIG,0x9020);+/* LEDs active in both modes, autosense prio = fiber */+phy_write(phy,MII_NCONFIG,0x945f);++if(!autoneg){+/* switch off fibre autoneg */+phy_write(phy,MII_NCONFIG,0xfc01);+phy_write(phy,0x0b,0x0004);+}++phy->autoneg=autoneg;++return0;+}++#define BCM5461_FIBER_LINK (1 << 2)+#define BCM5461_MODE_MASK (3 << 1)++staticintbcm5461_poll_link(structmii_phy*phy)+{+u32phy_reg;+intmode;++/* find out in what mode we are */+phy_write(phy,MII_NCONFIG,0x7c00);+phy_reg=phy_read(phy,MII_NCONFIG);++mode=(phy_reg&BCM5461_MODE_MASK)>>1;++if(mode==BCM54XX_COPPER)+returngenmii_poll_link(phy);++/* find out wether we have a link */+phy_write(phy,MII_NCONFIG,0x7000);+phy_reg=phy_read(phy,MII_NCONFIG);++if(phy_reg&BCM5461_FIBER_LINK)+return1;+else+return0;+}++#define BCM5461_FIBER_DUPLEX (1 << 3)++staticintbcm5461_read_link(structmii_phy*phy)+{+u32phy_reg;+intmode;++/* find out in what mode we are */+phy_write(phy,MII_NCONFIG,0x7c00);+phy_reg=phy_read(phy,MII_NCONFIG);++mode=(phy_reg&BCM5461_MODE_MASK)>>1;++if(mode==BCM54XX_COPPER){+returnbcm54xx_read_link(phy);+}++phy->speed=SPEED_1000;++/* find out wether we are running half- or full duplex */+phy_write(phy,MII_NCONFIG,0x7000);+phy_reg=phy_read(phy,MII_NCONFIG);++if(phy_reg&BCM5461_FIBER_DUPLEX)+phy->duplex|=DUPLEX_FULL;+else+phy->duplex|=DUPLEX_HALF;++return0;+}++staticintbcm5461_enable_fiber(structmii_phy*phy,intautoneg)+{+/* select fiber mode, enable 1000 base-X registers */+phy_write(phy,MII_NCONFIG,0xfc0b);++if(autoneg){+/* enable fiber with no autonegotiation */+phy_write(phy,MII_ADVERTISE,0x01e0);+phy_write(phy,MII_BMCR,0x1140);+}else{+/* enable fiber with autonegotiation */+phy_write(phy,MII_BMCR,0x0140);+}++phy->autoneg=autoneg;++return0;+}+staticintmarvell_setup_aneg(structmii_phy*phy,u32advertise){u16ctl,adv;
@@ -646,113 +872,6 @@ static int marvell_read_link(struct mii_return0;}-staticintgenmii_setup_aneg(structmii_phy*phy,u32advertise)-{-u16ctl,adv;--phy->autoneg=1;-phy->speed=SPEED_10;-phy->duplex=DUPLEX_HALF;-phy->pause=0;-phy->advertising=advertise;--/* Setup standard advertise */-adv=phy_read(phy,MII_ADVERTISE);-adv&=~(ADVERTISE_ALL|ADVERTISE_100BASE4);-if(advertise&ADVERTISED_10baseT_Half)-adv|=ADVERTISE_10HALF;-if(advertise&ADVERTISED_10baseT_Full)-adv|=ADVERTISE_10FULL;-if(advertise&ADVERTISED_100baseT_Half)-adv|=ADVERTISE_100HALF;-if(advertise&ADVERTISED_100baseT_Full)-adv|=ADVERTISE_100FULL;-if(advertise&ADVERTISED_Pause)-adv|=ADVERTISE_PAUSE_CAP;-if(advertise&ADVERTISED_Asym_Pause)-adv|=ADVERTISE_PAUSE_ASYM;-phy_write(phy,MII_ADVERTISE,adv);--/* Start/Restart aneg */-ctl=phy_read(phy,MII_BMCR);-ctl|=(BMCR_ANENABLE|BMCR_ANRESTART);-phy_write(phy,MII_BMCR,ctl);--return0;-}--staticintgenmii_setup_forced(structmii_phy*phy,intspeed,intfd)-{-u16ctl;--phy->autoneg=0;-phy->speed=speed;-phy->duplex=fd;-phy->pause=0;--ctl=phy_read(phy,MII_BMCR);-ctl&=~(BMCR_FULLDPLX|BMCR_SPEED100|BMCR_ANENABLE);--/* First reset the PHY */-phy_write(phy,MII_BMCR,ctl|BMCR_RESET);--/* Select speed & duplex */-switch(speed){-caseSPEED_10:-break;-caseSPEED_100:-ctl|=BMCR_SPEED100;-break;-caseSPEED_1000:-default:-return-EINVAL;-}-if(fd==DUPLEX_FULL)-ctl|=BMCR_FULLDPLX;-phy_write(phy,MII_BMCR,ctl);--return0;-}--staticintgenmii_poll_link(structmii_phy*phy)-{-u16status;--(void)phy_read(phy,MII_BMSR);-status=phy_read(phy,MII_BMSR);-if((status&BMSR_LSTATUS)==0)-return0;-if(phy->autoneg&&!(status&BMSR_ANEGCOMPLETE))-return0;-return1;-}--staticintgenmii_read_link(structmii_phy*phy)-{-u16lpa;--if(phy->autoneg){-lpa=phy_read(phy,MII_LPA);--if(lpa&(LPA_10FULL|LPA_100FULL))-phy->duplex=DUPLEX_FULL;-else-phy->duplex=DUPLEX_HALF;-if(lpa&(LPA_100FULL|LPA_100HALF))-phy->speed=SPEED_100;-else-phy->speed=SPEED_10;-phy->pause=(phy->duplex==DUPLEX_FULL)&&-((lpa&LPA_PAUSE)!=0);-}-/* On non-aneg, we assume what we put in BMCR is the speed,-*thoughmagic-anegshouldn'tpreventthiscasefromoccurring-*/--return0;-}--#define MII_BASIC_FEATURES \(SUPPORTED_10baseT_Half|SUPPORTED_10baseT_Full|\SUPPORTED_100baseT_Half|SUPPORTED_100baseT_Full|\
@@ -12,7 +12,7 @@ struct mii_phy_opsint(*setup_forced)(structmii_phy*phy,intspeed,intfd);int(*poll_link)(structmii_phy*phy);int(*read_link)(structmii_phy*phy);-int(*enable_fiber)(structmii_phy*phy);+int(*enable_fiber)(structmii_phy*phy,intautoneg);};/* Structure used to statically define an mii/gii based PHY */
@@ -26,6 +26,14 @@ struct mii_phy_defconststructmii_phy_ops*ops;};+enum{+BCM54XX_COPPER,+BCM54XX_FIBER,+BCM54XX_GBIC,+BCM54XX_SGMII,+BCM54XX_UNKNOWN,+};+/* An instance of a PHY, partially borrowed from mii_if_info */structmii_phy{
Subject: [PATCH 2/12]: spidernet: compile break.
As of 2.6.20-git4, the spider_net driver does not compile.
This appears to be due to some archaic usage involving kobjects.
It also fixes a nasty double-free during ifdown of the interface.
Signed-off-by: Linas Vepstas <redacted>
Cc: Jens Osterkamp <redacted>
Cc: Kou Ishizaki <redacted>
----
drivers/net/spider_net.c | 5 +----
1 file changed, 1 insertion(+), 4 deletions(-)
Index: linux-2.6.20-git4/drivers/net/spider_net.c
===================================================================
@@ -1693,17 +1761,88 @@ alloc_skbs_failed:alloc_rx_failed:spider_net_free_chain(card,&card->tx_chain);alloc_tx_failed:+del_timer_sync(&card->aneg_timer);returnresult;}/**+*spider_net_link_phy+*@data:usedforpointertocardstructure+*+*/+staticvoidspider_net_link_phy(unsignedlongdata)+{+structspider_net_card*card=(structspider_net_card*)data;+structmii_phy*phy=&card->phy;++/* if link didn't come up after SPIDER_NET_ANEG_TIMEOUT tries, setup phy again */+if(card->aneg_count>SPIDER_NET_ANEG_TIMEOUT){++pr_info("%s: link is down trying to bring it up\n",card->netdev->name);++switch(phy->medium){+caseGMII_COPPER:+/* enable fiber with autonegotiation first */+if(phy->def->ops->enable_fiber)+phy->def->ops->enable_fiber(phy,1);+phy->medium=GMII_FIBER;+break;++caseGMII_FIBER:+/* fiber didn't come up, try to disable fiber autoneg */+if(phy->def->ops->enable_fiber)+phy->def->ops->enable_fiber(phy,0);+phy->medium=GMII_UNKNOWN;+break;++caseGMII_UNKNOWN:+/* copper, fiber with and without failed,+*retryfrombeginning*/+spider_net_setup_aneg(card);+phy->medium=GMII_COPPER;+break;+}++card->aneg_count=0;+mod_timer(&card->aneg_timer,jiffies+SPIDER_NET_ANEG_TIMER);+return;+}++/* link still not up, try again later */+if(!(phy->def->ops->poll_link(phy))){+card->aneg_count++;+mod_timer(&card->aneg_timer,jiffies+SPIDER_NET_ANEG_TIMER);+return;+}++/* link came up, get abilities */+phy->def->ops->read_link(phy);++spider_net_write_reg(card,SPIDER_NET_GMACST,+spider_net_read_reg(card,SPIDER_NET_GMACST));+spider_net_write_reg(card,SPIDER_NET_GMACINTEN,0x4);++if(phy->speed==1000)+spider_net_write_reg(card,SPIDER_NET_GMACMODE,0x00000001);+else+spider_net_write_reg(card,SPIDER_NET_GMACMODE,0);++card->aneg_count=0;++pr_debug("Found %s with %i Mbps, %s-duplex %sautoneg.\n",+phy->def->name,phy->speed,phy->duplex==1?"Full":"Half",+phy->autoneg==1?"":"no ");++return;+}++/***spider_net_setup_phy-setupPHY*@card:cardstructure**returns0onsuccess,<0onfailure*-*spider_net_setup_phyisusedaspartofspider_net_probe.Sets-*thePHYto1000Mbps+*spider_net_setup_phyisusedaspartofspider_net_probe.**/staticintspider_net_setup_phy(structspider_net_card*card)
This patch moves calling init_firmware() from spider_net_probe() to
spider_net_open() so as to use the driver by built-in.
Signed-off-by: Kou Ishizaki <redacted>
Signed-off-by: Linas Vepstas <redacted>
----
drivers/net/spider_net.c | 247 +++++++++++++++++++++++------------------------
1 file changed, 123 insertions(+), 124 deletions(-)
Index: linux-2.6.20-git4/drivers/net/spider_net.c
===================================================================
@@ -184,7 +185,8 @@ extern char spider_net_driver_name[];/* pause frames: automatic, no upper retransmission count *//* outside loopback mode: ETOMOD signal dont matter, not connected */-#define SPIDER_NET_OPMODE_VALUE 0x00000063+/* ETOMOD signal is brought to PHY reset. bit 2 must be 1 in Celleb */+#define SPIDER_NET_OPMODE_VALUE 0x00000067/*#define SPIDER_NET_OPMODE_VALUE 0x001b0062*/#define SPIDER_NET_LENLMT_VALUE 0x00000908
This patches removes logging for SPIDER_NET_GTMFLLINT interrupts.
Since the interrupts are not irregular, and they happen frequently
when using 100Mbps network switches.
Signed-off-by: Kou Ishizaki <redacted>
Signed-off-by: Linas Vepstas <redacted>
----
drivers/net/spider_net.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
Index: linux-2.6.20-git4/drivers/net/spider_net.c
===================================================================
@@ -1422,8 +1422,8 @@ spider_net_handle_error_irq(struct spideswitch(i){caseSPIDER_NET_GTMFLLINT:-if(netif_msg_intr(card)&&net_ratelimit())-pr_err("Spider TX RAM full\n");+/* TX RAM full may happen on a usual case.+*Loggingisnotneeded.*/show_error=0;break;caseSPIDER_NET_GRFDFLLINT:/* fallthrough */
@@ -1909,26 +1909,26 @@ static void spider_net_link_phy(unsignedpr_info("%s: link is down trying to bring it up\n",card->netdev->name);-switch(phy->medium){-caseGMII_COPPER:+switch(card->medium){+caseBCM54XX_COPPER:/* enable fiber with autonegotiation first */if(phy->def->ops->enable_fiber)phy->def->ops->enable_fiber(phy,1);-phy->medium=GMII_FIBER;+card->medium=BCM54XX_FIBER;break;-caseGMII_FIBER:+caseBCM54XX_FIBER:/* fiber didn't come up, try to disable fiber autoneg */if(phy->def->ops->enable_fiber)phy->def->ops->enable_fiber(phy,0);-phy->medium=GMII_UNKNOWN;+card->medium=BCM54XX_UNKNOWN;break;-caseGMII_UNKNOWN:+caseBCM54XX_UNKNOWN:/* copper, fiber with and without failed,*retryfrombeginning*/spider_net_setup_aneg(card);-phy->medium=GMII_COPPER;+card->medium=BCM54XX_COPPER;break;}
This patch separates the hardware descriptor state from the
driver descriptor state, per (old) suggestion from Ben Herrenschmidt.
This compiles and boots and seems to work.
Signed-off-by: Linas Vepstas <redacted>
Cc: Jens Osterkamp <redacted>
Cc: Kou Ishizaki <redacted>
----
drivers/net/spider_net.c | 150 ++++++++++++++++++++++++++---------------------
drivers/net/spider_net.h | 16 +++--
2 files changed, 95 insertions(+), 71 deletions(-)
Index: linux-2.6.20-git4/drivers/net/spider_net.h
===================================================================
@@ -25,7 +25,7 @@#ifndef _SPIDER_NET_H#define _SPIDER_NET_H-#define VERSION "1.6 B"+#define VERSION "1.6 C"#include"sungem_phy.h"
@@ -364,8 +364,8 @@ enum spider_net_int2_status {#define SPIDER_NET_DESCR_NOT_IN_USE 0xF0000000#define SPIDER_NET_DESCR_TXDESFLG 0x00800000-structspider_net_descr{-/* as defined by the hardware */+/* Descriptor, as defined by the hardware */+structspider_net_hw_descr{u32buf_addr;u32buf_size;u32next_descr_addr;
@@ -374,13 +374,15 @@ struct spider_net_descr {u32valid_size;/* all zeroes for tx */u32data_status;u32data_error;/* all zeroes for tx */+}__attribute__((aligned(32)));-/* used in the driver */+structspider_net_descr{+structspider_net_hw_descr*hwdescr;structsk_buff*skb;u32bus_addr;structspider_net_descr*next;structspider_net_descr*prev;-}__attribute__((aligned(32)));+};structspider_net_descr_chain{spinlock_tlock;
@@ -464,6 +467,9 @@ struct spider_net_card {structnet_device_statsnetdev_stats;structspider_net_extra_statsspider_stats;structspider_net_optionsoptions;++/* Must be last item in struct */+structspider_net_descrdarray[0];};#define pr_err(fmt,arg...) \
@@ -343,31 +343,34 @@ spider_net_init_chain(struct spider_net_{inti;structspider_net_descr*descr;+structspider_net_hw_descr*hwdescr;dma_addr_tbuf;size_talloc_size;-alloc_size=chain->num_desc*sizeof(structspider_net_descr);+alloc_size=chain->num_desc*sizeof(structspider_net_hw_descr);-chain->ring=dma_alloc_coherent(&card->pdev->dev,alloc_size,+chain->hwring=dma_alloc_coherent(&card->pdev->dev,alloc_size,&chain->dma_addr,GFP_KERNEL);-if(!chain->ring)+if(!chain->hwring)return-ENOMEM;-descr=chain->ring;-memset(descr,0,alloc_size);+memset(chain->ring,0,chain->num_desc*sizeof(structspider_net_descr));/* Set up the hardware pointers in each descriptor */+descr=chain->ring;+hwdescr=chain->hwring;buf=chain->dma_addr;-for(i=0;i<chain->num_desc;i++,descr++){-descr->dmac_cmd_status=SPIDER_NET_DESCR_NOT_IN_USE;+for(i=0;i<chain->num_desc;i++,descr++,hwdescr++){+hwdescr->dmac_cmd_status=SPIDER_NET_DESCR_NOT_IN_USE;+hwdescr->next_descr_addr=0;+descr->hwdescr=hwdescr;descr->bus_addr=buf;-descr->next_descr_addr=0;descr->next=descr+1;descr->prev=descr-1;-buf+=sizeof(structspider_net_descr);+buf+=sizeof(structspider_net_hw_descr);}/* do actual circular list */(descr-1)->next=chain->ring;
@@ -693,30 +698,32 @@ spider_net_prepare_tx_descr(struct spidespin_lock_irqsave(&card->tx_chain.lock,flags);descr=card->tx_chain.head;+hwdescr=descr->hwdescr;card->tx_chain.head=descr->next;-descr->buf_addr=buf;-descr->buf_size=skb->len;-descr->next_descr_addr=0;descr->skb=skb;-descr->data_status=0;+hwdescr->buf_addr=buf;+hwdescr->buf_size=skb->len;+hwdescr->next_descr_addr=0;+hwdescr->data_status=0;-descr->dmac_cmd_status=+hwdescr->dmac_cmd_status=SPIDER_NET_DESCR_CARDOWNED|SPIDER_NET_DMAC_NOCS;spin_unlock_irqrestore(&card->tx_chain.lock,flags);if(skb->protocol==htons(ETH_P_IP))switch(skb->nh.iph->protocol){caseIPPROTO_TCP:-descr->dmac_cmd_status|=SPIDER_NET_DMAC_TCP;+hwdescr->dmac_cmd_status|=SPIDER_NET_DMAC_TCP;break;caseIPPROTO_UDP:-descr->dmac_cmd_status|=SPIDER_NET_DMAC_UDP;+hwdescr->dmac_cmd_status|=SPIDER_NET_DMAC_UDP;break;}/* Chain the bus address, so that the DMA engine finds this descr. */-descr->prev->next_descr_addr=descr->bus_addr;+wmb();+descr->prev->hwdescr->next_descr_addr=descr->bus_addr;card->netdev->trans_start=jiffies;/* set netdev watchdog timer */return0;
@@ -725,16 +732,17 @@ spider_net_prepare_tx_descr(struct spidestaticintspider_net_set_low_watermark(structspider_net_card*card){+structspider_net_descr*descr=card->tx_chain.tail;+structspider_net_hw_descr*hwdescr;unsignedlongflags;intstatus;intcnt=0;inti;-structspider_net_descr*descr=card->tx_chain.tail;/* Measure the length of the queue. Measurement does not*needtobeprecise--doesnotneedalock.*/while(descr!=card->tx_chain.head){-status=descr->dmac_cmd_status&SPIDER_NET_DESCR_NOT_IN_USE;+status=descr->hwdescr->dmac_cmd_status&SPIDER_NET_DESCR_NOT_IN_USE;if(status==SPIDER_NET_DESCR_NOT_IN_USE)break;descr=descr->next;
@@ -753,10 +761,12 @@ spider_net_set_low_watermark(struct spid/* Set the new watermark, clear the old watermark */spin_lock_irqsave(&card->tx_chain.lock,flags);-descr->dmac_cmd_status|=SPIDER_NET_DESCR_TXDESFLG;-if(card->low_watermark&&card->low_watermark!=descr)-card->low_watermark->dmac_cmd_status=-card->low_watermark->dmac_cmd_status&~SPIDER_NET_DESCR_TXDESFLG;+descr->hwdescr->dmac_cmd_status|=SPIDER_NET_DESCR_TXDESFLG;+if(card->low_watermark&&card->low_watermark!=descr){+hwdescr=card->low_watermark->hwdescr;+hwdescr->dmac_cmd_status=+hwdescr->dmac_cmd_status&~SPIDER_NET_DESCR_TXDESFLG;+}card->low_watermark=descr;spin_unlock_irqrestore(&card->tx_chain.lock,flags);returncnt;
@@ -958,17 +970,18 @@ static voidspider_net_pass_skb_up(structspider_net_descr*descr,structspider_net_card*card){+structspider_net_hw_descr*hwdescr=descr->hwdescr;structsk_buff*skb;structnet_device*netdev;u32data_status,data_error;-data_status=descr->data_status;-data_error=descr->data_error;+data_status=hwdescr->data_status;+data_error=hwdescr->data_error;netdev=card->netdev;skb=descr->skb;skb->dev=netdev;-skb_put(skb,descr->valid_size);+skb_put(skb,hwdescr->valid_size);/* the card seems to add 2 bytes of junk in front*oftheethernetframe*/
@@ -1044,9 +1057,10 @@ spider_net_decode_one_descr(struct spide{structspider_net_descr_chain*chain=&card->rx_chain;structspider_net_descr*descr=chain->tail;+structspider_net_hw_descr*hwdescr=descr->hwdescr;intstatus;-status=spider_net_get_descr_status(descr);+status=spider_net_get_descr_status(hwdescr);/* Nothing in the descriptor, or ring must be empty */if((status==SPIDER_NET_DESCR_CARDOWNED)||
@@ -1080,27 +1094,26 @@ spider_net_decode_one_descr(struct spide}/* The cases we'll throw away the packet immediately */-if(descr->data_error&SPIDER_NET_DESTROY_RX_FLAGS){+if(hwdescr->data_error&SPIDER_NET_DESTROY_RX_FLAGS){if(netif_msg_rx_err(card))pr_err("%s: error in received descriptor found, ""data_status=x%08x, data_error=x%08x\n",card->netdev->name,-descr->data_status,descr->data_error);+hwdescr->data_status,hwdescr->data_error);gotobad_desc;}-if(descr->dmac_cmd_status&0xfefe){+if(hwdescr->dmac_cmd_status&0xfefe){pr_err("%s: bad status, cmd_status=x%08x\n",card->netdev->name,-descr->dmac_cmd_status);-pr_err("buf_addr=x%08x\n",descr->buf_addr);-pr_err("buf_size=x%08x\n",descr->buf_size);-pr_err("next_descr_addr=x%08x\n",descr->next_descr_addr);-pr_err("result_size=x%08x\n",descr->result_size);-pr_err("valid_size=x%08x\n",descr->valid_size);-pr_err("data_status=x%08x\n",descr->data_status);-pr_err("data_error=x%08x\n",descr->data_error);-pr_err("bus_addr=x%08x\n",descr->bus_addr);+hwdescr->dmac_cmd_status);+pr_err("buf_addr=x%08x\n",hwdescr->buf_addr);+pr_err("buf_size=x%08x\n",hwdescr->buf_size);+pr_err("next_descr_addr=x%08x\n",hwdescr->next_descr_addr);+pr_err("result_size=x%08x\n",hwdescr->result_size);+pr_err("valid_size=x%08x\n",hwdescr->valid_size);+pr_err("data_status=x%08x\n",hwdescr->data_status);+pr_err("data_error=x%08x\n",hwdescr->data_error);pr_err("which=%ld\n",descr-card->rx_chain.ring);card->spider_stats.rx_desc_error++;
@@ -1109,12 +1122,12 @@ spider_net_decode_one_descr(struct spide/* Ok, we've got a packet in descr */spider_net_pass_skb_up(descr,card);-descr->dmac_cmd_status=SPIDER_NET_DESCR_NOT_IN_USE;+hwdescr->dmac_cmd_status=SPIDER_NET_DESCR_NOT_IN_USE;return1;bad_desc:dev_kfree_skb_irq(descr->skb);-descr->dmac_cmd_status=SPIDER_NET_DESCR_NOT_IN_USE;+hwdescr->dmac_cmd_status=SPIDER_NET_DESCR_NOT_IN_USE;return0;}
It appears that under certain circumstances, a race will result
in a double-free of an skb. This patch null's out the skb pointer
upon the skb free, avoiding the inadvertent deref of bogus data.
The next patch fixes the actual race.
Signed-off-by: Linas Vepstas <redacted>
Cc: Jens Osterkamp <redacted>
Cc: Kou Ishizaki <redacted>
----
drivers/net/spider_net.c | 23 +++++++++++++++--------
1 file changed, 15 insertions(+), 8 deletions(-)
Index: linux-2.6.20-git4/drivers/net/spider_net.c
===================================================================
@@ -1097,7 +1098,7 @@ spider_net_decode_one_descr(struct spideif((status!=SPIDER_NET_DESCR_COMPLETE)&&(status!=SPIDER_NET_DESCR_FRAME_END)){if(netif_msg_rx_err(card))-pr_err("%s: RX descriptor with unkown state %d\n",+pr_err("%s: RX descriptor with unknown state %d\n",card->netdev->name,status);card->spider_stats.rx_desc_unk_state++;gotobad_desc;
You only have the Signed-off-by information here and in the other
patches, but no 'From:' line.
I assume that Jeff uses the git-applymbox tool to import
mails, in which case the first line of the patch description
should be 'From: Someone Else [off-list ref]', unless you
are the author of the patch yourself.
Arnd <><
You only have the Signed-off-by information here and in the other
patches, but no 'From:' line.
I assume that Jeff uses the git-applymbox tool to import
mails, in which case the first line of the patch description
should be 'From: Someone Else [off-list ref]', unless you
are the author of the patch yourself.
Ahh. OK. I was assuming it was the first signed-off-by that counted.
--linas
I fear that the hardest part is yet to come, when we integrate the
driver for the the PS3 (currently called gelic_net) into spidernet.
The trouble is that the hardware is sufficiently similar to share
all the high-level mechanisms like the DMA data structures and
descriptor chains, but the low-level mechanisms are hidden in the
hypervisor on the PS3. Someone will have to invest a significant
amount of time coordinating this so we don't break celleb and qs20
in the process.
That to me implies they should be different drivers using a common
libata-something file. The PPC mac drivers likewise are currently mashed
into one in drivers/ide but really want splitting for libata with some
kind of libata-pmac owning the shared stuff
Alan
From: Benjamin Herrenschmidt <benh@kernel.crashing.org> Date: 2007-02-19 21:26:32
On Mon, 2007-02-19 at 21:56 +0000, Alan wrote:
quoted
I fear that the hardest part is yet to come, when we integrate the
driver for the the PS3 (currently called gelic_net) into spidernet.
The trouble is that the hardware is sufficiently similar to share
all the high-level mechanisms like the DMA data structures and
descriptor chains, but the low-level mechanisms are hidden in the
hypervisor on the PS3. Someone will have to invest a significant
amount of time coordinating this so we don't break celleb and qs20
in the process.
That to me implies they should be different drivers using a common
libata-something file. The PPC mac drivers likewise are currently mashed
into one in drivers/ide but really want splitting for libata with some
kind of libata-pmac owning the shared stuff
You meand driver/ide/ppc/pmac.c ?
This driver is really for one family of IP blocks, the apple ones. They
have the same DMA engine and same taskfile register layout, they only
differ in the timning register format & timing abilities.
However, they also differ in probing mecanism because Apple has been
moving them out of the macio_asic to a PCI device at one point, so yes,
maybe you are right, I should move the DMA bits to some "common" file
and split the various implementations.
Ben.
From: Benjamin Herrenschmidt <benh@kernel.crashing.org> Date: 2007-02-19 21:51:16
On Mon, 2007-02-19 at 21:56 +0000, Alan wrote:
quoted
I fear that the hardest part is yet to come, when we integrate the
driver for the the PS3 (currently called gelic_net) into spidernet.
The trouble is that the hardware is sufficiently similar to share
all the high-level mechanisms like the DMA data structures and
descriptor chains, but the low-level mechanisms are hidden in the
hypervisor on the PS3. Someone will have to invest a significant
amount of time coordinating this so we don't break celleb and qs20
in the process.
That to me implies they should be different drivers using a common
libata-something file. The PPC mac drivers likewise are currently mashed
into one in drivers/ide but really want splitting for libata with some
kind of libata-pmac owning the shared stuff
Also note that for spidernet vs. gelic, I'm actually very tempted to
keep them as separate drivers.
Ben.
into one in drivers/ide but really want splitting for libata with some
kind of libata-pmac owning the shared stuff
You meand driver/ide/ppc/pmac.c ?
Yes
moving them out of the macio_asic to a PCI device at one point, so yes,
maybe you are right, I should move the DMA bits to some "common" file
and split the various implementations.
I suspect it is worth doing when moving to libata at least, even if not
for the older driver.
Alan
into one in drivers/ide but really want splitting for libata with some
kind of libata-pmac owning the shared stuff
You meand driver/ide/ppc/pmac.c ?
Yes
quoted
moving them out of the macio_asic to a PCI device at one point, so yes,
maybe you are right, I should move the DMA bits to some "common" file
and split the various implementations.
I suspect it is worth doing when moving to libata at least, even if not
for the older driver.
From: Benjamin Herrenschmidt <benh@kernel.crashing.org> Date: 2007-02-19 23:22:57
On Mon, 2007-02-19 at 23:46 +0000, Alan wrote:
quoted
quoted
into one in drivers/ide but really want splitting for libata with some
kind of libata-pmac owning the shared stuff
You meand driver/ide/ppc/pmac.c ?
Yes
quoted
moving them out of the macio_asic to a PCI device at one point, so yes,
maybe you are right, I should move the DMA bits to some "common" file
and split the various implementations.
I suspect it is worth doing when moving to libata at least, even if not
for the older driver.
Yup. I don't when I'll have time to "libataify" it though. I need to
look into the best way of handling hotplug with the mediabay for that.
The current hacks are only really suitable for drivers/ide
Ben.
From: Benjamin Herrenschmidt <benh@kernel.crashing.org> Date: 2007-02-19 23:31:59
On Tue, 2007-02-20 at 00:17 +0100, Bartlomiej Zolnierkiewicz wrote:
On Tuesday 20 February 2007 00:46, Alan wrote:
quoted
quoted
quoted
into one in drivers/ide but really want splitting for libata with some
kind of libata-pmac owning the shared stuff
You meand driver/ide/ppc/pmac.c ?
Yes
quoted
moving them out of the macio_asic to a PCI device at one point, so yes,
maybe you are right, I should move the DMA bits to some "common" file
and split the various implementations.
I suspect it is worth doing when moving to libata at least, even if not
for the older driver.
fully agreed, the way to go for both drivers
I don't think it's worth touching the drivers/ide version.
Ben.
I fear that the hardest part is yet to come, when we integrate the
driver for the the PS3 (currently called gelic_net) into spidernet.
The trouble is that the hardware is sufficiently similar to share
all the high-level mechanisms like the DMA data structures and
descriptor chains, but the low-level mechanisms are hidden in the
hypervisor on the PS3. Someone will have to invest a significant
amount of time coordinating this so we don't break celleb and qs20
in the process.
That to me implies they should be different drivers using a common
libata-something file. The PPC mac drivers likewise are currently mashed
into one in drivers/ide but really want splitting for libata with some
kind of libata-pmac owning the shared stuff
FYI, the gelic_net and spidernet drivers Arnd was talking about are _Ethernet_
drivers, not (S)ATA drivers.
That's what happens to the casual reader when the email subjects no longer
match ;-)
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- Sony Network and Software Technology Center Europe (NSCE)
Geert.Uytterhoeven@sonycom.com ------- The Corporate Village, Da Vincilaan 7-D1
Voice +32-2-7008453 Fax +32-2-7008622 ---------------- B-1935 Zaventem, Belgium