linux/drivers/platform/surface, branch v6.3

platform/surface: aggregator: Add missing fwnode_handle_put()

2023-03-22T14:23:03Z

In fwnode_for_each_child_node(), we should add fwnode_handle_put() when break out of the iteration fwnode_for_each_child_node() as it will automatically increase and decrease the refcounter. Fixes: fc622b3d36e6 ("platform/surface: Set up Surface Aggregator device registry") Signed-off-by: Liang He Reviewed-by: Maximilian Luz Link: https://lore.kernel.org/r/20230322033057.1855741-1-windhl@126.com Reviewed-by: Hans de Goede Signed-off-by: Hans de Goede

Merge tag 'driver-core-6.3-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core

2023-02-24T20:58:55Z

Pull driver core updates from Greg KH: "Here is the large set of driver core changes for 6.3-rc1. There's a lot of changes this development cycle, most of the work falls into two different categories: - fw_devlink fixes and updates. This has gone through numerous review cycles and lots of review and testing by lots of different devices. Hopefully all should be good now, and Saravana will be keeping a watch for any potential regression on odd embedded systems. - driver core changes to work to make struct bus_type able to be moved into read-only memory (i.e. const) The recent work with Rust has pointed out a number of areas in the driver core where we are passing around and working with structures that really do not have to be dynamic at all, and they should be able to be read-only making things safer overall. This is the contuation of that work (started last release with kobject changes) in moving struct bus_type to be constant. We didn't quite make it for this release, but the remaining patches will be finished up for the release after this one, but the groundwork has been laid for this effort. Other than that we have in here: - debugfs memory leak fixes in some subsystems - error path cleanups and fixes for some never-able-to-be-hit codepaths. - cacheinfo rework and fixes - Other tiny fixes, full details are in the shortlog All of these have been in linux-next for a while with no reported problems" [ Geert Uytterhoeven points out that that last sentence isn't true, and that there's a pending report that has a fix that is queued up - Linus ] * tag 'driver-core-6.3-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core: (124 commits) debugfs: drop inline constant formatting for ERR_PTR(-ERROR) OPP: fix error checking in opp_migrate_dentry() debugfs: update comment of debugfs_rename() i3c: fix device.h kernel-doc warnings dma-mapping: no need to pass a bus_type into get_arch_dma_ops() driver core: class: move EXPORT_SYMBOL_GPL() lines to the correct place Revert "driver core: add error handling for devtmpfs_create_node()" Revert "devtmpfs: add debug info to handle()" Revert "devtmpfs: remove return value of devtmpfs_delete_node()" driver core: cpu: don't hand-override the uevent bus_type callback. devtmpfs: remove return value of devtmpfs_delete_node() devtmpfs: add debug info to handle() driver core: add error handling for devtmpfs_create_node() driver core: bus: update my copyright notice driver core: bus: add bus_get_dev_root() function driver core: bus: constify bus_unregister() driver core: bus: constify some internal functions driver core: bus: constify bus_get_kset() driver core: bus: constify bus_register/unregister_notifier() driver core: remove private pointer from struct bus_type ...

platform/surface: Switch to use acpi_evaluate_dsm_typed()

2023-02-02T21:48:20Z

The acpi_evaluate_dsm_typed() provides a way to check the type of the object evaluated by _DSM call. Use it instead of open coded variant. Signed-off-by: Andy Shevchenko Reviewed-by: Maximilian Luz Link: https://lore.kernel.org/r/20230118093823.39679-1-andriy.shevchenko@linux.intel.com Reviewed-by: Hans de Goede Signed-off-by: Hans de Goede

platform/surface: aggregator: Rename top-level request functions to avoid ambiguities

2023-02-02T21:48:20Z

