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

[Alan Cox]

> Can we probe safely for this device?

99% of the time yes the inb gives us a straight answer. However (and
we've hit this with port 0x81 for real) there are concerns that some
systems will trap those addresses into SMM and do weirdness that makes
the 0xFF check fail.

Alan

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

[Alan Cox]

> Can we probe safely for this device?

99% of the time yes the inb gives us a straight answer. However (and
we've hit this with port 0x81 for real) there are concerns that some
systems will trap those addresses into SMM and do weirdness that makes
the 0xFF check fail.

Alan

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

[Alan Cox]

> Please explain WHY 2017 is the cut-off date. I still have no clue how
> that
> is decided aside of being a random number.

Because if it's prior to 2017 then it'll almost certainly have those
registers even if the firmware says otherwise. After that point we
think the firmware is going to give valid answers (although the 0xFF
check is actually the important one in reality).

Alan

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

[Alan Cox]

> Please explain WHY 2017 is the cut-off date. I still have no clue how
> that
> is decided aside of being a random number.

Because if it's prior to 2017 then it'll almost certainly have those
registers even if the firmware says otherwise. After that point we
think the firmware is going to give valid answers (although the 0xFF
check is actually the important one in reality).

Alan

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

[Rajneesh Bhardwaj]

On Mon, Mar 26, 2018 at 03:34:44AM -0700, h...@zytor.com wrote:
> 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?

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

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

[Rajneesh Bhardwaj]

On Mon, Mar 26, 2018 at 03:34:44AM -0700, h...@zytor.com wrote:
> 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?

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

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

[hpa]

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.

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

[hpa]

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.

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

[Thomas Gleixner]

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

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

[Thomas Gleixner]

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

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

[Rajneesh Bhardwaj]

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.

Ideally, we didnt want to add this BIOS check at all and only wanted to use
inb() approch but unfortunately, that too was broken for port 0x81.

@Rafael / Alan / Andy - Please add more or correct me in case of anything
missed  or not communicated fully.

> 
> Thanks,
> 
>   tglx

-- 
Best Regards,
Rajneesh

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

[Rajneesh Bhardwaj]

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.

Ideally, we didnt want to add this BIOS check at all and only wanted to use
inb() approch but unfortunately, that too was broken for port 0x81.

@Rafael / Alan / Andy - Please add more or correct me in case of anything
missed  or not communicated fully.

> 
> Thanks,
> 
>   tglx

-- 
Best Regards,
Rajneesh

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

[Thomas Gleixner]

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.

Thanks,

tglx

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

[Thomas Gleixner]

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.

Thanks,

tglx

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

[Thomas Gleixner]

On Thu, 22 Mar 2018, Rajneesh Bhardwaj wrote:

> On Thu, Mar 22, 2018 at 03:51:58PM +0530, Anshuman Gupta wrote:
> 
> Adding Thomas.

I'm already there via x...@kernel.org :)

But thanks for noticing nevertheless.

tglx

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

[Thomas Gleixner]

On Thu, 22 Mar 2018, Rajneesh Bhardwaj wrote:

> On Thu, Mar 22, 2018 at 03:51:58PM +0530, Anshuman Gupta wrote:
> 
> Adding Thomas.

I'm already there via x...@kernel.org :)

But thanks for noticing nevertheless.

tglx

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

[Rajneesh Bhardwaj]

On Thu, Mar 22, 2018 at 03:51:58PM +0530, Anshuman Gupta wrote:

Adding Thomas.

> 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.
> For example open source system firmware like coreboot started unsetting
> ACPI_FADT_LEGACY_DEVICES field in FADT table very recently.
> https://github.com/coreboot/coreboot/blob/05132707ca1e13a11cd13c77326bc65011b09feb/src/soc/intel/skylake/acpi.c#L271
> 
> Please refer to chapter 21 of 6th Generation Intel® Core™ Processor
> Platform Controller Hub Family: BIOS Specification.
> 
> https://www.intel.in/content/www/in/en/embedded/products/skylake/u-mobile/software-and-drivers.html
> 
> Cc: Alan Cox 
> Reviewed-by: Andy Shevchenko 
> Signed-off-by: Anshuman Gupta 
> Signed-off-by: Rajneesh Bhardwaj 
> ---
> Changes in v3:
>  * Added x86_pnpbios_disabled and using it instead of pnpbios.
>  * Modified the commit message.
> 
> Changes in v2:
>  * changed to dma_inb()
> ---
>  arch/x86/include/asm/x86_init.h   |  1 +
>  arch/x86/kernel/i8237.c   | 25 +
>  arch/x86/kernel/platform-quirks.c |  7 ++-
>  3 files changed, 32 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/x86/include/asm/x86_init.h b/arch/x86/include/asm/x86_init.h
> index fc2f082..b6ceac0 100644
> --- a/arch/x86/include/asm/x86_init.h
> +++ b/arch/x86/include/asm/x86_init.h
> @@ -286,6 +286,7 @@ extern struct x86_msi_ops x86_msi;
>  extern struct x86_io_apic_ops x86_io_apic_ops;
>  
>  extern void x86_early_init_platform_quirks(void);
> +extern bool x86_pnpbios_disabled(void);
>  extern void x86_init_noop(void);
>  extern void x86_init_uint_noop(unsigned int unused);
>  
> diff --git a/arch/x86/kernel/i8237.c b/arch/x86/kernel/i8237.c
> index 8eeaa81..0a3e70f 100644
> --- a/arch/x86/kernel/i8237.c
> +++ b/arch/x86/kernel/i8237.c
> @@ -9,10 +9,12 @@
>   * your option) any later version.
>   */
>  
> +#include 
>  #include 
>  #include 
>  
>  #include 
> +#include 
>  
>  /*
>   * This module just handles suspend/resume issues with the
> @@ -49,6 +51,29 @@ static struct syscore_ops i8237_syscore_ops = {
>  
>  static int __init i8237A_init_ops(void)
>  {
> + /*
> +  * From SKL PCH onwards, the legacy DMA device is removed in which the
> +  * I/O ports (81h-83h, 87h, 89h-8Bh, 8Fh) related to it are removed
> +  * as well. All removed ports must return 0xff for a inb() request.
> +  *
> +  * Note: DMA_PAGE_2 (port 0x81) should not be checked for detecting
> +  * the presence of DMA device since it may be used by BIOS to decode
> +  * LPC traffic for POST codes. Original LPC only decodes one byte of
> +  * port 0x80 but some BIOS may choose to enhance PCH LPC port 0x8x
> +  * decoding.
> +  */
> + if (dma_inb(DMA_PAGE_0) == 0xFF)
> + return -ENODEV;
> +
> + /*
> +  * It is not required to load this driver as newer SoC may not
> +  * support 8237 DMA or bus mastering from LPC. Platform firmware
> +  * must announce the support for such legacy devices via
> +  * ACPI_FADT_LEGACY_DEVICES field in FADT table.
> +  */
> + if (x86_pnpbios_disabled() && dmi_get_bios_year() >= 2017)
> + return -ENODEV;
> +
>   register_syscore_ops(_syscore_ops);
>   return 0;
>  }
> diff --git a/arch/x86/kernel/platform-quirks.c 
> b/arch/x86/kernel/platform-quirks.c
> index 235fe60..b348a67 100644
> --- a/arch/x86/kernel/platform-quirks.c
> +++ b/arch/x86/kernel/platform-quirks.c
> @@ -33,9 +33,14 @@ void __init x86_early_init_platform_quirks(void)
>   x86_platform.set_legacy_features();
>  }
>  
> +bool __init x86_pnpbios_disabled(void)
> +{
> + return x86_platform.legacy.devices.pnpbios == 0;
> +}
> +
>  #if defined(CONFIG_PNPBIOS)
>  bool __init arch_pnpbios_disabled(void)
>  {
> - return x86_platform.legacy.devices.pnpbios == 0;
> + return x86_pnpbios_disabled();
>  }
>  #endif
> -- 
> 2.7.4
> 

