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 X-Spam-Level: X-Spam-Status: No, score=-5.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 17394C433B4 for ; Fri, 21 May 2021 11:56:17 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id EE5AA613D0 for ; Fri, 21 May 2021 11:56:16 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233890AbhEUL5i (ORCPT ); Fri, 21 May 2021 07:57:38 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:35002 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233431AbhEUL5f (ORCPT ); Fri, 21 May 2021 07:57:35 -0400 Received: from galois.linutronix.de (Galois.linutronix.de [IPv6:2a0a:51c0:0:12e:550::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 4B40EC061574; Fri, 21 May 2021 04:56:12 -0700 (PDT) From: Thomas Gleixner DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1621598170; 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: in-reply-to:in-reply-to:references:references; bh=mkWCZPQm4Sq8eRx/19smgC/LUP5WutmsllFmC78x3iM=; b=jrrijcDW62qctMPrxCPXE+I3Q90yWYLVqGQ/yxRh12V/HvAA4nCM4b766r4kA8aSn4+W6E SnRcFBlQvE0mrX89gDciuHuQz771KRrNl1rzuPHyZ7IOQOKeKFvJjJI/wOkLb6sDJpvn9q TgadlGc0X/rM2/PgucKpLTCyxxYD915Z+IIh5R86eu4bzWFOfnGAlLAdiRl+7RS8wzUa4O zUy3nLU2rk9dFpcvjfjfPfe15jnqoj9aLPNzfzFFf4JT5BYRKOaHYUjUsIyJwEPstKdLu1 8o9h1bEaNR5IEyG46taJYm8nVwLh9LGpPGvwj9eMvzQn3aSouG7k+mhy6HNnPQ== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1621598170; 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: in-reply-to:in-reply-to:references:references; bh=mkWCZPQm4Sq8eRx/19smgC/LUP5WutmsllFmC78x3iM=; b=pzOgjIPEze+IzdbjPO3qovTvTCQJdEkxS1LKiSfgOooS/j3Pkf4u1ZVW+rw51h6LKK/SxF /aR/hPOxq6scYiBg== To: Nitesh Lal , Jesse Brandeburg , Robin Murphy , Marcelo Tosatti Cc: Ingo Molnar , linux-kernel@vger.kernel.org, intel-wired-lan@lists.osuosl.org, jbrandeb@kernel.org, "frederic\@kernel.org" , "juri.lelli\@redhat.com" , Alex Belits , "linux-api\@vger.kernel.org" , "bhelgaas\@google.com" , "linux-pci\@vger.kernel.org" , "rostedt\@goodmis.org" , "peterz\@infradead.org" , "davem\@davemloft.net" , "akpm\@linux-foundation.org" , "sfr\@canb.auug.org.au" , "stephen\@networkplumber.org" , "rppt\@linux.vnet.ibm.com" , "jinyuqi\@huawei.com" , "zhangshaokun\@hisilicon.com" , netdev@vger.kernel.org, chris.friesen@windriver.com, Marc Zyngier , Neil Horman , pjwaskiewicz@gmail.com Subject: Re: [PATCH tip:irq/core v1] genirq: remove auto-set of the mask when setting the hint In-Reply-To: References: <20210504092340.00006c61@intel.com> <87pmxpdr32.ffs@nanos.tec.linutronix.de> <87im3gewlu.ffs@nanos.tec.linutronix.de> Date: Fri, 21 May 2021 13:56:10 +0200 Message-ID: <87zgwo9u79.ffs@nanos.tec.linutronix.de> MIME-Version: 1.0 Content-Type: text/plain Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Nitesh, On Thu, May 20 2021 at 20:03, Nitesh Lal wrote: > On Thu, May 20, 2021 at 5:57 PM Nitesh Lal wrote: >> I think here to ensure that we are not breaking any of the drivers we have >> to first analyze all the existing drivers and understand how they are using >> this API. >> AFAIK there are three possible scenarios: >> >> - A driver use this API to spread the IRQs >> + For this case we should be safe considering the spreading is naturally >> done from the IRQ subsystem itself. > > Forgot to mention another thing in the above case is to determine whether > it is true for all architectures or not as Thomas mentioned. Yes. >> >> - A driver use this API to actually set the hint >> + These drivers should have no functional impact because of this revert Correct. >> - Driver use this API to force a certain affinity mask >> + In this case we have to replace the API with the irq_force_affinity() irq_set_affinity() or irq_set_affinity_and_hint() >> I can start looking into the individual drivers, however, testing them will >> be a challenge. The only way to do that is to have the core infrastructure added and then send patches changing it in the way you think. The relevant maintainers/developers should be able to tell you when your analysis went south. :) Been there, done that. It's just lots of work :) Thanks, tglx