linux.git/drivers/platform, branch v5.12.5 Clone of https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git platform/surface: aggregator: fix a bit test 2021-05-14T08:52:33+00:00 Dan Carpenter dan.carpenter@oracle.com 2021-04-20T08:44:02+00:00 b877d36f134f89725f6feaae4e9b780cbc23117a [ Upstream commit 366f0a30c8a01e79255221539a52909cc4c7bd25 ] 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 <lkp@intel.com> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Reviewed-by: Maximilian Luz <luzmaximilian@gmail.com> Link: https://lore.kernel.org/r/YH6UUhJhGk3mk13b@mwanda Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit 366f0a30c8a01e79255221539a52909cc4c7bd25 ]

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 <lkp@intel.com>
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Maximilian Luz <luzmaximilian@gmail.com>
Link: https://lore.kernel.org/r/YH6UUhJhGk3mk13b@mwanda
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
platform/x86: pmc_atom: Match all Beckhoff Automation baytrail boards with critclk_systems DMI table 2021-05-14T08:52:31+00:00 Steffen Dirkwinkel s.dirkwinkel@beckhoff.com 2021-04-12T13:30:06+00:00 aabd4ef3a06555a151c4d3f4cdf9a636ee5da354 [ Upstream commit d21e5abd3a005253eb033090aab2e43bce090d89 ] 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 <andy.shevchenko@gmail.com> Signed-off-by: Steffen Dirkwinkel <s.dirkwinkel@beckhoff.com> Link: https://lore.kernel.org/r/20210412133006.397679-1-linux-kernel-dev@beckhoff.com Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit d21e5abd3a005253eb033090aab2e43bce090d89 ]

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 <andy.shevchenko@gmail.com>
Signed-off-by: Steffen Dirkwinkel <s.dirkwinkel@beckhoff.com>
Link: https://lore.kernel.org/r/20210412133006.397679-1-linux-kernel-dev@beckhoff.com
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
platform/x86: dell-wmi-sysman: Make init_bios_attributes() ACPI object parsing more robust 2021-05-14T08:52:27+00:00 Hans de Goede hdegoede@redhat.com 2021-03-21T12:16:07+00:00 3222157c9d2d0ebd6cc07651f58173d66b85f552 [ Upstream commit 5e3f5973c8dfd2b80268f1825ed2f2ddf81d3267 ] Make init_bios_attributes() ACPI object parsing more robust: 1. Always check that the type of the return ACPI object is package, rather then only checking this for instance_id == 0 2. Check that the package has the minimum amount of elements which will be consumed by the populate_foo_data() for the attr_type Note/TODO: The populate_foo_data() functions should also be made more robust. The should check the type of each of the elements matches the type which they expect and in case of populate_enum_data() obj->package.count should be passed to it as an argument and it should re-check this itself since it consume a variable number of elements. Fixes: e8a60aa7404b ("platform/x86: Introduce support for Systems Management Driver over WMI for Dell Systems") Cc: Divya Bharathi <Divya_Bharathi@dell.com> Cc: Mario Limonciello <mario.limonciello@dell.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20210321121607.35717-1-hdegoede@redhat.com Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit 5e3f5973c8dfd2b80268f1825ed2f2ddf81d3267 ]

Make init_bios_attributes() ACPI object parsing more robust:
1. Always check that the type of the return ACPI object is package, rather
   then only checking this for instance_id == 0
2. Check that the package has the minimum amount of elements which will
   be consumed by the populate_foo_data() for the attr_type

Note/TODO: The populate_foo_data() functions should also be made more
robust. The should check the type of each of the elements matches the
type which they expect and in case of populate_enum_data()
obj->package.count should be passed to it as an argument and it should
re-check this itself since it consume a variable number of elements.

