The Lenovo Yoga Tab 3 (YT3-X90F) is an Intel Cherry Trail based tablet
which ships with Android as Factory OS. Its DSDT contains a bunch of I2C
devices which are not actually there, causing various resource conflicts.
Use acpi_quirk_skip_i2c_client_enumeration() to not enumerate these.
The YT3-X90F has quite a bit of exotic hardware, this adds initial
support by manually instantiating the i2c-clients for the 2 charger +
2 fuel-gauge chips used for the 2 batteries.
Support for other parts of the hw will be added by follow-up patches.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20221127182458.104528-1-hdegoede@redhat.com
The Medion Lifetab S10346 is a x86 ACPI tablet which ships with Android
x86 as factory OS. Its DSDT contains a bunch of I2C devices which are not
actually there, causing various resource conflicts. Enumeration of these
is skipped through the acpi_quirk_skip_i2c_client_enumeration().
Add support for manually instantiating the I2C devices which are
actually present on this tablet by adding the necessary device info to
the x86-android-tablets module.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Link: https://lore.kernel.org/r/20221208110224.107354-1-hdegoede@redhat.com
Following by the below discussion, there's the potential UAF issue
between regulator and mfd.
https://lore.kernel.org/all/20221128143601.1698148-1-yangyingliang@huawei.com/
From the analysis of Yingliang
CPU A |CPU B
mt6370_probe() |
devm_mfd_add_devices() |
|mt6370_regulator_probe()
| regulator_register()
| //allocate init_data and add it to devres
| regulator_of_get_init_data()
i2c_unregister_device() |
device_del() |
devres_release_all() |
// init_data is freed |
release_nodes() |
| // using init_data causes UAF
| regulator_register()
It's common to use mfd core to create child device for the regulator.
In order to do the DT lookup for init data, the child that registered
the regulator would pass its parent as the parameter. And this causes
init data resource allocated to its parent, not itself. The issue happen
when parent device is going to release and regulator core is still doing
some operation of init data constraint for the regulator of child device.
To fix it, this patch expand 'regulator_register' API to use the
different devices for init data allocation and DT lookup.
Reported-by: Yang Yingliang <yangyingliang@huawei.com>
Signed-off-by: ChiYuan Huang <cy_huang@richtek.com>
Link: https://lore.kernel.org/r/1670311341-32664-1-git-send-email-u0084500@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Drop the "if MIPS" and "endif" drivers/platform/Kconfig. Instead add
a "depends on MIPS" to "menuconfig MIPS_PLATFORM_DEVICES" in drivers/
platform/mips/Kconfig, like all the other subdirs are doing.
Suggested-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
`cros_typec_get_switch_handles` allocates four pointers when obtaining
type-c switch handles. These pointers are all freed if failing to obtain
any of them; therefore, pointers in `port` become stale. The stale
pointers eventually cause use-after-free or double free in later code
paths. Zeroing out all pointer fields after freeing to eliminate these
stale pointers.
Fixes: f28adb41da ("platform/chrome: cros_ec_typec: Register Type C switches")
Fixes: 1a8912caba ("platform/chrome: cros_ec_typec: Get retimer handle")
Signed-off-by: Victor Ding <victording@chromium.org>
Acked-by: Prashant Malani <pmalani@chromium.org>
Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org>
Link: https://lore.kernel.org/r/20221207093924.v2.1.I1864b6a7ee98824118b93677868d22d3750f439b@changeid
Pull x86 platform driver fix from Hans de Goede:
"A single fix for 6.1 for suspend/resume issues on some AMD systems"
* tag 'platform-drivers-x86-v6.1-5' of git://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86:
platform/x86/amd: pmc: Add a workaround for an s0i3 issue on Cezanne
The following WARNING message was given when rmmod cros_usbpd_notify:
Unexpected driver unregister!
WARNING: CPU: 0 PID: 253 at drivers/base/driver.c:270 driver_unregister+0x8a/0xb0
Modules linked in: cros_usbpd_notify(-)
CPU: 0 PID: 253 Comm: rmmod Not tainted 6.1.0-rc3 #24
...
Call Trace:
<TASK>
cros_usbpd_notify_exit+0x11/0x1e [cros_usbpd_notify]
__x64_sys_delete_module+0x3c7/0x570
? __ia32_sys_delete_module+0x570/0x570
? lock_is_held_type+0xe3/0x140
? syscall_enter_from_user_mode+0x17/0x50
? rcu_read_lock_sched_held+0xa0/0xd0
? syscall_enter_from_user_mode+0x1c/0x50
do_syscall_64+0x37/0x90
entry_SYSCALL_64_after_hwframe+0x63/0xcd
RIP: 0033:0x7f333fe9b1b7
The reason is that the cros_usbpd_notify_init() does not check the return
value of platform_driver_register(), and the cros_usbpd_notify can
install successfully even if platform_driver_register() failed.
Fix by checking the return value of platform_driver_register() and
unregister cros_usbpd_notify_plat_driver when it failed.
Fixes: ec2daf6e33 ("platform: chrome: Add cros-usbpd-notify driver")
Signed-off-by: Yuan Can <yuancan@huawei.com>
Reviewed-by: Brian Norris <briannorris@chromium.org>
Link: https://lore.kernel.org/r/20221117080823.77549-1-yuancan@huawei.com
Signed-off-by: Prashant Malani <pmalani@chromium.org>
For bus-based driver, device removal is implemented as:
1 device_remove()->
2 bus->remove()->
3 driver->remove()
Driver core needs no inform from callee(bus driver) about the
result of remove callback. In that case, commit fc7a6209d5
("bus: Make remove callback return void") forces bus_type::remove
be void-returned.
Now we have the situation that both 1 & 2 of calling chain are
void-returned, so it does not make much sense for 3(driver->remove)
to return non-void to its caller.
So the basic idea behind this change is making remove() callback of
any bus-based driver to be void-returned.
This change, for itself, is for device drivers based on acpi-bus.
Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Acked-by: Lee Jones <lee@kernel.org>
Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Dawei Li <set_pte_at@outlook.com>
Reviewed-by: Maximilian Luz <luzmaximilian@gmail.com> # for drivers/platform/surface/*
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Remove the ACPI-HID + DMI-id deny-lists for touchpad_ctrl_via_ec and
instead make it a module option which defaults to false.
The touchpad sysfs attribute allowing directly writing VPCCMD_W_TOUCHPAD
from userspace has been leading to a lot of bug-reports / patches adding
both ACPI HID + dmi-id based deny-lists for it which then need to be
expanded all the time going forward leading to a high maintenance load.
At the same time the touchpad sysfs attribute is not a standard Linux
userspace API. So it is not used in standard desktop-enviroments, instead
it is only used in the following 2 rare circumstances:
1. Ideapad specific control-panel like applets
2. Custom scripts written by users
For 1. these applets need to already deal with the touchpad sysfs attr
sometimes not being there because of the existing deny lists so hiding
it be default should not cause an issue; and most desktop environments
already have a touchpad-disable option in their native control-panel,
so having an ideapad specific toggle for this is not necessary.
For 2. since these users are already customizing their systems they
can add the module option if they want to keep using the touchpad
sysfs attribute.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Jiaxun Yang <jiaxun.yang@flygoat.com>
Tested-by: Jiaxun Yang <jiaxun.yang@flygoat.com>
Tested-by: Maxim Mikityanskiy <maxtram95@gmail.com>
Link: https://lore.kernel.org/r/20221117110244.67811-7-hdegoede@redhat.com
Commit d69cd7eea9 ("platform/x86: ideapad-laptop: Disable touchpad_switch
for ELAN0634") from Janary 2021 added a flag hiding the touchpad sysfs-attr
and disabling ideapad_sync_touchpad_state() because some devices
"do not use EC to switch touchpad".
At the same time this added a write(VPCCMD_W_TOUCHPAD, 1) call at probe
time on these same devices. This seems to be copied from the rfkill code
which does something similar when hw rfkill support is disabled.
But for the rfkill code this is known to be necessary on some models,
where as for the touchpad control no motivation is given for doing this
and prior to this patch there were no reports of needing to do this.
So this seems unnecessary; and it is best to avoid poking the hardware
unnecessary to avoid unwanted side effects, so remove this.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Jiaxun Yang <jiaxun.yang@flygoat.com>
Tested-by: Jiaxun Yang <jiaxun.yang@flygoat.com>
Tested-by: Maxim Mikityanskiy <maxtram95@gmail.com>
Link: https://lore.kernel.org/r/20221117110244.67811-6-hdegoede@redhat.com
On recent Ideapad models the EC does not control the touchpad at all,
so instead of sending KEY_TOUCHPAD_ON/ _OFF on touchpad toggle hotkey
events, ideapad-laptop should send KEY_TOUCHPAD_TOGGLE and let userspace
handle the toggling.
Check for this by checking if the value read from VPCCMD_R_TOUCHPAD
actually changes when receiving a touchpad-toggle hotkey event; and
if it does not change send KEY_TOUCHPAD_TOGGLE to userspace to let
userspace enable/disable the touchpad in software.
Note this also drops the priv->features.touchpad_ctrl_via_ec check from
ideapad_sync_touchpad_state() so that KEY_TOUCHPAD_TOGGLE will be send
on laptops where this is not set too. This can be safely dropped now
because the i8042_command(I8042_CMD_AUX_ENABLE/_DISABLE) call is now
guarded by its own feature flag.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Jiaxun Yang <jiaxun.yang@flygoat.com>
Tested-by: Jiaxun Yang <jiaxun.yang@flygoat.com>
Tested-by: Maxim Mikityanskiy <maxtram95@gmail.com>
Link: https://lore.kernel.org/r/20221117110244.67811-5-hdegoede@redhat.com
Recently there have been multiple patches to disable the ideapad-laptop's
touchpad control code, because it is causing issues on various laptops:
Commit d69cd7eea9 ("platform/x86: ideapad-laptop: Disable touchpad_switch for ELAN0634")
Commit a231224a60 ("platform/x86: ideapad-laptop: Disable touchpad_switch")
The turning on/off of the ps2 aux port was added specifically for
the IdeaPad Z570, where the EC does toggle the touchpad on/off LED and
toggles the value returned by reading VPCCMD_R_TOUCHPAD, but it does not
actually turn on/off the touchpad.
The ideapad-laptop code really should not be messing with the i8042
controller on all devices just for this special case.
Add a new ctrl_ps2_aux_port flag set based on a DMI based allow-list
for devices which need this workaround, populating it with just
the Ideapad Z570 for now.
This also adds a module parameter so that this behavior can easily
be enabled on other models which may need it.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Jiaxun Yang <jiaxun.yang@flygoat.com>
Tested-by: Jiaxun Yang <jiaxun.yang@flygoat.com>
Tested-by: Maxim Mikityanskiy <maxtram95@gmail.com>
Link: https://lore.kernel.org/r/20221117110244.67811-4-hdegoede@redhat.com
Initial implementation assumed a single IFS test image file with a
fixed name ff-mm-ss.scan. (where ff, mm, ss refers to family, model and
stepping of the core).
Subsequently, it became evident that supporting more than one test
image file is needed to provide more comprehensive test coverage. (Test
coverage in this scenario refers to testing more transistors in the core
to identify faults).
The other alternative of increasing the size of a single scan test image
file would not work as the upper bound is limited by the size of memory
area reserved by BIOS for loading IFS test image.
Introduce "current_batch" file which accepts a number. Writing a
number to the current_batch file would load the test image file by
name ff-mm-ss-<xy>.scan, where <xy> is the number written to the
"current_batch" file in hex. Range check of the input is done to verify
it not greater than 0xff.
For e.g if the scan test image comprises of 6 files, they would be named:
06-8f-06-01.scan
06-8f-06-02.scan
06-8f-06-03.scan
06-8f-06-04.scan
06-8f-06-05.scan
06-8f-06-06.scan
And writing 3 to current_batch would result in loading 06-8f-06-03.scan
above. The file can also be read to know the currently loaded file.
And testing a system looks like:
for each scan file
do
load the IFS test image file (write to the batch file)
for each core
do
test the core with this set of tests
done
done
Qualify few error messages with the test image file suffix to provide
better context.
[ bp: Massage commit message. Add link to the discussion. ]
Signed-off-by: Jithu Joseph <jithu.joseph@intel.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Reviewed-by: Tony Luck <tony.luck@intel.com>
Reviewed-by: Sohil Mehta <sohil.mehta@intel.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20221107225323.2733518-13-jithu.joseph@intel.com
The data portion of a IFS test image file contains a metadata region
containing possibly multiple metadata structures in addition to test
data and hashes.
IFS Metadata layout
+----------------------+ 0
|META_TYPE_IFS (=1) |
+----------------------+
|meta_size |
+----------------------+
|test type |
+----------------------+
|fusa info |
+----------------------+
|total images |
+----------------------+
|current image# |
+----------------------+
|total chunks |
+----------------------+
|starting chunk |
+----------------------+
|size per chunk |
+----------------------+
|chunks per stride |
+----------------------+
|Reserved[54] |
+----------------------+ 256
| |
| Test Data/Chunks |
| |
+----------------------+ meta_size
| META_TYPE_END (=0) |
+----------------------+ meta_size + 4
| size of end (=8) |
+----------------------+ meta_size + 8
Introduce the layout of this meta_data structure and validate
the sanity of certain fields of the new image before loading.
Tweak references to IFS test image chunks to reflect the updated
layout of the test image.
[ bp: Massage commit message. ]
Signed-off-by: Jithu Joseph <jithu.joseph@intel.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Reviewed-by: Tony Luck <tony.luck@intel.com>
Reviewed-by: Sohil Mehta <sohil.mehta@intel.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20221117230408.30331-1-jithu.joseph@intel.com
Existing implementation (broken) of IFS used a header format (for IFS
test images) which was very similar to microcode format, but didn’t
accommodate extended signatures. This meant same IFS test image had to
be duplicated for different steppings and the validation code in the
driver was only looking at the primary header parameters. Going forward,
IFS test image headers have been tweaked to become fully compatible with
the microcode format.
Newer IFS test image headers will use header version 2 in order to
distinguish it from microcode images and older IFS test images.
In light of the above, reuse struct microcode_header_intel directly in
the IFS driver and reuse microcode functions for validation and sanity
checking.
[ bp: Massage commit message. ]
Signed-off-by: Jithu Joseph <jithu.joseph@intel.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Reviewed-by: Tony Luck <tony.luck@intel.com>
Reviewed-by: Sohil Mehta <sohil.mehta@intel.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20221117225039.30166-1-jithu.joseph@intel.com
One of the existing reserved fields in the microcode header has been
allocated to indicate the size of metadata structures.
The location of metadata section within microcode header is as shown
below:
Microcode Blob Format
+----------------------+ Base
|Header Version |
+----------------------+
|Update revision |
+----------------------+
|Date DDMMYYYY |
+----------------------+
|Sig |
+----------------------+
|Checksum |
+----------------------+
|Loader Version |
+----------------------+
|Processor Flags |
+----------------------+
|Data Size |
+----------------------+
|Total Size |
+----------------------+
|Meta Size |
+----------------------+
|Reserved |
+----------------------+
|Reserved |
+----------------------+ Base+48
| |
| Microcode |
| Data |
| |
+----------------------+ Base+48+data_size-
| | meta_size
| Meta Data |
| structure(s) |
| |
+----------------------+ Base+48+data_size
| |
| Extended Signature |
| Table |
| |
+----------------------+ Base+total_size
Add an accessor function which will return a pointer to the start of a
specific meta_type being queried.
[ bp: Massage commit message. ]
Signed-off-by: Ashok Raj <ashok.raj@intel.com>
Signed-off-by: Jithu Joseph <jithu.joseph@intel.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Reviewed-by: Tony Luck <tony.luck@intel.com>
Reviewed-by: Sohil Mehta <sohil.mehta@intel.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20221117035935.4136738-11-jithu.joseph@intel.com
IFS requires tests to be authenticated once for each CPU socket on a
system.
scan_chunks_sanity_check() was dynamically allocating memory to store
the state of whether tests have been authenticated on each socket for
every load operation.
Move the memory allocation to init path and store the pointer in
ifs_data struct.
Also rearrange the adjacent error checking in init for a more simplified
and natural flow.
Suggested-by: Borislav Petkov <bp@alien8.de>
Signed-off-by: Jithu Joseph <jithu.joseph@intel.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Reviewed-by: Tony Luck <tony.luck@intel.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20221117195957.28225-1-jithu.joseph@intel.com
Pull x86 platform driver fixes from Hans de Goede:
- Surface Pro 9 and Surface Laptop 5 kbd, battery, etc support (this
is just a few hw-id additions)
- A couple of other hw-id / DMI-quirk additions
- A few small bug fixes + 1 build fix
* tag 'platform-drivers-x86-v6.1-4' of git://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86:
platform/x86: ideapad-laptop: Add module parameters to match DMI quirk tables
platform/x86: ideapad-laptop: Fix interrupt storm on fn-lock toggle on some Yoga laptops
platform/x86: hp-wmi: Ignore Smart Experience App event
platform/surface: aggregator_registry: Add support for Surface Laptop 5
platform/surface: aggregator_registry: Add support for Surface Pro 9
platform/surface: aggregator: Do not check for repeated unsequenced packets
platform/x86: acer-wmi: Enable SW_TABLET_MODE on Switch V 10 (SW5-017)
platform/x86: asus-wmi: add missing pci_dev_put() in asus_wmi_set_xusb2pr()
platform/x86/intel: pmc: Don't unconditionally attach Intel PMC when virtualized
platform/x86: thinkpad_acpi: Enable s2idle quirk for 21A1 machine type
platform/x86/amd: pmc: Add new ACPI ID AMDI0009
platform/x86/amd: pmc: Remove more CONFIG_DEBUG_FS checks
