- 27 Jan, 2020 40 commits
-
-
Bryan O'Donoghue authored
[ Upstream commit 0493c479 ] The i.MX6 and i.MX8 both have a bit-field spanning bits 27:22 called the WAIT field. The WAIT field according to the documentation for both parts "specifies time interval between auto read and write access in one time program. It is given in number of ipg_clk periods." This patch ensures that the relevant field is read and written back to the timing register. Fixes: 0642bac7 ("nvmem: imx-ocotp: add write support") Signed-off-by:
Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by:
Leonard Crestez <leonard.crestez@nxp.com> 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>
-
Nathan Huckleberry authored
[ Upstream commit da642427 ] Clang produces the following warning drivers/clk/qcom/gcc-msm8996.c:133:32: warning: unused variable 'gcc_xo_gpll0_gpll2_gpll3_gpll0_early_div_map' [-Wunused-const-variable] static const struct parent_map gcc_xo_gpll0_gpll2_gpll3_gpll0_early_div_map[] = { ^drivers/clk/qcom/gcc-msm8996.c:141:27: warning: unused variable 'gcc_xo_gpll0_gpll2_gpll3_gpll0_early_div' [-Wunused-const-variable] static const char * const gcc_xo_gpll0_gpll2_gpll3_gpll0_early_div[] = { ^ drivers/clk/qcom/gcc-msm8996.c:187:32: warning: unused variable 'gcc_xo_gpll0_gpll2_gpll3_gpll1_gpll4_gpll0_early_div_map' [-Wunused-const-variable] static const struct parent_map gcc_xo_gpll0_gpll2_gpll3_gpll1_gpll4_gpll0_early_div_map[] = { ^ drivers/clk/qcom/gcc-msm8996.c:197:27: warning: unused variable 'gcc_xo_gpll0_gpll2_gpll3_gpll1_gpll4_gpll0_early_div' [-Wunused-const-variable] static const char * const gcc_xo_gpll0_gpll2_gpll3_gpll1_gpll4_gpll0_early_div[] = { It looks like these were never used. Fixes: b1e010c0 ("clk: qcom: Add MSM8996 Global Clock Control (GCC) driver") Cc: clang-built-linux@googlegroups.com Link: https://github.com/ClangBuiltLinux/linux/issues/518Suggested-by:
Nathan Chancellor <natechancellor@gmail.com> Signed-off-by:
Nathan Huckleberry <nhuck@google.com> Reviewed-by:
Stephen Boyd <sboyd@kernel.org> Signed-off-by:
-
Andy Shevchenko authored
[ Upstream commit c24a5c73 ] The commit 080edf75 ("dmaengine: hsu: set HSU_CH_MTSR to memory width") has been mistakenly submitted. The further investigations show that the original code does better job since the memory side transfer size has never been configured by DMA users. As per latest revision of documentation: "Channel minimum transfer size (CHnMTSR)... For IOSF UART, maximum value that can be programmed is 64 and minimum value that can be programmed is 1." This reverts commit 080edf75. Fixes: 080edf75 ("dmaengine: hsu: set HSU_CH_MTSR to memory width") Signed-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by:
Vinod Koul <vkoul@kernel.org> Signed-off-by:
-
Ravi Bangoria authored
[ Upstream commit 913a90bc ] perf_event_open() limits the sample_period to 63 bits. See: 0819b2e3 ("perf: Limit perf_event_attr::sample_period to 63 bits") Make ioctl() consistent with it. Also on PowerPC, negative sample_period could cause a recursive PMIs leading to a hang (reported when running perf-fuzzer). Signed-off-by:
Ravi Bangoria <ravi.bangoria@linux.ibm.com> Signed-off-by:
Peter Zijlstra (Intel) <peterz@infradead.org> Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com> Cc: Arnaldo Carvalho de Melo <acme@redhat.com> Cc: Jiri Olsa <jolsa@redhat.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Stephane Eranian <eranian@google.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Vince Weaver <vincent.weaver@maine.edu> Cc: acme@kernel.org Cc: linuxppc-dev@lists.ozlabs.org Cc: maddy@linux.vnet.ibm.com Cc: mpe@ellerman.id.au Fixes: 0819b2e3 ("perf: Limit perf_event_attr::sample_period to 63 bits") Link: https://lkml.kernel.org/r/20190604042953.914-1-ravi.bangoria@linux.ibm.comSigned-off-by:
Ingo Molnar <mingo@kernel.org> Signed-off-by:
-
Stefano Brivio authored
[ Upstream commit 40cb35d5 ] When we perform an inexact match on FIB nodes via fib6_locate_1(), longer prefixes will be preferred to shorter ones. However, it might happen that a node, with higher fn_bit value than some other, has no valid routing information. In this case, we'll pick that node, but it will be discarded by the check on RTN_RTINFO in fib6_locate(), and we might miss nodes with valid routing information but with lower fn_bit value. This is apparent when a routing exception is created for a default route: # ip -6 route list fc00:1::/64 dev veth_A-R1 proto kernel metric 256 pref medium fc00:2::/64 dev veth_A-R2 proto kernel metric 256 pref medium fc00:4::1 via fc00:2::2 dev veth_A-R2 metric 1024 pref medium fe80::/64 dev veth_A-R1 proto kernel metric 256 pref medium fe80::/64 dev veth_A-R2 proto kernel metric 256 pref medium default via fc00:1::2 dev veth_A-R1 metric 1024 pref medium # ip -6 route list cache fc00:4::1 via fc00:2::2 dev veth_A-R2 metric 1024 expires 593sec mtu 1500 pref medium fc00:3::1 via fc00:1::2 dev veth_A-R1 metric 1024 expires 593sec mtu 1500 pref medium # ip -6 route flush cache # node for default route is discarded Failed to send flush request: No such process # ip -6 route list cache fc00:3::1 via fc00:1::2 dev veth_A-R1 metric 1024 expires 586sec mtu 1500 pref medium Check right away if the node has a RTN_RTINFO flag, before replacing the 'prev' pointer, that indicates the longest matching prefix found so far. Fixes: 38fbeeee ("ipv6: prepare fib6_locate() for exception table") Signed-off-by:
Stefano Brivio <sbrivio@redhat.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Rob Clark authored
[ Upstream commit f47bee2b ] These regs are write-only, and the hw throws a hissy-fit (ie. reboots) when we try to read them for GPU state snapshot, in response to a GPU hang. It is rather impolite when GPU recovery triggers an insta- reboot, so lets remove the TPL1 registers from the snapshot. Fixes: 7198e6b0 drm/msm: add a3xx gpu support Signed-off-by:
Rob Clark <robdclark@chromium.org> Reviewed-by:
Jordan Crouse <jcrouse@codeaurora.org> Signed-off-by:
-
Chen-Yu Tsai authored
[ Upstream commit 0bb9d187 ] The external PCF8563 RTC chip's interrupt line is connected to the NMI line on the SoC. Add the interrupt line to the device tree. Fixes: 17ebc33a ("arm64: allwinner: h6: add PCF8563 RTC on Pine H64 board") Acked-by:
Maxime Ripard <maxime.ripard@bootlin.com> Signed-off-by:
Chen-Yu Tsai <wens@csie.org> Signed-off-by:
-
YueHaibing authored
[ Upstream commit 45d5cb13 ] If register_qdisc fails, we should unregister netdevice notifier. Reported-by:
Hulk Robot <hulkci@huawei.com> Fixes: e0a7683d ("net/sched: cbs: fix port_rate miscalculation") Signed-off-by:
YueHaibing <yuehaibing@huawei.com> Signed-off-by:
-
Fabrizio Castro authored
[ Upstream commit d211650a ] SDR50 isn't working anymore because the GPIO regulator driver is using descriptors since commit d6cd33ad ("regulator: gpio: Convert to use descriptors") which in turn causes the system to use the polarity of the GPIOs (as specified in the DT) for selecting the states, but the polarity specified in the DT is wrong. This patch fixes the regulator DT definition, and that fixes SDR50. Fixes: 029efb3a ("ARM: dts: iwg20d-q7: Add SDHI1 support") Signed-off-by:
Fabrizio Castro <fabrizio.castro@bp.renesas.com> Signed-off-by:
Simon Horman <horms+renesas@verge.net.au> Signed-off-by:
-
Chen-Yu Tsai authored
[ Upstream commit 3572e8ae ] Besides the alarm, the PCF8563 also has a timer triggered interrupt. In cases where the previous system left the timer and interrupts on, or somehow the bits got enabled, the interrupt would keep triggering as the kernel doesn't know about it. Clear both the alarm and timer event flags, and disable the interrupts, before requesting the interrupt line. Fixes: ede3e9d4 ("drivers/rtc/rtc-pcf8563.c: add alarm support") Fixes: a45d528a ("rtc: pcf8563: clear expired alarm at boot time") Signed-off-by:
Alexandre Belloni <alexandre.belloni@bootlin.com> Signed-off-by:
-
Chen-Yu Tsai authored
[ Upstream commit 65f662cb ] The PCF8563 datasheet says the interrupt line is active low and stays active until the events are cleared, i.e. a level trigger interrupt. Fix the flags used to request the interrupt. Fixes: ede3e9d4 ("drivers/rtc/rtc-pcf8563.c: add alarm support") Signed-off-by:
-
Peter Ujfalusi authored
[ Upstream commit fd14f443 ] If multiple serializers are connected in the system and the number of channels will need to use more than one serializer the mask to enable the serializers were left to 0 if tdm_mask is provided Fixes: dd55ff83 ("ASoC: davinci-mcasp: Add set_tdm_slots() support") Signed-off-by:
Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by:
Mark Brown <broonie@kernel.org> Signed-off-by:
-
Julian Wiedmann authored
[ Upstream commit 06996c1d ] Even when running as VM guest (ie pr_iucv != NULL), af_iucv can still open HiperTransport-based connections. For robust operation these connections require the af_iucv_netdev_notifier, so register it unconditionally. Also handle any error that register_netdevice_notifier() returns. Fixes: 9fbd87d4 ("af_iucv: handle netdev events") Signed-off-by:
Julian Wiedmann <jwi@linux.ibm.com> Reviewed-by:
Ursula Braun <ubraun@linux.ibm.com> Signed-off-by:
-
Julian Wiedmann authored
[ Upstream commit 238965b7 ] The HiperSockets-based transport path in af_iucv is still too closely entangled with qeth. With commit a647a025 ("s390/qeth: speed-up L3 IQD xmit"), the relevant xmit code in qeth has begun to use skb_cow_head(). So to avoid unnecessary skb head expansions, af_iucv must learn to 1) respect dev->needed_headroom when allocating skbs, and 2) drop the header reference before cloning the skb. While at it, also stop hard-coding the LL-header creation stage and just use the appropriate helper. Fixes: a647a025 ("s390/qeth: speed-up L3 IQD xmit") Signed-off-by:
-
Fred Klassen authored
[ Upstream commit 76e21533 ] Fixes an issue where TX Timestamps are not arriving on the error queue when UDP_SEGMENT CMSG type is combined with CMSG type SO_TIMESTAMPING. This can be illustrated with an updated updgso_bench_tx program which includes the '-T' option to test for this condition. It also introduces the '-P' option which will call poll() before reading the error queue. ./udpgso_bench_tx -4ucTPv -S 1472 -l2 -D 172.16.120.18 poll timeout udp tx: 0 MB/s 1 calls/s 1 msg/s The "poll timeout" message above indicates that TX timestamp never arrived. This patch preserves tx_flags for the first UDP GSO segment. Only the first segment is timestamped, even though in some cases there may be benefital in timestamping both the first and last segment. Factors in deciding on first segment timestamp only: - Timestamping both first and last segmented is not feasible. Hardware can only have one outstanding TS request at a time. - Timestamping last segment may under report network latency of the previous segments. Even though the doorbell is suppressed, the ring producer counter has been incremented. - Timestamping the first segment has the upside in that it reports timestamps from the application's view, e.g. RTT. - Timestamping the first segment has the downside that it may underreport tx host network latency. It appears that we have to pick one or the other. And possibly follow-up with a config flag to choose behavior. v2: Remove tests as noted by Willem de Bruijn <willemb@google.com> Moving tests from net to net-next v3: Update only relevant tx_flag bits as per Willem de Bruijn <willemb@google.com> v4: Update comments and commit message as per Willem de Bruijn <willemb@google.com> Fixes: ee80d1eb ("udp: add udp gso") Signed-off-by:
Fred Klassen <fklassen@appneta.com> Acked-by:
Willem de Bruijn <willemb@google.com> Signed-off-by:
-
Jakub Kicinski authored
[ Upstream commit 177b8007 ] When GSO frame has to be corrupted netem uses skb_gso_segment() to produce the list of frames, and re-enqueues the segments one by one. The backlog length has to be adjusted to account for new frames. The current calculation is incorrect, leading to wrong backlog lengths in the parent qdisc (both bytes and packets), and incorrect packet backlog count in netem itself. Parent backlog goes negative, netem's packet backlog counts all non-first segments twice (thus remaining non-zero even after qdisc is emptied). Move the variables used to count the adjustment into local scope to make 100% sure they aren't used at any stage in backports. Fixes: 6071bd1a ("netem: Segment GSO packets on enqueue") Signed-off-by:
Jakub Kicinski <jakub.kicinski@netronome.com> Reviewed-by:
Dirk van der Merwe <dirk.vandermerwe@netronome.com> Acked-by:
Cong Wang <xiyou.wangcong@gmail.com> Signed-off-by:
-
Jeffrey Hugo authored
[ Upstream commit fc19cbb7 ] If mdp5_cfg_init fails because of an unknown major version, a null pointer dereference occurs. This is because the caller of init expects error pointers, but init returns NULL on error. Fix this by returning the expected values on error. Fixes: 2e362e17 (drm/msm/mdp5: introduce mdp5_cfg module) Signed-off-by:
Jeffrey Hugo <jeffrey.l.hugo@gmail.com> Reviewed-by:
Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by:
-
Mike Marciniszyn authored
[ Upstream commit 942a8993 ] The call to sc_buffer_alloc currently returns NULL (no buffer) or a buffer descriptor. There is a third case when the port is down. Currently that returns NULL and this prevents the caller from properly handling the sc_buffer_alloc() failure. A verbs code link test after the call is racy so the indication needs to come from the state check inside the allocation routine to be valid. Fix by encoding the ECOMM failure like SDMA. IS_ERR_OR_NULL() tests are added at all call sites. For verbs send, this needs to treat any error by returning a completion without any MMIO copy. Fixes: 77241056 ("IB/hfi1: add driver files") Reviewed-by:
Dennis Dalessandro <dennis.dalessandro@intel.com> Signed-off-by:
Mike Marciniszyn <mike.marciniszyn@intel.com> Signed-off-by:
Doug Ledford <dledford@redhat.com> Signed-off-by:
-
Anton Protopopov authored
[ Upstream commit 56f0f84e ] The bpf_ipv6_fib_lookup function should return BPF_FIB_LKUP_RET_FWD_DISABLED when forwarding is disabled for the input device. However instead of checking if forwarding is enabled on the input device, it checked the global net->ipv6.devconf_all->forwarding flag. Change it to behave as expected. Fixes: 87f5fc7e ("bpf: Provide helper to do forwarding lookups in kernel FIB table") Signed-off-by:
Anton Protopopov <a.s.protopopov@gmail.com> Acked-by:
Toke Høiland-Jørgensen <toke@redhat.com> Reviewed-by:
David Ahern <dsahern@gmail.com> Signed-off-by:
Daniel Borkmann <daniel@iogearbox.net> Signed-off-by:
-
Nathan Lynch authored
[ Upstream commit e610a466 ] It's common for the platform to replace the cache device nodes after a migration. Since the cacheinfo code is never informed about this, it never drops its references to the source system's cache nodes, causing it to wind up in an inconsistent state resulting in warnings and oopses as soon as CPU online/offline occurs after the migration, e.g. cache for /cpus/l3-cache@3113(Unified) refers to cache for /cpus/l2-cache@200d(Unified) WARNING: CPU: 15 PID: 86 at arch/powerpc/kernel/cacheinfo.c:176 release_cache+0x1bc/0x1d0 [...] NIP release_cache+0x1bc/0x1d0 LR release_cache+0x1b8/0x1d0 Call Trace: release_cache+0x1b8/0x1d0 (unreliable) cacheinfo_cpu_offline+0x1c4/0x2c0 unregister_cpu_online+0x1b8/0x260 cpuhp_invoke_callback+0x114/0xf40 cpuhp_thread_fun+0x270/0x310 smpboot_thread_fn+0x2c8/0x390 kthread+0x1b8/0x1c0 ret_from_kernel_thread+0x5c/0x68 Using device tree notifiers won't work since we want to rebuild the hierarchy only after all the removals and additions have occurred and the device tree is in a consistent state. Call cacheinfo_teardown() before processing device tree updates, and rebuild the hierarchy afterward. Fixes: 410bccf9 ("powerpc/pseries: Partition migration in the kernel") Signed-off-by:
Nathan Lynch <nathanl@linux.ibm.com> Reviewed-by:
Gautham R. Shenoy <ego@linux.vnet.ibm.com> Signed-off-by:
Michael Ellerman <mpe@ellerman.id.au> Signed-off-by:
-
Nathan Lynch authored
[ Upstream commit d4aa219a ] Allow external callers to force the cacheinfo code to release all its references to cache nodes, e.g. before processing device tree updates post-migration, and to rebuild the hierarchy afterward. CPU online/offline must be blocked by callers; enforce this. Fixes: 410bccf9 ("powerpc/pseries: Partition migration in the kernel") Signed-off-by:
-
Michal Kalderon authored
[ Upstream commit 43cf40d9 ] Fix uninitialized variable warning by static checker. Fixes: ae3488ff ("qed: Add ll2 connection for processing unaligned MPA packets") Signed-off-by:
Ariel Elior <ariel.elior@marvell.com> Signed-off-by:
Michal Kalderon <michal.kalderon@marvell.com> Signed-off-by:
-
Michal Kalderon authored
[ Upstream commit 6117561e ] Destroy QP waits for it's ep object state to be set to CLOSED before proceeding. ep->state can be updated from a different context. Add smp_store_release/READ_ONCE to synchronize. Fixes: fc4c6065 ("qed: iWARP implement disconnect flows") Signed-off-by:
-
Jerome Brunet authored
[ Upstream commit 7e0d7d0f ] Right justified format is actually not supported by the amlogic tdm output encoder. Fixes: c41c2a35 ("ASoC: meson: add tdm output driver") Signed-off-by:
Jerome Brunet <jbrunet@baylibre.com> Signed-off-by:
-
Jerome Brunet authored
[ Upstream commit 47c317b7 ] Right justified format is actually not supported by the amlogic tdm input decoder. Fixes: 13a22e6a ("ASoC: meson: add tdm input driver") Signed-off-by:
-
Dan Carpenter authored
[ Upstream commit ff148d8a ] This code triggers a Smatch warning: drivers/ntb/hw/mscc/ntb_hw_switchtec.c:884 switchtec_ntb_init_sndev() warn: should '(1 << sndev->peer_partition)' be a 64 bit type? The "part_map" and "tpart_vec" variables are u64 type so this seems like a valid warning. Fixes: 3df54c87 ("ntb_hw_switchtec: Allow using Switchtec NTB in multi-partition setups") Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Reviewed-by:
Logan Gunthorpe <logang@deltatee.com> Signed-off-by:
Jon Mason <jdmason@kudzu.us> Signed-off-by:
-
Peng Fan authored
[ Upstream commit c0759b9b ] The boolean rate_discrete needs to be assigned to clk->rate_discrete, so that clock driver can distinguish between the continuous range and discrete rates. It uses this in scmi_clk_round_rate could get the rounded value if it's a continuous range. Fixes: 5f6c6430 ("firmware: arm_scmi: add initial support for clock protocol") Signed-off-by:
Peng Fan <peng.fan@nxp.com> [sudeep.holla: updated commit message] Signed-off-by:
Sudeep Holla <sudeep.holla@arm.com> Signed-off-by:
-
Sudeep Holla authored
[ Upstream commit 430daaf9 ] As per the SCMI specification the bitfields for SENSOR_DESC attributes are as follows: attributes_low [7:0] Number of trip points supported attributes_high [15:11] The power-of-10 multiplier in 2's-complement format that is applied to the sensor units Looks like the code developed during the draft versions of the specification slipped through and are wrong with respect to final released version. Fix them by adjusting the bitfields appropriately. Fixes: 5179c523 ("firmware: arm_scmi: add initial support for sensor protocol") Reviewed-by:
Florian Fainelli <f.fainelli@gmail.com> Signed-off-by:
-
Florian Fainelli authored
[ Upstream commit d9e10082 ] We are not destroying the sysfs attribute groupe we registered during the probe function which will make subsequent probe calls to that driver fail. Correct that with adding a remove function which only removes those attributes since the reference counting on clocks did its job already. Fixes: 415060b2 ("phy: usb: phy-brcm-usb: Add ability to force DRD mode to host or device") Signed-off-by:
Kishon Vijay Abraham I <kishon@ti.com> Signed-off-by:
-
Eric Auger authored
[ Upstream commit 5f64ce54 ] intel_iommu_get_resv_regions() aims to return the list of reserved regions accessible by a given @device. However several devices can access the same reserved memory region and when building the list it is not safe to use a single iommu_resv_region object, whose container is the RMRR. This iommu_resv_region must be duplicated per device reserved region list. Let's remove the struct iommu_resv_region from the RMRR unit and allocate the iommu_resv_region directly in intel_iommu_get_resv_regions(). We hold the dmar_global_lock instead of the rcu-lock to allow sleeping. Fixes: 0659b8dc ("iommu/vt-d: Implement reserved region get/put callbacks") Signed-off-by:
Eric Auger <eric.auger@redhat.com> Reviewed-by:
Lu Baolu <baolu.lu@linux.intel.com> Signed-off-by:
Joerg Roedel <jroedel@suse.de> Signed-off-by:
-
Christian Hewitt authored
[ Upstream commit 33344e21 ] - Remove serial1 alias - Add support for uart_A rts/cts - Add bluetooth uart_A subnode qith shutdown gpio Fixes: b8b74dda ("ARM64: dts: meson-gxm: Add support for Khadas VIM2") Signed-off-by:
Christian Hewitt <christianshewitt@gmail.com> Signed-off-by:
Neil Armstrong <narmstrong@baylibre.com> Signed-off-by:
Kevin Hilman <khilman@baylibre.com> Signed-off-by:
-
Christian Hewitt authored
[ Upstream commit 0afd24c2 ] Fix DTC warnings: meson-gxm-khadas-vim2.dtb: Warning (avoid_unnecessary_addr_size): /gpio-keys-polled: unnecessary #address-cells/#size-cells without "ranges" or child "reg" property Fixes: b8b74dda ("ARM64: dts: meson-gxm: Add support for Khadas VIM2") Signed-off-by:
Martin Blumenstingl <martin.blumenstingl@googlemail.com> Tested-by:
-
Borut Seljak authored
[ Upstream commit 707aeea1 ] Remove spin_lock_irqsave in stm32_config_rs485, it cause recursive locking. Already locked in uart_set_rs485_config. Fixes: 1bcda09d ("serial: stm32: add support for RS485 hardware control mode") Signed-off-by:
Borut Seljak <borut.seljak@t-2.net> Signed-off-by:
-
George Wilkie authored
[ Upstream commit 2f3f7d1f ] If you configure a route with multiple labels, e.g. ip route add 10.10.3.0/24 encap mpls 16/100 via 10.10.2.2 dev ens4 A warning is logged: kernel: [ 130.561819] netlink: 'ip': attribute type 1 has an invalid length. This happens because mpls_iptunnel_policy has set the type of MPLS_IPTUNNEL_DST to fixed size NLA_U32. Change it to a minimum size. nla_get_labels() does the remaining validation. Fixes: e3e4712e ("mpls: ip tunnel support") Signed-off-by:
George Wilkie <gwilkie@vyatta.att-mail.com> Reviewed-by:
-
Takeshi Kihara authored
[ Upstream commit 90d4fa39 ] It is incorrect to specify the no-ether-link property for the AVB device on the Ebisu board. This is because the property should only be used when a board does not provide a proper AVB_LINK signal. However, the Ebisu board does provide this signal. As per 87c059e9 ("arm64: dts: renesas: salvator-x: Remove renesas, no-ether-link property") this fixes a bug: Steps to reproduce: - start AVB TX stream (Using aplay via MSE), - disconnect+reconnect the eth cable, - after a reconnection the eth connection goes iteratively up/down without user interaction, - this may heal after some seconds or even stay for minutes. As the documentation specifies, the "renesas,no-ether-link" option should be used when a board does not provide a proper AVB_LINK signal. There is no need for this option enabled on RCAR H3/M3 Salvator-X/XS and ULCB starter kits since the AVB_LINK is correctly handled by HW. Choosing to keep or remove the "renesas,no-ether-link" option will have impact on the code flow in the following ways: - keeping this option enabled may lead to unexpected behavior since the RX & TX are enabled/disabled directly from adjust_link function without any HW interrogation, - removing this option, the RX & TX will only be enabled/disabled after HW interrogation. The HW check is made through the LMON pin in PSR register which specifies AVB_LINK signal value (0 - at low level; 1 - at high level). In conclusion, the present change is also a safety improvement because it removes the "renesas,no-ether-link" option leading to a proper way of detecting the link state based on HW interrogation and not on software heuristic. Fixes: 8441ef64 ("arm64: dts: renesas: r8a77990: ebisu: Enable EthernetAVB") Signed-off-by:
Takeshi Kihara <takeshi.kihara.df@renesas.com> [simon: updated changelog] Signed-off-by:
-
Antoine Tenart authored
[ Upstream commit ccd65a20 ] This patch fixes the queued len computation, which could theoretically be wrong if req->len[1] - req->processed[1] > 1. Be future-proof here, and fix it. Fixes: b460edb6 ("crypto: inside-secure - sha512 support") Signed-off-by:
Antoine Tenart <antoine.tenart@bootlin.com> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by:
-
Antoine Tenart authored
[ Upstream commit b926213d ] A request is zeroed in safexcel_ahash_exit_inv(). This request total size is EIP197_AHASH_REQ_SIZE while the memset zeroing it uses sizeof(struct ahash_request), which happens to be less than EIP197_AHASH_REQ_SIZE. This patch fixes it. Fixes: f6beaea3 ("crypto: inside-secure - authenc(hmac(sha256), cbc(aes)) support") Signed-off-by:
-
Colin Ian King authored
[ Upstream commit d4ec9550 ] The assigment of FB_VMODE_NONINTERLACE to var->vmode should be a bit-wise or of FB_VMODE_NONINTERLACE instead of an assignment, otherwise the previous clearing of the FB_VMODE_MASK bits of var->vmode makes no sense and is redundant. Addresses-Coverity: ("Unused value") Fixes: ad4e02d5 ("[media] vivid: add a simple framebuffer device for overlay testing") Signed-off-by:
Colin Ian King <colin.king@canonical.com> Signed-off-by:
Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by:
Mauro Carvalho Chehab <mchehab+samsung@kernel.org> Signed-off-by:
-
Ondrej Jirman authored
[ Upstream commit f1676754 ] The current code defines W1 clock gate to be at 0x1cc, overlaying it with the IR gate. Clock gate for r-apb1-w1 is at 0x1ec. This fixes issues with IR receiver causing interrupt floods on H6 (because interrupt flags can't be cleared, due to IR module's bus being disabled). Fixes: b7c7b050 ("clk: sunxi-ng: add support for H6 PRCM CCU") Signed-off-by:
Ondrej Jirman <megous@megous.com> Acked-by:
Clément Péron <peron.clem@gmail.com> Signed-off-by:
-
Florian Fainelli authored
[ Upstream commit 4c5681fc ] What we read back from the register is going to be capped at 32-bits, and cpufreq_freq_table.frequency is an unsigned int. Avoid any possible value truncation by using the appropriate return value. Fixes: de322e08 ("cpufreq: brcmstb-avs-cpufreq: AVS CPUfreq driver for Broadcom STB SoCs") Signed-off-by:
Markus Mayer <mmayer@broadcom.com> Signed-off-by:
Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by:
-
