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 - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
