From: Damien Le Moal <dlemoal@kernel.org>
To: "Niklas Cassel" <cassel@kernel.org>, 李佑鸿 <dayou5941@163.com>
Cc: linux-ide@vger.kernel.org, linux-kernel@vger.kernel.org,
liyouhong@kylinos.cn
Subject: Re: [PATCH] ata: libahci: fix panic when accessing ports beyond MMIO region
Date: Fri, 24 Apr 2026 11:43:11 +0900 [thread overview]
Message-ID: <e4280e3b-b02a-4c4d-97dd-1bd49daad2fd@kernel.org> (raw)
In-Reply-To: <aepUh_p0Jkw0XQ7N@ryzen>
On 4/24/26 02:19, Niklas Cassel wrote:
> Hello liyouhong,
>
> On Thu, Apr 23, 2026 at 05:48:54PM +0800, 李佑鸿 wrote:
>> However, I have already confirmed with the BIOS supplier that when the
>> BIOS disables all SATA ports, it does indeed initialize the values of
>> the HOST_CAP and HOSTPorts_IMPL registers in accordance with the specifications.
>>
>>
>> /* Register values after disabling SATA in BIOS */
>> HOST_CAP (0x00) = 0xffffffff
>> HOST_PORTS_IMPL (0x0c) = 0xffffffff
>> HOST_VERSION (0x10) = 0xffffffff
>> MMIO_SIZE = 4096
>
> I am actually very surprised to see e.g. CAP (0x00) and AHCI VERSION (0x10)
> being uninitialized.
What I am surprised of here is that we even see that device on the PCI bus at
all when it is disabled in the BIOs. If that device is disabled, why are we even
seeing it by scanning the PCI ports ? The adapter should simply not be visible
at all.
Trying to debug register values when we should not even be seeing the device in
the first place does not make sense to me. If anything, I would take a really
big hammer here and try to completely ignore that adapter if we can somehow
detect that it has been in fact disabled in the BIOS. But that detection may be
challenging to do since it seems we are dealing with a very buggy BIOS.
So maybe we should simply warn and exit probe early if we see a PCI BAR size
that is broken.
--
Damien Le Moal
Western Digital Research
next prev parent reply other threads:[~2026-04-24 2:43 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-22 8:03 [PATCH] ata: libahci: fix panic when accessing ports beyond MMIO region dayou5941
2026-04-22 14:36 ` Niklas Cassel
[not found] ` <55809835.8838.19db9be1205.Coremail.dayou5941@163.com>
2026-04-23 17:19 ` Niklas Cassel
2026-04-24 2:43 ` Damien Le Moal [this message]
[not found] ` <13d7d471.6389.19dbe594e14.Coremail.dayou5941@163.com>
2026-04-24 11:07 ` Niklas Cassel
2026-04-24 11:15 ` Damien Le Moal
2026-04-25 6:15 ` Re:Re: " 李佑鸿
[not found] ` <26f59adf.571d.19dbe310f41.Coremail.dayou5941@163.com>
2026-04-24 11:07 ` Niklas Cassel
2026-04-30 0:59 ` kernel test robot
2026-04-30 12:48 ` 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=e4280e3b-b02a-4c4d-97dd-1bd49daad2fd@kernel.org \
--to=dlemoal@kernel.org \
--cc=cassel@kernel.org \
--cc=dayou5941@163.com \
--cc=linux-ide@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=liyouhong@kylinos.cn \
/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