From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mika Westerberg Subject: Re: [PATCH v9 5/7] ACPI: Translate the I/O range of non-MMIO devices before scanning Date: Fri, 30 Jun 2017 12:05:15 +0300 Message-ID: <20170630090515.GU629@lahna.fi.intel.com> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Received: from mga06.intel.com ([134.134.136.31]:23527 "EHLO mga06.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751581AbdF3JHf (ORCPT ); Fri, 30 Jun 2017 05:07:35 -0400 Content-Disposition: inline In-Reply-To: <808a7db0-7844-b263-0216-1fe943ac819a@huawei.com> Sender: linux-acpi-owner@vger.kernel.org List-Id: linux-acpi@vger.kernel.org To: John Garry 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" 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. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751729AbdF3JHj (ORCPT ); Fri, 30 Jun 2017 05:07:39 -0400 Received: from mga06.intel.com ([134.134.136.31]:23527 "EHLO mga06.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751581AbdF3JHf (ORCPT ); Fri, 30 Jun 2017 05:07:35 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.40,285,1496127600"; d="scan'208";a="105560598" Date: Fri, 30 Jun 2017 12:05:15 +0300 From: Mika Westerberg To: John Garry 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)" Subject: Re: [PATCH v9 5/7] ACPI: Translate the I/O range of non-MMIO devices before scanning Message-ID: <20170630090515.GU629@lahna.fi.intel.com> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <808a7db0-7844-b263-0216-1fe943ac819a@huawei.com> Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo User-Agent: Mutt/1.7.1 (2016-10-04) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Fri, 30 Jun 2017 12:05:15 +0300 From: Mika Westerberg To: John Garry 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)" Subject: Re: [PATCH v9 5/7] ACPI: Translate the I/O range of non-MMIO devices before scanning Message-ID: <20170630090515.GU629@lahna.fi.intel.com> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: <808a7db0-7844-b263-0216-1fe943ac819a@huawei.com> Sender: linux-acpi-owner@vger.kernel.org List-ID: 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. From mboxrd@z Thu Jan 1 00:00:00 1970 From: mika.westerberg@linux.intel.com (Mika Westerberg) Date: Fri, 30 Jun 2017 12:05:15 +0300 Subject: [PATCH v9 5/7] ACPI: Translate the I/O range of non-MMIO devices before scanning In-Reply-To: <808a7db0-7844-b263-0216-1fe943ac819a@huawei.com> 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> Message-ID: <20170630090515.GU629@lahna.fi.intel.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org 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.