Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Tue, 16 May 2023 10:41:14 +0000
From:   Charles Keepax <ckeepax@opensource.cirrus.com>
To:     Lee Jones <lee@kernel.org>
CC:     Marc Zyngier <maz@kernel.org>, <broonie@kernel.org>,
        <robh+dt@kernel.org>, <krzysztof.kozlowski+dt@linaro.org>,
        <conor+dt@kernel.org>, <tglx@linutronix.de>,
        <linus.walleij@linaro.org>, <vkoul@kernel.org>,
        <lgirdwood@gmail.com>, <yung-chuan.liao@linux.intel.com>,
        <sanyog.r.kale@intel.com>, <pierre-louis.bossart@linux.intel.com>,
        <alsa-devel@alsa-project.org>, <patches@opensource.cirrus.com>,
        <devicetree@vger.kernel.org>, <linux-gpio@vger.kernel.org>,
        <linux-spi@vger.kernel.org>, <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 07/10] irqchip/cs42l43: Add support for the cs42l43 IRQs
Message-ID: <20230516104114.GU68926@ediswmail.ad.cirrus.com>
References: <20230512122838.243002-1-ckeepax@opensource.cirrus.com>
 <20230512122838.243002-8-ckeepax@opensource.cirrus.com>
 <86o7mpmvqq.wl-maz@kernel.org>
 <20230512153933.GH68926@ediswmail.ad.cirrus.com>
 <86mt29mt2m.wl-maz@kernel.org>
 <20230515112554.GA10825@google.com>
 <86h6scmzf7.wl-maz@kernel.org>
 <20230516100936.GF10825@google.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <20230516100936.GF10825@google.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Precedence: bulk

On Tue, May 16, 2023 at 11:09:36AM +0100, Lee Jones wrote:
> On Tue, 16 May 2023, Marc Zyngier wrote:
> > On Mon, 15 May 2023 12:25:54 +0100,
> > Lee Jones <lee@kernel.org> wrote:
> > > On Fri, 12 May 2023, Marc Zyngier wrote:
> > > > On Fri, 12 May 2023 16:39:33 +0100,
> > > > Charles Keepax <ckeepax@opensource.cirrus.com> wrote:
> > > I'm not aware of another subsystem that deals with !IRQChip level IRQ
> > > controllers.  Where do simple or "second class" interrupt controllers
> > > go?
> > 
> > This isn't an interrupt controller. This is internal signalling, local
> > to a single component that has been artificially broken into discrete
> > bits, including an interrupt controller. The only *real* interrupts
> > here are the GPIOs.
> > 

I would question this statement a little, they are fixed function
IRQs sure but they are still real interrupts. These are lines which
receive a signal and on an edge they set a stick status bit, which
causes another signal to generate an edge, they have registers
which let you mask events, if it walks like a duck and all. The
only difference between this and a "real" interrupt is whether the
chip designer or the board designer was the person who decided
where the wire was connected.

> > I'm happy to see an interrupt controller for the GPIOs. But the rest
> > is just internal muck that doesn't really belong here. Where should it

Internal-ish, granted many of them are primarily useful to the
device itself. But it is very easy to construct situations where
say knowing the speaker thermals are high, or that a jack has
been inserted are useful outside of the CODEC driver itself.

> > go? Together with the rest of the stuff that manages the block as a
> > whole. Which looks like the MFD subsystem to me.
> 
> Very well.  Let's see this "muck" in a patch please!

Groovy I will do a re-spin moving the IRQ stuff to the MFD and
lets see where we get to.

Thank you all for your help in reviewing this so far.

Thanks,
Charles