[PATCH 1/2] ata: ahci: Refactor ahci_broken_lpm()

[PATCH 1/2] ata: ahci: Refactor ahci_broken_lpm()

[Niklas Cassel]

Currently, the match table in ahci_broken_lpm() contains DMI BIOS dates
of BIOSes that are known to be working.

Having a list of known to be working versions is usually the wrong way to
do things (as this list could theoretically be infinite).

Refactor this match table to contain DMI BIOS dates of BIOSes that are
known to not be working, such that this list can be extended with BIOS
versions (for other boards) that are known to not be working, where there
is no good BIOS version (because all released versions are broken).

Signed-off-by: Niklas Cassel <cassel@kernel.org>
---
 drivers/ata/ahci.c | 34 ++++++++++++++++++++++++----------
 1 file changed, 24 insertions(+), 10 deletions(-)

diff --git a/drivers/ata/ahci.c b/drivers/ata/ahci.c
index 163ac909bd06..a6ce172fa928 100644
--- a/drivers/ata/ahci.c
+++ b/drivers/ata/ahci.c
@@ -1411,27 +1411,39 @@ static bool ahci_broken_suspend(struct pci_dev *pdev)
 static bool ahci_broken_lpm(struct pci_dev *pdev)
 {
 	static const struct dmi_system_id sysids[] = {
-		/* Various Lenovo 50 series have LPM issues with older BIOSen */
+		/* Table contains DMI BIOS dates of BIOSes with broken LPM. */
 		{
 			.matches = {
 				DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
 				DMI_MATCH(DMI_PRODUCT_VERSION, "ThinkPad X250"),
 			},
-			.driver_data = "20180406", /* 1.31 */
+			/*
+			 * 1.31, released 20180406, has working LPM, mark any
+			 * DMI BIOS date before that as broken.
+			 */
+			.driver_data = "20180405",
 		},
 		{
 			.matches = {
 				DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
 				DMI_MATCH(DMI_PRODUCT_VERSION, "ThinkPad L450"),
 			},
-			.driver_data = "20180420", /* 1.28 */
+			/*
+			 * 1.28, released 20180420, has working LPM, mark any
+			 * DMI BIOS date before that as broken.
+			 */
+			.driver_data = "20180419",
 		},
 		{
 			.matches = {
 				DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
 				DMI_MATCH(DMI_PRODUCT_VERSION, "ThinkPad T450s"),
 			},
-			.driver_data = "20180315", /* 1.33 */
+			/*
+			 * 1.33, released 20180315, has working LPM, mark any
+			 * DMI BIOS date before that as broken.
+			 */
+			.driver_data = "20180314",
 		},
 		{
 			.matches = {
@@ -1439,12 +1451,14 @@ static bool ahci_broken_lpm(struct pci_dev *pdev)
 				DMI_MATCH(DMI_PRODUCT_VERSION, "ThinkPad W541"),
 			},
 			/*
-			 * Note date based on release notes, 2.35 has been
-			 * reported to be good, but I've been unable to get
-			 * a hold of the reporter to get the DMI BIOS date.
-			 * TODO: fix this.
+			 * Note: according to release notes, version 2.35 has
+			 * working LPM, but we do not have the DMI BIOS date for
+			 * this version, so the date, 20180310, is based on the
+			 * release notes. Mark any DMI BIOS date before that as
+			 * broken.
+			 * TODO: find with date with DMI BIOS date.
 			 */
-			.driver_data = "20180310", /* 2.35 */
+			.driver_data = "20180309",
 		},
 		{ }	/* terminate list */
 	};
@@ -1458,7 +1472,7 @@ static bool ahci_broken_lpm(struct pci_dev *pdev)
 	dmi_get_date(DMI_BIOS_DATE, &year, &month, &date);
 	snprintf(buf, sizeof(buf), "%04d%02d%02d", year, month, date);
 
-	return strcmp(buf, dmi->driver_data) < 0;
+	return strcmp(buf, dmi->driver_data) <= 0;
 }
 
 static bool ahci_broken_online(struct pci_dev *pdev)
-- 
2.49.0

[PATCH 2/2] ata: ahci: Disallow LPM for ASUSPRO-D840SA motherboard

[Niklas Cassel]

