From: Damien Le Moal <dlemoal@kernel.org>
To: Hans de Goede <hdegoede@redhat.com>,
Niklas Cassel <cassel@kernel.org>,
Cryptearth <cryptearth@googlemail.com>
Cc: temnota.am@gmail.com, linux-ide@vger.kernel.org, conikost@gentoo.org
Subject: Re: Fwd: Re[2]: ASMedia ASM1166/ASM1064 port restrictions will break cards with port-multipliers
Date: Tue, 19 Mar 2024 08:59:19 +0900 [thread overview]
Message-ID: <921f2ef8-7afb-4ae3-9f3a-e5b412f590a8@kernel.org> (raw)
In-Reply-To: <b318971e-4748-49e0-a2ae-a1fba9267d82@redhat.com>
On 3/18/24 23:21, Hans de Goede wrote:
>>> But can we please drop the problematic quirk to lower the number
>>> of ports for now, to avoid more people getting bitten by this
>>> regression ?
>>
>> I am strongly against reverting that fix/improvement because of a problem with a
>> badly broken hardware that does not respect the AHCI specifications. Such
>> regression was bound to happen with such hardware and likely will happen again
>> in the future if we touch anything that does not fit with the adapters weird use
>> of PMP or other feature. I do not want libata code to be stuck as it is for fear
>> of breaking support for adapters that are already broken in the first place...
>>
>> So let's go the other way around and add a libata.force parameter that allows
>> disabling the port count fix, or allows specifying a port mask. That will allow
>> users of these broken adapters to get them running again. Ideally, we would use
>> a quirk but it seems that the same controller chip is used in both correct
>> setups and broken-PMP setups. So unless ASMedia indicates some black-magic
>> register we can look at to know what to do, it will have to be a "manual" module
>> parameter.
>
> The kernel has a clear no regressions policy and there is ample documented
> cases where needing to set a module option to undo the regression was
> considered not acceptable.
>
> So there really is no discussion here. We must not regress and thus the default
> behavior must be behavior which works out of the box on the boards with
> the PMP chips on them.
I am well aware of this policy and always work hard to not introduce any
regression or to address them with the highest priority when they happen. It is
however very unfortunate that such policy must be followed even when the
regression is due to some bad hardware that does not correctly follow
specifications and just happen to "work" by chance before a change. I do not
feel that is right, especially considering that in this case, the revert will
cause users with correct hardware to again see very long boot time (minutes order).
> Also we really want Linux to "just work" having to set a module option
> just to make things work very much goes against that.
Sure, but then avoiding the long boot time will still need a module parameter to
force applying a port mask. So it is one or the other here... I vote to support
well good hardware.
Anyway, I am not going to fight this and go with the revert for now. But if we
do not get anything from ASMedia to help resolve this, these broken adapters are
likely to cause issues again in the future. And because of that, I would very
much like to just blacklist them unless someone write a special driver for these
that does not pretend to be AHCI compliant. Because they are not.
--
Damien Le Moal
Western Digital Research
next prev parent reply other threads:[~2024-03-18 23:59 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CAFDm6W19R3KHDO09c94Uwry9mdG+whAVy=u4Sdpt30A2MK1KPA@mail.gmail.com>
2024-03-13 6:36 ` ASMedia ASM1166/ASM1064 port restrictions will break cards with port-multipliers Andrey Melnikov
2024-03-13 17:37 ` Cryptearth
2024-03-13 21:21 ` Hans de Goede
2024-03-13 21:52 ` Re[2]: " Conrad Kostecki
2024-03-13 22:20 ` Hans de Goede
2024-03-16 14:01 ` Andrey Jr. Melnikov
2024-03-17 1:34 ` Cryptearth
2024-03-14 15:58 ` Niklas Cassel
2024-03-15 15:01 ` Hans de Goede
2024-03-16 11:33 ` Cryptearth
2024-03-16 11:45 ` Re[2]: " Conrad Kostecki
[not found] ` <CAFDm6W2nCj+qw=-7Sb9xcJTYZ8sitwUriR+Qdh9fo9+ET1Oo=g@mail.gmail.com>
2024-03-17 22:58 ` Fwd: " Cryptearth
2024-03-17 23:04 ` Christoph Hellwig
[not found] ` <CAFDm6W2X_2Nhn4ZeDd-=6Sra-evDW8Dx_CE0m5yggXpOXNTQ9g@mail.gmail.com>
2024-03-17 23:25 ` Christoph Hellwig
[not found] ` <CAFDm6W3pe+nv5CTcEq2FwGbKS4Cdu+7xdLa1Zy6iODampfwxsw@mail.gmail.com>
2024-03-17 23:48 ` Christoph Hellwig
2024-03-18 10:56 ` Niklas Cassel
2024-03-18 11:07 ` Hans de Goede
2024-03-18 11:31 ` Niklas Cassel
2024-03-18 11:53 ` Damien Le Moal
2024-03-18 14:21 ` Hans de Goede
2024-03-18 23:59 ` Damien Le Moal [this message]
2024-03-17 9:36 ` Niklas Cassel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=921f2ef8-7afb-4ae3-9f3a-e5b412f590a8@kernel.org \
--to=dlemoal@kernel.org \
--cc=cassel@kernel.org \
--cc=conikost@gentoo.org \
--cc=cryptearth@googlemail.com \
--cc=hdegoede@redhat.com \
--cc=linux-ide@vger.kernel.org \
--cc=temnota.am@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).