- 08 2月, 2021 2 次提交
-
-
由 Rafael J. Wysocki 提交于
stable inclusion from stable-5.10.11 commit 881363cbddb18a6258d3a7fc2b2a023d8f029dc3 bugzilla: 47621 -------------------------------- commit 3d1cf435 upstream. If the device passed as the target (second argument) to device_is_dependent() is not completely registered (that is, it has been initialized, but not added yet), but the parent pointer of it is set, it may be missing from the list of the parent's children and device_for_each_child() called by device_is_dependent() cannot be relied on to catch that dependency. For this reason, modify device_is_dependent() to check the ancestors of the target device by following its parent pointer in addition to the device_for_each_child() walk. Fixes: 9ed98953 ("driver core: Functional dependencies tracking support") Reported-by: NStephan Gerhold <stephan@gerhold.net> Tested-by: NStephan Gerhold <stephan@gerhold.net> Reviewed-by: NSaravana Kannan <saravanak@google.com> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com> Link: https://lore.kernel.org/r/17705994.d592GUb2YH@kreacher Cc: stable <stable@vger.kernel.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com>
-
由 Saravana Kannan 提交于
stable inclusion from stable-5.10.11 commit b3bc56e3f503281a0d30896fe4f17a9a3d7d03c0 bugzilla: 47621 -------------------------------- commit e020ff61 upstream. The device link device's name was of the form: <supplier-dev-name>--<consumer-dev-name> This can cause name collision as reported here [1] as device names are not globally unique. Since device names have to be unique within the bus/class, add the bus/class name as a prefix to the device names used to construct the device link device name. So the devuce link device's name will be of the form: <supplier-bus-name>:<supplier-dev-name>--<consumer-bus-name>:<consumer-dev-name> [1] - https://lore.kernel.org/lkml/20201229033440.32142-1-michael@walle.cc/ Fixes: 287905e6 ("driver core: Expose device link details in sysfs") Cc: stable@vger.kernel.org Reported-by: NMichael Walle <michael@walle.cc> Tested-by: NMichael Walle <michael@walle.cc> Signed-off-by: NSaravana Kannan <saravanak@google.com> Link: https://lore.kernel.org/r/20210110175408.1465657-1-saravanak@google.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com>
-
- 27 1月, 2021 1 次提交
-
-
由 Bard Liao 提交于
stable inclusion from stable-5.10.7 commit 6844bc38c9fe5c20994f4a0819eac1fc9acd80eb bugzilla: 47429 -------------------------------- commit 47f44699 upstream. While commit d5dcce0c ("device property: Keep secondary firmware node secondary by type") describes everything correct in its commit message, the change it made does the opposite and original commit c15e1bdd ("device property: Fix the secondary firmware node handling in set_primary_fwnode()") was fully correct. Revert the former one here and improve documentation in the next patch. Fixes: d5dcce0c ("device property: Keep secondary firmware node secondary by type") Signed-off-by: NBard Liao <yung-chuan.liao@linux.intel.com> Reviewed-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: NHeikki Krogerus <heikki.krogerus@linux.intel.com> Cc: 5.10+ <stable@vger.kernel.org> # 5.10+ Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NChen Jun <chenjun102@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com>
-
- 12 1月, 2021 1 次提交
-
-
由 Takashi Iwai 提交于
stable inclusion from stable-5.10.4 commit c26062328e727bef49317270176f122d21c78de9 bugzilla: 46903 -------------------------------- commit 66482f64 upstream. 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: NRafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: NTakashi 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: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NChen Jun <chenjun102@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com>
-
- 03 11月, 2020 1 次提交
-
-
由 Rafael J. Wysocki 提交于
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: NRafael J. Wysocki <rafael.j.wysocki@intel.com> Cc: 5.1+ <stable@vger.kernel.org> # 5.1+ Tested-by: NXiang Chen <chenxiang66@hisilicon.com> Reviewed-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 28 10月, 2020 2 次提交
-
-
由 Andy Shevchenko 提交于
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: NFerry Toth <fntoth@gmail.com> Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: NHeikki Krogerus <heikki.krogerus@linux.intel.com> Tested-by: NFerry Toth <fntoth@gmail.com> Cc: 5.9+ <stable@vger.kernel.org> # 5.9+ Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
由 Andy Shevchenko 提交于
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: NAndy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: NHeikki Krogerus <heikki.krogerus@linux.intel.com> Tested-by: NFerry Toth <fntoth@gmail.com> Cc: 5.9+ <stable@vger.kernel.org> # 5.9+ Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
- 15 10月, 2020 1 次提交
-
-
由 Mauro Carvalho Chehab 提交于
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: NMauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
- 14 10月, 2020 1 次提交
-
-
由 Dan Williams 提交于
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: NDan Williams <dan.j.williams@intel.com> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Reviewed-by: NGreg 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: NLinus Torvalds <torvalds@linux-foundation.org>
-
- 02 10月, 2020 3 次提交
-
-
由 Joe Perches 提交于
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: NJoe Perches <joe@perches.com> Link: https://lore.kernel.org/r/8bc24444fe2049a9b2de6127389b57edfdfe324d.1600285923.git.joe@perches.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Joe Perches 提交于
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: NJoe Perches <joe@perches.com> Link: https://lore.kernel.org/r/5d606519698ce4c8f1203a2b35797d8254c6050a.1600285923.git.joe@perches.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Joe Perches 提交于
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: NJoe Perches <joe@perches.com> Link: https://lore.kernel.org/r/3d033c33056d88bbe34d4ddb62afd05ee166ab9a.1600285923.git.joe@perches.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 22 9月, 2020 1 次提交
-
-
由 John Ogness 提交于
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: NJohn Ogness <john.ogness@linutronix.de> Reviewed-by: NPetr Mladek <pmladek@suse.com> Signed-off-by: NPetr Mladek <pmladek@suse.com> Link: https://lore.kernel.org/r/87mu1jl6ne.fsf@jogness.linutronix.de
-
- 18 9月, 2020 1 次提交
-
-
由 Jim Quinlan 提交于
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: NJim Quinlan <james.quinlan@broadcom.com> [hch: various interface cleanups] Signed-off-by: NChristoph Hellwig <hch@lst.de> Reviewed-by: NMathieu Poirier <mathieu.poirier@linaro.org> Tested-by: NMathieu Poirier <mathieu.poirier@linaro.org> Tested-by: NNathan Chancellor <natechancellor@gmail.com>
-
- 17 9月, 2020 1 次提交
-
-
由 Oliver Neukum 提交于
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: NOliver Neukum <oneukum@suse.com> Link: https://lore.kernel.org/r/20200916191544.5104-1-oneukum@suse.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 05 9月, 2020 2 次提交
-
-
由 Saravana Kannan 提交于
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: NDong Aisheng <dongas86@gmail.com> Signed-off-by: NSaravana Kannan <saravanak@google.com> Tested-by: NPeng Fan <peng.fan@nxp.com> Link: https://lore.kernel.org/r/20200901184445.1736658-1-saravanak@google.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Michał Mirosław 提交于
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: NMichał Mirosław <mirq-linux@rere.qmqm.pl> Link: https://lore.kernel.org/r/ea3f973e4708919573026fdce52c264db147626d.1598630856.git.mirq-linux@rere.qmqm.plSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 22 8月, 2020 1 次提交
-
-
由 Heikki Krogerus 提交于
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: NHeikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
- 30 7月, 2020 2 次提交
-
-
由 Andrzej Hajda 提交于
/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: NAndrzej Hajda <a.hajda@samsung.com> Reviewed-by: NMark Brown <broonie@kernel.org> Reviewed-by: NJavier Martinez Canillas <javierm@redhat.com> Reviewed-by: NAndy Shevchenko <andy.shevchenko@gmail.com> Reviewed-by: NRafael J. Wysocki <rafael@kernel.org> Link: https://lore.kernel.org/r/20200713144324.23654-3-a.hajda@samsung.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Andrzej Hajda 提交于
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: NAndrzej Hajda <a.hajda@samsung.com> Reviewed-by: NRafael J. Wysocki <rafael@kernel.org> Reviewed-by: NMark Brown <broonie@kernel.org> Reviewed-by: NAndy Shevchenko <andy.shevchenko@gmail.com> Link: https://lore.kernel.org/r/20200713144324.23654-2-a.hajda@samsung.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 25 7月, 2020 1 次提交
-
-
由 Saravana Kannan 提交于
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: NSaravana Kannan <saravanak@google.com> Link: https://lore.kernel.org/r/20200724180523.1393383-1-saravanak@google.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 23 7月, 2020 1 次提交
-
-
由 Saravana Kannan 提交于
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: NMarek Szyprowski <m.szyprowski@samsung.com> Reported-by: NGuenter Roeck <linux@roeck-us.net> Reported-by: NNaresh Kamboju <naresh.kamboju@linaro.org> Signed-off-by: NSaravana Kannan <saravanak@google.com> Tested-by: NMarek Szyprowski <m.szyprowski@samsung.com> Tested-by: NGuenter Roeck <linux@roeck-us.net> Link: https://lore.kernel.org/r/20200716214523.2924704-1-saravanak@google.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 10 7月, 2020 5 次提交
-
-
由 Saravana Kannan 提交于
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: NSaravana Kannan <saravanak@google.com> Link: https://lore.kernel.org/r/20200521191800.136035-4-saravanak@google.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Saravana Kannan 提交于
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: NSaravana Kannan <saravanak@google.com> Link: https://lore.kernel.org/r/20200521191800.136035-2-saravanak@google.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Saravana Kannan 提交于
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: NSaravana Kannan <saravanak@google.com> Tested-by: NGeert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/r/20200701194259.3337652-4-saravanak@google.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Saravana Kannan 提交于
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: NSaravana Kannan <saravanak@google.com> Reviewed-by: NRafael J. Wysocki <rafael@kernel.org> Tested-by: NGeert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/r/20200701194259.3337652-3-saravanak@google.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Saravana Kannan 提交于
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: NSaravana Kannan <saravanak@google.com> Tested-by: NGeert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/r/20200701194259.3337652-2-saravanak@google.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 18 6月, 2020 1 次提交
-
-
由 Saravana Kannan 提交于
DT implementation of fw_devlink needs this function to detect cycles. So make it available. Signed-off-by: NSaravana Kannan <saravanak@google.com> Tested-by: NJohn Stultz <john.stultz@linaro.org> Signed-off-by: NRob Herring <robh@kernel.org>
-
- 27 5月, 2020 1 次提交
-
-
由 Saravana Kannan 提交于
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: NMichael Walle <michael@walle.cc> Tested-by: NMichael Walle <michael@walle.cc> Signed-off-by: NSaravana Kannan <saravanak@google.com> Reviewed-by: NRafael J. Wysocki <rrafael.j.wysocki@intel.com> Link: https://lore.kernel.org/r/20200526220928.49939-1-saravanak@google.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 21 5月, 2020 2 次提交
-
-
由 Saravana Kannan 提交于
That variable is no longer necessary. Remove it and also fix a minor typo in comments. Signed-off-by: NSaravana Kannan <saravanak@google.com> Link: https://lore.kernel.org/r/20200520034824.79049-2-saravanak@google.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Saravana Kannan 提交于
Commit 21c27f06 ("driver core: Fix SYNC_STATE_ONLY device link implementation") didn't completely fix STATELESS + SYNC_STATE_ONLY handling. What looks like an optimization in that commit is actually a bug that causes an if condition to always take the else path. This prevents reordering of devices in the dpm_list when a DL_FLAG_STATELESS device link is create on top of an existing DL_FLAG_SYNC_STATE_ONLY device link. Fixes: 21c27f06 ("driver core: Fix SYNC_STATE_ONLY device link implementation") Signed-off-by: NSaravana Kannan <saravanak@google.com> Cc: stable <stable@vger.kernel.org> Reviewed-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com> Link: https://lore.kernel.org/r/20200520043626.181820-1-saravanak@google.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 19 5月, 2020 1 次提交
-
-
由 Saravana Kannan 提交于
When SYNC_STATE_ONLY support was added in commit 05ef983e ("driver core: Add device link support for SYNC_STATE_ONLY flag"), device_link_add() incorrectly skipped adding the new SYNC_STATE_ONLY device link to the supplier's and consumer's "device link" list. This causes multiple issues: - The device link is lost forever from driver core if the caller didn't keep track of it (caller typically isn't expected to). This is a memory leak. - The device link is also never visible to any other code path after device_link_add() returns. If we fix the "device link" list handling, that exposes a bunch of issues. 1. The device link "status" state management code rightfully doesn't handle the case where a DL_FLAG_MANAGED device link exists between a supplier and consumer, but the consumer manages to probe successfully before the supplier. The addition of DL_FLAG_SYNC_STATE_ONLY links break this assumption. This causes device_links_driver_bound() to throw a warning when this happens. Since DL_FLAG_SYNC_STATE_ONLY device links are mainly used for creating proxy device links for child device dependencies and aren't useful once the consumer device probes successfully, this patch just deletes DL_FLAG_SYNC_STATE_ONLY device links once its consumer device probes. This way, we avoid the warning, free up some memory and avoid complicating the device links "status" state management code. 2. Creating a DL_FLAG_STATELESS device link between two devices that already have a DL_FLAG_SYNC_STATE_ONLY device link will result in the DL_FLAG_STATELESS flag not getting set correctly. This patch also fixes this. Lastly, this patch also fixes minor whitespace issues. Cc: stable@vger.kernel.org Fixes: 05ef983e ("driver core: Add device link support for SYNC_STATE_ONLY flag") Signed-off-by: NSaravana Kannan <saravanak@google.com> Reviewed-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com> Link: https://lore.kernel.org/r/20200519063000.128819-1-saravanak@google.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 15 5月, 2020 3 次提交
-
-
由 Saravana Kannan 提交于
The amount of time spent parsing fwnodes of devices can become really high if the devices are added in an non-ideal order. Worst case can be O(N^2) when N devices are added. But this can be optimized to O(N) by adding all the devices and then parsing all their fwnodes in one batch. This commit adds fw_devlink_pause() and fw_devlink_resume() to allow doing this. Signed-off-by: NSaravana Kannan <saravanak@google.com> Link: https://lore.kernel.org/r/20200515053500.215929-4-saravanak@google.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Saravana Kannan 提交于
Commit 4dbe191c ("driver core: Add device links from fwnode only for the primary device") skipped linking a fwnode's secondary device to the suppliers listed in its fwnode. However, a fwnode's secondary device can't be found using get_dev_from_fwnode(). So, there's no point in trying to see if devices waiting for suppliers might want to link to a fwnode's secondary device. This commit removes that unnecessary step for devices that aren't a fwnode's primary device and also moves the code to a more appropriate part of the file. Signed-off-by: NSaravana Kannan <saravanak@google.com> Link: https://lore.kernel.org/r/20200515053500.215929-3-saravanak@google.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Saravana Kannan 提交于
This commit just moves around code to match the general organization of the file. Signed-off-by: NSaravana Kannan <saravanak@google.com> Link: https://lore.kernel.org/r/20200515053500.215929-2-saravanak@google.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 10 5月, 2020 1 次提交
-
-
由 Christoph Hellwig 提交于
All external users of device_create_vargs are gone, so remove it and open code it in the only caller. Signed-off-by: NChristoph Hellwig <hch@lst.de> Reviewed-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Reviewed-by: NJan Kara <jack@suse.cz> Signed-off-by: NJens Axboe <axboe@kernel.dk>
-
- 05 5月, 2020 1 次提交
-
-
由 Saravana Kannan 提交于
This reverts commit 18555cb6. The reason[1] for the original revert has now been fixed by commit 00b24755 ("driver core: Fix handling of fw_devlink=permissive"). So, this patch reverts the revert. Marek has also tested this patch with the fix mentioned above and confirmed that the issue has been fixed. [1] - https://lore.kernel.org/lkml/CAGETcx8nbz-J1gLvoEKE_HgCcVGyV2o8rZeq_USFKM6=s7WmNg@mail.gmail.com/T/#m12dfb5dfd23805b84c49f4bb2238a8cce436c2f7 [2] - https://lore.kernel.org/lkml/CAGETcx8nbz-J1gLvoEKE_HgCcVGyV2o8rZeq_USFKM6=s7WmNg@mail.gmail.com/T/#m2408a6ce098b2ebf583ca8534329695923ae57feTested-by: NMarek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: NSaravana Kannan <saravanak@google.com> Link: https://lore.kernel.org/r/20200428192006.109006-1-saravanak@google.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 28 4月, 2020 1 次提交
-
-
由 Saravana Kannan 提交于
When commit 8375e74f ("driver core: Add fw_devlink kernel commandline option") added fw_devlink, it didn't implement "permissive" mode correctly. That commit got the device links flags correct to make sure unprobed suppliers don't block the probing of a consumer. However, if a consumer is waiting for mandatory suppliers to register, that could still block a consumer from probing. This commit fixes that by making sure in permissive mode, all suppliers to a consumer are treated as a optional suppliers. So, even if a consumer is waiting for suppliers to register and link itself (using the DL_FLAG_SYNC_STATE_ONLY flag) to the supplier, the consumer is never blocked from probing. Fixes: 8375e74f ("driver core: Add fw_devlink kernel commandline option") Reported-by: NMarek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: NSaravana Kannan <saravanak@google.com> Tested-by: NMarek Szyprowski <m.szyprowski@samsung.com> Link: https://lore.kernel.org/r/20200331022832.209618-1-saravanak@google.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 21 4月, 2020 1 次提交
-
-
由 Mauro Carvalho Chehab 提交于
Some filesystem references got broken by a previous patch series I submitted. Address those. Signed-off-by: NMauro Carvalho Chehab <mchehab+huawei@kernel.org> Acked-by: David Sterba <dsterba@suse.com> # fs/affs/Kconfig Link: https://lore.kernel.org/r/57318c53008dbda7f6f4a5a9e5787f4d37e8565a.1586881715.git.mchehab+huawei@kernel.orgSigned-off-by: NJonathan Corbet <corbet@lwn.net>
-
- 20 4月, 2020 1 次提交
-
-
由 Andy Shevchenko 提交于
Some drivers when compiled as modules may need to set secondary firmware node. Export set_secondary_fwnode() to make it possible without code duplication. Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by: NRafael J. Wysocki <rjw@rjwysocki.net> Reviewed-by: NHans de Goede <hdegoede@redhat.com> Tested-by: NHans de Goede <hdegoede@redhat.com> Reviewed-by: NHeikki Krogerus <heikki.krogerus@linux.intel.com>
-