From: Niklas Cassel <cassel@kernel.org>
To: Lennert Buytenhek <kernel@wantstofly.org>
Cc: Damien Le Moal <dlemoal@kernel.org>,
linux-ide@vger.kernel.org, linux-kernel@vger.kernel.org,
Robin Murphy <robin.murphy@arm.com>,
John Garry <john.g.garry@oracle.com>,
Joerg Roedel <jroedel@suse.de>
Subject: Re: [PATCH] ahci: add 43-bit DMA address quirk for ASMedia ASM106x controllers
Date: Thu, 25 Jan 2024 15:06:05 +0100 [thread overview]
Message-ID: <ZbJqzTD9v25SAPmd@x1-carbon> (raw)
In-Reply-To: <ZbJlatnuTMblK9hS@wantstofly.org>
On Thu, Jan 25, 2024 at 03:43:06PM +0200, Lennert Buytenhek wrote:
> On Thu, Jan 25, 2024 at 02:30:14PM +0100, Niklas Cassel wrote:
(snip)
> > > @@ -943,11 +951,19 @@ static int ahci_pci_device_resume(struct device *dev)
> > >
> > > #endif /* CONFIG_PM */
> > >
> > > -static int ahci_configure_dma_masks(struct pci_dev *pdev, int using_dac)
> > > +static int ahci_configure_dma_masks(struct pci_dev *pdev,
> > > + struct ahci_host_priv *hpriv)
> > > {
> > > - const int dma_bits = using_dac ? 64 : 32;
> > > + int dma_bits;
> > > int rc;
> > >
> > > + if (!(hpriv->cap & HOST_CAP_64))
> > > + dma_bits = 32;
> > > + else if (hpriv->flags & AHCI_HFLAG_43BIT_ONLY)
> > > + dma_bits = 43;
> > > + else
> > > + dma_bits = 64;
> > > +
> >
> > I would prefer if you write this as:
> >
> > if (hpriv->cap & HOST_CAP_64) {
> > dma_bits = 64;
> > if (hpriv->flags & AHCI_HFLAG_43BIT_ONLY)
> > dma_bits = 43;
> > } else {
> > dma_bits = 32;
> > }
> >
> > Such that we still require the device to advertize 64 bit support,
> > and the quirk.
> > If the device does not advertize 64, we don't want it to be possible
> > to use a mask >32, even if the quirk flag is set.
>
> Isn't that logic exactly the same as in my version? I.e. in both
> versions, HOST_CAP_64 has to be set and AHCI_HFLAG_43BIT_ONLY has
> to be set for dma_bits to become 43.
>
> (I don't mind doing it your way, I just don't see a functional
> difference between the versions. :-) )
Yes, you are right.
But please change it to not use an inverted check for the flag anyway,
as such pattern has apparently proven to be too complicated for my brain
to interpret correctly already :)
Kind regards,
Niklas
prev parent reply other threads:[~2024-01-25 14:06 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-24 13:54 [PATCH] ahci: add 43-bit DMA address quirk for ASMedia ASM106x controllers Lennert Buytenhek
2024-01-25 13:30 ` Niklas Cassel
2024-01-25 13:43 ` Lennert Buytenhek
2024-01-25 14:06 ` Niklas Cassel [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=ZbJqzTD9v25SAPmd@x1-carbon \
--to=cassel@kernel.org \
--cc=dlemoal@kernel.org \
--cc=john.g.garry@oracle.com \
--cc=jroedel@suse.de \
--cc=kernel@wantstofly.org \
--cc=linux-ide@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=robin.murphy@arm.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).