Re: [PATCH v3] x86/platform/uv: refactor deprecated strcpy and strncpy

[Hans de Goede]

Hi,

On 9/6/23 16:09, Ingo Molnar wrote:
> 
> * Hans de Goede  wrote:
> 
>> Hi Ingo,
>>
>> On 9/6/23 14:10, Ingo Molnar wrote:
>>>
>>> * Justin Stitt  wrote:
>>>
>>>> Both `strncpy` and `strcpy` are deprecated for use on NUL-terminated
>>>> destination strings [1].
>>>>
>>>> We can see that `arg` and `uv_nmi_action` are expected to be
>>>> NUL-terminated strings due to their use within `strcmp()` and format
>>>> strings respectively.
>>>>
>>>> With this in mind, a suitable replacement is `strscpy` [2] due to the
>>>> fact that it guarantees NUL-termination on its destination buffer
>>>> argument which is _not_ the case for `strncpy` or `strcpy`!
>>>>
>>>> In this case, we can drop both the forced NUL-termination and the `... -1` 
>>>> from:
>>>> |   strncpy(arg, val, ACTION_LEN - 1);
>>>> as `strscpy` implicitly has this behavior.
>>>>
>>>> Link: 
>>>> www.kernel.org/doc/html/latest/process/deprecated.html#strncpy-on-nul-terminated-strings[1]
>>>> Link: 
>>>> https://manpages.debian.org/testing/linux-manual-4.8/strscpy.9.en.html [2]
>>>> Link: https://github.com/KSPP/linux/issues/90
>>>> Cc: linux-harden...@vger.kernel.org
>>>> Signed-off-by: Justin Stitt 
>>>
>>>>  arch/x86/platform/uv/uv_nmi.c | 7 +++
>>>>  1 file changed, 3 insertions(+), 4 deletions(-)
>>>
>>> Note that this commit is already upstream:
>>>
>>>   1e6f01f72855 ("x86/platform/uv: Refactor code using deprecated 
>>> strcpy()/strncpy() interfaces to use strscpy()")
>>>
>>> Below is the delta your v3 patch has compared to what is upstream - is it 
>>> really necessary to open code it, instead of using strnchrnul() as your 
>>> original patch did? Am I missing anything here?
>>
>> The new version is a result of a review from my because IMHO:
>>
>>  strscpy(arg, val, strnchrnul(val, sizeof(arg)-1, '\n') - val + 1);
>>
>> Is really unreadable / really hard to reason about if
>> this is actually correct and does not contain any
>> of by 1 bugs.
>>
>> Note that the diff of v3 compared to the code before v2 landed is
>> actually smaller now and actually matches the subject of:
>> "refactor deprecated strcpy and strncpy"
>>
>> Where as v2 actually touches more code / refactor things
>> which fall outside of a "one change per patch" approach.
>> The:
>>
>>  p = strchr(arg, '\n');
>>  if (p)
>>  *p = '\0';
>>
>> was already there before v2 landed.
>>
>> I also suggested to do a follow up patch to change things to:
>>
>>  strscpy(arg, val, sizeof(arg));
>>  p = strchrnul(arg, '\n');
>>  *p = '\0';
>>
>> Which IMHO is much more readable then what has landed
>> now. But since v2 has already landed I guess the best
>> thing is just to stick with what we have upstream now...
> 
> Well, how about we do a delta patch with all the changes
> you suggested? I'm all for readability.

So I started doing this and notices that all the string
manipulation + parsing done here is really just a DYI
implementation of sysfs_match_string().

So I have prepared a patch to switch to sysfs_match_string(),
which completely removes the need to make a copy of the val
string.

I'll submit the patch right after this email.

Regards,

Hans

Re: [PATCH] platform/surface: aggregator: fix a bit test

[Hans de Goede]

Hi,

On 4/20/21 10:44 AM, Dan Carpenter wrote:
> The "funcs" variable is a u64.  If "func" is more than 31 then the
> BIT() shift will wrap instead of testing the high bits.
> 
> Fixes: c167b9c7e3d6 ("platform/surface: Add Surface Aggregator subsystem")
> Reported-by: kernel test robot 
> Signed-off-by: Dan Carpenter 

Thank you for your patch, I've applied this patch to my review-hans 
branch:
https://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86.git/log/?h=review-hans

Note it will show up in my review-hans branch once I've pushed my
local branch there, which might take a while.

Once I've run some tests on this branch the patches there will be
added to the platform-drivers-x86/for-next branch and eventually
will be included in the pdx86 pull-request to Linus for the next
merge-window.

Regards,

Hans


> ---
>  drivers/platform/surface/aggregator/controller.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/platform/surface/aggregator/controller.c 
> b/drivers/platform/surface/aggregator/controller.c
> index 00e38284885a..69e86cd599d3 100644
> --- a/drivers/platform/surface/aggregator/controller.c
> +++ b/drivers/platform/surface/aggregator/controller.c
> @@ -1040,7 +1040,7 @@ static int ssam_dsm_load_u32(acpi_handle handle, u64 
> funcs, u64 func, u32 *ret)
>   union acpi_object *obj;
>   u64 val;
>  
> - if (!(funcs & BIT(func)))
> + if (!(funcs & BIT_ULL(func)))
>   return 0; /* Not supported, leave *ret at its default value */
>  
>   obj = acpi_evaluate_dsm_typed(handle, _SSH_DSM_GUID,
> 

Re: [PATCH][next] platform/x86: intel_pmc_core: fix unsigned variable compared to less than zero

[Hans de Goede]

Hi Colin,

On 4/20/21 2:10 PM, Colin King wrote:
> From: Colin Ian King 
> 
> The check for ret < 0 is always false because ret is a (unsigned) size_t
> and not a (signed) ssize_t, hence simple_write_to_buffer failures are
> never detected. Fix this by making ret a ssize_t
> 
> Addresses-Coverity: ("Unsigned compared against 0")
> Fixes: 8074a79fad2e ("platform/x86: intel_pmc_core: Add option to set/clear 
> LPM mode")
> Signed-off-by: Colin Ian King 

Thank you for the patch, but I already send out the same patch myself
yesterday, so this is a duplicate.

Regards,

Hans



> ---
>  drivers/platform/x86/intel_pmc_core.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/platform/x86/intel_pmc_core.c 
> b/drivers/platform/x86/intel_pmc_core.c
> index 3ae00ac85c75..d174aeb492e0 100644
> --- a/drivers/platform/x86/intel_pmc_core.c
> +++ b/drivers/platform/x86/intel_pmc_core.c
> @@ -1360,7 +1360,7 @@ static ssize_t pmc_core_lpm_latch_mode_write(struct 
> file *file,
>   struct pmc_dev *pmcdev = s->private;
>   bool clear = false, c10 = false;
>   unsigned char buf[8];
> - size_t ret;
> + ssize_t ret;
>   int idx, m, mode;
>   u32 reg;
>  
> 

Re: [PATCH V2 0/9] intel_pmc_core: Add sub-state requirements and mode

[Hans de Goede]

Hi,

On 4/17/21 5:12 AM, David E. Box wrote:
> - Patch 1 and 2 remove the use of the global struct pmc_dev
> - Patches 3-7 add support for reading low power mode sub-state
>   requirements, latching sub-state status on different low power mode
>   events, and displaying the sub-state residency in microseconds
> - Patch 8 adds missing LTR IPs for TGL
> - Patch 9 adds support for ADL-P which is based on TGL
> 
> Applied on top of latest hans-review/review-hans

Thank you for your patch-series, I've applied the series to my
review-hans branch:
https://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86.git/log/?h=review-hans

Note it will show up in my review-hans branch once I've pushed my
local branch there, which might take a while.

Once I've run some tests on this branch the patches there will be
added to the platform-drivers-x86/for-next branch and eventually
will be included in the pdx86 pull-request to Linus for the next
merge-window.

Regards,

Hans



> Patches that changed in V2:
>   Patch 3: Variable name change
>   Patch 5: Do proper cleanup after fail
>   Patch 7: Debugfs write function fixes
> 
> David E. Box (4):
>   platform/x86: intel_pmc_core: Don't use global pmcdev in quirks
>   platform/x86: intel_pmc_core: Remove global struct pmc_dev
>   platform/x86: intel_pmc_core: Add option to set/clear LPM mode
>   platform/x86: intel_pmc_core: Add support for Alder Lake PCH-P
> 
> Gayatri Kammela (5):
>   platform/x86: intel_pmc_core: Handle sub-states generically
>   platform/x86: intel_pmc_core: Show LPM residency in microseconds
>   platform/x86: intel_pmc_core: Get LPM requirements for Tiger Lake
>   platform/x86: intel_pmc_core: Add requirements file to debugfs
>   platform/x86: intel_pmc_core: Add LTR registers for Tiger Lake
> 
>  drivers/platform/x86/intel_pmc_core.c | 384 +++---
>  drivers/platform/x86/intel_pmc_core.h |  47 +++-
>  2 files changed, 395 insertions(+), 36 deletions(-)
> 
> 
> base-commit: 823b31517ad3196324322804ee365d5fcff704d6
> 

Re: [PATCH 0/2] Remove GA14/15 quirks to acpi/video_detect

[Hans de Goede]

Hi,

On 4/19/21 10:02 AM, Luke Jones wrote:
> NP Hans, sorry about the length of time this took. Other duties etc.
> 
> I appreciated the wealth of insight you were able to provide to enable this.

BTW, I see that your drivers/acpi/video_detect.c patch is marked as [PATCH 1/3] 
I
guess these 2 patches are patch 2/3 and 3/3 ?  You may want to send a reply to
your own patch to make that clear and to explain that it is a standalone
patch.

Please Cc my on the reply.

Regards,

Hans

Re: [PATCH 0/2] Remove GA14/15 quirks to acpi/video_detect

[Hans de Goede]

Hi Luke,

On 4/19/21 9:49 AM, Luke D. Jones wrote:
> Revert two commits to allow a patch to acpi/video_detect to correctly
> set the backlight control as native.

Thank you for following up on our previous discussion about this.

I'll merge this as soon as Rafael has accepted to matching
drivers/acpi/video_detect.c patch.

Regards,

Hans


> Luke D. Jones (2):
>   Revert "platform/x86: asus-nb-wmi: Drop duplicate DMI quirk
> structures"
>   Revert "platform/x86: asus-nb-wmi: add support for ASUS ROG Zephyrus
> G14 and G15"
> 
>  drivers/platform/x86/asus-nb-wmi.c | 77 --
>  1 file changed, 77 deletions(-)
> 
> --
> 2.31.1
> 

Re: [PATCH V2 0/9] intel_pmc_core: Add sub-state requirements and mode

[Hans de Goede]

Hi,

On 4/17/21 5:12 AM, David E. Box wrote:
> - Patch 1 and 2 remove the use of the global struct pmc_dev
> - Patches 3-7 add support for reading low power mode sub-state
>   requirements, latching sub-state status on different low power mode
>   events, and displaying the sub-state residency in microseconds
> - Patch 8 adds missing LTR IPs for TGL
> - Patch 9 adds support for ADL-P which is based on TGL
> 
> Applied on top of latest hans-review/review-hans

Thank you, the series looks good to me know, except for one very minor
issue in patch 5, which as I already mentioned in a reply to patch 5,
I can fixup while merging this.

Once I have you ack for the prososed changes to patch 5 I'll merge this
into me review-hans branch.

Depending on if Linus does a rc8 or not I'll then push this to for-next
for 5.13, or this will have to wait for 5.14 :

Linus does a rc8  -> I'll promote this from review-hans to for-next in 
time for 5.13
Linus releases 5.12 final -> I'll rebase my review-hans on top of 5.13-rc1 once 
released and
 then push this to for-next

Regards,

Hans




> 
> Patches that changed in V2:
>   Patch 3: Variable name change
>   Patch 5: Do proper cleanup after fail
>   Patch 7: Debugfs write function fixes
> 
> David E. Box (4):
>   platform/x86: intel_pmc_core: Don't use global pmcdev in quirks
>   platform/x86: intel_pmc_core: Remove global struct pmc_dev
>   platform/x86: intel_pmc_core: Add option to set/clear LPM mode
>   platform/x86: intel_pmc_core: Add support for Alder Lake PCH-P
> 
> Gayatri Kammela (5):
>   platform/x86: intel_pmc_core: Handle sub-states generically
>   platform/x86: intel_pmc_core: Show LPM residency in microseconds
>   platform/x86: intel_pmc_core: Get LPM requirements for Tiger Lake
>   platform/x86: intel_pmc_core: Add requirements file to debugfs
>   platform/x86: intel_pmc_core: Add LTR registers for Tiger Lake
> 
>  drivers/platform/x86/intel_pmc_core.c | 384 +++---
>  drivers/platform/x86/intel_pmc_core.h |  47 +++-
>  2 files changed, 395 insertions(+), 36 deletions(-)
> 
> 
> base-commit: 823b31517ad3196324322804ee365d5fcff704d6
> 

Re: [PATCH V2 5/9] platform/x86: intel_pmc_core: Get LPM requirements for Tiger Lake

[Hans de Goede]

Hi,

On 4/17/21 5:12 AM, David E. Box wrote:
> From: Gayatri Kammela 
> 
> Platforms that support low power modes (LPM) such as Tiger Lake maintain
> requirements for each sub-state that a readable in the PMC. However, unlike
> LPM status registers, requirement registers are not memory mapped but are
> available from an ACPI _DSM. Collect the requirements for Tiger Lake using
> the _DSM method and store in a buffer.
> 
> Signed-off-by: Gayatri Kammela 
> Co-developed-by: David E. Box 
> Signed-off-by: David E. Box 
> Reviewed-by: Hans de Goede 
> ---
> 
> V2:   - Move buffer allocation so that it does not need to be freed
> (which was missing anyway) when an error is encountered.
>   - Use label to free out_obj after errors
>   - Use memcpy instead of memcpy_fromio for ACPI memory
> 
>  drivers/platform/x86/intel_pmc_core.c | 56 +++
>  drivers/platform/x86/intel_pmc_core.h |  2 +
>  2 files changed, 58 insertions(+)
> 
> diff --git a/drivers/platform/x86/intel_pmc_core.c 
> b/drivers/platform/x86/intel_pmc_core.c
> index 0e59a84b51bf..97efe9a6bd01 100644
> --- a/drivers/platform/x86/intel_pmc_core.c
> +++ b/drivers/platform/x86/intel_pmc_core.c
> @@ -23,7 +23,9 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -31,6 +33,9 @@
>  
>  #include "intel_pmc_core.h"
>  
> +#define ACPI_S0IX_DSM_UUID   "57a6512e-3979-4e9d-9708-ff13b2508972"
> +#define ACPI_GET_LOW_MODE_REGISTERS  1
> +
>  /* PKGC MSRs are common across Intel Core SoCs */
>  static const struct pmc_bit_map msr_map[] = {
>   {"Package C2",  MSR_PKG_C2_RESIDENCY},
> @@ -590,6 +595,53 @@ static const struct pmc_reg_map tgl_reg_map = {
>   .etr3_offset = ETR3_OFFSET,
>  };
>  
> +static void pmc_core_get_tgl_lpm_reqs(struct platform_device *pdev)
> +{
> + struct pmc_dev *pmcdev = platform_get_drvdata(pdev);
> + const int num_maps = pmcdev->map->lpm_num_maps;
> + size_t lpm_size = LPM_MAX_NUM_MODES * num_maps * 4;

The type of lpm_size should be an u32, so that it matches
the type of out_obj->buffer.length.

> + union acpi_object *out_obj;
> + struct acpi_device *adev;
> + guid_t s0ix_dsm_guid;
> + u32 *lpm_req_regs, *addr;
> +
> + adev = ACPI_COMPANION(>dev);
> + if (!adev)
> + return;
> +
> + guid_parse(ACPI_S0IX_DSM_UUID, _dsm_guid);
> +
> + out_obj = acpi_evaluate_dsm(adev->handle, _dsm_guid, 0,
> + ACPI_GET_LOW_MODE_REGISTERS, NULL);
> + if (out_obj && out_obj->type == ACPI_TYPE_BUFFER) {
> + int size = out_obj->buffer.length;

out_obj->buffer.length is an u32, please make this an u32 too.

> +
> + if (size != lpm_size) {
> + acpi_handle_debug(adev->handle,
> + "_DSM returned unexpected buffer size,"
> + " have %d, expect %ld\n", size, lpm_size);

And use %u here (twice), this should also fix the warnings reported
by the kernel test robot.

If there are no objections against the suggested changes, then I can
fix this up while merging this.

Please let me know if the suggested changes are ok with you.

Regards,

Hans


> + goto free_acpi_obj;
> + }
> + } else {
> + acpi_handle_debug(adev->handle,
> +   "_DSM function 0 evaluation failed\n");
> + goto free_acpi_obj;
> + }
> +
> + addr = (u32 *)out_obj->buffer.pointer;
> +
> + lpm_req_regs = devm_kzalloc(>dev, lpm_size * sizeof(u32),
> +  GFP_KERNEL);
> + if (!lpm_req_regs)
> + goto free_acpi_obj;
> +
> + memcpy(lpm_req_regs, addr, lpm_size);
> + pmcdev->lpm_req_regs = lpm_req_regs;
> +
> +free_acpi_obj:
> + ACPI_FREE(out_obj);
> +}
> +
>  static inline u32 pmc_core_reg_read(struct pmc_dev *pmcdev, int reg_offset)
>  {
>   return readl(pmcdev->regbase + reg_offset);
> @@ -1424,10 +1476,14 @@ static int pmc_core_probe(struct platform_device 
> *pdev)
>   return -ENOMEM;
>  
>   mutex_init(>lock);
> +
>   pmcdev->pmc_xram_read_bit = pmc_core_check_read_lock_bit(pmcdev);
>   pmc_core_get_low_power_modes(pmcdev);
>   pmc_core_do_dmi_quirks(pmcdev);
>  
> + if (pmcdev->map == _reg_map)
> + pmc_core_get_tgl_lpm_reqs(pdev);
> +
>   /*
>* On TGL, due to a hardware limitation, the GBE LTR blocks PC1

Re: [PATCH V2 5/9] platform/x86: intel_pmc_core: Get LPM requirements for Tiger Lake

[Hans de Goede]

Hi David,

On 4/17/21 5:12 AM, David E. Box wrote:
> From: Gayatri Kammela 
> 
> Platforms that support low power modes (LPM) such as Tiger Lake maintain
> requirements for each sub-state that a readable in the PMC. However, unlike
> LPM status registers, requirement registers are not memory mapped but are
> available from an ACPI _DSM. Collect the requirements for Tiger Lake using
> the _DSM method and store in a buffer.
> 
> Signed-off-by: Gayatri Kammela 
> Co-developed-by: David E. Box 
> Signed-off-by: David E. Box 
> Reviewed-by: Hans de Goede 

Erm, I did not give my "Reviewed-by: Hans de Goede "
for this patch, because it still needed some work.

Next time please only add my Reviewed-by to patches where I
explicitly replied with a Reviewed-by.

The same goes for patch 7/9

Regards,

Hans



> ---
> 
> V2:   - Move buffer allocation so that it does not need to be freed
> (which was missing anyway) when an error is encountered.
>   - Use label to free out_obj after errors
>   - Use memcpy instead of memcpy_fromio for ACPI memory
> 
>  drivers/platform/x86/intel_pmc_core.c | 56 +++
>  drivers/platform/x86/intel_pmc_core.h |  2 +
>  2 files changed, 58 insertions(+)
> 
> diff --git a/drivers/platform/x86/intel_pmc_core.c 
> b/drivers/platform/x86/intel_pmc_core.c
> index 0e59a84b51bf..97efe9a6bd01 100644
> --- a/drivers/platform/x86/intel_pmc_core.c
> +++ b/drivers/platform/x86/intel_pmc_core.c
> @@ -23,7 +23,9 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -31,6 +33,9 @@
>  
>  #include "intel_pmc_core.h"
>  
> +#define ACPI_S0IX_DSM_UUID   "57a6512e-3979-4e9d-9708-ff13b2508972"
> +#define ACPI_GET_LOW_MODE_REGISTERS  1
> +
>  /* PKGC MSRs are common across Intel Core SoCs */
>  static const struct pmc_bit_map msr_map[] = {
>   {"Package C2",  MSR_PKG_C2_RESIDENCY},
> @@ -590,6 +595,53 @@ static const struct pmc_reg_map tgl_reg_map = {
>   .etr3_offset = ETR3_OFFSET,
>  };
>  
> +static void pmc_core_get_tgl_lpm_reqs(struct platform_device *pdev)
> +{
> + struct pmc_dev *pmcdev = platform_get_drvdata(pdev);
> + const int num_maps = pmcdev->map->lpm_num_maps;
> + size_t lpm_size = LPM_MAX_NUM_MODES * num_maps * 4;
> + union acpi_object *out_obj;
> + struct acpi_device *adev;
> + guid_t s0ix_dsm_guid;
> + u32 *lpm_req_regs, *addr;
> +
> + adev = ACPI_COMPANION(>dev);
> + if (!adev)
> + return;
> +
> + guid_parse(ACPI_S0IX_DSM_UUID, _dsm_guid);
> +
> + out_obj = acpi_evaluate_dsm(adev->handle, _dsm_guid, 0,
> + ACPI_GET_LOW_MODE_REGISTERS, NULL);
> + if (out_obj && out_obj->type == ACPI_TYPE_BUFFER) {
> + int size = out_obj->buffer.length;
> +
> + if (size != lpm_size) {
> + acpi_handle_debug(adev->handle,
> + "_DSM returned unexpected buffer size,"
> + " have %d, expect %ld\n", size, lpm_size);
> + goto free_acpi_obj;
> + }
> + } else {
> + acpi_handle_debug(adev->handle,
> +   "_DSM function 0 evaluation failed\n");
> + goto free_acpi_obj;
> + }
> +
> + addr = (u32 *)out_obj->buffer.pointer;
> +
> + lpm_req_regs = devm_kzalloc(>dev, lpm_size * sizeof(u32),
> +  GFP_KERNEL);
> + if (!lpm_req_regs)
> + goto free_acpi_obj;
> +
> + memcpy(lpm_req_regs, addr, lpm_size);
> + pmcdev->lpm_req_regs = lpm_req_regs;
> +
> +free_acpi_obj:
> + ACPI_FREE(out_obj);
> +}
> +
>  static inline u32 pmc_core_reg_read(struct pmc_dev *pmcdev, int reg_offset)
>  {
>   return readl(pmcdev->regbase + reg_offset);
> @@ -1424,10 +1476,14 @@ static int pmc_core_probe(struct platform_device 
> *pdev)
>   return -ENOMEM;
>  
>   mutex_init(>lock);
> +
>   pmcdev->pmc_xram_read_bit = pmc_core_check_read_lock_bit(pmcdev);
>   pmc_core_get_low_power_modes(pmcdev);
>   pmc_core_do_dmi_quirks(pmcdev);
>  
> + if (pmcdev->map == _reg_map)
> + pmc_core_get_tgl_lpm_reqs(pdev);
> +
>   /*
>* On TGL, due to a hardware limitation, the GBE LTR blocks PC10 when
>* a cable is attached. Tell the PMC to ignore it.
> diff --git a/drivers/platform/x86/intel_pmc_core.h 
> b/drivers/platform/x86/intel_pmc_core.h
>

Re: [PATCH] platform/x86: intel_chtdc_ti_pwrbtn: Fix missing IRQF_ONESHOT as only threaded handler

[Hans de Goede]

Hi,

On 4/15/21 11:14 AM, zhuguangqin...@gmail.com wrote:
> From: Guangqing Zhu 
> 
> Coccinelle noticed:
>   drivers/platform/x86/intel_chtdc_ti_pwrbtn.c:59:7-32: ERROR: Threaded IRQ
> with no primary handler requested without IRQF_ONESHOT
> 
> Signed-off-by: Guangqing Zhu 

So I was wondering why this driver worked at all despite the missing flag.

The reason that this still works is that the irqchip instantiated by
the MFD driver for the CHT TI PMIC is using nested IRQ handling and
then the request_irq error for this does not trigger.

This is still the right thing to do though.

I've tested that the driver still works after this.

Thank you for your patch, I've applied this patch to my review-hans 
branch:
https://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86.git/log/?h=review-hans

Note it will show up in my review-hans branch once I've pushed my
local branch there, which might take a while.

Once I've run some tests on this branch the patches there will be
added to the platform-drivers-x86/for-next branch and eventually
will be included in the pdx86 pull-request to Linus for the next
merge-window.

Regards,

Hans



> ---
>  drivers/platform/x86/intel_chtdc_ti_pwrbtn.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/platform/x86/intel_chtdc_ti_pwrbtn.c 
> b/drivers/platform/x86/intel_chtdc_ti_pwrbtn.c
> index 0df2e82dd249..9606a994af22 100644
> --- a/drivers/platform/x86/intel_chtdc_ti_pwrbtn.c
> +++ b/drivers/platform/x86/intel_chtdc_ti_pwrbtn.c
> @@ -58,7 +58,7 @@ static int chtdc_ti_pwrbtn_probe(struct platform_device 
> *pdev)
>  
>   err = devm_request_threaded_irq(dev, irq, NULL,
>   chtdc_ti_pwrbtn_interrupt,
> - 0, KBUILD_MODNAME, input);
> + IRQF_ONESHOT, KBUILD_MODNAME, input);
>   if (err)
>   return err;
>  
> 

Re: linux-next: Signed-off-by missing for commit in the drivers-x86 tree

[Hans de Goede]

Hi,

On 4/14/21 3:51 PM, Stephen Rothwell wrote:
> Hi all,
> 
> Commit
> 
>   ff57cfaa3d68 ("platform/x86: pmc_atom: Match all Beckhoff Automation 
> baytrail boards with critclk_systems DMI table")
> 
> is missing a Signed-off-by from its committer.

My bad I somehow forgot to pass -s to "git am", this is fixed now.

Regards,

Hans

Re: [PATCH v7 1/2] platform/x86: dell-privacy: Add support for Dell hardware privacy

[Hans de Goede]

Hi,

On 4/12/21 11:19 AM, Perry Yuan wrote:
> From: Perry Yuan 
> 
> add support for Dell privacy driver for the Dell units equipped
> hardware privacy design, which protect users privacy of audio and
> camera from hardware level. Once the audio or camera privacy mode
> activated, any applications will not get any audio or video stream
> when user pressed ctrl+F4 hotkey, audio privacy mode will be
> enabled, micmute led will be also changed accordingly
> The micmute led is fully controlled by hardware & EC(embedded controller)
> and camera mute hotkey is Ctrl+F9. Currently design only emits
> SW_CAMERA_LENS_COVER event while the camera lens shutter will be
> changed by EC & HW(hardware) control
> 
> *The flow is like this:
> 1) User presses key. HW does stuff with this key (timeout timer is started)
> 2) WMI event is emitted from BIOS to kernel
> 3) WMI event is received by dell-privacy
> 4) KEY_MICMUTE emitted from dell-privacy
> 5) Userland picks up key and modifies kcontrol for SW mute
> 6) Codec kernel driver catches and calls ledtrig_audio_set, like this:
>ledtrig_audio_set(LED_AUDIO_MICMUTE, rt715->micmute_led ? LED_ON :LED_OFF);
> 7) If "LED" is set to on dell-privacy notifies EC, and timeout is cancelled,
>HW mic mute activated. If EC not notified, HW mic mute will also be
>activated when timeout used up, it is just later than active ack
> 
> Signed-off-by: Perry Yuan 
> ---
> v5 -> v6:
> * addressed feedback from Hans
> * addressed feedback from Pierre
> * optimize some debug format with dev_dbg()
> * remove platform driver,combined privacy acpi driver into single wmi
>   driver file
> * optimize sysfs interface with string added to be more clearly reading
> * remove unused function and clear header file

Thank you, almost there. A few small remarks inline.

> v4 -> v5:
> * addressed feedback from Randy Dunlap
> * addressed feedback from Pierre-Louis Bossart
> * rebase to latest 5.12 rc4 upstream kernel
> * fix some space alignment problem
> v3 -> v4:
> * fix format for Kconfig
> * add sysfs document
> * add flow comments to the privacy wmi/acpi driver
> * addressed feedback from Barnabás Pőcze[Thanks very much]
> * export privacy_valid to make the global state simpler to query
> * fix one issue which will block the dell-laptop driver to load when
>   privacy driver invalid
> * addressed feedback from Pierre-Louis Bossart,remove the EC ID match
> v2 -> v3:
> * add sysfs attributes doc
> v1 -> v2:
> * query EC handle from EC driver directly.
> * fix some code style.
> * add KEY_END to keymap array.
> * clean platform device when cleanup called
> * use hexadecimal format for log print in dev_dbg
> * remove __set_bit for the report keys from probe.
> * fix keymap leak
> * add err_free_keymap in dell_privacy_wmi_probe
> * wmi driver will be unregistered if privacy_acpi_init() fails
> * add sysfs attribute files for user space query.
> * add leds micmute driver to privacy acpi
> * add more design info the commit info
> ---
> ---
>  .../testing/sysfs-platform-dell-privacy-wmi   |  55 +++
>  drivers/platform/x86/dell/Kconfig |  14 +
>  drivers/platform/x86/dell/Makefile|   1 +
>  drivers/platform/x86/dell/dell-laptop.c   |  23 +-
>  drivers/platform/x86/dell/dell-privacy-wmi.c  | 394 ++
>  drivers/platform/x86/dell/dell-privacy-wmi.h  |  23 +
>  drivers/platform/x86/dell/dell-wmi.c  |   8 +-
>  7 files changed, 511 insertions(+), 7 deletions(-)
>  create mode 100644 Documentation/ABI/testing/sysfs-platform-dell-privacy-wmi
>  create mode 100644 drivers/platform/x86/dell/dell-privacy-wmi.c
>  create mode 100644 drivers/platform/x86/dell/dell-privacy-wmi.h
> 
> diff --git a/Documentation/ABI/testing/sysfs-platform-dell-privacy-wmi 
> b/Documentation/ABI/testing/sysfs-platform-dell-privacy-wmi
> new file mode 100644
> index ..7f9e18705861
> --- /dev/null
> +++ b/Documentation/ABI/testing/sysfs-platform-dell-privacy-wmi
> @@ -0,0 +1,55 @@
> +What:
> /sys/bus/wmi/devices/6932965F-1671-4CEB-B988-D3AB0A901919/dell_privacy_supported_type
> +Date:Apr 2021
> +KernelVersion:   5.13
> +Contact: "perry.y...@dell.com>"
> +Description:
> + Display which dell hardware level privacy devices are supported
> + “Dell Privacy” is a set of HW, FW, and SW features to enhance
> + Dell’s commitment to platform privacy for MIC, Camera, and
> + ePrivacy screens.
> + The supported hardware privacy devices are:
> +Attributes:
> + Microphone Mute:
> + Identifies the local microphone can be muted by 
> hardware, no applications
> + is available to capture system mic sound
> +
> + Camera Shutter:
> + Identifies camera shutter controlled by 
> hardware, which is a micromechanical
> + shutter assembly that is built onto the camera 

Re: [PATCH v2] platform/x86: pmc_atom: Match all Beckhoff Automation baytrail boards with critclk_systems DMI table

[Hans de Goede]

Hi,

On 4/12/21 3:30 PM, Steffen Dirkwinkel wrote:
> From: Steffen Dirkwinkel 
> 
> pmc_plt_clk* clocks are used for ethernet controllers, so need to stay
> turned on. This adds the affected board family to critclk_systems DMI
> table, so the clocks are marked as CLK_CRITICAL and not turned off.
> 
> This replaces the previously listed boards with a match for the whole
> device family CBxx63. CBxx63 matches only baytrail devices.
> There are new affected boards that would otherwise need to be listed.
> There are unaffected boards in the family, but having the clocks
> turned on is not an issue.
> 
> Fixes: 648e921888ad ("clk: x86: Stop marking clocks as CLK_IS_CRITICAL")
> Reviewed-by: Andy Shevchenko 
> Signed-off-by: Steffen Dirkwinkel 

Thank you for your patch, I've applied this patch to my review-hans 
branch:
https://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86.git/log/?h=review-hans

Note it will show up in my review-hans branch once I've pushed my
local branch there, which might take a while.

Once I've run some tests on this branch the patches there will be
added to the platform-drivers-x86/for-next branch and eventually
will be included in the pdx86 pull-request to Linus for the next
merge-window.

Regards,

Hans




> ---
>  drivers/platform/x86/pmc_atom.c | 28 ++--
>  1 file changed, 2 insertions(+), 26 deletions(-)
> 
> diff --git a/drivers/platform/x86/pmc_atom.c b/drivers/platform/x86/pmc_atom.c
> index ca684ed760d1..a9d2a4b98e57 100644
> --- a/drivers/platform/x86/pmc_atom.c
> +++ b/drivers/platform/x86/pmc_atom.c
> @@ -393,34 +393,10 @@ static const struct dmi_system_id critclk_systems[] = {
>   },
>   {
>   /* pmc_plt_clk* - are used for ethernet controllers */
> - .ident = "Beckhoff CB3163",
> + .ident = "Beckhoff Baytrail",
>   .matches = {
>   DMI_MATCH(DMI_SYS_VENDOR, "Beckhoff Automation"),
> - DMI_MATCH(DMI_BOARD_NAME, "CB3163"),
> - },
> - },
> - {
> - /* pmc_plt_clk* - are used for ethernet controllers */
> - .ident = "Beckhoff CB4063",
> - .matches = {
> - DMI_MATCH(DMI_SYS_VENDOR, "Beckhoff Automation"),
> - DMI_MATCH(DMI_BOARD_NAME, "CB4063"),
> - },
> - },
> - {
> - /* pmc_plt_clk* - are used for ethernet controllers */
> - .ident = "Beckhoff CB6263",
> - .matches = {
> - DMI_MATCH(DMI_SYS_VENDOR, "Beckhoff Automation"),
> - DMI_MATCH(DMI_BOARD_NAME, "CB6263"),
> - },
> - },
> - {
> - /* pmc_plt_clk* - are used for ethernet controllers */
> - .ident = "Beckhoff CB6363",
> - .matches = {
> - DMI_MATCH(DMI_SYS_VENDOR, "Beckhoff Automation"),
> - DMI_MATCH(DMI_BOARD_NAME, "CB6363"),
> + DMI_MATCH(DMI_PRODUCT_FAMILY, "CBxx63"),
>   },
>   },
>   {
> 

Re: [PATCH v5] platform/x86: add Gigabyte WMI temperature driver

[Hans de Goede]

Hi,

On 4/12/21 2:35 PM, Thomas Weißschuh wrote:
> Tested with
> * X570 I Aorus Pro Wifi (rev 1.0)
> * B550M DS3H
> * B550 Gaming X V2 (rev.1.x)
> * Z390 I AORUS PRO WIFI (rev. 1.0)
> 
> Those mainboards contain an ITE chips for management and
> monitoring.
> 
> They could also be handled by drivers/hwmon/i87.c.
> But the SuperIO range used by i87 is already claimed and used by the
> firmware.
> 
> The following warning is printed at boot:
> 
> kernel: ACPI Warning: SystemIO range 0x0A45-0x0A46 
> conflicts with OpRegion 0x0A45-0x0A46 (\GSA1.SIO1) 
> (20200528/utaddress-204)
> kernel: ACPI: This conflict may cause random problems and system instability
> kernel: ACPI: If an ACPI driver is available for this device, you should use 
> it instead of the native driver
> 
> This driver implements such an ACPI driver.

Thank you for your patch, I've applied this patch to my review-hans 
branch:
https://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86.git/log/?h=review-hans

Note it will show up in my review-hans branch once I've pushed my
local branch there, which might take a while.

Once I've run some tests on this branch the patches there will be
added to the platform-drivers-x86/for-next branch and eventually
will be included in the pdx86 pull-request to Linus for the next
merge-window.

Regards,

Hans






> 
> Unfortunately not all sensor registers are handled by the firmware and even
> less are exposed via WMI.
> 
> Signed-off-by: Thomas Weißschuh 
> Reviewed-by: Guenter Roeck 
> 
> ---
> 
> Changes since v4:
> * Style
> * Wording
> * Alignment of email addresses
> ---
>  MAINTAINERS |   6 +
>  drivers/platform/x86/Kconfig|  11 ++
>  drivers/platform/x86/Makefile   |   1 +
>  drivers/platform/x86/gigabyte-wmi.c | 195 
>  4 files changed, 213 insertions(+)
>  create mode 100644 drivers/platform/x86/gigabyte-wmi.c
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index d92f85ca831d..7fb5e2ba489b 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -7543,6 +7543,12 @@ F: Documentation/filesystems/gfs2*
>  F:   fs/gfs2/
>  F:   include/uapi/linux/gfs2_ondisk.h
>  
> +GIGABYTE WMI DRIVER
> +M:   Thomas Weißschuh 
> +L:   platform-driver-...@vger.kernel.org
> +S:   Maintained
> +F:   drivers/platform/x86/gigabyte-wmi.c
> +
>  GNSS SUBSYSTEM
>  M:   Johan Hovold 
>  S:   Maintained
> diff --git a/drivers/platform/x86/Kconfig b/drivers/platform/x86/Kconfig
> index ad4e630e73e2..96622a2106f7 100644
> --- a/drivers/platform/x86/Kconfig
> +++ b/drivers/platform/x86/Kconfig
> @@ -123,6 +123,17 @@ config XIAOMI_WMI
> To compile this driver as a module, choose M here: the module will
> be called xiaomi-wmi.
>  
> +config GIGABYTE_WMI
> + tristate "Gigabyte WMI temperature driver"
> + depends on ACPI_WMI
> + depends on HWMON
> + help
> +   Say Y here if you want to support WMI-based temperature reporting on
> +   Gigabyte mainboards.
> +
> +   To compile this driver as a module, choose M here: the module will
> +   be called gigabyte-wmi.
> +
>  config ACERHDF
>   tristate "Acer Aspire One temperature and fan driver"
>   depends on ACPI && THERMAL
> diff --git a/drivers/platform/x86/Makefile b/drivers/platform/x86/Makefile
> index 60d554073749..1621ebfd04fd 100644
> --- a/drivers/platform/x86/Makefile
> +++ b/drivers/platform/x86/Makefile
> @@ -15,6 +15,7 @@ obj-$(CONFIG_INTEL_WMI_THUNDERBOLT) += 
> intel-wmi-thunderbolt.o
>  obj-$(CONFIG_MXM_WMI)+= mxm-wmi.o
>  obj-$(CONFIG_PEAQ_WMI)   += peaq-wmi.o
>  obj-$(CONFIG_XIAOMI_WMI) += xiaomi-wmi.o
> +obj-$(CONFIG_GIGABYTE_WMI)   += gigabyte-wmi.o
>  
>  # Acer
>  obj-$(CONFIG_ACERHDF)+= acerhdf.o
> diff --git a/drivers/platform/x86/gigabyte-wmi.c 
> b/drivers/platform/x86/gigabyte-wmi.c
> new file mode 100644
> index ..bb1b0b205fa7
> --- /dev/null
> +++ b/drivers/platform/x86/gigabyte-wmi.c
> @@ -0,0 +1,195 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later
> +/*
> + *  Copyright (C) 2021 Thomas Weißschuh 
> + */
> +#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define GIGABYTE_WMI_GUID"DEADBEEF-2001--00A0-C9062910"
> +#define NUM_TEMPERATURE_SENSORS  6
> +
> +static bool force_load;
> +module_param(force_load, bool, 0444);
> +MODULE_PARM_DESC(force_load, "Force loading on unknown platform");
> +
> +static u8 usable_sensors_mask;
> +
> +enum gigabyte_wmi_commandtype {
> + GIGABYTE_WMI_BUILD_DATE_QUERY   =   0x1,
> + GIGABYTE_WMI_MAINBOARD_TYPE_QUERY   =   0x2,
> + GIGABYTE_WMI_FIRMWARE_VERSION_QUERY =   0x4,
> + GIGABYTE_WMI_MAINBOARD_NAME_QUERY   =   0x5,
> + GIGABYTE_WMI_TEMPERATURE_QUERY  = 0x125,
> +};
> +
> +struct gigabyte_wmi_args {
> + u32 arg1;
> +};
> +
> +static int 

Re: [PATCH v6] platform/x86: intel_pmc_core: export platform global reset bits via etr3 sysfs file

[Hans de Goede]

Hi,

On 4/11/21 4:15 PM, Tomas Winkler wrote:
> From: Tamar Mashiah 
> 
> During PCH (platform/board) manufacturing process a global platform
> reset has to be induced in order for the configuration changes take
> the effect upon following platform reset. This is an internal platform
> state and is not intended to be used in the regular platform resets.
> The setting is exposed via ETR3 (Extended Test Mode Register 3).
> After the manufacturing process is completed the register cannot be
> written anymore and is hardware locked.
> This setting was commonly done by accessing PMC registers via /dev/mem
> but due to security concerns /dev/mem access is much more restricted,
> hence the reason for exposing this setting via the dedicated sysfs
> interface.
> To prevent post manufacturing abuse the register is protected
> by hardware locking and the file is set to read-only mode via is_visible
> handler.
> 
> The register in MMIO space is defined for Cannon Lake and newer PCHs.
> 
> Cc: Hans de Goede 
> Cc: David E Box 
> Reviewed-by: Andy Shevchenko 
> Signed-off-by: Tamar Mashiah 
> Signed-off-by: Tomas Winkler 

Thank you for your patch, I've applied this patch to my review-hans 
branch:
https://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86.git/log/?h=review-hans

Note it will show up in my review-hans branch once I've pushed my
local branch there, which might take a while.

Once I've run some tests on this branch the patches there will be
added to the platform-drivers-x86/for-next branch and eventually
will be included in the pdx86 pull-request to Linus for the next
merge-window.

Regards,

Hans




> ---
> V2:
> 1. Add locking for reading the ET3 register  (Andy)
> 2. Fix few style issues (Andy)
> V3:
> 1. Resend
> v4:
> 1. Fix return statement (Andy)
> 2. Specify manufacturing process (Enrico)
> V5:
> 1. Rename sysfs file to etr3 (Hans)
> 2. Make file read only when register is locked (Hans)
> 3. Add more info to sysfs ABI documentation
> V5:
> 1. Parentheses around arithmetic in operand of '|' [-Wparentheses] (lkp)
>656 |  return reg & ETR3_CF9LOCK ? attr->mode & SYSFS_PREALLOC | 0444 : 
> attr->mode
> 
>  .../ABI/testing/sysfs-platform-intel-pmc  |  20 
>  MAINTAINERS   |   1 +
>  drivers/platform/x86/intel_pmc_core.c | 113 ++
>  drivers/platform/x86/intel_pmc_core.h |   6 +
>  4 files changed, 140 insertions(+)
>  create mode 100644 Documentation/ABI/testing/sysfs-platform-intel-pmc
> 
> diff --git a/Documentation/ABI/testing/sysfs-platform-intel-pmc 
> b/Documentation/ABI/testing/sysfs-platform-intel-pmc
> new file mode 100644
> index ..ef199af75ab0
> --- /dev/null
> +++ b/Documentation/ABI/testing/sysfs-platform-intel-pmc
> @@ -0,0 +1,20 @@
> +What:/sys/devices/platform//etr3
> +Date:Apr 2021
> +KernelVersion:   5.13
> +Contact: "Tomas Winkler" 
> +Description:
> + The file exposes "Extended Test Mode Register 3" global
> + reset bits. The bits are used during an Intel platform
> + manufacturing process to indicate that consequent reset
> + of the platform is a "global reset". This type of reset
> + is required in order for manufacturing configurations
> + to take effect.
> +
> + Display global reset setting bits for PMC.
> + * bit 31 - global reset is locked
> + * bit 20 - global reset is set
> + Writing bit 20 value to the etr3 will induce
> + a platform "global reset" upon consequent platform reset,
> + in case the register is not locked.
> + The "global reset bit" should be locked on a production
> + system and the file is in read-only mode.
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 7dd6b67f0f51..3e898660b5b4 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -9145,6 +9145,7 @@ M:  Rajneesh Bhardwaj 
>  M:   David E Box 
>  L:   platform-driver-...@vger.kernel.org
>  S:   Maintained
> +F:   Documentation/ABI/testing/sysfs-platform-intel-pmc
>  F:   drivers/platform/x86/intel_pmc_core*
>  
>  INTEL PMIC GPIO DRIVERS
> diff --git a/drivers/platform/x86/intel_pmc_core.c 
> b/drivers/platform/x86/intel_pmc_core.c
> index b5888aeb4bcf..8fb4e6d1d68d 100644
> --- a/drivers/platform/x86/intel_pmc_core.c
> +++ b/drivers/platform/x86/intel_pmc_core.c
> @@ -401,6 +401,7 @@ static const struct pmc_reg_map cnp_reg_map = {
>   .pm_cfg_offset = CNP_PMC_PM_CFG_OFFSET,
>   .pm_read_disable_bit = CNP_PMC_READ_DISABL

Re: [PATCH v7 2/2] ASoC: rt715:add micmute led state control supports

[Hans de Goede]

Hi Perry,

On 4/12/21 11:19 AM, Perry Yuan wrote:
> From: Perry Yuan 
> 
> Some new Dell system is going to support audio internal micphone
> privacy setting from hardware level with micmute led state changing
> When micmute hotkey pressed by user, soft mute will need to be enabled
> firstly in case of pop noise, and codec driver need to react to mic
> mute event to EC(embedded controller) notifying that SW mute is completed
> Then EC will do the hardware mute physically within the timeout reached
> 
> This patch allow codec rt715 and rt715 sdca driver to change the local micmute
> led state. Dell privacy led trigger driver will ack EC when micmute key 
> pressed
> through this micphone led control interface like hda_generic provided
> ACPI method defined in dell-privacy micmute led trigger will be called
> for notifying the EC that software mute has been completed, then hardware
> audio circuit solution controlled by EC will switch the audio input source 
> off/on
> 
> Signed-off-by: Perry Yuan 

The ALSA kernel-patch-set which I mentioned in previous discussions, which
allows controlling this through sysfs has been merged upstream and is
currently in for-nex.t. So IMHO you should use the new sysfs mechanism
for this rather then adding quirks to individual codec drivers.

Regards,

Hans


> 
> 
> v5 -> v6:
> * addresed review comments from Jaroslav
> * add quirks for micmute led control as short term solution to control
>   micmute led state change
> * add comments for the invert checking
> v4 -> v5:
> * rebase to latest 5.12 rc4 upstream kernel
> v3 -> v4:
> * remove unused debug log
> * remove compile flag of DELL privacy
> * move the micmute_led to local from rt715_priv
> * when Jaroslav upstream his gerneric LED trigger driver,I will rebase
>   this patch,please consider merge this at first
>   https://lore.kernel.org/alsa-devel/2021021400.1131020-1-pe...@perex.cz/
> v2 -> v3:
> * simplify the patch to reuse some val value
> * add more detail to the commit info
> v1 -> v2:
> * fix some format issue
> 
> ---
>  sound/soc/codecs/rt715-sdca.c | 42 ++
>  sound/soc/codecs/rt715.c  | 43 +++
>  2 files changed, 85 insertions(+)
> 
> diff --git a/sound/soc/codecs/rt715-sdca.c b/sound/soc/codecs/rt715-sdca.c
> index 20528afbdc57..47dc31f7f3e3 100644
> --- a/sound/soc/codecs/rt715-sdca.c
> +++ b/sound/soc/codecs/rt715-sdca.c
> @@ -11,12 +11,14 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -344,6 +346,32 @@ static int rt715_sdca_get_volsw(struct snd_kcontrol 
> *kcontrol,
>   return 0;
>  }
>  
> +static bool micmute_led_set;
> +static int  dmi_matched(const struct dmi_system_id *dmi)
> +{
> + micmute_led_set = 1;
> + return 1;
> +}
> +
> +/* Some systems will need to use this to trigger mic mute LED state changed 
> */
> +static const struct dmi_system_id micmute_led_dmi_table[] = {
> + {
> + .callback = dmi_matched,
> + .matches = {
> + DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
> + DMI_MATCH(DMI_PRODUCT_SKU, "0A32"),
> + },
> + },
> + {
> + .callback = dmi_matched,
> + .matches = {
> + DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
> + DMI_MATCH(DMI_PRODUCT_SKU, "0A3E"),
> + },
> + },
> + {},
> +};
> +
>  static int rt715_sdca_put_volsw(struct snd_kcontrol *kcontrol,
>   struct snd_ctl_elem_value *ucontrol)
>  {
> @@ -358,6 +386,7 @@ static int rt715_sdca_put_volsw(struct snd_kcontrol 
> *kcontrol,
>   unsigned int mask = (1 << fls(max)) - 1;
>   unsigned int invert = p->invert;
>   int err;
> + bool micmute_led;
>  
>   for (i = 0; i < 4; i++) {
>   if (ucontrol->value.integer.value[i] != 
> rt715->kctl_switch_orig[i]) {
> @@ -394,6 +423,18 @@ static int rt715_sdca_put_volsw(struct snd_kcontrol 
> *kcontrol,
>   return err;
>   }
>  
> + /* Micmute LED state changed by muted/unmute switch
> +  * to keep syncing with actual hardware mic mute led state
> +  * invert will be checked to change the state switch
> +  */
> + if (invert && micmute_led_set) {
> + if (ucontrol->value.integer.value[0] || 
> ucontrol->value.integer.value[1])
> + micmute_led = LED_OFF;
> + else
> + micmute_led = LED_ON;
> + ledtrig_audio_set(LED_AUDIO_MICMUTE, micmute_led);
> + }
> +
>   return k_changed;
>  }
>  
> @@ -1066,6 +1107,7 @@ int rt715_sdca_io_init(struct device *dev, struct 
> sdw_slave *slave)
>  
>   pm_runtime_mark_last_busy(>dev);
>   pm_runtime_put_autosuspend(>dev);
> + dmi_check_system(micmute_led_dmi_table);
>  
>   return 0;
>  }
> diff 

Re: [PATCH v3] platform/x86: add Gigabyte WMI temperature driver

[Hans de Goede]

Hi,

On 4/10/21 5:15 PM, Guenter Roeck wrote:
> On 4/10/21 7:40 AM, Thomas Weißschuh wrote:
>> Changes since v1:
>> * Incorporate feedback from Barnabás Pőcze
>>   * Use a WMI driver instead of a platform driver
>>   * Let the kernel manage the driver lifecycle
>>   * Fix errno/ACPI error confusion
>>   * Fix resource cleanup
>>   * Document reason for integer casting
>>
>> Changes since v2:
>> * Style cleanups
>> * Test for usability during probing
>> * DMI-based whitelist
>> * CC hwmon maintainers
>>
>> -- >8 --
>>
>> Tested with a X570 I Aorus Pro Wifi.
>> The mainboard contains an ITE IT8688E chip for management.
>> This chips is also handled by drivers/hwmon/i87.c but as it is also used
>> by the firmware itself it needs an ACPI driver.
>>
>> Unfortunately not all sensor registers are handled by the firmware and even
>> less are exposed via WMI.
>>
>> Signed-off-by: Thomas Weißschuh 
>> ---
>>  MAINTAINERS |   6 +
>>  drivers/platform/x86/Kconfig|  11 ++
>>  drivers/platform/x86/Makefile   |   1 +
>>  drivers/platform/x86/gigabyte-wmi.c | 194 
>>  4 files changed, 212 insertions(+)
>>  create mode 100644 drivers/platform/x86/gigabyte-wmi.c
>>
>> diff --git a/MAINTAINERS b/MAINTAINERS
>> index d92f85ca831d..9c10cfc00fe8 100644
>> --- a/MAINTAINERS
>> +++ b/MAINTAINERS
>> @@ -7543,6 +7543,12 @@ F:Documentation/filesystems/gfs2*
>>  F:  fs/gfs2/
>>  F:  include/uapi/linux/gfs2_ondisk.h
>>  
>> +GIGABYTE WMI DRIVER
>> +M:  Thomas Weißschuh 
>> +L:  platform-driver-...@vger.kernel.org
>> +S:  Maintained
>> +F:  drivers/platform/x86/gigabyte-wmi.c
>> +
>>  GNSS SUBSYSTEM
>>  M:  Johan Hovold 
>>  S:  Maintained
>> diff --git a/drivers/platform/x86/Kconfig b/drivers/platform/x86/Kconfig
>> index ad4e630e73e2..96622a2106f7 100644
>> --- a/drivers/platform/x86/Kconfig
>> +++ b/drivers/platform/x86/Kconfig
>> @@ -123,6 +123,17 @@ config XIAOMI_WMI
>>To compile this driver as a module, choose M here: the module will
>>be called xiaomi-wmi.
>>  
>> +config GIGABYTE_WMI
>> +tristate "Gigabyte WMI temperature driver"
>> +depends on ACPI_WMI
>> +depends on HWMON
>> +help
>> +  Say Y here if you want to support WMI-based temperature reporting on
>> +  Gigabyte mainboards.
>> +
>> +  To compile this driver as a module, choose M here: the module will
>> +  be called gigabyte-wmi.
>> +
>>  config ACERHDF
>>  tristate "Acer Aspire One temperature and fan driver"
>>  depends on ACPI && THERMAL
>> diff --git a/drivers/platform/x86/Makefile b/drivers/platform/x86/Makefile
>> index 60d554073749..1621ebfd04fd 100644
>> --- a/drivers/platform/x86/Makefile
>> +++ b/drivers/platform/x86/Makefile
>> @@ -15,6 +15,7 @@ obj-$(CONFIG_INTEL_WMI_THUNDERBOLT)+= 
>> intel-wmi-thunderbolt.o
>>  obj-$(CONFIG_MXM_WMI)   += mxm-wmi.o
>>  obj-$(CONFIG_PEAQ_WMI)  += peaq-wmi.o
>>  obj-$(CONFIG_XIAOMI_WMI)+= xiaomi-wmi.o
>> +obj-$(CONFIG_GIGABYTE_WMI)  += gigabyte-wmi.o
>>  
>>  # Acer
>>  obj-$(CONFIG_ACERHDF)   += acerhdf.o
>> diff --git a/drivers/platform/x86/gigabyte-wmi.c 
>> b/drivers/platform/x86/gigabyte-wmi.c
>> new file mode 100644
>> index ..fb4e6d4c1823
>> --- /dev/null
>> +++ b/drivers/platform/x86/gigabyte-wmi.c
>> @@ -0,0 +1,194 @@
>> +// SPDX-License-Identifier: GPL-2.0-or-later
>> +/*
>> + *  Copyright (C) 2021 Thomas Weißschuh 
>> + */
>> +#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
>> +
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +#define GIGABYTE_WMI_GUID "DEADBEEF-2001--00A0-C9062910"
>> +#define NUM_TEMPERATURE_SENSORS 6
> 
> Style: #definenamevalue
> 
> but of course that is Hans' call.

I agree that aligning the 2 define values with tabs would be better.

> 
>> +
>> +static bool force_load;
>> +module_param(force_load, bool, 0);
>> +MODULE_PARM_DESC(force_load, "Force loading on non-whitelisted platform");
>> +
>> +enum gigabyte_wmi_commandtype {
>> +GIGABYTE_WMI_BUILD_DATE_QUERY   =   0x1,
>> +GIGABYTE_WMI_MAINBOARD_TYPE_QUERY   =   0x2,
>> +GIGABYTE_WMI_FIRMWARE_VERSION_QUERY =   0x4,
>> +GIGABYTE_WMI_MAINBOARD_NAME_QUERY   =   0x5,
>> +GIGABYTE_WMI_TEMPERATURE_QUERY  = 0x125,
>> +};
>> +
>> +struct gigabyte_wmi_args {
>> +u32 arg1;
>> +};
>> +
>> +static int gigabyte_wmi_perform_query(struct wmi_device *wdev,
>> +  enum gigabyte_wmi_commandtype command,
>> +  struct gigabyte_wmi_args *args, struct 
>> acpi_buffer *out)
>> +{
>> +const struct acpi_buffer in = {
>> +.length = sizeof(*args),
>> +.pointer = args,
>> +};
>> +
>> +acpi_status ret = wmidev_evaluate_method(wdev, 0x0, command, , out);
>> +
>> +if ACPI_FAILURE(ret)
>> +return -EIO;
>> +
>> +return 0;
>> +}
>> +
>> +static int 

Re: [PATCH v3] platform/x86: add Gigabyte WMI temperature driver

[Hans de Goede]

Hi,

On 4/10/21 4:40 PM, Thomas Weißschuh wrote:
> Changes since v1:
> * Incorporate feedback from Barnabás Pőcze
>   * Use a WMI driver instead of a platform driver
>   * Let the kernel manage the driver lifecycle
>   * Fix errno/ACPI error confusion
>   * Fix resource cleanup
>   * Document reason for integer casting
> 
> Changes since v2:
> * Style cleanups
> * Test for usability during probing
> * DMI-based whitelist
> * CC hwmon maintainers
> 
> -- >8 --
> 
> Tested with a X570 I Aorus Pro Wifi.
> The mainboard contains an ITE IT8688E chip for management.
> This chips is also handled by drivers/hwmon/i87.c but as it is also used
> by the firmware itself it needs an ACPI driver.
> 
> Unfortunately not all sensor registers are handled by the firmware and even
> less are exposed via WMI.
> 
> Signed-off-by: Thomas Weißschuh 

This looks good, one small nitpick:

I know this is a touchy subject for some, but we are trying to move away
from the whitelist/blacklist naming where possible and we don't want to
introduce any new cases, see:

https://github.com/torvalds/linux/blob/master/Documentation/process/coding-style.rst#4-naming

The driver currently uses this twice:
"Force loading on non-whitelisted platform"
"Forcing loading on non-whitelisted platform"

Interestingly enough you already avoided naming the dmi_system_id table
a whitelist (good).

I would like to see "non-whitelisted" replaced with "unknown" so that we end up 
with:

"Force loading on unknown platform"
"Forcing loading on unknown platform"

And while at it, I think for the second sentence this would be better English
(I'm not a native speaker myself):

"Forcing load on unknown platform"

If you are ok with these changes I can fix this up while merging, no need
to send a v4. Although if you prefer to send a v4 that is fine too.

Either way let me know.

Regards,

Hans

p.s.

For v4 or for a next patch, the way to add the changelog so that it does
not get picked up / automatically gets snipped by git am is to put it
below the Signed-off-by at the end of the commit message like this:

Signed-off-by: Thomas Weißschuh 
---
Changes since v1:
* Incorporate feedback from Barnabás Pőcze
  * Use a WMI driver instead of a platform driver
  * Let the kernel manage the driver lifecycle
  * Fix errno/ACPI error confusion
  * Fix resource cleanup
  * Document reason for integer casting
 
Changes since v2:
* Style cleanups
* Test for usability during probing
* DMI-based whitelist
* CC hwmon maintainers







> ---
>  MAINTAINERS |   6 +
>  drivers/platform/x86/Kconfig|  11 ++
>  drivers/platform/x86/Makefile   |   1 +
>  drivers/platform/x86/gigabyte-wmi.c | 194 
>  4 files changed, 212 insertions(+)
>  create mode 100644 drivers/platform/x86/gigabyte-wmi.c
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index d92f85ca831d..9c10cfc00fe8 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -7543,6 +7543,12 @@ F: Documentation/filesystems/gfs2*
>  F:   fs/gfs2/
>  F:   include/uapi/linux/gfs2_ondisk.h
>  
> +GIGABYTE WMI DRIVER
> +M:   Thomas Weißschuh 
> +L:   platform-driver-...@vger.kernel.org
> +S:   Maintained
> +F:   drivers/platform/x86/gigabyte-wmi.c
> +
>  GNSS SUBSYSTEM
>  M:   Johan Hovold 
>  S:   Maintained
> diff --git a/drivers/platform/x86/Kconfig b/drivers/platform/x86/Kconfig
> index ad4e630e73e2..96622a2106f7 100644
> --- a/drivers/platform/x86/Kconfig
> +++ b/drivers/platform/x86/Kconfig
> @@ -123,6 +123,17 @@ config XIAOMI_WMI
> To compile this driver as a module, choose M here: the module will
> be called xiaomi-wmi.
>  
> +config GIGABYTE_WMI
> + tristate "Gigabyte WMI temperature driver"
> + depends on ACPI_WMI
> + depends on HWMON
> + help
> +   Say Y here if you want to support WMI-based temperature reporting on
> +   Gigabyte mainboards.
> +
> +   To compile this driver as a module, choose M here: the module will
> +   be called gigabyte-wmi.
> +
>  config ACERHDF
>   tristate "Acer Aspire One temperature and fan driver"
>   depends on ACPI && THERMAL
> diff --git a/drivers/platform/x86/Makefile b/drivers/platform/x86/Makefile
> index 60d554073749..1621ebfd04fd 100644
> --- a/drivers/platform/x86/Makefile
> +++ b/drivers/platform/x86/Makefile
> @@ -15,6 +15,7 @@ obj-$(CONFIG_INTEL_WMI_THUNDERBOLT) += 
> intel-wmi-thunderbolt.o
>  obj-$(CONFIG_MXM_WMI)+= mxm-wmi.o
>  obj-$(CONFIG_PEAQ_WMI)   += peaq-wmi.o
>  obj-$(CONFIG_XIAOMI_WMI) += xiaomi-wmi.o
> +obj-$(CONFIG_GIGABYTE_WMI)   += gigabyte-wmi.o
>  
>  # Acer
>  obj-$(CONFIG_ACERHDF)+= acerhdf.o
> diff --git a/drivers/platform/x86/gigabyte-wmi.c 
> b/drivers/platform/x86/gigabyte-wmi.c
> new file mode 100644
> index ..fb4e6d4c1823
> --- /dev/null
> +++ b/drivers/platform/x86/gigabyte-wmi.c
> @@ -0,0 +1,194 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later
> +/*
> + *  

Re: [PATCH v2] platform/x86: add Gigabyte WMI temperature driver

[Hans de Goede]

Hi,

On 4/10/21 8:56 AM, Guenter Roeck wrote:
> On 4/8/21 11:02 PM, Thomas Weißschuh wrote:
>> On Do, 2021-04-08T08:00-0700, Guenter Roeck wrote:
>>> On 4/8/21 2:36 AM, Hans de Goede wrote:
>>>> On 4/7/21 9:43 PM, Thomas Weißschuh wrote:
>>>>> On Mi, 2021-04-07T17:54+0200, Hans de Goede wrote:
>>>> Jean, Guenter,
>>>>
>>>> Thomas has been working on a WMI driver to expose various motherboard
>>>> temperatures on a gigabyte board where the IO-addresses for the it87 chip
>>>> are reserved by ACPI. We are discussing how best to deal with this, there
>>>> are some ACPI methods to directly access the super-IO registers (with 
>>>> locking
>>>> to protect against other ACPI accesses). This reminded me of an idea I had
>>>> a while ago to solve a similar issue with an other superIO chip, abstract
>>>> the superIO register access-es using some reg_ops struct and allow an 
>>>> ACPI/WMI
>>>> driver to provide alternative reg_ops:
>>>> https://bugzilla.kernel.org/show_bug.cgi?id=204807#c47
>>>>
>>>> Do you think this is a good idea (or a bad one)? And would something like 
>>>> that
>>>> be acceptable to you ?
>>>>
>>>
>>> The upstream it87 driver is severely out of date. I had an out-of-tree 
>>> driver
>>> with various improvements which I didn't upstream, first because no one was 
>>> willing
>>> to review changes and then because it had deviated too much. I pulled it 
>>> from
>>> public view because I got pounded for not upstreaming it, because people 
>>> started
>>> demanding support (not asking, demanding) for it, and because Gigabyte 
>>> stopped
>>> providing datasheets for the more recent ITE chips and it became effectively
>>> unmaintainable.
>>>
>>> Some ITE chips have issues which can cause system hangs if accessed 
>>> directly.
>>> I put some work to remedy that into the non-upstream driver, but that was 
>>> all
>>> just guesswork. Gigabyte knows about the problem (or so I was told from 
>>> someone
>>> who has an NDA with them), but I didn't get them or ITE to even acknowledge 
>>> it
>>> to me. I even had a support case open with Gigabyte for a while, but all I 
>>> could
>>> get out of them is that they don't support Linux and what I would have to 
>>> reproduce
>>> the problem with Windows for them to provide assistance (even though, again,
>>> they knew about it).
>>>
>>> As for using ACPI locks or WMI to ensure that ACPI leaves the chip alone 
>>> while
>>> the driver accesses chips directly: That is an option, but it has (at least)
>>> two problems.
>>>
>>> First, ACPI access methods are not well documented or standardized. I had 
>>> tried
>>> to find useful means to do that some time ago, but I gave up because each 
>>> board
>>> (even from the same vendor) handles locking and accesses differently. We 
>>> would
>>> end up with lots of board specific code. Coincidentally, that was for ASUS 
>>> boards
>>> and the nct6775 driver.
>>
>> At least for all the Gigabyte ACPI tables I have looked at all access is done
>> via two-byte "OperationRegion" over the Index/Data addresses, a "Field" with
>> two entries for these and an "IndexField" that is actually used to perform 
>> the
>> accesses.
>> As the IndexField is synchronized via "Lock" it should take a lock on the
>> OperationRegion itself.
>>
>> So I think we should be technically fine with validating these assumption and
>> then also taking locks on the OperationRegion.
>>
>> If it is reasonable to do so is another question.
>>
> You'd still have to validate this for each individual board unless you get
> confirmation from Gigabyte that the mechanism is consistent on their boards.
> Then you'd have to handle other vendors using it87 chips, and those are
> just as close-lipped as Gigabyte. Ultimately it would require acpi match
> tables to match the various boards and access methods. I had experimented
> with this this a long time ago but gave up on it after concluding that it was
> unmaintainable.
> 
>>> Second, access through ACPI is only one of the issues. Turns out there are 
>>> two
>>> ITE chips on many of the Gigabyte boards nowadays, and the two chips talk 
>>> to each
>>> other using I2C. My out-of-tree 

Re: [PATCH 1/1] usb: typec: tcpm: remove unused static variable 'tcpm_altmode_ops'

[Hans de Goede]

Hi,

On 4/8/21 3:55 PM, Guenter Roeck wrote:
> On 4/8/21 1:28 AM, Heikki Krogerus wrote:
>> On Wed, Apr 07, 2021 at 05:15:40PM +0800, Zhen Lei wrote:
>>> Fixes the following W=1 kernel build warning:
>>>
>>> drivers/usb/typec/tcpm/tcpm.c:2107:39: warning: ‘tcpm_altmode_ops’ defined 
>>> but not used [-Wunused-const-variable=]
>>>
>>> The reference to the variable 'tcpm_altmode_ops' is deleted by the
>>> commit a079973f462a ("usb: typec: tcpm: Remove tcpc_config configuration
>>> mechanism").
>>>
>>> By the way, the static functions referenced only by the variable
>>> 'tcpm_altmode_ops' are deleted accordingly.
>>>
>>> Reported-by: Hulk Robot 
>>> Signed-off-by: Zhen Lei 
>>
>> Oh, I thought this was already fixed. Should this go into the stable
>> trees as well?
>>
> 
> I thought there was some code supposed to be coming which would make use of 
> it,
> but my memory may defeat me.

There is code coming which uses this; and this is necessary to make
DP altmode work on some devices.

I have dropped the ball a bit on posting a v2 of my series using this.

I'll prepare a v2 of my series, addressing Heikki's review comments
to my v1 right away. I'll post a v2 at the latest tomorrow.

This is something which is on my TODO list anyways and this way we will
save some churn with these functions going away only to be re-introduced
again relatively soon after they were removed.

Regards,

Hans


> Either case, it is getting old. It it is ever needed,
> it can be reintroduced.
> 
> Reviewed-by: Guenter Roeck 
> 
> Guenter
> 
>> Acked-by: Heikki Krogerus 
>>
>>> ---
>>>  drivers/usb/typec/tcpm/tcpm.c | 60 
>>> ---
>>>  1 file changed, 60 deletions(-)
>>>
>>> diff --git a/drivers/usb/typec/tcpm/tcpm.c b/drivers/usb/typec/tcpm/tcpm.c
>>> index ce7af398c7c1c1f..2f89bae29c0c297 100644
>>> --- a/drivers/usb/typec/tcpm/tcpm.c
>>> +++ b/drivers/usb/typec/tcpm/tcpm.c
>>> @@ -1365,14 +1365,6 @@ static void tcpm_queue_vdm(struct tcpm_port *port, 
>>> const u32 header,
>>> mod_vdm_delayed_work(port, 0);
>>>  }
>>>  
>>> -static void tcpm_queue_vdm_unlocked(struct tcpm_port *port, const u32 
>>> header,
>>> -   const u32 *data, int cnt)
>>> -{
>>> -   mutex_lock(>lock);
>>> -   tcpm_queue_vdm(port, header, data, cnt);
>>> -   mutex_unlock(>lock);
>>> -}
>>> -
>>>  static void svdm_consume_identity(struct tcpm_port *port, const u32 *p, 
>>> int cnt)
>>>  {
>>> u32 vdo = p[VDO_INDEX_IDH];
>>> @@ -1705,8 +1697,6 @@ static void tcpm_handle_vdm_request(struct tcpm_port 
>>> *port,
>>>  *
>>>  * And we also have this ordering:
>>>  * 1. alt-mode driver takes the alt-mode's lock
>>> -* 2. alt-mode driver calls tcpm_altmode_enter which takes the
>>> -*tcpm port lock
>>>  *
>>>  * Dropping our lock here avoids this.
>>>  */
>>> @@ -2060,56 +2050,6 @@ static int tcpm_validate_caps(struct tcpm_port 
>>> *port, const u32 *pdo,
>>> return 0;
>>>  }
>>>  
>>> -static int tcpm_altmode_enter(struct typec_altmode *altmode, u32 *vdo)
>>> -{
>>> -   struct tcpm_port *port = typec_altmode_get_drvdata(altmode);
>>> -   int svdm_version;
>>> -   u32 header;
>>> -
>>> -   svdm_version = typec_get_negotiated_svdm_version(port->typec_port);
>>> -   if (svdm_version < 0)
>>> -   return svdm_version;
>>> -
>>> -   header = VDO(altmode->svid, vdo ? 2 : 1, svdm_version, CMD_ENTER_MODE);
>>> -   header |= VDO_OPOS(altmode->mode);
>>> -
>>> -   tcpm_queue_vdm_unlocked(port, header, vdo, vdo ? 1 : 0);
>>> -   return 0;
>>> -}
>>> -
>>> -static int tcpm_altmode_exit(struct typec_altmode *altmode)
>>> -{
>>> -   struct tcpm_port *port = typec_altmode_get_drvdata(altmode);
>>> -   int svdm_version;
>>> -   u32 header;
>>> -
>>> -   svdm_version = typec_get_negotiated_svdm_version(port->typec_port);
>>> -   if (svdm_version < 0)
>>> -   return svdm_version;
>>> -
>>> -   header = VDO(altmode->svid, 1, svdm_version, CMD_EXIT_MODE);
>>> -   header |= VDO_OPOS(altmode->mode);
>>> -
>>> -   tcpm_queue_vdm_unlocked(port, header, NULL, 0);
>>> -   return 0;
>>> -}
>>> -
>>> -static int tcpm_altmode_vdm(struct typec_altmode *altmode,
>>> -   u32 header, const u32 *data, int count)
>>> -{
>>> -   struct tcpm_port *port = typec_altmode_get_drvdata(altmode);
>>> -
>>> -   tcpm_queue_vdm_unlocked(port, header, data, count - 1);
>>> -
>>> -   return 0;
>>> -}
>>> -
>>> -static const struct typec_altmode_ops tcpm_altmode_ops = {
>>> -   .enter = tcpm_altmode_enter,
>>> -   .exit = tcpm_altmode_exit,
>>> -   .vdm = tcpm_altmode_vdm,
>>> -};
>>> -
>>>  /*
>>>   * PD (data, control) command handling functions
>>>   */
>>> -- 
>>> 1.8.3
>>>
>>
> 
> 

Re: [PATCH v2] platform/x86: add Gigabyte WMI temperature driver

[Hans de Goede]

Hi Guenter,

On 4/8/21 5:08 PM, Guenter Roeck wrote:
> On Mon, Apr 05, 2021 at 10:48:10PM +0200, Thomas Weißschuh wrote:
>> Changes since v1:
>> * Incorporate feedback from Barnabás Pőcze
>>   * Use a WMI driver instead of a platform driver
>>   * Let the kernel manage the driver lifecycle
>>   * Fix errno/ACPI error confusion
>>   * Fix resource cleanup
>>   * Document reason for integer casting
>>
>> Thank you Barnabás for your review, it is much appreciated.
>>
>> -- >8 --
>>
>> Tested with a X570 I Aorus Pro Wifi.
>> The mainboard contains an ITE IT8688E chip for management.
>> This chips is also handled by drivers/hwmon/i87.c but as it is also used
>> by the firmware itself it needs an ACPI driver.
>>
>> Unfortunately not all sensor registers are handled by the firmware and even
>> less are exposed via WMI.
>>
>> Signed-off-by: Thomas Weißschuh 
>> ---
>>  drivers/platform/x86/Kconfig|  11 +++
>>  drivers/platform/x86/Makefile   |   1 +
>>  drivers/platform/x86/gigabyte-wmi.c | 138 
> 
> Originally drivers/platform was supposed to be used for platform specific
> code. Not that I have control over it, but I really dislike that more and
> more hwmon drivers end up there.
> 
> At least hwmon is in good company - I see drivers for various other subsystems
> there as well. I just wonder if that is such a good idea. That entire 
> directory
> is bypassing subsystem maintainer reviews.

In case you are not aware I've recent(ish) taken over the drivers/platform/x86
maintainership from Andy Shevchenko.

Yes it is a bit of an odd grab-bag it mostly deals with vendor specific
ACPI / WMI interfaces which often more or less require using a single
driver while offering multiple functionalities. These firmware interfaces
do not really lend themselves to demultiplexing through something like
MFD. These are mostly found on laptops where they deal with some or all of:

- Hotkeys for brightness adjust / wlan-on/off toggle, touchpad on/off toggle, 
etc.
  (input subsystem stuff)
- Mic. / Speaker mute LEDS (and other special LEDs) found on some laptops
  (LED subsystem stuff)
- Enabling/disabling radios
  (rfkill stuff)
- Controlling the DPTF performance profile
  (ACPI stuff)
- Various sensors, some hwmon, some IIO
- Backlight control (drm/kms subsys)
- Enabling/disabling of LCD-builtin privacy filters (requires KMS/DRM subsys 
integration, pending)
- Fan control (hwmon subsys)

And often all of this in a single driver. This is all "stuff" for which
there are no standard APIs shared between vendors, so it is a free for
all and often it is all stuffed behind a single WMI or ACPI object,
because that is how the vendor's drivers under Windows work.

It certainly is not my intention to bypass review by other subsystem
maintainers and when there are significant questions I do try to always
get other subsys maintainers involved. See e.g. this thread, but also the
"[PATCH 1/3] thinkpad_acpi: add support for force_discharge" thread
where I asked for input from sre for the power-supply aspects of that.

The WMI code was reworked a while back to make WMI be a bus and have
individual WMI objects be devices on that bus. version 2 of this
driver has been reworked to use this. Since this new driver is just a hwmon
driver and as this is for a desktop I expect it will stay that way,
I'm fine with moving this one over to drivers/hwmon if that has your
preference.

As for other cases then this driver, if you want to make sure you are at
least Cc-ed on all hwmon related changes I'm fine with adding you as a
reviewer to the pdx86 MAINTAINERS entry.

Regards,

Hans




> 
> Guenter
> 
>>  3 files changed, 150 insertions(+)
>>  create mode 100644 drivers/platform/x86/gigabyte-wmi.c
>>
>> diff --git a/drivers/platform/x86/Kconfig b/drivers/platform/x86/Kconfig
>> index ad4e630e73e2..96622a2106f7 100644
>> --- a/drivers/platform/x86/Kconfig
>> +++ b/drivers/platform/x86/Kconfig
>> @@ -123,6 +123,17 @@ config XIAOMI_WMI
>>To compile this driver as a module, choose M here: the module will
>>be called xiaomi-wmi.
>>  
>> +config GIGABYTE_WMI
>> +tristate "Gigabyte WMI temperature driver"
>> +depends on ACPI_WMI
>> +depends on HWMON
>> +help
>> +  Say Y here if you want to support WMI-based temperature reporting on
>> +  Gigabyte mainboards.
>> +
>> +  To compile this driver as a module, choose M here: the module will
>> +  be called gigabyte-wmi.
>> +
>>  config ACERHDF
>>  tristate "Acer Aspire One temperature and fan driver"
>>  depends on ACPI && THERMAL
>> diff --git a/drivers/platform/x86/Makefile b/drivers/platform/x86/Makefile
>> index 60d554073749..1621ebfd04fd 100644
>> --- a/drivers/platform/x86/Makefile
>> +++ b/drivers/platform/x86/Makefile
>> @@ -15,6 +15,7 @@ obj-$(CONFIG_INTEL_WMI_THUNDERBOLT)+= 
>> intel-wmi-thunderbolt.o
>>  obj-$(CONFIG_MXM_WMI)   += mxm-wmi.o
>>  obj-$(CONFIG_PEAQ_WMI)  

Re: linux-next: Signed-off-by missing for commit in the drivers-x86 tree

[Hans de Goede]

Hi all,

On 4/8/21 2:13 PM, Stephen Rothwell wrote:
> Hi all,
> 
> Commit
> 
>   11cccec79c60 ("genirq: Add IRQF_NO_AUTOEN for request_irq/nmi()")
> 
> is missing a Signed-off-by from its committer.

Ugh, thanks for letting me know, this was supposed to come from a merge
from an immutable branch from the tip folks, but I did a rebase -i
to fixup a typo in a commit message and that seems to have flattened
the merge :|

I'll redo the last 3 commits in pdx/for-next to re-add the merge
and do a forced push.

Regards,

Hans

Re: [PATCH 1/1] usb: typec: tcpm: remove unused static variable 'tcpm_altmode_ops'

[Hans de Goede]

Hi,

On 4/8/21 11:25 AM, Heikki Krogerus wrote:
> On Thu, Apr 08, 2021 at 11:10:38AM +0200, Hans de Goede wrote:
>> Hi,
>>
>> On 4/7/21 11:15 AM, Zhen Lei wrote:
>>> Fixes the following W=1 kernel build warning:
>>>
>>> drivers/usb/typec/tcpm/tcpm.c:2107:39: warning: ‘tcpm_altmode_ops’ defined 
>>> but not used [-Wunused-const-variable=]
>>>
>>> The reference to the variable 'tcpm_altmode_ops' is deleted by the
>>> commit a079973f462a ("usb: typec: tcpm: Remove tcpc_config configuration
>>> mechanism").
>>>
>>> By the way, the static functions referenced only by the variable
>>> 'tcpm_altmode_ops' are deleted accordingly.
>>>
>>> Reported-by: Hulk Robot 
>>> Signed-off-by: Zhen Lei 
>>
>> I have a patch pending:
>>
>> https://www.spinics.net/lists/linux-usb/msg197684.html
>>
>> Which actually uses this. I really need to (and plan to) brush the dust of
>> this one soon and submit a new version.
>>
>> As such I would prefer for these ops to not get removed. But I guess I
>> can always include a patch in my series reverting the removal...
> 
> Well, can we then just leave the ops there? If we're going to
> re-introduce them back soon in any case, then why drop them in the
> first place.

Yes I'm in favor of just leaving them in place too, sorry if that was
not clear.

Regards,

Hans

Re: [PATCH v2] platform/x86: add Gigabyte WMI temperature driver

[Hans de Goede]

Hi,

On 4/7/21 9:43 PM, Thomas Weißschuh wrote:
> Hi Hans,
> 
> On Mi, 2021-04-07T17:54+0200, Hans de Goede wrote:
>> Thank you for your new driver and thank you for the quick respin
>> addressing Barnabás' request to make it a WMI driver.
>>
>> The code looks good, so merging this should be a no-brainer,
>> yet I'm not sure if I should merge this driver as-is, let me
>> explain.
> 
> thanks for the encouraging words.
> 
>> The problem is that I assume that this is based on reverse-engineering?
> 
> Yes, it is completely reverse-engineered.
> Essentially I stumbled upon Matthews comment at
> https://bugzilla.kernel.org/show_bug.cgi?id=204807#c37 and went from there.
> 
>> We have some mixes experiences with reverse-engineered WMI drivers,
>> sometimes a feature is not supported yet the wmi_evaluate_method()
>> call happily succeeds. One example of this causing trouble is:
>>
>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=1797d588af15174d4a4e7159dac8c800538e4f8c
> 
> There actually are reports of recent, similar mainboards with recent firmware 
> and
> similar sensor chips that do not support the temperature query.
> (https://github.com/t-8ch/linux-gigabyte-wmi-driver/issues/3 and
> https://github.com/t-8ch/linux-gigabyte-wmi-driver/issues/2)
> 
> Unfortunately for unknown WMI queries the firmware does not return any value.
> This ends up as an ACPI integer with value 0 on the driver side.
> (Which I could not yet find documentation for if that is expected)
> In the current version of the driver EIO is returned for 0 values which
> get translated to N/A by lm-sensors.
> 
>> At a minimum I think your driver should check in its
>> probe function that
>>
>> gigabyte_wmi_query_integer(GIGABYTE_WMI_TEMPERATURE_QUERY, ...)
>>
>> actually succeeds on the machine the driver is running on chances
>> are that Gigabyte has been using the DEADBEEF-2001--00A0-C9062910
>> GUID for ages, where as the 0x125 value for GIGABYTE_WMI_TEMPERATURE_QUERY
>> suggests that this is a pretty new API.
> 
> Would it be enough to probe all six sensors and check if all return 0?

I think that failing the probe with -ENODEV, with a dev_info() explaining why 
when
all six sensors return 0 would be good yes, that should also fix those 2
issues on https://github.com/t-8ch/linux-gigabyte-wmi-driver/.

>> It would be good if you can see if you can find some DSDT-s for older
>> gigabyte motherboards attached to various distro's bug-tracking systems
>> or forum posts and see how those respond to an unknown 
>> gigabyte_wmi_commandtype.
> 
> Will do.

Since you alreayd have bugreports of boards where this does not work,
please don't spend too much time on this. I guess those older DSDT-s will
also just return an integer with value 0.

>> Another open question to make sure this driver is suitable
>> as a generic driver (and does not misbehave) is how to figure out
>> how many temperature sensors there actually are.
> 
> So far I could not find out how to query this from the firmware.
> The IT8688 chip can report the state of each sensor but that is not exposed by
> the firmware.
> But even the state information from the IT8688 is not accurate as is.
> One of the sensors that is reported as being active (directly via it87) on my
> machine always reports -55°C (yes, negative).

Ok.

>> Perhaps the WMI interface returns an error when you query an out-of-range
>> temperature channel?
> 
> Also "0" as mentioned above.

Hmm, so maybe this can be used to limit the amount of reported temperature
sensors, IOW if sensors 5 and 6 report 0, only register 4 sensors ?

> 
>> One option here might be to add a DMI matching table and only load on
>> systems on that table for now. That table could then perhaps also provide
>> labels for each of the temperature channels, which is something which
>> would be nice to have regardless of my worries about how well this driver
>> will work on motherboards on which it has not been tested.
> 
> I am collecting reports for working motherboards at
> https://github.com/t-8ch/linux-gigabyte-wmi-driver/issues/1 .

Good, you should probably ask reporters there to provide the output of:

grep . /sys/class/dmi/id/* 2> /dev/null

Ran as a normal user (so that the serial-numbers will be skipped) so that
you will have DMI strings to match on if you decide to go that route.

> 
>> You could combine this DMI matching table with a "force" module option to
>> continue with probing on boards which are not on the table to allow users
>> to test and report their results to you.
>>
>> And hopefully after a while, 

Re: [PATCH 1/1] usb: typec: tcpm: remove unused static variable 'tcpm_altmode_ops'

[Hans de Goede]

Hi,

On 4/7/21 11:15 AM, Zhen Lei wrote:
> Fixes the following W=1 kernel build warning:
> 
> drivers/usb/typec/tcpm/tcpm.c:2107:39: warning: ‘tcpm_altmode_ops’ defined 
> but not used [-Wunused-const-variable=]
> 
> The reference to the variable 'tcpm_altmode_ops' is deleted by the
> commit a079973f462a ("usb: typec: tcpm: Remove tcpc_config configuration
> mechanism").
> 
> By the way, the static functions referenced only by the variable
> 'tcpm_altmode_ops' are deleted accordingly.
> 
> Reported-by: Hulk Robot 
> Signed-off-by: Zhen Lei 

I have a patch pending:

https://www.spinics.net/lists/linux-usb/msg197684.html

Which actually uses this. I really need to (and plan to) brush the dust of
this one soon and submit a new version.

As such I would prefer for these ops to not get removed. But I guess I
can always include a patch in my series reverting the removal...

Regards,

Hans



> ---
>  drivers/usb/typec/tcpm/tcpm.c | 60 
> ---
>  1 file changed, 60 deletions(-)
> 
> diff --git a/drivers/usb/typec/tcpm/tcpm.c b/drivers/usb/typec/tcpm/tcpm.c
> index ce7af398c7c1c1f..2f89bae29c0c297 100644
> --- a/drivers/usb/typec/tcpm/tcpm.c
> +++ b/drivers/usb/typec/tcpm/tcpm.c
> @@ -1365,14 +1365,6 @@ static void tcpm_queue_vdm(struct tcpm_port *port, 
> const u32 header,
>   mod_vdm_delayed_work(port, 0);
>  }
>  
> -static void tcpm_queue_vdm_unlocked(struct tcpm_port *port, const u32 header,
> - const u32 *data, int cnt)
> -{
> - mutex_lock(>lock);
> - tcpm_queue_vdm(port, header, data, cnt);
> - mutex_unlock(>lock);
> -}
> -
>  static void svdm_consume_identity(struct tcpm_port *port, const u32 *p, int 
> cnt)
>  {
>   u32 vdo = p[VDO_INDEX_IDH];
> @@ -1705,8 +1697,6 @@ static void tcpm_handle_vdm_request(struct tcpm_port 
> *port,
>*
>* And we also have this ordering:
>* 1. alt-mode driver takes the alt-mode's lock
> -  * 2. alt-mode driver calls tcpm_altmode_enter which takes the
> -  *tcpm port lock
>*
>* Dropping our lock here avoids this.
>*/
> @@ -2060,56 +2050,6 @@ static int tcpm_validate_caps(struct tcpm_port *port, 
> const u32 *pdo,
>   return 0;
>  }
>  
> -static int tcpm_altmode_enter(struct typec_altmode *altmode, u32 *vdo)
> -{
> - struct tcpm_port *port = typec_altmode_get_drvdata(altmode);
> - int svdm_version;
> - u32 header;
> -
> - svdm_version = typec_get_negotiated_svdm_version(port->typec_port);
> - if (svdm_version < 0)
> - return svdm_version;
> -
> - header = VDO(altmode->svid, vdo ? 2 : 1, svdm_version, CMD_ENTER_MODE);
> - header |= VDO_OPOS(altmode->mode);
> -
> - tcpm_queue_vdm_unlocked(port, header, vdo, vdo ? 1 : 0);
> - return 0;
> -}
> -
> -static int tcpm_altmode_exit(struct typec_altmode *altmode)
> -{
> - struct tcpm_port *port = typec_altmode_get_drvdata(altmode);
> - int svdm_version;
> - u32 header;
> -
> - svdm_version = typec_get_negotiated_svdm_version(port->typec_port);
> - if (svdm_version < 0)
> - return svdm_version;
> -
> - header = VDO(altmode->svid, 1, svdm_version, CMD_EXIT_MODE);
> - header |= VDO_OPOS(altmode->mode);
> -
> - tcpm_queue_vdm_unlocked(port, header, NULL, 0);
> - return 0;
> -}
> -
> -static int tcpm_altmode_vdm(struct typec_altmode *altmode,
> - u32 header, const u32 *data, int count)
> -{
> - struct tcpm_port *port = typec_altmode_get_drvdata(altmode);
> -
> - tcpm_queue_vdm_unlocked(port, header, data, count - 1);
> -
> - return 0;
> -}
> -
> -static const struct typec_altmode_ops tcpm_altmode_ops = {
> - .enter = tcpm_altmode_enter,
> - .exit = tcpm_altmode_exit,
> - .vdm = tcpm_altmode_vdm,
> -};
> -
>  /*
>   * PD (data, control) command handling functions
>   */
> 

Re: [PATCH] platform/surface: aggregator_registry: Give devices time to set up when connecting

[Hans de Goede]

Hi,

On 4/6/21 1:12 AM, Maximilian Luz wrote:
> Sometimes, the "base connected" event that we rely on to (re-)attach the
> device connected to the base is sent a bit too early. When this happens,
> some devices may not be completely ready yet.
> 
> Specifically, the battery has been observed to report zero-values for
> things like full charge capacity, which, however, is only loaded once
> when the driver for that device probes. This can thus result in battery
> readings being unavailable.
> 
> As we cannot easily and reliably discern between devices that are not
> ready yet and devices that are not connected (i.e. will never be ready),
> delay adding these devices. This should give them enough time to set up.
> 
> The delay is set to 2.5 seconds, which should give us a good safety
> margin based on testing and still be fairly responsive for users.
> 
> To achieve that delay switch to updating via a delayed work struct,
> which means that we can also get rid of some locking.
> 
> Signed-off-by: Maximilian Luz 

Thank you for your patch, I've applied this patch to my review-hans 
branch:
https://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86.git/log/?h=review-hans

Note it will show up in my review-hans branch once I've pushed my
local branch there, which might take a while.

Once I've run some tests on this branch the patches there will be
added to the platform-drivers-x86/for-next branch and eventually
will be included in the pdx86 pull-request to Linus for the next
merge-window.

Regards,

Hans


> ---
>  .../surface/surface_aggregator_registry.c | 98 ---
>  1 file changed, 40 insertions(+), 58 deletions(-)
> 
> diff --git a/drivers/platform/surface/surface_aggregator_registry.c 
> b/drivers/platform/surface/surface_aggregator_registry.c
> index eccb9d1007cd..685d37a7add1 100644
> --- a/drivers/platform/surface/surface_aggregator_registry.c
> +++ b/drivers/platform/surface/surface_aggregator_registry.c
> @@ -13,10 +13,10 @@
>  #include 
>  #include 
>  #include 
> -#include 
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include 
>  #include 
> @@ -287,6 +287,13 @@ static int ssam_hub_add_devices(struct device *parent, 
> struct ssam_controller *c
>  
>  /* -- SSAM base-hub driver. 
> - */
>  
> +/*
> + * Some devices (especially battery) may need a bit of time to be fully 
> usable
> + * after being (re-)connected. This delay has been determined via
> + * experimentation.
> + */
> +#define SSAM_BASE_UPDATE_CONNECT_DELAY   msecs_to_jiffies(2500)
> +
>  enum ssam_base_hub_state {
>   SSAM_BASE_HUB_UNINITIALIZED,
>   SSAM_BASE_HUB_CONNECTED,
> @@ -296,8 +303,8 @@ enum ssam_base_hub_state {
>  struct ssam_base_hub {
>   struct ssam_device *sdev;
>  
> - struct mutex lock;  /* Guards state update checks and transitions. */
>   enum ssam_base_hub_state state;
> + struct delayed_work update_work;
>  
>   struct ssam_event_notifier notif;
>  };
> @@ -335,11 +342,7 @@ static ssize_t ssam_base_hub_state_show(struct device 
> *dev, struct device_attrib
>   char *buf)
>  {
>   struct ssam_base_hub *hub = dev_get_drvdata(dev);
> - bool connected;
> -
> - mutex_lock(>lock);
> - connected = hub->state == SSAM_BASE_HUB_CONNECTED;
> - mutex_unlock(>lock);
> + bool connected = hub->state == SSAM_BASE_HUB_CONNECTED;
>  
>   return sysfs_emit(buf, "%d\n", connected);
>  }
> @@ -356,16 +359,20 @@ static const struct attribute_group ssam_base_hub_group 
> = {
>   .attrs = ssam_base_hub_attrs,
>  };
>  
> -static int __ssam_base_hub_update(struct ssam_base_hub *hub, enum 
> ssam_base_hub_state new)
> +static void ssam_base_hub_update_workfn(struct work_struct *work)
>  {
> + struct ssam_base_hub *hub = container_of(work, struct ssam_base_hub, 
> update_work.work);
>   struct fwnode_handle *node = dev_fwnode(>sdev->dev);
> + enum ssam_base_hub_state state;
>   int status = 0;
>  
> - lockdep_assert_held(>lock);
> + status = ssam_base_hub_query_state(hub, );
> + if (status)
> + return;
>  
> - if (hub->state == new)
> - return 0;
> - hub->state = new;
> + if (hub->state == state)
> + return;
> + hub->state = state;
>  
>   if (hub->state == SSAM_BASE_HUB_CONNECTED)
>   status = ssam_hub_add_devices(>sdev->dev, hub->sdev->ctrl, 
> node);
> @@ -374,51 +381,28 @@ static int __ssam_base_hub_update(struct ssam_base_hub 
> *hub, enum ssam_base_hub_
>  
>   if (status)
>   dev_err(>sdev->dev, "failed to update base-hub devices: 
> %d\n", status);
> -
> - return status;
> -}
> -
> -static int ssam_base_hub_update(struct ssam_base_hub *hub)
> -{
> - enum ssam_base_hub_state state;
> - int status;
> -
> - mutex_lock(>lock);
> -
> - status = ssam_base_hub_query_state(hub, );
> - if (!status)
> - 

Re: [PATCH v2] platform/x86: add Gigabyte WMI temperature driver

[Hans de Goede]

Hi Thomas,

Thank you for your new driver and thank you for the quick respin
addressing Barnabás' request to make it a WMI driver.

The code looks good, so merging this should be a no-brainer,
yet I'm not sure if I should merge this driver as-is, let me
explain.

The problem is that I assume that this is based on reverse-engineering?

We have some mixes experiences with reverse-engineered WMI drivers,
sometimes a feature is not supported yet the wmi_evaluate_method()
call happily succeeds. One example of this causing trouble is:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=1797d588af15174d4a4e7159dac8c800538e4f8c

At a minimum I think your driver should check in its
probe function that

gigabyte_wmi_query_integer(GIGABYTE_WMI_TEMPERATURE_QUERY, ...)

actually succeeds on the machine the driver is running on chances
are that Gigabyte has been using the DEADBEEF-2001--00A0-C9062910
GUID for ages, where as the 0x125 value for GIGABYTE_WMI_TEMPERATURE_QUERY
suggests that this is a pretty new API.

It would be good if you can see if you can find some DSDT-s for older
gigabyte motherboards attached to various distro's bug-tracking systems
or forum posts and see how those respond to an unknown gigabyte_wmi_commandtype.

Another open question to make sure this driver is suitable
as a generic driver (and does not misbehave) is how to figure out
how many temperature sensors there actually are.

Perhaps the WMI interface returns an error when you query an out-of-range
temperature channel?

One option here might be to add a DMI matching table and only load on
systems on that table for now. That table could then perhaps also provide
labels for each of the temperature channels, which is something which
would be nice to have regardless of my worries about how well this driver
will work on motherboards on which it has not been tested.

You could combine this DMI matching table with a "force" module option to
continue with probing on boards which are not on the table to allow users
to test and report their results to you.

And hopefully after a while, when we're confident that the code works
well on most gigabyte boards we can drop the DMI table, or at least
only use it for the channel labels.

Please don't take this the wrong way; I think it is great that you are
working on this. And the quick turnaround of the v2 of this drivers makes
me pretty certain that we can figure something out and get this merged.

Have you tried contacting Gigabyte about this? I don't think the WMI
interface is something which they need to keep secret for competitive
reasons, so maybe they can help? Note if they want you to sign a NDA
of sorts to view docs, then make sure that it contains some language
about them allowing you to release an opensource driver for their
hardware based on the "protected" information.

Regards,

Hans









On 4/5/21 10:48 PM, Thomas Weißschuh wrote:
> Changes since v1:
> * Incorporate feedback from Barnabás Pőcze
>   * Use a WMI driver instead of a platform driver
>   * Let the kernel manage the driver lifecycle
>   * Fix errno/ACPI error confusion
>   * Fix resource cleanup
>   * Document reason for integer casting
> 
> Thank you Barnabás for your review, it is much appreciated.
> 
> -- >8 --
> 
> Tested with a X570 I Aorus Pro Wifi.
> The mainboard contains an ITE IT8688E chip for management.
> This chips is also handled by drivers/hwmon/i87.c but as it is also used
> by the firmware itself it needs an ACPI driver.
> 
> Unfortunately not all sensor registers are handled by the firmware and even
> less are exposed via WMI.
> 
> Signed-off-by: Thomas Weißschuh 
> ---
>  drivers/platform/x86/Kconfig|  11 +++
>  drivers/platform/x86/Makefile   |   1 +
>  drivers/platform/x86/gigabyte-wmi.c | 138 
>  3 files changed, 150 insertions(+)
>  create mode 100644 drivers/platform/x86/gigabyte-wmi.c
> 
> diff --git a/drivers/platform/x86/Kconfig b/drivers/platform/x86/Kconfig
> index ad4e630e73e2..96622a2106f7 100644
> --- a/drivers/platform/x86/Kconfig
> +++ b/drivers/platform/x86/Kconfig
> @@ -123,6 +123,17 @@ config XIAOMI_WMI
> To compile this driver as a module, choose M here: the module will
> be called xiaomi-wmi.
>  
> +config GIGABYTE_WMI
> + tristate "Gigabyte WMI temperature driver"
> + depends on ACPI_WMI
> + depends on HWMON
> + help
> +   Say Y here if you want to support WMI-based temperature reporting on
> +   Gigabyte mainboards.
> +
> +   To compile this driver as a module, choose M here: the module will
> +   be called gigabyte-wmi.
> +
>  config ACERHDF
>   tristate "Acer Aspire One temperature and fan driver"
>   depends on ACPI && THERMAL
> diff --git a/drivers/platform/x86/Makefile b/drivers/platform/x86/Makefile
> index 60d554073749..1621ebfd04fd 100644
> --- a/drivers/platform/x86/Makefile
> +++ b/drivers/platform/x86/Makefile
> @@ -15,6 +15,7 @@ 

Re: [PATCH v6 1/2] platform/x86: dell-privacy: Add support for Dell hardware privacy

[Hans de Goede]

Hi Perry, Barnabás,

Barnabás thank you for your review. I agree with all your remarks.

Perry, Thank you for the new version, this version is looking good.
This is almost ready for merging.

Please fix the review remarks from Barnabás. I also have a couple of small
review remarks myself below.

On 4/4/21 6:53 PM, Barnabás Pőcze wrote:
> Hi
> 
> 
> 2021. április 4., vasárnap 10:31 keltezéssel, Perry Yuan írta:
> 
>> From: Perry Yuan 
>>
>> add support for Dell privacy driver for the Dell units equipped
>> hardware privacy design, which protect users privacy of audio and
>> camera from hardware level. Once the audio or camera privacy mode
>> activated, any applications will not get any audio or video stream
>> when user pressed ctrl+F4 hotkey, audio privacy mode will be
>> enabled, micmute led will be also changed accordingly
>> The micmute led is fully controlled by hardware & EC(embedded controller)
>> and camera mute hotkey is Ctrl+F9. Currently design only emits
>> SW_CAMERA_LENS_COVER event while the camera lens shutter will be
>> changed by EC & HW(hardware) control
>>
>> *The flow is like this:
>> 1) User presses key. HW does stuff with this key (timeout timer is started)
>> 2) WMI event is emitted from BIOS to kernel
>> 3) WMI event is received by dell-privacy
>> 4) KEY_MICMUTE emitted from dell-privacy
>> 5) Userland picks up key and modifies kcontrol for SW mute
>> 6) Codec kernel driver catches and calls ledtrig_audio_set, like this:
>>ledtrig_audio_set(LED_AUDIO_MICMUTE, rt715->micmute_led ? LED_ON 
>> :LED_OFF);
>> 7) If "LED" is set to on dell-privacy notifies EC, and timeout is cancelled,
>>HW mic mute activated. If EC not notified, HW mic mute will also be
>>activated when timeout used up, it is just later than active ack
>>
>> Signed-off-by: Perry Yuan 
>> ---
>> v5 -> v6:
>> * addressed feedback from Hans
>> * addressed feedback from Pierre
>> * optimize some debug format with dev_dbg()
>> * remove platform driver,combined privacy acpi driver into single wmi
>>   driver file
>> * optimize sysfs interface with string added to be more clearly reading
>> v4 -> v5:
>> * addressed feedback from Randy Dunlap
>> * addressed feedback from Pierre-Louis Bossart
>> * rebase to latest 5.12 rc4 upstream kernel
>> * fix some space alignment problem
>> v3 -> v4:
>> * fix format for Kconfig
>> * add sysfs document
>> * add flow comments to the privacy wmi/acpi driver
>> * addressed feedback from Barnabás Pőcze[Thanks very much]
>> * export privacy_valid to make the global state simpler to query
>> * fix one issue which will block the dell-laptop driver to load when
>>   privacy driver invalid
>> * addressed feedback from Pierre-Louis Bossart,remove the EC ID match
>> v2 -> v3:
>> * add sysfs attributes doc
>> v1 -> v2:
>> * query EC handle from EC driver directly.
>> * fix some code style.
>> * add KEY_END to keymap array.
>> * clean platform device when cleanup called
>> * use hexadecimal format for log print in dev_dbg
>> * remove __set_bit for the report keys from probe.
>> * fix keymap leak
>> * add err_free_keymap in dell_privacy_wmi_probe
>> * wmi driver will be unregistered if privacy_acpi_init() fails
>> * add sysfs attribute files for user space query.
>> * add leds micmute driver to privacy acpi
>> * add more design info the commit info
>> ---
>> ---
>>  .../testing/sysfs-platform-dell-privacy-wmi   |  55 +++
>>  drivers/platform/x86/dell/Kconfig |  14 +
>>  drivers/platform/x86/dell/Makefile|   1 +
>>  drivers/platform/x86/dell/dell-laptop.c   |  23 +-
>>  drivers/platform/x86/dell/dell-privacy-wmi.c  | 441 ++
>>  drivers/platform/x86/dell/dell-privacy-wmi.h  |  32 ++
>>  drivers/platform/x86/dell/dell-wmi.c  |  13 +-
>>  7 files changed, 572 insertions(+), 7 deletions(-)
>>  create mode 100644 Documentation/ABI/testing/sysfs-platform-dell-privacy-wmi
>>  create mode 100644 drivers/platform/x86/dell/dell-privacy-wmi.c
>>  create mode 100644 drivers/platform/x86/dell/dell-privacy-wmi.h
>>
>> diff --git a/Documentation/ABI/testing/sysfs-platform-dell-privacy-wmi 
>> b/Documentation/ABI/testing/sysfs-platform-dell-privacy-wmi
>> new file mode 100644
>> index ..a57ddc6a221e
>> --- /dev/null
>> +++ b/Documentation/ABI/testing/sysfs-platform-dell-privacy-wmi
>> @@ -0,0 +1,55 @@
>> +What:   
>> /sys/bus/wmi/devices/6932965F-1671-4CEB-B988-D3AB0A901919/dell_privacy_supported_type
>> +Date:   Apr 2021
>> +KernelVersion:  5.13
>> +Contact:"perry.y...@dell.com>"
>> +Description:
>> +Display which dell hardware level privacy devices are supported
>> +“Dell Privacy” is a set of HW, FW, and SW features to enhance
>> +Dell’s commitment to platform privacy for MIC, Camera, and
>> +ePrivacy screens.
>> +The supported hardware privacy devices are:
>> +Attributes:
>> +Microphone Mute:
>> +Identifies the 

Re: [PATCH 0/3] Adjust contacts for Dell drivers

[Hans de Goede]

Hi,

On 4/1/21 6:22 PM, Mario Limonciello wrote:
> The Dell drivers I'm involved with all have me as an author and/or
> maintainer.  In the future these will be maintained as a team effort.
> Adjust the contact addresses accordingly.
> 
> Mario Limonciello (3):
>   MAINTAINERS: Adjust Dell drivers to email alias
>   MAINTAINERS: Add missing section for alienware-wmi driver
>   platform/x86: Adjust Dell drivers to a personal email address

Thank you for your patch-series, I've applied the series to my
review-hans branch:
https://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86.git/log/?h=review-hans

Note it will show up in my review-hans branch once I've pushed my
local branch there, which might take a while.

Once I've run some tests on this branch the patches there will be
added to the platform-drivers-x86/for-next branch and eventually
will be included in the pdx86 pull-request to Linus for the next
merge-window.

Regards,

Hans




> 
>  MAINTAINERS | 17 +++--
>  drivers/platform/x86/dell/alienware-wmi.c   |  4 ++--
>  drivers/platform/x86/dell/dell-smbios-base.c|  2 +-
>  drivers/platform/x86/dell/dell-wmi-descriptor.c |  2 +-
>  .../platform/x86/dell/dell-wmi-sysman/sysman.c  |  2 +-
>  5 files changed, 16 insertions(+), 11 deletions(-)
> 

Re: [PATCH 0/9] intel_pmc_core: Add sub-state requirements and mode latching support

[Hans de Goede]

Hi,

On 4/1/21 5:05 AM, David E. Box wrote:
> - Patch 1 and 2 remove the use of the global struct pmc_dev
> - Patches 3-7 add support for reading low power mode sub-state
>   requirements, latching sub-state status on different low power mode
>   events, and displaying the sub-state residency in microseconds
> - Patch 8 adds missing LTR IPs for TGL
> - Patch 9 adds support for ADL-P which is based on TGL
> 
> Applied on top of latest 5.12-rc2 based hans-review/review-hans

Thnak you for this series, this mostly is fine, a few small remarks
on patch 5/9 and 7/9 if you can send a v2 addressing those, then
this is ready for merging.

Regards,

Hans


> 
> David E. Box (4):
>   platform/x86: intel_pmc_core: Don't use global pmcdev in quirks
>   platform/x86: intel_pmc_core: Remove global struct pmc_dev
>   platform/x86: intel_pmc_core: Add option to set/clear LPM mode
>   platform/x86: intel_pmc_core: Add support for Alder Lake PCH-P
> 
> Gayatri Kammela (5):
>   platform/x86: intel_pmc_core: Handle sub-states generically
>   platform/x86: intel_pmc_core: Show LPM residency in microseconds
>   platform/x86: intel_pmc_core: Get LPM requirements for Tiger Lake
>   platform/x86: intel_pmc_core: Add requirements file to debugfs
>   platform/x86: intel_pmc_core: Add LTR registers for Tiger Lake
> 
>  drivers/platform/x86/intel_pmc_core.c | 359 +++---
>  drivers/platform/x86/intel_pmc_core.h |  47 +++-
>  2 files changed, 370 insertions(+), 36 deletions(-)
> 

Re: [PATCH 9/9] platform/x86: intel_pmc_core: Add support for Alder Lake PCH-P

[Hans de Goede]

Hi,

On 4/1/21 5:05 AM, David E. Box wrote:
> Alder PCH-P is based on Tiger Lake PCH.
> 
> Signed-off-by: David E. Box 

Thanks, patch looks good to me:

Reviewed-by: Hans de Goede 

Regards,

Hans


> ---
>  drivers/platform/x86/intel_pmc_core.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/platform/x86/intel_pmc_core.c 
> b/drivers/platform/x86/intel_pmc_core.c
> index 9168062c927e..88d582df829f 100644
> --- a/drivers/platform/x86/intel_pmc_core.c
> +++ b/drivers/platform/x86/intel_pmc_core.c
> @@ -1440,6 +1440,7 @@ static const struct x86_cpu_id intel_pmc_core_ids[] = {
>   X86_MATCH_INTEL_FAM6_MODEL(ATOM_TREMONT,_reg_map),
>   X86_MATCH_INTEL_FAM6_MODEL(ATOM_TREMONT_L,  _reg_map),
>   X86_MATCH_INTEL_FAM6_MODEL(ROCKETLAKE,  _reg_map),
> + X86_MATCH_INTEL_FAM6_MODEL(ALDERLAKE_L, _reg_map),
>   {}
>  };
>  
> 

Re: [PATCH 8/9] platform/x86: intel_pmc_core: Add LTR registers for Tiger Lake

[Hans de Goede]

Hi,

On 4/1/21 5:05 AM, David E. Box wrote:
> From: Gayatri Kammela 
> 
> Just like Ice Lake, Tiger Lake uses Cannon Lake's LTR information
> and supports a few additional registers. Hence add the LTR registers
> specific to Tiger Lake to the cnp_ltr_show_map[].
> 
> Also adjust the number of LTR IPs for Tiger Lake to the correct amount.
> 
> Signed-off-by: Gayatri Kammela 
> Signed-off-by: David E. Box 

Thanks, patch looks good to me:

Reviewed-by: Hans de Goede 

Regards,

Hans


> ---
>  drivers/platform/x86/intel_pmc_core.c | 2 ++
>  drivers/platform/x86/intel_pmc_core.h | 4 +++-
>  2 files changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/platform/x86/intel_pmc_core.c 
> b/drivers/platform/x86/intel_pmc_core.c
> index 458c0056e7a1..9168062c927e 100644
> --- a/drivers/platform/x86/intel_pmc_core.c
> +++ b/drivers/platform/x86/intel_pmc_core.c
> @@ -383,6 +383,8 @@ static const struct pmc_bit_map cnp_ltr_show_map[] = {
>* a list of core SoCs using this.
>*/
>   {"WIGIG",   ICL_PMC_LTR_WIGIG},
> + {"THC0",TGL_PMC_LTR_THC0},
> + {"THC1",TGL_PMC_LTR_THC1},
>   /* Below two cannot be used for LTR_IGNORE */
>   {"CURRENT_PLATFORM",CNP_PMC_LTR_CUR_PLT},
>   {"AGGREGATED_SYSTEM",   CNP_PMC_LTR_CUR_ASLT},
> diff --git a/drivers/platform/x86/intel_pmc_core.h 
> b/drivers/platform/x86/intel_pmc_core.h
> index f41f61aa7008..634130b589a2 100644
> --- a/drivers/platform/x86/intel_pmc_core.h
> +++ b/drivers/platform/x86/intel_pmc_core.h
> @@ -192,8 +192,10 @@ enum ppfear_regs {
>  #define ETR3_CLEAR_LPM_EVENTS_BIT28
>  #define LPM_STS_LATCH_MODE_BIT   31
>  
> -#define TGL_NUM_IP_IGN_ALLOWED   22
>  #define TGL_PMC_SLP_S0_RES_COUNTER_STEP  0x7A
> +#define TGL_PMC_LTR_THC0 0x1C04
> +#define TGL_PMC_LTR_THC1 0x1C08
> +#define TGL_NUM_IP_IGN_ALLOWED   23
>  #define TGL_PMC_LPM_RES_COUNTER_STEP_X2  61  /* 30.5us * 2 */
>  
>  /*
> 

Re: [PATCH v1 0/5] ACPI: scan: acpi_bus_check_add() simplifications

[Hans de Goede]

Hi,

On 4/7/21 4:27 PM, Rafael J. Wysocki wrote:
> Hi,
> 
> This series simplifies acpi_bus_check_add() and related code.
> 
> It mostly is not expected to alter functionality, except for patch [4/5] that
> unifies the handling of device and processor objects.
> 
> Please refer to the patch changelogs for details.

Thanks, the entire series looks good to me:

Reviewed-by: Hans de Goede 

Regards,

Hans

Re: [PATCH 7/9] platform/x86: intel_pmc_core: Add option to set/clear LPM mode

[Hans de Goede]

Hi,

On 4/1/21 5:05 AM, David E. Box wrote:
> By default the Low Power Mode (LPM or sub-state) status registers will
> latch condition status on every entry into Package C10. This is
> configurable in the PMC to allow latching on any achievable sub-state. Add
> a debugfs file to support this.
> 
> Also add the option to clear the status registers to 0. Clearing the status
> registers before testing removes ambiguity around when the current values
> were set.
> 
> The new file, latch_lpm_mode, looks like this:
> 
>   [c10] S0i2.0 S0i3.0 S0i2.1 S0i3.1 S0i3.2 clear
> 
> Signed-off-by: David E. Box 
> ---
>  drivers/platform/x86/intel_pmc_core.c | 94 +++
>  drivers/platform/x86/intel_pmc_core.h | 20 ++
>  2 files changed, 114 insertions(+)
> 
> diff --git a/drivers/platform/x86/intel_pmc_core.c 
> b/drivers/platform/x86/intel_pmc_core.c
> index 0b47a1da5f49..458c0056e7a1 100644
> --- a/drivers/platform/x86/intel_pmc_core.c
> +++ b/drivers/platform/x86/intel_pmc_core.c
> @@ -584,6 +584,8 @@ static const struct pmc_reg_map tgl_reg_map = {
>   .ltr_ignore_max = TGL_NUM_IP_IGN_ALLOWED,
>   .lpm_num_maps = TGL_LPM_NUM_MAPS,
>   .lpm_res_counter_step_x2 = TGL_PMC_LPM_RES_COUNTER_STEP_X2,
> + .etr3_offset = TGL_ETR3_OFFSET,
> + .lpm_sts_latch_en_offset = TGL_LPM_STS_LATCH_EN_OFFSET,
>   .lpm_en_offset = TGL_LPM_EN_OFFSET,
>   .lpm_priority_offset = TGL_LPM_PRI_OFFSET,
>   .lpm_residency_offset = TGL_LPM_RESIDENCY_OFFSET,
> @@ -1202,6 +1204,95 @@ static int pmc_core_substate_req_regs_show(struct 
> seq_file *s, void *unused)
>  }
>  DEFINE_SHOW_ATTRIBUTE(pmc_core_substate_req_regs);
>  
> +static int pmc_core_lpm_latch_mode_show(struct seq_file *s, void *unused)
> +{
> + struct pmc_dev *pmcdev = s->private;
> + bool c10;
> + u32 reg;
> + int idx, mode;
> +
> + reg = pmc_core_reg_read(pmcdev, pmcdev->map->lpm_sts_latch_en_offset);
> + if (reg & BIT(LPM_STS_LATCH_MODE_BIT)) {
> + seq_puts(s, "c10");
> + c10 = false;
> + } else {
> + seq_puts(s, "[c10]");
> + c10 = true;
> + }
> +
> + pmc_for_each_mode(idx, mode, pmcdev) {
> + if ((BIT(mode) & reg) && !c10)
> + seq_printf(s, " [%s]", pmc_lpm_modes[mode]);
> + else
> + seq_printf(s, " %s", pmc_lpm_modes[mode]);
> + }

So this either shows [c10] selected, or it shows which s0ix modes
are selected, that is a bit weird.

I realize this is a debugfs interface, but can we still get some docs
in this, at a minimum some more explanation in the commit message ?


> +
> + seq_puts(s, " clear\n");
> +
> + return 0;
> +}
> +
> +static ssize_t pmc_core_lpm_latch_mode_write(struct file *file,
> +  const char __user *userbuf,
> +  size_t count, loff_t *ppos)
> +{
> + struct seq_file *s = file->private_data;
> + struct pmc_dev *pmcdev = s->private;
> + bool clear = false, c10 = false;
> + unsigned char buf[10] = {0};
> + size_t ret;
> + int mode;
> + u32 reg;
> +
> + ret = simple_write_to_buffer(buf, 10, ppos, userbuf, count);
> + if (ret < 0)
> + return ret;

You are using C-string functions on buf below, so you must guarantee
that it is 0 terminated. To guarantee the buffer's size must be 1 larger
then the size which you pass to simple_write_to_buffer()

> +
> + mode = sysfs_match_string(pmc_lpm_modes, buf);
> + if (mode < 0) {
> + if (strncmp("clear", buf, 5) == 0)
> + clear = true;
> + else if (strncmp("c10", buf, 3) == 0)
> + c10 = true;

Ugh, no. Now it will not just accept "clear" and "clear\n" but
also "clear foobar everything else I write now does not matter"
as "clear" string. This misuse of strncmp for sysfs / debugfs write
functions seems to be some sort of anti-pattern in the kernel.

Please use sysfs_streq() here so that only "clear" and "clear\n"
are accepted (and the same for the "c10" check).



> + else
> + return mode;
> + }
> +
> + if (clear) {
> + mutex_lock(>lock);
> +
> + reg = pmc_core_reg_read(pmcdev, pmcdev->map->etr3_offset);
> + reg |= BIT(ETR3_CLEAR_LPM_EVENTS_BIT);
> + pmc_core_reg_write(pmcdev, pmcdev->map->etr3_offset, reg);
> +
> + mutex_unlock(>lock);
> +
> + return count;
> + }
> +
> + if (c10) {
> + mutex_lock(>lock);
> +
> + reg = pmc_core_reg_read(pmcdev, 
> pmcdev->map->lpm_sts_latch_en_offset);
> + reg &= ~BIT(LPM_STS_LATCH_MODE_BIT);
> + pmc_core_reg_write(pmcdev, 
> pmcdev->map->lpm_sts_latch_en_offset, reg);
> +
> + mutex_unlock(>lock);
> +
> + return count;
> + }
> +
> + /*
> +  * For LPM mode latching we set the latch enable 

Re: [PATCH 6/9] platform/x86: intel_pmc_core: Add requirements file to debugfs

[Hans de Goede]

Hi,

On 4/1/21 5:05 AM, David E. Box wrote:
> From: Gayatri Kammela 
> 
> Add the debugfs file, substate_requirements, to view the low power mode
> (LPM) requirements for each enabled mode alongside the last latched status
> of the condition.
> 
> After this patch, the new file will look like this:
> 
> Element |S0i2.0 |S0i3.0 |S0i2.1 |S0i3.1 | 
>S0i3.2 |Status |
> USB2PLL_OFF_STS |  Required |  Required |  Required |  Required | 
>  Required |   |
> PCIe/USB3.1_Gen2PLL_OFF_STS |  Required |  Required |  Required |  Required | 
>  Required |   |
>PCIe_Gen3PLL_OFF_STS |  Required |  Required |  Required |  Required | 
>  Required |   Yes |
> OPIOPLL_OFF_STS |  Required |  Required |  Required |  Required | 
>  Required |   Yes |
>   OCPLL_OFF_STS |  Required |  Required |  Required |  Required | 
>  Required |   Yes |
> MainPLL_OFF_STS |   |  Required |   |  Required | 
>  Required |   |
> 
> Signed-off-by: Gayatri Kammela 
> Co-developed-by: David E. Box 
> Signed-off-by: David E. Box 

Thanks, patch looks good to me:

Reviewed-by: Hans de Goede 

Regards,

Hans

> ---
>  drivers/platform/x86/intel_pmc_core.c | 86 +++
>  1 file changed, 86 insertions(+)
> 
> diff --git a/drivers/platform/x86/intel_pmc_core.c 
> b/drivers/platform/x86/intel_pmc_core.c
> index 0ec26a4c715e..0b47a1da5f49 100644
> --- a/drivers/platform/x86/intel_pmc_core.c
> +++ b/drivers/platform/x86/intel_pmc_core.c
> @@ -1122,6 +1122,86 @@ static int pmc_core_substate_l_sts_regs_show(struct 
> seq_file *s, void *unused)
>  }
>  DEFINE_SHOW_ATTRIBUTE(pmc_core_substate_l_sts_regs);
>  
> +static void pmc_core_substate_req_header_show(struct seq_file *s)
> +{
> + struct pmc_dev *pmcdev = s->private;
> + int i, mode;
> +
> + seq_printf(s, "%30s |", "Element");
> + pmc_for_each_mode(i, mode, pmcdev)
> + seq_printf(s, " %9s |", pmc_lpm_modes[mode]);
> +
> + seq_printf(s, " %9s |\n", "Status");
> +}
> +
> +static int pmc_core_substate_req_regs_show(struct seq_file *s, void *unused)
> +{
> + struct pmc_dev *pmcdev = s->private;
> + const struct pmc_bit_map **maps = pmcdev->map->lpm_sts;
> + const struct pmc_bit_map *map;
> + const int num_maps = pmcdev->map->lpm_num_maps;
> + u32 sts_offset = pmcdev->map->lpm_status_offset;
> + u32 *lpm_req_regs = pmcdev->lpm_req_regs;
> + int mp;
> +
> + /* Display the header */
> + pmc_core_substate_req_header_show(s);
> +
> + /* Loop over maps */
> + for (mp = 0; mp < num_maps; mp++) {
> + u32 req_mask = 0;
> + u32 lpm_status;
> + int mode, idx, i, len = 32;
> +
> + /*
> +  * Capture the requirements and create a mask so that we only
> +  * show an element if it's required for at least one of the
> +  * enabled low power modes
> +  */
> + pmc_for_each_mode(idx, mode, pmcdev)
> + req_mask |= lpm_req_regs[mp + (mode * num_maps)];
> +
> + /* Get the last latched status for this map */
> + lpm_status = pmc_core_reg_read(pmcdev, sts_offset + (mp * 4));
> +
> + /*  Loop over elements in this map */
> + map = maps[mp];
> + for (i = 0; map[i].name && i < len; i++) {
> + u32 bit_mask = map[i].bit_mask;
> +
> + if (!(bit_mask & req_mask))
> + /*
> +  * Not required for any enabled states
> +  * so don't display
> +  */
> + continue;
> +
> + /* Display the element name in the first column */
> + seq_printf(s, "%30s |", map[i].name);
> +
> + /* Loop over the enabled states and display if required 
> */
> + pmc_for_each_mode(idx, mode, pmcdev) {
> + if (lpm_req_regs[mp + (mode * num_maps)] & 
> bit_mask)
> + seq_printf(s, " %9s |",
> +"Required");
> + else
> + seq_printf(s, " %9s |", " ");
> + }
> +
> + /* In Status column, show the last captured state of 

Re: [PATCH 5/9] platform/x86: intel_pmc_core: Get LPM requirements for Tiger Lake

[Hans de Goede]

Hi,

On 4/1/21 5:05 AM, David E. Box wrote:
> From: Gayatri Kammela 
> 
> Platforms that support low power modes (LPM) such as Tiger Lake maintain
> requirements for each sub-state that a readable in the PMC. However, unlike
> LPM status registers, requirement registers are not memory mapped but are
> available from an ACPI _DSM. Collect the requirements for Tiger Lake using
> the _DSM method and store in a buffer.
> 
> Signed-off-by: Gayatri Kammela 
> Co-developed-by: David E. Box 
> Signed-off-by: David E. Box 
> ---
>  drivers/platform/x86/intel_pmc_core.c | 49 +++
>  drivers/platform/x86/intel_pmc_core.h |  2 ++
>  2 files changed, 51 insertions(+)
> 
> diff --git a/drivers/platform/x86/intel_pmc_core.c 
> b/drivers/platform/x86/intel_pmc_core.c
> index ba0db301f07b..0ec26a4c715e 100644
> --- a/drivers/platform/x86/intel_pmc_core.c
> +++ b/drivers/platform/x86/intel_pmc_core.c
> @@ -23,7 +23,9 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -31,6 +33,9 @@
>  
>  #include "intel_pmc_core.h"
>  
> +#define ACPI_S0IX_DSM_UUID   "57a6512e-3979-4e9d-9708-ff13b2508972"
> +#define ACPI_GET_LOW_MODE_REGISTERS  1
> +
>  /* PKGC MSRs are common across Intel Core SoCs */
>  static const struct pmc_bit_map msr_map[] = {
>   {"Package C2",  MSR_PKG_C2_RESIDENCY},
> @@ -587,6 +592,46 @@ static const struct pmc_reg_map tgl_reg_map = {
>   .lpm_live_status_offset = TGL_LPM_LIVE_STATUS_OFFSET,
>  };
>  
> +static void pmc_core_get_tgl_lpm_reqs(struct platform_device *pdev)
> +{
> + struct pmc_dev *pmcdev = platform_get_drvdata(pdev);
> + const int num_maps = pmcdev->map->lpm_num_maps;
> + size_t lpm_size = LPM_MAX_NUM_MODES * num_maps * 4;
> + union acpi_object *out_obj;
> + struct acpi_device *adev;
> + guid_t s0ix_dsm_guid;
> + u32 *lpm_req_regs;
> +
> + adev = ACPI_COMPANION(>dev);
> + if (!adev)
> + return;
> +
> + lpm_req_regs = devm_kzalloc(>dev, lpm_size * sizeof(u32),
> +  GFP_KERNEL);
> + if (!lpm_req_regs)
> + return;
> +
> + guid_parse(ACPI_S0IX_DSM_UUID, _dsm_guid);
> +
> + out_obj = acpi_evaluate_dsm(adev->handle, _dsm_guid, 0,
> + ACPI_GET_LOW_MODE_REGISTERS, NULL);

Since you are using ACPI functions here, maybe change:

depends on PCI

In the config INTEL_PMC_CORE Kconfig entry to:

depends on PCI && ACPI

Note all functions you use are stubbed when !ACPI, so this
should build fine without this, but it will turn this function
into a no-op. If you prefer not to add the depends on ACPI that
is fine too.



> + if (out_obj && out_obj->type == ACPI_TYPE_BUFFER) {
> + u32 *addr = (u32 *)out_obj->buffer.pointer;
> + int size = out_obj->buffer.length;
> +
> + if (size != lpm_size)

You're leaking lpm_req_regs here (sort of) maybe devm_free it here ?

> + return;
> +
> + memcpy_fromio(lpm_req_regs, addr, lpm_size);

This is wrong, the memory in an ACPI buffer is not IO-mem it is normal memory.

> + } else
> + acpi_handle_debug(adev->handle,
> +   "_DSM function 0 evaluation failed\n");
> +
> + ACPI_FREE(out_obj);
> +
> + pmcdev->lpm_req_regs = lpm_req_regs;

You do this even if the "if (out_obj && out_obj->type == ACPI_TYPE_BUFFER)"
check above failed, making pmcdev->lpm_req_regs point to a block of
memory filled with zeros. That does not seem right.

> +}
> +
>  static inline u32 pmc_core_reg_read(struct pmc_dev *pmcdev, int reg_offset)
>  {
>   return readl(pmcdev->regbase + reg_offset);
> @@ -1312,10 +1357,14 @@ static int pmc_core_probe(struct platform_device 
> *pdev)
>   return -ENOMEM;
>  
>   mutex_init(>lock);
> +
>   pmcdev->pmc_xram_read_bit = pmc_core_check_read_lock_bit(pmcdev);
>   pmc_core_get_low_power_modes(pmcdev);
>   pmc_core_do_dmi_quirks(pmcdev);
>  
> + if (pmcdev->map == _reg_map)
> + pmc_core_get_tgl_lpm_reqs(pdev);
> +
>   /*
>* On TGL, due to a hardware limitation, the GBE LTR blocks PC10 when
>* a cable is attached. Tell the PMC to ignore it.
> diff --git a/drivers/platform/x86/intel_pmc_core.h 
> b/drivers/platform/x86/intel_pmc_core.h
> index 3800c1ba6fb7..81d797feed33 100644
> --- a/drivers/platform/x86/intel_pmc_core.h
> +++ b/drivers/platform/x86/intel_pmc_core.h
> @@ -288,6 +288,7 @@ struct pmc_reg_map {
>   * @s0ix_counter:S0ix residency (step adjusted)
>   * @num_modes:   Count of enabled modes
>   * @lpm_en_modes:Array of enabled modes from lowest to highest priority
> + * @lpm_req_regs:List of substate requirements
>   *
>   * pmc_dev contains info about power management controller device.
>   */
> @@ -304,6 +305,7 @@ struct pmc_dev {
>   u64 s0ix_counter;
>   int 

Re: [PATCH 4/9] platform/x86: intel_pmc_core: Show LPM residency in microseconds

[Hans de Goede]

Hi,

On 4/1/21 5:05 AM, David E. Box wrote:
> From: Gayatri Kammela 
> 
> Modify the low power mode (LPM or sub-state) residency counters to display
> in microseconds just like the slp_s0_residency counter. The granularity of
> the counter is approximately 30.5us per tick. Double this value then divide
> by two to maintain accuracy.
> 
> Signed-off-by: Gayatri Kammela 
> Signed-off-by: David E. Box 

Thanks, patch looks good to me:

Reviewed-by: Hans de Goede 

Regards,

Hans

> ---
>  drivers/platform/x86/intel_pmc_core.c | 14 --
>  drivers/platform/x86/intel_pmc_core.h |  3 +++
>  2 files changed, 15 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/platform/x86/intel_pmc_core.c 
> b/drivers/platform/x86/intel_pmc_core.c
> index ce300c2942d0..ba0db301f07b 100644
> --- a/drivers/platform/x86/intel_pmc_core.c
> +++ b/drivers/platform/x86/intel_pmc_core.c
> @@ -578,6 +578,7 @@ static const struct pmc_reg_map tgl_reg_map = {
>   .pm_read_disable_bit = CNP_PMC_READ_DISABLE_BIT,
>   .ltr_ignore_max = TGL_NUM_IP_IGN_ALLOWED,
>   .lpm_num_maps = TGL_LPM_NUM_MAPS,
> + .lpm_res_counter_step_x2 = TGL_PMC_LPM_RES_COUNTER_STEP_X2,
>   .lpm_en_offset = TGL_LPM_EN_OFFSET,
>   .lpm_priority_offset = TGL_LPM_PRI_OFFSET,
>   .lpm_residency_offset = TGL_LPM_RESIDENCY_OFFSET,
> @@ -1026,17 +1027,26 @@ static int pmc_core_ltr_show(struct seq_file *s, void 
> *unused)
>  }
>  DEFINE_SHOW_ATTRIBUTE(pmc_core_ltr);
>  
> +static inline u64 adjust_lpm_residency(struct pmc_dev *pmcdev, u32 offset,
> +const int lpm_adj_x2)
> +{
> + u64 lpm_res = pmc_core_reg_read(pmcdev, offset);
> +
> + return GET_X2_COUNTER((u64)lpm_adj_x2 * lpm_res);
> +}
> +
>  static int pmc_core_substate_res_show(struct seq_file *s, void *unused)
>  {
>   struct pmc_dev *pmcdev = s->private;
> + const int lpm_adj_x2 = pmcdev->map->lpm_res_counter_step_x2;
>   u32 offset = pmcdev->map->lpm_residency_offset;
>   int i, mode;
>  
>   seq_printf(s, "%-10s %-15s\n", "Substate", "Residency");
>  
>   pmc_for_each_mode(i, mode, pmcdev) {
> - seq_printf(s, "%-10s %-15u\n", pmc_lpm_modes[mode],
> -pmc_core_reg_read(pmcdev, offset + (4 * mode)));
> + seq_printf(s, "%-10s %-15llu\n", pmc_lpm_modes[mode],
> +adjust_lpm_residency(pmcdev, offset + (4 * mode), 
> lpm_adj_x2));
>   }
>  
>   return 0;
> diff --git a/drivers/platform/x86/intel_pmc_core.h 
> b/drivers/platform/x86/intel_pmc_core.h
> index 5a4e3a49f5b1..3800c1ba6fb7 100644
> --- a/drivers/platform/x86/intel_pmc_core.h
> +++ b/drivers/platform/x86/intel_pmc_core.h
> @@ -188,9 +188,11 @@ enum ppfear_regs {
>  #define ICL_PMC_SLP_S0_RES_COUNTER_STEP  0x64
>  
>  #define LPM_MAX_NUM_MODES8
> +#define GET_X2_COUNTER(v)((v) >> 1)
>  
>  #define TGL_NUM_IP_IGN_ALLOWED   22
>  #define TGL_PMC_SLP_S0_RES_COUNTER_STEP  0x7A
> +#define TGL_PMC_LPM_RES_COUNTER_STEP_X2  61  /* 30.5us * 2 */
>  
>  /*
>   * Tigerlake Power Management Controller register offsets
> @@ -263,6 +265,7 @@ struct pmc_reg_map {
>   const u32 pm_vric1_offset;
>   /* Low Power Mode registers */
>   const int lpm_num_maps;
> + const int lpm_res_counter_step_x2;
>   const u32 lpm_en_offset;
>   const u32 lpm_priority_offset;
>   const u32 lpm_residency_offset;
> 

Re: [PATCH 3/9] platform/x86: intel_pmc_core: Handle sub-states generically

[Hans de Goede]

Hi,

On 4/1/21 5:05 AM, David E. Box wrote:
> From: Gayatri Kammela 
> 
> The current implementation of pmc_core_substate_res_show() is written
> specifically for Tiger Lake. However, new platforms will also have
> sub-states and may support different modes. Therefore rewrite the code to
> handle sub-states generically.
> 
> Read the number and type of enabled states from the PMC. Use the Low
> Power Mode (LPM) priority register to store the states in order from
> shallowest to deepest for displaying. Add a for_each macro to simplify
> this. While changing the sub-state display it makes sense to show only the
> "enabled" sub-states instead of showing all possible ones. After this
> patch, the debugfs file looks like this:
> 
> Substate   Residency
> S0i2.0 0
> S0i3.0 0
> S0i2.1 9329279
> S0i3.1 0
> S0i3.2 0
> 
> Suggested-by: David E. Box 
> Signed-off-by: Gayatri Kammela 
> Signed-off-by: David E. Box 

Thanks, patch looks good to me:

Reviewed-by: Hans de Goede 

Regards,

Hans

> ---
>  drivers/platform/x86/intel_pmc_core.c | 59 ++-
>  drivers/platform/x86/intel_pmc_core.h | 18 +++-
>  2 files changed, 64 insertions(+), 13 deletions(-)
> 
> diff --git a/drivers/platform/x86/intel_pmc_core.c 
> b/drivers/platform/x86/intel_pmc_core.c
> index 5ca40fe3da59..ce300c2942d0 100644
> --- a/drivers/platform/x86/intel_pmc_core.c
> +++ b/drivers/platform/x86/intel_pmc_core.c
> @@ -577,8 +577,9 @@ static const struct pmc_reg_map tgl_reg_map = {
>   .pm_cfg_offset = CNP_PMC_PM_CFG_OFFSET,
>   .pm_read_disable_bit = CNP_PMC_READ_DISABLE_BIT,
>   .ltr_ignore_max = TGL_NUM_IP_IGN_ALLOWED,
> - .lpm_modes = tgl_lpm_modes,
> + .lpm_num_maps = TGL_LPM_NUM_MAPS,
>   .lpm_en_offset = TGL_LPM_EN_OFFSET,
> + .lpm_priority_offset = TGL_LPM_PRI_OFFSET,
>   .lpm_residency_offset = TGL_LPM_RESIDENCY_OFFSET,
>   .lpm_sts = tgl_lpm_maps,
>   .lpm_status_offset = TGL_LPM_STATUS_OFFSET,
> @@ -1028,18 +1029,14 @@ DEFINE_SHOW_ATTRIBUTE(pmc_core_ltr);
>  static int pmc_core_substate_res_show(struct seq_file *s, void *unused)
>  {
>   struct pmc_dev *pmcdev = s->private;
> - const char **lpm_modes = pmcdev->map->lpm_modes;
>   u32 offset = pmcdev->map->lpm_residency_offset;
> - u32 lpm_en;
> - int index;
> + int i, mode;
>  
> - lpm_en = pmc_core_reg_read(pmcdev, pmcdev->map->lpm_en_offset);
> - seq_printf(s, "status substate residency\n");
> - for (index = 0; lpm_modes[index]; index++) {
> - seq_printf(s, "%7s %7s %-15u\n",
> -BIT(index) & lpm_en ? "Enabled" : " ",
> -lpm_modes[index], pmc_core_reg_read(pmcdev, offset));
> - offset += 4;
> + seq_printf(s, "%-10s %-15s\n", "Substate", "Residency");
> +
> + pmc_for_each_mode(i, mode, pmcdev) {
> + seq_printf(s, "%-10s %-15u\n", pmc_lpm_modes[mode],
> +pmc_core_reg_read(pmcdev, offset + (4 * mode)));
>   }
>  
>   return 0;
> @@ -1091,6 +1088,45 @@ static int pmc_core_pkgc_show(struct seq_file *s, void 
> *unused)
>  }
>  DEFINE_SHOW_ATTRIBUTE(pmc_core_pkgc);
>  
> +static void pmc_core_get_low_power_modes(struct pmc_dev *pmcdev)
> +{
> + u8 lpm_priority[LPM_MAX_NUM_MODES];
> + u32 lpm_en;
> + int mode, i, p;
> +
> + /* Use LPM Maps to indicate support for substates */
> + if (!pmcdev->map->lpm_num_maps)
> + return;
> +
> + lpm_en = pmc_core_reg_read(pmcdev, pmcdev->map->lpm_en_offset);
> + pmcdev->num_modes = hweight32(lpm_en);
> +
> + /* Each byte contains information for 2 modes (7:4 and 3:0) */
> + for (mode = 0; mode < LPM_MAX_NUM_MODES; mode += 2) {
> + u8 priority = pmc_core_reg_read_byte(pmcdev,
> + pmcdev->map->lpm_priority_offset + (mode / 2));
> + int pri0 = GENMASK(3, 0) & priority;
> + int pri1 = (GENMASK(7, 4) & priority) >> 4;
> +
> + lpm_priority[pri0] = mode;
> + lpm_priority[pri1] = mode + 1;
> + }
> +
> + /*
> +  * Loop though all modes from lowest to highest priority,
> +  * and capture all enabled modes in order
> +  */
> + i = 0;
> + for (p = LPM_MAX_NUM_MODES - 1; p >= 0; p--) {
> + int mode = lpm_priority[p];
> +
> + if (!(BIT(mode) & lpm_en))
> + continue;
> +
> + pmcdev->lpm_en_modes[i++] = mode;
> +

Re: [PATCH 2/9] platform/x86: intel_pmc_core: Remove global struct pmc_dev

[Hans de Goede]

Hi,

On 4/1/21 5:05 AM, David E. Box wrote:
> The intel_pmc_core driver did not always bind to a device which meant it
> lacked a struct device that could be used to maintain driver data. So a
> global instance of struct pmc_dev was used for this purpose and functions
> accessed this directly. Since the driver now binds to an ACPI device,
> remove the global pmc_dev in favor of one that is allocated during probe.
> Modify users of the global to obtain the object by argument instead.
> 
> Signed-off-by: David E. Box 

Thanks, patch looks good to me:

Reviewed-by: Hans de Goede 

Regards,

Hans

> ---
>  drivers/platform/x86/intel_pmc_core.c | 41 ++-
>  1 file changed, 21 insertions(+), 20 deletions(-)
> 
> diff --git a/drivers/platform/x86/intel_pmc_core.c 
> b/drivers/platform/x86/intel_pmc_core.c
> index 260d49dca1ad..5ca40fe3da59 100644
> --- a/drivers/platform/x86/intel_pmc_core.c
> +++ b/drivers/platform/x86/intel_pmc_core.c
> @@ -31,8 +31,6 @@
>  
>  #include "intel_pmc_core.h"
>  
> -static struct pmc_dev pmc;
> -
>  /* PKGC MSRs are common across Intel Core SoCs */
>  static const struct pmc_bit_map msr_map[] = {
>   {"Package C2",  MSR_PKG_C2_RESIDENCY},
> @@ -617,9 +615,8 @@ static int pmc_core_dev_state_get(void *data, u64 *val)
>  
>  DEFINE_DEBUGFS_ATTRIBUTE(pmc_core_dev_state, pmc_core_dev_state_get, NULL, 
> "%llu\n");
>  
> -static int pmc_core_check_read_lock_bit(void)
> +static int pmc_core_check_read_lock_bit(struct pmc_dev *pmcdev)
>  {
> - struct pmc_dev *pmcdev = 
>   u32 value;
>  
>   value = pmc_core_reg_read(pmcdev, pmcdev->map->pm_cfg_offset);
> @@ -744,28 +741,26 @@ static int pmc_core_ppfear_show(struct seq_file *s, 
> void *unused)
>  DEFINE_SHOW_ATTRIBUTE(pmc_core_ppfear);
>  
>  /* This function should return link status, 0 means ready */
> -static int pmc_core_mtpmc_link_status(void)
> +static int pmc_core_mtpmc_link_status(struct pmc_dev *pmcdev)
>  {
> - struct pmc_dev *pmcdev = 
>   u32 value;
>  
>   value = pmc_core_reg_read(pmcdev, SPT_PMC_PM_STS_OFFSET);
>   return value & BIT(SPT_PMC_MSG_FULL_STS_BIT);
>  }
>  
> -static int pmc_core_send_msg(u32 *addr_xram)
> +static int pmc_core_send_msg(struct pmc_dev *pmcdev, u32 *addr_xram)
>  {
> - struct pmc_dev *pmcdev = 
>   u32 dest;
>   int timeout;
>  
>   for (timeout = NUM_RETRIES; timeout > 0; timeout--) {
> - if (pmc_core_mtpmc_link_status() == 0)
> + if (pmc_core_mtpmc_link_status(pmcdev) == 0)
>   break;
>   msleep(5);
>   }
>  
> - if (timeout <= 0 && pmc_core_mtpmc_link_status())
> + if (timeout <= 0 && pmc_core_mtpmc_link_status(pmcdev))
>   return -EBUSY;
>  
>   dest = (*addr_xram & MTPMC_MASK) | (1U << 1);
> @@ -791,7 +786,7 @@ static int pmc_core_mphy_pg_show(struct seq_file *s, void 
> *unused)
>  
>   mutex_lock(>lock);
>  
> - if (pmc_core_send_msg(_core_reg_low) != 0) {
> + if (pmc_core_send_msg(pmcdev, _core_reg_low) != 0) {
>   err = -EBUSY;
>   goto out_unlock;
>   }
> @@ -799,7 +794,7 @@ static int pmc_core_mphy_pg_show(struct seq_file *s, void 
> *unused)
>   msleep(10);
>   val_low = pmc_core_reg_read(pmcdev, SPT_PMC_MFPMC_OFFSET);
>  
> - if (pmc_core_send_msg(_core_reg_high) != 0) {
> + if (pmc_core_send_msg(pmcdev, _core_reg_high) != 0) {
>   err = -EBUSY;
>   goto out_unlock;
>   }
> @@ -842,7 +837,7 @@ static int pmc_core_pll_show(struct seq_file *s, void 
> *unused)
>   mphy_common_reg  = (SPT_PMC_MPHY_COM_STS_0 << 16);
>   mutex_lock(>lock);
>  
> - if (pmc_core_send_msg(_common_reg) != 0) {
> + if (pmc_core_send_msg(pmcdev, _common_reg) != 0) {
>   err = -EBUSY;
>   goto out_unlock;
>   }
> @@ -863,9 +858,8 @@ static int pmc_core_pll_show(struct seq_file *s, void 
> *unused)
>  }
>  DEFINE_SHOW_ATTRIBUTE(pmc_core_pll);
>  
> -static int pmc_core_send_ltr_ignore(u32 value)
> +static int pmc_core_send_ltr_ignore(struct pmc_dev *pmcdev, u32 value)
>  {
> - struct pmc_dev *pmcdev = 
>   const struct pmc_reg_map *map = pmcdev->map;
>   u32 reg;
>   int err = 0;
> @@ -891,6 +885,8 @@ static ssize_t pmc_core_ltr_ignore_write(struct file 
> *file,
>const char __user *userbuf,
>size_t count, loff_t *ppos)
>  {
> + struct seq_file *s = file->private_data;
&

Re: [PATCH 1/9] platform/x86: intel_pmc_core: Don't use global pmcdev in quirks

[Hans de Goede]

Hi,

On 4/1/21 5:05 AM, David E. Box wrote:
> The DMI callbacks, used for quirks, currently access the PMC by getting
> the address a global pmc_dev struct. Instead, have the callbacks set a
> global quirk specific variable. In probe, after calling dmi_check_system(),
> pass pmc_dev to a function that will handle each quirk if its variable
> condition is met. This allows removing the global pmc_dev later.
> 
> Signed-off-by: David E. Box 

Thanks, patch looks good to me:

Reviewed-by: Hans de Goede 

Regards,

Hans


> ---
>  drivers/platform/x86/intel_pmc_core.c | 19 ---
>  1 file changed, 16 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/platform/x86/intel_pmc_core.c 
> b/drivers/platform/x86/intel_pmc_core.c
> index b5888aeb4bcf..260d49dca1ad 100644
> --- a/drivers/platform/x86/intel_pmc_core.c
> +++ b/drivers/platform/x86/intel_pmc_core.c
> @@ -1186,9 +1186,15 @@ static const struct pci_device_id pmc_pci_ids[] = {
>   * the platform BIOS enforces 24Mhz crystal to shutdown
>   * before PMC can assert SLP_S0#.
>   */
> +static bool xtal_ignore;
>  static int quirk_xtal_ignore(const struct dmi_system_id *id)
>  {
> - struct pmc_dev *pmcdev = 
> + xtal_ignore = true;
> + return 0;
> +}
> +
> +static void pmc_core_xtal_ignore(struct pmc_dev *pmcdev)
> +{
>   u32 value;
>  
>   value = pmc_core_reg_read(pmcdev, pmcdev->map->pm_vric1_offset);
> @@ -1197,7 +1203,6 @@ static int quirk_xtal_ignore(const struct dmi_system_id 
> *id)
>   /* Low Voltage Mode Enable */
>   value &= ~SPT_PMC_VRIC1_SLPS0LVEN;
>   pmc_core_reg_write(pmcdev, pmcdev->map->pm_vric1_offset, value);
> - return 0;
>  }
>  
>  static const struct dmi_system_id pmc_core_dmi_table[]  = {
> @@ -1212,6 +1217,14 @@ static const struct dmi_system_id pmc_core_dmi_table[] 
>  = {
>   {}
>  };
>  
> +static void pmc_core_do_dmi_quirks(struct pmc_dev *pmcdev)
> +{
> + dmi_check_system(pmc_core_dmi_table);
> +
> + if (xtal_ignore)
> + pmc_core_xtal_ignore(pmcdev);
> +}
> +
>  static int pmc_core_probe(struct platform_device *pdev)
>  {
>   static bool device_initialized;
> @@ -1253,7 +1266,7 @@ static int pmc_core_probe(struct platform_device *pdev)
>   mutex_init(>lock);
>   platform_set_drvdata(pdev, pmcdev);
>   pmcdev->pmc_xram_read_bit = pmc_core_check_read_lock_bit();
> - dmi_check_system(pmc_core_dmi_table);
> + pmc_core_do_dmi_quirks(pmcdev);
>  
>   /*
>* On TGL, due to a hardware limitation, the GBE LTR blocks PC10 when
> 

Re: [PATCH] platform/x86: ISST: Account for increased timeout in some cases

[Hans de Goede]

Hi,

On 3/31/21 12:08 AM, Srinivas Pandruvada wrote:
> In some cases when firmware is busy or updating, some mailbox commands
> still timeout on some newer CPUs. To fix this issue, change how we
> process timeout.
> 
> With this change, replaced timeout from using simple count with real
> timeout in micro-seconds using ktime. When the command response takes
> more than average processing time, yield to other tasks. The worst case
> timeout is extended upto 1 milli-second.
> 
> Signed-off-by: Srinivas Pandruvada 

Thank you for your patch, I've applied this patch to my review-hans 
branch:
https://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86.git/log/?h=review-hans

Note it will show up in my review-hans branch once I've pushed my
local branch there, which might take a while.

Once I've run some tests on this branch the patches there will be
added to the platform-drivers-x86/for-next branch and eventually
will be included in the pdx86 pull-request to Linus for the next
merge-window.

Regards,

Hans


> ---
>  .../intel_speed_select_if/isst_if_mbox_pci.c  | 33 +--
>  1 file changed, 23 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/platform/x86/intel_speed_select_if/isst_if_mbox_pci.c 
> b/drivers/platform/x86/intel_speed_select_if/isst_if_mbox_pci.c
> index a2a2d923e60c..df1fc6c719f3 100644
> --- a/drivers/platform/x86/intel_speed_select_if/isst_if_mbox_pci.c
> +++ b/drivers/platform/x86/intel_speed_select_if/isst_if_mbox_pci.c
> @@ -21,12 +21,16 @@
>  #define PUNIT_MAILBOX_BUSY_BIT   31
>  
>  /*
> - * The average time to complete some commands is about 40us. The current
> - * count is enough to satisfy 40us. But when the firmware is very busy, this
> - * causes timeout occasionally.  So increase to deal with some worst case
> - * scenarios. Most of the command still complete in few us.
> + * The average time to complete mailbox commands is less than 40us. Most of
> + * the commands complete in few micro seconds. But the same firmware handles
> + * requests from all power management features.
> + * We can create a scenario where we flood the firmware with requests then
> + * the mailbox response can be delayed for 100s of micro seconds. So define
> + * two timeouts. One for average case and one for long.
> + * If the firmware is taking more than average, just call cond_resched().
>   */
> -#define OS_MAILBOX_RETRY_COUNT   100
> +#define OS_MAILBOX_TIMEOUT_AVG_US40
> +#define OS_MAILBOX_TIMEOUT_MAX_US1000
>  
>  struct isst_if_device {
>   struct mutex mutex;
> @@ -35,11 +39,13 @@ struct isst_if_device {
>  static int isst_if_mbox_cmd(struct pci_dev *pdev,
>   struct isst_if_mbox_cmd *mbox_cmd)
>  {
> - u32 retries, data;
> + s64 tm_delta = 0;
> + ktime_t tm;
> + u32 data;
>   int ret;
>  
>   /* Poll for rb bit == 0 */
> - retries = OS_MAILBOX_RETRY_COUNT;
> + tm = ktime_get();
>   do {
>   ret = pci_read_config_dword(pdev, PUNIT_MAILBOX_INTERFACE,
>   );
> @@ -48,11 +54,14 @@ static int isst_if_mbox_cmd(struct pci_dev *pdev,
>  
>   if (data & BIT_ULL(PUNIT_MAILBOX_BUSY_BIT)) {
>   ret = -EBUSY;
> + tm_delta = ktime_us_delta(ktime_get(), tm);
> + if (tm_delta > OS_MAILBOX_TIMEOUT_AVG_US)
> + cond_resched();
>   continue;
>   }
>   ret = 0;
>   break;
> - } while (--retries);
> + } while (tm_delta < OS_MAILBOX_TIMEOUT_MAX_US);
>  
>   if (ret)
>   return ret;
> @@ -74,7 +83,8 @@ static int isst_if_mbox_cmd(struct pci_dev *pdev,
>   return ret;
>  
>   /* Poll for rb bit == 0 */
> - retries = OS_MAILBOX_RETRY_COUNT;
> + tm_delta = 0;
> + tm = ktime_get();
>   do {
>   ret = pci_read_config_dword(pdev, PUNIT_MAILBOX_INTERFACE,
>   );
> @@ -83,6 +93,9 @@ static int isst_if_mbox_cmd(struct pci_dev *pdev,
>  
>   if (data & BIT_ULL(PUNIT_MAILBOX_BUSY_BIT)) {
>   ret = -EBUSY;
> + tm_delta = ktime_us_delta(ktime_get(), tm);
> + if (tm_delta > OS_MAILBOX_TIMEOUT_AVG_US)
> + cond_resched();
>   continue;
>   }
>  
> @@ -96,7 +109,7 @@ static int isst_if_mbox_cmd(struct pci_dev *pdev,
>   mbox_cmd->resp_data = data;
>   ret = 0;
>   break;
> - } while (--retries);
> + } while (tm_delta < OS_MAILBOX_TIMEOUT_MAX_US);
>  
>   return ret;
>  }
> 

Re: [PATCH v3 0/4] add device drivers for Siemens Industrial PCs

[Hans de Goede]

Hi,

On 3/29/21 7:49 PM, Henning Schild wrote:
> changes since v2:
> 
> - remove "simatic-ipc" prefix from LED names
> - fix style issues found in v2, mainly LED driver
> - fix OEM specific dmi code, and remove magic numbers
> - more "simatic_ipc" name prefixing
> - improved pmc quirk code using callbacks
> 
> changes since v1:
> 
> - fixed lots of style issues found in v1
>   - (debug) printing
>   - header ordering
> - fixed license issues GPLv2 and SPDX in all files
> - module_platform_driver instead of __init __exit
> - wdt simplifications cleanup
> - lots of fixes in wdt driver, all that was found in v1
> - fixed dmi length in dmi helper
> - changed LED names to allowed ones
> - move led driver to simple/
> - switched pmc_atom to dmi callback with global variable
> 
> --
> 
> This series adds support for watchdogs and leds of several x86 devices
> from Siemens.
> 
> It is structured with a platform driver that mainly does identification
> of the machines. It might trigger loading of the actual device drivers
> by attaching devices to the platform bus.
> 
> The identification is vendor specific, parsing a special binary DMI
> entry. The implementation of that platform identification is applied on
> pmc_atom clock quirks in the final patch.
> 
> It is all structured in a way that we can easily add more devices and
> more platform drivers later. Internally we have some more code for
> hardware monitoring, more leds, watchdogs etc. This will follow some
> day.

IT seems there still is significant discussion surrounding the LED and watchdog
drivers which use patch 1/4 as parent-driver.

I'm going to hold of on merging 1/4 and 4/4 until there is more consensus
surrounding this series.

Regards,

Hans


> 
> Henning Schild (4):
>   platform/x86: simatic-ipc: add main driver for Siemens devices
>   leds: simatic-ipc-leds: add new driver for Siemens Industial PCs
>   watchdog: simatic-ipc-wdt: add new driver for Siemens Industrial PCs
>   platform/x86: pmc_atom: improve critclk_systems matching for Siemens
> PCs
> 
>  drivers/leds/Kconfig  |   3 +
>  drivers/leds/Makefile |   3 +
>  drivers/leds/simple/Kconfig   |  11 +
>  drivers/leds/simple/Makefile  |   2 +
>  drivers/leds/simple/simatic-ipc-leds.c| 202 
>  drivers/platform/x86/Kconfig  |  12 +
>  drivers/platform/x86/Makefile |   3 +
>  drivers/platform/x86/pmc_atom.c   |  57 +++--
>  drivers/platform/x86/simatic-ipc.c| 169 ++
>  drivers/watchdog/Kconfig  |  11 +
>  drivers/watchdog/Makefile |   1 +
>  drivers/watchdog/simatic-ipc-wdt.c| 215 ++
>  .../platform_data/x86/simatic-ipc-base.h  |  29 +++
>  include/linux/platform_data/x86/simatic-ipc.h |  72 ++
>  14 files changed, 769 insertions(+), 21 deletions(-)
>  create mode 100644 drivers/leds/simple/Kconfig
>  create mode 100644 drivers/leds/simple/Makefile
>  create mode 100644 drivers/leds/simple/simatic-ipc-leds.c
>  create mode 100644 drivers/platform/x86/simatic-ipc.c
>  create mode 100644 drivers/watchdog/simatic-ipc-wdt.c
>  create mode 100644 include/linux/platform_data/x86/simatic-ipc-base.h
>  create mode 100644 include/linux/platform_data/x86/simatic-ipc.h
> 

Re: [PATCH] platform/x86: panasonic-laptop: remove redundant assignment of variable result

[Hans de Goede]

Hi,

On 3/26/21 8:20 PM, Colin King wrote:
> From: Colin Ian King 
> 
> The variable result is being assigned a value that is never
> read and it is being updated later with a new value. The
> assignment is redundant and can be removed.
> 
> Addresses-Coverity: ("Unused value")
> Signed-off-by: Colin Ian King 

Thank you for your patch, I've applied this patch to my review-hans 
branch:
https://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86.git/log/?h=review-hans

Note it will show up in my review-hans branch once I've pushed my
local branch there, which might take a while.

Once I've run some tests on this branch the patches there will be
added to the platform-drivers-x86/for-next branch and eventually
will be included in the pdx86 pull-request to Linus for the next
merge-window.

Regards,

Hans



> ---
>  drivers/platform/x86/panasonic-laptop.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/platform/x86/panasonic-laptop.c 
> b/drivers/platform/x86/panasonic-laptop.c
> index 6388c3c705a6..d4f01496 100644
> --- a/drivers/platform/x86/panasonic-laptop.c
> +++ b/drivers/platform/x86/panasonic-laptop.c
> @@ -973,7 +973,7 @@ static int acpi_pcc_hotkey_add(struct acpi_device *device)
>   pcc->mute = pcc->sinf[SINF_MUTE];
>   pcc->ac_brightness = pcc->sinf[SINF_AC_CUR_BRIGHT];
>   pcc->dc_brightness = pcc->sinf[SINF_DC_CUR_BRIGHT];
> - result = pcc->current_brightness = pcc->sinf[SINF_CUR_BRIGHT];
> + pcc->current_brightness = pcc->sinf[SINF_CUR_BRIGHT];
>  
>   /* add sysfs attributes */
>   result = sysfs_create_group(>dev.kobj, _attr_group);
> 

Re: [PATCH] platform/surface: clean up a variable in surface_dtx_read()

[Hans de Goede]

Hi,

On 3/26/21 3:06 PM, Maximilian Luz wrote:
> On 3/26/21 1:28 PM, Dan Carpenter wrote:
>> The ">ddev->lock" and ">lock" are the same thing.  Let's
>> use ">lock" consistently.
>>
>> Signed-off-by: Dan Carpenter 
> 
> Good catch, thanks!
> 
> Reviewed-by: Maximilian Luz 

Thank you for the review, I've merged this now:

Thank you for your patch, I've applied this patch to my review-hans 
branch:
https://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86.git/log/?h=review-hans

Note it will show up in my review-hans branch once I've pushed my
local branch there, which might take a while.

Once I've run some tests on this branch the patches there will be
added to the platform-drivers-x86/for-next branch and eventually
will be included in the pdx86 pull-request to Linus for the next
merge-window.

Regards,

Hans



> 
>> ---
>>   drivers/platform/surface/surface_dtx.c | 2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/platform/surface/surface_dtx.c 
>> b/drivers/platform/surface/surface_dtx.c
>> index 1fedacf74050..63ce587e79e3 100644
>> --- a/drivers/platform/surface/surface_dtx.c
>> +++ b/drivers/platform/surface/surface_dtx.c
>> @@ -487,7 +487,7 @@ static ssize_t surface_dtx_read(struct file *file, char 
>> __user *buf, size_t coun
>>   if (status < 0)
>>   return status;
>>   -    if (down_read_killable(>ddev->lock))
>> +    if (down_read_killable(>lock))
>>   return -ERESTARTSYS;
>>     /* Need to check that we're not shut down again. */
>>
> 

Re: [PATCH v3] platform/x86: asus-wmi: Add param to turn fn-lock mode on by default

[Hans de Goede]

Hi,

On 3/23/21 10:01 PM, Luca Stefani wrote:
> * On recent ZenBooks the fn-lock is disabled
>   by default on boot while running Windows.
> 
> * Add a module param ( fnlock_default ) that allows
>   changing the default at probe time
> > Signed-off-by: Luca Stefani 

Thank you for your patch, I've applied this patch to my review-hans 
branch:
https://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86.git/log/?h=review-hans

Note it will show up in my review-hans branch once I've pushed my
local branch there, which might take a while.

Once I've run some tests on this branch the patches there will be
added to the platform-drivers-x86/for-next branch and eventually
will be included in the pdx86 pull-request to Linus for the next
merge-window.

Regards,

Hans



> ---
>  drivers/platform/x86/asus-wmi.c | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/platform/x86/asus-wmi.c b/drivers/platform/x86/asus-wmi.c
> index 9ca15f724343..ebaeb7bb80f5 100644
> --- a/drivers/platform/x86/asus-wmi.c
> +++ b/drivers/platform/x86/asus-wmi.c
> @@ -47,6 +47,9 @@ MODULE_AUTHOR("Corentin Chary , "
>  MODULE_DESCRIPTION("Asus Generic WMI Driver");
>  MODULE_LICENSE("GPL");
>  
> +static bool fnlock_default = true;
> +module_param(fnlock_default, bool, 0444);
> +
>  #define to_asus_wmi_driver(pdrv) \
>   (container_of((pdrv), struct asus_wmi_driver, platform_driver))
>  
> @@ -2673,7 +2676,7 @@ static int asus_wmi_add(struct platform_device *pdev)
>   err = asus_wmi_set_devstate(ASUS_WMI_DEVID_BACKLIGHT, 2, NULL);
>  
>   if (asus_wmi_has_fnlock_key(asus)) {
> - asus->fnlock_locked = true;
> + asus->fnlock_locked = fnlock_default;
>   asus_wmi_fnlock_update(asus);
>   }
>  
> 

[GIT PULL] platform-drivers-x86 for 5.12-3

[Hans de Goede]

Hi Linus,

Here is a single bugfix (on top of platform-drivers-x86-v5.12-2) to fix
spurious wakeups from suspend caused by recent intel-hid driver changes.

Regards,

Hans


The following changes since commit d1635448f1105e549b4041aab930dbc6945fc635:

  platform/x86: intel_pmc_core: Ignore GBE LTR on Tiger Lake platforms 
(2021-03-23 21:50:14 +0100)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86.git 
tags/platform-drivers-x86-v5.12-3

for you to fetch changes up to a3790a8a94fc0234c5d38013b48e74ef221ec84c:

  platform/x86: intel-hid: Fix spurious wakeups caused by tablet-mode events 
during suspend (2021-04-06 22:10:21 +0200)


platform-drivers-x86 for v5.12-3

A single bugfix (on top of platform-drivers-x86-v5.12-2) to fix spurious
wakeups from suspend caused by recent intel-hid driver changes.

The following is an automated git shortlog grouped by driver:

intel-hid:
 -  Fix spurious wakeups caused by tablet-mode events during suspend


Hans de Goede (1):
  platform/x86: intel-hid: Fix spurious wakeups caused by tablet-mode 
events during suspend

 drivers/platform/x86/intel-hid.c | 16 +---
 1 file changed, 9 insertions(+), 7 deletions(-)

Re: [PATCH v4] platform/x86: intel_pmc_core: export platform global_reset via sysfs.

[Hans de Goede]

Hi,

On 4/7/21 11:31 AM, Winkler, Tomas wrote:
> 
> 
>> Hi,
>>
>> On 4/7/21 8:51 AM, Winkler, Tomas wrote:
>
> During PCH (platform/board) manufacturing process a global reset has
> to be induced in order for configuration changes take the effect
> upon following platform reset.
> This setting was commonly done by accessing PMC registers via
> /dev/mem but due to security concern /dev/mem access is much
> restricted, hence the reason for exposing this setting via dedicated sysfs
>> interface.
> To prevent post manufacturing abuse the register is protected by
> hardware locking.

 The purpose of this reset functionality is not entirely clear to me.

 Is this only used during production of a board? Or is this also
 something which a user/reseller may use as part of a factory-reset
>> procedure?
>>>
>>> Board production and refurbishing of the board. I can try to rephrase but I
>> thought all the info is in the commit message.
>>> As a runtime feature a user can check that her/his platform is correctly
>> sealed.
>>
>> Manufacturing is clear, refurbishing is very much not clear, do you mean
>> actually desoldering the chip and replacing it with a new one ?
>>
 If this is only used once during production, then I'm not sure if
 introducing a sysfs file for this is desirable.
>>>
>>> What do you suggest, than?  I'm just guessing is where are you heading
>>> so the answer is that the manufacturing is often already run on the
>> production OS installation,  w/o going into details swapping or reconfiguring
>> the OS is not always an option.
>>> The manufacturer is also a user of ours.
>>
>> Ok, so lets compromise here, please make use of the visibility sysfs 
>> attribute
>> callback, which returns a umask and make the file read-only at the umask
>> level if it has been sealed, to make it clear to users that they cannot 
>> write to
>> it, the -EACCES error means 'Permission denied' so if the user is already 
>> root
>> they are going to get mightily confused if ls -l shows the file is writable.
> Okay, it seems a better solution if the file is the global reset,  
> but maybe this path should not be taken if we rename it to  
> extended_test_mode_register3, than it's better to get EACCESS on a specific 
> bit.

Ack, I was thinking about this perhaps not being the best option if we
expose more bits myself too (when I wrote the rest of my email).

Still it might be an idea to do this if all bits which we allow setting
are locked ?  Note this is just a suggestion / something to consider,
I think that if we rename the file to extended_test_mode_register3
most of my concerns are solved.

I'm still not entirely happy with the -EACCESS though, can you perhaps do a
dev_err_ratelimited() in that case, logging why the EACCESS is happening?

As I said before, returning EACCESS when the file-mode bits say the file is
writable and the user is root will lead to some head-scratching I'm afraid.
Another option would be to pick another errno value. Although even with
another errno value a dev_err_ratelimited() logging the reason of the
failure is probably a good idea.

>> Also on set you are checking that the written value is bit 20, and on show 
>> you
>> are showing the contents of the "Extended Test Mode Register 3" in hex, or
>> at least those bits you are willing to show.
> 
> The intention was to left the user space behave same as with direct register 
> access (/dev/mem)

Ack, that is fine.

>> So in essence what you are doing here is giving userspace (some) access to
>> the "Extended Test Mode Register 3", I would prefer to spell that out
>> explicitly. The global_reset sysfs file name to me too much hints at 
>> something
>> which the user can trigger / use while it is not intended for user usage.
> 
> Yeah, Global reset is maybe too ambiguous name in a general context, this is 
> not the standard platform reset. 

Ack.

> I've left it in register form in order to keep the user space as it has 
> access to the register (/dev/mem)
>>
>> Also the Documentation/ABI/testing/sysfs-platform-intel-pm file pretty much
>> describes this as direct register access rather then as some reset mechanism.
>>
>> So I think it would be better to call the new file
>> extended_test_mode_register3, this will also be useful if we need to provide
>> access to other bits in the same register later; and this will be a good
>> template to follow if we need to provide some access to other registers later
>> too.
> 
> Need to sync with David on that he pointed just ow, that he plans to expose 
> some more bits. 

Ok, I assume I'll eventually see a new version appear.

Regards,

Hans





 Can you please provide a new version where the purpsoe of the newly
 introduced sysfs file is made more clear, both in the commit-msg as
 well as in
 the:
>>> Okay I can do that.

 Documentation/ABI/testing/sysfs-platform-intel-pmc

 File ?

 Regards,

 

Re: [PATCH v4] platform/x86: intel_pmc_core: export platform global_reset via sysfs.

[Hans de Goede]

Hi,

On 4/7/21 8:51 AM, Winkler, Tomas wrote:
>>>
>>> During PCH (platform/board) manufacturing process a global reset has
>>> to be induced in order for configuration changes take the effect upon
>>> following platform reset.
>>> This setting was commonly done by accessing PMC registers via /dev/mem
>>> but due to security concern /dev/mem access is much restricted, hence
>>> the reason for exposing this setting via dedicated sysfs interface.
>>> To prevent post manufacturing abuse the register is protected by
>>> hardware locking.
>>
>> The purpose of this reset functionality is not entirely clear to me.
>>
>> Is this only used during production of a board? Or is this also something
>> which a user/reseller may use as part of a factory-reset procedure?
> 
> Board production and refurbishing of the board. I can try to rephrase but I 
> thought all the info is in the commit message. 
> As a runtime feature a user can check that her/his platform is correctly 
> sealed. 

Manufacturing is clear, refurbishing is very much not clear, do you mean
actually desoldering the chip and replacing it with a new one ?

>> If this is only used once during production, then I'm not sure if 
>> introducing a
>> sysfs file for this is desirable.
> 
> What do you suggest, than?  I'm just guessing is where are you heading so the 
> answer is that the manufacturing
> is often already run on the production OS installation,  w/o going into 
> details swapping or reconfiguring the OS is not always an option.
> The manufacturer is also a user of ours.

Ok, so lets compromise here, please make use of the visibility sysfs attribute
callback, which returns a umask and make the file read-only at the umask level
if it has been sealed, to make it clear to users that they cannot write to it,
the -EACCES error means 'Permission denied' so if the user is already root
they are going to get mightily confused if ls -l shows the file is writable.

Also on set you are checking that the written value is bit 20, and on
show you are showing the contents of the "Extended Test Mode Register 3" in hex,
or at least those bits you are willing to show.

So in essence what you are doing here is giving userspace (some) access
to the "Extended Test Mode Register 3", I would prefer to spell that out
explicitly. The global_reset sysfs file name to me too much hints at
something which the user can trigger / use while it is not intended for
user usage.

Also the Documentation/ABI/testing/sysfs-platform-intel-pm file pretty much
describes this as direct register access rather then as some reset mechanism.

So I think it would be better to call the new file extended_test_mode_register3,
this will also be useful if we need to provide access to other bits in the
same register later; and this will be a good template to follow if we need to
provide some access to other registers later too.

Regards,

Hans



> 
>>
>> Can you please provide a new version where the purpsoe of the newly
>> introduced sysfs file is made more clear, both in the commit-msg as well as 
>> in
>> the:
> Okay I can do that.
>>
>> Documentation/ABI/testing/sysfs-platform-intel-pmc
>>
>> File ?
>>
>> Regards,
>>
>> Hans
>>
>>
>>
>>>
>>> The register in MMIO space is defined for Cannon Lake and newer PCHs.
>>>
>>> Cc: David E Box 
>>> Reviewed-by: Andy Shevchenko 
>>> Signed-off-by: Tamar Mashiah 
>>> Signed-off-by: Tomas Winkler 
>>> ---
>>> 2:
>>> 1. Add locking for reading the ET3 register  (Andy) 2. Fix few style
>>> issues (Andy)
>>> V3:
>>> 1. Resend
>>> v4:
>>> 1. Fix return statement (Andy)
>>> 2. Specify manufacturing process (Enrico)
>>>
>>>  .../ABI/testing/sysfs-platform-intel-pmc  | 11 +++
>>>  MAINTAINERS   |  1 +
>>>  drivers/platform/x86/intel_pmc_core.c | 97 +++
>>>  drivers/platform/x86/intel_pmc_core.h |  6 ++
>>>  4 files changed, 115 insertions(+)
>>>  create mode 100644 Documentation/ABI/testing/sysfs-platform-intel-pmc
>>>
>>> diff --git a/Documentation/ABI/testing/sysfs-platform-intel-pmc
>>> b/Documentation/ABI/testing/sysfs-platform-intel-pmc
>>> new file mode 100644
>>> index ..7ce00e77fbcd
>>> --- /dev/null
>>> +++ b/Documentation/ABI/testing/sysfs-platform-intel-pmc
>>> @@ -0,0 +1,11 @@
>>> +What:  /sys/devices/platform//global_reset
>>> +Date:  Apr 2021
>>> +KernelVersion: 5.13
>>> +Contact:   "Tomas Winkler" 
>>> +Description:
>>> +   Display global reset setting bits for PMC.
>>> +   * bit 31 - global reset is locked
>>> +   * bit 20 - global reset is set
>>> +   Writing bit 20 value to the global_reset will induce
>>> +   a platform global reset upon consequent platform reset.
>>> +   in case the register is not locked.
>>> diff --git a/MAINTAINERS b/MAINTAINERS index
>>> 04f68e0cda64..618676eba8c8 100644
>>> --- a/MAINTAINERS
>>> +++ b/MAINTAINERS
>>> @@ -9166,6 +9166,7 @@ M:Rajneesh 

Re: [PATCH 06/12] platform/x86: intel_cht_int33fe_microb: Constify the software node

[Hans de Goede]

Hi,

On 4/6/21 9:40 PM, Wolfram Sang wrote:
> 
>> What is the plan for merging this patch / this series ?
> 
> I'll take the series via I2C.

Ok, that works for me.

Regards,

Hans

Re: [PATCH v4] platform/x86: intel_pmc_core: export platform global_reset via sysfs.

[Hans de Goede]

Hi,

On 4/2/21 5:21 PM, Tomas Winkler wrote:
> From: Tamar Mashiah 
> 
> During PCH (platform/board) manufacturing process a global reset
> has to be induced in order for configuration changes take the effect
> upon following platform reset.
> This setting was commonly done by accessing PMC registers via /dev/mem
> but due to security concern /dev/mem access is much restricted, hence
> the reason for exposing this setting via dedicated sysfs interface.
> To prevent post manufacturing abuse the register is protected
> by hardware locking.

The purpose of this reset functionality is not entirely clear to me.

Is this only used during production of a board? Or is this also something
which a user/reseller may use as part of a factory-reset procedure?

If this is only used once during production, then I'm not sure if
introducing a sysfs file for this is desirable.

Can you please provide a new version where the purpsoe of the newly
introduced sysfs file is made more clear, both in the commit-msg
as well as in the:

Documentation/ABI/testing/sysfs-platform-intel-pmc

File ?

Regards,

Hans



> 
> The register in MMIO space is defined for Cannon Lake and newer PCHs.
> 
> Cc: David E Box 
> Reviewed-by: Andy Shevchenko 
> Signed-off-by: Tamar Mashiah 
> Signed-off-by: Tomas Winkler 
> ---
> 2:
> 1. Add locking for reading the ET3 register  (Andy)
> 2. Fix few style issues (Andy)
> V3:
> 1. Resend
> v4:
> 1. Fix return statement (Andy) 
> 2. Specify manufacturing process (Enrico)
> 
>  .../ABI/testing/sysfs-platform-intel-pmc  | 11 +++
>  MAINTAINERS   |  1 +
>  drivers/platform/x86/intel_pmc_core.c | 97 +++
>  drivers/platform/x86/intel_pmc_core.h |  6 ++
>  4 files changed, 115 insertions(+)
>  create mode 100644 Documentation/ABI/testing/sysfs-platform-intel-pmc
> 
> diff --git a/Documentation/ABI/testing/sysfs-platform-intel-pmc 
> b/Documentation/ABI/testing/sysfs-platform-intel-pmc
> new file mode 100644
> index ..7ce00e77fbcd
> --- /dev/null
> +++ b/Documentation/ABI/testing/sysfs-platform-intel-pmc
> @@ -0,0 +1,11 @@
> +What:/sys/devices/platform//global_reset
> +Date:Apr 2021
> +KernelVersion:   5.13
> +Contact: "Tomas Winkler" 
> +Description:
> + Display global reset setting bits for PMC.
> + * bit 31 - global reset is locked
> + * bit 20 - global reset is set
> + Writing bit 20 value to the global_reset will induce
> + a platform global reset upon consequent platform reset.
> + in case the register is not locked.
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 04f68e0cda64..618676eba8c8 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -9166,6 +9166,7 @@ M:  Rajneesh Bhardwaj 
>  M:   David E Box 
>  L:   platform-driver-...@vger.kernel.org
>  S:   Maintained
> +F:   Documentation/ABI/testing/sysfs-platform-intel-pmc
>  F:   drivers/platform/x86/intel_pmc_core*
>  
>  INTEL PMIC GPIO DRIVERS
> diff --git a/drivers/platform/x86/intel_pmc_core.c 
> b/drivers/platform/x86/intel_pmc_core.c
> index ee2f757515b0..8afc198550a4 100644
> --- a/drivers/platform/x86/intel_pmc_core.c
> +++ b/drivers/platform/x86/intel_pmc_core.c
> @@ -401,6 +401,7 @@ static const struct pmc_reg_map cnp_reg_map = {
>   .pm_cfg_offset = CNP_PMC_PM_CFG_OFFSET,
>   .pm_read_disable_bit = CNP_PMC_READ_DISABLE_BIT,
>   .ltr_ignore_max = CNP_NUM_IP_IGN_ALLOWED,
> + .etr3_offset = ETR3_OFFSET,
>  };
>  
>  static const struct pmc_reg_map icl_reg_map = {
> @@ -418,6 +419,7 @@ static const struct pmc_reg_map icl_reg_map = {
>   .pm_cfg_offset = CNP_PMC_PM_CFG_OFFSET,
>   .pm_read_disable_bit = CNP_PMC_READ_DISABLE_BIT,
>   .ltr_ignore_max = ICL_NUM_IP_IGN_ALLOWED,
> + .etr3_offset = ETR3_OFFSET,
>  };
>  
>  static const struct pmc_bit_map tgl_clocksource_status_map[] = {
> @@ -585,6 +587,7 @@ static const struct pmc_reg_map tgl_reg_map = {
>   .lpm_sts = tgl_lpm_maps,
>   .lpm_status_offset = TGL_LPM_STATUS_OFFSET,
>   .lpm_live_status_offset = TGL_LPM_LIVE_STATUS_OFFSET,
> + .etr3_offset = ETR3_OFFSET,
>  };
>  
>  static inline u32 pmc_core_reg_read(struct pmc_dev *pmcdev, int reg_offset)
> @@ -603,6 +606,99 @@ static inline u64 pmc_core_adjust_slp_s0_step(struct 
> pmc_dev *pmcdev, u32 value)
>   return (u64)value * pmcdev->map->slp_s0_res_counter_step;
>  }
>  
> +static int set_global_reset(struct pmc_dev *pmcdev)
> +{
> + const struct pmc_reg_map *map = pmcdev->map;
> + u32 reg;
> + int err;
> +
> + if (!map->etr3_offset)
> + return -EOPNOTSUPP;
> +
> + mutex_lock(>lock);
> +
> + /* check if CF9 is locked */
> + reg = pmc_core_reg_read(pmcdev, map->etr3_offset);
> + if (reg & ETR3_CF9LOCK) {
> + err = -EACCES;
> + goto out_unlock;
> + }
> +
> + /* write CF9 global reset bit */
> + reg |= 

Re: [External] Re: [PATCH 31/32] Documentation: update sysfs-platform_profile.rst reference

[Hans de Goede]

Hi,

On 4/1/21 5:07 PM, Mark Pearson wrote:
> 
> 
> On 01/04/2021 09:49, Hans de Goede wrote:
>> Hi,
>>
>> On 4/1/21 2:17 PM, Mauro Carvalho Chehab wrote:
>>> The file name: Documentation/ABI/testing/sysfs-platform_profile.rst
>>> should be, instead: Documentation/userspace-api/sysfs-platform_profile.rst.
>>>
>>> Update its cross-reference accordingly.
>>>
>>> Fixes: a2ff95e018f1 ("ACPI: platform: Add platform profile support")
>>> Fixes: 8e0cbf356377 ("Documentation: Add documentation for new 
>>> platform_profile sysfs attribute")
>>> Signed-off-by: Mauro Carvalho Chehab 
>>
>> Thanks, patch looks good to me:
>>
>> Reviewed-by: Hans de Goede 
>>
>> Rafael, I assume you will merge this through your tree?
>>
>> Regards,
>>
>> Hans
>>
> Looks good to me too - though I'd missed the fact the file had moved
> somehow :)
> 
> Not sure if my reviewed tag has any value but if it's useful:
> Reviewed-by: Mark Pearson 
> 
> Just for my education - how do things get moved from testing to
> somewhere else, is there a decision process etc?

I'm not sure how things work with the new Documentation/userspace-api/
dir, but with the old Documentation/ABI/testing dir things used to go
like this (AFAICT):

1) A new sysfs API bindings starts in Documentation/ABI/testing
2) This sysfs API bindings then stays in Documentation/ABI/testing forever

And if the bindings were actually in use by userspace then they were being
treated as immutable / unbreakable API anyways so the testing prefix
had very little meaning really.

Which I guess may well be the reason why new the new place no
longer has a testing prefix.

Regards,

Hans



>>> ---
>>>  include/linux/platform_profile.h | 2 +-
>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/include/linux/platform_profile.h 
>>> b/include/linux/platform_profile.h
>>> index a6329003aee7..e5cbb6841f3a 100644
>>> --- a/include/linux/platform_profile.h
>>> +++ b/include/linux/platform_profile.h
>>> @@ -2,7 +2,7 @@
>>>  /*
>>>   * Platform profile sysfs interface
>>>   *
>>> - * See Documentation/ABI/testing/sysfs-platform_profile.rst for more
>>> + * See Documentation/userspace-api/sysfs-platform_profile.rst for more
>>>   * information.
>>>   */
>>>  
>>>
>>
> 

Re: [PATCH 31/32] Documentation: update sysfs-platform_profile.rst reference

[Hans de Goede]

Hi,

On 4/1/21 2:17 PM, Mauro Carvalho Chehab wrote:
> The file name: Documentation/ABI/testing/sysfs-platform_profile.rst
> should be, instead: Documentation/userspace-api/sysfs-platform_profile.rst.
> 
> Update its cross-reference accordingly.
> 
> Fixes: a2ff95e018f1 ("ACPI: platform: Add platform profile support")
> Fixes: 8e0cbf356377 ("Documentation: Add documentation for new 
> platform_profile sysfs attribute")
> Signed-off-by: Mauro Carvalho Chehab 

Thanks, patch looks good to me:

Reviewed-by: Hans de Goede 

Rafael, I assume you will merge this through your tree?

Regards,

Hans

> ---
>  include/linux/platform_profile.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/include/linux/platform_profile.h 
> b/include/linux/platform_profile.h
> index a6329003aee7..e5cbb6841f3a 100644
> --- a/include/linux/platform_profile.h
> +++ b/include/linux/platform_profile.h
> @@ -2,7 +2,7 @@
>  /*
>   * Platform profile sysfs interface
>   *
> - * See Documentation/ABI/testing/sysfs-platform_profile.rst for more
> + * See Documentation/userspace-api/sysfs-platform_profile.rst for more
>   * information.
>   */
>  
> 

Re: [PATCH 11/11] [RFC] drm/i915/dp: fix array overflow warning

[Hans de Goede]

Hi,

On 3/22/21 5:02 PM, Arnd Bergmann wrote:
> From: Arnd Bergmann 
> 
> gcc-11 warns that intel_dp_check_mst_status() has a local array of
> fourteen bytes and passes the last four bytes into a function that
> expects a six-byte array:
> 
> drivers/gpu/drm/i915/display/intel_dp.c: In function 
> ‘intel_dp_check_mst_status’:
> drivers/gpu/drm/i915/display/intel_dp.c:4556:22: error: 
> ‘drm_dp_channel_eq_ok’ reading 6 bytes from a region of size 4 
> [-Werror=stringop-overread]
>  4556 | !drm_dp_channel_eq_ok([10], 
> intel_dp->lane_count)) {
>   |  
> ^~~~
> drivers/gpu/drm/i915/display/intel_dp.c:4556:22: note: referencing argument 1 
> of type ‘const u8 *’ {aka ‘const unsigned char *’}
> In file included from drivers/gpu/drm/i915/display/intel_dp.c:38:
> include/drm/drm_dp_helper.h:1459:6: note: in a call to function 
> ‘drm_dp_channel_eq_ok’
>  1459 | bool drm_dp_channel_eq_ok(const u8 link_status[DP_LINK_STATUS_SIZE],
>   |  ^~~~
> 
> Clearly something is wrong here, but I can't quite figure out what.
> Changing the array size to 16 bytes avoids the warning, but is
> probably the wrong solution here.

The drm displayport-helpers indeed expect a 6 bytes buffer, but they
usually only consume 4 bytes.

I don't think that changing the DP_DPRX_ESI_LEN is a good fix here,
since it is used in multiple places, but the esi array already gets
zero-ed out by its initializer, so we can just pass 2 extra 0 bytes
to give drm_dp_channel_eq_ok() call the 6 byte buffer its prototype
specifies by doing this:

diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
b/drivers/gpu/drm/i915/display/intel_dp.c
index 897711d9d7d3..147962d4ad06 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -4538,7 +4538,11 @@ intel_dp_check_mst_status(struct intel_dp *intel_dp)
drm_WARN_ON_ONCE(>drm, intel_dp->active_mst_links < 0);
 
for (;;) {
-   u8 esi[DP_DPRX_ESI_LEN] = {};
+   /*
+* drm_dp_channel_eq_ok() expects a 6 byte large buffer, but
+* the ESI info only contains 4 bytes, pass 2 extra 0 bytes.
+*/
+   u8 esi[DP_DPRX_ESI_LEN + 2] = {};
bool handled;
int retry;
 

So i915 devs, would such a fix be acceptable ?

Regards,

Hans






> 
> Signed-off-by: Arnd Bergmann 
> ---
>  drivers/gpu/drm/i915/display/intel_dp.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index 8c12d5375607..830e2515f119 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -65,7 +65,7 @@
>  #include "intel_vdsc.h"
>  #include "intel_vrr.h"
>  
> -#define DP_DPRX_ESI_LEN 14
> +#define DP_DPRX_ESI_LEN 16
>  
>  /* DP DSC throughput values used for slice count calculations KPixels/s */
>  #define DP_DSC_PEAK_PIXEL_RATE   272
> 

Re: [PATCH 00/10] platform/x86: toshiba_acpi: move acpi add/remove to device-managed routines

[Hans de Goede]

Hi,

On 3/30/21 11:22 AM, Alexandru Ardelean wrote:
> On Tue, Mar 30, 2021 at 11:21 AM Hans de Goede  wrote:
>>
>> Hi Alexadru, Jonathan,
>>
>> On 3/24/21 1:55 PM, Alexandru Ardelean wrote:
>>> This changeset tries to do a conversion of the toshiba_acpi driver to use
>>> only device-managed routines. The driver registers as a singleton, so no
>>> more than one device can be registered at a time.
>>>
>>> My main intent here is to try to convert the iio_device_alloc() and
>>> iio_device_register() to their devm_ variants.
>>>
>>> Usually, when converting a registration call to device-managed variant, the
>>> init order must be preserved. And the deregistration order must be a mirror
>>> of the registration (in reverse order).
>>>
>>> This change tries to do that, by using devm_ variants where available and
>>> devm_add_action_or_reset() where this isn't possible.
>>> Some deregistration ordering is changed, because it wasn't exactly
>>> mirroring (in reverse) the init order.
>>>
>>> For the IIO subsystem, the toshiba_acpi driver is the only user of
>>> iio_device_alloc(). If this changeset is accepted (after discussion), I
>>> will propose to remove the iio_device_alloc() function.
>>>
>>> While I admit this may look like an overzealous effort to use devm_
>>> everywhere (in IIO at least), for me it's a fun/interesting excercise.
>>
>> Alexadru, thank you for the patches.
>>
>> Jonathan, thank you for the reviews.
>>
>> To be honest I'm currently inclined to not accept / merge these patches,
>> this is based on 2 assumptions from me, which might be wrong. let me explain.
>>
>> If I understand things correctly, the main reason for this rework of
>> the toshiba_acpi code is to move iio_device_alloc() and iio_device_register()
>> to their devm_ variants, converting the last users in the tree ?
> 
> yes
> well, we still have plenty of users iio_device_alloc() /
> iio_device_register() inside drivers/iio
> 
> but the toshipa_acpi driver is the more quirky user of these functions
> [treewide]
> 
> i wanted to jump on those simpler IIO cases, but i thought i would
> leave those to new contributors [for a while];
> the complexity of those conversions is good enough to get some people
> started to contribute changes that are a bit more useful than
> checkpatch fixes, comment fixes [etc];
> 
> [personally] i feel that these devm_ conversions are complex enough to
> maybe get people wanting to dig more into some kernel design stuff

I like how you think about onboarding new people.

>> This would allow these 2 iio functions to then be e.g. marked as static /
>> private helpers inside the iio core, so that all new users can only use
>> the devm_ versions. But if I'm reading Jonathan's reaction correctly then
>> Jonathan is not planning to do that because they might still be useful
>> in some cases.
>>
>> Jonathan have I correctly understood that you don't plan to make any
>> changes to the iio_device_alloc() and iio_device_register() functions
>> even if this gets merged ?
>>
>> Which brings me to my next assumption, Alexandru, I don't read anything
>> about testing anywhere. So I'm currently under the assumption that
>> you don't have any hardware using the toshiba_acpi driver and that this
>> is thus untested ?
> 
> yes, i don't have any hw to test this
> 
>>
>> The not being tested state is my main reason for not wanting to merge
>> this. The toshiba_acpi driver likely does not have a whole lot of users,
>> so the chances of someone running release candidates or even just the
>> latest kernels on hardware which uses it are small.  This means that if
>> we accidentally introduce a bug with this series it might not get caught
>> until say lots of people start upgrading to Ubuntu 22.04 which is
>> the first Ubuntu kernel with your changes; and then at least one of the
>> hit users needs to have the skills to find us and get in contact about that.
>>
>> TL;DR: we might break stuff and if we do it might be a long time until we
>> find out we did and then we have been shipping broken code for ages...
> 
> ack
> well, i don't insist in pushing this series;

Ok, lets park this series then for now, because IMHO it is just a tad
too complex to merge without it being tested (and without another
important reason like it being part of some larger cleanup / refactoring).

Regards,

Hans




>>> Alexandru Ardelean (10):
>>>   platform/x86: toshiba_acpi: bind life-time of toshiba_acpi_dev to
>&g

Re: [PATCH 00/10] platform/x86: toshiba_acpi: move acpi add/remove to device-managed routines

[Hans de Goede]

Hi Alexadru, Jonathan,

On 3/24/21 1:55 PM, Alexandru Ardelean wrote:
> This changeset tries to do a conversion of the toshiba_acpi driver to use
> only device-managed routines. The driver registers as a singleton, so no
> more than one device can be registered at a time.
> 
> My main intent here is to try to convert the iio_device_alloc() and
> iio_device_register() to their devm_ variants.
> 
> Usually, when converting a registration call to device-managed variant, the
> init order must be preserved. And the deregistration order must be a mirror
> of the registration (in reverse order).
> 
> This change tries to do that, by using devm_ variants where available and
> devm_add_action_or_reset() where this isn't possible.
> Some deregistration ordering is changed, because it wasn't exactly
> mirroring (in reverse) the init order.
> 
> For the IIO subsystem, the toshiba_acpi driver is the only user of
> iio_device_alloc(). If this changeset is accepted (after discussion), I
> will propose to remove the iio_device_alloc() function.
> 
> While I admit this may look like an overzealous effort to use devm_
> everywhere (in IIO at least), for me it's a fun/interesting excercise.

Alexadru, thank you for the patches.

Jonathan, thank you for the reviews.

To be honest I'm currently inclined to not accept / merge these patches,
this is based on 2 assumptions from me, which might be wrong. let me explain.

If I understand things correctly, the main reason for this rework of
the toshiba_acpi code is to move iio_device_alloc() and iio_device_register()
to their devm_ variants, converting the last users in the tree ?

This would allow these 2 iio functions to then be e.g. marked as static /
private helpers inside the iio core, so that all new users can only use
the devm_ versions. But if I'm reading Jonathan's reaction correctly then
Jonathan is not planning to do that because they might still be useful
in some cases.

Jonathan have I correctly understood that you don't plan to make any
changes to the iio_device_alloc() and iio_device_register() functions
even if this gets merged ?

Which brings me to my next assumption, Alexandru, I don't read anything
about testing anywhere. So I'm currently under the assumption that
you don't have any hardware using the toshiba_acpi driver and that this
is thus untested ?

The not being tested state is my main reason for not wanting to merge
this. The toshiba_acpi driver likely does not have a whole lot of users,
so the chances of someone running release candidates or even just the
latest kernels on hardware which uses it are small.  This means that if
we accidentally introduce a bug with this series it might not get caught
until say lots of people start upgrading to Ubuntu 22.04 which is
the first Ubuntu kernel with your changes; and then at least one of the
hit users needs to have the skills to find us and get in contact about that.

TL;DR: we might break stuff and if we do it might be a long time until we
find out we did and then we have been shipping broken code for ages...

Regards,

Hans





> 
> Alexandru Ardelean (10):
>   platform/x86: toshiba_acpi: bind life-time of toshiba_acpi_dev to
> parent
>   platform/x86: toshiba_acpi: use devm_add_action_or_reset() for
> singleton clear
>   platform/x86: toshiba_acpi: bind registration of miscdev object to
> parent
>   platform/x86: toshiba_acpi: use device-managed functions for input
> device
>   platform/x86: toshiba_acpi: register backlight with device-managed
> variant
>   platform/x86: toshiba_acpi: use devm_led_classdev_register() for LEDs
>   platform/x86: toshiba_acpi: use device-managed functions for
> accelerometer
>   platform/x86: toshiba_acpi: use device-managed for wwan_rfkill
> management
>   platform/x86: toshiba_acpi: use device-managed for sysfs removal
>   platform/x86: toshiba_acpi: bind proc entries creation to parent
> 
>  drivers/platform/x86/toshiba_acpi.c | 249 +---
>  1 file changed, 150 insertions(+), 99 deletions(-)
> 

Re: [PATCH 07/12] i2c: cht-wc: Constify the software node

[Hans de Goede]

Hi,

On 3/29/21 12:50 PM, Heikki Krogerus wrote:
> Additional device properties are always just a part of a
> software fwnode. If the device properties are constant, the
> software node can also be constant.
> 
> Signed-off-by: Heikki Krogerus 
> Cc: Hans de Goede 

Thanks, patch looks good to me:

Reviewed-by: Hans de Goede 

Regards,

Hans


> ---
>  drivers/i2c/busses/i2c-cht-wc.c | 6 +-
>  1 file changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/i2c/busses/i2c-cht-wc.c b/drivers/i2c/busses/i2c-cht-wc.c
> index f80d79e973cd2..08f491ea21ac9 100644
> --- a/drivers/i2c/busses/i2c-cht-wc.c
> +++ b/drivers/i2c/busses/i2c-cht-wc.c
> @@ -280,6 +280,10 @@ static const struct property_entry bq24190_props[] = {
>   { }
>  };
>  
> +static const struct software_node bq24190_node = {
> + .properties = bq24190_props,
> +};
> +
>  static struct regulator_consumer_supply fusb302_consumer = {
>   .supply = "vbus",
>   /* Must match fusb302 dev_name in intel_cht_int33fe.c */
> @@ -308,7 +312,7 @@ static int cht_wc_i2c_adap_i2c_probe(struct 
> platform_device *pdev)
>   .type = "bq24190",
>   .addr = 0x6b,
>   .dev_name = "bq24190",
> - .properties = bq24190_props,
> + .swnode = _node,
>   .platform_data = _pdata,
>   };
>   int ret, reg, irq;
> 

Re: [PATCH 06/12] platform/x86: intel_cht_int33fe_microb: Constify the software node

[Hans de Goede]

Hi,

On 3/29/21 12:50 PM, Heikki Krogerus wrote:
> Additional device properties are always just a part of a
> software fwnode. If the device properties are constant, the
> software node can also be constant.
> 
> Signed-off-by: Heikki Krogerus 
> Cc: Hans de Goede 

Thanks, patch looks good to me:

Reviewed-by: Hans de Goede 

What is the plan for merging this patch / this series ?

Regards,

Hans


> ---
>  drivers/platform/x86/intel_cht_int33fe_microb.c | 6 +-
>  1 file changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/platform/x86/intel_cht_int33fe_microb.c 
> b/drivers/platform/x86/intel_cht_int33fe_microb.c
> index 20b11e0d9a758..673f41cd14b52 100644
> --- a/drivers/platform/x86/intel_cht_int33fe_microb.c
> +++ b/drivers/platform/x86/intel_cht_int33fe_microb.c
> @@ -35,6 +35,10 @@ static const struct property_entry bq27xxx_props[] = {
>   { }
>  };
>  
> +static const struct software_node bq27xxx_node = {
> + .properties = bq27xxx_props,
> +};
> +
>  int cht_int33fe_microb_probe(struct cht_int33fe_data *data)
>  {
>   struct device *dev = data->dev;
> @@ -43,7 +47,7 @@ int cht_int33fe_microb_probe(struct cht_int33fe_data *data)
>   memset(_info, 0, sizeof(board_info));
>   strscpy(board_info.type, "bq27542", ARRAY_SIZE(board_info.type));
>   board_info.dev_name = "bq27542";
> - board_info.properties = bq27xxx_props;
> + board_info.swnode = _node;
>   data->battery_fg = i2c_acpi_new_device(dev, 1, _info);
>  
>   return PTR_ERR_OR_ZERO(data->battery_fg);
> 

Re: [PATCH] iio: accel: da280: Drop unnecessarily used braces

[Hans de Goede]

Hi,

On 3/29/21 12:52 PM, Andy Shevchenko wrote:
> +Cc: Hans (just for your opinion)
> 
> On Sun, Mar 28, 2021 at 10:40 PM Andy Shevchenko
>  wrote:
>> On Sunday, March 28, 2021, Mugilraj Dhavachelvan  
>> wrote:
>>>
>>> As per linux kernel coding style braces are not needed for single
>>> statement.
>>> Checkpatch
>>> warning: braces {} are not necessary for any arm of this statement
>>> 128: FILE: drivers/iio/accel/da280.c:128:
>>>
>>
>> While it’s the correct patch, I would rather recommend making the driver 
>> non-ACPI centric. I.e.:
>> - replace that custom function by device_get_match_data() call
>>
>> - replace that condition by something like
>> type = device_get_match_data();
>>
>> - drop ACPI_PTR()
>>
>> - replace acpi.h by mod_devicetable.h and property.h
>>
>> - convert to use ->probe_new()
>>
>>
>>  Everything, except the last one is in one patch, the last one is another 
>> patch.

I agree that *carefully* converting to driver to device_get_match_data() would 
be good.

Regards,

Hans


>>
>>
>>
>>> Signed-off-by: Mugilraj Dhavachelvan 
>>> ---
>>>  drivers/iio/accel/da280.c | 5 ++---
>>>  1 file changed, 2 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/drivers/iio/accel/da280.c b/drivers/iio/accel/da280.c
>>> index 227bea2d738b..31f290ae4386 100644
>>> --- a/drivers/iio/accel/da280.c
>>> +++ b/drivers/iio/accel/da280.c
>>> @@ -125,11 +125,10 @@ static int da280_probe(struct i2c_client *client,
>>> indio_dev->modes = INDIO_DIRECT_MODE;
>>> indio_dev->channels = da280_channels;
>>>
>>> -   if (ACPI_HANDLE(>dev)) {
>>> +   if (ACPI_HANDLE(>dev))
>>> chip = da280_match_acpi_device(>dev);
>>> -   } else {
>>> +   else
>>> chip = id->driver_data;
>>> -   }
>>>
>>> if (chip == da226) {
>>> indio_dev->name = "da226";
> 

Re: [PATCH v2 1/4] platform/x86: simatic-ipc: add main driver for Siemens devices

[Hans de Goede]

Hi,

On 3/26/21 10:55 AM, Henning Schild wrote:
> Am Thu, 18 Mar 2021 12:45:01 +0100
> schrieb Hans de Goede :
> 
>> Hi,
>>
>> On 3/18/21 12:30 PM, Enrico Weigelt, metux IT consult wrote:
>>> On 17.03.21 21:03, Hans de Goede wrote:
>>>
>>> Hi,
>>>   
>>>>> It just identifies the box and tells subsequent drivers which one
>>>>> it is, which watchdog and LED path to take. Moving the knowledge
>>>>> of which box has which LED/watchdog into the respective drivers
>>>>> seems to be the better way to go.
>>>>>
>>>>> So we would end up with a LED and a watchdog driver both
>>>>> MODULE_ALIAS("dmi:*:svnSIEMENSAG:*");  
>>>
>>> Uh, isn't that a bit too broad ? This basically implies that Siemens
>>> will never produce boards with different configurations.  
>>
>> There is a further check done in probe() based on some Siemens
>> specific DMI table entries.
>>
>>>>> and doing the identification with the inline dmi from that header,
>>>>> doing p2sb with the support to come ... possibly a
>>>>> "//TODO\ninline" in the meantime.
>>>>>
>>>>> So no "main platform" driver anymore, but still central platform
>>>>> headers.
>>>>>
>>>>> Not sure how this sounds, but i think making that change should be
>>>>> possible. And that is what i will try and go for in v3.  
>>>>
>>>> Dropping the main drivers/platform/x86 driver sounds good to me,
>>>> I was already wondering a bit about its function since it just
>>>> instantiates devs to which the other ones bind to then instantiate
>>>> more devs (in the LED case).  
>>>
>>> hmm, IMHO that depends on whether the individual sub-devices can be
>>> more generic than just that specific machine. (@Hanning: could you
>>> tell us more about that ?).
>>>
>>> Another question is how they're actually probed .. only dmi or maybe
>>> also pci dev ? (i've seen some refs to pci stuff in the led driver,
>>> but missed the other code thats called here).
>>>
>>> IMHO, if the whole thing lives on some PCI device (which can be
>>> probed via pci ID), and that device has the knowledge, where the
>>> LED registers actually are (eg. based on device ID, pci mmio
>>> mapping, ...) then there should be some parent driver that
>>> instantiates the led devices (and possibly other board specific
>>> stuff). That would be a clear separation, modularization. In that
>>> case, maybe this LED driver could even be replaced by some really
>>> generic "register-based-LED" driver, which just needs to be fed
>>> with some parameters like register ranges, bitmasks, etc.
>>>
>>> OTOH, if everything can be derived entirely from DMI match, w/o
>>> things like pci mappings involved (IOW: behaves like directly wired
>>> to the cpu's mem/io bus, no other "intelligent" bus involved), and
>>> it's all really board specific logic (no generic led or gpio
>>> controllers involved), then it might be better to have entirely
>>> separate drivers.  
> 
> In fact it does dmi and not "common" but unfortunately vendor-specific.
> On top it does pci, so it might be fair to call it "intelligent" and
> keep it.
> 
>> FWIW I'm fine with either solution, and if we go the "parent driver"
>> route I'm happy to have that driver sit in drivers/platform/x86
>> (once all the discussions surrounding this are resolved).
>>
>> My reply was because I noticed that the Led driver seemed to sort of
>> also act as a parent driver (last time I looked) and instantiated
>> a bunch of stuff, so then we have 2 parent(ish) drivers. If things
>> stay that way then having 2 levels of parent drivers seems a bit too
>> much to me, esp. if it can all be done cleanly in e.g. the LED driver.
> 
> One "leds" driver doing multiple leds seems to be a common pattern. So
> that "1 parent N children" maybe does not count as parentish.
> 
>> But as said I'm fine either way as long as the code is reasonably
>> clean and dealing with this sort of platform specific warts happens
>> a lot in drivers/platform/x86 .
> 
> I thought about it again and also prefer the "parent driver" idea as it
> is. That parent identifies the machine and depending on it, causes
> device drivers to be loaded. At the moment LED and watchdog, but with
> nvram, hwmon to come.
> 
> I will stick with "platform" instead of "mfd" because it is really a
> machine having multiple devices. Not a device having multiple functions.

Ok, sticking with the current separate "platform" parent driver design
is fine by me.

Regards,

Hans

Re: [PATCH v4 2/2] ASoC: rt715:add micmute led state control supports

[Hans de Goede]

Hi,

On 3/25/21 3:11 PM, Yuan, Perry wrote:
> Hi Hans
> 
>> -Original Message-----
>> From: Hans de Goede 
>> Sent: Monday, March 22, 2021 11:02 PM
>> To: Jaroslav Kysela; Yuan, Perry; Mark Brown; pierre-
>> louis.boss...@linux.intel.com; Limonciello, Mario
>> Cc: po...@protonmail.com; oder_ch...@realtek.com; ti...@suse.com;
>> mgr...@linux.intel.com; lgirdw...@gmail.com; alsa-de...@alsa-project.org;
>> linux-kernel@vger.kernel.org; platform-driver-...@vger.kernel.org
>> Subject: Re: [PATCH v4 2/2] ASoC: rt715:add micmute led state control
>> supports
>>
>>
>> [EXTERNAL EMAIL]
>>
>> Hi,
>>
>> On 3/22/21 3:37 PM, Jaroslav Kysela wrote:
>>> Dne 22. 03. 21 v 10:25 Yuan, Perry napsal(a):
>>>> Hi Mark:
>>>>
>>>>> -Original Message-
>>>>> From: Mark Brown 
>>>>> Sent: Tuesday, March 9, 2021 1:24 AM
>>>>> To: Yuan, Perry
>>>>> Cc: po...@protonmail.com; pierre-louis.boss...@linux.intel.com;
>>>>> oder_ch...@realtek.com; pe...@perex.cz; ti...@suse.com;
>>>>> hdego...@redhat.com; mgr...@linux.intel.com; Limonciello, Mario;
>>>>> lgirdw...@gmail.com; alsa-de...@alsa-project.org; linux-
>>>>> ker...@vger.kernel.org; platform-driver-...@vger.kernel.org
>>>>> Subject: Re: [PATCH v4 2/2] ASoC: rt715:add micmute led state
>>>>> control supports
>>>>>
>>>>> On Mon, Mar 01, 2021 at 05:38:34PM +0800, Perry Yuan wrote:
>>>>>
>>>>>> +/* Micmute LED state changed by muted/unmute switch */
>>>>>> +if (mc->invert) {
>>>>>> +if (ucontrol->value.integer.value[0] || ucontrol-
>>>>>> value.integer.value[1]) {
>>>>>> +micmute_led = LED_OFF;
>>>>>> +} else {
>>>>>> +micmute_led = LED_ON;
>>>>>> +}
>>>>>> +ledtrig_audio_set(LED_AUDIO_MICMUTE, micmute_led);
>>>>>> +}
>>>>>
>>>>> These conditionals on inversion seem weird and counterintuitive.  If
>>>>> we're going with this approach it would probably be clearer to
>>>>> define a custom operation for the affected controls that wraps the
>>>>> standard one and adds the LED setting rather than keying off invert like
>> this.
>>>>
>>>> Currently the sof soundwire driver has no generic led control yet.
>>>> This patch can handle the led control needs for MIC mute LED, definitely
>> the patch is a short term solution.
>>>> There is a feature request discussion when we started to implement this
>> solution.
>>>> https://github.com/thesofproject/linux/issues/2496#issuecomment-
>> 71389
>>>> 2620
>>>>
>>>> The workable way for now is that we put the LED mute control to the
>> codec driver.
>>>> When there is new and full sound LED solution implemented, this part will
>> be also optimized.
>>>> The Hardware privacy feature needs this patch to handle the Mic mute led
>> state change.
>>>> Before that full solution ready in kernel, could we take this as short term
>> solution?
>>>
>>> Perry, it's about the machine detection. Your code is too much generic
>>> even for the top-level LED trigger implementation. We need an extra
>>> check, if the proper LED's are really controlled on the specific
>>> hardware. Other hardware may use RT715 for a different purpose. Use
>>> DMI / ACPI checks to detect this hardware and don't misuse the inversion
>> flag to enable this code.
>>
>> I think this would be a goo candidate for the new generic LED handling:
>>
>> https://lore.kernel.org/alsa-devel/20210317172945.842280-1-
>> pe...@perex.cz/
>>
>> And then use a udev-rule + hwdb and/or UCM profiles to configure the LED
>> trigger for specific models from userspace ?
>>
>> Regards,
>>
>> Hans
>>
>>
>>
> Because the SOF SDW design has no mic mute led control yet.
> So I add one short term solution to make Dell privacy working for now 
> Definitely , that is new solution I can add my patch on that to test as one 
> user case .
> We really need to take the short term solution work for some system which 
> support new SOF soundwire hardware which have  dependence on the MIC mute 
> feature
> Meanwhile we can continue working on the new  "udev-rule + hwdb and/or UCM 
> profiles" solution as to replace this one.
> If we agree that, I will submit another V6 addressing new feedback. 

The triggering of the LED trigger and the code registering the led_classdev
are in 2 separate subsystems; and should be merged separately.

If you post a new version of patch 1/2 addressing my review remarks then
I can merge that.

For merging the sound side of this you need to talk to the sound folks
(Jaroslav Kysela, Takashi Iwai, Mark Brown for files under sound/soc).

Regards,

Hans

Re: [PATCH v5 1/2] platform/x86: dell-privacy: Add support for Dell hardware privacy

[Hans de Goede]

Hi,

On 3/25/21 8:52 AM, Yuan, Perry wrote:
> Hi Hans.
> 
>> -Original Message-----
>> From: Hans de Goede 
>> Sent: Wednesday, March 24, 2021 3:40 AM
>> To: Pierre-Louis Bossart; Yuan, Perry; po...@protonmail.com;
>> oder_ch...@realtek.com; pe...@perex.cz; ti...@suse.com;
>> mgr...@linux.intel.com; Limonciello, Mario
>> Cc: alsa-de...@alsa-project.org; linux-kernel@vger.kernel.org;
>> lgirdw...@gmail.com; platform-driver-...@vger.kernel.org;
>> broo...@kernel.org
>> Subject: Re: [PATCH v5 1/2] platform/x86: dell-privacy: Add support for Dell
>> hardware privacy
>>
>>
>> [EXTERNAL EMAIL]
>>
>> Hi,
>>
>> On 3/23/21 7:57 PM, Pierre-Louis Bossart wrote:
>>> Minor comments below.
>>
>> >
>>>> +int __init dell_privacy_acpi_init(void)
>>>
>>> is the __init necessary? You call this routine from another which already 
>>> has
>> this qualifier.
>>
>> Yes this is necessary, all functions which are only used during module_load /
>> from the module's init function must be marked as __init so that the kernel
>> can unload them after module loading is done.
>>
>> I do wonder if this one should not be static though (I've not looked at this
>> patch in detail yet).
>>
>>>
>>>> +{
>>>> +    int err;
>>>> +    struct platform_device *pdev;
>>>> +
>>>> +    if (!wmi_has_guid(DELL_PRIVACY_GUID))
>>>> +    return -ENODEV;
>>>> +
>>>> +    privacy_acpi = kzalloc(sizeof(*privacy_acpi), GFP_KERNEL);
>>>> +    if (!privacy_acpi)
>>>> +    return -ENOMEM;
>>>> +
>>>> +    err = platform_driver_register(_privacy_platform_drv);
>>>> +    if (err)
>>>> +    goto pdrv_err;
>>>> +
>>>> +    pdev = platform_device_register_simple(
>>>> +    PRIVACY_PLATFORM_NAME, PLATFORM_DEVID_NONE, NULL, 0);
>>>> +    if (IS_ERR(pdev)) {
>>>> +    err = PTR_ERR(pdev);
>>>> +    goto pdev_err;
>>>> +    }
>>>> +
>>>> +    return 0;
>>>> +
>>>> +pdev_err:
>>>> +    platform_device_unregister(pdev);
>>>> +pdrv_err:
>>>> +    kfree(privacy_acpi);
>>>> +    return err;
>>>> +}
>>>> +
>>>> +void __exit dell_privacy_acpi_exit(void)
>>>
>>> is the __exit required here?
>>
>> Idem. Also static ?
>>
>> Regards,
>>
>> Hans
>>
> 
> If adding static to the function,  I will be worried about that the init and 
> exit cannot be called by another file .

That is right, which is why I added the "?".

But this is no longer relevant after my detailed review of the patch,
so lets discuss things further in the detailed review email-thread.

Regards,

Hans

[GIT PULL] platform-drivers-x86 for 5.12-2

[Hans de Goede]

Hi Linus,

Here is a set of bug-fixes and some model specific quirks for 
platform-drivers-x86 for 5.12.

Regards,

Hans


The following changes since commit a38fd8748464831584a19438cbb3082b5a2dab15:

  Linux 5.12-rc2 (2021-03-05 17:33:41 -0800)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86.git 
tags/platform-drivers-x86-v5.12-2

for you to fetch changes up to d1635448f1105e549b4041aab930dbc6945fc635:

  platform/x86: intel_pmc_core: Ignore GBE LTR on Tiger Lake platforms 
(2021-03-23 21:50:14 +0100)


platform-drivers-x86 for v5.12-2

Summary:
 - dell-wmi-sysman: A set of probe-error-exit-handling fixes to fix some systems
   which advertise the WMI GUIDs, but are not compatible, not booting
 - intel-vbtn/intel-hid: Misc. bugfixes
 - intel_pmc: Bug-fixes + a quirk to lower suspend power-consumption on Tiger 
Lake
 - thinkpad_acpi: Misc. bugfixes

The following is an automated git shortlog grouped by driver:

dell-wmi-sysman:
 -  Cleanup create_attributes_level_sysfs_files()
 -  Make sysman_init() return -ENODEV of the interfaces are not found
 -  Cleanup sysman_init() error-exit handling
 -  Fix release_attributes_data() getting called twice on 
init_bios_attributes() failure
 -  Make it safe to call exit_foo_attributes() multiple times
 -  Fix possible NULL pointer deref on exit
 -  Fix crash caused by calling kset_unregister twice

intel-hid:
 -  Support Lenovo ThinkPad X1 Tablet Gen 2

intel-vbtn:
 -  Stop reporting SW_DOCK events

intel_pmc_core:
 -  Ignore GBE LTR on Tiger Lake platforms
 -  Update Kconfig

intel_pmt_class:
 -  Initial resource to 0

intel_pmt_crashlog:
 -  Fix incorrect macros

thinkpad_acpi:
 -  Disable DYTC CQL mode around switching to balanced mode
 -  Allow the FnLock LED to change state
 -  check dytc version for lapmode sysfs


Alban Bedel (1):
  platform/x86: intel-hid: Support Lenovo ThinkPad X1 Tablet Gen 2

David E. Box (4):
  platform/x86: intel_pmt_class: Initial resource to 0
  platform/x86: intel_pmt_crashlog: Fix incorrect macros
  platform/x86: intel_pmc_core: Update Kconfig
  platform/x86: intel_pmc_core: Ignore GBE LTR on Tiger Lake platforms

Esteve Varela Colominas (1):
  platform/x86: thinkpad_acpi: Allow the FnLock LED to change state

Hans de Goede (9):
  platform/x86: thinkpad_acpi: Disable DYTC CQL mode around switching to 
balanced mode
  platform/x86: dell-wmi-sysman: Fix crash caused by calling 
kset_unregister twice
  platform/x86: dell-wmi-sysman: Fix possible NULL pointer deref on exit
  platform/x86: dell-wmi-sysman: Make it safe to call exit_foo_attributes() 
multiple times
  platform/x86: dell-wmi-sysman: Fix release_attributes_data() getting 
called twice on init_bios_attributes() failure
  platform/x86: dell-wmi-sysman: Cleanup sysman_init() error-exit handling
  platform/x86: dell-wmi-sysman: Make sysman_init() return -ENODEV of the 
interfaces are not found
  platform/x86: dell-wmi-sysman: Cleanup 
create_attributes_level_sysfs_files()
  platform/x86: intel-vbtn: Stop reporting SW_DOCK events

Mark Pearson (1):
  platform/x86: thinkpad_acpi: check dytc version for lapmode sysfs

 drivers/platform/x86/Kconfig   |  11 ++-
 .../x86/dell/dell-wmi-sysman/enum-attributes.c |   3 +
 .../x86/dell/dell-wmi-sysman/int-attributes.c  |   3 +
 .../x86/dell/dell-wmi-sysman/passobj-attributes.c  |   3 +
 .../x86/dell/dell-wmi-sysman/string-attributes.c   |   3 +
 drivers/platform/x86/dell/dell-wmi-sysman/sysman.c |  84 ++--
 drivers/platform/x86/intel-hid.c   |   7 ++
 drivers/platform/x86/intel-vbtn.c  |  12 ++-
 drivers/platform/x86/intel_pmc_core.c  |  50 +++---
 drivers/platform/x86/intel_pmt_class.c |   2 +-
 drivers/platform/x86/intel_pmt_crashlog.c  |  13 ++-
 drivers/platform/x86/thinkpad_acpi.c   | 108 +++--
 12 files changed, 190 insertions(+), 109 deletions(-)

Re: [PATCH v5 1/2] platform/x86: dell-privacy: Add support for Dell hardware privacy

[Hans de Goede]

Hi,

On 3/24/21 12:19 PM, Hans de Goede wrote:
> Hi,
> 
> On 3/22/21 10:38 AM, Perry Yuan wrote:
>> From: Perry Yuan 
>>
>> add support for Dell privacy driver for the Dell units equipped
>> hardware privacy design, which protect users privacy of audio and
>> camera from hardware level. Once the audio or camera privacy mode
>> activated, any applications will not get any audio or video stream
>> when user pressed ctrl+F4 hotkey, audio privacy mode will be
>> enabled, micmute led will be also changed accordingly
>> The micmute led is fully controlled by hardware & EC(embedded controller)
>> and camera mute hotkey is Ctrl+F9. Currently design only emmits
>> SW_CAMERA_LENS_COVER event while the camera lens shutter will be
>> changed by EC & hw(hadware) control
>>
>> *The flow is like this:
>> 1) User presses key. HW does stuff with this key (timeout timer is started)
>> 2) WMI event is emitted from BIOS to kernel
>> 3) WMI event is received by dell-privacy
>> 4) KEY_MICMUTE emitted from dell-privacy
>> 5) Userland picks up key and modifies kcontrol for SW mute
>> 6) Codec kernel driver catches and calls ledtrig_audio_set, like this:
>>  ledtrig_audio_set(LED_AUDIO_MICMUTE,
>>  rt715->micmute_led ? LED_ON :LED_OFF);
>> 7) If "LED" is set to on dell-privacy notifies EC,
>>  and timeout is cancelled, HW mic mute activated.
>>
>> Signed-off-by: Perry Yuan 

One last remark, I think that the dell_privacy_present() function which
I suggested in my review should be renamed to:

dell_privacy_has_micmute() and then its return should check the micmute
feature bit in priv->features_present and this new function should then
be used in dell-laptop.c to determine it dell-laptop.c should register
its own mic-mute led_classdev.

This way if a theoretical future laptop shows up where the micmute feature
is not implemented by the privacy interface dell-laptop.c will still
register the non-privacy mic-mute led_classdev.

Regards,

Hans




>> ---
>> v4 -> v5:
>> * addressed feedback from Randy Dunlap
>> * addressed feedback from Pierre-Louis Bossart
>> * rebase to latest 5.12 rc4 upstream kernel
>> * fix some space alignment problem
>> v3 -> v4:
>> * fix format for Kconfig
>> * add sysfs document
>> * add flow comments to the privacy wmi/acpi driver
>> * addressed feedback from Barnabás Pőcze[Thanks very much]
>> * export privacy_valid to make the global state simpler to query
>> * fix one issue which will block the dell-laptop driver to load when
>>   privacy driver invalid
>> * addressed feedback from Pierre-Louis Bossart,remove the EC ID match
>> v2 -> v3:
>> * add sysfs attributes doc
>> v1 -> v2:
>> * query EC handle from EC driver directly.
>> * fix some code style.
>> * add KEY_END to keymap array.
>> * clean platform device when cleanup called
>> * use hexadecimal format for log print in dev_dbg
>> * remove __set_bit for the report keys from probe.
>> * fix keymap leak
>> * add err_free_keymap in dell_privacy_wmi_probe
>> * wmi driver will be unregistered if privacy_acpi_init() fails
>> * add sysfs attribute files for user space query.
>> * add leds micmute driver to privacy acpi
>> * add more design info the commit info
>> ---
>> ---
>>  .../testing/sysfs-platform-dell-privacy-wmi   |  32 ++
>>  drivers/platform/x86/dell/Kconfig |  16 +
>>  drivers/platform/x86/dell/Makefile|   3 +
>>  drivers/platform/x86/dell/dell-laptop.c   |  23 +-
>>  drivers/platform/x86/dell/dell-privacy-acpi.c | 164 +
>>  drivers/platform/x86/dell/dell-privacy-wmi.c  | 340 ++
>>  drivers/platform/x86/dell/dell-privacy-wmi.h  |  35 ++
>>  drivers/platform/x86/dell/dell-wmi.c  |  27 +-
>>  8 files changed, 627 insertions(+), 13 deletions(-)
>>  create mode 100644 Documentation/ABI/testing/sysfs-platform-dell-privacy-wmi
>>  create mode 100644 drivers/platform/x86/dell/dell-privacy-acpi.c
>>  create mode 100644 drivers/platform/x86/dell/dell-privacy-wmi.c
>>  create mode 100644 drivers/platform/x86/dell/dell-privacy-wmi.h
>>
>> diff --git a/Documentation/ABI/testing/sysfs-platform-dell-privacy-wmi 
>> b/Documentation/ABI/testing/sysfs-platform-dell-privacy-wmi
>> new file mode 100644
>> index ..20c15a51ec38
>> --- /dev/null
>> +++ b/Documentation/ABI/testing/sysfs-platform-dell-privacy-wmi
>> @@ -0,0 +1,32 @@
>> +What:   
>> /sys/bus/wmi/devices/6932965F-1671-4CEB-B988-D3AB0A901919/devices_supported
>> +Date:   

Re: [PATCH v5 1/2] platform/x86: dell-privacy: Add support for Dell hardware privacy

[Hans de Goede]

Hi,

On 3/22/21 10:38 AM, Perry Yuan wrote:
> From: Perry Yuan 
> 
> add support for Dell privacy driver for the Dell units equipped
> hardware privacy design, which protect users privacy of audio and
> camera from hardware level. Once the audio or camera privacy mode
> activated, any applications will not get any audio or video stream
> when user pressed ctrl+F4 hotkey, audio privacy mode will be
> enabled, micmute led will be also changed accordingly
> The micmute led is fully controlled by hardware & EC(embedded controller)
> and camera mute hotkey is Ctrl+F9. Currently design only emmits
> SW_CAMERA_LENS_COVER event while the camera lens shutter will be
> changed by EC & hw(hadware) control
> 
> *The flow is like this:
> 1) User presses key. HW does stuff with this key (timeout timer is started)
> 2) WMI event is emitted from BIOS to kernel
> 3) WMI event is received by dell-privacy
> 4) KEY_MICMUTE emitted from dell-privacy
> 5) Userland picks up key and modifies kcontrol for SW mute
> 6) Codec kernel driver catches and calls ledtrig_audio_set, like this:
>   ledtrig_audio_set(LED_AUDIO_MICMUTE,
>   rt715->micmute_led ? LED_ON :LED_OFF);
> 7) If "LED" is set to on dell-privacy notifies EC,
>   and timeout is cancelled, HW mic mute activated.
> 
> Signed-off-by: Perry Yuan 
> ---
> v4 -> v5:
> * addressed feedback from Randy Dunlap
> * addressed feedback from Pierre-Louis Bossart
> * rebase to latest 5.12 rc4 upstream kernel
> * fix some space alignment problem
> v3 -> v4:
> * fix format for Kconfig
> * add sysfs document
> * add flow comments to the privacy wmi/acpi driver
> * addressed feedback from Barnabás Pőcze[Thanks very much]
> * export privacy_valid to make the global state simpler to query
> * fix one issue which will block the dell-laptop driver to load when
>   privacy driver invalid
> * addressed feedback from Pierre-Louis Bossart,remove the EC ID match
> v2 -> v3:
> * add sysfs attributes doc
> v1 -> v2:
> * query EC handle from EC driver directly.
> * fix some code style.
> * add KEY_END to keymap array.
> * clean platform device when cleanup called
> * use hexadecimal format for log print in dev_dbg
> * remove __set_bit for the report keys from probe.
> * fix keymap leak
> * add err_free_keymap in dell_privacy_wmi_probe
> * wmi driver will be unregistered if privacy_acpi_init() fails
> * add sysfs attribute files for user space query.
> * add leds micmute driver to privacy acpi
> * add more design info the commit info
> ---
> ---
>  .../testing/sysfs-platform-dell-privacy-wmi   |  32 ++
>  drivers/platform/x86/dell/Kconfig |  16 +
>  drivers/platform/x86/dell/Makefile|   3 +
>  drivers/platform/x86/dell/dell-laptop.c   |  23 +-
>  drivers/platform/x86/dell/dell-privacy-acpi.c | 164 +
>  drivers/platform/x86/dell/dell-privacy-wmi.c  | 340 ++
>  drivers/platform/x86/dell/dell-privacy-wmi.h  |  35 ++
>  drivers/platform/x86/dell/dell-wmi.c  |  27 +-
>  8 files changed, 627 insertions(+), 13 deletions(-)
>  create mode 100644 Documentation/ABI/testing/sysfs-platform-dell-privacy-wmi
>  create mode 100644 drivers/platform/x86/dell/dell-privacy-acpi.c
>  create mode 100644 drivers/platform/x86/dell/dell-privacy-wmi.c
>  create mode 100644 drivers/platform/x86/dell/dell-privacy-wmi.h
> 
> diff --git a/Documentation/ABI/testing/sysfs-platform-dell-privacy-wmi 
> b/Documentation/ABI/testing/sysfs-platform-dell-privacy-wmi
> new file mode 100644
> index ..20c15a51ec38
> --- /dev/null
> +++ b/Documentation/ABI/testing/sysfs-platform-dell-privacy-wmi
> @@ -0,0 +1,32 @@
> +What:
> /sys/bus/wmi/devices/6932965F-1671-4CEB-B988-D3AB0A901919/devices_supported
> +Date:Feb 2021
> +KernelVersion:   5.12
> +Contact: "perry.y...@dell.com>"
> +Description:
> + Display which dell hardware level privacy devices are supported
> + “Dell Privacy” is a set of HW, FW, and SW features to enhance
> + Dell’s commitment to platform privacy for MIC, Camera, and
> + ePrivacy screens.
> + The supported hardware privacy devices are:
> + - 0 = Not Supported
> + - 1 = Supported
> + - Bit0 -> Microphone
> + - Bit1 -> Camera
> + - Bit2 -> ePrivacy Screen
> +
> +What:
> /sys/bus/wmi/devices/6932965F-1671-4CEB-B988-D3AB0A901919/current_state
> +Date:Feb 2021
> +KernelVersion:   5.12
> +Contact: "perry.y...@dell.com>"
> +Description:
> + Allow user space to check current dell privacy device state.
> + Describes the Device State class exposed by BIOS which can be
> + consumed by various applications interested in knowing the 
> Privacy
> + feature capabilities
> + There are three Bits for available states:
> + - 0 = Enabled
> + - 1 = Disabled

What is the 

Re: [PATCH 1/2] extcon: extcon-gpio: Log error if work-queue init fails

[Hans de Goede]

Hi,

On 3/24/21 10:21 AM, Matti Vaittinen wrote:
> Add error print for probe failure when resource managed work-queue
> initialization fails.
> 
> Signed-off-by: Matti Vaittinen 
> Suggested-by: Chanwoo Choi 
> ---
>  drivers/extcon/extcon-gpio.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/extcon/extcon-gpio.c b/drivers/extcon/extcon-gpio.c
> index 4105df74f2b0..8ea2cda8f7f3 100644
> --- a/drivers/extcon/extcon-gpio.c
> +++ b/drivers/extcon/extcon-gpio.c
> @@ -114,8 +114,10 @@ static int gpio_extcon_probe(struct platform_device 
> *pdev)
>   return ret;
>  
>   ret = devm_delayed_work_autocancel(dev, >work, gpio_extcon_work);
> - if (ret)
> + if (ret) {
> + dev_err(dev, "Failed to initialize delayed_work");
>   return ret;
> + }

The only ret which we can have here is -ENOMEM and as a rule we don't log
errors for those, because the kernel memory-management code already complains
loudly when this happens.

So IMHO this patch should be dropped.

Regards,

Hans




>  
>   /*
>* Request the interrupt of gpio to detect whether external connector
> 

Re: [PATCH v3 3/8] extconn: Clean-up few drivers by using managed work init

[Hans de Goede]

Hi,

On 3/24/21 6:02 AM, Matti Vaittinen wrote:
> Hello Chanwoo, Greg,
> 
> Thanks for the review.
> 
> On Wed, 2021-03-24 at 11:09 +0900, Chanwoo Choi wrote:
>> Hi,
>>
>> Need to fix the work as following:
>> s/extconn/extcon
>>
>> And I'd like you to use the more correct patch title like the
>> following example:
>> "extcon: Use resource-managed function for delayed work"
> 
> I think Greg merged this already. How should we handle this?
> 
>> @@ -112,7 +113,9 @@ static int gpio_extcon_probe(struct
>>> platform_device *pdev)
>>> if (ret < 0)
>>> return ret;
>>>  
>>> -   INIT_DELAYED_WORK(>work, gpio_extcon_work);
>>> +   ret = devm_delayed_work_autocancel(dev, >work,
>>> gpio_extcon_work);
>>> +   if (ret)
>>> +   return ret;
>>
>> Need to add the error log as following:
>>  if (ret) {
>>  dev_err(dev, "Failed to initialize delayed_work");
>>  return ret;
>>  }   
> 
> I could send incremental patch to Greg for this but it does not change
> the commit message.

We cannot do anything about the commit message anymore, but the ordering
issue which you introduced really needs to be fixed.

Please send an incremental patch fixing the wrong order and the double
init of the workqueue.

Regards,

Hans

Re: [PATCH v2] platform/x86: asus-wmi: Add param to turn fn-lock mode on by default

[Hans de Goede]

Hi,

On 3/23/21 9:25 PM, Luca Stefani wrote:
> * On recent ZenBooks the fn-lock is disabled
>   by default on boot while running Windows.
> 
> * Add a module param ( fnlock_default ) that allows
>   changing the default at probe time
> 
> Signed-off-by: Luca Stefani 
> ---
>  drivers/platform/x86/asus-wmi.c | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/platform/x86/asus-wmi.c b/drivers/platform/x86/asus-wmi.c
> index 9ca15f724343..f3ed72f01462 100644
> --- a/drivers/platform/x86/asus-wmi.c
> +++ b/drivers/platform/x86/asus-wmi.c
> @@ -47,6 +47,9 @@ MODULE_AUTHOR("Corentin Chary , "
>  MODULE_DESCRIPTION("Asus Generic WMI Driver");
>  MODULE_LICENSE("GPL");
>  
> +static bool fnlock_default = false;

The initial value of this needs to be true, so that there is no behavioral
change when people upgrade from a kernel without this to one with it.

And then people who want a different behavior can get that by setting
the module option.

Regards,

Hans


> +module_param(fnlock_default, bool, 0444);
> +
>  #define to_asus_wmi_driver(pdrv) \
>   (container_of((pdrv), struct asus_wmi_driver, platform_driver))
>  
> @@ -2673,7 +2676,7 @@ static int asus_wmi_add(struct platform_device *pdev)
>   err = asus_wmi_set_devstate(ASUS_WMI_DEVID_BACKLIGHT, 2, NULL);
>  
>   if (asus_wmi_has_fnlock_key(asus)) {
> - asus->fnlock_locked = true;
> + asus->fnlock_locked = fnlock_default;
>   asus_wmi_fnlock_update(asus);
>   }
>  
> 

Re: [PATCH 1/2] platform/x86: intel_pmt_class: Initial resource to 0

[Hans de Goede]

Hi,

On 3/23/21 6:29 PM, David E. Box wrote:
> On Tue, 2021-03-16 at 19:44 -0700, David E. Box wrote:
>> Initialize the struct resource in intel_pmt_dev_register to zero to
>> avoid a
>> fault should the char *name field be non-zero.
> 
> Hi Hans. Can these 2 patches be pulled as fixes for 5.12? Thanks.

I've merged this into my review-hans branch now.

I'll also them to my fixes branch and add them to my next
pull-req to Linus for 5.12.

Regards,

Hans



> David
> 
>>
>> Signed-off-by: David E. Box 
>> ---
>>
>> Base commit is v5.12-rc3.
>>
>>  drivers/platform/x86/intel_pmt_class.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/platform/x86/intel_pmt_class.c
>> b/drivers/platform/x86/intel_pmt_class.c
>> index c8939fba4509..ee2b3bbeb83d 100644
>> --- a/drivers/platform/x86/intel_pmt_class.c
>> +++ b/drivers/platform/x86/intel_pmt_class.c
>> @@ -173,7 +173,7 @@ static int intel_pmt_dev_register(struct
>> intel_pmt_entry *entry,
>>   struct intel_pmt_namespace *ns,
>>   struct device *parent)
>>  {
>> -   struct resource res;
>> +   struct resource res = {0};
>> struct device *dev;
>> int ret;
>>  
>>
>> base-commit: 1e28eed17697bcf343c6743f0028cc3b5dd88bf0
> 
> 

Re: [PATCH 1/2] platform/x86: intel_pmt_class: Initial resource to 0

[Hans de Goede]

Hi,

On 3/17/21 3:44 AM, David E. Box wrote:
> Initialize the struct resource in intel_pmt_dev_register to zero to avoid a
> fault should the char *name field be non-zero.
> 
> Signed-off-by: David E. Box 

Thank you for your patch-series, I've applied the series to my
review-hans branch:
https://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86.git/log/?h=review-hans

Note it will show up in my review-hans branch once I've pushed my
local branch there, which might take a while.

Once I've run some tests on this branch the patches there will be
added to the platform-drivers-x86/for-next branch and eventually
will be included in the pdx86 pull-request to Linus for the next
merge-window.

Regards,

Hans


> ---
> 
> Base commit is v5.12-rc3.
> 
>  drivers/platform/x86/intel_pmt_class.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/platform/x86/intel_pmt_class.c 
> b/drivers/platform/x86/intel_pmt_class.c
> index c8939fba4509..ee2b3bbeb83d 100644
> --- a/drivers/platform/x86/intel_pmt_class.c
> +++ b/drivers/platform/x86/intel_pmt_class.c
> @@ -173,7 +173,7 @@ static int intel_pmt_dev_register(struct intel_pmt_entry 
> *entry,
> struct intel_pmt_namespace *ns,
> struct device *parent)
>  {
> - struct resource res;
> + struct resource res = {0};
>   struct device *dev;
>   int ret;
>  
> 
> base-commit: 1e28eed17697bcf343c6743f0028cc3b5dd88bf0
> 

Re: [V2,1/1] platform/x86: add support for Advantech software defined button

[Hans de Goede]

Hi,

On 3/19/21 5:00 AM, YingChieh, Ho wrote:
> Hi Hans,
> 
> Thank you for your kindly review.
> As a beginner in driver coding, I got gains much from your suggestions.

I'm glad to hear that my reviews are helping you.

> Path v3 is ready at patchwork.^^

Thank you, I'll try to take a look at it soon.

Regards,

Hans


> 
> Hans de Goede  於 2021年3月19日 週五 上午12:21寫道：
>>
>> Hi,
>>
>> On 3/12/21 9:11 AM, YingChieh Ho wrote:
>>> From: "Andrea.Ho" 
>>>
>>> Advantech sw_button is a ACPI event trigger button.
>>>
>>> With this driver, we can report KEY_EVENT on the
>>> Advantech Tabletop Network Appliances products and it has been
>>> tested in FWA1112VC.
>>>
>>> Add the software define button support to report EV_REP key_event
>>> (KEY_PROG1) by pressing button that cloud be get on user
>>> interface and trigger the customized actions.
>>>
>>> Signed-off-by: Andrea.Ho 
>>>
>>> v2:
>>> - change evdev key-code from BTN_TRIGGER_HAPPY to KEY_PROG1
>>> - to rewrite the driver to be a regular platform_driver
>>> - use specific names instead of generic names,
>>>   "Software Button" to "Advantech Software Button",
>>>   "button" to "adv_swbutton"
>>> - remove unused defines or use-once defines, ACPI_BUTTON_FILE_INFO,
>>>   ACPI_BUTTON_FILE_STATE, ACPI_BUTTON_TYPE_UNKNOWN, ACPI_SWBTN_NAME
>>
>> Thank you this version is much better, I have various review remarks below.
>>
>> Please send a v3 with those fixed.
>>
>>
>>> ---
>>>  MAINTAINERS |   5 +
>>>  drivers/platform/x86/Kconfig|  11 ++
>>>  drivers/platform/x86/Makefile   |   3 +
>>>  drivers/platform/x86/adv_swbutton.c | 192 
>>>  4 files changed, 211 insertions(+)
>>>  create mode 100644 drivers/platform/x86/adv_swbutton.c
>>>
>>> diff --git a/MAINTAINERS b/MAINTAINERS
>>> index 68f21d46614c..e35c48e411b7 100644
>>> --- a/MAINTAINERS
>>> +++ b/MAINTAINERS
>>> @@ -562,6 +562,11 @@ S: Maintained
>>>  F: Documentation/scsi/advansys.rst
>>>  F: drivers/scsi/advansys.c
>>>
>>> +ADVANTECH SWBTN DRIVER
>>> +M: Andrea Ho 
>>> +S: Maintained
>>> +F: drivers/platform/x86/adv_swbutton.c
>>> +
>>>  ADXL34X THREE-AXIS DIGITAL ACCELEROMETER DRIVER (ADXL345/ADXL346)
>>>  M: Michael Hennerich 
>>>  S: Supported
>>> diff --git a/drivers/platform/x86/Kconfig b/drivers/platform/x86/Kconfig
>>> index 0581a54cf562..b1340135c5e9 100644
>>> --- a/drivers/platform/x86/Kconfig
>>> +++ b/drivers/platform/x86/Kconfig
>>> @@ -180,6 +180,17 @@ config ACER_WMI
>>>   If you have an ACPI-WMI compatible Acer/ Wistron laptop, say Y or 
>>> M
>>>   here.
>>
>> This is supposed to be indented by a space (from the diff format) and then
>> a tab + 2 spaces, but in your patch this is now indented by 10 spaces.
>>
>> In general your entire patch has all tabs replaced by spaces, I guess that
>> your mail-client or editor is mangling things. Please do the following:
>>
>> 1. Check your patch for checkpatch errors:
>>
>> git format-patch HEAD~
>> scripts/checkpatch.pl 0001-platform...patch
>>
>> And fix all reported issues, both whitespace issues and others.
>>
>> 2. Send the next version of the patch like this:
>>
>> git format-patch -v3 HEAD~
>> git send-email v3-0001-platform...patch
>>
>> Do NOT edit the v3-0001-platform...patch file between these 2 steps.
>>
>>
>>> +config ADV_SWBUTTON
>>> +tristate "Advantech ACPI Software Button Driver"
>>
>> You are using indent steps of 4 spaces here, that should be a tab
>>> +depends on ACPI
>>> +help
>>> +  Say Y here to enable support for Advantech software defined
>>> +  button feature. More information can be fount at
>>> +  <http://www.advantech.com.tw/products/>
>>
>> And a tab and 2 spaces for the help text.
>>
>>> +
>>> +  To compile this driver as a module, choose M here. The module will
>>> +  be called adv_swbutton.
>>> +
>>>  config APPLE_GMUX
>>> tristate "Apple Gmux Driver"
>>> depends on ACPI && PCI
>>> d

Re: [PATCH] asus-laptop: fix kobj_to_dev.cocci warnings

[Hans de Goede]

Hi,

On 3/17/21 1:00 PM, Julia Lawall wrote:
> From: kernel test robot 
> 
> Use kobj_to_dev() instead of container_of()
> 
> Generated by: scripts/coccinelle/api/kobj_to_dev.cocci
> 
> CC: Denis Efremov 
> Reported-by: kernel test robot 
> Signed-off-by: kernel test robot 
> Signed-off-by: Julia Lawall 

Thank you for your patch, I've applied this patch to my review-hans 
branch:
https://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86.git/log/?h=review-hans

Note it will show up in my review-hans branch once I've pushed my
local branch there, which might take a while.

Once I've run some tests on this branch the patches there will be
added to the platform-drivers-x86/for-next branch and eventually
will be included in the pdx86 pull-request to Linus for the next
merge-window.

Regards,

Hans


> ---
> 
> tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
> master
> head:   1df27313f50a57497c1faeb6a6ae4ca939c85a7d
> commit: a2fc3718bc22e85378085568ecc5765fb28cabce coccinelle: api: add 
> kobj_to_dev.cocci script
> :: branch date: 5 hours ago
> :: commit date: 7 months ago
> 
>  asus-laptop.c |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> --- a/drivers/platform/x86/asus-laptop.c
> +++ b/drivers/platform/x86/asus-laptop.c
> @@ -1569,7 +1569,7 @@ static umode_t asus_sysfs_is_visible(str
>   struct attribute *attr,
>   int idx)
>  {
> - struct device *dev = container_of(kobj, struct device, kobj);
> + struct device *dev = kobj_to_dev(kobj);
>   struct asus_laptop *asus = dev_get_drvdata(dev);
>   acpi_handle handle = asus->handle;
>   bool supported;
> 

Re: [PATCH] platform: mellanox: Typo fix in the file mlxbf-bootctl.c

[Hans de Goede]

Hi,

On 3/17/21 10:56 AM, Bhaskar Chowdhury wrote:
> 
> s/progamming/programming/
> 
> Signed-off-by: Bhaskar Chowdhury 

Thank you for your patch, I've applied this patch to my review-hans 
branch:
https://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86.git/log/?h=review-hans

Note it will show up in my review-hans branch once I've pushed my
local branch there, which might take a while.

Once I've run some tests on this branch the patches there will be
added to the platform-drivers-x86/for-next branch and eventually
will be included in the pdx86 pull-request to Linus for the next
merge-window.

Regards,

Hans


> ---
>  drivers/platform/mellanox/mlxbf-bootctl.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/platform/mellanox/mlxbf-bootctl.c 
> b/drivers/platform/mellanox/mlxbf-bootctl.c
> index 5d21c6adf1ab..1c7a288b59a5 100644
> --- a/drivers/platform/mellanox/mlxbf-bootctl.c
> +++ b/drivers/platform/mellanox/mlxbf-bootctl.c
> @@ -208,7 +208,7 @@ static ssize_t secure_boot_fuse_state_show(struct device 
> *dev,
>* 0011 = version 1, 0111 = version 2,  = version 3). Upper 4 bits
>* are a thermometer code indicating key programming has completed for
>* key n (same encodings as the start bits). This allows for detection
> -  * of an interruption in the progamming process which has left the key
> +  * of an interruption in the programming process which has left the key
>* partially programmed (and thus invalid). The process is to burn the
>* eFuse for the new key start bit, burn the key eFuses, then burn the
>* eFuse for the new key complete bit.
> --
> 2.30.2
> 

Re: [PATCH] platform: x86: Typo fix in the file classmate-laptop.c

[Hans de Goede]

Hi,

On 3/17/21 9:43 AM, Bhaskar Chowdhury wrote:
> 
> s/derefence/dereference/
> 
> Signed-off-by: Bhaskar Chowdhury 

Thank you for your patch, I've applied this patch to my review-hans 
branch:
https://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86.git/log/?h=review-hans

Note it will show up in my review-hans branch once I've pushed my
local branch there, which might take a while.

Once I've run some tests on this branch the patches there will be
added to the platform-drivers-x86/for-next branch and eventually
will be included in the pdx86 pull-request to Linus for the next
merge-window.

Regards,

Hans


> ---
>  drivers/platform/x86/classmate-laptop.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/platform/x86/classmate-laptop.c 
> b/drivers/platform/x86/classmate-laptop.c
> index 3e03e8d3a07f..9309ab5792cb 100644
> --- a/drivers/platform/x86/classmate-laptop.c
> +++ b/drivers/platform/x86/classmate-laptop.c
> @@ -956,7 +956,7 @@ static int cmpc_ipml_add(struct acpi_device *acpi)
>   /*
>* If RFKILL is disabled, rfkill_alloc will return ERR_PTR(-ENODEV).
>* This is OK, however, since all other uses of the device will not
> -  * derefence it.
> +  * dereference it.
>*/
>   if (ipml->rf) {
>   retval = rfkill_register(ipml->rf);
> --
> 2.30.2
> 

Re: [PATCH] platform/x86: asus-wmi: Disable fn-lock mode by default

[Hans de Goede]

Hi,

On 3/16/21 11:17 PM, Luca Stefani wrote:
> * On recent ZenBooks the fn-lock is disabled
>   by default on boot while running Windows.
> 
> * Follow the same paradigm also here.
> 
> Signed-off-by: Luca Stefani 

This will be a behavioral change for many users where their F-keys will
now all of a sudden work different after boot under Linux then they
did before.

As such this seems like a bad idea, so I'm not going to merge this patch.

What might be an option is adding a module-option which allows users to
configure the default setting at boot that way, while keeping the current
default.

Regards,

Hans



> ---
>  drivers/platform/x86/asus-wmi.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/platform/x86/asus-wmi.c b/drivers/platform/x86/asus-wmi.c
> index 9ca15f724343..32319f7d6e17 100644
> --- a/drivers/platform/x86/asus-wmi.c
> +++ b/drivers/platform/x86/asus-wmi.c
> @@ -2673,7 +2673,7 @@ static int asus_wmi_add(struct platform_device *pdev)
>   err = asus_wmi_set_devstate(ASUS_WMI_DEVID_BACKLIGHT, 2, NULL);
>  
>   if (asus_wmi_has_fnlock_key(asus)) {
> - asus->fnlock_locked = true;
> + asus->fnlock_locked = false;
>   asus_wmi_fnlock_update(asus);
>   }
>  
> 

Re: [PATCH v5 1/2] platform/x86: dell-privacy: Add support for Dell hardware privacy

[Hans de Goede]

Hi,

On 3/23/21 7:57 PM, Pierre-Louis Bossart wrote:
> Minor comments below.

> +int __init dell_privacy_acpi_init(void)
> 
> is the __init necessary? You call this routine from another which already has 
> this qualifier.

Yes this is necessary, all functions which are only used during module_load / 
from the
module's init function must be marked as __init so that the kernel can unload 
them
after module loading is done.

I do wonder if this one should not be static though (I've not looked at this 
patch in
detail yet).

> 
>> +{
>> +    int err;
>> +    struct platform_device *pdev;
>> +
>> +    if (!wmi_has_guid(DELL_PRIVACY_GUID))
>> +    return -ENODEV;
>> +
>> +    privacy_acpi = kzalloc(sizeof(*privacy_acpi), GFP_KERNEL);
>> +    if (!privacy_acpi)
>> +    return -ENOMEM;
>> +
>> +    err = platform_driver_register(_privacy_platform_drv);
>> +    if (err)
>> +    goto pdrv_err;
>> +
>> +    pdev = platform_device_register_simple(
>> +    PRIVACY_PLATFORM_NAME, PLATFORM_DEVID_NONE, NULL, 0);
>> +    if (IS_ERR(pdev)) {
>> +    err = PTR_ERR(pdev);
>> +    goto pdev_err;
>> +    }
>> +
>> +    return 0;
>> +
>> +pdev_err:
>> +    platform_device_unregister(pdev);
>> +pdrv_err:
>> +    kfree(privacy_acpi);
>> +    return err;
>> +}
>> +
>> +void __exit dell_privacy_acpi_exit(void)
> 
> is the __exit required here?

Idem. Also static ?

Regards,

Hans



> 
>> +{
>> +    struct platform_device *pdev = to_platform_device(privacy_acpi->dev);
>> +
>> +    platform_device_unregister(pdev);
>> +    platform_driver_unregister(_privacy_platform_drv);
>> +    kfree(privacy_acpi);
>> +}
>> +
>> +MODULE_AUTHOR("Perry Yuan ");
>> +MODULE_DESCRIPTION("DELL Privacy ACPI Driver");
>> +MODULE_LICENSE("GPL");
> 
> 

Re: [PATCH v3 5/8] platform/x86: gpd pocket fan: Clean-up by using managed work init

[Hans de Goede]

HI,

On 3/23/21 2:57 PM, Matti Vaittinen wrote:
> Few drivers implement remove call-back only for ensuring a delayed
> work gets cancelled prior driver removal. Clean-up these by switching
> to use devm_delayed_work_autocancel() instead.
> 
> This change is compile-tested only. All testing is appreciated.
> 
> Signed-off-by: Matti Vaittinen 

Thanks, patch looks good to me:

Reviewed-by: Hans de Goede 

Regards,

Hans


> ---
> Changelog from RFCv2:
>  - RFC dropped. No functional changes.
> 
>  drivers/platform/x86/gpd-pocket-fan.c | 17 ++---
>  1 file changed, 6 insertions(+), 11 deletions(-)
> 
> diff --git a/drivers/platform/x86/gpd-pocket-fan.c 
> b/drivers/platform/x86/gpd-pocket-fan.c
> index 5b516e4c2bfb..7a20f68ae206 100644
> --- a/drivers/platform/x86/gpd-pocket-fan.c
> +++ b/drivers/platform/x86/gpd-pocket-fan.c
> @@ -6,6 +6,7 @@
>   */
>  
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -124,7 +125,7 @@ static void gpd_pocket_fan_force_update(struct 
> gpd_pocket_fan_data *fan)
>  static int gpd_pocket_fan_probe(struct platform_device *pdev)
>  {
>   struct gpd_pocket_fan_data *fan;
> - int i;
> + int i, ret;
>  
>   for (i = 0; i < ARRAY_SIZE(temp_limits); i++) {
>   if (temp_limits[i] < 2 || temp_limits[i] > 9) {
> @@ -152,7 +153,10 @@ static int gpd_pocket_fan_probe(struct platform_device 
> *pdev)
>   return -ENOMEM;
>  
>   fan->dev = >dev;
> - INIT_DELAYED_WORK(>work, gpd_pocket_fan_worker);
> + ret = devm_delayed_work_autocancel(>dev, >work,
> +gpd_pocket_fan_worker);
> + if (ret)
> + return ret;
>  
>   /* Note this returns a "weak" reference which we don't need to free */
>   fan->dts0 = thermal_zone_get_zone_by_name("soc_dts0");
> @@ -177,14 +181,6 @@ static int gpd_pocket_fan_probe(struct platform_device 
> *pdev)
>   return 0;
>  }
>  
> -static int gpd_pocket_fan_remove(struct platform_device *pdev)
> -{
> - struct gpd_pocket_fan_data *fan = platform_get_drvdata(pdev);
> -
> - cancel_delayed_work_sync(>work);
> - return 0;
> -}
> -
>  #ifdef CONFIG_PM_SLEEP
>  static int gpd_pocket_fan_suspend(struct device *dev)
>  {
> @@ -215,7 +211,6 @@ MODULE_DEVICE_TABLE(acpi, gpd_pocket_fan_acpi_match);
>  
>  static struct platform_driver gpd_pocket_fan_driver = {
>   .probe  = gpd_pocket_fan_probe,
> - .remove = gpd_pocket_fan_remove,
>   .driver = {
>   .name   = "gpd_pocket_fan",
>   .acpi_match_table   = gpd_pocket_fan_acpi_match,
> 

Re: [PATCH] Input: i8042 - fix Pegatron C15B ID entry

[Hans de Goede]

Hi,

On 3/23/21 2:06 PM, Arnd Bergmann wrote:
> From: Arnd Bergmann 
> 
> The Zenbook Flip entry that was added overwrites a previous one
> because of a typo:
> 
> In file included from drivers/input/serio/i8042.h:23,
>  from drivers/input/serio/i8042.c:131:
> drivers/input/serio/i8042-x86ia64io.h:591:28: error: initialized field 
> overwritten [-Werror=override-init]
>   591 | .matches = {
>   |^
> drivers/input/serio/i8042-x86ia64io.h:591:28: note: (near initialization for 
> 'i8042_dmi_noselftest_table[0].matches')
> 
> Add the missing separator between the two.
> 
> Fixes: b5d6e7ab7fe7 ("Input: i8042 - add ASUS Zenbook Flip to noselftest 
> list")
> Signed-off-by: Arnd Bergmann 

Thanks, patch looks good to me:

Reviewed-by: Hans de Goede 

Regards,

Hans


> ---
>  drivers/input/serio/i8042-x86ia64io.h | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/input/serio/i8042-x86ia64io.h 
> b/drivers/input/serio/i8042-x86ia64io.h
> index 9119e12a5778..a5a003553646 100644
> --- a/drivers/input/serio/i8042-x86ia64io.h
> +++ b/drivers/input/serio/i8042-x86ia64io.h
> @@ -588,6 +588,7 @@ static const struct dmi_system_id 
> i8042_dmi_noselftest_table[] = {
>   DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
>   DMI_MATCH(DMI_CHASSIS_TYPE, "10"), /* Notebook */
>   },
> + }, {
>   .matches = {
>   DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
>   DMI_MATCH(DMI_CHASSIS_TYPE, "31"), /* Convertible 
> Notebook */
> 

Re: [PATCH v3 3/8] extconn: Clean-up few drivers by using managed work init

[Hans de Goede]

Hi,

On 3/23/21 2:57 PM, Matti Vaittinen wrote:
> Few drivers implement remove call-back only for ensuring a delayed
> work gets cancelled prior driver removal. Clean-up these by switching
> to use devm_delayed_work_autocancel() instead.
> 
> Additionally, this helps avoiding mixing devm and manual resource
> management and cleans up a (theoretical?) bug from extconn-palmas.c
> and extcon-qcom-spmi-misc.c where (devm managed)IRQ might schedule
> new work item after wq was cleaned at remove().
> 
> This change is compile-tested only. All testing is appreciated.
> 
> Signed-off-by: Matti Vaittinen 

Thanks, patch looks good to me:

Reviewed-by: Hans de Goede 

Note that this is not just a cleanup, it also actually fixes a
couple of driver-unbind races where the work was stopped before
the IRQ is free-ed, so there is a race where the work can be
restarted.

Regards,

Hans



> ---
> Changelog from RFCv2:
>  - RFC dropped. No functional changes.
> 
>  drivers/extcon/extcon-gpio.c   | 15 ---
>  drivers/extcon/extcon-intel-int3496.c  | 16 
>  drivers/extcon/extcon-palmas.c | 17 ++---
>  drivers/extcon/extcon-qcom-spmi-misc.c | 17 ++---
>  4 files changed, 20 insertions(+), 45 deletions(-)
> 
> diff --git a/drivers/extcon/extcon-gpio.c b/drivers/extcon/extcon-gpio.c
> index c211222f5d0c..4105df74f2b0 100644
> --- a/drivers/extcon/extcon-gpio.c
> +++ b/drivers/extcon/extcon-gpio.c
> @@ -9,6 +9,7 @@
>   * (originally switch class is supported)
>   */
>  
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -112,7 +113,9 @@ static int gpio_extcon_probe(struct platform_device *pdev)
>   if (ret < 0)
>   return ret;
>  
> - INIT_DELAYED_WORK(>work, gpio_extcon_work);
> + ret = devm_delayed_work_autocancel(dev, >work, gpio_extcon_work);
> + if (ret)
> + return ret;
>  
>   /*
>* Request the interrupt of gpio to detect whether external connector
> @@ -131,15 +134,6 @@ static int gpio_extcon_probe(struct platform_device 
> *pdev)
>   return 0;
>  }
>  
> -static int gpio_extcon_remove(struct platform_device *pdev)
> -{
> - struct gpio_extcon_data *data = platform_get_drvdata(pdev);
> -
> - cancel_delayed_work_sync(>work);
> -
> - return 0;
> -}
> -
>  #ifdef CONFIG_PM_SLEEP
>  static int gpio_extcon_resume(struct device *dev)
>  {
> @@ -158,7 +152,6 @@ static SIMPLE_DEV_PM_OPS(gpio_extcon_pm_ops, NULL, 
> gpio_extcon_resume);
>  
>  static struct platform_driver gpio_extcon_driver = {
>   .probe  = gpio_extcon_probe,
> - .remove = gpio_extcon_remove,
>   .driver = {
>   .name   = "extcon-gpio",
>   .pm = _extcon_pm_ops,
> diff --git a/drivers/extcon/extcon-intel-int3496.c 
> b/drivers/extcon/extcon-intel-int3496.c
> index 80c9abcc3f97..fb527c23639e 100644
> --- a/drivers/extcon/extcon-intel-int3496.c
> +++ b/drivers/extcon/extcon-intel-int3496.c
> @@ -11,6 +11,7 @@
>   */
>  
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -101,7 +102,9 @@ static int int3496_probe(struct platform_device *pdev)
>   return -ENOMEM;
>  
>   data->dev = dev;
> - INIT_DELAYED_WORK(>work, int3496_do_usb_id);
> + ret = devm_delayed_work_autocancel(dev, >work, int3496_do_usb_id);
> + if (ret)
> + return ret;
>  
>   data->gpio_usb_id = devm_gpiod_get(dev, "id", GPIOD_IN);
>   if (IS_ERR(data->gpio_usb_id)) {
> @@ -155,16 +158,6 @@ static int int3496_probe(struct platform_device *pdev)
>   return 0;
>  }
>  
> -static int int3496_remove(struct platform_device *pdev)
> -{
> - struct int3496_data *data = platform_get_drvdata(pdev);
> -
> - devm_free_irq(>dev, data->usb_id_irq, data);
> - cancel_delayed_work_sync(>work);
> -
> - return 0;
> -}
> -
>  static const struct acpi_device_id int3496_acpi_match[] = {
>   { "INT3496" },
>   { }
> @@ -177,7 +170,6 @@ static struct platform_driver int3496_driver = {
>   .acpi_match_table = int3496_acpi_match,
>   },
>   .probe = int3496_probe,
> - .remove = int3496_remove,
>  };
>  
>  module_platform_driver(int3496_driver);
> diff --git a/drivers/extcon/extcon-palmas.c b/drivers/extcon/extcon-palmas.c
> index a2852bcc5f0d..d2c1a8b89c08 100644
> --- a/drivers/extcon/extcon-palmas.c
> +++ b/drivers/extcon/extcon-palmas.c
> @@ -9,6 +9,7 @@
>   * Author: Hema HK 
>   */
>  
> +#include 
>  #include 
>  #include 
>  #inclu

Re: [PATCH v3 1/8] workqueue: Add resource managed version of delayed work init

[Hans de Goede]

Hi,

On 3/23/21 2:56 PM, Matti Vaittinen wrote:
> A few drivers which need a delayed work-queue must cancel work at driver
> detach. Some of those implement remove() solely for this purpose. Help
> drivers to avoid unnecessary remove and error-branch implementation by
> adding managed verision of delayed work initialization. This will also
> help drivers to avoid mixing manual and devm based unwinding when other
> resources are handled by devm.
> 
> Signed-off-by: Matti Vaittinen 

Thanks, patch looks good to me:

Reviewed-by: Hans de Goede 

Regards,

Hans



> ---
> Changelog from RFCv2:
>  - RFC dropped. No functional changes.
> 
>  include/linux/devm-helpers.h | 53 
>  1 file changed, 53 insertions(+)
>  create mode 100644 include/linux/devm-helpers.h
> 
> diff --git a/include/linux/devm-helpers.h b/include/linux/devm-helpers.h
> new file mode 100644
> index ..f64e0c9f3763
> --- /dev/null
> +++ b/include/linux/devm-helpers.h
> @@ -0,0 +1,53 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +#ifndef __LINUX_DEVM_HELPERS_H
> +#define __LINUX_DEVM_HELPERS_H
> +
> +/*
> + * Functions which do automatically cancel operations or release resources 
> upon
> + * driver detach.
> + *
> + * These should be helpful to avoid mixing the manual and devm-based resource
> + * management which can be source of annoying, rarely occurring,
> + * hard-to-reproduce bugs.
> + *
> + * Please take into account that devm based cancellation may be performed 
> some
> + * time after the remove() is ran.
> + *
> + * Thus mixing devm and manual resource management can easily cause problems
> + * when unwinding operations with dependencies. IRQ scheduling a work in a 
> queue
> + * is typical example where IRQs are often devm-managed and WQs are manually
> + * cleaned at remove(). If IRQs are not manually freed at remove() (and this 
> is
> + * often the case when we use devm for IRQs) we have a period of time after
> + * remove() - and before devm managed IRQs are freed - where new IRQ may fire
> + * and schedule a work item which won't be cancelled because remove() was
> + * already ran.
> + */
> +
> +#include 
> +#include 
> +
> +static inline void devm_delayed_work_drop(void *res)
> +{
> + cancel_delayed_work_sync(res);
> +}
> +
> +/**
> + * devm_delayed_work_autocancel - Resource-managed work allocation
> + * @dev: Device which lifetime work is bound to
> + * @pdata: work to be cancelled when driver is detached
> + *
> + * Initialize work which is automatically cancelled when driver is detached.
> + * A few drivers need delayed work which must be cancelled before driver
> + * is detached to avoid accessing removed resources.
> + * devm_delayed_work_autocancel() can be used to omit the explicit
> + * cancelleation when driver is detached.
> + */
> +static inline int devm_delayed_work_autocancel(struct device *dev,
> +struct delayed_work *w,
> +work_func_t worker)
> +{
> + INIT_DELAYED_WORK(w, worker);
> + return devm_add_action(dev, devm_delayed_work_drop, w);
> +}
> +
> +#endif
> 

Re: [PATCH v3 2/8] MAINTAINERS: Add entry for devm helpers

[Hans de Goede]

Hi,

On 3/23/21 2:56 PM, Matti Vaittinen wrote:
> Devm helper header containing small inline helpers was added.
> Hans promised to maintain it.
> 
> Add Hans as maintainer and myself as designated reviewer.
> 
> Signed-off-by: Matti Vaittinen 

Yes I did promise that, didn't I?  FWIW going this route is still
fine by me, assuming that having someone else maintain this makes
this easier on / more acceptable to Greg.

Ultimately this is up to Greg though, so lets wait and see what
Greg has to say about this.

Regards,

Hans



> ---
> Changelog from RFCv2:
>  - RFC dropped. No functional changes.
> 
>  MAINTAINERS | 6 ++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 9e876927c60d..fa5ac3164678 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -5169,6 +5169,12 @@ M: Torben Mathiasen 
>  S:   Maintained
>  W:   http://lanana.org/docs/device-list/index.html
>  
> +DEVICE RESOURCE MANAGEMENT HELPERS
> +M:   Hans de Goede 
> +R:   Matti Vaittinen 
> +S:   Maintained
> +F:   include/linux/devm-helpers.h
> +
>  DEVICE-MAPPER  (LVM)
>  M:   Alasdair Kergon 
>  M:   Mike Snitzer 
> 

Re: [PATCH v4 2/2] ASoC: rt715:add micmute led state control supports

[Hans de Goede]

Hi,

On 3/22/21 3:37 PM, Jaroslav Kysela wrote:
> Dne 22. 03. 21 v 10:25 Yuan, Perry napsal(a):
>> Hi Mark:
>>
>>> -Original Message-
>>> From: Mark Brown 
>>> Sent: Tuesday, March 9, 2021 1:24 AM
>>> To: Yuan, Perry
>>> Cc: po...@protonmail.com; pierre-louis.boss...@linux.intel.com;
>>> oder_ch...@realtek.com; pe...@perex.cz; ti...@suse.com;
>>> hdego...@redhat.com; mgr...@linux.intel.com; Limonciello, Mario;
>>> lgirdw...@gmail.com; alsa-de...@alsa-project.org; linux-
>>> ker...@vger.kernel.org; platform-driver-...@vger.kernel.org
>>> Subject: Re: [PATCH v4 2/2] ASoC: rt715:add micmute led state control
>>> supports
>>>
>>> On Mon, Mar 01, 2021 at 05:38:34PM +0800, Perry Yuan wrote:
>>>
 +  /* Micmute LED state changed by muted/unmute switch */
 +  if (mc->invert) {
 +  if (ucontrol->value.integer.value[0] || ucontrol-
 value.integer.value[1]) {
 +  micmute_led = LED_OFF;
 +  } else {
 +  micmute_led = LED_ON;
 +  }
 +  ledtrig_audio_set(LED_AUDIO_MICMUTE, micmute_led);
 +  }
>>>
>>> These conditionals on inversion seem weird and counterintuitive.  If we're
>>> going with this approach it would probably be clearer to define a custom
>>> operation for the affected controls that wraps the standard one and adds the
>>> LED setting rather than keying off invert like this.
>>
>> Currently the sof soundwire driver has no generic led control yet.
>> This patch can handle the led control needs for MIC mute LED, definitely the 
>> patch is a short term solution.
>> There is a feature request discussion when we started to implement this 
>> solution.
>> https://github.com/thesofproject/linux/issues/2496#issuecomment-713892620
>>
>> The workable way for now is that we put the LED mute control to the codec 
>> driver.
>> When there is new and full sound LED solution implemented, this part will be 
>> also optimized.
>> The Hardware privacy feature needs this patch to handle the Mic mute led 
>> state change.
>> Before that full solution ready in kernel, could we take this as short term 
>> solution?
> 
> Perry, it's about the machine detection. Your code is too much generic even
> for the top-level LED trigger implementation. We need an extra check, if the
> proper LED's are really controlled on the specific hardware. Other hardware
> may use RT715 for a different purpose. Use DMI / ACPI checks to detect this
> hardware and don't misuse the inversion flag to enable this code.

I think this would be a goo candidate for the new generic LED handling:

https://lore.kernel.org/alsa-devel/20210317172945.842280-1-pe...@perex.cz/

And then use a udev-rule + hwdb and/or UCM profiles to configure the LED trigger
for specific models from userspace ?

Regards,

Hans

Re: [GIT PULL] Immutable branch between MFD and Extcon due for the v5.13 merge window

[Hans de Goede]

Hi,

On 3/22/21 3:40 PM, Lee Jones wrote:
> Enjoy!
> 
> The following changes since commit a38fd8748464831584a19438cbb3082b5a2dab15:
> 
>   Linux 5.12-rc2 (2021-03-05 17:33:41 -0800)
> 
> are available in the Git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd.git 
> ib-mfd-extcon-v5.13
> 
> for you to fetch changes up to a908a716696eee75bf85199cde2b0989290536d1:
> 
>   ASoC/extcon: arizona: Move arizona jack code to 
> sound/soc/codecs/arizona-jack.c (2021-03-18 11:46:15 +)

Thank you.

Mark can you merge this into your ASoC tree and merge patches 7-13 of:
https://lore.kernel.org/alsa-devel/20210307151807.35201-1-hdego...@redhat.com/

?

Regards,

Hans





> 
> 
> Immutable branch between MFD and Extcon due for the v5.13 merge window
> 
> --------
> Hans de Goede (6):
>   mfd: arizona: Drop arizona-extcon cells
>   extcon: arizona: Fix some issues when HPDET IRQ fires after the jack 
> has been unplugged
>   extcon: arizona: Fix various races on driver unbind
>   extcon: arizona: Fix flags parameter to the gpiod_get("wlf,micd-pol") 
> call
>   extcon: arizona: Always use pm_runtime_get_sync() when we need the 
> device to be awake
>   ASoC/extcon: arizona: Move arizona jack code to 
> sound/soc/codecs/arizona-jack.c
> 
>  MAINTAINERS|  3 +-
>  drivers/extcon/Kconfig |  8 ---
>  drivers/extcon/Makefile|  1 -
>  drivers/mfd/arizona-core.c | 20 ---
>  .../soc/codecs/arizona-jack.c  | 63 
> +++---
>  5 files changed, 34 insertions(+), 61 deletions(-)
>  rename drivers/extcon/extcon-arizona.c => sound/soc/codecs/arizona-jack.c 
> (98%)
> 

Re: [V2,1/1] platform/x86: add support for Advantech software defined button

[Hans de Goede]

Hi,

On 3/12/21 9:11 AM, YingChieh Ho wrote:
> From: "Andrea.Ho" 
> 
> Advantech sw_button is a ACPI event trigger button.
> 
> With this driver, we can report KEY_EVENT on the
> Advantech Tabletop Network Appliances products and it has been
> tested in FWA1112VC.
> 
> Add the software define button support to report EV_REP key_event
> (KEY_PROG1) by pressing button that cloud be get on user
> interface and trigger the customized actions.
> 
> Signed-off-by: Andrea.Ho 
> 
> v2:
> - change evdev key-code from BTN_TRIGGER_HAPPY to KEY_PROG1
> - to rewrite the driver to be a regular platform_driver
> - use specific names instead of generic names,
>   "Software Button" to "Advantech Software Button",
>   "button" to "adv_swbutton"
> - remove unused defines or use-once defines, ACPI_BUTTON_FILE_INFO,
>   ACPI_BUTTON_FILE_STATE, ACPI_BUTTON_TYPE_UNKNOWN, ACPI_SWBTN_NAME

Thank you this version is much better, I have various review remarks below.

Please send a v3 with those fixed.


> ---
>  MAINTAINERS |   5 +
>  drivers/platform/x86/Kconfig|  11 ++
>  drivers/platform/x86/Makefile   |   3 +
>  drivers/platform/x86/adv_swbutton.c | 192 
>  4 files changed, 211 insertions(+)
>  create mode 100644 drivers/platform/x86/adv_swbutton.c
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 68f21d46614c..e35c48e411b7 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -562,6 +562,11 @@ S: Maintained
>  F: Documentation/scsi/advansys.rst
>  F: drivers/scsi/advansys.c
> 
> +ADVANTECH SWBTN DRIVER
> +M: Andrea Ho 
> +S: Maintained
> +F: drivers/platform/x86/adv_swbutton.c
> +
>  ADXL34X THREE-AXIS DIGITAL ACCELEROMETER DRIVER (ADXL345/ADXL346)
>  M: Michael Hennerich 
>  S: Supported
> diff --git a/drivers/platform/x86/Kconfig b/drivers/platform/x86/Kconfig
> index 0581a54cf562..b1340135c5e9 100644
> --- a/drivers/platform/x86/Kconfig
> +++ b/drivers/platform/x86/Kconfig
> @@ -180,6 +180,17 @@ config ACER_WMI
>   If you have an ACPI-WMI compatible Acer/ Wistron laptop, say Y or M
>   here.

This is supposed to be indented by a space (from the diff format) and then
a tab + 2 spaces, but in your patch this is now indented by 10 spaces.

In general your entire patch has all tabs replaced by spaces, I guess that
your mail-client or editor is mangling things. Please do the following:

1. Check your patch for checkpatch errors:

git format-patch HEAD~
scripts/checkpatch.pl 0001-platform...patch

And fix all reported issues, both whitespace issues and others.

2. Send the next version of the patch like this:

git format-patch -v3 HEAD~
git send-email v3-0001-platform...patch

Do NOT edit the v3-0001-platform...patch file between these 2 steps.


> +config ADV_SWBUTTON
> +tristate "Advantech ACPI Software Button Driver"

You are using indent steps of 4 spaces here, that should be a tab
> +depends on ACPI
> +help
> +  Say Y here to enable support for Advantech software defined
> +  button feature. More information can be fount at
> +  

And a tab and 2 spaces for the help text.

> +
> +  To compile this driver as a module, choose M here. The module will
> +  be called adv_swbutton.
> +
>  config APPLE_GMUX
> tristate "Apple Gmux Driver"
> depends on ACPI && PCI
> diff --git a/drivers/platform/x86/Makefile b/drivers/platform/x86/Makefile
> index 2b85852a1a87..76a321fc58ba 100644
> --- a/drivers/platform/x86/Makefile
> +++ b/drivers/platform/x86/Makefile
> @@ -22,6 +22,9 @@ obj-$(CONFIG_ACERHDF) += acerhdf.o
>  obj-$(CONFIG_ACER_WIRELESS)+= acer-wireless.o
>  obj-$(CONFIG_ACER_WMI) += acer-wmi.o
> 
> +# Advantech
> +obj-$(CONFIG_ADV_SWBUTTON)  += adv_swbutton.o
> +

The indent before the += should use tabs not spaces.

>  # Apple
>  obj-$(CONFIG_APPLE_GMUX)   += apple-gmux.o
> 
> diff --git a/drivers/platform/x86/adv_swbutton.c
> b/drivers/platform/x86/adv_swbutton.c
> new file mode 100644
> index ..f4387220e8a0
> --- /dev/null
> +++ b/drivers/platform/x86/adv_swbutton.c
> @@ -0,0 +1,192 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + *  adv_swbutton.c - Software Button Interface Driver.
> + *
> + *  (C) Copyright 2020 Advantech Corporation, Inc
> + *
> + */
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 

Please drop the following unused defines:

#include 
#include 
#include 
#include 
#include 
#include 
#include 

And sort the remaining includes alphabetically.

> +
> +#define MODULE_NAME "adv_swbutton"

Please drop this define, instead just set the .driver.name part of the 
platform_driver struct directly to "adv_swbutton".

> +
> +#define ACPI_BUTTON_HID_SWBTN   "AHC0310"
> +#define 

Re: [PATCH v2 1/4] platform/x86: simatic-ipc: add main driver for Siemens devices

[Hans de Goede]

Hi,

On 3/18/21 12:30 PM, Enrico Weigelt, metux IT consult wrote:
> On 17.03.21 21:03, Hans de Goede wrote:
> 
> Hi,
> 
>>> It just identifies the box and tells subsequent drivers which one it
>>> is, which watchdog and LED path to take. Moving the knowledge of which
>>> box has which LED/watchdog into the respective drivers seems to be the
>>> better way to go.
>>>
>>> So we would end up with a LED and a watchdog driver both
>>> MODULE_ALIAS("dmi:*:svnSIEMENSAG:*");
> 
> Uh, isn't that a bit too broad ? This basically implies that Siemens
> will never produce boards with different configurations.

There is a further check done in probe() based on some Siemens specific
DMI table entries.

>>> and doing the identification with the inline dmi from that header,
>>> doing p2sb with the support to come ... possibly a "//TODO\ninline" in
>>> the meantime.
>>>
>>> So no "main platform" driver anymore, but still central platform
>>> headers.
>>>
>>> Not sure how this sounds, but i think making that change should be
>>> possible. And that is what i will try and go for in v3.
>>
>> Dropping the main drivers/platform/x86 driver sounds good to me,
>> I was already wondering a bit about its function since it just
>> instantiates devs to which the other ones bind to then instantiate
>> more devs (in the LED case).
> 
> hmm, IMHO that depends on whether the individual sub-devices can be
> more generic than just that specific machine. (@Hanning: could you
> tell us more about that ?).
> 
> Another question is how they're actually probed .. only dmi or maybe
> also pci dev ? (i've seen some refs to pci stuff in the led driver, but
> missed the other code thats called here).
> 
> IMHO, if the whole thing lives on some PCI device (which can be probed
> via pci ID), and that device has the knowledge, where the LED registers
> actually are (eg. based on device ID, pci mmio mapping, ...) then there
> should be some parent driver that instantiates the led devices (and
> possibly other board specific stuff). That would be a clear separation,
> modularization. In that case, maybe this LED driver could even be
> replaced by some really generic "register-based-LED" driver, which just
> needs to be fed with some parameters like register ranges, bitmasks, etc.
> 
> OTOH, if everything can be derived entirely from DMI match, w/o things
> like pci mappings involved (IOW: behaves like directly wired to the
> cpu's mem/io bus, no other "intelligent" bus involved), and it's all
> really board specific logic (no generic led or gpio controllers
> involved), then it might be better to have entirely separate drivers.

FWIW I'm fine with either solution, and if we go the "parent driver"
route I'm happy to have that driver sit in drivers/platform/x86
(once all the discussions surrounding this are resolved).

My reply was because I noticed that the Led driver seemed to sort of
also act as a parent driver (last time I looked) and instantiated a
bunch of stuff, so then we have 2 parent(ish) drivers. If things stay
that way then having 2 levels of parent drivers seems a bit too much
to me, esp. if it can all be done cleanly in e.g. the LED driver.

But as said I'm fine either way as long as the code is reasonably
clean and dealing with this sort of platform specific warts happens
a lot in drivers/platform/x86 .

Regards,

Hans

Re: [PATCH v4 resend 00/13] MFD/extcon/ASoC: Rework arizona codec jack-detect support

[Hans de Goede]

Hi Lee,

On 3/7/21 4:17 PM, Hans de Goede wrote:
> Hi All,
> 
> Here is v4 of my series to rework the arizona codec jack-detect support
> to use the snd_soc_jack helpers instead of direct extcon reporting.
> 
> As discussed before here is a resend rebased on 5.12-rc2, making sure that
> all patches this depends on are in place.
> 
> Lee, can you pick-up patches 1-6 through the MFD tree and then send a
> pull-req to Mark so that Mark can merge the Asoc parts throught the ASoC
> tree ?
> 
> Patches 2-6 touch drivers/extcon, these all have an Ack from Chanwoo Choi
> for merging these through the MFD tree.

Lee, is there a specific reason why these have not been merged yet,
or did you just not get around to these yet ?

As I already mentioned Chanwoo Choi already gave an ack for merging
the extcon patches through MFD, so AFAICT eveything is ready to merge
1-6 through the MFD tree, and then have Mark merge an ib from the
MFD tree and merge the rest.

Regards,

Hans



> 
> Here is some more generic info on this series from the previous
> cover-letter:
> 
> This is done by reworking the extcon driver into an arizona-jackdet
> library and then modifying the codec drivers to use that directly,
> replacing the old separate extcon child-devices and extcon-driver.
> 
> This brings the arizona-codec jack-detect handling inline with how
> all other ASoC codec driver do this. This was developed and tested on
> a Lenovo Yoga Tablet 1051L with a WM5102 codec.
> 
> This was also tested by Charles Keepax, one of the Cirrus Codec folks.
> 
> Regards,
> 
> Hans
> 
> 
> Hans de Goede (13):
>   mfd: arizona: Drop arizona-extcon cells
>   extcon: arizona: Fix some issues when HPDET IRQ fires after the jack
> has been unplugged
>   extcon: arizona: Fix various races on driver unbind
>   extcon: arizona: Fix flags parameter to the gpiod_get("wlf,micd-pol")
> call
>   extcon: arizona: Always use pm_runtime_get_sync() when we need the
> device to be awake
>   ASoC/extcon: arizona: Move arizona jack code to
> sound/soc/codecs/arizona-jack.c
>   ASoC: arizona-jack: Move jack-detect variables to struct arizona_priv
>   ASoC: arizona-jack: Use arizona->dev for runtime-pm
>   ASoC: arizona-jack: convert into a helper library for codec drivers
>   ASoC: arizona-jack: Use snd_soc_jack to report jack events
>   ASoC: arizona-jack: Cleanup logging
>   ASoC: arizona: Make the wm5102, wm5110, wm8997 and wm8998 drivers use
> the new jack library
>   ASoC: Intel: bytcr_wm5102: Add jack detect support
> 
>  MAINTAINERS   |   3 +-
>  drivers/extcon/Kconfig|   8 -
>  drivers/extcon/Makefile   |   1 -
>  drivers/mfd/arizona-core.c|  20 -
>  sound/soc/codecs/Makefile |   2 +-
>  .../soc/codecs/arizona-jack.c | 577 +++---
>  sound/soc/codecs/arizona.h|  44 ++
>  sound/soc/codecs/wm5102.c |  12 +-
>  sound/soc/codecs/wm5110.c |  12 +-
>  sound/soc/codecs/wm8997.c |  14 +-
>  sound/soc/codecs/wm8998.c |   9 +
>  sound/soc/intel/boards/bytcr_wm5102.c |  28 +-
>  12 files changed, 325 insertions(+), 405 deletions(-)
>  rename drivers/extcon/extcon-arizona.c => sound/soc/codecs/arizona-jack.c 
> (76%)
> 

Re: [GIT PULL v2] Immutable branch between MFD and Platform/X86 due for the v5.13 merge window

[Hans de Goede]

Hi,

On 3/10/21 11:57 AM, Lee Jones wrote:
> Rebased onto -rc2
> 
> The following changes since commit a38fd8748464831584a19438cbb3082b5a2dab15:
> 
>   Linux 5.12-rc2 (2021-03-05 17:33:41 -0800)
> 
> are available in the Git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd.git 
> ib-mfd-platform-x86-v5.13
> 
> for you to fetch changes up to aa47ad3f853ae72c32b7e46dfc8bc2c8dc2dbad7:
> 
>   mfd: intel_pmt: Add support for DG1 (2021-03-10 10:48:48 +)
> 
> 
> Immutable branch between MFD and Platform/x86 due for the v5.13 merge window

Thank you, I've merged this into my review-hans branch now, so this will
soon be in pdx86/for-next.

Regards,

Hans

Re: [PATCH v2 1/4] platform/x86: simatic-ipc: add main driver for Siemens devices

[Hans de Goede]

Hi,

On 3/17/21 8:13 PM, Henning Schild wrote:
> Am Mon, 15 Mar 2021 12:31:11 +0200
> schrieb Andy Shevchenko :
> 
>> On Mon, Mar 15, 2021 at 12:02 PM Henning Schild
>>  wrote:
>>>
>>> This mainly implements detection of these devices and will allow
>>> secondary drivers to work on such machines.
>>>
>>> The identification is DMI-based with a vendor specific way to tell
>>> them apart in a reliable way.
>>>
>>> Drivers for LEDs and Watchdogs will follow to make use of that
>>> platform detection.  
>>
>> ...
>>
>>> +static int register_platform_devices(u32 station_id)
>>> +{
>>> +   u8 ledmode = SIMATIC_IPC_DEVICE_NONE;
>>> +   u8 wdtmode = SIMATIC_IPC_DEVICE_NONE;
>>> +   int i;
>>> +
>>> +   platform_data.devmode = SIMATIC_IPC_DEVICE_NONE;
>>> +
>>> +   for (i = 0; i < ARRAY_SIZE(device_modes); i++) {
>>> +   if (device_modes[i].station_id == station_id) {
>>> +   ledmode = device_modes[i].led_mode;
>>> +   wdtmode = device_modes[i].wdt_mode;
>>> +   break;
>>> +   }
>>> +   }
>>> +
>>> +   if (ledmode != SIMATIC_IPC_DEVICE_NONE) {
>>> +   platform_data.devmode = ledmode;
>>> +   ipc_led_platform_device =
>>> +   platform_device_register_data(NULL,
>>> +   KBUILD_MODNAME "_leds",
>>> PLATFORM_DEVID_NONE,
>>> +   _data,
>>> +   sizeof(struct
>>> simatic_ipc_platform));
>>> +   if (IS_ERR(ipc_led_platform_device))
>>> +   return PTR_ERR(ipc_led_platform_device);
>>> +
>>> +   pr_debug("device=%s created\n",
>>> +ipc_led_platform_device->name);
>>> +   }
>>> +
>>> +   if (wdtmode != SIMATIC_IPC_DEVICE_NONE) {
>>> +   platform_data.devmode = wdtmode;
>>> +   ipc_wdt_platform_device =
>>> +   platform_device_register_data(NULL,
>>> +   KBUILD_MODNAME "_wdt",
>>> PLATFORM_DEVID_NONE,
>>> +   _data,
>>> +   sizeof(struct
>>> simatic_ipc_platform));
>>> +   if (IS_ERR(ipc_wdt_platform_device))
>>> +   return PTR_ERR(ipc_wdt_platform_device);
>>> +
>>> +   pr_debug("device=%s created\n",
>>> +ipc_wdt_platform_device->name);
>>> +   }
>>> +
>>> +   if (ledmode == SIMATIC_IPC_DEVICE_NONE &&
>>> +   wdtmode == SIMATIC_IPC_DEVICE_NONE) {
>>> +   pr_warn("unsupported IPC detected, station
>>> id=%08x\n",
>>> +   station_id);
>>> +   return -EINVAL;
>>> +   }
>>> +
>>> +   return 0;
>>> +}  
>>
>> Why not use MFD here?
> 
> Never had a close look at mfd to be honest. I might
> 
> With the custom dmi matching on 129 being part of the header, and the
> p2sb unhide moving out as well ... that first driver ends up being not
> too valuable indeed
> 
> It just identifies the box and tells subsequent drivers which one it
> is, which watchdog and LED path to take. Moving the knowledge of which
> box has which LED/watchdog into the respective drivers seems to be the
> better way to go.
> 
> So we would end up with a LED and a watchdog driver both
> MODULE_ALIAS("dmi:*:svnSIEMENSAG:*");
> and doing the identification with the inline dmi from that header,
> doing p2sb with the support to come ... possibly a "//TODO\ninline" in
> the meantime.
> 
> So no "main platform" driver anymore, but still central platform
> headers.
> 
> Not sure how this sounds, but i think making that change should be
> possible. And that is what i will try and go for in v3.

Dropping the main drivers/platform/x86 driver sounds good to me,
I was already wondering a bit about its function since it just
instantiates devs to which the other ones bind to then instantiate
more devs (in the LED case).

Regards,

Hans


>> ...
>>
>>> +/*
>>> + * Get membase address from PCI, used in leds and wdt modul. Here
>>> we read
>>> + * the bar0. The final address calculation is done in the
>>> appropriate modules
>>> + */  
>>
>> No blank line here.
>>
>> I would add FIXME or REVISIT here to point out that this should be
>> deduplicated in the future.
>>
>>> +u32 simatic_ipc_get_membase0(unsigned int p2sb)
>>> +{
>>> +   struct pci_bus *bus;
>>> +   u32 bar0 = 0;
>>> +
>>> +   /*
>>> +* The GPIO memory is bar0 of the hidden P2SB device.
>>> Unhide the device  
>>
>> No, it's not a GPIO's bar. It's P2SB's one. GPIO resides in that bar
>> somewhere.
>>
>>> +* to have a quick look at it, before we hide it again.
>>> +* Also grab the pci rescan lock so that device does not
>>> get discovered
>>> +* and remapped while it is visible.
>>> +* This code is inspired by drivers/mfd/lpc_ich.c
>>> +*/
>>> +   bus = pci_find_bus(0, 0);
>>> +   

Re: [PATCH 0/2] HID: Add support for Surface Aggregator Module HID transport

[Hans de Goede]

Hi,

On 3/10/21 11:53 PM, Maximilian Luz wrote:
> This series adds support for the Surface System Aggregator Module (SSAM)
> HID transport subsystem.
> 
> The SSAM is an embedded controller, found on 5th- and later generation
> Microsoft Surface devices. On some of these devices (specifically
> Surface Laptops 1, 2, and 3, as well as Surface Book 3), built-in input
> devices are connected via the SSAM. These devices communicate (mostly)
> via normal HID reports, so adding support for them is (mostly) just a
> matter of implementing an HID transport driver.
> 
> SSAM actually has two different HID interfaces: One (legacy) interface
> used on Surface Laptops 1 and 2, and a newer interface for the rest. The
> newer interface allows for multiple HID devices to be addressed and is
> implemented in the first patch. The older interface only allows a single
> HID device to be connected and, furthermore, only allows a single output
> report, specifically one for the caps lock LED. This is implemented in
> the second patch.
> 
> See the commit messages of the respective patches for more details.
> 
> Regards,
> Max
> 
> Note: This patch depends on the
> 
> platform/surface: Add Surface Aggregator device registry
> 
> series. More specifically patch
> 
> platform/surface: Set up Surface Aggregator device registry
> 
> The full series has been merged into the for-next branch of the
> platform-drivers-x86 tree [1]. The commit in question can be found at
> [2].
> 
> [1]: 
> https://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86.git/log/?h=for-next
> [2]: 
> https://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86.git/commit/?h=for-next=fc622b3d36e6d91330fb21506b9ad1e3206a4dde

Jiri, I'll prepare an immutable branch with the necessary pdx86 pre-reqs for 
this
and I'll send you a pull-req for that IM branch, then you can merge these
through the HID tree after merging that pull-req.

Regards,

Hans



> 
> Maximilian Luz (2):
>   HID: Add support for Surface Aggregator Module HID transport
>   HID: surface-hid: Add support for legacy keyboard interface
> 
>  MAINTAINERS|   7 +
>  drivers/hid/Kconfig|   2 +
>  drivers/hid/Makefile   |   2 +
>  drivers/hid/surface-hid/Kconfig|  42 +++
>  drivers/hid/surface-hid/Makefile   |   7 +
>  drivers/hid/surface-hid/surface_hid.c  | 253 +
>  drivers/hid/surface-hid/surface_hid_core.c | 272 +++
>  drivers/hid/surface-hid/surface_hid_core.h |  77 ++
>  drivers/hid/surface-hid/surface_kbd.c  | 300 +
>  9 files changed, 962 insertions(+)
>  create mode 100644 drivers/hid/surface-hid/Kconfig
>  create mode 100644 drivers/hid/surface-hid/Makefile
>  create mode 100644 drivers/hid/surface-hid/surface_hid.c
>  create mode 100644 drivers/hid/surface-hid/surface_hid_core.c
>  create mode 100644 drivers/hid/surface-hid/surface_hid_core.h
>  create mode 100644 drivers/hid/surface-hid/surface_kbd.c
> 

Re: [PATCH 0/2] power: supply: Add battery and AC drivers for Surface devices

[Hans de Goede]

Hi,

On 3/17/21 6:47 PM, Maximilian Luz wrote:
> On 3/17/21 6:39 PM, Hans de Goede wrote:
>> Hi,
>>
>> On 3/9/21 1:05 AM, Maximilian Luz wrote:
>>> This series provides battery and AC drivers for Microsoft Surface
>>> devices, where this information is provided via an embedded controller
>>> (the Surface System Aggregator Module, SSAM) instead of the usual ACPI
>>> interface.
>>>
>>> Specifically, 7th generation Surface devices, i.e. Surface Pro 7,
>>> Surface Book 3, Surface Laptop 3, as well as the Surface Laptop Go use
>>> this new interface.
>>>
>>> Note: This series depends on the
>>>
>>>  platform/surface: Add Surface Aggregator device registry
>>>
>>> series. More specifically patch
>>>
>>>  platform/surface: Set up Surface Aggregator device registry
>>>
>>> The full series has been merged into the for-next branch of the
>>> platform-drivers-x86 tree [1]. The commit in question can be found at
>>> [2].
>>>
>>> [1]: 
>>> https://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86.git/log/?h=for-next
>>> [2]: 
>>> https://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86.git/commit/?h=for-next=fc622b3d36e6d91330fb21506b9ad1e3206a4dde
>>
>> Sebastian, I guess you want a pull-req from an immutable branch from me for
>> that dependend commit and then you will merge these 2 patches ?
>>
>> Maximillian, this only needs that commit right, or would it be better if
>> I send Sebastian a pull-req for a branch with the entire series?
> 
> The entire series would be better, I think.
> 
> Strictly speaking, it only requires the mentioned commit to compile
> successfully, but if anyone would want to test this they'd need the full
> series (or at least the battery/power subsystem commit) due to the
> device instantiation.

Ack, I think the whole series makes the most sense too, so I will
prepare a pull-req for that.

> Same reasoning applies to the HID series.

Ack.

Regards,

Hans

Re: [PATCH] platform/surface: aggregator_registry: Add support for Surface Pro 7+

[Hans de Goede]

Hi,

On 3/9/21 5:25 PM, Maximilian Luz wrote:
> The Surface Pro 7+ is essentially a refresh of the Surface Pro 7 with
> updated hardware and a new WSID identifier.
> 
> Signed-off-by: Maximilian Luz 

Thank you for your patch, I've applied this patch to my review-hans 
branch:
https://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86.git/log/?h=review-hans

Note it will show up in my review-hans branch once I've pushed my
local branch there, which might take a while.

Once I've run some tests on this branch the patches there will be
added to the platform-drivers-x86/for-next branch and eventually
will be included in the pdx86 pull-request to Linus for the next
merge-window.

Regards,

Hans



> ---
>  drivers/platform/surface/surface_aggregator_registry.c | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/platform/surface/surface_aggregator_registry.c 
> b/drivers/platform/surface/surface_aggregator_registry.c
> index cdb4a95af3e8..c42b97f61a57 100644
> --- a/drivers/platform/surface/surface_aggregator_registry.c
> +++ b/drivers/platform/surface/surface_aggregator_registry.c
> @@ -191,7 +191,7 @@ static const struct software_node *ssam_node_group_sp6[] 
> = {
>   NULL,
>  };
>  
> -/* Devices for Surface Pro 7. */
> +/* Devices for Surface Pro 7 and Surface Pro 7+. */
>  static const struct software_node *ssam_node_group_sp7[] = {
>   _node_root,
>   _node_bat_ac,
> @@ -521,6 +521,9 @@ static const struct acpi_device_id 
> ssam_platform_hub_match[] = {
>   /* Surface Pro 7 */
>   { "MSHW0116", (unsigned long)ssam_node_group_sp7 },
>  
> + /* Surface Pro 7+ */
> + { "MSHW0119", (unsigned long)ssam_node_group_sp7 },
> +
>   /* Surface Book 2 */
>   { "MSHW0107", (unsigned long)ssam_node_group_sb2 },
>  
> 

Re: [PATCH 0/3] platform/surface: Add DTX detachment system driver

[Hans de Goede]

Hi,

On 3/8/21 7:48 PM, Maximilian Luz wrote:
> The Microsoft Surface Book series devices consist of a so-called
> clipboard part (containing the CPU, touchscreen, and primary battery)
> and a base part (containing keyboard, secondary battery, and optional
> discrete GPU). These parts can be separated, i.e. the clipboard can be
> detached and used as tablet.
> 
> This detachment process is managed by a subsystem of the Surface System
> Aggregator Module (SSAM). As that process is a bit more complex, i.e.
> can involve user interaction, it seems the best way to implement this is
> to provide a somewhat cleaned-up version of this interface to userspace.
> 
> This series adds a driver (and documentation) for the detachment system
> which provides such an interface. See the commit message of the first
> patch for more details and a link to a user-space daemon using this
> interface. Support for the Surface Book 3 is added in patch 2,
> user-space API documentation in patch 3.

Thank you for your patch-series, I've applied the series to my
review-hans branch:
https://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86.git/log/?h=review-hans

Note it will show up in my review-hans branch once I've pushed my
local branch there, which might take a while.

Once I've run some tests on this branch the patches there will be
added to the platform-drivers-x86/for-next branch and eventually
will be included in the pdx86 pull-request to Linus for the next
merge-window.

Regards,

Hans


> 
> Regards,
> Max
> 
> Maximilian Luz (3):
>   platform/surface: Add DTX driver
>   platform/surface: dtx: Add support for native SSAM devices
>   docs: driver-api: Add Surface DTX driver documentation
> 
>  .../surface_aggregator/clients/dtx.rst|  718 +
>  .../surface_aggregator/clients/index.rst  |1 +
>  .../userspace-api/ioctl/ioctl-number.rst  |2 +
>  MAINTAINERS   |8 +
>  drivers/platform/surface/Kconfig  |   20 +
>  drivers/platform/surface/Makefile |1 +
>  drivers/platform/surface/surface_dtx.c| 1289 +
>  include/uapi/linux/surface_aggregator/dtx.h   |  146 ++
>  8 files changed, 2185 insertions(+)
>  create mode 100644 
> Documentation/driver-api/surface_aggregator/clients/dtx.rst
>  create mode 100644 drivers/platform/surface/surface_dtx.c
>  create mode 100644 include/uapi/linux/surface_aggregator/dtx.h
> 

Re: [PATCH 0/2] power: supply: Add battery and AC drivers for Surface devices

[Hans de Goede]

Hi,

On 3/9/21 1:05 AM, Maximilian Luz wrote:
> This series provides battery and AC drivers for Microsoft Surface
> devices, where this information is provided via an embedded controller
> (the Surface System Aggregator Module, SSAM) instead of the usual ACPI
> interface.
> 
> Specifically, 7th generation Surface devices, i.e. Surface Pro 7,
> Surface Book 3, Surface Laptop 3, as well as the Surface Laptop Go use
> this new interface.
> 
> Note: This series depends on the
> 
> platform/surface: Add Surface Aggregator device registry
> 
> series. More specifically patch
> 
> platform/surface: Set up Surface Aggregator device registry
> 
> The full series has been merged into the for-next branch of the
> platform-drivers-x86 tree [1]. The commit in question can be found at
> [2].
> 
> [1]: 
> https://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86.git/log/?h=for-next
> [2]: 
> https://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86.git/commit/?h=for-next=fc622b3d36e6d91330fb21506b9ad1e3206a4dde

Sebastian, I guess you want a pull-req from an immutable branch from me for
that dependend commit and then you will merge these 2 patches ?

Maximillian, this only needs that commit right, or would it be better if
I send Sebastian a pull-req for a branch with the entire series?

Regards,

Hans





> 
> Maximilian Luz (2):
>   power: supply: Add battery driver for Surface Aggregator Module
>   power: supply: Add AC driver for Surface Aggregator Module
> 
>  MAINTAINERS|   8 +
>  drivers/power/supply/Kconfig   |  32 +
>  drivers/power/supply/Makefile  |   2 +
>  drivers/power/supply/surface_battery.c | 901 +
>  drivers/power/supply/surface_charger.c | 296 
>  5 files changed, 1239 insertions(+)
>  create mode 100644 drivers/power/supply/surface_battery.c
>  create mode 100644 drivers/power/supply/surface_charger.c
> 

Re: AHCI SATA Runtime PM

[Hans de Goede]

Hi,

On 3/4/21 4:34 PM, Alexander Monakov wrote:
> Hello, Hans, Linux PM folks,
> 
> I'm looking for clarification regarding this patch discussion:
> 
> https://patchwork.kernel.org/project/linux-pm/patch/20180420101834.15783-2-0v3rdr...@gmail.com/
> 
> Hans said,
> 
>> Ah, so the AHCI code has runtime pm enabled by default (so there
>> is another pm_runtime_allow() somewhere, but then disables it for
>> unused ports to make hotpluging something into those ports work.
> 
> I have a laptop where two unused AHCI SATA controllers are present (but
> obviously nothing can be hotplugged into them). Apparently due to the above,
> they do not enter runtime autosuspend.
> 
> The problem is, these "ATA port" nodes don't seem to participate in udev
> hierarchy, so it's unclear how I'm supposed to automatically re-enable
> runtime PM for them. For PCI device nodes, I have
> 
> ACTION=="add", SUBSYSTEM=="pci", TEST=="power/control", 
> ATTR{power/control}="auto"
> 
> but ata1/uevent is empty, so there's no obvious way to write the corresponding
> UDev rule.

You can enable runtime-pm from udev using the following rule:

ACTION=="add", SUBSYSTEM=="ata_port", ATTR{../../power/control}="auto"

> Prior to discovering the above patch discussion, I have filed a bug:
> https://bugzilla.kernel.org/show_bug.cgi?id=211837
> 
> Does the above correctly reflect how AHCI PM is supposed to be?

This is a complicated question, I just checked and according to:
https://www.intel.com/content/www/us/en/io/serial-ata/serial-ata-ahci-spec-rev1-3-1.html

AHCI 1.3 compliant controllers should raise a PME signal on hotplug
changes even when in D3. So perhaps the solution is to catch this signal
and then wakeup the controller; and remove the pm_runtime_forbid(dev); call
from ata_tport_add().

I don't have much experience with dealing with the PME stuff, so you will
need to do some research there, or perhaps someone else can help?

This seems to be more of a sata/ahci question then a generic linux-pm question
though, so I have added Jebns and linux-ide to the To / Cc.

> If so, what is
> the proper way to enable runtime PM for unused ATA ports?

Regards,

Hans

Re: [PATCH] platform/x86: pmc_atom: use callback for all dmi quirk entries

[Hans de Goede]

Hi Henning,

On 3/16/21 6:47 AM, Henning Schild wrote:
> Hoi Hans,
> 
> on a slighly different but also related topic. Did you ever come across
> SMSC SCH5347? Seems to be pretty similar to 56xx, only with spec non
> public ... and probably less often in use
> Maybe you happen to have code, or know the differences. We already have
> it working with a modified copy of sch56xx but that is still rough and
> i thought i ask before we potentially duplicate work.

The history of FSC (Fujitsu-Siemens Computers) sensor support goes something
like this:

1. The university which I worked at had picked a FSC machine for the
replacement of all workstations, the FSCXXX sensor chip it had was i2c based,
so I could relatively easy reverse-engineer it and wrote a driver.

2. Around the time I stopped working for the university and started working
for Red Hat (2008) FSC contacted me and asked me if I wanted to help them
with officially supporting the FSC and later the SCH devices. They provided
test hardware and documentation at this time.

3. This continued for a while when FSC became just "Fujitsu" and things
moved from the FSC i2c based chips to the super-io based SCH chips. After
a while Fujitsu stopped contacting me about new chips and I stopped working
on this.

So ATM I'm not working no SCH56xx support and I've not worked on that for
quite some time now. So it is good to hear that you will be contributing
SCH5347 support to the kernel.

Regards,

Hans






> Am Mon, 15 Mar 2021 19:01:13 +0100
> schrieb Hans de Goede :
> 
>> Hi,
>>
>> On 3/15/21 6:00 PM, Henning Schild wrote:
>>> Am Mon, 15 Mar 2021 17:31:49 +0100
>>> schrieb Hans de Goede :
>>>   
>>>> Hi,
>>>>
>>>> On 3/15/21 3:58 PM, Henning Schild wrote:  
>>>>> Introduce a global variable to remember the matching entry for
>>>>> later printing. Also having a callback allows to stop matching
>>>>> after the first hit.
>>>>>
>>>>> Signed-off-by: Henning Schild 
>>>>> ---
>>>>>  drivers/platform/x86/pmc_atom.c | 26 --
>>>>>  1 file changed, 20 insertions(+), 6 deletions(-)
>>>>>
>>>>> diff --git a/drivers/platform/x86/pmc_atom.c
>>>>> b/drivers/platform/x86/pmc_atom.c index 38542d547f29..d0f74856cd8b
>>>>> 100644 --- a/drivers/platform/x86/pmc_atom.c
>>>>> +++ b/drivers/platform/x86/pmc_atom.c
>>>>> @@ -364,8 +364,16 @@ static void pmc_dbgfs_register(struct pmc_dev
>>>>> *pmc) #endif /* CONFIG_DEBUG_FS */
>>>>>  
>>>>>  static bool pmc_clk_is_critical = true;
>>>>> +static const struct dmi_system_id *dmi_critical;
>>>>>  
>>>>> -static int siemens_clk_is_critical(const struct dmi_system_id *d)
>>>>> +static int dmi_callback(const struct dmi_system_id *d)
>>>>> +{
>>>>> + dmi_critical = d;
>>>>
>>>> Don't introduce a global variable for this please. Instead just
>>>> directly print the ident of the matching dmi_system_id here.  
>>>
>>> Sorry, missed that part. Result looks nice and clean, thanks. I
>>> think i will squash it into 4/4 in v3 and not follow up here for
>>> now.  
>>
>> Ack, that sounds good to me.
>>
>> Regards,
>>
>> Hans
>>
>>
>>>>> +
>>>>> + return 1;
>>>>> +}
>>>>> +
>>>>> +static int dmi_callback_siemens(const struct dmi_system_id *d)
>>>>>  {
>>>>>   u32 st_id;
>>>>>  
>>>>> @@ -373,7 +381,7 @@ static int siemens_clk_is_critical(const
>>>>> struct dmi_system_id *d) goto out;
>>>>>  
>>>>>   if (st_id == SIMATIC_IPC_IPC227E || st_id ==
>>>>> SIMATIC_IPC_IPC277E)
>>>>> - return 1;
>>>>> + return dmi_callback(d);
>>>>>  
>>>>>  out:
>>>>>   pmc_clk_is_critical = false;
>>>>> @@ -388,6 +396,7 @@ static const struct dmi_system_id
>>>>> critclk_systems[] = { {
>>>>>   /* pmc_plt_clk0 is used for an external HSIC USB
>>>>> HUB */ .ident = "MPL CEC1x",
>>>>> + .callback = dmi_callback,
>>>>>   .matches = {
>>>>>   DMI_MATCH(DMI_SYS_VENDOR, "MPL AG"),
>>>>>   DMI_MATCH(DMI_PRODUCT_NAME, "CEC10
>>>>> Family"), @@ -396,6 +405,7 @@ static const struct 

Re: [PATCH] platform/x86: pmc_atom: use callback for all dmi quirk entries

[Hans de Goede]

Hi,

On 3/15/21 6:00 PM, Henning Schild wrote:
> Am Mon, 15 Mar 2021 17:31:49 +0100
> schrieb Hans de Goede :
> 
>> Hi,
>>
>> On 3/15/21 3:58 PM, Henning Schild wrote:
>>> Introduce a global variable to remember the matching entry for later
>>> printing. Also having a callback allows to stop matching after the
>>> first hit.
>>>
>>> Signed-off-by: Henning Schild 
>>> ---
>>>  drivers/platform/x86/pmc_atom.c | 26 --
>>>  1 file changed, 20 insertions(+), 6 deletions(-)
>>>
>>> diff --git a/drivers/platform/x86/pmc_atom.c
>>> b/drivers/platform/x86/pmc_atom.c index 38542d547f29..d0f74856cd8b
>>> 100644 --- a/drivers/platform/x86/pmc_atom.c
>>> +++ b/drivers/platform/x86/pmc_atom.c
>>> @@ -364,8 +364,16 @@ static void pmc_dbgfs_register(struct pmc_dev
>>> *pmc) #endif /* CONFIG_DEBUG_FS */
>>>  
>>>  static bool pmc_clk_is_critical = true;
>>> +static const struct dmi_system_id *dmi_critical;
>>>  
>>> -static int siemens_clk_is_critical(const struct dmi_system_id *d)
>>> +static int dmi_callback(const struct dmi_system_id *d)
>>> +{
>>> +   dmi_critical = d;  
>>
>> Don't introduce a global variable for this please. Instead just
>> directly print the ident of the matching dmi_system_id here.
> 
> Sorry, missed that part. Result looks nice and clean, thanks. I think i
> will squash it into 4/4 in v3 and not follow up here for now.

Ack, that sounds good to me.

Regards,

Hans


>>> +
>>> +   return 1;
>>> +}
>>> +
>>> +static int dmi_callback_siemens(const struct dmi_system_id *d)
>>>  {
>>> u32 st_id;
>>>  
>>> @@ -373,7 +381,7 @@ static int siemens_clk_is_critical(const struct
>>> dmi_system_id *d) goto out;
>>>  
>>> if (st_id == SIMATIC_IPC_IPC227E || st_id ==
>>> SIMATIC_IPC_IPC277E)
>>> -   return 1;
>>> +   return dmi_callback(d);
>>>  
>>>  out:
>>> pmc_clk_is_critical = false;
>>> @@ -388,6 +396,7 @@ static const struct dmi_system_id
>>> critclk_systems[] = { {
>>> /* pmc_plt_clk0 is used for an external HSIC USB
>>> HUB */ .ident = "MPL CEC1x",
>>> +   .callback = dmi_callback,
>>> .matches = {
>>> DMI_MATCH(DMI_SYS_VENDOR, "MPL AG"),
>>> DMI_MATCH(DMI_PRODUCT_NAME, "CEC10
>>> Family"), @@ -396,6 +405,7 @@ static const struct dmi_system_id
>>> critclk_systems[] = { {
>>> /* pmc_plt_clk0 - 3 are used for the 4 ethernet
>>> controllers */ .ident = "Lex 3I380D",
>>> +   .callback = dmi_callback,
>>> .matches = {
>>> DMI_MATCH(DMI_SYS_VENDOR, "Lex BayTrail"),
>>> DMI_MATCH(DMI_PRODUCT_NAME, "3I380D"),
>>> @@ -404,6 +414,7 @@ static const struct dmi_system_id
>>> critclk_systems[] = { {
>>> /* pmc_plt_clk* - are used for ethernet
>>> controllers */ .ident = "Lex 2I385SW",
>>> +   .callback = dmi_callback,
>>> .matches = {
>>> DMI_MATCH(DMI_SYS_VENDOR, "Lex BayTrail"),
>>> DMI_MATCH(DMI_PRODUCT_NAME, "2I385SW"),
>>> @@ -412,6 +423,7 @@ static const struct dmi_system_id
>>> critclk_systems[] = { {
>>> /* pmc_plt_clk* - are used for ethernet
>>> controllers */ .ident = "Beckhoff CB3163",
>>> +   .callback = dmi_callback,
>>> .matches = {
>>> DMI_MATCH(DMI_SYS_VENDOR, "Beckhoff
>>> Automation"), DMI_MATCH(DMI_BOARD_NAME, "CB3163"),
>>> @@ -420,6 +432,7 @@ static const struct dmi_system_id
>>> critclk_systems[] = { {
>>> /* pmc_plt_clk* - are used for ethernet
>>> controllers */ .ident = "Beckhoff CB4063",
>>> +   .callback = dmi_callback,
>>> .matches = {
>>> DMI_MATCH(DMI_SYS_VENDOR, "Beckhoff
>>> Automation"), DMI_MATCH(DMI_BOARD_NAME, "CB4063"),
>>> @@ -428,6 +441,7 @@ static const struct dmi_system_id
>>> critclk_systems[] = { {
>>> /* pmc_plt_clk* - are used for ethernet
>>> controllers */ .ident = "Beckhoff CB6263",
>>> +   .callback = dmi_

Re: [PATCH] platform/x86: pmc_atom: use callback for all dmi quirk entries

[Hans de Goede]

Hi,

On 3/15/21 3:58 PM, Henning Schild wrote:
> Introduce a global variable to remember the matching entry for later
> printing. Also having a callback allows to stop matching after the first
> hit.
> 
> Signed-off-by: Henning Schild 
> ---
>  drivers/platform/x86/pmc_atom.c | 26 --
>  1 file changed, 20 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/platform/x86/pmc_atom.c b/drivers/platform/x86/pmc_atom.c
> index 38542d547f29..d0f74856cd8b 100644
> --- a/drivers/platform/x86/pmc_atom.c
> +++ b/drivers/platform/x86/pmc_atom.c
> @@ -364,8 +364,16 @@ static void pmc_dbgfs_register(struct pmc_dev *pmc)
>  #endif /* CONFIG_DEBUG_FS */
>  
>  static bool pmc_clk_is_critical = true;
> +static const struct dmi_system_id *dmi_critical;
>  
> -static int siemens_clk_is_critical(const struct dmi_system_id *d)
> +static int dmi_callback(const struct dmi_system_id *d)
> +{
> + dmi_critical = d;

Don't introduce a global variable for this please. Instead just directly
print the ident of the matching dmi_system_id here.

Regards,

Hans


> +
> + return 1;
> +}
> +
> +static int dmi_callback_siemens(const struct dmi_system_id *d)
>  {
>   u32 st_id;
>  
> @@ -373,7 +381,7 @@ static int siemens_clk_is_critical(const struct 
> dmi_system_id *d)
>   goto out;
>  
>   if (st_id == SIMATIC_IPC_IPC227E || st_id == SIMATIC_IPC_IPC277E)
> - return 1;
> + return dmi_callback(d);
>  
>  out:
>   pmc_clk_is_critical = false;
> @@ -388,6 +396,7 @@ static const struct dmi_system_id critclk_systems[] = {
>   {
>   /* pmc_plt_clk0 is used for an external HSIC USB HUB */
>   .ident = "MPL CEC1x",
> + .callback = dmi_callback,
>   .matches = {
>   DMI_MATCH(DMI_SYS_VENDOR, "MPL AG"),
>   DMI_MATCH(DMI_PRODUCT_NAME, "CEC10 Family"),
> @@ -396,6 +405,7 @@ static const struct dmi_system_id critclk_systems[] = {
>   {
>   /* pmc_plt_clk0 - 3 are used for the 4 ethernet controllers */
>   .ident = "Lex 3I380D",
> + .callback = dmi_callback,
>   .matches = {
>   DMI_MATCH(DMI_SYS_VENDOR, "Lex BayTrail"),
>   DMI_MATCH(DMI_PRODUCT_NAME, "3I380D"),
> @@ -404,6 +414,7 @@ static const struct dmi_system_id critclk_systems[] = {
>   {
>   /* pmc_plt_clk* - are used for ethernet controllers */
>   .ident = "Lex 2I385SW",
> + .callback = dmi_callback,
>   .matches = {
>   DMI_MATCH(DMI_SYS_VENDOR, "Lex BayTrail"),
>   DMI_MATCH(DMI_PRODUCT_NAME, "2I385SW"),
> @@ -412,6 +423,7 @@ static const struct dmi_system_id critclk_systems[] = {
>   {
>   /* pmc_plt_clk* - are used for ethernet controllers */
>   .ident = "Beckhoff CB3163",
> + .callback = dmi_callback,
>   .matches = {
>   DMI_MATCH(DMI_SYS_VENDOR, "Beckhoff Automation"),
>   DMI_MATCH(DMI_BOARD_NAME, "CB3163"),
> @@ -420,6 +432,7 @@ static const struct dmi_system_id critclk_systems[] = {
>   {
>   /* pmc_plt_clk* - are used for ethernet controllers */
>   .ident = "Beckhoff CB4063",
> + .callback = dmi_callback,
>   .matches = {
>   DMI_MATCH(DMI_SYS_VENDOR, "Beckhoff Automation"),
>   DMI_MATCH(DMI_BOARD_NAME, "CB4063"),
> @@ -428,6 +441,7 @@ static const struct dmi_system_id critclk_systems[] = {
>   {
>   /* pmc_plt_clk* - are used for ethernet controllers */
>   .ident = "Beckhoff CB6263",
> + .callback = dmi_callback,
>   .matches = {
>   DMI_MATCH(DMI_SYS_VENDOR, "Beckhoff Automation"),
>   DMI_MATCH(DMI_BOARD_NAME, "CB6263"),
> @@ -436,13 +450,14 @@ static const struct dmi_system_id critclk_systems[] = {
>   {
>   /* pmc_plt_clk* - are used for ethernet controllers */
>   .ident = "Beckhoff CB6363",
> + .callback = dmi_callback,
>   .matches = {
>   DMI_MATCH(DMI_SYS_VENDOR, "Beckhoff Automation"),
>   DMI_MATCH(DMI_BOARD_NAME, "CB6363"),
>   },
>   },
>   {
> - .callback = siemens_clk_is_critical,
> + .callback = dmi_callback_siemens,
>   .ident = "SIEMENS AG",
>   .matches = {
>   DMI_MATCH(DMI_SYS_VENDOR, "SIEMENS AG"),
> @@ -457,7 +472,6 @@ static int pmc_setup_clks(struct pci_dev *pdev, void 
> __iomem *pmc_regmap,
>  {
>   struct platform_device *clkdev;
>   struct pmc_clk_data *clk_data;
> - const struct dmi_system_id *d;
>  
>   clk_data = kzalloc(sizeof(*clk_data), GFP_KERNEL);
>   if (!clk_data)
> @@ -468,8 +482,8 @@ static int pmc_setup_clks(struct 

Re: [PATCH v2 4/4] platform/x86: pmc_atom: improve critclk_systems matching for Siemens PCs

[Hans de Goede]

Hi,

On 3/15/21 11:14 AM, Henning Schild wrote:
> Am Mon, 15 Mar 2021 10:57:10 +0100
> schrieb Henning Schild :
> 
>> Siemens industrial PCs unfortunately can not always be properly
>> identified the way we used to. An earlier commit introduced code that
>> allows proper identification without looking at DMI strings that could
>> differ based on product branding.
>> Switch over to that proper way and revert commits that used to collect
>> the machines based on unstable strings.
>>
>> Fixes: 648e921888ad ("clk: x86: Stop marking clocks as
>> CLK_IS_CRITICAL") Fixes: e8796c6c69d1 ("platform/x86: pmc_atom: Add
>> Siemens CONNECT ...") Fixes: f110d252ae79 ("platform/x86: pmc_atom:
>> Add Siemens SIMATIC ...") Fixes: ad0d315b4d4e ("platform/x86:
>> pmc_atom: Add Siemens SIMATIC ...") Tested-by: Michael Haener
>>  Signed-off-by: Henning Schild
>>  ---
>>  drivers/platform/x86/pmc_atom.c | 47
>> +++-- 1 file changed, 27 insertions(+),
>> 20 deletions(-)
>>
>> diff --git a/drivers/platform/x86/pmc_atom.c
>> b/drivers/platform/x86/pmc_atom.c index ca684ed760d1..38542d547f29
>> 100644 --- a/drivers/platform/x86/pmc_atom.c
>> +++ b/drivers/platform/x86/pmc_atom.c
>> @@ -13,6 +13,7 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>>  #include 
>>  #include 
>>  #include 
>> @@ -362,6 +363,23 @@ static void pmc_dbgfs_register(struct pmc_dev
>> *pmc) }
>>  #endif /* CONFIG_DEBUG_FS */
>>  
>> +static bool pmc_clk_is_critical = true;
>> +
>> +static int siemens_clk_is_critical(const struct dmi_system_id *d)
>> +{
>> +u32 st_id;
>> +
>> +if (dmi_walk(simatic_ipc_find_dmi_entry_helper, _id))
>> +goto out;
>> +
>> +if (st_id == SIMATIC_IPC_IPC227E || st_id ==
>> SIMATIC_IPC_IPC277E)
>> +return 1;
>> +
>> +out:
>> +pmc_clk_is_critical = false;
>> +return 1;
>> +}
>> +
>>  /*
>>   * Some systems need one or more of their pmc_plt_clks to be
>>   * marked as critical.
>> @@ -424,24 +442,10 @@ static const struct dmi_system_id
>> critclk_systems[] = { },
>>  },
>>  {
>> -.ident = "SIMATIC IPC227E",
>> -.matches = {
>> -DMI_MATCH(DMI_SYS_VENDOR, "SIEMENS AG"),
>> -DMI_MATCH(DMI_PRODUCT_VERSION, "6ES7647-8B"),
>> -},
>> -},
>> -{
>> -.ident = "SIMATIC IPC277E",
>> -.matches = {
>> -DMI_MATCH(DMI_SYS_VENDOR, "SIEMENS AG"),
>> -DMI_MATCH(DMI_PRODUCT_VERSION, "6AV7882-0"),
>> -},
>> -},
>> -{
>> -.ident = "CONNECT X300",
>> +.callback = siemens_clk_is_critical,
>> +.ident = "SIEMENS AG",
>>  .matches = {
>>  DMI_MATCH(DMI_SYS_VENDOR, "SIEMENS AG"),
>> -DMI_MATCH(DMI_PRODUCT_VERSION,
>> "A5E45074588"), },
>>  },
>>  
>> @@ -453,7 +457,7 @@ static int pmc_setup_clks(struct pci_dev *pdev,
>> void __iomem *pmc_regmap, {
>>  struct platform_device *clkdev;
>>  struct pmc_clk_data *clk_data;
>> -const struct dmi_system_id *d =
>> dmi_first_match(critclk_systems);
>> +const struct dmi_system_id *d;
>>  
>>  clk_data = kzalloc(sizeof(*clk_data), GFP_KERNEL);
>>  if (!clk_data)
>> @@ -461,9 +465,12 @@ static int pmc_setup_clks(struct pci_dev *pdev,
>> void __iomem *pmc_regmap, 
>>  clk_data->base = pmc_regmap; /* offset is added by client */
>>  clk_data->clks = pmc_data->clks;
>> -if (d) {
>> -clk_data->critical = true;
>> -pr_info("%s critclks quirk enabled\n", d->ident);
>> +if (dmi_check_system(critclk_systems)) {
> 
> Had to switch to check_system to get the callback to work.
> 
>> +clk_data->critical = pmc_clk_is_critical;
>> +if (clk_data->critical) {
>> +d = dmi_first_match(critclk_systems);
>> +pr_info("%s critclks quirk enabled\n",
>> d->ident);
> 
> Now need a double match here just to print the ident. Not too happy
> with that but proposing it like this to keep the ident printing.
> 
> I guess it could be improved by not printing the ident or having a
> global variable and global callback to remember the ident to print
> later. I would propose to not print the ident if the double-match does
> not find traction.

IMHO it would be best to add another callback for the non Siemens
entries which just prints the ideent and returns 1 to avoid needsly
looping over the rest of the array.

And then just set the callback member of all the non Siemens entries
to this new callback. The space for the callback pointer is already
reserved in the struct anyways, so actually setting it does not take
up any space.

Regards,

Hans

Re: [PATCH 1/2] ata: delete redundant printing of return value

[Hans de Goede]

Hi,

On 3/13/21 8:46 AM, Wang Qing wrote:
> platform_get_irq() has already checked and printed the return value, 
> the printing here is nothing special, it is not necessary at all.
> 
> Signed-off-by: Wang Qing 

Thanks, patch looks good to me:

Reviewed-by: Hans de Goede 

Regards,

Hans


> ---
>  drivers/ata/libahci_platform.c | 5 +
>  1 file changed, 1 insertion(+), 4 deletions(-)
> 
> diff --git a/drivers/ata/libahci_platform.c b/drivers/ata/libahci_platform.c
> index de638da..2e7ea75
> --- a/drivers/ata/libahci_platform.c
> +++ b/drivers/ata/libahci_platform.c
> @@ -582,11 +582,8 @@ int ahci_platform_init_host(struct platform_device *pdev,
>   int i, irq, n_ports, rc;
>  
>   irq = platform_get_irq(pdev, 0);
> - if (irq <= 0) {
> - if (irq != -EPROBE_DEFER)
> - dev_err(dev, "no irq\n");
> + if (irq <= 0)
>   return irq;
> - }
>  
>   hpriv->irq = irq;
>  
> 

Re: Logitech G602 wireless mouse kernel error messages in 5.10.11+ kernels

[Hans de Goede]

Hi,

On 3/10/21 9:55 PM, Filipe Laíns wrote:
> On Wed, 2021-03-10 at 15:24 -0500, Mark Hounschell wrote:
>>
>> That is correct, I don't have any buttons bound to keyboard events. With 
>> the original patch the G4(forward) and G5(Backward) buttons work in a 
>> browser. I guess G7, G8, and G9 buttons are programmable to keyboard events?
>>
>> However this patch does not seem to fix the messages I get.
>>
>> Regards
>> Mark
> 
> Those events belong to the USB HID button usage page and are sent by the
> receiver in the HID device with the unnumbered report descriptor, so they are
> not affected.
> 
> Looking at the report descriptor for the other HID device, I see a report ID 
> of
> 128 (0x80) used for a vendor application, I am not really sure what it is used
> for and can't seem to trigger my device to send it.
> 
> I am gonna guess this is the device reporting the pressed buttons via vendor
> reports or something like that. Speaking as the person who added support for
> this device in libratbag, this report is very likely not something that we 
> don't
> need in our custom drivers and just likely something extra that Logitech built
> to achieve something custom in the Windows driver. FWIW, this device is a very
> weird one, it does not even follow Logitech's own spec :P
> 
> Seeing this report the driver chugs.
> 
>   if (report > REPORT_TYPE_RFREPORT_LAST) {
>   hid_err(hdev, "Unexpected input report number %d\n", report);
>   return;
>   }
> 
> Causing your
> 
> [   36.471326] logitech-djreceiver 0003:046D:C537.0002: Unexpected input 
> report number 128
> [   36.565317] logitech-djreceiver 0003:046D:C537.0002: Unexpected input 
> report number 128
> [   42.390321] logitech-djreceiver 0003:046D:C537.0002: Unexpected input 
> report number 128
> 
> I feel like the correct fix for these cases is not to consume the report and 
> not
> forward it to device node, but rather to forward it to the receiver node.
> 
> (looping in Hans)
> Hans, you introduced this code, do you remember why? Where did
> REPORT_TYPE_RFREPORT_LAST get its value from and what is the purpose of this
> check?
> Shouldn't we just keep forwarding unknown reports to the receiver node? Is 
> there
> any technical limitation to do that? I am not too familiar with this part of 
> the
> code.

The code used by the recvr_type_gaming_hidpp receivers is shared with all the
other non-unifying receivers. Even though these receivers are not unifying the
non gaming versions may still have multiple devices (typically a keyboard + a 
mouse)
paired with them.

The standard HID interfaces which these devices emulate are usually split in
at least 2 HID interfaces:

1. A keyboard following the requirements of the "boot keyboard" subclass of the
USB HID class, so that the keyboard works inside say the BIOS setup screen.
This uses a single unnumbered HID report

2. A mouse + media-keys interface, which delivers numbered reports, including 
the
special Logitech HID++ reports for things like battery monitoring, but also some
special keys, which have their own sub-addressing embedded inside the reports.

The driver asks the receiver for a list of paired devices and then builts a list
of devices, which are then instantiated as child-HID devices which are
handled by the drivers/hid/hid-logitech-hidpp.c driver.

Any input reports received by drivers/hid/hid-logitech-dj.c are then forwarded
to the instantiated child devices, where they are actually processed.

The problem is that there is not a 1:1 relation between the interfaces and
the instantiated child-devices, so the driver aggregates all input-reports
from both interfaces together and then dispatches / forwards them to the
child-devices using its own internal addressing.

This forwarding uses 2 different addressing schemes:

1. If the report received is a special HID++ report, then it is forwarded to
paired-dev child-dev matching the HID++ device-index which is embedded
inside these special reports.

2. If a normal (unnumbered or numbered) report is received then that report is
forwarded based on the report-number.  What happens here is that each paired-dev
which the hid-logitech-dj.c code instantiates has a bitmask associated with it
which indicates which kind of reports it consumes. So e.g. a normal mouse will
only consume mouse input-reports (STD_MOUSE, report-id 2) and a keyboard
will consume all of:

#define STD_KEYBOARDBIT(1)
#define MULTIMEDIA  BIT(3)
#define POWER_KEYS  BIT(4)
#define MEDIA_CENTERBIT(8)
#define KBD_LEDSBIT(14)

When forwarding these normal (unnumbered or numbered) reports, the list of
paired devices is searched and the report is forwarded to the first paired-dev
which reports_supported bitmask includes the report-nr:

spin_lock_irqsave(_dev->lock, flags);
for (i = 0; i < (DJ_MAX_PAIRED_DEVICES 

Re: [GIT PULL] Immutable branch between MFD and Platform/X86 due for the v5.13 merge window

[Hans de Goede]

Hi Lee,

On 3/9/21 7:12 PM, Lee Jones wrote:
> Enjoy!
> 
> The following changes since commit fe07bfda2fb9cdef8a4d4008a409bb02f35f1bd8:
> 
>   Linux 5.12-rc1 (2021-02-28 16:05:19 -0800)

I thought we were supposed to avoid using 5.12-rc1 as a base to avoid people
hitting the swapfile related disk-corruption when bisecting?

See: https://lwn.net/Articles/848431/

So it might be better to redo this branch with 5.12-rc2 as a base ?

Regards,

Hans


> 
> are available in the Git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd.git 
> ib-mfd-platform-x86-v5.13
> 
> for you to fetch changes up to ccafe3126ad3f48ea1cd9ae460c69d1ba879fb65:
> 
>   mfd: intel_pmt: Add support for DG1 (2021-03-09 17:05:25 +)
> 
> 
> Immutable branch between MFD and Platform/X86 due for the v5.13 merge window
> 
> 
> David E. Box (2):
>   mfd: intel_pmt: Fix nuisance messages and handling of disabled 
> capabilities
>   mfd: intel_pmt: Add support for DG1
> 
>  drivers/mfd/intel_pmt.c| 112 
> +++--
>  drivers/platform/x86/intel_pmt_class.c |  46 
>  drivers/platform/x86/intel_pmt_class.h |   1 +
>  drivers/platform/x86/intel_pmt_telemetry.c |  20 --
>  4 files changed, 122 insertions(+), 57 deletions(-)
>