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 [off-list ref] wrote:

Hi Krysztof,

quoted

quoted

quoted

+  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.

quoted

quoted

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