From: "李佑鸿 " <dayou5941@163.com>
To: "Niklas Cassel" <cassel@kernel.org>
Cc: "Damien Le Moal" <dlemoal@kernel.org>,
linux-ide@vger.kernel.org, linux-kernel@vger.kernel.org,
liyouhong@kylinos.cn
Subject: Re:Re: Re: [PATCH] ata: libahci: fix panic when accessing ports beyond MMIO region
Date: Sat, 25 Apr 2026 14:15:15 +0800 (CST) [thread overview]
Message-ID: <215c4c47.18f7.19dc347307f.Coremail.dayou5941@163.com> (raw)
In-Reply-To: <aetO9e7Kf5DZK0QH@ryzen>
Hi Niklas, Damien,
At 2026-04-24 19:07:33, "Niklas Cassel" <cassel@kernel.org> wrote:
>On Fri, Apr 24, 2026 at 03:16:56PM +0800, 李佑鸿 wrote:
>> At 2026-04-24 10:43:11, "Damien Le Moal" <dlemoal@kernel.org> wrote:
>> >
>> >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.
>
>I agree.
>E.g. both AMD and Intel make sure that the AHCI controller PCI device does
>not show up on the PCI bus if you disable it using the BIOS.
>
>It would have been nice if the Phytium BIOS also worked like that.
>
>
>> 3. **BAR Size Mismatch**: `CAP.NP` indicates more ports than physically fit in the BAR
>> - If CAP claims 32 ports but BAR is only 4KB, this is physically impossible
>> - 32 ports require at least 0x1100 bytes (0x100 + 32 * 0x80)
>
>The reason why I did not suggest failing the probe() originally, was because
>李佑鸿 sent a patch with a Fixes tag, so I assumed that he considered it a
>regression, and wanted the hardware to continue working, even though it was
>marked as disabled in BIOS, because that is how it was before the commit in
>the Fixes tag was introduced.
>
>That said, I fully agree that I think it is better to modify the AHCI driver
>to fail the probe() for this AHCI controller when it has not been properly
>initialized (because it is marked as disabled in BIOS).
>
>I prefer option 3.
>Look at CAP.NP and look at the BAR size, if it is too small, just fail the
>probe().
Thank you for the clear direction. I agree that checking BAR size against
CAP.NP is the cleanest solution.
I will prepare a v2 patch implementing this check:
1. In ahci_init_one(), after mapping MMIO but before any port access.
2. Calculate: required_size = 0x100 + (CAP.NP * 0x80).
3. Compare with pci_resource_len(pdev, 5).
4. If required_size > BAR size, fail probe with -ENODEV and clear error.
The patch will include:
- A new ahci_validate_bar_size() helper function
- Clear error message: "AHCI: BAR5 too small for %u ports..."
I'll send the v2 patch shortly.
Best regards,
liyouhong>
>
>Kind regards,
>Niklas
next prev parent reply other threads:[~2026-04-25 6:15 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
[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 ` 李佑鸿 [this message]
[not found] ` <26f59adf.571d.19dbe310f41.Coremail.dayou5941@163.com>
2026-04-24 11:07 ` Re: " 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=215c4c47.18f7.19dc347307f.Coremail.dayou5941@163.com \
--to=dayou5941@163.com \
--cc=cassel@kernel.org \
--cc=dlemoal@kernel.org \
--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