linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH] ACPI, APEI: Fixup incorrect 16-bit access width firmware bug
@ 2017-07-21  9:41 Song liwei
  2017-07-21  9:56 ` Andy Shevchenko
  0 siblings, 1 reply; 4+ messages in thread
From: Song liwei @ 2017-07-21  9:41 UTC (permalink / raw)
  To: Rafael J . Wysocki, Len Brown; +Cc: linux-acpi, linux-kernel, LiweiSong

From: Liwei Song <liwei.song@windriver.com>

This is a follow up to commit f712c71f7b2b ("ACPI, APEI: Fixup common
access width firmware bug") fix the following firmware bug:

[Firmware Bug]: APEI: Invalid bit width + offset in GAR [0xb2/16/0/1/1]

This is due to an 8-bit access width is specified for a 16-bit register,
Do bit_width check just like what the original commit have done.

Signed-off-by: Liwei Song <liwei.song@windriver.com>
---
 drivers/acpi/apei/apei-base.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/acpi/apei/apei-base.c b/drivers/acpi/apei/apei-base.c
index da370e1..7e47bc6 100644
--- a/drivers/acpi/apei/apei-base.c
+++ b/drivers/acpi/apei/apei-base.c
@@ -610,6 +610,9 @@ static int apei_check_gar(struct acpi_generic_address *reg, u64 *paddr,
 	else if (bit_width == 64 && bit_offset == 0 && (*paddr & 0x07) == 0 &&
 	    *access_bit_width < 64)
 		*access_bit_width = 64;
+	else if (bit_width == 16 && bit_offset == 0 && (*paddr & 0x01) == 0 &&
+	    *access_bit_width < 16)
+		*access_bit_width = 16;
 
 	if ((bit_width + bit_offset) > *access_bit_width) {
 		pr_warning(FW_BUG APEI_PFX
-- 
2.7.4

^ permalink raw reply related	[flat|nested] 4+ messages in thread

* Re: [PATCH] ACPI, APEI: Fixup incorrect 16-bit access width firmware bug
  2017-07-21  9:41 [PATCH] ACPI, APEI: Fixup incorrect 16-bit access width firmware bug Song liwei
@ 2017-07-21  9:56 ` Andy Shevchenko
  2017-07-26  6:16   ` Liwei Song
  0 siblings, 1 reply; 4+ messages in thread
From: Andy Shevchenko @ 2017-07-21  9:56 UTC (permalink / raw)
  To: Song liwei; +Cc: Rafael J . Wysocki, Len Brown, linux-acpi, linux-kernel

On Fri, Jul 21, 2017 at 12:41 PM, Song liwei <liwei.song@windriver.com> wrote:

> [Firmware Bug]: APEI: Invalid bit width + offset in GAR [0xb2/16/0/1/1]
>
> This is due to an 8-bit access width is specified for a 16-bit register,
> Do bit_width check just like what the original commit have done.

>         else if (bit_width == 64 && bit_offset == 0 && (*paddr & 0x07) == 0 &&
>             *access_bit_width < 64)
>                 *access_bit_width = 64;
> +       else if (bit_width == 16 && bit_offset == 0 && (*paddr & 0x01) == 0 &&
> +           *access_bit_width < 16)
> +               *access_bit_width = 16;

Wouldn't be better to rearrange that it will go in a sequence
(16,32,64 or 64,32,16) ?

or move bit_offset == 0 into external condion

    /* Fixup common BIOS bug */
    if (bit_offset == 0) {
      if (bit_width == 16 && (*paddr & 0x01) == 0 && *access_bit_width < 16)
               *access_bit_width = 16;
      else if (bit_width == 32 && (*paddr & 0x03) == 0 &&
*access_bit_width < 32)
               *access_bit_width = 32;
      else if (bit_width == 64 && (*paddr & 0x07) == 0 &&
*access_bit_width < 64)
               *access_bit_width = 64;
    }


It might be (I'm not sure it will make it better, just a side note)
considered to convert each internal conditional to

...if (bit_width == XX && (*paddr & YY) == 0)
               *access_bit_width = max(*access_bit_width, bit_width);

-- 
With Best Regards,
Andy Shevchenko

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH] ACPI, APEI: Fixup incorrect 16-bit access width firmware bug
  2017-07-21  9:56 ` Andy Shevchenko
@ 2017-07-26  6:16   ` Liwei Song
  2017-07-26 10:44     ` Andy Shevchenko
  0 siblings, 1 reply; 4+ messages in thread
From: Liwei Song @ 2017-07-26  6:16 UTC (permalink / raw)
  To: Andy Shevchenko; +Cc: Rafael J . Wysocki, Len Brown, linux-acpi, linux-kernel



