- Cloud Kernel - lists.openanolis.cn

[patch v2 2/3] ck: x86/cpu: Set low performance CRC32C flag on some Zhaoxin CPUs

by LeoLiuoc

Some Zhaoxin CPUs declare support SSE4.2 instruction sets but having a CRC32C instruction implementation that not working as intended. Set low performance CRC32C flag on these CPUs for later use. Signed-off-by: LeoLiu-oc <LeoLiu-oc(a)zhaoxin.com> --- arch/x86/kernel/cpu/centaur.c | 7 +++++++ arch/x86/kernel/cpu/zhaoxin.c | 7 +++++++ 2 files changed, 14 insertions(+) diff --git a/arch/x86/kernel/cpu/centaur.c b/arch/x86/kernel/cpu/centaur.c index 49b33cc78751..1c92a57364e9 100644 --- a/arch/x86/kernel/cpu/centaur.c +++ b/arch/x86/kernel/cpu/centaur.c @@ -116,6 +116,13 @@ static void early_init_centaur(struct cpuinfo_x86 *c) set_cpu_cap(c, X86_FEATURE_NONSTOP_TSC); } + /* + * These CPUs declare support SSE4.2 instruction sets but + * having low performance CRC32C instruction implementation. + */ + if (c->x86 == 0x6 || (c->x86 == 0x7 && c->x86_model <= 0x3b)) + set_cpu_cap(c, X86_FEATURE_CRC32C_LOW_PERF); + if (c->cpuid_level >= 0x00000001) { u32 eax, ebx, ecx, edx; diff --git a/arch/x86/kernel/cpu/zhaoxin.c b/arch/x86/kernel/cpu/zhaoxin.c index b6fc969b3e74..75fca076d9ab 100644 --- a/arch/x86/kernel/cpu/zhaoxin.c +++ b/arch/x86/kernel/cpu/zhaoxin.c @@ -85,6 +85,13 @@ static void early_init_zhaoxin(struct cpuinfo_x86 *c) c->x86_coreid_bits = get_count_order((ebx >> 16) & 0xff); } + /* + * These CPUs declare support SSE4.2 instruction sets but + * having low performance CRC32C instruction implementation. + */ + if (c->x86 == 0x6 || (c->x86 == 0x7 && c->x86_model <= 0x3b)) + set_cpu_cap(c, X86_FEATURE_CRC32C_LOW_PERF); + if (detect_extended_topology_early(c) < 0) detect_ht_early(c); } -- 2.20.1

4 years, 1 month

2
1
0 0

[patch v2 1/3] ck: x86/cpufeatures: Add low performance CRC32C instruction CPU feature

by LeoLiuoc

SSE4.2 on Zhaoxin CPUs are compatible with Intel. The presence of CRC32C instruction is enumerated by CPUID.01H:ECX.SSE4_2[bit 20] = 1. Some Zhaoxin CPUs declare support SSE4.2 instruction sets but their CRC32C instruction are working with low performance. Add a synthetic CPU flag to indicates that the CRC32C instruction is not working as intended. This low performance CRC32C instruction flag is depend on X86_FEATURE_XMM4_2. Signed-off-by: LeoLiu-oc <LeoLiu-oc(a)zhaoxin.com> --- arch/x86/include/asm/cpufeatures.h | 1 + arch/x86/kernel/cpu/cpuid-deps.c | 1 + 2 files changed, 2 insertions(+) diff --git a/arch/x86/include/asm/cpufeatures.h b/arch/x86/include/asm/cpufeatures.h index 77ecd7136536..653de364f36e 100644 --- a/arch/x86/include/asm/cpufeatures.h +++ b/arch/x86/include/asm/cpufeatures.h @@ -304,6 +304,7 @@ #define X86_FEATURE_CQM_MBM_LOCAL (11*32+ 3) /* LLC Local MBM monitoring */ #define X86_FEATURE_FENCE_SWAPGS_USER (11*32+ 4) /* "" LFENCE in user entry SWAPGS path */ #define X86_FEATURE_FENCE_SWAPGS_KERNEL (11*32+ 5) /* "" LFENCE in kernel entry SWAPGS path */ +#define X86_FEATURE_CRC32C_LOW_PERF (11*32+ 6) /* "" Low performance */ /* Intel-defined CPU features, CPUID level 0x00000007:1 (EAX), word 12 */ #define X86_FEATURE_AVX512_BF16 (12*32+ 5) /* AVX512 BFLOAT16 instructions */ diff --git a/arch/x86/kernel/cpu/cpuid-deps.c b/arch/x86/kernel/cpu/cpuid-deps.c index a444028d8145..aebb5e92c31d 100644 --- a/arch/x86/kernel/cpu/cpuid-deps.c +++ b/arch/x86/kernel/cpu/cpuid-deps.c @@ -63,6 +63,7 @@ static const struct cpuid_dep cpuid_deps[] = { { X86_FEATURE_CQM_MBM_TOTAL, X86_FEATURE_CQM_LLC }, { X86_FEATURE_CQM_MBM_LOCAL, X86_FEATURE_CQM_LLC }, { X86_FEATURE_AVX512_BF16, X86_FEATURE_AVX512VL }, + { X86_FEATURE_CRC32C_LOW_PERF, X86_FEATURE_XMM4_2 }, {} }; -- 2.20.1

