Is the Half/Full duplex type state distinction really needed on the Spi driver?

[Dominaezzz]

I don't really see much point to this distinction.
The full duplex driver can still make half duplex transfers and all the pins are optional.
I reckon most users just create a full duplex driver regardless of which duplex mode they need or not, since discovering the existence of new_half_duplex() is not something I think people will do immediately.

Can we just remove the generic parameter and reduce the duplication between both or is there something I'm missing?

[bjoernQ]

I think the original idea to have the type was because pins are in different modes depending on the type (push-pull, input vs open-drain).

We could just have multiple constructors (without the type state) but the type state keeps users from calling functions which don't make sense depending on which constructor they used

[Dominaezzz]

Ahh I didn't realize the pins would be in different modes for each duplex type.

but the type state keeps users from calling functions which don't make sense depending on which constructor they used

I would agree if the pins weren't optional. I suppose the main controversial case is 3 wire, where transfer would just be treated as a write be the hardware.

[Dominaezzz]

but the type state keeps users from calling functions which don't make sense depending on which constructor they used

Could users have half duplex and full duplex devices on the same bus? I suppose this would be a good reason to not have the type state

[MabezDev]

I think with #1985 the need for duplication goes away, so we can probably add half duplex support back?

[Dominaezzz]

Yeah agreed