- 05 Dec, 2019 40 commits
-
-
Arnd Bergmann authored
[ Upstream commit 4aa64677 ] WARNING: vmlinux.o(.text+0x13250): Section mismatch in reference from the function acs5k_i2c_init() to the (unknown reference) .init.data:(unknown) The function acs5k_i2c_init() references the (unknown reference) __initdata (unknown). This is often because acs5k_i2c_init lacks a __initdata annotation or the annotation of (unknown) is wrong. Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
Olof Johansson <olof@lixom.net> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Dave Chinner authored
[ Upstream commit 43feeea8 ] A log recovery failure has been reproduced where a symlink inode has a zero length in extent form. It was caused by a shutdown during a combined fstress+fsmark workload. The underlying problem is the issue in xfs_inactive_symlink(): the inode is unlocked between the symlink inactivation/truncation and the inode being freed. This opens a window for the inode to be written to disk before it xfs_ifree() removes it from the unlinked list, marks it free in the inobt and zeros the mode. For shortform inodes, the fix is simple. xfs_ifree() clears the data fork state, so there's no need to do it in xfs_inactive_symlink(). This means the shortform fork verifier will not see a zero length data fork as it mirrors the inode size through to xfs_ifree()), and hence if the inode gets written back and the fork verifiers are run they will still see a fork that matches the on-disk inode size. For extent form (remote) symlinks, it is a little more tricky. Here we explicitly set the inode size to zero, so the above race can lead to zero length symlinks on disk. Because the inode is unlinked at this point (i.e. on the unlinked list) and unreferenced, it can never be seen again by a user. Hence when we set the inode size to zeor, also change the type to S_IFREG. xfs_ifree() expects S_IFREG inodes to be of zero length, and so this avoids all the problems of zero length symlinks ever hitting the disk. It also avoids the problem of needing to handle zero length symlink inodes in log recovery to replay the extent free intents and the remaining deferops to free the extents the symlink used. Also add a couple of asserts to warn us if zero length symlinks end up in either the symlink create or inactivation paths. Signed-off-by:
Dave Chinner <dchinner@redhat.com> Reviewed-by:
Darrick J. Wong <darrick.wong@oracle.com> Signed-off-by:
-
Thomas Meyer authored
[ Upstream commit 14d338a8 ] NULL check before some freeing functions is not needed. Signed-off-by:
Thomas Meyer <thomas@m3y3r.de> Reviewed-by:
Kevin Hilman <khilman@baylibre.com> Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by:
-
Gal Pressman authored
[ Upstream commit a276a4d9 ] Create address handle callback should not sleep, use GFP_ATOMIC instead of GFP_KERNEL for memory allocation. Fixes: 29c8d9eb ("IB: Add vmw_pvrdma driver") Cc: Adit Ranadive <aditr@vmware.com> Signed-off-by:
Gal Pressman <galpress@amazon.com> Reviewed-by:
Yuval Shaia <yuval.shaia@oracle.com> Signed-off-by:
Jason Gunthorpe <jgg@mellanox.com> Signed-off-by:
-
Will Deacon authored
[ Upstream commit 7faa313f ] Commit 39624469 ("arm64: preempt: Provide our own implementation of asm/preempt.h") extended the preempt count field in struct thread_info to 64 bits, so that it consists of a 32-bit count plus a 32-bit flag indicating whether or not the current task needs rescheduling. Whilst the asm-offsets definition of TSK_TI_PREEMPT was updated to point to this new field, the assembly usage was left untouched meaning that a 32-bit load from TSK_TI_PREEMPT on a big-endian machine actually returns the reschedule flag instead of the count. Whilst we could fix this by pointing TSK_TI_PREEMPT at the count field, we're actually better off reworking the two assembly users so that they operate on the whole 64-bit value in favour of inspecting the thread flags separately in order to determine whether a reschedule is needed. Acked-by:
Ard Biesheuvel <ard.biesheuvel@linaro.org> Reported-by:
"kernelci.org bot" <bot@kernelci.org> Tested-by:
Will Deacon <will.deacon@arm.com> Signed-off-by:
-
Lijun Ou authored
[ Upstream commit 4af07f01 ] It will prevent multiply overflow when defines the pbl for u64 type. Signed-off-by:
Lijun Ou <oulijun@huawei.com> Signed-off-by:
-
Aaro Koskinen authored
[ Upstream commit c7b7b5cb ] Currently we do USB configuration only if the host mode (CONFIG_USB) is enabled. But it should be done also in the case of device-only setups, so change the condition to CONFIG_USB_SUPPORT. This allows to use omap_udc on Palm Tungsten E. Signed-off-by:
Aaro Koskinen <aaro.koskinen@iki.fi> Signed-off-by:
Tony Lindgren <tony@atomide.com> Signed-off-by:
-
Vadim Pasternak authored
[ Upstream commit 440f343d ] Exchange LED configuration between msn201x and next generation systems types. Bug was introduced when LED driver activation was added to mlx-platform. LED configuration for the three new system MQMB7, MSN37, MSN34 was assigned to MSN21 and vice versa. This bug affects MSN21 only and likely requires backport to v4.19. Fixes: 1189456b ("platform/x86: mlx-platform: Add LED platform driver activation") Signed-off-by:
Vadim Pasternak <vadimp@mellanox.com> Signed-off-by:
Darren Hart (VMware) <dvhart@infradead.org> Signed-off-by:
-
Tony Lindgren authored
[ Upstream commit 4014c08b ] With ti-sysc, we need to now have the device tree properties for ti,no-reset-on-init and ti,no-idle-on-init at the module level instead of the child device level. Let's check for these properties at the child device level to enable quirks, and warn about moving the properties to the module level. Otherwise am335x-evm based boards tagging gpio1 with ti,no-reset-on-init will have their DDR power disabled if wired up in such a tricky way. Note that this should not be an issue for earlier kernels as we don't rely on this until the dts files have been updated to probe with ti-sysc interconnect target driver. Cc: Peter Ujfalusi <peter.ujfalusi@ti.com> Reported-by:
Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by:
-
Suzuki K Poulose authored
[ Upstream commit f357b3a7 ] The __cpu_up() routine ignores the errors reported by the firmware for a CPU bringup operation and looks for the error status set by the booting CPU. If the CPU never entered the kernel, we could end up in assuming stale error status, which otherwise would have been set/cleared appropriately by the booting CPU. Reported-by:
Steve Capper <steve.capper@arm.com> Cc: Will Deacon <will.deacon@arm.com> Signed-off-by:
Suzuki K Poulose <suzuki.poulose@arm.com> Signed-off-by:
-
Steve Capper authored
[ Upstream commit a96a33b1 ] For cases where there is a mismatch in ARMv8.2-LVA support between CPUs we have to be careful in allowing secondary CPUs to boot if 52-bit virtual addresses have already been enabled on the boot CPU. This patch adds code to the secondary startup path. If the boot CPU has enabled 52-bit VAs then ID_AA64MMFR2_EL1 is checked to see if the secondary can also enable 52-bit support. If not, the secondary is prevented from booting and an error message is displayed indicating why. Technically this patch could be implemented using the cpufeature code when considering 52-bit userspace support. However, we employ low level checks here as the cpufeature code won't be able to run if we have mismatched 52-bit kernel va support. Signed-off-by:
-
Tony Lindgren authored
[ Upstream commit e9e68548 ] While reviewing the missing mcasp ranges I noticed omap4 hsi range for gdd is wrong so let's fix it. I'm not aware of any omap4 devices in mainline kernel though that use hsi though. Fixes: 84badc5e ("ARM: dts: omap4: Move l4 child devices to probe them with ti-sysc") Reviewed-by:
Sebastian Reichel <sebastian.reichel@collabora.com> Signed-off-by:
-
Helge Deller authored
[ Upstream commit c4bff35c ] Show the hpa address of the HP SDC instead of a hashed value, e.g.: HP SDC: HP SDC at 0xf0201000, IRQ 23 (NMI IRQ 24) Signed-off-by:
Helge Deller <deller@gmx.de> Signed-off-by:
-
Helge Deller authored
[ Upstream commit 78514517 ] We want the hpa addresses printed in the serio modules, not some virtual ioremap()ed address, e.g.: serio: gsc-ps2-keyboard port at 0xf0108000 irq 22 @ 2:0:11 serio: gsc-ps2-mouse port at 0xf0108100 irq 22 @ 2:0:12 Signed-off-by:
-
Fabio Estevam authored
[ Upstream commit 998a84c2 ] imx53-voipac-dmm-668 has two memory nodes, but the correct representation would be to use a single one with two reg entries - one for each RAM chip select, so fix it accordingly. Reported-by:
Marco Franchi <marco.franchi@nxp.com> Signed-off-by:
Fabio Estevam <festevam@gmail.com> Signed-off-by:
Shawn Guo <shawnguo@kernel.org> Signed-off-by:
-
Fabio Estevam authored
[ Upstream commit 59d8bb36 ] Boards based on imx25 have duplicate memory nodes: - One coming from the board dts file: memory@ - One coming from the imx25.dtsi file. Fix the duplication by removing the memory node from the dtsi file and by adding 'device_type = "memory";' in the board dts. Reported-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
Fabio Estevam authored
[ Upstream commit 38715dcd ] Boards based on imx27 have duplicate memory nodes: - One coming from the board dts file: memory@ - One coming from the imx27.dtsi file. Fix the duplication by removing the memory node from the dtsi file and by adding 'device_type = "memory";' in the board dts. Reported-by:
-
Fabio Estevam authored
[ Upstream commit 62864d56 ] Boards based on imx1 have duplicate memory nodes: - One coming from the board dts file: memory@ - One coming from the imx1.dtsi file. Fix the duplication by removing the memory node from the dtsi file and by adding 'device_type = "memory";' in the board dts. Reported-by:
-
Fabio Estevam authored
[ Upstream commit b629e835 ] Boards based on imx23 have duplicate memory nodes: - One coming from the board dts file: memory@ - One coming from the imx23.dtsi file. Fix the duplication by removing the memory node from the dtsi file and by adding 'device_type = "memory";' in the board dts. Reported-by:
-
Fabio Estevam authored
[ Upstream commit aab5e3ea ] imx50-evk has duplicate memory nodes: - One coming from the board dts file: memory@ - One coming from the imx50.dtsi file. Fix the duplication by removing the memory node from the dtsi file and by adding 'device_type = "memory";' in the board dts. Reported-by:
-
Fabio Estevam authored
[ Upstream commit 7fa8ab65 ] Boards based on imx6sl have duplicate memory nodes: - One coming from the board dts file: memory@ - One coming from the imx6sl.dtsi file. Fix the duplication by removing the memory node from the dtsi file and by adding 'device_type = "memory";' in the board dts. Reported-by:
-
Fabio Estevam authored
[ Upstream commit 216f35fe ] Boards based on imx6sx have duplicate memory nodes: - One coming from the board dts file: memory@ - One coming from the imx6sx.dtsi file. Fix the duplication by removing the memory node from the dtsi file and by adding 'device_type = "memory";' in the board dts. Reported-by:
-
Fabio Estevam authored
[ Upstream commit 750d8df6 ] Boards based on imx6ul have duplicate memory nodes: - One coming from the board dts file: memory@ - One coming from the imx6ul.dtsi file. Fix the duplication by removing the memory node from the dtsi file and by adding 'device_type = "memory";' in the board dts. Reported-by:
-
Fabio Estevam authored
[ Upstream commit 29988e86 ] Boards based on imx7 have duplicate memory nodes: - One coming from the board dts file: memory@ - One coming from the imx7s.dtsi file. Fix the duplication by removing the memory node from the dtsi file and by adding 'device_type = "memory";' in the board dts. Reported-by:
-
Fabio Estevam authored
[ Upstream commit 8721610a ] Boards based on imx35 have duplicate memory nodes: - One coming from the board dts file: memory@ - One coming from the imx35.dtsi file. Fix the duplication by removing the memory node from the dtsi file and by adding 'device_type = "memory";' in the board dts. Reported-by:
-
Fabio Estevam authored
[ Upstream commit 013d37e4 ] Boards based on imx31 have duplicate memory nodes: - One coming from the board dts file: memory@ - One coming from the imx31.dtsi file. Fix the duplication by removing the memory node from the dtsi file and by adding 'device_type = "memory";' in the board dts. Reported-by:
Vladimir Zapolskiy <vz@mleia.com> Tested-by:
-
Fabio Estevam authored
[ Upstream commit e8fd17b9 ] Boards based on imx53 have duplicate memory nodes: - One coming from the board dts file: memory@ - One coming from the imx53.dtsi file. Fix the duplication by removing the memory node from the dtsi file and by adding 'device_type = "memory";' in the board dts. Reported-by:
-
Fabio Estevam authored
[ Upstream commit 6a968116 ] Boards based on imx51 have duplicate memory nodes: - One coming from the board dts file: memory@ - One coming from the imx51.dtsi file. Fix the duplication by removing the memory node from the dtsi file and by adding 'device_type = "memory";' in the board dts. Reported-by:
-
Uwe Kleine-König authored
[ Upstream commit 7c41ea57 ] If debugging on i.MX is enabled DEBUG_IMX_UART_PORT defines which UART is used for the debug output. If however debugging is off don't only hide the then unused config item but drop it completely by using a dependency instead of a conditional prompt. This fixes DEBUG_IMX_UART_PORT being present in the kernel config even if DEBUG_LL is disabled. Signed-off-by:
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by:
-
Masami Hiramatsu authored
[ Upstream commit fc800a10 ] synthetic event is using synth_event_mutex for protecting synth_event_list, and event_trigger_write() path acquires locks as below order. event_trigger_write(event_mutex) ->trigger_process_regex(trigger_cmd_mutex) ->event_hist_trigger_func(synth_event_mutex) On the other hand, synthetic event creation and deletion paths call trace_add_event_call() and trace_remove_event_call() which acquires event_mutex. In that case, if we keep the synth_event_mutex locked while registering/unregistering synthetic events, its dependency will be inversed. To avoid this issue, current synthetic event is using a 2 phase process to create/delete events. For example, it searches existing events under synth_event_mutex to check for event-name conflicts, and unlocks synth_event_mutex, then registers a new event under event_mutex locked. Finally, it locks synth_event_mutex and tries to add the new event to the list. But it can introduce complexity and a chance for name conflicts. To solve this simpler, this introduces trace_add_event_call_nolock() and trace_remove_event_call_nolock() which don't acquire event_mutex inside. synthetic event can lock event_mutex before synth_event_mutex to solve the lock dependency issue simpler. Link: http://lkml.kernel.org/r/154140844377.17322.13781091165954002713.stgit@devboxReviewed-by:
Tom Zanussi <tom.zanussi@linux.intel.com> Tested-by:
Masami Hiramatsu <mhiramat@kernel.org> Signed-off-by:
Steven Rostedt (VMware) <rostedt@goodmis.org> Signed-off-by:
-
Linus Walleij authored
[ Upstream commit d88b11ef ] This sets the partition information on the SQ201 to be read out from the RedBoot partition table, removes the static partition table and sets our boot options to mount root from /dev/mtdblock2 where the squashfs+JFFS2 resides. Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
-
James Smart authored
[ Upstream commit 7c4042a4 ] When dif and first burst is used in a write command wqe, the driver was not properly setting fields in the io command request. This resulted in no dif bytes being sent and invalid xfer_rdy's, resulting in the io being aborted by the hardware. Correct the wqe initializaton when both dif and first burst are used. Signed-off-by:
Dick Kennedy <dick.kennedy@broadcom.com> Signed-off-by:
James Smart <jsmart2021@gmail.com> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by:
-
James Smart authored
[ Upstream commit 5a9eeff5 ] Driver is hitting null pring pointers in lpfc_do_work(). Pointer assignment occurs based on SLI-revision. If recovering after an error, its possible the sli revision for the port was cleared, making the lpfc_phba_elsring() not return a ring pointer, thus the null pointer. Add SLI revision checking to lpfc_phba_elsring() and status checking to all callers. Signed-off-by:
-
Bart Van Assche authored
[ Upstream commit e7f41104 ] This patch does not change any functionality but avoids that sparse complains about the queue_cmd_ring() function and its callers. Fixes: 6fd0ce79 ("tcmu: prep queue_cmd_ring to be used by unmap wq") Reviewed-by:
David Disseldorp <ddiss@suse.de> Cc: Nicholas Bellinger <nab@linux-iscsi.org> Cc: Mike Christie <mchristi@redhat.com> Cc: Christoph Hellwig <hch@lst.de> Cc: Hannes Reinecke <hare@suse.de> Signed-off-by:
Bart Van Assche <bvanassche@acm.org> Signed-off-by:
-
Uwe Kleine-König authored
[ Upstream commit 24906a41 ] The owner member of struct pwm_ops must be set to THIS_MODULE to increase the reference count of the module such that the module cannot be removed while its code is in use. Fixes: daa5abc4 ("pwm: Add support for Broadcom iProc PWM controller") Signed-off-by:
Florian Fainelli <f.fainelli@gmail.com> Signed-off-by:
Thierry Reding <thierry.reding@gmail.com> Signed-off-by:
-
Dan Carpenter authored
[ Upstream commit 8e9c5230 ] There are two callers of this function and they both unlock the mutex so this ends up being a double unlock. Fixes: 44ed167d ("drbd: rcu_read_lock() and rcu_dereference() for tconn->net_conf") Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
Jens Axboe <axboe@kernel.dk> Signed-off-by:
-
Ahmed Zaki authored
[ Upstream commit 285531f9 ] In the first 5 minutes after boot (time of INITIAL_JIFFIES), ieee80211_sta_last_active() returns zero if last_ack is zero. This leads to "inactive time" showing jiffies_to_msecs(jiffies). # iw wlan0 station get fc:ec:da:64:a6:dd Station fc:ec:da:64:a6:dd (on wlan0) inactive time: 4294894049 ms . . connected time: 70 seconds Fix by returning last_rx if last_ack == 0. Signed-off-by:
Ahmed Zaki <anzaki@gmail.com> Link: https://lore.kernel.org/r/20191031121243.27694-1-anzaki@gmail.comSigned-off-by:
Johannes Berg <johannes.berg@intel.com> Signed-off-by:
-
Toke Høiland-Jørgensen authored
[ Upstream commit 71e67c3b ] The FQ implementation used by mac80211 allocates memory using kmalloc(), which can fail; and Johannes reported that this actually happens in practice. To avoid this, switch the allocation to kvmalloc() instead; this also brings fq_impl in line with all the FQ qdiscs. Fixes: 557fc4a0 ("fq: add fair queuing framework") Reported-by:
Johannes Berg <johannes@sipsolutions.net> Signed-off-by:
Toke Høiland-Jørgensen <toke@redhat.com> Link: https://lore.kernel.org/r/20191105155750.547379-1-toke@redhat.comSigned-off-by:
-
Jeff Layton authored
[ Upstream commit ff29fde8 ] If someone requests fscache on the mount, and the kernel doesn't support it, it should fail the mount. [ Drop ceph prefix -- it's provided by pr_err. ] Signed-off-by:
Jeff Layton <jlayton@kernel.org> Reviewed-by:
Ilya Dryomov <idryomov@gmail.com> Signed-off-by:
-
Vladimir Oltean authored
[ Upstream commit 17fdd763 ] The "read-modify-write register index" function is declared with a confusing prototype: the "mask" and "reg" arguments are swapped. Fortunately, this does not affect callers so far. Both arguments are u32, and the wrapper macros (ocelot_rmw_ix etc) have the arguments in the correct order (the one from ocelot_io.c). Signed-off-by:
Vladimir Oltean <olteanv@gmail.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
