linux-kernel - Re: [PATCH 1/2] dt-bindings: i3c: dw: Add property to select IBI ops

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: <CAMmmMt25nkZTXXLCVGv1baf3azQR0kwbM8LP4EzCQKOPLUhbVQ@mail.gmail.com>
Date: Wed, 26 Jun 2024 14:22:24 +0530
From: "Aniket ." <aniketmaurya@...gle.com>
To: Jeremy Kerr <jk@...econstruct.com.au>
Cc: Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>, 
	Alexandre Belloni <alexandre.belloni@...tlin.com>, Joel Stanley <joel@....id.au>, 
	Billy Tsai <billy_tsai@...eedtech.com>, Rob Herring <robh@...nel.org>, 
	Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>, linux-i3c@...ts.infradead.org, 
	linux-kernel@...r.kernel.org, devicetree@...r.kernel.org
Subject: Re: [PATCH 1/2] dt-bindings: i3c: dw: Add property to select IBI ops

Hi Jeremy,

> Aniket: the hardware you're dealing with there may need a new, specific
> compatible property, which will dictate whether we enable IBIs in the
> driver.
>
> For cases where no other special behaviour is required, we can
> represent this just as an entry in the OF match table.

Actually I see that IBI support is always present in the HW(DW I3C
IP). It's just that we have
an option in SW to decide whether to populate function pointers for IBI or not.
So can we remove this selection of ops and always go with ibi ops?

Thanks,
Aniket.

On Wed, Jun 26, 2024 at 1:48 PM Jeremy Kerr <jk@...econstruct.com.au> wrote:
>
> Hi Krysztof,
>
> > > > +  ibi-capable:
> > > > +    description: Set to select IBI ops.
> >
> > What are IBI ops? Standard form letter:
> >
> > You described the desired Linux feature or behavior, not the actual
> > hardware.
>
> In this case it is the actual hardware; my understanding is that the
> gateware IP can be configured to support in-band-interrupts or not,
> before being baked-in to hardware.
>
> > > Wouldn't the compatible string select whether the hardware instance
> > > supports IBI or not?
> > >
> > > I'd imagine that each specific synthesis of the DW IP would imply
> > > corresponding hardware settings, and so would warrant its own
> > > compatible
> > > value.
> > >
> > > Maybe one for the DT folks: would this work better as individual
> > > properties? Is there a policy here?
> >
> > Usually if feature is specific to given hardware, e.g. always capable
> > of foobar, then it can be deduced from compatible, so no need for new
> > property.
>
> Sounds good.
>
> Aniket: the hardware you're dealing with there may need a new, specific
> compatible property, which will dictate whether we enable IBIs in the
> driver.
>
> For cases where no other special behaviour is required, we can
> represent this just as an entry in the OF match table.
>
> Cheers,
>
>
> Jeremy