- Mar 09, 2023
-
-
Uwe Kleine-König authored
The probe function doesn't make use of the i2c_device_id * parameter so it can be trivially converted. Reviewed-by:
Kieran Bingham <kieran.bingham+renesas@ideasonboard.com> Acked-by:
Hans Verkuil <hverkuil-cisco@xs4all.nl> Link: https://lore.kernel.org/lkml/20221121102705.16092-1-u.kleine-koenig@pengutronix.de Signed-off-by:
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by:
Wolfram Sang <wsa@kernel.org>
-
Uwe Kleine-König authored
The probe function doesn't make use of the i2c_device_id * parameter so it can be trivially converted. Link: https://lore.kernel.org/lkml/20221118224540.619276-596-uwe@kleine-koenig.org Signed-off-by:
-
Uwe Kleine-König authored
.probe_new() doesn't get the i2c_device_id * parameter, so determine that explicitly in the probe function. Reviewed-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Link: https://lore.kernel.org/lkml/20221118224540.619276-572-uwe@kleine-koenig.org Signed-off-by:
-
Uwe Kleine-König authored
The probe function doesn't make use of the i2c_device_id * parameter so it can be trivially converted. Acked-by:
Richard Weinberger <richard@nod.at> Link: https://lore.kernel.org/lkml/20221118224540.619276-497-uwe@kleine-koenig.org Signed-off-by:
-
Uwe Kleine-König authored
.probe_new() doesn't get the i2c_device_id * parameter, so determine that explicitly in the probe function. Acked-by:
-
- Mar 03, 2023
-
-
Dan Carpenter authored
This is passing IS_ERR() instead of PTR_ERR() so instead of an error code it prints and returns the number 1. Fixes: 4a55ed6f ("i2c: Add GXP SoC I2C Controller") Signed-off-by:
Dan Carpenter <error27@gmail.com> Reviewed-by:
Nick Hawkins <nick.hawkins@hpe.com> Signed-off-by:
-
Wolfram Sang authored
According to Documentation/i2c/fault-codes.rst, NACK after sending an address should be -ENXIO. Signed-off-by: -
Wolfram Sang authored
There used to be error messages which had to go. Now, it only consists of 'break's, so it can go. Signed-off-by: -
Benjamin Gray authored
The ppc64le_allmodconfig sets I2C_PASEMI=y and leaves COMPILE_TEST to default to y and I2C_APPLE to default to m, running into a known incompatible configuration that breaks the build [1]. Specifically, a common dependency (i2c-pasemi-core.o in this case) cannot be used by both builtin and module consumers. Disable I2C_APPLE when I2C_PASEMI is a builtin to prevent this. [1]: https://lore.kernel.org/all/202112061809.XT99aPrf-lkp@intel.com Suggested-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
Benjamin Gray <bgray@linux.ibm.com> Acked-by:
Sven Peter <sven@svenpeter.dev> Signed-off-by:
-
Damien Le Moal authored
Commit 104ff59a ("ata: ahci: Add Tiger Lake UP{3,4} AHCI controller") enabled low power mode for the Tiger Lake AHIC adapter in the author system but created regressions for others. Revert this patch for now until a better solution is found to make this adapter eco-friendly. Link: https://bugzilla.kernel.org/show_bug.cgi?id=217114 CC: stable@vger.kernel.org Signed-off-by:
Damien Le Moal <damien.lemoal@opensource.wdc.com>
-
- Mar 02, 2023
-
-
Thomas Gleixner authored
Miquel reported a warning in the MSI core which is triggered when interrupts are freed via platform_msi_device_domain_free(). This code got reworked to use core functions for freeing the MSI descriptors, but nothing took care to clear the msi_desc->irq entry, which then triggers the warning in msi_free_msi_desc() which uses desc->irq to validate that the descriptor has been torn down. The same issue exists in msi_domain_populate_irqs(). Up to the point that msi_free_msi_descs() grew a warning for this case, this went un-noticed. Provide the counterpart of msi_domain_populate_irqs() and invoke it in platform_msi_device_domain_free() before freeing the interrupts and MSI descriptors and also in the error path of msi_domain_populate_irqs(). Fixes: 2f2940d1 ("genirq/msi: Remove filter from msi_free_descs_free_range()") Reported-by:
Miquel Raynal <miquel.raynal@bootlin.com> Signed-off-by:
Thomas Gleixner <tglx@linutronix.de> Tested-by:
-
Uwe Kleine-König authored
The single difference between returning 0 and returning an error code in a platform remove callback is that in the latter case the platform core emits a warning about the error being ignored. at91wdt_remove() already emits a warning in the error case, so suppress the more generic (and less helpful) one by returning 0. Signed-off-by:
Claudiu Beznea <claudiu.beznea@microchip.com> Reviewed-by:
Guenter Roeck <linux@roeck-us.net> Link: https://lore.kernel.org/r/20230217095317.1213387-1-u.kleine-koenig@pengutronix.de Signed-off-by:
Wim Van Sebroeck <wim@linux-watchdog.org>
-
Sergio Paracuellos authored
MT7621 SoC has a system controller node. Watchdog need to access to reset status register. Ralink architecture and related driver are old and from the beggining they are using some architecture dependent operations for accessing this shared registers through 'asm/mach-ralink/ralink_regs.h' header file. However this is not ideal from a driver perspective which can just access to the system controller registers in an arch independent way using regmap syscon APIs. Update Kconfig accordingly to select new added dependencies and allow driver to be compile tested. Signed-off-by:
Sergio Paracuellos <sergio.paracuellos@gmail.com> Reviewed-by:
-
Sergio Paracuellos authored
Instead of using static global definitions in driver code, refactor code introducing a new watchdog driver data structure and use it along the code. Reviewed-by:
-
bobzhou authored
This patch is used to fix following compilation issue with legacy gcc error: ‘for’ loop initial declarations are only allowed in C99 mode for (int i = 0; i < adev->vcn.num_vcn_inst; ++i) { Signed-off-by:bobzhou <bob.zhou@amd.com> Reviewed-by:
Guchun Chen <guchun.chen@amd.com> Signed-off-by:
Alex Deucher <alexander.deucher@amd.com>
-
Sung Joon Kim authored
[why] More branch devices are able to support Freesync over PCon so include them in the list of supporting devices. [how] Add more compatible PCon devices in the whitelist for Freesync over Pcon. Reviewed-by:
Harry Wentland <Harry.Wentland@amd.com> Acked-by:
Qingqing Zhuo <qingqing.zhuo@amd.com> Signed-off-by:
Sung Joon Kim <sungjoon.kim@amd.com> Tested-by:
Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by:
-
Aric Cyr authored
This reverts commit 4f1b5e73. [Why & How] Original change causes a regression. Revert until fix is available. Reviewed-by:
Aric Cyr <aric.cyr@amd.com> Acked-by:
-
Alex Hung authored
[WHY] When PTEBufferSizeInRequests is zero, UBSAN reports the following warning because dml_log2 returns an unexpected negative value: shift exponent 4294966273 is too large for 32-bit type 'int' [HOW] In the case PTEBufferSizeInRequests is zero, skip the dml_log2() and assign the result directly. Reviewed-by:
Jun Lei <Jun.Lei@amd.com> Acked-by:
Alex Hung <alex.hung@amd.com> Tested-by:
-
Ryan Lin authored
[Why] Needs to set the default value of the LTTPR timeout after resume. [How] Set the default (3.2ms) timeout at resuming if the sink supports LTTPR Reviewed-by:
Jerry Zuo <Jerry.Zuo@amd.com> Acked-by:
Ryan Lin <tsung-hua.lin@amd.com> Tested-by:
-
Horatio Zhang authored
The call trace occurs when the amdgpu is removed after the mode1 reset. During mode1 reset, from suspend to resume, there is no need to reinitialize the ta firmware buffer which caused the bo pin_count increase redundantly. [ 489.885525] Call Trace: [ 489.885525] <TASK> [ 489.885526] amdttm_bo_put+0x34/0x50 [amdttm] [ 489.885529] amdgpu_bo_free_kernel+0xe8/0x130 [amdgpu] [ 489.885620] psp_free_shared_bufs+0xb7/0x150 [amdgpu] [ 489.885720] psp_hw_fini+0xce/0x170 [amdgpu] [ 489.885815] amdgpu_device_fini_hw+0x2ff/0x413 [amdgpu] [ 489.885960] ? blocking_notifier_chain_unregister+0x56/0xb0 [ 489.885962] amdgpu_driver_unload_kms+0x51/0x60 [amdgpu] [ 489.886049] amdgpu_pci_remove+0x5a/0x140 [amdgpu] [ 489.886132] ? __pm_runtime_resume+0x60/0x90 [ 489.886134] pci_device_remove+0x3e/0xb0 [ 489.886135] __device_release_driver+0x1ab/0x2a0 [ 489.886137] driver_detach+0xf3/0x140 [ 489.886138] bus_remove_driver+0x6c/0xf0 [ 489.886140] driver_unregister+0x31/0x60 [ 489.886141] pci_unregister_driver+0x40/0x90 [ 489.886142] amdgpu_exit+0x15/0x451 [amdgpu] Signed-off-by:
Horatio Zhang <Hongkun.Zhang@amd.com> Signed-off-by:
longlyao <Longlong.Yao@amd.com> Reviewed-by:
-
Tom Rix authored
building with gcc and W=1 reports drivers/gpu/drm/amd/amdgpu/vcn_v4_0.c:81:29: error: variable ‘ring’ set but not used [-Werror=unused-but-set-variable] 81 | struct amdgpu_ring *ring; | ^~~~ ring is not used so remove it. Signed-off-by:Tom Rix <trix@redhat.com> Signed-off-by:
-
tiancyin authored
[Why] Variable adev->crtc_irq.num_types was initialized as the value of adev->mode_info.num_crtc at early_init stage, later at hw_init stage, the num_crtc changed due to the display pipe harvest on some SKUs, but the num_types was not updated accordingly, that cause below error in gpu recover. *ERROR* amdgpu_dm_set_crtc_irq_state: crtc is NULL at id :3 *ERROR* amdgpu_dm_set_crtc_irq_state: crtc is NULL at id :3 *ERROR* amdgpu_dm_set_crtc_irq_state: crtc is NULL at id :3 *ERROR* amdgpu_dm_set_pflip_irq_state: crtc is NULL at id :3 *ERROR* amdgpu_dm_set_pflip_irq_state: crtc is NULL at id :3 *ERROR* amdgpu_dm_set_pflip_irq_state: crtc is NULL at id :3 *ERROR* amdgpu_dm_set_pflip_irq_state: crtc is NULL at id :3 *ERROR* amdgpu_dm_set_vupdate_irq_state: crtc is NULL at id :3 *ERROR* amdgpu_dm_set_vupdate_irq_state: crtc is NULL at id :3 *ERROR* amdgpu_dm_set_vupdate_irq_state: crtc is NULL at id :3 [How] Defer the initialization of num_types to eliminate the error logs. Signed-off-by:
tiancyin <tianci.yin@amd.com> Reviewed-by:
Hamza Mahfooz <hamza.mahfooz@amd.com> Signed-off-by:
-
Mario Limonciello authored
A mistake has been made in the BIOS for some ASICs with NBIO 7.5.1 where some NBIO registers aren't properly setup. Ensure that they're set during initialization. Tested-by:
Richard Gong <richard.gong@amd.com> Signed-off-by:
Mario Limonciello <mario.limonciello@amd.com> Acked-by:
-
Harry Wentland authored
This will let us pass the kms_hdr.bpc_switch IGT test. The reason the bpc restriction was required is historical. At one point in time we were not falling back to a lower bpc when we didn't have enough bandwidth for the maximum bpc reported by a display. This meant that we couldn't enable some high refresh modes unless we limitted the bpc. Starting with this patch the issue is fixed: commit cbd14ae7 ("drm/amd/display: Fix incorrectly pruned modes with deep color") This patch implemented a fallback mechanism if mode validation failed at the max bpc. This means users now automatically get all modes that can be supported by at least 6 bpc. The driver will enable the mode with the highest possible bpc that is supported by the display. v2: - explain why this is no longer needed (Michel) - refer to commit that fixed bpc fallback (Michel) Signed-off-by:
Joshua Ashton <joshua@froggi.es> Reviewed-by:
Michel Dänzer <mdaenzer@redhat.com> Signed-off-by:
-
Candice Li authored
Fixes following warnings: warning: no previous prototype for 'umc_v8_10_convert_error_address' warning: variable 'channel_index' set but not used Reported-by:
kernel test robot <lkp@intel.com> Signed-off-by:
Candice Li <candice.li@amd.com> Reviewed-by:
Tao Zhou <tao.zhou1@amd.com> Signed-off-by:
-
Mark Hawrylak authored
Apple iMac11,2 (mid 2010) also with Radeon HD-4670 that has the same issue as iMac10,1 (late 2009) where the internal eDP panel stays dark on driver load. This patch treats iMac11,2 the same as iMac10,1, so the eDP panel stays active. Additional steps: Kernel boot parameter radeon.nomodeset=0 required to keep the eDP panel active. This patch is an extension of commit 564d8a2c ("drm/radeon: Fix eDP for single-display iMac10,1 (v2)") Link: https://lore.kernel.org/all/lsq.1507553064.833262317@decadent.org.uk/ Signed-off-by:
Mark Hawrylak <mark.hawrylak@gmail.com> Signed-off-by:
-
- Mar 01, 2023
-
-
Mayuresh Chitale authored
Applications need to be able to program the SBI implementation specific or custom firmware events in addition to the standard firmware events. Remove a check in the driver that prohibits the programming of the custom firmware events. Signed-off-by:
Mayuresh Chitale <mchitale@ventanamicro.com> Reviewed-by:
Andrew Jones <ajones@ventanamicro.com> Link: https://lore.kernel.org/r/20230208074314.3661406-1-mchitale@ventanamicro.com Signed-off-by:
Palmer Dabbelt <palmer@rivosinc.com>
-
Arnd Bergmann authored
The argument to do_div() is a 32-bit integer, and it was read from a 32-bit register so there is no point in doing a 64-bit division on it. On 32-bit arm, do_div() causes a compile-time warning here: include/asm-generic/div64.h:238:22: error: passing argument 1 of '__div64_32' from incompatible pointer type [-Werror=incompatible-pointer-types] 238 | __rem = __div64_32(&(n), __base); \ | ^~~~ | | | unsigned int * drivers/power/supply/qcom_battmgr.c:1130:4: note: in expansion of macro 'do_div' 1130 | do_div(battmgr->status.percent, 100); Signed-off-by:Geert Uytterhoeven <geert+renesas@glider.be> Acked-by:
Sebastian Reichel <sebastian.reichel@collabora.com> Reviewed-by:
Konrad Dybcio <konrad.dybcio@linaro.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
Dan Carpenter authored
The of_iomap() function returns NULL if it fails. It never returns error pointers. Fix the check accordingly. Fixes: 6286bbb4 ("cpufreq: apple-soc: Add new driver to control Apple SoC CPU P-states") Signed-off-by:
Eric Curtin <ecurtin@redhat.com> Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com>
-
Randy Dunlap authored
REGMAP is a hidden (not user visible) symbol. Users cannot set it directly thru "make *config", so drivers should select it instead of depending on it if they need it. Consistently using "select" or "depends on" can also help reduce Kconfig circular dependency issues. Therefore, change the use of "depends on REGMAP" to "select REGMAP". Fixes: b474303f ("thermal: add Intel BXT WhiskeyCove PMIC thermal driver") Signed-off-by:
Randy Dunlap <rdunlap@infradead.org> Signed-off-by:
-
Dan Carpenter authored
If alloc_soc_dts() fails, then we can just return. Trying to free "soc_dts" will lead to an Oops. Fixes: 8c187693 ("thermal: intel Quark SoC X1000 DTS thermal driver") Signed-off-by:
-
Mario Limonciello authored
commit 018d6711 ("ACPI: x86: Add a quirk for Dell Inspiron 14 2-in-1 for StorageD3Enable") introduced a quirk to allow a system with ambiguous use of _ADR 0 to force StorageD3Enable. It was reported that several more Dell systems suffered the same symptoms. As the list is continuing to grow but these are all Cezanne systems, instead add Cezanne to the CPU list to apply the StorageD3Enable property and remove the whole list. It was also reported that an HP system only has StorageD3Enable on the ACPI device for the first NVME disk, not the second. Link: https://bugzilla.kernel.org/show_bug.cgi?id=217003 Link: https://bugzilla.kernel.org/show_bug.cgi?id=216773 Reported-by:
David Alvarez Lombardi <dqalombardi@proton.me> Reported-by:
<dbilios@stdio.gr> Reported-and-tested-by:
Elvis Angelaccio <elvis.angelaccio@kde.org> Tested-by:
<victor.bonnelle@proton.me> Tested-by:
<hurricanepootis@protonmail.com> Signed-off-by:
-
Tom Lendacky authored
Commit 47894e0f ("virt/sev-guest: Prevent IV reuse in the SNP guest driver") changed the behavior associated with the return value when the caller does not supply a large enough certificate buffer. Prior to the commit a value of -EIO was returned. Now, 0 is returned. This breaks the established ABI with the user. Change the code to detect the buffer size error and return -EIO. Fixes: 47894e0f ("virt/sev-guest: Prevent IV reuse in the SNP guest driver") Reported-by:
Larry Dewey <larry.dewey@amd.com> Signed-off-by:
Tom Lendacky <thomas.lendacky@amd.com> Signed-off-by:
Borislav Petkov (AMD) <bp@alien8.de> Tested-by:
-
- Feb 28, 2023
-
-
Jack Chen authored
Bus-speed could be default(12.5MHz) or defined by users in dts. Dw-i3c-master should not hard-code the initial speed to be I3C_BUS_TYP_I3C_SCL_RATE (12.5MHz) And because of Synopsys's I3C controller limit (hcnt/lcnt register length) and core-clk provided, there is a limit to bus speed, too. For example, when core-clk is 250 MHz, the bus speed cannot be lowered below 1MHz. Tested: tested with an i3c sensor and captured with a logic analyzer. Signed-off-by:
Jack Chen <zenghuchen@google.com> Link: https://lore.kernel.org/r/20230216151057.293764-1-zenghuchen@google.com Signed-off-by:
Alexandre Belloni <alexandre.belloni@bootlin.com>
-
Nick Alcock authored
Since commit 8b41fc44 ("kbuild: create modules.builtin without Makefile.modbuiltin or tristate.conf"), MODULE_LICENSE declarations are used to identify modules. As a consequence, uses of the macro in non-modules will cause modprobe to misidentify their containing object file as a module when it is not (false positives), and modprobe might succeed rather than failing with a suitable error message. So remove it in the files in this commit, none of which can be built as modules. Signed-off-by:
Nick Alcock <nick.alcock@oracle.com> Suggested-by:
Luis Chamberlain <mcgrof@kernel.org> Signed-off-by:
-
Nick Alcock authored
Since commit 8b41fc44 ("kbuild: create modules.builtin without Makefile.modbuiltin or tristate.conf"), MODULE_LICENSE declarations are used to identify modules. As a consequence, uses of the macro in non-modules will cause modprobe to misidentify their containing object file as a module when it is not (false positives), and modprobe might succeed rather than failing with a suitable error message. So remove it in the files in this commit, none of which can be built as modules. Signed-off-by:
-
Mario Limonciello authored
There was a quirk in `acpi/x86/s2idle.c` for an HP Elitebook G9 platforms to force AMD GUID codepath instead of Microsoft codepath. This was due to a bug with WCN6855 WLAN firmware interaction with the system. This bug is fixed by WCN6855 firmware: WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.23 Remove the quirk as it's no longer necessary with this firmware. Link: https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/commit/?id=c7a57ef688f7d99d8338a5d8edddc8836ff0e6de Tested-by:
Anson Tsao <anson.tsao@amd.com> Signed-off-by:
-
Krishna Yarlagadda authored
Fix warn: iterator used outside loop: 'xfer'. 'xfer' variable contain invalid value in few conditions. Complete transfer within DATA phase in successful case and at the end for failed transfer. Reported-by:
Dan Carpenter <dan.carpenter@oracle.com> Link:https://lore.kernel.org/all/202210191211.46FkzKmv-lkp@intel.com/ Fixes: 8777dd9d ("spi: tegra210-quad: Fix combined sequence") Signed-off-by:
Krishna Yarlagadda <kyarlagadda@nvidia.com> Link: https://lore.kernel.org/r/20230227200428.45832-1-kyarlagadda@nvidia.com Signed-off-by:
Mark Brown <broonie@kernel.org>
-
Daniel Wagner authored
The kernel always logs the unique subsystem name for a discovery controller, even in the case user space asked for the well known. This has lead to confusion as the logs of nvme-cli and the kernel logs didn't match. First, nvme-cli connects to the well known discovery controller to figure out if it supports TP8013. If so then nvme-cli disconnects and connects to the unique discovery controller. Currently, the kernel show that user space connected twice to the unique one. To avoid further confusion, show the well known discovery controller if user space asked for it: $ nvme connect-all -v -t tcp -a 192.168.0.1 nvme0: nqn.2014-08.org.nvmexpress.discovery connected nvme0: nqn.2014-08.org.nvmexpress.discovery disconnected nvme0: nqn.discovery connected kernel log: nvme nvme0: new ctrl: NQN "nqn.2014-08.org.nvmexpress.discovery", addr 192.168.0.1:8009 nvme nvme0: Removing ctrl: NQN "nqn.2014-08.org.nvmexpress.discovery" nvme nvme0: new ctrl: NQN "nqn.discovery", addr 192.168.0.1:8009 Fixes: e5ea42fa ("nvme: display correct subsystem NQN") Signed-off-by:
Daniel Wagner <dwagner@suse.de> Reviewed-by:
Hannes Reinecke <hare@suse.de> Signed-off-by:
Christoph Hellwig <hch@lst.de>
-
Akinobu Mita authored
While the error recovery work is temporarily failing reconnect attempts, running the 'nvme list' command causes a kernel NULL pointer dereference by calling getsockname() with a released socket. During error recovery work, the nvme tcp socket is released and a new one created, so it is not safe to access the socket without proper check. Signed-off-by:
Akinobu Mita <akinobu.mita@gmail.com> Fixes: 02c57a82 ("nvme-tcp: print actual source IP address through sysfs "address" attr") Reviewed-by:
Martin Belanger <martin.belanger@dell.com> Reviewed-by:
-
