All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bjorn Helgaas <helgaas@kernel.org>
To: Stanislav Kinsburskii <skinsburskii@linux.microsoft.com>
Cc: ryder.lee@mediatek.com, jianjun.wang@mediatek.com,
	lpieralisi@kernel.org, kw@linux.com, robh@kernel.org,
	bhelgaas@google.com, matthias.bgg@gmail.com,
	angelogioacchino.delregno@collabora.com,
	linux-pci@vger.kernel.org, linux-mediatek@lists.infradead.org,
	linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org, skinsburskii@gmail.com
Subject: Re: [PATCH] PCI: mediatek: Fix sparse warning caused to virt_to_phys() prototype change
Date: Tue, 21 Nov 2023 16:23:25 -0600	[thread overview]
Message-ID: <20231121222325.GA260057@bhelgaas> (raw)
In-Reply-To: <20231121220556.GA21969@skinsburskii.>

On Tue, Nov 21, 2023 at 02:05:56PM -0800, Stanislav Kinsburskii wrote:
> On Tue, Nov 21, 2023 at 03:37:55PM -0600, Bjorn Helgaas wrote:
> > On Mon, Nov 20, 2023 at 03:40:33PM -0800, Stanislav Kinsburskii wrote:
> > > Explicitly cast __iomem pointer to const void* with __force to fix the
> > > following warning:
> > > 
> > >   warning: incorrect type in argument 1 (different address spaces)
> > >      expected void const volatile *address
> > >      got void [noderef] __iomem *
> > 
> > I have two questions about this:
> > 
> >   1) There's no other use of __force in drivers/pci, so I don't know
> >   what's special about pcie-mediatek.c.  There should be a way to fix
> >   the types so it's not needed.
> 
> __force suppreses the following sparse warning:
> 
>     warning: cast removes address space '__iomem' of expression

I'm suggesting that the cast is a band-aid that covers up a type
mismatch, and there shouldn't be a mismatch in the first place.

> >   2) virt_to_phys() is not quite right to begin with because what we
> >   want is a *bus* address, not the CPU physical address we get from
> >   virt_to_phys().  Obviously the current platforms that use this must
> >   not apply any offset between bus and CPU physical addresses, but
> >   it's not something we should rely on.
> > 
> >   There are only three drivers (pci-aardvark.c, pcie-xilinx.c, and
> >   this one) that use virt_to_phys(), and they're all slightly wrong
> >   here.
> > 
> > The *_compose_msi_msg() methods could use a little more consistency
> > across the board.
> 
> Could you elaborate on what do you suggest?
> Should virt_to_phys() be simply removed?

The DMA API (Documentation/core-api/dma-api.rst) is the usual way to
get bus addresses, since an MSI is basically a DMA on the PCI bus.

https://lore.kernel.org/linux-pci/20230914203146.GA77870@bhelgaas/

Nobody is very motivated to fix these, I guess ;)  I sort of hate to
just throw in a cast to shut up the warning because it doesn't really
solve the problem.

> > > Signed-off-by: Stanislav Kinsburskii <skinsburskii@linux.microsoft.com>
> > > ---
> > >  drivers/pci/controller/pcie-mediatek.c |    4 ++--
> > >  1 file changed, 2 insertions(+), 2 deletions(-)
> > > 
> > > diff --git a/drivers/pci/controller/pcie-mediatek.c b/drivers/pci/controller/pcie-mediatek.c
> > > index 66a8f73296fc..27f0f79810a1 100644
> > > --- a/drivers/pci/controller/pcie-mediatek.c
> > > +++ b/drivers/pci/controller/pcie-mediatek.c
> > > @@ -397,7 +397,7 @@ static void mtk_compose_msi_msg(struct irq_data *data, struct msi_msg *msg)
> > >  	phys_addr_t addr;
> > >  
> > >  	/* MT2712/MT7622 only support 32-bit MSI addresses */
> > > -	addr = virt_to_phys(port->base + PCIE_MSI_VECTOR);
> > > +	addr = virt_to_phys((__force const void *)port->base + PCIE_MSI_VECTOR);
> > >  	msg->address_hi = 0;
> > >  	msg->address_lo = lower_32_bits(addr);
> > >  
> > > @@ -520,7 +520,7 @@ static void mtk_pcie_enable_msi(struct mtk_pcie_port *port)
> > >  	u32 val;
> > >  	phys_addr_t msg_addr;
> > >  
> > > -	msg_addr = virt_to_phys(port->base + PCIE_MSI_VECTOR);
> > > +	msg_addr = virt_to_phys((__force const void *)port->base + PCIE_MSI_VECTOR);
> > >  	val = lower_32_bits(msg_addr);
> > >  	writel(val, port->base + PCIE_IMSI_ADDR);


WARNING: multiple messages have this Message-ID (diff)
From: Bjorn Helgaas <helgaas@kernel.org>
To: Stanislav Kinsburskii <skinsburskii@linux.microsoft.com>
Cc: ryder.lee@mediatek.com, jianjun.wang@mediatek.com,
	lpieralisi@kernel.org, kw@linux.com, robh@kernel.org,
	bhelgaas@google.com, matthias.bgg@gmail.com,
	angelogioacchino.delregno@collabora.com,
	linux-pci@vger.kernel.org, linux-mediatek@lists.infradead.org,
	linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org, skinsburskii@gmail.com
