- Kernel - mailweb.openeuler.org

[PATCH openEuler-5.10 01/18] efi: Make efi_print_memmap() public
by Zheng Zengkai 23 Feb '22

23 Feb '22

From: Ma Wupeng <mawupeng1(a)huawei.com> hulk inclusion category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I4PM01 CVE: NA -------------------------------- Make efi_print_memmap() public in preparation for adding fake memory support for architecture with efi support, eg, arm64. Co-developed-by: Jing Xiangfeng <jingxiangfeng(a)huawei.com> Signed-off-by: Ma Wupeng <mawupeng1(a)huawei.com> Reviewed-by: Kefeng Wang <wangkefeng.wang(a)huawei.com> Signed-off-by: Zheng Zengkai <zhengzengkai(a)huawei.com> --- arch/x86/include/asm/efi.h | 1 - arch/x86/platform/efi/efi.c | 16 ---------------- drivers/firmware/efi/memmap.c | 16 ++++++++++++++++ include/linux/efi.h | 1 + 4 files changed, 17 insertions(+), 17 deletions(-) diff --git a/arch/x86/include/asm/efi.h b/arch/x86/include/asm/efi.h index bc9758ef292e..3be8754408d5 100644 --- a/arch/x86/include/asm/efi.h +++ b/arch/x86/include/asm/efi.h @@ -138,7 +138,6 @@ struct efi_scratch { extern struct efi_scratch efi_scratch; extern int __init efi_memblock_x86_reserve_range(void); -extern void __init efi_print_memmap(void); extern void __init efi_map_region(efi_memory_desc_t *md); extern void __init efi_map_region_fixed(efi_memory_desc_t *md); extern void efi_sync_low_kernel_mappings(void); diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c index 8a26e705cb06..ef6f4cbffe28 100644 --- a/arch/x86/platform/efi/efi.c +++ b/arch/x86/platform/efi/efi.c @@ -323,22 +323,6 @@ static void __init efi_clean_memmap(void) } } -void __init efi_print_memmap(void) -{ - efi_memory_desc_t *md; - int i = 0; - - for_each_efi_memory_desc(md) { - char buf[64]; - - pr_info("mem%02u: %s range=[0x%016llx-0x%016llx] (%lluMB)\n", - i++, efi_md_typeattr_format(buf, sizeof(buf), md), - md->phys_addr, - md->phys_addr + (md->num_pages << EFI_PAGE_SHIFT) - 1, - (md->num_pages >> (20 - EFI_PAGE_SHIFT))); - } -} - static int __init efi_systab_init(unsigned long phys) { int size = efi_enabled(EFI_64BIT) ? sizeof(efi_system_table_64_t) diff --git a/drivers/firmware/efi/memmap.c b/drivers/firmware/efi/memmap.c index 2ff1883dc788..0155bf066ba5 100644 --- a/drivers/firmware/efi/memmap.c +++ b/drivers/firmware/efi/memmap.c @@ -376,3 +376,19 @@ void __init efi_memmap_insert(struct efi_memory_map *old_memmap, void *buf, } } } + +void __init efi_print_memmap(void) +{ + efi_memory_desc_t *md; + int i = 0; + + for_each_efi_memory_desc(md) { + char buf[64]; + + pr_info("mem%02u: %s range=[0x%016llx-0x%016llx] (%lluMB)\n", + i++, efi_md_typeattr_format(buf, sizeof(buf), md), + md->phys_addr, + md->phys_addr + (md->num_pages << EFI_PAGE_SHIFT) - 1, + (md->num_pages >> (20 - EFI_PAGE_SHIFT))); + } +} diff --git a/include/linux/efi.h b/include/linux/efi.h index e17cd4c44f93..280f36cb7c14 100644 --- a/include/linux/efi.h +++ b/include/linux/efi.h @@ -643,6 +643,7 @@ extern int __init efi_memmap_split_count(efi_memory_desc_t *md, struct range *range); extern void __init efi_memmap_insert(struct efi_memory_map *old_memmap, void *buf, struct efi_mem_range *mem); +extern void __init efi_print_memmap(void); #ifdef CONFIG_EFI_ESRT extern void __init efi_esrt_init(void); -- 2.20.1

1 17

[PATCH openEuler-5.10 04/25] ahci: Fix some bugs like plugin support and sata link stability when user enable ahci RTD3
by Zheng Zengkai 23 Feb '22

23 Feb '22

