- 22 Oct, 2016 25 commits
-
-
Dave Chinner authored
commit 541d48f0 upstream. oss.sgi.com is going away, move contact details over to vger. Signed-off-by:
Dave Chinner <david@fromorbit.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Guilherme G Piccoli authored
commit edfc23ee upstream. Although rare, it's possible to hit PCI error early on device probe, meaning possibly some structs are not entirely initialized, and some might even be completely uninitialized, leading to NULL pointer dereference. The i40e driver currently presents a "bad" behavior if device hits such early PCI error: firstly, the struct i40e_pf might not be attached to pci_dev yet, leading to a NULL pointer dereference on access to pf->state. Even checking if the struct is NULL and avoiding the access in that case isn't enough, since the driver cannot recover from PCI error that early; in our experiments we saw multiple failures on kernel log, like: [549.664] i40e 0007:01:00.1: Initial pf_reset failed: -15 [549.664] i40e: probe of 0007:01:00.1 failed with error -15 [...] [871.644] i40e 0007:01:00.1: The driver for the device stopped because the device firmware failed to init. Try updating your NVM image. [871.644] i40e: probe of 0007:01:00.1 failed with error -32 [...] [872.516] i40e 0007:01:00.0: ARQ: Unknown event 0x0000 ignored Between the first probe failure (error -15) and the second (error -32) another PCI error happened due to the first bad probe. Also, driver started to flood console with those ARQ event messages. This patch will prevent these issues by allowing error recovery mechanism to remove the failed device from the system instead of trying to recover from early PCI errors during device probe. Signed-off-by:
Guilherme G Piccoli <gpiccoli@linux.vnet.ibm.com> Acked-by:
Jacob Keller <jacob.e.keller@intel.com> Tested-by:
Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by:
Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Johannes Weiner authored
commit 3ddf40e8 upstream. Commit 22f2ac51 ("mm: workingset: fix crash in shadow node shrinker caused by replace_page_cache_page()") switched replace_page_cache() from raw radix tree operations to page_cache_tree_insert() but didn't take into account that the latter function, unlike the raw radix tree op, handles mapping->nrpages. As a result, that counter is bumped for each page replacement rather than balanced out even. The mapping->nrpages counter is used to skip needless radix tree walks when invalidating, truncating, syncing inodes without pages, as well as statistics for userspace. Since the error is positive, we'll do more page cache tree walks than necessary; we won't miss a necessary one. And we'll report more buffer pages to userspace than there are. The error is limited to fuse inodes. Fixes: 22f2ac51 ("mm: workingset: fix crash in shadow node shrinker caused by replace_page_cache_page()") Signed-off-by:
Johannes Weiner <hannes@cmpxchg.org> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Miklos Szeredi <miklos@szeredi.hu> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Miklos Szeredi authored
commit a09f99ed upstream. Fuse allowed VFS to set mode in setattr in order to clear suid/sgid on chown and truncate, and (since writeback_cache) write. The problem with this is that it'll potentially restore a stale mode. The poper fix would be to let the filesystems do the suid/sgid clearing on the relevant operations. Possibly some are already doing it but there's no way we can detect this. So fix this by refreshing and recalculating the mode. Do this only if ATTR_KILL_S[UG]ID is set to not destroy performance for writes. This is still racy but the size of the window is reduced. Signed-off-by:
Miklos Szeredi <mszeredi@redhat.com> Signed-off-by:
-
Miklos Szeredi authored
commit 5e2b8828 upstream. Without "default_permissions" the userspace filesystem's lookup operation needs to perform the check for search permission on the directory. If directory does not allow search for everyone (this is quite rare) then userspace filesystem has to set entry timeout to zero to make sure permissions are always performed. Changing the mode bits of the directory should also invalidate the (previously cached) dentry to make sure the next lookup will have a chance of updating the timeout, if needed. Reported-by:
Jean-Pierre André <jean-pierre.andre@wanadoo.fr> Signed-off-by:
-
Miklos Szeredi authored
commit cb3ae6d2 upstream. Make sure userspace filesystem is returning a well formed list of xattr names (zero or more nonzero length, null terminated strings). [Michael Theall: only verify in the nonzero size case] Signed-off-by:
-
Marcin Wojtas authored
commit a0245eb7 upstream. Original commit, which added support for Armada CP110 system controller used global variables for storing all clock information. It worked fine for Armada 7k SoC, with single CP110 block. After dual-CP110 Armada 8k was introduced, the data got overwritten and corrupted. This patch fixes the issue by allocating resources dynamically in the driver probe and storing it as platform drvdata. Fixes: d3da3eae ("clk: mvebu: new driver for Armada CP110 system ...") Signed-off-by:
Marcin Wojtas <mw@semihalf.com> Reviewed-by:
Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by:
Stephen Boyd <sboyd@codeaurora.org> Signed-off-by:
-
Marcin Wojtas authored
commit ad715b26 upstream. Armada CP110 system controller comprises its own routine responsble for registering gate clocks. Among others 'flags' field in struct clk_init_data was not set, using a random values, which may cause an unpredicted behavior. This patch fixes the problem by resetting all fields of clk_init_data before assigning values for all gated clocks of Armada 7k/8k SoCs family. Fixes: d3da3eae ("clk: mvebu: new driver for Armada CP110 system ...") Signed-off-by:
-
Mike Marciniszyn authored
commit 72f53af2 upstream. There is a a bug in defered ack stuff that causes a race with the destroy of a QP. A packet causes a defered ack to be pended by putting the QP into an rcd queue. A return from the driver interrupt processing will process that rcd queue of QPs and attempt to do a direct send of the ack. At this point no locks are held and the above QP could now be put in the reset state in the qp destroy logic. A refcount protects the QP while it is in the rcd queue so it isn't going anywhere yet. If the direct send fails to allocate a pio buffer, hfi1_schedule_send() is called to trigger sending an ack from the send engine. There is no state test in that code path. The refcount is then dropped from the driver.c caller potentially allowing the qp destroy to continue from its refcount wait in parallel with the workqueue scheduling of the qp. Reviewed-by:
Dennis Dalessandro <dennis.dalessandro@intel.com> Signed-off-by:
Mike Marciniszyn <mike.marciniszyn@intel.com> Signed-off-by:
Doug Ledford <dledford@redhat.com> Signed-off-by:
-
Peng Fan authored
commit 85714108 upstream. When dma_common_free_remap, the input parameter 'size' may not be page aligned. And, met kernel warning when doing iommu dma for usb on i.MX8 platform: " WARNING: CPU: 0 PID: 869 at mm/vmalloc.c:70 vunmap_page_range+0x1cc/0x1d0() Modules linked in: CPU: 0 PID: 869 Comm: kworker/u8:2 Not tainted 4.1.12-00444-gc5f9d1d-dirty #147 Hardware name: Freescale i.MX8DV Sabreauto (DT) Workqueue: ci_otg ci_otg_work Call trace: [<ffffffc000089920>] dump_backtrace+0x0/0x124 [<ffffffc000089a54>] show_stack+0x10/0x1c [<ffffffc0006d1e6c>] dump_stack+0x84/0xc8 [<ffffffc0000b4568>] warn_slowpath_common+0x98/0xd0 [<ffffffc0000b4664>] warn_slowpath_null+0x14/0x20 [<ffffffc000170348>] vunmap_page_range+0x1c8/0x1d0 [<ffffffc000170388>] unmap_kernel_range+0x20/0x88 [<ffffffc000460ad0>] dma_common_free_remap+0x74/0x84 [<ffffffc0000940d8>] __iommu_free_attrs+0x9c/0x178 [<ffffffc0005032bc>] ehci_mem_cleanup+0x140/0x194 [<ffffffc000503548>] ehci_stop+0x8c/0xdc [<ffffffc0004e8258>] usb_remove_hcd+0xf0/0x1cc [<ffffffc000516bc0>] host_stop+0x1c/0x58 [<ffffffc000514240>] ci_otg_work+0xdc/0x120 [<ffffffc0000c9c34>] process_one_work+0x134/0x33c [<ffffffc0000c9f78>] worker_thread+0x13c/0x47c [<ffffffc0000cf43c>] kthread+0xd8/0xf0 " For dma_common_pages_remap: dma_common_pages_remap |->get_vm_area_caller |->__get_vm_area_node |->size = PAGE_ALIGN(size); Round up to page aligned So, in dma_common_free_remap, we also need a page aligned size, pass 'PAGE_ALIGN(size)' to unmap_kernel_range. Signed-off-by:
Peng Fan <van.freenix@gmail.com> Signed-off-by:
-
Alexander Usyskin authored
commit e728ae27 upstream. The device lock was unnecessary obtained in bus rescan work before the amthif client search. That causes incorrect lock ordering and task hang: ... [88004.613213] INFO: task kworker/1:14:21832 blocked for more than 120 seconds. ... [88004.645934] Workqueue: events mei_cl_bus_rescan_work ... The correct lock order is cl_bus_lock device_lock me_clients_rwsem Move device_lock into amthif init function that called after me_clients_rwsem is released. This fixes regression introduced by commit: commit 025fb792 ("mei: split amthif client init from end of clients enumeration") Signed-off-by:
Alexander Usyskin <alexander.usyskin@intel.com> Signed-off-by:
Tomas Winkler <tomas.winkler@intel.com> Signed-off-by:
-
Junjie Mao authored
commit 14155caf upstream. Fixes: 4246a0b6 ("block: add a bi_error field to struct bio") Signed-off-by:
Junjie Mao <junjie.mao@enight.me> Acked-by:
David Sterba <dsterba@suse.cz> Signed-off-by:
-
Omar Sandoval authored
commit 6675df31 upstream. There are two separate issues that can lead to corrupted free space trees. 1. The free space tree bitmaps had an endianness issue on big-endian systems which is fixed by an earlier patch in this series. 2. btrfs-progs before v4.7.3 modified filesystems without updating the free space tree. To catch both of these issues at once, we need to force the free space tree to be rebuilt. To do so, add a FREE_SPACE_TREE_VALID compat_ro bit. If the bit isn't set, we know that it was either produced by a broken big-endian kernel or may have been corrupted by btrfs-progs. This also provides us with a way to add rudimentary read-write support for the free space tree to btrfs-progs: it can just clear this bit and have the kernel rebuild the free space tree. Tested-by:
Holger Hoffstätte <holger@applied-asynchrony.com> Tested-by:
Chandan Rajendra <chandan@linux.vnet.ibm.com> Signed-off-by:
Omar Sandoval <osandov@fb.com> Signed-off-by:
David Sterba <dsterba@suse.com> Signed-off-by:
-
Omar Sandoval authored
commit f8d468a1 upstream. We moved the code for creating the free space tree the first time that it's enabled, but didn't move the clearing code along with it. This breaks my (undocumented) intention that `mount -o clear_cache,space_cache=v2` would clear the free space tree and then recreate it. Fixes: 511711af ("btrfs: don't run delayed references while we are creating the free space tree") Tested-by:
-
Omar Sandoval authored
commit 2fe1d551 upstream. In convert_free_space_to_{bitmaps,extents}(), we buffer the free space bitmaps in memory and copy them directly to/from the extent buffers with {read,write}_extent_buffer(). The extent buffer bitmap helpers use byte granularity, which is equivalent to a little-endian bitmap. This means that on big-endian systems, the in-memory bitmaps will be written to disk byte-swapped. To fix this, use byte-granularity for the bitmaps in memory. Fixes: a5ed9182 ("Btrfs: implement the free space B-tree") Tested-by:
-
Christian Lamparter authored
commit 6ee6d1cb upstream. Ben Greear reported: > I see lots of instability as soon as I load up the carl9710 NIC. > My application is going to be poking at it's debugfs files... > > BUG: KASAN: slab-out-of-bounds in carl9170_debugfs_read+0xd5/0x2a0 > [carl9170] at addr 0xffff8801bc1208b0 > Read of size 8 by task btserver/5888 > ======================================================================= > BUG kmalloc-256 (Tainted: G W ): kasan: bad access detected > ----------------------------------------------------------------------- > > INFO: Allocated in seq_open+0x50/0x100 age=2690 cpu=2 pid=772 >... This breakage was caused by the introduction of intermediate fops in debugfs by commit 9fd4dcec ("debugfs: prevent access to possibly dead file_operations at file open") Thankfully, the original/real fops are still available in d_fsdata. Reported-by:
Ben Greear <greearb@candelatech.com> Signed-off-by:
Christian Lamparter <chunkeey@gmail.com> Signed-off-by:
-
Christian Lamparter authored
commit 9c4a45b1 upstream. This patch fixes a crash that happens because b43legacy's debugfs code expects file->f_op to be a pointer to its own b43legacy_debugfs_fops struct. This is no longer the case since commit 9fd4dcec ("debugfs: prevent access to possibly dead file_operations at file open") Reviewed-by:
Nicolai Stange <nicstange@gmail.com> Signed-off-by:
-
Christian Lamparter authored
commit 51b275a6 upstream. This patch fixes a crash that happens because b43's debugfs code expects file->f_op to be a pointer to its own b43_debugfs_fops struct. This is no longer the case since commit 9fd4dcec ("debugfs: prevent access to possibly dead file_operations at file open") Reviewed-by:
-
Christian Lamparter authored
commit 86f0e067 upstream. This patch introduces an accessor which can be used by the users of debugfs (drivers, fs, ...) to get the original file_operations struct. It also removes the REAL_FOPS_DEREF macro in file.c and converts the code to use the public version. Previously, REAL_FOPS_DEREF was only available within the file.c of debugfs. But having a public getter available for debugfs users is important as some drivers (carl9170 and b43) use the pointer of the original file_operations in conjunction with container_of() within their debugfs implementations. Reviewed-by:
-
Vineet Gupta authored
commit cd5d38b0 upstream. Commit d9676fa1 ("ARCv2: Enable LOCKDEP"), changed local_save_flags() to not return raw STATUS32 but encoded in the form such that it could be fed directly to CLRI/SETI instructions. However the STATUS32.E[] was not captured correctly as it corresponds to bits [4:1] in the register and not [3:0] Fixes: d9676fa1 ("ARCv2: Enable LOCKDEP") Cc: Evgeny Voevodin <evgeny.voevodin@intel.com> Signed-off-by:
Vineet Gupta <vgupta@synopsys.com> Signed-off-by:
-
Yuriy Kolerov authored
commit bc0c7ece upstream. In the end of "arc_init_IRQ" STATUS32.IE flag is going to be affected by "flag" instruction but "flag" never touches IE flag on ARCv2. So "kflag" instruction must be used instead of "flag". Signed-off-by:
Yuriy Kolerov <yuriy.kolerov@synopsys.com> Signed-off-by:
-
Andy Shevchenko authored
commit b3965767 upstream. There are calls to serial8250_rpm_{get|put}() in __do_stop_tx_rs485() that are certainly placed in a wrong location. I dunno how it had been tested with runtime PM enabled because it is obvious "sleep in atomic context" error. Besides that serial8250_rpm_get() is called immediately after an IO just happened. It implies that the device is already powered on, see implementation of serial8250_em485_rts_after_send() and serial8250_clear_fifos() for the details. There is no bug have been seen due to, as I can guess, use of auto suspend mode when scheduled transaction to suspend is invoked quite lately than it's needed for a few writes to the port. It might be possible to trigger a warning if stop_tx_timer fires when device is suspended. Refactor the code to use runtime PM only in case of timer function. Fixes: 0c66940d ("tty/serial/8250: fix RS485 half-duplex RX") Cc: "Matwey V. Kornilov" <matwey@sai.msu.ru> Tested-by:
Yegor Yefremov <yegorslists@googlemail.com> Signed-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by:
-
Kefeng Wang authored
commit e16b46f1 upstream. It should check the data->pclk, not data->clk when get apb_pclk. Fixes: c8ed99d4("serial: 8250_dw: Add support for deferred probing") Signed-off-by:
Kefeng Wang <wangkefeng.wang@huawei.com> Tested-by:
-
Richard Genoud authored
commit 0ae9fdef upstream. Since commit 18dfef9c ("serial: atmel: convert to irq handling provided mctrl-gpio"), interrupts from GPIOs are not disabled any more when the serial port is closed, leading to an oops when the one of the input pin is toggled (CTS/DSR/DCD/RNG). This is only the case if those pins are used as GPIOs, i.e. declared like that: usart1: serial@f8020000 { /* CTS and DTS will be handled by GPIO */ status = "okay"; rts-gpios = <&pioB 17 GPIO_ACTIVE_LOW>; cts-gpios = <&pioB 16 GPIO_ACTIVE_LOW>; dtr-gpios = <&pioB 14 GPIO_ACTIVE_LOW>; dsr-gpios = <&pioC 31 GPIO_ACTIVE_LOW>; rng-gpios = <&pioB 12 GPIO_ACTIVE_LOW>; dcd-gpios = <&pioB 15 GPIO_ACTIVE_LOW>; }; That's because modem interrupts used to be freed in atmel_shutdown(). After commit 18dfef9c ("serial: atmel: convert to irq handling provided mctrl-gpio"), this code was just removed. Calling atmel_disable_ms() disables the interrupts and everything works fine again. Tested on at91sam9g35-cm (This patch doesn't apply on -stable kernels, fixes for 4.4 and 4.7 will be sent after this one is applied.) Signed-off-by:
Richard Genoud <richard.genoud@gmail.com> Fixes: 18dfef9c ("serial: atmel: convert to irq handling provided mctrl-gpio") Acked-by:
Nicolas Ferre <nicolas.ferre@atmel.com> Acked-by:
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by:
-
Sascha Hauer authored
commit 4b75f800 upstream. The USR2_DCDIN bit is tested for in register usr1. As the name suggests the usr2 register should be used instead. This fixes reading the Carrier detect status. Signed-off-by:
Sascha Hauer <s.hauer@pengutronix.de> Fixes: 90ebc483 ("serial: imx: repair and complete handshaking") Acked-by:
Fabio Estevam <fabio.estevam@nxp.com> Signed-off-by:
-
- 20 Oct, 2016 5 commits
-
-
Greg Kroah-Hartman authored
-
Linus Torvalds authored
commit 19be0eaf upstream. This is an ancient bug that was actually attempted to be fixed once (badly) by me eleven years ago in commit 4ceb5db9 ("Fix get_user_pages() race for write access") but that was then undone due to problems on s390 by commit f33ea7f4 ("fix get_user_pages bug"). In the meantime, the s390 situation has long been fixed, and we can now fix it by checking the pte_dirty() bit properly (and do it better). The s390 dirty bit was implemented in abf09bed ("s390/mm: implement software dirty bits") which made it into v3.9. Earlier kernels will have to look at the page state itself. Also, the VM has become more scalable, and what used a purely theoretical race back then has become easier to trigger. To fix it, we introduce a new internal FOLL_COW flag to mark the "yes, we already did a COW" rather than play racy games with FOLL_WRITE that is very fundamental, and then use the pte dirty flag to validate that the FOLL_COW flag is still valid. Reported-and-tested-by:
Phil "not Paul" Oester <kernel@linuxace.com> Acked-by:
Hugh Dickins <hughd@google.com> Reviewed-by:
Michal Hocko <mhocko@suse.com> Cc: Andy Lutomirski <luto@kernel.org> Cc: Kees Cook <keescook@chromium.org> Cc: Oleg Nesterov <oleg@redhat.com> Cc: Willy Tarreau <w@1wt.eu> Cc: Nick Piggin <npiggin@gmail.com> Cc: Greg Thelen <gthelen@google.com> Signed-off-by:
-
Artem Savkov authored
commit 791cc43b upstream. Commit 2a6fba6d "xfs: only return -errno or success from attr ->put_listent" changes the returnvalue of __xfs_xattr_put_listen to 0 in case when there is insufficient space in the buffer assuming that setting context->count to -1 would be enough, but all of the ->put_listent callers only check seen_enough. This results in a failed assertion: XFS: Assertion failed: context->count >= 0, file: fs/xfs/xfs_xattr.c, line: 175 in insufficient buffer size case. This is only reproducible with at least 2 xattrs and only when the buffer gets depleted before the last one. Furthermore if buffersize is such that it is enough to hold the last xattr's name, but not enough to hold the sum of preceeding xattr names listxattr won't fail with ERANGE, but will suceed returning last xattr's name without the first character. The first character end's up overwriting data stored at (context->alist - 1). Signed-off-by:
Artem Savkov <asavkov@redhat.com> Reviewed-by:
Dave Chinner <dchinner@redhat.com> Signed-off-by:
-
Heiner Kallweit authored
commit 0d5644b7 upstream. Runtime PM should be configured already once we call device_add. See also the description in this mail thread https://lists.linuxfoundation.org/pipermail/linux-pm/2009-November/023198.html or the order of calls e.g. in usb_new_device. The changed order also helps to avoid scenarios where runtime pm for &shost->shost_gendev is activated whilst the parent is suspended, resulting in error message "runtime PM trying to activate child device hostx but parent yyy is not active". In addition properly reverse the runtime pm calls in the error path. Signed-off-by:
Heiner Kallweit <hkallweit1@gmail.com> Acked-by:
Alan Stern <stern@rowland.harvard.edu> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by:
-
Laurent Pinchart authored
commit fd44aa9a upstream. The rcar_fcp_enable() function immediately returns successfully when the FCP device pointer is NULL to avoid forcing the users to check the FCP device manually before every call. However, the stub version of the function used when the FCP driver is disabled returns -ENOSYS unconditionally, resulting in a different API contract for the two versions of the function. As a user that requires FCP support will fail at probe time when calling rcar_fcp_get() if the FCP driver is disabled, the stub version of the rcar_fcp_enable() function will only be called with a NULL FCP device. We can thus return 0 unconditionally to align the behaviour with the normal version of the function. Reported-by:
Sergei Shtylyov <sergei.shtylyov@cogentembedded.com> Signed-off-by:
Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Reviewed-by:
Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by:
Mauro Carvalho Chehab <mchehab@s-opensource.com> Signed-off-by:
-
- 16 Oct, 2016 10 commits
-
-
Greg Kroah-Hartman authored
-
Jarkko Sakkinen authored
commit 72fd50e1 upstream. The req_canceled() callback is used by tpm_transmit() periodically to check whether the request has been canceled while it is receiving a response from the TPM. The TPM_CRB_CTRL_CANCEL register was cleared already in the crb_cancel callback, which has two consequences: * Cancel might not happen. * req_canceled() always returns zero. A better place to clear the register is when starting to send a new command. The behavior of TPM_CRB_CTRL_CANCEL is described in the section 5.5.3.6 of the PTP specification. Fixes: 30fc8d13 ("tpm: TPM 2.0 CRB Interface") Signed-off-by:
Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> Signed-off-by:
-
Jarkko Sakkinen authored
commit d4816edf upstream. Unseal and load operations should be done as an atomic operation. This commit introduces unlocked tpm_transmit() so that tpm2_unseal_trusted() can do the locking by itself. Fixes: 0fe54803 ("keys, trusted: seal/unseal with TPM 2.0 chips") Signed-off-by:
Jason Gunthorpe <jgunthorpe@obsidianresearch.com> Signed-off-by:
-
Miklos Szeredi authored
commit e71b9dff upstream. Ima tries to call ->setxattr() on overlayfs dentry after having locked underlying inode, which results in a deadlock. Reported-by:
Krisztian Litkey <kli@iki.fi> Fixes: 4bacc9c9 ("overlayfs: Make f_path always point to the overlay and f_inode to the underlay") Signed-off-by:
-
Dmitry Tunin authored
commit 1144a4ee upstream. BugLink: https://bugs.launchpad.net/bugs/1535802 T: Bus=01 Lev=02 Prnt=02 Port=04 Cnt=01 Dev#= 3 Spd=12 MxCh= 0 D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=04ca ProdID=3011 Rev=00.01 C: #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA I: If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb I: If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb Signed-off-by:
Dmitry Tunin <hanipouspilot@gmail.com> Signed-off-by:
Marcel Holtmann <marcel@holtmann.org> Signed-off-by:
-
Christophe Jaillet authored
commit af48d7bc upstream. We know that 'ret = 0' because it has been tested a few lines above. So, if 'kzalloc' fails, 0 will be returned instead of an error code. Return -ENOMEM instead. Fixes: a0d46a3d ("ARM: cpuidle: Register per cpuidle device") Signed-off-by:
Christophe Jaillet <christophe.jaillet@wanadoo.fr> Acked-by:
Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by:
-
Linus Walleij authored
commit dcf5907e upstream. The Qualcomm SPMI GPIO and MPP lines are problematic: the are fetched from the main MFD driver with platform_get_irq() which means that at this point they will all be assigned the flags set up for the interrupts in the device tree. That is problematic since these are flagged as rising edge and an this point the interrupt descriptor is assigned a rising edge, while the only thing the GPIO/MPP drivers really do is issue irq_get_irqchip_state() on the line to read it out and to provide a .to_irq() helper for *other* IRQ consumers. If another device tree node tries to flag the same IRQ for use as something else than rising edge, the kernel irqdomain core will protest like this: type mismatch, failed to map hwirq-NN for <FOO>! Which is what happens when the device tree defines two contradictory flags for the same interrupt line. To work around this and alleviate the problem, assign 0 as flag for the interrupts taken by the PM GPIO and MPP drivers. This will lead to the flag being unset, and a second consumer requesting rising, falling, both or level interrupts will be respected. This is what the qcom-pm*.dtsi files already do. Switched to using the symbolic name IRQ_TYPE_NONE so that we get this more readable. This misconfiguration was caused by a copy/pasting the APQ8064 set-up, the latter has been fixed in a separate patch. Tested with one of the SPMI GPIOs: after this I can successfully request one of these GPIOs as falling edge from the device tree. Fixes: 0840ea9e ("ARM: dts: add GPIO and MPP to MSM8660 PMIC") Cc: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Cc: Stephen Boyd <sboyd@codeaurora.org> Cc: Björn Andersson <bjorn.andersson@linaro.org> Cc: Ivan T. Ivanov <ivan.ivanov@linaro.org> Cc: John Stultz <john.stultz@linaro.org> Cc: Andy Gross <andy.gross@linaro.org> Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
Andy Gross <andy.gross@linaro.org> Signed-off-by:
-
Linus Walleij authored
commit ca88696e upstream. The Qualcomm PMIC GPIO and MPP lines are problematic: the are fetched from the main MFD driver with platform_get_irq() which means that at this point they will all be assigned the flags set up for the interrupts in the device tree. That is problematic since these are flagged as rising edge and an this point the interrupt descriptor is assigned a rising edge, while the only thing the GPIO/MPP drivers really do is issue irq_get_irqchip_state() on the line to read it out and to provide a .to_irq() helper for *other* IRQ consumers. If another device tree node tries to flag the same IRQ for use as something else than rising edge, the kernel irqdomain core will protest like this: type mismatch, failed to map hwirq-NN for <FOO>! Which is what happens when the device tree defines two contradictory flags for the same interrupt line. To work around this and alleviate the problem, assign 0 as flag for the interrupts taken by the PM GPIO and MPP drivers. This will lead to the flag being unset, and a second consumer requesting rising, falling, both or level interrupts will be respected. This is what the qcom-pm*.dtsi files already do. Switched to using the symbolic name IRQ_TYPE_NONE so that we get this more readable. Fixes: bce36046 ("ARM: dts: apq8064: add pm8921 mpp support") Fixes: 874443fe ("ARM: dts: apq8064: Add pm8921 mfd and its gpio node") Cc: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Cc: Stephen Boyd <sboyd@codeaurora.org> Cc: Björn Andersson <bjorn.andersson@linaro.org> Cc: Ivan T. Ivanov <ivan.ivanov@linaro.org> Cc: John Stultz <john.stultz@linaro.org> Cc: Andy Gross <andy.gross@linaro.org> Signed-off-by:
-
Grzegorz Jaszczyk authored
commit 061492cf upstream. The armada-390.dtsi was broken since the first patch which adds Device Tree files for Armada 39x SoC was introduced. Signed-off-by:
Grzegorz Jaszczyk <jaz@semihalf.com> Acked-by:
Gregory CLEMENT <gregory.clement@free-electrons.com> Fixes 538da83d ("ARM: mvebu: add Device Tree files for Armada 39x SoC and board") Signed-off-by:
-
Russell King authored
commit fb833b1f upstream. Commit 215e362d ("ARM: 8306/1: loop_udelay: remove bogomips value limitation") tried to increase the bogomips limitation, but in doing so messed up udelay such that it always gives about a 5% error in the delay, even if we use a timer. The calculation is: loops = UDELAY_MULT * us_delay * ticks_per_jiffy >> UDELAY_SHIFT Originally, UDELAY_MULT was ((UL(2199023) * HZ) >> 11) and UDELAY_SHIFT 30. Assuming HZ=100, us_delay of 1000 and ticks_per_jiffy of 1660000 (eg, 166MHz timer, 1ms delay) this would calculate: ((UL(2199023) * HZ) >> 11) * 1000 * 1660000 >> 30 => 165999 With the new values of 2047 * HZ + 483648 * HZ / 1000000 and 31, we get: (2047 * HZ + 483648 * HZ / 1000000) * 1000 * 1660000 >> 31 => 158269 which is incorrect. This is due to a typo - correcting it gives: (2147 * HZ + 483648 * HZ / 1000000) * 1000 * 1660000 >> 31 => 165999 i.o.w, the original value. Fixes: 215e362d ("ARM: 8306/1: loop_udelay: remove bogomips value limitation") Reviewed-by:
Nicolas Pitre <nico@linaro.org> Signed-off-by:
Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by:
-
