Repository navigation
Conversation
Signed-off-by: Dorian Stoll <dorian.stoll@tmsp.io> Patchset: ipts Link: linux-surface/linux-surface@91786c3 Signed-off-by: Mingcong Bai <jeffbai@aosc.io> (cherry picked from commit 4241b8562f1ec9b7b79f9969fe53dafa430508b8) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
Adds a quirk so that IOMMU uses passthrough mode for the IPTS device. Otherwise, when IOMMU is enabled, IPTS produces DMAR errors like: DMAR: [DMA Read NO_PASID] Request device [00:16.4] fault addr 0x104ea3000 [fault reason 0x06] PTE Read access is not set This is very similar to the bug described at: https://bugs.launchpad.net/bugs/1958004 Fixed with the following patch which this patch basically copies: https://launchpadlibrarian.net/586396847/43255ca.diff Signed-off-by: Dorian Stoll <dorian.stoll@tmsp.io> Patchset: ipts [Mingcong Bai: Resolved a minor merge conflict in drivers/iommu/intel/iommu.c.] Link: linux-surface/linux-surface@91786c3 Signed-off-by: Mingcong Bai <jeffbai@aosc.io> (cherry picked from commit fd8b0d2b3fbe11efeaa0f49a59f27495c30bcc39) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
Based on linux-surface/intel-precise-touch@8abe268 Signed-off-by: Dorian Stoll <dorian.stoll@tmsp.io> Patchset: ipts Link: linux-surface/linux-surface@91786c3 Signed-off-by: Mingcong Bai <jeffbai@aosc.io> (cherry picked from commit f737c5be0b3e7dc16b394a0dcf54dcd6ed62215f) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
Signed-off-by: Dorian Stoll <dorian.stoll@tmsp.io> Patchset: ithc Link: linux-surface/linux-surface@91786c3 Signed-off-by: Mingcong Bai <jeffbai@aosc.io> (cherry picked from commit fb9f863716e68ca64eb953e6e9414fb4fe86e911) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
Based on quo/ithc-linux@34539af4726d. Signed-off-by: Maximilian Stoll <luzmaximilian@gmail.com> Patchset: ithc Link: linux-surface/linux-surface@91786c3 Signed-off-by: Mingcong Bai <jeffbai@aosc.io> (cherry picked from commit 891a44d86f046faa0e12d27abd26aa7a1799a3d5) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
… Module Signed-off-by: Maximilian Luz <luzmaximilian@gmail.com> Patchset: surface-sam Link: linux-surface/linux-surface@91786c3 Signed-off-by: Mingcong Bai <jeffbai@aosc.io> (cherry picked from commit 709259d6d7f40ab55160b4f71db081bc155de92e) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
…(ACPI) Patchset: surface-sam Link: linux-surface/linux-surface@91786c3 Signed-off-by: Mingcong Bai <jeffbai@aosc.io> (cherry picked from commit aa93c1208cfd82b5bea46773d7f254acb0b93161) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
Microsoft Surface Pro 4 and Book 1 devices access the MSHW0030 I2C
device via a generic serial bus operation region and RawBytes read
access. On the Surface Book 1, this access is required to turn on (and
off) the discrete GPU.
Multiple things are to note here:
a) The RawBytes access is device/driver dependent. The ACPI
specification states:
> Raw accesses assume that the writer has knowledge of the bus that
> the access is made over and the device that is being accessed. The
> protocol may only ensure that the buffer is transmitted to the
> appropriate driver, but the driver must be able to interpret the
> buffer to communicate to a register.
Thus this implementation may likely not work on other devices
accessing I2C via the RawBytes accessor type.
b) The MSHW0030 I2C device is an HID-over-I2C device which seems to
serve multiple functions:
1. It is the main access point for the legacy-type Surface Aggregator
Module (also referred to as SAM-over-HID, as opposed to the newer
SAM-over-SSH/UART). It has currently not been determined on how
support for the legacy SAM should be implemented. Likely via a
custom HID driver.
2. It seems to serve as the HID device for the Integrated Sensor Hub.
This might complicate matters with regards to implementing a
SAM-over-HID driver required by legacy SAM.
In light of this, the simplest approach has been chosen for now.
However, it may make more sense regarding breakage and compatibility to
either provide functionality for replacing or enhancing the default
operation region handler via some additional API functions, or even to
completely blacklist MSHW0030 from the I2C core and provide a custom
driver for it.
Replacing/enhancing the default operation region handler would, however,
either require some sort of secondary driver and access point for it,
from which the new API functions would be called and the new handler
(part) would be installed, or hard-coding them via some sort of
quirk-like interface into the I2C core.
Signed-off-by: Maximilian Luz <luzmaximilian@gmail.com>
Patchset: surface-sam-over-hid
Link: linux-surface/linux-surface@91786c3
Signed-off-by: Mingcong Bai <jeffbai@aosc.io>
(cherry picked from commit b77289658fad0233987b0a25b74cd49cfbee59ba)
Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
Add driver exposing the discrete GPU power-switch of the Microsoft Surface Book 1 to user-space. On the Surface Book 1, the dGPU power is controlled via the Surface System Aggregator Module (SAM). The specific SAM-over-HID command for this is exposed via ACPI. This module provides a simple driver exposing the ACPI call via a sysfs parameter to user-space, so that users can easily power-on/-off the dGPU. Patchset: surface-sam-over-hid Link: linux-surface/linux-surface@91786c3 Signed-off-by: Mingcong Bai <jeffbai@aosc.io> (cherry picked from commit 47b375f1a8697c576b90fd2f979fd0ed5ed13e6c) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
The power button on the AMD variant of the Surface Laptop uses the same MSHW0040 device ID as the 5th and later generation of Surface devices, however they report 0 for their OEM platform revision. As the _DSM does not exist on the devices requiring special casing, check for the existance of the _DSM to determine if soc_button_array should be loaded. Fixes: c394159 ("Input: soc_button_array - add support for newer surface devices") Co-developed-by: Maximilian Luz <luzmaximilian@gmail.com> Signed-off-by: Sachi King <nakato@nakato.io> Patchset: surface-button Link: linux-surface/linux-surface@91786c3 Signed-off-by: Mingcong Bai <jeffbai@aosc.io> (cherry picked from commit 9057b820fc7dc213d07a8b6d327e1e1c68633a5f) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
The AMD variant of the Surface Laptop report 0 for their OEM platform revision. The Surface devices that require the surfacepro3_button driver do not have the _DSM that gets the OEM platform revision. If the method does not exist, load surfacepro3_button. Fixes: 64dd243 ("platform/x86: surfacepro3_button: Fix device check") Co-developed-by: Maximilian Luz <luzmaximilian@gmail.com> Signed-off-by: Sachi King <nakato@nakato.io> Patchset: surface-button Link: linux-surface/linux-surface@91786c3 Signed-off-by: Mingcong Bai <jeffbai@aosc.io> (cherry picked from commit a547c8cb49464a0b9fecbd60cd77746484935257) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
…Cover The touchpad on the Type-Cover of the Surface Go 3 is sometimes not being initialized properly. Apply USB_QUIRK_DELAY_INIT to fix this issue. More specifically, the device in question is a fairly standard modern touchpad with pointer and touchpad input modes. During setup, the device needs to be switched from pointer- to touchpad-mode (which is done in hid-multitouch) to fully utilize it as intended. Unfortunately, however, this seems to occasionally fail silently, leaving the device in pointer-mode. Applying USB_QUIRK_DELAY_INIT seems to fix this. Link: linux-surface/linux-surface#1059 Signed-off-by: Maximilian Luz <luzmaximilian@gmail.com> Patchset: surface-typecover Link: linux-surface/linux-surface@91786c3 Signed-off-by: Mingcong Bai <jeffbai@aosc.io> (cherry picked from commit 7b0832499e64cee4cd12c6204b5ecc26a31e5757) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
Work around buggy EFI firmware: On some Microsoft Surface devices (Surface Pro 9 and Surface Laptop 5) the EFI ResetSystem call with EFI_RESET_SHUTDOWN doesn't function properly. Instead of shutting the system down, it returns and the system stays on. It turns out that this only happens after PCI shutdown callbacks ran for specific devices. Excluding those devices from the shutdown process makes the ResetSystem call work as expected. TODO: Maybe we can find a better way or the root cause of this? Not-Signed-off-by: Maximilian Luz <luzmaximilian@gmail.com> Patchset: surface-shutdown [Mingcong Bai: Resolved a minor merge conflict in drivers/pci/quirks.c.] Link: linux-surface/linux-surface@91786c3 Signed-off-by: Mingcong Bai <jeffbai@aosc.io> (cherry picked from commit 338c1feda509da0b5ad92ccbf98d67a64d32577d) Signed-off-by: Wentao Guan <guanwentao@uniontech.com> Conflicts: drivers/pci/quirks.c
Add the lid GPE used by the Surface Pro 9. Signed-off-by: Maximilian Luz <luzmaximilian@gmail.com> Patchset: surface-gpe Link: linux-surface/linux-surface@91786c3 Signed-off-by: Mingcong Bai <jeffbai@aosc.io> (cherry picked from commit a767dfa17d478fe69f09b3dae70569f9937720b2) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
…n INT3472 device The clk and regulator frameworks expect clk/regulator consumer-devices to have info about the consumed clks/regulators described in the device's fw_node. To work around cases where this info is not present in the firmware tables, which is often the case on x86/ACPI devices, both frameworks allow the provider-driver to attach info about consumers to the clks/regulators when registering these. This causes problems with the probe ordering wrt drivers for consumers of these clks/regulators. Since the lookups are only registered when the provider-driver binds, trying to get these clks/regulators before then results in a -ENOENT error for clks and a dummy regulator for regulators. One case where we hit this issue is camera sensors such as e.g. the OV8865 sensor found on the Microsoft Surface Go. The sensor uses clks, regulators and GPIOs provided by a TPS68470 PMIC which is described in an INT3472 ACPI device. There is special platform code handling this and setting platform_data with the necessary consumer info on the MFD cells instantiated for the PMIC under: drivers/platform/x86/intel/int3472. For this to work properly the ov8865 driver must not bind to the I2C-client for the OV8865 sensor until after the TPS68470 PMIC gpio, regulator and clk MFD cells have all been fully setup. The OV8865 on the Microsoft Surface Go is just one example, all X86 devices using the Intel IPU3 camera block found on recent Intel SoCs have similar issues where there is an INT3472 HID ACPI-device, which describes the clks and regulators, and the driver for this INT3472 device must be fully initialized before the sensor driver (any sensor driver) binds for things to work properly. On these devices the ACPI nodes describing the sensors all have a _DEP dependency on the matching INT3472 ACPI device (there is one per sensor). This allows solving the probe-ordering problem by delaying the enumeration (instantiation of the I2C-client in the ov8865 example) of ACPI-devices which have a _DEP dependency on an INT3472 device. The new acpi_dev_ready_for_enumeration() helper used for this is also exported because for devices, which have the enumeration_by_parent flag set, the parent-driver will do its own scan of child ACPI devices and it will try to enumerate those during its probe(). Code doing this such as e.g. the i2c-core-acpi.c code must call this new helper to ensure that it too delays the enumeration until all the _DEP dependencies are met on devices which have the new honor_deps flag set. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Patchset: cameras Link: linux-surface/linux-surface@91786c3 Signed-off-by: Mingcong Bai <jeffbai@aosc.io> (cherry picked from commit 23fd4dd3d86c127050b9d51d3347dc7126d90b25) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
…ntel IPUs Intel IPU(Image Processing Unit) has its own (IO)MMU hardware, The IPU driver allocates its own page table that is not mapped via the DMA, and thus the Intel IOMMU driver blocks access giving this error: DMAR: DRHD: handling fault status reg 3 DMAR: [DMA Read] Request device [00:05.0] PASID ffffffff fault addr 76406000 [fault reason 06] PTE Read access is not set As IPU is not an external facing device which is not risky, so use IOMMU passthrough mode for Intel IPUs. Change-Id: I6dcccdadac308cf42e20a18e1b593381391e3e6b Depends-On: Iacd67578e8c6a9b9ac73285f52b4081b72fb68a6 Tracked-On: #JIITL8-411 Signed-off-by: Bingbu Cao <bingbu.cao@intel.com> Signed-off-by: zouxiaoh <xiaohong.zou@intel.com> Signed-off-by: Xu Chongyang <chongyang.xu@intel.com> Patchset: cameras [Mingcong Bai: Resolved a minor merge conflict in drivers/iommu/intel/iommu.c.] Link: linux-surface/linux-surface@91786c3 Signed-off-by: Mingcong Bai <jeffbai@aosc.io> (cherry picked from commit a6063ea18b67a0bfddab7c12c0a0978f7e04ce40) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
The TPS68470 PMIC has an I2C passthrough mode through which I2C traffic can be forwarded to a device connected to the PMIC as though it were connected directly to the system bus. Enable this mode when the chip is initialised. Signed-off-by: Daniel Scally <djrscally@gmail.com> Patchset: cameras Link: linux-surface/linux-surface@91786c3 Signed-off-by: Mingcong Bai <jeffbai@aosc.io> (cherry picked from commit 955d8c6c36e05884ff162e0004db5418fadc8b71) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
Update the control ID for the gain control in the ov7251 driver to V4L2_CID_ANALOGUE_GAIN. Signed-off-by: Daniel Scally <dan.scally@ideasonboard.com> Patchset: cameras Link: linux-surface/linux-surface@91786c3 Signed-off-by: Mingcong Bai <jeffbai@aosc.io> (cherry picked from commit 9ec4aeed3f7800f8d2c14135c8c7c6aa707e38d9) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
…_subdev() The current call to v4l2_subdev_get_privacy_led() is contained in v4l2_async_register_subdev_sensor(), but that function isn't used by all the sensor drivers. Move the acquisition of the privacy led to v4l2_async_register_subdev() instead. Signed-off-by: Daniel Scally <dan.scally@ideasonboard.com> Patchset: cameras Link: linux-surface/linux-surface@91786c3 Signed-off-by: Mingcong Bai <jeffbai@aosc.io> (cherry picked from commit 99e8efdef65492e79854d86924677d60557a7e3c) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
Add MFD cell for tps68470-led. Reviewed-by: Daniel Scally <dan.scally@ideasonboard.com> Signed-off-by: Kate Hsuan <hpa@redhat.com> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Patchset: cameras Link: linux-surface/linux-surface@91786c3 Signed-off-by: Mingcong Bai <jeffbai@aosc.io> (cherry picked from commit 0ef6f1d99a19b1e6c70831028cf68c2e7417f5d9) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
Add flags for both LEDA(TPS68470_ILEDCTL_ENA), LEDB (TPS68470_ILEDCTL_ENB), and current control mask for LEDB (TPS68470_ILEDCTL_CTRLB) Reviewed-by: Daniel Scally <dan.scally@ideasonboard.com> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Kate Hsuan <hpa@redhat.com> Patchset: cameras Link: linux-surface/linux-surface@91786c3 Signed-off-by: Mingcong Bai <jeffbai@aosc.io> (cherry picked from commit 0d7b9b3d3827e79fe53d798375ff98237e36792b) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
There are two LED controllers, LEDA indicator LED and LEDB flash LED for tps68470. LEDA can be enabled by setting TPS68470_ILEDCTL_ENA. Moreover, tps68470 provides four levels of power status for LEDB. If the properties called "ti,ledb-current" can be found, the current will be set according to the property values. These two LEDs can be controlled through the LED class of sysfs (tps68470-leda and tps68470-ledb). Signed-off-by: Kate Hsuan <hpa@redhat.com> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Patchset: cameras Link: linux-surface/linux-surface@91786c3 Signed-off-by: Mingcong Bai <jeffbai@aosc.io> (cherry picked from commit 36f2d3f1b3d76a110a136bb5869bfff64163eadd) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
On surface go 2, sometimes probing dw9719 fails with "dw9719: probe of i2c-INT347A:00-VCM failed with error -121". The -121(-EREMOTEIO) is came from drivers/i2c/busses/i2c-designware-common.c:575, and indicates the initialize occurs too early. So just add some delay. There is no exact reason for this 10000us, but 100us failed. Patchset: cameras Link: linux-surface/linux-surface@91786c3 Signed-off-by: Mingcong Bai <jeffbai@aosc.io> (cherry picked from commit 6d3ac4de40d057d6471d6cd701fb9cf3359ef496) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
This patch is the work of Thomas Gleixner <tglx@linutronix.de> and is copied from: https://lore.kernel.org/lkml/87lf8ddjqx.ffs@nanos.tec.linutronix.de/ This patch adds a quirk to the ACPI setup to patch in the the irq 7 pin setup that is missing in the laptops ACPI table. This patch was used for validation of the issue, and is not a proper fix, but is probably a better temporary hack than continuing to probe the Legacy PIC and run with the PIC in an unknown state. Patchset: amd-gpio Link: linux-surface/linux-surface@91786c3 Signed-off-by: Mingcong Bai <jeffbai@aosc.io> (cherry picked from commit 0ef2abe9b2779b8f2f4f27325246bd23d7cd67e0) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
…uirk The 13" version of the Surface Laptop 4 has the same problem as the 15" version, but uses a different SKU. Add that SKU to the quirk as well. Patchset: amd-gpio Link: linux-surface/linux-surface@91786c3 Signed-off-by: Mingcong Bai <jeffbai@aosc.io> (cherry picked from commit 5a5c235bac8d7ec6c6981994fea02acd345a1fe5) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
On LoongArch, radeon causes a memory read violation that crashes radeonsi_dri.so (and all processes that loaded this module). When using amdgpu, this issue does not occur. The upstream maintainers are likely not going to accept this change as the default drivers were set since long ago, and we do not have enough proof to show that this change is worth merging. Signed-off-by: Mingcong Bai <jeffbai@aosc.io> Link: https://t.me/c/1109254909/477558 Signed-off-by: Kexy Biscuit <kexybiscuit@aosc.io> Signed-off-by: Mingcong Bai <jeffbai@aosc.io> (cherry picked from commit f7082f60edff70614e0cad6b4de3299290bb09da) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
…ocation"
When this change was introduced between v6.10.4 and v6.10.5, the Broadcom
Tigon3 Ethernet interface (tg3) found on Apple MacBook Pro (15'',
Mid 2010) would throw many rcu stall errors during boot up, causing
peripherals such as the wireless card to misbehave.
[ 24.153855] rcu: INFO: rcu_preempt detected expedited stalls on CPUs/tasks: { 2-.... } 21 jiffies s: 973 root: 0x4/.
[ 24.166938] rcu: blocking rcu_node structures (internal RCU debug):
[ 24.177800] Sending NMI from CPU 3 to CPUs 2:
[ 24.183113] NMI backtrace for cpu 2
[ 24.183119] CPU: 2 PID: 1049 Comm: NetworkManager Not tainted 6.10.5-aosc-main #1
[ 24.183123] Hardware name: Apple Inc. MacBookPro6,2/Mac-F22586C8, BIOS MBP61.88Z.005D.B00.1804100943 04/10/18
[ 24.183125] RIP: 0010:__this_module+0x2d3d1/0x4f310 [tg3]
[ 24.183135] Code: c3 cc cc cc cc 0f 1f 40 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 0f 1f 44 00 00 89 f6 48 03 77 30 8b 06 <31> f6 31 ff c3 cc cc cc cc 66 0f 1f 44 00 00 90 90 90 90 90 90 90
[ 24.183138] RSP: 0018:ffffbf1a011d75e8 EFLAGS: 00000082
[ 24.183141] RAX: 0000000000000000 RBX: ffffa04ec78f8a00 RCX: 0000000000000000
[ 24.183143] RDX: 0000000000000000 RSI: ffffbf1a00fb007c RDI: ffffa04ec78f8a00
[ 24.183145] RBP: 0000000000000b50 R08: 0000000000000000 R09: 0000000000000000
[ 24.183147] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000216
[ 24.183148] R13: ffffbf1a011d7624 R14: ffffa04ec78f8a08 R15: ffffa04ec78f8b40
[ 24.183151] FS: 00007f4c524b2140(0000) GS:ffffa05007d00000(0000) knlGS:0000000000000000
[ 24.183153] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 24.183155] CR2: 00007f7025eae3e8 CR3: 00000001040f8000 CR4: 00000000000006f0
[ 24.183157] Call Trace:
[ 24.183162] <NMI>
[ 24.183167] ? nmi_cpu_backtrace+0xbf/0x140
[ 24.183175] ? nmi_cpu_backtrace_handler+0x11/0x20
[ 24.183181] ? nmi_handle+0x61/0x160
[ 24.183186] ? default_do_nmi+0x42/0x110
[ 24.183191] ? exc_nmi+0x1bd/0x290
[ 24.183194] ? end_repeat_nmi+0xf/0x53
[ 24.183203] ? __this_module+0x2d3d1/0x4f310 [tg3]
[ 24.183207] ? __this_module+0x2d3d1/0x4f310 [tg3]
[ 24.183210] ? __this_module+0x2d3d1/0x4f310 [tg3]
[ 24.183213] </NMI>
[ 24.183214] <TASK>
[ 24.183215] __this_module+0x31828/0x4f310 [tg3]
[ 24.183218] ? __this_module+0x2d390/0x4f310 [tg3]
[ 24.183221] __this_module+0x398e6/0x4f310 [tg3]
[ 24.183225] __this_module+0x3baf8/0x4f310 [tg3]
[ 24.183229] __this_module+0x4733f/0x4f310 [tg3]
[ 24.183233] ? _raw_spin_unlock_irqrestore+0x25/0x70
[ 24.183237] ? __this_module+0x398e6/0x4f310 [tg3]
[ 24.183241] __this_module+0x4b943/0x4f310 [tg3]
[ 24.183244] ? delay_tsc+0x89/0xf0
[ 24.183249] ? preempt_count_sub+0x51/0x60
[ 24.183254] __this_module+0x4be4b/0x4f310 [tg3]
[ 24.183258] __dev_open+0x103/0x1c0
[ 24.183265] __dev_change_flags+0x1bd/0x230
[ 24.183269] ? rtnl_getlink+0x362/0x400
[ 24.183276] dev_change_flags+0x26/0x70
[ 24.183280] do_setlink+0xe16/0x11f0
[ 24.183286] ? __nla_validate_parse+0x61/0xd40
[ 24.183295] __rtnl_newlink+0x63d/0x9f0
[ 24.183301] ? kmem_cache_alloc_node_noprof+0x12b/0x360
[ 24.183308] ? kmalloc_trace_noprof+0x11e/0x350
[ 24.183312] ? rtnl_newlink+0x2e/0x70
[ 24.183316] rtnl_newlink+0x47/0x70
[ 24.183320] rtnetlink_rcv_msg+0x152/0x400
[ 24.183324] ? __netlink_sendskb+0x68/0x90
[ 24.183329] ? netlink_unicast+0x237/0x290
[ 24.183333] ? __pfx_rtnetlink_rcv_msg+0x10/0x10
[ 24.183336] netlink_rcv_skb+0x5b/0x110
[ 24.183343] netlink_unicast+0x1a4/0x290
[ 24.183347] netlink_sendmsg+0x222/0x4a0
[ 24.183350] ? proc_get_long.constprop.0+0x116/0x210
[ 24.183358] ____sys_sendmsg+0x379/0x3b0
[ 24.183363] ? copy_msghdr_from_user+0x6d/0xb0
[ 24.183368] ___sys_sendmsg+0x86/0xe0
[ 24.183372] ? addrconf_sysctl_forward+0xf3/0x270
[ 24.183378] ? _copy_from_iter+0x8b/0x570
[ 24.183384] ? __pfx_addrconf_sysctl_forward+0x10/0x10
[ 24.183388] ? _raw_spin_unlock+0x19/0x50
[ 24.183392] ? proc_sys_call_handler+0xf3/0x2f0
[ 24.183397] ? trace_hardirqs_on+0x29/0x90
[ 24.183401] ? __fdget+0xc2/0xf0
[ 24.183405] __sys_sendmsg+0x5b/0xc0
[ 24.183410] ? syscall_trace_enter+0x110/0x1b0
[ 24.183416] do_syscall_64+0x64/0x150
[ 24.183423] entry_SYSCALL_64_after_hwframe+0x76/0x7e
I have bisected the error to this commit. Reverting it caused no new or
perceivable issues on both the MacBook and a Zen4-based laptop. Revert
this commit as a workaround.
This reverts commit aa162aa4aa383a0a714b1c36e8fcc77612ddd1a2.
Upstream report: https://bugzilla.kernel.org/show_bug.cgi?id=219390
Signed-off-by: Mingcong Bai <jeffbai@aosc.io>
Bug: https://lore.kernel.org/all/b8da4aec-4cca-4eb0-ba87-5f8641aa2ca9@leemhuis.info/
Signed-off-by: Kexy Biscuit <kexybiscuit@aosc.io>
Signed-off-by: Mingcong Bai <jeffbai@aosc.io>
(cherry picked from commit 7f25237f15da1e0a469fcf3e27be202dc74444aa)
Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
The loongson DRM driver is known to cause boot failure or hang on certain LS7A1000-based hardware. Add a switch (`loongson.ls7a1000_support', disabled by default to help users of LS7A2000/2K2000-based hardware leverage the loongson DRM driver. For those who feel adventurous, use the `loongson.ls7a1000_support=1' parameter to enable this driver. Signed-off-by: Mingcong Bai <jeffbai@aosc.io> Link: https://t.me/c/1109254909/605851 Signed-off-by: Kexy Biscuit <kexybiscuit@aosc.io> Signed-off-by: Mingcong Bai <jeffbai@aosc.io> (cherry picked from commit d1503d83a088a0a2c78bbfab85a07ccfd606a5db) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
Similar to 3a057bf ("platform/x86: hp-wmi: Add thermal profile support for 8BAD boards"), the HP OMEN 9 2023 (8BAB) board (China-specific model) should also be added to the list of boards handled by the OMEN thermal profiles. Signed-off-by: Mingcong Bai <jeffbai@aosc.io> Link: https://t.me/c/1109254909/613200 Signed-off-by: Kexy Biscuit <kexybiscuit@aosc.io> Signed-off-by: Mingcong Bai <jeffbai@aosc.io> (cherry picked from commit 0330de200f255990eafb4c6d548cf3e09d622b0c) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
…efault Per report from a contributor, since v6.9, ABM was set to be automatically enabled/disabled. It may have seemed like a good idea for brighter screens, but the brightness adjustment is quite abrupt, which is quite bothersome. Disable this feature by default for now. Signed-off-by: Mingcong Bai <jeffbai@aosc.io> Link: https://t.me/c/1109254909/594612 Signed-off-by: Kexy Biscuit <kexybiscuit@aosc.io> Signed-off-by: Mingcong Bai <jeffbai@aosc.io> (cherry picked from commit 3537da5b0e0938ac2dee9b71c84510b80dd86ddb) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
The V2 files were never actually compiled: SPI_PHYTIUM_V2 and SPI_PHYTIUM_PLAT_V2 depend on ARCH_PHYTIUM, which is unset on every build of this tree, so the Kconfig symbols were silently dropped and the stale pre-6.x API usage went unnoticed. Adapt the code so it builds against 6.18: - s/spi_master/spi_controller/ for the alloc, devdata, register and put helpers (spi_alloc_host, spi_controller_get/set_devdata, devm_spi_register_controller, spi_controller_put) and spi->master -> spi->controller - from_timer() no longer exists; use timer_container_of(), and del_timer_sync() is now timer_delete_sync() - the legacy of_get_named_gpio()/devm_gpio_request() OF path is gone; request the chip-select lines through the gpiod API for both DT and ACPI firmware, matching what the SPI core expects, and drop the now unused fts->cs array - add missing prototypes by making the file-local helpers static and remove the unused ones (spi_phytium_data_subid, spi_phyt_enable_debug) - drop the dead asm/memory.h and linux/of_gpio.h includes - allow COMPILE_TEST for SPI_PHYTIUM_PLAT_V2 so the files keep compiling on other architectures Fixes: b4cb017 ("spi-v2: phytium: Add the debug log function to the driver") Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
After issuing SPINOR_OP_CHIP_ERASE to the firmware, execution fell through to the generic TX path, which sent the same opcode a second time — a duplicate flash operation. The return value of spi_phytium_flash_erase() was also ignored and the flash_erase state was committed even on failure. Return right after the erase command and only update the state flags on success, propagating the error otherwise. Fixes: b127bad ("spi-v2: phytium: Adapt the mcp251x device") Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
The alive watchdog timer handler rearmed itself unconditionally every 10 ms even though alive_enabled defaults to false, causing 100 unnecessary wakeups per second per controller indefinitely. The add_host and resume paths also armed the timer unconditionally. Rearm only while alive monitoring is enabled, and start the timer from the sysfs enable path when alive monitoring transitions to enabled. Fixes: b4cb017 ("spi-v2: phytium: Add the debug log function to the driver") Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
When hw_pos == appl_pos, gf_update_stream() copied the entire PCM buffer — up to 7 MiB — to the framebuffer MMIO mapping. The function runs from the PCM pointer callback, which can be invoked from the period/IRQ path, so a caught-up or underrun stream caused extreme interrupt latency and repeatedly copied an empty buffer. Drop the full-copy branch: the pointer callback now only moves the newly committed range (appl_pos advance), and the full refresh remains in gf_pre_trigger() when the stream starts. Fixes: 86858d4 ("add gf hdaudio 001 patch in deepin kernel 6.6") Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
The DMA completion wait returned success even when the controller error IRQ had already set cur_msg->status to -EIO via phytium_spi_check_status(). The chunked transfer path then submitted another DMA chunk after the controller was reset, corrupting state. Check cur_msg->status after the completion fires and propagate the error so the transfer stops and handle_err terminates outstanding DMA. Fixes: caf2f8f ("arm64: spi: add Phytium SPI controller support") Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
The v2 probe unconditionally requires resource 0 (register file) and resource 1 (shared memory), but the schema allowed a single reg range for phytium,spi-2.0 — a v2 DT with one range validated and then always failed probing. Add a per-compatible conditional: require exactly two reg ranges for phytium,spi-2.0, keeping one for the v1 compatible. Fixes: caf2f8f ("arm64: spi: add Phytium SPI controller support") Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
spi_phyt_add_host() allocated the controller with spi_alloc_host() (non-devm) but registered it with devm_spi_register_controller(). The devres cleanup only unregisters the controller; it does not drop the initial reference taken by the allocation, so every successful unbind leaked the controller. The managed registration also ordered teardown wrongly: the devres unregister action only runs after the platform .remove callback has returned, but spi_phyt_remove_host() shuts the chip down inside .remove — leaving child devices and the transfer queue registered against hardware that is already disabled. Switch to devm_spi_alloc_host() so the initial reference is managed, register explicitly with spi_register_controller(), and make spi_phyt_remove_host() unregister the controller before stopping the hardware, matching the V1 driver. Fixes: b4cb017 ("spi-v2: phytium: Add the debug log function to the driver") Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
phytium_spi_add_host() allocates the controller with spi_alloc_host(), which takes an initial reference, but phytium_spi_remove_host() only calls spi_unregister_controller(). That function does device_del() without put_device(), so the initial reference is never released and the controller allocation leaks on every unbind. Add spi_controller_put() after spi_unregister_controller() to drop the reference. Fixes: caf2f8f ("arm64: spi: add Phytium SPI controller support") Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
spi_phytium_set_cmd8/16/32() discarded the return value of spi_phytium_check_result(), so their setup callers returned success even when a firmware command timed out or reported an error, leaving the controller partially configured. Change these helpers to return int and propagate the check_result status everywhere: - spi_phyt_setup() aborts on the first failed command (chip disable, clock setting, DATA_WIDTH/MODE/TMOD, final chip enable); - the spi_phyt_enable_chip()/set_clk()/dma_reset()/global_cs() wrappers return int instead of discarding the result; - spi_phyt_resume_host() propagates failures from the chip disable, clock setting and re-enable sequence. Fixes: b4cb017 ("spi-v2: phytium: Add the debug log function to the driver") Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
…rate phytium_spi_dma_wait_rx_done() computed the poll delay as 4U * NSEC_PER_SEC / fts->max_freq * nents without guarding the division. fts->max_freq is 0 when the clock is unconfigured or the ACPI "spi-clock" property is absent, so the FIFO drain on the DMA error-recovery path divided by zero and crashed. Use max_t(u32, fts->max_freq, 1) as the divisor, mirroring the guard already present in phytium_spi_dma_wait_tx_done(). Fixes: 3674931 ("arm64: spi: Phytium: Adapt SPI driver to use DDMA interface") Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
Two stack buffer overflows in the firmware command helpers: - spi_phytium_flash_erase() copied len bytes (the full remaining transfer length) into cmd_addr[1..7], which holds only 7 bytes, and then read len + 1 bytes back from the 8-byte buffer, past its end. A malformed or oversized client transfer longer than 7 bytes corrupted the stack. - spi_phytium_flash_write() copied fts->len bytes into cmd_addr[2..7], 6 bytes of space, with no bound. cmd_addr[0] also assigned the size_t length to a u8 byte, silently truncating it. Cap the copies to the buffer space in both functions and make the u8 length conversion explicit. Also fix the unaligned u64 dereference in memcpy_byte(): its callers pass &cmd_addr[1]/&cmd_addr[2], which are not 8-byte aligned; use get_unaligned()/put_unaligned() so the helper is safe on strict-alignment architectures. Fixes: b4cb017 ("spi-v2: phytium: Add the debug log function to the driver") Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
The capacity registers need each flash's size, which comes from the spi-nor driver bound to the child. When MTD_SPI_NOR is a module that has not loaded yet, the children exist but no driver is bound, so the sizes stay zero and the capacity encoding cannot be programmed. Register a bus notifier and program the capacity when spi-nor binds. SPI children are parented by the controller device, so filter notifications against &qspi->ctrl->dev rather than the platform device. This keeps the controller independent of spi-nor module load order. Fixes: 9f2e218 ("arm64: spi: Phytium-qspi: Add support for Phytium QSPI controller") Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
…ware down phytium_qspi_remove() disabled the clock first, while the controller was registered through devm_spi_register_controller(): the devres unregister action only runs after the platform .remove callback returns, so child devices and the transfer queue stayed registered against dead hardware for that window. The deferred-probe error path added for spi-nor load ordering has the same inverted teardown. Register explicitly with spi_register_controller() and unregister the controller before disabling the clock, both in .remove and on the post-registration failure paths. Fixes: 9f2e218 ("arm64: spi: Phytium-qspi: Add support for Phytium QSPI controller") Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
The parser treated any child of the flash device as proof that a dedicated partition layout was present, then iterated only the master's direct children. A conventional "partitions" container node therefore failed parsing: it has no offset/length of its own, so in dedicated mode it triggered -EINVAL, and its partition children were never visited. An unrelated child node (e.g. a GPIO consumer) likewise switched the parser into strict dedicated mode by mistake. Descend into a "partitions" subnode when present, mirroring the OF parser: the container enables dedicated mode and its children are the partitions. Without the container, keep parsing the direct subnodes leniently. Fixes: 7f4fb2e ("arm64: phytium: UEFI mode acpi table support for qspi/spi driver") Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
The driver provides runtime suspend and resume callbacks, but never sets AZX_DCAPS_PM_RUNTIME or enables runtime PM. Consequently the callbacks are unreachable and the controller remains active even after all codecs enter D3. Enable runtime PM and hold the controller active while the asynchronous probe accesses its registers. Allow codecs to use the configured power-save delay so the parent controller can stop its command engine and place the link in reset once every codec is idle. Use the same callbacks for system sleep and balance runtime PM during probe failure, removal and shutdown. Also quiesce and synchronize the deferred stream IRQ work before entering link reset. Fixes: 8da93e4 ("hda: phytium: Add Phytium hda driver support") Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
To trade off between powersave and performace. Enable it for more powersave. It can be turn off by kernel boot cmdline through grub/systemdboot. Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
The rcu lazy callbacks enabled by "deepin: x86: enable rcu lazy by default" take effect only on rcu_nocbs CPUs, that is, on the CPUs whose callbacks have been offloaded, so they cover no CPU unless the rcu_nocbs=all boot cmdline is passed. Enable CONFIG_RCU_NOCB_CPU_DEFAULT_ALL to offload the callbacks of all CPUs by default, so that rcu lazy works with the default boot cmdline, and the rcu_nocbs boot parameter still takes precedence when specified. Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
Since commit 9dfd13f ("cpufreq/amd-pstate: Toggle auto_sel in active mode on shared memory systems"), shmem_init_perf() programs AUTONOMOUS_SELECTION_ENABLE unconditionally, including in active mode. Platforms that exclusively support autonomous selection report this field as an Integer of 1, as required by the ACPI specification, instead of as a register descriptor. cppc_get_reg_val() reads such a field back successfully, but cppc_set_reg_val() rejects the write with -EOPNOTSUPP because the entry is not an ACPI_TYPE_BUFFER. shmem_init_perf() propagates that error, so every amd_pstate_epp_cpu_init() fails, cpufreq_register_driver() ends up with an empty policy list and returns -ENODEV, and amd-pstate refuses to load at all: amd_pstate: failed to set auto_sel, ret: -95 amd_pstate: Failed to initialize CPU 0: -95 ... amd_pstate: failed to register with return -19 Skip the write when the register already holds the value the requested mode needs. Active and guided mode are fixed on these platforms, which report auto_sel as 1, while passive mode still fails to load on a platform that cannot disable autonomous selection, exactly as it did before the offending commit. Fixes: 9dfd13f ("cpufreq/amd-pstate: Toggle auto_sel in active mode on shared memory systems") Cc: stable@vger.kernel.org Reviewed-by: K Prateek Nayak <kprateek.nayak@amd.com> Tested-by: K Prateek Nayak <kprateek.nayak@amd.com> Tested-by: LFRon <ronforever@outlook.com> Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
deepin inclusion category: bugfix phytium_get_mac_mode() only reads the Phytium-specific "mac-mode" property. Commit fb7c537 ("BACKPORT: PHYTIUM: drivers: fix build errors") dropped the device_get_phy_mode() call, so platforms whose firmware only provides the standard "phy-mode"/"phy-connection-type" property (e.g. PHYT0004 ACPI devices) end up with plat->phy_interface set to a negative error code. stmmac_phy_setup() then uses that invalid value to fill phylink_config.supported_interfaces, leaving the bitmap empty, and phylink_create() rejects it with -EINVAL: (null): phylink: error: empty supported_interfaces phytium-dwmac PHYT0004:00: failed to setup phy (-22) Try "mac-mode" first to keep the existing Phytium-specific override, fall back to the standard "phy-mode" via device_get_phy_mode(), and fail the probe with a clear message when neither property exists. Fixes: fb7c537 ("BACKPORT: PHYTIUM: drivers: fix build errors") Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
deepin inclusion category: bugfix plat->phy_interface has type phy_interface_t, an enum whose values are all non-negative, which GCC treats as unsigned int. The "< 0" error checks added by commit eae94a7 are therefore always false, and -O2 eliminates both the device_get_phy_mode() fallback and the dev_err_probe() return as dead code, while -Wno-type-limits hides the warning. The built dwmac-phytium.o ends up functionally identical to the unfixed driver (no device_get_phy_mode reference in the object), so PHYT0004 platforms still fail to probe with: (null): phylink: error: empty supported_interfaces phytium-dwmac PHYT0004:00: failed to setup phy (-22) Worse, on that failure path the negative error code is stored into the unsigned field (e.g. -EINVAL becomes 0xFFFFFFEA) and is later used as a bit index by __set_bit() in stmmac_phy_setup(), silently corrupting kernel memory far past the supported_interfaces bitmap. Carry the lookup result in a local int and only assign to plat->phy_interface once a valid mode is known, matching how dwmac-loongson and stmmac_platform handle device_get_phy_mode(). Fixes: eae94a7 ("net: stmmac: phytium: fall back to standard \"phy-mode\" property") Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
They are so special and not be selected in arch config, remove them to save space and improve performance. Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
![sourcery-ai[bot]](https://avatars.githubusercontent.com/in/48477?s=60&v=4){kind=small}
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
|
The following users are mentioned in OWNERS file(s) but are untrusted for the following reasons. One way to make the user trusted is to add them as members of the deepin-community org. You can then trigger verification by writing
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
20 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No description provided.