public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Stuart Hayes <stuart.w.hayes@gmail.com>
To: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: Darren Hart <dvhart@infradead.org>,
	Douglas_Warzecha@dell.com,
	Mario Limonciello <mario.limonciello@dell.com>,
	Jared.Dominguez@dell.com,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Platform Driver <platform-driver-x86@vger.kernel.org>
Subject: Re: [PATCH v3] dcdbas: Add support for WSMT ACPI table
Date: Thu, 14 Jun 2018 09:22:57 -0500	[thread overview]
Message-ID: <8307f1e0-c480-3f78-9327-e248208e5349@gmail.com> (raw)
In-Reply-To: <CAHp75VcK78jL_7sF+ZGaPpwDED-6Xd+SdH_5WCfSBsVJW2GnDg@mail.gmail.com>


On 6/13/2018 3:54 AM, Andy Shevchenko wrote:
>> +               /* Calling Interface SMI
> 
> I suppose the style of the comments like
> /*
>  * Calling ...
> ...

Yes... goof on my part.  Thanks.

>> +                *
>> +                * Provide physical address of command buffer field within
>> +                * the struct smi_cmd... can't use virt_to_phys on smi_cmd
>> +                * because address may be from memremap.
> 
> Wait, memremap() might return a virtual address. How we be sure that
> we got still physical address here?
> 
> (Also note () when referring to functions)
>
>> +                */
>> +               smi_cmd->ebx = smi_data_buf_phys_addr +
>> +                               offsetof(struct smi_cmd, command_buffer);
> 
> Btw, can it be one line (~83 character are okay for my opinion).
> 

Before this patch, the address in smi_cmd always came from an alloc, so
virt_to_phys() was used to get the physical address here.  With WSMT, we
could be using a BIOS-provided buffer for SMI, in which case the address in
smi_cmd will come from memremap(), so we can't use virt_to_phys() on it.
So instead I changed this to use the physical address of smi_data_buf that
is stored in smi_data_buf_phys_addr, which will be valid regardless of how
the address of smi_data_buf was generated.

But that would be like 97 characters long if I made it all one line...

>> +       acpi_get_table(ACPI_SIG_WSMT, 0, (struct acpi_table_header **)&wsmt);
>> +       if (!wsmt)
>> +               return 0;
>> +
>> +       /* Check if WSMT ACPI table shows that protection is enabled */
>> +       if (!(wsmt->protection_flags & ACPI_WSMT_FIXED_COMM_BUFFERS)
> 
>> +           || !(wsmt->protection_flags
>> +                & ACPI_WSMT_COMM_BUFFER_NESTED_PTR_PROTECTION))
> 
> Better to indent like
> 
> if (... ||
>  !(... & ...)
> 

Yes thanks.

>> +               return 0;
>> +
>> +       /* Scan for EPS (entry point structure) */
>> +       for (addr = (u8 *)__va(0xf0000);
>> +            addr < (u8 *)__va(0x100000 - sizeof(struct smm_eps_table));
> 
>> +            addr += 1) {
> 
> This wasn't commented IIRC and changed. So, why?
> 

I changed this is response to your earlier comment (7 june)... you had pointed
out that it would be better if I put an "if (eps) break;" inside the for loop
instead of having "&& !eps" in the condition of the for loop.  I put the note
"Changed loop searching 0xf0000 to be more readable" in the list of changes for
patch version v3 to cover this change.

Thanks again for your time!

  reply	other threads:[~2018-06-14 14:23 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-05-16 14:05 [PATCH v2] dcdbas: Add support for WSMT ACPI table Stuart Hayes
2018-05-25 19:01 ` Douglas.Warzecha
2018-05-28  5:20   ` Mario.Limonciello
2018-06-07 15:59 ` [PATCH resend " Stuart Hayes
2018-06-07 16:07   ` Mario.Limonciello
2018-06-08 23:08     ` Darren Hart
2018-06-07 17:11   ` Andy Shevchenko
2018-06-09  1:04     ` Darren Hart
2018-06-09 18:57       ` Andy Shevchenko
2018-06-13  1:24         ` [PATCH v3] " Stuart Hayes
2018-06-13  8:54           ` Andy Shevchenko
2018-06-14 14:22             ` Stuart Hayes [this message]
2018-06-14 17:25               ` Andy Shevchenko
2018-06-14 22:31                 ` Stuart Hayes
2018-06-27 23:52                   ` Andy Shevchenko
2018-06-29 18:56                     ` Stuart Hayes
2018-06-29 19:29                       ` Andy Shevchenko
2018-07-02 14:07                         ` Mario.Limonciello
2018-07-02 15:21                           ` Andy Shevchenko
2018-07-02 16:15                             ` Mario.Limonciello
2018-07-03 13:52                               ` Stuart Hayes
2018-07-03 16:20                               ` [PATCH v5] " Stuart Hayes
2018-07-13 14:34                                 ` Andy Shevchenko
2018-07-16 13:37                                   ` Mario.Limonciello
2018-06-14 15:45           ` [PATCH v4] " Stuart Hayes
2018-06-14 17:26             ` Andy Shevchenko
2018-06-26  3:12               ` Stuart Hayes
2018-06-11 13:47       ` [PATCH resend v2] " Mario.Limonciello
2018-06-11 14:30       ` Stuart Hayes

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=8307f1e0-c480-3f78-9327-e248208e5349@gmail.com \
    --to=stuart.w.hayes@gmail.com \
    --cc=Douglas_Warzecha@dell.com \
    --cc=Jared.Dominguez@dell.com \
    --cc=andy.shevchenko@gmail.com \
    --cc=dvhart@infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mario.limonciello@dell.com \
    --cc=platform-driver-x86@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox