All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sergio Paracuellos <sergio.paracuellos@gmail.com>
To: Arnd Bergmann <arnd@arndb.de>
Cc: linux-pci <linux-pci@vger.kernel.org>,
	Bjorn Helgaas <bhelgaas@google.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	linux-staging@lists.linux.dev,
	gregkh <gregkh@linuxfoundation.org>,
	Liviu Dudau <Liviu.Dudau@arm.com>, Rob Herring <robh@kernel.org>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Subject: Re: [PATCH v3] PCI: of: Avoid pci_remap_iospace() when PCI_IOBASE not defined
Date: Fri, 24 Sep 2021 18:45:43 +0200	[thread overview]
Message-ID: <CAMhs-H_hGeGZN_-1GhkhD5wahSoJFd+PrEMXx3C7zvJireJ=xg@mail.gmail.com> (raw)
In-Reply-To: <CAK8P3a36jiomsqSr0rP8_BL8HwceKvV78bT2Ym+iomSGyYuOGA@mail.gmail.com>

Hi Arnd,

On Fri, Sep 24, 2021 at 3:28 PM Arnd Bergmann <arnd@arndb.de> wrote:
>
> On Fri, Sep 24, 2021 at 2:46 PM Sergio Paracuellos
> <sergio.paracuellos@gmail.com> wrote:
> > On Fri, Sep 24, 2021 at 1:39 PM Arnd Bergmann <arnd@arndb.de> wrote:
> > > On Fri, Sep 24, 2021 at 12:15 PM Sergio Paracuellos
> >
> > > I meant RALINK_PCI_IOBASE. We do need to write both, to clarify:
> > >
> > > RALINK_PCI_IOBASE must be set to match the *bus* address in DT,
> > > so ideally '0', but any value should work as long as these two match.
> > >
> > > PCI_IOBASE/mips_io_port_base must be set to the *CPU* address
> > > in DT, so that must be 0x1e160000, possibly converted from
> > > physical to a virtual __iomem address (this is where my MIPS
> > > knowledge ends).
> >
> > Understood. I have tried the following:
> >
> > I have added the following at the beggining of the pci host driver to
> > match what you are describing above:
> >
> > unsigned long vaddr = (unsigned long)ioremap(PCI_IOBASE, 0x10000);
> > set_io_port_base(vaddr);
> >
> > dev_info(dev, "Setting base to PCI_IOBASE: 0x%x -> mips_io_port_base
> > 0x%lx", PCI_IOBASE, mips_io_port_base);
> >
> > PCI_IOBASE is the physical cpu address. Hence, 0x1e160000
> > set_io_port_base sets 'mips_io_port_base' to the virtual address where
> > 'PCI_IOBASE' has been mapped (vaddr).
>
> Ok, sounds good. I would still suggest using
> "#define PCI_IOBASE mips_io_port_base", so it has the same meaning
> as on other architectures (the virtual address of port 0), and replace
> the hardcoded base with the CPU address you read from DT to
> make that code more portable. As a general rule, DT-enabled drivers
> should contain no hardcoded addresses.

Yes, it must be cleaned. I was only explaining a possible way to proceed.

So, the changes would be:
1) Reverting already added two commits in staging-tree [0] and [1].
(two revert patches)
2) Setting PCI_IOBASE to 'mips_io_port_base' so the spaces.h become: (one patch)

$ cat arch/mips/include/asm/mach-ralink/spaces.h
/* SPDX-License-Identifier: GPL-2.0 */
#ifndef __ASM_MACH_RALINK_SPACES_H_
#define __ASM_MACH_RALINK_SPACES_H_

#define PCI_IOBASE    mips_io_port_base
#define PCI_IOSIZE    SZ_16M
#define IO_SPACE_LIMIT  (PCI_IOSIZE - 1)

#include <asm/mach-generic/spaces.h>
#endif

3) Change the value written in RALINK_PCI_IOBASE to be sure the value
written takes into account address before linux port translation (one
patch):

pcie_write(pcie, entry->res->start - entry->offset, RALINK_PCI_IOBASE);

4) Virtually Map cpu physical address 0x1e160000 and set
'mips_io_port_base' to that virtual address. Something like the
following (one patch):

static int mt7621_set_io(struct device *dev)
{
    struct device_node *node = dev->of_node;
    struct of_pci_range_parser parser;
    struct of_pci_range range;
    unsigned long vaddr;
    int ret = -EINVAL;

    ret = of_pci_range_parser_init(&parser, node);
    if (ret)
        return ret;

    for_each_of_pci_range(&parser, &range) {
        switch (range.flags & IORESOURCE_TYPE_BITS) {
        case IORESOURCE_IO:
            vaddr = (unsigned long)ioremap(range.cpu_addr, range.size);
            set_io_port_base(vaddr);
            ret = 0;
            break;
        }
    }

    return ret;
}

