From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753690AbcA0FY4 (ORCPT ); Wed, 27 Jan 2016 00:24:56 -0500 Received: from cn.fujitsu.com ([59.151.112.132]:64989 "EHLO heian.cn.fujitsu.com" rhost-flags-OK-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S1752775AbcA0FYy (ORCPT ); Wed, 27 Jan 2016 00:24:54 -0500 X-IronPort-AV: E=Sophos;i="5.20,346,1444665600"; d="scan'208";a="3015165" Subject: Re: [PATCH v2] pci: fix unavailable irq number 255 reported by BIOS To: Bjorn Helgaas , Thomas Gleixner References: <1453705178-27389-1-git-send-email-chen.fan.fnst@cn.fujitsu.com> <20160125205803.GA10272@localhost> <20160126152221.GB9279@localhost> <20160127002505.GA3329@localhost> CC: Chen Fan , , , , , , , , , , , From: Cao jin Message-ID: <56A85494.8070606@cn.fujitsu.com> Date: Wed, 27 Jan 2016 13:24:36 +0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: <20160127002505.GA3329@localhost> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.167.226.69] X-yoursite-MailScanner-ID: 551B7418AD4D.A7E84 X-yoursite-MailScanner: Found to be clean X-yoursite-MailScanner-From: caoj.fnst@cn.fujitsu.com Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 01/27/2016 08:25 AM, Bjorn Helgaas wrote: > On Tue, Jan 26, 2016 at 04:48:25PM +0100, Thomas Gleixner wrote: >> On Tue, 26 Jan 2016, Bjorn Helgaas wrote: >> >> Right. So we could certainly do something like this INVALID_IRQ thingy, but >> that looks a bit weird. What would request_irq() return? >> >> If it returns success, then drivers might make the wrong decision. If it >> returns an error code, then the i801 one works, but we might have to fix >> others anyway. > > I was thinking request_irq() could return -EINVAL if the caller passed > INVALID_IRQ. That should tell drivers that this interrupt won't work. > > We'd be making request_irq() return -EINVAL in some cases where it > currently returns success. But even though it returns success today, > I don't think the driver is getting interrupts, because the wire isn't > connected. > >> I think it's better to have a software flag in pci_dev to indicate that there >> is no irq line and fix up the (probably few) affected drivers so they avoid >> calling request_irq() and take the right action. > > We could add an "irq_valid" flag in struct pci_dev and make a new > rule that drivers should check dev->irq_valid before using dev->irq. > But realistically, i801 is the only place that will check irq_valid > because that's the only driver where we know about a problem, so that > seems like sort of a point solution. > > Bjorn > How about using IRQ_BITMAP_BITS as that "irq_valid" flag? because it is the ceiling of struct irq_desc irq_desc[], and request_irq() will return -EINVAL in case of the ceiling. #ifdef CONFIG_SPARSE_IRQ # define IRQ_BITMAP_BITS (NR_IRQS + 8196) #else # define IRQ_BITMAP_BITS NR_IRQS #endif > . > -- Yours Sincerely, Cao jin