An error occurred fetching the project authors.
- 13 Feb, 2021 1 commit
-
-
Christoph Hellwig authored
Lift the dma_default_coherent variable from the mips architecture code to the driver core. This allows an architecture to sdefault all device to be DMA coherent at run time, even if the kernel is build with support for DMA noncoherent device. By allowing device_initialize to set the ->dma_coherent field to this default the amount of arch hooks required for this behavior can be greatly reduced. Signed-off-by:
Christoph Hellwig <hch@lst.de> Acked-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
Thomas Bogendoerfer <tsbogend@alpha.franken.de>
-
- 09 Dec, 2020 12 commits
-
-
Thierry Reding authored
These were just some minor typos that have crept in recently and are easily fixed. Reviewed-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by:
Thierry Reding <treding@nvidia.com> Link: https://lore.kernel.org/r/20201127104630.1839171-1-thierry.reding@gmail.comSigned-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Saravana Kannan authored
The struct device input to add_links() is not used for anything. So delete it. Acked-by:
Rob Herring <robh@kernel.org> Signed-off-by:
Saravana Kannan <saravanak@google.com> Link: https://lore.kernel.org/r/20201121020232.908850-18-saravanak@google.comSigned-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Saravana Kannan authored
The current implementation of fw_devlink is very inefficient because it tries to get away without creating fwnode links in the name of saving memory usage. Past attempts to optimize runtime at the cost of memory usage were blocked with request for data showing that the optimization made significant improvement for real world scenarios. We have those scenarios now. There have been several reports of boot time increase in the order of seconds in this thread [1]. Several OEMs and SoC manufacturers have also privately reported significant (350-400ms) increase in boot time due to all the parsing done by fw_devlink. So this patch uses all the setup done by the previous patches in this series to refactor fw_devlink to be more efficient. Most of the code has been moved out of firmware specific (DT mostly) code into driver core. This brings the following benefits: - Instead of parsing the device tree multiple times during bootup, fw_devlink parses each fwnode node/property only once and creates fwnode links. The rest of the fw_devlink code then just looks at these fwnode links to do rest of the work. - Makes it much easier to debug probe issue due to fw_devlink in the future. fw_devlink=on blocks the probing of devices if they depend on a device that hasn't been added yet. With this refactor, it'll be very easy to tell what that device is because we now have a reference to the fwnode of the device. - Much easier to add fw_devlink support to ACPI and other firmware types. A refactor to move the common bits from DT specific code to driver core was in my TODO list as a prerequisite to adding ACPI support to fw_devlink. This series gets that done. [1] - https://lore.kernel.org/linux-omap/ea02f57e-871d-cd16-4418-c1da4bbc4696@ti.com/Tested-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Tested-by:
Grygorii Strashko <grygorii.strashko@ti.com> Signed-off-by:
Saravana Kannan <saravanak@google.com> Link: https://lore.kernel.org/r/20201121020232.908850-17-saravanak@google.comSigned-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Saravana Kannan authored
To check if a device is still waiting for its supplier devices to be added, we used to check if the devices is in a global waiting_for_suppliers list. Since the global list will be deleted in subsequent patches, this patch stops using this check. Instead, this patch uses a more device specific check. It checks if the device's fwnode has any fwnode links that haven't been converted to device links yet. Signed-off-by:
Saravana Kannan <saravanak@google.com> Link: https://lore.kernel.org/r/20201121020232.908850-14-saravanak@google.comSigned-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Saravana Kannan authored
This function is a wrapper around fwnode_operations.add_links(). This function parses each node in a fwnode tree and create fwnode links for each of those nodes. The information for creating the fwnode links (the supplier and consumer fwnode) is obtained by parsing the properties in each of the fwnodes. This function also ensures that no fwnode is parsed more than once by marking the fwnodes as parsed. Signed-off-by:
Saravana Kannan <saravanak@google.com> Link: https://lore.kernel.org/r/20201121020232.908850-13-saravanak@google.comSigned-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Saravana Kannan authored
SYNC_STATE_ONLY device links only affect the behavior of sync_state() callbacks. Specifically, they prevent sync_state() only callbacks from being called on a device if one or more of its consumers haven't probed. So, creating a SYNC_STATE_ONLY device link from an already probed consumer is useless. So, don't allow creating such device links. Signed-off-by:
Saravana Kannan <saravanak@google.com> Link: https://lore.kernel.org/r/20201121020232.908850-10-saravanak@google.comSigned-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Saravana Kannan authored
Add support for creating supplier-consumer links between fwnodes. It is intended for internal use the driver core and generic firmware support code (eg. Device Tree, ACPI), so it is simple by design and the API provided is limited. Acked-by:
Rob Herring <robh@kernel.org> Signed-off-by:
Saravana Kannan <saravanak@google.com> Link: https://lore.kernel.org/r/20201121020232.908850-9-saravanak@google.comSigned-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Saravana Kannan authored
This reverts commit 716a7a25. The fw_devlink_pause/resume() APIs added by the commit being reverted were a first cut attempt at optimizing boot time. But these APIs don't fully solve the problem and are very fragile (can only be used for the top level devices being added). This series replaces them with a much better optimization that works for all device additions and also has the benefit of reducing the complexity of the firmware (DT, EFI) specific code and abstracting out common code to driver core. Signed-off-by:
Saravana Kannan <saravanak@google.com> Link: https://lore.kernel.org/r/20201121020232.908850-7-saravanak@google.comSigned-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Saravana Kannan authored
This reverts commit cec72f3e. Commit cec72f3e ("driver core: Don't do deferred probe in parallel with kernel_init thread") was fixing a commit 716a7a25 ("driver core: fw_devlink: Add support for batching fwnode parsing"). Since the commit being fixed itself is going to be reverted, the fix can also be reverted. Signed-off-by:
Saravana Kannan <saravanak@google.com> Link: https://lore.kernel.org/r/20201121020232.908850-4-saravanak@google.comSigned-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Saravana Kannan authored
This reverts commit ec7bd784. This field rename was done to reuse defer_syc list head for multiple lists. That's not needed anymore and this list head will only be used for defer sync. So revert this patch to avoid conflicts with the other reverts coming after this. Signed-off-by:
Saravana Kannan <saravanak@google.com> Link: https://lore.kernel.org/r/20201121020232.908850-3-saravanak@google.comSigned-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Saravana Kannan authored
This reverts commit 2451e746. fw_devlink_pause/resume() was an incomplete attempt at boot time optimization. That's going to get replaced by a much better optimization at the end of the series. Since fw_devlink_pause/resume() is going away, changes made for that can also go away. Signed-off-by:
Saravana Kannan <saravanak@google.com> Link: https://lore.kernel.org/r/20201121020232.908850-2-saravanak@google.comSigned-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Takashi Iwai authored
The device_links_purge() function (called from device_del()) tries to remove the links.needs_suppliers list entry, but it's using list_del(), hence it doesn't initialize after the removal. This is OK for normal cases where device_del() is called via device_destroy(). However, it's not guaranteed that the device object will be really deleted soon after device_del(). In a minor case like HD-audio codec reconfiguration that re-initializes the device after device_del(), it may lead to a crash by the corrupted list entry. As a simple fix, replace list_del() with list_del_init() in order to make the list intact after the device_del() call. Fixes: e2ae9bcc ("driver core: Add support for linking devices during device addition") Cc: <stable@vger.kernel.org> Reviewed-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by:
Takashi Iwai <tiwai@suse.de> Link: https://lore.kernel.org/r/20201208190326.27531-1-tiwai@suse.de Cc: Saravana Kannan <saravanak@google.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 09 Nov, 2020 1 commit
-
-
Saravana Kannan authored
There's a potential deadlock with the following cycle: wfs_lock --> device_links_lock --> kn->count Fix this by simply dropping the lock around a list_empty() check that's just exported to a sysfs file. The sysfs file output is an instantaneous check anyway and the lock doesn't really add any protection. Lockdep log: [ 48.808132] [ 48.808132] the existing dependency chain (in reverse order) is: [ 48.809069] [ 48.809069] -> #2 (kn->count){++++}: [ 48.809707] __kernfs_remove.llvm.7860393000964815146+0x2d4/0x460 [ 48.810537] kernfs_remove_by_name_ns+0x54/0x9c [ 48.811171] sysfs_remove_file_ns+0x18/0x24 [ 48.811762] device_del+0x2b8/0x5a8 [ 48.812269] __device_link_del+0x98/0xb8 [ 48.812829] device_links_driver_bound+0x210/0x2d8 [ 48.813496] driver_bound+0x44/0xf8 [ 48.814000] really_probe+0x340/0x6e0 [ 48.814526] driver_probe_device+0xb8/0x100 [ 48.815117] device_driver_attach+0x78/0xb8 [ 48.815708] __driver_attach+0xe0/0x194 [ 48.816255] bus_for_each_dev+0xa8/0x11c [ 48.816816] driver_attach+0x24/0x30 [ 48.817331] bus_add_driver+0x100/0x1e0 [ 48.817880] driver_register+0x78/0x114 [ 48.818427] __platform_driver_register+0x44/0x50 [ 48.819089] 0xffffffdbb3227038 [ 48.819551] do_one_initcall+0xd8/0x1e0 [ 48.820099] do_init_module+0xd8/0x298 [ 48.820636] load_module+0x3afc/0x44c8 [ 48.821173] __arm64_sys_finit_module+0xbc/0xf0 [ 48.821807] el0_svc_common+0xbc/0x1d0 [ 48.822344] el0_svc_handler+0x74/0x98 [ 48.822882] el0_svc+0x8/0xc [ 48.823310] [ 48.823310] -> #1 (device_links_lock){+.+.}: [ 48.824036] __mutex_lock_common+0xe0/0xe44 [ 48.824626] mutex_lock_nested+0x28/0x34 [ 48.825185] device_link_add+0xd4/0x4ec [ 48.825734] of_link_to_suppliers+0x158/0x204 [ 48.826347] of_fwnode_add_links+0x50/0x64 [ 48.826928] device_link_add_missing_supplier_links+0x90/0x11c [ 48.827725] fw_devlink_resume+0x58/0x130 [ 48.828296] of_platform_default_populate_init+0xb4/0xd0 [ 48.829030] do_one_initcall+0xd8/0x1e0 [ 48.829578] do_initcall_level+0xb8/0xcc [ 48.830137] do_basic_setup+0x60/0x7c [ 48.830662] kernel_init_freeable+0x128/0x1ac [ 48.831275] kernel_init+0x18/0x29c [ 48.831781] ret_from_fork+0x10/0x18 [ 48.832297] [ 48.832297] -> #0 (wfs_lock){+.+.}: [ 48.832922] __lock_acquire+0xe04/0x2e20 [ 48.833480] lock_acquire+0xbc/0xec [ 48.833984] __mutex_lock_common+0xe0/0xe44 [ 48.834577] mutex_lock_nested+0x28/0x34 [ 48.835136] waiting_for_supplier_show+0x3c/0x98 [ 48.835781] dev_attr_show+0x48/0xb4 [ 48.836295] sysfs_kf_seq_show+0xe8/0x184 [ 48.836864] kernfs_seq_show+0x48/0x8c [ 48.837401] seq_read+0x1c8/0x600 [ 48.837884] kernfs_fop_read+0x68/0x204 [ 48.838431] __vfs_read+0x60/0x214 [ 48.838925] vfs_read+0xbc/0x15c [ 48.839397] ksys_read+0x78/0xe4 [ 48.839869] __arm64_sys_read+0x1c/0x28 [ 48.840416] el0_svc_common+0xbc/0x1d0 [ 48.840953] el0_svc_handler+0x74/0x98 [ 48.841490] el0_svc+0x8/0xc [ 48.841917] [ 48.841917] other info that might help us debug this: [ 48.841917] [ 48.842920] Chain exists of: [ 48.842920] wfs_lock --> device_links_lock --> kn->count [ 48.842920] [ 48.844152] Possible unsafe locking scenario: [ 48.844152] [ 48.844895] CPU0 CPU1 [ 48.845463] ---- ---- [ 48.846032] lock(kn->count); [ 48.846417] lock(device_links_lock); [ 48.847203] lock(kn->count); [ 48.847902] lock(wfs_lock); [ 48.848276] [ 48.848276] *** DEADLOCK *** Reported-by: Cheng-Jui.Wang@mediatek.com Signed-off-by:
Saravana Kannan <saravanak@google.com> Link: https://lore.kernel.org/r/20201104205431.3795207-1-saravanak@google.comSigned-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 02 Nov, 2020 1 commit
-
-
Rafael J. Wysocki authored
While removing a device link, drop the supplier device's runtime PM usage counter as many times as needed to drop all of the runtime PM references to it from the consumer in addition to dropping the consumer's link count. Fixes: baa8809f ("PM / runtime: Optimize the use of device links") Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Cc: 5.1+ <stable@vger.kernel.org> # 5.1+ Tested-by:
Xiang Chen <chenxiang66@hisilicon.com> Reviewed-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 27 Oct, 2020 2 commits
-
-
Andy Shevchenko authored
It appears that firmware nodes can be shared between devices. In such case when a (child) device is about to be deleted, its firmware node may be shared and ACPI_COMPANION_SET(..., NULL) call for it breaks the secondary link of the shared primary firmware node. In order to prevent that, check, if the device has a parent and parent's firmware node is shared with its child, and avoid crashing the link. Fixes: c15e1bdd ("device property: Fix the secondary firmware node handling in set_primary_fwnode()") Reported-by:
Ferry Toth <fntoth@gmail.com> Signed-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by:
Heikki Krogerus <heikki.krogerus@linux.intel.com> Tested-by:
Ferry Toth <fntoth@gmail.com> Cc: 5.9+ <stable@vger.kernel.org> # 5.9+ Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com>
-
Andy Shevchenko authored
Behind primary and secondary we understand the type of the nodes which might define their ordering. However, if primary node gone, we can't maintain the ordering by definition of the linked list. Thus, by ordering secondary node becomes first in the list. But in this case the meaning of it is still secondary (or auxiliary). The type of the node is maintained by the secondary pointer in it: secondary pointer Meaning NULL or valid primary node ERR_PTR(-ENODEV) secondary node So, if by some reason we do the following sequence of calls set_primary_fwnode(dev, NULL); set_primary_fwnode(dev, primary); we should preserve secondary node. This concept is supported by the description of set_primary_fwnode() along with implementation of set_secondary_fwnode(). Hence, fix the commit c15e1bdd to follow this as well. Fixes: c15e1bdd ("device property: Fix the secondary firmware node handling in set_primary_fwnode()") Cc: Ferry Toth <fntoth@gmail.com> Signed-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by:
Heikki Krogerus <heikki.krogerus@linux.intel.com> Tested-by:
Ferry Toth <fntoth@gmail.com> Cc: 5.9+ <stable@vger.kernel.org> # 5.9+ Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com>
-
- 15 Oct, 2020 1 commit
-
-
Mauro Carvalho Chehab authored
There are two literal blocks there. Fix the markups, in order to produce the right html output and solve those warnings: ./drivers/base/core.c:4218: WARNING: Unexpected indentation. ./drivers/base/core.c:4222: WARNING: Definition list ends without a blank line; unexpected unindent. ./drivers/base/core.c:4223: WARNING: Block quote ends without a blank line; unexpected unindent. Fixes: a787e540 ("driver core: add device probe log helper") Signed-off-by:
Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
- 14 Oct, 2020 1 commit
-
-
Dan Williams authored
Use sysfs_streq() in device_find_child_by_name() to allow it to use a sysfs input string that might contain a trailing newline. The other "device by name" interfaces, {bus,driver,class}_find_device_by_name(), already account for sysfs strings. Signed-off-by:
Dan Williams <dan.j.williams@intel.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Reviewed-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Andy Lutomirski <luto@kernel.org> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Ard Biesheuvel <ardb@kernel.org> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Ben Skeggs <bskeggs@redhat.com> Cc: Bjorn Helgaas <bhelgaas@google.com> Cc: Borislav Petkov <bp@alien8.de> Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com> Cc: Brice Goglin <Brice.Goglin@inria.fr> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Dave Hansen <dave.hansen@linux.intel.com> Cc: Dave Jiang <dave.jiang@intel.com> Cc: David Airlie <airlied@linux.ie> Cc: David Hildenbrand <david@redhat.com> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Hulk Robot <hulkci@huawei.com> Cc: Ingo Molnar <mingo@redhat.com> Cc: Ira Weiny <ira.weiny@intel.com> Cc: Jason Gunthorpe <jgg@mellanox.com> Cc: Jason Yan <yanaijie@huawei.com> Cc: Jeff Moyer <jmoyer@redhat.com> Cc: "Jérôme Glisse" <jglisse@redhat.com> Cc: Jia He <justin.he@arm.com> Cc: Joao Martins <joao.m.martins@oracle.com> Cc: Jonathan Cameron <Jonathan.Cameron@huawei.com> Cc: Juergen Gross <jgross@suse.com> Cc: kernel test robot <lkp@intel.com> Cc: Michael Ellerman <mpe@ellerman.id.au> Cc: Mike Rapoport <rppt@linux.ibm.com> Cc: Paul Mackerras <paulus@ozlabs.org> Cc: Pavel Tatashin <pasha.tatashin@soleen.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: "Rafael J. Wysocki" <rafael.j.wysocki@intel.com> Cc: Randy Dunlap <rdunlap@infradead.org> Cc: Stefano Stabellini <sstabellini@kernel.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Tom Lendacky <thomas.lendacky@amd.com> Cc: Vishal Verma <vishal.l.verma@intel.com> Cc: Vivek Goyal <vgoyal@redhat.com> Cc: Wei Yang <richard.weiyang@linux.alibaba.com> Cc: Will Deacon <will@kernel.org> Link: https://lkml.kernel.org/r/159643102106.4062302.12229802117645312104.stgit@dwillia2-desk3.amr.corp.intel.com Link: https://lkml.kernel.org/r/160106114576.30709.2960091665444712180.stgit@dwillia2-desk3.amr.corp.intel.comSigned-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
- 02 Oct, 2020 3 commits
-
-
Joe Perches authored
Change additional instances that could use sysfs_emit and sysfs_emit_at that the coccinelle script could not convert. o macros creating show functions with ## concatenation o unbound sprintf uses with buf+len for start of output to sysfs_emit_at o returns with ?: tests and sprintf to sysfs_emit o sysfs output with struct class * not struct device * arguments Miscellanea: o remove unnecessary initializations around these changes o consistently use int len for return length of show functions o use octal permissions and not S_<FOO> o rename a few show function names so DEVICE_ATTR_<FOO> can be used o use DEVICE_ATTR_ADMIN_RO where appropriate o consistently use const char *output for strings o checkpatch/style neatening Signed-off-by:
Joe Perches <joe@perches.com> Link: https://lore.kernel.org/r/8bc24444fe2049a9b2de6127389b57edfdfe324d.1600285923.git.joe@perches.comSigned-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Joe Perches authored
strcat is no longer necessary for sysfs_emit and sysfs_emit_at uses. Convert the strcat uses to sysfs_emit calls and neaten other block uses of direct returns to use an intermediate const char *. Signed-off-by:
Joe Perches <joe@perches.com> Link: https://lore.kernel.org/r/5d606519698ce4c8f1203a2b35797d8254c6050a.1600285923.git.joe@perches.comSigned-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Joe Perches authored
Convert the various sprintf fmaily calls in sysfs device show functions to sysfs_emit and sysfs_emit_at for PAGE_SIZE buffer safety. Done with: $ spatch -sp-file sysfs_emit_dev.cocci --in-place --max-width=80 . And cocci script: $ cat sysfs_emit_dev.cocci @@ identifier d_show; identifier dev, attr, buf; @@ ssize_t d_show(struct device *dev, struct device_attribute *attr, char *buf) { <... return - sprintf(buf, + sysfs_emit(buf, ...); ...> } @@ identifier d_show; identifier dev, attr, buf; @@ ssize_t d_show(struct device *dev, struct device_attribute *attr, char *buf) { <... return - snprintf(buf, PAGE_SIZE, + sysfs_emit(buf, ...); ...> } @@ identifier d_show; identifier dev, attr, buf; @@ ssize_t d_show(struct device *dev, struct device_attribute *attr, char *buf) { <... return - scnprintf(buf, PAGE_SIZE, + sysfs_emit(buf, ...); ...> } @@ identifier d_show; identifier dev, attr, buf; expression chr; @@ ssize_t d_show(struct device *dev, struct device_attribute *attr, char *buf) { <... return - strcpy(buf, chr); + sysfs_emit(buf, chr); ...> } @@ identifier d_show; identifier dev, attr, buf; identifier len; @@ ssize_t d_show(struct device *dev, struct device_attribute *attr, char *buf) { <... len = - sprintf(buf, + sysfs_emit(buf, ...); ...> return len; } @@ identifier d_show; identifier dev, attr, buf; identifier len; @@ ssize_t d_show(struct device *dev, struct device_attribute *attr, char *buf) { <... len = - snprintf(buf, PAGE_SIZE, + sysfs_emit(buf, ...); ...> return len; } @@ identifier d_show; identifier dev, attr, buf; identifier len; @@ ssize_t d_show(struct device *dev, struct device_attribute *attr, char *buf) { <... len = - scnprintf(buf, PAGE_SIZE, + sysfs_emit(buf, ...); ...> return len; } @@ identifier d_show; identifier dev, attr, buf; identifier len; @@ ssize_t d_show(struct device *dev, struct device_attribute *attr, char *buf) { <... - len += scnprintf(buf + len, PAGE_SIZE - len, + len += sysfs_emit_at(buf, len, ...); ...> return len; } @@ identifier d_show; identifier dev, attr, buf; expression chr; @@ ssize_t d_show(struct device *dev, struct device_attribute *attr, char *buf) { ... - strcpy(buf, chr); - return strlen(buf); + return sysfs_emit(buf, chr); } Signed-off-by:
Joe Perches <joe@perches.com> Link: https://lore.kernel.org/r/3d033c33056d88bbe34d4ddb62afd05ee166ab9a.1600285923.git.joe@perches.comSigned-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 22 Sep, 2020 1 commit
-
-
John Ogness authored
Dictionaries are only used for SUBSYSTEM and DEVICE properties. The current implementation stores the property names each time they are used. This requires more space than otherwise necessary. Also, because the dictionary entries are currently considered optional, it cannot be relied upon that they are always available, even if the writer wanted to store them. These issues will increase should new dictionary properties be introduced. Rather than storing the subsystem and device properties in the dict ring, introduce a struct dev_printk_info with separate fields to store only the property values. Embed this struct within the struct printk_info to provide guaranteed availability. Signed-off-by:
John Ogness <john.ogness@linutronix.de> Reviewed-by:
Petr Mladek <pmladek@suse.com> Signed-off-by:
Petr Mladek <pmladek@suse.com> Link: https://lore.kernel.org/r/87mu1jl6ne.fsf@jogness.linutronix.de
-
- 17 Sep, 2020 2 commits
-
-
Jim Quinlan authored
The new field 'dma_range_map' in struct device is used to facilitate the use of single or multiple offsets between mapping regions of cpu addrs and dma addrs. It subsumes the role of "dev->dma_pfn_offset" which was only capable of holding a single uniform offset and had no region bounds checking. The function of_dma_get_range() has been modified so that it takes a single argument -- the device node -- and returns a map, NULL, or an error code. The map is an array that holds the information regarding the DMA regions. Each range entry contains the address offset, the cpu_start address, the dma_start address, and the size of the region. of_dma_configure() is the typical manner to set range offsets but there are a number of ad hoc assignments to "dev->dma_pfn_offset" in the kernel driver code. These cases now invoke the function dma_direct_set_offset(dev, cpu_addr, dma_addr, size). Signed-off-by:
Jim Quinlan <james.quinlan@broadcom.com> [hch: various interface cleanups] Signed-off-by:
Christoph Hellwig <hch@lst.de> Reviewed-by:
Mathieu Poirier <mathieu.poirier@linaro.org> Tested-by:
Mathieu Poirier <mathieu.poirier@linaro.org> Tested-by:
Nathan Chancellor <natechancellor@gmail.com>
-
Oliver Neukum authored
There is one overlooked situation under which a driver must not do IO to allocate memory. You cannot do that while disconnecting a device. A device being disconnected is no longer functional in most cases, yet IO may fail only when the handler runs. Signed-off-by:
Oliver Neukum <oneukum@suse.com> Link: https://lore.kernel.org/r/20200916191544.5104-1-oneukum@suse.comSigned-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 04 Sep, 2020 2 commits
-
-
Saravana Kannan authored
This commit fixes two issues: 1. The lockdep warning reported by Dong Aisheng <dongas86@gmail.com> [1]. It is a warning about a cycle (dpm_list_mtx --> kn->active#3 --> fw_lock) that was introduced when device-link devices were added to expose device link information in sysfs. The patch that "introduced" this cycle can't be reverted because it's fixes a real SRCU issue and also ensures that the device-link device is deleted as soon as the device-link is deleted. This is important to avoid sysfs name collisions if the device-link is create again immediately (this can happen a lot with deferred probing). 2. Inconsistency in grabbing device_pm_lock() during device link deletion Some device link deletion code paths grab device_pm_lock(), while others don't. The device_pm_lock() is grabbed during device_link_add() because it checks if the supplier is in the dpm_list and also reorders the dpm_list. However, when a device link is deleted, it does not do either of those and therefore device_pm_lock() is not necessary. Dropping the device_pm_lock() in all the device link deletion paths removes the inconsistency in locking. Thanks to Stephen Boyd for helping me understand the lockdep splat. Fixes: 843e600b ("driver core: Fix sleeping in invalid context during device link deletion") [1] - https://lore.kernel.org/lkml/CAA+hA=S4eAreb7vo69LAXSk2t5=DEKNxHaiY1wSpk4xTp9urLg@mail.gmail.com/Reported-by:
Dong Aisheng <dongas86@gmail.com> Signed-off-by:
Saravana Kannan <saravanak@google.com> Tested-by:
Peng Fan <peng.fan@nxp.com> Link: https://lore.kernel.org/r/20200901184445.1736658-1-saravanak@google.comSigned-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Michał Mirosław authored
dev_err_probe() prepends the message with an error code. Let's make it more readable by translating the code to a more recognisable symbol. Fixes: a787e540 ("driver core: add device probe log helper") Signed-off-by:
Michał Mirosław <mirq-linux@rere.qmqm.pl> Link: https://lore.kernel.org/r/ea3f973e4708919573026fdce52c264db147626d.1598630856.git.mirq-linux@rere.qmqm.plSigned-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 21 Aug, 2020 1 commit
-
-
Heikki Krogerus authored
When the primary firmware node pointer is removed from a device (set to NULL) the secondary firmware node pointer, when it exists, is made the primary node for the device. However, the secondary firmware node pointer of the original primary firmware node is never cleared (set to NULL). To avoid situation where the secondary firmware node pointer is pointing to a non-existing object, clearing it properly when the primary node is removed from a device in set_primary_fwnode(). Fixes: 97badf87 ("device property: Make it possible to use secondary firmware nodes") Cc: All applicable <stable@vger.kernel.org> Signed-off-by:
Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com>
-
- 30 Jul, 2020 2 commits
-
-
Andrzej Hajda authored
/sys/kernel/debug/devices_deferred property contains list of deferred devices. This list does not contain reason why the driver deferred probe, the patch improves it. The natural place to set the reason is dev_err_probe function introduced recently, ie. if dev_err_probe will be called with -EPROBE_DEFER instead of printk the message will be attached to a deferred device and printed when user reads devices_deferred property. Signed-off-by:
Andrzej Hajda <a.hajda@samsung.com> Reviewed-by:
Mark Brown <broonie@kernel.org> Reviewed-by:
Javier Martinez Canillas <javierm@redhat.com> Reviewed-by:
Andy Shevchenko <andy.shevchenko@gmail.com> Reviewed-by:
Rafael J. Wysocki <rafael@kernel.org> Link: https://lore.kernel.org/r/20200713144324.23654-3-a.hajda@samsung.comSigned-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Andrzej Hajda authored
During probe every time driver gets resource it should usually check for error printk some message if it is not -EPROBE_DEFER and return the error. This pattern is simple but requires adding few lines after any resource acquisition code, as a result it is often omitted or implemented only partially. dev_err_probe helps to replace such code sequences with simple call, so code: if (err != -EPROBE_DEFER) dev_err(dev, ...); return err; becomes: return dev_err_probe(dev, err, ...); Signed-off-by:
Andrzej Hajda <a.hajda@samsung.com> Reviewed-by:
Rafael J. Wysocki <rafael@kernel.org> Reviewed-by:
Mark Brown <broonie@kernel.org> Reviewed-by:
Andy Shevchenko <andy.shevchenko@gmail.com> Link: https://lore.kernel.org/r/20200713144324.23654-2-a.hajda@samsung.comSigned-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 24 Jul, 2020 1 commit
-
-
Saravana Kannan authored
The devlink device name is of the form "supplier:consumer". But ":" is fairly common in device names and makes it visually hard to distinguish supplier and consumer. So, replace it with "--" to make it easier. Signed-off-by:
Saravana Kannan <saravanak@google.com> Link: https://lore.kernel.org/r/20200724180523.1393383-1-saravanak@google.comSigned-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 23 Jul, 2020 1 commit
-
-
Saravana Kannan authored
Marek and Guenter reported that commit 287905e6 ("driver core: Expose device link details in sysfs") caused sleeping/scheduling while atomic warnings. BUG: sleeping function called from invalid context at kernel/locking/mutex.c:935 in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 12, name: kworker/0:1 2 locks held by kworker/0:1/12: #0: ee8074a8 ((wq_completion)rcu_gp){+.+.}-{0:0}, at: process_one_work+0x174/0x7dc #1: ee921f20 ((work_completion)(&sdp->work)){+.+.}-{0:0}, at: process_one_work+0x174/0x7dc Preemption disabled at: [<c01b10f0>] srcu_invoke_callbacks+0xc0/0x154 ----- 8< ----- SNIP [<c064590c>] (device_del) from [<c0645c9c>] (device_unregister+0x24/0x64) [<c0645c9c>] (device_unregister) from [<c01b10fc>] (srcu_invoke_callbacks+0xcc/0x154) [<c01b10fc>] (srcu_invoke_callbacks) from [<c01493c4>] (process_one_work+0x234/0x7dc) [<c01493c4>] (process_one_work) from [<c01499b0>] (worker_thread+0x44/0x51c) [<c01499b0>] (worker_thread) from [<c0150bf4>] (kthread+0x158/0x1a0) [<c0150bf4>] (kthread) from [<c0100114>] (ret_from_fork+0x14/0x20) Exception stack(0xee921fb0 to 0xee921ff8) This was caused by the device link device being released in the context of srcu_invoke_callbacks(). There is no need to wait till the RCU callback to release the device link device. So release the device earlier and move the call_srcu() into the device release code. That way, the memory will get freed only after the device is released AND the RCU callback is called. Fixes: 287905e6 ("driver core: Expose device link details in sysfs") Reported-by:
Marek Szyprowski <m.szyprowski@samsung.com> Reported-by:
Guenter Roeck <linux@roeck-us.net> Reported-by:
Naresh Kamboju <naresh.kamboju@linaro.org> Signed-off-by:
Saravana Kannan <saravanak@google.com> Tested-by:
Marek Szyprowski <m.szyprowski@samsung.com> Tested-by:
Guenter Roeck <linux@roeck-us.net> Link: https://lore.kernel.org/r/20200716214523.2924704-1-saravanak@google.comSigned-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 10 Jul, 2020 5 commits
-
-
Saravana Kannan authored
This would be useful to check if a device is not probing because it's waiting for a supplier to be added and then linked to before it can probe. To reduce sysfs clutter, this file is added only if it can ever be 1. So, if fw_devlink is disabled or set to permissive, this file is not added. Also, this file is removed once the device probes as it's no longer relevant. Signed-off-by:
Saravana Kannan <saravanak@google.com> Link: https://lore.kernel.org/r/20200521191800.136035-4-saravanak@google.comSigned-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Saravana Kannan authored
It's helpful to be able to look at device link details from sysfs. So, expose it in sysfs. Say device-A is supplier of device-B. These are the additional files this patch would create: /sys/class/devlink/device-A:device-B/ auto_remove_on consumer/ -> .../device-B/ runtime_pm status supplier/ -> .../device-A/ sync_state_only /sys/devices/.../device-A/ consumer:device-B/ -> /sys/class/devlink/device-A:device-B/ /sys/devices/.../device-B/ supplier:device-A/ -> /sys/class/devlink/device-A:device-B/ That way: To get a list of all the device link in the system: ls /sys/class/devlink/ To get the consumer names and links of a device: ls -d /sys/devices/.../device-X/consumer:* To get the supplier names and links of a device: ls -d /sys/devices/.../device-X/supplier:* Signed-off-by:
Saravana Kannan <saravanak@google.com> Link: https://lore.kernel.org/r/20200521191800.136035-2-saravanak@google.comSigned-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Saravana Kannan authored
With the earlier patch in this series, all devices that deferred probe due to fw_devlink_pause() will have their probes delayed till the deferred probe thread is kicked off during late_initcall. This will also affect all their consumers. This delayed probing in unnecessary. So this patch just keeps track of the devices that had their probe deferred due to fw_devlink_pause() and attempts to probe them once during fw_devlink_resume(). Fixes: 716a7a25 ("driver core: fw_devlink: Add support for batching fwnode parsing") Signed-off-by:
Saravana Kannan <saravanak@google.com> Tested-by:
Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/r/20200701194259.3337652-4-saravanak@google.comSigned-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Saravana Kannan authored
The defer_sync field is used as a hook to add the device to the deferred_sync list. Rename it so that it's more meaningful for the next patch that'll also use this field as a hook to a deferred_fw_devlink list. Signed-off-by:
Saravana Kannan <saravanak@google.com> Reviewed-by:
Rafael J. Wysocki <rafael@kernel.org> Tested-by:
Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/r/20200701194259.3337652-3-saravanak@google.comSigned-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Saravana Kannan authored
The current deferred probe implementation can mess up suspend/resume ordering if deferred probe thread is kicked off in parallel with the main initcall thread (kernel_init thread) [1]. For example: Say device-B is a consumer of device-A. Initcall thread Deferred probe thread =============== ===================== 1. device-A is added. 2. device-B is added. 3. dpm_list is now [device-A, device-B]. 4. driver-A defers probe of device-A. 5. device-A is moved to end of dpm_list 6. dpm_list is now [device-B, device-A] 7. driver-B is registereed and probes device-B. 8. dpm_list stays as [device-B, device-A]. The reverse order of dpm_list is used for suspend. So in this case device-A would incorrectly get suspended before device-B. Commit 716a7a25 ("driver core: fw_devlink: Add support for batching fwnode parsing") kicked off the deferred probe thread early during boot to run in parallel with the initcall thread and caused suspend/resume regressions. This patch removes the parallel run of the deferred probe thread to avoid the suspend/resume regressions. [1] - https://lore.kernel.org/lkml/CAGETcx8W96KAw-d_siTX4qHB_-7ddk0miYRDQeHE6E0_8qx-6Q@mail.gmail.com/ Fixes: 716a7a25 ("driver core: fw_devlink: Add support for batching fwnode parsing") Signed-off-by:
Saravana Kannan <saravanak@google.com> Tested-by:
Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/r/20200701194259.3337652-2-saravanak@google.comSigned-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 17 Jun, 2020 1 commit
-
-
Saravana Kannan authored
DT implementation of fw_devlink needs this function to detect cycles. So make it available. Signed-off-by:
Saravana Kannan <saravanak@google.com> Tested-by:
John Stultz <john.stultz@linaro.org> Signed-off-by:
Rob Herring <robh@kernel.org>
-
- 27 May, 2020 1 commit
-
-
Saravana Kannan authored
When SYNC_STATE_ONLY support was added in commit 05ef983e ("driver core: Add device link support for SYNC_STATE_ONLY flag"), SYNC_STATE_ONLY links were treated similar to STATELESS links in terms of not blocking consumer probe if the supplier hasn't probed yet. That caused a SYNC_STATE_ONLY device link's status to not get updated. Since SYNC_STATE_ONLY device link is no longer useful once the consumer probes, commit 21c27f06 ("driver core: Fix SYNC_STATE_ONLY device link implementation") addresses the status update issue by deleting the SYNC_STATE_ONLY device link instead of complicating the status update code. However, there are still some cases where we need to update the status of a SYNC_STATE_ONLY device link. This is because a SYNC_STATE_ONLY device link can later get converted into a normal MANAGED device link when a normal MANAGED device link is created between a supplier and consumer that already have a SYNC_STATE_ONLY device link between them. If a SYNC_STATE_ONLY device link's status isn't maintained correctly till it's converted to a normal MANAGED device link, then the normal MANAGED device link will end up with a wrong link status. This can cause a warning stack trace[1] when the consumer device probes successfully. This commit fixes the SYNC_STATE_ONLY device link status update issue where it wouldn't transition correctly from DL_STATE_DORMANT or DL_STATE_AVAILABLE to DL_STATE_CONSUMER_PROBE. It also resets the status back to DL_STATE_DORMANT or DL_STATE_AVAILABLE if the consumer probe fails. [1] - https://lore.kernel.org/lkml/20200522204120.3b3c9ed6@apollo/ Fixes: 05ef983e ("driver core: Add device link support for SYNC_STATE_ONLY flag") Fixes: 21c27f06 ("driver core: Fix SYNC_STATE_ONLY device link implementation") Reported-by:
Michael Walle <michael@walle.cc> Tested-by:
Michael Walle <michael@walle.cc> Signed-off-by:
Saravana Kannan <saravanak@google.com> Reviewed-by:
Rafael J. Wysocki <rrafael.j.wysocki@intel.com> Link: https://lore.kernel.org/r/20200526220928.49939-1-saravanak@google.comSigned-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 21 May, 2020 1 commit
-
-
Saravana Kannan authored
That variable is no longer necessary. Remove it and also fix a minor typo in comments. Signed-off-by:
Saravana Kannan <saravanak@google.com> Link: https://lore.kernel.org/r/20200520034824.79049-2-saravanak@google.comSigned-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-