- 12 Feb, 2019 40 commits
-
-
Kai-Heng Feng authored
[ Upstream commit e03e303e ] We can use MEMSTICK_POWER_{ON,OFF} along with pm_runtime_{get,put} helpers to let memstick host support runtime pm. The rpm count may go down to zero before the memstick host powers on, so the host can be runtime suspended. So before doing card detection, increment the rpm count to avoid the host gets runtime suspended. Balance the rpm count after card detection is done. Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Tested-by: Oleksandr Natalenko <oleksandr@natalenko.name> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
-
Nicholas Mc Guire authored
[ Upstream commit b0d06f1c ] devm_kasprintf() may return NULL on failure of internal allocation thus the assignments to init.name are not safe if not checked. On error meson_mx_mmc_register_clks() returns negative values so -ENOMEM in the (unlikely) failure case of devm_kasprintf() should be fine here. Signed-off-by: Nicholas Mc Guire <hofrat@osadl.org> Fixes: ed80a13b ("mmc: meson-mx-sdio: Add a driver for the Amlogic Meson8 and Meson8b SoCs") Acked-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
-
Michal Suchanek authored
[ Upstream commit f6000a4e ] The bcm2835 mmc host tends to lock up for unknown reason so reset it on timeout. The upper mmc block layer tries retransimitting with single blocks which tends to work out after a long wait. This is better than giving up and leaving the machine broken for no obvious reason. Fixes: 660fc733 ("mmc: bcm2835: Add new driver for the sdhost controller.") Signed-off-by: Michal Suchanek <msuchanek@suse.de> Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com> Acked-by: Eric Anholt <eric@anholt.net> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
-
Phil Elwell authored
[ Upstream commit 07d40576 ] If the user issues an "mmc extcsd read", the SD controller receives what it thinks is a SEND_IF_COND command with an unexpected data block. The resulting operations leave the FSM stuck in READWAIT, a state which persists until the MMC framework resets the controller, by which point the root filesystem is likely to have been unmounted. A less heavyweight solution is to detect the condition and nudge the FSM by asserting the (self-clearing) FORCE_DATA_MODE bit. Link: https://github.com/raspberrypi/linux/issues/2728Signed-off-by: Phil Elwell <phil@raspberrypi.org> Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com> Acked-by: Eric Anholt <eric@anholt.net> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
-
Suraj Jitindar Singh authored
[ Upstream commit 693ac10a ] The kvm capability KVM_CAP_SPAPR_TCE_VFIO is used to indicate the availability of in kernel tce acceleration for vfio. However it is currently the case that this is only available on a powernv machine, not for a pseries machine. Thus make this capability dependent on having the cpu feature CPU_FTR_HVMODE. [paulus@ozlabs.org - fixed compilation for Book E.] Signed-off-by: Suraj Jitindar Singh <sjitindarsingh@gmail.com> Signed-off-by: Paul Mackerras <paulus@ozlabs.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
-
Fabio Estevam authored
[ Upstream commit add68836 ] eukrea-tlv320.c machine driver runs on non-DT platforms and include <asm/mach-types.h> header file in order to be able to use some machine_is_eukrea_xxx() macros. Building it for ARM64 causes the following build error: sound/soc/fsl/eukrea-tlv320.c:28:10: fatal error: asm/mach-types.h: No such file or directory Avoid this error by not allowing to build the SND_SOC_EUKREA_TLV320 driver when ARM64 is selected. This is needed in preparation for the i.MX8M support. Reported-by: kbuild test robot <lkp@intel.com> Signed-off-by: Fabio Estevam <festevam@gmail.com> Acked-by: Shawn Guo <shawnguo@kernel.org> Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
-
Arnd Bergmann authored
[ Upstream commit 88af3209 ] WARNING: vmlinux.o(.text+0x19f90): Section mismatch in reference from the function littleton_init_lcd() to the function .init.text:pxa_set_fb_info() The function littleton_init_lcd() references the function __init pxa_set_fb_info(). This is often because littleton_init_lcd lacks a __init annotation or the annotation of pxa_set_fb_info is wrong. WARNING: vmlinux.o(.text+0xf824): Section mismatch in reference from the function zeus_register_ohci() to the function .init.text:pxa_set_ohci_info() The function zeus_register_ohci() references the function __init pxa_set_ohci_info(). This is often because zeus_register_ohci lacks a __init annotation or the annotation of pxa_set_ohci_info is wrong. WARNING: vmlinux.o(.text+0xf95c): Section mismatch in reference from the function cm_x300_init_u2d() to the function .init.text:pxa3xx_set_u2d_info() The function cm_x300_init_u2d() references the function __init pxa3xx_set_u2d_info(). This is often because cm_x300_init_u2d lacks a __init annotation or the annotation of pxa3xx_set_u2d_info 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>
-
Stanislav Fomichev authored
[ Upstream commit a0517a0f ] For some reason, my older GCC (< 4.8) isn't smart enough to optimize the !__builtin_constant_p() branch in bpf_htons, I see: error: implicit declaration of function '__builtin_bswap16' Let's use __bpf_constant_htons as suggested by Daniel Borkmann. I tried to use simple htons, but it produces the following: test_progs.c:54:17: error: braced-group within expression allowed only inside a function .eth.h_proto = htons(ETH_P_IP), Signed-off-by: Stanislav Fomichev <sdf@google.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Signed-off-by: Alexei Starovoitov <ast@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
-
Joey Zhang authored
[ Upstream commit e4a7dca5 ] In the ioctl_event_ctl() SWITCHTEC_IOCTL_EVENT_IDX_ALL case, we call event_ctl() several times with the same "ctl" struct. Each call clobbers ctl.flags, which leads to the problem that we may not actually enable or disable all events as the user requested. Preserve the event flag value with a temporary variable. Fixes: 52eabba5 ("switchtec: Add IOCTLs to the Switchtec driver") Signed-off-by: Joey Zhang <joey.zhang@microchip.com> Signed-off-by: Wesley Sheng <wesley.sheng@microchip.com> [bhelgaas: changelog] Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Logan Gunthorpe <logang@deltatee.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
-
Jan Kara authored
[ Upstream commit d288d958 ] When inode is corrupted so that extent type is invalid, some functions (such as udf_truncate_extents()) will just BUG. Check that extent type is valid when loading the inode to memory. Reported-by: Anatoly Trosinenko <anatoly.trosinenko@gmail.com> Signed-off-by: Jan Kara <jack@suse.cz> Signed-off-by: Sasha Levin <sashal@kernel.org>
-
Nir Dotan authored
[ Upstream commit d7263ab3 ] In Spectrum-2, higher priority value wins and priority valid values are in the range of {1,cap_kvd_size-1}. mlxsw_sp_acl_tcam_priority_get converts from lower-bound priorities alike tc flower to Spectrum-2 HW range. Up until now tc flower did not provide priority 0 or reached the maximal value, however multicast routing does provide priority 0. Therefore, Change mlxsw_sp_acl_tcam_priority_get to verify priority is in the correct range. Make sure priority is never set to zero and never exceeds the maximal allowed value. Signed-off-by: Nir Dotan <nird@mellanox.com> Reviewed-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Sasha Levin <sashal@kernel.org>
-
Icenowy Zheng authored
[ Upstream commit 2659392e ] The new Allwinner H6 SoC's USB2 PHY has two holes -- USB1 (which is a 3.0 port with dedicated PHY) and USB2 (which doesn't exist at all). Add support for this kind of missing USB PHY index. Signed-off-by: Icenowy Zheng <icenowy@aosc.io> Reviewed-by: Chen-Yu Tsai <wens@csie.org> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
-
[ Upstream commit 4f5c85fe ] It was observed that when using seqentional mode contrary to the documentation, the SS bit (which is supposed to only be set if automatic/sequence command completed normally), is sometimes set together with NA (NAK in address phase) causing transfer to falsely be considered successful. My assumption is that this does not happen during manual mode since the controller is stopping its work the moment it sets NA/ND bit in status register. This is not the case in Automatic/Sequentional mode where it is still working to send STOP condition and the actual status we get depends on the time when the ISR is run. This patch changes the order of checking status bits in ISR - error conditions are checked first and only if none of them occurred, the transfer may be considered successful. This is required to introduce using of sequentional mode in next patch. Signed-off-by: Krzysztof Adamski <krzysztof.adamski@nokia.com> Reviewed-by: Alexander Sverdlin <alexander.sverdlin@nokia.com> Signed-off-by: Wolfram Sang <wsa@the-dreams.de> Signed-off-by: Sasha Levin <sashal@kernel.org>
-
Hua Su authored
[ Upstream commit fde201a4 ] Protect the list_add on the pblk_line_init_bb() error path in case this code is used for some other purpose in the future. Signed-off-by: Hua Su <suhua.tanke@gmail.com> Reviewed-by: Javier González <javier@cnexlabs.com> Signed-off-by: Matias Bjørling <mb@lightnvm.io> Signed-off-by: Jens Axboe <axboe@kernel.dk> Signed-off-by: Sasha Levin <sashal@kernel.org>
-
Hans Holmberg authored
[ Upstream commit c12fa401 ] Make sure we only look up valid lba addresses on the resubmission path. If an lba is invalidated in the write buffer, that sector will be submitted to disk (as it is already mapped to a ppa), and that write might fail, resulting in a crash when trying to look up the lba in the mapping table (as the lba is marked as invalid). Signed-off-by: Hans Holmberg <hans.holmberg@cnexlabs.com> Reviewed-by: Javier González <javier@javigon.com> Signed-off-by: Matias Bjørling <mb@lightnvm.io> Signed-off-by: Jens Axboe <axboe@kernel.dk> Signed-off-by: Sasha Levin <sashal@kernel.org>
-
Sean Paul authored
[ Upstream commit 5f79e03b ] There exists a case where a flush of a plane/dma may have been triggered & started from an async commit. If that plane/dma is subsequently disabled by the next commit, the flush register will continue to hold the flush bit for the disabled plane. Since the bit remains active, pending_kickoff_cnt will never decrement and we'll miss frame_done events. This patch limits the check of flush_register to include only those bits which have been updated with the latest commit. Changes in v2: - None Reviewed-by: Jeykumar Sankaran <jsanka@codeaurora.org> Signed-off-by: Sean Paul <seanpaul@chromium.org> Signed-off-by: Rob Clark <robdclark@gmail.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
-
Abhinav Kumar authored
[ Upstream commit c1866d44 ] Fix the dsi clock names in the DSI 10nm PLL driver to match the names in the dispcc driver as those are according to the clock plan of the chipset. Changes in v2: - Update the clock diagram with the new clock name Reviewed-by: Sean Paul <seanpaul@chromium.org> Signed-off-by: Abhinav Kumar <abhinavk@codeaurora.org> Signed-off-by: Sean Paul <seanpaul@chromium.org> Signed-off-by: Rob Clark <robdclark@gmail.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
-
Zhizhou Zhang authored
[ Upstream commit b2d102bd ] This bug occurs when: - a new request arrives, one thread(let's call it A) is pending in optee_supp_req() with req->busy is initial value false. - tee-supplicant is killed, then optee_supp_release() is called, this function calls list_del(&req->link), and set supp->ctx to NULL. And it also wake up process A. - process A continues, it firstly checks supp->ctx which is NULL, then checks req->busy which is false, at last run list_del(&req->link). This triggers double list_del() and results kernel panic. For solve this problem, we rename req->busy to req->in_queue, and associate it with state of whether req is linked to supp->reqs. So we can just only check req->in_queue to make decision calling list_del() or not. Signed-off-by: Zhizhou Zhang <zhizhouzhang@asrmicro.com> Signed-off-by: Jens Wiklander <jens.wiklander@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
-
Viresh Kumar authored
[ Upstream commit 90e3577b ] The value of opp_table->regulator_count is not very consistent right now and it may end up being 0 while we do have a "opp-microvolt" property in the OPP table. It was kept that way as we used to check if any regulators are set with the OPP core for a device or not using value of regulator_count. Lets use opp_table->regulators for that purpose as the meaning of regulator_count is going to change in the later patches. Reported-by: Quentin Perret <quentin.perret@arm.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
-
Yangtao Li authored
[ Upstream commit 9456823c ] of_find_node_by_path() acquires a reference to the node returned by it and that reference needs to be dropped by its caller. bl_idle_init() doesn't do that, so fix it. Signed-off-by: Yangtao Li <tiny.windzz@gmail.com> Acked-by: Daniel Lezcano <daniel.lezcano@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
-
Vadim Pasternak authored
[ Upstream commit edd45cba ] Shift by one the registers for tachometers (7 - 12). This fix is relevant for the same new systems MQMB7, MSN37, MSN34, which are about to be released to the customers. At the moment, none of them is at customers sites. The customers will not suffer from this change. This fix is necessary, because register used before for tachometer 7 has been than reserved for the second PWM for newer systems, which are not supported yet in mlx-platform driver. So registers of tachometers 7-12 have been shifted by one. Fixes: 0378123c ("platform/x86: mlx-platform: Add mlxreg-fan platform driver activation") Signed-off-by: Vadim Pasternak <vadimp@mellanox.com> Signed-off-by: Darren Hart (VMware) <dvhart@infradead.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
-
Anson Huang authored
[ Upstream commit 0efcc2c0 ] Same as other i.MX6 SoCs, ensure unused MMDC channel's handshake is bypassed, this is to make sure no request signal will be generated when periphe_clk_sel is changed or SRC warm reset is triggered. Signed-off-by: Anson Huang <Anson.Huang@nxp.com> Signed-off-by: Stephen Boyd <sboyd@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
-
Sergei Shtylyov authored
[ Upstream commit 9f83cfdb ] The driver overrides the error codes returned by platform_get_irq() to -EINVAL, so if it returns -EPROBE_DEFER, the driver would fail the probe permanently instead of the deferred probing. Switch to propagating the error code upstream, still checking/overriding IRQ0 as libata regards it as "no IRQ" (thus polling) anyway... Fixes: 9ec36caf ("of/irq: do irq resolution in platform_get_irq") Reviewed-by: Simon Horman <horms+renesas@verge.net.au> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com> Signed-off-by: Jens Axboe <axboe@kernel.dk> Signed-off-by: Sasha Levin <sashal@kernel.org>
-
Will Deacon authored
[ Upstream commit a868e853 ] After removing an entry from a queue (e.g. reading an event in arm_smmu_evtq_thread()) it is necessary to advance the MMIO consumer pointer to free the queue slot back to the SMMU. A memory barrier is required here so that all reads targetting the queue entry have completed before the consumer pointer is updated. The implementation of queue_inc_cons() relies on a writel() to complete the previous reads, but this is incorrect because writel() is only guaranteed to complete prior writes. This patch replaces the call to writel() with an mb(); writel_relaxed() sequence, which gives us the read->write ordering which we require. Cc: Robin Murphy <robin.murphy@arm.com> Signed-off-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
-
Vivek Gautam authored
[ Upstream commit 89cddc56 ] qcom,smmu-v2 is an arm,smmu-v2 implementation with specific clock and power requirements. On msm8996, multiple cores, viz. mdss, video, etc. use this smmu. On sdm845, this smmu is used with gpu. Add bindings for the same. Signed-off-by: Vivek Gautam <vivek.gautam@codeaurora.org> Reviewed-by: Rob Herring <robh@kernel.org> Reviewed-by: Tomasz Figa <tfiga@chromium.org> Tested-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Reviewed-by: Robin Murphy <robin.murphy@arm.com> Signed-off-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
-
Zhen Lei authored
[ Upstream commit 84a9a757 ] The GITS_TRANSLATER MMIO doorbell register in the ITS hardware is architected to be 4 bytes in size, yet on hi1620 and earlier, Hisilicon have allocated the adjacent 4 bytes to carry some IMPDEF sideband information which results in an 8-byte MSI payload being delivered when signalling an interrupt: MSIAddr: |----4bytes----|----4bytes----| | MSIData | IMPDEF | This poses no problem for the ITS hardware because the adjacent 4 bytes are reserved in the memory map. However, when delivering MSIs to memory, as we do in the SMMUv3 driver for signalling the completion of a SYNC command, the extended payload will corrupt the 4 bytes adjacent to the "sync_count" member in struct arm_smmu_device. Fortunately, the current layout allocates these bytes to padding, but this is fragile and we should make this explicit. Reviewed-by: Robin Murphy <robin.murphy@arm.com> Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com> [will: Rewrote commit message and comment] Signed-off-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
-
Tejas Joglekar authored
[ Upstream commit 244add8e ] In stream mode, when fast-forwarding TRBs, the stream number is not cleared causing the new stream to not get assigned. So we don't want controller to carry on transfers when short packet is received. So disable the CSP for stream capable endpoint. This is based on the 3.30a Programming guide, where table 3-1 device descriptor structure field definitions says for CSP bit If this bit is 0, the controller generates an XferComplete event and remove the stream. So if we keep CSP as 1 then switching between streams would not happen as in stream mode, when fast-forwarding TRBs, the stream number is not cleared causing the new stream to not get assigned. Signed-off-by: Tejas Joglekar <joglekar@synopsys.com> Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
-
Andrey Smirnov authored
[ Upstream commit 79da07de ] TPA6130A2 SD pin on RDU1 is not really controlled by SoC and instead is only meant to notify the system that audio was "muted" by external actors. To accommodate that, drop "power-gpio" property of hpa1 node as well as specify a name for that GPIO so that userspace can access it. Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com> Signed-off-by: Fabio Estevam <festevam@gmail.com> Tested-by: Chris Healy <cphealy@gmail.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
-
Wolfram Sang authored
[ Upstream commit e990e127 ] The datasheet says we must stop the timer before changing the clock divider. This can happen when the restart handler is called while the watchdog is running. Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Reviewed-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com> Reviewed-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Wim Van Sebroeck <wim@linux-watchdog.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
-
Linus Walleij authored
[ Upstream commit 738a05e6 ] The vendor firmware was analyzed to get the right idea about this flash layout. /proc/mtd contains: dev: size erasesize name mtd0: 01e7ff40 00020000 "rootfs" mtd1: 01f40000 00020000 "upgrade" mtd2: 00040000 00020000 "rgdb" mtd3: 00020000 00020000 "nvram" mtd4: 00040000 00020000 "RedBoot" mtd5: 00020000 00020000 "LangPack" mtd6: 02000000 00020000 "flash" Here "flash" is obviously the whole device and we know "rootfs" is a bogus hack to point to a squashfs rootfs inside of the main "upgrade partition". We know "RedBoot" is the first 0x40000 of the flash and the "upgrade" partition follows from 0x40000 to 0x1f8000. So we have mtd0, 1, 4 and 6 covered. Remains: mtd2: 00040000 00020000 "rgdb" mtd3: 00020000 00020000 "nvram" mtd5: 00020000 00020000 "LangPack" Inspecting the flash at 0x1f8000 and 0x1fa000 reveals each of these starting with "RGCFG1" so we assume 0x1f8000-1fbfff is "rgdb" of 0x40000. Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
-
Philipp Zabel authored
[ Upstream commit 75fa6e4f ] Add support for the third loop filter mode V4L2_MPEG_VIDEO_H264_LOOP_FILTER_MODE_DISABLED_AT_SLICE_BOUNDARY, and fix V4L2_CID_MPEG_VIDEO_H264_LOOP_FILTER_ALPHA and V4L2_CID_MPEG_VIDEO_H264_LOOP_FILTER_BETA controls. The filter offset controls are signed values in the -6 to 6 range and are stored into the slice header fields slice_alpha_c0_offset_div2 and slice_beta_offset_div2. The actual filter offsets FilterOffsetA/B are double their value, in range of -12 to 12. Rename variables to more closely match the nomenclature in the H.264 specification. Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
-
Jiong Wang authored
[ Upstream commit 17f6c83f ] For micro-mips, srlv inside POOL32A encoding space should use 0x50 sub-opcode, NOT 0x90. Some early version ISA doc describes the encoding as 0x90 for both srlv and srav, this looks to me was a typo. I checked Binutils libopcode implementation which is using 0x50 for srlv and 0x90 for srav. v1->v2: - Keep mm_srlv32_op sorted by value. Fixes: f31318fd ("MIPS: uasm: Add srlv uasm instruction") Cc: Markos Chandras <markos.chandras@imgtec.com> Cc: Paul Burton <paul.burton@mips.com> Cc: linux-mips@vger.kernel.org Acked-by: Jakub Kicinski <jakub.kicinski@netronome.com> Acked-by: Song Liu <songliubraving@fb.com> Signed-off-by: Jiong Wang <jiong.wang@netronome.com> Signed-off-by: Alexei Starovoitov <ast@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
-
Russell King - ARM Linux authored
[ Upstream commit 84fb6c7f ] It was noticed that unbinding and rebinding the KSZ8851 ethernet resulted in the driver reporting "failed to read device ID" at probe. Probing the reset line with a 'scope while repeatedly attempting to bind the driver in a shell loop revealed that the KSZ8851 RSTN pin is constantly held at zero, meaning the device is held in reset, and does not respond on the SPI bus. Experimentation with the startup delay on the regulator set to 50ms shows that the reset is positively released after 20ms. Schematics for this board are not available, and the traces are buried in the inner layers of the board which makes tracing where the RSTN pin extremely difficult. We can only guess that the RSTN pin is wired to a reset generator chip driven off the ethernet supply, which fits the observed behaviour. Include this delay in the regulator startup delay - effectively treating the reset as a "supply stable" indicator. This can not be modelled as a delay in the KSZ8851 driver since the reset generation is board specific - if the RSTN pin had been wired to a GPIO, reset could be released earlier via the already provided support in the KSZ8851 driver. This also got confirmed by Peter Ujfalusi <peter.ujfalusi@ti.com> based on Blaze schematics that should be very close to SDP4430: TPS22902YFPR is used as the regulator switch (gpio48 controlled): Convert arm boot_lock to raw The VOUT is routed to TPS3808G01DBV. (SCH Note: Threshold set at 90%. Vsense: 0.405V). According to the TPS3808 data sheet the RESET delay time when Ct is open (this is the case in the schema): MIN/TYP/MAX: 12/20/28 ms. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Reviewed-by: Peter Ujfalusi <peter.ujfalusi@ti.com> [tony@atomide.com: updated with notes from schematics from Peter] Signed-off-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
-
Yu Zhao authored
[ Upstream commit c12b08eb ] The parameter is still there but it's ignored. We need to check its value before deciding to go into passthrough mode for AMD IOMMU v2 capable device. We occasionally use this parameter to force v2 capable device into translation mode to debug memory corruption that we suspect is caused by DMA writes. To address the following comment from Joerg Roedel on the first version, v2 capability of device is completely ignored. > This breaks the iommu_v2 use-case, as it needs a direct mapping for the > devices that support it. And from Documentation/admin-guide/kernel-parameters.txt: This option does not override iommu=pt Fixes: aafd8ba0 ("iommu/amd: Implement add_device and remove_device") Signed-off-by: Yu Zhao <yuzhao@google.com> Signed-off-by: Joerg Roedel <jroedel@suse.de> Signed-off-by: Sasha Levin <sashal@kernel.org>
-
Nicholas Mc Guire authored
[ Upstream commit a9d9f6b8 ] devm_kstrdup() may return NULL if internal allocation failed. Thus using label, name is unsafe without checking. Therefor in the unlikely case of allocation failure, sx150x_probe() simply returns -ENOMEM. Signed-off-by: Nicholas Mc Guire <hofrat@osadl.org> Fixes: 9e80f906 ("pinctrl: Add SX150X GPIO Extender Pinctrl Driver") Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
-
Nicholas Mc Guire authored
[ Upstream commit a109c2db ] The error cases of mediatek_gpio_bank_probe() would go unnoticed (except for the dev_err() messages). The probe function should return an error if one of the banks failed to initialize properly indicated by not returning non-0. Fixes: 4ba9c3af ("gpio: mt7621: Add a driver for MT7621") Signed-off-by: Nicholas Mc Guire <hofrat@osadl.org> Acked-by: Sean Wang <sean.wang@kernel.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
-
Nicholas Mc Guire authored
[ Upstream commit 59d646c7 ] kasprintf() may return NULL on failure of internal allocation thus the assigned label is not safe if not explicitly checked. On error mediatek_gpio_bank_probe() returns negative values so -ENOMEM in the (unlikely) failure case should be fine here. Fixes: 4ba9c3af ("gpio: mt7621: Add a driver for MT7621") Signed-off-by: Nicholas Mc Guire <hofrat@osadl.org> Reviewed-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Acked-by: Sean Wang <sean.wang@kernel.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
-
Andy Shevchenko authored
[ Upstream commit 54d48183 ] The missed break statement in the outer switch makes the code fall through always and thus always same value will be printed. Besides that, compiler warns about missed fall through marker: drivers/usb/dwc3/./trace.h: In function ‘trace_raw_output_dwc3_log_trb’: drivers/usb/dwc3/./trace.h:246:4: warning: this statement may fall through [-Wimplicit-fallthrough=] switch (pcm) { ^~~~~~ Add the missing break statement to work correctly without compilation warnings. Fixes: fa8d965d ("usb: dwc3: trace: pretty print high-bandwidth transfers too") Cc: Felipe Balbi <felipe.balbi@linux.intel.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
-
Kaike Wan authored
[ Upstream commit ca95f802 ] Currently, When a reserved operation is completed, its entry in the send queue will not be unreserved, which leads to the miscalculation of qp->s_avail and thus the triggering of a WARN_ON call trace. This patch fixes the problem by unreserving the reserved operation when it is completed. Fixes: 856cc4c2 ("IB/hfi1: Add the capability for reserved operations") Reviewed-by: Mike Marciniszyn <mike.marciniszyn@intel.com> Signed-off-by: Kaike Wan <kaike.wan@intel.com> Signed-off-by: Dennis Dalessandro <dennis.dalessandro@intel.com> Signed-off-by: Jason Gunthorpe <jgg@mellanox.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
-
Peter Rajnoha authored
[ Upstream commit df44b479 ] Propagate error code back to userspace if writing the /sys/.../uevent file fails. Before, the write operation always returned with success, even if we failed to recognize the input string or if we failed to generate the uevent itself. With the error codes properly propagated back to userspace, we are able to react in userspace accordingly by not assuming and awaiting a uevent that is not delivered. Signed-off-by: Peter Rajnoha <prajnoha@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
-