The register (SLP_S0_RES) at offset slp_s0_offset is a 32 bit register.
The pmc_core_adjust_slp_s0_step() could overflow the u32 value while
returning it after adjusting the step. Thus change to u64, this is
already accounted for in debugfs attribute (that wants to output a
64 bit value).
Signed-off-by: Rajat Jain <rajatja@google.com>
Acked-by: Rajneesh Bhardwaj <rajneesh.bhardwaj@linux.intel.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Darren Hart (VMware) <dvhart@infradead.org>
Commit 0252894f53 added the Legion Y530 to the no_hw_rfkill
list, but missed a Y530 variant using the nvidia 1060 graphics card.
I have had to blacklist ideapad-laptop as a result to get Wi-Fi working.
dmidecode info:
Handle 0x0001, DMI type 1, 27 bytes
System Information
Manufacturer: LENOVO
Product Name: 81LB
Version: Lenovo Legion Y530-15ICH-1060
Serial Number: <snip>
UUID: <snip>
Wake-up Type: Power Switch
SKU Number: LENOVO_MT_81LB_BU_idea_FM_Legion Y530-15ICH-1060
Family: Legion Y530-15ICH-1060
Signed-off-by: Mark Levedahl <mlevedahl@gmail.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Darren Hart (VMware) <dvhart@infradead.org>
In the function wmi_dev_match() the variable id is dereferenced without
first performing a NULL check. The variable can for example be NULL if
a WMI driver is registered without specifying the id_table field in
struct wmi_driver.
Add a NULL check and return that the driver can't handle the device if
the variable is NULL.
Fixes: 844af950da ("platform/x86: wmi: Turn WMI into a bus driver")
Signed-off-by: Mattias Jacobsson <2pi@mok.nu>
Signed-off-by: Darren Hart (VMware) <dvhart@infradead.org>
For some odd reason dell_rbu actually seems to want the physical and
not a bus address for the allocated buffer. Lets assume that actually
is correct given that it is BIOS-related and that is a good source
of insanity. In that case we should not use dma_alloc_coherent with
a NULL device to allocate memory, but use GFP_DMA32 to stay under
the 32-bit BIOS limit.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Acked-by: Stuart Hayes <stuart.w.hayes@gmail.com>
Signed-off-by: Darren Hart (VMware) <dvhart@infradead.org>
Commit ae7c8cba32 ("platform/x86: ideapad-laptop: add lenovo RESCUER
R720-15IKBN to no_hw_rfkill_list") added
DMI_MATCH(DMI_BOARD_NAME, "80WW")
for Lenovo RESCUER R720-15IKBN.
But DMI_BOARD_NAME does not match 80WW on Lenovo RESCUER R720-15IKBN,
thus cause Wireless LAN still be hard blocked.
On Lenovo RESCUER R720-15IKBN:
~$ cat /sys/class/dmi/id/sys_vendor
LENOVO
~$ cat /sys/class/dmi/id/board_name
Provence-5R3
~$ cat /sys/class/dmi/id/product_name
80WW
~$ cat /sys/class/dmi/id/product_version
Lenovo R720-15IKBN
So on Lenovo RESCUER R720-15IKBN:
DMI_SYS_VENDOR should match "LENOVO",
DMI_BOARD_NAME should match "Provence-5R3",
DMI_PRODUCT_NAME should match "80WW",
DMI_PRODUCT_VERSION should match "Lenovo R720-15IKBN".
Fix it, and in according with other entries in no_hw_rfkill_list,
use DMI_PRODUCT_VERSION instead of DMI_BOARD_NAME.
Fixes: ae7c8cba32 ("platform/x86: ideapad-laptop: add lenovo RESCUER R720-15IKBN to no_hw_rfkill_list")
Signed-off-by: Yang Fan <nullptr.cpp@gmail.com>
Signed-off-by: Darren Hart (VMware) <dvhart@infradead.org>
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>
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>
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>
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>
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>
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>
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>
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: c977b98bbe ("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>
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: 661405bd81 ("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>
Commit c3b8e884de ("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: c3b8e884de ("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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
