summaryrefslogtreecommitdiff
path: root/drivers/platform/chrome
AgeCommit message (Collapse)AuthorFilesLines
2023-04-24platform/chrome: cros_ec: Separate logic for getting panic infoRob Barnes1-9/+33
Create a separate function called cros_ec_get_panicinfo for getting panic info from EC. Currently cros_ec_create_panicinfo is the only caller. Signed-off-by: Rob Barnes <robbarnes@google.com> Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org> Link: https://lore.kernel.org/r/20230410165817.932449-1-robbarnes@google.com
2023-04-24platform/chrome: cros_typec_switch: Add missing fwnode_handle_put()Liang He1-0/+1
In cros_typec_register_switches(), we should add fwnode_handle_put() when break out of the iteration device_for_each_child_node() as it will automatically increase and decrease the refcounter. Fixes: affc804c44c8 ("platform/chrome: cros_typec_switch: Add switch driver") Signed-off-by: Liang He <windhl@126.com> Link: https://lore.kernel.org/r/20230322041657.1857001-1-windhl@126.com Signed-off-by: Prashant Malani <pmalani@chromium.org>
2023-04-24platform/chrome: cros_ec: remove unneeded label and if-conditionTzung-Bi Shih1-6/+4
Both `ec_dev->ec` and `ec_dev->pd` are initialized to NULL at the beginning of cros_ec_register(). Also, platform_device_unregister() takes care if the given platform_device is NULL. Remove the unneeded goto-label and if-condition. Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org> Reviewed-by: Guenter Roeck <groeck@chromium.org> Link: https://lore.kernel.org/r/20230308031247.2866401-1-tzungbi@kernel.org
2023-04-03Merge 6.3-rc5 into driver-core-nextGreg Kroah-Hartman1-1/+1
We need the fixes in here for testing, as well as the driver core changes for documentation updates to build on. Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-03-24platform/chrome: cros_ec_chardev: fix kernel data leak from ioctlTzung-Bi Shih1-1/+1
It is possible to peep kernel page's data by providing larger `insize` in struct cros_ec_command[1] when invoking EC host commands. Fix it by using zeroed memory. [1]: https://elixir.bootlin.com/linux/v6.2/source/include/linux/platform_data/cros_ec_proto.h#L74 Fixes: eda2e30c6684 ("mfd / platform: cros_ec: Miscellaneous character device to talk with the EC") Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org> Reviewed-by: Guenter Roeck <groeck@chromium.org> Link: https://lore.kernel.org/r/20230324010658.1082361-1-tzungbi@kernel.org
2023-03-17drivers: remove struct module * setting from struct classGreg Kroah-Hartman2-2/+0
There is no need to manually set the owner of a struct class, as the registering function does it automatically, so remove all of the explicit settings from various drivers that did so as it is unneeded. This allows us to remove this pointer entirely from this structure going forward. Cc: "Rafael J. Wysocki" <rafael@kernel.org> Link: https://lore.kernel.org/r/20230313181843.1207845-2-gregkh@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-02-08platform/chrome: cros_ec_typec: Fix spelling mistakeColin Ian King1-1/+1
There is a spelling mistake in a dev_warn message, make it lower case and fix the spelling. Signed-off-by: Colin Ian King <colin.i.king@gmail.com> Reviewed-by: Tzung-Bi Shih <tzungbi@kernel.org> Reviewed-by: Guenter Roeck <groeck@chromium.org> Link: https://lore.kernel.org/r/20230207091443.143995-1-colin.i.king@gmail.com Signed-off-by: Prashant Malani <pmalani@chromium.org> [pmalani fixed up commit message based on tzungbi comment]
2023-01-31platform/chrome: cros_typec_vdm: Add Attention supportPrashant Malani3-0/+49
Add support to retrieve VDM attention messages and forward them to the appropriate alt mode driver. Signed-off-by: Prashant Malani <pmalani@chromium.org> Reviewed-by: Benson Leung <bleung@chromium.org> Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Link: https://lore.kernel.org/r/20230126205620.3714994-2-pmalani@chromium.org
2023-01-24platform/chrome: cros_typec_vdm: Fix VDO copyPrashant Malani1-1/+3
The usage of memcpy() affects the representation of the VDOs as they are copied to the EC Host Command buffer. Specifically, all higher order bits get dropped (for example: a VDO of 0x406 just gets copied as 0x6). Avoid this by explicitly copying each VDO in the array. The number of VDOs generated by alternate mode drivers in their VDMs is almost always just 1 (apart from the header) so this doesn't affect performance in a meaningful way). Fixes: 40a9b13a09ef ("platform/chrome: cros_typec_vdm: Add VDM send support") Signed-off-by: Prashant Malani <pmalani@chromium.org> Reviewed-by: Benson Leung <bleung@chromium.org> Link: https://lore.kernel.org/r/20230113182626.1149539-1-pmalani@chromium.org Signed-off-by: Prashant Malani <pmalani@chromium.org>
2023-01-24platform/chrome: cros_ec_typec: allow deferred probe of switch handlesVictor Ding1-8/+16
`fwnode_typec_{retimer,mux,switch}_get()` could return `-EPROBE_DEFER`, which is called from `cros_typec_get_switch_handles`. When this happens, it does not indicate absence of switches; instead, it only hints that probing of switches should occur at a later time. Progagate `-EPROBE_DEFER` to upper layer logic so that they can re-try probing switches as a better time. Signed-off-by: Victor Ding <victording@chromium.org> Reviewed-by: Benson Leung <bleung@chromium.org> Reviewed-by: Guenter Roeck <groeck@chromium.org> Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Link: https://lore.kernel.org/r/20230124075555.v3.1.I6c0a089123fdf143f94ef4cca8677639031856cf@changeid Signed-off-by: Prashant Malani <pmalani@chromium.org>
2023-01-18platform/chrome: cros_ec_proto: remove big stub objects from stackTzung-Bi Shih1-5/+5
sizeof(struct device) = 680 sizeof(struct cros_ec_dev) = 720 They tend to exceed the stack frame size limit in some specific environment which results in the following compilation error: >> drivers/platform/chrome/cros_ec_proto_test.c:2530:13: error: stack frame size (2128) exceeds limit (2048) in 'cros_ec_proto_test_get_sensor_count_legacy' Remove the big stub objects from stack. This is: $ sed -i 's/struct cros_ec_dev /static struct cros_ec_dev /' \ drivers/platform/chrome/cros_ec_proto_test.c Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org> Reviewed-by: Guenter Roeck <linux@roeck-us.net> Link: https://lore.kernel.org/r/20230117080254.2725536-1-tzungbi@kernel.org
2023-01-18platform/chrome: cros_ec_uart: fix negative type promoted to highTzung-Bi Shih1-2/+3
serdev_device_write_buf() returns negative numbers on errors. When the return value compares to unsigned integer `len`, it promotes to quite large positive number. Fix it. Fixes: 04a8bdd135cc ("platform/chrome: cros_ec_uart: Add transport layer") Reported-by: Dan Carpenter <error27@gmail.com> Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org> Reviewed-by: Dan Carpenter <dan.carpenter@oracle.com> Reviewed-by: Benson Leung <bleung@chromium.org> Link: https://lore.kernel.org/r/20230109081554.3792547-1-tzungbi@kernel.org
2023-01-13platform/chrome: cros_ec: Use per-device lockdep keyChen-Yu Tsai1-3/+11
Lockdep reports a bogus possible deadlock on MT8192 Chromebooks due to the following lock sequences: 1. lock(i2c_register_adapter) [1]; lock(&ec_dev->lock) 2. lock(&ec_dev->lock); lock(prepare_lock); The actual dependency chains are much longer. The shortened version looks somewhat like: 1. cros-ec-rpmsg on mtk-scp ec_dev->lock -> prepare_lock 2. In rt5682_i2c_probe() on native I2C bus: prepare_lock -> regmap->lock -> (possibly) i2c_adapter->bus_lock 3. In rt5682_i2c_probe() on native I2C bus: regmap->lock -> i2c_adapter->bus_lock 4. In sbs_probe() on i2c-cros-ec-tunnel I2C bus attached on cros-ec: i2c_adapter->bus_lock -> ec_dev->lock While lockdep is correct that the shared lockdep classes have a circular dependency, it is bogus because a) 2+3 happen on a native I2C bus b) 4 happens on the actual EC on ChromeOS devices c) 1 happens on the SCP coprocessor on MediaTek Chromebooks that just happens to expose a cros-ec interface, but does not have an i2c-cros-ec-tunnel I2C bus In short, the "dependencies" are actually on different devices. Setup a per-device lockdep key for cros_ec devices so lockdep can tell the two instances apart. This helps with getting rid of the bogus lockdep warning. For ChromeOS devices that only have one cros-ec instance this doesn't change anything. Also add a missing mutex_destroy, just to make the teardown complete. [1] This is likely the per I2C bus lock with shared lockdep class Signed-off-by: Chen-Yu Tsai <wenst@chromium.org> Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org> Link: https://lore.kernel.org/r/20230111074146.2624496-1-wenst@chromium.org
2023-01-13platform/chrome: fix kernel-doc warnings for panic notifierTzung-Bi Shih1-0/+2
Fix the following kernel-doc warnings: $ ./scripts/kernel-doc -none drivers/platform/chrome/* drivers/platform/chrome/cros_ec_debugfs.c:54: warning: Function parameter or member 'notifier_panic' not described in 'cros_ec_debugfs' $ ./scripts/kernel-doc -none include/linux/platform_data/cros_ec_proto.h include/linux/platform_data/cros_ec_proto.h:187: warning: Function parameter or member 'panic_notifier' not described in 'cros_ec_device' Cc: Rob Barnes <robbarnes@google.com> Fixes: d90fa2c64d59 ("platform/chrome: cros_ec: Poll EC log on EC panic") Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org> Reviewed-by: Guenter Roeck <groweck@chromium.org> Link: https://lore.kernel.org/r/20230111055728.708990-2-tzungbi@kernel.org
2023-01-11platform/chrome: cros_ec_lpc: initialize the buf variableTom Rix1-1/+1
Clang static analysis reports this problem drivers/platform/chrome/cros_ec_lpc.c:379:13: warning: The left operand of '!=' is a garbage value [core.UndefinedBinaryOperatorResult] if (buf[0] != 'E' || buf[1] != 'C') { ~~~~~~ ^ The check depends on the side effect of the read. When the read fails or is short, a buf containing garbage could be mistaken as correct. Signed-off-by: Tom Rix <trix@redhat.com> Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org> Link: https://lore.kernel.org/r/20230110193611.3573777-1-trix@redhat.com
2023-01-11platform/chrome: cros_ec: Fix panic notifier registrationMarek Szyprowski1-0/+1
Initialize panic notifier to avoid the following lockdep warning: INFO: trying to register non-static key. The code is fine but needs lockdep annotation, or maybe you didn't initialize this object before use? turning off the locking correctness validator. [...] Hardware name: Samsung Exynos (Flattened Device Tree) Workqueue: events_unbound async_run_entry_fn unwind_backtrace from show_stack [...] blocking_notifier_chain_register from cros_ec_debugfs_probe cros_ec_debugfs_probe from platform_probe Fixes: d90fa2c64d59 ("platform/chrome: cros_ec: Poll EC log on EC panic") Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> [tzungbi: trimmed the stack trace in commit message.] Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org> Link: https://lore.kernel.org/r/20230110221033.7441-1-m.szyprowski@samsung.com
2023-01-10platform/chrome: cros_typec_switch: Check for retimer flagPrashant Malani1-6/+8
Not all ports have retimers. Only register a retimer switch if the "retimer-switch" property is present for that port's mux device. Signed-off-by: Prashant Malani <pmalani@chromium.org> Reviewed-by: Benson Leung <bleung@chromium.org> Link: https://lore.kernel.org/r/20230104060846.112216-2-pmalani@chromium.org
2023-01-10platform/chrome: cros_typec_switch: Use fwnode* prop checkPrashant Malani1-1/+1
Using device_property_present() multiple times on an ACPI device leads to kernel panics on Chromebook systems. This happens when there is > 1 boolean property in an ACPI device which is created dynamically by the BIOS as part of SSDT[1] on Chromebook systems Since fwnode_* can handle simple device tree properties equally well, switch to using the fwnode_property_present() function version. This will avoid panics and make the usage consistent when we introduce a check for the 2nd property in a subsequent patch. [1] https://wiki.osdev.org/SSDT Signed-off-by: Prashant Malani <pmalani@chromium.org> Reviewed-by: Benson Leung <bleung@chromium.org> Link: https://lore.kernel.org/r/20230104060846.112216-1-pmalani@chromium.org
2023-01-09platform/chrome: cros_typec_vdm: Add VDM send supportPrashant Malani1-0/+24
Add support to send generic VDM messages from the alt mode driver to the partner (via the ChromeOS EC). The function introduced here is intended to be called by the alt mode driver (via the Type-C bus logic). Cc: Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by: Prashant Malani <pmalani@chromium.org> Reviewed-by: Benson Leung <bleung@chromium.org> Acked-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Link: https://lore.kernel.org/r/20221228004648.793339-11-pmalani@chromium.org
2023-01-09platform/chrome: cros_typec_vdm: Add VDM reply supportPrashant Malani3-0/+48
Handle response VDMs which are sent by the partner (replying to VDMs sent by the host system itself). These get forwarded to the altmode driver. Cc: Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by: Prashant Malani <pmalani@chromium.org> Reviewed-by: Benson Leung <bleung@chromium.org> Acked-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Link: https://lore.kernel.org/r/20221228004648.793339-10-pmalani@chromium.org
2023-01-09platform/chrome: cros_ec_typec: Add initial VDM supportPrashant Malani4-1/+57
Add ops to support USB PD VDM (Vendor Defined Message) from the port driver. This enables the port driver to interface with alternate mode drivers and communicate with connected peripherals. The initial support just contains an implementation of the Enter Mode command. Cc: Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by: Prashant Malani <pmalani@chromium.org> [pmalani: Fixed trivial conflict in Makefile] Reviewed-by: Benson Leung <bleung@chromium.org> Acked-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Link: https://lore.kernel.org/r/20221228004648.793339-9-pmalani@chromium.org
2023-01-09platform/chrome: cros_ec_typec: Alter module name with hyphensPrashant Malani2-2/+3
Change the Type-C module name from cros_ec_typec to cros-ec-typec. This allows us to include more files in the same module (rather than relying on the file name cros_ec_typec to also be the module name). Signed-off-by: Prashant Malani <pmalani@chromium.org> [pmalani: Fixed trivial conflict in Makefile] Reviewed-by: Benson Leung <bleung@chromium.org> Acked-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Link: https://lore.kernel.org/r/20221228004648.793339-8-pmalani@chromium.org
2023-01-09platform/chrome: cros_ec_typec: Move structs to headerPrashant Malani2-76/+87
Move ChromeOS Type-C structs into their own header, so they can be referenced by other files which can be added to the same module. No functional changes introduced by this patch. Signed-off-by: Prashant Malani <pmalani@chromium.org> Reviewed-by: Benson Leung <bleung@chromium.org> Acked-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Link: https://lore.kernel.org/r/20221228004648.793339-7-pmalani@chromium.org
2023-01-09platform/chrome: cros_ec_typec: Update port DP VDOPrashant Malani1-1/+1
The port advertising DP support is a Type-C receptacle. Fix the port's DisplayPort VDO to reflect this. Fixes: 1903adae0464 ("platform/chrome: cros_ec_typec: Add bit offset for DP VDO") Signed-off-by: Prashant Malani <pmalani@chromium.org> Reviewed-by: Benson Leung <bleung@chromium.org> Acked-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Link: https://lore.kernel.org/r/20221228004648.793339-6-pmalani@chromium.org
2023-01-09platform/chrome: cros_ec_typec: Set port alt mode drvdataPrashant Malani1-0/+2
Save the ChromeOS-specific Type-C port info in the port altmodes' driver data. This makes communication with the ChromeOS EC (Embedded Controller) easier when alt mode drivers need to send messages to peripherals. Cc: Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by: Prashant Malani <pmalani@chromium.org> Reviewed-by: Benson Leung <bleung@chromium.org> Acked-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Link: https://lore.kernel.org/r/20221228004648.793339-5-pmalani@chromium.org
2023-01-09platform/chrome: cros_ec_typec: Stash port driver infoPrashant Malani1-0/+5
Stash port number and a pointer to the driver-specific struct in the local typec port struct. These can be useful to the port driver to figure out how to communicate with the Chrome EC when an altmode-driver related callback is invoked from the Type-C class code. Signed-off-by: Prashant Malani <pmalani@chromium.org> Reviewed-by: Benson Leung <bleung@chromium.org> Acked-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Link: https://lore.kernel.org/r/20221228004648.793339-4-pmalani@chromium.org
2023-01-06platform/chrome: cros_ec: Shutdown on EC PanicRob Barnes1-0/+3
When an EC panic is reported, attempt an orderly shutdown. Force a shutdown after a brief timeout if the orderly shutdown fails for any reason. Using the common hw_protection_shutdown utility function since an EC panic has the potential to cause hw damage. This is all best effort. EC should also force a hard reset after a short timeout. Signed-off-by: Rob Barnes <robbarnes@google.com> Reviewed-by: Prashant Malani <pmalani@chromium.org> Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org> Link: https://lore.kernel.org/r/20230104011524.369764-3-robbarnes@google.com
2023-01-06platform/chrome: cros_ec: Poll EC log on EC panicRob Barnes2-0/+30
Add handler for CrOS EC panic events. When a panic is reported, immediately poll for EC log. This should result in the log leading to the EC panic being preserved. ACPI_NOTIFY_CROS_EC_PANIC is defined in coreboot at https://review.coreboot.org/plugins/gitiles/coreboot/+/refs/heads/master/src/ec/google/chromeec/acpi/ec.asl Signed-off-by: Rob Barnes <robbarnes@google.com> Reviewed-by: Prashant Malani <pmalani@chromium.org> Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org> Link: https://lore.kernel.org/r/20230104011524.369764-2-robbarnes@google.com
2023-01-05platform/chrome: cros_ec_proto: Use asm instead of asm-genericAndy Shevchenko1-1/+2
There is no point to specify asm-generic for the unaligned.h. Drop the 'generic' suffix. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Guenter Roeck <groeck@chromium.org> [tzungbi: s/intead/instead/ in commit title.] Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org> Link: https://lore.kernel.org/r/20230103145023.40055-1-andriy.shevchenko@linux.intel.com
2023-01-05platform/chrome: cros_ec_uart: fix race conditionRobert Zieba1-1/+2
serdev_device_set_client_ops() is called before `ec_dev` is fully initialized. This can result in cros_ec_uart_rx_bytes() being called while `ec_dev` is still not initialized, resulting in a kernel panic. Call serdev_device_set_client_ops() after `ec_dev` is initialized. Fixes: 04a8bdd135cc ("platform/chrome: cros_ec_uart: Add transport layer") Signed-off-by: Robert Zieba <robertzieba@google.com> [tzungbi: modified commit message and fixed context conflict.] Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org> Reviewed-by: Guenter Roeck <groeck@chromium.org> Link: https://lore.kernel.org/r/20221229094738.2304044-1-tzungbi@kernel.org
2023-01-05platform/chrome: cros_ec_uart: Add DT enumeration supportBhanu Prakash Maiya1-0/+8
Existing firmware uses the "PRP0001" _HID and an associated compatible string to enumerate the cros_ec_uart. Add DT enumeration support for already shipped firmware. Signed-off-by: Bhanu Prakash Maiya <bhanumaiya@chromium.org> Co-developed-by: Mark Hasemeyer <markhas@chromium.org> Signed-off-by: Mark Hasemeyer <markhas@chromium.org> Reviewed-by: Prashant Malani <pmalani@chromium.org> Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org> Link: https://lore.kernel.org/r/20221227123212.v13.3.Ie23c217d69ff25d7354db942613f143bbc8ef891@changeid
2022-12-28platform/chrome: cros_ec_uart: Add transport layerBhanu Prakash Maiya3-0/+363
This patch does following: 1. Adds a new cros-ec-uart driver. This driver can send EC requests on UART and process response packets received on UART transport. 2. Once probed, this driver will initialize the serdev device based on the underlying information in the ACPI resource. After serdev device properties are set, this driver will register itself cros-ec. 3. High level driver can use this implementation to talk to ChromeOS Embedded Controller device in case it supports UART as transport. 4. When cros-ec driver initiates a request packet, outgoing message is processed in buffer and sent via serdev. Once bytes are sent, driver enables a wait_queue. 5. Since ChromeOS EC device sends response asynchronously, AP's TTY driver accumulates response bytes and calls the registered callback. TTY driver can send multiple callback for bytes ranging from 1 to MAX bytes supported by EC device. 6. Driver waits for EC_MSG_DEADLINE_MS to collect and process received bytes. It wakes wait_queue if expected bytes are received or else wait_queue timeout. Based on the error condition, driver returns data_len or error to cros_ec. Signed-off-by: Bhanu Prakash Maiya <bhanumaiya@chromium.org> Co-developed-by: Mark Hasemeyer <markhas@chromium.org> Signed-off-by: Mark Hasemeyer <markhas@chromium.org> Reviewed-by: Prashant Malani <pmalani@chromium.org> Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org> Link: https://lore.kernel.org/r/20221227123212.v13.1.If7926fcbad397bc6990dd725690229bed403948c@changeid
2022-12-26platform/chrome: use sysfs_emit_at() instead of scnprintf()Tzung-Bi Shih1-22/+14
Follow the advice in Documentation/filesystems/sysfs.rst: show() should only use sysfs_emit() or sysfs_emit_at() when formatting the value to be returned to user space. Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org> Reviewed-by: Guenter Roeck <linux@roeck-us.net> Link: https://lore.kernel.org/r/20221205061042.1774769-1-tzungbi@kernel.org
2022-12-26platform/chrome: use sysfs_emit() instead of scnprintf()ye xingchen3-12/+9
Follow the advice in Documentation/filesystems/sysfs.rst: show() should only use sysfs_emit() or sysfs_emit_at() when formatting the value to be returned to user space. Signed-off-by: ye xingchen <ye.xingchen@zte.com.cn> Link: https://lore.kernel.org/r/202212021656040995199@zte.com.cn [tzungbi: fixed the commit message.] Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org>
2022-12-16Merge tag 'usb-6.2-rc1' of ↵Linus Torvalds1-1/+1
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb Pull USB and Thunderbolt driver updates from Greg KH: "Here is the large set of USB and Thunderbolt driver changes for 6.2-rc1. Overall, thanks to the removal of a driver, more lines were removed than added, a nice change. Highlights include: - removal of the sisusbvga driver that was not used by anyone anymore - minor thunderbolt driver changes and tweaks - chipidea driver updates - usual set of typec driver features and hardware support added - musb minor driver fixes - fotg210 driver fixes, bringing that hardware back from the "dead" - minor dwc3 driver updates - addition, and then removal, of a list.h helper function for many USB and other subsystem drivers, that ended up breaking the build. That will come back for 6.3-rc1, it missed this merge window. - usual xhci updates and enhancements - usb-serial driver updates and support for new devices - other minor USB driver updates All of these have been in linux-next for a while with no reported problems" * tag 'usb-6.2-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb: (153 commits) usb: gadget: uvc: Rename bmInterfaceFlags -> bmInterlaceFlags usb: dwc2: power on/off phy for peripheral mode in dual-role mode usb: dwc2: disable lpm feature on Rockchip SoCs dt-bindings: usb: mtk-xhci: add support for mt7986 usb: dwc3: core: defer probe on ulpi_read_id timeout usb: ulpi: defer ulpi_register on ulpi_read_id timeout usb: misc: onboard_usb_hub: add Genesys Logic GL850G hub support dt-bindings: usb: Add binding for Genesys Logic GL850G hub controller dt-bindings: vendor-prefixes: add Genesys Logic usb: fotg210-udc: fix potential memory leak in fotg210_udc_probe() usb: typec: tipd: Set mode of operation for USB Type-C connector usb: gadget: udc: drop obsolete dependencies on COMPILE_TEST usb: musb: remove extra check in musb_gadget_vbus_draw usb: gadget: uvc: Prevent buffer overflow in setup handler usb: dwc3: qcom: Fix memory leak in dwc3_qcom_interconnect_init usb: typec: wusb3801: fix fwnode refcount leak in wusb3801_probe() usb: storage: Add check for kcalloc USB: sisusbvga: use module_usb_driver() USB: sisusbvga: rename sisusb.c to sisusbvga.c USB: sisusbvga: remove console support ...
2022-12-13Merge tag 'acpi-6.2-rc1' of ↵Linus Torvalds2-5/+2
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm Pull ACPI and PNP updates from Rafael Wysocki: "These include new code (for instance, support for the FFH address space type and support for new firmware data structures in ACPICA), some new quirks (mostly related to backlight handling and I2C enumeration), a number of fixes and a fair amount of cleanups all over. Specifics: - Update the ACPICA code in the kernel to the 20221020 upstream version and fix a couple of issues in it: - Make acpi_ex_load_op() match upstream implementation (Rafael Wysocki) - Add support for loong_arch-specific APICs in MADT (Huacai Chen) - Add support for fixed PCIe wake event (Huacai Chen) - Add EBDA pointer sanity checks (Vit Kabele) - Avoid accessing VGA memory when EBDA < 1KiB (Vit Kabele) - Add CCEL table support to both compiler/disassembler (Kuppuswamy Sathyanarayanan) - Add a couple of new UUIDs to the known UUID list (Bob Moore) - Add support for FFH Opregion special context data (Sudeep Holla) - Improve warning message for "invalid ACPI name" (Bob Moore) - Add support for CXL 3.0 structures (CXIMS & RDPAS) in the CEDT table (Alison Schofield) - Prepare IORT support for revision E.e (Robin Murphy) - Finish support for the CDAT table (Bob Moore) - Fix error code path in acpi_ds_call_control_method() (Rafael Wysocki) - Fix use-after-free in acpi_ut_copy_ipackage_to_ipackage() (Li Zetao) - Update the version of the ACPICA code in the kernel (Bob Moore) - Use ZERO_PAGE(0) instead of empty_zero_page in the ACPI device enumeration code (Giulio Benetti) - Change the return type of the ACPI driver remove callback to void and update its users accordingly (Dawei Li) - Add general support for FFH address space type and implement the low- level part of it for ARM64 (Sudeep Holla) - Fix stale comments in the ACPI tables parsing code and make it print more messages related to MADT (Hanjun Guo, Huacai Chen) - Replace invocations of generic library functions with more kernel- specific counterparts in the ACPI sysfs interface (Christophe JAILLET, Xu Panda) - Print full name paths of ACPI power resource objects during enumeration (Kane Chen) - Eliminate a compiler warning regarding a missing function prototype in the ACPI power management code (Sudeep Holla) - Fix and clean up the ACPI processor driver (Rafael Wysocki, Li Zhong, Colin Ian King, Sudeep Holla) - Add quirk for the HP Pavilion Gaming 15-cx0041ur to the ACPI EC driver (Mia Kanashi) - Add some mew ACPI backlight handling quirks and update some existing ones (Hans de Goede) - Make the ACPI backlight driver prefer the native backlight control over vendor backlight control when possible (Hans de Goede) - Drop unsetting ACPI APEI driver data on remove (Uwe Kleine-König) - Use xchg_release() instead of cmpxchg() for updating new GHES cache slots (Ard Biesheuvel) - Clean up the ACPI APEI code (Sudeep Holla, Christophe JAILLET, Jay Lu) - Add new I2C device enumeration quirks for Medion Lifetab S10346 and Lenovo Yoga Tab 3 Pro (YT3-X90F) (Hans de Goede) - Make the ACPI battery driver notify user space about adding new battery hooks and removing the existing ones (Armin Wolf) - Modify the pfr_update and pfr_telemetry drivers to use ACPI_FREE() for freeing acpi_object structures to help diagnostics (Wang ShaoBo) - Make the ACPI fan driver use sysfs_emit_at() in its sysfs interface code (ye xingchen) - Fix the _FIF package extraction failure handling in the ACPI fan driver (Hanjun Guo) - Fix the PCC mailbox handling error code path (Huisong Li) - Avoid using PCC Opregions if there is no platform interrupt allocated for this purpose (Huisong Li) - Use sysfs_emit() instead of scnprintf() in the ACPI PAD driver and CPPC library (ye xingchen) - Fix some kernel-doc issues in the ACPI GSI processing code (Xiongfeng Wang) - Fix name memory leak in pnp_alloc_dev() (Yang Yingliang) - Do not disable PNP devices on suspend when they cannot be re-enabled on resume (Hans de Goede) - Clean up the ACPI thermal driver a bit (Rafael Wysocki)" * tag 'acpi-6.2-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: (67 commits) ACPI: x86: Add skip i2c clients quirk for Medion Lifetab S10346 ACPI: APEI: EINJ: Refactor available_error_type_show() ACPI: APEI: EINJ: Fix formatting errors ACPI: processor: perflib: Adjust acpi_processor_notify_smm() return value ACPI: processor: perflib: Rearrange acpi_processor_notify_smm() ACPI: processor: perflib: Rearrange unregistration routine ACPI: processor: perflib: Drop redundant parentheses ACPI: processor: perflib: Adjust white space ACPI: processor: idle: Drop unnecessary statements and parens ACPI: thermal: Adjust critical.flags.valid check ACPI: fan: Convert to use sysfs_emit_at() API ACPICA: Fix use-after-free in acpi_ut_copy_ipackage_to_ipackage() ACPI: battery: Call power_supply_changed() when adding hooks ACPI: use sysfs_emit() instead of scnprintf() ACPI: x86: Add skip i2c clients quirk for Lenovo Yoga Tab 3 Pro (YT3-X90F) ACPI: APEI: Remove a useless include PNP: Do not disable devices on suspend when they cannot be re-enabled on resume ACPI: processor: Silence missing prototype warnings ACPI: processor_idle: Silence missing prototype warnings ACPI: PM: Silence missing prototype warning ...
2022-12-08platform/chrome: cros_ec_typec: zero out stale pointersVictor Ding1-0/+3
`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: f28adb41dab4 ("platform/chrome: cros_ec_typec: Register Type C switches") Fixes: 1a8912caba02 ("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
2022-11-29platform/chrome: cros_ec_typec: Set parent of partner PD objectPrashant Malani1-1/+1
In order to tell what Type-C device a PD object belongs to, its parent needs to be set. Use the Type-C partner USB PD registration wrapper to set the parent appropriately for PD objects which are created for connected Type-C partners. Cc: Benson Leung <bleung@chromium.org> Cc: Heikki Krogerus <heikki.krogerus@linux.intel.com> Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by: Prashant Malani <pmalani@chromium.org> Link: https://lore.kernel.org/r/20221122220538.2991775-3-pmalani@chromium.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-11-25platform/chrome: cros_usbpd_notify: Fix error handling in ↵Yuan Can1-1/+5
cros_usbpd_notify_init() 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: ec2daf6e33f9 ("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>
2022-11-23ACPI: make remove callback of ACPI driver voidDawei Li2-5/+2
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 fc7a6209d571 ("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>
2022-11-19platform/chrome: cros_ec: Convert to i2c's .probe_new()Uwe Kleine-König1-3/+2
The probe function doesn't make use of the i2c_device_id * parameter so it can be trivially converted. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Reviewed-by: Guenter Roeck <groeck@chromium.org> Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org> Link: https://lore.kernel.org/r/20221118224540.619276-513-uwe@kleine-koenig.org
2022-11-14platform/chrome: cros_ec_lpc: Force synchronous probeBrian Norris1-1/+6
This reverts commit bd88b965ae8c ("platform/chrome: cros_ec_lpc: Mark PROBE_PREFER_ASYNCHRONOUS"), and then some. It has been reported that there are issues with 'cros-ec-keyb' devices that are children of this. As noted in the initial patch for its ACPI support (commit ba0f32141bc5 ("Input: cros_ec_keyb - handle x86 detachable/convertible Chromebooks")), it's possible to probe an ACPI child device before its parent is probed -- hence the need for EPROBE_DEFER. Unfortunately, poking your parent's dev_get_drvdata() isn't safe with asynchronous probe, as there's no locking, and the ordering is all wrong anyway (drvdata is set before the device is *really* ready). Because this parent/child relationship has known issues, let's go the other direction and force synchronous probe, until we resolve the issues. Possible solutions involve adding device links, so we ensure the child doesn't probe before the parent is done; or perhaps some other larger refactoring (auxiliary bus?). But that might take a little more effort and review, as there are many other potential sub-devices of cros_ec_lpc that could need patching. Note that we don't have the same problem for non-ACPI cros-ec hosts, like cros-ec-spi (commit 015e4b05c377 ("platform/chrome: cros_ec_spi: Set PROBE_PREFER_ASYNCHRONOUS")), because its sub-devices aren't created until cros_ec_register(), or they don't exist at all (e.g., FPMCU uses). Fixes: bd88b965ae8c ("platform/chrome: cros_ec_lpc: Mark PROBE_PREFER_ASYNCHRONOUS") Signed-off-by: Brian Norris <briannorris@chromium.org> Reviewed-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Reviewed-by: Guenter Roeck <groeck@chromium.org> Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org> Link: https://lore.kernel.org/r/20221111231302.3458191-1-briannorris@chromium.org
2022-11-02platform/chrome: cros_ec_spi: Set PROBE_PREFER_ASYNCHRONOUSBrian Norris1-0/+1
This driver often takes on the order of 10ms to start, but in some cases as much as 600ms [1]. It shouldn't have many cross-device dependencies to race with, nor racy access to shared state with other drivers, so this should be a relatively low risk change. This driver was pinpointed as part of a survey of top slowest initcalls (i.e., are built in, and probing synchronously) on a lab of ChromeOS systems. [1] 600ms was especially surprising to me, so I checked a little deeper. This driver is used to interface with Embedded Controllers besides just the traditional laptop power-state controller -- it also interfaces with some fingerprint readers, which may start up in parallel with the kernel, or which may not even be present on some SKUs, despite having a node for it. Thus, our time is wasted just timing out talking to it. At least we can do that without blocking everyone else. Signed-off-by: Brian Norris <briannorris@chromium.org> Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org> Link: https://lore.kernel.org/r/20221101152132.v2.5.Ia458a69e1d592bfa4f04cde7018bbc7486f91a23@changeid
2022-11-02platform/chrome: cros_ec_lightbar: Set PROBE_PREFER_ASYNCHRONOUSBrian Norris1-0/+1
This driver takes on the order of 15ms to start on some systems. Even on systems where there is no lightbar support, it can take a few milliseconds just to probe the EC for support. It shouldn't have many cross-device dependencies to race with, nor racy access to shared state with other drivers, so this should be a relatively low risk change. This driver was pinpointed as part of a survey of top slowest initcalls (i.e., are built in, and probing synchronously) on a lab of ChromeOS systems. Signed-off-by: Brian Norris <briannorris@chromium.org> Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org> Link: https://lore.kernel.org/r/20221101152132.v2.4.I565598102e0bfb03bdf8c090d3bfdf954d026bc5@changeid
2022-11-02platform/chrome: cros_ec_debugfs: Set PROBE_PREFER_ASYNCHRONOUSBrian Norris1-0/+1
This driver takes on the order of 40ms to start on some systems. It shouldn't have many cross-device dependencies to race with, nor racy access to shared state with other drivers, so this should be a relatively low risk change. This driver was pinpointed as part of a survey of top slowest initcalls (i.e., are built in, and probing synchronously) on a lab of ChromeOS systems. Signed-off-by: Brian Norris <briannorris@chromium.org> Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org> Link: https://lore.kernel.org/r/20221101152132.v2.3.Ic9a4f378f73319da323cd55940012fa6b1de24f4@changeid
2022-11-02platform/chrome: cros_ec_lpc: Mark PROBE_PREFER_ASYNCHRONOUSBrian Norris1-0/+1
This takes on the order of 60ms to probe on some systems, so let it probe asynchronously. It shouldn't have any dependencies that aren't handled cleanly. Signed-off-by: Brian Norris <briannorris@chromium.org> Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org> Link: https://lore.kernel.org/r/20221101152132.v2.2.Ib1036816e77aba71ebc16b71f7615c55d054689c@changeid
2022-11-02platform/chrome: cros_ec_lpc: Move mec_init to device probeBrian Norris1-3/+3
Disregarding the weird global state hiding in this cros_ec_lpc_mec_*() stuff, it belongs in device probe. We shouldn't assume we can access hardware resources when the device isn't attached to the driver. Signed-off-by: Brian Norris <briannorris@chromium.org> Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org> Link: https://lore.kernel.org/r/20221101152132.v2.1.I0728421299079b104710c202d5d7095b2674fd8c@changeid
2022-11-02platform/chrome: Use kstrtobool() instead of strtobool()Christophe JAILLET1-1/+2
strtobool() is the same as kstrtobool(). However, the latter is more used within the kernel. In order to remove strtobool() and slightly simplify kstrtox.h, switch to the other function name. While at it, include the corresponding header file (<linux/kstrtox.h>) Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org> Link: https://lore.kernel.org/r/8d66b4688c05a44b592a4d20e2660e9067163276.1667336095.git.christophe.jaillet@wanadoo.fr
2022-11-01platform/chrome: cros_ec_lpc_mec: remove cros_ec_lpc_mec_destroy()Tzung-Bi Shih4-21/+0
It's pointless (and invalid) to destroy a statically allocated mutex in cros_ec_lpc_mec_destroy(). Let's remove it. Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org> Reviewed-by: Guenter Roeck <groeck@chromium.org> Reviewed-by: Brian Norris <briannorris@chromium.org> Link: https://lore.kernel.org/r/20221031050657.3899359-1-tzungbi@kernel.org
2022-10-19platform/chrome: cros_hps_i2c: make remove callback return voidDan Callaghan1-3/+1
Commit ed5c2f5fd10d ("i2c: Make remove callback return void") changed the return type of the 'remove' callback to void, but this driver was originally written before that change landed. Update the remove callback to match. Fixes: 5f9952548d91 ("platform/chrome: add a driver for HPS") Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Dan Callaghan <dcallagh@chromium.org> Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org> Link: https://lore.kernel.org/r/20221018235237.2274969-1-dcallagh@chromium.org
generated by cgit v1.2.3 (git 2.39.0) at 2024-10-19 01:23:49 +0300