summaryrefslogtreecommitdiff
path: root/drivers/platform
AgeCommit message (Collapse)Author
2020-03-28platform/chrome: cros_ec_sensorhub: Add median filterGwendal Grignou
Events are timestamped in EC time space, their timestamps need to be converted in host time space. The assumption is the time delta between when the interrupt is sent by the EC and when it is receive by the host is a [small] constant. This is not always true, even with hard-wired interrupt. To mitigate worst offenders, add a median filter to weed out bigger than expected delays. Signed-off-by: Gwendal Grignou <gwendal@chromium.org> Acked-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Acked-by: Lee Jones <lee.jones@linaro.org> Acked-by: Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
2020-03-28platform/chrome: cros_ec_sensorhub: Add code to spread timestmapGwendal Grignou
EC FIFO can send sensor events in batch. Spread them based on previous (TSa) and currnet timestamp (TSb) EC FIFO iio events +-----------+ | TSa | +-----------+ +---------------------------------------+ | event 1 | | event 1 | TSb - (TSb - TSa)/n * (n-1) | +-----------+ +---------------------------------------+ | event 2 | | event 2 | TSb - (TSb - TSa)/n * (n-2) | +-----------+ +---------------------------------------+ | ... | ------> | .... | | +-----------+ +---------------------------------------+ | event n-1 | | event 2 | TSb - (TSb - TSa)/n | +-----------+ +---------------------------------------+ | event n | | event 2 | TSb | +-----------+ +---------------------------------------+ | TSb | +-----------+ Signed-off-by: Gwendal Grignou <gwendal@chromium.org> Acked-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Acked-by: Lee Jones <lee.jones@linaro.org> Acked-by: Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
2020-03-28platform/chrome: cros_ec_sensorhub: Add FIFO supportGwendal Grignou
cros_ec_sensorhub registers a listener and query motion sense FIFO, spread to iio sensors registers. To test, we can use libiio: iiod& iio_readdev -u ip:localhost -T 10000 -s 25 -b 16 cros-ec-gyro | od -x Signed-off-by: Gwendal Grignou <gwendal@chromium.org> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Acked-by: Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
2020-03-28platform/chrome: cros_ec_sensorhub: Add the number of sensors in sensorhubGwendal Grignou
To better manage resources, store the number of sensors reported by the EC. Signed-off-by: Gwendal Grignou <gwendal@chromium.org> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
2020-03-28platform/x86: surface3_power: Fix Kconfig section orderingAndy Shevchenko
Kconfig section is misplaced. Put it in the same order as it is done in Makefile for this driver. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
2020-03-28platform/x86: surface3_power: Add missed headersAndy Shevchenko
We obviously are users of bits.h and types.h. Add them to the list. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
2020-03-28platform/x86: surface3_power: Reformat GUID assignmentAndy Shevchenko
For better readability reformat GUID assignment. While here, add the comment how this GUID looks in a string representation. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
2020-03-28platform/x86: surface3_power: Drop useless macro ACPI_PTR()Andy Shevchenko
Driver depends to ACPI, this marco always is evaluated to the parameter, thus useless. Drop it for good. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
2020-03-28platform/x86: surface3_power: Prefix POLL_INTERVAL with SURFACE_3Andy Shevchenko
For better namespace maintenance prefix POLL_INTERVAL macro with SURFACE_3. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
2020-03-28platform/x86: surface3_power: Simplify mshw0011_adp_psr() to one linerAndy Shevchenko
Refactor mshw0011_adp_psr() to be one liner. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
2020-03-28platform/x86: surface3_power: Use dev_err() instead of pr_err()Andy Shevchenko
We have device and we may use it to print messages. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
2020-03-28platform/x86: surface3_power: Drop unused structure definitionAndy Shevchenko
As reported by kbuild bot the struct mshw0011_lookup in never used. Drop its definition for good. Reported-by: kbuild test robot <lkp@intel.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
2020-03-27platform/chrome: chromeos_laptop: make I2C API conversion completeWolfram Sang
When converting to i2c_new_scanned_device(), it was overlooked that a conversion to i2c_new_client_device() was also needed. Fix it. Fixes: c82ebf1bf738 ("platform/chrome: chromeos_laptop: Convert to i2c_new_scanned_device") Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
2020-03-26platform/x86: surface3_power: MSHW0011 rev-eng implementationBlaž Hrastnik
Patch was rebased on top of for-next. Thanks for your patience! Blaž I'm resubmitting this patch with review feedback addressed: https://patchwork.kernel.org/patch/10584079/ The patch was previously not resubmitted because it required a change that was reverted in the ACPICA. That has since been corrected: https://github.com/acpica/acpica/commit/9159c09a2a5897a43f78c95cdffc160d399722c3 We've been using this patch for a while and user reports confirm that it works: https://github.com/linux-surface/linux-surface Previous description follows. >8------------------------------------------------------8< The MSHW0011 device is a chip that replaces the battery firmware by using ACPI operation regions on the Surface 3. It is unclear whether or not the chip will be reused somewhere else (under Windows, the chip is called "Surface Platform Power Driver" and the driver is provided by Microsoft). The values have been obtained by reverse engineering, and are subject to errors. Looks like it works on overall pretty well. I couldn't manage to get the IRQ correctly triggered, so I am using a good old polling thread to check for changes. This is something to be fixed in a later version. Link: https://bugzilla.kernel.org/show_bug.cgi?id=106231 Signed-off-by: Blaž Hrastnik <blaz@mxxn.io> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by: Stephen Just <stephenjust@gmail.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
2020-03-25Merge branch 'x86/cpu' into perf/core, to resolve conflictIngo Molnar
Conflicts: arch/x86/events/intel/uncore.c Signed-off-by: Ingo Molnar <mingo@kernel.org>
2020-03-24platform/x86: Convert to new CPU match macrosThomas Gleixner
The new macro set has a consistent namespace and uses C99 initializers instead of the grufty C89 ones. Get rid the of the local macro wrappers for consistency. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Borislav Petkov <bp@suse.de> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Link: https://lkml.kernel.org/r/20200320131509.766573641@linutronix.de
2020-03-22platform/chrome: wilco_ec: event: Replace zero-length array with ↵Gustavo A. R. Silva
flexible-array member The current codebase makes use of the zero-length array language extension to the C90 standard, but the preferred mechanism to declare variable-length types such as these ones is a flexible array member[1][2], introduced in C99: struct foo { int stuff; struct boo array[]; }; By making use of the mechanism above, we will get a compiler warning in case the flexible array does not occur last in the structure, which will help us prevent some kind of undefined behavior bugs from being inadvertently introduced[3] to the codebase from now on. Also, notice that, dynamic memory allocations won't be affected by this change: "Flexible array members have incomplete type, and so the sizeof operator may not be applied. As a quirk of the original implementation of zero-length arrays, sizeof evaluates to zero."[1] This issue was found with the help of Coccinelle. [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html [2] https://github.com/KSPP/linux/issues/21 [3] commit 76497732932f ("cxgb3/l2t: Fix undefined behaviour") Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
2020-03-22platform/chrome: cros_ec_chardev: Replace zero-length array with ↵Gustavo A. R. Silva
flexible-array member The current codebase makes use of the zero-length array language extension to the C90 standard, but the preferred mechanism to declare variable-length types such as these ones is a flexible array member[1][2], introduced in C99: struct foo { int stuff; struct boo array[]; }; By making use of the mechanism above, we will get a compiler warning in case the flexible array does not occur last in the structure, which will help us prevent some kind of undefined behavior bugs from being inadvertently introduced[3] to the codebase from now on. Also, notice that, dynamic memory allocations won't be affected by this change: "Flexible array members have incomplete type, and so the sizeof operator may not be applied. As a quirk of the original implementation of zero-length arrays, sizeof evaluates to zero."[1] This issue was found with the help of Coccinelle. [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html [2] https://github.com/KSPP/linux/issues/21 [3] commit 76497732932f ("cxgb3/l2t: Fix undefined behaviour") Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
2020-03-22platform/chrome: cros_ec_typec: Update port info from ECPrashant Malani
After registering the ports at probe, get the current port information from EC and update the Type C connector class ports accordingly. Co-developed-by: Jon Flatley <jflat@chromium.org> Signed-off-by: Prashant Malani <pmalani@chromium.org> Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
2020-03-22platform/chrome: Add Type C connector class driverPrashant Malani
Add a driver to implement the Type C connector class for Chrome OS devices with ECs (Embedded Controllers). The driver relies on firmware device specifications for various port attributes. On ACPI platforms, this is specified using the logical device with HID GOOG0014. On DT platforms, this is specified using the DT node with compatible string "google,cros-ec-typec". The driver reads the device FW node and uses the port attributes to register the typec ports with the Type C connector class framework, but doesn't do much else. Subsequent patches will add more functionality to the driver, including obtaining current port information (polarity, vconn role, current power role etc.) after querying the EC. Co-developed-by: Benson Leung <bleung@chromium.org> Signed-off-by: Prashant Malani <pmalani@chromium.org> Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
2020-03-21acpi: Remove header dependencyPeter Zijlstra
In order to avoid future header hell, remove the inclusion of proc_fs.h from acpi_bus.h. All it needs is a forward declaration of a struct. Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Acked-by: Andy Shevchenko <andy.shevchenko@gmail.com> Link: https://lkml.kernel.org/r/20200321113241.246190285@linutronix.de
2020-03-20platform/x86: touchscreen_dmi: Add info for the Chuwi Vi8 Plus tabletHans de Goede
Add touchscreen info for the Chuwi Vi8 Plus tablet. This tablet uses a Chipone ICN8505 touchscreen controller, with the firmware used by the touchscreen embedded in the EFI firmware. Acked-by: Andy Shevchenko <andy.shevchenko@gmail.com> Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20200115163554.101315-11-hdegoede@redhat.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-03-20platform/x86: touchscreen_dmi: Add EFI embedded firmware info supportHans de Goede
Sofar we have been unable to get permission from the vendors to put the firmware for touchscreens listed in touchscreen_dmi in linux-firmware. Some of the tablets with such a touchscreen have a touchscreen driver, and thus a copy of the firmware, as part of their EFI code. This commit adds the necessary info for the new EFI embedded-firmware code to extract these firmwares, making the touchscreen work OOTB without the user needing to manually add the firmware. Acked-by: Andy Shevchenko <andy.shevchenko@gmail.com> Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20200115163554.101315-10-hdegoede@redhat.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-03-20platform/x86: intel_pmc_core: Make pmc_core_substate_res_show() genericGayatri Kammela
Currently pmc_core_substate_res_show() uses array of char pointers i.e., lpm_modes for Tiger Lake directly to iterate through and to get the number of low power modes which is hardcoded and cannot be re-used for future platforms that support sub-states. To maintain readability, make pmc_core_substate_res_show() generic, so that it can re-used for future platforms. Cc: Chen Zhou <chenzhou10@huawei.com> Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Cc: David E. Box <david.e.box@intel.com> Signed-off-by: Gayatri Kammela <gayatri.kammela@intel.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
2020-03-20platform/x86: intel_pmc_core: Make pmc_core_lpm_display() generic for ↵Gayatri Kammela
platforms that support sub-states Currently pmc_core_lpm_display() uses an array of the struct pointers, i.e. tgl_lpm_maps for Tiger Lake directly to iterate through and to get the number of (live) status registers which is hard coded and can not be re-used for the future platforms that support sub-states. To maintain readability, make pmc_core_lpm_display() generic, so that it can be re-used for future platforms. Cc: Chen Zhou <chenzhou10@huawei.com> Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Cc: David E. Box <david.e.box@intel.com> Suggested-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Gayatri Kammela <gayatri.kammela@intel.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
2020-03-20platform/x86: sony-laptop: Use scnprintf() for avoiding potential buffer ↵Takashi Iwai
overflow Since snprintf() returns the would-be-output size instead of the actual output size, the succeeding calls may go beyond the given buffer limit. Fix it by replacing with scnprintf(). Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
2020-03-20platform/x86: GPD pocket fan: Fix error message when temp-limits are out of ↵Hans de Goede
range Commit 1f27dbd8265d ("platform/x86: GPD pocket fan: Allow somewhat lower/higher temperature limits") changed the module-param sanity check to accept temperature limits between 20 and 90 degrees celcius. But the error message printed when the module params are outside this range was not updated. This commit updates the error message to match the new min and max value for the temp-limits. Reported-by: Pavel Machek <pavel@denx.de> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Acked-by: Pavel Machek <pavel@denx.de> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
2020-03-20platform/x86: ISST: Fix wrong unregister typeSrinivas Pandruvada
The MMIO driver is not unregistering with the correct type with the ISST common core during module removal. This should be unregistered with ISST_IF_DEV_MMIO instead of ISST_IF_DEV_MBOX. Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
2020-03-20platform/x86: asus_wmi: Fix return value of fan_boost_mode_storeLeonid Maksymchuk
Function fan_boost_mode_store returns 0 if store is successful, this leads to infinite loop after any write to it's sysfs entry: # echo 0 >/sys/devices/platform/asus-nb-wmi/fan_boost_mode This command never ends, one CPU core is at 100% utilization. This patch fixes this by returning size of written data. Fixes: b096f626a682 ("platform/x86: asus-wmi: Switch fan boost mode") Signed-off-by: Leonid Maksymchuk <leonmaxx@gmail.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
2020-03-20platform/x86: asus-wmi: Support laptops where the first battery is named BATTKristian Klausen
The WMI method to set the charge threshold does not provide a way to specific a battery, so we assume it is the first/primary battery (by checking if the name is BAT0). On some newer ASUS laptops (Zenbook UM431DA) though, the primary/first battery isn't named BAT0 but BATT, so we need to support that case. Fixes: 7973353e92ee ("platform/x86: asus-wmi: Refactor charge threshold to use the battery hooking API") Cc: stable@vger.kernel.org Signed-off-by: Kristian Klausen <kristian@klausen.dk> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
2020-03-17platform/chrome: cros_usbpd_notify: Pull PD_HOST_EVENT statusPrashant Malani
Read the PD host even status from the EC and send that to the notifier listeners, for more fine-grained event information. Signed-off-by: Prashant Malani <pmalani@chromium.org> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> Signed-off-by: Benson Leung <bleung@chromium.org>
2020-03-17platform/chrome: cros_usbpd_notify: Amend ACPI driver to platPrashant Malani
Convert the ACPI driver into the equivalent platform driver, with the same ACPI match table as before. This allows the device driver to access the parent platform EC device and its cros_ec_device struct, which will be required to communicate with the EC to pull PD Host event information from it. Also change the ACPI driver name to "cros-usbpd-notify-acpi" so that there is no confusion between it and the "regular" platform driver on platforms that have both CONFIG_ACPI and CONFIG_OF enabled. Signed-off-by: Prashant Malani <pmalani@chromium.org> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> Signed-off-by: Benson Leung <bleung@chromium.org>
2020-03-17platform/chrome: cros_usbpd_notify: Add driver data structPrashant Malani
Introduce a device driver data structure, cros_usbpd_notify_data, in which we can store the notifier block object and pointers to the struct cros_ec_device and struct device objects. This will make it more convenient to access these pointers when executing both platform and ACPI callbacks. Signed-off-by: Prashant Malani <pmalani@chromium.org> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> Signed-off-by: Benson Leung <bleung@chromium.org>
2020-03-17platform/chrome: cros_usbpd_notify: Fix cros-usbpd-notify notifierGwendal Grignou
cros-usbpd-notify notifier was returning NOTIFY_BAD when no host event was available in the MKBP message. But MKBP messages are used to transmit other information, so return NOTIFY_DONE instead, to allow other notifier to be called. Fixes: ec2daf6e33f9f ("platform: chrome: Add cros-usbpd-notify driver") Signed-off-by: Gwendal Grignou <gwendal@chromium.org> Signed-off-by: Benson Leung <bleung@chromium.org> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
2020-03-06platform/chrome: Kconfig: Remove CONFIG_ prefix from MFD_CROS_EC sectionEnric Balletbo i Serra
Remove the CONFIG_ prefix from the select statement for MFD_CROS_EC. Fixes: 2fa2b980e3fe1 ("mfd / platform: cros_ec: Rename config to a better name") Reported-by: Randy Dunlap <rdunlap@infradead.org> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by: Randy Dunlap <rdunlap@infradead.org>
2020-03-02platform/chrome: cros_ec: Use cros_ec_cmd_xfer_status helperEnric Balletbo i Serra
This patch makes use of cros_ec_cmd_xfer_status() instead of cros_ec_cmd_xfer(). In this case the change is trivial and the only reason to do it is because we want to make cros_ec_cmd_xfer() a private function for the EC protocol and let people only use the cros_ec_cmd_xfer_status() to return Linux standard error codes. Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> Tested-by: Prashant Malani <pmalani@chromium.org>
2020-03-02platform/chrome: cros_ec_lightbar: Use cros_ec_cmd_xfer_status helperEnric Balletbo i Serra
This patch makes use of cros_ec_cmd_xfer_status() instead of cros_ec_cmd_xfer(). It allows us to remove some redundand code. In this case, though, we are changing a bit the behaviour because of returning -EINVAL on protocol error we propagate the error return for cros_ec_cmd_xfer_status() function, but I think it will be fine, even more clear as we don't mask the Linux error code. Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> Tested-by: Prashant Malani <pmalani@chromium.org>
2020-03-02platform/chrome: cros_ec_sysfs: Use cros_ec_cmd_xfer_status helperEnric Balletbo i Serra
This patch makes use of cros_ec_cmd_xfer_status() instead of cros_ec_cmd_xfer(). In this case the change is trivial and the only reason to do it is because we want to make cros_ec_cmd_xfer() a private function for the EC protocol and let people only use the cros_ec_cmd_xfer_status() to return Linux standard error codes. Looking at the code I am even unsure that makes sense differentiate these two errors but let's not change the behaviour for now. Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> Tested-by: Prashant Malani <pmalani@chromium.org>
2020-03-02platform/chrome: cros_ec_chardev: Use cros_ec_cmd_xfer_status helperEnric Balletbo i Serra
This patch makes use of cros_ec_cmd_xfer_status() instead of cros_ec_cmd_xfer(). In this case the change is trivial and the only reason to do it is because we want to make cros_ec_cmd_xfer() a private function for the EC protocol and let people only use the cros_ec_cmd_xfer_status() to return Linux standard error codes. Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> Tested-by: Prashant Malani <pmalani@chromium.org>
2020-03-02platform/chrome: cros_ec_vbc: Use cros_ec_cmd_xfer_status helperEnric Balletbo i Serra
This patch makes use of cros_ec_cmd_xfer_status() instead of cros_ec_cmd_xfer(). In this case the change is trivial and the only reason to do it is because we want to make cros_ec_cmd_xfer() a private function for the EC protocol and let people only use the cros_ec_cmd_xfer_status() to return Linux standard error codes. Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> Tested-by: Prashant Malani <pmalani@chromium.org>
2020-03-02platform/chrome: cros_ec_proto: Report command not supportedEnric Balletbo i Serra
In practice most drivers that use the EC protocol what really care is if the result was successful or not, hence, we introduced a cros_ec_cmd_xfer_status() function that converts EC errors to standard Linux error codes. On some few cases, though, we are interested on know if the command is supported or not, and in such cases, just ignore the error. To achieve this, return a -ENOTSUPP error when the command is not supported. This will allow us to finish the conversion of all users to use the cros_ec_cmd_xfer_status() function instead of cros_ec_cmd_xfer() and make the latest private to the protocol driver, so users of the protocol are not confused in which function they should use. Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> Tested-by: Prashant Malani <pmalani@chromium.org>
2020-03-02platform/chrome: cros_ec_spi: Use new structure for SPI transfer delaysSergiu Cuciurean
In a recent change to the SPI subsystem [1], a new `delay` struct was added to replace the `delay_usecs`. This change replaces the current `delay_usecs` with `delay` for this driver. The `spi_transfer_delay_exec()` function [in the SPI framework] makes sure that both `delay_usecs` & `delay` are used (in this order to preserve backwards compatibility). [1] commit bebcfd272df6 ("spi: introduce `delay` field for `spi_transfer` + spi_transfer_delay_exec()") Signed-off-by: Sergiu Cuciurean <sergiu.cuciurean@analog.com> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
2020-03-02platform/chrome: cros_ec_rpmsg: Fix race with host eventPi-Hsun Shih
Host event can be sent by remoteproc by any time, and cros_ec_rpmsg_callback would be called after cros_ec_rpmsg_create_ept. But the cros_ec_device is initialized after that, which cause host event handler to use cros_ec_device that are not initialized properly yet. Fix this by don't schedule host event handler before cros_ec_register returns. Instead, remember that we have a pending host event, and schedule host event handler after cros_ec_register. Fixes: 71cddb7097e2 ("platform/chrome: cros_ec_rpmsg: Fix race with host command when probe failed.") Signed-off-by: Pi-Hsun Shih <pihsun@chromium.org> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
2020-02-28platform/x86: Kconfig: Fix a typoChristophe JAILLET
'paramaters' should be 'parameters' Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
2020-02-28platform/x86: i2c-multi-instantiate: Replace zero-length array with ↵Gustavo A. R. Silva
flexible-array member The current codebase makes use of the zero-length array language extension to the C90 standard, but the preferred mechanism to declare variable-length types such as these ones is a flexible array member[1][2], introduced in C99: struct foo { int stuff; struct boo array[]; }; By making use of the mechanism above, we will get a compiler warning in case the flexible array does not occur last in the structure, which will help us prevent some kind of undefined behavior bugs from being inadvertently introduced[3] to the codebase from now on. Also, notice that, dynamic memory allocations won't be affected by this change: "Flexible array members have incomplete type, and so the sizeof operator may not be applied. As a quirk of the original implementation of zero-length arrays, sizeof evaluates to zero."[1] This issue was found with the help of Coccinelle. [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html [2] https://github.com/KSPP/linux/issues/21 [3] commit 76497732932f ("cxgb3/l2t: Fix undefined behaviour") Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
2020-02-28platform/x86/intel-uncore-freq: Add release callbackSrinivas Pandruvada
On module unload wait for relese callback for each packag_die entry and then free the memory. This is done by waiting on a completion object, till release() callback. While here, also change to kobject_init_and_add() to kobject_create_and_add() to simplify. Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
2020-02-28platform/x86/intel-uncore-freq: Fix static checker issue and potential race ↵Srinivas Pandruvada
condition There is a possible race condition when: All CPUs in a package is offlined and just before the last CPU offline, user tries to read sysfs entry and read happens while offline callback is about to delete the sysfs entry. Although not reproduced but this is possible scenerio and can be reproduced by adding a msleep() in the show_min_max_freq_khz() before mutex_lock() and read min_freq attribute from user space. Before msleep() finishes, force every CPUs in a package offline. This will cause deadlock, with offline and sysfs read/write operation because of mutex_lock. The uncore_remove_die_entry() will not release mutex till read/write callback returns because of kobject_put() and read/write callback waiting on mutex. We don't have to remove the sysfs folder when the package is offline. While there is no CPU present, we can fail the read/write calls by returning ENXIO error. So remove the kobject_put() call in offline path. This also address the warning from static checker, as there is no access to "data" variable after kobject_put: "The patch 49a474c7ba51: "platform/x86: Add support for Uncore frequency control" from Jan 13, 2020, leads to the following static checker warning: drivers/platform/x86/intel-uncore-frequency.c:285 uncore_remove_die_entry() error: dereferencing freed memory 'data' " Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
2020-02-28platform/x86: intel_pmc_core: Add slp_s0_offset attribute back to tgl_reg_mapGayatri Kammela
If platforms such as Tiger Lake has sub-states of S0ix, then attributes such as slps0_dbg_offset become invalid. But slp_s0_offset is still valid as it is used to get the pmcdev_base_addr. Hence, add back slp_s0_offset and remove slps0_dbg_offset attributes. Cc: Chen Zhou <chenzhou10@huawei.com> Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Cc: David E. Box <david.e.box@intel.com> Signed-off-by: Gayatri Kammela <gayatri.kammela@intel.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
2020-02-28platform/x86: intel_pmc_core: Remove duplicate 'if' to create debugfs entryGayatri Kammela
A debugfs entry for substate_live_status_registers is created only if the platform has sub-states, which requires the same condition to create substate_status_registers debugfs entry. Hence remove the redundant condition and re-use the existing one. Cc: Chen Zhou <chenzhou10@huawei.com> Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Cc: David E. Box <david.e.box@intel.com> Signed-off-by: Gayatri Kammela <gayatri.kammela@intel.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
2020-02-28platform/x86: intel_pmc_core: Relocate pmc_core_*_display() to outside of ↵Gayatri Kammela
CONFIG_DEBUG_FS Since pmc_core_slps0_display() and pmc_core_lpm_display() is responsible for dumping as well as displaying debug registers, there is no need for these two functions to be defined under CONFIG_DEBUG_FS. Hence, relocate these functions from under CONFIG_DEBUG_FS to above the block. Cc: Chen Zhou <chenzhou10@huawei.com> Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Cc: David E. Box <david.e.box@intel.com> Signed-off-by: Gayatri Kammela <gayatri.kammela@intel.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>