- 31 Jan, 2019 12 commits
-
-
Sergei Shtylyov authored
devm_ioremap_resource() prefers calling devm_request_mem_region() with a resource name instead of a device name -- this looks pretty iff a resource name isn't specified via a device tree with a "reg-names" property (in this case, a resource name is set to a device node's full name), but if it is, it doesn't really scale since these names are only unique to a given device node, not globally; so, looking at the output of 'cat /proc/iomem', you do not have an idea which memory region belongs to which device (see "dirmap", "regs", and "wbuf" lines below): 08000000-0bffffff : dirmap 48000000-bfffffff : System RAM 48000000-48007fff : reserved 48080000-48b0ffff : Kernel code 48b10000-48b8ffff : reserved 48b90000-48c7afff : Kernel data bc6a4000-bcbfffff : reserved bcc0f000-bebfffff : reserved bec0e000-bec0efff : reserved bec11000-bec11fff : reserved bec12000-bec14fff : reserved bec15000-bfffffff : reserved e6050000-e605004f : gpio@e6050000 e6051000-e605104f : gpio@e6051000 e6052000-e605204f : gpio@e6052000 e6053000-e605304f : gpio@e6053000 e6054000-e605404f : gpio@e6054000 e6055000-e605504f : gpio@e6055000 e6060000-e606050b : pin-controller@e6060000 e6e60000-e6e6003f : e6e60000.serial e7400000-e7400fff : ethernet@e7400000 ee200000-ee2001ff : regs ee208000-ee2080ff : wbuf I think that devm_request_mem_region() should be called with dev_name() despite the region names won't look as pretty as before (however, we gain more consistency with e.g. the serial driver: 08000000-0bffffff : ee200000.rpc 48000000-bfffffff : System RAM 48000000-48007fff : reserved 48080000-48b0ffff : Kernel code 48b10000-48b8ffff : reserved 48b90000-48c7afff : Kernel data bc6a4000-bcbfffff : reserved bcc0f000-bebfffff : reserved bec0e000-bec0efff : reserved bec11000-bec11fff : reserved bec12000-bec14fff : reserved bec15000-bfffffff : reserved e6050000-e605004f : e6050000.gpio e6051000-e605104f : e6051000.gpio e6052000-e605204f : e6052000.gpio e6053000-e605304f : e6053000.gpio e6054000-e605404f : e6054000.gpio e6055000-e605504f : e6055000.gpio e6060000-e606050b : e6060000.pin-controller e6e60000-e6e6003f : e6e60000.serial e7400000-e7400fff : e7400000.ethernet ee200000-ee2001ff : ee200000.rpc ee208000-ee2080ff : ee200000.rpc Fixes: 72f8c0bf ("lib: devres: add convenience function to remap a resource") Signed-off-by:
Sergei Shtylyov <sergei.shtylyov@cogentembedded.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Mathieu Malaterre authored
Silence warnings (triggered at W=1) by adding relevant __printf attributes. drivers/base/cpu.c:432:2: warning: function '__cpu_device_create' might be a candidate for 'gnu_printf' format attribute [-Wsuggest-attribute=format] Signed-off-by:
Mathieu Malaterre <malat@debian.org> Signed-off-by:
-
Richard Gong authored
Add a Kconfig dependency to ensure Intel Stratix10 service layer driver can be built only on the platform that supports it. Signed-off-by:
Richard Gong <richard.gong@intel.com> Signed-off-by:
-
Alexander Duyck authored
The current async_probe test code is only testing one device allocated prior to driver load and only loading one device afterwards. Instead of doing things this way it makes much more sense to load one device per CPU in order to actually stress the async infrastructure. By doing this we should see delays significantly increase in the event of devices being serialized. In addition I have updated the test to verify that we are trying to place the work on the correct NUMA node when we are running in async mode. By doing this we can verify the best possible outcome for device and driver load times. I have added a timeout value that is used to disable the sleep and instead cause the probe routine to report an error indicating it timed out. By doing this we limit the maximum runtime for the test to 20 seconds or less. The last major change in this set is that I have gone through and tuned it for handling the massive number of possible events that will be scheduled. Instead of reporting the sleep for each individual device it is moved to only being displayed if we enable debugging. With this patch applied below are what a failing test and a passing test should look like. I elided a few hundred lines in the failing test that were duplicated since the system I was testing on had a massive number of CPU cores: -- Failing -- [ 243.524697] test_async_driver_probe: registering first set of asynchronous devices... [ 243.535625] test_async_driver_probe: registering asynchronous driver... [ 243.543038] test_async_driver_probe: registration took 0 msecs [ 243.549559] test_async_driver_probe: registering second set of asynchronous devices... [ 243.568350] platform test_async_driver.447: registration took 9 msecs [ 243.575544] test_async_driver_probe: registering first synchronous device... [ 243.583454] test_async_driver_probe: registering synchronous driver... [ 248.825920] test_async_driver_probe: registration took 5235 msecs [ 248.825922] test_async_driver_probe: registering second synchronous device... [ 248.825928] test_async_driver test_async_driver.443: NUMA node mismatch 3 != 1 [ 248.825932] test_async_driver test_async_driver.445: NUMA node mismatch 3 != 1 [ 248.825935] test_async_driver test_async_driver.446: NUMA node mismatch 3 != 1 [ 248.825939] test_async_driver test_async_driver.440: NUMA node mismatch 3 != 1 [ 248.825943] test_async_driver test_async_driver.441: NUMA node mismatch 3 != 1 ... [ 248.827150] test_async_driver test_async_driver.229: NUMA node mismatch 0 != 1 [ 248.827158] test_async_driver test_async_driver.228: NUMA node mismatch 0 != 1 [ 248.827220] test_async_driver test_async_driver.281: NUMA node mismatch 2 != 1 [ 248.827229] test_async_driver test_async_driver.282: NUMA node mismatch 2 != 1 [ 248.827240] test_async_driver test_async_driver.280: NUMA node mismatch 2 != 1 [ 253.945834] test_async_driver test_async_driver.1: NUMA node mismatch 0 != 1 [ 253.945878] test_sync_driver test_sync_driver.1: registration took 5119 msecs [ 253.961693] test_async_driver_probe: async events still pending, forcing timeout and synchronize [ 259.065839] test_async_driver test_async_driver.2: NUMA node mismatch 0 != 1 [ 259.073786] test_async_driver test_async_driver.3: async probe took too long [ 259.081669] test_async_driver test_async_driver.3: NUMA node mismatch 0 != 1 [ 259.089569] test_async_driver test_async_driver.4: async probe took too long [ 259.097451] test_async_driver test_async_driver.4: NUMA node mismatch 0 != 1 [ 259.105338] test_async_driver test_async_driver.5: async probe took too long [ 259.113204] test_async_driver test_async_driver.5: NUMA node mismatch 0 != 1 [ 259.121089] test_async_driver test_async_driver.6: async probe took too long [ 259.128961] test_async_driver test_async_driver.6: NUMA node mismatch 0 != 1 [ 259.136850] test_async_driver test_async_driver.7: async probe took too long ... [ 262.124062] test_async_driver test_async_driver.221: async probe took too long [ 262.132130] test_async_driver test_async_driver.221: NUMA node mismatch 3 != 1 [ 262.140206] test_async_driver test_async_driver.222: async probe took too long [ 262.148277] test_async_driver test_async_driver.222: NUMA node mismatch 3 != 1 [ 262.156351] test_async_driver test_async_driver.223: async probe took too long [ 262.164419] test_async_driver test_async_driver.223: NUMA node mismatch 3 != 1 [ 262.172630] test_async_driver_probe: Test failed with 222 errors and 336 warnings -- Passing -- [ 105.419247] test_async_driver_probe: registering first set of asynchronous devices... [ 105.432040] test_async_driver_probe: registering asynchronous driver... [ 105.439718] test_async_driver_probe: registration took 0 msecs [ 105.446239] test_async_driver_probe: registering second set of asynchronous devices... [ 105.477986] platform test_async_driver.447: registration took 22 msecs [ 105.485276] test_async_driver_probe: registering first synchronous device... [ 105.493169] test_async_driver_probe: registering synchronous driver... [ 110.597981] test_async_driver_probe: registration took 5097 msecs [ 110.604806] test_async_driver_probe: registering second synchronous device... [ 115.707490] test_sync_driver test_sync_driver.1: registration took 5094 msecs [ 115.715478] test_async_driver_probe: completed successfully Signed-off-by:
Alexander Duyck <alexander.h.duyck@linux.intel.com> Signed-off-by:
-
Alexander Duyck authored
Force the device registration for nvdimm devices to be closer to the actual device. This is achieved by using either the NUMA node ID of the region, or of the parent. By doing this we can have everything above the region based on the region, and everything below the region based on the nvdimm bus. By guaranteeing NUMA locality I see an improvement of as high as 25% for per-node init of a system with 12TB of persistent memory. Reviewed-by:
Bart Van Assche <bvanassche@acm.org> Signed-off-by:
-
Alexander Duyck authored
Use the device specific version of the async_schedule commands to defer various tasks related to power management. By doing this we should see a slight improvement in performance as any device that is sensitive to latency/locality in the setup will now be initializing on the node closest to the device. Reviewed-by:
Dan Williams <dan.j.williams@intel.com> Reviewed-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by:
-
Alexander Duyck authored
Call the asynchronous probe routines on a CPU local to the device node. By doing this we should be able to improve our initialization time significantly as we can avoid having to access the device from a remote node which may introduce higher latency. For example, in the case of initializing memory for NVDIMM this can have a significant impact as initialing 3TB on remote node can take up to 39 seconds while initialing it on a local node only takes 23 seconds. It is situations like this where we will see the biggest improvement. Reviewed-by:
-
Alexander Duyck authored
Introduce four new variants of the async_schedule_ functions that allow scheduling on a specific NUMA node. The first two functions are async_schedule_near and async_schedule_near_domain end up mapping to async_schedule and async_schedule_domain, but provide NUMA node specific functionality. They replace the original functions which were moved to inline function definitions that call the new functions while passing NUMA_NO_NODE. The second two functions are async_schedule_dev and async_schedule_dev_domain which provide NUMA specific functionality when passing a device as the data member and that device has a NUMA node other than NUMA_NO_NODE. The main motivation behind this is to address the need to be able to schedule device specific init work on specific NUMA nodes in order to improve performance of memory initialization. I have seen a significant improvement in initialziation time for persistent memory as a result of this approach. In the case of 3TB of memory on a single node the initialization time in the worst case went from 36s down to about 26s for a 10s improvement. As such the data shows a general benefit for affinitizing the async work to the node local to the device. Reviewed-by:
-
Alexander Duyck authored
Provide a new function, queue_work_node, which is meant to schedule work on a "random" CPU of the requested NUMA node. The main motivation for this is to help assist asynchronous init to better improve boot times for devices that are local to a specific node. For now we just default to the first CPU that is in the intersection of the cpumask of the node and the online cpumask. The only exception is if the CPU is local to the node we will just use the current CPU. This should work for our purposes as we are currently only using this for unbound work so the CPU will be translated to a node anyway instead of being directly used. As we are only using the first CPU to represent the NUMA node for now I am limiting the scope of the function so that it can only be used with unbound workqueues. Acked-by:
Tejun Heo <tj@kernel.org> Reviewed-by:
-
Alexander Duyck authored
Probe devices asynchronously instead of the driver. This results in us seeing the same behavior if the device is registered before the driver or after. This way we can avoid serializing the initialization should the driver not be loaded until after the devices have already been added. The motivation behind this is that if we have a set of devices that take a significant amount of time to load we can greatly reduce the time to load by processing them in parallel instead of one at a time. In addition, each device can exist on a different node so placing a single thread on one CPU to initialize all of the devices for a given driver can result in poor performance on a system with multiple nodes. This approach can reduce the time needed to scan SCSI LUNs significantly. The only way to realize that speedup is by enabling more concurrency which is what is achieved with this patch. To achieve this it was necessary to add a new member "async_driver" to the device_private structure to store the driver pointer while we wait on the deferred probe call. Reviewed-by:
-
Alexander Duyck authored
Try to consolidate all of the locking and unlocking of both the parent and device when attaching or removing a driver from a given device. To do that I first consolidated the lock pattern into two functions __device_driver_lock and __device_driver_unlock. After doing that I then created functions specific to attaching and detaching the driver while acquiring these locks. By doing this I was able to reduce the number of spots where we touch need_parent_lock from 12 down to 4. This patch should produce no functional changes, it is meant to be a code clean-up/consolidation only. Reviewed-by:
Luis Chamberlain <mcgrof@kernel.org> Reviewed-by:
-
Alexander Duyck authored
Add an additional bit flag to the device_private struct named "dead". This additional flag provides a guarantee that when a device_del is executed on a given interface an async worker will not attempt to attach the driver following the earlier device_del call. Previously this guarantee was not present and could result in the device_del call attempting to remove a driver from an interface only to have the async worker attempt to probe the driver later when it finally completes the asynchronous probe call. One additional change added was that I pulled the check for dev->driver out of the __device_attach_driver call and instead placed it in the __device_attach_async_helper call. This was motivated by the fact that the only other caller of this, __device_attach, had already taken the device_lock() and checked for dev->driver. Instead of testing for this twice in this path it makes more sense to just consolidate the dev->dead and dev->driver checks together into one set of checks. Reviewed-by:
-
- 22 Jan, 2019 19 commits
-
-
Yong Wu authored
DL_FLAG_AUTOREMOVE_CONSUMER/SUPPLIER means "Remove the link automatically on consumer/supplier driver unbind", that means we should remove whole the device_link when there is no this driver no matter what the ref_count of the link is. CC: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
Yong Wu <yong.wu@mediatek.com> Signed-off-by:
-
Jerome Brunet authored
On platforms making a fair use of regulators, the dev_info() messages coming from the device link function are a bit too verbose. The amount of message will increase further with the clock framework joining the device link party. These messages looks valuable for people debugging device link related issues, so dev_dbg() looks more appropriate than dev_info(). Signed-off-by:
Jerome Brunet <jbrunet@baylibre.com> Acked-by:
Kevin Hilman <khilman@baylibre.com> Reviewed-by:
-
Bo YU authored
There is currently a missing terminating newline in non-switch case match when msg == NULL Signed-off-by:
Bo YU <tsu.yubo@gmail.com> Reviewed-by:
-
Bo YU authored
Repalce printk with pr_warn in kobject_synth_uevent and replace printk with pr_err in uevent_net_init to make both consistent with other code in kobject_uevent.c Signed-off-by:
-
Eric Biggers authored
kset_get_ownership() is only used in lib/kobject.c, so make it 'static'. Signed-off-by:
Eric Biggers <ebiggers@google.com> Reviewed-by:
-
Greg Kroah-Hartman authored
We are trying to get rid of BUS_ATTR() and the usage of that in rbd.c can be trivially converted to use BUS_ATTR_WO and RO, so use those macros instead. Cc: Sage Weil <sage@redhat.com> Cc: Alex Elder <elder@kernel.org> Cc: Jens Axboe <axboe@kernel.dk> Acked-by:
Ilya Dryomov <idryomov@gmail.com> Signed-off-by:
-
Greg Kroah-Hartman authored
We are trying to get rid of BUS_ATTR() and the usage of that in rio-sysfs.c can be trivially converted to use BUS_ATTR_WO(), so use that instead. Cc: Matt Porter <mporter@kernel.crashing.org> Cc: Alexandre Bounine <alex.bou9@gmail.com> Signed-off-by: -
Greg Kroah-Hartman authored
We are trying to get rid of BUS_ATTR() and the usage of that in ibmebus.c can be trivially converted to use BUS_ATTR_WO(), so use that instead. Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Paul Mackerras <paulus@samba.org> Cc: Tyrel Datwyler <tyreld@linux.vnet.ibm.com> Acked-by: Michael Ellerman <mpe@ellerman.id.au> (powerpc) Signed-off-by: -
Greg Kroah-Hartman authored
We are trying to get rid of BUS_ATTR() and the usage of that in pci-sysfs.c can be trivially converted to use BUS_ATTR_WO(), so use that instead. Cc: Bjorn Helgaas <bhelgaas@google.com> Signed-off-by: -
Greg Kroah-Hartman authored
We are trying to get rid of BUS_ATTR() and the usage of that in pci.c can be trivially converted to use BUS_ATTR_RW(), so use that instead. Cc: Bjorn Helgaas <bhelgaas@google.com> Signed-off-by: -
Greg Kroah-Hartman authored
When calling debugfs functions, there is no need to ever check the return value. The function can work or not, but the code logic should never do something different based on this. Cc: Jaegeuk Kim <jaegeuk@kernel.org> Reviewed-by:
Chao Yu <yuchao0@huawei.com> Cc: linux-f2fs-devel@lists.sourceforge.net Signed-off-by:
-
Sergey Senozhatsky authored
debugfs_use_file_start() and debugfs_use_file_finish() do not exist since commit c9afbec2 ("debugfs: purge obsolete SRCU based removal protection"); tweak debugfs_create_file_unsafe() comment. Signed-off-by:
Sergey Senozhatsky <sergey.senozhatsky@gmail.com> Reviewed-by:
-
Masahiro Yamada authored
Currently, the 'firmware' directory only contains a single Makefile to embed extra firmware into the kernel. Move it to the more relevant place. Signed-off-by:
Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by:
-
Masahiro Yamada authored
The whole code of fallback_table.c is surrounded by #ifdef of CONFIG_FW_LOADER_USER_HELPER. Move the CONFIG_FW_LOADER_USER_HELPER switch to Makefile so that it is not compiled at all when this CONFIG option is disabled. I also removed the confusing comment, "Module or buit-in [sic]". CONFIG_FW_LOADER_USER_HELPER is a boolean option. (If it were a module, CONFIG_FW_LOADER_USER_HELPER_MODULE would be defined instead.) Signed-off-by:
-
Andrey Smirnov authored
(X + 3) & ~3 is the same as ALIGN(X, 4), so replace all of the instances of the formwer in the code with the latter. While at it, introduce a helper variable 'record_size' to avoid duplicating length calculatin code. No functional change intended. Cc: Chris Healy <cphealy@gmail.com> Cc: Kyle McMartin <kyle@kernel.org> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Masahiro Yamada <yamada.masahiro@socionext.com> Cc: David Woodhouse <dwmw2@infradead.org> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: linux-kernel <linux-kernel@vger.kernel.org> Signed-off-by:
Andrey Smirnov <andrew.smirnov@gmail.com> Signed-off-by:
-
Andrey Smirnov authored
We can convert original expression for 'writelen" to use ALIGN as follows: (p->len + 9) & ~3 => (p->len + 6 + 3) & ~3 => ALIGN(p->len + 6, 4) Now, subsituting "p->len + 6" with "p->len + sizeof(p->addr) + sizeof(p->len)" we end up with the same expression as used by kernel couterpart in linux/ihex.h: ALIGN(p->len + sizeof(p->addr) + sizeof(p->len), 4) That is a full size of the record, aligned to 4 bytes. No functional change intended. Cc: Chris Healy <cphealy@gmail.com> Cc: Kyle McMartin <kyle@kernel.org> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Masahiro Yamada <yamada.masahiro@socionext.com> Cc: David Woodhouse <dwmw2@infradead.org> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: linux-kernel <linux-kernel@vger.kernel.org> Signed-off-by: -
Andrey Smirnov authored
Next record calucaltion can be reduced to a much more tivial ALIGN operation as follows: 1. Splitting 5 into 2 + 3 we get next = ((be16_to_cpu(rec->len) + 2 + 3) & ~3) - 2 (1) 2. Using ALIGN macro we reduce (1) to: ALIGN(be16_to_cpu(rec->len) + 2, 4) - 2 (2) 3. Subsituting 'next' in original next record calucation we get: (void *)&rec->data[ALIGN(be16_to_cpu(rec->len) + 2, 4) - 2] (3) 4. Converting array index to pointer arithmetic we convert (3) into: (void *)rec + sizeof(*rec) + ALIGN(be16_to_cpu(rec->len) + 2, 4) - 2 (4) 5. Subsituting sizeof(*rec) with its value, 6, and substracting 2, in (4) we get: (void *)rec + ALIGN(be16_to_cpu(rec->len) + 2, 4) + 4 (5) 6. Since ALIGN(X, 4) + 4 == ALIGN(X + 4, 4), (5) can be converted to: (void *)rec + ALIGN(be16_to_cpu(rec->len) + 6, 4) (6) 5. Subsituting 6 in (6) to sizeof(*rec) we get: (void *)rec + ALIGN(be16_to_cpu(rec->len) + sizeof(*rec), 4) (7) Using expression (7) should make it more clear that next record is located by adding full size of the current record (payload + auxiliary data) aligned to 4 bytes, to the location of the current one. No functional change intended. Cc: Chris Healy <cphealy@gmail.com> Cc: Kyle McMartin <kyle@kernel.org> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Masahiro Yamada <yamada.masahiro@socionext.com> Cc: David Woodhouse <dwmw2@infradead.org> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: linux-kernel <linux-kernel@vger.kernel.org> Signed-off-by:
-
Andrey Smirnov authored
When verifying the validity of IHEX file we need to make sure that zero-length record we found is located at the end of the file. Not doing that could result in an invalid file with a bogus zero-length in the middle short-circuiting the check and being reported as valid. Cc: Chris Healy <cphealy@gmail.com> Cc: Kyle McMartin <kyle@kernel.org> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Masahiro Yamada <yamada.masahiro@socionext.com> Cc: David Woodhouse <dwmw2@infradead.org> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: linux-kernel <linux-kernel@vger.kernel.org> Signed-off-by:
-
Andrey Smirnov authored
Convert both ihex_validate_fw() and ihex_next_binrec() to use a helper function to calculate next record offest. This way we only have one place implementing next record offset calculation logic. No functional change intended. Cc: Chris Healy <cphealy@gmail.com> Cc: Kyle McMartin <kyle@kernel.org> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Masahiro Yamada <yamada.masahiro@socionext.com> Cc: David Woodhouse <dwmw2@infradead.org> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: linux-kernel <linux-kernel@vger.kernel.org> Signed-off-by:
-
- 18 Jan, 2019 2 commits
-
-
Wei Yang authored
As the description of struct device_private says, it stores data which is private to driver core. And it already has similar fields like: knode_parent, knode_driver, knode_driver and knode_bus. This look it is more proper to put knode_class together with those fields to make it private to driver core. This patch move device->knode_class to device_private to make it comply with code convention. Signed-off-by:
Wei Yang <richardw.yang@linux.intel.com> Reviewed-by:
-
Stephen Martin authored
Fixed a coding style issue. Signed-off-by:
Stephen Martin <lockwood@opperline.com> Signed-off-by:
-
- 15 Jan, 2019 1 commit
-
-
Greg Kroah-Hartman authored
We want the driver core changes in that branch in here to build on top of. Signed-off-by:
-
- 13 Jan, 2019 6 commits
-
-
Linus Torvalds authored
-
Jonathan Neuschäfer authored
UNAME26 is a mechanism to report Linux's version as 2.6.x, for compatibility with old/broken software. Due to the way it is implemented, it would have to be updated after 5.0, to keep the resulting versions unique. Linus Torvalds argued: "Do we actually need this? I'd rather let it bitrot, and just let it return random versions. It will just start again at 2.4.60, won't it? Anybody who uses UNAME26 for a 5.x kernel might as well think it's still 4.x. The user space is so old that it can't possibly care about differences between 4.x and 5.x, can it? The only thing that matters is that it shows "2.4.<largeenough>", which it will do regardless" Signed-off-by:
Jonathan Neuschäfer <j.neuschaefer@gmx.net> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-socLinus Torvalds authored
Pull ARM SoC fixes from Olof Johansson: "A bigger batch than I anticipated this week, for two reasons: - Some fallout on Davinci from board file -> DTB conversion, that also includes a few longer-standing fixes (i.e. not recent regressions). - drivers/reset material that has been in linux-next for a while, but didn't get sent to us until now for a variety of reasons (maintainer out sick, holidays, etc). There's a functional dependency in there such that one platform (Altera's SoCFPGA) won't boot without one of the patches; instead of reverting the patch that got merged, I looked at this set and decided it was small enough that I'll pick it up anyway. If you disagree I can revisit with a smaller set. That being said, there's also a handful of the usual stuff: - Fix for a crash on Armada 7K/8K when the kernel touches PSCI-reserved memory - Fix for PCIe reset on Macchiatobin (Armada 8K development board, what this email is sent from in fact :) - Enable a few new-merged modules for Amlogic in arm64 defconfig - Error path fixes on Integrator - Build fix for Renesas and Qualcomm - Initialization fix for Renesas RZ/G2E .. plus a few more fixlets" * tag 'armsoc-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc: (28 commits) ARM: integrator: impd1: use struct_size() in devm_kzalloc() qcom-scm: Include <linux/err.h> header gpio: pl061: handle failed allocations ARM: dts: kirkwood: Fix polarity of GPIO fan lines arm64: dts: marvell: mcbin: fix PCIe reset signal arm64: dts: marvell: armada-ap806: reserve PSCI area ARM: dts: da850-lcdk: Correct the sound card name ARM: dts: da850-lcdk: Correct the audio codec regulators ARM: dts: da850-evm: Correct the sound card name ARM: dts: da850-evm: Correct the audio codec regulators ARM: davinci: omapl138-hawk: fix label names in GPIO lookup entries ARM: davinci: dm644x-evm: fix label names in GPIO lookup entries ARM: davinci: dm355-evm: fix label names in GPIO lookup entries ARM: davinci: da850-evm: fix label names in GPIO lookup entries ARM: davinci: da830-evm: fix label names in GPIO lookup entries arm64: defconfig: enable modules for amlogic s400 sound card reset: uniphier-glue: Add AHCI reset control support in glue layer dt-bindings: reset: uniphier: Add AHCI core reset description reset: uniphier-usb3: Rename to reset-uniphier-glue dt-bindings: reset: uniphier: Replace the expression of USB3 with generic peripherals ... -
git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linuxLinus Torvalds authored
Pull btrfs fixes from David Sterba: - two regression fixes in clone/dedupe ioctls, the generic check callback needs to lock extents properly and wait for io to avoid problems with writeback and relocation - fix deadlock when using free space tree due to block group creation - a recently added check refuses a valid fileystem with seeding device, make that work again with a quickfix, proper solution needs more intrusive changes * tag 'for-5.0-rc1-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux: btrfs: Use real device structure to verify dev extent Btrfs: fix deadlock when using free space tree due to block group creation Btrfs: fix race between reflink/dedupe and relocation Btrfs: fix race between cloning range ending at eof and writeback
-
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-coreLinus Torvalds authored
Pull driver core fixes from Greg KH: "Here is one small sysfs change, and a documentation update for 5.0-rc2 The sysfs change moves from using BUG_ON to WARN_ON, as discussed in an email thread on lkml while trying to track down another driver bug. sysfs should not be crashing and preventing people from seeing where they went wrong. Now it properly recovers and warns the developer. The documentation update removes the use of BUS_ATTR() as the kernel is moving away from this to use the specific BUS_ATTR_RW() and friends instead. There are pending patches in all of the different subsystems to remove the last users of this macro, but for now, don't advertise it should be used anymore to keep new ones from being introduced. Both have been in linux-next with no reported issues" * tag 'driver-core-5.0-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core: Documentation: driver core: remove use of BUS_ATTR sysfs: convert BUG_ON to WARN_ON
-
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/stagingLinus Torvalds authored
Pull staging driver fixes from Greg KH: "Here are some small staging driver fixes for some reported issues. One reverts a patch that was made to the rtl8723bs driver that turned out to not be needed at all as it was a bug in clang. The others fix up some reported issues in the rtl8188eu driver and update the MAINTAINERS file to point to Larry for this driver so he can get the bug reports easier. All have been in linux-next with no reported issues" * tag 'staging-5.0-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging: Revert "staging: rtl8723bs: Mark ACPI table declaration as used" staging: rtl8188eu: Fix module loading from tasklet for WEP encryption staging: rtl8188eu: Fix module loading from tasklet for CCMP encryption MAINTAINERS: Add entry for staging driver r8188eu
-
