lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date:	Tue, 31 Jul 2012 15:11:21 +0100
From:	Graeme Gregory <gg@...mlogic.co.uk>
To:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
CC:	Mark Brown <broonie@...nsource.wolfsonmicro.com>,
	Grant Likely <grant.likely@...retlab.ca>,
	Benjamin Herrenschmidt <benh@...nel.crashing.org>,
	Paul Mundt <lethal@...ux-sh.org>
Subject: I2C dummy, regmap, irq domain issue

I have an interesting issue with the combination of i2c dummy devices,
regmap-irq and domains.

I have been adding device tree support to the palmas mfd driver.

The palmas device has 3 i2c addresses it responds to so it has one
normal i2c device and 2 dummy devices to claim the 2nd/3rd addresses
(this is pretty normal).

The registers for the IRQ handling on the chip happen to be in the 2nd
slave address. This means that when I am calling the regmap_add_irq_chip
call it is using a regmap based on the dummy i2c device.

regmap_add_irq_chip(palmas->regmap[slave], palmas->irq,
            IRQF_ONESHOT | IRQF_TRIGGER_LOW, -1, &palmas_irq_chip,
            &palmas->irq_data);

This works however when probing the child devices from the device tree
because I have used a dummy I2C device it fails to find the IRQ domain
created by regmap-irq.

of_platform_populate(node, NULL, NULL, &i2c->dev);

While debugging this issue I changed the regmap_add_irq_chip as per the
diff at end of the email. Is there a cleaner way to solve this within
the DT system?

Graeme

@@ -194,7 +194,7 @@ static struct irq_domain_ops regmap_domain_ops = {
  * register cache.  The chip driver is responsible for restoring the
  * register values used by the IRQ controller over suspend and resume.
  */
-int regmap_add_irq_chip(struct regmap *map, int irq, int irq_flags,
+int regmap_add_irq_chip(struct device *dev, struct regmap *map, int
irq, int irq_flags,
             int irq_base, struct regmap_irq_chip *chip,
             struct regmap_irq_chip_data **data)
 {
@@ -269,11 +269,11 @@ int regmap_add_irq_chip(struct regmap *map, int
irq, int irq_flags,
     }
 
     if (irq_base)
-        d->domain = irq_domain_add_legacy(map->dev->of_node,
+        d->domain = irq_domain_add_legacy(dev->of_node,
                           chip->num_irqs, irq_base, 0,
                           &regmap_domain_ops, d);
     else
-        d->domain = irq_domain_add_linear(map->dev->of_node,
+        d->domain = irq_domain_add_linear(dev->of_node,
                           chip->num_irqs,
                           &regmap_domain_ops, d);
     if (!d->domain) {


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