aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/platform (follow)
AgeCommit message (Collapse)AuthorFilesLines
2019-02-23platform/x86: asus-wmi: Allow loading on systems without the Asus Management GUIDHans de Goede1-7/+2
hid-asus depends on asus-wmi through the asus_wmi_evaluate_method. Before this commit asus-wmi, and thus hid-asus, could not be loaded on non-Asus systems. This breaks using Asus bluetooth keyboards such as the Asus T100CHI keyboard with non Asus systems. This commit fixes this by allowing asus-wmi to load on systems without the Asus Management GUID. This is safe to do since all asus-wmi sub drivers use asus_wmi_register_driver which also checks for the GUID. This commit also improves the error messages in asus_wmi_register_driver to include "ASUS" in their description to make them more clear. This is important since we now rely on those errors when loaded on systems without the Asus Management GUID. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Darren Hart (VMware) <dvhart@infradead.org>
2019-02-22x86: pcengines apuv2 gpio/leds/keys platform driverEnrico Weigelt, metux IT consult3-0/+274
Driver for PCengines APUv2 board's front LEDs and Button, which are attached to AMD PCH GPIOs. Due to lack of dedicated ACPI entry, detecting the board via DMI. Cc: linux-gpio@vger.kernel.org Cc: linus.walleij@linaro.org Cc: bgolaszewski@baylibre.com Cc: dvhart@infradead.org Cc: platform-driver-x86@vger.kernel.org Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2019-02-21platform/chrome: wilco_ec: Add RTC driverNick Crews1-0/+18
This Embedded Controller has an internal RTC that is exposed as a standard RTC class driver with read/write functionality. The driver is added to the drivers/rtc/ so that the maintainer of that directory will be able to comment on this change, as that maintainer is the expert on this system. In addition, the driver code is called indirectly after a corresponding device is registered from core.c, as opposed to core.c registering the driver callbacks directly. To test: > hwclock --show --rtc /dev/rtc1 2007-12-31 16:01:20.460959-08:00 > hwclock --systohc --rtc /dev/rtc1 > hwclock --show --rtc /dev/rtc1 2018-11-29 17:08:00.780793-08:00 > hwclock --show --rtc /dev/rtc1 2007-12-31 16:01:20.460959-08:00 > hwclock --systohc --rtc /dev/rtc1 > hwclock --show --rtc /dev/rtc1 2018-11-29 17:08:00.780793-08:00 Signed-off-by: Duncan Laurie <dlaurie@google.com> Signed-off-by: Nick Crews <ncrews@chromium.org> Acked-by: Alexandre Belloni <alexandre.belloni@bootlin.com> [Fix the sparse warning: symbol 'wilco_ec_rtc_read/write' was not declared] Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
2019-02-21platform/chrome: wilco_ec: Add support for raw commands in debugfsNick Crews4-0/+264
Add a debugfs attribute that allows sending raw commands to the EC. This is useful for development and debug but should not be enabled in a production environment. To test: Get the EC firmware build date First send the request command > echo 00 f0 38 00 03 00 > raw Then read the result. "12/21/18" is in the middle of the response > cat raw 00 31 32 2f 32 31 2f 31 38 00 00 0f 01 00 01 00 .12/21/18....... Get the EC firmware build date First send the request command > echo 00 f0 38 00 03 00 > raw Then read the result. "12/21/18" is in the middle of the response > cat raw 00 31 32 2f 32 31 2f 31 38 00 00 0f 01 00 01 00 .12/21/18....... Signed-off-by: Duncan Laurie <dlaurie@google.com> Signed-off-by: Nick Crews <ncrews@chromium.org> [Fix off-by-one error in wilco_ec/debugfs.c] Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
2019-02-21platform/chrome: Add new driver for Wilco ECNick Crews6-0/+359
This EC is an incompatible variant of the typical Chrome OS embedded controller. It uses the same low-level communication and a similar protocol with some significant differences. The EC firmware does not support the same mailbox commands so it is not registered as a cros_ec device type. This commit exports the wilco_ec_mailbox() function so that other modules can use it to communicate with the EC. Signed-off-by: Duncan Laurie <dlaurie@google.com> Signed-off-by: Nick Crews <ncrews@chromium.org> [Fix the sparse warning: symbol 'wilco_ec_transfer' was not declared] Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com> [Fix Kconfig dependencies for wilco_ec] Reported-by: Randy Dunlap <rdunlap@infradead.org> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
2019-02-21platform/x86: intel_pmc_core: Include Reserved IP for LTRRajneesh Bhardwaj2-0/+4
Recently introduced commit "platform/x86: intel_pmc_core: Show Latency Tolerance info <51337cd94d18184601ac0fb4cf1a02b8bbabc3d7> skipped the LTR from a reserved IP. Though this doesn't cause any functional issue but it is needed for the consumers of "ltr_ignore" as the index printing for "ltr_show" is missing. For example, w/o this change, a user that wants to ignore LTR from ME would do something like echo 5 > ltr_ignore but the index for ME is 6. Printing a reserved IP helps to properly calculate LTR ignore offsets. Cc: "David E. Box" <david.e.box@intel.com> Cc: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Signed-off-by: Rajneesh Bhardwaj <rajneesh.bhardwaj@linux.intel.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
2019-02-21platform/x86: intel_pmc_core: Fix file permissions for ltr_showRajneesh Bhardwaj1-1/+1
File permissions for ltr_show attribute should be similar to other debugfs attributes created by this driver. '0644' should be used only when there is a write operation desired such as for ltr_ignore. Cc: "David E. Box" <david.e.box@intel.com> Cc: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Fixes: 2eb150558bb7 ("platform/x86: intel_pmc_core: Show Latency Tolerance info") Signed-off-by: Rajneesh Bhardwaj <rajneesh.bhardwaj@linux.intel.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
2019-02-14platform/x86: intel_cht_int33fe: Remove old style mux connectionsHeikki Krogerus1-15/+6
The new mux connection naming scheme is now in use, so dropping the connections still using the old names. From now on the same connection description named "mode-switch" is used with both the port and the alternate modes, so on CHT the DP alt mode will use the same connection as the port to get a handle to the mux device. Reviewed-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Reviewed-by: Jun Li <jun.li@nxp.com> Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-02-14platform/x86: intel_cht_int33fe: Prepare for better mux naming schemeHeikki Krogerus1-1/+7
Adding new connections with for the muxes with new identifiers. The old connection are left in for now. Reviewed-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Reviewed-by: Jun Li <jun.li@nxp.com> Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-02-11platform/chrome: cros_ec: Remove cros_ec dependency in lpc_mecNick Crews3-59/+83
In order to allow this code to be re-used, remove the dependency on the rest of the cros_ec code from the cros_ec_lpc_mec functions. Instead of using a hardcoded register base address of 0x800 have this be passed in to cros_ec_lpc_mec_init(). The existing cros_ec use case now passes in the 0x800 base address this way. There are some error checks that happen in cros_ec_lpc_mec_in_range() that probably shouldn't be there, as they are checking kernel-space callers and not user-space input. However, we'll just do the refactor in this patch, and in a future patch might remove this error checking and fix all the instances of code that calls this. There's a similar problem in cros_ec_lpc_read_bytes(), where we return a checksum, but on error just return 0. This should probably be changed so that it returns int, but we don't want to have to mess with all the calling code for this fix. Maybe we'll come back through later and fix this. Signed-off-by: Duncan Laurie <dlaurie@google.com> Signed-off-by: Nick Crews <ncrews@chromium.org> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
2019-02-11Merge 5.0-rc6 into char-misc-nextGreg Kroah-Hartman1-0/+2
We need the char-misc fixes in here as well. Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-02-05platform/x86: intel_pmc_core: Fix PCH IP nameRajneesh Bhardwaj1-1/+1
For Cannonlake and Icelake, the IP name for Res_6 should be SPF i.e. South Port F. No functional change is intended other than just renaming the IP appropriately. Cc: "David E. Box" <david.e.box@intel.com> Cc: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Fixes: 291101f6a735 ("platform/x86: intel_pmc_core: Add CannonLake PCH support") Signed-off-by: Rajneesh Bhardwaj <rajneesh.bhardwaj@linux.intel.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
2019-02-05platform/x86: intel_pmc_core: Fix PCH IP sts readingRajneesh Bhardwaj2-2/+3
A previous commit "platform/x86: intel_pmc_core: Make the driver PCH family agnostic <c977b98bbef5898ed3d30b08ea67622e9e82082a>" provided better abstraction to this driver but has some fundamental issues. e.g. the following condition for (index = 0; index < pmcdev->map->ppfear_buckets && index < PPFEAR_MAX_NUM_ENTRIES; index++, iter++) is wrong because for CNL, PPFEAR_MAX_NUM_ENTRIES is hardcoded as 5 which is _wrong_ and even though ppfear_buckets is 8, the loop fails to read all eight registers needed for CNL PCH i.e. PPFEAR0 and PPFEAR1. This patch refactors the pfear show logic to correctly read PCH IP power gating status for Cannonlake and beyond. Cc: "David E. Box" <david.e.box@intel.com> Cc: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Fixes: c977b98bbef5 ("platform/x86: intel_pmc_core: Make the driver PCH family agnostic") Signed-off-by: Rajneesh Bhardwaj <rajneesh.bhardwaj@linux.intel.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
2019-02-05platform/x86: intel_pmc_core: Handle CFL regmap properlyRajneesh Bhardwaj1-1/+1
Only Coffeelake should use Cannonlake regmap other than Cannonlake platform. This allows Coffeelake special handling only when there is no matching PCI device and default reg map selected as per CPUID is for Sunrisepoint PCH. This change is needed to enable support for newer SoCs such as Icelake. Cc: "David E. Box" <david.e.box@intel.com> Cc: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Fixes: 661405bd817b ("platform/x86: intel_pmc_core: Special case for Coffeelake") Acked-by: "David E. Box" <david.e.box@linux.intel.com> Signed-off-by: Rajneesh Bhardwaj <rajneesh.bhardwaj@linux.intel.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
2019-02-05platform/x86: intel_int0002_vgpio: Only implement irq_set_wake on Bay TrailHans de Goede1-6/+26
Commit c3b8e884defa ("platform/x86: intel_int0002_vgpio: Implement irq_set_wake"), was written to fix some wakeup issues on Bay Trail (BYT) devices. We've received a bug report that this causes a suspend regression on some Cherry Trail (CHT) based devices. To fix the issues this causes on CHT devices, this commit modifies the irq_set_wake support so that we only implement irq_set_wake on BYT devices, Fixes: c3b8e884defa ("platform/x86: intel_int0002_vgpio: ... irq_set_wake") Reported-and-tested-by: Maxim Mikityanskiy <maxtram95@gmail.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
2019-02-05platform/x86: ideapad: Add ideapad 330-15ICH to no_hw_rfkillAnthony Wong1-0/+7
Lenovo ideapad 330-15ICH does not have hardware radio switch but driver wrongly reports all radios as hard-blocked, add it to no_hw_rfkill to fix it. BugLink: https://bugs.launchpad.net/bugs/1811815 Signed-off-by: Anthony Wong <anthony.wong@ubuntu.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
2019-02-05platform/x86: touchscreen_dmi: Add info for the Chuwi Hi8 Air tabletKai Renzig1-0/+23
Add touchscreen platform data for the Chuwi Hi8 Air tablet. Signed-off-by: Kai Renzig <k.renzig@gmail.com> [andy: fixed driver name and rewrote subject] Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
2019-02-05platform/x86: touchscreen_dmi: Add info for the PoV Wintab P1006w (v1.0) tabletHans de Goede1-0/+29
Add touchscreen info for the Point of View Wintab P1006w (v1.0) tablet. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
2019-02-05platform/x86: dell-wmi: Ignore new keyboard backlight change eventKai-Heng Feng1-0/+3
There's a new wmi event generated by dell-wmi when pressing keyboard backlight hotkey: [ 3285.474172] dell_wmi: Unknown key with type 0x0010 and code 0x003f pressed This event is for notification purpose, let's ignore it. The keyboard backlight hotkey uses another event so it still works without event 0x3f. Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Reviewed-by: Pali Rohár <pali.rohar@gmail.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
2019-02-05ACPI / scan: Create platform device for BSG2150 ACPI nodesHans de Goede1-0/+9
The Point of View TAB-P1006W-232-3G tablet has an ACPI firmware node with a HID of BSG2150 describing the 2 Bosch sensors used in the device a BMC150 compatible accelerometer and a BMC150 compatible magnetometer. The ACPI firmware node actually contains 3 I2cSerialBusV2 resources, but this seems to be a copy and paste job from the BSG1160 firmware node on other devices, since there is no i2c-client listening to the 0x68 address listed in the third resource and the 0x68 address is identical to the address of the third resource in the BSG1160 nodes, where as the other 2 addresses are different. Add the ID to the I2C multi instantiate list, so that the i2c-multi-instantiate.c driver can handle it; And add the necessary info to the i2c-multi-instantiate.c driver to enumerate all I2C slaves correctly. To avoid triggering the: if (i < multi->num_clients) { dev_err(dev, "Error finding driver, idx %d\n", i); Error this commit lists the 3th device in the i2c_inst_data with a type of "bsg2150_dummy_dev". Signed-off-by: Hans de Goede <hdegoede@redhat.com> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
2019-02-01platform/chrome: cros_ec_sysfs: remove pr_fmt() defineEnric Balletbo i Serra1-2/+0
This driver no longer has any pr_{level} messages. Remove the pr_fmt(). Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> Reviewed-by: Guenter Roeck <groeck@chromium.org>
2019-02-01platform/chrome: cros_ec_lightbar: remove pr_fmt() defineEnric Balletbo i Serra1-2/+0
This driver no longer has any pr_{level} messages. Remove the pr_fmt(). Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> Reviewed-by: Guenter Roeck <groeck@chromium.org>
2019-02-01platform/chrome: cros_kbd_led_backlight: switch to SPDX identifierEnric Balletbo i Serra1-15/+4
Adopt the SPDX license identifier headers to ease license compliance management. Also change the term 'Chrome OS' for 'ChromeOS' to be coherent with other drivers. Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> Reviewed-by: Guenter Roeck <groeck@chromium.org>
2019-02-01platform/chrome: cros_ec_spi: switch to SPDX identifierEnric Balletbo i Serra1-15/+5
Adopt the SPDX license identifier headers to ease license compliance management. Also change the description for one more appropriate. Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> Reviewed-by: Guenter Roeck <groeck@chromium.org>
2019-02-01platform/chrome: cros_ec_proto: switch to SPDX identifierEnric Balletbo i Serra1-15/+4
Adopt the SPDX license identifier headers to ease license compliance management. Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> Reviewed-by: Guenter Roeck <groeck@chromium.org>
2019-02-01platform/chrome: cros_ec_lpc: switch to SPDX identifierEnric Balletbo i Serra5-102/+24
Adopt the SPDX license identifier headers to ease license compliance management. Also remove the license boiler-plate and redundant driver description. Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> Reviewed-by: Guenter Roeck <groeck@chromium.org>
2019-02-01platform/chrome: cros_ec_i2c: switch to SPDX identifierEnric Balletbo i Serra1-16/+6
Adopt the SPDX license identifier headers to ease license compliance management. Also fix the module license mismatch and change the description for a more descriptive phrase. Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> Reviewed-by: Guenter Roeck <groeck@chromium.org>
2019-02-01platform/chrome: cros_ec_vbc: switch to SPDX identifierEnric Balletbo i Serra1-19/+5
Adopt the SPDX license identifier headers to ease license compliance management. Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> Reviewed-by: Guenter Roeck <groeck@chromium.org>
2019-02-01platform/chrome: cros_ec_sysfs: switch to SPDX identifierEnric Balletbo i Serra1-19/+5
Adopt the SPDX license identifier headers to ease license compliance management. Also change the description for one more appropriate. Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> Reviewed-by: Guenter Roeck <groeck@chromium.org>
2019-02-01platform/chrome: cros_ec_lightbar: switch to SPDX identifierEnric Balletbo i Serra1-18/+4
Adopt the SPDX license identifier headers to ease license compliance management. Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> Reviewed-by: Guenter Roeck <groeck@chromium.org>
2019-02-01platform/chrome: cros_ec_debugfs: switch to SPDX identifierEnric Balletbo i Serra1-18/+4
Adopt the SPDX license identifier headers to ease license compliance management. Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> Reviewed-by: Guenter Roeck <groeck@chromium.org>
2019-02-01platform/chrome: cromeos_pstore: switch to SPDX identifierEnric Balletbo i Serra1-11/+6
Adopt the SPDX license identifier headers to ease license compliance management. Also fix the module license mismatch and change the term 'Chrome OS' for 'ChromeOS' to be coherent with other drivers. Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> Reviewed-by: Guenter Roeck <groeck@chromium.org>
2019-02-01platform/chrome: cros_ec_lightbar: Instantiate only if the EC has a lightbarEnric Balletbo i Serra1-35/+18
Due to the way attribute groups visibility work, the function cros_ec_lightbar_attrs_are_visible is called multiple times, once per attribute, and each of these calls makes an EC transaction. For what is worth the EC log reports multiple errors on boot when the lightbar is not available. Instead, check if the EC has a lightbar in the probe function and only instantiate the device. Ideally we should have instantiate the driver only if the EC_FEATURE_LIGHTBAR is defined, but that's not possible because that flag is not in the very first Pixel Chromebook (Link), only on Samus. So, the driver is instantiated by his parent always. This patch changes a bit the actual behaviour. Before the patch if an EC doesn't have a lightbar an empty lightbar folder is created in /sys/class/chromeos/<ec-device-name>, after the patch the empty folder is not created, so, the folder is only created if the lightbar exists. Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> Reviewed-by: Guenter Roeck <groeck@chromium.org> Signed-off-by: Lee Jones <lee.jones@linaro.org>
2019-02-01mfd / platform: cros_ec_vbc: Instantiate only if the EC has a VBC NVRAMEnric Balletbo i Serra1-16/+0
The cros-ec-vbc driver is DT-only and there is a DT property that indicates if the EC has the VCB NVRAM, in such case instantiate the driver but don't instantiate on the other cases. To do this move the check code to its parent instead of play with the attribute group visibility. This changes a bit the actual behaviour. Before the patch if an EC doesn't have a VBC NVRAM an empty vbc folder is created in /sys/class/chromeos/<ec-device-name>, after the patch the empty folder is not created, so, the folder is only created if the vbc is set. Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> Reviewed-by: Guenter Roeck <groeck@chromium.org> Signed-off-by: Lee Jones <lee.jones@linaro.org>
2019-02-01mfd / platform: cros_ec: Move device sysfs attributes to its own driverEnric Balletbo i Serra4-7/+48
The entire way how cros debugfs attibutes are created is broken. cros_ec_sysfs should be its own driver and its attributes should be associated with the sysfs driver not the mfd driver. The patch also adds the sysfs documentation. Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> Reviewed-by: Guenter Roeck <groeck@chromium.org> Signed-off-by: Lee Jones <lee.jones@linaro.org>
2019-02-01mfd / platform: cros_ec: Move debugfs attributes to its own driverEnric Balletbo i Serra3-22/+55
The entire way how cros debugfs attibutes are created is broken. cros_ec_debugfs should be its own driver and its attributes should be associated with a debugfs driver not the mfd driver. Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> Reviewed-by: Guenter Roeck <groeck@chromium.org> Signed-off-by: Lee Jones <lee.jones@linaro.org>
2019-02-01mfd / platform: cros_ec: Move vbc attributes to its own driverEnric Balletbo i Serra3-2/+55
The entire way how cros sysfs attibutes are created is broken. cros_ec_vbc should be its own driver and its attributes should be associated with a vbc driver not the mfd driver. In order to retain the path, the vbc attributes are attached to the cros_class. The patch also adds the sysfs documentation. Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> Reviewed-by: Guenter Roeck <groeck@chromium.org> Signed-off-by: Lee Jones <lee.jones@linaro.org>
2019-02-01mfd / platform: cros_ec: Move lightbar attributes to its own driverEnric Balletbo i Serra3-23/+86
The entire way how cros sysfs attibutes are created is broken. cros_ec_lightbar should be its own driver and its attributes should be associated with a lightbar driver not the mfd driver. In order to retain the path, the lightbar attributes are attached to the cros_class. The patch also adds the sysfs documentation. Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> Reviewed-by: Guenter Roeck <groeck@chromium.org> Signed-off-by: Lee Jones <lee.jones@linaro.org>
2019-02-01mfd / platform: cros_ec: Use devm_mfd_add_devicesEnric Balletbo i Serra3-25/+0
Use devm_mfd_add_devices() for adding cros-ec core MFD child devices. This reduces the need of remove callback from platform/chrome for removing the MFD child devices. Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> Reviewed-by: Guenter Roeck <groeck@chromium.org> Signed-off-by: Lee Jones <lee.jones@linaro.org>
2019-01-29platform/x86: Fix unmet dependency warning for SAMSUNG_Q10Sinan Kaya1-0/+1
Add BACKLIGHT_LCD_SUPPORT for SAMSUNG_Q10 to fix the warning: unmet direct dependencies detected for BACKLIGHT_CLASS_DEVICE. SAMSUNG_Q10 selects BACKLIGHT_CLASS_DEVICE but BACKLIGHT_CLASS_DEVICE depends on BACKLIGHT_LCD_SUPPORT. Copy BACKLIGHT_LCD_SUPPORT dependency into SAMSUNG_Q10 to fix: WARNING: unmet direct dependencies detected for BACKLIGHT_CLASS_DEVICE Depends on [n]: HAS_IOMEM [=y] && BACKLIGHT_LCD_SUPPORT [=n] Selected by [y]: - SAMSUNG_Q10 [=y] && X86 [=y] && X86_PLATFORM_DEVICES [=y] && ACPI [=y] Signed-off-by: Sinan Kaya <okaya@kernel.org> Acked-by: Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2019-01-29platform/x86: Fix unmet dependency warning for ACPI_CMPCSinan Kaya1-0/+1
Add BACKLIGHT_LCD_SUPPORT for ACPI_CMPC to fix the warning: unmet direct dependencies detected for BACKLIGHT_CLASS_DEVICE. ACPI_CMPC selects BACKLIGHT_CLASS_DEVICE but BACKLIGHT_CLASS_DEVICE depends on BACKLIGHT_LCD_SUPPORT. Copy BACKLIGHT_LCD_SUPPORT dependency into ACPI_CMPC to fix WARNING: unmet direct dependencies detected for BACKLIGHT_CLASS_DEVICE Depends on [n]: HAS_IOMEM [=y] && BACKLIGHT_LCD_SUPPORT [=n] Selected by [y]: - ACPI_CMPC [=y] && X86 [=y] && X86_PLATFORM_DEVICES [=y] && ACPI [=y] && INPUT [=y] && (RFKILL [=n] || RFKILL [=n]=n) Signed-off-by: Sinan Kaya <okaya@kernel.org> Acked-by: Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2019-01-28Merge 5.0-rc4 into char-misc-nextGreg Kroah-Hartman1-3/+3
We need the char-misc fixes in here as well. Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-01-26platform/x86: mlx-platform: Add support for new VMOD0007 board nameVadim Pasternak1-0/+13
Add support for new Mellanox system type MSN3700C, which is a cost reduced flavor of the MSN37 system class. Signed-off-by: Vadim Pasternak <vadimp@mellanox.com> Signed-off-by: Darren Hart (VMware) <dvhart@infradead.org>
2019-01-26platform/x86: mlx-platform: Add support for fan capability registersVadim Pasternak2-1/+91
Provide support for the fan capability registers for the next generation systems of types MQM87xx, MSN34xx, MSN37xx. These new registers provide configuration for tachometers and fan drawers connectivity. Use these registers for next generation led, fan and hotplug structures in order to distinguish between the systems which have minor configuration differences. This reduces the amount of code used to describe such systems. Signed-off-by: Vadim Pasternak <vadimp@mellanox.com> Signed-off-by: Darren Hart (VMware) <dvhart@infradead.org>
2019-01-26platform/x86: mlx-platform: Add support for fan direction registerVadim Pasternak1-0/+9
Provide support for the fan direction register. This register shows configuration for system fans direction, which could be forward or reversed. For forward direction - relevant bit is set 0; For reversed direction - relevant bit is set 1. Signed-off-by: Vadim Pasternak <vadimp@mellanox.com> Signed-off-by: Darren Hart (VMware) <dvhart@infradead.org>
2019-01-26platform/x86: intel-hid: Missing power button release on some Dell modelsJérôme de Bretagne1-2/+5
Power button suspend for some Dell models was added in: commit 821b85366284 ("platform/x86: intel-hid: Power button suspend on Dell Latitude 7275") by checking against the power button press notification (0xCE) to report the power button press event. The corresponding power button release notification (0xCF) was caught and ignored to stop it from being reported as an "unknown event" in the logs. The missing button release event is creating issues on Android-x86, as reported on the project mailing list for a Dell Latitude 5175 model, since the events are expected in down/up pairs. Report the power button release event to fix this issue. Link: https://groups.google.com/forum/#!topic/android-x86/aSwZK9Nf9Ro Tested-by: Tristian Celestin <tristian.celestin@outlook.com> Tested-by: Jérôme de Bretagne <jerome.debretagne@gmail.com> Signed-off-by: Jérôme de Bretagne <jerome.debretagne@gmail.com> Reviewed-by: Mario Limonciello <mario.limonciello@dell.com> [dvhart: corrected commit reference format per checkpatch] Signed-off-by: Darren Hart (VMware) <dvhart@infradead.org>
2019-01-22drivers: platform: goldfish: fix the checkpatch complain in KconfigRoman Kiryanov1-2/+2
prefer 'help' over '---help---' for new help texts Signed-off-by: Roman Kiryanov <rkir@google.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-01-15platform/x86: apple-gmux: Make PCI dependency explicitSinan Kaya1-1/+1
After commit 5d32a66541c4 (PCI/ACPI: Allow ACPI to be built without CONFIG_PCI set) dependencies on CONFIG_PCI that previously were satisfied implicitly through dependencies on CONFIG_ACPI have to be specified directly. This driver depends on the PCI infrastructure but the dependency has not been called out explicitly yet. Fixes: 5d32a66541c46 ("PCI/ACPI: Allow ACPI to be built without CONFIG_PCI set") Signed-off-by: Sinan Kaya <okaya@kernel.org> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2019-01-15platform/x86: intel_pmc: Make PCI dependency explicitSinan Kaya1-1/+1
After commit 5d32a66541c4 (PCI/ACPI: Allow ACPI to be built without CONFIG_PCI set) dependencies on CONFIG_PCI that previously were satisfied implicitly through dependencies on CONFIG_ACPI have to be specified directly. Some code in intel_pmc relies on PCI for execution. Specify this in the Kconfig. [ Andy S: For sake of a quick fix this introduces a new mandatory dependency to the driver which may survive without it. Otherwise we need to revisit the driver architecture to address this properly. ] Fixes: 5d32a66541c46 ("PCI/ACPI: Allow ACPI to be built without CONFIG_PCI set") Signed-off-by: Sinan Kaya <okaya@kernel.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2019-01-15platform/x86: intel_ips: make PCI dependency explicitSinan Kaya1-1/+1
After commit 5d32a66541c4 (PCI/ACPI: Allow ACPI to be built without CONFIG_PCI set) dependencies on CONFIG_PCI that previously were satisfied implicitly through dependencies on CONFIG_ACPI have to be specified directly. intel_ips is a PCI device driver but this has not been mentioned anywhere in Kconfig. Fixes: 5d32a66541c46 ("PCI/ACPI: Allow ACPI to be built without CONFIG_PCI set") Signed-off-by: Sinan Kaya <okaya@kernel.org> Acked-by: Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>