| Message ID | 20230519145731.574867-1-bigeasy@linutronix.de |
|---|---|
| Headers | show |
| Series | ARM: vfp: Fixes for PREEMP_RT | expand |
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. > 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(). > Thanks, > Ard. Sebastian
On Fri, 19 May 2023 at 20:06, Sebastian Andrzej Siewior <bigeasy@linutronix.de> 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.
Hi Ard, On 2023-05-18 00:05:33 [+0200], Ard Biesheuvel wrote: > Don't let me stop you :-) made a small series. It seems to address everything and with your assembly rework it is not a big mess. What do you think? Sebastian