- 22 Jun, 2021 4 commits
-
-
Andy Shevchenko authored
When we call acpi_gpio_get_io_resource(), the output will be the pointer to the ACPI GPIO resource. Use it directly instead of dereferencing the generic resource. Signed-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by:
Daniel Scally <djrscally@gmail.com> Tested-by:
Hans de Goede <hdegoede@redhat.com>
-
Andy Shevchenko authored
Besides the fact that COMMON_CLK selects CLKDEV_LOOKUP, the latter is going to be removed from clock framework. Reviewed-by:
-
Andy Shevchenko authored
We may free ACPI device resources immediately after use. Refactor skl_int3472_parse_crs() accordingly. Signed-off-by:
-
Andy Shevchenko authored
Linus already once did that for PDx86, don't repeat our mistakes. TL;DR: 'n' *is* the default 'default'. Signed-off-by:
-
- 18 Jun, 2021 5 commits
-
-
Hans de Goede authored
Signed tag for the immutable devm-helpers branch for merging into the extcon and pdx86 trees.
-
Srinivas Pandruvada authored
There is a problem in mapping CPU to a PCI device instance when the bus numbers are reused in different packages. This was observed on some Sapphire Rapids systems. The current implementation reads bus number assigned to a CPU package via MSR 0x128. This allows to establish relationship between a CPU and a PCI device. This allows to update power related parameters to a MMIO offset in a PCI device space which is unique to a CPU. But if two packages uses same bus number then this mapping will not be unique. When bus number is reused, PCI device will use different domain number or segment number. So we need to be aware of this domain information while matching CPU to PCI bus number. This domain information is not available via any MSR. So need to use ACPI numa node information. There is an interface already available in the Linux to read numa node for a CPU and a PCI device. This change uses this interface to check the numa node of a match PCI device with bus number. If the bus number and numa node matches with the CPU's assigned bus number and numa node, the matched PCI device instance will be returned to the caller. It is possible that before Sapphire Rapids, the numa node is not defined for the Speed Select PCI device in some OEM systems. In this case to restore old behavior, return the last matched PCI device for domain 0 unlsess there are more than one matches. Signed-off-by:
Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Link: https://lore.kernel.org/r/20210616221329.1909276-2-srinivas.pandruvada@linux.intel.comReviewed-by:
-
Srinivas Pandruvada authored
It was observed that some of the high performance benchmarks are spending more time in kernel depending on which CPU package they are executing. The difference is significant and benchmark scores varies more than 10%. These benchmarks adjust class of service to improve thread performance which run in parallel. This class of service change causes access to MMIO region of Intel Speed Select PCI devices depending on the CPU package they are executing. This mapping from CPU to PCI device instance uses a standard Linux PCI interface "pci_get_domain_bus_and_slot()". This function does a linear search to get to a PCI device. Since these platforms have 100+ PCI devices, this search can be expensive in fast path for benchmarks. Since the device and function of PCI device is fixed for Intel Speed Select PCI devices, the CPU to PCI device information can be cached at the same time when bus number for the CPU is read. In this way during runtime the cached information can be used. This improves performance of these benchmarks significantly. Signed-off-by:
-
Srinivas Pandruvada authored
This release adds following change: - Fix reporting of memory frequency Signed-off-by:
-
Srinivas Pandruvada authored
The uncore memory frequency value from the mailbox command CONFIG_TDP_GET_MEM_FREQ needs to be scaled based on the platform for display. There is no single constant multiplier. This change introduces CPU model specific memory frequency multiplier. Signed-off-by:
-
- 17 Jun, 2021 6 commits
-
-
Matti Vaittinen authored
Simplify driver by switching to use the resource managed IRQ requesting and resource managed work-queue initialization. Signed-off-by:
Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com> Reviewed-by:
Chanwoo Choi <cw00.choi@samsung.com> Link: https://lore.kernel.org/r/61190cc280a63baeb05ec570282bb3677bee8e7b.1623146580.git.matti.vaittinen@fi.rohmeurope.comSigned-off-by:
-
Matti Vaittinen authored
If reading MAX8997_MUIC_REG_STATUS1 fails at probe the driver exits without freeing the requested IRQs. Free the IRQs prior returning if reading the status fails. Fixes: 3e34c819 ("extcon: max8997: Avoid forcing UART path on drive probe") Signed-off-by:
-
Matti Vaittinen authored
The extcon IRQ schedules a work item. IRQ is requested using devm while WQ is cancelld at remove(). This mixing of devm and manual unwinding has potential case where the WQ has been emptied (.remove() was ran) but devm unwinding of IRQ was not yet done. It may be possible the IRQ is triggered at this point scheduling new work item to the already flushed queue. According to the input documentation the input device allocated by devm_input_allocate_device() does not need to be explicitly unregistered. Use the new devm_work_autocancel() and remove the remove() to simplify the code. Signed-off-by:
Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> Reviewed-by:
-
Matti Vaittinen authored
The extcon IRQ schedules a work item. IRQ is requested using devm while WQ is cancelld at remove(). This mixing of devm and manual unwinding has potential case where the WQ has been emptied (.remove() was ran) but devm unwinding of IRQ was not yet done. It is possible the IRQ is triggered at this point scheduling new work item to the already flushed queue. Use new devm_work_autocancel() to remove the remove() and to kill the bug. Signed-off-by:
-
Matti Vaittinen authored
A few drivers which need a 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 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:
-
Daniel Scally authored
This driver only covered one scenario in which ACPI devices with _HID INT3472 are found, and its functionality has been taken over by the intel-skl-int3472 module, so remove it. Acked-by:
Andy Shevchenko <andy.shevchenko@gmail.com> Acked-by:
Lee Jones <lee.jones@linaro.org> Reviewed-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by:
-
- 16 Jun, 2021 25 commits
-
-
Daniel Scally authored
ACPI devices with _HID INT3472 are currently matched to the tps68470 driver, however this does not cover all situations in which that _HID occurs. We've encountered three possibilities: 1. On Chrome OS devices, an ACPI device with _HID INT3472 (representing a physical TPS68470 device) that requires a GPIO and OpRegion driver 2. On devices designed for Windows, an ACPI device with _HID INT3472 (again representing a physical TPS68470 device) which requires GPIO, Clock and Regulator drivers. 3. On other devices designed for Windows, an ACPI device with _HID INT3472 which does **not** represent a physical TPS68470, and is instead used as a dummy device to group some system GPIO lines which are meant to be consumed by the sensor that is dependent on this entry. This commit adds a new module, registering a platform driver to deal with the 3rd scenario plus an i2c driver to deal with #1 and #2, by querying the CLDB buffer found against INT3472 entries to determine which is most appropriate. Suggested-by:
-
Hans de Goede authored
-
Hans de Goede authored
intel-gpio for v5.14-1 * Export two functions from GPIO ACPI for wider use * Clean up Whiskey Cove and Crystal Cove GPIO drivers The following is an automated git shortlog grouped by driver: crystalcove: - remove platform_set_drvdata() + cleanup probe gpiolib: - acpi: Add acpi_gpio_get_io_resource() - acpi: Introduce acpi_get_and_request_gpiod() helper wcove: - Split error handling for CTRL and IRQ registers - Unify style of to_reg() with to_ireg() - Use IRQ hardware number getter instead of direct access
-
Hans de Goede authored
Signed tag for the immutable platform-drivers-x86-goodix branch for merging into the input subsystem.
-
Maximilian Luz authored
We have moved to libera.chat. Update the link accordingly. Signed-off-by:
Maximilian Luz <luzmaximilian@gmail.com> Link: https://lore.kernel.org/r/20210614194635.1681519-1-luzmaximilian@gmail.comSigned-off-by:
-
Zou Wei authored
This patch adds missing MODULE_DEVICE_TABLE definition which generates correct modalias for automatic loading of this driver when it is built as an external module. Reported-by:
Hulk Robot <hulkci@huawei.com> Signed-off-by:
Zou Wei <zou_wei@huawei.com> Link: https://lore.kernel.org/r/1623811809-65099-1-git-send-email-zou_wei@huawei.comSigned-off-by:
-
Hans de Goede authored
If length equals 0 then reading buf[length-1] will read before the start of the buffer. Avoid this by moving the length == 0 check up. Cc: Mark Pearson <markpearson@lenovo.com> Reported-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
-
Hans de Goede authored
tlmi_priv.pwd_admin->password is an array (not a pointer), so the correct way to check for the password being set is to check for tlmi_priv.pwd_admin->password[0] != 0. For the second check, replace the check with checking that auth_str is set instead. Cc: Mark Pearson <markpearson@lenovo.com> Reported-by:
coverity-bot <keescook+coverity-bot@chromium.org> Addresses-Coverity-ID: 1505158 ("NO_EFFECT") Fixes: a7314b3b1d8a ("platform/x86: think-lmi: Add WMI interface support on Lenovo platforms") Signed-off-by:
-
Hans de Goede authored
The dell-wmi-sysman and think-lmi kernel modules both have a global struct class *fw_attr_class variable, leading to the following compile errors when both are builtin: ld: drivers/platform/x86/think-lmi.o:(.bss+0x0): multiple definition of `fw_attr_class'; drivers/platform/x86/dell/dell-wmi-sysman/sysman.o:(.bss+0x0): first defined here In both cases the variable is only used in the file where it is declared. Make both declarations static to avoid the linker error. Cc: Mark Pearson <markpearson@lenovo.com> Cc: Dell.Client.Kernel@dell.com Reported-by:
Nathan Chancellor <nathan@kernel.org> Signed-off-by:
-
yangerkun authored
drivers/platform/x86/intel_ips.c:832:6: warning: variable ‘ret’ set but not used [-Wunused-but-set-variable] 832 | u16 ret; | ^~~ Fix it by mark ret as '__maybe_unused'. Reported-by:yangerkun <yangerkun@huawei.com> Link: https://lore.kernel.org/r/20210607014702.2981097-1-yangerkun@huawei.comSigned-off-by:
-
Rikard Falkeborn authored
The only use of base_attr_group and hubless_base_attr_group is to pass their addresses to sysfs_create_group() and sysfs_remove_group(), both which takes pointers to const attribute_group structs. Make them const to allow the compiler to put them in read-only memory. Signed-off-by:
Rikard Falkeborn <rikard.falkeborn@gmail.com> Reviewed-by:
Justin Ernst <justin.ernst@hpe.com> Link: https://lore.kernel.org/r/20210605203807.60547-5-rikard.falkeborn@gmail.comSigned-off-by:
-
Rikard Falkeborn authored
The only use of tc1100_attribute_group is to pass its address to sysfs_create_group() and sysfs_remove_group(), both which takes pointer to const attribute_group structs. Make it const to allow the compiler to put it in read-only memory. Signed-off-by:
-
Rikard Falkeborn authored
The only use of pmt_crashlog_group is to assign its address to the attr_grp field in the intel_pmt_namespace struct, which is a pointer to const attribute_group. Make it const to allow the compiler to put it in read-only memory. Signed-off-by:
-
Rikard Falkeborn authored
The only use of hdaps_attribute_group is to pass its address to sysfs_create_group() and sysfs_remove_group(), both which takes pointers to const attribute_group structs. Make it const to allow the compiler to put it in read-only memory. Signed-off-by:
Frank Seidel <frank@f-seidel.de> Link: https://lore.kernel.org/r/20210605203807.60547-2-rikard.falkeborn@gmail.comSigned-off-by:
-
Baokun Li authored
platform/surface: aggregator: Use list_move_tail instead of list_del/list_add_tail in ssh_packet_layer.c Using list_move_tail() instead of list_del() + list_add_tail() in ssh_packet_layer.c. Reported-by:
Baokun Li <libaokun1@huawei.com> Reviewed-by:
-
Baokun Li authored
platform/surface: aggregator: Use list_move_tail instead of list_del/list_add_tail in ssh_request_layer.c Using list_move_tail() instead of list_del() + list_add_tail() in ssh_request_layer.c. Reported-by:
-
Maximilian Luz authored
The status variable in ssam_controller_event_disable() is always set, no need to initialize it. Signed-off-by:
-
Maximilian Luz authored
The status variable in ssam_nf_refcount_disable_free() is only set when the reference count equals zero. Otherwise, it is returned uninitialized. Fix this by always initializing status to zero. Reported-by:
kernel test robot <lkp@intel.com> Fixes: 640ee17199e4 ("platform/surface: aggregator: Allow enabling of events without notifiers") Signed-off-by:
-
Maximilian Luz authored
Update the controller-device user-space interface (cdev) documentation for the newly introduced IOCTLs and event interface. Signed-off-by:
-
Maximilian Luz authored
Mark functions with locking requirements via the corresponding lockdep calls for debugging and documentary purposes. Signed-off-by:
-
Maximilian Luz authored
While events can already be enabled and disabled via the generic request IOCTL, this bypasses the internal reference counting mechanism of the controller. Due to that, disabling an event will turn it off regardless of any other client having requested said event, which may break functionality of that client. To solve this, add IOCTLs wrapping the ssam_controller_event_enable() and ssam_controller_event_disable() functions, which have been previously introduced for this specific purpose. Signed-off-by:
-
Maximilian Luz authored
Currently, debugging unknown events requires writing a custom driver. This is somewhat difficult, slow to adapt, and not entirely user-friendly for quickly trying to figure out things on devices of some third-party user. We can do better. We already have a user-space interface intended for debugging SAM EC requests, so let's add support for receiving events to that. This commit provides support for receiving events by reading from the controller file. It additionally introduces two new IOCTLs to control which event categories will be forwarded. Specifically, a user-space client can specify which target categories it wants to receive events from by registering the corresponding notifier(s) via the IOCTLs and after that, read the received events by reading from the controller device. Signed-off-by:
-
Maximilian Luz authored
It's 2021, update the copyright accordingly. Signed-off-by:
-
Maximilian Luz authored
We can already enable and disable SAM events via one of two ways: either via a (non-observer) notifier tied to a specific event group, or a generic event enable/disable request. In some instances, however, neither method may be desirable. The first method will tie the event enable request to a specific notifier, however, when we want to receive notifications for multiple event groups of the same target category and forward this to the same notifier callback, we may receive duplicate events, i.e. one event per registered notifier. The second method will bypass the internal reference counting mechanism, meaning that a disable request will disable the event regardless of any other client driver using it, which may break the functionality of that driver. To address this problem, add new functions that allow enabling and disabling of events via the event reference counting mechanism built into the controller, without needing to register a notifier. This can then be used in combination with observer notifiers to process multiple events of the same target category without duplication in the same callback function. Signed-off-by:
-
Maximilian Luz authored
Currently, each SSAM event notifier is directly tied to one group of events. This makes sense as registering a notifier will automatically take care of enabling the corresponding event group and normally drivers only need notifications for a very limited number of events, associated with different callbacks for each group. However, there are rare cases, especially for debugging, when we want to get notifications for a whole event target category instead of just a single group of events in that category. Registering multiple notifiers, i.e. one per group, may be infeasible due to two issues: a) we might not know every event enable/disable specification as some events are auto-enabled by the EC and b) forwarding this to the same callback will lead to duplicate events as we might not know the full event specification to perform the appropriate filtering. This commit introduces observer-notifiers, which are notifiers that are not tied to a specific event group and do not attempt to manage any events. In other words, they can be registered without enabling any event group or incrementing the corresponding reference count and just act as silent observers, listening to all currently/previously enabled events based on their match-specification. Essentially, this allows us to register one single notifier for a full event target category, meaning that we can process all events of that target category in a single callback without duplication. Specifically, this will be used in the cdev debug interface to forward events to user-space via a device file from which the events can be read. Signed-off-by:
-
