Re: libata-sff/pata_cmd64x problem with hardwired configurations

[James Bottomley <James.Bottomley@HansenPartnership.com>]

On Mon, 2011-04-18 at 14:12 +0400, Sergei Shtylyov wrote:
> Hello.
> 
> On 18-04-2011 3:58, James Bottomley wrote:
> 
> > I've got a parisc system where the DVD drive is hardwired to a silicon
> > image controller:
> 
> > 00:02.0 IDE interface: Silicon Image, Inc. SiI 0649 Ultra ATA/100 PCI to
> > ATA Host Controller (rev 02) (prog-if 8f [Master SecP SecO PriP PriO])
> >          Subsystem: Silicon Image, Inc. SiI 0649 Ultra ATA/100 PCI to ATA
> > Host Controller
> >          Flags: bus master, medium devsel, latency 64, IRQ 69
> >          I/O ports at 0d18 [size=8]
> >          I/O ports at 0d24 [size=4]
> >          I/O ports at 0d10 [size=8]
> >          I/O ports at 0d20 [size=4]
> >          I/O ports at 0d00 [size=16]
> >          Capabilities: [60] Power Management version 2
> >          Kernel driver in use: pata_cmd64x
> 
> > The specific problem is that any access to the registers where the
> > secondary port should be causes an instant fault on the box (I think
> > because the second port just isn't wired up internally, so the memory
> > doesn't respond), so the default libata-sff driver that pata_cmd64x is
> > attached to causes this by insisting on probing both ports.
> 
>     Perhaps the secondary port is disabled (though it's strange that your 
> lspci dump shows I/O resources for both ports allocated).

It's a last minute wedgie into an enterprise system because they wanted
a DVD and there are no SCSI ones ... although why they didn't do USB 

> > I can get all of this working by fixing up all the hard coded knowledge
> > in libata-sff only to use a single port.
> 
> > However, I can't fix the libata-sff driver until I know how to tell
> > there's only one port wired.  Does anyone with cmd649 knowledge have any
> > idea how I might tell this?
> 
>     The secondary port is enabled in the PCI config. space: register 0x51 bit 
> 3 controls this. Unfortunately, pata_cmd64x driver still doesn't check the 
> channel enable bits; the cmd64x driver does though, so it might be worth trying...

So this is the enablebits code in driver/ide that's missing from any of
the libata stuff?  Should this be generic in libata-sff? ... I mean even
on an x86 where arbitrary memory can be poked without consequence,
trying to activate a disabled port will still produce lots of noise.

James