- Kernel - mailweb.openeuler.org

【Meeting Notice】openEuler kernel sig meeting Time: 2021-04-02 14:00-16:00
by Meeting Book 30 Mar '21

30 Mar '21

2 1

[PATCH kernel-4.19 v2] USB:Fix kernel NULL pointer when unbind UHCI form vfio-pci
by LeoLiuoc 29 Mar '21

29 Mar '21

This bug is found in Zhaoxin platform, but it's a commom code bug. Fail sequence: step1: Unbind UHCI controller from native driver; step2: Bind UHCI controller to vfio-pci, which will put UHCI controller in one vfio group's device list and set UHCI's dev->driver_data to struct vfio-pci(for UHCI) step3: Unbind EHCI controller from native driver, will try to tell UHCI native driver that "I'm removed by set companion_hcd->self.hs_companion to NULL. However, companion_hcd get from UHCI's dev->driver_data that has modified by vfio-pci already.So, the vfio-pci structure will be damaged! step4: Bind EHCI controller to vfio-pci driver, which will put EHCI controller in the same vfio group as UHCI controller; ... ... step5: Unbind UHCI controller from vfio-pci, which will delete UHCI from vfio group' device list that has been damaged in step 3. So,delete operation can random result into a NULL pointer dereference with the below stack dump. step6: Bind UHCI controller to native driver; step7: Unbind EHCI controller from vfio-pci, which will try to remove EHCI controller from the vfio group; step8: Bind EHCI controller to native driver; [ 929.114641] uhci_hcd 0000:00:10.0: remove, state 1 [ 929.114652] usb usb1: USB disconnect, device number 1 [ 929.114655] usb 1-1: USB disconnect, device number 2 [ 929.270313] usb 1-2: USB disconnect, device number 3 [ 929.318404] uhci_hcd 0000:00:10.0: USB bus 1 deregistered [ 929.343029] uhci_hcd 0000:00:10.1: remove, state 4 [ 929.343045] usb usb3: USB disconnect, device number 1 [ 929.343685] uhci_hcd 0000:00:10.1: USB bus 3 deregistered [ 929.369087] ehci-pci 0000:00:10.7: remove, state 4 [ 929.369102] usb usb4: USB disconnect, device number 1 [ 929.370325] ehci-pci 0000:00:10.7: USB bus 4 deregistered [ 932.398494] BUG: unable to handle kernel NULL pointer dereference at 0000000000000000 [ 932.398496] PGD 42a67d067 P4D 42a67d067 PUD 42a65f067 PMD 0 [ 932.398502] Oops: 0002 [#2] SMP NOPTI [ 932.398505] CPU: 2 PID: 7824 Comm: vfio_unbind.sh Tainted: P D 4.19.65-2020051917-rainos #1 [ 932.398506] Hardware name: Shanghai Zhaoxin Semiconductor Co., Ltd. HX002EH/HX002EH, BIOS HX002EH0_01_R480_R_200408 04/08/2020 [ 932.398513] RIP: 0010:vfio_device_put+0x31/0xa0 [vfio] [ 932.398515] Code: 89 e5 41 54 53 4c 8b 67 18 48 89 fb 49 8d 74 24 30 e8 e3 0e f3 de 84 c0 74 67 48 8b 53 20 48 8b 43 28 48 8b 7b 18 48 89 42 08 <48> 89 10 48 b8 00 01 00 00 00 00 ad de 48 89 43 20 48 b8 00 02 00 [ 932.398516] RSP: 0018:ffffbbfd04cffc18 EFLAGS: 00010202 [ 932.398518] RAX: 0000000000000000 RBX: ffff92c7ea717880 RCX: 0000000000000000 [ 932.398519] RDX: ffff92c7ea713620 RSI: ffff92c7ea713630 RDI: ffff92c7ea713600 [ 932.398521] RBP: ffffbbfd04cffc28 R08: ffff92c7f02a8080 R09: ffff92c7efc03980 [ 932.398522] R10: ffffbbfd04cff9a8 R11: 0000000000000000 R12: ffff92c7ea713600 [ 932.398523] R13: ffff92c7ed8bb0a8 R14: ffff92c7ea717880 R15: 0000000000000000 [ 932.398525] FS: 00007f3031500740(0000) GS:ffff92c7f0280000(0000) knlGS:0000000000000000 [ 932.398526] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 932.398527] CR2: 0000000000000000 CR3: 0000000428626004 CR4: 0000000000160ee0 [ 932.398528] Call Trace: [ 932.398534] vfio_del_group_dev+0xe8/0x2a0 [vfio] [ 932.398539] ? __blocking_notifier_call_chain+0x52/0x60 [ 932.398542] ? do_wait_intr_irq+0x90/0x90 [ 932.398546] ? iommu_bus_notifier+0x75/0x100 [ 932.398551] vfio_pci_remove+0x20/0xa0 [vfio_pci] [ 932.398554] pci_device_remove+0x3e/0xc0 [ 932.398557] device_release_driver_internal+0x17a/0x240 [ 932.398560] device_release_driver+0x12/0x20 [ 932.398561] unbind_store+0xee/0x180 [ 932.398564] drv_attr_store+0x27/0x40 [ 932.398567] sysfs_kf_write+0x3c/0x50 [ 932.398568] kernfs_fop_write+0x125/0x1a0 [ 932.398572] __vfs_write+0x3a/0x190 [ 932.398575] ? apparmor_file_permission+0x1a/0x20 [ 932.398577] ? security_file_permission+0x3b/0xc0 [ 932.398581] ? _cond_resched+0x1a/0x50 [ 932.398582] vfs_write+0xb8/0x1b0 [ 932.398584] ksys_write+0x5c/0xe0 [ 932.398586] __x64_sys_write+0x1a/0x20 [ 932.398589] do_syscall_64+0x5a/0x110 [ 932.398592] entry_SYSCALL_64_after_hwframe+0x44/0xa9 Using virt-manager/qemu to boot guest os, we can see the same fail sequence! Fix this by determine whether the PCI Driver of the USB controller is a kernel native driver. If not, do not let it modify UHCI's dev->driver_data. Signed-off-by: LeoLiu-oc <LeoLiu-oc(a)zhaoxin.com> --- drivers/usb/core/hcd-pci.c | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/drivers/usb/core/hcd-pci.c b/drivers/usb/core/hcd-pci.c index 7537681355f6..c3cddaab708d 100644 --- a/drivers/usb/core/hcd-pci.c +++ b/drivers/usb/core/hcd-pci.c @@ -49,6 +49,7 @@ static void for_each_companion(struct pci_dev *pdev, struct usb_hcd *hcd, struct pci_dev *companion; struct usb_hcd *companion_hcd; unsigned int slot = PCI_SLOT(pdev->devfn); + struct pci_driver *drv; /* * Iterate through other PCI functions in the same slot. @@ -61,6 +62,15 @@ static void for_each_companion(struct pci_dev *pdev, struct usb_hcd *hcd, PCI_SLOT(companion->devfn) != slot) continue; + drv = companion->driver; + if (!drv) + continue; + + if (strncmp(drv->name, "uhci_hcd", sizeof("uhci_hcd") - 1) && + strncmp(drv->name, "ooci_hcd", sizeof("uhci_hcd") - 1) && + strncmp(drv->name, "ehci_hcd", sizeof("uhci_hcd") - 1)) + continue; + /* * Companion device should be either UHCI,OHCI or EHCI host * controller, otherwise skip. -- 2.20.1

1 0

[PATCH kernel-4.19] xhci: fix issue with some USB device cannot recognize
by LeoLiu-oc 29 Mar '21

29 Mar '21

During polling phase after some device plug in type-c port, if polling timeout three times, link state will goto inactive. However this event not handle by the driver, which will cause device can't be recognized. To fix this issue, if port link state detected in inactive, record this event that will trigger a warm reset to bring device identified by driver. The patch is scheduled to be submitted to the kernel mainline in 2021. Signed-off-by: LeoLiu-oc <LeoLiu-oc(a)zhaoxin.com> --- drivers/usb/core/hub.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c index fa28f23a4a33..302caa1ea345 100644 --- a/drivers/usb/core/hub.c +++ b/drivers/usb/core/hub.c @@ -1135,6 +1135,11 @@ static void hub_activate(struct usb_hub *hub, enum hub_activation_type type) USB_SS_PORT_LS_POLLING)) need_debounce_delay = true; + /* Make sure a warm-reset request is handled by port_event */ + if (type == HUB_RESUME && + hub_port_warm_reset_required(hub, port1, portstatus)) + set_bit(port1, hub->event_bits); + /* Clear status-change flags; we'll debounce later */ if (portchange & USB_PORT_STAT_C_CONNECTION) { need_debounce_delay = true; -- 2.20.1

3 5

[PATCH kernel-4.19] arm64/mpam: fix a possible deadlock in mpam_enable
by Zhang Ming 29 Mar '21

29 Mar '21

openEuler inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I3D58V CVE: NA ---------------------------------- No unlock operation is performed on the mpam_devices_lock before the return statement, which may lead to a deadlock. Signed-off-by: Zhang Ming <154842638(a)qq.com> Reported-by: Jian Cheng <cj.chengjian(a)huawei.com> Suggested-by: Jian Cheng <cj.chengjian(a)huawei.com> --- arch/arm64/kernel/mpam/mpam_device.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/arch/arm64/kernel/mpam/mpam_device.c b/arch/arm64/kernel/mpam/mpam_device.c index fc7aa1ae0b82..c08ff933db5a 100644 --- a/arch/arm64/kernel/mpam/mpam_device.c +++ b/arch/arm64/kernel/mpam/mpam_device.c @@ -560,8 +560,10 @@ static void __init mpam_enable(struct work_struct *work) mutex_lock(&mpam_devices_lock); mpam_enable_squash_features(); err = mpam_allocate_config(); - if (err) + if (err) { + mutex_unlock(&mpam_devices_lock); return; + } mutex_unlock(&mpam_devices_lock); mpam_enable_irqs(); -- 2.25.1

4 3

订阅
by LeoLiuoc 29 Mar '21

29 Mar '21

2 1

help
by LeoLiuoc 29 Mar '21

29 Mar '21

help

1 0

[PATCH kernel-4.19] USB:Fix kernel NULL pointer when unbind UHCI form vfio-pci
by LeoLiu-oc 29 Mar '21

29 Mar '21

This bug is found in Zhaoxin platform, but it's a commom code bug. Fail sequence: step1: Unbind UHCI controller from native driver; step2: Bind UHCI controller to vfio-pci, which will put UHCI controller in one vfio group's device list and set UHCI's dev->driver_data to struct vfio-pci(for UHCI) step3: Unbind EHCI controller from native driver, will try to tell UHCI native driver that "I'm removed by set companion_hcd->self.hs_companion to NULL. However, companion_hcd get from UHCI's dev->driver_data that has modified by vfio-pci already.So, the vfio-pci structure will be damaged! step4: Bind EHCI controller to vfio-pci driver, which will put EHCI controller in the same vfio group as UHCI controller; ... ... step5: Unbind UHCI controller from vfio-pci, which will delete UHCI from vfio group' device list that has been damaged in step 3. So,delete operation can random result into a NULL pointer dereference with the below stack dump. step6: Bind UHCI controller to native driver; step7: Unbind EHCI controller from vfio-pci, which will try to remove EHCI controller from the vfio group; step8: Bind EHCI controller to native driver; [ 929.114641] uhci_hcd 0000:00:10.0: remove, state 1 [ 929.114652] usb usb1: USB disconnect, device number 1 [ 929.114655] usb 1-1: USB disconnect, device number 2 [ 929.270313] usb 1-2: USB disconnect, device number 3 [ 929.318404] uhci_hcd 0000:00:10.0: USB bus 1 deregistered [ 929.343029] uhci_hcd 0000:00:10.1: remove, state 4 [ 929.343045] usb usb3: USB disconnect, device number 1 [ 929.343685] uhci_hcd 0000:00:10.1: USB bus 3 deregistered [ 929.369087] ehci-pci 0000:00:10.7: remove, state 4 [ 929.369102] usb usb4: USB disconnect, device number 1 [ 929.370325] ehci-pci 0000:00:10.7: USB bus 4 deregistered [ 932.398494] BUG: unable to handle kernel NULL pointer dereference at 0000000000000000 [ 932.398496] PGD 42a67d067 P4D 42a67d067 PUD 42a65f067 PMD 0 [ 932.398502] Oops: 0002 [#2] SMP NOPTI [ 932.398505] CPU: 2 PID: 7824 Comm: vfio_unbind.sh Tainted: P D 4.19.65-2020051917-rainos #1 [ 932.398506] Hardware name: Shanghai Zhaoxin Semiconductor Co., Ltd. HX002EH/HX002EH, BIOS HX002EH0_01_R480_R_200408 04/08/2020 [ 932.398513] RIP: 0010:vfio_device_put+0x31/0xa0 [vfio] [ 932.398515] Code: 89 e5 41 54 53 4c 8b 67 18 48 89 fb 49 8d 74 24 30 e8 e3 0e f3 de 84 c0 74 67 48 8b 53 20 48 8b 43 28 48 8b 7b 18 48 89 42 08 <48> 89 10 48 b8 00 01 00 00 00 00 ad de 48 89 43 20 48 b8 00 02 00 [ 932.398516] RSP: 0018:ffffbbfd04cffc18 EFLAGS: 00010202 [ 932.398518] RAX: 0000000000000000 RBX: ffff92c7ea717880 RCX: 0000000000000000 [ 932.398519] RDX: ffff92c7ea713620 RSI: ffff92c7ea713630 RDI: ffff92c7ea713600 [ 932.398521] RBP: ffffbbfd04cffc28 R08: ffff92c7f02a8080 R09: ffff92c7efc03980 [ 932.398522] R10: ffffbbfd04cff9a8 R11: 0000000000000000 R12: ffff92c7ea713600 [ 932.398523] R13: ffff92c7ed8bb0a8 R14: ffff92c7ea717880 R15: 0000000000000000 [ 932.398525] FS: 00007f3031500740(0000) GS:ffff92c7f0280000(0000) knlGS:0000000000000000 [ 932.398526] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 932.398527] CR2: 0000000000000000 CR3: 0000000428626004 CR4: 0000000000160ee0 [ 932.398528] Call Trace: [ 932.398534] vfio_del_group_dev+0xe8/0x2a0 [vfio] [ 932.398539] ? __blocking_notifier_call_chain+0x52/0x60 [ 932.398542] ? do_wait_intr_irq+0x90/0x90 [ 932.398546] ? iommu_bus_notifier+0x75/0x100 [ 932.398551] vfio_pci_remove+0x20/0xa0 [vfio_pci] [ 932.398554] pci_device_remove+0x3e/0xc0 [ 932.398557] device_release_driver_internal+0x17a/0x240 [ 932.398560] device_release_driver+0x12/0x20 [ 932.398561] unbind_store+0xee/0x180 [ 932.398564] drv_attr_store+0x27/0x40 [ 932.398567] sysfs_kf_write+0x3c/0x50 [ 932.398568] kernfs_fop_write+0x125/0x1a0 [ 932.398572] __vfs_write+0x3a/0x190 [ 932.398575] ? apparmor_file_permission+0x1a/0x20 [ 932.398577] ? security_file_permission+0x3b/0xc0 [ 932.398581] ? _cond_resched+0x1a/0x50 [ 932.398582] vfs_write+0xb8/0x1b0 [ 932.398584] ksys_write+0x5c/0xe0 [ 932.398586] __x64_sys_write+0x1a/0x20 [ 932.398589] do_syscall_64+0x5a/0x110 [ 932.398592] entry_SYSCALL_64_after_hwframe+0x44/0xa9 Using virt-manager/qemu to boot guest os, we can see the same fail sequence! Fix this by check for UHCI driver loaded or not before modifiy UHCI's dev->driver_data, which will happen in ehci native driver probe/remove. This patch was submitted to mainline kernel but not accepted by upstream maintainer whose reason is "Given that it's currently needed in only one place, it seems reasonable to leave this as a "gentlemen's agreement" in userspace for the time being instead of adding it to the kernel." We think the kernel driver should fix this bug regardless of userspaces behavior. https://lkml.org/lkml/2020/7/22/493 Signed-off-by: LeoLiu-oc <LeoLiu-oc(a)zhaoxin.com> --- drivers/usb/core/hcd-pci.c | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/drivers/usb/core/hcd-pci.c b/drivers/usb/core/hcd-pci.c index 7537681355f6..57ac942acf12 100644 --- a/drivers/usb/core/hcd-pci.c +++ b/drivers/usb/core/hcd-pci.c @@ -34,6 +34,8 @@ static DECLARE_RWSEM(companions_rwsem); #define CL_OHCI PCI_CLASS_SERIAL_USB_OHCI #define CL_EHCI PCI_CLASS_SERIAL_USB_EHCI +#define PCI_DEV_DRV_FLAG 2 + static inline int is_ohci_or_uhci(struct pci_dev *pdev) { return pdev->class == CL_OHCI || pdev->class == CL_UHCI; @@ -69,6 +71,9 @@ static void for_each_companion(struct pci_dev *pdev, struct usb_hcd *hcd, companion->class != CL_EHCI) continue; + if (!(companion->priv_flags & PCI_DEV_DRV_FLAG)) + continue; + companion_hcd = pci_get_drvdata(companion); if (!companion_hcd || !companion_hcd->self.root_hub) continue; @@ -253,6 +258,7 @@ int usb_hcd_pci_probe(struct pci_dev *dev, const struct pci_device_id *id) } pci_set_master(dev); + dev->priv_flags |= PCI_DEV_DRV_FLAG; /* Note: dev_set_drvdata must be called while holding the rwsem */ if (dev->class == CL_EHCI) { @@ -325,6 +331,7 @@ void usb_hcd_pci_remove(struct pci_dev *dev) local_irq_disable(); usb_hcd_irq(0, hcd); local_irq_enable(); + dev->priv_flags &= ~PCI_DEV_DRV_FLAG; /* Note: dev_set_drvdata must be called while holding the rwsem */ if (dev->class == CL_EHCI) { -- 2.20.1

3 4

[PATCH openEuler-1.0-LTS 00/16] bugfix for openEuler 20.03 @20210329
by Cheng Jian 29 Mar '21

29 Mar '21

bugfix for openEuler 20.03 @20210329 *** BLURB HERE *** Dan Carpenter (2): net/x25: prevent a couple of overflows staging: rtl8188eu: prevent ->ssid overflow in rtw_wx_set_scan() Dave Airlie (1): drm/ttm/nouveau: don't call tt destroy callback on alloc failure. Filipe Manana (1): btrfs: fix race when cloning extent buffer during rewind of an old root Kan Liang (1): perf/x86/intel: Fix a crash caused by zero PEBS status Li ZhiGang (1): staging: TCM: add GMJS(Nationz Tech) TCM driver. Liu Shixin (1): mm/vmscan: fix uncleaned mem_cgroup_uncharge Lu Jialin (1): cgroup: Fix kabi broken by files_cgroup introduced Piotr Krysiuk (2): bpf: Prohibit alu ops for pointer types not defining ptr_limit bpf: Fix off-by-one for area size in creating mask to left Tyrel Datwyler (1): PCI: rpadlpar: Fix potential drc_name corruption in store functions Yang Yingliang (1): config: enable config TXGBE by default Zhang Ming (1): arm64/mpam: fix a possible deadlock in mpam_enable Zhen Lei (1): config: arm64: build TCM driver to modules by default zhenpengzheng (2): net: txgbe: Add support for Netswift 10G NIC x86/config: Set CONFIG_TXGBE=m by default arch/arm64/configs/hulk_defconfig | 2 + arch/arm64/configs/openeuler_defconfig | 3 + arch/arm64/kernel/mpam/mpam_device.c | 4 +- arch/x86/configs/openeuler_defconfig | 2 + arch/x86/events/intel/ds.c | 2 +- drivers/gpu/drm/nouveau/nouveau_sgdma.c | 9 +- drivers/gpu/drm/ttm/ttm_tt.c | 3 - drivers/net/ethernet/Kconfig | 1 + drivers/net/ethernet/Makefile | 1 + drivers/net/ethernet/netswift/Kconfig | 20 + drivers/net/ethernet/netswift/Makefile | 6 + drivers/net/ethernet/netswift/txgbe/Kconfig | 13 + drivers/net/ethernet/netswift/txgbe/Makefile | 11 + drivers/net/ethernet/netswift/txgbe/txgbe.h | 1260 +++ .../net/ethernet/netswift/txgbe/txgbe_bp.c | 875 ++ .../net/ethernet/netswift/txgbe/txgbe_bp.h | 41 + .../net/ethernet/netswift/txgbe/txgbe_dcb.h | 30 + .../ethernet/netswift/txgbe/txgbe_ethtool.c | 3381 +++++++ .../net/ethernet/netswift/txgbe/txgbe_hw.c | 7072 +++++++++++++++ .../net/ethernet/netswift/txgbe/txgbe_hw.h | 264 + .../net/ethernet/netswift/txgbe/txgbe_lib.c | 959 ++ .../net/ethernet/netswift/txgbe/txgbe_main.c | 8045 +++++++++++++++++ .../net/ethernet/netswift/txgbe/txgbe_mbx.c | 399 + .../net/ethernet/netswift/txgbe/txgbe_mbx.h | 171 + .../net/ethernet/netswift/txgbe/txgbe_mtd.c | 1366 +++ .../net/ethernet/netswift/txgbe/txgbe_mtd.h | 1540 ++++ .../net/ethernet/netswift/txgbe/txgbe_param.c | 1191 +++ .../net/ethernet/netswift/txgbe/txgbe_phy.c | 1014 +++ .../net/ethernet/netswift/txgbe/txgbe_phy.h | 190 + .../net/ethernet/netswift/txgbe/txgbe_ptp.c | 884 ++ .../net/ethernet/netswift/txgbe/txgbe_type.h | 3213 +++++++ drivers/pci/hotplug/rpadlpar_sysfs.c | 14 +- drivers/staging/Kconfig | 2 + drivers/staging/Makefile | 1 + drivers/staging/gmjstcm/Kconfig | 21 + drivers/staging/gmjstcm/Makefile | 3 + drivers/staging/gmjstcm/tcm.c | 949 ++ drivers/staging/gmjstcm/tcm.h | 122 + drivers/staging/gmjstcm/tcm_tis_spi.c | 847 ++ .../staging/rtl8188eu/os_dep/ioctl_linux.c | 6 +- fs/btrfs/ctree.c | 2 + include/linux/cgroup_subsys.h | 2 + kernel/bpf/verifier.c | 20 +- kernel/cgroup/cgroup.c | 6 + mm/vmscan.c | 1 - net/x25/af_x25.c | 6 +- 46 files changed, 33942 insertions(+), 32 deletions(-) create mode 100644 drivers/net/ethernet/netswift/Kconfig create mode 100644 drivers/net/ethernet/netswift/Makefile create mode 100644 drivers/net/ethernet/netswift/txgbe/Kconfig create mode 100644 drivers/net/ethernet/netswift/txgbe/Makefile create mode 100644 drivers/net/ethernet/netswift/txgbe/txgbe.h create mode 100644 drivers/net/ethernet/netswift/txgbe/txgbe_bp.c create mode 100644 drivers/net/ethernet/netswift/txgbe/txgbe_bp.h create mode 100644 drivers/net/ethernet/netswift/txgbe/txgbe_dcb.h create mode 100644 drivers/net/ethernet/netswift/txgbe/txgbe_ethtool.c create mode 100644 drivers/net/ethernet/netswift/txgbe/txgbe_hw.c create mode 100644 drivers/net/ethernet/netswift/txgbe/txgbe_hw.h create mode 100644 drivers/net/ethernet/netswift/txgbe/txgbe_lib.c create mode 100644 drivers/net/ethernet/netswift/txgbe/txgbe_main.c create mode 100644 drivers/net/ethernet/netswift/txgbe/txgbe_mbx.c create mode 100644 drivers/net/ethernet/netswift/txgbe/txgbe_mbx.h create mode 100644 drivers/net/ethernet/netswift/txgbe/txgbe_mtd.c create mode 100644 drivers/net/ethernet/netswift/txgbe/txgbe_mtd.h create mode 100644 drivers/net/ethernet/netswift/txgbe/txgbe_param.c create mode 100644 drivers/net/ethernet/netswift/txgbe/txgbe_phy.c create mode 100644 drivers/net/ethernet/netswift/txgbe/txgbe_phy.h create mode 100644 drivers/net/ethernet/netswift/txgbe/txgbe_ptp.c create mode 100644 drivers/net/ethernet/netswift/txgbe/txgbe_type.h create mode 100644 drivers/staging/gmjstcm/Kconfig create mode 100644 drivers/staging/gmjstcm/Makefile create mode 100644 drivers/staging/gmjstcm/tcm.c create mode 100644 drivers/staging/gmjstcm/tcm.h create mode 100644 drivers/staging/gmjstcm/tcm_tis_spi.c -- 2.25.1

1 16

add kabi list for aarch64 and x86_64
by Yang Yingliang 27 Mar '21

27 Mar '21

1 0

[PATCH kernel-4.19] iommu/vt-d:Add support for detecting ACPI device in RMRR
by LeoLiu-oc 27 Mar '21

27 Mar '21

Some ACPI devices need to issue dma requests to access the reserved memory area.BIOS uses the device scope type ACPI_NAMESPACE_DEVICE in RMRR to report these ACPI devices. This patch add support for detecting ACPI devices in RMRR and in order to distinguish it from PCI device, some interface functions are modified. This patch was submitted to mainline kernel but not accepted by upstream maintainer whose reason is "As I explained in the previous reply, RMRRs were added as work around for certain legacy device and we have been working hard to fix those legacy devices so that RMRR are no longer needed. Any new use case of RMRR is not encouraged". VT-D 1.3/2.5/3.0 Spec have this case's specification, We think this Intel driver should support this case too. https://lkml.org/lkml/2020/10/10/56 Signed-off-by: LeoLiu-oc <LeoLiu-oc(a)zhaoxin.com> --- drivers/iommu/dmar.c | 75 +++++++++++++++++++++---------------- drivers/iommu/intel-iommu.c | 24 +++++++++++- include/linux/dmar.h | 11 +++++- 3 files changed, 75 insertions(+), 35 deletions(-) diff --git a/drivers/iommu/dmar.c b/drivers/iommu/dmar.c index 3f0c2c1ef0cb..9a07bcad38e5 100644 --- a/drivers/iommu/dmar.c +++ b/drivers/iommu/dmar.c @@ -226,7 +226,7 @@ static bool dmar_match_pci_path(struct dmar_pci_notify_info *info, int bus, } /* Return: > 0 if match found, 0 if no match found, < 0 if error happens */ -int dmar_insert_dev_scope(struct dmar_pci_notify_info *info, +int dmar_pci_insert_dev_scope(struct dmar_pci_notify_info *info, void *start, void*end, u16 segment, struct dmar_dev_scope *devices, int devices_cnt) @@ -315,7 +315,7 @@ static int dmar_pci_bus_add_dev(struct dmar_pci_notify_info *info) drhd = container_of(dmaru->hdr, struct acpi_dmar_hardware_unit, header); - ret = dmar_insert_dev_scope(info, (void *)(drhd + 1), + ret = dmar_pci_insert_dev_scope(info, (void *)(drhd + 1), ((void *)drhd) + drhd->header.length, dmaru->segment, dmaru->devices, dmaru->devices_cnt); @@ -707,47 +707,58 @@ dmar_find_matched_drhd_unit(struct pci_dev *dev) return dmaru; } -static void __init dmar_acpi_insert_dev_scope(u8 device_number, - struct acpi_device *adev) +/* Return: > 0 if match found, 0 if no match found */ +bool dmar_acpi_insert_dev_scope(u8 device_number, + struct acpi_device *adev, + void *start, void *end, + struct dmar_dev_scope *devices, + int devices_cnt) { - struct dmar_drhd_unit *dmaru; - struct acpi_dmar_hardware_unit *drhd; struct acpi_dmar_device_scope *scope; struct device *tmp; int i; struct acpi_dmar_pci_path *path; + for (; start < end; start += scope->length) { + scope = start; + if (scope->entry_type != ACPI_DMAR_SCOPE_TYPE_NAMESPACE) + continue; + if (scope->enumeration_id != device_number) + continue; + path = (void *)(scope + 1); + for_each_dev_scope(devices, devices_cnt, i, tmp) + if (tmp == NULL) { + devices[i].bus = scope->bus; + devices[i].devfn = PCI_DEVFN(path->device, path->function); + rcu_assign_pointer(devices[i].dev, + get_device(&adev->dev)); + return true; + } + WARN_ON(i >= devices_cnt); + } + return false; +} + +static int dmar_acpi_bus_add_dev(u8 device_number, struct acpi_device *adev) +{ + struct dmar_drhd_unit *dmaru; + struct acpi_dmar_hardware_unit *drhd; + int ret; + for_each_drhd_unit(dmaru) { drhd = container_of(dmaru->hdr, struct acpi_dmar_hardware_unit, header); - for (scope = (void *)(drhd + 1); - (unsigned long)scope < ((unsigned long)drhd) + drhd->header.length; - scope = ((void *)scope) + scope->length) { - if (scope->entry_type != ACPI_DMAR_SCOPE_TYPE_NAMESPACE) - continue; - if (scope->enumeration_id != device_number) - continue; - - path = (void *)(scope + 1); - pr_info("ACPI device \"%s\" under DMAR at %llx as %02x:%02x.%d\n", - dev_name(&adev->dev), dmaru->reg_base_addr, - scope->bus, path->device, path->function); - for_each_dev_scope(dmaru->devices, dmaru->devices_cnt, i, tmp) - if (tmp == NULL) { - dmaru->devices[i].bus = scope->bus; - dmaru->devices[i].devfn = PCI_DEVFN(path->device, - path->function); - rcu_assign_pointer(dmaru->devices[i].dev, - get_device(&adev->dev)); - return; - } - BUG_ON(i >= dmaru->devices_cnt); - } + ret = dmar_acpi_insert_dev_scope(device_number, adev, (void *)(drhd+1), + ((void *)drhd)+drhd->header.length, + dmaru->devices, dmaru->devices_cnt); + if (ret) + break; } - pr_warn("No IOMMU scope found for ANDD enumeration ID %d (%s)\n", - device_number, dev_name(&adev->dev)); + if (ret > 0) + ret = dmar_rmrr_add_acpi_dev(device_number, adev); + return ret; } static int __init dmar_acpi_dev_scope_init(void) @@ -776,7 +787,7 @@ static int __init dmar_acpi_dev_scope_init(void) andd->device_name); continue; } - dmar_acpi_insert_dev_scope(andd->device_number, adev); + dmar_acpi_bus_add_dev(andd->device_number, adev); } } return 0; diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c index f51ae0086786..18e0be8e05a5 100644 --- a/drivers/iommu/intel-iommu.c +++ b/drivers/iommu/intel-iommu.c @@ -4512,6 +4512,26 @@ int dmar_find_matched_atsr_unit(struct pci_dev *dev) return ret; } +int dmar_rmrr_add_acpi_dev(u8 device_number, struct acpi_device *adev) +{ + int ret; + struct dmar_rmrr_unit *rmrru; + struct acpi_dmar_reserved_memory *rmrr; + + list_for_each_entry(rmrru, &dmar_rmrr_units, list) { + rmrr = container_of(rmrru->hdr, + struct acpi_dmar_reserved_memory, + header); + ret = dmar_acpi_insert_dev_scope(device_number, adev, (void *)(rmrr + 1), + ((void *)rmrr) + rmrr->header.length, + rmrru->devices, rmrru->devices_cnt); + if (ret) + break; + } + pr_info("Add acpi_dev:%s to rmrru->devices\n", dev_name(&adev->dev)); + return 0; +} + int dmar_iommu_notify_scope_dev(struct dmar_pci_notify_info *info) { int ret = 0; @@ -4527,7 +4547,7 @@ int dmar_iommu_notify_scope_dev(struct dmar_pci_notify_info *info) rmrr = container_of(rmrru->hdr, struct acpi_dmar_reserved_memory, header); if (info->event == BUS_NOTIFY_ADD_DEVICE) { - ret = dmar_insert_dev_scope(info, (void *)(rmrr + 1), + ret = dmar_pci_insert_dev_scope(info, (void *)(rmrr + 1), ((void *)rmrr) + rmrr->header.length, rmrr->segment, rmrru->devices, rmrru->devices_cnt); @@ -4545,7 +4565,7 @@ int dmar_iommu_notify_scope_dev(struct dmar_pci_notify_info *info) atsr = container_of(atsru->hdr, struct acpi_dmar_atsr, header); if (info->event == BUS_NOTIFY_ADD_DEVICE) { - ret = dmar_insert_dev_scope(info, (void *)(atsr + 1), + ret = dmar_pci_insert_dev_scope(info, (void *)(atsr + 1), (void *)atsr + atsr->header.length, atsr->segment, atsru->devices, atsru->devices_cnt); diff --git a/include/linux/dmar.h b/include/linux/dmar.h index 843a41ba7e28..68de8732d8d4 100644 --- a/include/linux/dmar.h +++ b/include/linux/dmar.h @@ -117,10 +117,13 @@ extern int dmar_parse_dev_scope(void *start, void *end, int *cnt, struct dmar_dev_scope **devices, u16 segment); extern void *dmar_alloc_dev_scope(void *start, void *end, int *cnt); extern void dmar_free_dev_scope(struct dmar_dev_scope **devices, int *cnt); -extern int dmar_insert_dev_scope(struct dmar_pci_notify_info *info, +extern int dmar_pci_insert_dev_scope(struct dmar_pci_notify_info *info, void *start, void*end, u16 segment, struct dmar_dev_scope *devices, int devices_cnt); +extern bool dmar_acpi_insert_dev_scope(u8 device_number, + struct acpi_device *adev, void *start, void *end, + struct dmar_dev_scope *devices, int devices_cnt); extern int dmar_remove_dev_scope(struct dmar_pci_notify_info *info, u16 segment, struct dmar_dev_scope *devices, int count); @@ -143,6 +146,7 @@ extern int dmar_parse_one_atsr(struct acpi_dmar_header *header, void *arg); extern int dmar_check_one_atsr(struct acpi_dmar_header *hdr, void *arg); extern int dmar_release_one_atsr(struct acpi_dmar_header *hdr, void *arg); extern int dmar_iommu_hotplug(struct dmar_drhd_unit *dmaru, bool insert); +extern int dmar_rmrr_add_acpi_dev(u8 device_number, struct acpi_device *adev); extern int dmar_iommu_notify_scope_dev(struct dmar_pci_notify_info *info); #else /* !CONFIG_INTEL_IOMMU: */ static inline int intel_iommu_init(void) { return -ENODEV; } @@ -152,6 +156,11 @@ static inline int intel_iommu_init(void) { return -ENODEV; } #define dmar_check_one_atsr dmar_res_noop #define dmar_release_one_atsr dmar_res_noop +static inline int dmar_rmrr_add_acpi_dev(u8 device_number, struct acpi_device *adev) +{ + return 0; +} + static inline int dmar_iommu_notify_scope_dev(struct dmar_pci_notify_info *info) { return 0; -- 2.20.1

3 3

2025

2024

2023

2022

2021

2020

2019

Kernel