Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753683AbdFPMW6 (ORCPT ); Fri, 16 Jun 2017 08:22:58 -0400 Received: from mail-it0-f44.google.com ([209.85.214.44]:36799 "EHLO mail-it0-f44.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753619AbdFPMWy (ORCPT ); Fri, 16 Jun 2017 08:22:54 -0400 MIME-Version: 1.0 In-Reply-To: <20170616120048.GC629@lahna.fi.intel.com> References: <20170606085553.GA20085@red-moon> <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> <20170616120048.GC629@lahna.fi.intel.com> From: "Rafael J. Wysocki" Date: Fri, 16 Jun 2017 14:22:51 +0200 X-Google-Sender-Auth: S84y_DGJWr0nn5F0jGYAMu2_z9M Message-ID: Subject: Re: [PATCH v9 5/7] ACPI: Translate the I/O range of non-MMIO devices before scanning To: Mika Westerberg 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" , John Garry , "xuwei (O)" Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 788 Lines: 15 On Fri, Jun 16, 2017 at 2:00 PM, Mika Westerberg wrote: > On Fri, Jun 16, 2017 at 01:24:32PM +0200, Rafael J. Wysocki wrote: >> > 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. > > Sure but those have I2c/SpiSerialBus() resources which we can use to > identify them but for the ipmi thing there is nothing else than _HID so > we would need to keep a list of such devices in ACPI core. OK, so adding a scan handler for that would be the way to go IMO.