- 09 Feb, 2023 12 commits
-
-
Greg Kroah-Hartman authored
Convert the bus_for_each_dev(), bus_find_device, and bus_for_each_drv() functions to use bus_to_subsys() and not use the back-pointer to the private structure. Cc: "Rafael J. Wysocki" <rafael@kernel.org> Link: https://lore.kernel.org/r/20230208111330.439504-13-gregkh@linuxfoundation.orgSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Greg Kroah-Hartman authored
Convert the bus_add_driver() and bus_remove_driver() functions to use bus_to_subsys() and not use the back-pointer to the private structure. Cc: "Rafael J. Wysocki" <rafael@kernel.org> Link: https://lore.kernel.org/r/20230208111330.439504-12-gregkh@linuxfoundation.orgSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Greg Kroah-Hartman authored
Convert the bus_register_notifier() and bus_unregister_notifier() public functions to use bus_to_subsys() and not use the back-pointer to the private structure as well as the bus_notify() function. Cc: "Rafael J. Wysocki" <rafael@kernel.org> Link: https://lore.kernel.org/r/20230208111330.439504-11-gregkh@linuxfoundation.orgSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Greg Kroah-Hartman authored
Convert the bus_get_kset() function function to use bus_to_subsys() and not use the back-pointer to the private structure. Cc: "Rafael J. Wysocki" <rafael@kernel.org> Link: https://lore.kernel.org/r/20230208111330.439504-10-gregkh@linuxfoundation.orgSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Greg Kroah-Hartman authored
Convert the subsys_interface_register and subsys_interface_unregister() functions to use bus_to_subsys() and not use the back-pointer to the private structure. This also requires changing the parameters on subsys_dev_iter_init() to iterate over the list properly. Cc: "Rafael J. Wysocki" <rafael@kernel.org> Link: https://lore.kernel.org/r/20230208111330.439504-9-gregkh@linuxfoundation.orgSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Greg Kroah-Hartman authored
Convert the bus_register() and bus_unregister() functions to use bus_to_subsys() and not use the back-pointer to the private structure. Because bus_add_groups() and bus_remove_groups() were only called in one place, remove those one-line-wrapper functions and call the real sysfs group function where it is needed instead, saving another layer of indirection. Cc: "Rafael J. Wysocki" <rafael@kernel.org> Link: https://lore.kernel.org/r/20230208111330.439504-8-gregkh@linuxfoundation.orgSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Greg Kroah-Hartman authored
Convert the bus_add_device(), bus_probe_device(), and bus_remove_device() functions to use bus_to_subsys() and not use the back-pointer to the private structure. Cc: "Rafael J. Wysocki" <rafael@kernel.org> Link: https://lore.kernel.org/r/20230208111330.439504-7-gregkh@linuxfoundation.orgSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Greg Kroah-Hartman authored
Convert the drivers_autoprobe show/store and uevent sysfs callbacks to use bus_to_subsys() and not use the back-pointer to the private structure. Cc: "Rafael J. Wysocki" <rafael@kernel.org> Link: https://lore.kernel.org/r/20230208111330.439504-6-gregkh@linuxfoundation.orgSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Greg Kroah-Hartman authored
bus_create_file() and bus_remove_file() can be made to take a constant bus pointer, as it should not be modifying anything in the bus structure. Make this change and move the functions to use the internal subsys_get/put() logic as well, to prevent the use of the back-pointer in struct bus_type. Cc: "Rafael J. Wysocki" <rafael@kernel.org> Link: https://lore.kernel.org/r/20230208111330.439504-5-gregkh@linuxfoundation.orgSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Greg Kroah-Hartman authored
All of the bus find and iterator functions do not modify the struct bus_type passed to them, so mark them as constant to enforce this rule. Cc: "Rafael J. Wysocki" <rafael@kernel.org> Link: https://lore.kernel.org/r/20230208111330.439504-4-gregkh@linuxfoundation.orgSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Greg Kroah-Hartman authored
In the quest to make 'struct bus_type' constant and in read-only memory, we need to stop using the private pointer to the subsys_private structure. First step in doing this is to create a helper function that turns a 'struct bus_type' into 'struct subsys_private' called bus_to_subsys(). bus_to_subsys() walks the list of registered busses in the system and finds the matching one based on the pointer to the bus_type itself. As this is a short list, and this function is not on any fast path, it should not be noticable. Implement bus_get() and bus_put() using this new helper function. Cc: "Rafael J. Wysocki" <rafael@kernel.org> Link: https://lore.kernel.org/r/20230208111330.439504-3-gregkh@linuxfoundation.orgSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Greg Kroah-Hartman authored
We need to control the reference count of the subsys private structure instead of directly manipulating the kset reference count of it, so wrap that logic up in a subsys_get() and subsys_put() function to make it more obvious as to what is happening. Cc: "Rafael J. Wysocki" <rafael@kernel.org> Link: https://lore.kernel.org/r/20230208111330.439504-2-gregkh@linuxfoundation.orgSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 08 Feb, 2023 21 commits
-
-
Saravana Kannan authored
These "nvmem-cells" platform devices never get probed because there's no platform driver for it and it's never used anywhere else. So it's a waste of memory. These devices also cause fw_devlink to block nvmem consumers of "nvmem-cells" partition from probing because the supplier device never probes. So stop creating platform devices for nvmem-cells partitions to avoid wasting memory and to avoid blocking probing of consumers. Reported-by: Maxim Kiselev <bigunclemax@gmail.com> Fixes: bcdf0315 ("mtd: call of_platform_populate() for MTD partitions") Signed-off-by: Saravana Kannan <saravanak@google.com> Tested-by: Maksim Kiselev <bigunclemax@gmail.com> Tested-by: Douglas Anderson <dianders@chromium.org> Tested-by: Geert Uytterhoeven <geert+renesas@glider.be> Tested-by: Luca Weiss <luca.weiss@fairphone.com> # qcom/sm7225-fairphone-fp4 Link: https://lore.kernel.org/r/20230207014207.1678715-13-saravanak@google.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Saravana Kannan authored
This allows fw_devlink to track and enforce supplier-consumer dependencies for scmi_device. Signed-off-by: Saravana Kannan <saravanak@google.com> Acked-by: Sudeep Holla <sudeep.holla@arm.com> Tested-by: Colin Foster <colin.foster@in-advantage.com> Tested-by: Sudeep Holla <sudeep.holla@arm.com> Tested-by: Douglas Anderson <dianders@chromium.org> Tested-by: Geert Uytterhoeven <geert+renesas@glider.be> Tested-by: Luca Weiss <luca.weiss@fairphone.com> # qcom/sm7225-fairphone-fp4 Link: https://lore.kernel.org/r/20230207014207.1678715-12-saravanak@google.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Saravana Kannan authored
Since this device is only partially initialized by the irqchip driver, we need to mark the fwnode device as not initialized. This is to let fw_devlink know that the device will be completely initialized at a later point. That way, fw_devlink will continue to defer the probe of the power domain consumers till the power domain driver successfully binds to the struct device and completes the initialization of the device. Signed-off-by: Saravana Kannan <saravanak@google.com> Tested-by: Douglas Anderson <dianders@chromium.org> Tested-by: Geert Uytterhoeven <geert+renesas@glider.be> Tested-by: Luca Weiss <luca.weiss@fairphone.com> # qcom/sm7225-fairphone-fp4 Link: https://lore.kernel.org/r/20230207014207.1678715-11-saravanak@google.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Saravana Kannan authored
The driver core now: - Has the parent device of a supplier pick up the consumers if the supplier never has a device created for it. - Ignores a supplier if the supplier has no parent device and will never be probed by a driver And already prevents creating a device link with the consumer as a supplier of a parent. So, we no longer need to find the "compatible" node of the supplier or do any other checks in of_link_to_phandle(). We simply need to make sure that the supplier is available in DT. Signed-off-by: Saravana Kannan <saravanak@google.com> Tested-by: Colin Foster <colin.foster@in-advantage.com> Tested-by: Sudeep Holla <sudeep.holla@arm.com> Tested-by: Douglas Anderson <dianders@chromium.org> Tested-by: Geert Uytterhoeven <geert+renesas@glider.be> Tested-by: Luca Weiss <luca.weiss@fairphone.com> # qcom/sm7225-fairphone-fp4 Link: https://lore.kernel.org/r/20230207014207.1678715-10-saravanak@google.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Saravana Kannan authored
fw_devlink could only detect a single and simple cycle because it relied mainly on device link cycle detection code that only checked for cycles between devices. The expectation was that the firmware wouldn't have complicated cycles and multiple cycles between devices. That expectation has been proven to be wrong. For example, fw_devlink could handle: +-+ +-+ |A+------> |B+ +-+ +++ ^ | | | +----------+ But it couldn't handle even something as "simple" as: +---------------------+ | | v | +-+ +-+ +++ |A+------> |B+------> |C| +-+ +++ +-+ ^ | | | +----------+ But firmware has even more complicated cycles like: +---------------------+ | | v | +-+ +---+ +++ +--+A+------>| B +-----> |C|<--+ | +-+ ++--+ +++ | | ^ | ^ | | | | | | | | | +---------+ +---------+ | | | +------------------------------+ And this is without including parent child dependencies or nodes in the cycle that are just firmware nodes that'll never have a struct device created for them. The proper way to treat these devices it to not force any probe ordering between them, while still enforce dependencies between node in the cycles (A, B and C) and their consumers. So this patch goes all out and just deals with all types of cycles. It does this by: 1. Following dependencies across device links, parent-child and fwnode links. 2. When it find cycles, it mark the device links and fwnode links as such instead of just deleting them or making the indistinguishable from proxy SYNC_STATE_ONLY device links. This way, when new nodes get added, we can immediately find and mark any new cycles whether the new node is a device or firmware node. Fixes: 2de9d8e0 ("driver core: fw_devlink: Improve handling of cyclic dependencies") Signed-off-by: Saravana Kannan <saravanak@google.com> Tested-by: Colin Foster <colin.foster@in-advantage.com> Tested-by: Sudeep Holla <sudeep.holla@arm.com> Tested-by: Douglas Anderson <dianders@chromium.org> Tested-by: Geert Uytterhoeven <geert+renesas@glider.be> Tested-by: Luca Weiss <luca.weiss@fairphone.com> # qcom/sm7225-fairphone-fp4 Link: https://lore.kernel.org/r/20230207014207.1678715-9-saravanak@google.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Saravana Kannan authored
Consolidate the code that computes the flags to be used when creating a device link from a fwnode link. Fixes: 2de9d8e0 ("driver core: fw_devlink: Improve handling of cyclic dependencies") Signed-off-by: Saravana Kannan <saravanak@google.com> Tested-by: Colin Foster <colin.foster@in-advantage.com> Tested-by: Sudeep Holla <sudeep.holla@arm.com> Tested-by: Douglas Anderson <dianders@chromium.org> Tested-by: Geert Uytterhoeven <geert+renesas@glider.be> Tested-by: Luca Weiss <luca.weiss@fairphone.com> # qcom/sm7225-fairphone-fp4 Link: https://lore.kernel.org/r/20230207014207.1678715-8-saravanak@google.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Saravana Kannan authored
To improve detection and handling of dependency cycles, we need to be able to mark fwnode links as being part of cycles. fwnode links marked as being part of a cycle should not block their consumers from probing. Fixes: 2de9d8e0 ("driver core: fw_devlink: Improve handling of cyclic dependencies") Signed-off-by: Saravana Kannan <saravanak@google.com> Tested-by: Colin Foster <colin.foster@in-advantage.com> Tested-by: Sudeep Holla <sudeep.holla@arm.com> Tested-by: Douglas Anderson <dianders@chromium.org> Tested-by: Geert Uytterhoeven <geert+renesas@glider.be> Tested-by: Luca Weiss <luca.weiss@fairphone.com> # qcom/sm7225-fairphone-fp4 Link: https://lore.kernel.org/r/20230207014207.1678715-7-saravanak@google.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Saravana Kannan authored
fw_devlink uses DL_FLAG_SYNC_STATE_ONLY device link flag for two purposes: 1. To allow a parent device to proxy its child device's dependency on a supplier so that the supplier doesn't get its sync_state() callback before the child device/consumer can be added and probed. In this usage scenario, we need to ignore cycles for ensure correctness of sync_state() callbacks. 2. When there are dependency cycles in firmware, we don't know which of those dependencies are valid. So, we have to ignore them all wrt probe ordering while still making sure the sync_state() callbacks come correctly. However, when detecting dependency cycles, there can be multiple dependency cycles between two devices that we need to detect. For example: A -> B -> A and A -> C -> B -> A. To detect multiple cycles correct, we need to be able to differentiate DL_FLAG_SYNC_STATE_ONLY device links used for (1) vs (2) above. To allow this differentiation, add a DL_FLAG_CYCLE that can be use to mark use case (2). We can then use the DL_FLAG_CYCLE to decide which DL_FLAG_SYNC_STATE_ONLY device links to follow when looking for dependency cycles. Fixes: 2de9d8e0 ("driver core: fw_devlink: Improve handling of cyclic dependencies") Signed-off-by: Saravana Kannan <saravanak@google.com> Tested-by: Colin Foster <colin.foster@in-advantage.com> Tested-by: Sudeep Holla <sudeep.holla@arm.com> Tested-by: Douglas Anderson <dianders@chromium.org> Tested-by: Geert Uytterhoeven <geert+renesas@glider.be> Tested-by: Luca Weiss <luca.weiss@fairphone.com> # qcom/sm7225-fairphone-fp4 Link: https://lore.kernel.org/r/20230207014207.1678715-6-saravanak@google.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Saravana Kannan authored
Registering an irqdomain sets the flag for the fwnode. But having the flag set when a device is added is interpreted by fw_devlink to mean the device has already been initialized and will never probe. This prevents fw_devlink from creating device links with the gpio_device as a supplier. So, clear the flag before adding the device. Signed-off-by: Saravana Kannan <saravanak@google.com> Acked-by: Bartosz Golaszewski <brgl@bgdev.pl> Tested-by: Colin Foster <colin.foster@in-advantage.com> Tested-by: Sudeep Holla <sudeep.holla@arm.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Tested-by: Douglas Anderson <dianders@chromium.org> Tested-by: Geert Uytterhoeven <geert+renesas@glider.be> Tested-by: Luca Weiss <luca.weiss@fairphone.com> # qcom/sm7225-fairphone-fp4 Link: https://lore.kernel.org/r/20230207014207.1678715-5-saravanak@google.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Saravana Kannan authored
The OF_POPULATED flag was set to let fw_devlink know that the device tree node will not have a struct device created for it. This information is used by fw_devlink to avoid deferring the probe of consumers of this device tree node. Let's use fwnode_dev_initialized() instead because it achieves the same effect without using OF specific flags. This allows more generic code to be written in driver core. Signed-off-by: Saravana Kannan <saravanak@google.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Acked-by: Geert Uytterhoeven <geert+renesas@glider.be> Tested-by: Douglas Anderson <dianders@chromium.org> Tested-by: Geert Uytterhoeven <geert+renesas@glider.be> Tested-by: Luca Weiss <luca.weiss@fairphone.com> # qcom/sm7225-fairphone-fp4 Link: https://lore.kernel.org/r/20230207014207.1678715-4-saravanak@google.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Saravana Kannan authored
fw_devlink shouldn't defer the probe of a device to wait on a supplier that'll never have a struct device or will never be probed by a driver. We currently check if a supplier falls into this category, but don't check its ancestors. We need to check the ancestors too because if the ancestor will never probe, then the supplier will never probe either. Signed-off-by: Saravana Kannan <saravanak@google.com> Tested-by: Colin Foster <colin.foster@in-advantage.com> Tested-by: Sudeep Holla <sudeep.holla@arm.com> Tested-by: Douglas Anderson <dianders@chromium.org> Tested-by: Geert Uytterhoeven <geert+renesas@glider.be> Tested-by: Luca Weiss <luca.weiss@fairphone.com> # qcom/sm7225-fairphone-fp4 Link: https://lore.kernel.org/r/20230207014207.1678715-3-saravanak@google.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Saravana Kannan authored
When a device X is bound successfully to a driver, if it has a child firmware node Y that doesn't have a struct device created by then, we delete fwnode links where the child firmware node Y is the supplier. We did this to avoid blocking the consumers of the child firmware node Y from deferring probe indefinitely. While that a step in the right direction, it's better to make the consumers of the child firmware node Y to be consumers of the device X because device X is probably implementing whatever functionality is represented by child firmware node Y. By doing this, we capture the device dependencies more accurately and ensure better probe/suspend/resume ordering. Signed-off-by: Saravana Kannan <saravanak@google.com> Tested-by: Colin Foster <colin.foster@in-advantage.com> Tested-by: Sudeep Holla <sudeep.holla@arm.com> Tested-by: Douglas Anderson <dianders@chromium.org> Tested-by: Geert Uytterhoeven <geert+renesas@glider.be> Tested-by: Luca Weiss <luca.weiss@fairphone.com> # qcom/sm7225-fairphone-fp4 Link: https://lore.kernel.org/r/20230207014207.1678715-2-saravanak@google.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Greg Kroah-Hartman authored
When calling debugfs_lookup() the result must have dput() called on it, otherwise the memory will leak over time. To make things simpler, just call debugfs_lookup_and_remove() instead which handles all of the logic at once. Cc: Andrew Morton <akpm@linux-foundation.org> Reviewed-by: Yang Yingliang <yangyingliang@huawei.com> Link: https://lore.kernel.org/r/20230202151633.2310897-1-gregkh@linuxfoundation.orgSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Greg Kroah-Hartman authored
When calling debugfs_lookup() the result must have dput() called on it, otherwise the memory will leak over time. To make things simpler, just call debugfs_lookup_and_remove() instead which handles all of the logic at once. Cc: "Rafael J. Wysocki" <rafael@kernel.org> Cc: Pavel Machek <pavel@ucw.cz> Cc: Len Brown <len.brown@intel.com> Link: https://lore.kernel.org/r/20230202151515.2309543-1-gregkh@linuxfoundation.orgSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Greg Kroah-Hartman authored
When calling debugfs_lookup() the result must have dput() called on it, otherwise the memory will leak over time. To make things simpler, just call debugfs_lookup_and_remove() instead which handles all of the logic at once. Link: https://lore.kernel.org/r/20230202151214.2306822-1-gregkh@linuxfoundation.orgSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Thomas Weißschuh authored
Since commit ee6d3dd4 ("driver core: make kobj_type constant.") the driver core allows the usage of const struct kobj_type. Take advantage of this to constify the structure definition to prevent modification at runtime. Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Link: https://lore.kernel.org/r/20230208-kobj_type-samples-v1-1-fca804a8e9f3@weissschuh.netSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Thomas Weißschuh authored
Since commit ee6d3dd4 ("driver core: make kobj_type constant.") the driver core allows the usage of const struct kobj_type. Take advantage of this to constify the structure definitions to prevent modification at runtime. Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Link: https://lore.kernel.org/r/20230204-kobj_type-driver-core-v1-1-b9f809419f2c@weissschuh.netSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Thomas Weißschuh authored
Since commit ee6d3dd4 ("driver core: make kobj_type constant.") the driver core allows the usage of const struct kobj_type. Take advantage of this to constify the structure definitions to prevent modification at runtime. Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Link: https://lore.kernel.org/r/20230204-kobj_type-kobj-v1-1-ddd1b4ef8ab5@weissschuh.netSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Thomas Weißschuh authored
Since commit ee6d3dd4 ("driver core: make kobj_type constant.") the driver core allows the usage of const struct kobj_type. Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Link: https://lore.kernel.org/r/20230204-kobj_type-checkpatch-v1-1-9a94b04adbb2@weissschuh.netSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Greg Kroah-Hartman authored
When calling debugfs_lookup() the result must have dput() called on it, otherwise the memory will leak over time. To make things simpler, just call debugfs_lookup_and_remove() instead which handles all of the logic at once. Cc: "Rafael J. Wysocki" <rafael@kernel.org> Link: https://lore.kernel.org/r/20230202141621.2296458-2-gregkh@linuxfoundation.orgSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Greg Kroah-Hartman authored
When calling debugfs_lookup() the result must have dput() called on it, otherwise the memory will leak over time. To make things simpler, just call debugfs_lookup_and_remove() instead which handles all of the logic at once. Cc: "Rafael J. Wysocki" <rafael@kernel.org> Link: https://lore.kernel.org/r/20230202141621.2296458-1-gregkh@linuxfoundation.orgSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 02 Feb, 2023 1 commit
-
-
Longlong Xia authored
Use the pr_fmt() macro to prefix all the output with "devtmpfs: ". while at it, convert printk(<LEVEL>) to pr_<level>(). Signed-off-by: Longlong Xia <xialonglong1@huawei.com> Link: https://lore.kernel.org/r/20230202033203.1239239-2-xialonglong1@huawei.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 01 Feb, 2023 4 commits
-
-
Greg Kroah-Hartman authored
Move the lock_class_key structure out of struct bus_type and into the dynamic structure we create already for all bus_types registered with the kernel. This saves on static space and removes one more writable field in struct bus_type. In the future, the same field can be moved out of the struct class logic because it shares this same private structure. Most everyone will never notice this change, as lockdep is not enabled in real systems so no memory or logic changes are happening for them. Cc: "Rafael J. Wysocki" <rafael@kernel.org> Acked-by: Rafael J. Wysocki <rafael@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Link: https://lore.kernel.org/r/20230201083349.4038660-1-gregkh@linuxfoundation.orgSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Greg Kroah-Hartman authored
__platform_driver_probe() pokes around in some bus and driver private lists and locks in a way that is not needed at all. The code only wants to know if a device was bound to the driver that was registered, so walk all devices on the bus to see if there was a match. If there is not a match, return an error. This is the same logic as was originally present, but just done in a simpler and more obvious way that is not a layering violation. Cc: "Rafael J. Wysocki" <rafael@kernel.org> Link: https://lore.kernel.org/r/20230131082459.301603-2-gregkh@linuxfoundation.orgSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Greg Kroah-Hartman authored
In the reworking of the function __platform_driver_probe() over the years, it turns out that the variable 'code' does not actually do anything or mean anything anymore and can be removed to simplify the logic when trying to read and understand what this function is actually doing. Cc: "Rafael J. Wysocki" <rafael@kernel.org> Link: https://lore.kernel.org/r/20230131082459.301603-1-gregkh@linuxfoundation.orgSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Greg Kroah-Hartman authored
The driver core recently changed the uevent bus callback to take a const pointer, and the maple_bus_uevent() was not correctly fixed up. Instead of fixing the function parameter types, just remove the callback entirely as it does not do anything, so it is not necessary. Cc: Yoshinori Sato <ysato@users.sourceforge.jp> Cc: Rich Felker <dalias@libc.org> Cc: Hans de Goede <hdegoede@redhat.com> Cc: "Rafael J. Wysocki" <rafael@kernel.org> Reported-by: Linux Kernel Functional Testing <lkft@linaro.org> Reported-by: Naresh Kamboju <naresh.kamboju@linaro.org> Fixes: 2a81ada3 ("driver core: make struct bus_type.uevent() take a const *") Link: https://lore.kernel.org/r/20230201125642.624255-1-gregkh@linuxfoundation.orgSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 31 Jan, 2023 2 commits
-
-
Pierre Gondois authored
commit e75d18ce ("arm64: cacheinfo: Fix incorrect assignment of signed error value to unsigned fw_level") checks the fw_level value in init_cache_level() in case the value is negative. Remove this check as the error code is not returned through fw_level anymore, and reset fw_level if acpi_get_cache_info() failed. This allows to try fetching the cache information from clidr_el1. Signed-off-by: Pierre Gondois <pierre.gondois@arm.com> Link: https://lore.kernel.org/r/20230124154053.355376-4-pierre.gondois@arm.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Pierre Gondois authored
commit bd500361 ("ACPI: PPTT: Update acpi_find_last_cache_level() to acpi_get_cache_info()") updates the prototype of acpi_get_cache_info(). The cache 'levels' is update through a pointer and not the return value of the function. If CONFIG_ACPI_PPTT is not defined, acpi_get_cache_info() doesn't update its *levels and *split_levels parameters and returns 0. This can lead to a faulty behaviour. Make acpi_get_cache_info() return an error code if CONFIG_ACPI_PPTT is not defined. Also, In init_cache_level(), if no PPTT is present or CONFIG_ACPI_PPTT is not defined, instead of aborting if acpi_get_cache_info() returns an error code, just continue. This allows to try fetching the cache information from clidr_el1. Signed-off-by: Pierre Gondois <pierre.gondois@arm.com> Link: https://lore.kernel.org/r/20230124154053.355376-3-pierre.gondois@arm.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-