- 20 Nov, 2019 40 commits
-
-
Srinivas Kandagatla authored
[ Upstream commit 94fe5f2b ] Register slimbus controller only after finishing powerup sequnce so that we do not endup in situation where core starts sending transactions before the controller is ready. Signed-off-by:
Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Srinivas Kandagatla authored
[ Upstream commit 9652e6aa ] It looks like there is a typo in probe return. Fix it. Signed-off-by:
-
Srinivas Kandagatla authored
[ Upstream commit 1830dad3 ] Move ngd platform driver out of loop so that it registers only once. Signed-off-by:
-
Suzuki K Poulose authored
[ Upstream commit 30af4fb6 ] When a replicator port is enabled, we block the traffic on the other port and route all traffic to the new enabled port. If there are two active trace sessions each targeting the two different paths from the replicator, the second session will disable the first session and route all the data to the second path. ETR / e.g, replicator \ ETB If CPU0 is operated in sysfs mode to ETR and CPU1 is operated in perf mode to ETB, depending on the order in which the replicator is enabled one device is blocked. Ideally we need trace-id for the session to make the right choice. That implies we need a trace-id allocation logic for the coresight subsystem and use that to route the traffic. The short term solution is to only manage the "target port" and leave the other port untouched. That leaves both the paths unaffected, except that some unwanted traffic may be pushed to the paths (if the Trace-IDs are not far enough), which is still fine and can be filtered out while processing rather than silently blocking the data. Cc: Mathieu Poirier <mathieu.poirier@linaro.org> Signed-off-by:
Suzuki K Poulose <suzuki.poulose@arm.com> Signed-off-by:
Mathieu Poirier <mathieu.poirier@linaro.org> Signed-off-by:
-
Leo Yan authored
[ Upstream commit e7753f39 ] >From the comment in the code, it claims the requirement for byte-address alignment for RRP register: 'for 32-bit, 64-bit and 128-bit wide trace memory, the four LSBs must be 0s. For 256-bit wide trace memory, the five LSBs must be 0s'. This isn't consistent with the program, the program sets five LSBs as zeros for 32/64/128-bit wide trace memory and set six LSBs zeros for 256-bit wide trace memory. After checking with the CoreSight Trace Memory Controller technical reference manual (ARM DDI 0461B, section 3.3.4 RAM Read Pointer Register), it proves the comment is right and the program does wrong setting. This patch fixes byte-address alignment for RRP by following correct definition in the technical reference manual. Cc: Mathieu Poirier <mathieu.poirier@linaro.org> Cc: Mike Leach <mike.leach@linaro.org> Signed-off-by:
Leo Yan <leo.yan@linaro.org> Signed-off-by:
-
Tomasz Nowicki authored
[ Upstream commit b860801e ] For non-VHE systems host kernel runs at EL1 and jumps to EL2 whenever hypervisor code should be executed. In this case ETM4x driver must restrict configuration to EL1 when it setups kernel tracing. However, there is no separate hypervisor privilege level when VHE is enabled, the host kernel runs at EL2. This patch fixes configuration of TRCACATRn register for VHE systems so that ETM_EXLEVEL_NS_HYP bit is used instead of ETM_EXLEVEL_NS_OS to on/off kernel tracing. At the same time, it moves common code to new helper. Signed-off-by:
Tomasz Nowicki <tnowicki@caviumnetworks.com> Signed-off-by:
-
Suzuki K Poulose authored
[ Upstream commit 96a7f644 ] Since the ETR could be driven either by SYSFS or by perf, it becomes complicated how we deal with the buffers used for each of these modes. The ETR driver cannot simply free the current attached buffer without knowing the provider (i.e, sysfs vs perf). To solve this issue, we provide: 1) the driver-mode specific etr buffer to be retained in the drvdata 2) the etr_buf for a session should be passed on when enabling the hardware, which will be stored in drvdata->etr_buf. This will be replaced (not free'd) as soon as the hardware is disabled, after necessary sync operation. The advantages of this are : 1) The common code path doesn't need to worry about how to dispose an existing buffer, if it is about to start a new session with a different buffer, possibly in a different mode. 2) The driver mode can control its buffers and can get access to the saved session even when the hardware is operating in a different mode. (e.g, we can still access a trace buffer from a sysfs mode even if the etr is now used in perf mode, without disrupting the current session.) Towards this, we introduce a sysfs specific data which will hold the etr_buf used for sysfs mode of operation, controlled solely by the sysfs mode handling code. Cc: Mathieu Poirier <mathieu.poirier@linaro.org> Signed-off-by:
-
Suzuki K Poulose authored
[ Upstream commit 4f8ef210 ] We enable the trace path, before activating the source. If we fail to enable the source, we must disable the path to make sure it is available for another session. Cc: Mathieu Poirier <mathieu.poirier@linaro.org> Signed-off-by:
-
Suzuki K Poulose authored
[ Upstream commit 5ecabe4a ] We create a coresight trace path for each online CPU when we start the event. We rely on the number of online CPUs and then go on to allocate an array matching the "number of online CPUs" for holding the path and then uses normal CPU id as the index to the array. This is problematic as we could have some offline CPUs causing us to access beyond the actual array size (e.g, on a dual SMP system, if CPU0 is offline, CPU1 could be really accessing beyond the array). The solution is to switch to per-cpu array for holding the path. Cc: Mathieu Poirier <mathieu.poirier@linaro.org> Signed-off-by:
-
Suzuki K Poulose authored
[ Upstream commit c71369de ] The coresight components could be operated either in sysfs mode or in perf mode. For some of the components, the mode of operation doesn't matter as they simply relay the data to the next component in the trace path. But for sinks, they need to be able to provide the trace data back to the user. Thus we need to make sure that "mode" is handled appropriately. e.g, the sysfs mode could have multiple sources driving the trace data, while perf mode doesn't allow sharing the sink. The coresight_enable_sink() however doesn't really allow this check to trigger as it skips the "enable_sink" callback if the component is already enabled, irrespective of the mode. This could cause mixing of data from different modes or even same mode (in perf), if the sources are different. Also, if we fail to enable the sink while enabling a path (where sink is the first component enabled), we could end up in disabling the components in the "entire" path which were not enabled in this trial, causing disruptions in the existing trace paths. Cc: Mathieu Poirier <mathieu.poirier@linaro.org> Signed-off-by:
-
zhong jiang authored
[ Upstream commit bbd35ba6 ] Use ERR_CAT inlined function to replace the ERR_PTR(PTR_ERR). It make the code more concise. Signed-off-by:
zhong jiang <zhongjiang@huawei.com> Signed-off-by:
-
Laurent Pinchart authored
[ Upstream commit 8dbf9c7a ] When USB requests for video data fail to be submitted, the driver signals a problem to the host by halting the video streaming endpoint. This is only valid in bulk mode, as isochronous transfers have no handshake phase and can't thus report a stall. The usb_ep_set_halt() call returns an error when using isochronous endpoints, which we happily ignore, but some UDCs complain in the kernel log. Fix this by only trying to halt the endpoint in bulk mode. Signed-off-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by:
Paul Elder <paul.elder@ideasonboard.com> Tested-by:
Kieran Bingham <kieran.bingham@ideasonboard.com> Signed-off-by:
-
Laurent Pinchart authored
[ Upstream commit 9d1ff5dc ] USB requests for video data are queued from two different locations in the driver, with the same code block occurring twice. Factor it out to a function. Signed-off-by:
-
Anson Huang authored
[ Upstream commit 245f880c ] Update VDD_SOC voltage to 1.25V for 900MHz operating point according to datasheet Rev. 1.3, 08/2018, 25mV is added to the minimum allowed values to cover power supply ripple. Signed-off-by:
Anson Huang <Anson.Huang@nxp.com> Reviewed-by:
Sébastien Szymanski <sebastien.szymanski@armadeus.com> Signed-off-by:
Shawn Guo <shawnguo@kernel.org> Signed-off-by:
-
Andreas Kemnade authored
[ Upstream commit 6c7103aa ] When runtime is not enabled, pm_runtime_get_sync() returns -EACCESS, the counter will be incremented but the resume callback not called, so enumeration and charging will not start properly. To avoid that happen, disable irq on suspend and recheck on resume. Practically this happens when the device is woken up from suspend by plugging in usb. Signed-off-by:
Andreas Kemnade <andreas@kemnade.info> Signed-off-by:
Kishon Vijay Abraham I <kishon@ti.com> Signed-off-by:
-
Yoshihiro Shimoda authored
[ Upstream commit 09938ea9 ] This patch fixes and issue that the vbus_ctrl is disabled by rcar_gen3_init_from_a_peri_to_a_host(), so a usb host cannot supply the vbus. Note that this condition will exit when the otg irq happens even if we don't apply this patch. Fixes: 9bb86777 ("phy: rcar-gen3-usb2: add sysfs for usb role swap") Signed-off-by:
Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Reviewed-by:
Simon Horman <horms+renesas@verge.net.au> Signed-off-by:
-
Florian Fainelli authored
[ Upstream commit 26728df4 ] Broadcom ARM-based DSL SoCs (BCM63xx product line) have the same Broadcom SATA PHY that other SoCs are using, make it possible to select that driver on these platforms. Signed-off-by:
Florian Fainelli <f.fainelli@gmail.com> Signed-off-by:
-
zhong jiang authored
[ Upstream commit 95590a62 ] of_find_device_by_node takes a reference to the struct device when it finds a match via get_device. but it fails to put_device in at91_pm_config_ws, for_each_matching_node_and_match will get and put the node properly, there is no need to call the of_put_node. Therefore, just call put_device instead of of_node_put in at91_pm_config_ws. Fixes: d7484f5c ("ARM: at91: pm: configure wakeup sources for ULP1 mode") Suggested-by:
Claudiu Beznea <Claudiu.Beznea@microchip.com> Signed-off-by:
Alexandre Belloni <alexandre.belloni@bootlin.com> Signed-off-by:
-
Ricardo Ribalda Delgado authored
[ Upstream commit ae9847f4 ] GPIOs with no programmable direction are not required to implement direction_output nor direction_input. If we try to set an output direction on an output-only GPIO or input direction on an input-only GPIO simply return 0. This allows this single direction GPIO to be used by libgpiod. Signed-off-by:
Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com> Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
-
Brendan Higgins authored
[ Upstream commit 17ccba67 ] The function that computes clock parameters from divisors did not respect the maximum size of the bitfields that the parameters were written to. This fixes the bug. This bug can be reproduced with (and this fix verified with) the test at: https://kunit-review.googlesource.com/c/linux/+/1035/ Discovered-by-KUnit: https://kunit-review.googlesource.com/c/linux/+/1035/Signed-off-by:
Brendan Higgins <brendanhiggins@google.com> Reviewed-by:
Jae Hyun Yoo <jae.hyun.yoo@linux.intel.com> Signed-off-by:
Wolfram Sang <wsa@the-dreams.de> Signed-off-by:
-
Marek Szyprowski authored
[ Upstream commit ff1e37c6 ] The proper parent clock for audio subsystem for Exynos5420 and Exynos5800 SoCs is CLK_MAU_EPLL. This fixes following warning: clk: failed to reparent mout_audss to fout_epll: -22 Fixes: ed7d1307: ARM: dts: exynos: Enable HDMI audio support on Peach Pit Fixes: bae0f445: ARM: dts: exynos: Enable HDMI audio support on Peach Pi Signed-off-by:
Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by:
Krzysztof Kozlowski <krzk@kernel.org> Signed-off-by:
-
Paul Elder authored
[ Upstream commit 89969a84 ] There is an issue where the host is unable to tell the gadget what frame rate it wants if the dwFrameIntervals in the interface descriptors are not in ascending order. This means that when instantiating a uvc gadget via configfs the user must make sure the dwFrameIntervals are in ascending order. Instead of silently failing the breaking of this rule, we sort the dwFrameIntervals upon writing to configfs. Signed-off-by:
-
Joel Pepper authored
[ Upstream commit cb2200f7 ] While checks are in place to avoid attributes and children of a format being manipulated after the format is linked into the streaming header, the linked flag was never actually set, invalidating the protections. Update the flag as appropriate in the header link calls. Signed-off-by:
Joel Pepper <joel.pepper@rwth-aachen.de> Reviewed-by:
-
Laurent Pinchart authored
[ Upstream commit 86f3daed ] Some of the .allow_link() and .drop_link() operations implementations call config_group_find_item() and then leak the reference to the returned item. Fix this by dropping those references where needed. Signed-off-by:
-
Heiko Stuebner authored
[ Upstream commit a2df0984 ] It is good practice to make the setting of gpio-pinctrls explicitly in the devicetree, and in this case even necessary. Rockchip boards start with iomux settings set to gpio for most pins and while the linux pinctrl driver also implicitly sets the gpio function if a pin is requested as gpio that is not necessarily true for other drivers. The issue in question stems from uboot, where the sdmmc_pwr pin is set to function 1 (sdmmc-power) by the bootrom when reading the 1st-stage loader. The regulator controlled by the pin is active-low though, so when the dwmmc hw-block sets its enabled bit, it actually disables the regulator. By changing the pin back to gpio we fix that behaviour. Signed-off-by:
Heiko Stuebner <heiko@sntech.de> Signed-off-by:
-
Nathan Chancellor authored
[ Upstream commit 41587573 ] Clang warns when one enumerated type is implicitly converted to another. drivers/media/platform/davinci/vpbe_display.c:524:24: warning: implicit conversion from enumeration type 'enum osd_v_exp_ratio' to different enumeration type 'enum osd_h_exp_ratio' [-Wenum-conversion] layer_info->h_exp = V_EXP_6_OVER_5; ~ ^~~~~~~~~~~~~~ 1 warning generated. This appears to be a copy and paste error judging from the couple of lines directly above this statement and the way that height is handled in the if block above this one. Reported-by:
Nick Desaulniers <ndesaulniers@google.com> Signed-off-by:
Nathan Chancellor <natechancellor@gmail.com> Signed-off-by:
Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by:
Mauro Carvalho Chehab <mchehab+samsung@kernel.org> Signed-off-by:
-
Brad Love authored
[ Upstream commit f347596f ] Correcting red herring error messages. Where appropriate, replaces au0282_dev_register with: - au0828_analog_register - au0828_dvb_register Signed-off-by:
Brad Love <brad@nextdimension.cc> Signed-off-by:
-
Jia-Ju Bai authored
[ Upstream commit 8d11eb84 ] The driver may sleep in a interrupt handler. The function call paths (from bottom to top) in Linux-4.16 are: [FUNC] kzalloc(GFP_KERNEL) drivers/media/pci/ivtv/ivtv-yuv.c, 938: kzalloc in ivtv_yuv_init drivers/media/pci/ivtv/ivtv-yuv.c, 960: ivtv_yuv_init in ivtv_yuv_next_free drivers/media/pci/ivtv/ivtv-yuv.c, 1126: ivtv_yuv_next_free in ivtv_yuv_setup_stream_frame drivers/media/pci/ivtv/ivtv-irq.c, 827: ivtv_yuv_setup_stream_frame in ivtv_irq_dec_data_req drivers/media/pci/ivtv/ivtv-irq.c, 1013: ivtv_irq_dec_data_req in ivtv_irq_handler To fix this bug, GFP_KERNEL is replaced with GFP_ATOMIC. This bug is found by my static analysis tool DSAC. Signed-off-by:
Jia-Ju Bai <baijiaju1990@gmail.com> Signed-off-by:
-
Arnd Bergmann authored
[ Upstream commit 8d1a4817 ] A warning that I thought to be solved by a previous patch of mine has resurfaced with gcc-8: media/imx/imx-media-csi.c: In function 'csi_link_validate': media/imx/imx-media-csi.c:1025:20: error: 'upstream_ep' may be used uninitialized in this function [-Werror=maybe-uninitialized] media/imx/imx-media-csi.c:1026:24: error: 'upstream_ep.bus_type' may be used uninitialized in this function [-Werror=maybe-uninitialized] media/imx/imx-media-csi.c:127:19: error: 'upstream_ep.bus.parallel.bus_width' may be used uninitialized in this function [-Werror=maybe-uninitialized] media/imx/imx-media-csi.c: In function 'csi_enum_mbus_code': media/imx/imx-media-csi.c:132:9: error: '*((void *)&upstream_ep+12)' may be used uninitialized in this function [-Werror=maybe-uninitialized] media/imx/imx-media-csi.c:132:48: error: 'upstream_ep.bus.parallel.bus_width' may be used uninitialized in this function [-Werror=maybe-uninitialized] I spent some more time digging in this time, and think I have a better fix, bailing out of the function that either initializes or errors out here, which simplifies the code enough for gcc to figure out what is going on. The earlier partial workaround can be removed now, as the new workaround is better. Fixes: 890f2769 ("media: imx: work around false-positive warning") Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
-
Petr Machata authored
[ Upstream commit 12ba7e10 ] Up until now, mlxsw tolerated firmware versions that weren't exactly matching the required version, if the branch number matched. That allowed the users to test various firmware versions as long as they were on the right branch. On the other hand, it made it impossible for mlxsw to put a hard lower bound on a version that fixes all problems known to date. If a user had a somewhat older FW version installed, mlxsw would start up just fine, possibly performing non-optimally as it would use features that trigger problematic behavior. Therefore tweak the check to accept any FW version that is: - on the same branch as the preferred version, and - the same as or newer than the preferred version. Signed-off-by:
Petr Machata <petrm@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:
-
Vicente Bergas authored
[ Upstream commit 88a20edf ] The microSD card slot in the Sapphire board is not working because of several issues: 1.- The vmmc power supply is missing in the DTS. It is capable of 3.0V and has a GPIO-based enable control. 2.- The vqmmc power supply can provide up to 3.3V, but it is capped in the DTS to just 3.0V because of the vmmc capability. This results in a conflict from the mmc driver requesting an unsupportable voltage range from 3.3V to 3.0V (min > max) as reported in dmesg. So, extend the range up to 3.3V. The hw should be able to stand this 0.3V tolerance. See mmc_regulator_set_vqmmc in drivers/mmc/core/core.c. 3.- The card detect signal is non-working. There is a known conflict with jtag, but the workaround in drivers/soc/rockchip/grf.c does not work. Adding the broken-cd attribute to the DTS fixes the issue. Signed-off-by:
Vicente Bergas <vicencb@gmail.com> Signed-off-by:
-
Dengcheng Zhu authored
[ Upstream commit a6da4d6f ] We can rely on the system kernel and the dump capture kernel themselves in memory usage. Being restrictive with 512MB limit may cause kexec tool failure on some platforms. Tested-by:
Rachel Mozes <rachel.mozes@intel.com> Reported-by:
Dengcheng Zhu <dzhu@wavecomp.com> Signed-off-by:
Paul Burton <paul.burton@mips.com> Patchwork: https://patchwork.linux-mips.org/patch/20568/ Cc: pburton@wavecomp.com Cc: ralf@linux-mips.org Cc: linux-mips@linux-mips.org Signed-off-by:
-
Qiuxu Zhuo authored
[ Upstream commit 6f6da136 ] The {i3200|i7core|sb|skx}_edac drivers show DIMM capacity using the wrong unit symbol: 'Mb' - megabit. Fix them by replacing 'Mb' with 'MiB' - mebibyte. [Tony: These are all "edac_dbg()" messages, so this won't break scripts that parse console logs.] Signed-off-by:
Qiuxu Zhuo <qiuxu.zhuo@intel.com> Signed-off-by:
Tony Luck <tony.luck@intel.com> Signed-off-by:
Borislav Petkov <bp@suse.de> Acked-by:
Aristeu Rozanski <aris@redhat.com> Cc: Mauro Carvalho Chehab <mchehab@kernel.org> Cc: linux-edac@vger.kernel.org Link: https://lkml.kernel.org/r/20180919003433.16475-1-tony.luck@intel.comSigned-off-by:
-
Matthew Whitehead authored
[ Upstream commit 2893cc8f ] Presently we check first if CPUID is enabled. If it is not already enabled, then we next call identify_cpu_without_cpuid() and clear X86_FEATURE_CPUID. Unfortunately, identify_cpu_without_cpuid() is the function where CPUID becomes _enabled_ on Cyrix 6x86/6x86L CPUs. Reverse the calling sequence so that CPUID is first enabled, and then check a second time to see if the feature has now been activated. [ bp: Massage commit message and remove trailing whitespace. ] Suggested-by:
Andy Lutomirski <luto@amacapital.net> Signed-off-by:
Matthew Whitehead <tedheadster@gmail.com> Signed-off-by:
-
Matthew Whitehead authored
[ Upstream commit 03b099bd ] There are comments in processor-cyrix.h advising you to _not_ make calls using the deprecated macros in this style: setCx86_old(CX86_CCR4, getCx86_old(CX86_CCR4) | 0x80); This is because it expands the macro into a non-functioning calling sequence. The calling order must be: outb(CX86_CCR2, 0x22); inb(0x23); From the comments: * When using the old macros a line like * setCx86(CX86_CCR2, getCx86(CX86_CCR2) | 0x88); * gets expanded to: * do { * outb((CX86_CCR2), 0x22); * outb((({ * outb((CX86_CCR2), 0x22); * inb(0x23); * }) | 0x88), 0x23); * } while (0); The new macros fix this problem, so use them instead. Signed-off-by:
-
YueHaibing authored
[ Upstream commit 06983aa5 ] The method ndo_start_xmit() is defined as returning an 'netdev_tx_t', which is a typedef for an enum type, so make sure the implementation in this driver has returns 'netdev_tx_t' value, and change the function return type to netdev_tx_t. Found by coccinelle. Signed-off-by:
YueHaibing <yuehaibing@huawei.com> Signed-off-by:
-
YueHaibing authored
[ Upstream commit 2b49117a ] The method ndo_start_xmit() is defined as returning an 'netdev_tx_t', which is a typedef for an enum type, so make sure the implementation in this driver has returns 'netdev_tx_t' value, and change the function return type to netdev_tx_t. Found by coccinelle. Signed-off-by:
-
Florian Fainelli authored
[ Upstream commit b78ac6ec ] Allow the configuration of the MDIO clock divider when the Device Tree contains 'clock-frequency' property (similar to I2C and SPI buses). Because the hardware may have lost its state during suspend/resume, re-apply the MDIO clock divider upon resumption. Signed-off-by:
-
Prashant Bhole authored
[ Upstream commit 32c00979 ] following commit: commit d58e468b ("flow_dissector: implements flow dissector BPF hook") added struct bpf_flow_keys which conflicts with the struct with same name in sockex2_kern.c and sockex3_kern.c similar to commit: commit 534e0e52 ("samples/bpf: fix a compilation failure") we tried the rename it "flow_keys" but it also conflicted with struct having same name in include/net/flow_dissector.h. Hence renaming the struct to "flow_key_record". Also, this commit doesn't fix the compilation error completely because the similar struct is present in sockex3_kern.c. Hence renaming it in both files sockex3_user.c and sockex3_kern.c Signed-off-by:
Prashant Bhole <bhole_prashant_q7@lab.ntt.co.jp> Acked-by:
Song Liu <songliubraving@fb.com> Signed-off-by:
Daniel Borkmann <daniel@iogearbox.net> Signed-off-by:
-
Keith Busch authored
[ Upstream commit c4eed62a ] The secondary bus reset may have link side effects that a hotplug capable port may incorrectly react to. Use the slot specific reset for hotplug ports, fixing the undesirable link down-up handling during error recovering. Signed-off-by:
Keith Busch <keith.busch@intel.com> [bhelgaas: fold in https://lore.kernel.org/linux-pci/20180926152326.14821-1-keith.busch@intel.com for issue reported by Stephen Rothwell <sfr@canb.auug.org.au>] Signed-off-by:
Bjorn Helgaas <bhelgaas@google.com> Reviewed-by:
Sinan Kaya <okaya@kernel.org> Signed-off-by:
-
