Received: by 2002:ac0:e350:0:0:0:0:0 with SMTP id g16csp2030874imn; Mon, 1 Aug 2022 08:42:33 -0700 (PDT) X-Google-Smtp-Source: AGRyM1v5j0HBldemA5Pl4GsVakB5nZNFC3skNOklpcry/kVcznYejVHwSOmQ2kTLLz6ie12Q2mc2 X-Received: by 2002:a62:58c5:0:b0:52b:fa53:d052 with SMTP id m188-20020a6258c5000000b0052bfa53d052mr16789080pfb.68.1659368553633; Mon, 01 Aug 2022 08:42:33 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1659368553; cv=none; d=google.com; s=arc-20160816; b=MY4RM4l+mCWnHOunutbwuhrWkcpklsxYykDpNsHpPlrDac7uqC/eHxWmdNifDccaIj KgQRbwU1i4zwbh9pFS6N6BulpQ/avsu58Re/odSC9R/ZKjJ0tiUwbGyiFBGzdT6a4XVc gh5UF7A06/eHiquje3HyKvdi3iHZZlVLTEogiJomxS6e5aLUf6fEtImHVBo2KWVBoVg1 VREXWXGbQ29EFx/a939kGGEHfEK0oD6u9jVFzUp/ER/rQS5QimzqwsPirtBVMEq+4wat 7mAHBTNqSh35s16flnJjtlvcwG+LplBjmtq1l0IDzlUZ1vjvawxnylQNc6RZ19HEGBQ6 49jw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=SMXNEAXXXfthaRM2wt3FVPBEB+0O9dyvrj43azE2s4w=; b=h+PMqOBtpDnGjPsC03UcYSeMnBH5KRYdBT4c9Z/8IhsxU95k70V6JhC9TgTZx3/5jN njj1oAU7bW/Zfm1KY05NabG2MuzYCZlNQW928a9wiwS+su7b2uzZBddZ6HOokE8Gcheh wwdkyVG45FhJYI3Y9fcPJ3Or+uJv70U/kni8eAiiDufZKIBqQFFVV/qLQwYfLUZSkp/x 7/vKxkIlVQNuXdP3PD+o8fiKiPjHSX0Hl2UZzzoLEHA7HbrS5IB8ehkGj/hu/i6Ynoqe GyZ0UqixWJbio82gIRGV22OV6HLy6UgTUMX1BAw+aDPI5HQdzEROAk8vwauScZv9HvJz 330Q== ARC-Authentication-Results: i=1; mx.google.com; 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 Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id q184-20020a632ac1000000b00419b8e83910si12704357pgq.668.2022.08.01.08.42.18; Mon, 01 Aug 2022 08:42:33 -0700 (PDT) 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; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233538AbiHAP0X (ORCPT + 99 others); Mon, 1 Aug 2022 11:26:23 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60180 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233504AbiHAP0V (ORCPT ); Mon, 1 Aug 2022 11:26:21 -0400 Received: from elvis.franken.de (elvis.franken.de [193.175.24.41]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 81BBA1838B; Mon, 1 Aug 2022 08:26:19 -0700 (PDT) Received: from uucp (helo=alpha) by elvis.franken.de with local-bsmtp (Exim 3.36 #1) id 1oIXJA-0005sx-00; Mon, 01 Aug 2022 17:26:16 +0200 Received: by alpha.franken.de (Postfix, from userid 1000) id 35F03C0193; Mon, 1 Aug 2022 17:25:59 +0200 (CEST) Date: Mon, 1 Aug 2022 17:25:59 +0200 From: Thomas Bogendoerfer To: Martin Blumenstingl Cc: Marc Zyngier , Sander Vanheule , Aleksander Jan Bajkowski , Hauke Mehrtens , git@birger-koblitz.de, linux-mips@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] MIPS: smp-mt: enable all hardware interrupts on second VPE Message-ID: <20220801152559.GA9041@alpha.franken.de> References: <20220702190705.5319-1-olek2@wp.pl> <3c9a032edd0fb9b9608ad3ca08d6e3cc38f21464.camel@svanheule.net> <87fsjen2kl.wl-maz@kernel.org> <20220706081901.GA10797@alpha.franken.de> <20220707100630.GC9894@alpha.franken.de> <20220707143930.GA14693@alpha.franken.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW, SPF_HELO_PASS,SPF_NONE autolearn=ham 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: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Jul 28, 2022 at 05:50:10PM +0200, Martin Blumenstingl wrote: > I think for the Realtek SoC's this would be problematic because it's > using MIPS_GENERIC. My understanding is that in an ideal world all which SOC are these ? > platforms would switch to MIPS_GENERIC. > As an alternative to making irq-mips-cpu capable of changing another > CPU's registers: would you also be happy with a change that implements > the following idea (pseudocode) in vsmp_init_secondary(): > struct device_node *root_node = of_find_node_by_path("/"); > > if (mips_gic_present() || > of_device_is_compatible(root_node, "lantiq,xrx200") || > of_device_is_compatible(root_node, "realtek,some-relevant-soc")) > change_c0_status(ST0_IM, STATUSF_IP2 | STATUSF_IP3 | > STATUSF_IP4 | STATUSF_IP5 | > STATUSF_IP6 | STATUSF_IP7); > else > ... > > of_node_put(root_node); > > That way we don't risk enabling interrupt lines which shouldn't be > enabled (on SoCs which we don't know). > And also it would not cause any issues with MIPS_GENERIC support. well it's not exactly the abstraction I'm looking for, but it's ok for me as a short term way to move forward. Thomas. -- Crap can work. Given enough thrust pigs will fly, but it's not necessarily a good idea. [ RFC1925, 2.3 ]