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? > 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 MBR, Sergey
