- 18 11月, 2020 1 次提交
-
-
由 Lukas Bulwahn 提交于
Commit 6ee1b77b ("iommu/vt-d: Add svm/sva invalidate function") introduced intel_iommu_sva_invalidate() when CONFIG_INTEL_IOMMU_SVM. This function uses the dedicated static variable inv_type_granu_table and functions to_vtd_granularity() and to_vtd_size(). These parts are unused when !CONFIG_INTEL_IOMMU_SVM, and hence, make CC=clang W=1 warns with an -Wunused-function warning. Include these parts conditionally on CONFIG_INTEL_IOMMU_SVM. Fixes: 6ee1b77b ("iommu/vt-d: Add svm/sva invalidate function") Signed-off-by: NLukas Bulwahn <lukas.bulwahn@gmail.com> Acked-by: NLu Baolu <baolu.lu@linux.intel.com> Link: https://lore.kernel.org/r/20201115205951.20698-1-lukas.bulwahn@gmail.comSigned-off-by: NWill Deacon <will@kernel.org>
-
- 09 11月, 2020 1 次提交
-
-
由 Daniel Vetter 提交于
It's buggy: On Fri, Nov 06, 2020 at 10:30:08PM +0800, Minh Yuan wrote: > We recently discovered a slab-out-of-bounds read in fbcon in the latest > kernel ( v5.10-rc2 for now ). The root cause of this vulnerability is that > "fbcon_do_set_font" did not handle "vc->vc_font.data" and > "vc->vc_font.height" correctly, and the patch > <https://lkml.org/lkml/2020/9/27/223> for VT_RESIZEX can't handle this > issue. > > Specifically, we use KD_FONT_OP_SET to set a small font.data for tty6, and > use KD_FONT_OP_SET again to set a large font.height for tty1. After that, > we use KD_FONT_OP_COPY to assign tty6's vc_font.data to tty1's vc_font.data > in "fbcon_do_set_font", while tty1 retains the original larger > height. Obviously, this will cause an out-of-bounds read, because we can > access a smaller vc_font.data with a larger vc_font.height. Further there was only one user ever. - Android's loadfont, busybox and console-tools only ever use OP_GET and OP_SET - fbset documentation only mentions the kernel cmdline font: option, not anything else. - systemd used OP_COPY before release 232 published in Nov 2016 Now unfortunately the crucial report seems to have gone down with gmane, and the commit message doesn't say much. But the pull request hints at OP_COPY being broken https://github.com/systemd/systemd/pull/3651 So in other words, this never worked, and the only project which foolishly every tried to use it, realized that rather quickly too. Instead of trying to fix security issues here on dead code by adding missing checks, fix the entire thing by removing the functionality. Note that systemd code using the OP_COPY function ignored the return value, so it doesn't matter what we're doing here really - just in case a lone server somewhere happens to be extremely unlucky and running an affected old version of systemd. The relevant code from font_copy_to_all_vcs() in systemd was: /* copy font from active VT, where the font was uploaded to */ cfo.op = KD_FONT_OP_COPY; cfo.height = vcs.v_active-1; /* tty1 == index 0 */ (void) ioctl(vcfd, KDFONTOP, &cfo); Note this just disables the ioctl, garbage collecting the now unused callbacks is left for -next. v2: Tetsuo found the old mail, which allowed me to find it on another archive. Add the link too. Acked-by: NPeilin Ye <yepeilin.cs@gmail.com> Reported-by: NMinh Yuan <yuanmingbuaa@gmail.com> References: https://lists.freedesktop.org/archives/systemd-devel/2016-June/036935.html References: https://github.com/systemd/systemd/pull/3651 Cc: Greg KH <greg@kroah.com> Cc: Peilin Ye <yepeilin.cs@gmail.com> Cc: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp> Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com> Link: https://lore.kernel.org/r/20201108153806.3140315-1-daniel.vetter@ffwll.chSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 07 11月, 2020 7 次提交
-
-
由 Damien Le Moal 提交于
Commit aa1c09cb ("null_blk: Fix locking in zoned mode") changed zone locking to using the potentially sleeping wait_on_bit_io() function. This is acceptable when memory backing is enabled as the device queue is in that case marked as blocking, but this triggers a scheduling while in atomic context with memory backing disabled. Fix this by relying solely on the device zone spinlock for zone information protection without temporarily releasing this lock around null_process_cmd() execution in null_zone_write(). This is OK to do since when memory backing is disabled, command processing does not block and the memory backing lock nullb->lock is unused. This solution avoids the overhead of having to mark a zoned null_blk device queue as blocking when memory backing is unused. This patch also adds comments to the zone locking code to explain the unusual locking scheme. Fixes: aa1c09cb ("null_blk: Fix locking in zoned mode") Reported-by: Nkernel test robot <lkp@intel.com> Signed-off-by: NDamien Le Moal <damien.lemoal@wdc.com> Reviewed-by: NChristoph Hellwig <hch@lst.de> Cc: stable@vger.kernel.org Signed-off-by: NJens Axboe <axboe@kernel.dk>
-
由 Matthias Reichl 提交于
Commit 2ae0b31e ("tty: don't crash in tty_init_dev when missing tty_port") didn't fully prevent the crash as the cleanup path in tty_init_dev() calls release_tty() which dereferences tty->port without checking it for non-null. Add tty->port checks to release_tty to avoid the kernel crash. Fixes: 2ae0b31e ("tty: don't crash in tty_init_dev when missing tty_port") Signed-off-by: NMatthias Reichl <hias@horus.com> Link: https://lore.kernel.org/r/20201105123432.4448-1-hias@horus.com Cc: stable <stable@vger.kernel.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Qinglang Miao 提交于
Add the missing platform_driver_unregister() before return from serial_txx9_init in the error handling case when failed to register serial_txx9_pci_driver with macro ENABLE_SERIAL_TXX9_PCI defined. Fixes: ab4382d2 ("tty: move drivers/serial/ to drivers/tty/serial/") Signed-off-by: NQinglang Miao <miaoqinglang@huawei.com> Link: https://lore.kernel.org/r/20201103084942.109076-1-miaoqinglang@huawei.com Cc: stable <stable@vger.kernel.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Lucas Stach 提交于
Since 699cc4df (tty: serial: imx: add imx earlycon driver), the earlycon part of imx serial is a separate driver and isn't necessarily enabled anymore when the console is enabled. This causes users to loose the earlycon functionality when upgrading their kenrel configuration via oldconfig. Enable earlycon by default when IMX_SERIAL_CONSOLE is enabled. Fixes: 699cc4df (tty: serial: imx: add imx earlycon driver) Reviewed-by: NFabio Estevam <festevam@gmail.com> Reviewed-by: NFugang Duan <fugang.duan@nxp.com> Signed-off-by: NLucas Stach <l.stach@pengutronix.de> Link: https://lore.kernel.org/r/20201105204026.1818219-1-l.stach@pengutronix.de Cc: stable <stable@vger.kernel.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Claire Chang 提交于
Mediatek 8250 port supports speed higher than uartclk / 16. If the baud rates in both the new and the old termios setting are higher than uartclk / 16, the WARN_ON in uart_get_baud_rate() will be triggered. Passing NULL as the old termios so uart_get_baud_rate() will use uartclk / 16 - 1 as the new baud rate which will be replaced by the original baud rate later by tty_termios_encode_baud_rate() in mtk8250_set_termios(). Fixes: 551e553f ("serial: 8250_mtk: Fix high-speed baud rates clamping") Signed-off-by: NClaire Chang <tientzu@chromium.org> Link: https://lore.kernel.org/r/20201102120749.374458-1-tientzu@chromium.org Cc: stable <stable@vger.kernel.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Tyler Hicks 提交于
Mimic the pre-existing ACPI and Device Tree event log behavior by not creating the binary_bios_measurements file when the EFI TPM event log is empty. This fixes the following NULL pointer dereference that can occur when reading /sys/kernel/security/tpm0/binary_bios_measurements after the kernel received an empty event log from the firmware: BUG: kernel NULL pointer dereference, address: 000000000000002c #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 [#1] SMP PTI CPU: 2 PID: 3932 Comm: fwupdtpmevlog Not tainted 5.9.0-00003-g629990edad62 #17 Hardware name: LENOVO 20LCS03L00/20LCS03L00, BIOS N27ET38W (1.24 ) 11/28/2019 RIP: 0010:tpm2_bios_measurements_start+0x3a/0x550 Code: 54 53 48 83 ec 68 48 8b 57 70 48 8b 1e 65 48 8b 04 25 28 00 00 00 48 89 45 d0 31 c0 48 8b 82 c0 06 00 00 48 8b 8a c8 06 00 00 <44> 8b 60 1c 48 89 4d a0 4c 89 e2 49 83 c4 20 48 83 fb 00 75 2a 49 RSP: 0018:ffffa9c901203db0 EFLAGS: 00010246 RAX: 0000000000000010 RBX: 0000000000000000 RCX: 0000000000000010 RDX: ffff8ba1eb99c000 RSI: ffff8ba1e4ce8280 RDI: ffff8ba1e4ce8258 RBP: ffffa9c901203e40 R08: ffffa9c901203dd8 R09: ffff8ba1ec443300 R10: ffffa9c901203e50 R11: 0000000000000000 R12: ffff8ba1e4ce8280 R13: ffffa9c901203ef0 R14: ffffa9c901203ef0 R15: ffff8ba1e4ce8258 FS: 00007f6595460880(0000) GS:ffff8ba1ef880000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000000000002c CR3: 00000007d8d18003 CR4: 00000000003706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ? __kmalloc_node+0x113/0x320 ? kvmalloc_node+0x31/0x80 seq_read+0x94/0x420 vfs_read+0xa7/0x190 ksys_read+0xa7/0xe0 __x64_sys_read+0x1a/0x20 do_syscall_64+0x37/0x80 entry_SYSCALL_64_after_hwframe+0x44/0xa9 In this situation, the bios_event_log pointer in the tpm_bios_log struct was not NULL but was equal to the ZERO_SIZE_PTR (0x10) value. This was due to the following kmemdup() in tpm_read_log_efi(): int tpm_read_log_efi(struct tpm_chip *chip) { ... /* malloc EventLog space */ log->bios_event_log = kmemdup(log_tbl->log, log_size, GFP_KERNEL); if (!log->bios_event_log) { ret = -ENOMEM; goto out; } ... } When log_size is zero, due to an empty event log from firmware, ZERO_SIZE_PTR is returned from kmemdup(). Upon a read of the binary_bios_measurements file, the tpm2_bios_measurements_start() function does not perform a ZERO_OR_NULL_PTR() check on the bios_event_log pointer before dereferencing it. Rather than add a ZERO_OR_NULL_PTR() check in functions that make use of the bios_event_log pointer, simply avoid creating the binary_bios_measurements_file as is done in other event log retrieval backends. Explicitly ignore all of the events in the final event log when the main event log is empty. The list of events in the final event log cannot be accurately parsed without referring to the first event in the main event log (the event log header) so the final event log is useless in such a situation. Fixes: 58cc1e4f ("tpm: parse TPM event logs based on EFI table") Link: https://lore.kernel.org/linux-integrity/E1FDCCCB-CA51-4AEE-AC83-9CDE995EAE52@canonical.com/Reported-by: NKai-Heng Feng <kai.heng.feng@canonical.com> Reported-by: NKenneth R. Crudup <kenny@panix.com> Reported-by: NMimi Zohar <zohar@linux.ibm.com> Cc: Thiébaud Weksteen <tweek@google.com> Cc: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: NTyler Hicks <tyhicks@linux.microsoft.com> Reviewed-by: NJarkko Sakkinen <jarkko@kernel.org> Signed-off-by: NJarkko Sakkinen <jarkko@kernel.org>
-
由 Jerry Snitselaar 提交于
There is a misconfiguration in the bios of the gpio pin used for the interrupt in the T490s. When interrupts are enabled in the tpm_tis driver code this results in an interrupt storm. This was initially reported when we attempted to enable the interrupt code in the tpm_tis driver, which previously wasn't setting a flag to enable it. Due to the reports of the interrupt storm that code was reverted and we went back to polling instead of using interrupts. Now that we know the T490s problem is a firmware issue, add code to check if the system is a T490s and disable interrupts if that is the case. This will allow us to enable interrupts for everyone else. If the user has a fixed bios they can force the enabling of interrupts with tpm_tis.interrupts=1 on the kernel command line. Cc: Peter Huewe <peterhuewe@gmx.de> Cc: Jason Gunthorpe <jgg@ziepe.ca> Cc: Hans de Goede <hdegoede@redhat.com> Signed-off-by: NJerry Snitselaar <jsnitsel@redhat.com> Reviewed-by: NJames Bottomley <James.Bottomley@HansenPartnership.com> Reviewed-by: NHans de Goede <hdegoede@redhat.com> Reviewed-by: NJarkko Sakkinen <jarkko@kernel.org> Signed-off-by: NJarkko Sakkinen <jarkko@kernel.org>
-
- 06 11月, 2020 13 次提交
-
-
由 Michael Wu 提交于
Sometimes we would get the following flow when doing an i2cset: 0x1 STATUS SLAVE_ACTIVITY=0x1 : RAW_INTR_STAT=0x514 : INTR_STAT=0x4 I2C_SLAVE_WRITE_RECEIVED 0x1 STATUS SLAVE_ACTIVITY=0x0 : RAW_INTR_STAT=0x714 : INTR_STAT=0x204 I2C_SLAVE_WRITE_REQUESTED I2C_SLAVE_WRITE_RECEIVED Documentation/i2c/slave-interface.rst says that I2C_SLAVE_WRITE_REQUESTED, which is mandatory, should be sent while the data did not arrive yet. It means in a write-request I2C_SLAVE_WRITE_REQUESTED should be reported before any I2C_SLAVE_WRITE_RECEIVED. By the way, I2C_SLAVE_STOP didn't be reported in the above case because DW_IC_INTR_STAT was not 0x200. dev->status can be used to record the current state, especially Designware I2C controller has no interrupts to identify a write-request. This patch makes not only I2C_SLAVE_WRITE_REQUESTED been reported first when IC_INTR_RX_FULL is rising and dev->status isn't STATUS_WRITE_IN_PROGRESS but also I2C_SLAVE_STOP been reported when a STOP condition is received. Signed-off-by: NMichael Wu <michael.wu@vatics.com> Acked-by: NJarkko Nikula <jarkko.nikula@linux.intel.com> Signed-off-by: NWolfram Sang <wsa@kernel.org>
-
由 Michael Wu 提交于
If some bits were cleared by i2c_dw_read_clear_intrbits_slave() in i2c_dw_isr_slave() and not handled immediately, those cleared bits would not be shown again by later i2c_dw_read_clear_intrbits_slave(). They therefore were forgotten to be handled. i2c_dw_read_clear_intrbits_slave() should be called once in an ISR and take its returned state for all later handlings. Signed-off-by: NMichael Wu <michael.wu@vatics.com> Acked-by: NJarkko Nikula <jarkko.nikula@linux.intel.com> Signed-off-by: NWolfram Sang <wsa@kernel.org>
-
由 Geert Uytterhoeven 提交于
The Mellanox BlueField I2C controller is only present on Mellanox BlueField SoCs. Hence add a dependency on MELLANOX_PLATFORM, to prevent asking the user about this driver when configuring a kernel without Mellanox platform support. Fixes: b5b5b320 ("i2c: mlxbf: I2C SMBus driver for Mellanox BlueField SoC") Signed-off-by: NGeert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: NWolfram Sang <wsa@kernel.org>
-
由 Khalil Blaiech 提交于
Correct the email addresses of the author and the maintainer of the Mellanox BlueField I2C driver. Fixes: b5b5b320 ("i2c: mlxbf: I2C SMBus driver for Mellanox BlueField SoC") Reviewed-by: NLeon Romanovsky <leonro@nvidia.com> Signed-off-by: NKhalil Blaiech <kblaiech@nvidia.com> Signed-off-by: NWolfram Sang <wsa@kernel.org>
-
由 Khalil Blaiech 提交于
The reference clock frequency remains the same across Bluefield products. Thus, update the frequency and rename the macro. Fixes: b5b5b320 ("i2c: mlxbf: I2C SMBus driver for Mellanox BlueField SoC") Reviewed-by: NLeon Romanovsky <leonro@nvidia.com> Signed-off-by: NKhalil Blaiech <kblaiech@nvidia.com> Signed-off-by: NWolfram Sang <wsa@kernel.org>
-
由 Khalil Blaiech 提交于
Few wrapper functions are useless and can be inlined. So delete mlxbf_i2c_read() and mlxbf_i2c_write() and replace them with readl() and writel(), respectively. Also delete mlxbf_i2c_read_data() and mlxbf_i2c_write() and replace them with ioread32be() and iowrite32be(), respectively. Fixes: b5b5b320 ("i2c: mlxbf: I2C SMBus driver for Mellanox BlueField SoC") Reviewed-by: NLeon Romanovsky <leonro@nvidia.com> Reviewed-by: NVadim Pasternak <vadimp@nvidia.com> Signed-off-by: NKhalil Blaiech <kblaiech@nvidia.com> Signed-off-by: NWolfram Sang <wsa@kernel.org>
-
由 Khalil Blaiech 提交于
Address warnings "warning: cast to restricted __be32" reported by sparse. Fixes: b5b5b320 ("i2c: mlxbf: I2C SMBus driver for Mellanox BlueField SoC") Reported-by: Nkernel test robot <lkp@intel.com> Reviewed-by: NLeon Romanovsky <leonro@nvidia.com> Reviewed-by: NVadim Pasternak <vadimp@nvidia.com> Signed-off-by: NKhalil Blaiech <kblaiech@nvidia.com> Signed-off-by: NWolfram Sang <wsa@kernel.org>
-
由 Khalil Blaiech 提交于
The build fails with "implicit declaration of function 'acpi_device_uid'" error. Thus, protect ACPI function calls from being called when CONFIG_ACPI is disabled. Fixes: b5b5b320 ("i2c: mlxbf: I2C SMBus driver for Mellanox BlueField SoC") Reported-by: Nkernel test robot <lkp@intel.com> Reviewed-by: NLeon Romanovsky <leonro@nvidia.com> Reviewed-by: NVadim Pasternak <vadimp@nvidia.com> Signed-off-by: NKhalil Blaiech <kblaiech@nvidia.com> Signed-off-by: NWolfram Sang <wsa@kernel.org>
-
由 Ulrich Hecht 提交于
Implements atomic transfers to fix reboot/shutdown on r8a7790 Lager and similar boards. Signed-off-by: NUlrich Hecht <uli+renesas@fpond.eu> Tested-by: NWolfram Sang <wsa+renesas@sang-engineering.com> Tested-by: NGeert Uytterhoeven <geert+renesas@glider.be> [wsa: some whitespace fixing] Signed-off-by: NWolfram Sang <wsa@kernel.org>
-
由 Martin Hundebøll 提交于
Removing the duplicate gpio chip select level handling in bcm2835_spi_setup() left the lflags variable uninitialized. Avoid trhe use of such variable by passing default flags to gpiochip_request_own_desc(). Fixes: 5e31ba0c ("spi: bcm2835: fix gpio cs level inversion") Signed-off-by: NMartin Hundebøll <martin@geanix.com> Link: https://lore.kernel.org/r/20201105090615.620315-1-martin@geanix.comSigned-off-by: NMark Brown <broonie@kernel.org>
-
由 Zhang Qilong 提交于
pm_runtime_get_sync() will increment pm usage at first and it will resume the device later. If runtime of the device has error or device is in inaccessible state(or other error state), resume operation will fail. If we do not call put operation to decrease the reference, the result is that this device cannot enter the idle state and always stay busy or other non-idle state. Fixes: 249fa821 ("USB: Add driver to control USB fast charge for iOS devices") Signed-off-by: NZhang Qilong <zhangqilong3@huawei.com> Link: https://lore.kernel.org/r/20201102022650.67115-1-zhangqilong3@huawei.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Macpaul Lin 提交于
This patch fixes a possible issue when mtu3_gadget_stop() already assigned NULL to mtu->gadget_driver during mtu_gadget_disconnect(). [<ffffff9008161974>] notifier_call_chain+0xa4/0x128 [<ffffff9008161fd4>] __atomic_notifier_call_chain+0x84/0x138 [<ffffff9008162ec0>] notify_die+0xb0/0x120 [<ffffff900809e340>] die+0x1f8/0x5d0 [<ffffff90080d03b4>] __do_kernel_fault+0x19c/0x280 [<ffffff90080d04dc>] do_bad_area+0x44/0x140 [<ffffff90080d0f9c>] do_translation_fault+0x4c/0x90 [<ffffff9008080a78>] do_mem_abort+0xb8/0x258 [<ffffff90080849d0>] el1_da+0x24/0x3c [<ffffff9009bde01c>] mtu3_gadget_disconnect+0xac/0x128 [<ffffff9009bd576c>] mtu3_irq+0x34c/0xc18 [<ffffff90082ac03c>] __handle_irq_event_percpu+0x2ac/0xcd0 [<ffffff90082acae0>] handle_irq_event_percpu+0x80/0x138 [<ffffff90082acc44>] handle_irq_event+0xac/0x148 [<ffffff90082b71cc>] handle_fasteoi_irq+0x234/0x568 [<ffffff90082a8708>] generic_handle_irq+0x48/0x68 [<ffffff90082a96ac>] __handle_domain_irq+0x264/0x1740 [<ffffff90080819f4>] gic_handle_irq+0x14c/0x250 [<ffffff9008084cec>] el1_irq+0xec/0x194 [<ffffff90085b985c>] dma_pool_alloc+0x6e4/0xae0 [<ffffff9008d7f890>] cmdq_mbox_pool_alloc_impl+0xb0/0x238 [<ffffff9008d80904>] cmdq_pkt_alloc_buf+0x2dc/0x7c0 [<ffffff9008d80f60>] cmdq_pkt_add_cmd_buffer+0x178/0x270 [<ffffff9008d82320>] cmdq_pkt_perf_begin+0x108/0x148 [<ffffff9008d824d8>] cmdq_pkt_create+0x178/0x1f0 [<ffffff9008f96230>] mtk_crtc_config_default_path+0x328/0x7a0 [<ffffff90090246cc>] mtk_drm_idlemgr_kick+0xa6c/0x1460 [<ffffff9008f9bbb4>] mtk_drm_crtc_atomic_begin+0x1a4/0x1a68 [<ffffff9008e8df9c>] drm_atomic_helper_commit_planes+0x154/0x878 [<ffffff9008f2fb70>] mtk_atomic_complete.isra.16+0xe80/0x19c8 [<ffffff9008f30910>] mtk_atomic_commit+0x258/0x898 [<ffffff9008ef142c>] drm_atomic_commit+0xcc/0x108 [<ffffff9008ef7cf0>] drm_mode_atomic_ioctl+0x1c20/0x2580 [<ffffff9008ebc768>] drm_ioctl_kernel+0x118/0x1b0 [<ffffff9008ebcde8>] drm_ioctl+0x5c0/0x920 [<ffffff900863b030>] do_vfs_ioctl+0x188/0x1820 [<ffffff900863c754>] SyS_ioctl+0x8c/0xa0 Fixes: df2069ac ("usb: Add MediaTek USB3 DRD driver") Signed-off-by: NMacpaul Lin <macpaul.lin@mediatek.com> Acked-by: NChunfeng Yun <chunfeng.yun@mediatek.com> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/1604642069-20961-1-git-send-email-macpaul.lin@mediatek.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Shannon Nelson 提交于
Check for corner case of port_init failure before using the port_info pointer. Fixes: 4d03e00a ("ionic: Add initial ethtool support") Signed-off-by: NShannon Nelson <snelson@pensando.io> Link: https://lore.kernel.org/r/20201104195606.61184-1-snelson@pensando.ioSigned-off-by: NJakub Kicinski <kuba@kernel.org>
-
- 05 11月, 2020 6 次提交
-
-
由 Jason Gunthorpe 提交于
htmldocs fails with: drivers/infiniband/ulp/srpt/ib_srpt.c:630: warning: Function parameter or member 'port_cnt' not described in 'srpt_unregister_mad_agent' Fixes: 372a1786 ("IB/srpt: Fix memory leak in srpt_add_one") Reported-by: NStephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: NJason Gunthorpe <jgg@nvidia.com>
-
由 Heiner Kallweit 提交于
Network problems with RTL8125B have been reported [0] and with help from Realtek it turned out that this chip version has a hw problem with short packets (similar to RTL8168evl). Having said that activate the same workaround as for RTL8168evl. Realtek suggested to activate the workaround for RTL8125A too, even though they're not 100% sure yet which RTL8125 versions are affected. [0] https://bugzilla.kernel.org/show_bug.cgi?id=209839 Fixes: 0439297b ("r8169: add support for RTL8125B") Reported-by: NMaxim Plotnikov <wgh@torlan.ru> Tested-by: NMaxim Plotnikov <wgh@torlan.ru> Signed-off-by: NHeiner Kallweit <hkallweit1@gmail.com> Link: https://lore.kernel.org/r/8002c31a-60b9-58f1-f0dd-8fd07239917f@gmail.comSigned-off-by: NJakub Kicinski <kuba@kernel.org>
-
由 Daniele Palmas 提交于
Add the following Telit FN980 composition: 0x1055: tty, adb, tty, tty, tty, tty Signed-off-by: NDaniele Palmas <dnlplm@gmail.com> Link: https://lore.kernel.org/r/20201103124425.12940-1-dnlplm@gmail.com Cc: stable@vger.kernel.org Signed-off-by: NJohan Hovold <johan@kernel.org>
-
由 Rob Herring 提交于
With commit 669cbc70 ("PCI: Move DT resource setup into devm_pci_alloc_host_bridge()"), the DT 'ranges' is parsed and populated into resources when the host bridge is allocated. The resources are requested as well, but that happens a second time for the mvebu driver in mvebu_pcie_parse_request_resources(). We should only be requesting the additional resources added in mvebu_pcie_parse_request_resources(). These are not added by default because they use custom properties rather than standard DT address translation. Also, the bus ranges was also populated by default, so we can remove it from mvebu_pci_host_probe(). Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=209729 Fixes: 669cbc70 ("PCI: Move DT resource setup into devm_pci_alloc_host_bridge()") Link: https://lore.kernel.org/r/20201023145252.2691779-1-robh@kernel.org Reported-by: vtolkm@googlemail.com Tested-by: NJan Kundrát <jan.kundrat@cesnet.cz> Signed-off-by: NRob Herring <robh@kernel.org> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com> Acked-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com> Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com> Cc: Jason Cooper <jason@lakedaemon.net> Cc: Russell King <linux@armlinux.org.uk>
-
由 Rob Herring 提交于
Prior to commit 0f71c60f ("PCI: dwc: Remove storing of PCI resources"), the DWC driver was setting up the last memory resource rather than the first memory resource. This doesn't matter for most platforms which only have 1 memory resource, but it broke Tegra194 which has a 2nd (prefetchable) memory region that requires an ATU entry. The first region on Tegra194 relies on the default 1:1 pass-thru of outbound transactions and doesn't need an ATU entry. Fixes: 0f71c60f ("PCI: dwc: Remove storing of PCI resources") Link: https://lore.kernel.org/r/20201026154852.221483-1-robh@kernel.orgReported-by: NVidya Sagar <vidyas@nvidia.com> Signed-off-by: NRob Herring <robh@kernel.org> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com> Acked-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com> Acked-by: NJingoo Han <jingoohan1@gmail.com> Cc: Gustavo Pimentel <gustavo.pimentel@synopsys.com>
-
由 Zhao Qiang 提交于
Since commit 530b5aff ("spi: fsl-dspi: fix use-after-free in remove path"), this driver causes a "NULL pointer dereference" in dspi_suspend/resume. This is because since this commit, the drivers private data point to "dspi" instead of "ctlr", the codes in suspend and resume func were not modified correspondly. Fixes: 530b5aff ("spi: fsl-dspi: fix use-after-free in remove path") Signed-off-by: NZhao Qiang <qiang.zhao@nxp.com> Reviewed-by: NVladimir Oltean <olteanv@gmail.com> Link: https://lore.kernel.org/r/20201103020546.1822-1-qiang.zhao@nxp.comSigned-off-by: NMark Brown <broonie@kernel.org>
-
- 04 11月, 2020 12 次提交
-
-
由 Alex Deucher 提交于
No need for a separate config option at this point. Reviewed-by: NLuben Tuikov <luben.tuikov@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Roman Li 提交于
Display Manager support for green_sardine Signed-off-by: NRoman Li <Roman.Li@amd.com> Reviewed-by: NAlex Deucher <alexander.deucher@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Roman Li 提交于
Display Core support for green_sardine Signed-off-by: NRoman Li <Roman.Li@amd.com> Acked-by: NHersen Wu <hersenxs.wu@amd.com> Reviewed-by: NAlex Deucher <alexander.deucher@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Thong Thai 提交于
Enable Green_Sardine VCN support and VCN firmware loading v2: use apu flags Signed-off-by: NThong Thai <thong.thai@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Aaron Liu 提交于
This patch enable green_sardine_asd.bin loading. v2: use apu flags Signed-off-by: NAaron Liu <aaron.liu@amd.com> Reviewed-by: NHuang Rui <ray.huang@amd.com> Reviewed-by: NPrike Liang <Prike.Liang@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Prike Liang 提交于
Initialize the SDMA IP for green_sardine. v2: use apu flags Signed-off-by: NPrike Liang <Prike.Liang@amd.com> Reviewed-by: NAlex Deucher <alexander.deucher@amd.com> Reviewed-by: NHuang Rui <ray.huang@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Prike Liang 提交于
Enable the gfx base HW function of green_sardine. v2: use apu flags Signed-off-by: NPrike Liang <Prike.Liang@amd.com> Reviewed-by: NAlex Deucher <alexander.deucher@amd.com> Reviewed-by: NHuang Rui <ray.huang@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Prike Liang 提交于
This patch adds common ip support for green_sardine. v2: use apu flags, squash in CG/PG enablement v3: rebase Signed-off-by: NPrike Liang <Prike.Liang@amd.com> Reviewed-by: NAlex Deucher <alexander.deucher@amd.com> Reviewed-by: NHuang Rui <ray.huang@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Prike Liang 提交于
This patch adds green_sardine support for gpu_info firmware and ip block setting. v2: use apu flag Signed-off-by: NPrike Liang <Prike.Liang@amd.com> Reviewed-by: NAlex Deucher <alexander.deucher@amd.com> Reviewed-by: NHuang Rui <ray.huang@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Alex Deucher 提交于
Will be used for Green_Sardine which is a new APU. Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Daniele Palmas 提交于
Add following Telit LE910Cx compositions: 0x1203: rndis, tty, adb, tty, tty, tty, tty 0x1230: tty, adb, rmnet, audio, tty, tty, tty, tty 0x1231: rndis, tty, adb, audio, tty, tty, tty, tty Signed-off-by: NDaniele Palmas <dnlplm@gmail.com> Link: https://lore.kernel.org/r/20201031225458.10512-1-dnlplm@gmail.com [ johan: add comments after entries ] Cc: stable@vger.kernel.org Signed-off-by: NJohan Hovold <johan@kernel.org>
-
由 Johan Hovold 提交于
The write-URB busy flag was being cleared before the completion handler was done with the URB, something which could lead to corrupt transfers due to a racing write request if the URB is resubmitted. Fixes: 507ca9bc ("[PATCH] USB: add ability for usb-serial drivers to determine if their write urb is currently being used.") Cc: stable <stable@vger.kernel.org> # 2.6.13 Reviewed-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NJohan Hovold <johan@kernel.org>
-