iv/linux
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
d9cd21d441
linux/drivers/platform/x86/Makefile

147 lines
4.1 KiB
Makefile
Raw Normal View History

License cleanup: add SPDX GPL-2.0 license identifier to files with no license Many source files in the tree are missing licensing information, which makes it harder for compliance tools to determine the correct license. By default all files without license information are under the default license of the kernel, which is GPL version 2. Update the files which contain no license information with the 'GPL-2.0' SPDX license identifier. The SPDX identifier is a legally binding shorthand, which can be used instead of the full boiler plate text. This patch is based on work done by Thomas Gleixner and Kate Stewart and Philippe Ombredanne. How this work was done: Patches were generated and checked against linux-4.14-rc6 for a subset of the use cases: - file had no licensing information it it. - file was a */uapi/* one with no licensing information in it, - file was a */uapi/* one with existing licensing information, Further patches will be generated in subsequent months to fix up cases where non-standard license headers were used, and references to license had to be inferred by heuristics based on keywords. The analysis to determine which SPDX License Identifier to be applied to a file was done in a spreadsheet of side by side results from of the output of two independent scanners (ScanCode & Windriver) producing SPDX tag:value files created by Philippe Ombredanne. Philippe prepared the base worksheet, and did an initial spot review of a few 1000 files. The 4.13 kernel was the starting point of the analysis with 60,537 files assessed. Kate Stewart did a file by file comparison of the scanner results in the spreadsheet to determine which SPDX license identifier(s) to be applied to the file. She confirmed any determination that was not immediately clear with lawyers working with the Linux Foundation. Criteria used to select files for SPDX license identifier tagging was: - Files considered eligible had to be source code files. - Make and config files were included as candidates if they contained >5 lines of source - File already had some variant of a license header in it (even if <5 lines). All documentation files were explicitly excluded. The following heuristics were used to determine which SPDX license identifiers to apply. - when both scanners couldn't find any license traces, file was considered to have no license information in it, and the top level COPYING file license applied. For non */uapi/* files that summary was: SPDX license identifier # files ---------------------------------------------------|------- GPL-2.0 11139 and resulted in the first patch in this series. If that file was a */uapi/* path one, it was "GPL-2.0 WITH Linux-syscall-note" otherwise it was "GPL-2.0". Results of that was: SPDX license identifier # files ---------------------------------------------------|------- GPL-2.0 WITH Linux-syscall-note 930 and resulted in the second patch in this series. - if a file had some form of licensing information in it, and was one of the */uapi/* ones, it was denoted with the Linux-syscall-note if any GPL family license was found in the file or had no licensing in it (per prior point). Results summary: SPDX license identifier # files ---------------------------------------------------|------ GPL-2.0 WITH Linux-syscall-note 270 GPL-2.0+ WITH Linux-syscall-note 169 ((GPL-2.0 WITH Linux-syscall-note) OR BSD-2-Clause) 21 ((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause) 17 LGPL-2.1+ WITH Linux-syscall-note 15 GPL-1.0+ WITH Linux-syscall-note 14 ((GPL-2.0+ WITH Linux-syscall-note) OR BSD-3-Clause) 5 LGPL-2.0+ WITH Linux-syscall-note 4 LGPL-2.1 WITH Linux-syscall-note 3 ((GPL-2.0 WITH Linux-syscall-note) OR MIT) 3 ((GPL-2.0 WITH Linux-syscall-note) AND MIT) 1 and that resulted in the third patch in this series. - when the two scanners agreed on the detected license(s), that became the concluded license(s). - when there was disagreement between the two scanners (one detected a license but the other didn't, or they both detected different licenses) a manual inspection of the file occurred. - In most cases a manual inspection of the information in the file resulted in a clear resolution of the license that should apply (and which scanner probably needed to revisit its heuristics). - When it was not immediately clear, the license identifier was confirmed with lawyers working with the Linux Foundation. - If there was any question as to the appropriate license identifier, the file was flagged for further research and to be revisited later in time. In total, over 70 hours of logged manual review was done on the spreadsheet to determine the SPDX license identifiers to apply to the source files by Kate, Philippe, Thomas and, in some cases, confirmation by lawyers working with the Linux Foundation. Kate also obtained a third independent scan of the 4.13 code base from FOSSology, and compared selected files where the other two scanners disagreed against that SPDX file, to see if there was new insights. The Windriver scanner is based on an older version of FOSSology in part, so they are related. Thomas did random spot checks in about 500 files from the spreadsheets for the uapi headers and agreed with SPDX license identifier in the files he inspected. For the non-uapi files Thomas did random spot checks in about 15000 files. In initial set of patches against 4.14-rc6, 3 files were found to have copy/paste license identifier errors, and have been fixed to reflect the correct identifier. Additionally Philippe spent 10 hours this week doing a detailed manual inspection and review of the 12,461 patched files from the initial patch version early this week with: - a full scancode scan run, collecting the matched texts, detected license ids and scores - reviewing anything where there was a license detected (about 500+ files) to ensure that the applied SPDX license was correct - reviewing anything where there was no detection but the patch license was not GPL-2.0 WITH Linux-syscall-note to ensure that the applied SPDX license was correct This produced a worksheet with 20 files needing minor correction. This worksheet was then exported into 3 different .csv files for the different types of files to be modified. These .csv files were then reviewed by Greg. Thomas wrote a script to parse the csv files and add the proper SPDX tag to the file, in the format that the file expected. This script was further refined by Greg based on the output to detect more types of files automatically and to distinguish between header and source .c files (which need different comment types.) Finally Greg ran the script using the .csv files to generate the patches. Reviewed-by: Kate Stewart <kstewart@linuxfoundation.org> Reviewed-by: Philippe Ombredanne <pombredanne@nexb.com> Reviewed-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-11-01 17:07:57 +03:00
# SPDX-License-Identifier: GPL-2.0
create drivers/platform/x86/ from drivers/misc/ Move x86 platform specific drivers from drivers/misc/ to a new home under drivers/platform/x86/. The community has been maintaining x86 vendor-specific platform specific drivers under /drivers/misc/ for a few years. The oldest ones started life under drivers/acpi. They moved out of drivers/acpi/ because they don't actually implement the ACPI specification, but either simply use ACPI, or implement vendor-specific ACPI extensions. In the future we anticipate... drivers/misc/ will go away. other architectures will create drivers/platform/<arch> Signed-off-by: Len Brown <len.brown@intel.com>
2008-12-01 08:09:47 +03:00
#
# Makefile for linux/drivers/platform/x86
# x86 Platform-Specific Drivers
#
platform/x86: Makefile: Group modules by companies and functions For better maintenance group modules by companies and functions. No functional change intended. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
2020-01-28 21:33:05 +03:00
# Windows Management Interface
obj-$(CONFIG_ACPI_WMI) += wmi.o
obj-$(CONFIG_WMI_BMOF) += wmi-bmof.o
# WMI drivers
obj-$(CONFIG_HUAWEI_WMI) += huawei-wmi.o
obj-$(CONFIG_MXM_WMI) += mxm-wmi.o
platform/x86: Rename wmaa-backlight-wmi to nvidia-wmi-ec-backlight 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>
2021-09-27 23:23:59 +03:00
obj-$(CONFIG_NVIDIA_WMI_EC_BACKLIGHT) += nvidia-wmi-ec-backlight.o
platform/x86: Makefile: Group modules by companies and functions For better maintenance group modules by companies and functions. No functional change intended. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
2020-01-28 21:33:05 +03:00
obj-$(CONFIG_XIAOMI_WMI) += xiaomi-wmi.o
platform/x86: add Gigabyte WMI temperature driver 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>
2021-04-12 15:35:13 +03:00
obj-$(CONFIG_GIGABYTE_WMI) += gigabyte-wmi.o
platform/x86: Makefile: Group modules by companies and functions For better maintenance group modules by companies and functions. No functional change intended. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
2020-01-28 21:33:05 +03:00
# Acer
obj-$(CONFIG_ACERHDF) += acerhdf.o
obj-$(CONFIG_ACER_WIRELESS) += acer-wireless.o
obj-$(CONFIG_ACER_WMI) += acer-wmi.o
platform/x86: amd-pmc: Add AMD platform support for S2Idle 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>
2020-11-05 17:05:31 +03:00
# AMD
platform/x86: Move AMD platform drivers to separate directory Currently, AMD supported platform drivers are grouped under generic "x86" folder structure. Move the current drivers (amd-pmc and amd_hsmp) to a separate directory. This would also mean the newer driver submissions to pdx86 subsystem in the future will also land in AMD specific directory. Reviewed-by: Naveen Krishna Chatradhi <NaveenKrishna.Chatradhi@amd.com> Tested-by: Suma Hegde <suma.hegde@amd.com> Signed-off-by: Shyam Sundar S K <Shyam-sundar.S-k@amd.com> Link: https://lore.kernel.org/r/20220608193212.2827257-1-Shyam-sundar.S-k@amd.com Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2022-06-08 22:32:12 +03:00
obj-y += amd/
platform/x86: amd-pmc: Add AMD platform support for S2Idle 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>
2020-11-05 17:05:31 +03:00
platform/x86: add support for Advantech software defined button 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>
2021-03-19 06:44:27 +03:00
# Advantech
obj-$(CONFIG_ADV_SWBUTTON) += adv_swbutton.o
platform/x86: Makefile: Group modules by companies and functions For better maintenance group modules by companies and functions. No functional change intended. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
2020-01-28 21:33:05 +03:00
# Apple
obj-$(CONFIG_APPLE_GMUX) += apple-gmux.o
# ASUS
create drivers/platform/x86/ from drivers/misc/ Move x86 platform specific drivers from drivers/misc/ to a new home under drivers/platform/x86/. The community has been maintaining x86 vendor-specific platform specific drivers under /drivers/misc/ for a few years. The oldest ones started life under drivers/acpi. They moved out of drivers/acpi/ because they don't actually implement the ACPI specification, but either simply use ACPI, or implement vendor-specific ACPI extensions. In the future we anticipate... drivers/misc/ will go away. other architectures will create drivers/platform/<arch> Signed-off-by: Len Brown <len.brown@intel.com>
2008-12-01 08:09:47 +03:00
obj-$(CONFIG_ASUS_LAPTOP) += asus-laptop.o
platform/x86: Makefile: Group modules by companies and functions For better maintenance group modules by companies and functions. No functional change intended. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
2020-01-28 21:33:05 +03:00
obj-$(CONFIG_ASUS_WIRELESS) += asus-wireless.o
eeepc-wmi: asus generic asus-wmi.ko module New Asus notebooks are using a WMI device similar to the one used in Eee PCs. Since we don't want to load eeepc-wmi module on Asus notebooks, and we want to keep the eeepc-wmi module for backward compatibility, this patch introduce a new module, named asus-wmi, that will be used by eeepc-wmi and the new Asus Notebook WMI Driver. eeepc-wmi's input device strings (device name and phys) are kept, but rfkill and led names are changed (s/eeepc/asus/). This should not break anything since rfkill are used by type or index, not by name, and the eeepc::touchpad led wasn't working correctly before 2.6.39 anyway. Signed-off-by: Corentin Chary <corentincj@iksaif.net> Signed-off-by: Matthew Garrett <mjg@redhat.com>
2011-02-26 12:20:31 +03:00
obj-$(CONFIG_ASUS_WMI) += asus-wmi.o
asus-nb-wmi: Asus Notebooks WMI Driver Introduce a new driver for Asus Notebooks shipped with a WMI device instead of the old ACPI device. The WMI device is almost the same as the one present in Eee PC, but the event guid and the keymap are different. The keymap comes from asus-laptop module. On Asus notebooks, when you call the WMI device, you always need a 64bit buffer, even if you only want to get the state of a device (tested on a G73). Signed-off-by: Corentin Chary <corentincj@iksaif.net> Signed-off-by: Matthew Garrett <mjg@redhat.com>
2011-02-26 12:20:40 +03:00
obj-$(CONFIG_ASUS_NB_WMI) += asus-nb-wmi.o
platform/x86: Add Asus TF103C dock driver 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
2021-12-26 17:18:49 +03:00
obj-$(CONFIG_ASUS_TF103C_DOCK) += asus-tf103c-dock.o
create drivers/platform/x86/ from drivers/misc/ Move x86 platform specific drivers from drivers/misc/ to a new home under drivers/platform/x86/. The community has been maintaining x86 vendor-specific platform specific drivers under /drivers/misc/ for a few years. The oldest ones started life under drivers/acpi. They moved out of drivers/acpi/ because they don't actually implement the ACPI specification, but either simply use ACPI, or implement vendor-specific ACPI extensions. In the future we anticipate... drivers/misc/ will go away. other architectures will create drivers/platform/<arch> Signed-off-by: Len Brown <len.brown@intel.com>
2008-12-01 08:09:47 +03:00
obj-$(CONFIG_EEEPC_LAPTOP) += eeepc-laptop.o
eeepc-wmi: asus generic asus-wmi.ko module New Asus notebooks are using a WMI device similar to the one used in Eee PCs. Since we don't want to load eeepc-wmi module on Asus notebooks, and we want to keep the eeepc-wmi module for backward compatibility, this patch introduce a new module, named asus-wmi, that will be used by eeepc-wmi and the new Asus Notebook WMI Driver. eeepc-wmi's input device strings (device name and phys) are kept, but rfkill and led names are changed (s/eeepc/asus/). This should not break anything since rfkill are used by type or index, not by name, and the eeepc::touchpad led wasn't working correctly before 2.6.39 anyway. Signed-off-by: Corentin Chary <corentincj@iksaif.net> Signed-off-by: Matthew Garrett <mjg@redhat.com>
2011-02-26 12:20:31 +03:00
obj-$(CONFIG_EEEPC_WMI) += eeepc-wmi.o
platform/x86: Makefile: Group modules by companies and functions For better maintenance group modules by companies and functions. No functional change intended. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
2020-01-28 21:33:05 +03:00
platform/x86: add meraki-mx100 platform driver This adds platform support for the Cisco Meraki MX100 (Tinkerbell) network appliance. This sets up the network LEDs and Reset button. Depends-on: ef0eea5b151ae ("mfd: lpc_ich: Enable GPIO driver for DH89xxCC") Co-developed-by: Christian Lamparter <chunkeey@gmail.com> Signed-off-by: Christian Lamparter <chunkeey@gmail.com> Signed-off-by: Chris Blake <chrisrblake93@gmail.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Link: https://lore.kernel.org/r/20210810004021.2538308-1-chrisrblake93@gmail.com Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2021-08-10 03:40:21 +03:00
# Cisco/Meraki
obj-$(CONFIG_MERAKI_MX100) += meraki-mx100.o
platform/x86: Makefile: Group modules by companies and functions For better maintenance group modules by companies and functions. No functional change intended. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
2020-01-28 21:33:05 +03:00
# Dell
platform/x86: Move all dell drivers to their own subdirectory A user without a Dell system doesn't need to pick any of these drivers. Users with a Dell system can enable this submenu and all drivers behind it will be enabled. Suggested-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Mario Limonciello <mario.limonciello@dell.com> Link: https://lore.kernel.org/r/20210203195832.2950605-1-mario.limonciello@dell.com Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2021-02-03 22:58:32 +03:00
obj-$(CONFIG_X86_PLATFORM_DRIVERS_DELL) += dell/
platform/x86: Makefile: Group modules by companies and functions For better maintenance group modules by companies and functions. No functional change intended. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
2020-01-28 21:33:05 +03:00
# Fujitsu
obj-$(CONFIG_AMILO_RFKILL) += amilo-rfkill.o
obj-$(CONFIG_FUJITSU_LAPTOP) += fujitsu-laptop.o
obj-$(CONFIG_FUJITSU_TABLET) += fujitsu-tablet.o
# GPD
obj-$(CONFIG_GPD_POCKET_FAN) += gpd-pocket-fan.o
# Hewlett Packard
platform/x86: Move existing HP drivers to a new hp subdir The purpose of this patch is to provide a central location where all HP related drivers are found. HP drivers will recide under drivers/platform/x86/hp directory. Introduce changes to Kconfig file to list all HP driver under "HP X86 Platform Specific Device Drivers" menu option. Additional changes include update MAINTAINERS file to indicate hp related drivers new path. Signed-off-by: Jorge Lopez <jorge.lopez2@hp.com> Link: https://lore.kernel.org/r/20221020201033.12790-2-jorge.lopez2@hp.com Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2022-10-20 23:10:28 +03:00
obj-$(CONFIG_X86_PLATFORM_DRIVERS_HP) += hp/
platform/x86: Makefile: Group modules by companies and functions For better maintenance group modules by companies and functions. No functional change intended. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
2020-01-28 21:33:05 +03:00
x86/platform/uv: Add new uv_sysfs platform driver 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
2020-11-25 20:54:42 +03:00
# Hewlett Packard Enterprise
obj-$(CONFIG_UV_SYSFS) += uv_sysfs.o
platform/x86: Makefile: Group modules by companies and functions For better maintenance group modules by companies and functions. No functional change intended. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
2020-01-28 21:33:05 +03:00
# IBM Thinkpad and Lenovo
obj-$(CONFIG_IBM_RTL) += ibm_rtl.o
ideapad-laptop: Fix Makefile The makefile didn't get updated when the driver changed name, which broke the build. Signed-off-by: Matthew Garrett <mjg@redhat.com>
2010-10-05 17:18:30 +04:00
obj-$(CONFIG_IDEAPAD_LAPTOP) += ideapad-laptop.o
platform/x86: Add driver for Yoga Tablet Mode switch This WMI driver for the tablet mode control switch for Lenovo Yoga notebooks was originally written by Gergo Koteles. The mode is mapped to a SW_TABLET_MODE switch capable input device. Andrew followed the suggestions that were posted in reply to Gergo's RFC patch, and on the v1 & v2 versions of this patch to follow-up and get it merged. Changes from Gergo's RFC: - Refactored obtaining a reference to the EC ACPI device needed for the quirk implementation as suggested by Hans de Goede - Applied small fixes and switched to always registering handles with the driver for automatic cleanup as suggested by Barnabás Pőcze. - Merged the lenovo_ymc_trigger_ec function with the ideapad_trigger_ymc_next_read function since it was no longer external. - Added the word "Tablet" to the driver description to hopefully make it more clear. - Fixed the LENOVO_YMC_QUERY_METHOD ID and the name string for the EC APCI device trigged for the quirk - Triggered the input event on probe so that the initial tablet mode state when the driver is loaded is reported to userspace as suggested by Armin Wolf. - Restricted the permissions of the ec_trigger parameter as suggested by Armin Wolf. Also updated the description. We have tested this on the Yoga 7 14AIL7 for the non-quirk path and on the Yoga 7 14ARB7 which has the firmware bug that requires triggering the embedded controller to send the mode change events. This workaround is also used by the Windows drivers. According to reports at https://github.com/lukas-w/yoga-usage-mode, which uses the same WMI devices, the following models should also work: Yoga C940, Ideapad flex 14API, Yoga 9 14IAP7, Yoga 7 14ARB7, etc. Signed-off-by: Gergo Koteles <soyer@irl.hu> Co-developed-by: Andrew Kallmeyer <kallmeyeras@gmail.com> Signed-off-by: Andrew Kallmeyer <kallmeyeras@gmail.com> Link: https://lore.kernel.org/r/20221004214332.35934-1-soyer@irl.hu/ Link: https://lore.kernel.org/r/20230310041726.217447-1-kallmeyeras@gmail.com/ Link: https://lore.kernel.org/r/20230323025200.5462-1-kallmeyeras@gmail.com/ Tested-by: André Apitzsch <git@apitzsch.eu> Link: https://lore.kernel.org/r/20230329014559.44494-3-kallmeyeras@gmail.com Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2023-03-29 04:45:59 +03:00
obj-$(CONFIG_LENOVO_YMC) += lenovo-ymc.o
Move hdaps driver to platform/x86 The hdaps driver isn't a hardware monitoring driver, so it shouldn't live under driver/hwmon. drivers/platform/x86 seems much more appropriate, as the driver is only useful on x86 laptops. Signed-off-by: Jean Delvare <khali@linux-fr.org> Cc: Guenter Roeck <guenter.roeck@ericsson.com> Cc: Matthew Garrett <mjg@redhat.com> Cc: Frank Seidel <frank@f-seidel.de> Signed-off-by: Matthew Garrett <mjg@redhat.com>
2010-10-05 14:08:57 +04:00
obj-$(CONFIG_SENSORS_HDAPS) += hdaps.o
platform/x86: Makefile: Group modules by companies and functions For better maintenance group modules by companies and functions. No functional change intended. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
2020-01-28 21:33:05 +03:00
obj-$(CONFIG_THINKPAD_ACPI) += thinkpad_acpi.o
platform/x86: think-lmi: Add WMI interface support on Lenovo platforms For Lenovo platforms that support a WMI interface to the BIOS add support, using the firmware-attributes class, to allow users to access and modify various BIOS related settings. Signed-off-by: Mark Pearson <markpearson@lenovo.com> Link: https://lore.kernel.org/r/20210530223111.25929-3-markpearson@lenovo.com Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2021-05-31 01:31:11 +03:00
obj-$(CONFIG_THINKPAD_LMI) += think-lmi.o
platform/x86: lenovo-yogabook: Rename lenovo-yogabook-wmi to lenovo-yogabook The lenovo-yogabook-wmi.c code now consists of both a platform and a WMI driver and it does not use WMI at all when used on the Android model. Rename the module from lenovo-yogabook-wmi to lenovo-yogabook to reflect this. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20230430165807.472798-20-hdegoede@redhat.com
2023-04-30 19:58:07 +03:00
obj-$(CONFIG_YOGABOOK) += lenovo-yogabook.o
platform/x86: Makefile: Group modules by companies and functions For better maintenance group modules by companies and functions. No functional change intended. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
2020-01-28 21:33:05 +03:00
# Intel
platform/x86/intel: Remove X86_PLATFORM_DRIVERS_INTEL 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: 8bd836feb6ca ("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>
2021-12-22 22:49:41 +03:00
obj-y += intel/
platform/x86: intel_skl_int3472: Move to intel/ subfolder Start collecting Intel x86 related drivers in its own subfolder. Move intel_skl_int3472 first. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20210618125516.53510-7-andriy.shevchenko@linux.intel.com Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2021-06-18 15:55:15 +03:00
platform/x86: Makefile: Group modules by companies and functions For better maintenance group modules by companies and functions. No functional change intended. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
2020-01-28 21:33:05 +03:00
# MSI
platform/x86: Add new msi-ec driver Add a new driver to allow various MSI laptops' functionalities to be controlled from userspace. This includes such features as power profiles (aka shift modes), fan speed, charge thresholds, LEDs, etc. This driver contains EC memory configurations for different firmware versions and exports battery charge thresholds to userspace (note, that start and end thresholds control the same EC parameter and are always 10% apart). Link: https://github.com/BeardOverflow/msi-ec/ Link: https://github.com/BeardOverflow/msi-ec/pull/13 Cc: Aakash Singh <mail@singhaakash.dev> Cc: Jose Angel Pastrana <japp0005@red.ujaen.es> Signed-off-by: Nikita Kravets <teackot@gmail.com> Link: https://lore.kernel.org/r/20230320225509.3559-1-teackot@gmail.com Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2023-03-21 01:55:09 +03:00
obj-$(CONFIG_MSI_EC) += msi-ec.o
platform/x86: Makefile: Group modules by companies and functions For better maintenance group modules by companies and functions. No functional change intended. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
2020-01-28 21:33:05 +03:00
obj-$(CONFIG_MSI_LAPTOP) += msi-laptop.o
X86 drivers: Introduce msi-wmi driver This driver serves backlight (including switching) and volume up/down keys for MSI machines providing a specific wmi interface: 551A1F84-FBDD-4125-91DB-3EA8F44F1D45 B6F3EEF2-3D2F-49DC-9DE3-85BCE18C62F2 Signed-off-by: Thomas Renninger <trenn@suse.de> CC: Carlos Corbacho <carlos@strangeworlds.co.uk> CC: Matthew Garrett <mjg59@srcf.ucam.org> Tested-by: Matt Chen <machen@novell.com> Reviewed-by: Anisse Astier <anisse@astier.eu> Signed-off-by: Len Brown <len.brown@intel.com>
2009-12-10 16:18:13 +03:00
obj-$(CONFIG_MSI_WMI) += msi-wmi.o
toshiba_acpi: Refuse to load on machines with buggy INFO implementations Several Satellite models have a buggy implementation of the INFO method that causes ACPI exceptions when executed: ACPI Error: Result stack is empty! State=ffff88012d70f800 (20110413/dswstate-98) ACPI Exception: AE_AML_NO_RETURN_VALUE, Missing or null operand (20110413/dsutils-646) ACPI Exception: AE_AML_NO_RETURN_VALUE, While creating Arg 0 (20110413/dsutils-763) ACPI Error: Method parse/execution failed [\_SB_.VALZ.GETE] (Node ffff880131175eb0), AE_AML_NO_RETURN_VALUE (20110413/psparse-536) ACPI Error: Method parse/execution failed [\_SB_.VALZ.INFO] (Node ffff880131175ed8), AE_AML_NO_RETURN_VALUE (20110413/psparse-536) toshiba_acpi: ACPI INFO method execution failed toshiba_acpi: Failed to query hotkey event All known machines with this implementation also have a WMI interface with event GUID 59142400-C6A3-40FA-BADB-8A2652834100 which is not seen on any other models. Refuse to load toshiba_acpi on machines with this guid. Signed-off-by: Seth Forshee <seth.forshee@canonical.com> Signed-off-by: Matthew Garrett <mjg@redhat.com>
2012-01-18 23:44:11 +04:00
platform/x86: Makefile: Group modules by companies and functions For better maintenance group modules by companies and functions. No functional change intended. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
2020-01-28 21:33:05 +03:00
# OLPC
obj-$(CONFIG_XO15_EBOOK) += xo15-ebook.o
obj-$(CONFIG_XO1_RFKILL) += xo1-rfkill.o
toshiba_acpi: Refuse to load on machines with buggy INFO implementations Several Satellite models have a buggy implementation of the INFO method that causes ACPI exceptions when executed: ACPI Error: Result stack is empty! State=ffff88012d70f800 (20110413/dswstate-98) ACPI Exception: AE_AML_NO_RETURN_VALUE, Missing or null operand (20110413/dsutils-646) ACPI Exception: AE_AML_NO_RETURN_VALUE, While creating Arg 0 (20110413/dsutils-763) ACPI Error: Method parse/execution failed [\_SB_.VALZ.GETE] (Node ffff880131175eb0), AE_AML_NO_RETURN_VALUE (20110413/psparse-536) ACPI Error: Method parse/execution failed [\_SB_.VALZ.INFO] (Node ffff880131175ed8), AE_AML_NO_RETURN_VALUE (20110413/psparse-536) toshiba_acpi: ACPI INFO method execution failed toshiba_acpi: Failed to query hotkey event All known machines with this implementation also have a WMI interface with event GUID 59142400-C6A3-40FA-BADB-8A2652834100 which is not seen on any other models. Refuse to load toshiba_acpi on machines with this guid. Signed-off-by: Seth Forshee <seth.forshee@canonical.com> Signed-off-by: Matthew Garrett <mjg@redhat.com>
2012-01-18 23:44:11 +04:00
platform/x86: Makefile: Group modules by companies and functions For better maintenance group modules by companies and functions. No functional change intended. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
2020-01-28 21:33:05 +03:00
# PC Engines
obj-$(CONFIG_PCENGINES_APU2) += pcengines-apuv2.o
platform/x86: Support for EC-connected GPIOs for identify LED/button on Barco P50 board 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>
2021-10-20 15:36:34 +03:00
# Barco
obj-$(CONFIG_BARCO_P50_GPIO) += barco-p50-gpio.o
platform/x86: Makefile: Group modules by companies and functions For better maintenance group modules by companies and functions. No functional change intended. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
2020-01-28 21:33:05 +03:00
# Samsung
obj-$(CONFIG_SAMSUNG_LAPTOP) += samsung-laptop.o
obj-$(CONFIG_SAMSUNG_Q10) += samsung-q10.o
# Toshiba
Toshiba Bluetooth Enabling driver (RFKill handler v3) This patch adds support for the ACPI events generated by the RFKill switch on modern Toshiba laptops, and re-enables the Bluetooth USB device when the switch is flipped back to the 'on' position. The RFKill switch brute force pulls out the USB device when flipped to 'off', but it doesn't automatically re-enable it. Without this driver, the Bluetooth is gone until after a reboot on my Portege R500. Signed-off-by: Jes Sorensen <Jes.Sorensen@gmail.com> Signed-off-by: Len Brown <len.brown@intel.com>
2009-12-16 20:08:15 +03:00
obj-$(CONFIG_TOSHIBA_BT_RFKILL) += toshiba_bluetooth.o
platform/x86: Enable build support for toshiba_haps Makefile and Kconfig build support patch for the newly introduced kernel module toshiba_haps. Signed-off-by: Azael Avalos <coproscefalo@gmail.com> Signed-off-by: Matthew Garrett <matthew.garrett@nebula.com>
2014-08-14 19:55:40 +04:00
obj-$(CONFIG_TOSHIBA_HAPS) += toshiba_haps.o
platform/x86: Toshiba WMI Hotkey Driver Toshiba laptops that feature WMI events for hotkeys were left unsupported by the toshiba_acpi driver, however, commit a88bc06e5aec ("toshiba_acpi: Avoid registering input device on WMI event laptops") added hardware support for such laptops, but the hotkeys are not handled there. This driver adds support for hotkey monitoring on certain Toshiba laptops that manage the hotkeys via WMI events instead of the Toshiba Configuration Interface (TCI). The toshiba_acpi driver and this one can co-exist, as this only takes care of hotkeys, while the proper takes care of hardware related stuff. Currently the driver is under the EXPERIMENTAL flag, as the keymap and the notify function are incomplete (due to lack of hardware to test). Signed-off-by: Azael Avalos <coproscefalo@gmail.com> Signed-off-by: Darren Hart <dvhart@linux.intel.com>
2015-09-29 05:32:28 +03:00
obj-$(CONFIG_TOSHIBA_WMI) += toshiba-wmi.o
pvpanic: pvpanic device driver pvpanic device is a qemu simulated device through which guest panic event is sent to host. Signed-off-by: Hu Tao <hutao@cn.fujitsu.com> Signed-off-by: Matthew Garrett <matthew.garrett@nebula.com>
2013-05-08 07:15:32 +04:00
platform/x86: Makefile: Group modules by companies and functions For better maintenance group modules by companies and functions. No functional change intended. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
2020-01-28 21:33:05 +03:00
# toshiba_acpi must link after wmi to ensure that wmi devices are found
# before toshiba_acpi initializes
obj-$(CONFIG_ACPI_TOSHIBA) += toshiba_acpi.o
platform/x86: inspur-platform-profile: Add platform profile support Add support for Inspur platforms to used the platform profile feature. This will allow users to determine and control the platform modes between low-power, balanced and performance modes. Signed-off-by: Ai Chao <aichao@kylinos.cn> Reviewed-by: Thomas Weißschuh <linux@weissschuh.net> Reviewed-by: Armin Wolf <W_Armin@gmx.de> Link: https://lore.kernel.org/r/20231020024007.1677962-1-aichao@kylinos.cn [ij: Removed kerneldoc markers from non-kerneldoc comments.] Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2023-10-20 05:40:07 +03:00
# Inspur
obj-$(CONFIG_INSPUR_PLATFORM_PROFILE) += inspur_platform_profile.o
platform/x86: Makefile: Group modules by companies and functions For better maintenance group modules by companies and functions. No functional change intended. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
2020-01-28 21:33:05 +03:00
# Laptop drivers
obj-$(CONFIG_ACPI_CMPC) += classmate-laptop.o
obj-$(CONFIG_COMPAL_LAPTOP) += compal-laptop.o
obj-$(CONFIG_LG_LAPTOP) += lg-laptop.o
obj-$(CONFIG_PANASONIC_LAPTOP) += panasonic-laptop.o
obj-$(CONFIG_SONY_LAPTOP) += sony-laptop.o
obj-$(CONFIG_SYSTEM76_ACPI) += system76_acpi.o
obj-$(CONFIG_TOPSTAR_LAPTOP) += topstar-laptop.o
# Platform drivers
platform/x86: firmware_attributes_class: Create helper file for handling firmware-attributes class registration events This offers shared code for registering the firmware_attributes_class, which is used by the Dell and Lenovo WMI management drivers. Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Mark Pearson <markpearson@lenovo.com> Link: https://lore.kernel.org/r/20210530223111.25929-1-markpearson@lenovo.com Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2021-05-31 01:31:09 +03:00
obj-$(CONFIG_FW_ATTR_CLASS) += firmware_attributes_class.o
platform/x86: i2c-multi-instantiate: Rename it for a generic serial driver name Rename I2C multi instantiate driver to serial-multi-instantiate for upcoming addition of SPI support Signed-off-by: Lucas Tanure <tanureal@opensource.cirrus.com> Signed-off-by: Stefan Binding <sbinding@opensource.cirrus.com> Link: https://lore.kernel.org/r/20220121172431.6876-6-sbinding@opensource.cirrus.com Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2022-01-21 20:24:27 +03:00
obj-$(CONFIG_SERIAL_MULTI_INSTANTIATE) += serial-multi-instantiate.o
platform/x86: Makefile: Group modules by companies and functions For better maintenance group modules by companies and functions. No functional change intended. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
2020-01-28 21:33:05 +03:00
obj-$(CONFIG_MLX_PLATFORM) += mlx-platform.o
obj-$(CONFIG_TOUCHSCREEN_DMI) += touchscreen_dmi.o
platform/x86: Rename hp-wireless to wireless-hotkey This driver was originally intended to support some HP laptops, but later support was added for Xioami and AMD laptops. Rename it to make it clear that it supports a larger variety of systems. Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Link: https://lore.kernel.org/r/20210519174405.30155-1-mario.limonciello@amd.com Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2021-05-19 20:44:05 +03:00
obj-$(CONFIG_WIRELESS_HOTKEY) += wireless-hotkey.o
platform/x86: x86-android-tablets: Move into its own subdir Move the x86-android-tablets code into its own subdir, this is a preparation patch for splitting the somewhat large file into multiple smaller files. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Link: https://lore.kernel.org/r/20230301092331.7038-3-hdegoede@redhat.com
2023-02-19 19:06:14 +03:00
obj-$(CONFIG_X86_ANDROID_TABLETS) += x86-android-tablets/
platform/x86: Makefile: Group modules by companies and functions For better maintenance group modules by companies and functions. No functional change intended. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
2020-01-28 21:33:05 +03:00
# Intel uncore drivers
obj-$(CONFIG_INTEL_IPS) += intel_ips.o
platform/x86: p2sb: Move out of X86_PLATFORM_DEVICES dependency The P2SB library is used for various drivers, including server platforms. That's why the dependency on X86_PLATFORM_DEVICES seems superfluous. Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20220718145328.14374-1-andriy.shevchenko@linux.intel.com Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2022-07-18 17:53:28 +03:00
# Intel miscellaneous drivers
intel_p2sb-y := p2sb.o
obj-$(CONFIG_P2SB) += intel_p2sb.o
platform/x86: Makefile: Group modules by companies and functions For better maintenance group modules by companies and functions. No functional change intended. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
2020-01-28 21:33:05 +03:00
# Intel PMIC / PMC / P-Unit devices
obj-$(CONFIG_INTEL_SCU_IPC) += intel_scu_ipc.o
platform/x86: intel_scu_ipc: Split out SCU IPC functionality from the SCU driver The SCU IPC functionality is usable outside of Intel MID devices. For example modern Intel CPUs include the same thing but now it is called PMC (Power Management Controller) instead of SCU. To make the IPC available for those split the driver into core part (intel_scu_ipc.c) and the SCU PCI driver part (intel_scu_pcidrv.c) which then calls the former before it goes and creates rest of the SCU devices. The SCU IPC will also register a new class that gets assigned to the device that is created under the parent PCI device. We also split the Kconfig symbols so that INTEL_SCU_IPC enables the SCU IPC library and INTEL_SCU_PCI the SCU driver and convert the users accordingly. While there remove default y from the INTEL_SCU_PCI symbol as it is already selected by X86_INTEL_MID. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Lee Jones <lee.jones@linaro.org>
2020-04-16 11:15:33 +03:00
obj-$(CONFIG_INTEL_SCU_PCI) += intel_scu_pcidrv.o
platform/x86: Add Elkhart Lake SCU/PMC support Intel Elkhart Lake exposes SCU/PMC as an ACPI device that only supports IPC functionality so add a platform driver supporting it. Interrupt is optional so we let intel_scu_ipc_probe() to decide based on the passed platform data whether it uses interrupt or polling. Co-developed-by: Divya Sasidharan <divya.s.sasidharan@intel.com> Signed-off-by: Divya Sasidharan <divya.s.sasidharan@intel.com> Co-developed-by: Rajmohan Mani <rajmohan.mani@intel.com> Signed-off-by: Rajmohan Mani <rajmohan.mani@intel.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
2020-04-28 11:51:12 +03:00
obj-$(CONFIG_INTEL_SCU_PLATFORM) += intel_scu_pltdrv.o
platform/x86: intel_scu_wdt: Move driver from arch/x86 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>
2020-10-23 19:03:19 +03:00
obj-$(CONFIG_INTEL_SCU_WDT) += intel_scu_wdt.o
platform/x86: Makefile: Group modules by companies and functions For better maintenance group modules by companies and functions. No functional change intended. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
2020-01-28 21:33:05 +03:00
obj-$(CONFIG_INTEL_SCU_IPC_UTIL) += intel_scu_ipcutil.o
platform/x86: Drop the PMC_ATOM Kconfig option The def_bool y PMC_ATOM Kconfig option provides a couple of symbols used by the code enabled by the X86_INTEL_LPSS option and it registers some clocks. These clocks are only registered on Bay Trail, Cherry Trail and Brasswell Intel SoCs and kernels targeting these SoCs must always have the X86_INTEL_LPSS option enabled otherwise many things will not work. Building the PMC_ATOM code on kernels which are not targeting the mentioned SoCs and which do not have the X86_INTEL_LPSS enabled is not useful. This means that we can simplify things by replacing the PMC_ATOM Kconfig option in Makefiles with X86_INTEL_LPSS and then drop the option. Cc: Paul Gortmaker <paul.gortmaker@windriver.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Acked-by: Andy Shevchenko <andy.shevchenko@gmail.com> Acked-by: Stephen Boyd <sboyd@kernel.org> Link: https://lore.kernel.org/r/20220503140207.101218-2-hdegoede@redhat.com
2022-05-03 17:02:07 +03:00
obj-$(CONFIG_X86_INTEL_LPSS) += pmc_atom.o
platform/x86: simatic-ipc: add main driver for Siemens devices 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>
2021-12-13 15:04:59 +03:00
# Siemens Simatic Industrial PCs
platform/x86: Move all simatic ipc drivers to the subdirectory siemens With more files around move everything to a subdirectory. Users will only see the several options once they enable the main one. Suggested-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Henning Schild <henning.schild@siemens.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20230719153518.13073-4-henning.schild@siemens.com Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2023-07-19 18:35:18 +03:00
obj-$(CONFIG_SIEMENS_SIMATIC_IPC) += siemens/
platform/x86: winmate-fm07-keys: Winmate FM07/FM07P buttons Winmate FM07 and FM07P in-vehicle computers have a row of five buttons below the display. This module adds an input device that delivers key events when these buttons are pressed. Signed-off-by: Daniel Beer <daniel.beer@tirotech.co.nz> Link: https://lore.kernel.org/r/623a110a.1c69fb81.64f39.0118@mx.google.com Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2022-03-21 06:16:27 +03:00
platform/x86: Add Silicom Platform Driver Add Silicom platform (silicom-platform) Linux driver for Swisscom Business Box (Swisscom BB) as well as Cordoba family products. This platform driver provides support for various functions via the Linux LED framework, GPIO framework, Hardware Monitoring (HWMON) and device attributes. Signed-off-by: Henry Shi <henryshi2018@gmail.com> Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Link: https://lore.kernel.org/r/20231124200334.5318-1-henryshi2018@gmail.com Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2023-11-24 23:03:34 +03:00
# Silicom
obj-$(CONFIG_SILICOM_PLATFORM) += silicom-platform.o
platform/x86: winmate-fm07-keys: Winmate FM07/FM07P buttons Winmate FM07 and FM07P in-vehicle computers have a row of five buttons below the display. This module adds an input device that delivers key events when these buttons are pressed. Signed-off-by: Daniel Beer <daniel.beer@tirotech.co.nz> Link: https://lore.kernel.org/r/623a110a.1c69fb81.64f39.0118@mx.google.com Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2022-03-21 06:16:27 +03:00
# Winmate
obj-$(CONFIG_WINMATE_FM07_KEYS) += winmate-fm07-keys.o
platform/x86: Add SEL-3350 platform driver Add a driver for Schweitzer Engineering Laboratories SEL-3350 computers front LEDs and power supplies. LED and power supply status is provided by the Intel SoC GPIO. Signed-off-by: Robert Joslyn <robert.joslyn@redrectangle.org> Link: https://lore.kernel.org/r/20230713035714.807819-1-robert.joslyn@redrectangle.org Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2023-07-13 06:48:52 +03:00
# SEL
obj-$(CONFIG_SEL3350_PLATFORM) += sel3350-platform.o
Reference in New Issue Copy Permalink