On Fri, May 21, 2021 at 7:56 AM Thomas Gleixner <tglx@xxxxxxxxxxxxx> wrote: > > Nitesh, > > On Thu, May 20 2021 at 20:03, Nitesh Lal wrote: > > On Thu, May 20, 2021 at 5:57 PM Nitesh Lal <nilal@xxxxxxxxxx> wrote: > >> I think here to ensure that we are not breaking any of the drivers we have > >> to first analyze all the existing drivers and understand how they are using > >> this API. > >> AFAIK there are three possible scenarios: > >> > >> - A driver use this API to spread the IRQs > >> + For this case we should be safe considering the spreading is naturally > >> done from the IRQ subsystem itself. > > > > Forgot to mention another thing in the above case is to determine whether > > it is true for all architectures or not as Thomas mentioned. > > Yes. > > >> > >> - A driver use this API to actually set the hint > >> + These drivers should have no functional impact because of this revert > > Correct. > > > >> - Driver use this API to force a certain affinity mask > >> + In this case we have to replace the API with the irq_force_affinity() > > irq_set_affinity() or irq_set_affinity_and_hint() Ah yes! my bad. _force_ doesn't check the mask against the online CPUs. Hmm, I didn't realize that you also added irq_set_affinity_and_hint() in your last patchset. > > >> I can start looking into the individual drivers, however, testing them will > >> be a challenge. > > The only way to do that is to have the core infrastructure added and Right. > then send patches changing it in the way you think. The relevant > maintainers/developers should be able to tell you when your analysis > went south. :) Ack will start looking into this. -- Thanks Nitesh
