On 07/03/2021 17:01, Arnd Bergmann wrote:

On Sun, Mar 7, 2021 at 12:34 PM Krzysztof Kozlowski
[off-list ref] wrote:

quoted

On 05/03/2021 17:29, Hector Martin wrote:

quoted

On 06/03/2021 01.20, Andy Shevchenko wrote:

quoted

quoted

I am just splitting an
existing function into two, where one takes the lock and the other does
the work. Do you mean using a different locking function? I'm not
entirely sure what you're suggesting.

Yes, as a prerequisite

spin_lock_irqsave -> spin_lock().

Krzysztof, is this something you want in this series? I was trying to
avoid logic changes to the non-Apple paths.

I don't quite get the need for such change (the code will be still
called in interrupt handler, right?), but assuming the "why?" is
properly documented, it can be a separate patch here.

This is only for readability: the common rule is to not disable
interrupts when they are already disabled, so a reader might wonder
if this instance of the handler is special in some case that it might
be called with interrupts enabled.

There is also a small overhead in accessing the global irq mask
register on some architectures, but for a uart that does not make
any difference of course.

While I'm generally in favor of that kind of cleanup, I'd also
prefer to leave it out of this series -- once you get into details
like this the series gets harder to review.

So it's only about the spinlock in the IRQ handler (which does not need
to disable the IRQs). Makes sense but not related at all to the topic of
bringing up Apple M1, therefore should not stop the review/merging.

Best regards,
Krzysztof

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel