On Fri, Dec 28, 2018 at 12:16:17PM +0000, Vaittinen, Matti wrote: > Hello Charles, > > Sending this mail form outlook web interface - so I won't inline any code :/ > > From: Charles Keepax [[email protected]] > Sent: Friday, December 28, 2018 1:55 PM > > > On Fri, Dec 28, 2018 at 11:23:58AM +0000, Charles Keepax wrote: > > > Currently only gpio-max77620 is using the type support in regmap IRQ, > > > but the implementation causes the irq_set_type operation to fail on all > > > other regmap IRQ chips. Avoid these regressions by skipping the type > > > handling on any chips that don't define a set of supported types. > > > > > > Fixes: 1c2928e3e321 ("regmap: regmap-irq/gpio-max77620: add level-irq > > > support") > > > Signed-off-by: Charles Keepax <[email protected]> > > > --- > > > drivers/base/regmap/regmap-irq.c | 3 +++ > > > 1 file changed, 3 insertions(+) > > > > > > diff --git a/drivers/base/regmap/regmap-irq.c > > > b/drivers/base/regmap/regmap-irq.c > > > index 1bd1145ad8b5e..8c674f1ad0fc8 100644 > > > --- a/drivers/base/regmap/regmap-irq.c > > > +++ b/drivers/base/regmap/regmap-irq.c > > > @@ -257,6 +257,9 @@ static int regmap_irq_set_type(struct irq_data *data, > > > unsigned int type) > > > int reg; > > > const struct regmap_irq_type *t = &irq_data->type; > > > > > > + if (!t->types_supported) > > > + return 0; > > > + > > > if ((t->types_supported & type) != type) > > > return -ENOTSUPP; > > > > > I got the bug-report from Geert and sent this patch yesterday: > https://lore.kernel.org/lkml/[email protected]/ > > Looking at these two options, I wonder if we shuld return > -ENOTSUPP if we do support type setting, but for example > only for edge, not level active IRQs - and if LEVEL_LOW or > LEVEL_HIGH is requested? Well, I have no strong opinion and > both of these should fix the regressions - sorry for the hassle! > > I still wonder whether we should do as I suggested and only > set the irq_set_type callback for chips which have non zero > type_registers? I suggested that here: > https://lore.kernel.org/lkml/[email protected]/ >
Yeah that does look like probably the best solution. Thanks, Charles
