libata: implement libata.force module parameter

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.

For example, you can say "use 1.5Gbps for all fan-out ports attached to the second port but allow 3.0Gbps for the PMP device itself, oh, the device attached to the third fan-out port chokes on NCQ and shouldn't go over UDMA4" by the following.

libata.force=2:1.5g,2.15:3.0g,2.03:noncq,udma4

Signed-off-by Tejun Heo <[email protected]>

---
I guess it's about time we add something like this. More than anything else this should help debugging and can serve as a last resort to work around problems.

Thanks.

 Documentation/kernel-parameters.txt |   35 +++
 drivers/ata/libata-core.c           |  375 +++++++++++++++++++++++++++++++++++-
 drivers/ata/libata-eh.c             |    8 
 drivers/ata/libata.h                |    1 
 4 files changed, 415 insertions(+), 4 deletions(-)

Quoted 17 lines · Tejun Heo

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.

For example, you can say "use 1.5Gbps for all fan-out ports attached to the second port but allow 3.0Gbps for the PMP device itself, oh, the device attached to the third fan-out port chokes on NCQ and shouldn't go over UDMA4" by the following.

libata.force=2:1.5g,2.15:3.0g,2.03:noncq,udma4

Signed-off-by Tejun Heo <[email protected]>

---
I guess it's about time we add something like this. More than anything else this should help debugging and can serve as a last resort to work around problems.

Quoted 7 lines

Thanks.

 Documentation/kernel-parameters.txt |   35 +++
 drivers/ata/libata-core.c           |  375 +++++++++++++++++++++++++++++++++++-
 drivers/ata/libata-eh.c             |    8
 drivers/ata/libata.h                |    1
 4 files changed, 415 insertions(+), 4 deletions(-)

ACK, but it breaks the build due to section type conflicts:

drivers/ata/libata-core.c:108: error: ata_force_param_buf causes a section type conflict

Given that the data is marked __initdata and the code is marked __init, I cannot see the problem.

Quoted 17 lines · Tejun Heo

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.

For example, you can say "use 1.5Gbps for all fan-out ports attached to the second port but allow 3.0Gbps for the PMP device itself, oh, the device attached to the third fan-out port chokes on NCQ and shouldn't go over UDMA4" by the following.

libata.force=2:1.5g,2.15:3.0g,2.03:noncq,udma4

Signed-off-by Tejun Heo <[email protected]>

---
I guess it's about time we add something like this. More than anything else this should help debugging and can serve as a last resort to work around problems.

Quoted 8 lines

Thanks.

Documentation/kernel-parameters.txt | 35 +++
drivers/ata/libata-core.c | 375
+++++++++++++++++++++++++++++++++++-

drivers/ata/libata-eh.c             |    8 
drivers/ata/libata.h                |    1 
4 files changed, 415 insertions(+), 4 deletions(-)

ACK, but it breaks the build due to section type conflicts:

drivers/ata/libata-core.c:108: error: ata_force_param_buf causes a section type conflict

Given that the data is marked __initdata and the code is marked __init, I cannot see the problem.

I have lost the actual patch.
But what you see is what happens when you mix const and non-const data in the same section.

Look for use of __initdata for const data and replace it with __initconst.

And modpost cannot warn about it as gcc errors out before we look at the .o file with modpost.

Quoted 4 lines · Sam Ravnborg

I have lost the actual patch.
But what you see is what happens when you mix const and non-const data in the same section.

Quoted 4 lines

Look for use of __initdata for const data and replace it with __initconst.

And modpost cannot warn about it as gcc errors out before we look at the .o file with modpost.

OIC, thanks. Hmmm... in init.h, I see __{dev|cpu|mem}initconst but no __initconst. The data structure in question is used from module init function tagged properly with __init. What should be done here?

Quoted 17 lines · Tejun Heo

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.

For example, you can say "use 1.5Gbps for all fan-out ports attached to the second port but allow 3.0Gbps for the PMP device itself, oh, the device attached to the third fan-out port chokes on NCQ and shouldn't go over UDMA4" by the following.

libata.force=2:1.5g,2.15:3.0g,2.03:noncq,udma4

Signed-off-by Tejun Heo <[email protected]>

---
I guess it's about time we add something like this. More than anything else this should help debugging and can serve as a last resort to work around problems.

Quoted 8 lines

Thanks.

 Documentation/kernel-parameters.txt |   35 +++
 drivers/ata/libata-core.c           |  375
+++++++++++++++++++++++++++++++++++-
 drivers/ata/libata-eh.c             |    8

drivers/ata/libata.h | 1 4 files changed, 415
insertions(+), 4 deletions(-)

ACK, but it breaks the build due to section type conflicts:

drivers/ata/libata-core.c:108: error: ata_force_param_buf causes a section type conflict

Given that the data is marked __initdata and the code is marked __init, I cannot see the problem.

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.

Quoted 3 lines · Tejun Heo

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.

...

Documentation/kernel-parameters.txt and is between 256 and 4096 characters. It is defined in the file · line 951

Quoted 4 lines

Documentation/kernel-parameters.txt +4 -0

+    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?

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.

Quoted 9 lines · Mark Lord

Quoted 3 lines · Tejun Heo

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.

...

Quoted 4 lines

Documentation/kernel-parameters.txt +4 -0

+    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

Quoted 3 lines

..

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...

Quoted 3 lines

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?

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.

For example, you can say "use 1.5Gbps for all fan-out ports attached to the second port but allow 3.0Gbps for the PMP device itself, oh, the device attached to the third fan-out port chokes on NCQ and shouldn't go over UDMA4" by the following.

libata.force=2:1.5g,2.15:3.0g,2.03:noncq,udma4

Signed-off-by Tejun Heo <[email protected]>

---
Okay, the build failure is dependent on compiler version. 4.1.2 fails but 4.2.1 is okay. I was using 4.2.1 so I didn't know about it. const is dropped from the offending structure and comment is added.

 Documentation/kernel-parameters.txt |   35 +++
 drivers/ata/libata-core.c           |  380 +++++++++++++++++++++++++++++++++++-
 drivers/ata/libata-eh.c             |    8 
 drivers/ata/libata.h                |    1 
 4 files changed, 420 insertions(+), 4 deletions(-)