- 13 Mar, 2020 40 commits
-
-
Arnd Bergmann authored
BugLink: https://bugs.launchpad.net/bugs/1864773 [ Upstream commit bc83f79b ] Generally, declaring a platform device as a static variable is a bad idea and can cause all kinds of problems, in particular with the DMA configuration and lifetime rules. A specific problem we hit here is from a bug in clang that warns about certain (otherwise valid) macros when used in static variables: drivers/misc/mic/card/mic_x100.c:285:27: warning: shift count >= width of type [-Wshift-count-overflow] static u64 mic_dma_mask = DMA_BIT_MASK(64); ^~~~~~~~~~~~~~~~ include/linux/dma-mapping.h:141:54: note: expanded from macro 'DMA_BIT_MASK' #define DMA_BIT_MASK(n) (((n) == 64) ? ~0ULL : ((1ULL<<(n))-1)) ^ ~~~ A slightly better way here is to create the platform device dynamically and set the dma mask in the probe function. This avoids the warning and some other problems, but is still not ideal because the device creation should really be separated from the driver, and the fact that the device has no parent means we have to force the dma mask rather than having it set up from the bus that the device is actually on. Fixes: dd8d8d44 ("misc: mic: MIC card driver specific changes to enable SCIF") Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Link: https://lore.kernel.org/r/20190712092426.872625-1-arnd@arndb.deSigned-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.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>
-
Ruslan Bilovol authored
BugLink: https://bugs.launchpad.net/bugs/1864773 [ Upstream commit 6269e4c7 ] Don't do extra cpu_to_le32 conversion for put_unaligned_le32 because it is already implemented in this function. Fixes sparse error: xhci-hub.c:1152:44: warning: incorrect type in argument 1 (different base types) xhci-hub.c:1152:44: expected unsigned int [usertype] val xhci-hub.c:1152:44: got restricted __le32 [usertype] Fixes: 395f5409 "xhci: support new USB 3.1 hub request to get extended port status" Cc: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by:
Ruslan Bilovol <ruslan.bilovol@gmail.com> Link: https://lore.kernel.org/r/1562501839-26522-1-git-send-email-ruslan.bilovol@gmail.comSigned-off-by:
-
YueHaibing authored
BugLink: https://bugs.launchpad.net/bugs/1864773 [ Upstream commit 2ec4ad49 ] It seems we should use 'range' instead of 'priv->range' in lbtf_geo_init(), because 'range' is the corret one related to current regioncode. Reported-by:
Hulk Robot <hulkci@huawei.com> Fixes: 691cdb49 ("libertas_tf: command helper functions for libertas_tf") Signed-off-by:
YueHaibing <yuehaibing@huawei.com> Signed-off-by:
Kalle Valo <kvalo@codeaurora.org> Signed-off-by:
-
Colin Ian King authored
BugLink: https://bugs.launchpad.net/bugs/1864773 [ Upstream commit 41a6bf65 ] Currently if lport is null then the null lport pointer is dereference when printing out debug via the FC_LPORT_DB macro. Fix this by using the more generic FC_LIBFC_DBG debug macro instead that does not use lport. Addresses-Coverity: ("Dereference after null check") Fixes: 7414705e ("libfc: Add runtime debugging with debug_logging module parameter") Signed-off-by:
Colin Ian King <colin.king@canonical.com> Reviewed-by:
Hannes Reinecke <hare@suse.com> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by:
-
Wen Yang authored
BugLink: https://bugs.launchpad.net/bugs/1864773 [ Upstream commit faf5577f ] The phy_dn variable is still being used in of_phy_connect() after the of_node_put() call, which may result in use-after-free. Fixes: 1dd2d06c ("net: Rework pasemi_mac driver to use of_mdio infrastructure") Signed-off-by:
Wen Yang <wen.yang99@zte.com.cn> Cc: "David S. Miller" <davem@davemloft.net> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Luis Chamberlain <mcgrof@kernel.org> Cc: Michael Ellerman <mpe@ellerman.id.au> Cc: netdev@vger.kernel.org Cc: linux-kernel@vger.kernel.org Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Arnd Bergmann authored
BugLink: https://bugs.launchpad.net/bugs/1864773 [ Upstream commit 9dea44c9 ] devm_ioremap_resource() does not currently take 'const' arguments, which results in a warning from the first driver trying to do it anyway: drivers/gpio/gpio-amd-fch.c: In function 'amd_fch_gpio_probe': drivers/gpio/gpio-amd-fch.c:171:49: error: passing argument 2 of 'devm_ioremap_resource' discards 'const' qualifier from pointer target type [-Werror=discarded-qualifiers] priv->base = devm_ioremap_resource(&pdev->dev, &amd_fch_gpio_iores); ^~~~~~~~~~~~~~~~~~~ Change the prototype to allow it, as there is no real reason not to. Fixes: 9bb2e0452508 ("gpio: amd: Make resource struct const") Signed-off-by:
Enrico Weigelt <info@metux.net> Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
-
Andy Shevchenko authored
BugLink: https://bugs.launchpad.net/bugs/1864773 [ Upstream commit 02f36911 ] ida instances allocate some internal memory for ->free_bitmap in addition to the base 'struct ida'. Use ida_destroy() to release that memory at module_exit(). Fixes: 4b45efe8 ("mfd: Add support for Intel Sunrisepoint LPSS devices") Signed-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by:
Lee Jones <lee.jones@linaro.org> Signed-off-by:
-
Kevin Mitchell authored
BugLink: https://bugs.launchpad.net/bugs/1864773 [ Upstream commit 3ddbe913 ] Make it safe to call iommu_disable during early init error conditions before mmio_base is set, but after the struct amd_iommu has been added to the amd_iommu_list. For example, this happens if firmware fails to fill in mmio_phys in the ACPI table leading to a NULL pointer dereference in iommu_feature_disable. Fixes: 2c0ae172 ('iommu/amd: Convert iommu initialization to state machine') Signed-off-by:
Kevin Mitchell <kevmitch@arista.com> Signed-off-by:
Joerg Roedel <jroedel@suse.de> Signed-off-by:
-
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:
-
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:
-
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:
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:
-
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:
Nick Desaulniers <ndesaulniers@google.com> Signed-off-by:
Nathan Chancellor <natechancellor@gmail.com> 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:
-
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:
-
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:
Robert Jarzmik <robert.jarzmik@free.fr> Signed-off-by:
-
