From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 52608C43217 for ; Wed, 16 Nov 2022 10:43:24 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238581AbiKPKnW (ORCPT ); Wed, 16 Nov 2022 05:43:22 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52108 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S238605AbiKPKm5 (ORCPT ); Wed, 16 Nov 2022 05:42:57 -0500 Received: from us-smtp-delivery-115.mimecast.com (us-smtp-delivery-115.mimecast.com [170.10.129.115]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id EE8D540474 for ; Wed, 16 Nov 2022 02:30:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=maxlinear.com; s=selector; t=1668594601; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=/gE01YR1VoS3Sv/S7ZKZi1MOxZyMrH2MOmc3kbSaN0Q=; b=IPWbQjXYV71iXpoCuHeQKikD/eu9iFD/04U5sGwl+ovKPXuPsN8xdxKYtjINHUu5sH56Zl xsTTqibjJwndOBU1olGltCla0afauzekTZaTF7zAyARNsdUEFUiJHthEH1lldsW+/qBzgK SlHOwNSLkY4y59fTXUbomld0g0j4qZQYQaKg0iC5dmH4nOLi/waJ90IoLGLDgSHqkMXYxD cd6vQ2PcyQ2SiJlx7R9QsRo6lKznmkk/OnmFZwVoPuYjkQTxsi78LPY3TYfbWKqIIDTMdH Zar9qYoP38VqK1+xqEJSZ21zjVyfGORw6Un+XBWIAax19hRyrrnCaiAU2EsvBA== Received: from mail.maxlinear.com (174-47-1-83.static.ctl.one [174.47.1.83]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id us-mta-314-Tpq0nae2NIO1dmxz6cOAWQ-1; Wed, 16 Nov 2022 05:28:31 -0500 X-MC-Unique: Tpq0nae2NIO1dmxz6cOAWQ-1 Received: from sgsxdev001.isng.phoenix.local (10.226.81.111) by mail.maxlinear.com (10.23.38.120) with Microsoft SMTP Server id 15.1.2375.24; Wed, 16 Nov 2022 02:28:25 -0800 From: Rahul Tanwar To: , , , , , , , CC: , , , , , , , , "Rahul Tanwar" Subject: [PATCH v2 0/2] x86/of: Fix a bug in x86 arch OF support Date: Wed, 16 Nov 2022 18:28:19 +0800 Message-ID: X-Mailer: git-send-email 2.17.1 MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: maxlinear.com Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org + devicetree@vger.kernel.org Hi Sebastian, All touched part in this patch series was added by you. Hoping for concerns/comments or best case ACK, reviewed-by tag from you. I have CCed all others who were involved with you when you added this changes. Hi devicetree@vger.kernel.org, Rob, Since this appears to be entrirely in devicetree domain. Hoping for feedback, concerns, mistakes or improvement feedbacks from you. Hi Andy, Hoping for a reviewed-by tag from you once you think it is ready to go. Thanks. Hi Thomas, Ingo, Boris, Andy, Dave & all x86@kernel.org maintainers, Resending below details hoping to figure out if the changes are logically aligned with your understanding & that it will not break any x86/arch concerns that you might have. Shooting on any mistakes welcomed :-). I sent this patch 3 times but for some reasons, never got any response or attention from anybody so far. Hence, resending with a cover letter to explain the rationale behind it in detail & to justify the need to add this fix. Also, hoping to get some feedback in-case i am mistaken in my understanding which might be the reason why i never got any response. Background (baseline understanding - pls correct if mistaken anywhere): References [1], [2] & [6] For SMP systems, Intel defines three (logically four) interrupt modes during boot/init time while BIOS/bootloader boots & switches to linux kernel. 1. PIC mode - Legacy 8259 PIC interrupt controller. 2. Virtual wire mode via Local APIC - uses local APIC as virtual wire 3. Virtual wire mode via I/O APIC - uses I/O APIC as virtual wire 4. Symmetric I/O mode - final one used by linux for SMP systems.=20 BIOS/bootloaders are supposed to boot in either #1 or #2 or #3 and then switch to #4 in linux for SMP systems. For our platform, we use #2. Detection of which interrupt mode the system is booting in is made by using below global variable in apic.c int pic_mode __ro_after_init;=20 Here pic_mode =3D 1 means #1 (PIC mode) above. And pic_mode =3D 0 means #2 or #3 (basically virtual wire mode via apic). And apic.c while doing setup_local_APIC() uses below code [3]: value =3D apic_read(APIC_LVT0) & APIC_LVT_MASKED; if (!cpu && (pic_mode || !value || skip_ioapic_setup)) { value =3D APIC_DM_EXTINT; apic_printk(APIC_VERBOSE, "enabled ExtINT on CPU#%d\n", cpu= ); } else { value =3D APIC_DM_EXTINT | APIC_LVT_MASKED; apic_printk(APIC_VERBOSE, "masked ExtINT on CPU#%d\n", cpu)= ; } apic_write(APIC_LVT0, value); What i understand from above is that if at this point of time, as long as it is cpu0 & pic_mode=3D1, it will set delivery mode to ExtINT (causes the processor to respond to the interrupt as if the interrupt originated in an externally connected (8259A-compatible) interrupt controller) and enables/ unmask the interrupts. pic_mode is presently set/populated/initialized at only two places: 1. In mpparse.c [4] 2. In devicetree.c [7] For #1 MPPARSE Kconfig definition is as below: =09config X86_MPPARSE =09bool "Enable MPS table" if ACPI =09default y =09depends on X86_LOCAL_APIC =09help =09For old smp systems that do not have proper acpi support. Newe= r systems =09(esp with 64bit cpus) with acpi support, MADT and DSDT will ov= erride it As seen above, if ACPI is not enabled, then mpparse by default is always enabled. Presently, there is no way to disable MPPARSE (if ACPI is not enabled). This to me appears to be another bug which needs fixing. As per theory, MPPARSE was to support MPS spec [1] as a temporary solution to support SMP systems until a final ACPI standard was added. But now if ACPI is not enabled, it will rely on MPPARSE driver to read MP floating pointer structure's IMCRP Bit 7 of MP feature info byte 2 [5] to figure out if it supports PIC mode or virtual wire mode and initialize pic_mode variable accordingly. If ACPI is enabled, the ACPI code overrides it by using the MADT table spec'ed in ACPI spec [2].=20 For #2 devicetree.c presently hardcodes pic_mode =3D 1 (PIC Mode). There is no support to configure virtual wire mode via devicetree path for OF based systems. Now we have a platform which is OF based & does not use legacy 8259 PIC interrupt controller. Non ACPI compliant as well as non MPPARSE compliant. For such platforms, it appears to me that hardcoding pic_mode =3D 1 (PIC Mo= de) and giving no other choice to choose virtual wire mode is a bug for OF based x86 platforms.=20 Just like mpparse relies on IMCRP bit 7 of MP feature info byte2 [5] to select pic_mode to PIC mode or virtual wire mode. arch/x86/kernel/devicetre= e.c should also provide some similar configurability to choose interrupt delivery mode & not hardcode it to PIC mode. This patch is to fix above explained bug in x86/of support for interrupt delivery mode configuration. Please let me know if you find any mistake in above understanding or if you have a alternative better suggestion to solve it or if you find anything odd here in our platform/system. TIA. The patch is baselined on below git tree: git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86/core [1] https://pdos.csail.mit.edu/6.828/2008/readings/ia32/MPspec.pdf [2] https://uefi.org/sites/default/files/resources/ACPI_6_3_final_Jan30.pdf [3] https://elixir.bootlin.com/linux/v6.1-rc5/source/arch/x86/kernel/apic/a= pic.c#L1691 [4] https://elixir.bootlin.com/linux/v6.1-rc5/source/arch/x86/kernel/mppars= e.c#L517 [5] https://www.manualslib.com/manual/77733/Intel-Multiprocessor.html?page= =3D40#manual [6] https://www.intel.com/content/www/us/en/developer/articles/technical/in= tel-sdm.html [7] https://elixir.bootlin.com/linux/v6.1-rc5/source/arch/x86/kernel/device= tree.c#L170 v2: - Address review concern from Andy - rename property name to make it a bit more positive & self explanatory. - Found that the bindings document for these HW's (APIC) are a bit off/obsolete and still in text format. Created new YAML schemas one for each - lapic & ioapic. Updated these schemas with latest info and add in new optional property details in the updated schema for lapic. Delete/let go of the text binding doc. - CC devicetree@vger.kernel.org as these changes appear to be mainly targeted for devicetree maintainers review & approval. - Increase CCed list to include all possible people who touched and were involved this part of code/feature addition. v1: - Initial draft Rahul Tanwar (2): x86/of: Add support for boot time interrupt delivery mode configuration x86/of: Convert & update Intel's APIC related binding schemas .../intel,ce4100-ioapic.txt | 26 -------- .../intel,ce4100-ioapic.yaml | 62 ++++++++++++++++++ .../intel,ce4100-lapic.yaml | 63 +++++++++++++++++++ arch/x86/kernel/devicetree.c | 9 ++- 4 files changed, 133 insertions(+), 27 deletions(-) delete mode 100644 Documentation/devicetree/bindings/interrupt-controller/= intel,ce4100-ioapic.txt create mode 100644 Documentation/devicetree/bindings/interrupt-controller/= intel,ce4100-ioapic.yaml create mode 100644 Documentation/devicetree/bindings/interrupt-controller/= intel,ce4100-lapic.yaml --=20 2.17.1 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 45176C433FE for ; Wed, 16 Nov 2022 10:54:12 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233028AbiKPKyL (ORCPT ); Wed, 16 Nov 2022 05:54:11 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:35390 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S238918AbiKPKxL (ORCPT ); Wed, 16 Nov 2022 05:53:11 -0500 Received: from us-smtp-delivery-115.mimecast.com (us-smtp-delivery-115.mimecast.com [170.10.129.115]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 08517554CE for ; Wed, 16 Nov 2022 02:41:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=maxlinear.com; s=selector; t=1668595272; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=IMVM2YiTG2iDsFSmW+XV66q1v8bk48GDDU5GN/L+sZM=; b=ZxhL5+nQ3Cmro08fHrMBFi6kfc1sZ8OWQsaX3mVhqTOMQa0KpMDP5Rb4atK2T7l3yZc78l 3ATf49wkJU0byh1SuCG3WbtLOgZQGSJKW+LO6yuias0/4dbljnqReS/c0yYLXvfmYs8ba0 6UGcCkFAYf8PobHWMfyA7tAyjH4ALic/xFdz1qIZv4BMypWF8CPKYks7F0briBYdGLTS/w QpOUeTM/Ij4K8I3GkxiaV8Ob9qRGfDLTsSLZoqsYEOWmY07VyghJcy288mDdD0zyUaQDSG 2nqjb/X2SMrOBuSO8RZxDjZiFqyMn2mOj2A8ePuIt0S55FllfYj0qh6n3nLAWQ== Received: from mail.maxlinear.com (174-47-1-83.static.ctl.one [174.47.1.83]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id us-mta-53-bUUDQ6BsMlerbOpDYg5uAw-1; Wed, 16 Nov 2022 05:41:11 -0500 X-MC-Unique: bUUDQ6BsMlerbOpDYg5uAw-1 Received: from sgsxdev001.isng.phoenix.local (10.226.81.111) by mail.maxlinear.com (10.23.38.120) with Microsoft SMTP Server id 15.1.2375.24; Wed, 16 Nov 2022 02:41:04 -0800 From: Rahul Tanwar To: , , , , , , , , CC: , , , , , , , , "Rahul Tanwar" Subject: [PATCH v2 0/2] x86/of: Fix a bug in x86 arch OF support Date: Wed, 16 Nov 2022 18:41:00 +0800 Message-ID: X-Mailer: git-send-email 2.17.1 MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: maxlinear.com Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org Message-ID: <20221116104100.tYeQQvQTBFIHaAaQxZCplhMXAk6N0JlwFFq-IOcUW20@z> [Resend] as i missed to include Sebastian who changes this patch modifies. + devicetree@vger.kernel.org Hi Sebastian, All touched part in this patch series was added by you. Hoping for concerns/comments or best case ACK, reviewed-by tag from you. I have CCed all others who were involved with you when you added this changes. Hi devicetree@vger.kernel.org, Rob, Since this appears to be entrirely in devicetree domain. Hoping for feedback, concerns, mistakes or improvement feedbacks from you. Hi Andy, Hoping for a reviewed-by tag from you once you think it is ready to go. Thanks. Hi Thomas, Ingo, Boris, Andy, Dave & all x86@kernel.org maintainers, Resending below details hoping to figure out if the changes are logically aligned with your understanding & that it will not break any x86/arch concerns that you might have. Shooting on any mistakes welcomed :-). I sent this patch 3 times but for some reasons, never got any response or attention from anybody so far. Hence, resending with a cover letter to explain the rationale behind it in detail & to justify the need to add this fix. Also, hoping to get some feedback in-case i am mistaken in my understanding which might be the reason why i never got any response. Background (baseline understanding - pls correct if mistaken anywhere): References [1], [2] & [6] For SMP systems, Intel defines three (logically four) interrupt modes during boot/init time while BIOS/bootloader boots & switches to linux kernel. 1. PIC mode - Legacy 8259 PIC interrupt controller. 2. Virtual wire mode via Local APIC - uses local APIC as virtual wire 3. Virtual wire mode via I/O APIC - uses I/O APIC as virtual wire 4. Symmetric I/O mode - final one used by linux for SMP systems.=20 BIOS/bootloaders are supposed to boot in either #1 or #2 or #3 and then switch to #4 in linux for SMP systems. For our platform, we use #2. Detection of which interrupt mode the system is booting in is made by using below global variable in apic.c int pic_mode __ro_after_init;=20 Here pic_mode =3D 1 means #1 (PIC mode) above. And pic_mode =3D 0 means #2 or #3 (basically virtual wire mode via apic). And apic.c while doing setup_local_APIC() uses below code [3]: value =3D apic_read(APIC_LVT0) & APIC_LVT_MASKED; if (!cpu && (pic_mode || !value || skip_ioapic_setup)) { value =3D APIC_DM_EXTINT; apic_printk(APIC_VERBOSE, "enabled ExtINT on CPU#%d\n", cpu= ); } else { value =3D APIC_DM_EXTINT | APIC_LVT_MASKED; apic_printk(APIC_VERBOSE, "masked ExtINT on CPU#%d\n", cpu)= ; } apic_write(APIC_LVT0, value); What i understand from above is that if at this point of time, as long as it is cpu0 & pic_mode=3D1, it will set delivery mode to ExtINT (causes the processor to respond to the interrupt as if the interrupt originated in an externally connected (8259A-compatible) interrupt controller) and enables/ unmask the interrupts. pic_mode is presently set/populated/initialized at only two places: 1. In mpparse.c [4] 2. In devicetree.c [7] For #1 MPPARSE Kconfig definition is as below: =09config X86_MPPARSE =09bool "Enable MPS table" if ACPI =09default y =09depends on X86_LOCAL_APIC =09help =09For old smp systems that do not have proper acpi support. Newe= r systems =09(esp with 64bit cpus) with acpi support, MADT and DSDT will ov= erride it As seen above, if ACPI is not enabled, then mpparse by default is always enabled. Presently, there is no way to disable MPPARSE (if ACPI is not enabled). This to me appears to be another bug which needs fixing. As per theory, MPPARSE was to support MPS spec [1] as a temporary solution to support SMP systems until a final ACPI standard was added. But now if ACPI is not enabled, it will rely on MPPARSE driver to read MP floating pointer structure's IMCRP Bit 7 of MP feature info byte 2 [5] to figure out if it supports PIC mode or virtual wire mode and initialize pic_mode variable accordingly. If ACPI is enabled, the ACPI code overrides it by using the MADT table spec'ed in ACPI spec [2].=20 For #2 devicetree.c presently hardcodes pic_mode =3D 1 (PIC Mode). There is no support to configure virtual wire mode via devicetree path for OF based systems. Now we have a platform which is OF based & does not use legacy 8259 PIC interrupt controller. Non ACPI compliant as well as non MPPARSE compliant. For such platforms, it appears to me that hardcoding pic_mode =3D 1 (PIC Mo= de) and giving no other choice to choose virtual wire mode is a bug for OF based x86 platforms.=20 Just like mpparse relies on IMCRP bit 7 of MP feature info byte2 [5] to select pic_mode to PIC mode or virtual wire mode. arch/x86/kernel/devicetre= e.c should also provide some similar configurability to choose interrupt delivery mode & not hardcode it to PIC mode. This patch is to fix above explained bug in x86/of support for interrupt delivery mode configuration. Please let me know if you find any mistake in above understanding or if you have a alternative better suggestion to solve it or if you find anything odd here in our platform/system. TIA. The patch is baselined on below git tree: git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86/core [1] https://pdos.csail.mit.edu/6.828/2008/readings/ia32/MPspec.pdf [2] https://uefi.org/sites/default/files/resources/ACPI_6_3_final_Jan30.pdf [3] https://elixir.bootlin.com/linux/v6.1-rc5/source/arch/x86/kernel/apic/a= pic.c#L1691 [4] https://elixir.bootlin.com/linux/v6.1-rc5/source/arch/x86/kernel/mppars= e.c#L517 [5] https://www.manualslib.com/manual/77733/Intel-Multiprocessor.html?page= =3D40#manual [6] https://www.intel.com/content/www/us/en/developer/articles/technical/in= tel-sdm.html [7] https://elixir.bootlin.com/linux/v6.1-rc5/source/arch/x86/kernel/device= tree.c#L170 v2: - Address review concern from Andy - rename property name to make it a bit more positive & self explanatory. - Found that the bindings document for these HW's (APIC) are a bit off/obsolete and still in text format. Created new YAML schemas one for each - lapic & ioapic. Updated these schemas with latest info and add in new optional property details in the updated schema for lapic. Delete/let go of the text binding doc. - CC devicetree@vger.kernel.org as these changes appear to be mainly targeted for devicetree maintainers review & approval. - Increase CCed list to include all possible people who touched and were involved this part of code/feature addition. v1: - Initial draft Rahul Tanwar (2): x86/of: Add support for boot time interrupt delivery mode configuration x86/of: Convert & update Intel's APIC related binding schemas .../intel,ce4100-ioapic.txt | 26 -------- .../intel,ce4100-ioapic.yaml | 62 ++++++++++++++++++ .../intel,ce4100-lapic.yaml | 63 +++++++++++++++++++ arch/x86/kernel/devicetree.c | 9 ++- 4 files changed, 133 insertions(+), 27 deletions(-) delete mode 100644 Documentation/devicetree/bindings/interrupt-controller/= intel,ce4100-ioapic.txt create mode 100644 Documentation/devicetree/bindings/interrupt-controller/= intel,ce4100-ioapic.yaml create mode 100644 Documentation/devicetree/bindings/interrupt-controller/= intel,ce4100-lapic.yaml --=20 2.17.1