- 21 Dec, 2021 6 commits
-
-
Sanket Goswami authored
STB (Smart Trace Buffer), is a debug trace buffer that isolates the failures by analyzing the last running feature of a system. This non-intrusive way always runs in the background and stores the trace into the SoC. This patch enables the STB feature by passing module param "enable_stb=1" while loading the driver and provides mechanism to access the STB buffer using the read and write routines. Co-developed-by:
Shyam Sundar S K <Shyam-sundar.S-k@amd.com> Signed-off-by:
Sanket Goswami <Sanket.Goswami@amd.com> Link: https://lore.kernel.org/r/20211130112318.92850-3-Sanket.Goswami@amd.comReviewed-by:
Hans de Goede <hdegoede@redhat.com> Signed-off-by:
-
Sanket Goswami authored
Handle error-exits in the amd_pmc_probe() to avoid duplication and store the root port information in amd_pmc_probe() so that the information can be used across multiple routines. Suggested-by:
-
Thomas Weißschuh authored
This adds support for the inhibit-charge charge_behaviour through the embedded controller of ThinkPads. Co-developed-by:
Thomas Koch <linrunner@gmx.net> Signed-off-by:
Nicolò Piazzalunga <nicolopiazzalunga@gmail.com> Signed-off-by:
Thomas Weißschuh <linux@weissschuh.net> Acked-by:
Sebastian Reichel <sebastian.reichel@collabora.com> Link: https://lore.kernel.org/r/20211123232704.25394-5-linux@weissschuh.netReviewed-by:
-
Thomas Weißschuh authored
This adds support for the force-discharge charge_behaviour through the embedded controller of ThinkPads. Co-developed-by:
-
Thomas Weißschuh authored
These helper functions can be used by drivers to implement their own sysfs-attributes. This is useful for ACPI-drivers extending the default ACPI-battery with their own charge_behaviour attributes. Signed-off-by:
-
Thomas Weißschuh authored
This a revised version of "[RFC] add standardized attributes for force_discharge and inhibit_charge" [0], incorporating discussion results. The biggest change is the switch from two boolean attributes to a single enum attribute. [0] https://lore.kernel.org/platform-driver-x86/21569a89-8303-8573-05fb-c2fec29983d1@gmail.com/Signed-off-by:
-
- 15 Dec, 2021 1 commit
-
-
Hans de Goede authored
Signed tag for the immutable platform-drivers-x86-int3472 branch This branch contains 5.16-rc1 + the pending ACPI/i2c, tps68570 platform_data and INT3472 driver patches.
-
- 13 Dec, 2021 9 commits
-
-
Hans de Goede authored
The clk and regulator frameworks expect clk/regulator consumer-devices to have info about the consumed clks/regulators described in the device's fw_node. To work around this info missing from the ACPI tables on devices where the int3472 driver is used, the int3472 MFD-cell drivers attach info about consumers to the clks/regulators when registering these. This causes problems with the probe ordering wrt drivers for consumers of these clks/regulators. Since the lookups are only registered when the provider-driver binds, trying to get these clks/regulators before then results in a -ENOENT error for clks and a dummy regulator for regulators. All the sensor ACPI fw-nodes have a _DEP dependency on the INT3472 ACPI fw-node, so to work around these probe ordering issues the ACPI core / i2c-code does not instantiate the I2C-clients for any ACPI devices which have a _DEP dependency on an INT3472 ACPI device until all _DEP-s are met. This relies on acpi_dev_clear_dependencies() getting called by the driver for the _DEP-s when they are ready, add a acpi_dev_clear_dependencies() call to the discrete.c probe code. In the tps68470 case calling acpi_dev_clear_dependencies() is already done by the acpi_gpiochip_add() call done by the driver for the GPIO MFD cell (The GPIO cell is deliberately the last cell created to make sure the clk + regulator cells are already instantiated when this happens). However for proper probe ordering, the clk/regulator cells must not just be instantiated the must be fully ready (the clks + regulators must be registered with their subsystems). Add MODULE_SOFTDEP dependencies for the clk and regulator drivers for the instantiated MFD-cells so that these are loaded before us and so that they bind immediately when the platform-devs are instantiated. Reviewed-by:
Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by:
-
Hans de Goede authored
Pass tps68470_regulator_platform_data to the tps68470-regulator MFD-cell, specifying the voltages of the various regulators and tying the regulators to the sensor supplies so that sensors which use the TPS68470 can find their regulators. Since the voltages and supply connections are board-specific, this introduces a DMI matches int3472_tps68470_board_data struct which contains the necessary per-board info. This per-board info also includes GPIO lookup information for the sensor IO lines which may be connected to the tps68470 GPIOs. Reviewed-by:
-
Hans de Goede authored
Pass tps68470_clk_platform_data to the tps68470-clk MFD-cell, so that sensors which use the TPS68470 can find their clock. Reviewed-by:
-
Hans de Goede authored
The discrete.c code is not the only code which needs to lookup the acpi_device and device-name for the sensor for which the INT3472 ACPI-device is a GPIO/clk/regulator provider. The tps68470.c code also needs this functionality, so factor this out into a new get_sensor_adev_and_name() helper. Reviewed-by:
-
Hans de Goede authored
The intel_skl_int3472.ko module contains 2 separate drivers, the int3472_discrete platform driver and the int3472_tps68470 I2C-driver. These 2 drivers contain very little shared code, only skl_int3472_get_acpi_buffer() and skl_int3472_fill_cldb() are shared. Split the module into 2 drivers, linking the little shared code directly into both. This will allow us to add soft-module dependencies for the tps68470 clk, gpio and regulator drivers to the new intel_skl_int3472_tps68470.ko to help with probe ordering issues without causing these modules to get loaded on boards which only use the int3472_discrete platform driver. While at it also rename the .c and .h files to remove the cumbersome intel_skl_int3472_ prefix. Reviewed-by:
-
Hans de Goede authored
The clk and regulator frameworks expect clk/regulator consumer-devices to have info about the consumed clks/regulators described in the device's fw_node. To work around cases where this info is not present in the firmware tables, which is often the case on x86/ACPI devices, both frameworks allow the provider-driver to attach info about consumers to the provider-device during probe/registration of the provider device. The TI TPS68470 PMIC is used x86/ACPI devices with the consumer-info missing from the ACPI tables. Thus the tps68470-clk and tps68470-regulator drivers must provide the consumer-info at probe time. Define tps68470_clk_platform_data and tps68470_regulator_platform_data structs to allow the x86 platform code to pass the necessary consumer info to these drivers. Reviewed-by:
-
Hans de Goede authored
Change i2c_acpi_new_device() into i2c_acpi_new_device_by_fwnode() and add a static inline wrapper providing the old i2c_acpi_new_device() behavior. This is necessary because in some cases we may only have access to the fwnode / acpi_device and not to the matching physical-node struct device *. Suggested-by:
Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by:
Wolfram Sang <wsa@kernel.org> Signed-off-by:
-
Hans de Goede authored
The clk and regulator frameworks expect clk/regulator consumer-devices to have info about the consumed clks/regulators described in the device's fw_node. To work around cases where this info is not present in the firmware tables, which is often the case on x86/ACPI devices, both frameworks allow the provider-driver to attach info about consumers to the clks/regulators when registering these. This causes problems with the probe ordering wrt drivers for consumers of these clks/regulators. Since the lookups are only registered when the provider-driver binds, trying to get these clks/regulators before then results in a -ENOENT error for clks and a dummy regulator for regulators. To ensure the correct probe-ordering the ACPI core has code to defer the enumeration of consumers affected by this until the providers are ready. Call the new acpi_dev_ready_for_enumeration() helper to avoid enumerating / instantiating i2c-clients too early. Acked-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by:
-
Hans de Goede authored
The clk and regulator frameworks expect clk/regulator consumer-devices to have info about the consumed clks/regulators described in the device's fw_node. To work around cases where this info is not present in the firmware tables, which is often the case on x86/ACPI devices, both frameworks allow the provider-driver to attach info about consumers to the clks/regulators when registering these. This causes problems with the probe ordering wrt drivers for consumers of these clks/regulators. Since the lookups are only registered when the provider-driver binds, trying to get these clks/regulators before then results in a -ENOENT error for clks and a dummy regulator for regulators. One case where we hit this issue is camera sensors such as e.g. the OV8865 sensor found on the Microsoft Surface Go. The sensor uses clks, regulators and GPIOs provided by a TPS68470 PMIC which is described in an INT3472 ACPI device. There is special platform code handling this and setting platform_data with the necessary consumer info on the MFD cells instantiated for the PMIC under: drivers/platform/x86/intel/int3472. For this to work properly the ov8865 driver must not bind to the I2C-client for the OV8865 sensor until after the TPS68470 PMIC gpio, regulator and clk MFD cells have all been fully setup. The OV8865 on the Microsoft Surface Go is just one example, all X86 devices using the Intel IPU3 camera block found on recent Intel SoCs have similar issues where there is an INT3472 HID ACPI-device, which describes the clks and regulators, and the driver for this INT3472 device must be fully initialized before the sensor driver (any sensor driver) binds for things to work properly. On these devices the ACPI nodes describing the sensors all have a _DEP dependency on the matching INT3472 ACPI device (there is one per sensor). This allows solving the probe-ordering problem by delaying the enumeration (instantiation of the I2C-client in the ov8865 example) of ACPI-devices which have a _DEP dependency on an INT3472 device. The new acpi_dev_ready_for_enumeration() helper used for this is also exported because for devices, which have the enumeration_by_parent flag set, the parent-driver will do its own scan of child ACPI devices and it will try to enumerate those during its probe(). Code doing this such as e.g. the i2c-core-acpi.c code must call this new helper to ensure that it too delays the enumeration until all the _DEP dependencies are met on devices which have the new honor_deps flag set. Acked-by:
-
- 07 Dec, 2021 4 commits
-
-
Andy Shevchenko authored
After the commit 34570a89 ("platform/x86: hp_accel: Remove _INI method call") there is no need to have separate methods for resume and restore, hence we may fold them together and use SIMPLE_DEV_PM_OPS() for PM ops. While at it, switch to use __maybe_unused attribute. Signed-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20211206151521.22578-1-andriy.shevchenko@linux.intel.comReviewed-by:
-
Jarrett Schultz authored
Since the Surface XBL Driver does not depend on ACPI, the platform/surface directory as a whole no longer depends on ACPI. With respect to this, the ACPI dependency is moved into each config that depends on ACPI individually. Signed-off-by:
Jarrett Schultz <jaschultz@microsoft.com> Link: https://lore.kernel.org/r/20211202191630.12450-3-jaschultz@microsoft.comReviewed-by:
-
Hans de Goede authored
On the back of the device there is a Hall sensor connected to the "INT33FF:02" GPIO controller pin 18, which gets triggered when the device is fully folded into tablet-mode (when the back of the display touches the back of the keyboard). Use this to disable both the touch-keyboard and the digitizer when the tablet is fully folded into tablet-mode. Reviewed-by:
-
Yauhen Kharuzhy authored
Add driver to handle WMI events, control the keyboard backlight and bind/unbind the keyboard-touch / digitizer driver so that only one is active at a time. It may seem a bit weird to handle the toggling of the modes in the kernel, but the hw actually expects only 1 device to be active at a time. Changes by Hans de Goede: - Whole bunch of cleanups - Make the kernel do the driver bind/unbind itself instead of sending events to userspace and requiring a special userspace daemon to deal with this Signed-off-by:
Yauhen Kharuzhy <jekhor@gmail.com> Co-developed-by:
-
- 06 Dec, 2021 4 commits
-
-
Hans de Goede authored
Some WMI implementations do notifies on WMI objects without a _WED method allow WMI drivers to indicate that _WED should not be called for notifies on the WMI objects the driver is bound to. Instead the driver's notify callback will simply be called with a NULL data argument. Reported-by:
-
Hans de Goede authored
The driver core sets struct device->driver before calling out to the bus' probe() method, this leaves a window where an ACPI notify may happen on the WMI object before the driver's probe() method has completed running, causing e.g. the driver's notify() callback to get called with drvdata not yet being set leading to a NULL pointer deref. At a check for this to the WMI core, ensuring that the notify() callback is not called before the driver is ready. Fixes: 1686f544 ("platform/x86: wmi: Incorporate acpi_install_notify_handler") Reviewed-by:
-
Hans de Goede authored
Replace the wmi_block.read_takes_no_args bool field with an unsigned long flags field, used together with test_bit() and friends. This is a preparation patch for fixing a driver->notify() vs ->probe() race, which requires atomic flag handling. Reviewed-by:
-
Alex Hung authored
Similar to other systems Surface Go 3 requires a DMI quirk to enable 5 button array for power and volume buttons. Buglink: https://github.com/linux-surface/linux-surface/issues/595 Cc: stable@vger.kernel.org Signed-off-by:
Alex Hung <alex.hung@canonical.com> Link: https://lore.kernel.org/r/20211203212810.2666508-1-alex.hung@canonical.comSigned-off-by:
-
- 02 Dec, 2021 6 commits
-
-
Fabrizio Bertocci authored
On some AMD hardware laptops, the system fails communicating with the PMC when entering s2idle and the machine is battery powered. Hardware description: HP Pavilion Aero Laptop 13-be0097nr CPU: AMD Ryzen 7 5800U with Radeon Graphics GPU: 03:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Device [1002:1638] (rev c1) Detailed description of the problem (and investigation) here: https://gitlab.freedesktop.org/drm/amd/-/issues/1799 Patch is a single line: reduce the polling delay in half, from 100uSec to 50uSec when waiting for a change in state from the PMC after a write command operation. After changing the delay, I did not see a single failure on this machine (I have this fix for now more than one week and s2idle worked every single time on battery power). Cc: stable@vger.kernel.org Acked-by:
Fabrizio Bertocci <fabriziobertocci@gmail.com> Link: https://lore.kernel.org/r/CADtzkx7TdfbwtaVEXUdD6YXPey52E-nZVQNs+Z41DTx7gqMqtw@mail.gmail.comSigned-off-by:
-
Hans de Goede authored
The TrekStor SurfTab duo W1 (ST10432-10b) has a Goodix touchscreen which has its x-axis mirrored. Add a quirk to fix this. Signed-off-by:
-
Matan Ziv-Av authored
LG uses 5 instead of 0 in the third digit (second digit after 2019) of the year string to indicate newer models in the same year. Handle this case as well. Signed-off-by:
Matan Ziv-Av <matan@svgalib.org> Link: https://lore.kernel.org/r/c752b3b2-9718-bd9a-732d-e165aa8a1fca@svgalib.orgSigned-off-by:
-
Yang Li authored
Eliminate the following coccicheck warning: ./drivers/platform/x86/asus-wmi.c:2386:2-3: Unneeded semicolon Reported-by:
Abaci Robot <abaci@linux.alibaba.com> Signed-off-by:
Yang Li <yang.lee@linux.alibaba.com> Link: https://lore.kernel.org/r/1637719332-45224-1-git-send-email-yang.lee@linux.alibaba.comSigned-off-by:
-
Hans de Goede authored
There have been various bugs / forum threads about allowing control of the LED in the ThinkPad logo on the lid of various models. This seems to be something which users want to control and there really is no reason to require setting CONFIG_THINKPAD_ACPI_UNSAFE_LEDS for this. The lid-logo-dot is LED number 10, so change the name of the 10th led from unknown_led2 to lid_logo_dot and add it to the TPACPI_SAFE_LEDS mask. Link: https://www.reddit.com/r/thinkpad/comments/7n8eyu/thinkpad_led_control_under_gnulinux/ BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1943318Signed-off-by:
-
Hans de Goede authored
Add the LED_RETAIN_AT_SHUTDOWN flag to the registered led_class_devs so that the LEDs do not get turned-off when reloading the driver and thus so that they also stay under default EC control when reloading the driver, unless explicitly overridden by the user. Signed-off-by:
-
- 25 Nov, 2021 10 commits
-
-
Hans de Goede authored
After the recent sysfs-attributes registration cleanups, the tp_features.sensors_pdev_attrs_registered flag only ever gets set and never gets read, remove it. Signed-off-by:
-
Hans de Goede authored
The hwmon sysfs-attr should show up under the hwmon-classdev, not under the tpacpi_sensors_pdev. Pass the tpacpi_hwmon_groups attr-groups array to hwmon_device_register_with_groups() instead of setting tpacpi_hwmon_pdriver.driver.dev_groups to it to fix this. This also requires moving the hwmon_device_register_with_groups() call to after the subdriver init functions have run so that the is_visible() calls will work properly. Fixes: 79f960e2 ("platform/x86: thinkpad_acpi: Convert platform driver to use dev_groups") Cc: Len Baker <len.baker@gmx.com> Signed-off-by:
-
Hans de Goede authored
Commit 79f960e2 ("platform/x86: thinkpad_acpi: Convert platform driver to use dev_groups") put the debug_level, interface_version, version and the THINKPAD_ACPI_DEBUGFACILITIES attributes in a new tpacpi_attr_group and added those to the tpacpi_groups groups-array which is used to initialize the driver.dev_groups member. But before this commit these attributes were registered with driver_create_file(), so they should be part of the groups-array which is used to initialize the driver.groups member instead. And also make the same change for the fan_watchdog hwmon driver attribute. Fixes: 79f960e2 ("platform/x86: thinkpad_acpi: Convert platform driver to use dev_groups") Cc: Len Baker <len.baker@gmx.com> Signed-off-by:
-
Hans de Goede authored
Commit 79f960e2 ("platform/x86: thinkpad_acpi: Convert platform driver to use dev_groups") introduces the use of driver.dev_groups + attribute_group.is_visible callbacks replacing the conditional calling of driver_create_file() for optional attributes. The is_visible callbacks rely on various tp_features.has_foo flags, which get set by the subdriver init functions. But before this fix, thinkpad_acpi_module_init() would call the subdriver init functions after registering the platform_device and the tpacpi_pdriver. Which would cause the is_visible callbacks to get called before the subdriver init functions, which in turn would cause optional attributes to not get registered at all, even when the feature is actually present. Fix this by moving the platform_driver_register(&tpacpi_pdriver) to after the subdriver init calls; and do the same for the tpacpi_hmon_pdriver. Fixes: 79f960e2 ("platform/x86: thinkpad_acpi: Convert platform driver to use dev_groups") Cc: Len Baker <len.baker@gmx.com> Signed-off-by:
-
Hans de Goede authored
Commit c99ca78d ("platform/x86: thinkpad_acpi: Switch to common use of attributes") removed the conditional adding of the hotkey_tablet_mode and hotkey_radio_sw sysfs-attributes, replacing this with a hotkey_attr_is_visible() callback which hides them when the feature is not present. But this commit forgot to add these 2 attributes to the default hotkey_attributes[] set, so they would now never get added at all. Add the 2 attributes to the default hotkey_attributes[] set so that they are available on systems with these features once more. Fixes: c99ca78d ("platform/x86: thinkpad_acpi: Switch to common use of attributes") Cc: Len Baker <len.baker@gmx.com> Signed-off-by:
-
Hans de Goede authored
Fix thermal_temp_input_attr sorting. Now that we use is_visible, rather then registering only part of the thermal_temp_input_attr array, putting attr 0-7 last is no longer needed. Reviewed-by:
Mark Pearson <mpearson@lenovo.com> Signed-off-by:
-
Hans de Goede authored
The err_exit label just does a: return (res < 0) ? res : -ENODEV; And res is always < 0 when we go there (hotkey_mask_get() returns either 0 or -EIO), so the goto-s can simply be replaced with "return res". Reviewed-by:
-
Hans de Goede authored
The previous refactoring of some code in tpacpi_dytc_profile_init() left a weirdly indented code-block behind. Remove the unnecessary '{}' and reduce the indent level one step, other then changing the indentation the code is completely unchanged. Reviewed-by: -
Hans de Goede authored
Remove the dytc_profile_available check from dytc_profile_set(), that function only gets called if the platform_profile_handler was registered, so the check is not necessary. Make tpacpi_dytc_profile_init() return -ENODEV when it does not register the platform_profile() handler this will cause dytc_profile_driver_data.flags.init to not get set, which in turn will cause the dytc_profile_exit() call to get skipped. Together this avoids the need to have the dytc_profile_available variable at all, since the information is now duplicated in the dytc_profile_driver_data.flags.init flag. Note this leaves a weirdly indented code-block behind, this is deliberately done to make what actually changes in this commit clear. This will be fixed-up in the next commit. Reviewed-by:
-
Hans de Goede authored
The only reason the proxysensor code needs dytc_version handling is for proxsensor_attr_is_visible() and that will only ever get called after all the subdrv init() callbacks have run. tpacpi_dytc_profile_init() already calls DYTC_CMD_QUERY and is the primary consumer of dytc_version, so simply let tpacpi_dytc_profile_init() set dytc_version and remove the now no longer necessary dytc_get_version() helper and its calls. Reviewed-by:
-
