All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marek Vasut <marek.vasut@gmail.com>
To: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: linux-pci@vger.kernel.org, Bjorn Helgaas <bhelgaas@google.com>,
	Geert Uytterhoeven <geert+renesas@glider.be>,
	Wolfram Sang <wsa@the-dreams.de>,
	Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>,
	linux-renesas-soc@vger.kernel.org
Subject: Re: [PATCH] PCI: rcar: Always allocate MSI addresses in 32bit space
Date: Wed, 16 Dec 2020 18:49:54 +0100	[thread overview]
Message-ID: <d7279eff-2129-f58c-baed-aa805f26429d@gmail.com> (raw)
In-Reply-To: <20201214160829.GA3623@e121166-lin.cambridge.arm.com>

On 12/14/20 5:08 PM, Lorenzo Pieralisi wrote:
> On Sat, Dec 12, 2020 at 08:13:54PM +0100, Marek Vasut wrote:
>> On 12/10/20 7:11 PM, Lorenzo Pieralisi wrote:
>>
>> [...]
>>
>>>> diff --git a/drivers/pci/controller/pcie-rcar-host.c b/drivers/pci/controller/pcie-rcar-host.c
>>>> index 1194d5f3341b..ac5c7d7573a6 100644
>>>> --- a/drivers/pci/controller/pcie-rcar-host.c
>>>> +++ b/drivers/pci/controller/pcie-rcar-host.c
>>>> @@ -753,7 +753,7 @@ static int rcar_pcie_enable_msi(struct rcar_pcie_host *host)
>>>>    	}
>>>>    	/* setup MSI data target */
>>>> -	msi->pages = __get_free_pages(GFP_KERNEL, 0);
>>>> +	msi->pages = __get_free_pages(GFP_KERNEL | GFP_DMA32, 0);
>>>
>>> This does not do what you want on !CONFIG_ZONE_DMA32 (ie arm LPAE).
>>
>> How come? I would expect GFP_DMA32 allocates a buffer below 4 GiB in any
>> case.
> 
> For ARM LPAE allocation falls back to ZONE_NORMAL that happens to work
> because if there is memory > 4GB it ends up in ZONE_HIGHMEM, so this
> patch should still work on ARM LPAE too.
> 
> Regardless, thoughts above the alternative approach (that saves you
> a page allocation) ?

Since this is a bugfix, I would prefer it to be minimal.

Also, in case there was some yet undiscovered hardware bug which would 
let the MSI write through, having unused memory as the MSI destination 
address would only lead to write into that memory -- instead of a write 
into some other address.

Changing this to some hard-coded address (any suggestions?) can be a 
subsequent patch.

  reply	other threads:[~2020-12-16 18:05 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-16 12:04 [PATCH] PCI: rcar: Always allocate MSI addresses in 32bit space marek.vasut
2020-10-20  7:47 ` Geert Uytterhoeven
2020-10-25 15:37   ` Marek Vasut
2020-10-27 12:04 ` Yoshihiro Shimoda
2020-12-10 18:11 ` Lorenzo Pieralisi
2020-12-12 19:13   ` Marek Vasut
2020-12-14 16:08     ` Lorenzo Pieralisi
2020-12-16 17:49       ` Marek Vasut [this message]
2020-12-21 10:01         ` Lorenzo Pieralisi
2020-12-30 12:47           ` Marek Vasut
2021-01-04 12:21             ` Lorenzo Pieralisi
2021-01-15 12:12 ` Lorenzo Pieralisi

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=d7279eff-2129-f58c-baed-aa805f26429d@gmail.com \
    --to=marek.vasut@gmail.com \
    --cc=bhelgaas@google.com \
    --cc=geert+renesas@glider.be \
    --cc=linux-pci@vger.kernel.org \
    --cc=linux-renesas-soc@vger.kernel.org \
    --cc=lorenzo.pieralisi@arm.com \
    --cc=wsa@the-dreams.de \
    --cc=yoshihiro.shimoda.uh@renesas.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.