Add a driver for the keyboard, touchpad and USB port of
the keyboard dock for the Asus TF103C 2-in-1 tablet.
This keyboard dock has its own I2C attached embedded controller
and the keyboard and touchpad are also connected over I2C,
instead of using the usual USB connection. This means that the
keyboard dock requires this special driver to function.
Cc: Michał Mirosław <mirq-linux@rere.qmqm.pl>
Cc: Ion Agorria <ion@agorria.com>
Cc: Svyatoslav Ryhel <clamor95@gmail.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20211226141849.156407-1-hdegoede@redhat.com
x86 tablets which ship with Android as (part of) the factory image
typically have various problems with their DSDTs. The factory kernels
shipped on these devices typically have device addresses and GPIOs
hardcoded in the kernel, rather then specified in their DSDT.
With the DSDT containing a random collection of devices which may or
may not actually be present as well as missing devices which are
actually present.
This driver, which loads only on affected models based on DMI matching,
adds DMI based instantiating of kernel devices for devices which are
missing from the DSDT, fixing e.g. battery monitoring, touchpads and/or
accelerometers not working.
Note the Kconfig help text also refers to "various fixes" ATM there are
no such fixes, but there are also known cases where entries are present
in the DSDT but they contain bugs, such as missing/wrong GPIOs. The plan
is to also add fixes for things like this here in the future.
This is the least ugly option to get these devices to fully work and to
do so without adding any extra code to the main kernel image (vmlinuz)
when built as a module.
Link: https://lore.kernel.org/platform-driver-x86/20211031162428.22368-1-hdegoede@redhat.com/
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20211223190750.397487-1-hdegoede@redhat.com
This mainly implements detection of these devices and will allow
secondary drivers to work on such machines.
The identification is DMI-based with a vendor specific way to tell them
apart in a reliable way.
Drivers for LEDs and Watchdogs will follow to make use of that platform
detection.
There is also some code to allow secondary drivers to find GPIO memory,
that needs to be in place because the pinctrl drivers do not come up.
Signed-off-by: Henning Schild <henning.schild@siemens.com>
Link: https://lore.kernel.org/r/20211213120502.20661-2-henning.schild@siemens.com
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
While introduction of this menu brings a nice view in the configuration tools,
it brought more issues than solves, i.e. it prevents to locate files in the
intel/ subfolder without touching non-related Kconfig dependencies elsewhere.
Drop X86_PLATFORM_DRIVERS_INTEL altogether.
Note, on x86 it's enabled by default and it's quite unlikely anybody wants to
disable all of the modules in this submenu.
Fixes: 8bd836feb6 ("platform/x86: intel_skl_int3472: Move to intel/ subfolder")
Suggested-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20211222194941.76054-1-andriy.shevchenko@linux.intel.com
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Add driver to handle WMI events, control the keyboard backlight and
bind/unbind the keyboard-touch / digitizer driver so that only one
is active at a time.
It may seem a bit weird to handle the toggling of the modes in the
kernel, but the hw actually expects only 1 device to be active
at a time.
Changes by Hans de Goede:
- Whole bunch of cleanups
- Make the kernel do the driver bind/unbind itself instead of
sending events to userspace and requiring a special userspace
daemon to deal with this
Signed-off-by: Yauhen Kharuzhy <jekhor@gmail.com>
Co-developed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20211128190031.405620-4-hdegoede@redhat.com
Add a driver providing access to the GPIOs for the identify button and led
present on Barco P50 board, based on the pcengines-apuv2.c driver.
There is unfortunately no suitable ACPI entry for the EC communication
interface, so instead bind to boards with "P50" as their DMI product family
and hard code the I/O port number (0x299).
The driver also hooks up the leds-gpio and gpio-keys-polled drivers to the
GPIOs, so they are finally exposed as:
LED:
/sys/class/leds/identify
Button: (/proc/bus/input/devices)
I: Bus=0019 Vendor=0001 Product=0001 Version=0100
N: Name="identify"
P: Phys=gpio-keys-polled/input0
S: Sysfs=/devices/platform/barco-p50-gpio/gpio-keys-polled/input/input10
U: Uniq=
H: Handlers=event10
B: PROP=0
B: EV=3
B: KEY=1000000 0 0 0 0 0 0
Signed-off-by: Santosh Kumar Yadav <santoshkumar.yadav@barco.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Link: https://lore.kernel.org/r/20211020123634.2638-1-peter@korsgaard.com
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Rename the wmaa-backlight-wmi driver and associated KConfig option to
remove the remaining references to the "WMAA" ACPI handle which was
used in the previous name. The driver has already been updated to
remove internal references to "WMAA". As part of the renaming, the
components in the name have been rearranged to reflect the standard
vendor_wmi_feature pattern.
Signed-off-by: Daniel Dadap <ddadap@nvidia.com>
Link: https://lore.kernel.org/r/20210927202359.13684-2-ddadap@nvidia.com
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
A number of upcoming notebook computer designs drive the internal
display panel's backlight PWM through the Embedded Controller (EC).
This EC-based backlight control can be plumbed through to an ACPI
"WMAA" method interface, which in turn can be wrapped by WMI with
the GUID handle 603E9613-EF25-4338-A3D0-C46177516DB7.
Add a new driver, aliased to the WMAA WMI GUID, to expose a sysfs
backlight class driver to control backlight levels on systems with
EC-driven backlights.
Signed-off-by: Daniel Dadap <ddadap@nvidia.com>
Reviewed-by: Thomas Weißschuh <linux@weissschuh.net>
Link: https://lore.kernel.org/r/20210903003838.15797-1-ddadap@nvidia.com
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
ACPI devices with _HID INT3472 are currently matched to the tps68470
driver, however this does not cover all situations in which that _HID
occurs. We've encountered three possibilities:
1. On Chrome OS devices, an ACPI device with _HID INT3472 (representing
a physical TPS68470 device) that requires a GPIO and OpRegion driver
2. On devices designed for Windows, an ACPI device with _HID INT3472
(again representing a physical TPS68470 device) which requires GPIO,
Clock and Regulator drivers.
3. On other devices designed for Windows, an ACPI device with _HID
INT3472 which does **not** represent a physical TPS68470, and is instead
used as a dummy device to group some system GPIO lines which are meant
to be consumed by the sensor that is dependent on this entry.
This commit adds a new module, registering a platform driver to deal
with the 3rd scenario plus an i2c driver to deal with #1 and #2, by
querying the CLDB buffer found against INT3472 entries to determine
which is most appropriate.
Suggested-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Daniel Scally <djrscally@gmail.com>
Link: https://lore.kernel.org/r/20210603224007.120560-6-djrscally@gmail.com
[hdegoede@redhat.com Make skl_int3472_tps68470_calc_type() static]
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Tested with
* X570 I Aorus Pro Wifi (rev 1.0)
* B550M DS3H
* B550 Gaming X V2 (rev.1.x)
* Z390 I AORUS PRO WIFI (rev. 1.0)
Those mainboards contain an ITE chips for management and
monitoring.
They could also be handled by drivers/hwmon/i87.c.
But the SuperIO range used by i87 is already claimed and used by the
firmware.
The following warning is printed at boot:
kernel: ACPI Warning: SystemIO range 0x0000000000000A45-0x0000000000000A46 conflicts with OpRegion 0x0000000000000A45-0x0000000000000A46 (\GSA1.SIO1) (20200528/utaddress-204)
kernel: ACPI: This conflict may cause random problems and system instability
kernel: ACPI: If an ACPI driver is available for this device, you should use it instead of the native driver
This driver implements such an ACPI driver.
Unfortunately not all sensor registers are handled by the firmware and even
less are exposed via WMI.
Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
Link: https://lore.kernel.org/r/20210412123513.628901-1-linux@weissschuh.net
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Advantech sw_button is a ACPI event trigger button.
With this driver, we can report KEY_PROG1 on the
Advantech Tabletop Network Appliances products and it has been
tested in FWA1112VC.
Add the software define button support to report EV_REP key_event
(KEY_PROG1) by pressing button that could be get on user
interface and trigger the customized actions.
Signed-off-by: Andrea.Ho <Andrea.Ho@advantech.com.tw>
Link: https://lore.kernel.org/r/20210319034427.23222-1-andrea.cs97g@nctu.edu.tw
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
The ACPI-enabled Intel MID platforms neither have WDAT table nor proper IDs
to instantiate watchdog device. In order to keep them working move the board
code from arch/x86 to drivers/platform/x86.
Note, the complete SFI support is going to be removed, that's why PDx86
has been chosen as a new home for it. This is the only device which needs
additional code so far.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Intel Moorestown and Medfield are quite old Intel Atom based
32-bit platforms, which were in limited use in some Android phones,
tablets and consumer electronics more than eight years ago.
There are no bugs or problems ever reported outside from Intel
for breaking any of that platforms for years. It seems no real
users exists who run more or less fresh kernel on it. The commit
05f4434bc1 ("ASoC: Intel: remove mfld_machine") also in align
with this theory.
Due to above and to reduce a burden of supporting outdated drivers
we remove the support of outdated platforms completely.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Intel Moorestown and Medfield are quite old Intel Atom based
32-bit platforms, which were in limited use in some Android phones,
tablets and consumer electronics more than eight years ago.
There are no bugs or problems ever reported outside from Intel
for breaking any of that platforms for years. It seems no real
users exists who run more or less fresh kernel on it. The commit
05f4434bc1 ("ASoC: Intel: remove mfld_machine") also in align
with this theory.
Due to above and to reduce a burden of supporting outdated drivers
we remove the support of outdated platforms completely.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Pull x86 platform driver updates from Hans de Goede:
"Highlights:
- New driver for changing BIOS settings from within Linux on Dell
devices. This introduces a new generic sysfs API for this. Lenovo
is working on also supporting this API on their devices
- New Intel PMT telemetry and crashlog drivers
- Support for SW_TABLET_MODE reporting for the acer-wmi and intel-hid
drivers
- Preparation work for improving support for Microsoft Surface
hardware
- Various fixes / improvements / quirks for the panasonic-laptop and
others"
* tag 'platform-drivers-x86-v5.11-1' of git://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86: (81 commits)
platform/x86: ISST: Mark mmio_range_devid_0 and mmio_range_devid_1 with static keyword
platform/x86: intel-hid: add Rocket Lake ACPI device ID
x86/platform: classmate-laptop: add WiFi media button
platform/x86: mlx-platform: Fix item counter assignment for MSN2700/ComEx system
platform/x86: mlx-platform: Fix item counter assignment for MSN2700, MSN24xx systems
tools/power/x86/intel-speed-select: Update version for v5.11
tools/power/x86/intel-speed-select: Account for missing sysfs for die_id
tools/power/x86/intel-speed-select: Read TRL from mailbox
platform/x86: intel-hid: Do not create SW_TABLET_MODE input-dev when a KIOX010A ACPI dev is present
platform/x86: intel-hid: Add alternative method to enable switches
platform/x86: intel-hid: Add support for SW_TABLET_MODE
platform/x86: intel-vbtn: Fix SW_TABLET_MODE always reporting 1 on some HP x360 models
platform/x86: ISST: Change PCI device macros
platform/x86: ISST: Allow configurable offset range
platform/x86: ISST: Check for unaligned mmio address
acer-wireless: send an EV_SYN/SYN_REPORT between state changes
platform/x86: dell-wmi-sysman: work around for BIOS bug
platform/x86: mlx-platform: remove an unused variable
platform/x86: thinkpad_acpi: remove trailing semicolon in macro definition
platform/x86: dell-smbios-base: Fix error return code in dell_smbios_init
...
Add the uv_sysfs driver to construct a read-only sysfs interface at
/sys/firmware/sgi_uv/ to expose information gathered from UV BIOS. This
information includes:
* UV Hub descriptions, including physical location
* Cabling layout between hubs on the fabric
* PCI topology, including physical location of PCI cards
Together, the information provides a robust physical description of a UV
system, useful for correlating to performance data or performing remote
support.
Signed-off-by: Justin Ernst <justin.ernst@hpe.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Reviewed-by: Steve Wahl <steve.wahl@hpe.com>
Acked-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lkml.kernel.org/r/20201125175444.279074-4-justin.ernst@hpe.com
AMD Power Management Controller driver a.k.a. amd-pmc driver is the
controller which is meant for the final S2Idle transaction that goes to
the PMFW running on the AMD SMU (System Management Unit) responsible for
tuning of the VDD.
Once all the monitored list or the idle constraints are met, this driver
would go and set the OS_HINT (meaning all the devices have reached to
their lowest state possible) via the SMU mailboxes.
This driver would also provide some debug capabilities via debugfs.
Signed-off-by: Shyam Sundar S K <Shyam-sundar.S-k@amd.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Link: https://lore.kernel.org/r/20201105140531.2955555-1-Shyam-sundar.S-k@amd.com
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Add support for the Intel Platform Monitoring Technology crashlog
interface. This interface provides a few sysfs values to allow for
controlling the crashlog telemetry interface as well as a character
driver to allow for mapping the crashlog memory region so that it can be
accessed after a crashlog has been recorded.
This driver is meant to only support the server version of the crashlog
which is identified as crash_type 1 with a version of zero. Currently no
other types are supported.
Signed-off-by: Alexander Duyck <alexander.h.duyck@linux.intel.com>
Signed-off-by: David E. Box <david.e.box@linux.intel.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
PMT Telemetry is a capability of the Intel Platform Monitoring Technology.
The Telemetry capability provides access to device telemetry metrics that
provide hardware performance data to users from read-only register spaces.
With this driver present the intel_pmt directory can be populated with
telem<x> devices. These devices will contain the standard intel_pmt sysfs
data and a "telem" binary sysfs attribute which can be used to access the
telemetry data.
Also create a PCI device id list for early telemetry hardware that require
workarounds for known issues.
Signed-off-by: Alexander Duyck <alexander.h.duyck@linux.intel.com>
Co-developed-by: David E. Box <david.e.box@linux.intel.com>
Signed-off-by: David E. Box <david.e.box@linux.intel.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Intel Platform Monitoring Technology is meant to provide a common way to
access telemetry and system metrics.
Register mappings are not provided by the driver. Instead, a GUID is read
from a header for each endpoint. The GUID identifies the device and is to
be used with an XML, provided by the vendor, to discover the available set
of metrics and their register mapping. This allows firmware updates to
modify the register space without needing to update the driver every time
with new mappings. Firmware writes a new GUID in this case to specify the
new mapping. Software tools with access to the associated XML file can
then interpret the changes.
The module manages access to all Intel PMT endpoints on a system,
independent of the device exporting them. It creates an intel_pmt class
to manage the devices. For each telemetry endpoint, sysfs files provide
GUID and size information as well as a pointer to the parent device the
telemetry came from. Software may discover the association between
endpoints and devices by iterating through the list in sysfs, or by looking
for the existence of the class folder under the device of interest. A
binary sysfs attribute of the same name allows software to then read or map
the telemetry space for direct access.
Signed-off-by: Alexander Duyck <alexander.h.duyck@linux.intel.com>
Signed-off-by: David E. Box <david.e.box@linux.intel.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