-- 
Best Regards,
Rajneesh

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

[Rajneesh Bhardwaj]

On Thu, Mar 22, 2018 at 03:51:58PM +0530, Anshuman Gupta wrote:

Adding Thomas.

> 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.
> For example open source system firmware like coreboot started unsetting
> ACPI_FADT_LEGACY_DEVICES field in FADT table very recently.
> https://github.com/coreboot/coreboot/blob/05132707ca1e13a11cd13c77326bc65011b09feb/src/soc/intel/skylake/acpi.c#L271
> 
> Please refer to chapter 21 of 6th Generation Intel® Core™ Processor
> Platform Controller Hub Family: BIOS Specification.
> 
> https://www.intel.in/content/www/in/en/embedded/products/skylake/u-mobile/software-and-drivers.html
> 
> Cc: Alan Cox 
> Reviewed-by: Andy Shevchenko 
> Signed-off-by: Anshuman Gupta 
> Signed-off-by: Rajneesh Bhardwaj 
> ---
> Changes in v3:
>  * Added x86_pnpbios_disabled and using it instead of pnpbios.
>  * Modified the commit message.
> 
> Changes in v2:
>  * changed to dma_inb()
> ---
>  arch/x86/include/asm/x86_init.h   |  1 +
>  arch/x86/kernel/i8237.c   | 25 +
>  arch/x86/kernel/platform-quirks.c |  7 ++-
>  3 files changed, 32 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/x86/include/asm/x86_init.h b/arch/x86/include/asm/x86_init.h
> index fc2f082..b6ceac0 100644
> --- a/arch/x86/include/asm/x86_init.h
> +++ b/arch/x86/include/asm/x86_init.h
> @@ -286,6 +286,7 @@ extern struct x86_msi_ops x86_msi;
>  extern struct x86_io_apic_ops x86_io_apic_ops;
>  
>  extern void x86_early_init_platform_quirks(void);
> +extern bool x86_pnpbios_disabled(void);
>  extern void x86_init_noop(void);
>  extern void x86_init_uint_noop(unsigned int unused);
>  
> diff --git a/arch/x86/kernel/i8237.c b/arch/x86/kernel/i8237.c
> index 8eeaa81..0a3e70f 100644
> --- a/arch/x86/kernel/i8237.c
> +++ b/arch/x86/kernel/i8237.c
> @@ -9,10 +9,12 @@
>   * your option) any later version.
>   */
>  
> +#include 
>  #include 
>  #include 
>  
>  #include 
> +#include 
>  
>  /*
>   * This module just handles suspend/resume issues with the
> @@ -49,6 +51,29 @@ static struct syscore_ops i8237_syscore_ops = {
>  
>  static int __init i8237A_init_ops(void)
>  {
> + /*
> +  * From SKL PCH onwards, the legacy DMA device is removed in which the
> +  * I/O ports (81h-83h, 87h, 89h-8Bh, 8Fh) related to it are removed
> +  * as well. All removed ports must return 0xff for a inb() request.
> +  *
> +  * Note: DMA_PAGE_2 (port 0x81) should not be checked for detecting
> +  * the presence of DMA device since it may be used by BIOS to decode
> +  * LPC traffic for POST codes. Original LPC only decodes one byte of
> +  * port 0x80 but some BIOS may choose to enhance PCH LPC port 0x8x
> +  * decoding.
> +  */
> + if (dma_inb(DMA_PAGE_0) == 0xFF)
> + return -ENODEV;
> +
> + /*
> +  * It is not required to load this driver as newer SoC may not
> +  * support 8237 DMA or bus mastering from LPC. Platform firmware
> +  * must announce the support for such legacy devices via
> +  * ACPI_FADT_LEGACY_DEVICES field in FADT table.
> +  */
> + if (x86_pnpbios_disabled() && dmi_get_bios_year() >= 2017)
> + return -ENODEV;
> +
>   register_syscore_ops(_syscore_ops);
>   return 0;
>  }
> diff --git a/arch/x86/kernel/platform-quirks.c 
> b/arch/x86/kernel/platform-quirks.c
> index 235fe60..b348a67 100644
> --- a/arch/x86/kernel/platform-quirks.c
> +++ b/arch/x86/kernel/platform-quirks.c
> @@ -33,9 +33,14 @@ void __init x86_early_init_platform_quirks(void)
>   x86_platform.set_legacy_features();
>  }
>  
> +bool __init x86_pnpbios_disabled(void)
> +{
> + return x86_platform.legacy.devices.pnpbios == 0;
> +}
> +
>  #if defined(CONFIG_PNPBIOS)
>  bool __init arch_pnpbios_disabled(void)
>  {
> - return x86_platform.legacy.devices.pnpbios == 0;
> + return x86_pnpbios_disabled();
>  }
>  #endif
> -- 
> 2.7.4
> 