A user has bisected a regression which causes graphical corruptions on his
screen to commit 7627a0edef54 ("ata: ahci: Drop low power policy board
type").

Simply reverting commit 7627a0edef54 ("ata: ahci: Drop low power policy
board type") makes the graphical corruptions on his screen to go away.
(Note: there are no visible messages in dmesg that indicates a problem
with AHCI.)

The user also reports that the problem occurs regardless if there is an
HDD or an SSD connected via AHCI, so the problem is not device related.

The devices also work fine on other motherboards, so it seems specific to
the ASUSPRO-D840SA motherboard.

While enabling low power modes for AHCI is not supposed to affect
completely unrelated hardware, like a graphics card, it does however
allow the system to enter deeper PC-states, which could expose ACPI issues
that were previously not visible (because the system never entered these
lower power states before).

There are previous examples where enabling LPM exposed serious BIOS/ACPI
bugs, see e.g. commit 240630e61870 ("ahci: Disable LPM on Lenovo 50 series
laptops with a too old BIOS").

Since there hasn't been any BIOS update in years for the ASUSPRO-D840SA
motherboard, disable LPM for this board, in order to avoid entering lower
PC-states, which triggers graphical corruptions.

Cc: stable+noautosel@kernel.org # Depends on ahci_broken_lpm() refactor
Reported-by: Andy Yang <andyybtc79@gmail.com>
Closes: https://bugzilla.kernel.org/show_bug.cgi?id=220111
Fixes: 7627a0edef54 ("ata: ahci: Drop low power policy board type")
Signed-off-by: Niklas Cassel <cassel@kernel.org>
---
 drivers/ata/ahci.c | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/drivers/ata/ahci.c b/drivers/ata/ahci.c
index a6ce172fa928..be464d0f46a4 100644
--- a/drivers/ata/ahci.c
+++ b/drivers/ata/ahci.c
@@ -1460,6 +1460,17 @@ static bool ahci_broken_lpm(struct pci_dev *pdev)
 			 */
 			.driver_data = "20180309",
 		},
+		{
+			.matches = {
+				DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
+				DMI_MATCH(DMI_PRODUCT_VERSION, "ASUSPRO D840MB_M840SA"),
+			},
+			/*
+			 * 320, released 20230208, has broken LPM, no working
+			 * BIOS has been released at time of writing.
+			 */
+			.driver_data = "20230208",
+		},
 		{ }	/* terminate list */
 	};
 	const struct dmi_system_id *dmi = dmi_first_match(sysids);
-- 
2.49.0

Re: [PATCH 2/2] ata: ahci: Disallow LPM for ASUSPRO-D840SA motherboard

[Hans de Goede]

Hi Niklas,

On 9-Jun-25 3:45 PM, Niklas Cassel wrote:
> A user has bisected a regression which causes graphical corruptions on his
> screen to commit 7627a0edef54 ("ata: ahci: Drop low power policy board
> type").
> 
> Simply reverting commit 7627a0edef54 ("ata: ahci: Drop low power policy
> board type") makes the graphical corruptions on his screen to go away.
> (Note: there are no visible messages in dmesg that indicates a problem
> with AHCI.)
> 
> The user also reports that the problem occurs regardless if there is an
> HDD or an SSD connected via AHCI, so the problem is not device related.
> 
> The devices also work fine on other motherboards, so it seems specific to
> the ASUSPRO-D840SA motherboard.
> 
> While enabling low power modes for AHCI is not supposed to affect
> completely unrelated hardware, like a graphics card, it does however
> allow the system to enter deeper PC-states, which could expose ACPI issues
> that were previously not visible (because the system never entered these
> lower power states before).
> 
> There are previous examples where enabling LPM exposed serious BIOS/ACPI
> bugs, see e.g. commit 240630e61870 ("ahci: Disable LPM on Lenovo 50 series
> laptops with a too old BIOS").
> 
> Since there hasn't been any BIOS update in years for the ASUSPRO-D840SA
> motherboard, disable LPM for this board, in order to avoid entering lower
> PC-states, which triggers graphical corruptions.
> 
> Cc: stable+noautosel@kernel.org # Depends on ahci_broken_lpm() refactor
> Reported-by: Andy Yang <andyybtc79@gmail.com>
> Closes: https://bugzilla.kernel.org/show_bug.cgi?id=220111
> Fixes: 7627a0edef54 ("ata: ahci: Drop low power policy board type")
> Signed-off-by: Niklas Cassel <cassel@kernel.org>
> ---
>  drivers/ata/ahci.c | 11 +++++++++++
>  1 file changed, 11 insertions(+)
> 
> diff --git a/drivers/ata/ahci.c b/drivers/ata/ahci.c
> index a6ce172fa928..be464d0f46a4 100644
> --- a/drivers/ata/ahci.c
> +++ b/drivers/ata/ahci.c
> @@ -1460,6 +1460,17 @@ static bool ahci_broken_lpm(struct pci_dev *pdev)
>  			 */
>  			.driver_data = "20180309",
>  		},
> +		{
> +			.matches = {
> +				DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
> +				DMI_MATCH(DMI_PRODUCT_VERSION, "ASUSPRO D840MB_M840SA"),
> +			},
> +			/*
> +			 * 320, released 20230208, has broken LPM, no working
> +			 * BIOS has been released at time of writing.
> +			 */
> +			.driver_data = "20230208",
> +		},

Same remark about using "released" in the comment. Otherwise
both patches look good to me:

Reviewed-by: Hans de Goede <hansg@kernel.org>

for the series.

Regards,

Hans




>  		{ }	/* terminate list */
>  	};
>  	const struct dmi_system_id *dmi = dmi_first_match(sysids);

Re: [PATCH 1/2] ata: ahci: Refactor ahci_broken_lpm()

[Hans de Goede]

Hi Niklas,

On 9-Jun-25 3:45 PM, Niklas Cassel wrote:
> Currently, the match table in ahci_broken_lpm() contains DMI BIOS dates
> of BIOSes that are known to be working.
> 
> Having a list of known to be working versions is usually the wrong way to
> do things (as this list could theoretically be infinite).
> 
> Refactor this match table to contain DMI BIOS dates of BIOSes that are
> known to not be working, such that this list can be extended with BIOS
> versions (for other boards) that are known to not be working, where there
> is no good BIOS version (because all released versions are broken).
> 
> Signed-off-by: Niklas Cassel <cassel@kernel.org>
> ---
>  drivers/ata/ahci.c | 34 ++++++++++++++++++++++++----------
>  1 file changed, 24 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/ata/ahci.c b/drivers/ata/ahci.c
> index 163ac909bd06..a6ce172fa928 100644
> --- a/drivers/ata/ahci.c
> +++ b/drivers/ata/ahci.c
> @@ -1411,27 +1411,39 @@ static bool ahci_broken_suspend(struct pci_dev *pdev)
>  static bool ahci_broken_lpm(struct pci_dev *pdev)
>  {
>  	static const struct dmi_system_id sysids[] = {
> -		/* Various Lenovo 50 series have LPM issues with older BIOSen */
> +		/* Table contains DMI BIOS dates of BIOSes with broken LPM. */
>  		{
>  			.matches = {
>  				DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
>  				DMI_MATCH(DMI_PRODUCT_VERSION, "ThinkPad X250"),
>  			},
> -			.driver_data = "20180406", /* 1.31 */
> +			/*
> +			 * 1.31, released 20180406, has working LPM, mark any
> +			 * DMI BIOS date before that as broken.
> +			 */

Note the DMI_BIOS_DATE field is the data the BIOS was build, I would avoid
the word "released" here since release-notes doucments often contain different
dates then the actual build date (e.g. see below).

> +			.driver_data = "20180405",
>  		},
>  		{
>  			.matches = {
>  				DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
>  				DMI_MATCH(DMI_PRODUCT_VERSION, "ThinkPad L450"),
>  			},
> -			.driver_data = "20180420", /* 1.28 */
> +			/*
> +			 * 1.28, released 20180420, has working LPM, mark any
> +			 * DMI BIOS date before that as broken.
> +			 */
> +			.driver_data = "20180419",
>  		},
>  		{
>  			.matches = {
>  				DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
>  				DMI_MATCH(DMI_PRODUCT_VERSION, "ThinkPad T450s"),
>  			},
> -			.driver_data = "20180315", /* 1.33 */
> +			/*
> +			 * 1.33, released 20180315, has working LPM, mark any
> +			 * DMI BIOS date before that as broken.
> +			 */
> +			.driver_data = "20180314",
>  		},
>  		{
>  			.matches = {
> @@ -1439,12 +1451,14 @@ static bool ahci_broken_lpm(struct pci_dev *pdev)
>  				DMI_MATCH(DMI_PRODUCT_VERSION, "ThinkPad W541"),
>  			},
>  			/*
> -			 * Note date based on release notes, 2.35 has been
> -			 * reported to be good, but I've been unable to get
> -			 * a hold of the reporter to get the DMI BIOS date.
> -			 * TODO: fix this.
> +			 * Note: according to release notes, version 2.35 has
> +			 * working LPM, but we do not have the DMI BIOS date for
> +			 * this version, so the date, 20180310, is based on the
> +			 * release notes. Mark any DMI BIOS date before that as
> +			 * broken.
> +			 * TODO: find with date with DMI BIOS date.
>  			 */
> -			.driver_data = "20180310", /* 2.35 */
> +			.driver_data = "20180309",

This reminds me that I did eventually got the actual BIOS date from
the reporter. After some digging I managed to find the email.

The first known working BIOS has a BIOS date of 04/09/2018 so that
would become "20180409" before your patch / "20180408" after your patch.

I guess you may want to add a prep patch before the rest of this
series before this patch to make things a bit cleaner.

Regards,

Hans





>  		},
>  		{ }	/* terminate list */
>  	};
> @@ -1458,7 +1472,7 @@ static bool ahci_broken_lpm(struct pci_dev *pdev)
>  	dmi_get_date(DMI_BIOS_DATE, &year, &month, &date);
>  	snprintf(buf, sizeof(buf), "%04d%02d%02d", year, month, date);
>  
> -	return strcmp(buf, dmi->driver_data) < 0;
> +	return strcmp(buf, dmi->driver_data) <= 0;
>  }
>  
>  static bool ahci_broken_online(struct pci_dev *pdev)

Re: [PATCH 1/2] ata: ahci: Refactor ahci_broken_lpm()

[Hans de Goede]

Hi,

On 9-Jun-25 4:49 PM, Hans de Goede wrote:
> Hi Niklas,
> 
> On 9-Jun-25 3:45 PM, Niklas Cassel wrote:
>> Currently, the match table in ahci_broken_lpm() contains DMI BIOS dates
>> of BIOSes that are known to be working.
>>
>> Having a list of known to be working versions is usually the wrong way to
>> do things (as this list could theoretically be infinite).
>>
>> Refactor this match table to contain DMI BIOS dates of BIOSes that are
>> known to not be working, such that this list can be extended with BIOS
>> versions (for other boards) that are known to not be working, where there
>> is no good BIOS version (because all released versions are broken).
>>
>> Signed-off-by: Niklas Cassel <cassel@kernel.org>
>> ---
>>  drivers/ata/ahci.c | 34 ++++++++++++++++++++++++----------
>>  1 file changed, 24 insertions(+), 10 deletions(-)
>>
>> diff --git a/drivers/ata/ahci.c b/drivers/ata/ahci.c
>> index 163ac909bd06..a6ce172fa928 100644
>> --- a/drivers/ata/ahci.c
>> +++ b/drivers/ata/ahci.c
>> @@ -1411,27 +1411,39 @@ static bool ahci_broken_suspend(struct pci_dev *pdev)
>>  static bool ahci_broken_lpm(struct pci_dev *pdev)
>>  {
>>  	static const struct dmi_system_id sysids[] = {
>> -		/* Various Lenovo 50 series have LPM issues with older BIOSen */
>> +		/* Table contains DMI BIOS dates of BIOSes with broken LPM. */
>>  		{
>>  			.matches = {
>>  				DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
>>  				DMI_MATCH(DMI_PRODUCT_VERSION, "ThinkPad X250"),
>>  			},
>> -			.driver_data = "20180406", /* 1.31 */
>> +			/*
>> +			 * 1.31, released 20180406, has working LPM, mark any
>> +			 * DMI BIOS date before that as broken.
>> +			 */
> 
> Note the DMI_BIOS_DATE field is the data the BIOS was build, I would avoid
> the word "released" here since release-notes doucments often contain different
> dates then the actual build date (e.g. see below).
> 
>> +			.driver_data = "20180405",
>>  		},
>>  		{
>>  			.matches = {
>>  				DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
>>  				DMI_MATCH(DMI_PRODUCT_VERSION, "ThinkPad L450"),
>>  			},
>> -			.driver_data = "20180420", /* 1.28 */
>> +			/*
>> +			 * 1.28, released 20180420, has working LPM, mark any
>> +			 * DMI BIOS date before that as broken.
>> +			 */
>> +			.driver_data = "20180419",
>>  		},
>>  		{
>>  			.matches = {
>>  				DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
>>  				DMI_MATCH(DMI_PRODUCT_VERSION, "ThinkPad T450s"),
>>  			},
>> -			.driver_data = "20180315", /* 1.33 */
>> +			/*
>> +			 * 1.33, released 20180315, has working LPM, mark any
>> +			 * DMI BIOS date before that as broken.
>> +			 */
>> +			.driver_data = "20180314",
>>  		},
>>  		{
>>  			.matches = {
>> @@ -1439,12 +1451,14 @@ static bool ahci_broken_lpm(struct pci_dev *pdev)
>>  				DMI_MATCH(DMI_PRODUCT_VERSION, "ThinkPad W541"),
>>  			},
>>  			/*
>> -			 * Note date based on release notes, 2.35 has been
>> -			 * reported to be good, but I've been unable to get
>> -			 * a hold of the reporter to get the DMI BIOS date.
>> -			 * TODO: fix this.
>> +			 * Note: according to release notes, version 2.35 has
>> +			 * working LPM, but we do not have the DMI BIOS date for
>> +			 * this version, so the date, 20180310, is based on the
>> +			 * release notes. Mark any DMI BIOS date before that as
>> +			 * broken.
>> +			 * TODO: find with date with DMI BIOS date.
>>  			 */
>> -			.driver_data = "20180310", /* 2.35 */
>> +			.driver_data = "20180309",
> 
> This reminds me that I did eventually got the actual BIOS date from
> the reporter. After some digging I managed to find the email.
> 
> The first known working BIOS has a BIOS build date of 04/09/2018 so that
> would become "20180409" before your patch / "20180408" after your patch.
> 
> I guess you may want to add a prep patch before the rest of this
> series before this patch to make things a bit cleaner.

Quick followup on this, the original "20180310" was picked to be
one day older then the release-date (which is always after
the build-date) of the known broken 2.34 version.

Here are the release-dates from the release-notes:

https://download.lenovo.com/pccbbs/mobiles/gnuj39us.txt
 
  2.42  (GNUJ39US)  2.42  (GNET94WW)      1.15  (GMHT30WW)    01    2021/06/10
  2.41  (GNUJ38US)  2.41  (GNET93WW)      1.15  (GMHT30WW)    01    2020/05/11
  2.40  (GNUJ37US)  2.40  (GNET92WW)      1.15  (GMHT30WW)    01    2019/09/12
  2.39  (GNUJ36US)  2.39  (GNET91WW)      1.14  (GMHT29WW)    01    2019/06/05
  2.38  (GNUJ35US)  2.38  (GNET90WW)      1.14  (GMHT29WW)    01    2019/03/29
  2.37  (GNUJ34US)  2.37  (GNET89WW)      1.14  (GMHT29WW)    01    2018/11/30
  2.36  (GNUJ33US)  2.36  (GNET88WW)      1.14  (GMHT29WW)    01    2018/06/21
  2.35  (GNUJ32US)  2.35  (GNET87WW)      1.14  (GMHT29WW)    01    2018/04/16
  2.34  (GNUJ31US)  2.34  (GNET86WW)      1.14  (GMHT29WW)    01    2018/03/09
  2.33  (GNUJ30US)  2.33  (GNET85WW)      1.14  (GMHT29WW)    01    2017/12/20
  2.32  (GNUJ29US)  2.32  (GNET84WW)      1.14  (GMHT29WW)    01    2017/09/21
  2.31  (GNUJ28US)  2.31  (GNET83WW)      1.14  (GMHT29WW)    01    2017/05/11
  2.30  (GNUJ27US)  2.30  (GNET82WW)      1.14  (GMHT29WW)    01    2017/04/07

As you can see the known working 2.35 was released at 2018/04/16
so just a few days after its build date of 2018/04/09 .

Regards,
 
Hans



>>  		},
>>  		{ }	/* terminate list */
>>  	};
>> @@ -1458,7 +1472,7 @@ static bool ahci_broken_lpm(struct pci_dev *pdev)
>>  	dmi_get_date(DMI_BIOS_DATE, &year, &month, &date);
>>  	snprintf(buf, sizeof(buf), "%04d%02d%02d", year, month, date);
>>  
>> -	return strcmp(buf, dmi->driver_data) < 0;
>> +	return strcmp(buf, dmi->driver_data) <= 0;
>>  }
>>  
>>  static bool ahci_broken_online(struct pci_dev *pdev)
> 

Re: [PATCH 1/2] ata: ahci: Refactor ahci_broken_lpm()

[Niklas Cassel]

Hello Hans,

On Mon, Jun 09, 2025 at 04:49:17PM +0200, Hans de Goede wrote:
> On 9-Jun-25 3:45 PM, Niklas Cassel wrote:
> > Currently, the match table in ahci_broken_lpm() contains DMI BIOS dates
> > of BIOSes that are known to be working.
> > 
> > Having a list of known to be working versions is usually the wrong way to
> > do things (as this list could theoretically be infinite).
> > 
> > Refactor this match table to contain DMI BIOS dates of BIOSes that are
> > known to not be working, such that this list can be extended with BIOS
> > versions (for other boards) that are known to not be working, where there
> > is no good BIOS version (because all released versions are broken).
> > 
> > Signed-off-by: Niklas Cassel <cassel@kernel.org>
> > ---
> >  drivers/ata/ahci.c | 34 ++++++++++++++++++++++++----------
> >  1 file changed, 24 insertions(+), 10 deletions(-)
> > 
> > diff --git a/drivers/ata/ahci.c b/drivers/ata/ahci.c
> > index 163ac909bd06..a6ce172fa928 100644
> > --- a/drivers/ata/ahci.c
> > +++ b/drivers/ata/ahci.c
> > @@ -1411,27 +1411,39 @@ static bool ahci_broken_suspend(struct pci_dev *pdev)
> >  static bool ahci_broken_lpm(struct pci_dev *pdev)
> >  {
> >  	static const struct dmi_system_id sysids[] = {
> > -		/* Various Lenovo 50 series have LPM issues with older BIOSen */
> > +		/* Table contains DMI BIOS dates of BIOSes with broken LPM. */
> >  		{
> >  			.matches = {
> >  				DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
> >  				DMI_MATCH(DMI_PRODUCT_VERSION, "ThinkPad X250"),
> >  			},
> > -			.driver_data = "20180406", /* 1.31 */
> > +			/*
> > +			 * 1.31, released 20180406, has working LPM, mark any
> > +			 * DMI BIOS date before that as broken.
> > +			 */
> 
> Note the DMI_BIOS_DATE field is the data the BIOS was build, I would avoid
> the word "released" here since release-notes doucments often contain different
> dates then the actual build date (e.g. see below).

Hm... the command to get this date is:
$ dmidecode -s bios-release-date

So in one way, I think this is the correct term.

But indeed, the "release date" in the release notes is usually different
from the "dmidecode -s bios-release-date" date, so perhaps just to avoid
confusion, using "build date" rather than "released"/"release date" is a
good idea.


> 
> > +			.driver_data = "20180405",
> >  		},
> >  		{
> >  			.matches = {
> >  				DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
> >  				DMI_MATCH(DMI_PRODUCT_VERSION, "ThinkPad L450"),
> >  			},
> > -			.driver_data = "20180420", /* 1.28 */
> > +			/*
> > +			 * 1.28, released 20180420, has working LPM, mark any
> > +			 * DMI BIOS date before that as broken.
> > +			 */
> > +			.driver_data = "20180419",
> >  		},
> >  		{
> >  			.matches = {
> >  				DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
> >  				DMI_MATCH(DMI_PRODUCT_VERSION, "ThinkPad T450s"),
> >  			},
> > -			.driver_data = "20180315", /* 1.33 */
> > +			/*
> > +			 * 1.33, released 20180315, has working LPM, mark any
> > +			 * DMI BIOS date before that as broken.
> > +			 */
> > +			.driver_data = "20180314",
> >  		},
> >  		{
> >  			.matches = {
> > @@ -1439,12 +1451,14 @@ static bool ahci_broken_lpm(struct pci_dev *pdev)
> >  				DMI_MATCH(DMI_PRODUCT_VERSION, "ThinkPad W541"),
> >  			},
> >  			/*
> > -			 * Note date based on release notes, 2.35 has been
> > -			 * reported to be good, but I've been unable to get
> > -			 * a hold of the reporter to get the DMI BIOS date.
> > -			 * TODO: fix this.
> > +			 * Note: according to release notes, version 2.35 has
> > +			 * working LPM, but we do not have the DMI BIOS date for
> > +			 * this version, so the date, 20180310, is based on the
> > +			 * release notes. Mark any DMI BIOS date before that as
> > +			 * broken.
> > +			 * TODO: find with date with DMI BIOS date.
> >  			 */
> > -			.driver_data = "20180310", /* 2.35 */
> > +			.driver_data = "20180309",
> 
> This reminds me that I did eventually got the actual BIOS date from
> the reporter. After some digging I managed to find the email.
> 
> The first known working BIOS has a BIOS date of 04/09/2018 so that
> would become "20180409" before your patch / "20180408" after your patch.
> 
> I guess you may want to add a prep patch before the rest of this
> series before this patch to make things a bit cleaner.

Thank you!

I will send a V2 with the proper date as a patch 1/3.


Kind regards,
Niklas