netdev - 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] [day] [month] [year] [list]

Message-ID: <b399c73b-359a-4dde-acc3-0bf4aea900e9@ti.com>
Date: Thu, 20 Feb 2025 01:05:58 +0530
From: "Vankar, Chintan" <c-vankar@...com>
To: Thomas Gleixner <tglx@...utronix.de>, 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

Hello Thomas/Greg,

On 2/18/2025 1:47 AM, Thomas Gleixner wrote:
> 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 for the reviewing the patch. Since you suggest to implement it
with a different subsystem, I want your and Greg's suggestion for that.

As we discussed and also from the documentation, Timesync INTR should be
configured by programming it's output registers to control the selection
corresponding to the input. Mux-controller subsystem also works on the
similar kind of principle, to program the output by selectively choosing
from multiple input sources, I am trying to relate Timesync INTR with
that subsystem.

Could you please suggest if the implementation can be achieved using the
mux-subsystem ?


Regards,
Chintan.

> Thanks,
> 
>          tglx