From: Josua Mayer <josua@solid-run.com>
To: Klaus Kudielka <klaus.kudielka@gmail.com>,
Damien Le Moal <dlemoal@kernel.org>,
Niklas Cassel <cassel@kernel.org>,
Hans de Goede <hdegoede@redhat.com>
Cc: Jon Nettleton <jon@solid-run.com>,
Mikhail Anikin <mikhail.anikin@solid-run.com>,
Yazan Shhady <yazan.shhady@solid-run.com>,
Rabeeh Khoury <rabeeh@solid-run.com>,
"linux-ide@vger.kernel.org" <linux-ide@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2] ata: libahci_platform: support non-consecutive port numbers
Date: Sat, 8 Feb 2025 13:39:47 +0000 [thread overview]
Message-ID: <26f6bc4b-265f-4576-9d34-22d6752c17d6@solid-run.com> (raw)
In-Reply-To: <cb8175c2755557dd6532ee71d1064241a1412ce2.camel@gmail.com>
Am 07.02.25 um 20:45 schrieb Klaus Kudielka:
> On Fri, 2025-02-07 at 11:22 +0000, Josua Mayer wrote:
>> Can you confirm the physical number of sata ports on your board?
>>
> The second port indeed seems not wired on Turris Omnia.
> If the "masking port_map 0x3 -> 0x1" kernel warning had not suddenly appeared, I would not have noticed this at all.
>
>> I would be curious whether in another board that has two ports physically,
>> whether both of them were functional before my patch.
> I don't have such a board, but to me it seems the existing code was made exactly for that case.
I have such a board and tested how it behaves with Linux 6.1.124 from Debian.
I modified the dtb removing the port subnodes from sata nodes and found
just one difference:
- [ 3.225848] ahci-mvebu f10a8000.sata: masking port_map 0x3 -> 0x3
[ 3.225882] ahci-mvebu f10a8000.sata: AHCI 0001.0000 32 slots 2 ports 6 Gbps 0x3 impl platform mode
[ 3.225891] ahci-mvebu f10a8000.sata: flags: 64bit ncq sntf led only pmp fbs pio slum part sxs
...
- [ 3.248678] ahci-mvebu f10e0000.sata: masking port_map 0x3 -> 0x3
[ 3.248714] ahci-mvebu f10e0000.sata: AHCI 0001.0000 32 slots 2 ports 6 Gbps 0x3 impl platform mode
[ 3.248723] ahci-mvebu f10e0000.sata: flags: 64bit ncq sntf led only pmp fbs pio slum part sxs
So, only the masking message goes away.
When connecting drives to each port, both ports per controller were functional
contrary to my intuition.
>
> For reference, my board later reports
> ata2: SATA link down (SStatus 0 SControl 300)
> ata1: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
Thanks!
prev parent reply other threads:[~2025-02-08 13:39 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-01 12:13 Josua Mayer
2025-01-01 13:17 ` Hans de Goede
2025-01-06 5:27 ` Damien Le Moal
2025-02-05 18:03 ` Klaus Kudielka
2025-02-06 1:34 ` Damien Le Moal
2025-02-06 18:42 ` Klaus Kudielka
2025-02-07 11:22 ` Josua Mayer
2025-02-07 19:45 ` Klaus Kudielka
2025-02-08 13:39 ` Josua Mayer [this message]
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=26f6bc4b-265f-4576-9d34-22d6752c17d6@solid-run.com \
--to=josua@solid-run.com \
--cc=cassel@kernel.org \
--cc=dlemoal@kernel.org \
--cc=hdegoede@redhat.com \
--cc=jon@solid-run.com \
--cc=klaus.kudielka@gmail.com \
--cc=linux-ide@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mikhail.anikin@solid-run.com \
--cc=rabeeh@solid-run.com \
--cc=yazan.shhady@solid-run.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
all inboxes | Powered by JetHome®