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=-2.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 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 A263FC433DF for ; Mon, 15 Jun 2020 17:32:05 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 89F4020810 for ; Mon, 15 Jun 2020 17:32:05 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731266AbgFORcE (ORCPT ); Mon, 15 Jun 2020 13:32:04 -0400 Received: from foss.arm.com ([217.140.110.172]:52812 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728585AbgFORcD (ORCPT ); Mon, 15 Jun 2020 13:32:03 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 2B79C1F1; Mon, 15 Jun 2020 10:32:02 -0700 (PDT) Received: from [10.57.9.128] (unknown [10.57.9.128]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 2E3FC3F73C; Mon, 15 Jun 2020 10:32:00 -0700 (PDT) Subject: Re: [PATCH v2] spi: bcm2835: Enable shared interrupt support To: Florian Fainelli , Mark Brown Cc: lukas@wunner.de, "moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE" , "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" , Scott Branden , Ray Jui , linux-kernel@vger.kernel.org, "open list:SPI SUBSYSTEM" , Rob Herring , "maintainer:BROADCOM BCM281XX/BCM11XXX/BCM216XX ARM ARCHITE..." , "moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE" , Martin Sperl , Nicolas Saenz Julienne References: <20200604212819.715-1-f.fainelli@gmail.com> <142d48ae-2725-1368-3e11-658449662371@arm.com> <20200605132037.GF5413@sirena.org.uk> <2e371a32-fb52-03a2-82e4-5733d9f139cc@arm.com> <06342e88-e130-ad7a-9f97-94f09156f868@arm.com> <20200608112840.GC4593@sirena.org.uk> <20200615170031.GA4447@sirena.org.uk> <692bc94e-d574-e07a-d834-c0d569e87bba@gmail.com> From: Robin Murphy Message-ID: <2f354ed0-9fb7-59ea-ddd1-78703d9c818e@arm.com> Date: Mon, 15 Jun 2020 18:31:58 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <692bc94e-d574-e07a-d834-c0d569e87bba@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2020-06-15 18:04, Florian Fainelli wrote: > > > On 6/15/2020 10:00 AM, Mark Brown wrote: >> On Mon, Jun 15, 2020 at 09:34:58AM -0700, Florian Fainelli wrote: >> >>> OK, so this has been dropped for spi/for-next right? How do we move from >>> there? >> >> Well, I actually have it queued up for applying so unless I pull it >> before my scripts get that far through the stuff I queued over the merge >> window it'll go in (I dropped it due to it not being a bugfix). If it >> were me I'd go with the two instruction hit from checking the flag TBH >> but otherwise I guess __always_inline should work for compilers that >> misoptimize. None of this is getting in the way of the framework so if >> everyone involved in the driver is happy to spend time optimising it >> and dealing with the fragility then it's fine by me. > > OK, how about I send you an increment patch (would a fixup be okay?) > that adds __always_inline since we know from this thread that some > compilers may mis-optimize the function inlining? Now that I've been inclined to go and look up the documentation, are we sure this so-very-contentious check is even correct? From my reading of things we're checking whether the RXR interrupt function is *enabled*, which still says nothing about whether either condition for the interrupt being *asserted* is true (RXR = 1 or DONE = 1). Thus if more than one SPI instance is active at once we could still end up trying to service an IRQ on a controller that didn't raise it. Robin.