[ Upstream commit e42fe5b29ac07210297e75f36deefe54edbdbf80 ]

The Intel Compute Stick `STK1A32SC` can have a system vendor of
"Intel(R) Client Systems".
Broaden the Intel Compute Stick DMI checks so that they match "Intel
Corporation" as well as "Intel(R) Client Systems".

This fixes an issue where the STK1A32SC compute sticks were still
exposing a battery with the existing blacklist entry.

Signed-off-by: Jeffery Miller <jmiller@neverware.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>

[ Upstream commit 583b53ece0b0268c542a1eafadb62e3d4b0aab8c ]

The driver fails to probe with -EPROBE_DEFER if battery's power supply
(charger driver) isn't ready yet and this results in a bit noisy error
message in KMSG during kernel's boot up. Let's silence the harmless
error message.

Signed-off-by: Dmitry Osipenko <digetx@gmail.com>
Reviewed-by: Andrew F. Davis <afd@ti.com>
Reviewed-by: Pali Rohár <pali@kernel.org>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 9c80662a74cd2a5d1113f5c69d027face963a556 upstream.

Some HP Pavilion x2 10 models use an AXP288 for charging and fuel-gauge.
We use a native power_supply / PMIC driver in this case, because on most
models with an AXP288 the ACPI AC / Battery code is either completely
missing or relies on custom / proprietary ACPI OpRegions which Linux
does not implement.

The native drivers mostly work fine, but there are 2 problems:

1. These model uses a Type-C connector for charging which the AXP288 does
not support. As long as a Type-A charger (which uses the USB data pins for
charger type detection) is used everything is fine. But if a Type-C
charger is used (such as the charger shipped with the device) then the
charger is not recognized.

So we end up slowly discharging the device even though a charger is
connected, because we are limiting the current from the charger to 500mA.
To make things worse this happens with the device's official charger.

Looking at the ACPI tables HP has "solved" the problem of the AXP288 not
being able to recognize Type-C chargers by simply always programming the
input-current-limit at 3000mA and relying on a Vhold setting of 4.7V
(normally 4.4V) to limit the current intake if the charger cannot handle
this.

2. If no charger is connected when the machine boots then it boots with the
vbus-path disabled. On other devices this is done when a 5V boost converter
is active to avoid the PMIC trying to charge from the 5V boost output.
This is done when an OTG host cable is inserted and the ID pin on the
micro-B receptacle is pulled low, the ID pin has an ACPI event handler
associated with it which re-enables the vbus-path when the ID pin is pulled
high when the OTG cable is removed. The Type-C connector has no ID pin,
there is no ID pin handler and there appears to be no 5V boost converter,
so we end up not charging because the vbus-path is disabled, until we
unplug the charger which automatically clears the vbus-path disable bit and
then on the second plug-in of the adapter we start charging.

The HP Pavilion x2 10 models with an AXP288 do have mostly working ACPI
AC / Battery code which does not rely on custom / proprietary ACPI
OpRegions. So one possible solution would be to blacklist the AXP288
native power_supply drivers and add the HP Pavilion x2 10 with AXP288
DMI ids to the list of devices which should use the ACPI AC / Battery
code even though they have an AXP288 PMIC. This would require changes to
4 files: drivers/acpi/ac.c, drivers/power/supply/axp288_charger.c,
drivers/acpi/battery.c and drivers/power/supply/axp288_fuel_gauge.c.

Beside needing adding the same DMI matches to 4 different files, this
approach also triggers problem 2. from above, but then when suspended,
during suspend the machine will not wakeup because the vbus path is
disabled by the AML code when not charging, so the Vbus low-to-high
IRQ is not triggered, the CPU never wakes up and the device does not
charge even though the user likely things it is charging, esp. since
the charge status LED is directly coupled to an adapter being plugged
in and does not reflect actual charging.

This could be worked by enabling vbus-path explicitly from say the
axp288_charger driver's suspend handler.

So neither situation is ideal, in both cased we need to explicitly enable
the vbus-path to work around different variants of problem 2 above, this
requires a quirk in the axp288_charger code.

If we go the route of using the ACPI AC / Battery drivers then we need
modifications to 3 other drivers; and we need to partially disable the
axp288_charger code, while at the same time keeping it around to enable
vbus-path on suspend.

OTOH we can copy the hardcoding of 3A input-current-limit (we never touch
Vhold, so that would stay at 4.7V) to the axp288_charger code, which needs
changes regardless, then we concentrate all special handling of this
interesting device model in the axp288_charger code. That is what this
commit does.

Cc: stable@vger.kernel.org
BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1791098
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Pull ARM SoC platform updates from Olof Johansson:
 "Most of these are smaller fixes that have accrued, and some continued
  cleanup of OMAP platforms towards shared frameworks.

  One new SoC from Atmel/Microchip: sam9x60"

* tag 'armsoc-soc' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc: (35 commits)
  ARM: OMAP2+: Fix undefined reference to omap_secure_init
  ARM: s3c64xx: Drop unneeded select of TIMER_OF
  ARM: exynos: Drop unneeded select of MIGHT_HAVE_CACHE_L2X0
  ARM: s3c24xx: Switch to atomic pwm API in rx1950
  ARM: OMAP2+: sleep43xx: Call secure suspend/resume handlers
  ARM: OMAP2+: Use ARM SMC Calling Convention when OP-TEE is available
  ARM: OMAP2+: Introduce check for OP-TEE in omap_secure_init()
  ARM: OMAP2+: Add omap_secure_init callback hook for secure initialization
  ARM: at91: Documentation: add sam9x60 product and datasheet
  ARM: at91: pm: use of_device_id array to find the proper shdwc node
  ARM: at91: pm: use SAM9X60 PMC's compatible
  ARM: imx: only select ARM_ERRATA_814220 for ARMv7-A
  ARM: zynq: use physical cpuid in zynq_slcr_cpu_stop/start
  ARM: tegra: Use clk_m CPU on Tegra124 LP1 resume
  ARM: tegra: Modify reshift divider during LP1
  ARM: tegra: Enable PLLP bypass during Tegra124 LP1
  ARM: samsung: Rename Samsung and Exynos to lowercase
  ARM: exynos: Correct the help text for platform Kconfig option
  ARM: bcm: Select ARM_AMBA for ARCH_BRCMSTB
  ARM: brcmstb: Add debug UART entry for 7216
  ...

