Re: [PATCH v3] x86: i8237: Register based on FADT legacy boot flag

[Rajneesh Bhardwaj]

On Mon, Mar 26, 2018 at 03:34:44AM -0700, hpa@xxxxxxxxx wrote:
> On March 26, 2018 2:11:51 AM PDT, Thomas Gleixner <tglx@xxxxxxxxxxxxx> 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 <rajneesh.bhardwaj@xxxxxxxxx>
> >> > > 
> >> > > >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?

Hi Peter - Apparently No, that's why we are trying all these indirect means to
determine the presence of the DMA device. As you might have noticed, this
driver registers as syscore ops and not on the basis of a ACPI object or
HWID or anything else.

> -- 
> Sent from my Android device with K-9 Mail. Please excuse my brevity.

-- 
Best Regards,
Rajneesh