Could FFM providers be given responsibility for checking for pin conflict?

[IAmNickNack]

Can FFM check pin availability prior to creating a device (it probably does already)?

If so, this could make the additional complexity introduced by #484 unnecessary.

[taartspi]

My two cents #484 is a simple check that works no matter the SBC/kernel so it should remain.

…

On Sat, Aug 1, 2026 at 3:18 AM IAmNickNack ***@***.***> wrote: *IAmNickNack* created an issue (Pi4J/pi4j#723) <#723> Can FFM check pin availability prior to creating a device? If so, this could make the additional complexity introduced by #484 <#484> unnecessary. — Reply to this email directly, view it on GitHub <#723?email_source=notifications&email_token=AK5A323KFINVES3FMWX76V35HWRVHA5CNFSL4Z3JMQ5C6L3HNF2C22DVMIXUS43TOVSS6NJQGM3DCMJZGYZDLJTSMVQXG33OVJZXKYTTMNZGSYTFMSSWK5TFNZ2KYZTPN52GK4S7MNWGSY3L>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AK5A3255WTNHMSREV4IIMLT5HWRVHAVCNFSNUABFKJSXA33TNF2G64TZHMYTSMRVHEYTMMZRHNEXG43VMU5TKMBTGYYTCOJWGI22C5QC> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[IAmNickNack]

Are there kernels for which the ioctl GPIO operations don't allow line info to be queried or don't honour GPIO_V2_LINE_FLAG_USED?

[IAmNickNack]

PWM is probably an issue too if info about the pins used by PWM isn't available to ioctl. So I'm probably barking up the wrong tree.

What's currently implemented would have to be updated if Pi4j adds a parallel/mulit-pin device

[stefanhaustein]

Assuming one background here is pin group / port support, we could fix our mutable registry to allow multiple unique identifiers per config

Keeping most of the existing system in place, we could add the following new method to Config:

default getUniqueIdentifierSet() {
  return Set.of(getUniqueIdentifier())
}

Then

• Override this directly in multipin config
• Replace all internal use cases with accessing the set
• Let the single identifier method throw in the multipin config case

I think we should also drop the id based "instances" map in MutableRegistry and only use a single map there as a single source of truth:

 private final Map<IOType, Map<Integer, IO>> usedAddressesByIoType;