From: Arnd Bergmann <arnd@arndb.de>
To: Gabriele Paoloni <gabriele.paoloni@huawei.com>
Cc: "devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
"lorenzo.pieralisi@arm.com" <lorenzo.pieralisi@arm.com>,
"benh@kernel.crashing.org" <benh@kernel.crashing.org>,
"minyard@acm.org" <minyard@acm.org>,
"gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>,
"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
John Garry <john.garry@huawei.com>,
"will.deacon@arm.com" <will.deacon@arm.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Yuanzhichang <yuanzhichang@hisilicon.com>,
Linuxarm <linuxarm@huawei.com>,
"xuwei \(O\)" <xuwei5@hisilicon.com>,
"linux-serial@vger.kernel.org" <linux-serial@vger.kernel.org>,
"zhichang.yuan" <zhichang.yuan02@gmail.com>,
"zourongrong@gmail.com" <zourongrong@gmail.com>,
"liviu.dudau@arm.com" <liviu.dudau@arm.com>,
"kantyzc@163.com" <kantyzc@163.com>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH V3 2/4] ARM64 LPC: LPC driver implementation on Hip06
Date: Fri, 23 Sep 2016 17:55:10 +0200 [thread overview]
Message-ID: <1849232.KJrfRPHGN6@wuerfel> (raw)
In-Reply-To: <EE11001F9E5DDD47B7634E2F8A612F2E1F8850F2@lhreml507-mbx>
On Friday, September 23, 2016 2:59:55 PM CEST Gabriele Paoloni wrote:
>
> > > From the perspective of the indirect IO function the input parameter
> > > is an unsigned long addr that (now) can be either:
> > > 1) an IO token coming from a legacy pci device
> > > 2) a phys address that lives on the LPC bus
> > >
> > > These are conceptually two separate address spaces (and actually they
> > > both start from 0).
> >
> > Why? Any IORESOURCE_IO address always refers to the logical I/O port
> > range in Linux, not the physical address that is used on a bus.
>
> If I read the code correctly when you get an I/O token you just add it
> to PCI_IOBASE.
> This is enough since pci_remap_iospace set the virtual address to
> PCI_IOBASE + the I/O token offset; so we can read/write to
> vaddr = PCI_IOBASE + token as pci_remap_iospace has mapped it correctly
> to the respective PCI cpu address (that is set in the I/O range property
> of the host controller)
>
> In the patchset accessors LPC operates directly on the cpu addresses
> and the input parameter of the accessors can be either an IO token or
> a cpu address
>
> +static inline void outb(u8 value, unsigned long addr)
> +{
> +#ifdef CONFIG_ARM64_INDIRECT_PIO
> + if (arm64_extio_ops && arm64_extio_ops->start <= addr &&
> + addr <= arm64_extio_ops->end)
>
> Here below we operate on cpu address
>
> + extio_outb(value, addr);
> + else
> +#endif
I missed this bug earlier, this obviously needs to be
arm64_extio_ops->outb(value, addr - arm64_extio_ops->start);
or possibly
arm64_extio_ops->outb(arm64_extio_ops, value, addr);
as the outb function won't know what the offset is, but
that needed to be fixed regardless.
Arnd
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
WARNING: multiple messages have this Message-ID (diff)
From: Arnd Bergmann <arnd@arndb.de>
To: Gabriele Paoloni <gabriele.paoloni@huawei.com>
Cc: "zhichang.yuan" <zhichang.yuan02@gmail.com>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
"lorenzo.pieralisi@arm.com" <lorenzo.pieralisi@arm.com>,
"minyard@acm.org" <minyard@acm.org>,
"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
"gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>,
John Garry <john.garry@huawei.com>,
"will.deacon@arm.com" <will.deacon@arm.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Yuanzhichang <yuanzhichang@hisilicon.com>,
Linuxarm <linuxarm@huawei.com>,
"xuwei (O)" <xuwei5@hisilicon.com>,
"linux-serial@vger.kernel.org" <linux-serial@vger.kernel.org>,
"benh@kernel.crashing.org" <benh@kernel.crashing.org>
Subject: Re: [PATCH V3 2/4] ARM64 LPC: LPC driver implementation on Hip06
Date: Fri, 23 Sep 2016 17:55:10 +0200 [thread overview]
Message-ID: <1849232.KJrfRPHGN6@wuerfel> (raw)
In-Reply-To: <EE11001F9E5DDD47B7634E2F8A612F2E1F8850F2@lhreml507-mbx>
On Friday, September 23, 2016 2:59:55 PM CEST Gabriele Paoloni wrote:
>
> > > From the perspective of the indirect IO function the input parameter
> > > is an unsigned long addr that (now) can be either:
> > > 1) an IO token coming from a legacy pci device
> > > 2) a phys address that lives on the LPC bus
> > >
> > > These are conceptually two separate address spaces (and actually they
> > > both start from 0).
> >
> > Why? Any IORESOURCE_IO address always refers to the logical I/O port
> > range in Linux, not the physical address that is used on a bus.
>
> If I read the code correctly when you get an I/O token you just add it
> to PCI_IOBASE.
> This is enough since pci_remap_iospace set the virtual address to
> PCI_IOBASE + the I/O token offset; so we can read/write to
> vaddr = PCI_IOBASE + token as pci_remap_iospace has mapped it correctly
> to the respective PCI cpu address (that is set in the I/O range property
> of the host controller)
>
> In the patchset accessors LPC operates directly on the cpu addresses
> and the input parameter of the accessors can be either an IO token or
> a cpu address
>
> +static inline void outb(u8 value, unsigned long addr)
> +{
> +#ifdef CONFIG_ARM64_INDIRECT_PIO
> + if (arm64_extio_ops && arm64_extio_ops->start <= addr &&
> + addr <= arm64_extio_ops->end)
>
> Here below we operate on cpu address
>
> + extio_outb(value, addr);
> + else
> +#endif
I missed this bug earlier, this obviously needs to be
arm64_extio_ops->outb(value, addr - arm64_extio_ops->start);
or possibly
arm64_extio_ops->outb(arm64_extio_ops, value, addr);
as the outb function won't know what the offset is, but
that needed to be fixed regardless.
Arnd
WARNING: multiple messages have this Message-ID (diff)
From: arnd@arndb.de (Arnd Bergmann)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH V3 2/4] ARM64 LPC: LPC driver implementation on Hip06
Date: Fri, 23 Sep 2016 17:55:10 +0200 [thread overview]
Message-ID: <1849232.KJrfRPHGN6@wuerfel> (raw)
In-Reply-To: <EE11001F9E5DDD47B7634E2F8A612F2E1F8850F2@lhreml507-mbx>
On Friday, September 23, 2016 2:59:55 PM CEST Gabriele Paoloni wrote:
>
> > > From the perspective of the indirect IO function the input parameter
> > > is an unsigned long addr that (now) can be either:
> > > 1) an IO token coming from a legacy pci device
> > > 2) a phys address that lives on the LPC bus
> > >
> > > These are conceptually two separate address spaces (and actually they
> > > both start from 0).
> >
> > Why? Any IORESOURCE_IO address always refers to the logical I/O port
> > range in Linux, not the physical address that is used on a bus.
>
> If I read the code correctly when you get an I/O token you just add it
> to PCI_IOBASE.
> This is enough since pci_remap_iospace set the virtual address to
> PCI_IOBASE + the I/O token offset; so we can read/write to
> vaddr = PCI_IOBASE + token as pci_remap_iospace has mapped it correctly
> to the respective PCI cpu address (that is set in the I/O range property
> of the host controller)
>
> In the patchset accessors LPC operates directly on the cpu addresses
> and the input parameter of the accessors can be either an IO token or
> a cpu address
>
> +static inline void outb(u8 value, unsigned long addr)
> +{
> +#ifdef CONFIG_ARM64_INDIRECT_PIO
> + if (arm64_extio_ops && arm64_extio_ops->start <= addr &&
> + addr <= arm64_extio_ops->end)
>
> Here below we operate on cpu address
>
> + extio_outb(value, addr);
> + else
> +#endif
I missed this bug earlier, this obviously needs to be
arm64_extio_ops->outb(value, addr - arm64_extio_ops->start);
or possibly
arm64_extio_ops->outb(arm64_extio_ops, value, addr);
as the outb function won't know what the offset is, but
that needed to be fixed regardless.
Arnd
WARNING: multiple messages have this Message-ID (diff)
From: Arnd Bergmann <arnd@arndb.de>
To: Gabriele Paoloni <gabriele.paoloni@huawei.com>
Cc: "zhichang.yuan" <zhichang.yuan02@gmail.com>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
"lorenzo.pieralisi@arm.com" <lorenzo.pieralisi@arm.com>,
"minyard@acm.org" <minyard@acm.org>,
"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
"gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>,
John Garry <john.garry@huawei.com>,
"will.deacon@arm.com" <will.deacon@arm.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Yuanzhichang <yuanzhichang@hisilicon.com>,
Linuxarm <linuxarm@huawei.com>,
"xuwei (O)" <xuwei5@hisilicon.com>,
"linux-serial@vger.kernel.org" <linux-serial@vger.kernel.org>,
"benh@kernel.crashing.org" <benh@kernel.crashing.org>,
"zourongrong@gmail.com" <zourongrong@gmail.com>,
"liviu.dudau@arm.com" <liviu.dudau@arm.com>,
"kantyzc@163.com" <kantyzc@163.com>
Subject: Re: [PATCH V3 2/4] ARM64 LPC: LPC driver implementation on Hip06
Date: Fri, 23 Sep 2016 17:55:10 +0200 [thread overview]
Message-ID: <1849232.KJrfRPHGN6@wuerfel> (raw)
In-Reply-To: <EE11001F9E5DDD47B7634E2F8A612F2E1F8850F2@lhreml507-mbx>
On Friday, September 23, 2016 2:59:55 PM CEST Gabriele Paoloni wrote:
>
> > > From the perspective of the indirect IO function the input parameter
> > > is an unsigned long addr that (now) can be either:
> > > 1) an IO token coming from a legacy pci device
> > > 2) a phys address that lives on the LPC bus
> > >
> > > These are conceptually two separate address spaces (and actually they
> > > both start from 0).
> >
> > Why? Any IORESOURCE_IO address always refers to the logical I/O port
> > range in Linux, not the physical address that is used on a bus.
>
> If I read the code correctly when you get an I/O token you just add it
> to PCI_IOBASE.
> This is enough since pci_remap_iospace set the virtual address to
> PCI_IOBASE + the I/O token offset; so we can read/write to
> vaddr = PCI_IOBASE + token as pci_remap_iospace has mapped it correctly
> to the respective PCI cpu address (that is set in the I/O range property
> of the host controller)
>
> In the patchset accessors LPC operates directly on the cpu addresses
> and the input parameter of the accessors can be either an IO token or
> a cpu address
>
> +static inline void outb(u8 value, unsigned long addr)
> +{
> +#ifdef CONFIG_ARM64_INDIRECT_PIO
> + if (arm64_extio_ops && arm64_extio_ops->start <= addr &&
> + addr <= arm64_extio_ops->end)
>
> Here below we operate on cpu address
>
> + extio_outb(value, addr);
> + else
> +#endif
I missed this bug earlier, this obviously needs to be
arm64_extio_ops->outb(value, addr - arm64_extio_ops->start);
or possibly
arm64_extio_ops->outb(arm64_extio_ops, value, addr);
as the outb function won't know what the offset is, but
that needed to be fixed regardless.
Arnd
next prev parent reply other threads:[~2016-09-23 15:55 UTC|newest]
Thread overview: 149+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-09-14 12:15 [PATCH V3 0/4] ARM64 LPC: legacy ISA I/O support Zhichang Yuan
2016-09-14 12:15 ` Zhichang Yuan
2016-09-14 12:15 ` Zhichang Yuan
2016-09-14 12:15 ` [PATCH V3 1/4] ARM64 LPC: Indirect ISA port IO introduced Zhichang Yuan
2016-09-14 12:15 ` Zhichang Yuan
2016-09-14 12:15 ` Zhichang Yuan
2016-09-14 12:24 ` Arnd Bergmann
2016-09-14 12:24 ` Arnd Bergmann
2016-09-14 14:16 ` zhichang.yuan
2016-09-14 14:16 ` zhichang.yuan
2016-09-14 14:16 ` zhichang.yuan
2016-09-14 14:23 ` Arnd Bergmann
2016-09-14 14:23 ` Arnd Bergmann
2016-09-14 14:23 ` Arnd Bergmann
2016-09-18 3:38 ` zhichang
2016-09-18 3:38 ` zhichang
2016-09-18 3:38 ` zhichang
2016-09-21 9:26 ` zhichang
2016-09-21 9:26 ` zhichang
2016-09-21 9:26 ` zhichang
2016-09-14 12:15 ` [PATCH V3 2/4] ARM64 LPC: LPC driver implementation on Hip06 Zhichang Yuan
2016-09-14 12:15 ` Zhichang Yuan
2016-09-14 12:15 ` Zhichang Yuan
2016-09-14 12:33 ` Arnd Bergmann
2016-09-14 12:33 ` Arnd Bergmann
2016-09-14 14:50 ` zhichang.yuan
2016-09-14 14:50 ` zhichang.yuan
2016-09-14 14:50 ` zhichang.yuan
2016-09-14 21:32 ` Arnd Bergmann
2016-09-14 21:32 ` Arnd Bergmann
2016-09-15 8:02 ` Gabriele Paoloni
2016-09-15 8:02 ` Gabriele Paoloni
2016-09-15 8:02 ` Gabriele Paoloni
2016-09-15 8:02 ` Gabriele Paoloni
2016-09-15 8:22 ` Arnd Bergmann
2016-09-15 8:22 ` Arnd Bergmann
2016-09-15 8:22 ` Arnd Bergmann
2016-09-15 12:05 ` Gabriele Paoloni
2016-09-15 12:05 ` Gabriele Paoloni
2016-09-15 12:05 ` Gabriele Paoloni
2016-09-15 12:24 ` Arnd Bergmann
2016-09-15 12:24 ` Arnd Bergmann
2016-09-15 12:24 ` Arnd Bergmann
2016-09-15 14:28 ` Gabriele Paoloni
2016-09-15 14:28 ` Gabriele Paoloni
2016-09-15 14:28 ` Gabriele Paoloni
2016-09-21 10:09 ` zhichang
2016-09-21 10:09 ` zhichang
2016-09-21 10:09 ` zhichang
2016-09-21 16:20 ` Gabriele Paoloni
2016-09-21 16:20 ` Gabriele Paoloni
2016-09-21 16:20 ` Gabriele Paoloni
2016-09-21 16:20 ` Gabriele Paoloni
2016-09-21 20:18 ` Arnd Bergmann
2016-09-21 20:18 ` Arnd Bergmann
2016-09-21 20:18 ` Arnd Bergmann
2016-09-21 20:18 ` Arnd Bergmann
2016-09-22 11:55 ` Gabriele Paoloni
2016-09-22 11:55 ` Gabriele Paoloni
2016-09-22 11:55 ` Gabriele Paoloni
2016-09-22 11:55 ` Gabriele Paoloni
2016-09-22 12:14 ` Arnd Bergmann
2016-09-22 12:14 ` Arnd Bergmann
2016-09-22 12:14 ` Arnd Bergmann
2016-09-22 12:14 ` Arnd Bergmann
2016-09-22 14:47 ` Gabriele Paoloni
2016-09-22 14:47 ` Gabriele Paoloni
2016-09-22 14:47 ` Gabriele Paoloni
2016-09-22 14:59 ` Arnd Bergmann
2016-09-22 14:59 ` Arnd Bergmann
2016-09-22 14:59 ` Arnd Bergmann
2016-09-22 15:20 ` Gabriele Paoloni
2016-09-22 15:20 ` Gabriele Paoloni
2016-09-22 15:20 ` Gabriele Paoloni
2016-09-22 15:46 ` zhichang.yuan
2016-09-22 15:46 ` zhichang.yuan
2016-09-22 15:46 ` zhichang.yuan
2016-09-22 16:27 ` zhichang.yuan
2016-09-22 16:27 ` zhichang.yuan
2016-09-22 16:27 ` zhichang.yuan
2016-09-22 16:27 ` zhichang.yuan
2016-09-23 9:51 ` Arnd Bergmann
2016-09-23 9:51 ` Arnd Bergmann
2016-09-23 9:51 ` Arnd Bergmann
2016-09-23 9:51 ` Arnd Bergmann
2016-09-23 10:23 ` Gabriele Paoloni
2016-09-23 10:23 ` Gabriele Paoloni
2016-09-23 10:23 ` Gabriele Paoloni
2016-09-23 13:42 ` Arnd Bergmann
2016-09-23 13:42 ` Arnd Bergmann
2016-09-23 13:42 ` Arnd Bergmann
2016-09-23 14:59 ` Gabriele Paoloni
2016-09-23 14:59 ` Gabriele Paoloni
2016-09-23 14:59 ` Gabriele Paoloni
2016-09-23 15:55 ` Arnd Bergmann [this message]
2016-09-23 15:55 ` Arnd Bergmann
2016-09-23 15:55 ` Arnd Bergmann
2016-09-23 15:55 ` Arnd Bergmann
2016-09-24 8:14 ` zhichang
2016-09-24 8:14 ` zhichang
2016-09-24 8:14 ` zhichang
2016-09-24 21:00 ` Arnd Bergmann
2016-09-24 21:00 ` Arnd Bergmann
2016-09-24 21:00 ` Arnd Bergmann
2016-09-24 21:00 ` Arnd Bergmann
2016-09-26 13:21 ` Gabriele Paoloni
2016-09-26 13:21 ` Gabriele Paoloni
2016-09-26 13:21 ` Gabriele Paoloni
2016-09-26 13:21 ` Gabriele Paoloni
2016-09-24 8:00 ` zhichang
2016-09-24 8:00 ` zhichang
2016-09-24 8:00 ` zhichang
2016-09-24 8:00 ` zhichang
2016-10-02 22:03 ` Jon Masters
2016-10-02 22:03 ` Jon Masters
2016-10-02 22:03 ` Jon Masters
2016-10-02 22:03 ` Jon Masters
2016-10-04 12:02 ` John Garry
2016-10-04 12:02 ` John Garry
2016-10-04 12:02 ` John Garry
2016-10-06 0:18 ` Benjamin Herrenschmidt
2016-10-06 0:18 ` Benjamin Herrenschmidt
2016-10-06 0:18 ` Benjamin Herrenschmidt
2016-10-06 13:31 ` John Garry
2016-10-06 13:31 ` John Garry
2016-10-06 13:31 ` John Garry
2016-09-14 14:09 ` kbuild test robot
2016-09-14 14:09 ` kbuild test robot
2016-09-14 14:09 ` kbuild test robot
2016-09-14 12:15 ` [PATCH V3 3/4] ARM64 LPC: support serial based on low-pin-count Zhichang Yuan
2016-09-14 12:15 ` Zhichang Yuan
2016-09-14 12:15 ` Zhichang Yuan
2016-09-14 12:25 ` Arnd Bergmann
2016-09-14 12:25 ` Arnd Bergmann
2016-09-14 12:25 ` Arnd Bergmann
2016-09-14 15:04 ` zhichang.yuan
2016-09-14 15:04 ` zhichang.yuan
2016-09-14 15:04 ` zhichang.yuan
2016-09-14 21:33 ` Arnd Bergmann
2016-09-14 21:33 ` Arnd Bergmann
2016-09-21 10:12 ` zhichang
2016-09-21 10:12 ` zhichang
2016-09-21 10:12 ` zhichang
2016-09-21 19:29 ` Arnd Bergmann
2016-09-21 19:29 ` Arnd Bergmann
2016-09-21 19:29 ` Arnd Bergmann
2016-09-14 12:15 ` [PATCH V3 4/4] ARM64 LPC: support earlycon for UART connected to LPC Zhichang Yuan
2016-09-14 12:15 ` Zhichang Yuan
2016-09-14 12:15 ` Zhichang Yuan
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=1849232.KJrfRPHGN6@wuerfel \
--to=arnd@arndb.de \
--cc=benh@kernel.crashing.org \
--cc=devicetree@vger.kernel.org \
--cc=gabriele.paoloni@huawei.com \
--cc=gregkh@linuxfoundation.org \
--cc=john.garry@huawei.com \
--cc=kantyzc@163.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=linux-serial@vger.kernel.org \
--cc=linuxarm@huawei.com \
--cc=liviu.dudau@arm.com \
--cc=lorenzo.pieralisi@arm.com \
--cc=minyard@acm.org \
--cc=will.deacon@arm.com \
--cc=xuwei5@hisilicon.com \
--cc=yuanzhichang@hisilicon.com \
--cc=zhichang.yuan02@gmail.com \
--cc=zourongrong@gmail.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.