From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754199AbcAVTXm (ORCPT ); Fri, 22 Jan 2016 14:23:42 -0500 Received: from mail-pa0-f43.google.com ([209.85.220.43]:33186 "EHLO mail-pa0-f43.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753301AbcAVTXi (ORCPT ); Fri, 22 Jan 2016 14:23:38 -0500 Message-ID: <56A281B6.6070709@gmail.com> Date: Fri, 22 Jan 2016 11:23:34 -0800 From: David Daney User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7 MIME-Version: 1.0 To: Bjorn Helgaas CC: "Rafael J. Wysocki" , Cao jin , "Rafael J. Wysocki" , Chen Fan , ACPI Devel Maling List , Linux Kernel Mailing List , Len Brown , izumi.taku@jp.fujitsu.com, wency@cn.fujitsu.com, Bjorn Helgaas , Linux PCI , Jiang Liu Subject: Re: [PATCH] pci: fix unavailable irq number 255 reported by BIOS References: <1453167913-16248-1-git-send-email-chen.fan.fnst@cn.fujitsu.com> <6239489.QX2A2kAHWp@vostro.rjw.lan> <20160120002431.GA7973@localhost> <56A0EE00.80709@cn.fujitsu.com> <20160122175332.GA11004@localhost> In-Reply-To: <20160122175332.GA11004@localhost> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 01/22/2016 09:53 AM, Bjorn Helgaas wrote: > On Thu, Jan 21, 2016 at 11:58:26PM +0100, Rafael J. Wysocki wrote: >> On Thu, Jan 21, 2016 at 3:41 PM, Cao jin wrote: >>> Hi, >>> >>> IMHO, I think maybe modification on i801_smbus driver is easier. >>> >>> Because when i801_smbus request_irq using pci_dev->irq, this >>> pci_dev->irq seems still holds the value read from register( >>> pci_setup_device->pci_read_irq), if the value is 255, it is invalid in >>> register, >> >> Right. >> >> Which is why the PCI core should not leak it into the driver's ->probe callback. > > Is there a reserved IRQ value we could use to mean "invalid"? In many (most) cases, zero indicates no irq. > > I guess we have NR_IRQS as a ceiling, so the range of valid IRQs would be > [0 .. NR_IRQS - 1]. It looks like irq_desc() and a few drivers already > rely on NR_IRQS being the bound: > > lpc32xx_kscan_probe > lpc32xx_nand_probe > pcmcia_setup_isa_irq > lpc32xx_rtc_probe > apbuart_verify_port > ar933x_uart_verify_port > lqasc_verify_port > > So I guess we could use ~0 as "invalid IRQ", and maybe the PCI core could > set dev->irq to ~0 in these cases, and drivers like i801_smbus could check > for that. Maybe a wrapper like irq_valid() would be useful. > > Bjorn > >