Re: [PATCH] libata: remove experimental tag on PATA drivers

[Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>]

On Friday 13 November 2009 19:25:15 Alan Cox wrote:
> > Fine but please update status of following host drivers that were
> > marked as "stable" prematurely by commit e3389cb first:
> > 
> > PATA_PDC_OLD: needs to be marked as EXPERIMENTAL (or just BROKEN)
> > - known reliability problems with UDMA
> 
> A few odd reports apparently linked to specific chip revs. It's at
> least as stable as the old IDE one which doesn't work on my hardware. I'd
> love to get it working on everything but neither driver does and I don't
> think we are likely to ever extract more docs from Promise.

"A few odd reports..." is a big understatement here..

> > PATA_ALI: EXPERIMENTAL
> > - ATAPI DMA is still broken
> 
> Not experimental as we default to not doing ATAPI DMA. Glancing over the

Which is a regression compared to the "old IDE" driver.

> code I notice the ALI C2/C3 workaround probably wants adding to the old
> driver as it can do nasty things otherwise. (See the reset function in
> the pata_ali driver)

Please let the driver's maintainer know about it.

One would wonder why workaround hasn't been back-ported to stable driver
but said one is not familiar with kernel development process' definitions
of such words as "progress", "working with", "consensus" and "technical
honesty".

> > PATA_CMD64X: EXPERIMENTAL
> > - potential data corruption issues remains unfixed for CMD64[3,6]
> 
> Patch in testing, and unlike the old IDE one it doesn't cripple the
> controller but implements the proper workaround in full including
> permitting parallel PIO command streams. I'll push that back through
> stable once done.

This patch is way too complex and risky for -rc, let alone -stable.

> > PATA_SIS: EXPERIMENTAL
> > - missing MWDMA support on newer controllers
> 
> Yes seems someone fixed that in the old driver but didn't forward port

You mean like someone fixed the non-experimental driver back in October
2007 and the author of the experimental one didn't care to port over
the fix for two years?

Indeed a very bad thing and much worse than not porting back fixes from
experimental stuff to a stable code.  As the author of the original fix
I would like to stand corrected and publicly apologize for my negligence.

> it. Trivial and fixed.

I can't see a fix anywhere but I'll assume that I can't look for it
properly (I'm really sorry for it).

> BTW - its wrong in the old driver as far as I can see - it doesn't clip
> the DMA mode to the PIO limit as required by the documentation and the
> ATA standard. Remember the same timings are used for both PIO and MWDMA
> cycles.

Please let the driver's maintainer know.

> > They are all old & known problems and not present in
> > [ "old", "deprecated", "legacy" ] counterparts.
> 
> Which has its own different set of problems.

Which doesn't matter at all here.

Progress is not about replacing one set of slightly buggy drivers
with another slightly buggy one.  At least this was the old definition
of the word..

> Any others spring to mind while you are at it ?

HPA handling related patches that were "being worked on" if you really
would like to know..

-- 
Bartlomiej Zolnierkiewicz