We currently have a struct ssam_request_sync and a function ssam_request_sync(). While this is valid C, there are some downsides to it. One of these is that current Sphinx versions (>= 3.0) cannot disambiguate between the two (see disucssion and pull request linked below). It instead emits a "WARNING: Duplicate C declaration" and links for the struct and function in the resulting documentation link to the same entry (i.e. both to either function or struct documentation) instead of their respective own entries. While we could just ignore that and wait for a fix, there's also a point to be made that the current naming can be somewhat confusing when searching (e.g. via grep) or trying to understand the levels of abstraction at play: We currently have struct ssam_request_sync and associated functions ssam_request_sync_[alloc|free|init|wait|...]() operating on this struct. However, function ssam_request_sync() is one abstraction level above this. Similarly, ssam_request_sync_with_buffer() is not a function operating on struct ssam_request_sync, but rather a sibling to ssam_request_sync(), both using the struct under the hood. Therefore, rename the top level request functions: ssam_request_sync() -> ssam_request_do_sync() ssam_request_sync_with_buffer() -> ssam_request_do_sync_with_buffer() ssam_request_sync_onstack() -> ssam_request_do_sync_onstack() Link: https://lore.kernel.org/all/085e0ada65c11da9303d07e70c510dc45f21315b.1656756450.git.mchehab@kernel.org/ Link: https://github.com/sphinx-doc/sphinx/pull/8313 Signed-off-by: Maximilian Luz Link: https://lore.kernel.org/r/20221220175608.1436273-2-luzmaximilian@gmail.com Reviewed-by: Hans de Goede Signed-off-by: Hans de Goede

platform/surface: aggregator_registry: Fix target-ID of base-hub

2023-02-02T21:48:20Z

The target ID of the base hub is currently set to KIP (keyboard/ peripherals). However, even though it manages such devices with the KIP target ID, the base hub itself is actually accessed via the SAM target ID. So set it accordingly. Note that the target ID of the hub can be chosen arbitrarily and does not directly correspond to any physical or virtual component of the EC. This change is only a code improvement intended for consistency and clarity, it does not fix an actual bug. Signed-off-by: Maximilian Luz Link: https://lore.kernel.org/r/20221202223327.690880-10-luzmaximilian@gmail.com Reviewed-by: Hans de Goede Signed-off-by: Hans de Goede

platform/surface: aggregator: Enforce use of target-ID enum in device ID macros

2023-02-02T21:48:20Z

Similar to the target category (TC), the target ID (TID) can be one value out of a small number of choices, given in enum ssam_ssh_tid. In the device ID macros, SSAM_SDEV() and SSAM_VDEV() we already use text expansion to, both, remove some textual clutter for the target category values and enforce that the value belongs to the known set. Now that we know the names for the target IDs, use the same trick for them as well. Also rename the SSAM_ANY_x macros to SSAM_SSH_x_ANY to better fit in. Signed-off-by: Maximilian Luz Acked-by: Sebastian Reichel Link: https://lore.kernel.org/r/20221202223327.690880-9-luzmaximilian@gmail.com Reviewed-by: Hans de Goede Signed-off-by: Hans de Goede

platform/surface: dtx: Use target-ID enum instead of hard-coding values

2023-02-02T21:48:20Z

Instead of hard-coding the target ID, use the respective enum ssam_ssh_tid value. Signed-off-by: Maximilian Luz Link: https://lore.kernel.org/r/20221202223327.690880-7-luzmaximilian@gmail.com Reviewed-by: Hans de Goede Signed-off-by: Hans de Goede

platform/surface: aggregator_tabletsw: Use target-ID enum instead of hard-coding values

2023-02-02T21:48:20Z

Instead of hard-coding the target ID, use the respective enum ssam_ssh_tid value. Signed-off-by: Maximilian Luz Link: https://lore.kernel.org/r/20221202223327.690880-6-luzmaximilian@gmail.com Reviewed-by: Hans de Goede Signed-off-by: Hans de Goede

platform/surface: aggregator_hub: Use target-ID enum instead of hard-coding values

2023-02-02T21:48:20Z

Instead of hard-coding the target ID, use the respective enum ssam_ssh_tid value. Signed-off-by: Maximilian Luz Link: https://lore.kernel.org/r/20221202223327.690880-5-luzmaximilian@gmail.com Reviewed-by: Hans de Goede Signed-off-by: Hans de Goede

platform/surface: aggregator: Add target and source IDs to command trace events

2023-02-02T21:48:20Z

Add command source and target IDs to trace events. Tracing support for the Surface Aggregator driver was originally implemented at a time when only two peers were known: Host and SAM. We now know that there are at least five, with three actively being used (Host, SAM, KIP; four with Debug if you want to count manually enabling that interface). So it makes sense to also explicitly name the peers involved when tracing. Signed-off-by: Maximilian Luz Link: https://lore.kernel.org/r/20221202223327.690880-4-luzmaximilian@gmail.com Reviewed-by: Hans de Goede Signed-off-by: Hans de Goede