Message ID | 9114810c7af7fbaf9d0b2823752afcef865bdda0.1668589253.git.rtanwar@maxlinear.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:6687:0:0:0:0:0 with SMTP id l7csp68098wru; Wed, 16 Nov 2022 02:39:28 -0800 (PST) X-Google-Smtp-Source: AA0mqf6kpo6ZPIAkDE46ONmzJat4Uo8JCSX8weNgJSv0HUqWsKAEtAYpw6mJ0agQBrNDa8q1Lm6j X-Received: by 2002:a05:6402:2947:b0:467:5e8a:bce3 with SMTP id ed7-20020a056402294700b004675e8abce3mr18427692edb.334.1668595168267; Wed, 16 Nov 2022 02:39:28 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1668595168; cv=none; d=google.com; s=arc-20160816; b=Sg1mhhrqgaetwmKmTNOCs90FIFrN8f6Xg3nFXG930c8uZO6cvuXEdsC3JHboAAfuDb gGHghVTvevmXLleMD47mjV9ClY4A40Ahuk+L19W8kJTQuuqEQrhSi76Oy4lDaXpNe5u3 EteAGMwijDgo9sQo+IEJ3Az6xmlBykBVW48pEYcZw3X+t6A+Sz6ZGmnMuE1dc/gKAJCf tmA6wca2qkRLxIVXaQOgqku5b6aLT1KPy/H0Q3wA1oJjdDE2nu0yzbj28K9KbHDY/SqF n7i0Yazfk2+FBqpSNEExb8hxeRY6gSbxeKZK0zZ8Rhlz6SZxwcQ/ikurTSDkUkMSiNfM vSGw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=o2vFFZj0asvM/eG5j2z+UIf5OoA8cJ4FO5LVI46RoA8=; b=xzPNs24JypWnFW3H4YvBZ+SL/Kf75Cz0P6JP4h55SXrL9tCXrLV3H6N1Sz5cj07cf0 qSX/MmsBlZpO+jv1u0ZDQfH4KskmG+gAEBZQ9nUOtBG324+Uj9uPziqB3C9XDTNcdGn6 t+sXGTlNLPMuF0OGEAkcdS9/3l+wvxr7PzCaBW0dp0GdDR6NnMIYQQGeMkaM3Nh5tf7Y 3vCQQjdX8A17uRBAc1n+1M/HiCEd5L/074zu8QYJM+Z1Faq8lcLbdRKKGt11ugEfzNtc dtXtWcbP6dYCJub6jgGTiDO81abJEOxCS3TAoxyidu1cMtEiGIpl9LEiG2wxueIY+Qan /gtQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@maxlinear.com header.s=selector header.b=N0abli5i; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=maxlinear.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id dt4-20020a170907728400b0073d8ccd37c2si13716427ejc.107.2022.11.16.02.39.04; Wed, 16 Nov 2022 02:39:28 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@maxlinear.com header.s=selector header.b=N0abli5i; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=maxlinear.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233612AbiKPKh1 (ORCPT <rfc822;just.gull.subs@gmail.com> + 99 others); Wed, 16 Nov 2022 05:37:27 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43794 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233471AbiKPKff (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Wed, 16 Nov 2022 05:35:35 -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 E0BC46429 for <linux-kernel@vger.kernel.org>; Wed, 16 Nov 2022 02:28:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=maxlinear.com; s=selector; t=1668594517; 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: in-reply-to:in-reply-to:references:references; bh=o2vFFZj0asvM/eG5j2z+UIf5OoA8cJ4FO5LVI46RoA8=; b=N0abli5il4jQti6/qWePPd61pmJvXpK7xK+Fz02GMpH8L2IdXROtZVL9ubERZxdec5HTWe O7PAiUEMqaw8vA3A3MAHUQI9i3uC1nmdaEVlDxIcalCfN4lK1mKrmd3JWxCNcGFDmGIEV7 10ieYA44yIx+tJoarnmlDfHnuvn+zXumCT0yNW2S1k3oreQKlPh7r5h0vtZPuZES/UDiuF OL/S0QEJ0WDrQcb5w9e2ktFkLHbzFZ+3HGwZsWGhCK+XV12C9pEDrS6Lg+pAnk+V3VdBWJ SSdt0ZbmFTwxwIIhxc/GEML35i4LidMexRubYvacgZ7AJtMf1uq4YFVZ1cEoHQ== 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-119-9UH-ool9MTCCl9vGZhfhXQ-1; Wed, 16 Nov 2022 05:28:36 -0500 X-MC-Unique: 9UH-ool9MTCCl9vGZhfhXQ-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:30 -0800 From: Rahul Tanwar <rtanwar@maxlinear.com> To: <devicetree@vger.kernel.org>, <robh@kernel.org>, <andriy.shevchenko@linux.intel.com>, <tglx@linutronix.de>, <mingo@redhat.com>, <bp@alien8.de>, <dave.hansen@linux.intel.com>, <x86@kernel.org> CC: <linux-kernel@vger.kernel.org>, <hpa@zytor.com>, <alan@lxorguk.ukuu.org.uk>, <dirk.brandewie@gmail.com>, <grant.likely@secretlab.ca>, <sodaville@linutronix.de>, <devicetree-discuss@lists.ozlabs.org>, <linux-lgm-soc@maxlinear.com>, "Rahul Tanwar" <rtanwar@maxlinear.com> Subject: [PATCH v2 1/2] x86/of: Add support for boot time interrupt delivery mode configuration Date: Wed, 16 Nov 2022 18:28:20 +0800 Message-ID: <9114810c7af7fbaf9d0b2823752afcef865bdda0.1668589253.git.rtanwar@maxlinear.com> X-Mailer: git-send-email 2.17.1 In-Reply-To: <cover.1668589253.git.rtanwar@maxlinear.com> References: <cover.1668589253.git.rtanwar@maxlinear.com> 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 X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1749648846727452918?= X-GMAIL-MSGID: =?utf-8?q?1749648846727452918?= |
Series |
x86/of: Fix a bug in x86 arch OF support
|
|
Commit Message
Rahul Tanwar
Nov. 16, 2022, 10:28 a.m. UTC
Presently, init/boot time interrupt delivery mode is enumerated
only for ACPI enabled systems by parsing MADT table or for older
systems by parsing MP table. But for OF based x86 systems, it is
assumed & hardcoded to legacy PIC mode. This is a bug for
platforms which are OF based but do not use 8259 compliant legacy
PIC interrupt controller. Such platforms can not even boot because
of this bug/hardcoding.
Fix this bug by adding support for configuration of init time
interrupt delivery mode for x86 OF based systems by introducing a
new optional boolean property 'intel,virtual-wire-mode' for
interrupt-controller node of local APIC. This property emulates
IMCRP Bit 7 of MP feature info byte 2 of MP floating pointer
structure [1].
Defaults to legacy PIC mode if absent. Configures it to virtual
wire compatibility mode if present.
[1] https://www.manualslib.com/manual/77733/Intel-Multiprocessor.html?page=40#manual
Fixes: 3879a6f329483 ("x86: dtb: Add early parsing of IO_APIC")
Signed-off-by: Rahul Tanwar <rtanwar@maxlinear.com>
---
arch/x86/kernel/devicetree.c | 9 ++++++++-
1 file changed, 8 insertions(+), 1 deletion(-)
Comments
On Wed, Nov 16, 2022 at 06:28:20PM +0800, Rahul Tanwar wrote: > Presently, init/boot time interrupt delivery mode is enumerated > only for ACPI enabled systems by parsing MADT table or for older > systems by parsing MP table. But for OF based x86 systems, it is > assumed & hardcoded to legacy PIC mode. This is a bug for > platforms which are OF based but do not use 8259 compliant legacy > PIC interrupt controller. Such platforms can not even boot because > of this bug/hardcoding. > > Fix this bug by adding support for configuration of init time > interrupt delivery mode for x86 OF based systems by introducing a > new optional boolean property 'intel,virtual-wire-mode' for > interrupt-controller node of local APIC. This property emulates > IMCRP Bit 7 of MP feature info byte 2 of MP floating pointer > structure [1]. > > Defaults to legacy PIC mode if absent. Configures it to virtual > wire compatibility mode if present. > [1] https://www.manualslib.com/manual/77733/Intel-Multiprocessor.html?page=40#manual Link: ? ... > + if (of_property_read_bool(dn, "intel,virtual-wire-mode")) { You need a separate patch to show this property being added (yes, I have just commented on your patch 2). > + printk(KERN_NOTICE "Virtual Wire compatibility mode.\n"); > + pic_mode = 0; > + } else { > + printk(KERN_NOTICE "IMCR and PIC compatibility mode.\n"); > + pic_mode = 1; Why not pr_notice() in both cases? > + }
On 16/11/2022 6:42 pm, Andy Shevchenko wrote: > This email was sent from outside of MaxLinear. > > On Wed, Nov 16, 2022 at 06:28:20PM +0800, Rahul Tanwar wrote: > > Presently, init/boot time interrupt delivery mode is enumerated > > only for ACPI enabled systems by parsing MADT table or for older > > systems by parsing MP table. But for OF based x86 systems, it is > > assumed & hardcoded to legacy PIC mode. This is a bug for > > platforms which are OF based but do not use 8259 compliant legacy > > PIC interrupt controller. Such platforms can not even boot because > > of this bug/hardcoding. > > > > Fix this bug by adding support for configuration of init time > > interrupt delivery mode for x86 OF based systems by introducing a > > new optional boolean property 'intel,virtual-wire-mode' for > > interrupt-controller node of local APIC. This property emulates > > IMCRP Bit 7 of MP feature info byte 2 of MP floating pointer > > structure [1]. > > > > Defaults to legacy PIC mode if absent. Configures it to virtual > > wire compatibility mode if present. > > > [1] > https://www.manualslib.com/manual/77733/Intel-Multiprocessor.html?page=40#manual <https://www.manualslib.com/manual/77733/Intel-Multiprocessor.html?page=40#manual> > > Link: ? Rechecked. Link URL works for me. Am i missing any standard practice to add URL links in commit log ? > > ... > > > + if (of_property_read_bool(dn, "intel,virtual-wire-mode")) { > > You need a separate patch to show this property being added (yes, > I have just commented on your patch 2). > > > + printk(KERN_NOTICE "Virtual Wire compatibility mode.\n"); > > + pic_mode = 0; > > + } else { > > + printk(KERN_NOTICE "IMCR and PIC compatibility mode.\n"); > > + pic_mode = 1; > > Why not pr_notice() in both cases? Reset of the file uses printk(KERN_xxx ""). In v1, i used pr_notice() but on reviewing again found it to be odd one out in the file. So switched to printk(KERN_xxx ""). I can revert back to using pr_notice() if you think that's a better fit. Thanks. Regards, Rahul > > > + } > > -- > With Best Regards, > Andy Shevchenko >
On 16/11/2022 6:42 pm, Andy Shevchenko wrote: > This email was sent from outside of MaxLinear. > > On Wed, Nov 16, 2022 at 06:28:20PM +0800, Rahul Tanwar wrote: > > Presently, init/boot time interrupt delivery mode is enumerated > > only for ACPI enabled systems by parsing MADT table or for older > > systems by parsing MP table. But for OF based x86 systems, it is > > assumed & hardcoded to legacy PIC mode. This is a bug for > > platforms which are OF based but do not use 8259 compliant legacy > > PIC interrupt controller. Such platforms can not even boot because > > of this bug/hardcoding. > > > > Fix this bug by adding support for configuration of init time > > interrupt delivery mode for x86 OF based systems by introducing a > > new optional boolean property 'intel,virtual-wire-mode' for > > interrupt-controller node of local APIC. This property emulates > > IMCRP Bit 7 of MP feature info byte 2 of MP floating pointer > > structure [1]. > > > > Defaults to legacy PIC mode if absent. Configures it to virtual > > wire compatibility mode if present. > > > [1] > https://www.manualslib.com/manual/77733/Intel-Multiprocessor.html?page=40#manual <https://www.manualslib.com/manual/77733/Intel-Multiprocessor.html?page=40#manual> > > Link: ? > > ... > > > + if (of_property_read_bool(dn, "intel,virtual-wire-mode")) { > > You need a separate patch to show this property being added (yes, > I have just commented on your patch 2). > Well noted about it. Will update. Thanks. Regards, Rahul > > + printk(KERN_NOTICE "Virtual Wire compatibility mode.\n"); > > + pic_mode = 0; > > + } else { > > + printk(KERN_NOTICE "IMCR and PIC compatibility mode.\n"); > > + pic_mode = 1; > > Why not pr_notice() in both cases? > > > + } > > -- > With Best Regards, > Andy Shevchenko >
On Wed, Nov 16, 2022 at 11:25:47AM +0000, Rahul Tanwar wrote: > On 16/11/2022 6:42 pm, Andy Shevchenko wrote: > > On Wed, Nov 16, 2022 at 06:28:20PM +0800, Rahul Tanwar wrote: ... > > Why not pr_notice() in both cases? > > Reset of the file uses printk(KERN_xxx ""). In v1, i used pr_notice() > but on reviewing again found it to be odd one out in the file. So > switched to printk(KERN_xxx ""). I can revert back to using pr_notice() > if you think that's a better fit. Thanks. I don;t know why we should use antique style of printing APIs in new patches. Even if the old code uses that, you can create a followup that can do two things: - uses pr_lvl() instead of printk(KERN_LVL) - keeps string literals unbroken between the lines (if any of such breakage exists)
diff --git a/arch/x86/kernel/devicetree.c b/arch/x86/kernel/devicetree.c index 5cd51f25f446..2a8833f0f6ae 100644 --- a/arch/x86/kernel/devicetree.c +++ b/arch/x86/kernel/devicetree.c @@ -167,7 +167,14 @@ static void __init dtb_lapic_setup(void) return; } smp_found_config = 1; - pic_mode = 1; + if (of_property_read_bool(dn, "intel,virtual-wire-mode")) { + printk(KERN_NOTICE "Virtual Wire compatibility mode.\n"); + pic_mode = 0; + } else { + printk(KERN_NOTICE "IMCR and PIC compatibility mode.\n"); + pic_mode = 1; + } + register_lapic_address(lapic_addr); }