Pull more power management updates from Rafael Wysocki:

 - Update the recently merged CPR (Core Power Reduction) support in the
   AVS (Adaptive Voltage Scaling) subsystem (Brendan Higgins, Nathan
   Chancellor, Niklas Cassel)

 - Update the rockchip-io AVS driver (Heiko Stuebner)

 - Add two more module parameters to intel_idle on top of the recently
   merged material (Rafael Wysocki)

 - Clean up a piece of cpuidle documentation and consolidate system
   sleep states documentation (Rafael Wysocki)

* tag 'pm-5.6-rc1-3' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm:
  cpuidle: Documentation: Clean up PM QoS description
  Documentation: admin-guide: PM: Update sleep states documentation
  intel_idle: Introduce 'states_off' module parameter
  intel_idle: Introduce 'use_acpi' module parameter
  power: avs: qcom-cpr: Avoid clang -Wsometimes-uninitialized in cpr_scale
  power: avs: qcom-cpr: add unspecified HAS_IOMEM dependency
  PM / AVS: rockchip-io: fix the supply naming for the emmc supply on px30
  power: avs: qcom-cpr: add a printout after the driver has been initialized

* pm-avs:
  power: avs: qcom-cpr: Avoid clang -Wsometimes-uninitialized in cpr_scale
  power: avs: qcom-cpr: add unspecified HAS_IOMEM dependency
  PM / AVS: rockchip-io: fix the supply naming for the emmc supply on px30
  power: avs: qcom-cpr: add a printout after the driver has been initialized

* pm-cpuidle:
  cpuidle: Documentation: Clean up PM QoS description
  intel_idle: Introduce 'states_off' module parameter
  intel_idle: Introduce 'use_acpi' module parameter

Pull chrome platform updates from Benson Leung:
 "CrOS EC:

   - Refactoring of some of cros_ec's headers:

     include/linux/mfd/cros_ec.h now removed, new cros_ec.h added to
     drivers/platform/chrome which contains shared operations of cros_ec
     transport drivers.

   - Response tracing in cros_ec_proto

  Wilco EC:

   - Fix unregistration order.

   - Fix keyboard backlight probing on systems without keyboard
     backlight

   - Minor cleanup (newlines in printks, COMPILE_TEST)

  Misc:

   - chromeos_laptop converted to use i2c_new_scanned_device instead of
     i2c_new_probed_device"

* tag 'tag-chrome-platform-for-v5.6' of git://git.kernel.org/pub/scm/linux/kernel/git/chrome-platform/linux:
  platform/chrome: cros_ec: Match implementation with headers
  platform/chrome: cros_ec: Drop unaligned.h include
  platform/chrome: wilco_ec: Allow wilco to be compiled in COMPILE_TEST
  platform/chrome: wilco_ec: Add newlines to printks
  platform/chrome: wilco_ec: Fix unregistration order
  cros_ec: treewide: Remove 'include/linux/mfd/cros_ec.h'
  platform/chrome: cros_ec_ishtp: Make init_lock static
  platform/chrome: chromeos_laptop: Convert to i2c_new_scanned_device
  platform/chrome: cros_ec_lpc: Use platform_get_irq_optional() for optional IRQs
  platform/chrome: cros_ec_proto: Add response tracing
  platform/chrome: cros_ec_trace: Match trace commands with EC commands

Clang warns (trimmed for brevity):

../drivers/power/avs/qcom-cpr.c:570:13: warning: variable 'reg_mask' is
used uninitialized whenever 'if' condition is false
[-Wsometimes-uninitialized]

../drivers/power/avs/qcom-cpr.c:520:13: warning: variable 'new_uV' is
used uninitialized whenever 'if' condition is false
[-Wsometimes-uninitialized]

Due to the fact that Clang's static analysis happens before any
optimization passes are taken into account, it cannot see that both
branches in the if statement must be taken because dir cannot be
something other than UP or DOWN due to the check at the top of this
function. Change the else if condition to else to fix this false
positive.

Fixes: bf6910abf548 ("power: avs: Add support for CPR (Core Power Reduction)")
Link: https://github.com/ClangBuiltLinux/linux/issues/840
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Acked-by: Kevin Hilman <khilman@baylibre.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

Currently CONFIG_QCOM_CPR=y implicitly depends on CONFIG_HAS_IOMEM=y;
consequently, on architectures without IOMEM we get the following build
error:

/usr/bin/ld: drivers/power/avs/qcom-cpr.o: in function `cpr_probe':
drivers/power/avs/qcom-cpr.c:1690: undefined reference to `devm_ioremap_resource'

Fix the build error by adding the unspecified dependency.

Signed-off-by: Brendan Higgins <brendanhiggins@google.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

The supply going to the emmc/flash is named vccio6, not vccio0 and while
the code does this correctly already, the comments and error output do not.

So just change these values to the correct ones.

Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>