-- 
Best Regards,
Rajneesh

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

[Anshuman Gupta]

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.
For example open source system firmware like coreboot started unsetting
ACPI_FADT_LEGACY_DEVICES field in FADT table very recently.
https://github.com/coreboot/coreboot/blob/05132707ca1e13a11cd13c77326bc65011b09feb/src/soc/intel/skylake/acpi.c#L271

Please refer to chapter 21 of 6th Generation Intel® Core™ Processor
Platform Controller Hub Family: BIOS Specification.

https://www.intel.in/content/www/in/en/embedded/products/skylake/u-mobile/software-and-drivers.html

Cc: Alan Cox 
Reviewed-by: Andy Shevchenko 
Signed-off-by: Anshuman Gupta 
Signed-off-by: Rajneesh Bhardwaj 
---
Changes in v3:
 * Added x86_pnpbios_disabled and using it instead of pnpbios.
 * Modified the commit message.

Changes in v2:
 * changed to dma_inb()
---
 arch/x86/include/asm/x86_init.h   |  1 +
 arch/x86/kernel/i8237.c   | 25 +
 arch/x86/kernel/platform-quirks.c |  7 ++-
 3 files changed, 32 insertions(+), 1 deletion(-)

diff --git a/arch/x86/include/asm/x86_init.h b/arch/x86/include/asm/x86_init.h
index fc2f082..b6ceac0 100644
--- a/arch/x86/include/asm/x86_init.h
+++ b/arch/x86/include/asm/x86_init.h
@@ -286,6 +286,7 @@ extern struct x86_msi_ops x86_msi;
 extern struct x86_io_apic_ops x86_io_apic_ops;
 
 extern void x86_early_init_platform_quirks(void);
