Like other Lenovo models the IdeaPad V310-15ISK does not have an hw
rfkill switch. This results in hard-blocked radios after boot, resulting
in always blocked radios rendering them unusable.

Add the IdeaPad V310-15ISK to the no_hw_rfkill DMI list and allows using
the built-in radios.
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>

To maintain the uniformity in accessing GCR registers, this patch
modifies the S0ix counter read function to use GCR address base
instead of ipc address base.
Signed-off-by: NKuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>
Reviewed-by: NRajneesh Bhardwaj <rajneesh.bhardwaj@intel.com>
Tested-by: NShanth Murthy <shanth.murthy@intel.com>
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>

iTCO_wdt driver need access to PMC_CFG GCR register to modify the
noreboot setting. Currently, this is done by passing PMC_CFG reg
address as memory resource to watchdog driver and allowing it directly
modify the PMC_CFG register. But currently PMC driver also has
requirement to memory map the entire GCR register space in this driver.
This causes mem request failure in watchdog driver. So this patch fixes
this issue by adding API to update noreboot flag and passes them
to watchdog driver via platform data.
Signed-off-by: NKuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>

In some SoCs, setting noreboot bit needs modification to
PMC GC registers. But not all PMC drivers allow other drivers
to memory map their GC region. This could create mem request
conflict in watchdog driver. So this patch adds facility to allow
PMC drivers to pass noreboot update function to watchdog
drivers via platform data.
Signed-off-by: NKuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>
Acked-by: NGuenter Roeck <linux@roeck-us.net>
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>

iTCO_wdt no_reboot_bit set/unset functions has lot of common code between
them. So merging these two functions into a single update function would
remove these unnecessary code duplications. This patch fixes this issue
by creating a no_reboot_bit update function to handle both set/unset
functions.

Also checking for iTCO version every time you make no_reboot_bit set/unset
call is inefficient and makes the code look complex. This can be improved
by performing this check once during device probe and selecting the
appropriate no_reboot_bit update function. This patch fixes this issue
by splitting the update function into multiple helper functions.
Signed-off-by: NKuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>
Reviewed-by: NGuenter Roeck <linux@roeck-us.net>
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>

This patch adds API's to read/write/update PMC GC registers.
PMC dependent devices like iTCO_wdt, Telemetry has requirement
to acces GCR registers. These API's can be used for this
purpose.
Signed-off-by: NKuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>

According to Broxton APL spec, PMC MIMO resources for Global Control
Registers(GCR) are located at 4K(0x1000) offset from IPC base address.
In this driver, PLAT_RESOURCE_GCR_OFFSET macro defines the offset of GCR
region base address from IPC base address and its current value of
0x1008 is incorrect because it points to location for PMC_CFG register
and not the GCR base address itself.

GCR Base = IPC1 Base + 0x1000.

This patch fixes this offset issue.
Signed-off-by: NKuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>

When changing keyboard backlight state on new Dell laptops, firmware
expects a new timeout AC value filled in Set New State SMBIOS call.

Without it any change of keyboard backlight state on new Dell laptops
fails. And user can see following error message in dmesg:

  dell_laptop: Setting old previous keyboard state failed
  leds dell::kbd_backlight: Setting an LED's brightness failed (-6)

This patch adds support for retrieving current timeout AC values and also
updating them. Current timeout value in sysfs is displayed based on current
AC status, like current display brightness value.

Detection if Dell laptop supports or not new timeout AC settings is done by
checking existence of Keyboard Backlight with AC SMBIOS token (0x0451).
Signed-off-by: NPali Rohár <pali.rohar@gmail.com>
Acked-by: NMario Limonciello <mario.limonciello@dell.com>
Tested-by: NArcadiy Ivanov <arcadiy@ivanov.biz>
[andy: fixed merge conflict with defined constants]
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>

Here, This patch is to handle a return error from dell_get_intensity.
This change is done using Coccinelle.
Signed-off-by: NArvind Yadav <arvind.yadav.cs@gmail.com>
Acked-by: NPali Rohár <pali.rohar@gmail.com>
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>

There is a macro to register and unregister modules in simple cases,
Let's use it and clean up the driver.

Cc: Alex Hung <alex.hung@canonical.com>
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: NDarren Hart (VMware) <dvhart@infradead.org>

