Re: [PATCH #upstream] libata: implement libata.force module parameter

[Tejun Heo <htejun@gmail.com>]

Mark Lord wrote:
> Tejun Heo wrote:
>> This patch implements libata.force module parameter which can
>> selectively override ATA port, link and device configurations
>> including cable type, SATA PHY SPD limit, transfer mode and NCQ.
> ...
>> +    libata.force=    [LIBATA] Force configurations.  The format is comma
>> +            separated list of "[ID:]VAL" where ID is
>> +            PORT[:DEVICE].  PORT and DEVICE are decimal numbers
>> +            matching port, link or device.  Basically, it matches
> ..
> 
> Mmm.. not a NAK, but is there also a way to set/change these on the fly?

What do you mean by 'on the fly'?  While the system is running?  If so,
I think that should be done through other interfaces - pass through,
sysfs, etc...

> I ask because, on my 4-core test system here, libata enumerates
> the ports differently depending upon whether I boot with a 32-bit
> kernel or a 64-bit kernel.
> 
> Major PITA, that, and it's just the kind of thing that spoils
> fixed "PORT:DEVICE" module parameters, too.
> 
> Now mind you, it's more likely the PCI layer that does the reverse
> order thing, but the end result is that my drives/ports are numbered
> differently depending upon which kernel I happen to boot with.

Heck... That's ugly.  libata.force is mainly conceived as debugging /
installation helper, so using fixed PORT is good enough but maybe
allowing bus_id as PORT is useful?  Something like [00:1f.2]:00?

-- 
tejun