On Mon, Feb 6, 2012 at 8:19 AM, Tejun Heo [off-list ref] wrote:
Hello,
(cc'ing Jian Peng, hi)
Hello,
Jian Peng is no longer working on this project; I have taken over for his work.
On Mon, Feb 06, 2012 at 12:42:56PM +0800, Lin Ming wrote:
quoted
On Mon, 2012-02-06 at 12:15 +0900, Norbert Preining wrote:
quoted
On Mo, 06 Feb 2012, Lin Ming wrote:
quoted
Only this patch on top of HEAD *without* reverting 7faa33da9b7.
Works. Am I right that it differs from 7faa33da9b7 only in that
the later also changes:
Right.
Tejun,
This regression is caused by 7faa33da9b7(ahci: start engine only during
soft/hard resets).
But I can't reproduce it.
What's your guess?
Urgh.... yeah, following standard can sometimes be silly thing to do.
Jian, I think we'll have to add a flag for your controller and revert
to the original behavior for others. How can your controller be
distinguished?
Our controller utilizes the ahci_platform.c driver and does not have a
distinguishing interface ID (e.g., PCI ID). It is maintained in an
out-of-tree distribution, but we would like to have a
standards-compliant solution in mainline so that we do not have to
support a fork of the main codebase.
Is there any possibility of debugging this regression instead of
effectively reverting it for mainline? Or perhaps can I have better
information regarding the hardware on which this regression is seen?
With some time, I can try to debug it further.
I see the following options:
(1) implement a flag that can be passed through ahci_platform; this
would not be very useful, as we would still have to tweak the driver
out of tree.
(2) Drop the fix entirely. This is a spec. violation, but we can
simply try to maintain the fix out-of-tree.
(3) Debug Norbert's hardware problems.
(1) or (2) aren't ideal, and they are effectively very similar. The
only advantage to (1) is that there will be at least some illusion of
our controller's support in future kernel development.
Brian