RE: [PATCH v2 6/8] irqchip/al-fic: support error and fatal outputs and FIC v2

[Farber, Eliav]

On Thu, 2026-10-08 at 01:19 +0000, Radu Rendec wrote:
> I see, so you're relying on all bits being 0 out of hardware reset
> (except for the revision bits). The driver can only be compiled as
> built-in, so it will never be loaded multiple times during the lifetime
> of the kernel, which means the hardware will always be in the
> after-reset state when the driver initializes. I know nothing about 
> this particular hardware, so the question may be silly - is the
> hardware guaranteed to also reset in the case of a "soft" reboot
> (e.g. running the "reboot" command)?

Not a silly question, but the driver does not depend on it. It programs
only two bits of this register: mask_msi_x, which al_fic_wire_init() sets
when it initialises a group, and set_on_posedge, which al_fic_set_trigger()
sets or clears from irq_set_type() when the first child selects the trigger
type. Both are written unconditionally whenever the driver configures a
group, so their value does not depend on what was in the register
beforehand - after a soft reboot as much as after a cold one.

> I agree that read-modify-write is generally good practice. However, as
> part of their initialization, drivers should make sure that the
> hardware is in a known state - either by resetting it or by setting
> registers to fixed values. In this case, you're assuming it's already
> in a specific state - which is fine if that's guaranteed to always be
> the hardware reset state. In other words, I just want to make sure
> you're not missing a case when the hardware can be in a different state
> than after-reset when the driver initializes.

Agreed, and that is what happens for the two bits above - the driver sets
them to fixed values on every probe, rather than assuming what it finds.
The remaining bits are not ones the driver uses, so leaving them as it
found them does not change how it behaves.

Thanks,
Eliav