From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Google-Smtp-Source: AG47ELulwCAcMETj1aR0ODp2Li7nbVQ9qpwZrcPTPajwOipPLnlHdXyBky/yd1ZXjJozViqA99FH ARC-Seal: i=1; a=rsa-sha256; t=1520353390; cv=none; d=google.com; s=arc-20160816; b=NNtpCOh/97MAmgobAe13z/BLBM9YlBTs8l7XkhON3RZ5lvWx5fLcV2wb2nPwhfOM1a 3l6ScnlegNwC+fviaodPT6GO+e96fqMnqQsMG3Mku3K/i0tK0EwPUMGWwmQ+Cv4/CbWP FmXWWpr8HWm8KByUvDXlCXBabM4Zx7PVPMMDwWSIWyBM2ZcimqFYRMy0kRxF2QcHBOu+ y40KTfY+0MleLLRWP6LpbJT/2NbTYfF2Gt8fHhatusOLqCwqugiKrj9Zen8iAMVRgUK+ AWPqrq4hU6sK369dsI4UVA+T+6bmn40ZjXbOkhOrQ2GIYHIse2SAElaBieYLdnJLjKN2 7AQg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:in-reply-to:mime-version:user-agent:date :message-id:from:cc:references:to:subject:arc-authentication-results; bh=xgVZ/arozCtLZ7smg6KYbmxSeT9Va/n5/9XdQDLjg2E=; b=BbJrtseA5KZdoJ7lj+tnAg+oJ38wBBJB8d7INUONG0XTt5kQ8GhYYIW7fzQxjx3HSr ld8LEIKK5j+cUc7y2y4usWT8ndLic0yC9ALNsrAj0SFt8ulLVksExfCc5vmtv1gYMCvA HPPqwUkRYZFTCE6Qehx0juZM9cItDDN2uyL5OHHGNkLYQZeHE3nbH7j0PN+gRzMymVEe gRdBz5UtoB3RZzDIL9Bpj4uaIlSm/+RQVnaUL9OnCDlwZKIItt+R40DOM/fbjvMGB1Pe 6HnXaiSv3ea/s9/WlnfNqnML2McFMxYuAD2RhSL5qgw3oCJkQrarT7eypTZOKQYQPj8k i++g== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of john.garry@huawei.com designates 45.249.212.190 as permitted sender) smtp.mailfrom=john.garry@huawei.com Authentication-Results: mx.google.com; spf=pass (google.com: domain of john.garry@huawei.com designates 45.249.212.190 as permitted sender) smtp.mailfrom=john.garry@huawei.com Subject: Re: [PATCH v16 0/9] LPC: legacy ISA I/O support To: "Rafael J. Wysocki" References: <1520333268-82754-1-git-send-email-john.garry@huawei.com> <1520335317.10722.416.camel@linux.intel.com> CC: Andy Shevchenko , Mika Westerberg , Lorenzo Pieralisi , "Rafael J. Wysocki" , "Hanjun Guo" , Rob Herring , Bjorn Helgaas , Arnd Bergmann , Mark Rutland , Olof Johansson , Dann Frazier , Andy Shevchenko , Rob Herring , Joe Perches , "Benjamin Herrenschmidt" , Linux PCI , Linux Kernel Mailing List , ACPI Devel Maling List , Linuxarm , Corey Minyard , "devicetree@vger.kernel.org" , linux-arch , Randy Dunlap , Greg Kroah-Hartman , Andrew Morton , Frank Rowand , Alexander Graf From: John Garry Message-ID: <3ef757ff-8430-017f-59d3-ff67f49f5a80@huawei.com> Date: Tue, 6 Mar 2018 16:22:36 +0000 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: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.202.227.238] X-CFilter-Loop: Reflected X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: =?utf-8?q?1594185012385637551?= X-GMAIL-MSGID: =?utf-8?q?1594206076749181461?= X-Mailing-List: linux-kernel@vger.kernel.org List-ID: >>>> >>>> Based on this patch-set, all the I/O accesses to Hip06/Hip07 LPC >>>> peripherals can >>>> be supported without any changes on the existing ipmi-si driver. >>>> >>>> The whole patchset has been tested on Hip07 D05 board both using DTB >>>> and ACPI. >>>> >>> >>>> V15 thread here: https://lkml.org/lkml/2018/2/26/584 >>> >>> >>> Thanks for an update. >>> Though I answered to previous thread. >>> >>> Summary: I'm fine with the series as long as maintainers are fine >>> (Rafael et al.). On personal side I think that the handler approach is >>> better. Details are in v15 thread. >> >> >> Hi Andy, >> >> Thanks for your input and continued support. As I mentioned in reply in v15, >> the handler support would (or has) faced issues. And Rafael seems fine with >> deferring the probe to the LLDD in Patch #7/9 > Hi Rafael, > Well, the only sort-of concern is that these devices may not be > "serial bus slaves" in general, so the naming is slightly confusing. > Right, the name. The key point is that we model the bus the same as other serial buses like I2C or SPI, so require the same treatment from the ACPI scan. Would you prefer acpi_is_serial_bus_slave() and acpi_device_flags.serial_bus_slave symbols be modified also? > But overall this approach and the one based on a scan handler both > boil down to checking a (list of) device ID(s) and doing something > special in case of a match. > > . > Thanks, John