4 years, 1 month

2
1
0 0

[patch v2 0/3] ck: crypto: x86/crc32c-intel - Exclude some Zhaoxin CPUs

by LeoLiuoc

The driver crc32c-intel match CPUs supporting X86_FEATURE_XMM4_2. On platforms with Zhaoxin CPUs supporting this X86 feature, when crc32c-intel and crc32c-generic are both registered, system will use crc32c-intel because its .cra_priority is greater than crc32c-generic. When doing lmbench3 Create and Delete file test on partitions with ext4 enabling metadata checksum, found using crc32c-generic driver could get about 20% performance gain than using the driver crc32c-intel on some Zhaoxin CPUs. Lower-level testing result is that with the same input value the generic C implementation takes fewer time than the crc32c instruction implementation on these CPUs. This case expect to use crc32c-generic driver for these CPUs to get performance gain. The presence of crc32c is enumerated by CPUID.01:ECX[SSE4.2] = 1, and these CPUs other SSE4.2 instructions is ok. Add a synthetic flag to indicates low performance CRC32C instruction implementation, set this flag in Zhaoxin CPUs specific init phase, and exclude CPUs which setting this flag from the driver crc32c-intel. LeoLiu-oc (3): ck: x86/cpufeatures: Add low performance CRC32C instruction CPU feature ck: x86/cpu: Set low performance CRC32C flag on some Zhaoxin CPUs ck: crypto: x86/crc32c-intel Exclude low performance CRC32C instruction CPUs arch/x86/crypto/crc32c-intel_glue.c | 5 +++++ arch/x86/include/asm/cpufeatures.h | 1 + arch/x86/kernel/cpu/centaur.c | 7 +++++++ arch/x86/kernel/cpu/cpuid-deps.c | 1 + arch/x86/kernel/cpu/zhaoxin.c | 7 +++++++ 5 files changed, 21 insertions(+) -- 2.20.1

4 years, 1 month

1
0
0 0

[patch v1] ck: USB:Fix kernel NULL pointer when unbind UHCI form vfio-pci

by LeoLiu-oc

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

4 years, 1 month

4
4
0 0

Re: 回复：Re: 回复： [patch v1] ck: crypto: x86/crc32c-intel - Don't match some Zhaoxin CPUs

by Tony W Wang-oc