On 07/21/2017 05:56 PM, Andy Shevchenko wrote:
> On Fri, Jul 21, 2017 at 12:41 PM, Song liwei <liwei.song@windriver.com> wrote:
> 
>> [Firmware Bug]: APEI: Invalid bit width + offset in GAR [0xb2/16/0/1/1]
>>
>> This is due to an 8-bit access width is specified for a 16-bit register,
>> Do bit_width check just like what the original commit have done.
> 
>>         else if (bit_width == 64 && bit_offset == 0 && (*paddr & 0x07) == 0 &&
>>             *access_bit_width < 64)
>>                 *access_bit_width = 64;
>> +       else if (bit_width == 16 && bit_offset == 0 && (*paddr & 0x01) == 0 &&
>> +           *access_bit_width < 16)
>> +               *access_bit_width = 16;
> 
> Wouldn't be better to rearrange that it will go in a sequence
> (16,32,64 or 64,32,16) ?
> 
> or move bit_offset == 0 into external condion
> 
>     /* Fixup common BIOS bug */
>     if (bit_offset == 0) {
>       if (bit_width == 16 && (*paddr & 0x01) == 0 && *access_bit_width < 16)
>                *access_bit_width = 16;
>       else if (bit_width == 32 && (*paddr & 0x03) == 0 &&
> *access_bit_width < 32)
>                *access_bit_width = 32;
>       else if (bit_width == 64 && (*paddr & 0x07) == 0 &&
> *access_bit_width < 64)
>                *access_bit_width = 64;
>     }
> 
> 
> It might be (I'm not sure it will make it better, just a side note)
> considered to convert each internal conditional to
> 
> ...if (bit_width == XX && (*paddr & YY) == 0)
>                *access_bit_width = max(*access_bit_width, bit_width);

Hi Andy,

Thanks for your suggestion, what about the condition like the following?
The main bug in bios is bit_width is not comfortable with access_bit_width
So check it first.

if (*access_bit_width < bit_width && bit_offset == 0) {
	if ((bit_width == 16 && (*paddr & 0x01) == 0) ||
	    (bit_width == 32 && (*paddr & 0x03) == 0) ||
	    (bit_width == 64 && (*paddr & 0x07) == 0))
		*access_bit_width = bit_width;
}


Thanks,
Liwei.


> 

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH] ACPI, APEI: Fixup incorrect 16-bit access width firmware bug
  2017-07-26  6:16   ` Liwei Song
@ 2017-07-26 10:44     ` Andy Shevchenko
  0 siblings, 0 replies; 4+ messages in thread
From: Andy Shevchenko @ 2017-07-26 10:44 UTC (permalink / raw)
  To: Liwei Song; +Cc: Rafael J . Wysocki, Len Brown, linux-acpi, linux-kernel

On Wed, Jul 26, 2017 at 9:16 AM, Liwei Song <liwei.song@windriver.com> wrote:
> On 07/21/2017 05:56 PM, Andy Shevchenko wrote:
>> On Fri, Jul 21, 2017 at 12:41 PM, Song liwei <liwei.song@windriver.com> wrote:

>>     /* Fixup common BIOS bug */
>>     if (bit_offset == 0) {
>>       if (bit_width == 16 && (*paddr & 0x01) == 0 && *access_bit_width < 16)
>>                *access_bit_width = 16;
>>       else if (bit_width == 32 && (*paddr & 0x03) == 0 &&
>> *access_bit_width < 32)
>>                *access_bit_width = 32;
>>       else if (bit_width == 64 && (*paddr & 0x07) == 0 &&
>> *access_bit_width < 64)
>>                *access_bit_width = 64;
>>     }

> Thanks for your suggestion, what about the condition like the following?
> The main bug in bios is bit_width is not comfortable with access_bit_width
> So check it first.
>
> if (*access_bit_width < bit_width && bit_offset == 0) {
>         if ((bit_width == 16 && (*paddr & 0x01) == 0) ||
>             (bit_width == 32 && (*paddr & 0x03) == 0) ||
>             (bit_width == 64 && (*paddr & 0x07) == 0))
>                 *access_bit_width = bit_width;
> }

Either works to me.

P.S. Less explicit case is to use bit operations to check those, i.e.
is_power_of_2(), fls().

-- 
With Best Regards,
Andy Shevchenko

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2017-07-26 10:44 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-07-21  9:41 [PATCH] ACPI, APEI: Fixup incorrect 16-bit access width firmware bug Song liwei
2017-07-21  9:56 ` Andy Shevchenko
2017-07-26  6:16   ` Liwei Song
2017-07-26 10:44     ` Andy Shevchenko

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).