summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2019-06-06net: mvpp2: Use strscpy to handle stat stringsMaxime Chevallier
Use a safe strscpy call to copy the ethtool stat strings into the relevant buffers, instead of a memcpy that will be accessing out-of-bound data. Fixes: 118d6298f6f0 ("net: mvpp2: add ethtool GOP statistics") Signed-off-by: Maxime Chevallier <maxime.chevallier@bootlin.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-06-06net: rds: fix memory leak in rds_ib_flush_mr_poolZhu Yanjun
When the following tests last for several hours, the problem will occur. Server: rds-stress -r 1.1.1.16 -D 1M Client: rds-stress -r 1.1.1.14 -s 1.1.1.16 -D 1M -T 30 The following will occur. " Starting up.... tsks tx/s rx/s tx+rx K/s mbi K/s mbo K/s tx us/c rtt us cpu % 1 0 0 0.00 0.00 0.00 0.00 0.00 -1.00 1 0 0 0.00 0.00 0.00 0.00 0.00 -1.00 1 0 0 0.00 0.00 0.00 0.00 0.00 -1.00 1 0 0 0.00 0.00 0.00 0.00 0.00 -1.00 " >From vmcore, we can find that clean_list is NULL. >From the source code, rds_mr_flushd calls rds_ib_mr_pool_flush_worker. Then rds_ib_mr_pool_flush_worker calls " rds_ib_flush_mr_pool(pool, 0, NULL); " Then in function " int rds_ib_flush_mr_pool(struct rds_ib_mr_pool *pool, int free_all, struct rds_ib_mr **ibmr_ret) " ibmr_ret is NULL. In the source code, " ... list_to_llist_nodes(pool, &unmap_list, &clean_nodes, &clean_tail); if (ibmr_ret) *ibmr_ret = llist_entry(clean_nodes, struct rds_ib_mr, llnode); /* more than one entry in llist nodes */ if (clean_nodes->next) llist_add_batch(clean_nodes->next, clean_tail, &pool->clean_list); ... " When ibmr_ret is NULL, llist_entry is not executed. clean_nodes->next instead of clean_nodes is added in clean_list. So clean_nodes is discarded. It can not be used again. The workqueue is executed periodically. So more and more clean_nodes are discarded. Finally the clean_list is NULL. Then this problem will occur. Fixes: 1bc144b62524 ("net, rds, Replace xlist in net/rds/xlist.h with llist") Signed-off-by: Zhu Yanjun <yanjun.zhu@oracle.com> Acked-by: Santosh Shilimkar <santosh.shilimkar@oracle.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-06-06Merge branch 'ipv6-fix-EFAULT-on-sendto-with-icmpv6-and-hdrincl'David S. Miller
Olivier Matz says: ==================== ipv6: fix EFAULT on sendto with icmpv6 and hdrincl The following code returns EFAULT (Bad address): s = socket(AF_INET6, SOCK_RAW, IPPROTO_ICMPV6); setsockopt(s, SOL_IPV6, IPV6_HDRINCL, 1); sendto(ipv6_icmp6_packet, addr); /* returns -1, errno = EFAULT */ The problem is fixed in the second patch. The first one aligns the code to ipv4, to avoid a race condition in the second patch. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2019-06-06ipv6: fix EFAULT on sendto with icmpv6 and hdrinclOlivier Matz
The following code returns EFAULT (Bad address): s = socket(AF_INET6, SOCK_RAW, IPPROTO_ICMPV6); setsockopt(s, SOL_IPV6, IPV6_HDRINCL, 1); sendto(ipv6_icmp6_packet, addr); /* returns -1, errno = EFAULT */ The IPv4 equivalent code works. A workaround is to use IPPROTO_RAW instead of IPPROTO_ICMPV6. The failure happens because 2 bytes are eaten from the msghdr by rawv6_probe_proto_opt() starting from commit 19e3c66b52ca ("ipv6 equivalent of "ipv4: Avoid reading user iov twice after raw_probe_proto_opt""), but at that time it was not a problem because IPV6_HDRINCL was not yet introduced. Only eat these 2 bytes if hdrincl == 0. Fixes: 715f504b1189 ("ipv6: add IPV6_HDRINCL option for raw sockets") Signed-off-by: Olivier Matz <olivier.matz@6wind.com> Acked-by: Nicolas Dichtel <nicolas.dichtel@6wind.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-06-06ipv6: use READ_ONCE() for inet->hdrincl as in ipv4Olivier Matz
As it was done in commit 8f659a03a0ba ("net: ipv4: fix for a race condition in raw_sendmsg") and commit 20b50d79974e ("net: ipv4: emulate READ_ONCE() on ->hdrincl bit-field in raw_sendmsg()") for ipv4, copy the value of inet->hdrincl in a local variable, to avoid introducing a race condition in the next commit. Signed-off-by: Olivier Matz <olivier.matz@6wind.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-06-06x86/fpu: Use fault_in_pages_writeable() for pre-faultingHugh Dickins
Since commit d9c9ce34ed5c8 ("x86/fpu: Fault-in user stack if copy_fpstate_to_sigframe() fails") get_user_pages_unlocked() pre-faults user's memory if a write generates a page fault while the handler is disabled. This works in general and uncovered a bug as reported by Mike Rapoport¹. It has been pointed out that this function may be fragile and a simple pre-fault as in fault_in_pages_writeable() would be a better solution. Better as in taste and simplicity: that write (as performed by the alternative function) performs exactly the same faulting of memory as before. This was suggested by Hugh Dickins and Andrew Morton. Use fault_in_pages_writeable() for pre-faulting user's stack. [ bigeasy: Write commit message. ] [ bp: Massage some. ] ¹ https://lkml.kernel.org/r/1557844195-18882-1-git-send-email-rppt@linux.ibm.com Fixes: d9c9ce34ed5c8 ("x86/fpu: Fault-in user stack if copy_fpstate_to_sigframe() fails") Suggested-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Hugh Dickins <hughd@google.com> Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: Borislav Petkov <bp@suse.de> Tested-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Andrea Arcangeli <aarcange@redhat.com> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Dave Hansen <dave.hansen@linux.intel.com> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Ingo Molnar <mingo@redhat.com> Cc: Jann Horn <jannh@google.com> Cc: linux-mm <linux-mm@kvack.org> Cc: Mike Rapoport <rppt@linux.ibm.com> Cc: Pavel Machek <pavel@ucw.cz> Cc: Rik van Riel <riel@surriel.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: x86-ml <x86@kernel.org> Link: https://lkml.kernel.org/r/20190529072540.g46j4kfeae37a3iu@linutronix.de Link: https://lkml.kernel.org/r/1557844195-18882-1-git-send-email-rppt@linux.ibm.com
2019-06-06nvme-rdma: use dynamic dma mapping per commandMax Gurtovoy
Commit 87fd125344d6 ("nvme-rdma: remove redundant reference between ib_device and tagset") caused a kernel panic when disconnecting from an inaccessible controller (disconnect during re-connection). -- nvme nvme0: Removing ctrl: NQN "testnqn1" nvme_rdma: nvme_rdma_exit_request: hctx 0 queue_idx 1 BUG: unable to handle kernel paging request at 0000000080000228 PGD 0 P4D 0 Oops: 0000 [#1] SMP PTI ... Call Trace: blk_mq_exit_hctx+0x5c/0xf0 blk_mq_exit_queue+0xd4/0x100 blk_cleanup_queue+0x9a/0xc0 nvme_rdma_destroy_io_queues+0x52/0x60 [nvme_rdma] nvme_rdma_shutdown_ctrl+0x3e/0x80 [nvme_rdma] nvme_do_delete_ctrl+0x53/0x80 [nvme_core] nvme_sysfs_delete+0x45/0x60 [nvme_core] kernfs_fop_write+0x105/0x180 vfs_write+0xad/0x1a0 ksys_write+0x5a/0xd0 do_syscall_64+0x55/0x110 entry_SYSCALL_64_after_hwframe+0x44/0xa9 RIP: 0033:0x7fa215417154 -- The reason for this crash is accessing an already freed ib_device for performing dma_unmap during exit_request commands. The root cause for that is that during re-connection all the queues are destroyed and re-created (and the ib_device is reference counted by the queues and freed as well) but the tagset stays alive and all the DMA mappings (that we perform in init_request) kept in the request context. The original commit fixed a different bug that was introduced during bonding (aka nic teaming) tests that for some scenarios change the underlying ib_device and caused memory leakage and possible segmentation fault. This commit is a complementary commit that also changes the wrong DMA mappings that were saved in the request context and making the request sqe dma mappings dynamic with the command lifetime (i.e. mapped in .queue_rq and unmapped in .complete). It also fixes the above crash of accessing freed ib_device during destruction of the tagset. Fixes: 87fd125344d6 ("nvme-rdma: remove redundant reference between ib_device and tagset") Reported-by: Jim Harris <james.r.harris@intel.com> Suggested-by: Sagi Grimberg <sagi@grimberg.me> Tested-by: Jim Harris <james.r.harris@intel.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Max Gurtovoy <maxg@mellanox.com> Signed-off-by: Sagi Grimberg <sagi@grimberg.me>
2019-06-06nvme: Fix u32 overflow in the number of namespace list calculationJaesoo Lee
The Number of Namespaces (nn) field in the identify controller data structure is defined as u32 and the maximum allowed value in NVMe specification is 0xFFFFFFFEUL. This change fixes the possible overflow of the DIV_ROUND_UP() operation used in nvme_scan_ns_list() by casting the nn to u64. Signed-off-by: Jaesoo Lee <jalee@purestorage.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Sagi Grimberg <sagi@grimberg.me>
2019-06-06vfio/mdev: Improve the create/remove sequenceParav Pandit
This patch addresses below two issues and prepares the code to address 3rd issue listed below. 1. mdev device is placed on the mdev bus before it is created in the vendor driver. Once a device is placed on the mdev bus without creating its supporting underlying vendor device, mdev driver's probe() gets triggered. However there isn't a stable mdev available to work on. create_store() mdev_create_device() device_register() ... vfio_mdev_probe() [...] parent->ops->create() vfio_ap_mdev_create() mdev_set_drvdata(mdev, matrix_mdev); /* Valid pointer set above */ Due to this way of initialization, mdev driver who wants to use the mdev, doesn't have a valid mdev to work on. 2. Current creation sequence is, parent->ops_create() groups_register() Remove sequence is, parent->ops->remove() groups_unregister() However, remove sequence should be exact mirror of creation sequence. Once this is achieved, all users of the mdev will be terminated first before removing underlying vendor device. (Follow standard linux driver model). At that point vendor's remove() ops shouldn't fail because taking the device off the bus should terminate any usage. 3. When remove operation fails, mdev sysfs removal attempts to add the file back on already removed device. Following call trace [1] is observed. [1] call trace: kernel: WARNING: CPU: 2 PID: 9348 at fs/sysfs/file.c:327 sysfs_create_file_ns+0x7f/0x90 kernel: CPU: 2 PID: 9348 Comm: bash Kdump: loaded Not tainted 5.1.0-rc6-vdevbus+ #6 kernel: Hardware name: Supermicro SYS-6028U-TR4+/X10DRU-i+, BIOS 2.0b 08/09/2016 kernel: RIP: 0010:sysfs_create_file_ns+0x7f/0x90 kernel: Call Trace: kernel: remove_store+0xdc/0x100 [mdev] kernel: kernfs_fop_write+0x113/0x1a0 kernel: vfs_write+0xad/0x1b0 kernel: ksys_write+0x5a/0xe0 kernel: do_syscall_64+0x5a/0x210 kernel: entry_SYSCALL_64_after_hwframe+0x49/0xbe Therefore, mdev core is improved in following ways. 1. Split the device registration/deregistration sequence so that some things can be done between initialization of the device and hooking it up to the bus respectively after deregistering it from the bus but before giving up our final reference. In particular, this means invoking the ->create() and ->remove() callbacks in those new windows. This gives the vendor driver an initialized mdev device to work with during creation. At the same time, a bus driver who wish to bind to mdev driver also gets initialized mdev device. This follows standard Linux kernel bus and device model. 2. During remove flow, first remove the device from the bus. This ensures that any bus specific devices are removed. Once device is taken off the mdev bus, invoke remove() of mdev from the vendor driver. 3. The driver core device model provides way to register and auto unregister the device sysfs attribute groups at dev->groups. Make use of dev->groups to let core create the groups and eliminate code to avoid explicit groups creation and removal. To ensure, that new sequence is solid, a below stack dump of a process is taken who attempts to remove the device while device is in use by vfio driver and user application. This stack dump validates that vfio driver guards against such device removal when device is in use. cat /proc/21962/stack [<0>] vfio_del_group_dev+0x216/0x3c0 [vfio] [<0>] mdev_remove+0x21/0x40 [mdev] [<0>] device_release_driver_internal+0xe8/0x1b0 [<0>] bus_remove_device+0xf9/0x170 [<0>] device_del+0x168/0x350 [<0>] mdev_device_remove_common+0x1d/0x50 [mdev] [<0>] mdev_device_remove+0x8c/0xd0 [mdev] [<0>] remove_store+0x71/0x90 [mdev] [<0>] kernfs_fop_write+0x113/0x1a0 [<0>] vfs_write+0xad/0x1b0 [<0>] ksys_write+0x5a/0xe0 [<0>] do_syscall_64+0x5a/0x210 [<0>] entry_SYSCALL_64_after_hwframe+0x49/0xbe [<0>] 0xffffffffffffffff This prepares the code to eliminate calling device_create_file() in subsequent patch. Reviewed-by: Cornelia Huck <cohuck@redhat.com> Signed-off-by: Parav Pandit <parav@mellanox.com> Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
2019-06-06SoC: rt274: Fix internal jack assignment in set_jack callbackAmadeusz Sławiński
When we call snd_soc_component_set_jack(component, NULL, NULL) we should set rt274->jack to passed jack, so when interrupt is triggered it calls snd_soc_jack_report(rt274->jack, ...) with proper value. This fixes problem in machine where in register, we call snd_soc_register(component, &headset, NULL), which just calls rt274_mic_detect via callback. Now when machine driver is removed "headset" will be gone, so we need to tell codec driver that it's gone with: snd_soc_register(component, NULL, NULL), but we also need to be able to handle NULL jack argument here gracefully. If we don't set it to NULL, next time the rt274_irq runs it will call snd_soc_jack_report with first argument being invalid pointer and there will be Oops. Signed-off-by: Amadeusz Sławiński <amadeuszx.slawinski@linux.intel.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2019-06-06ALSA: hdac: fix memory release for SST and SOF driversAmadeusz Sławiński
During the integration of HDaudio support, we changed the way in which we get hdev in snd_hdac_ext_bus_device_init() to use one preallocated with devm_kzalloc(), however it still left kfree(hdev) in snd_hdac_ext_bus_device_exit(). It leads to oopses when trying to rmmod and modprobe. Fix it, by just removing kfree call. SOF also uses some of the snd_hdac_ functions for HDAudio support but allocated the memory with kzalloc. A matching fix is provided separately to align all users of the snd_hdac_ library. Fixes: 6298542fa33b ("ALSA: hdac: remove memory allocation from snd_hdac_ext_bus_device_init") Reviewed-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Amadeusz Sławiński <amadeuszx.slawinski@linux.intel.com> Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2019-06-06ASoC: SOF: Intel: hda: use the defined ppcap functionsZhu Yingjiang
There are already defined ppcap and ppcap interrupt functions, use the already defined functions for easy code read. Fixes: 8a300c8fb17 ("ASoC: SOF: Intel: Add HDA controller for Intel DSP") Reviewed-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Zhu Yingjiang <yingjiang.zhu@linux.intel.com> Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2019-06-06ASoC: core: move DAI pre-links initiation to snd_soc_instantiate_cardTzung-Bi Shih
Kernel crashes when an ASoC component rebinding. The dai_link->platforms has been reset to NULL by soc_cleanup_platform() in soc_cleanup_card_resources() when un-registering component. However, it has no chance to re-allocate the dai_link->platforms when registering the component again. Move the DAI pre-links initiation from snd_soc_register_card() to snd_soc_instantiate_card() to make sure all DAI pre-links get initiated when component rebinding. As an example, by using the following commands: - echo -n max98357a > /sys/bus/platform/drivers/max98357a/unbind - echo -n max98357a > /sys/bus/platform/drivers/max98357a/bind Got the error message: "Unable to handle kernel NULL pointer dereference at virtual address". The call trace: snd_soc_is_matching_component+0x30/0x6c soc_bind_dai_link+0x16c/0x240 snd_soc_bind_card+0x1e4/0xb10 snd_soc_add_component+0x270/0x300 snd_soc_register_component+0x54/0x6c Signed-off-by: Tzung-Bi Shih <tzungbi@google.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2019-06-06ASoC: Intel: cht_bsw_rt5672: fix kernel oops with platform_name overridePierre-Louis Bossart
The platform override code uses devm_ functions to allocate memory for the new name but the card device is not initialized. Fix by moving the init earlier. Fixes: f403906da05cd ("ASoC: Intel: cht_bsw_rt5672: platform name fixup support") Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2019-06-06ASoC: Intel: cht_bsw_nau8824: fix kernel oops with platform_name overridePierre-Louis Bossart
The platform override code uses devm_ functions to allocate memory for the new name but the card device is not initialized. Fix by moving the init earlier. Fixes: 4506db8043341 ("ASoC: Intel: cht_bsw_nau8824: platform name fixup support") Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2019-06-06ASoC: Intel: bytcht_es8316: fix kernel oops with platform_name overridePierre-Louis Bossart
The platform override code uses devm_ functions to allocate memory for the new name but the card device is not initialized. Fix by moving the init earlier. Fixes: e4bc6b1195f64 ("ASoC: Intel: bytcht_es8316: platform name fixup support") Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2019-06-06ASoC: Intel: cht_bsw_max98090: fix kernel oops with platform_name overridePierre-Louis Bossart
The platform override code uses devm_ functions to allocate memory for the new name but the card device is not initialized. Fix by moving the init earlier. Fixes: 7e7e24d7c7ff0 ("ASoC: Intel: cht_bsw_max98090_ti: platform name fixup support") Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2019-06-06Revert "gfs2: Replace gl_revokes with a GLF flag"Bob Peterson
Commit 73118ca8baf7 introduced a glock reference counting bug in gfs2_trans_remove_revoke. Given that, replacing gl_revokes with a GLF flag is no longer useful, so revert that commit. Signed-off-by: Bob Peterson <rpeterso@redhat.com> Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com>
2019-06-06arm64: dts: renesas: Add HiHope RZ/G2M sub board supportBiju Das
The HiHope RZ/G2M sub board sits below the HiHope RZ/G2M main board. This patch also adds ethernet support along with a dtsi common to both HiHope RZ/G2M and RZ/G2N sub boards. Signed-off-by: Biju Das <biju.das@bp.renesas.com> Reviewed-by: Chris Paterson <Chris.Paterson2@renesas.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
2019-06-06arm64: dts: renesas: hihope-common: Add pincontrol support to scif2/scif clockBiju Das
This patch adds pincontrol support to scif2/scif clock. Signed-off-by: Biju Das <biju.das@bp.renesas.com> Reviewed-by: Chris Paterson <Chris.Paterson2@renesas.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
2019-06-06arm64: dts: renesas: Add HiHope RZ/G2M main board supportBiju Das
Basic support for the HiHope RZ/G2M main board: - Memory, - Main crystal, - Serial console This patch also includes a dtsi common to both HiHope RZ/G2M and RZ/G2N main boards. Signed-off-by: Biju Das <biju.das@bp.renesas.com> Reviewed-by: Chris Paterson <Chris.Paterson2@renesas.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
2019-06-06Merge tag 'misc-habanalabs-fixes-2019-06-06' of ↵Greg Kroah-Hartman
git://people.freedesktop.org/~gabbayo/linux into char-misc-linus Oded writes: This tag contains the following fixes: - Fix the code that checks whether we can use 2MB page size when mapping memory in the ASIC's MMU. The current code had a "hole" which happened in architectures other then x86-64. - Fix the debugfs interface to read/write from/to the device using device virtual addresses. There was a bug in the translation regarding addresses that were mapped using 2MB page size. - Fix a bug in the debug/profiling code, where the code didn't read the full address but only the lower 32-bits of the address. * tag 'misc-habanalabs-fixes-2019-06-06' of git://people.freedesktop.org/~gabbayo/linux: habanalabs: Read upper bits of trace buffer from RWPHI habanalabs: Fix virtual address access via debugfs for 2MB pages habanalabs: fix bug in checking huge page optimization
2019-06-06arm64: Silence gcc warnings about arch ABI driftDave Martin
Since GCC 9, the compiler warns about evolution of the platform-specific ABI, in particular relating for the marshaling of certain structures involving bitfields. The kernel is a standalone binary, and of course nobody would be so stupid as to expose structs containing bitfields as function arguments in ABI. (Passing a pointer to such a struct, however inadvisable, should be unaffected by this change. perf and various drivers rely on that.) So these warnings do more harm than good: turn them off. We may miss warnings about future ABI drift, but that's too bad. Future ABI breaks of this class will have to be debugged and fixed the traditional way unless the compiler evolves finer-grained diagnostics. Signed-off-by: Dave Martin <Dave.Martin@arm.com> Signed-off-by: Will Deacon <will.deacon@arm.com>
2019-06-06parisc: Fix crash due alternative coding for NP iopdir_fdc bitHelge Deller
According to the found documentation, data cache flushes and sync instructions are needed on the PCX-U+ (PA8200, e.g. C200/C240) platforms, while PCX-W (PA8500, e.g. C360) platforms aparently don't need those flushes when changing the IO PDIR data structures. We have no documentation for PCX-W+ (PA8600) and PCX-W2 (PA8700) CPUs, but Carlo Pisani reported that his C3600 machine (PA8600, PCX-W+) fails when the fdc instructions were removed. His firmware didn't set the NIOP bit, so one may assume it's a firmware bug since other C3750 machines had the bit set. Even if documentation (as mentioned above) states that PCX-W (PA8500, e.g. J5000) does not need fdc flushes, Sven could show that an Adaptec 29320A PCI-X SCSI controller reliably failed on a dd command during the first five minutes in his J5000 when fdc flushes were missing. Going forward, we will now NOT replace the fdc and sync assembler instructions by NOPS if: a) the NP iopdir_fdc bit was set by firmware, or b) we find a CPU up to and including a PCX-W+ (PA8600). This fixes the HPMC crashes on a C240 and C36XX machines. For other machines we rely on the firmware to set the bit when needed. In case one finds HPMC issues, people could try to boot their machines with the "no-alternatives" kernel option to turn off any alternative patching. Reported-by: Sven Schnelle <svens@stackframe.org> Reported-by: Carlo Pisani <carlojpisani@gmail.com> Tested-by: Sven Schnelle <svens@stackframe.org> Fixes: 3847dab77421 ("parisc: Add alternative coding infrastructure") Signed-off-by: Helge Deller <deller@gmx.de> Cc: stable@vger.kernel.org # 5.0+
2019-06-06parisc: Use lpa instruction to load physical addresses in driver codeJohn David Anglin
Most I/O in the kernel is done using the kernel offset mapping. However, there is one API that uses aliased kernel address ranges: > The final category of APIs is for I/O to deliberately aliased address > ranges inside the kernel. Such aliases are set up by use of the > vmap/vmalloc API. Since kernel I/O goes via physical pages, the I/O > subsystem assumes that the user mapping and kernel offset mapping are > the only aliases. This isn't true for vmap aliases, so anything in > the kernel trying to do I/O to vmap areas must manually manage > coherency. It must do this by flushing the vmap range before doing > I/O and invalidating it after the I/O returns. For this reason, we should use the hardware lpa instruction to load the physical address of kernel virtual addresses in the driver code. I believe we only use the vmap/vmalloc API with old PA 1.x processors which don't have a sba, so we don't hit this problem. Tested on c3750, c8000 and rp3440. Signed-off-by: John David Anglin <dave.anglin@bell.net> Signed-off-by: Helge Deller <deller@gmx.de>
2019-06-06parisc: configs: Remove useless UEVENT_HELPER_PATHKrzysztof Kozlowski
Remove the CONFIG_UEVENT_HELPER_PATH because: 1. It is disabled since commit 1be01d4a5714 ("driver: base: Disable CONFIG_UEVENT_HELPER by default") as its dependency (UEVENT_HELPER) was made default to 'n', 2. It is not recommended (help message: "This should not be used today [...] creates a high system load") and was kept only for ancient userland, 3. Certain userland specifically requests it to be disabled (systemd README: "Legacy hotplug slows down the system and confuses udev"). Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org> Acked-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Helge Deller <deller@gmx.de>
2019-06-06parisc: Use implicit space register selection for loading the coherence ↵John David Anglin
index of I/O pdirs We only support I/O to kernel space. Using %sr1 to load the coherence index may be racy unless interrupts are disabled. This patch changes the code used to load the coherence index to use implicit space register selection. This saves one instruction and eliminates the race. Tested on rp3440, c8000 and c3750. Signed-off-by: John David Anglin <dave.anglin@bell.net> Cc: stable@vger.kernel.org Signed-off-by: Helge Deller <deller@gmx.de>
2019-06-06ARM: dts: sun8i: r40: Change the RTC compatibleMaxime Ripard
Unlike what's being reported in the device tree so far, the RTC in the R40 is quite different from the H3. Indeed it doesn't have the internal oscillator output, and it has only a single interrupt. Let's add a compatible for it. Acked-by: Chen-Yu Tsai <wens@csie.org> Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
2019-06-06ARM: dts: sun8i: v3s: Add external crystals accuracyMaxime Ripard
The V3s datasheet mandates oscillators accuracy to be within 50ppm. Let's add that accuracy to their device tree nodes. Acked-by: Chen-Yu Tsai <wens@csie.org> Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
2019-06-06ARM: dts: sun8i: v3s: Fix the RTC nodeMaxime Ripard
For some reason, while the v3s has a dedicated compatible in the RTC binding, the one actually used was the A31's. However, it turns out that the controller is pretty different (which justified the compatible). Let's use the proper compatible, and use the proper binding description as well. Acked-by: Chen-Yu Tsai <wens@csie.org> Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
2019-06-06ARM: dts: sun6i: Add external crystals accuracyMaxime Ripard
The A31 datasheet mandates oscillators accuracy to be within 50ppm. Let's add that accuracy to their device tree nodes. Acked-by: Chen-Yu Tsai <wens@csie.org> Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
2019-06-06ARM: dts: sun6i: Fix RTC nodeMaxime Ripard
The RTC node doesn't match what is described in the binding for historical reasons. Let's add the proper description. Acked-by: Chen-Yu Tsai <wens@csie.org> Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
2019-06-06usb: gadget: udc: lpc32xx: fix return value check in lpc32xx_udc_probe()Wei Yongjun
In case of error, the function devm_ioremap_resource() returns ERR_PTR() and never returns NULL. The NULL test in the return value check should be replaced with IS_ERR(). This issue was detected by using the Coccinelle software. Fixes: 408b56ca5c8e ("usb: gadget: udc: lpc32xx: simplify probe") Acked-by: Sylvain Lemieux <slemieux.tyco@gmail.com> Acked-by: Vladimir Zapolskiy <vz@mleia.com> Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com> Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
2019-06-06usb: gadget: dwc2: fix zlp handlingAndrzej Pietrasiewicz
The patch 10209abe87f5ebfd482a00323f5236d6094d0865 usb: dwc2: gadget: Add scatter-gather mode avoided a NULL pointer dereference (hs_ep->req == NULL) by calling dwc2_gadget_fill_nonisoc_xfer_dma_one() directly instead of through the dwc2_gadget_config_nonisoc_xfer_ddma() wrapper, which unconditionally dereferenced the said pointer. However, this was based on an incorrect assumption that in the context of dwc2_hsotg_program_zlp() the pointer is always NULL, which is not the case. The result were SB CV MSC tests failing starting from Test Case 6. Instead, this patch reverts to calling the wrapper and adds a check for the pointer being NULL inside the wrapper. Fixes: 10209abe87f5 (usb: dwc2: gadget: Add scatter-gather mode) Acked-by: Minas Harutyunyan <hminas@synopsys.com> Signed-off-by: Andrzej Pietrasiewicz <andrzej.p@collabora.com> Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
2019-06-06usb: dwc2: Set actual frame number for completed ISOC transfer for none DDMAMinas Harutyunyan
On ISOC OUT transfer completion, in none DDMA mode, set actual frame number returning to function driver in usb_request. Signed-off-by: Minas Harutyunyan <hminas@synopsys.com> Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
2019-06-06usb: gadget: udc: lpc32xx: allocate descriptor with GFP_ATOMICAlexandre Belloni
Gadget drivers may queue request in interrupt context. This would lead to a descriptor allocation in that context. In that case we would hit BUG_ON(in_interrupt()) in __get_vm_area_node. Also remove the unnecessary cast. Acked-by: Sylvain Lemieux <slemieux.tyco@gmail.com> Tested-by: James Grant <jamesg@zaltys.org> Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
2019-06-06usb: gadget: fusb300_udc: Fix memory leak of fusb300->ep[i]Young Xiao
There is no deallocation of fusb300->ep[i] elements, allocated at fusb300_probe. The patch adds deallocation of fusb300->ep array elements. Signed-off-by: Young Xiao <92siuyang@gmail.com> Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
2019-06-06usb: phy: mxs: Disable external charger detect in mxs_phy_hw_init()Andrey Smirnov
Since this driver already handles changer detction state, copy the workaround code currently residing in arch/arm/mach-imx/anatop.c into this drier to consolidate the places modifying it. Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com> Cc: Chris Healy <cphealy@gmail.com> Cc: Felipe Balbi <balbi@kernel.org> Cc: Shawn Guo <shawnguo@kernel.org> Cc: Fabio Estevam <festevam@gmail.com> Cc: NXP Linux Team <linux-imx@nxp.com> Cc: linux-usb@vger.kernel.org Cc: linux-arm-kernel@lists.infradead.org Cc: linux-kernel@vger.kernel.org Reviewed-by: Peter Chen <peter.chen@nxp.com> Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
2019-06-06usb: dwc2: Fix DMA cache alignment issuesMartin Schiller
Insert a padding between data and the stored_xfer_buffer pointer to ensure they are not on the same cache line. Otherwise, the stored_xfer_buffer gets corrupted for IN URBs on non-cache-coherent systems. (In my case: Lantiq xRX200 MIPS) Fixes: 3bc04e28a030 ("usb: dwc2: host: Get aligned DMA in a more supported way") Fixes: 56406e017a88 ("usb: dwc2: Fix DMA alignment to start at allocated boundary") Cc: <stable@vger.kernel.org> Tested-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Douglas Anderson <dianders@chromium.org> Acked-by: Minas Harutyunyan <hminas@synopsys.com> Signed-off-by: Martin Schiller <ms@dev.tdt.de> Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
2019-06-06usb: dwc2: host: Fix wMaxPacketSize handling (fix webcam regression)Douglas Anderson
In commit abb621844f6a ("usb: ch9: make usb_endpoint_maxp() return only packet size") the API to usb_endpoint_maxp() changed. It used to just return wMaxPacketSize but after that commit it returned wMaxPacketSize with the high bits (the multiplier) masked off. If you wanted to get the multiplier it was now up to your code to call the new usb_endpoint_maxp_mult() which was introduced in commit 541b6fe63023 ("usb: add helper to extract bits 12:11 of wMaxPacketSize"). Prior to the API change most host drivers were updated, but no update was made to dwc2. Presumably it was assumed that dwc2 was too simplistic to use the multiplier and thus just didn't support a certain class of USB devices. However, it turns out that dwc2 did use the multiplier and many devices using it were working quite nicely. That means that many USB devices have been broken since the API change. One such device is a Logitech HD Pro Webcam C920. Specifically, though dwc2 didn't directly call usb_endpoint_maxp(), it did call usb_maxpacket() which in turn called usb_endpoint_maxp(). Let's update dwc2 to work properly with the new API. Fixes: abb621844f6a ("usb: ch9: make usb_endpoint_maxp() return only packet size") Cc: stable@vger.kernel.org Acked-by: Minas Harutyunyan <hminas@synopsys.com> Reviewed-by: Matthias Kaehlcke <mka@chromium.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
2019-06-06ARM: dts: rockchip: Split GPIO keys for veyron into multiple devicesMatthias Kaehlcke
With a single device DT overrides can become messy, especially when keys are added or removed. Multiple devices also allow to enable/disable wakeup per key/group. Signed-off-by: Matthias Kaehlcke <mka@chromium.org> [used actual switch+event constants in new lid-switch entry] Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2019-06-06ARM: dts: rockchip: Add HDMI i2c unwedging for rk3288-veyronDouglas Anderson
Veyron uses the builtin i2c controller that's part of dw-hdmi. Hook up the unwedging feature. Signed-off-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Sean Paul <sean@poorly.run> Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2019-06-06ARM: dts: rockchip: Add unwedge pinctrl entries for dw_hdmi on rk3288Douglas Anderson
This adds the "unwedge" pinctrl entries introduced by a recent dw_hdmi change that can unwedge the dw_hdmi i2c bus in some cases. It's expected that any boards using this would add: pinctrl-names = "default", "unwedge"; pinctrl-0 = <&hdmi_ddc>; pinctrl-1 = <&hdmi_ddc_unwedge>; Note that this isn't added by default because some boards may choose to mux i2c5 for their DDC bus (if that is more tested for them). Signed-off-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Sean Paul <sean@poorly.run> Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2019-06-06ARM: dts: rockchip: Switch to builtin HDMI DDC bus on rk3288-veyronDouglas Anderson
Downstream Chrome OS kernels use the builtin DDC bus from dw_hdmi on veyron. This is the only way to get them to negotiate HDCP. Although HDCP isn't currently all supported upstream, it still seems like it makes sense to use dw_hdmi's builtin I2C. Maybe eventually we can get HDCP negotiation working. Signed-off-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Sean Paul <sean@poorly.run> Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2019-06-06ARM64: trivial: s/TIF_SECOMP/TIF_SECCOMP/ comment typo fixGeorge G. Davis
Fix a s/TIF_SECOMP/TIF_SECCOMP/ comment typo Cc: Jiri Kosina <trivial@kernel.org> Reviewed-by: Kees Cook <keescook@chromium.org Signed-off-by: George G. Davis <george_davis@mentor.com> Signed-off-by: Will Deacon <will.deacon@arm.com>
2019-06-06arm64: dts: renesas: r8a774a1: Add operating pointsFabrizio Castro
The RZ/G2M (a.k.a. r8a774a1) comes with two clusters of processors, similarly to the r8a7796. The first cluster is made of A57s, the second cluster is made of A53s. The operating points for the cluster with the A57s are: Frequency | Voltage -----------|--------- 500 MHz | 0.82V 1.0 GHz | 0.82V 1.5 GHz | 0.82V The operating points for the cluster with the A53s are: Frequency | Voltage -----------|--------- 800 MHz | 0.82V 1.0 GHz | 0.82V 1.2 GHz | 0.82V This patch adds the definitions for the operating points to the SoC specific DT. Signed-off-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com> Reviewed-by: Chris Paterson <Chris.Paterson2@renesas.com> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
2019-06-06arm64: dts: renesas: r8a77990: Add dynamic power coefficientSimon Horman
Describe the dynamic power coefficient of A53 CPUs. Based on work by Gaku Inami <gaku.inami.xw@bp.renesas.com> and others. Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
2019-06-06arm64: dts: renesas: r8a77990: Create thermal zone to support IPADien Pham
Setup a thermal zone driven by SoC temperature sensor. Create passive trip points and bind them to CPUFreq cooling device that supports power extension. In R-Car Gen3, IPA is supported for only one channel Reason: Currently, IPA controls base on only CPU temperature. And only one thermal channel is assembled closest CPU cores is selected as target of IPA. If other channels are used, IPA controlling is not properly. A single cooling device is described for all A53 CPUs as this reflects that physically there is only one cooling device present. This patch improves on an earlier version by: * Omitting cooling-max-level and cooling-min-level properties which are no longer present in mainline as of v4.17 * Removing an unused trip-point0 node sub-property from the trips property. * Defers adding dynamic-power-coefficient properties to a separate patch as these are properties of the CPU. The long signed-off by chain below reflects many revisions, mainly internal, that this patch has been through. Signed-off-by: Dien Pham <dien.pham.ry@renesas.com> Signed-off-by: Takeshi Kihara <takeshi.kihara.df@renesas.com> Signed-off-by: Yoshihiro Kaneko <ykaneko0929@gmail.com> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
2019-06-06arm64: dts: renesas: r8a77965: Add dynamic power coefficientSimon Horman
Describe the dynamic power coefficient of A57 and A53 CPUs. Based on work by Gaku Inami <gaku.inami.xw@bp.renesas.com> and others. Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
2019-06-06arm64: dts: renesas: r8a77965: Create thermal zone to support IPADien Pham
Setup a thermal zone driven by SoC temperature sensor. Create passive trip points and bind them to CPUFreq cooling device that supports power extension. In R-Car Gen3, IPA is supported for only one channel (on H3/M3/M3N SoCs, it is channel THS3). Reason: Currently, IPA controls base on only CPU temperature. And only one thermal channel is assembled closest CPU cores is selected as target of IPA. If other channels are used, IPA controlling is not properly. The A57 cooling device supports 5 cooling states which can be categorised as follows: 0 & 1) boost (clocking up) 2) default 3 & 4) cooling (clocking down) Currently the thermal framework assumes that the default is the minimum, or in other words there is no provision for handling boost states. So this patch only describes the upper 3 states, default and cooling. A single cooling device is described for all A57 CPUs and a separate cooling device is described for all A53 CPUs. This reflects that physically there is only one cooling device present for each type of CPU. This patch improves on an earlier version by: * Omitting cooling-max-level and cooling-min-level properties which are no longer present in mainline as of v4.17 * Removing an unused trip-point0 node sub-property from the trips property. * Using cooling-device indexes such that maximum refers to maximum cooling rather than the inverse. * Defers adding dynamic-power-coefficient properties to a separate patch as these are properties of the CPU. The long signed-off by chain below reflects many revisions, mainly internal, that this patch has been through. Signed-off-by: Dien Pham <dien.pham.ry@renesas.com> Signed-off-by: An Huynh <an.huynh.uj@rvc.renesas.com> Signed-off-by: Takeshi Kihara <takeshi.kihara.df@renesas.com> Signed-off-by: Yoshihiro Kaneko <ykaneko0929@gmail.com> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>