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.
