Received: by 2002:a25:c205:0:0:0:0:0 with SMTP id s5csp1124844ybf; Thu, 27 Feb 2020 05:30:22 -0800 (PST) X-Google-Smtp-Source: APXvYqxFLTB0B3dWsFeOhxzlc6qdF5Tepb9f/zzjb9trW4nEi9lzLrcLLAhrQ0f0xgeyLShENyHJ X-Received: by 2002:a9d:600e:: with SMTP id h14mr3168924otj.113.1582810222805; Thu, 27 Feb 2020 05:30:22 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1582810222; cv=none; d=google.com; s=arc-20160816; b=LmQmME2ktEm9WBX1A4hShm3q9656+/Mb2Kmc090h9SuSA+s65tLAs4mdNlPfLALaSC GXa6fbFGLKUroZ/DfvAE0Y2kQST1B7hHLzbR6bpBqlzDVYuFxA24SiAR8ZF2tHZcjSzB hQJHyHzBbv+FJyAaT2jfJKY1Wh4KLa7aIN96dnmGFQnfqe/+Q+DGZRGv8k+j/hKl/ZNj S5WfeDK3tUqFCk8yRPo45UWuI2V5wPAY3q8/87HokBJpyxPHb+tdlyoN/MsP06luf/ox +/Ji2kNSQ+E6JNhRROJpHzC8UasxLT3TtcbyG4HAV5gFMjBRqbmw2V7MAwBGcfEzfkxC PLTw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:message-id:date:references :in-reply-to:subject:cc:to:from; bh=yr6T5MAzGGu1VcJgwtyppA3CLkV5jlIG02UsiAoqpJ4=; b=yezYQLcbuQJHSr4Il1O7ZYRJlHs1Op7ACc+TjLHvbx9ogzg562h02FTOBmoNgDIjo3 mnZLdkc/1oXz79Oa+IktNA3W2C7/8lXh+s24cwhV9PTNzQf6j11Xd0yKBCjFOCXitXG/ ry7Z9ihPjCZuHlRn29EuQsVY3s2Bk1QFRKyHhlDpwuEo4RFyScYq3hHrdGx8YjAutEE6 9TtFSkzV5cql3TpXrOHq3MQPqR79UyT/B9FMF1Zo+D95FaGoLfysqM2xfwyFVoFBJJUf 1kgdGsQnfxB2czMattShoLC2ufwti5moLlowX2xw3f4xY5oh+RRmIz+PyjRvIpsYh22K tZwg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id v25si1579298oth.274.2020.02.27.05.30.10; Thu, 27 Feb 2020 05:30:22 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729153AbgB0NaG (ORCPT + 99 others); Thu, 27 Feb 2020 08:30:06 -0500 Received: from Galois.linutronix.de ([193.142.43.55]:34289 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729110AbgB0NaG (ORCPT ); Thu, 27 Feb 2020 08:30:06 -0500 Received: from p5de0bf0b.dip0.t-ipconnect.de ([93.224.191.11] helo=nanos.tec.linutronix.de) by Galois.linutronix.de with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1j7JEh-0001eE-KQ; Thu, 27 Feb 2020 14:29:55 +0100 Received: by nanos.tec.linutronix.de (Postfix, from userid 1000) id C0FEE1040A9; Thu, 27 Feb 2020 14:29:54 +0100 (CET) From: Thomas Gleixner To: afzal mohammed Cc: linux-kernel@vger.kernel.org, x86@kernel.org, Ingo Molnar , Borislav Petkov , "H. Peter Anvin" , Juergen Gross , Josh Poimboeuf , Masami Hiramatsu , Peter Zijlstra Subject: Re: [PATCH 14/18] x86: Replace setup_irq() by request_irq() In-Reply-To: <20200227113648.GA5760@afzalpc> References: <87v9nsmhjj.fsf@nanos.tec.linutronix.de> <20200227113648.GA5760@afzalpc> Date: Thu, 27 Feb 2020 14:29:54 +0100 Message-ID: <87sgiwma3x.fsf@nanos.tec.linutronix.de> MIME-Version: 1.0 Content-Type: text/plain X-Linutronix-Spam-Score: -1.0 X-Linutronix-Spam-Level: - X-Linutronix-Spam-Status: No , -1.0 points, 5.0 required, ALL_TRUSTED=-1,SHORTCIRCUIT=-0.0001 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Afzal, afzal mohammed writes: > On Thu, Feb 27, 2020 at 11:49:20AM +0100, Thomas Gleixner wrote: >> afzal mohammed writes: > >> > Seldom remove_irq() usage has been observed coupled with setup_irq(), >> > wherever that has been found, it too has been replaced by free_irq(). >> >> Please do not copy the irrelevant parts of your boilerplate text into >> individual changelogs. Changelogs should have the information which is >> relevant to the patch they describe. > > Sure, i will change. > >> > + if (request_irq(2, no_action, IRQF_NO_THREAD, "cascade", NULL)) >> > + pr_err("request_irq() on %s failed\n", "cascade"); >> >> What's the purpose of the %s indirection here? > > Putting that indirection helped me automate making these kind of changes w/ > cocci. As there were >150 instances of setup_irq and since "failed", > "request_irq()" were common, putting a %s indirection with the timer > name that changes in each instance, it was easy to take help of cocci > to automatically create it (though not fully). > > Would you be okay to keep that indirection ?, if not , i will make the > changes manually. > >> Also that error message is not really helpful: >> >> request_irq() on cascade failed >> >> Something like: >> >> Failed to request irq 2 (cascade). > > Yes, as i mentioned in m86k patch (6/18) [1], i was uncomfortable w/ that > string, based on Finn's feedback, in v2, it was modified to, > > cascade: request_irq() failed > > though still using %s indirection. Using scripting to find the spots and automatically convert them to something which is functionally and semantically correct is perfectly fine. But scripts neither have taste nor common sense. So going over a scripted conversion and fixing non-sensical stuff up manually is a good thing. > Yeah, i had felt it, the reason i went ahead that way was cocci could > automate that way for me for three-fourth of >150 instances making > things easy for me. Another reason was to reduce manual changes so as > to make it less error prone. > > Seems you are against taking the easy route of taking cocci's help, in > that case, i will change as you suggest. The easy route is fine for the initial step. See above. Thanks, tglx