> > * A bug where older revision (CD/CE) MVP3 boards would be detected as
> > VP3. The ID of the AGP bridge has to be checked here, not just the
> > host bridge ID.
>
> It is getting WORSE!!!!!!!!!
> Now we have to parse the north-bridge into pieces also.
Oh, yes. It's always getting worse. The older MVP3's have host bridge ID
597 and AGP bridge ID 8598. The newer have 598 and 8598. VP3's have 597
and 8597.
But I really think we don't need to mess with the northbridges at all,
because they can be combined with almost any southbridge, and yes,
manufacturers were doing that. It doesn't help to know the northbridge
to determine what IDE we have.
> > * Some North/South bridge combinations will not be detected because
> > they're not in the table. Honestly, I think the table should not
> > be used at all and all detection should be based on southbridges
> > only.
>
> No go, there is now way to feature check.
It's not so bad after all. As far as I know the 596a has the 66 MHz bit
wired to 0, and the 596b has it toggle-able. This should allow to tell
them apart. This and/or the PCI revision.
> > * Apollo Pro Plus, (and probably Pro133 and Pro133A) with vt82c596b
> > won't work in UDMA mode. This is because one table entry which assumes
> > that the Pro Plus chipset only comes with the vt82c596a southbridge.
> > I think this is wrong, but can't confirm it. Changing FLAG_NULL
> > to FLAG_ATA66 would make sense here.
>
> That is fine but we need a test extention.
I propose we test the for presence of UDMA33 on 586, 586a and 586b by
checking the revision and for the presence of UDMA66 on all newer models
(UDMA33 must be present) by checking toggleability of the 66 MHz bit.
> > * The thing won't work with arbirtary PCI clocks. To achieve that
> > the big timing tables at the beginning of the file would need to
> > go and be replaced by about 10 lines of code which computes the
> > timing.
>
> I agree, but the stack of defines are ugly.
> The job is yours to fix or trash.
Ok. What 'stack of defines' you refer to? The word 'but' puts some doubt
in.
Please sent the current patch to Linus if you find it acceptable, and
I'll continue working on the rewritten version so that it can replace
the current one later.
> I do not have a setup, it is all blind code off the docs.
> I have never tested the VIA code personally.
> Pretty damn good for never being tested by the author, well on goods it is.
Nice. Btw, I've done a LOT of driver programming (the joystick drivers)
with no hardware and no docs. ;)
-- Vojtech Pavlik SuSE Labs- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/