On 25/03/2021 17:56, Artie Ding wrote: > > 在 2021/3/25 下午5:27, Tony W Wang-oc 写道: >> On 25/03/2021 17:15, 丁宁(富邻) wrote: >>> I have a question here. If crc32c instruction on some Zhaoxin CPUs >>> slower than generic C >>> implementation, then why not clear the X86_FEATURE_XMM4_2 flag? >>> >> The presence of crc32c and some other instructions supports are >> enumerated by CPUID.01:ECX[SSE4.2] = 1 that called X86_FEATURE_XMM4_2 in >> kernel, other instructions are ok except the crc32c instruction on these >> Zhaoxin CPUs. >> >> Sincerely >> TonyWWangoc > > Got it. It seems there is an issue for crc32c instruction. It's not nice > to change intel driver for Zhaoxin CPUs issue. > > It's better to make it clear with a individual flag for crc32c instruction. > As crc32c-intel is the common driver that match X86_FEATURE_XMM4_2, add specific code for other CPUs should be reasonable. Sincerely TonyWWangoc > BR > > Artie > >> >>> Best Regards >>> Artie Ding（丁宁） >>> ------------------原始邮件 ------------------ >>> 发件人:Tony W Wang-oc <TonyWWang-oc(a)zhaoxin.com> >>> 发送时间:Thu Mar 25 16:37:49 2021 >>> 收件人:丁宁(富邻) <fulin.dn(a)alibaba-inc.com>, LeoLiu-oc >>> <LeoLiu-oc(a)zhaoxin.com>, cloud-kernel >>> <cloud-kernel(a)lists.openanolis.org> >>> 抄送:TimGuo <TimGuo(a)zhaoxin.com>, CobeChen <CobeChen(a)zhaoxin.com> >>> 主题:Re: 回复：[ck] [patch v1] ck: crypto: x86/crc32c-intel - Don't >>> match some Zhaoxin CPUs >>> On 25/03/2021 15:53, 丁宁(富邻) wrote: >>>> If X86_FEATURE_XMM4_2 meens different hw implement to Zhaoxin CPUs, >>>> a new flag is needed to distinguish >>>> them. >>>> >>> The X86_FEATURE_XMM4_2 on Zhaoxin CPUs have the same meaning with Intel. >>> crc32c instruction on some Zhaoxin CPUs slower than generic C >>> implementation, should avoid these Zhaoxin CPUs using the driver >>> crc32c-intel which will call crc32c instruction. >>> >>> Sincerely >>> TonyWWangoc >>> >>>> Artie >>>> >>>> >>>> ------------------原始邮件 ------------------ >>>> 发件人:LeoLiu-oc <LeoLiu-oc(a)zhaoxin.com> >>>> 发送时间:Mon Mar 22 18:44:54 2021 >>>> 收件人: <cloud-kernel(a)lists.openanolis.org> >>>> 抄送: <TonyWWang-oc(a)zhaoxin.com>, <TimGuo(a)zhaoxin.com>, >>>> <CobeChen(a)zhaoxin.com> >>>> 主题:[ck] [patch v1] ck: crypto: x86/crc32c-intel - Don't match some >>>> Zhaoxin CPUs >>>> >>>> The driver crc32c-intel match CPUs supporting X86_FEATURE_XMM4_2. >>>> On platforms with Zhaoxin CPUs supporting this X86 feature, >>>> when crc32c-intel and crc32c-generic are both registered, >>>> system will use crc32c-intel because its .cra_priority is greater >>>> than crc32c-generic. >>>> >>>> When doing lmbench3 Create and Delete file test on partitions with >>>> ext4 enabling metadata checksum, found using crc32c-generic driver >>>> could get about 20% performance gain than using the driver >>>> crc32c-intel on some Zhaoxin CPUs. >>>> >>>> This case expect to use crc32c-generic driver for these Zhaoxin CPUs >>>> to get performance gain, so remove these Zhaoxin CPUs support from >>>> crc32c-intel. >>>> >>>> This patch was submitted to mainline kernel but not accepted by >>>> upstream >>>> maintainer whose reason is "Then create a BUG flag for it,". >>>> >>>> We think this is not a CPU bug for Zhaoxin CPUs. So should patch the >>>> crc32c driver for Zhaoxin CPUs but not report a BUG. >>>> >>>> https://lkml.org/lkml/2020/12/11/308 >>>> >>>> Signed-off-by: LeoLiu-oc <LeoLiu-oc(a)zhaoxin.com> >>>> --- >>>> arch/x86/crypto/crc32c-intel_glue.c | 5 +++++ >>>> 1 file changed, 5 insertions(+) >>>> >>>> diff --git a/arch/x86/crypto/crc32c-intel_glue.c >>>> b/arch/x86/crypto/crc32c-intel_glue.c >>>> index 5773e1161072..d994bd49761a 100644 >>>> --- a/arch/x86/crypto/crc32c-intel_glue.c >>>> +++ b/arch/x86/crypto/crc32c-intel_glue.c >>>> @@ -242,8 +242,13 @@ MODULE_DEVICE_TABLE(x86cpu, crc32c_cpu_id); >>>> >>>> static int __init crc32c_intel_mod_init(void) >>>> { >>>> +struct cpuinfo_x86 *c = &boot_cpu_data; >>>> if (!x86_match_cpu(crc32c_cpu_id)) >>>> return -ENODEV; >>>> +if ((c->x86_vendor == X86_VENDOR_ZHAOXIN || c->x86_vendor == >>>> X86_VENDOR_CENTAUR) && >>>> +(c->x86 <= 7 && c->x86_model <= 59)) { >>>> +return -ENODEV; >>>> +} >>>> #ifdef CONFIG_X86_64 >>>> if (boot_cpu_has(X86_FEATURE_PCLMULQDQ)) { >>>> alg.update = crc32c_pcl_intel_update; > .

4 years, 1 month

2
2
0 0

[patch v3] ck: xhci: fix issue of cross page boundary in TRB prefetch mechanism

by LeoLiuoc

