From: Arnd Bergmann <arnd@arndb.de> To: Rongrong Zou <zourongrong@huawei.com> Cc: linux-arm-kernel@lists.infradead.org, Rongrong Zou <zourongrong@gmail.com>, devicetree@vger.kernel.org, Catalin Marinas <catalin.marinas@arm.com>, Corey Minyard <minyard@acm.org>, gregkh@linuxfoundation.org, Will Deacon <will.deacon@arm.com>, linux-kernel@vger.kernel.org, linuxarm@huawei.com, benh@kernel.crashing.org, liviu.dudau@arm.com Subject: Re: [PATCH v1 3/3] ARM64 LPC: update binding doc Date: Tue, 05 Jan 2016 13:19:48 +0100 [thread overview] Message-ID: <2550495.K9prJVsVEi@wuerfel> (raw) In-Reply-To: <568BB035.1050801@huawei.com> On Tuesday 05 January 2016 19:59:49 Rongrong Zou wrote: > 在 2016/1/5 0:34, Arnd Bergmann 写道: > > On Tuesday 05 January 2016 00:04:19 Rongrong Zou wrote: > >> 在 2016/1/4 19:13, Arnd Bergmann 写道: > >>> On Sunday 03 January 2016 20:24:14 Rongrong Zou wrote: > >>>> 在 2015/12/31 23:00, Rongrong Zou 写道: > >> Ranges property can set empty, but this means 1:1 translation. the I/O > >> port range is translated to MMIO address 0x00000001 00000000 to > >> 0x00000001 00000004, it looks wrong else. I wonder if anyone get legacy > >> I/O port resource from dts. > > > > As I said, nothing should really require the ranges property here, unless > > you have a valid IORESOURCE_MEM translation. The code that requires > > the ranges to be present is wrong. > > > > I think the openfirmware(DT) do not support for those unmapped I/O ports, because I > must get resource by calling of_address_to_resource(), which have to call > pci_address_to_pio() when resource type is IORESOURCE_IO. I'm sorry I have no > better idea for this now. Maybe liviu can give me some opinions. I think on x86 it works (or used to work, few people use open firmware on x86 these days, and it may be broken), and the pci_address_to_pio() call behaves differently when PCI_IOBASE is set. x86 never maps I/O ports into memory mapped I/O addresses, they have their own way of accessing them just like your platform. > /** > * of_address_to_resource - Translate device tree address and return as resource > * > * Note that if your address is a PIO address, the conversion will fail if > * the physical address can't be internally converted to an IO token with > * pci_address_to_pio(), that is because it's either called to early or it > * can't be matched to any host bridge IO space > */ > int of_address_to_resource(struct device_node *dev, int index, > struct resource *r) The problem here seems to be that the code assumes that either the I/O ports are always mapped or they are never mapped (no PCI_IOBASE). We need to extend it because now we can have the combination of the two. > >> For ipmi driver, I can get I/O port resource by DMI rather than dts. > > > > No, the ipmi driver uses the resource that belongs to the platform > > device already, you can't rely on DMI data to be present there. > > Ipmi has a lot of way to be discovered(ACPI, DMI, hardcoded, hot-add, > openfirmware and a few other), I think we just use one of them, not all of them. > It depend on vendor's hardware solution actually. I don't think we should mix multiple methods here: if the bus is described in DT, all its children should be there as well. Otherwise you get into problems e.g. if you have multiple instances of the LPC bus and the Linux I/O addresses for one or more of them have an offset to the bus specific addresses. The bus probe code decides what the Linux I/O port numbers are, but DMI and other methods have no idea of the mapping. As long as there is only one instance, using the first 0x1000 addresses with a 1:1 mapping saves us a bit of trouble, but I'd be worried about relying on that assumption too much. Arnd
WARNING: multiple messages have this Message-ID (diff)
From: arnd@arndb.de (Arnd Bergmann) To: linux-arm-kernel@lists.infradead.org Subject: [PATCH v1 3/3] ARM64 LPC: update binding doc Date: Tue, 05 Jan 2016 13:19:48 +0100 [thread overview] Message-ID: <2550495.K9prJVsVEi@wuerfel> (raw) In-Reply-To: <568BB035.1050801@huawei.com> On Tuesday 05 January 2016 19:59:49 Rongrong Zou wrote: > ? 2016/1/5 0:34, Arnd Bergmann ??: > > On Tuesday 05 January 2016 00:04:19 Rongrong Zou wrote: > >> ? 2016/1/4 19:13, Arnd Bergmann ??: > >>> On Sunday 03 January 2016 20:24:14 Rongrong Zou wrote: > >>>> ? 2015/12/31 23:00, Rongrong Zou ??: > >> Ranges property can set empty, but this means 1:1 translation. the I/O > >> port range is translated to MMIO address 0x00000001 00000000 to > >> 0x00000001 00000004, it looks wrong else. I wonder if anyone get legacy > >> I/O port resource from dts. > > > > As I said, nothing should really require the ranges property here, unless > > you have a valid IORESOURCE_MEM translation. The code that requires > > the ranges to be present is wrong. > > > > I think the openfirmware(DT) do not support for those unmapped I/O ports, because I > must get resource by calling of_address_to_resource(), which have to call > pci_address_to_pio() when resource type is IORESOURCE_IO. I'm sorry I have no > better idea for this now. Maybe liviu can give me some opinions. I think on x86 it works (or used to work, few people use open firmware on x86 these days, and it may be broken), and the pci_address_to_pio() call behaves differently when PCI_IOBASE is set. x86 never maps I/O ports into memory mapped I/O addresses, they have their own way of accessing them just like your platform. > /** > * of_address_to_resource - Translate device tree address and return as resource > * > * Note that if your address is a PIO address, the conversion will fail if > * the physical address can't be internally converted to an IO token with > * pci_address_to_pio(), that is because it's either called to early or it > * can't be matched to any host bridge IO space > */ > int of_address_to_resource(struct device_node *dev, int index, > struct resource *r) The problem here seems to be that the code assumes that either the I/O ports are always mapped or they are never mapped (no PCI_IOBASE). We need to extend it because now we can have the combination of the two. > >> For ipmi driver, I can get I/O port resource by DMI rather than dts. > > > > No, the ipmi driver uses the resource that belongs to the platform > > device already, you can't rely on DMI data to be present there. > > Ipmi has a lot of way to be discovered(ACPI, DMI, hardcoded, hot-add, > openfirmware and a few other), I think we just use one of them, not all of them. > It depend on vendor's hardware solution actually. I don't think we should mix multiple methods here: if the bus is described in DT, all its children should be there as well. Otherwise you get into problems e.g. if you have multiple instances of the LPC bus and the Linux I/O addresses for one or more of them have an offset to the bus specific addresses. The bus probe code decides what the Linux I/O port numbers are, but DMI and other methods have no idea of the mapping. As long as there is only one instance, using the first 0x1000 addresses with a 1:1 mapping saves us a bit of trouble, but I'd be worried about relying on that assumption too much. Arnd
next prev parent reply other threads:[~2016-01-05 12:21 UTC|newest] Thread overview: 111+ messages / expand[flat|nested] mbox.gz Atom feed top 2015-12-29 13:33 [PATCH v1 0/3] ARM64 LPC: legacy ISA I/O support Rongrong Zou 2015-12-29 13:33 ` [PATCH v1 1/3] ARM64 LPC: indirect ISA PORT IO introduced Rongrong Zou 2015-12-29 13:47 ` Arnd Bergmann 2015-12-29 14:26 ` Rongrong Zou 2015-12-29 14:35 ` Arnd Bergmann 2015-12-30 1:24 ` Rongrong Zou 2015-12-30 8:59 ` Arnd Bergmann 2015-12-30 9:28 ` Rongrong Zou 2015-12-30 9:42 ` Arnd Bergmann 2016-01-04 10:11 ` Will Deacon 2016-01-04 10:27 ` Rongrong Zou 2016-01-04 10:27 ` Rongrong Zou 2015-12-29 13:33 ` [PATCH v1 2/3] ARM64 LPC: LPC driver implementation Rongrong Zou 2015-12-29 13:51 ` Arnd Bergmann 2015-12-29 14:03 ` Rongrong Zou 2015-12-29 14:11 ` Arnd Bergmann 2015-12-29 13:33 ` [PATCH v1 3/3] ARM64 LPC: update binding doc Rongrong Zou 2015-12-29 13:52 ` Arnd Bergmann 2015-12-30 9:06 ` Arnd Bergmann 2015-12-31 14:12 ` Rongrong Zou 2015-12-31 14:12 ` Rongrong Zou 2015-12-31 14:40 ` Arnd Bergmann [not found] ` <CABTftiT1+AmrNjiAie-T6on-oWA4Zz73+Tj2pQrixMT3o475uw@mail.gmail.com> 2016-01-03 12:24 ` Rongrong Zou 2016-01-03 12:24 ` Rongrong Zou 2016-01-03 12:24 ` Rongrong Zou 2016-01-04 11:13 ` Arnd Bergmann 2016-01-04 11:13 ` Arnd Bergmann 2016-01-04 11:13 ` Arnd Bergmann 2016-01-04 16:04 ` Rongrong Zou 2016-01-04 16:04 ` Rongrong Zou 2016-01-04 16:04 ` Rongrong Zou 2016-01-04 16:34 ` Arnd Bergmann 2016-01-04 16:34 ` Arnd Bergmann 2016-01-04 16:34 ` Arnd Bergmann 2016-01-05 11:59 ` Rongrong Zou 2016-01-05 11:59 ` Rongrong Zou 2016-01-05 11:59 ` Rongrong Zou 2016-01-05 12:19 ` Arnd Bergmann [this message] 2016-01-05 12:19 ` Arnd Bergmann 2016-01-06 13:36 ` Rongrong Zou 2016-01-06 13:36 ` Rongrong Zou 2016-01-06 13:36 ` Rongrong Zou 2016-01-07 3:37 ` Rongrong Zou 2016-01-07 3:37 ` Rongrong Zou 2016-01-07 3:37 ` Rongrong Zou 2016-01-10 9:29 ` Rolland Chau 2016-01-10 9:29 ` Rolland Chau 2016-01-10 13:38 ` Rongrong Zou 2016-01-10 13:38 ` Rongrong Zou 2016-01-10 13:38 ` Rongrong Zou 2016-01-11 16:14 ` liviu.dudau 2016-01-11 16:14 ` liviu.dudau at arm.com 2016-01-11 16:14 ` liviu.dudau-5wv7dgnIgG8 2016-01-12 2:39 ` Rongrong Zou 2016-01-12 2:39 ` Rongrong Zou 2016-01-12 9:07 ` liviu.dudau 2016-01-12 9:07 ` liviu.dudau at arm.com 2016-01-12 9:25 ` Rongrong Zou 2016-01-12 9:25 ` Rongrong Zou 2016-01-12 9:25 ` Rongrong Zou 2016-01-12 10:14 ` liviu.dudau 2016-01-12 10:14 ` liviu.dudau at arm.com 2016-01-12 11:05 ` Rongrong Zou 2016-01-12 11:05 ` Rongrong Zou 2016-01-12 11:05 ` Rongrong Zou 2016-01-12 11:27 ` liviu.dudau 2016-01-12 11:27 ` liviu.dudau at arm.com 2016-01-12 11:27 ` liviu.dudau-5wv7dgnIgG8 2016-01-12 11:56 ` Rongrong Zou 2016-01-12 11:56 ` Rongrong Zou 2016-01-12 11:56 ` Rongrong Zou 2016-01-12 15:13 ` liviu.dudau 2016-01-12 15:13 ` liviu.dudau at arm.com 2016-01-12 15:13 ` liviu.dudau-5wv7dgnIgG8 2016-01-12 22:52 ` Arnd Bergmann 2016-01-12 22:52 ` Arnd Bergmann 2016-01-13 5:53 ` Benjamin Herrenschmidt 2016-01-13 5:53 ` Benjamin Herrenschmidt 2016-01-13 5:53 ` Benjamin Herrenschmidt 2016-01-13 6:34 ` Rongrong Zou 2016-01-13 6:34 ` Rongrong Zou 2016-01-13 6:34 ` Rongrong Zou 2016-01-13 9:26 ` Arnd Bergmann 2016-01-13 9:26 ` Arnd Bergmann 2016-01-13 9:26 ` Arnd Bergmann 2016-01-13 10:10 ` liviu.dudau 2016-01-13 10:10 ` liviu.dudau at arm.com 2016-01-13 10:10 ` liviu.dudau-5wv7dgnIgG8 2016-01-13 10:18 ` Arnd Bergmann 2016-01-13 10:18 ` Arnd Bergmann 2016-01-13 10:32 ` liviu.dudau 2016-01-13 10:32 ` liviu.dudau at arm.com 2016-01-13 10:32 ` liviu.dudau-5wv7dgnIgG8 2016-01-12 22:54 ` Arnd Bergmann 2016-01-12 22:54 ` Arnd Bergmann 2016-01-13 10:09 ` liviu.dudau 2016-01-13 10:09 ` liviu.dudau at arm.com 2016-01-13 10:09 ` liviu.dudau-5wv7dgnIgG8 2016-01-13 10:29 ` Arnd Bergmann 2016-01-13 10:29 ` Arnd Bergmann 2016-01-13 10:29 ` Arnd Bergmann 2016-01-13 11:06 ` Rongrong Zou 2016-01-13 11:06 ` Rongrong Zou 2016-01-13 11:25 ` liviu.dudau 2016-01-13 11:25 ` liviu.dudau at arm.com 2016-01-13 23:29 ` Benjamin Herrenschmidt 2016-01-14 2:03 ` Rongrong Zou 2016-01-14 3:39 ` Benjamin Herrenschmidt 2016-01-14 4:42 ` Rongrong Zou 2016-01-14 11:25 ` Benjamin Herrenschmidt 2016-01-14 13:11 ` Rongrong Zou
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=2550495.K9prJVsVEi@wuerfel \ --to=arnd@arndb.de \ --cc=benh@kernel.crashing.org \ --cc=catalin.marinas@arm.com \ --cc=devicetree@vger.kernel.org \ --cc=gregkh@linuxfoundation.org \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linuxarm@huawei.com \ --cc=liviu.dudau@arm.com \ --cc=minyard@acm.org \ --cc=will.deacon@arm.com \ --cc=zourongrong@gmail.com \ --cc=zourongrong@huawei.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: linkBe 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.