+extern bool x86_pnpbios_disabled(void);
 extern void x86_init_noop(void);
 extern void x86_init_uint_noop(unsigned int unused);
 
diff --git a/arch/x86/kernel/i8237.c b/arch/x86/kernel/i8237.c
index 8eeaa81..0a3e70f 100644
--- a/arch/x86/kernel/i8237.c
+++ b/arch/x86/kernel/i8237.c
@@ -9,10 +9,12 @@
  * your option) any later version.
  */
 
+#include 
 #include 
 #include 
 
 #include 
+#include 
 
 /*
  * This module just handles suspend/resume issues with the
@@ -49,6 +51,29 @@ static struct syscore_ops i8237_syscore_ops = {
 
 static int __init i8237A_init_ops(void)
 {
+   /*
+* From SKL PCH onwards, the legacy DMA device is removed in which the
+* I/O ports (81h-83h, 87h, 89h-8Bh, 8Fh) related to it are removed
+* as well. All removed ports must return 0xff for a inb() request.
+*
+* Note: DMA_PAGE_2 (port 0x81) should not be checked for detecting
+* the presence of DMA device since it may be used by BIOS to decode
+* LPC traffic for POST codes. Original LPC only decodes one byte of
+* port 0x80 but some BIOS may choose to enhance PCH LPC port 0x8x
+* decoding.
+*/
+   if (dma_inb(DMA_PAGE_0) == 0xFF)
+   return -ENODEV;
+
+   /*
+* It is not required to load this driver as newer SoC may not
+* support 8237 DMA or bus mastering from LPC. Platform firmware
+* must announce the support for such legacy devices via
+* ACPI_FADT_LEGACY_DEVICES field in FADT table.
+*/
+   if (x86_pnpbios_disabled() && dmi_get_bios_year() >= 2017)
+   return -ENODEV;
+
register_syscore_ops(_syscore_ops);
return 0;
 }
diff --git a/arch/x86/kernel/platform-quirks.c 
b/arch/x86/kernel/platform-quirks.c
index 235fe60..b348a67 100644
--- a/arch/x86/kernel/platform-quirks.c
+++ b/arch/x86/kernel/platform-quirks.c
@@ -33,9 +33,14 @@ void __init x86_early_init_platform_quirks(void)
x86_platform.set_legacy_features();
 }
 
+bool __init x86_pnpbios_disabled(void)
+{
+   return x86_platform.legacy.devices.pnpbios == 0;
+}
+
 #if defined(CONFIG_PNPBIOS)
 bool __init arch_pnpbios_disabled(void)
 {
-   return x86_platform.legacy.devices.pnpbios == 0;
+   return x86_pnpbios_disabled();
 }
 #endif
-- 
2.7.4

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

