public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Niklas Cassel <cassel@kernel.org>
To: 李佑鸿 <dayou5941@163.com>
Cc: Damien Le Moal <dlemoal@kernel.org>,
	linux-ide@vger.kernel.org, linux-kernel@vger.kernel.org,
	liyouhong@kylinos.cn
Subject: Re: Re: [PATCH] ata: libahci: fix panic when accessing ports beyond MMIO region
Date: Fri, 24 Apr 2026 13:07:33 +0200	[thread overview]
Message-ID: <aetO9e7Kf5DZK0QH@ryzen> (raw)
In-Reply-To: <13d7d471.6389.19dbe594e14.Coremail.dayou5941@163.com>

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


Kind regards,
Niklas

  parent reply	other threads:[~2026-04-24 11:07 UTC|newest]

Thread overview: 8+ 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 [this message]
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

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=aetO9e7Kf5DZK0QH@ryzen \
    --to=cassel@kernel.org \
    --cc=dayou5941@163.com \
    --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