From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751905AbcAEMAU (ORCPT ); Tue, 5 Jan 2016 07:00:20 -0500 Received: from szxga01-in.huawei.com ([58.251.152.64]:42016 "EHLO szxga01-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751188AbcAEMAR (ORCPT ); Tue, 5 Jan 2016 07:00:17 -0500 Subject: Re: [PATCH v1 3/3] ARM64 LPC: update binding doc To: Arnd Bergmann , References: <1451396032-23708-1-git-send-email-zourongrong@gmail.com> <15026471.7nGZ0rWlIf@wuerfel> <568A9803.6050108@gmail.com> <6384244.Uhpjfgly6O@wuerfel> CC: Rongrong Zou , , Catalin Marinas , Corey Minyard , , Will Deacon , , , , From: Rongrong Zou Message-ID: <568BB035.1050801@huawei.com> Date: Tue, 5 Jan 2016 19:59:49 +0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <6384244.Uhpjfgly6O@wuerfel> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [10.177.30.66] X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020205.568BB046.00CF,ss=1,re=0.000,recu=0.000,reip=0.000,cl=1,cld=1,fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: ac15b06e153a41e4c30614159d31b5bd Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 在 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 写道: >>>> */ >>>> compatible = "low-pin-count"; >>>> device_type = "isa"; >>>> #address-cells = <2>; >>>> #size-cells = <1>; >>>> reg = <0x0 0xa01b0000 0x0 0x10000>; >>>> ranges = <0x1 0x0 0x0 0x0 0x1000>; >>>> /* >>>> * ranges is required, then i can get the IORESOURCE_IO <0xe4,4> from "reg = <0x1, 0x000000e4, 4>". >>>> * >>>> */ >>>> ipmi_0:ipmi@000000e4{ >>>> device_type = "ipmi"; >>>> compatible = "ipmi-bt"; >>>> reg = <0x1 0x000000e4 0x4>; >>>> }; >>>> >>> >>> This looks wrong: the property above says that the I/O port range is >>> translated to MMIO address 0x00000000 to 0x00010000, which is not >>> true on your hardware. I think this needs to be changed in the code >>> so the ranges property is not required for I/O ports. >> >> 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. /** * 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) >> 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. > > Arnd > > . > Thanks, Rongrong From mboxrd@z Thu Jan 1 00:00:00 1970 From: Rongrong Zou Subject: Re: [PATCH v1 3/3] ARM64 LPC: update binding doc Date: Tue, 5 Jan 2016 19:59:49 +0800 Message-ID: <568BB035.1050801@huawei.com> References: <1451396032-23708-1-git-send-email-zourongrong@gmail.com> <15026471.7nGZ0rWlIf@wuerfel> <568A9803.6050108@gmail.com> <6384244.Uhpjfgly6O@wuerfel> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE Return-path: In-Reply-To: <6384244.Uhpjfgly6O@wuerfel> Sender: devicetree-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Arnd Bergmann , linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org Cc: Rongrong Zou , devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Catalin Marinas , Corey Minyard , gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org, Will Deacon , linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linuxarm-hv44wF8Li93QT0dZR+AlfA@public.gmane.org, benh-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r@public.gmane.org, liviu.dudau-5wv7dgnIgG8@public.gmane.org List-Id: devicetree@vger.kernel.org =E5=9C=A8 2016/1/5 0:34, Arnd Bergmann =E5=86=99=E9=81=93: > On Tuesday 05 January 2016 00:04:19 Rongrong Zou wrote: >> =E5=9C=A8 2016/1/4 19:13, Arnd Bergmann =E5=86=99=E9=81=93: >>> On Sunday 03 January 2016 20:24:14 Rongrong Zou wrote: >>>> =E5=9C=A8 2015/12/31 23:00, Rongrong Zou =E5=86=99=E9=81=93: >>>> */ >>>> compatible =3D "low-pin-count"; >>>> device_type =3D "isa"; >>>> #address-cells =3D <2>; >>>> #size-cells =3D <1>; >>>> reg =3D <0x0 0xa01b0000 0x0 0x10000>; >>>> ranges =3D <0x1 0x0 0x0 0x0 0x1000>; >>>> /* >>>> * ranges is required, then i can get the IORESOURCE_IO <0xe4,4> f= rom "reg =3D <0x1, 0x000000e4, 4>". >>>> * >>>> */ >>>> ipmi_0:ipmi@000000e4{ >>>> device_type =3D "ipmi"; >>>> compatible =3D "ipmi-bt"; >>>> reg =3D <0x1 0x000000e4 0x4>; >>>> }; >>>> >>> >>> This looks wrong: the property above says that the I/O port range i= s >>> translated to MMIO address 0x00000000 to 0x00010000, which is not >>> true on your hardware. I think this needs to be changed in the code >>> so the ranges property is not required for I/O ports. >> >> 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 leg= acy >> I/O port resource from dts. > > As I said, nothing should really require the ranges property here, un= less > 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 port= s, because I must get resource by calling of_address_to_resource(), which have to ca= ll pci_address_to_pio() when resource type is IORESOURCE_IO. I'm sorry I h= ave no better idea for this now. Maybe liviu can give me some opinions. /** * of_address_to_resource - Translate device tree address and return a= s resource * * Note that if your address is a PIO address, the conversion will fai= l if * the physical address can't be internally converted to an IO token w= ith * pci_address_to_pio(), that is because it's either called to early o= r 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) >> 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. > > Arnd > > . > Thanks, Rongrong -- To unsubscribe from this list: send the line "unsubscribe devicetree" i= n the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html From mboxrd@z Thu Jan 1 00:00:00 1970 From: zourongrong@huawei.com (Rongrong Zou) Date: Tue, 5 Jan 2016 19:59:49 +0800 Subject: [PATCH v1 3/3] ARM64 LPC: update binding doc In-Reply-To: <6384244.Uhpjfgly6O@wuerfel> References: <1451396032-23708-1-git-send-email-zourongrong@gmail.com> <15026471.7nGZ0rWlIf@wuerfel> <568A9803.6050108@gmail.com> <6384244.Uhpjfgly6O@wuerfel> Message-ID: <568BB035.1050801@huawei.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org ? 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 ??: >>>> */ >>>> compatible = "low-pin-count"; >>>> device_type = "isa"; >>>> #address-cells = <2>; >>>> #size-cells = <1>; >>>> reg = <0x0 0xa01b0000 0x0 0x10000>; >>>> ranges = <0x1 0x0 0x0 0x0 0x1000>; >>>> /* >>>> * ranges is required, then i can get the IORESOURCE_IO <0xe4,4> from "reg = <0x1, 0x000000e4, 4>". >>>> * >>>> */ >>>> ipmi_0:ipmi at 000000e4{ >>>> device_type = "ipmi"; >>>> compatible = "ipmi-bt"; >>>> reg = <0x1 0x000000e4 0x4>; >>>> }; >>>> >>> >>> This looks wrong: the property above says that the I/O port range is >>> translated to MMIO address 0x00000000 to 0x00010000, which is not >>> true on your hardware. I think this needs to be changed in the code >>> so the ranges property is not required for I/O ports. >> >> 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. /** * 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) >> 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. > > Arnd > > . > Thanks, Rongrong