From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751108AbeCZKfK convert rfc822-to-8bit (ORCPT ); Mon, 26 Mar 2018 06:35:10 -0400 Received: from terminus.zytor.com ([198.137.202.136]:44227 "EHLO mail.zytor.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750864AbeCZKfJ (ORCPT ); Mon, 26 Mar 2018 06:35:09 -0400 Date: Mon, 26 Mar 2018 03:34:44 -0700 User-Agent: K-9 Mail for Android In-Reply-To: References: <1521714118-31282-1-git-send-email-anshuman.gupta@intel.com> <20180326054833.GA25173@raj-desk2.iind.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8BIT Subject: Re: [PATCH v3] x86: i8237: Register based on FADT legacy boot flag To: Thomas Gleixner , Rajneesh Bhardwaj CC: Anshuman Gupta , glx@linutronix.de, x86@kernel.org, mingo@redhat.com, rjw@rjwysocki.net, andriy.shevchenko@linux.intel.com, alan@linux.intel.com, linux-kernel@vger.kernel.org From: hpa@zytor.com Message-ID: <8A68406D-B05E-4953-89D1-D2AB49904644@zytor.com> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On March 26, 2018 2:11:51 AM PDT, Thomas Gleixner wrote: >On Mon, 26 Mar 2018, Rajneesh Bhardwaj wrote: > >> On Sun, Mar 25, 2018 at 01:50:40PM +0200, Thomas Gleixner wrote: >> > On Thu, 22 Mar 2018, Anshuman Gupta wrote: >> > >> > > From: Rajneesh Bhardwaj >> > > >> > > >From Skylake onwards, the platform controller hub (Sunrisepoint >PCH) does >> > > not support legacy DMA operations to IO ports 81h-83h, 87h, >89h-8Bh, 8Fh. >> > > Currently this driver registers as syscore ops and its resume >function is >> > > called on every resume from S3. On Skylake and Kabylake, this >causes a >> > > resume delay of around 100ms due to port IO operations, which is >a problem. >> > > >> > > This change allows to load the driver only when the platform bios >> > > explicitly supports such devices or has a cut-off date earlier >than 2017. >> > >> > Please explain WHY 2017 is the cut-off date. I still have no clue >how that >> > is decided aside of being a random number. >> >> Hello Thomas, >> >> We tested on few Intel platforms such as Skylake, Kabylake, >Geminilake etc >> and realized that the BIOS always sets the FADT flag to be true >though the >> device may not be physically present on the SoC. This is a BIOS bug. >To keep >> the impact minimum, we decided to add a cut-off date since we are not >aware >> of any BIOS (other than the coreboot link provided in the commit msg) >that >> properly sets this field. SoCs released after Skylake will not have >this DMA >> device on the PCH. So, because of these two reasons, we decided to >add a >> cut-off date as 2017. >> >> Please let us know if you feel strongly about it and we can change it >or >> remove it if you feel so. > >I don't feel strongly about the cut off itself, but I want a reasonable >explanation in the changelog or code comment because half a year from >now >nobody remembers .... > >Thanks, > > tglx Can we probe safely for this device? -- Sent from my Android device with K-9 Mail. Please excuse my brevity.