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=-0.8 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,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 EED76C47254 for ; Sat, 2 May 2020 06:15:41 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id C0E202184D for ; Sat, 2 May 2020 06:15:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1588400141; bh=P1G9XTk6/zTFJDfUeyPIvBiffh6K8okBFUBHJ5TkZvY=; h=Date:From:To:Cc:Subject:References:In-Reply-To:List-ID:From; b=ZxCEzoQYI2quh2yYy6KgzKHn4YYoNOmOj+bWKhttm84Nv58h8SdswBjoesDkRDpRz SsVP89EBqAKzd/hEv+geUAFNe0X4gcp2Q+V6F31muVf6rdrnHF5PNIDzEQuTUXK3Q6 izFY/gzXhinXnu+X5XbBSwfkVIrXqfEVenoV6bwY= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726846AbgEBGPk (ORCPT ); Sat, 2 May 2020 02:15:40 -0400 Received: from mail.kernel.org ([198.145.29.99]:51298 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726058AbgEBGPk (ORCPT ); Sat, 2 May 2020 02:15:40 -0400 Received: from localhost (83-86-89-107.cable.dynamic.v4.ziggo.nl [83.86.89.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 76B5821775; Sat, 2 May 2020 06:15:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1588400139; bh=P1G9XTk6/zTFJDfUeyPIvBiffh6K8okBFUBHJ5TkZvY=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=eDu3tcE8yBlXCT4EEkbq6EGPGsc+QaWK+l5JsE7CT1KqGrux/+91GpomWgneZBDGI TlaMW6qgHqlCY8eFJaFoc5Z/1nIYSkSgSfYKSV/HqWK1hrlMWyLY9KuEXslxnW4NgZ s/BaJy30d8q5L0xLnyVKnmAgWfboXCsNp7jqkUAY= Date: Sat, 2 May 2020 08:15:37 +0200 From: Greg Kroah-Hartman To: Bjorn Helgaas Cc: Thomas Gleixner , "Rafael J . Wysocki" , Aman Sharma , linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org, Bjorn Helgaas Subject: Re: [PATCH v2 1/2] driver core: platform: Clarify that IRQ 0 is invalid Message-ID: <20200502061537.GA2527384@kroah.com> References: <20200501224042.141366-1-helgaas@kernel.org> <20200501224042.141366-2-helgaas@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200501224042.141366-2-helgaas@kernel.org> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, May 01, 2020 at 05:40:41PM -0500, Bjorn Helgaas wrote: > From: Bjorn Helgaas > > These interfaces return a negative error number or an IRQ: > > platform_get_irq() > platform_get_irq_optional() > platform_get_irq_byname() > platform_get_irq_byname_optional() > > The function comments suggest checking for error like this: > > irq = platform_get_irq(...); > if (irq < 0) > return irq; > > which is what most callers (~900 of 1400) do, so it's implicit that IRQ 0 > is invalid. But some callers check for "irq <= 0", and it's not obvious > from the source that we never return an IRQ 0. > > Make this more explicit by updating the comments to say that an IRQ number > is always non-zero and adding a WARN() if we ever do return zero. If we do > return IRQ 0, it likely indicates a bug in the arch-specific parts of > platform_get_irq(). I worry about adding WARN() as there are systems that do panic_on_warn() and syzbot trips over this as well. I don't think that for this issue it would be a problem, but what really is this warning about that someone could do anything with? Other than that minor thing, this looks good to me, thanks for finally clearing this up. greg k-h