On Wed, Oct 09, 2019 at 07:24:57AM +0000, Anson Huang wrote: > > On Wed, Oct 09, 2019 at 06:58:24AM +0000, Anson Huang wrote: > > > > The patch is fine given the changed behaviour of platform_get_irq. I > > > > wonder if it is sensible to introduce a variant of platform_get_irq (say > > > > platform_get_irq_nowarn) that behaves like __platform_get_irq does t > > > > Then the imx driver would just call platform_get_irq_nowarn without > > > > having to check the number of available irqs first. > > > > > > Agreed, it would be nice if we can fix this from the API level, this > > > is to save many patches from various drivers side, let me know if > > > agreement is reached and I will do the patch. > > > > I wouldn't expect that most callers actually want an error message and so > > these need a different patch (i.e. dropping the error message by the caller). > > This type of patch is fine and the normal load when something is > > consolidated. > > > > Which other drivers do you have on your radar that don't want an error > > message if platform_get_irq() fails? > > I did NOT mean drivers don't want an error when getting irq failed, but I just > agree that introducing another API with nowarn as you mentioned upper, then > i.MX driver can call it. For now, the FEC driver also have many such error message, > we will fix later. > > So if the API with nowarn is added, then I can change the API call in some i.MX driver > instead of getting irq_count first. Do you think I should add the nowarn API and redo > this patch to call it? Having a patch (or a set of patches) is probably helpful to get forward here, yes. You have my blessing to create a suggestion. (Not that you actually need that :-) Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König | Industrial Linux Solutions | http://www.pengutronix.de/ |
