From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753145AbbLaOlf (ORCPT ); Thu, 31 Dec 2015 09:41:35 -0500 Received: from mout.kundenserver.de ([217.72.192.75]:61563 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751895AbbLaOlT convert rfc822-to-8bit (ORCPT ); Thu, 31 Dec 2015 09:41:19 -0500 From: Arnd Bergmann To: Rongrong Zou Cc: Rongrong Zou , minyard@acm.org, gregkh@linuxfoundation.org, catalin.marinas@arm.com, will.deacon@arm.com, linuxarm@huawei.com, linux-kernel@vger.kernel.org, benh@kernel.crashing.org, devicetree@vger.kernel.org Subject: Re: [PATCH v1 3/3] ARM64 LPC: update binding doc Date: Thu, 31 Dec 2015 15:40:49 +0100 Message-ID: <17750582.ajK78gYOFz@wuerfel> User-Agent: KMail/4.11.5 (Linux/3.16.0-10-generic; KDE/4.11.5; x86_64; ; ) In-Reply-To: <568537C3.3060902@huawei.com> References: <1451396032-23708-1-git-send-email-zourongrong@gmail.com> <1899302.RWIn6Bg3Dr@wuerfel> <568537C3.3060902@huawei.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8BIT Content-Type: text/plain; charset="utf-8" X-Provags-ID: V03:K0:rqnacd+yETpdLFjgGiElc4IBfia9n7GQgL0I8QhGjfzS65nxQpw KmT/px84eW7HgEB13NVjKXaErT7Vk8u0k4o2oYel9i7KZrYyc22M/39T6Yv+VsopHDA4Y64 n9F+pZfoz5RXWII1zA0C7IOm/mU09NpRydpMhcneTfYV0bWcxzy/BQqyeKydb6j1YlHUHy6 /6opQW8fdOE1rTsfvXyWw== X-UI-Out-Filterresults: notjunk:1;V01:K0:bus5/XoKFGM=:OxZZTLEozoZPnpfMLBQ0og SniRppcLIQBbRE8+TxGj8wJtAvEcP6DMcE4/gaA+4nisedb1LLVncoXQVuaqlf6bHe84LUMoM TIvyP9+YUpiloJrHhQf+oSDinw+j0iQ/64ZOWyrLk/7U07V7mpi8zI/mS2PqeS+EsTf6321MX 9ukHYmt5T9pPh8alKCTj485JD9as3/VkOPHywe5GKZF+5JCK27qi8TF9H1odKDp4zNMdR/DL0 4wM3QoQKQeduYH9P6bh64WMPqtlz50Im19bysQ4XAtNCN3wnLsmmJb1uq7NYzzDT+3apWoQnK bxCPsqJilZlb6Gs+f0j5pKC1/SqsaI6aH+skOrt1TuPn7A58jXF8x4LzhPiCwxxIl+6bILBgU BC8Ktndg7DDTESswmdjCZ5EFaGOvXPPQVhuCZJZHHdrhYeds48ikxWnXwqbcQeNkstx9PcOIO M5IwW+uULDNuX1+/4wIV76fI3uMQCEqpbTQghna5kh87DCZRFPGfNh5rwB0bIiFCQDXkhCiRp 5RkDxOQd0JLG/ifnnG6K1VYOQUPDhrzNjZG2DDko32ObzGbnD+ExnbD9TnowBx5jtipjuHonU poFk0Qrze1/royAdqb7wQsOt7AioQTgtEflwiw3e1gYUpqg5ainlkClNPg17SGKM07v83n5oq F1dNYeeORvtxTV4iwDYlu44ddwiE242B18y08Bwcak9YNST+b1HpyoG9IxwEF7yteQ/dK/afJ OSneZQ22qbblHwfX Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thursday 31 December 2015 22:12:19 Rongrong Zou wrote: > 在 2015/12/30 17:06, Arnd Bergmann 写道: > > On Tuesday 29 December 2015 21:33:52 Rongrong Zou wrote: > >> +Example: > >> + > >> + lpc_0: lpc@a01b0000 { > >> + #address-cells = <1>; > >> + #size-cells = <1>; > >> + compatible = "low-pin-count"; > >> + reg = <0x0 0xa01b0000 0x0 0x10000>; > >> + }; > > > > One more thought: please try to stick as closely as possible to the existing > > ISA binding that is documented at > > > > http://www.firmware.org/1275/bindings/isa/isa0_4d.ps > From the specification, I think I should use 2 32bit integer to describe the isa addr in dts. > > > > In particular, this should cover the possibility of describing both memory > > and I/O spaces in child devices. > > > > I found below config in powerpc dts "arch/powerpc/boot/dts/mpc8544ds.dts" > > isa@1e { > device_type = "isa"; > #interrupt-cells = <2>; > #size-cells = <1>; > #address-cells = <2>; > reg = <0xf000 0x0 0x0 0x0 0x0>; > ranges = <0x1 0x0 0x1000000 0x0 0x0 > 0x1000>; > interrupt-parent = <&i8259>; > > > > rtc@70 { > compatible = "pnpPNP,b00"; > reg = <0x1 0x70 0x2>; > }; > the isa space in child-node: reg = <0x1 0x70 0x2>; > 0x1 means IO space, 70 means addr, 0x2 is size. > but when i config the following in dts, the ipmi_0 node can't be probed, > I think there may be some problems. > > lpc_0: lpc@a01b0000 { > compatible = "low-pin-count"; > device_type = "isa"; > #address-cells = <2>; > #size-cells = <1>; > reg = <0x0 0xa01b0000 0x0 0x10000>; > > ipmi_0:ipmi@000000e4{ > device_type = "ipmi"; > compatible = "ipmi-bt"; > reg = <0x1 0x000000e4 0x4>; > }; The DT sample above looks good in principle. I believe what you are missing here is code in your driver to scan the child nodes to create the platform devices. of_bus_isa_translate() should work with your definition here and create the correct IORESOURCE_IO resources. You don't have any MMIO resources, so the absence of a ranges property is ok. Maybe all you are missing is a call to of_platform_populate() or of_platform_bus_probe()? Arnd