linux-kernel - Re: [PATCH v2] regmap: irq: allow different device for irq chip and regmap

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-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20170630133327.bqjzrt5hecjss725@pengutronix.de>
Date:   Fri, 30 Jun 2017 15:33:27 +0200
From:   Michael Grzeschik <mgr@...gutronix.de>
To:     Mark Brown <broonie@...nel.org>
Cc:     linux-kernel@...r.kernel.org, kernel@...gutronix.de,
        Philipp Zabel <p.zabel@...gutronix.de>
Subject: Re: [PATCH v2] regmap: irq: allow different device for irq chip and
 regmap

On Fri, Jun 23, 2017 at 01:00:43PM +0100, Mark Brown wrote:
> On Thu, Jun 22, 2017 at 01:03:20PM +0200, Michael Grzeschik wrote:
> 
> > If the irq chip device is using the regmap of its parent device or
> > a syscon regmap that doesn't have an associated device at all,
> > allow the driver to provide its own device. That makes it possible
> > to reference the irq controller from other devices running on the
> > same regmap.
> 
> I would strongly expect that the regmap for a device would be associated
> with the physical device, if it's not that seems likely to create
> further problems.  How is this happening?
> 
> syscon is one potential thing here but it seems odd for the sort of
> hardware that syscon handles to be a good fit for regmap-irq.

We have the special case that we use the syscon as the basic driver
underneath some subdevices that vary in function. We have six arcnet
controllers sitting side by side in an 8 byte offset. And after them we
have the next small memory windows for an reset controller and one
interrupt controller which the other devices reference.

For that scenario the interrupt driver sitting under the "devicefree" syscon
node, we have to add our own device node with dev_regmap_add_irq_chip.

        kmae_conf: syscon@...9000000 {
                compatible = "syscon", "simple-bus";
                bits = <32>;
                reg-io-width = <1>;
                stride = <1>;
                reg = <0x09000000 0x20000>;

                com20020_1@...9014000 {
                        compatible = "smsc,com20020";
                        reg = <0x14000 0x8>;
                        interrupt-parent = <&kmae>;
                        interrupts = <0 0x4>;
                        resets = <&kmae_reset 0 0>;
                };

                com20020_2@...9014010 {
                        compatible = "smsc,com20020";
                        reg = <0x14010 0x8>;
                        interrupt-parent = <&kmae>;
                        interrupts = <1 0x4>;
                        resets = <&kmae_reset 1 0>;
                };

                com20020_3@...9014020 {
                        compatible = "smsc,com20020";
                        reg = <0x14020 0x8>;
                        interrupt-parent = <&kmae>;
                        interrupts = <2 0x4>;
                        resets = <&kmae_reset 2 0>;
                };

                com20020_4@...9014030 {
                        compatible = "smsc,com20020";
                        reg = <0x14030 0x8>;
                        interrupt-parent = <&kmae>;
                        interrupts = <3 0x4>;
                        resets = <&kmae_reset 3 0>;
                };

                com20020_5@...9014040 {
                        compatible = "smsc,com20020";
                        reg = <0x14040 0x8>;
                        interrupt-parent = <&kmae>;
                        interrupts = <4 0x4>;
                        resets = <&kmae_reset 4 0>;
                };

                com20020_6@...9014050 {
                        compatible = "smsc,com20020";
                        reg = <0x14050 0x8>;
                        interrupt-parent = <&kmae>;
                        interrupts = <5 0x4>;
                        resets = <&kmae_reset 5 0>;
                };

                kmae_reset: kmae_reset@...9014060 {
                        compatible = "eae,kmae-reset";
                        reg = <0x14060 0x8>;
                        reset-controller;
                        #reset-cells = <1>;
                };

                kmae_irq: kmae_irq@...9014060 {
                        compatible = "eae,kmae-irq";
                        reg = <0x1406c 0x2>;
                        interrupt-controller;
                        #interrupt-cells = <2>;
                        interrupt-parent = <&gpio1>;
                        interrupts = <31 0x4>;
                        gpmc = <&gpmc>;
                };
        };


You can imagine this kind of scenarios in various situations where the device
structure is loaded into an FPGA. The simplest way to memory map that packed
layout pagewise is by using syscon in that case.

Regards,
Michael

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)