- 05 Dec, 2019 40 commits
-
-
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:
Tony Lindgren <tony@atomide.com> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
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:
Will Deacon <will.deacon@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:
-
Doug Berger authored
[ Upstream commit 0686bd9d ] The phy_init_hw() function may reset the PHY to a configuration that does not match manual network settings stored in the phydev structure. If the phy state machine is polled rather than event driven this can create a timing hazard where the phy state machine might alter the settings stored in the phydev structure from the value read from the BMCR. This commit follows invocations of phy_init_hw() by the bcmgenet driver with invocations of the genphy_config_aneg() function to ensure that the BMCR is written to match the settings held in the phydev structure. This prevents the risk of manual settings being accidentally altered. Fixes: 1c1008c7 ("net: bcmgenet: add main driver file") Signed-off-by:
Doug Berger <opendmb@gmail.com> Acked-by:
-
Doug Berger authored
[ Upstream commit 3a55402c ] As noted in commit 28c2d1a7 ("net: bcmgenet: enable loopback during UniMAC sw_reset") the UniMAC must be clocked while sw_reset is asserted for its state machines to reset cleanly. The transmit and receive clocks used by the UniMAC are derived from the signals used on its PHY interface. The bcmgenet MAC can be configured to work with different PHY interfaces including MII, GMII, RGMII, and Reverse MII on internal and external interfaces. Unfortunately for the UniMAC, when configured for MII the Tx clock is always driven from the PHY which places it outside of the direct control of the MAC. The earlier commit enabled a local loopback mode within the UniMAC so that the receive clock would be derived from the transmit clock which addressed the observed issue with an external GPHY disabling it's Rx clock. However, when a Tx clock is not available this loopback is insufficient. This commit implements a workaround that leverages the fact that the MAC can reliably generate all of its necessary clocking by enterring the external GPHY RGMII interface mode with the UniMAC in local loopback during the sw_reset interval. Unfortunately, this has the undesirable side efect of the RGMII GTXCLK signal being driven during the same window. In most configurations this is a benign side effect as the signal is either not routed to a pin or is already expected to drive the pin. The one exception is when an external MII PHY is expected to drive the same pin with its TX_CLK output creating output driver contention. This commit exploits the IEEE 802.3 clause 22 standard defined isolate mode to force an external MII PHY to present a high impedance on its TX_CLK output during the window to prevent any contention at the pin. The MII interface is used internally with the 40nm internal EPHY which agressively disables its clocks for power savings leading to incomplete resets of the UniMAC and many instabilities observed over the years. The workaround of this commit is expected to put an end to those problems. Fixes: 1c1008c7 ("net: bcmgenet: add main driver file") Signed-off-by:
-
Ilya Leoshkevich authored
[ Upstream commit 8731acc5 ] gcc's -freorder-blocks-and-partition option makes it group frequently and infrequently used code in .text.hot and .text.unlikely sections respectively. At least when building modules on s390, this option is used by default. gdb assumes that all code is located in .text section, and that .text section is located at module load address. With such modules this is no longer the case: there is code in .text.hot and .text.unlikely, and either of them might precede .text. Fix by explicitly telling gdb the addresses of code sections. It might be tempting to do this for all sections, not only the ones in the white list. Unfortunately, gdb appears to have an issue, when telling it about e.g. loadable .note.gnu.build-id section causes it to think that non-loadable .note.Linux section is loaded at address 0, which in turn causes NULL pointers to be resolved to bogus symbols. So keep using the white list approach for the time being. Link: http://lkml.kernel.org/r/20191028152734.13065-1-iii@linux.ibm.comSigned-off-by:
Ilya Leoshkevich <iii@linux.ibm.com> Reviewed-by:
Jan Kiszka <jan.kiszka@siemens.com> Cc: Kieran Bingham <kbingham@kernel.org> Cc: Heiko Carstens <heiko.carstens@de.ibm.com> Cc: Vasily Gorbik <gor@linux.ibm.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Olivier Moysan authored
[ Upstream commit eaf072e5 ] Do not support mmap in S/PDIF mode. In S/PDIF mode the buffer has to be copied, to allow the channel status bits insertion. Signed-off-by:
Olivier Moysan <olivier.moysan@st.com> Link: https://lore.kernel.org/r/20191104133654.28750-1-olivier.moysan@st.comSigned-off-by:
Mark Brown <broonie@kernel.org> Signed-off-by:
-
Xingyu Chen authored
[ Upstream commit 2c777346 ] The left time value is wrong when we get it by sysfs. The left time value should be equal to preset timeout value minus elapsed time value. According to the Meson-GXB/GXL datasheets which can be found at [0], the timeout value is saved to BIT[0-15] of the WATCHDOG_TCNT, and elapsed time value is saved to BIT[16-31] of the WATCHDOG_TCNT. [0]: http://linux-meson.com Fixes: 683fa50f ("watchdog: Add Meson GXBB Watchdog Driver") Signed-off-by:
Xingyu Chen <xingyu.chen@amlogic.com> Acked-by:
Neil Armstrong <narmstrong@baylibre.com> Reviewed-by:
Kevin Hilman <khilman@baylibre.com> Reviewed-by:
Guenter Roeck <linux@roeck-us.net> Signed-off-by:
Wim Van Sebroeck <wim@linux-watchdog.org> Signed-off-by:
-
Timo Schlüßler authored
[ Upstream commit 27a0e54b ] In mcp251x_restart_work_handler() the variable to stop the interrupt handler (priv->force_quit) is reset after the chip is restarted and thus a interrupt might occur. This patch fixes the potential race condition by resetting force_quit before enabling interrupts. Signed-off-by:
Timo Schlüßler <schluessler@krause.de> Signed-off-by:
Marc Kleine-Budde <mkl@pengutronix.de> Signed-off-by:
-
Marc Kleine-Budde authored
[ Upstream commit 75812433 ] The call to can_rx_offload_queue_sorted() may fail and return an error (in the current implementation due to resource shortage). The passed skb is consumed. This patch adds incrementing of the appropriate error counters to let the device statistics reflect that there's a problem. Reported-by:
Martin Hundebøll <martin@geanix.com> Signed-off-by:
-
Marc Kleine-Budde authored
[ Upstream commit 1f7f504d ] In case of a resource shortage, i.e. the rx_offload queue will overflow or a skb fails to be allocated (due to OOM), can_rx_offload_offload_one() will call mailbox_read() to discard the mailbox and return an ERR_PTR. If the hardware FIFO is empty can_rx_offload_offload_one() will return NULL. In case a CAN frame was read from the hardware, can_rx_offload_offload_one() returns the skb containing it. Without this patch can_rx_offload_irq_offload_fifo() bails out if no skb returned, regardless of the reason. Similar to can_rx_offload_irq_offload_timestamp() in case of a resource shortage the whole FIFO should be discarded, to avoid an IRQ storm and give the system some time to recover. However if the FIFO is empty the loop can be left. With this patch the loop is left in case of empty FIFO, but not on errors. Signed-off-by:
-