static int mt7621_pci_probe(struct platform_device *pdev)
{
  ...
    err = mt7621_set_io(dev);
    if (err) {
        dev_err(dev, "error setting io\n");
        return err;
    }
...
    return 0;
}

And now my concerns:
1) We have to read DT range IO values in the driver and those values
will be also parsed by core apis but converting them to linux io
ports. Should this be done by the driver or is there a better way to
abstract this to don't do things twice?
2) 'set_io_port_base()' function does what we want but it is only
mips. We already have the iocu stuff there and the driver is mips
anyway, but it is worth to comment this just in case.

Thoughts?

Thanks in advance for your time.

Best regards,
    Sergio Paracuellos

>
> > However, nothing seems to change:
> >
> > mt7621-pci 1e140000.pcie: Setting base to PCI_IOBASE: 0x1e160000 ->
> > mips_io_port_base 0xbe160000
> >                                                 ^^^
> >                                                  This seems aligned
> > with what you are saying. mips_io_port_base have now a proper virtual
> > addr for 0x1e160000
>
> Ok.
>
>             Arnd

  reply	other threads:[~2021-09-24 16:45 UTC|newest]

Thread overview: 47+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-22  4:20 [PATCH v3] PCI: of: Avoid pci_remap_iospace() when PCI_IOBASE not defined Sergio Paracuellos
2021-09-22 15:47 ` Arnd Bergmann
2021-09-22 15:47   ` Arnd Bergmann
2021-09-22 17:42   ` Sergio Paracuellos
2021-09-22 17:42     ` Sergio Paracuellos
2021-09-22 18:07     ` Arnd Bergmann
2021-09-22 18:07       ` Arnd Bergmann
2021-09-22 18:40       ` Sergio Paracuellos
2021-09-22 18:40         ` Sergio Paracuellos
2021-09-22 19:57         ` Arnd Bergmann
2021-09-22 19:57           ` Arnd Bergmann
2021-09-22 20:55           ` Sergio Paracuellos
2021-09-22 20:55             ` Sergio Paracuellos
2021-09-23  5:51             ` Arnd Bergmann
2021-09-23  5:51               ` Arnd Bergmann
2021-09-23  6:36               ` Sergio Paracuellos
2021-09-23  6:36                 ` Sergio Paracuellos
2021-09-23  9:07                 ` Arnd Bergmann
2021-09-23  9:07                   ` Arnd Bergmann
2021-09-23 11:08                   ` Sergio Paracuellos
2021-09-23 11:08                     ` Sergio Paracuellos
2021-09-23 13:26                     ` Arnd Bergmann
2021-09-23 13:26                       ` Arnd Bergmann
2021-09-23 14:55                       ` Sergio Paracuellos
2021-09-23 14:55                         ` Sergio Paracuellos
2021-09-23 17:55                         ` Arnd Bergmann
2021-09-23 17:55                           ` Arnd Bergmann
2021-09-23 20:32                           ` Sergio Paracuellos
2021-09-23 20:32                             ` Sergio Paracuellos
2021-09-24  8:53                             ` Arnd Bergmann
2021-09-24  8:53                               ` Arnd Bergmann
2021-09-24 10:15                               ` Sergio Paracuellos
2021-09-24 10:15                                 ` Sergio Paracuellos
2021-09-24 11:39                                 ` Arnd Bergmann
2021-09-24 11:39                                   ` Arnd Bergmann
2021-09-24 12:46                                   ` Sergio Paracuellos
2021-09-24 12:46                                     ` Sergio Paracuellos
2021-09-24 13:27                                     ` Arnd Bergmann
2021-09-24 13:27                                       ` Arnd Bergmann
2021-09-24 16:45                                       ` Sergio Paracuellos [this message]
2021-09-24 16:45                                         ` Sergio Paracuellos
2021-09-24 16:47                                         ` Sergio Paracuellos
2021-09-24 16:47                                           ` Sergio Paracuellos
2021-09-24 17:04                                         ` Arnd Bergmann
2021-09-24 17:04                                           ` Arnd Bergmann
2021-09-24 17:15                                           ` Sergio Paracuellos
2021-09-24 17:15                                             ` Sergio Paracuellos

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='CAMhs-H_hGeGZN_-1GhkhD5wahSoJFd+PrEMXx3C7zvJireJ=xg@mail.gmail.com' \
    --to=sergio.paracuellos@gmail.com \
    --cc=Liviu.Dudau@arm.com \
    --cc=arnd@arndb.de \
    --cc=bhelgaas@google.com \
    --cc=catalin.marinas@arm.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=linux-staging@lists.linux.dev \
    --cc=robh@kernel.org \
    --cc=tsbogend@alpha.franken.de \
    /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.