Tested on HP Elite X2 1012 G1.
Matches event report of Lenovo Helix 2
(https://www.spinics.net/lists/ibm-acpi-devel/msg03982.html).
Signed-off-by: NMaarten Maathuis <madman2003@shikahr.net>
[andy: fixed indentation of comments and massaged title of the change]
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>

With CONFIG_I2C=m and CONFIG_INTEL_CHT_INT33FE=y we see the following link
errors:

drivers/built-in.o: In function 'cht_int33fe_remove':
intel_cht_int33fe.c:(.text+0x391f6e): undefined reference to 'i2c_unregister_device'
intel_cht_int33fe.c:(.text+0x391f76): undefined reference to 'i2c_unregister_device'
intel_cht_int33fe.c:(.text+0x391f7d): undefined reference to 'i2c_unregister_device'
drivers/built-in.o: In function 'cht_int33fe_probe':
intel_cht_int33fe.c:(.text+0x392147): undefined reference to 'i2c_acpi_new_device'
intel_cht_int33fe.c:(.text+0x392185): undefined reference to 'i2c_acpi_new_device'
intel_cht_int33fe.c:(.text+0x3921bd): undefined reference to 'i2c_acpi_new_device'
intel_cht_int33fe.c:(.text+0x3921d9): undefined reference to 'i2c_unregister_device'
intel_cht_int33fe.c:(.text+0x3921e8): undefined reference to 'i2c_unregister_device'
drivers/built-in.o: In function 'cht_int33fe_driver_init':
intel_cht_int33fe.c:(.init.text+0x2386d): undefined reference to 'i2c_register_driver'
drivers/built-in.o: In function 'cht_int33fe_driver_exit':
intel_cht_int33fe.c:(.exit.text+0x206e): undefined reference to 'i2c_del_driver'

Fix this by adding a kconfig dependency on the I2C subsystem.

Fixes: 1cd706df ("platform/x86: Add Intel Cherry Trail ACPI INT33FE device driver")
Signed-off-by: NTobias Regnery <tobias.regnery@gmail.com>
Reviewed-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NDarren Hart (VMware) <dvhart@infradead.org>

Several exit paths were more complex than they needed to be. Remove
superfluous conditionals, use labels common cleanup, do not shadow
negative error codes.
Signed-off-by: NDarren Hart (VMware) <dvhart@infradead.org>
Tested-by: NCarlo Caione <carlo@endlessm.com>
Reviewed-by: NAndy Shevchenko <andy.shevchenko@gmail.com>

The new hp_wmi_read_int function returns a negative value in case of
error, pass this on directly rather than always replacing it with
-EINVAL.
Signed-off-by: NDarren Hart (VMware) <dvhart@infradead.org>
Tested-by: NCarlo Caione <carlo@endlessm.com>
Reviewed-by: NAndy Shevchenko <andy.shevchenko@gmail.com>

Use the DEVICE_ATTR_(RO|RW) macros, ranaming the show and store
functions accordingly.
Signed-off-by: NDarren Hart (VMware) <dvhart@infradead.org>
Tested-by: NCarlo Caione <carlo@endlessm.com>
Reviewed-by: NAndy Shevchenko <andy.shevchenko@gmail.com>

Both dock and tablet use the HPWMI_HARDWARE_QUERY, but require different
masks. Rather than using two functions with magic masks, define the
masks, and use a common accessor.
Signed-off-by: NDarren Hart (VMware) <dvhart@infradead.org>
Tested-by: NCarlo Caione <carlo@endlessm.com>
Reviewed-by: NAndy Shevchenko <andy.shevchenko@gmail.com>

Use the new hp_wmi_read_int() function and add a WARN_ONCE() to the TBD
regarding passing the error through. These are used in a null return
function unfortunately.
Signed-off-by: NDarren Hart (VMware) <dvhart@infradead.org>
Tested-by: NCarlo Caione <carlo@endlessm.com>
Reviewed-by: NAndy Shevchenko <andy.shevchenko@gmail.com>

Several functions perform the same WMI read int with different query
arguments. Refactor this into a single hp_wmi_read_int function.
Signed-off-by: NDarren Hart (VMware) <dvhart@infradead.org>
Tested-by: NCarlo Caione <carlo@endlessm.com>
Reviewed-by: NAndy Shevchenko <andy.shevchenko@gmail.com>

Use enums consistently throughout the hp-wmi driver for groups of
related constants. Use hex and align the assignment within groups. Move
the *QUERY constants into an enum, create a new enum defining the READ,
WRITE, and ODM constants and use them instead of 0 and 1 at the call
sites. Set the command directly instead of using the ternary operator
since both 1 and 3 as previously documented would result in the command
being set to 0x2.
Signed-off-by: NDarren Hart (VMware) <dvhart@infradead.org>
Tested-by: NCarlo Caione <carlo@endlessm.com>
Reviewed-by: NAndy Shevchenko <andy.shevchenko@gmail.com>

Declare like types on one line. Order declarations in decreasing length
where possible.
Signed-off-by: NDarren Hart (VMware) <dvhart@infradead.org>
Tested-by: NCarlo Caione <carlo@endlessm.com>
Reviewed-by: NAndy Shevchenko <andy.shevchenko@gmail.com>

All the helper functions (i.e. hp_wmi_dock_state, hp_wmi_tablet_state,
...) using hp_wmi_perform_query to perform an HP WMI query shadow the
returned value in case of error.

We return -EINVAL only when the HP WMI query returns a positive value
(the specific error code) to not mix this up with the actual value
returned by the helper function.
Suggested-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: NCarlo Caione <carlo@endlessm.com>
Signed-off-by: NDarren Hart (VMware) <dvhart@infradead.org>

As LED class devices registered by fujitsu-laptop no longer depend on
the platform device, two function calls inside acpi_fujitsu_laptop_add()
can be rearranged in order to simplify error handling.
Signed-off-by: NMichał Kępień <kernel@kempniu.pl>
Reviewed-by: NJonathan Woithe <jwoithe@just42.net>
Signed-off-by: NDarren Hart (VMware) <dvhart@infradead.org>

If acpi_fujitsu_laptop_leds_register() returns an error, the latter will
become the return value of acpi_fujitsu_laptop_add(), which in turn will
be reported by driver core.  Simplify code by replacing pr_err() calls
with return statements.  Return 0 instead of result when no errors occur
in order to make the code easier to read.
Signed-off-by: NMichał Kępień <kernel@kempniu.pl>
Reviewed-by: NJonathan Woithe <jwoithe@just42.net>
Signed-off-by: NDarren Hart (VMware) <dvhart@infradead.org>

Use devm_led_classdev_register() for registering LED class devices in
order to simplify cleanup and remove LED-related fields with the
"_registered" suffix from struct fujitsu_laptop.  This also fixes a
cleanup bug: with non-managed LED class devices, if e.g. two supported
LEDs are detected, the first one gets registered successfully but the
second one does not, acpi_fujitsu_laptop_add() will return an error, but
the successfully registered LED will never get unregistered.

Change the parent device for LED class devices to the FUJ02E3 ACPI
device due to this being the logically correct relationship as LED class
devices do not depend on any facility provided by the platform device
registered by fujitsu-laptop, which was their parent until now.

Each managed LED class device is automatically unregistered when the
last reference to its parent device is dropped.  Taking the parent
change described above into account, LED class devices registered by
fujitsu-laptop will be unregistered after acpi_fujitsu_laptop_remove()
is called.  During unregistration, LED brightness is reset to LED_OFF by
LED core, so do not set the acpi_handle field of struct fujitsu_laptop
to NULL inside acpi_fujitsu_laptop_remove() to prevent call_fext_func()
from generating errors upon module removal.
Signed-off-by: NMichał Kępień <kernel@kempniu.pl>
Reviewed-by: NJonathan Woithe <jwoithe@just42.net>
Signed-off-by: NDarren Hart (VMware) <dvhart@infradead.org>

Move around LED definitions and callbacks to eliminate the need for
forward declarations and ensure code is organized LED-wise, not
action-wise.  Reorder assignments inside designated initializers so that
they are in the same order as struct led_classdev fields in
include/linux/leds.h.  Adjust whitespace to make checkpatch happy.
Signed-off-by: NMichał Kępień <kernel@kempniu.pl>
Reviewed-by: NJonathan Woithe <jwoithe@just42.net>
Signed-off-by: NDarren Hart (VMware) <dvhart@infradead.org>

Move a long section of code responsible for registering LEDs out of
acpi_fujitsu_laptop_add() to improve readability and ensure proper
cleanup of platform device and kfifo e.g. when two supported LEDs are
detected, the first one gets registered successfully but the second one
does not.  This makes the result variable in acpi_fujitsu_laptop_add()
redundant, so remove it.  Adjust whitespace to make checkpatch happy.
Signed-off-by: NMichał Kępień <kernel@kempniu.pl>
Reviewed-by: NJonathan Woithe <jwoithe@just42.net>
Signed-off-by: NDarren Hart (VMware) <dvhart@infradead.org>

Follow common subsystem practice of selecting LEDS_CLASS instead of
riddling module code with #ifdefs.
Signed-off-by: NMichał Kępień <kernel@kempniu.pl>
Reviewed-by: NJonathan Woithe <jwoithe@just42.net>
Signed-off-by: NDarren Hart (VMware) <dvhart@infradead.org>

The intel-hid driver is missing a PM ->thaw callback allowing the
device to go back to the operational state after creating a
hibernation image or when there is an image restoration error during
resume.

The lack of the ->thaw callback basically means that all events
signaled by the device are discarded after a hibernation image has
been created which may be problematic, for example, if the image
cannot be saved (eg. due to an I/O issue with storage).
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: NDarren Hart (VMware) <dvhart@infradead.org>

The INT33FE ACPI device has a CRS table with I2cSerialBusV2 resources for
3 devices: Maxim MAX17047 Fuel Gauge Controller, FUSB302 USB Type-C
Controller and PI3USB30532 USB switch.

This commit adds a driver for this ACPI device which instantiates
i2c-clients for these, so that the standard i2c drivers for these chips
can bind to the them.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Reviewed-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: NDarren Hart (VMware) <dvhart@infradead.org>

Merge branch 'i2c/for-INT33FE' of
git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git
to prepare for an incoming INT33FE driver.
Signed-off-by: NDarren Hart (VMware) <dvhart@infradead.org>

By default the i2c-core will try to get an irq with index 0 on ACPI / of
instantiated devices. This is troublesome on some ACPI systems where the
irq info at index 0 in the CRS table may contain nonsense and/or point
to an irqchip for which there is no Linux driver.

If this happens then before this commit the driver's probe method would
never get called because i2c_device_probe will try to get an irq by
calling acpi_dev_gpio_irq_get which will always return -EPROBE in this
case, as it waits for a matching irqchip driver to load. Thus causing
the driver to not get a chance to bind.

This commit adds a new disable_i2c_core_irq_mapping flag to struct
i2c_driver which a driver can set to tell the core to skip irq mapping.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Reviewed-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

By default the i2c subsys creates an i2c-client for the first I2cSerialBus
resource of an acpi_device, but some acpi_devices have multiple
I2cSerialBus resources and we may want to instantiate i2c-clients for
the others.

This commit adds a new i2c_acpi_new_device function which can be used to
create an i2c-client for any I2cSerialBus resource of an acpi_device.

Note that the other resources may even be on a different i2c bus, so just
retrieving the client address is not enough.

Here is an example DSDT excerpt from such a device:

Device (WIDR)
{
    Name (_HID, "INT33FE" /* XPOWER Battery Device */)
    Name (_CID, "INT33FE" /* XPOWER Battery Device */)
    Name (_DDN, "WC PMIC Battery Device")
<snip>
    Name (RBUF, ResourceTemplate ()
    {
        I2cSerialBusV2 (0x005E, ControllerInitiated, 0x000186A0,
            AddressingMode7Bit, "\\_SB.PCI0.I2C7",
            0x00, ResourceConsumer, , Exclusive,
            )
        I2cSerialBusV2 (0x0036, ControllerInitiated, 0x000186A0,
            AddressingMode7Bit, "\\_SB.PCI0.I2C1",
            0x00, ResourceConsumer, , Exclusive,
            )
        I2cSerialBusV2 (0x0022, ControllerInitiated, 0x00061A80,
            AddressingMode7Bit, "\\_SB.PCI0.I2C1",
            0x00, ResourceConsumer, , Exclusive,
            )
        I2cSerialBusV2 (0x0054, ControllerInitiated, 0x00061A80,
            AddressingMode7Bit, "\\_SB.PCI0.I2C1",
            0x00, ResourceConsumer, , Exclusive,
            )
        GpioInt (Level, ActiveLow, Exclusive, PullNone, 0x0000,
            "\\_SB.PCI0.I2C7.PMI5", 0x00, ResourceConsumer, ,
            )
            {   // Pin list
        0x0012
            }
        GpioInt (Edge, ActiveLow, ExclusiveAndWake, PullNone, 0x0000,
            "\\_SB.GPO1", 0x00, ResourceConsumer, ,
            )
            {   // Pin list
        0x0005
            }
        GpioInt (Level, ActiveLow, Exclusive, PullNone, 0x0000,
            "\\_SB.PCI0.I2C7.PMI5", 0x00, ResourceConsumer, ,
            )
            {   // Pin list
        0x0013
            }
    })
    Method (_CRS, 0, NotSerialized)  // _CRS: Current Resource Settings
    {
        Return (RBUF) /* \_SB_.PCI0.I2C7.WIDR.RBUF */
    }
<snip>
}
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Reviewed-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

Modify struct i2c_acpi_lookup and i2c_acpi_fill_info() to allow
using them to get the info from a certain index in the ACPI-resource
list rather then taking the first I2cSerialBus resource.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Reviewed-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

The current driver code is not checking for the error values returned by
'hp_wmi_dock_state()' and 'hp_wmi_tablet_state()' before passing the
returned values down to 'input_report_switch()'. This error code is
being translated to '1' in the input subsystem, reporting the wrong
status.

The biggest problem caused by this issue is that several laptops are
wrongly reported by the driver as docked, preventing them to be put to
sleep using the LID (and in most cases they are not even dockable).

With this patch we create the report switches only if we are able to
read the dock and tablet mode status correctly from ACPI.
Signed-off-by: NCarlo Caione <carlo@endlessm.com>
Signed-off-by: NDarren Hart (VMware) <dvhart@infradead.org>

hp_wmi_tablet_state() fails to return the correct error code when
hp_wmi_perform_query() returns the HP WMI query specific error code
that is a positive value.
Signed-off-by: NCarlo Caione <carlo@endlessm.com>
Signed-off-by: NDarren Hart (VMware) <dvhart@infradead.org>

The airplane mode button on Xiaomi's new laptops are the same as HP
laptops.

This is tested on Xiaomi Notebook Air 13.
Signed-off-by: NAlex Hung <alex.hung@canonical.com>
[dvhart: Dropped module init/exit info messages]
Signed-off-by: NDarren Hart (VMware) <dvhart@infradead.org>

Add touchscreen info for the Trekstor Surftab Wintron 7.0 ST70416-6
tablet.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NDarren Hart (VMware) <dvhart@infradead.org>

The dev field of struct fujitsu_bl is assigned in acpi_fujitsu_bl_add(),
but never used afterwards.  brightness_changed is set in get_lcd_level()
and then its value is only printed in a debug message, so it does not
influence execution flow.  Remove both fields as they are redundant.
Update the aforementioned debug message.  Adjust whitespace to make
checkpatch happy.
Signed-off-by: NMichał Kępień <kernel@kempniu.pl>
Reviewed-by: NJonathan Woithe <jwoithe@just42.net>
Signed-off-by: NDarren Hart (VMware) <dvhart@infradead.org>

The comment for the get_brightness backlight device callback in
include/linux/backlight.h states that it should "return the current
backlight brightness (accounting for power, fb_blank etc.)".
fujitsu-laptop violates that premise by simply returning the value to
which ACPI function GBLL evaluates to.  Make sure 0 is returned when
backlight power is turned off.
Signed-off-by: NMichał Kępień <kernel@kempniu.pl>
Reviewed-by: NJonathan Woithe <jwoithe@just42.net>
Signed-off-by: NDarren Hart (VMware) <dvhart@infradead.org>

Any set_lcd_level() call can fail for one of two reasons: either
requested brightness is outside the allowed range or the ACPI method
used for setting brightness level is not available.  For
bl_update_status(), the first case is handled by backlight core, which
means bl_update_status() will not even be called if requested brightness
is outside the allowed range.  The second case will be logged anyway by
set_lcd_level() itself, so there is no point in generating another
message in bl_update_status().  Remove the superfluous debug message
along with a local variable that is now redundant.
Signed-off-by: NMichał Kępień <kernel@kempniu.pl>
Reviewed-by: NJonathan Woithe <jwoithe@just42.net>
Signed-off-by: NDarren Hart (VMware) <dvhart@infradead.org>