On Wed, Jan 19, 2022 at 10:47:06PM +0300, Sergey Shtylyov wrote: > On 1/19/22 9:51 PM, Andy Shevchenko wrote: > >>>>> It'd certainly be good to name anything that doesn't correspond to one > >>>>> of the existing semantics for the API (!) something different rather > >>>>> than adding yet another potentially overloaded meaning. > >>>> > >>>> It seems we're (at least) three who agree about this. Here is a patch > >>>> fixing the name. > >>> > >>> And similar number of people are on the other side. > >> > >> If someone already opposed to the renaming (and not only the name) I > >> must have missed that. > >> > >> So you think it's a good idea to keep the name > >> platform_get_irq_optional() despite the "not found" value returned by it > >> isn't usable as if it were a normal irq number? > > > > I meant that on the other side people who are in favour of Sergey's patch. > > Since that I commented already that I opposed the renaming being a standalone > > change. > > > > Do you agree that we have several issues with platform_get_irq*() APIs? > > > > 1. The unfortunate naming > > Mmm, "what's in a name?"... is this the topmost prio issue? The order is arbitrary. > > 2. The vIRQ0 handling: a) WARN() followed by b) returned value 0 > > This is the most severe issue, I think... > > > 3. The specific cookie for "IRQ not found, while no error happened" case -- With Best Regards, Andy Shevchenko
