Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751790AbdF3JaX (ORCPT ); Fri, 30 Jun 2017 05:30:23 -0400 Received: from szxga02-in.huawei.com ([45.249.212.188]:9326 "EHLO szxga02-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751545AbdF3JaV (ORCPT ); Fri, 30 Jun 2017 05:30:21 -0400 Subject: Re: [PATCH v9 5/7] ACPI: Translate the I/O range of non-MMIO devices before scanning To: Mika Westerberg References: <20170612155700.GA31930@red-moon> <20170613084831.GP3187@lahna.fi.intel.com> <20170613151013.GT3187@lahna.fi.intel.com> <20170613200339.GX3187@lahna.fi.intel.com> <20170616083313.GY3187@lahna.fi.intel.com> <808a7db0-7844-b263-0216-1fe943ac819a@huawei.com> <20170630090515.GU629@lahna.fi.intel.com> CC: "Rafael J. Wysocki" , Gabriele Paoloni , Lorenzo Pieralisi , "Rafael J. Wysocki" , "catalin.marinas@arm.com" , "will.deacon@arm.com" , "robh+dt@kernel.org" , "frowand.list@gmail.com" , "bhelgaas@google.com" , "arnd@arndb.de" , "linux-arm-kernel@lists.infradead.org" , "mark.rutland@arm.com" , "brian.starkey@arm.com" , "olof@lixom.net" , "benh@kernel.crashing.org" , "linux-kernel@vger.kernel.org" , "linux-acpi@vger.kernel.org" , Linuxarm , "linux-pci@vger.kernel.org" , "minyard@acm.org" , "xuwei (O)" From: John Garry Message-ID: Date: Fri, 30 Jun 2017 10:28:36 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: <20170630090515.GU629@lahna.fi.intel.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.203.181.152] X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A0B0206.595619DD.0028,ss=1,re=0.000,recu=0.000,reip=0.000,cl=1,cld=1,fgs=0, ip=0.0.0.0, so=2014-11-16 11:51:01, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 420ce41b90e63035dac45782342b8778 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1687 Lines: 42 On 30/06/2017 10:05, Mika Westerberg wrote: > On Thu, Jun 29, 2017 at 05:16:15PM +0100, John Garry wrote: >> On 16/06/2017 12:24, Rafael J. Wysocki wrote: >>>>>>>>> >>>>>>>>> It causes acpi_default_enumeration() to be called but it should be fine >>>>>>>>> as we are dealing with platform device anyway. >>>>>>> >>>>>>> I do not quite understand how declaring such MFD cell above would make sure >>>>>>> that the LPC probe is called before the IPMI device is enumerated... >>>>> >>>>> In fact it may be that it is not sufficient in this case because the >>>>> ACPI core might enumerate child devices before the LPC driver even gets >>>>> a chance to probe so you would need to add also scan handler to the >>>>> child devices and mark them already enumerated or something like that. >>> Or extend the special I2C/SPI handling to them. >>> >> >> For this, is it possible to just configure the ACPI table so we spoof that >> the LPC slave (IPI0001), is an i2c/spi slave? Could we just add a resource >> of type ACPI_RESOURCE_TYPE_SERIAL_BUS, and common serial bus type i2c/spi to >> solve this? > > But is the device connected to a I2C or SPI bus? If not, then it does > not make much sense to declare it as I2C or SPI slave. Instead it should > be platform device which is the type we use when there is no explicit > bus specified in ACPI. > No, it's not a SPI nor an I2C bus. I actually would say that my idea is generally wrong, as the ACPI definition is not a real reflection of the bus/slave. However, Rafael did suggest extending special I2C/SPI handling to them. In this case, I don't see how the LPC slave can be identified like an I2C or SPI slave is. Thanks, John > . >