On Tue, Jun 18, 2019 at 11:01 AM Fletcher Woodruff fletcherw@chromium.org wrote:
On Sun, Jun 16, 2019 at 10:56 AM Cezary Rojewski cezary.rojewski@intel.com wrote:
On 2019-06-14 21:48, Fletcher Woodruff wrote:
+static irqreturn_t rt5677_irq(int unused, void *data) +{
struct rt5677_priv *rt5677 = data;int ret = 0, i, reg_irq, virq;bool irq_fired = false;mutex_lock(&rt5677->irq_lock);/* Read interrupt status */ret = regmap_read(rt5677->regmap, RT5677_IRQ_CTRL1, ®_irq);if (ret) {pr_err("rt5677: failed reading IRQ status: %d\n", ret);The entire rt5677 makes use of dev_XXX with the exception of.. this very function. Consider reusing "component" field which is already part of struct rt5677_priv and removing pr_XXX.
I was using dev_XXX, but I believe Curtis found that 'component' was sometimes uninitialized when this function was called, so I switched back to pr_XXX. I may be misremembering though, so I'll let Curtis comment as well.
The issue here is that the IRQ is setup in the i2c probe and the component is setup in the codec probe. In theory if the hardware is in a bad state you can get an interrupt between the probes and have the interrupt called with the component being NULL. It might be worth considering migrating the IRQ setup to the codec probe so this condition cannot happen and then we can avoid using pr_XXX.
if (ret) {dev_err(&i2c->dev, "Failed to request IRQ: %d\n", ret); return ret;You may want to simplify this, similarly to how's it done in your rt5677_i2c_probe - leave message alone and return "ret" explicitly at the end.
Good suggestion. I'll update that for the next patch.