Subject: Re: [PATCH] PCI: mediatek: Fix sparse warning caused to virt_to_phys() prototype change
Date: Tue, 21 Nov 2023 16:23:25 -0600	[thread overview]
Message-ID: <20231121222325.GA260057@bhelgaas> (raw)
In-Reply-To: <20231121220556.GA21969@skinsburskii.>

On Tue, Nov 21, 2023 at 02:05:56PM -0800, Stanislav Kinsburskii wrote:
> On Tue, Nov 21, 2023 at 03:37:55PM -0600, Bjorn Helgaas wrote:
> > On Mon, Nov 20, 2023 at 03:40:33PM -0800, Stanislav Kinsburskii wrote:
> > > Explicitly cast __iomem pointer to const void* with __force to fix the
> > > following warning:
> > > 
> > >   warning: incorrect type in argument 1 (different address spaces)
> > >      expected void const volatile *address
> > >      got void [noderef] __iomem *
> > 
> > I have two questions about this:
> > 
> >   1) There's no other use of __force in drivers/pci, so I don't know
> >   what's special about pcie-mediatek.c.  There should be a way to fix
> >   the types so it's not needed.
> 
> __force suppreses the following sparse warning:
> 
>     warning: cast removes address space '__iomem' of expression

I'm suggesting that the cast is a band-aid that covers up a type
mismatch, and there shouldn't be a mismatch in the first place.

> >   2) virt_to_phys() is not quite right to begin with because what we
> >   want is a *bus* address, not the CPU physical address we get from
> >   virt_to_phys().  Obviously the current platforms that use this must
> >   not apply any offset between bus and CPU physical addresses, but
> >   it's not something we should rely on.
> > 
> >   There are only three drivers (pci-aardvark.c, pcie-xilinx.c, and
> >   this one) that use virt_to_phys(), and they're all slightly wrong
> >   here.
> > 
> > The *_compose_msi_msg() methods could use a little more consistency
> > across the board.
> 
> Could you elaborate on what do you suggest?
> Should virt_to_phys() be simply removed?

The DMA API (Documentation/core-api/dma-api.rst) is the usual way to
get bus addresses, since an MSI is basically a DMA on the PCI bus.

https://lore.kernel.org/linux-pci/20230914203146.GA77870@bhelgaas/

Nobody is very motivated to fix these, I guess ;)  I sort of hate to
just throw in a cast to shut up the warning because it doesn't really
solve the problem.

> > > Signed-off-by: Stanislav Kinsburskii <skinsburskii@linux.microsoft.com>
> > > ---
> > >  drivers/pci/controller/pcie-mediatek.c |    4 ++--
> > >  1 file changed, 2 insertions(+), 2 deletions(-)
> > > 
> > > diff --git a/drivers/pci/controller/pcie-mediatek.c b/drivers/pci/controller/pcie-mediatek.c
> > > index 66a8f73296fc..27f0f79810a1 100644
> > > --- a/drivers/pci/controller/pcie-mediatek.c
> > > +++ b/drivers/pci/controller/pcie-mediatek.c
> > > @@ -397,7 +397,7 @@ static void mtk_compose_msi_msg(struct irq_data *data, struct msi_msg *msg)
> > >  	phys_addr_t addr;
> > >  
> > >  	/* MT2712/MT7622 only support 32-bit MSI addresses */
> > > -	addr = virt_to_phys(port->base + PCIE_MSI_VECTOR);
> > > +	addr = virt_to_phys((__force const void *)port->base + PCIE_MSI_VECTOR);
> > >  	msg->address_hi = 0;
> > >  	msg->address_lo = lower_32_bits(addr);
> > >  
> > > @@ -520,7 +520,7 @@ static void mtk_pcie_enable_msi(struct mtk_pcie_port *port)
> > >  	u32 val;
> > >  	phys_addr_t msg_addr;
> > >  
> > > -	msg_addr = virt_to_phys(port->base + PCIE_MSI_VECTOR);
> > > +	msg_addr = virt_to_phys((__force const void *)port->base + PCIE_MSI_VECTOR);
> > >  	val = lower_32_bits(msg_addr);
> > >  	writel(val, port->base + PCIE_IMSI_ADDR);

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2023-11-21 22:23 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-11-20 23:40 [PATCH] PCI: mediatek: Fix sparse warning caused to virt_to_phys() prototype change Stanislav Kinsburskii
2023-11-20 23:40 ` Stanislav Kinsburskii
2023-11-21 21:37 ` Bjorn Helgaas
2023-11-21 21:37   ` Bjorn Helgaas
2023-11-21 22:05   ` Stanislav Kinsburskii
2023-11-21 22:05     ` Stanislav Kinsburskii
2023-11-21 22:23     ` Bjorn Helgaas [this message]
2023-11-21 22:23       ` Bjorn Helgaas
2023-11-21 22:34       ` Stanislav Kinsburskii
2023-11-21 22:34         ` Stanislav Kinsburskii
2023-11-22  4:15         ` Jianjun Wang (王建军)
2023-11-22  4:15           ` Jianjun Wang (王建军)

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=20231121222325.GA260057@bhelgaas \
    --to=helgaas@kernel.org \
    --cc=angelogioacchino.delregno@collabora.com \
    --cc=bhelgaas@google.com \
    --cc=jianjun.wang@mediatek.com \
    --cc=kw@linux.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mediatek@lists.infradead.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=lpieralisi@kernel.org \
    --cc=matthias.bgg@gmail.com \
    --cc=robh@kernel.org \
    --cc=ryder.lee@mediatek.com \
    --cc=skinsburskii@gmail.com \
    --cc=skinsburskii@linux.microsoft.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.