X86 platform drivers
 help / color / mirror / Atom feed
From: "Limonciello, Mario" <mario.limonciello@amd.com>
To: Jorge Lopez <jorgealtxwork@gmail.com>,
	Hans de Goede <hdegoede@redhat.com>
Cc: platform-driver-x86@vger.kernel.org
Subject: Re: [PATCH v1 1/1] Introduction of HP-BIOSCFG driver
Date: Mon, 17 Oct 2022 09:29:12 -0500	[thread overview]
Message-ID: <dbffc3c3-9fbf-8d7d-99a9-29d44671e7f2@amd.com> (raw)
In-Reply-To: <CAOOmCE9fuHTTVcSUSC0SU3N_ht8uVLg4hGUAJE7bJgs6UAt3gA@mail.gmail.com>

FYI When you submit v3, you don't need to add "new patches on top" for 
your feedbacks to the new driver, they can roll into the patch 
introducing hp-cfg.  Just make sure you include a changelog under your 
cut line to indicate you changed these from vX->vY

I suspect that Hans will also want you to split the driver up into 
smaller bite-size patches to make his review easier as well, but I'll 
let him advise how he wants it done.

On 10/17/2022 09:11, Jorge Lopez wrote:
> ''Hi Mario,
> 
> Please see comments to previous source comments.
<snip>

>>> Thanks.  If you make this change for v2, I can make the matching change
>>> in fwupd so that if it notices current_value permissions like this that
>>> it shows read only there too.
>>
>> Submitted the recommended changes for review in v2
>>

Thanks, looks good.

>> Submitted a patch to improve the friendly display name for
>> few numbers of attributes associated with ‘Schedule Power-ON.’  BIOS
>> assign names such ‘Tuesday’ to an attribute. The name is correct, but
>> it is not descriptive enough for the user.  Under those
>> conditions a portion of the path data value is appended to the attribute
>> name to create a user-friendly display name.
>>
>> For instance, the attribute name is ‘Tuesday,’ and the display name
>> value is ‘Schedule Power-ON – Tuesday’

Looks good

>>>>>
>>>>> Presumably if this is going into it's own directory you should move all
>>>>> platform-x86 HP drivers to this directory earlier in the series too.
> 
> The other drivers named HP-WMI and HP_ACCEL  were written by third
> party members and not by HP.   It is for this reason and because of
> the number of files, only hp-bioscfg was placed in a separate
> directory.   Let me know If my reasoning is not valid enough  and I
> will keep the files in a separate directory and move the selection to
> the main list.    In addition, Moving  HP-WMI and HP_ACCEL drivers
> from x86 directories fall outside of the scope of these changes,
> Correct?
> 

There is no distinction who writes a driver.  I think either you keep 
this driver in the root of drivers/platform/x86 or you put all the HP 
drivers in drivers/platform/x86/hp.

I think if you're going to put this driver in the sub-directory "hp", 
then the first patch in this series should be to move those drivers to 
that sub-directory.  The second patch should be to introduce your new 
driver.

> 
> The build process was tested with the latest  drivers/platform/x86
> from branch for-next.
> Nonetheless, I will investigate.

I did my test on 6.0 rather than for-next.  But given it's a header 
issue I suspect you have a miss that works with the compiler I'm using.

I was using gcc 11.2.0 on Ubuntu 22.04.

<snip>

  reply	other threads:[~2022-10-17 14:29 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-10 16:23 [PATCH v1 0/1] Introduction of HP-BIOSCFG driver Jorge Lopez
2022-10-10 16:23 ` [PATCH v1 1/1] " Jorge Lopez
2022-10-10 16:57   ` Limonciello, Mario
2022-10-10 21:26     ` Jorge Lopez
2022-10-10 21:31       ` Limonciello, Mario
2022-10-11 14:53         ` Jorge Lopez
2022-10-17 13:18         ` Jorge Lopez
2022-10-17 14:11           ` Jorge Lopez
2022-10-17 14:29             ` Limonciello, Mario [this message]
2022-10-17 14:36               ` Hans de Goede
2022-10-17 15:20                 ` Jorge Lopez
2022-10-17 15:37                   ` Hans de Goede
2022-10-17 16:03                     ` Limonciello, Mario

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=dbffc3c3-9fbf-8d7d-99a9-29d44671e7f2@amd.com \
    --to=mario.limonciello@amd.com \
    --cc=hdegoede@redhat.com \
    --cc=jorgealtxwork@gmail.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