From: LeoLiu-oc <LeoLiu-oc(a)zhaoxin.com> zhaoxin inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I40QDN CVE: NA ---------------------------------------------------------------- The kernel driver now will disable interrupt when port is suspended, causing plugin not work. It is useful to make plugin work，when the plugin interrupt is enabled with power management status. Adding pm_request_resume() is to reume port for plugin or PME signal waking up controller which in D3. with the AHCI controller frequently enters into D3 and leaves from D3, the identify cmd may be timeout when controller resumes and establishes a connect with the device.it is effective to delay 10ms between controller resume and port resume，with link’s smooth transition. with non power management request and power management competing with each other in queue, it is often found that block IO hang 120s when system disk is suspending or resuming.it is now guaranteed that PM requests will enter the queue no matter other non-PM requests are waiting. Increase the pm_only counter before checking whether any non-PM blk_queue_enter() calls are in progress. Meanwhile, the new blk_pm_request_resume() call is necessary to occur during request assigned to a queue when device is suspended. Signed-off-by: LeoLiu-oc <LeoLiu-oc(a)zhaoxin.com> Reviewed-by: Xiongfeng Wang <wangxiongfeng2(a)huawei.com> Signed-off-by: Zheng Zengkai <zhengzengkai(a)huawei.com> --- drivers/ata/ahci.c | 13 +++++++++++++ drivers/ata/libahci.c | 15 +++++++++++++++ 2 files changed, 28 insertions(+) diff --git a/drivers/ata/ahci.c b/drivers/ata/ahci.c index ff2add0101fe..8a7140ee88b5 100644 --- a/drivers/ata/ahci.c +++ b/drivers/ata/ahci.c @@ -869,6 +869,19 @@ static int ahci_pci_device_runtime_resume(struct device *dev) if (rc) return rc; ahci_pci_init_controller(host); + + /* Port resume for Zhaoxin platform */ + if (pdev->vendor == PCI_VENDOR_ID_ZHAOXIN) { + if (pdev->revision == 0x01) + ata_msleep(NULL, 10); + + for (rc = 0; rc < host->n_ports; rc++) { + struct ata_port *ap = host->ports[rc]; + + pm_request_resume(&ap->tdev); + } + } + return 0; } diff --git a/drivers/ata/libahci.c b/drivers/ata/libahci.c index fec2e9754aed..4514f3f28b7c 100644 --- a/drivers/ata/libahci.c +++ b/drivers/ata/libahci.c @@ -823,9 +823,15 @@ static int ahci_set_lpm(struct ata_link *link, enum ata_lpm_policy policy, static void ahci_power_down(struct ata_port *ap) { struct ahci_host_priv *hpriv = ap->host->private_data; + struct pci_dev *pdev; void __iomem *port_mmio = ahci_port_base(ap); u32 cmd, scontrol; + /* port suspended enable Plugin intr for Zhaoxin platform */ + pdev = (ap->dev && dev_is_pci(ap->dev)) ? to_pci_dev(ap->dev) : NULL; + if ((pdev && pdev->vendor == PCI_VENDOR_ID_ZHAOXIN) && !ap->link.device->sdev) + writel(PORT_IRQ_CONNECT, port_mmio + PORT_IRQ_MASK); + if (!(hpriv->cap & HOST_CAP_SSS)) return; @@ -1701,6 +1707,7 @@ static void ahci_error_intr(struct ata_port *ap, u32 irq_stat) struct ata_link *link = NULL; struct ata_queued_cmd *active_qc; struct ata_eh_info *active_ehi; + struct pci_dev *pdev; bool fbs_need_dec = false; u32 serror; @@ -1791,6 +1798,14 @@ static void ahci_error_intr(struct ata_port *ap, u32 irq_stat) ata_ehi_push_desc(host_ehi, "%s", irq_stat & PORT_IRQ_CONNECT ? "connection status changed" : "PHY RDY changed"); + + /* When plugin intr happen, now resume suspended port for Zhaoxin platform */ + pdev = (ap->dev && dev_is_pci(ap->dev)) ? to_pci_dev(ap->dev) : NULL; + if ((pdev && pdev->vendor == PCI_VENDOR_ID_ZHAOXIN) && + (ap->pflags & ATA_PFLAG_SUSPENDED)) { + pm_request_resume(&ap->tdev); + return; + } } /* okay, let's hand over to EH */ -- 2.20.1

1 3

[PATCH openEuler-5.10 01/25] rtc: Fix set RTC time delay 500ms on some Zhaoxin SOCs
by Zheng Zengkai 23 Feb '22

23 Feb '22

From: LeoLiu-oc <LeoLiu-oc(a)zhaoxin.com> zhaoxin inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I40QDN CVE: NA ---------------------------------------------------------------- When the RTC divider is changed from reset to an operating time base, the first update cycle should be 500ms later. But on some Zhaoxin SOCs, this first update cycle is one second later. So set RTC time on these Zhaoxin SOCs will causing 500ms delay. Skip setup RTC divider on these SOCs in mc146818_set_time to fix it. Signed-off-by: LeoLiu-oc <LeoLiu-oc(a)zhaoxin.com> Signed-off-by: Zheng Zengkai <zhengzengkai(a)huawei.com> Reviewed-by: Xiongfeng Wang <wangxiongfeng2(a)huawei.com> --- drivers/rtc/rtc-mc146818-lib.c | 26 +++++++++++++++++++++++--- 1 file changed, 23 insertions(+), 3 deletions(-) diff --git a/drivers/rtc/rtc-mc146818-lib.c b/drivers/rtc/rtc-mc146818-lib.c index 2ecd8752b088..033dcc0645a5 100644 --- a/drivers/rtc/rtc-mc146818-lib.c +++ b/drivers/rtc/rtc-mc146818-lib.c @@ -8,6 +8,22 @@ #include <linux/acpi.h> #endif +#ifdef CONFIG_X86 +static inline bool follow_mc146818_divider_reset(void) +{ + if ((boot_cpu_data.x86_vendor == X86_VENDOR_CENTAUR || + boot_cpu_data.x86_vendor == X86_VENDOR_ZHAOXIN) && + (boot_cpu_data.x86 <= 7 && boot_cpu_data.x86_model <= 59)) + return false; + return true; +} +#else +static inline bool follow_mc146818_divider_reset(void) +{ + return true; +} +#endif + /* * Returns true if a clock update is in progress */ @@ -171,8 +187,11 @@ int mc146818_set_time(struct rtc_time *time) save_control = CMOS_READ(RTC_CONTROL); CMOS_WRITE((save_control|RTC_SET), RTC_CONTROL); - save_freq_select = CMOS_READ(RTC_FREQ_SELECT); - CMOS_WRITE((save_freq_select|RTC_DIV_RESET2), RTC_FREQ_SELECT); + if (follow_mc146818_divider_reset()) { + save_freq_select = CMOS_READ(RTC_FREQ_SELECT); + CMOS_WRITE((save_freq_select|RTC_DIV_RESET2), RTC_FREQ_SELECT); + } + #ifdef CONFIG_MACH_DECSTATION CMOS_WRITE(real_yrs, RTC_DEC_YEAR); @@ -190,7 +209,8 @@ int mc146818_set_time(struct rtc_time *time) #endif CMOS_WRITE(save_control, RTC_CONTROL); - CMOS_WRITE(save_freq_select, RTC_FREQ_SELECT); + if (follow_mc146818_divider_reset()) + CMOS_WRITE(save_freq_select, RTC_FREQ_SELECT); spin_unlock_irqrestore(&rtc_lock, flags); -- 2.20.1

1 24

[PATCH openEuler-1.0-LTS] ext4: fix underflow in ext4_max_bitmap_size()
by Yang Yingliang 23 Feb '22

23 Feb '22

From: Zhang Yi <yi.zhang(a)huawei.com> hulk inclusion category: bugfix bugzilla: 186216, https://gitee.com/openeuler/kernel/issues/I4PW7R CVE: NA -------------------------------- The same to commit 1c2d14212b15 ("ext2: Fix underflow in ext2_max_size()") in ext2 filesystem, ext4 driver has the same issue with 64K block size and ^huge_file, fix this issue the same as ext2. This patch also revert commit 75ca6ad408f4 ("ext4: fix loff_t overflow in ext4_max_bitmap_size()") because it's no longer needed. Signed-off-by: Zhang Yi <yi.zhang(a)huawei.com> Conflicts: fs/ext4/super.c Signed-off-by: Baokun Li <libaokun1(a)huawei.com> Reviewed-by: Yang Erkun <yangerkun(a)huawei.com> Signed-off-by: Yang Yingliang <yangyingliang(a)huawei.com> --- fs/ext4/super.c | 46 +++++++++++++++++++++++++++++++--------------- 1 file changed, 31 insertions(+), 15 deletions(-) diff --git a/fs/ext4/super.c b/fs/ext4/super.c index 59637e70f9e32..8f9d60ec607ea 100644 --- a/fs/ext4/super.c +++ b/fs/ext4/super.c @@ -2958,9 +2958,10 @@ static loff_t ext4_max_size(int blkbits, int has_huge_files) */ static loff_t ext4_max_bitmap_size(int bits, int has_huge_files) { - loff_t res = EXT4_NDIR_BLOCKS; + loff_t upper_limit, res = EXT4_NDIR_BLOCKS; int meta_blocks; - loff_t upper_limit; + unsigned int ppb = 1 << (bits - 2); + /* This is calculated to be the largest file size for a dense, block * mapped file such that the file's total number of 512-byte sectors, * including data and all indirect blocks, does not exceed (2^48 - 1). @@ -2991,23 +2992,38 @@ static loff_t ext4_max_bitmap_size(int bits, int has_huge_files) } - /* indirect blocks */ - meta_blocks = 1; - /* double indirect blocks */ - meta_blocks += 1 + (1LL << (bits-2)); - /* tripple indirect blocks */ - meta_blocks += 1 + (1LL << (bits-2)) + (1LL << (2*(bits-2))); - - upper_limit -= meta_blocks; - upper_limit <<= bits; - + /* Compute how many blocks we can address by block tree */ res += 1LL << (bits-2); res += 1LL << (2*(bits-2)); res += 1LL << (3*(bits-2)); + /* Compute how many metadata blocks are needed */ + meta_blocks = 1; + meta_blocks += 1 + ppb; + meta_blocks += 1 + ppb + ppb * ppb; + /* Does block tree limit file size? */ + if (res + meta_blocks <= upper_limit) + goto check_lfs; + + res = upper_limit; + /* How many metadata blocks are needed for addressing upper_limit? */ + upper_limit -= EXT4_NDIR_BLOCKS; + /* indirect blocks */ + meta_blocks = 1; + upper_limit -= ppb; + /* double indirect blocks */ + if (upper_limit < ppb * ppb) { + meta_blocks += 1 + DIV_ROUND_UP(upper_limit, ppb); + res -= meta_blocks; + goto check_lfs; + } + meta_blocks += 1 + ppb; + upper_limit -= ppb * ppb; + /* tripple indirect blocks for the rest */ + meta_blocks += 1 + DIV_ROUND_UP(upper_limit, ppb) + + DIV_ROUND_UP(upper_limit, ppb*ppb); + res -= meta_blocks; +check_lfs: res <<= bits; - if (res > upper_limit) - res = upper_limit; - if (res > MAX_LFS_FILESIZE) res = MAX_LFS_FILESIZE; -- 2.25.1

1 0

[PATCH OLK-5.10 v4 0/7] Backport zhaoxin enhancement and bugfix
by Zheng Zengkai 23 Feb '22

23 Feb '22

v3->v4: Refector 0001 patch. v2->v3: Fix compile warning "ahci_error_intr ISO C90 forbids mixed declarations and code" Backport zhaoxin enhancement and bugfix patches. LeoLiu-oc (7): rtc: Fix set RTC time delay 500ms on some Zhaoxin SOCs XHCI:Fix some device identify fail when enable xHCI runtime suspend EHCI:Clear wakeup signal locked in S0 state when device plug in Fix some bugs like plugin support and sata link stability when user enable ahci RTD3 Add support for disabling PhyRdy Change Interrupt based on actual LPM capability Add support for PxSCT.LPM set based on actual LPM capability x86/tsc: Make cur->adjusted values in package#1 to be the same arch/x86/kernel/tsc_sync.c | 5 +++++ drivers/ata/ahci.c | 24 ++++++++++++++++++++++++ drivers/ata/libahci.c | 15 +++++++++++++++ drivers/ata/libata-eh.c | 7 +++++++ drivers/ata/libata-sata.c | 20 ++++++++++++++++++-- drivers/pci/pci-driver.c | 6 +++++- drivers/rtc/rtc-mc146818-lib.c | 28 +++++++++++++++++++++++++--- drivers/usb/host/ehci-hcd.c | 21 +++++++++++++++++++++ drivers/usb/host/ehci-pci.c | 4 ++++ drivers/usb/host/ehci.h | 1 + drivers/usb/host/xhci-pci.c | 2 ++ include/linux/libata.h | 4 ++++ 12 files changed, 131 insertions(+), 6 deletions(-) -- 2.20.1

2 9

[PATCH openEuler-5.10 01/90] ACPICA: Interpreter: fix memory leak by using existing buffer
by Zheng Zengkai 23 Feb '22

23 Feb '22

From: Erik Kaneda <erik.kaneda(a)intel.com> mainline inclusion from mainline-v5.11-rc1 commit 32cf1a12cad43358e47dac8014379c2f33dfbed4 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I4T7OX CVE: NA -------------------------------- ACPICA commit 52d1da5dcbd79a722b70f02a1a83f04088f51ff6 There was a memory leak that ocurred when a _CID object is defined as a package containing string objects. When _CID is checked for any possible repairs, it calls a helper function to repair _HID (because _CID basically contains multiple _HID entries). The _HID repair function assumes that string objects are standalone objects that are not contained inside of any packages. The _HID repair function replaces the string object with a brand new object and attempts to delete the old object by decrementing the reference count of the old object. Strings inside of packages have a reference count of 2 so the _HID repair function leaves this object in a dangling state and causes a memory leak. Instead of allocating a brand new object and removing the old object, use the existing object when repairing the _HID object. Link: https://github.com/acpica/acpica/commit/52d1da5d Signed-off-by: Erik Kaneda <erik.kaneda(a)intel.com> Signed-off-by: Bob Moore <robert.moore(a)intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki(a)intel.com> Conflicts: drivers/acpi/acpica/nsrepair2.c [wangxiongfeng: fix conflicts caused by context mismatch] Signed-off-by: Xiongfeng Wang <wangxiongfeng2(a)huawei.com> Reviewed-by: Hanjun Guo <guohanjun(a)huawei.com> Signed-off-by: Zheng Zengkai <zhengzengkai(a)huawei.com> --- drivers/acpi/acpica/nsrepair2.c | 17 ++++------------- 1 file changed, 4 insertions(+), 13 deletions(-) diff --git a/drivers/acpi/acpica/nsrepair2.c b/drivers/acpi/acpica/nsrepair2.c index 125143c41bb8..fb4f8f6209bd 100644 --- a/drivers/acpi/acpica/nsrepair2.c +++ b/drivers/acpi/acpica/nsrepair2.c @@ -491,9 +491,8 @@ acpi_ns_repair_HID(struct acpi_evaluate_info *info, union acpi_operand_object **return_object_ptr) { union acpi_operand_object *return_object = *return_object_ptr; - union acpi_operand_object *new_string; - char *source; char *dest; + char *source; ACPI_FUNCTION_NAME(ns_repair_HID); @@ -514,13 +513,6 @@ acpi_ns_repair_HID(struct acpi_evaluate_info *info, return (AE_OK); } - /* It is simplest to always create a new string object */ - - new_string = acpi_ut_create_string_object(return_object->string.length); - if (!new_string) { - return (AE_NO_MEMORY); - } - /* * Remove a leading asterisk if present. For some unknown reason, there * are many machines in the field that contains IDs like this. @@ -530,7 +522,7 @@ acpi_ns_repair_HID(struct acpi_evaluate_info *info, source = return_object->string.pointer; if (*source == '*') { source++; - new_string->string.length--; + return_object->string.length--; ACPI_DEBUG_PRINT((ACPI_DB_REPAIR, "%s: Removed invalid leading asterisk\n", @@ -545,12 +537,11 @@ acpi_ns_repair_HID(struct acpi_evaluate_info *info, * "NNNN####" where N is an uppercase letter or decimal digit, and * # is a hex digit. */ - for (dest = new_string->string.pointer; *source; dest++, source++) { + for (dest = return_object->string.pointer; *source; dest++, source++) { *dest = (char)toupper((int)*source); } + return_object->string.pointer[return_object->string.length] = 0; - acpi_ut_remove_reference(return_object); - *return_object_ptr = new_string; return (AE_OK); } -- 2.20.1

2 91

Re: [PATCH OLK-5.10 v3 3/7] EHCI: Clear wakeup signal locked in S0 state when device plug in
by Zheng Zengkai 23 Feb '22

23 Feb '22

Loop Leo 在 2022/2/22 17:49, Jackie Liu 写道: > > > 在 2022/2/22 下午4:16, Zheng Zengkai 写道: >> From: LeoLiu-oc <LeoLiu-oc(a)zhaoxin.com> >> >> zhaoxin inclusion >> category: feature >> bugzilla: https://gitee.com/openeuler/kernel/issues/I40QDN >> CVE: NA >> >> ---------------------------------------------------------------- >> >> If we plug in a LS/FS device on USB2 port of EHCI, it will latch a wakeup >> signal in EHCI internal. This is a bug of EHCI for Some project of >> ZhaoXin. If enable EHCI runtime suspend and no device attach. >> PM core will let EHCI go to D3 to save power. However, once EHCI go to D3, >> it will release wakeup signal that latched on device connect to port >> during S0. Which will generate a SCI interrupt and bring EHCI to D0. >> But without device connect, EHCI will go to D3 again. >> So, there is suspend-resume loop and generate SCI interrupt Continuously. >> >> In order to fix this issues, we need to clear the wakeup signal latched >> in EHCI when EHCI suspend function is called. >> >> Signed-off-by: LeoLiu-oc <LeoLiu-oc(a)zhaoxin.com> >> Signed-off-by: Zheng Zengkai <zhengzengkai(a)huawei.com> >> --- >> drivers/pci/pci-driver.c | 6 +++++- >> drivers/usb/host/ehci-hcd.c | 21 +++++++++++++++++++++ >> drivers/usb/host/ehci-pci.c | 4 ++++ >> drivers/usb/host/ehci.h | 1 + >> 4 files changed, 31 insertions(+), 1 deletion(-) >> >> diff --git a/drivers/pci/pci-driver.c b/drivers/pci/pci-driver.c >> index 8b587fc97f7b..c33d7e0a60b5 100644 >> --- a/drivers/pci/pci-driver.c >> +++ b/drivers/pci/pci-driver.c >> @@ -518,7 +518,11 @@ static int pci_restore_standard_config(struct pci_dev *pci_dev) >> } >> >> pci_restore_state(pci_dev); >> - pci_pme_restore(pci_dev); >> + if (!((pci_dev->vendor == PCI_VENDOR_ID_ZHAOXIN) && >> + (pci_dev->device == 0x3104) && >> + ((pci_dev->revision & 0xf0) == 0x90)) || > >> + !(pci_dev->class == PCI_CLASS_SERIAL_USB_EHCI)) > 上面这句话是不是改变了通用逻辑？增加了一个 pci_dev->class != > PCI_CLASS_SERIAL_USB_EHCI 才进行 restore？ > >> + pci_pme_restore(pci_dev); >> return 0; >> } >> >> diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c >> index 8aff19ff8e8f..586e2735d6e0 100644 >> --- a/drivers/usb/host/ehci-hcd.c >> +++ b/drivers/usb/host/ehci-hcd.c >> @@ -1142,6 +1142,27 @@ int ehci_suspend(struct usb_hcd *hcd, bool do_wakeup) >> return -EBUSY; >> } >> >> + /*clear wakeup signal locked in S0 state when device plug in*/ >> + if (ehci->zx_wakeup_clear == 1) { >> + u32 __iomem *reg = &ehci->regs->port_status[4]; >> + u32 t1 = ehci_readl(ehci, reg); >> + >> + t1 &= (u32)~0xf0000; >> + t1 |= PORT_TEST_FORCE; >> + ehci_writel(ehci, t1, reg); >> + t1 = ehci_readl(ehci, reg); >> + usleep_range(1000, 2000); >> + t1 &= (u32)~0xf0000; >> + ehci_writel(ehci, t1, reg); >> + usleep_range(1000, 2000); >> + t1 = ehci_readl(ehci, reg); >> + ehci_writel(ehci, t1 | PORT_CSC, reg); >> + udelay(500); >> + t1 = ehci_readl(ehci, &ehci->regs->status); >> + ehci_writel(ehci, t1 & STS_PCD, &ehci->regs->status); >> + ehci_readl(ehci, &ehci->regs->status); >> + } >> + >> return 0; >> } >> EXPORT_SYMBOL_GPL(ehci_suspend); >> diff --git a/drivers/usb/host/ehci-pci.c b/drivers/usb/host/ehci-pci.c >> index e87cf3a00fa4..a5e27deda83a 100644 >> --- a/drivers/usb/host/ehci-pci.c >> +++ b/drivers/usb/host/ehci-pci.c >> @@ -222,6 +222,10 @@ static int ehci_pci_setup(struct usb_hcd *hcd) >> ehci->has_synopsys_hc_bug = 1; >> } >> break; >> + case PCI_VENDOR_ID_ZHAOXIN: >> + if (pdev->device == 0x3104 && (pdev->revision & 0xf0) == 0x90) >> + ehci->zx_wakeup_clear = 1; >> + break; >> } >> >> /* optional debug port, normally in the first BAR */ >> diff --git a/drivers/usb/host/ehci.h b/drivers/usb/host/ehci.h >> index 59fd523c55f3..8da080a54668 100644 >> --- a/drivers/usb/host/ehci.h >> +++ b/drivers/usb/host/ehci.h >> @@ -219,6 +219,7 @@ struct ehci_hcd { /* one per controller */ >> unsigned need_oc_pp_cycle:1; /* MPC834X port power */ >> unsigned imx28_write_fix:1; /* For Freescale i.MX28 */ >> unsigned is_aspeed:1; >> + unsigned zx_wakeup_clear:1; >> >> /* required for usb32 quirk */ >> #define OHCI_CTRL_HCFS (3 << 6) >> >> >> Content-type: Text/plain >> >> No virus found >> Checked by Hillstone Network AntiVirus

2 1

Re: [PATCH OLK-5.10 v3 1/7] rtc: Fix set RTC time delay 500ms on some Zhaoxin SOCs
by Zheng Zengkai 23 Feb '22

23 Feb '22

Hi Jackie, Leo 在 2022/2/22 17:46, Jackie Liu 写道: > > > 在 2022/2/22 下午4:16, Zheng Zengkai 写道: >> From: LeoLiu-oc <LeoLiu-oc(a)zhaoxin.com> >> >> zhaoxin inclusion >> category: bugfix >> bugzilla: https://gitee.com/openeuler/kernel/issues/I40QDN >> CVE: NA >> >> ---------------------------------------------------------------- >> >> When the RTC divider is changed from reset to an operating time base, >> the first update cycle should be 500ms later. But on some Zhaoxin SOCs, >> this first update cycle is one second later. >> So set RTC time on these Zhaoxin SOCs will causing 500ms delay. >> Skip setup RTC divider on these SOCs in mc146818_set_time to fix it. >> >> Signed-off-by: LeoLiu-oc <LeoLiu-oc(a)zhaoxin.com> >> Signed-off-by: Zheng Zengkai <zhengzengkai(a)huawei.com> >> --- >> drivers/rtc/rtc-mc146818-lib.c | 16 ++++++++++++++++ >> 1 file changed, 16 insertions(+) >> >> diff --git a/drivers/rtc/rtc-mc146818-lib.c b/drivers/rtc/rtc-mc146818-lib.c >> index 2ecd8752b088..96d9d0219394 100644 >> --- a/drivers/rtc/rtc-mc146818-lib.c >> +++ b/drivers/rtc/rtc-mc146818-lib.c >> @@ -171,8 +171,17 @@ int mc146818_set_time(struct rtc_time *time) >> >> save_control = CMOS_READ(RTC_CONTROL); >> CMOS_WRITE((save_control|RTC_SET), RTC_CONTROL); >> +#ifdef CONFIG_X86 >> + if (!((boot_cpu_data.x86_vendor == X86_VENDOR_CENTAUR || >> + boot_cpu_data.x86_vendor == X86_VENDOR_ZHAOXIN) && >> + (boot_cpu_data.x86 <= 7 && boot_cpu_data.x86_model <= 59))) { >> + save_freq_select = CMOS_READ(RTC_FREQ_SELECT); >> + CMOS_WRITE((save_freq_select|RTC_DIV_RESET2), RTC_FREQ_SELECT); >> + } >> +#else >> save_freq_select = CMOS_READ(RTC_FREQ_SELECT); >> CMOS_WRITE((save_freq_select|RTC_DIV_RESET2), RTC_FREQ_SELECT); >> +#endif >> >> #ifdef CONFIG_MACH_DECSTATION >> CMOS_WRITE(real_yrs, RTC_DEC_YEAR); >> @@ -190,7 +199,14 @@ int mc146818_set_time(struct rtc_time *time) >> #endif >> >> CMOS_WRITE(save_control, RTC_CONTROL); >> +#ifdef CONFIG_X86 >> + if (!((boot_cpu_data.x86_vendor == X86_VENDOR_CENTAUR || >> + boot_cpu_data.x86_vendor == X86_VENDOR_ZHAOXIN) && >> + (boot_cpu_data.x86 <= 7 && boot_cpu_data.x86_model <= 59))) > 在这里直接写个 #endif 后面的 else 和 endif 就不需要了 > >> + CMOS_WRITE(save_freq_select, RTC_FREQ_SELECT); >> +#else >> CMOS_WRITE(save_freq_select, RTC_FREQ_SELECT); >> +#endif 这里依据上次兆芯同事解释的代码逻辑： X86架构情况下，兆芯的相应平台不执行CMOS_WRITE(save_freq_select, RTC_FREQ_SELECT), 即 commit message中Skip setup RTC divider on these SOCs in mc146818_set_time to fix it; 而其他架构(#else 分支)，仍然需要执行CMOS_WRITE(save_freq_select, RTC_FREQ_SELECT); @Jackie @ Leo，两位看下理解是否OK？ >> >> spin_unlock_irqrestore(&rtc_lock, flags); >> >> >> >> Content-type: Text/plain >> >> No virus found >> Checked by Hillstone Network AntiVirus

2 1

Re: [PATCH OLK-5.10 v3 3/7] EHCI: Clear wakeup signal locked in S0 state when device plug in
by Zheng Zengkai 23 Feb '22

23 Feb '22

Hi Jackie, 在 2022/2/22 17:49, Jackie Liu 写道: > > > 在 2022/2/22 下午4:16, Zheng Zengkai 写道: >> From: LeoLiu-oc <LeoLiu-oc(a)zhaoxin.com> >> >> zhaoxin inclusion >> category: feature >> bugzilla: https://gitee.com/openeuler/kernel/issues/I40QDN >> CVE: NA >> >> ---------------------------------------------------------------- >> >> If we plug in a LS/FS device on USB2 port of EHCI, it will latch a wakeup >> signal in EHCI internal. This is a bug of EHCI for Some project of >> ZhaoXin. If enable EHCI runtime suspend and no device attach. >> PM core will let EHCI go to D3 to save power. However, once EHCI go to D3, >> it will release wakeup signal that latched on device connect to port >> during S0. Which will generate a SCI interrupt and bring EHCI to D0. >> But without device connect, EHCI will go to D3 again. >> So, there is suspend-resume loop and generate SCI interrupt Continuously. >> >> In order to fix this issues, we need to clear the wakeup signal latched >> in EHCI when EHCI suspend function is called. >> >> Signed-off-by: LeoLiu-oc <LeoLiu-oc(a)zhaoxin.com> >> Signed-off-by: Zheng Zengkai <zhengzengkai(a)huawei.com> >> --- >> drivers/pci/pci-driver.c | 6 +++++- >> drivers/usb/host/ehci-hcd.c | 21 +++++++++++++++++++++ >> drivers/usb/host/ehci-pci.c | 4 ++++ >> drivers/usb/host/ehci.h | 1 + >> 4 files changed, 31 insertions(+), 1 deletion(-) >> >> diff --git a/drivers/pci/pci-driver.c b/drivers/pci/pci-driver.c >> index 8b587fc97f7b..c33d7e0a60b5 100644 >> --- a/drivers/pci/pci-driver.c >> +++ b/drivers/pci/pci-driver.c >> @@ -518,7 +518,11 @@ static int pci_restore_standard_config(struct pci_dev *pci_dev) >> } >> >> pci_restore_state(pci_dev); >> - pci_pme_restore(pci_dev); >> + if (!((pci_dev->vendor == PCI_VENDOR_ID_ZHAOXIN) && >> + (pci_dev->device == 0x3104) && >> + ((pci_dev->revision & 0xf0) == 0x90)) || > >> + !(pci_dev->class == PCI_CLASS_SERIAL_USB_EHCI)) > 上面这句话是不是改变了通用逻辑？增加了一个 pci_dev->class != > PCI_CLASS_SERIAL_USB_EHCI 才进行 restore？ > >> + pci_pme_restore(pci_dev); 逻辑上应该是和！((pci_dev->vendor == PCI_VENDOR_ID_ZHAOXIN) && (pci_dev->device == 0x3104) && ((pci_dev->revision & 0xf0) == 0x90) && (pci_dev->class == PCI_CLASS_SERIAL_USB_EHCI)）等同的, 即只有zhaoxin的0x3104 devid的PCI_CLASS_SERIAL_USB_EHCI设备不做pci_pme_restore(pci_dev)操作 >> return 0; >> } >> >> diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c >> index 8aff19ff8e8f..586e2735d6e0 100644 >> --- a/drivers/usb/host/ehci-hcd.c >> +++ b/drivers/usb/host/ehci-hcd.c >> @@ -1142,6 +1142,27 @@ int ehci_suspend(struct usb_hcd *hcd, bool do_wakeup) >> return -EBUSY; >> } >> >> + /*clear wakeup signal locked in S0 state when device plug in*/ >> + if (ehci->zx_wakeup_clear == 1) { >> + u32 __iomem *reg = &ehci->regs->port_status[4]; >> + u32 t1 = ehci_readl(ehci, reg); >> + >> + t1 &= (u32)~0xf0000; >> + t1 |= PORT_TEST_FORCE; >> + ehci_writel(ehci, t1, reg); >> + t1 = ehci_readl(ehci, reg); >> + usleep_range(1000, 2000); >> + t1 &= (u32)~0xf0000; >> + ehci_writel(ehci, t1, reg); >> + usleep_range(1000, 2000); >> + t1 = ehci_readl(ehci, reg); >> + ehci_writel(ehci, t1 | PORT_CSC, reg); >> + udelay(500); >> + t1 = ehci_readl(ehci, &ehci->regs->status); >> + ehci_writel(ehci, t1 & STS_PCD, &ehci->regs->status); >> + ehci_readl(ehci, &ehci->regs->status); >> + } >> + >> return 0; >> } >> EXPORT_SYMBOL_GPL(ehci_suspend); >> diff --git a/drivers/usb/host/ehci-pci.c b/drivers/usb/host/ehci-pci.c >> index e87cf3a00fa4..a5e27deda83a 100644 >> --- a/drivers/usb/host/ehci-pci.c >> +++ b/drivers/usb/host/ehci-pci.c >> @@ -222,6 +222,10 @@ static int ehci_pci_setup(struct usb_hcd *hcd) >> ehci->has_synopsys_hc_bug = 1; >> } >> break; >> + case PCI_VENDOR_ID_ZHAOXIN: >> + if (pdev->device == 0x3104 && (pdev->revision & 0xf0) == 0x90) >> + ehci->zx_wakeup_clear = 1; >> + break; >> } >> >> /* optional debug port, normally in the first BAR */ >> diff --git a/drivers/usb/host/ehci.h b/drivers/usb/host/ehci.h >> index 59fd523c55f3..8da080a54668 100644 >> --- a/drivers/usb/host/ehci.h >> +++ b/drivers/usb/host/ehci.h >> @@ -219,6 +219,7 @@ struct ehci_hcd { /* one per controller */ >> unsigned need_oc_pp_cycle:1; /* MPC834X port power */ >> unsigned imx28_write_fix:1; /* For Freescale i.MX28 */ >> unsigned is_aspeed:1; >> + unsigned zx_wakeup_clear:1; >> >> /* required for usb32 quirk */ >> #define OHCI_CTRL_HCFS (3 << 6) >> >> >> Content-type: Text/plain >> >> No virus found >> Checked by Hillstone Network AntiVirus

1 0

[PATCH OLK-5.10,v4,0/3] Add support for kunpeng920 Ultrasoc System Memory Buffer driver
by Qi Liu 23 Feb '22

23 Feb '22

Add support for kunpeng920 Ultrasoc System Memory Buffer driver v3->4: Resend this patchset as openeuler maillist hasn't received patch[1/3] in v3 series. Qi Liu (3): coresight: etm4x: Modify core-commit to avoid HiSilicon ETM overflow drivers/coresight: Add Ultrasoc System Memory Buffer driver arm64: openeuler_defconfig: Enable config for ultrasoc driver arch/arm64/configs/openeuler_defconfig | 13 +- drivers/hwtracing/coresight/Kconfig | 20 + drivers/hwtracing/coresight/Makefile | 1 + .../coresight/coresight-etm4x-core.c | 98 +++ drivers/hwtracing/coresight/coresight-etm4x.h | 8 + drivers/hwtracing/coresight/ultrasoc-smb.c | 602 ++++++++++++++++++ drivers/hwtracing/coresight/ultrasoc-smb.h | 100 +++ 7 files changed, 841 insertions(+), 1 deletion(-) create mode 100644 drivers/hwtracing/coresight/ultrasoc-smb.c create mode 100644 drivers/hwtracing/coresight/ultrasoc-smb.h -- 2.33.0

1 3