- 13 Mar, 2020 40 commits
-
-
Rob Clark authored
BugLink: https://bugs.launchpad.net/bugs/1864773 [ 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:
Sasha Levin <sashal@kernel.org> Signed-off-by:
Khalid Elmously <khalid.elmously@canonical.com> Signed-off-by:
Kleber Sacilotto de Souza <kleber.souza@canonical.com>
-
Chen-Yu Tsai authored
BugLink: https://bugs.launchpad.net/bugs/1864773 [ 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:
Chen-Yu Tsai <wens@csie.org> Signed-off-by:
Alexandre Belloni <alexandre.belloni@bootlin.com> Signed-off-by:
-
Peter Ujfalusi authored
BugLink: https://bugs.launchpad.net/bugs/1864773 [ 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
BugLink: https://bugs.launchpad.net/bugs/1864773 [ 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:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Jeffrey Hugo authored
BugLink: https://bugs.launchpad.net/bugs/1864773 [ 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:
-
Nathan Lynch authored
BugLink: https://bugs.launchpad.net/bugs/1864773 [ 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:
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:
-
Colin Ian King authored
BugLink: https://bugs.launchpad.net/bugs/1864773 [ 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:
-
Eric Dumazet authored
BugLink: https://bugs.launchpad.net/bugs/1864773 [ Upstream commit ae7352d3 ] Both IPv6 and 6lowpan are calling inet_frags_fini() too soon. inet_frags_fini() is dismantling a kmem_cache, that might be needed later when unregister_pernet_subsys() eventually has to remove frags queues from hash tables and free them. This fixes potential use-after-free, and is a prereq for the following patch. Fixes: d4ad4d22 ("inet: frags: use kmem_cache for inet_frag_queue") Signed-off-by:
Eric Dumazet <edumazet@google.com> Signed-off-by:
-
Eric W. Biederman authored
BugLink: https://bugs.launchpad.net/bugs/1864773 [ Upstream commit 72abe3bc ] The locking in force_sig_info is not prepared to deal with a task that exits or execs (as sighand may change). The is not a locking problem in force_sig as force_sig is only built to handle synchronous exceptions. Further the function force_sig_info changes the signal state if the signal is ignored, or blocked or if SIGNAL_UNKILLABLE will prevent the delivery of the signal. The signal SIGKILL can not be ignored and can not be blocked and SIGNAL_UNKILLABLE won't prevent it from being delivered. So using force_sig rather than send_sig for SIGKILL is confusing and pointless. Because it won't impact the sending of the signal and and because using force_sig is wrong, replace force_sig with send_sig. Cc: Namjae Jeon <namjae.jeon@samsung.com> Cc: Jeff Layton <jlayton@primarydata.com> Cc: Steve French <smfrench@gmail.com> Fixes: a5c3e1c7 ("Revert "cifs: No need to send SIGKILL to demux_thread during umount"") Fixes: e7ddee90 ("cifs: disable sharing session and tcon and add new TCP sharing code") Signed-off-by:
"Eric W. Biederman" <ebiederm@xmission.com> Signed-off-by:
-
Lu Baolu authored
BugLink: https://bugs.launchpad.net/bugs/1864773 [ Upstream commit 57274ea2 ] The iommu_group_get_for_dev() will allocate a group for a device if it isn't in any group. This isn't the use case in iommu_request_dm_for_dev(). Let's use iommu_group_get() instead. Fixes: d290f1e7 ("iommu: Introduce iommu_request_dm_for_dev()") Signed-off-by:
Lu Baolu <baolu.lu@linux.intel.com> Signed-off-by:
Joerg Roedel <jroedel@suse.de> Signed-off-by:
-
Nathan Chancellor authored
BugLink: https://bugs.launchpad.net/bugs/1864773 [ Upstream commit b0576f9e ] Clang warns: drivers/misc/sgi-xp/xpc_partition.c:73:14: warning: variable 'buf' is uninitialized when used within its own initialization [-Wuninitialized] void *buf = buf; ~~~ ^~~ 1 warning generated. Arnd's explanation during review: /* * Returns the physical address of the partition's reserved page through * an iterative number of calls. * * On first call, 'cookie' and 'len' should be set to 0, and 'addr' * set to the nasid of the partition whose reserved page's address is * being sought. * On subsequent calls, pass the values, that were passed back on the * previous call. * * While the return status equals SALRET_MORE_PASSES, keep calling * this function after first copying 'len' bytes starting at 'addr' * into 'buf'. Once the return status equals SALRET_OK, 'addr' will * be the physical address of the partition's reserved page. If the * return status equals neither of these, an error as occurred. */ static inline s64 sn_partition_reserved_page_pa(u64 buf, u64 *cookie, u64 *addr, u64 *len) so *len is set to zero on the first call and tells the bios how many bytes are accessible at 'buf', and it does get updated by the BIOS to tell us how many bytes it needs, and then we allocate that and try again. Fixes: 27929029 ("[IA64-SGI] cleanup the way XPC locates the reserved page") Link: https://github.com/ClangBuiltLinux/linux/issues/466Suggested-by:
Stephen Hines <srhines@google.com> Reviewed-by:
Arnd Bergmann <arnd@arndb.de> Reviewed-by:
Nick Desaulniers <ndesaulniers@google.com> Signed-off-by:
Nathan Chancellor <natechancellor@gmail.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
-
Christophe Leroy authored
BugLink: https://bugs.launchpad.net/bugs/1864773 [ Upstream commit 44a04218 ] spi_finalize_current_message() shall be called once all actions are finished, otherwise the last actions might step over a newly started transfer. Fixes: c592becb ("spi: fsl-(e)spi: migrate to generic master queueing") Signed-off-by:
Christophe Leroy <christophe.leroy@c-s.fr> Signed-off-by:
-
Matthias Kaehlcke authored
BugLink: https://bugs.launchpad.net/bugs/1864773 [ Upstream commit bf45ac18 ] The CPU load values passed to the thermal_power_cpu_get_power tracepoint are zero for all CPUs, unless, unless the thermal_power_cpu_limit tracepoint is enabled too: irq/41-rockchip-98 [000] .... 290.972410: thermal_power_cpu_get_power: cpus=0000000f freq=1800000 load={{0x0,0x0,0x0,0x0}} dynamic_power=4815 vs irq/41-rockchip-96 [000] .... 95.773585: thermal_power_cpu_get_power: cpus=0000000f freq=1800000 load={{0x56,0x64,0x64,0x5e}} dynamic_power=4959 irq/41-rockchip-96 [000] .... 95.773596: thermal_power_cpu_limit: cpus=0000000f freq=408000 cdev_state=10 power=416 There seems to be no good reason for omitting the CPU load information depending on another tracepoint. My guess is that the intention was to check whether thermal_power_cpu_get_power is (still) enabled, however 'load_cpu != NULL' already indicates that it was at least enabled when cpufreq_get_requested_power() was entered, there seems little gain from omitting the assignment if the tracepoint was just disabled, so just remove the check. Fixes: 6828a471 ("thermal: add trace events to the power allocator governor") Signed-off-by:
Matthias Kaehlcke <mka@chromium.org> Reviewed-by:
Daniel Lezcano <daniel.lezcano@linaro.org> Acked-by:
Javi Merino <javi.merino@kernel.org> Acked-by:
Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by:
Eduardo Valentin <edubezval@gmail.com> Signed-off-by:
-
Brian Masney authored
BugLink: https://bugs.launchpad.net/bugs/1864773 [ Upstream commit d3f48ec0 ] lm3630a_bank_a_update_status() and lm3630a_bank_b_update_status() both return the brightness value if the brightness was successfully updated. Writing to these attributes via sysfs would cause a 'Bad address' error to be returned. These functions should return 0 on success, so let's change it to correct that error. Fixes: 28e64a68 ("backlight: lm3630: apply chip revision") Signed-off-by:
Brian Masney <masneyb@onstation.org> Acked-by:
Pavel Machek <pavel@ucw.cz> Acked-by:
Daniel Thompson <daniel.thompson@linaro.org> Signed-off-by:
Lee Jones <lee.jones@linaro.org> Signed-off-by:
-
Dan Carpenter authored
BugLink: https://bugs.launchpad.net/bugs/1864773 [ Upstream commit b586627e ] The "whichcpu" comes from argv[3]. The cpu_online() macro looks up the cpu in a bitmap of online cpus, but if the value is too high then it could read beyond the end of the bitmap and possibly Oops. Fixes: 5d5314d6 ("kdb: core for kgdb back end (1 of 2)") Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Reviewed-by:
Douglas Anderson <dianders@chromium.org> Signed-off-by:
-
Russell King authored
BugLink: https://bugs.launchpad.net/bugs/1864773 [ Upstream commit 63a0666b ] Fix lack of keyboard interrupts for RiscPC due to incorrect conversion. Fixes: e8d36d5d ("ARM: kill off set_irq_flags usage") Signed-off-by:
Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by:
-
Florian Westphal authored
BugLink: https://bugs.launchpad.net/bugs/1864773 [ Upstream commit 680f6af5 ] If userspace provides a rule blob with trailing data after last target, we trigger a splat, then convert ruleset to 64bit format (with trailing data), then pass that to do_replace_finish() which then returns -EINVAL. Erroring out right away avoids the splat plus unneeded translation and error unwind. Fixes: 81e675c2 ("netfilter: ebtables: add CONFIG_COMPAT support") Reported-by:
Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp> Signed-off-by:
Florian Westphal <fw@strlen.de> Signed-off-by:
Pablo Neira Ayuso <pablo@netfilter.org> Signed-off-by:
-
Dan Carpenter authored
BugLink: https://bugs.launchpad.net/bugs/1864773 [ Upstream commit 6d1f8b3d ] The "out_data" variable is uninitialized at the point. Originally, this used to print "status" instead and that seems like the correct thing to print. Fixes: bc2ef884 ("alienware-wmi: For WMAX HDMI method, introduce a way to query HDMI cable status") Signed-off-by:
Mario Limonciello <mario.limonciello@dell.com> Signed-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by:
-
Dan Carpenter authored
BugLink: https://bugs.launchpad.net/bugs/1864773 [ Upstream commit b72845ee ] In vpbe_enum_outputs() we check if (temp_index >= cfg->num_outputs) but the problem is that "temp_index" can be negative. This patch changes the types to unsigned to address this array underflow bug. Fixes: 66715cdc ("[media] davinci vpbe: VPBE display driver") Signed-off-by:
"Lad, Prabhakar" <prabhakar.csengg@gmail.com> Signed-off-by:
-
Dan Carpenter authored
BugLink: https://bugs.launchpad.net/bugs/1864773 [ Upstream commit dd6e2a98 ] The "b->index" is a u32 the comes from the user in the ioctl. It hasn't been checked. We aren't supposed to use it but we're instead supposed to use the value that gets written to it when we call videobuf_dqbuf(). The videobuf_dqbuf() first memsets it to zero and then re-initializes it inside the videobuf_status() function. It's this final value which we want. Hans Verkuil pointed out that we need to check the return from videobuf_dqbuf(). I ended up doing a little cleanup related to that as well. Fixes: 72915e85 ("[media] V4L2: OMAP: VOUT: dma map and unmap v4l2 buffers in qbuf and dqbuf") Signed-off-by:
-
Lu Baolu authored
BugLink: https://bugs.launchpad.net/bugs/1864773 [ Upstream commit 5daab580 ] The kernel parameter igfx_off is used by users to disable DMA remapping for the Intel integrated graphic device. It was designed for bare metal cases where a dedicated IOMMU is used for graphic. This doesn't apply to virtual IOMMU case where an include-all IOMMU is used. This makes the kernel parameter work with virtual IOMMU as well. Cc: Ashok Raj <ashok.raj@intel.com> Cc: Jacob Pan <jacob.jun.pan@linux.intel.com> Suggested-by:
Kevin Tian <kevin.tian@intel.com> Fixes: c0771df8 ("intel-iommu: Export a flag indicating that the IOMMU is used for iGFX.") Signed-off-by:
Zhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by:
-
Jack Morgenstein authored
BugLink: https://bugs.launchpad.net/bugs/1864773 [ Upstream commit 8f4426aa ] The QP transition optional parameters for the various transition for XRC QPs are identical to those for RC QPs. Many of the XRC QP transition optional parameter bits are missing from the QP optional mask table. These omissions caused failures when doing XRC QP state transitions. For example, when trying to change the response timer of an XRC receive QP via the RTS2RTS transition, the new timer value was ignored because MLX5_QP_OPTPAR_RNR_TIMEOUT bit was missing from the optional params mask for XRC qps for the RTS2RTS transition. Fix this by adding the missing XRC optional parameters for all QP transitions to the opt_mask table. Fixes: e126ba97 ("mlx5: Add driver for Mellanox Connect-IB adapters") Fixes: a4774e90 ("IB/mlx5: Fix opt param mask according to firmware spec") Signed-off-by:
Jack Morgenstein <jackm@dev.mellanox.co.il> Signed-off-by:
Leon Romanovsky <leonro@mellanox.com> Signed-off-by:
Jason Gunthorpe <jgg@mellanox.com> Signed-off-by:
-
Jerome Brunet authored
BugLink: https://bugs.launchpad.net/bugs/1864773 [ Upstream commit 6a7c59c6 ] A stream may specify a rate range using 'rate_min' and 'rate_max', so a stream may be valid and not specify any rates. However, as stream cannot be valid and not have any channel. Let's use this condition instead to determine if a stream is valid or not. Fixes: cde79035 ("ASoC: Handle multiple codecs with split playback / capture") Signed-off-by:
Jerome Brunet <jbrunet@baylibre.com> Signed-off-by:
-
Willem de Bruijn authored
BugLink: https://bugs.launchpad.net/bugs/1864773 [ Upstream commit b2cf86e1 ] Packet send checks that msg_name is at least sizeof sockaddr_ll. Packet recv must return at least this length, so that its output can be passed unmodified to packet send. This ceased to be true since adding support for lladdr longer than sll_addr. Since, the return value uses true address length. Always return at least sizeof sockaddr_ll, even if address length is shorter. Zero the padding bytes. Change v1->v2: do not overwrite zeroed padding again. use copy_len. Fixes: 0fb375fb ("[AF_PACKET]: Allow for > 8 byte hardware addresses.") Suggested-by:
David Laight <David.Laight@aculab.com> Signed-off-by:
Willem de Bruijn <willemb@google.com> Signed-off-by:
-
Takashi Iwai authored
BugLink: https://bugs.launchpad.net/bugs/1864773 [ Upstream commit 328e9f69 ] The error from snd_usb_mixer_apply_create_quirk() is ignored in the current usb-audio driver code, which will continue the probing even after the error. Let's take it more serious. Fixes: 7b1eda22 ("ALSA: usb-mixer: factor out quirks") Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
Alexandru Ardelean authored
BugLink: https://bugs.launchpad.net/bugs/1864773 [ Upstream commit 648865a7 ] In 2D transfers (for the AXI DMAC), the number of frames (numf) represents Y_LENGTH, and the length of a frame is X_LENGTH. 2D transfers are useful for video transfers where screen resolutions ( X * Y ) are typically aligned for X, but not for Y. There is no requirement for Y_LENGTH to be aligned to the bus-width (or anything), and this is also true for AXI DMAC. Checking the Y_LENGTH for alignment causes false errors when initiating DMA transfers. This change fixes this by checking only that the Y_LENGTH is non-zero. Fixes: 0e3b67b3 ("dmaengine: Add support for the Analog Devices AXI-DMAC DMA controller") Signed-off-by:
Alexandru Ardelean <alexandru.ardelean@analog.com> Signed-off-by:
Vinod Koul <vkoul@kernel.org> Signed-off-by:
-
Dan Carpenter authored
BugLink: https://bugs.launchpad.net/bugs/1864773 [ Upstream commit f57c4bbf ] NEXTHDR_MAX is 255. What happens here is that we take a u8 value "hdr->nexthdr" from the network and then look it up in lowpan_nexthdr_nhcs[]. The problem is that if hdr->nexthdr is 0xff then we read one element beyond the end of the array so the array needs to be one element larger. Fixes: 92aa7c65 ("6lowpan: add generic nhc layer interface") Signed-off-by:
Jukka Rissanen <jukka.rissanen@linux.intel.com> Acked-by:
Alexander Aring <aring@mojatatu.com> Signed-off-by:
Marcel Holtmann <marcel@holtmann.org> Signed-off-by:
-
Akinobu Mita authored
BugLink: https://bugs.launchpad.net/bugs/1864773 [ Upstream commit 384538bd ] Avoid returning with mutex locked. Fixes: fa8cb644 ("[media] ov2659: Don't depend on subdev API") Cc: "Lad, Prabhakar" <prabhakar.csengg@gmail.com> Signed-off-by:
Akinobu Mita <akinobu.mita@gmail.com> Acked-by:
Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by:
-
Ben Hutchings authored
BugLink: https://bugs.launchpad.net/bugs/1864773 [ Upstream commit ff6d2782 ] The 32-bit vDSO is not needed and not normally built for 64-bit little-endian configurations. However, the vdso_install target still builds and installs it. Add the same config condition as is normally used for the build. Fixes: e0d00591 ("powerpc/vdso: Disable building the 32-bit VDSO ...") Signed-off-by:
Ben Hutchings <ben@decadent.org.uk> Signed-off-by:
-
Jie Liu authored
BugLink: https://bugs.launchpad.net/bugs/1864773 [ Upstream commit 4bcd4ec1 ] We find that sysctl_tipc_rmem and named_timeout do not have the right minimum setting. sysctl_tipc_rmem should be larger than zero, like sysctl_tcp_rmem. And named_timeout as a timeout setting should be not less than zero. Fixes: cc79dd1b ("tipc: change socket buffer overflow control to respect sk_rcvbuf") Fixes: a5325ae5 ("tipc: add name distributor resiliency queue") Signed-off-by:
Jie Liu <liujie165@huawei.com> Reported-by:
Qiang Ning <ningqiang1@huawei.com> Reviewed-by:
Zhiqiang Liu <liuzhiqiang26@huawei.com> Reviewed-by:
Miaohe Lin <linmiaohe@huawei.com> Signed-off-by:
-
Guenter Roeck authored
BugLink: https://bugs.launchpad.net/bugs/1864773 [ Upstream commit e95fd518 ] Super-IO accesses may fail on a system with no or unmapped LPC bus. Also, other drivers may attempt to access the LPC bus at the same time, resulting in undefined behavior. Use request_muxed_region() to ensure that IO access on the requested address space is supported, and to ensure that access by multiple drivers is synchronized. Fixes: b72656db ("hwmon: (w83627hf) Stop using globals for I/O port numbers") Signed-off-by:
Guenter Roeck <linux@roeck-us.net> Signed-off-by:
-
YueHaibing authored
BugLink: https://bugs.launchpad.net/bugs/1864773 [ Upstream commit 9ee8578d ] Since commit 1c459de1 ("ARM: pxa: ssp: use devm_ functions") kfree, iounmap, clk_put etc are not needed anymore in remove path. Fixes: 1c459de1 ("ARM: pxa: ssp: use devm_ functions") Signed-off-by:
YueHaibing <yuehaibing@huawei.com> [ commit message spelling fix ] Signed-off-by:
Robert Jarzmik <robert.jarzmik@free.fr> Signed-off-by:
-
Bart Van Assche authored
BugLink: https://bugs.launchpad.net/bugs/1864773 [ Upstream commit c794d24e ] If module initialization fails after the character device has been registered, unregister the character device. Additionally, avoid duplicating error path code. Cc: Himanshu Madhani <hmadhani@marvell.com> Cc: Giridhar Malavali <giridhar.malavali@qlogic.com> Fixes: 6a03b4cd ("[SCSI] qla2xxx: Add char device to increase driver use count") # v2.6.35. Signed-off-by:
Bart Van Assche <bvanassche@acm.org> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by:
-
YueHaibing authored
BugLink: https://bugs.launchpad.net/bugs/1864773 [ Upstream commit c8f19128 ] pr->tx_bytes should be assigned to tx_bytes other than rx_bytes. Reported-by:
Hulk Robot <hulkci@huawei.com> Fixes: ce45b873 ("ehea: Fixing statistics") Signed-off-by:
Mukesh Ojha <mojha@codeaurora.org> Signed-off-by:
-
Martin Sperl authored
BugLink: https://bugs.launchpad.net/bugs/1864773 [ Upstream commit 509c5836 ] The original driver by default defines num_chipselects as -1. This actually allicates an array of 65535 entries in of_spi_register_master. There is a side-effect for buggy device trees that (contrary to dt-binding documentation) have no cs-gpio defined. This mode was never supported by the driver due to limitations of native cs and additional code complexity and is explicitly not stated to be implemented. To keep backwards compatibility with such buggy DTs we limit the number of chip_selects to 1, as for all practical purposes it is only ever realistic to use a single chip select in native cs mode without negative side-effects. Fixes: 1ea29b39 ("spi: bcm2835aux: add bcm2835 auxiliary spi device...") Signed-off-by:
Martin Sperl <kernel@martin.sperl.org> Acked-by:
Stefan Wahren <stefan.wahren@i2se.com> Signed-off-by:
-
Dan Carpenter authored
BugLink: https://bugs.launchpad.net/bugs/1864773 [ Upstream commit 5674a92c ] We forgot to set "err" on this error path. Fixes: 1a2d397a ("gpio/powerpc: Eliminate duplication of of_get_named_gpio_flags()") Signed-off-by:
Li Yang <leoyang.li@nxp.com> Signed-off-by:
-
Sowjanya Komatineni authored
BugLink: https://bugs.launchpad.net/bugs/1864773 [ Upstream commit 1a89ac5b ] Fixes: computation of actual bytes to fill/receive in/from FIFO in unpacked mode when transfer length is not a multiple of requested bits per word. unpacked mode transfers fails when the transfer includes partial bytes in the last word. Total words to be written/read to/from FIFO is computed based on transfer length and bits per word. Unpacked mode includes 0 padding bytes for partial words to align with bits per word and these extra bytes are also accounted for calculating bytes left to transfer in the current driver. This causes extra bytes access of tx/rx buffers along with buffer index position crossing actual length where remain_len becomes negative and due to unsigned type, negative value is a 32 bit representation of signed value and transferred bytes never meets the actual transfer length resulting in transfer timeout and a hang. This patch fixes this with proper computation of the actual bytes to fill in FIFO during transmit and the actual bytes to read from FIFO during receive ignoring 0 padded bytes. Signed-off-by:
Sowjanya Komatineni <skomatineni@nvidia.com> Signed-off-by:
-
Sowjanya Komatineni authored
BugLink: https://bugs.launchpad.net/bugs/1864773 [ Upstream commit 7b3d10cd ] Fixes: Clear packed bit when not using packed mode. Packed bit is not cleared when not using packed mode. This results in transfer timeouts for the unpacked mode transfers followed by the packed mode transfers. Signed-off-by:
-
Arnd Bergmann authored
BugLink: https://bugs.launchpad.net/bugs/1864773 [ Upstream commit 0e633f97 ] clang warns about a possible variable use that gcc never complained about: drivers/media/platform/davinci/isif.c:982:32: error: variable 'frame_size' is uninitialized when used here [-Werror,-Wuninitialized] dm365_vpss_set_pg_frame_size(frame_size); ^~~~~~~~~~ drivers/media/platform/davinci/isif.c:887:2: note: variable 'frame_size' is declared here struct vpss_pg_frame_size frame_size; ^ 1 error generated. There is no initialization for this variable at all, and there has never been one in the mainline kernel, so we really should not put that stack data into an mmio register. On the other hand, I suspect that gcc checks the condition more closely and notices that the global isif_cfg.bayer.config_params.test_pat_gen flag is initialized to zero and never written to from any code path, so anything depending on it can be eliminated. To shut up the clang warning, just remove the dead code manually, it has probably never been used because any attempt to do so would have resulted in undefined behavior. Fixes: 63e3ab14 ("V4L/DVB: V4L - vpfe capture - source for ISIF driver on DM365") Signed-off-by:
-
Tony Lindgren authored
BugLink: https://bugs.launchpad.net/bugs/1864773 [ Upstream commit 7f0d0786 ] Commit 747834ab ("ARM: OMAP2+: hwmod: revise hardreset behavior") made the call to _enable() conditional based on no oh->rst_lines_cnt. This caused the return value to be potentially uninitialized. Curiously we see no compiler warnings for this, probably as this gets inlined. We call _setup_reset() from _setup() and only _setup_postsetup() if the return value is zero. Currently the return value can be uninitialized for cases where oh->rst_lines_cnt is set and HWMOD_INIT_NO_RESET is not set. Fixes: 747834ab ("ARM: OMAP2+: hwmod: revise hardreset behavior") Cc: Paul Walmsley <paul@pwsan.com> Cc: Tero Kristo <t-kristo@ti.com> Signed-off-by:
Tony Lindgren <tony@atomide.com> Signed-off-by:
-