Fixes: e8a60aa7404b ("platform/x86: Introduce support for Systems Management Driver over WMI for Dell Systems")
Cc: Divya Bharathi <Divya_Bharathi@dell.com>
Cc: Mario Limonciello <mario.limonciello@dell.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20210321121607.35717-1-hdegoede@redhat.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
platform/x86: intel_pmc_core: Don't use global pmcdev in quirks 2021-05-12T06:39:39+00:00 David E. Box david.e.box@linux.intel.com 2021-04-17T03:12:44+00:00 aa7ce33cb69143eaaea1a4f9631468d050926240 [ Upstream commit c9f86d6ca6b5e23d30d16ade4b9fff5b922a610a ] 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 <david.e.box@linux.intel.com> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Rajneesh Bhardwaj <irenic.rajneesh@gmail.com> Link: https://lore.kernel.org/r/20210417031252.3020837-2-david.e.box@linux.intel.com Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit c9f86d6ca6b5e23d30d16ade4b9fff5b922a610a ]

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 <david.e.box@linux.intel.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Rajneesh Bhardwaj <irenic.rajneesh@gmail.com>
Link: https://lore.kernel.org/r/20210417031252.3020837-2-david.e.box@linux.intel.com
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
platform/x86: ISST: Account for increased timeout in some cases 2021-05-12T06:39:37+00:00 Srinivas Pandruvada srinivas.pandruvada@linux.intel.com 2021-03-30T22:08:40+00:00 43f27251c576fcb84118528e404ee8271d09c539 [ Upstream commit 5c782817a981981917ec3c647cf521022ee07143 ] 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 <srinivas.pandruvada@linux.intel.com> Link: https://lore.kernel.org/r/20210330220840.3113959-1-srinivas.pandruvada@linux.intel.com Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit 5c782817a981981917ec3c647cf521022ee07143 ]

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 <srinivas.pandruvada@linux.intel.com>
Link: https://lore.kernel.org/r/20210330220840.3113959-1-srinivas.pandruvada@linux.intel.com
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
platform/x86: thinkpad_acpi: Correct thermal sensor allocation 2021-05-07T10:53:26+00:00 Mark Pearson markpearson@lenovo.com 2021-04-07T21:20:15+00:00 b4571c859f59d1b3360b1dbfdc9d8c8072ba3785 commit 6759e18e5cd8745a5dfc5726e4a3db5281ec1639 upstream. On recent Thinkpad platforms it was reported that temp sensor 11 was always incorrectly displaying 66C. It turns out the reason for this is that this location in EC RAM is not a temperature sensor but is the power supply ID (offset 0xC2). Based on feedback from the Lenovo firmware team the EC RAM version can be determined and for the current version (3) only the 0x78 to 0x7F range is used for temp sensors. I don't have any details for earlier versions so I have left the implementation unaltered there. Note - in this block only 0x78 and 0x79 are officially designated (CPU & GPU sensors). The use of the other locations in the block will vary from platform to platform; but the existing logic to detect a sensor presence holds. Signed-off-by: Mark Pearson <markpearson@lenovo.com> Link: https://lore.kernel.org/r/20210407212015.298222-1-markpearson@lenovo.com Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 6759e18e5cd8745a5dfc5726e4a3db5281ec1639 upstream.

On recent Thinkpad platforms it was reported that temp sensor 11 was
always incorrectly displaying 66C. It turns out the reason for this is
that this location in EC RAM is not a temperature sensor but is the
power supply ID (offset 0xC2).

Based on feedback from the Lenovo firmware team the EC RAM version can
be determined and for the current version (3) only the 0x78 to 0x7F
range is used for temp sensors. I don't have any details for earlier
versions so I have left the implementation unaltered there.

Note - in this block only 0x78 and 0x79 are officially designated (CPU &
GPU sensors). The use of the other locations in the block will vary from
platform to platform; but the existing logic to detect a sensor presence
holds.

Signed-off-by: Mark Pearson <markpearson@lenovo.com>
Link: https://lore.kernel.org/r/20210407212015.298222-1-markpearson@lenovo.com
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
platform/x86: intel-hid: Fix spurious wakeups caused by tablet-mode events during suspend 2021-04-06T20:10:21+00:00 Hans de Goede hdegoede@redhat.com 2021-04-04T14:38:31+00:00 a3790a8a94fc0234c5d38013b48e74ef221ec84c Some devices send (duplicate) tablet-mode events when moved around even though the mode has not changed; and they do this even when suspended. Change the tablet-mode event handling when priv->wakeup_mode is set to update the switch state in case it changed and then return immediately (without calling pm_wakeup_hard_event()) to avoid spurious wakeups. BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=212537 Fixes: 537b0dd4729e ("platform/x86: intel-hid: Add support for SW_TABLET_MODE") Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Elia Devito <eliadevito@gmail.com> Link: https://lore.kernel.org/r/20210404143831.25173-1-hdegoede@redhat.com 
Some devices send (duplicate) tablet-mode events when moved around even
though the mode has not changed; and they do this even when suspended.

Change the tablet-mode event handling when priv->wakeup_mode is set to
update the switch state in case it changed and then return immediately
(without calling pm_wakeup_hard_event()) to avoid spurious wakeups.

BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=212537
Fixes: 537b0dd4729e ("platform/x86: intel-hid: Add support for SW_TABLET_MODE")
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Elia Devito <eliadevito@gmail.com>
Link: https://lore.kernel.org/r/20210404143831.25173-1-hdegoede@redhat.com
platform/x86: intel_pmc_core: Ignore GBE LTR on Tiger Lake platforms 2021-03-23T20:50:14+00:00 David E. Box david.e.box@linux.intel.com 2021-03-19T20:18:44+00:00 d1635448f1105e549b4041aab930dbc6945fc635 Due to a HW limitation, the Latency Tolerance Reporting (LTR) value programmed in the Tiger Lake GBE controller is not large enough to allow the platform to enter Package C10, which in turn prevents the platform from achieving its low power target during suspend-to-idle. Ignore the GBE LTR value on Tiger Lake. LTR ignore functionality is currently performed solely by a debugfs write call. Split out the LTR code into its own function that can be called by both the debugfs writer and by this work around. Signed-off-by: David E. Box <david.e.box@linux.intel.com> Reviewed-by: Sasha Neftin <sasha.neftin@intel.com> Cc: intel-wired-lan@lists.osuosl.org Reviewed-by: Rajneesh Bhardwaj <irenic.rajneesh@gmail.com> Link: https://lore.kernel.org/r/20210319201844.3305399-2-david.e.box@linux.intel.com Signed-off-by: Hans de Goede <hdegoede@redhat.com> 
Due to a HW limitation, the Latency Tolerance Reporting (LTR) value
programmed in the Tiger Lake GBE controller is not large enough to allow
the platform to enter Package C10, which in turn prevents the platform from
achieving its low power target during suspend-to-idle.  Ignore the GBE LTR
value on Tiger Lake. LTR ignore functionality is currently performed solely
by a debugfs write call. Split out the LTR code into its own function that
can be called by both the debugfs writer and by this work around.

Signed-off-by: David E. Box <david.e.box@linux.intel.com>
Reviewed-by: Sasha Neftin <sasha.neftin@intel.com>
Cc: intel-wired-lan@lists.osuosl.org
Reviewed-by: Rajneesh Bhardwaj <irenic.rajneesh@gmail.com>
Link: https://lore.kernel.org/r/20210319201844.3305399-2-david.e.box@linux.intel.com
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
platform/x86: intel_pmc_core: Update Kconfig 2021-03-23T20:50:08+00:00 David E. Box david.e.box@linux.intel.com 2021-03-19T20:18:43+00:00 269b04a50992d8defab869079049ecfc60b6b3e5 The intel_pmc_core driver is mostly used as a debugging driver for Intel platforms that support SLPS0 (S0ix). But the driver may also be used to communicate actions to the PMC in order to ensure transition to SLPS0 on some systems and architectures. As such the driver should be built on all platforms it supports. Indicate this in the Kconfig. Also update the list of supported features. Signed-off-by: David E. Box <david.e.box@linux.intel.com> Suggested-by: Mario Limonciello <mario.limonciello@dell.com> Link: https://lore.kernel.org/r/20210319201844.3305399-1-david.e.box@linux.intel.com Signed-off-by: Hans de Goede <hdegoede@redhat.com> 
The intel_pmc_core driver is mostly used as a debugging driver for Intel
platforms that support SLPS0 (S0ix). But the driver may also be used to
communicate actions to the PMC in order to ensure transition to SLPS0 on
some systems and architectures. As such the driver should be built on all
platforms it supports. Indicate this in the Kconfig. Also update the list
of supported features.

Signed-off-by: David E. Box <david.e.box@linux.intel.com>
Suggested-by: Mario Limonciello <mario.limonciello@dell.com>
Link: https://lore.kernel.org/r/20210319201844.3305399-1-david.e.box@linux.intel.com
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
platform/x86: intel_pmt_crashlog: Fix incorrect macros 2021-03-23T20:50:02+00:00 David E. Box david.e.box@linux.intel.com 2021-03-17T02:44:55+00:00 10c931cdfe64ebc38a15a485dd794915044f2111 Fixes off-by-one bugs in the macro assignments for the crashlog control bits. Was initially tested on emulation but bug revealed after testing on silicon. Fixes: 5ef9998c96b0 ("platform/x86: Intel PMT Crashlog capability driver") Signed-off-by: David E. Box <david.e.box@linux.intel.com> Link: https://lore.kernel.org/r/20210317024455.3071477-2-david.e.box@linux.intel.com Signed-off-by: Hans de Goede <hdegoede@redhat.com> 
Fixes off-by-one bugs in the macro assignments for the crashlog control
bits. Was initially tested on emulation but bug revealed after testing on
silicon.

Fixes: 5ef9998c96b0 ("platform/x86: Intel PMT Crashlog capability driver")
Signed-off-by: David E. Box <david.e.box@linux.intel.com>
Link: https://lore.kernel.org/r/20210317024455.3071477-2-david.e.box@linux.intel.com
Signed-off-by: Hans de Goede <hdegoede@redhat.com>