- 05 Dec, 2019 40 commits
-
-
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:
Sasha Levin <sashal@kernel.org>
-
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:
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Reviewed-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:
-
Jeroen Hofstee authored
[ Upstream commit c2a9f74c ] 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. However can_rx_offload_irq_offload_timestamp() bails out in the error case. In case of a resource shortage all mailboxes should be discarded, to avoid an IRQ storm and give the system some time to recover. Since can_rx_offload_irq_offload_timestamp() is typically called from a while loop, all message will eventually be discarded. So let's continue on error instead to discard them directly. Signed-off-by:
Jeroen Hofstee <jhofstee@victronenergy.com> Signed-off-by:
-
Marc Kleine-Budde authored
can: rx-offload: can_rx_offload_offload_one(): use ERR_PTR() to propagate error value in case of errors [ Upstream commit d763ab30 ] Before this patch can_rx_offload_offload_one() returns a pointer to a skb containing the read CAN frame or a NULL pointer. However the meaning of the NULL pointer is ambiguous, it can either mean the requested mailbox is empty or there was an error. This patch fixes this situation by returning: - pointer to skb on success - NULL pointer if mailbox is empty - ERR_PTR() in case of an error All users of can_rx_offload_offload_one() have been adopted, no functional change intended. Signed-off-by:
-
Marc Kleine-Budde authored
[ Upstream commit 4e9016be ] If the rx-offload skb_queue is full or the skb allocation fails (due to OOM), the mailbox contents is discarded. This patch adds the incrementing of the rx_fifo_errors statistics counter. Signed-off-by:
-
Marc Kleine-Budde authored
can: rx-offload: can_rx_offload_offload_one(): do not increase the skb_queue beyond skb_queue_len_max [ Upstream commit a2dc3f5e ] The skb_queue is a linked list, holding the skb to be processed in the next NAPI call. Without this patch, the queue length in can_rx_offload_offload_one() is limited to skb_queue_len_max + 1. As the skb_queue is a linked list, no array or other resources are accessed out-of-bound, however this behaviour is counterintuitive. This patch limits the rx-offload skb_queue length to skb_queue_len_max. Fixes: d254586c ("can: rx-offload: Add support for HW fifo based irq offloading") Signed-off-by:
-
Marc Kleine-Budde authored
[ Upstream commit 6caf8a6d ] If the rx-offload skb_queue is full can_rx_offload_queue_tail() will not queue the skb and return with an error. This patch frees the skb in case of a full queue, which brings can_rx_offload_queue_tail() in line with the can_rx_offload_queue_sorted() function, which has been adjusted in the previous patch. The return value is adjusted to -ENOBUFS to better reflect the actual problem. The device stats handling is left to the caller. Fixes: d254586c ("can: rx-offload: Add support for HW fifo based irq offloading") Reported-by:
Kurt Van Dijck <dev.kurt@vandijck-laurijssen.be> Signed-off-by:
-
Jeroen Hofstee authored
[ Upstream commit 23c5a948 ] When the CAN interface is closed it the hardwre is put in power down mode, but does not reset the error counters / state. Reset the D_CAN on open, so the reported state and the actual state match. According to [1], the C_CAN module doesn't have the software reset. [1] http://www.bosch-semiconductors.com/media/ip_modules/pdf_2/c_can_fd8/users_manual_c_can_fd8_r210_1.pdfSigned-off-by:
-
Jeroen Hofstee authored
[ Upstream commit 128a1b87 ] While the state changes are reported when the error counters increase and decrease, there is no event when the bus recovers and the error counters decrease again. So add those as well. Change the state going downward to be ERROR_PASSIVE -> ERROR_WARNING -> ERROR_ACTIVE instead of directly to ERROR_ACTIVE again. Signed-off-by:
-
Florian Westphal authored
[ Upstream commit b23c0742 ] xt_in() returns NULL in the output hook, skip the pkt_type change for that case, redirection only makes sense in broute/prerouting hooks. Reported-by:
Tom Yan <tom.ty89@gmail.com> Cc: Linus Lüssing <linus.luessing@c0d3.blue> Fixes: cf3cb246 ("bridge: ebtables: fix reception of frames DNAT-ed to bridge device/port") Signed-off-by:
Florian Westphal <fw@strlen.de> Signed-off-by:
Pablo Neira Ayuso <pablo@netfilter.org> Signed-off-by:
-
Chuhong Yuan authored
[ Upstream commit c43eab3e ] This driver forgets to disable and unprepare clks when remove. Add calls to clk_disable_unprepare to fix it. Signed-off-by:
Chuhong Yuan <hslester96@gmail.com> Signed-off-by:
-
Tony Lindgren authored
[ Upstream commit 81a41901 ] Commit 3d8598fb ("clk: ti: clkctrl: use fallback udelay approach if timekeeping is suspended") added handling for cases when timekeeping is suspended. But looks like we can still get occasional "failed to enable" errors on the PM runtime resume path with udelay() returning faster than expected. With ti-sysc interconnect target module driver this leads into device failure with PM runtime failing with "failed to enable" clkctrl error. Let's fix the issue with a delay of two times the desired delay as in often done for udelay() to account for the inaccuracy. Fixes: 3d8598fb ("clk: ti: clkctrl: use fallback udelay approach if timekeeping is suspended") Cc: Keerthy <j-keerthy@ti.com> Cc: Tero Kristo <t-kristo@ti.com> Signed-off-by:
Tony Lindgren <tony@atomide.com> Link: https://lkml.kernel.org/r/20190930154001.46581-1-tony@atomide.comTested-by:
Keerthy <j-keerthy@ti.com> Signed-off-by:
Stephen Boyd <sboyd@kernel.org> Signed-off-by:
-
Peter Ujfalusi authored
[ Upstream commit 9982b0f6 ] ti_clk_register() calls it already so the driver should not create duplicated alias. Signed-off-by:
Peter Ujfalusi <peter.ujfalusi@ti.com> Link: https://lkml.kernel.org/r/20191002083436.10194-1-peter.ujfalusi@ti.comSigned-off-by:
-
Xiaochen Shen authored
[ Upstream commit 26467b0f ] When a mon group is being deleted, rdtgrp->flags is set to RDT_DELETED in rdtgroup_rmdir_mon() firstly. The structure of rdtgrp will be freed until rdtgrp->waitcount is dropped to 0 in rdtgroup_kn_unlock() later. During the window of deleting a mon group, if an application calls rdtgroup_mondata_show() to read mondata under this mon group, 'rdtgrp' returned from rdtgroup_kn_lock_live() is a NULL pointer when rdtgrp->flags is RDT_DELETED. And then 'rdtgrp' is passed in this path: rdtgroup_mondata_show() --> mon_event_read() --> mon_event_count(). Thus it results in NULL pointer dereference in mon_event_count(). Check 'rdtgrp' in rdtgroup_mondata_show(), and return -ENOENT immediately when reading mondata during the window of deleting a mon group. Fixes: d89b7379 ("x86/intel_rdt/cqm: Add mon_data") Signed-off-by:
Xiaochen Shen <xiaochen.shen@intel.com> Signed-off-by:
Borislav Petkov <bp@suse.de> Reviewed-by:
Fenghua Yu <fenghua.yu@intel.com> Reviewed-by:
Tony Luck <tony.luck@intel.com> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Ingo Molnar <mingo@redhat.com> Cc: pei.p.jia@intel.com Cc: Reinette Chatre <reinette.chatre@intel.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: x86-ml <x86@kernel.org> Link: https://lkml.kernel.org/r/1572326702-27577-1-git-send-email-xiaochen.shen@intel.comSigned-off-by:
-
Matthew Wilcox (Oracle) authored
[ Upstream commit b7e9728f ] Attempting to allocate an entry at 0xffffffff when one is already present would succeed in allocating one at 2^32, which would confuse everything. Return -ENOSPC in this case, as expected. Signed-off-by:
Matthew Wilcox (Oracle) <willy@infradead.org> Signed-off-by:
-
Matthew Wilcox (Oracle) authored
[ Upstream commit f6341c5a ] If there is an entry at INT_MAX then idr_for_each_entry() will increment id after handling it. This is undefined behaviour, and is caught by UBSAN. Adding 1U to id forces the operation to be carried out as an unsigned addition which (when assigned to id) will result in INT_MIN. Since there is never an entry stored at INT_MIN, idr_get_next() will return NULL, ending the loop as expected. Signed-off-by:
-
Eric Dumazet authored
[ Upstream commit 7de08690 ] We have seen many crashes on powerpc hosts while loading bpf programs. The problem here is that bpf_int_jit_compile() does a first pass to compute the program length. Then it allocates memory to store the generated program and calls bpf_jit_build_body() a second time (and a third time later) What I have observed is that the second bpf_jit_build_body() could end up using few more words than expected. If bpf_jit_binary_alloc() put the space for the program at the end of the allocated page, we then write on a non mapped memory. It appears that bpf_jit_emit_tail_call() calls bpf_jit_emit_common_epilogue() while ctx->seen might not be stable. Only after the second pass we can be sure ctx->seen wont be changed. Trying to avoid a second pass seems quite complex and probably not worth it. Fixes: ce076141 ("powerpc/bpf: Implement support for tail calls") Signed-off-by:
Eric Dumazet <edumazet@google.com> Signed-off-by:
Daniel Borkmann <daniel@iogearbox.net> Cc: Naveen N. Rao <naveen.n.rao@linux.ibm.com> Cc: Sandipan Das <sandipan@linux.ibm.com> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Paul Mackerras <paulus@samba.org> Cc: Michael Ellerman <mpe@ellerman.id.au> Cc: Martin KaFai Lau <kafai@fb.com> Cc: Song Liu <songliubraving@fb.com> Cc: Yonghong Song <yhs@fb.com> Link: https://lore.kernel.org/bpf/20191101033444.143741-1-edumazet@google.comSigned-off-by:
-
Björn Töpel authored
[ Upstream commit 04ec044b ] To remove that test_attr__{enabled/open} are used by perf-sys.h, we set HAVE_ATTR_TEST to zero. Signed-off-by:
Björn Töpel <bjorn.topel@intel.com> Tested-by:
KP Singh <kpsingh@google.com> Acked-by:
Song Liu <songliubraving@fb.com> Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: Alexei Starovoitov <ast@kernel.org> Cc: Jiri Olsa <jolsa@kernel.org> Cc: Namhyung Kim <namhyung@kernel.org> Cc: bpf@vger.kernel.org Cc: netdev@vger.kernel.org Signed-off-by:
Arnaldo Carvalho de Melo <acme@redhat.com> Signed-off-by:
-
Ondrej Jirman authored
[ Upstream commit e614f341 ] Without enabling keep-power-in-suspend, we can't wake the device up using WOL packet, and the log is flooded with these messages on resume: sunxi-mmc 1c10000.mmc: send stop command failed sunxi-mmc 1c10000.mmc: data error, sending stop command sunxi-mmc 1c10000.mmc: send stop command failed sunxi-mmc 1c10000.mmc: data error, sending stop command So to make the WiFi really a wakeup-source, we need to keep it powered during suspend. Fixes: 0e233720 ("arm: dts: sun8i: Add the TBS A711 tablet devicetree") Signed-off-by:
Ondrej Jirman <megous@megous.com> Signed-off-by:
Maxime Ripard <mripard@kernel.org> Signed-off-by:
-
Colin Ian King authored
[ Upstream commit cdfc2e20 ] The zero'ing of bits 16 and 18 is incorrect. Currently the code is masking with the bitwise-and of BIT(16) & BIT(18) which is 0, so the updated value for val is always zero. Fix this by bitwise and-ing value with the correct mask that will zero bits 16 and 18. Addresses-Coverity: (" Suspicious &= or |= constant expression") Fixes: b8eb71dc ("clk: sunxi-ng: Add A80 CCU") Signed-off-by:
Colin Ian King <colin.king@canonical.com> Signed-off-by:
-
Nathan Chancellor authored
[ Upstream commit afdc74ed ] r375326 in Clang exposes an issue with operator precedence in sunxi_div_clk_setup: drivers/clk/sunxi/clk-sunxi.c:1083:30: warning: operator '?:' has lower precedence than '|'; '|' will be evaluated first [-Wbitwise-conditional-parentheses] data->div[i].critical ? ~~~~~~~~~~~~~~~~~~~~~ ^ drivers/clk/sunxi/clk-sunxi.c:1083:30: note: place parentheses around the '|' expression to silence this warning data->div[i].critical ? ^ ) drivers/clk/sunxi/clk-sunxi.c:1083:30: note: place parentheses around the '?:' expression to evaluate it first data->div[i].critical ? ^ ( 1 warning generated. It appears that the intention was for ?: to be evaluated first so that CLK_IS_CRITICAL could be added to clkflags if the critical boolean was set; right now, | is being evaluated first. Add parentheses around the ?: block to have it be evaluated first. Fixes: 9919d44f ("clk: sunxi: Use CLK_IS_CRITICAL flag for critical clks") Link: https://github.com/ClangBuiltLinux/linux/issues/745Signed-off-by:
Nathan Chancellor <natechancellor@gmail.com> Signed-off-by:
-
Alexandre Belloni authored
[ Upstream commit 658fd65c ] It is not allowed to sleep to early in the boot process and this may lead to kernel issues if the bootloader didn't prepare the slow clock and main clock. This results in the following error and dump stack on the AriettaG25: bad: scheduling from the idle thread! Ensure it is possible to sleep, else simply have a delay. Reported-by:
Alexandre Belloni <alexandre.belloni@bootlin.com> Link: https://lkml.kernel.org/r/20190920153906.20887-1-alexandre.belloni@bootlin.com Fixes: 80eded6c ("clk: at91: add slow clks driver") Tested-by:
-
Randy Dunlap authored
[ Upstream commit f430c7ed ] Add a missing short description to the reset_control_ops documentation. Signed-off-by:
Randy Dunlap <rdunlap@infradead.org> [p.zabel@pengutronix.de: rebased and updated commit message] Signed-off-by:
Philipp Zabel <p.zabel@pengutronix.de> Signed-off-by:
-
Fabio Estevam authored
[ Upstream commit 7e5d0bf6 ] Since commit a211b8c5 ("ARM: dts: imx6qdl-sabreauto: Add sensors") a storm of accelerometer interrupts is seen: [ 114.211283] irq 260: nobody cared (try booting with the "irqpoll" option) [ 114.218108] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.3.4 #1 [ 114.223960] Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree) [ 114.230531] [<c0112858>] (unwind_backtrace) from [<c010cdc8>] (show_stack+0x10/0x14) [ 114.238301] [<c010cdc8>] (show_stack) from [<c0c1aa1c>] (dump_stack+0xd8/0x110) [ 114.245644] [<c0c1aa1c>] (dump_stack) from [<c0193594>] (__report_bad_irq+0x30/0xc0) [ 114.253417] [<c0193594>] (__report_bad_irq) from [<c01933ac>] (note_interrupt+0x108/0x298) [ 114.261707] [<c01933ac>] (note_interrupt) from [<c018ffe4>] (handle_irq_event_percpu+0x70/0x80) [ 114.270433] [<c018ffe4>] (handle_irq_event_percpu) from [<c019002c>] (handle_irq_event+0x38/0x5c) [ 114.279326] [<c019002c>] (handle_irq_event) from [<c019438c>] (handle_level_irq+0xc8/0x154) [ 114.287701] [<c019438c>] (handle_level_irq) from [<c018eda0>] (generic_handle_irq+0x20/0x34) [ 114.296166] [<c018eda0>] (generic_handle_irq) from [<c0534214>] (mxc_gpio_irq_handler+0x30/0xf0) [ 114.304975] [<c0534214>] (mxc_gpio_irq_handler) from [<c0534334>] (mx3_gpio_irq_handler+0x60/0xb0) [ 114.313955] [<c0534334>] (mx3_gpio_irq_handler) from [<c018eda0>] (generic_handle_irq+0x20/0x34) [ 114.322762] [<c018eda0>] (generic_handle_irq) from [<c018f3ac>] (__handle_domain_irq+0x64/0xe0) [ 114.331485] [<c018f3ac>] (__handle_domain_irq) from [<c05215a8>] (gic_handle_irq+0x4c/0xa8) [ 114.339862] [<c05215a8>] (gic_handle_irq) from [<c0101a70>] (__irq_svc+0x70/0x98) [ 114.347361] Exception stack(0xc1301ec0 to 0xc1301f08) [ 114.352435] 1ec0: 00000001 00000006 00000000 c130c340 00000001 c130f688 9785636d c13ea2e8 [ 114.360635] 1ee0: 9784907d 0000001a eaf99d78 0000001a 00000000 c1301f10 c0182b00 c0878de4 [ 114.368830] 1f00: 20000013 ffffffff [ 114.372349] [<c0101a70>] (__irq_svc) from [<c0878de4>] (cpuidle_enter_state+0x168/0x5f4) [ 114.380464] [<c0878de4>] (cpuidle_enter_state) from [<c08792ac>] (cpuidle_enter+0x28/0x38) [ 114.388751] [<c08792ac>] (cpuidle_enter) from [<c015ef9c>] (do_idle+0x224/0x2a8) [ 114.396168] [<c015ef9c>] (do_idle) from [<c015f3b8>] (cpu_startup_entry+0x18/0x20) [ 114.403765] [<c015f3b8>] (cpu_startup_entry) from [<c1200e54>] (start_kernel+0x43c/0x500) [ 114.411958] handlers: [ 114.414302] [<a01028b8>] irq_default_primary_handler threaded [<fd7a3b08>] mma8452_interrupt [ 114.422974] Disabling IRQ #260 CPU0 CPU1 .... 260: 100001 0 gpio-mxc 31 Level mma8451 The MMA8451 interrupt triggers as low level, so the GPIO6_IO31 pin needs to activate its pull up, otherwise it will stay always at low level generating multiple interrupts. The current device tree does not configure the IOMUX for this pin, so it uses whathever comes configured from the bootloader. The IOMUXC_SW_PAD_CTL_PAD_EIM_BCLK register value comes as 0x8000 from the bootloader, which has PKE bit cleared, hence disabling the pull-up. Instead of relying on a previous configuration from the bootloader, configure the GPIO6_IO31 pin with pull-up enabled in order to fix this problem. Fixes: a211b8c5 ("ARM: dts: imx6qdl-sabreauto: Add sensors") Signed-off-by:
Fabio Estevam <festevam@gmail.com> Reviewed-By:
Leonard Crestez <leonard.crestez@nxp.com> Signed-off-by:
Shawn Guo <shawnguo@kernel.org> Signed-off-by:
-
