On Fri, 19 May 2023 at 20:06, Sebastian Andrzej Siewior <bigeasy@xxxxxxxxxxxxx> wrote: > > On 2023-05-19 18:14:38 [+0200], Ard Biesheuvel wrote: > > This looks reasonable to me - thanks for taking the time. > > > > However, I was about to hit send on my PR to Russell for the following series: > > > > https://git.kernel.org/pub/scm/linux/kernel/git/ardb/linux.git/log/?h=arm-vfp-softirq-fixes > > > > which moves all of the VFP processing to C, and so this is going to > > conflict at the very least, but also provide a cleaner base for patch > > #2 in this series. > > Okay. PR? Is this still the rmk's patch tracking system or did something > change? Either way, please let me know once this get through so I can > rebase accordingly. In the mean I throw this into -RT. > As I said, I am about to send it but I haven't yet, and it takes Russell usually some time to catch up. So this won't be in -next for another week or two. > > Also, aren't there a few other places in the VFP code where BH are > > disabled and enabled again? Do those need the same treatment? > > If so I haven't found them. A grep in arch/arm/ for bh_disable() has now > hit and this is vfp_lock(). > Apologies, I got myself confused.
