linux-kernel - Re: [RFC PATCH 1/2] irqchip: ti-tsir: Add support for Timesync Interrupt Router

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: <87ikp8jph9.ffs@tglx>
Date: Mon, 17 Feb 2025 21:17:06 +0100
From: Thomas Gleixner <tglx@...utronix.de>
To: Chintan Vankar <c-vankar@...com>, Jason Reeder <jreeder@...com>,
 vigneshr@...com, nm@...com, Paolo Abeni <pabeni@...hat.com>, Jakub
 Kicinski <kuba@...nel.org>, Eric Dumazet <edumazet@...gle.com>, "David S.
 Miller" <davem@...emloft.net>, Andrew Lunn <andrew+netdev@...n.ch>
Cc: netdev@...r.kernel.org, linux-kernel@...r.kernel.org, srk@...com,
 s-vadapalli@...com, danishanwar@...com, m-malladi@...com, Greg
 Kroah-Hartman <gregkh@...uxfoundation.org>
Subject: Re: [RFC PATCH 1/2] irqchip: ti-tsir: Add support for Timesync
 Interrupt Router

Chintan!

On Sat, Feb 15 2025 at 17:19, Chintan Vankar wrote:
> On 14/02/25 04:13, Thomas Gleixner wrote:
>> Two questions:
>> 
>>   1) For the case where no interrupt is involved, how is the routing
>>      configured?
>> 
>>   2) For the case where it routes an input line to an interupt, then how
>>      is this interrupt going to be handled by this interrupt domain which
>>      is not connected to anything and implements an empty disfunctional
>>      interrupt chip?
>> 
>
> For both the cases above the job of Timesync INTR is to map the output
> register with the corresponding input.
>
> As described in section 11.3.2.1 in the TRM at:
> https://www.ti.com/lit/ug/spruiu1d/spruiu1d.pdf,
> the job of the Timesync INTR is to provide a configuration of the
> "output registers which controls the selection". Hence we just have to
> provide configuration APIs in the Timesync INTR which programs output
> registers of the Timesync INTR. About the handling of the interrupts,
> the device which receives an interrupt needs to handle the interrupt.
>
> Could you please explain why we consider these two cases to be
> different?

They are different as

  #1 Routes the signal from one IP block to another IP block

     So there is no notion of an actual interrupt, but still you use the
     interrupt domain mechanism, which requires to allocate a Linux
     interrupt number just to configure that router.

     What's the purpose of this interrupt number and the allocated
     resources behind it?

  #2 Routes the signal from an IP block to an actual interrupt "input"

     Again, this requires to allocate a Linux interrupt number which is
     disfunctional as it is not connected in the interrupt domain
     hierarchy and just provides an interrupt chip with a name and no
     actual functionality behind it.

     So the resulting real interrupt needs yet another interrupt number
     which then maps to something which actually can handle interrupts.

So in some aspect they are not that different because both have nothing
to do with the actual concept of interrupt management in the Linux
kernel.

>From the kernel's interrupt handling POV this is a completely
transparent piece of hardware, which is not associated to any interrupt
handling mechanism. Just because the manual mentions INTR in the name of
the IP block does not make it part of the actual kernel interrupt
handling.

I have no idea into which subsystem such a SoC configuration belongs to,
but Greg might have an idea.

Thanks,

        tglx