[Anshuman Gupta]

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.
For example open source system firmware like coreboot started unsetting
ACPI_FADT_LEGACY_DEVICES field in FADT table very recently.
https://github.com/coreboot/coreboot/blob/05132707ca1e13a11cd13c77326bc65011b09feb/src/soc/intel/skylake/acpi.c#L271

Please refer to chapter 21 of 6th Generation Intel® Core™ Processor
Platform Controller Hub Family: BIOS Specification.

https://www.intel.in/content/www/in/en/embedded/products/skylake/u-mobile/software-and-drivers.html

Cc: Alan Cox 
Reviewed-by: Andy Shevchenko 
Signed-off-by: Anshuman Gupta 
Signed-off-by: Rajneesh Bhardwaj 
---
Changes in v3:
 * Added x86_pnpbios_disabled and using it instead of pnpbios.
 * Modified the commit message.

Changes in v2:
 * changed to dma_inb()
---
 arch/x86/include/asm/x86_init.h   |  1 +
 arch/x86/kernel/i8237.c   | 25 +
 arch/x86/kernel/platform-quirks.c |  7 ++-
 3 files changed, 32 insertions(+), 1 deletion(-)

diff --git a/arch/x86/include/asm/x86_init.h b/arch/x86/include/asm/x86_init.h
index fc2f082..b6ceac0 100644
--- a/arch/x86/include/asm/x86_init.h
+++ b/arch/x86/include/asm/x86_init.h
@@ -286,6 +286,7 @@ extern struct x86_msi_ops x86_msi;
 extern struct x86_io_apic_ops x86_io_apic_ops;
 
 extern void x86_early_init_platform_quirks(void);
+extern bool x86_pnpbios_disabled(void);
 extern void x86_init_noop(void);
 extern void x86_init_uint_noop(unsigned int unused);
 
diff --git a/arch/x86/kernel/i8237.c b/arch/x86/kernel/i8237.c
index 8eeaa81..0a3e70f 100644
--- a/arch/x86/kernel/i8237.c
+++ b/arch/x86/kernel/i8237.c
@@ -9,10 +9,12 @@
  * your option) any later version.
  */
 
+#include 
 #include 
 #include 
 
 #include 
+#include 
 
 /*
  * This module just handles suspend/resume issues with the
@@ -49,6 +51,29 @@ static struct syscore_ops i8237_syscore_ops = {
 
 static int __init i8237A_init_ops(void)
 {
+   /*
+* From SKL PCH onwards, the legacy DMA device is removed in which the
+* I/O ports (81h-83h, 87h, 89h-8Bh, 8Fh) related to it are removed
+* as well. All removed ports must return 0xff for a inb() request.
+*
+* Note: DMA_PAGE_2 (port 0x81) should not be checked for detecting
+* the presence of DMA device since it may be used by BIOS to decode
+* LPC traffic for POST codes. Original LPC only decodes one byte of
+* port 0x80 but some BIOS may choose to enhance PCH LPC port 0x8x
+* decoding.
+*/
+   if (dma_inb(DMA_PAGE_0) == 0xFF)
+   return -ENODEV;
+
+   /*
+* It is not required to load this driver as newer SoC may not
+* support 8237 DMA or bus mastering from LPC. Platform firmware
+* must announce the support for such legacy devices via
+* ACPI_FADT_LEGACY_DEVICES field in FADT table.
+*/
+   if (x86_pnpbios_disabled() && dmi_get_bios_year() >= 2017)
+   return -ENODEV;
+
register_syscore_ops(_syscore_ops);
return 0;
 }
diff --git a/arch/x86/kernel/platform-quirks.c 
b/arch/x86/kernel/platform-quirks.c
index 235fe60..b348a67 100644
--- a/arch/x86/kernel/platform-quirks.c
+++ b/arch/x86/kernel/platform-quirks.c
@@ -33,9 +33,14 @@ void __init x86_early_init_platform_quirks(void)
x86_platform.set_legacy_features();
 }
 
+bool __init x86_pnpbios_disabled(void)
+{
+   return x86_platform.legacy.devices.pnpbios == 0;
+}
+
 #if defined(CONFIG_PNPBIOS)
 bool __init arch_pnpbios_disabled(void)
 {
-   return x86_platform.legacy.devices.pnpbios == 0;
+   return x86_pnpbios_disabled();
 }
 #endif
-- 
2.7.4