On some Zhaoxin platforms, xHCI will prefetch TRB for performance improvement. However this TRB prefetch mechanism may cross page boundary, which may access memory not belong to xHCI. In order to fix this issue, using two pages for TRB allocate and only the first page will be used. The patch is scheduled to be submitted to the kernel mainline in 2021. --- v2->v3: - Fix some coding style issues. v1->v2: - Use quirks instead of vendor id. Signed-off-by: LeoLiu-oc <LeoLiu-oc(a)zhaoxin.com> --- drivers/usb/host/xhci-mem.c | 13 ++++++++++--- drivers/usb/host/xhci-pci.c | 5 +++++ drivers/usb/host/xhci.h | 1 + 3 files changed, 16 insertions(+), 3 deletions(-) diff --git a/drivers/usb/host/xhci-mem.c b/drivers/usb/host/xhci-mem.c index 82ce6d8b708d..4e68aada1a23 100644 --- a/drivers/usb/host/xhci-mem.c +++ b/drivers/usb/host/xhci-mem.c @@ -2421,7 +2421,6 @@ int xhci_mem_init(struct xhci_hcd *xhci, gfp_t flags) "// Device context base array address = 0x%llx (DMA), %p (virt)", (unsigned long long)xhci->dcbaa->dma, xhci->dcbaa); xhci_write_64(xhci, dma, &xhci->op_regs->dcbaa_ptr); - /* * Initialize the ring segment pool. The ring must be a contiguous * structure comprised of TRBs. The TRBs must be 16 byte aligned, @@ -2429,8 +2428,16 @@ int xhci_mem_init(struct xhci_hcd *xhci, gfp_t flags) * and our use of dma addresses in the trb_address_map radix tree needs * TRB_SEGMENT_SIZE alignment, so we pick the greater alignment need. */ - xhci->segment_pool = dma_pool_create("xHCI ring segments", dev, - TRB_SEGMENT_SIZE, TRB_SEGMENT_SIZE, xhci->page_size); + /* With xHCI TRB prefetch patch:To fix cross page boundry access issue + * in IOV environment. + */ + + if (xhci->quirks & XHCI_ZHAOXIN_TRB_FETCH) { + xhci->segment_pool = dma_pool_create("xHCI ring segments", dev, + TRB_SEGMENT_SIZE * 2, TRB_SEGMENT_SIZE * 2, xhci->page_size * 2); + } else + xhci->segment_pool = dma_pool_create("xHCI ring segments", dev, + TRB_SEGMENT_SIZE, TRB_SEGMENT_SIZE, xhci->page_size); /* See Table 46 and Note on Figure 55 */ xhci->device_pool = dma_pool_create("xHCI input/output contexts", dev, diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c index 712bcb2eab76..c88402cb09ef 100644 --- a/drivers/usb/host/xhci-pci.c +++ b/drivers/usb/host/xhci-pci.c @@ -226,6 +226,11 @@ static void xhci_pci_quirks(struct device *dev, struct xhci_hcd *xhci) pdev->device == 0x3432) xhci->quirks |= XHCI_BROKEN_STREAMS; + if (pdev->vendor == PCI_VENDOR_ID_ZHAOXIN && + (pdev->device == 0x9202 || + pdev->device == 0x9203)) + xhci->quirks |= XHCI_ZHAOXIN_TRB_FETCH; + if (pdev->vendor == PCI_VENDOR_ID_ASMEDIA && pdev->device == 0x1042) xhci->quirks |= XHCI_BROKEN_STREAMS; diff --git a/drivers/usb/host/xhci.h b/drivers/usb/host/xhci.h index 76b872dcb0d9..f285e3cc6aa1 100644 --- a/drivers/usb/host/xhci.h +++ b/drivers/usb/host/xhci.h @@ -1866,6 +1866,7 @@ struct xhci_hcd { #define XHCI_RESET_PLL_ON_DISCONNECT BIT_ULL(34) #define XHCI_SNPS_BROKEN_SUSPEND BIT_ULL(35) #define XHCI_ZHAOXIN_HOST BIT_ULL(36) +#define XHCI_ZHAOXIN_TRB_FETCH BIT_ULL(37) unsigned int num_active_eps; unsigned int limit_active_eps; -- 2.20.1

4 years, 1 month

2
1
0 0

[patch v2] ck: ata: sata_zhaoxin: Add support for Zhaoxin Serial ATA

by LeoLiu-oc

Add Zhaoxin Serial ATA support for Zhaoxin CPUs. The patch is scheduled to be submitted to the kernel mainline in 2021. v1->v2: - Fix some coding style issues Signed-off-by: LeoLiu-oc <LeoLiu-oc(a)zhaoxin.com> --- drivers/ata/Kconfig | 8 + drivers/ata/Makefile | 1 + drivers/ata/sata_zhaoxin.c | 384 +++++++++++++++++++++++++++++++++++++ 3 files changed, 393 insertions(+) create mode 100644 drivers/ata/sata_zhaoxin.c diff --git a/drivers/ata/Kconfig b/drivers/ata/Kconfig index 99698d7fe585..78a6338d074e 100644 --- a/drivers/ata/Kconfig +++ b/drivers/ata/Kconfig @@ -494,6 +494,14 @@ config SATA_VITESSE If unsure, say N. +config SATA_ZHAOXIN + tristate "ZhaoXin SATA support" + depends on PCI + help + This option enables support for ZhaoXin Serial ATA. + + If unsure, say N. + comment "PATA SFF controllers with BMDMA" config PATA_ALI diff --git a/drivers/ata/Makefile b/drivers/ata/Makefile index d21cdd83f7ab..2d9220311187 100644 --- a/drivers/ata/Makefile +++ b/drivers/ata/Makefile @@ -44,6 +44,7 @@ obj-$(CONFIG_SATA_SIL) += sata_sil.o obj-$(CONFIG_SATA_SIS) += sata_sis.o obj-$(CONFIG_SATA_SVW) += sata_svw.o obj-$(CONFIG_SATA_ULI) += sata_uli.o +obj-$(CONFIG_SATA_ZHAOXIN) += sata_zhaoxin.o obj-$(CONFIG_SATA_VIA) += sata_via.o obj-$(CONFIG_SATA_VITESSE) += sata_vsc.o diff --git a/drivers/ata/sata_zhaoxin.c b/drivers/ata/sata_zhaoxin.c new file mode 100644 index 000000000000..f4a694355f13 --- /dev/null +++ b/drivers/ata/sata_zhaoxin.c @@ -0,0 +1,384 @@ +// SPDX-License-Identifier: GPL-2.0-only +/* + * sata_zhaoxin.c - ZhaoXin Serial ATA controllers + */ + +#include <linux/kernel.h> +#include <linux/module.h> +#include <linux/pci.h> +#include <linux/blkdev.h> +#include <linux/delay.h> +#include <linux/device.h> +#include <scsi/scsi.h> +#include <scsi/scsi_cmnd.h> +#include <scsi/scsi_host.h> +#include <linux/libata.h> + +#define DRV_NAME "sata_zx" +#define DRV_VERSION "2.6.1" + +enum board_ids_enum { + cnd001, +}; + +enum { + SATA_CHAN_ENAB = 0x40, /* SATA channel enable */ + SATA_INT_GATE = 0x41, /* SATA interrupt gating */ + SATA_NATIVE_MODE = 0x42, /* Native mode enable */ + PATA_UDMA_TIMING = 0xB3, /* PATA timing for DMA/ cable detect */ + PATA_PIO_TIMING = 0xAB, /* PATA timing register */ + + PORT0 = (1 << 1), + PORT1 = (1 << 0), + ALL_PORTS = PORT0 | PORT1, + + NATIVE_MODE_ALL = (1 << 7) | (1 << 6) | (1 << 5) | (1 << 4), + + SATA_EXT_PHY = (1 << 6), /* 0==use PATA, 1==ext phy */ +}; + +static int szx_init_one(struct pci_dev *pdev, const struct pci_device_id *ent); +static int cnd001_scr_read(struct ata_link *link, unsigned int scr, u32 *val); +static int cnd001_scr_write(struct ata_link *link, unsigned int scr, u32 val); +static int szx_hardreset(struct ata_link *link, unsigned int *class, + unsigned long deadline); + +static void szx_tf_load(struct ata_port *ap, const struct ata_taskfile *tf); + +static const struct pci_device_id szx_pci_tbl[] = { + { PCI_VDEVICE(ZHAOXIN, 0x9002), cnd001 }, + { PCI_VDEVICE(ZHAOXIN, 0x9003), cnd001 }, + + { } /* terminate list */ +}; + +static struct pci_driver szx_pci_driver = { + .name = DRV_NAME, + .id_table = szx_pci_tbl, + .probe = szx_init_one, +#ifdef CONFIG_PM_SLEEP + .suspend = ata_pci_device_suspend, + .resume = ata_pci_device_resume, +#endif + .remove = ata_pci_remove_one, +}; + +static struct scsi_host_template szx_sht = { + ATA_BMDMA_SHT(DRV_NAME), +}; + +static struct ata_port_operations szx_base_ops = { + .inherits = &ata_bmdma_port_ops, + .sff_tf_load = szx_tf_load, +}; + +static struct ata_port_operations cnd001_ops = { + .inherits = &szx_base_ops, + .hardreset = szx_hardreset, + .scr_read = cnd001_scr_read, + .scr_write = cnd001_scr_write, +}; + +static struct ata_port_info cnd001_port_info = { + .flags = ATA_FLAG_SATA | ATA_FLAG_SLAVE_POSS, + .pio_mask = ATA_PIO4, + .mwdma_mask = ATA_MWDMA2, + .udma_mask = ATA_UDMA6, + .port_ops = &cnd001_ops, +}; + + +static int szx_hardreset(struct ata_link *link, unsigned int *class, + unsigned long deadline) +{ + int rc; + + rc = sata_std_hardreset(link, class, deadline); + if (!rc || rc == -EAGAIN) { + struct ata_port *ap = link->ap; + int pmp = link->pmp; + int tmprc; + + if (pmp) { + ap->ops->sff_dev_select(ap, pmp); + tmprc = ata_sff_wait_ready(&ap->link, deadline); + } else { + tmprc = ata_sff_wait_ready(link, deadline); + } + if (tmprc) + ata_link_err(link, "COMRESET failed for wait (errno=%d)\n", + rc); + else + ata_link_err(link, "wait for bsy success\n"); + + ata_link_err(link, "COMRESET success (errno=%d) ap=%d link %d\n", + rc, link->ap->port_no, link->pmp); + } else { + ata_link_err(link, "COMRESET failed (errno=%d) ap=%d link %d\n", + rc, link->ap->port_no, link->pmp); + } + return rc; +} + +static int cnd001_scr_read(struct ata_link *link, unsigned int scr, u32 *val) +{ + static const u8 ipm_tbl[] = { 1, 2, 6, 0 }; + struct pci_dev *pdev = to_pci_dev(link->ap->host->dev); + int slot = 2 * link->ap->port_no + link->pmp; + u32 v = 0; + u8 raw; + + switch (scr) { + case SCR_STATUS: + pci_read_config_byte(pdev, 0xA0 + slot, &raw); + + /* read the DET field, bit0 and 1 of the config byte */ + v |= raw & 0x03; + + /* read the SPD field, bit4 of the configure byte */ + v |= raw & 0x30; + + /* read the IPM field, bit2 and 3 of the config byte */ + v |= ((ipm_tbl[(raw >> 2) & 0x3])<<8); + break; + + case SCR_ERROR: + /* devices other than 5287 uses 0xA8 as base */ + WARN_ON(pdev->device != 0x9002 && pdev->device != 0x9003); + pci_write_config_byte(pdev, 0x42, slot); + pci_read_config_dword(pdev, 0xA8, &v); + break; + + case SCR_CONTROL: + pci_read_config_byte(pdev, 0xA4 + slot, &raw); + + /* read the DET field, bit0 and bit1 */ + v |= ((raw & 0x02) << 1) | (raw & 0x01); + + /* read the IPM field, bit2 and bit3 */ + v |= ((raw >> 2) & 0x03) << 8; + + break; + + default: + return -EINVAL; + } + + *val = v; + return 0; +} + +static int cnd001_scr_write(struct ata_link *link, unsigned int scr, u32 val) +{ + struct pci_dev *pdev = to_pci_dev(link->ap->host->dev); + int slot = 2 * link->ap->port_no + link->pmp; + u32 v = 0; + + WARN_ON(pdev == NULL); + + switch (scr) { + case SCR_ERROR: + /* devices 0x9002 uses 0xA8 as base */ + WARN_ON(pdev->device != 0x9002 && pdev->device != 0x9003); + pci_write_config_byte(pdev, 0x42, slot); + pci_write_config_dword(pdev, 0xA8, val); + return 0; + + case SCR_CONTROL: + /* set the DET field */ + v |= ((val & 0x4) >> 1) | (val & 0x1); + + /* set the IPM field */ + v |= ((val >> 8) & 0x3) << 2; + + + pci_write_config_byte(pdev, 0xA4 + slot, v); + + + return 0; + + default: + return -EINVAL; + } +} + + +/** + * szx_tf_load - send taskfile registers to host controller + * @ap: Port to which output is sent + * @tf: ATA taskfile register set + * + * Outputs ATA taskfile to standard ATA host controller. + * + * This is to fix the internal bug of zx chipsets, which will + * reset the device register after changing the IEN bit on ctl + * register. + */ +static void szx_tf_load(struct ata_port *ap, const struct ata_taskfile *tf) +{ + struct ata_taskfile ttf; + + if (tf->ctl != ap->last_ctl) { + ttf = *tf; + ttf.flags |= ATA_TFLAG_DEVICE; + tf = &ttf; + } + ata_sff_tf_load(ap, tf); +} + +static const unsigned int szx_bar_sizes[] = { + 8, 4, 8, 4, 16, 256 +}; + +static const unsigned int cnd001_bar_sizes0[] = { + 8, 4, 8, 4, 16, 0 +}; + +static const unsigned int cnd001_bar_sizes1[] = { + 8, 4, 0, 0, 16, 0 +}; + +static int cnd001_prepare_host(struct pci_dev *pdev, struct ata_host **r_host) +{ + const struct ata_port_info *ppi0[] = { + &cnd001_port_info, NULL + }; + const struct ata_port_info *ppi1[] = { + &cnd001_port_info, &ata_dummy_port_info + }; + struct ata_host *host; + int i, rc; + + if (pdev->device == 0x9002) + rc = ata_pci_bmdma_prepare_host(pdev, ppi0, &host); + else if (pdev->device == 0x9003) + rc = ata_pci_bmdma_prepare_host(pdev, ppi1, &host); + else + rc = -EINVAL; + + if (rc) + return rc; + + *r_host = host; + + /* cnd001 9002 hosts four sata ports as M/S of the two channels */ + /* cnd001 9003 hosts two sata ports as M/S of the one channel */ + for (i = 0; i < host->n_ports; i++) + ata_slave_link_init(host->ports[i]); + + return 0; +} + +static void szx_configure(struct pci_dev *pdev, int board_id) +{ + u8 tmp8; + + pci_read_config_byte(pdev, PCI_INTERRUPT_LINE, &tmp8); + dev_info(&pdev->dev, "routed to hard irq line %d\n", + (int) (tmp8 & 0xf0) == 0xf0 ? 0 : tmp8 & 0x0f); + + /* make sure SATA channels are enabled */ + pci_read_config_byte(pdev, SATA_CHAN_ENAB, &tmp8); + if ((tmp8 & ALL_PORTS) != ALL_PORTS) { + dev_dbg(&pdev->dev, "enabling SATA channels (0x%x)\n", + (int)tmp8); + tmp8 |= ALL_PORTS; + pci_write_config_byte(pdev, SATA_CHAN_ENAB, tmp8); + } + + /* make sure interrupts for each channel sent to us */ + pci_read_config_byte(pdev, SATA_INT_GATE, &tmp8); + if ((tmp8 & ALL_PORTS) != ALL_PORTS) { + dev_dbg(&pdev->dev, "enabling SATA channel interrupts (0x%x)\n", + (int) tmp8); + tmp8 |= ALL_PORTS; + pci_write_config_byte(pdev, SATA_INT_GATE, tmp8); + } + + /* make sure native mode is enabled */ + pci_read_config_byte(pdev, SATA_NATIVE_MODE, &tmp8); + if ((tmp8 & NATIVE_MODE_ALL) != NATIVE_MODE_ALL) { + dev_dbg(&pdev->dev, + "enabling SATA channel native mode (0x%x)\n", + (int) tmp8); + tmp8 |= NATIVE_MODE_ALL; + pci_write_config_byte(pdev, SATA_NATIVE_MODE, tmp8); + } +} + +static int szx_init_one(struct pci_dev *pdev, const struct pci_device_id *ent) +{ + unsigned int i; + int rc; + struct ata_host *host = NULL; + int board_id = (int) ent->driver_data; + const unsigned int *bar_sizes; + int legacy_mode = 0; + + ata_print_version_once(&pdev->dev, DRV_VERSION); + + if (pdev->device == 0x9002 || pdev->device == 0x9003) { + if ((pdev->class >> 8) == PCI_CLASS_STORAGE_IDE) { + u8 tmp8, mask; + + /* TODO: What if one channel is in native mode ... */ + pci_read_config_byte(pdev, PCI_CLASS_PROG, &tmp8); + mask = (1 << 2) | (1 << 0); + if ((tmp8 & mask) != mask) + legacy_mode = 1; + } + if (legacy_mode) + return -EINVAL; + } + + rc = pcim_enable_device(pdev); + if (rc) + return rc; + + if (board_id == cnd001 && pdev->device == 0x9002) + bar_sizes = &cnd001_bar_sizes0[0]; + else if (board_id == cnd001 && pdev->device == 0x9003) + bar_sizes = &cnd001_bar_sizes1[0]; + else + bar_sizes = &szx_bar_sizes[0]; + + for (i = 0; i < ARRAY_SIZE(szx_bar_sizes); i++) { + if ((pci_resource_start(pdev, i) == 0) || + (pci_resource_len(pdev, i) < bar_sizes[i])) { + if (bar_sizes[i] == 0) + continue; + + dev_err(&pdev->dev, + "invalid PCI BAR %u (sz 0x%llx, val 0x%llx)\n", + i, + (unsigned long long)pci_resource_start(pdev, i), + (unsigned long long)pci_resource_len(pdev, i)); + + return -ENODEV; + } + } + + switch (board_id) { + case cnd001: + rc = cnd001_prepare_host(pdev, &host); + break; + default: + rc = -EINVAL; + } + if (rc) + return rc; + + szx_configure(pdev, board_id); + + pci_set_master(pdev); + return ata_host_activate(host, pdev->irq, ata_bmdma_interrupt, + IRQF_SHARED, &szx_sht); +} + +module_pci_driver(szx_pci_driver); + +MODULE_AUTHOR("Yanchen:YanchenSun@zhaoxin.com"); +MODULE_DESCRIPTION("SCSI low-level driver for ZX SATA controllers"); +MODULE_LICENSE("GPL"); +MODULE_DEVICE_TABLE(pci, szx_pci_tbl); +MODULE_VERSION(DRV_VERSION); -- 2.20.1

4 years, 1 month

2
1
0 0

[patch v2] ck: xhci: fix issue of cross page boundary in TRB prefetch mechanism

by LeoLiu-oc

On some Zhaoxin platforms, xHCI will prefetch TRB for performance improvement. However this TRB prefetch mechanism may cross page boundary, which may access memory not belong to xHCI. In order to fix this issue, using two pages for TRB allocate and only the first page will be used. The patch is scheduled to be submitted to the kernel mainline in 2021. v1->v2: - Use quirks instead of vendor id. Signed-off-by: LeoLiu-oc <LeoLiu-oc(a)zhaoxin.com> --- drivers/usb/host/xhci-mem.c | 9 +++++++-- drivers/usb/host/xhci-pci.c | 5 +++++ drivers/usb/host/xhci.h | 1 + 3 files changed, 13 insertions(+), 2 deletions(-) diff --git a/drivers/usb/host/xhci-mem.c b/drivers/usb/host/xhci-mem.c index 82ce6d8b708d..b2fb044befb6 100644 --- a/drivers/usb/host/xhci-mem.c +++ b/drivers/usb/host/xhci-mem.c @@ -2429,8 +2429,13 @@ int xhci_mem_init(struct xhci_hcd *xhci, gfp_t flags) * and our use of dma addresses in the trb_address_map radix tree needs * TRB_SEGMENT_SIZE alignment, so we pick the greater alignment need. */ - xhci->segment_pool = dma_pool_create("xHCI ring segments", dev, - TRB_SEGMENT_SIZE, TRB_SEGMENT_SIZE, xhci->page_size); + /*With xHCI TRB prefetch patch:To fix cross page boundry access issue in IOV environment*/ + if (xhci->quirks & XHCI_ZHAOXIN_TRB_FETCH) { + xhci->segment_pool = dma_pool_create("xHCI ring segments", dev, + TRB_SEGMENT_SIZE*2, TRB_SEGMENT_SIZE*2, xhci->page_size*2); + } else + xhci->segment_pool = dma_pool_create("xHCI ring segments", dev, + TRB_SEGMENT_SIZE, TRB_SEGMENT_SIZE, xhci->page_size); /* See Table 46 and Note on Figure 55 */ xhci->device_pool = dma_pool_create("xHCI input/output contexts", dev, diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c index 712bcb2eab76..c88402cb09ef 100644 --- a/drivers/usb/host/xhci-pci.c +++ b/drivers/usb/host/xhci-pci.c @@ -226,6 +226,11 @@ static void xhci_pci_quirks(struct device *dev, struct xhci_hcd *xhci) pdev->device == 0x3432) xhci->quirks |= XHCI_BROKEN_STREAMS; + if (pdev->vendor == PCI_VENDOR_ID_ZHAOXIN && + (pdev->device == 0x9202 || + pdev->device == 0x9203)) + xhci->quirks |= XHCI_ZHAOXIN_TRB_FETCH; + if (pdev->vendor == PCI_VENDOR_ID_ASMEDIA && pdev->device == 0x1042) xhci->quirks |= XHCI_BROKEN_STREAMS; diff --git a/drivers/usb/host/xhci.h b/drivers/usb/host/xhci.h index 76b872dcb0d9..f285e3cc6aa1 100644 --- a/drivers/usb/host/xhci.h +++ b/drivers/usb/host/xhci.h @@ -1866,6 +1866,7 @@ struct xhci_hcd { #define XHCI_RESET_PLL_ON_DISCONNECT BIT_ULL(34) #define XHCI_SNPS_BROKEN_SUSPEND BIT_ULL(35) #define XHCI_ZHAOXIN_HOST BIT_ULL(36) +#define XHCI_ZHAOXIN_TRB_FETCH BIT_ULL(37) unsigned int num_active_eps; unsigned int limit_active_eps; -- 2.20.1

4 years, 1 month

3
2
0 0

[patch v2] usb: handle warm-reset port requests on hub resume

by LeoLiu-oc

commit 4fdc1790e6a9ef22399c6bc6e63b80f4609f3b7e upstream. On plug-in of my USB-C device, its USB_SS_PORT_LS_SS_INACTIVE link state bit is set. Greping all the kernel for this bit shows that the port status requests a warm-reset this way. This just happens, if its the only device on the root hub, the hub therefore resumes and the HCDs status_urb isn't yet available. If a warm-reset request is detected, this sets the hubs event_bits, which will prevent any auto-suspend and allows the hubs workqueue to warm-reset the port later in port_event. v1->v2: -Resubmit the patch according to the rule of Backport patch. 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 b33ec768404b..22e233afc6f6 100644 --- a/drivers/usb/core/hub.c +++ b/drivers/usb/core/hub.c @@ -1128,6 +1128,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

4 years, 1 month

3
6
0 0

[PATCH openAnolis v1 0/4] support phytium ft2500 platform

by Xin Hao

This patch is provide by vendor phytium to enable ft25000 support Xin Hao (4): PHYTIUM: ACPI: APD: Add clock frequency for for phytium i2c control PHYTIUM: rtc: new driver: rtc-phytium add phytium rtc device support PHYTIUM: ACPICA: ACPI: add support for phytium profiling in GICC PHYTIUM: irqchip:phytium-gic: add phytium new gic control support arch/arm64/Kconfig.platforms | 6 + drivers/acpi/acpi_apd.c | 7 + drivers/i2c/busses/i2c-designware-platdrv.c | 1 + drivers/irqchip/Kconfig | 9 + drivers/irqchip/Makefile | 1 + drivers/irqchip/irq-gic-common.h | 2 + drivers/irqchip/irq-gic-phytium-2500-its.c | 3862 ++++++++++++++++++ drivers/irqchip/irq-gic-phytium-2500.c | 1864 +++++++++ drivers/rtc/Kconfig | 10 + drivers/rtc/Makefile | 1 + drivers/rtc/rtc-phytium.c | 316 ++ include/acpi/actbl2.h | 3 +- include/linux/irqchip/arm-gic-phytium-2500.h | 619 +++ 13 files changed, 6700 insertions(+), 1 deletion(-) create mode 100644 drivers/irqchip/irq-gic-phytium-2500-its.c create mode 100644 drivers/irqchip/irq-gic-phytium-2500.c create mode 100644 drivers/rtc/rtc-phytium.c create mode 100644 include/linux/irqchip/arm-gic-phytium-2500.h -- 2.28.0

4 years, 1 month

4
10
0 0

2025

2024

2023

2022

2021

Cloud Kernel