ptp_find_pin(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

ptp_find_pin(9) β€” the Kernel API Manual, bestie edition πŸ’…βœ¨

okay so this is ptp_find_pin, and it's literally the glow-up you need when you're trying to figure out which pin handles a specific auxiliary function. iconic behavior, no cap. πŸŽ€


✨ NAME ✨

ptp_find_pin β€” obtain the pin index of a given auxiliary function 🫢

🌸 SYNOPSIS 🌸

int ptp_find_pin (struct ptp_clock *ptp , enum ptp_pin_function func ,
unsigned int chan );

πŸ¦‹ ARGUMENTS πŸ¦‹

  • ptp β€” the clock you got from ptp_clock_register. your main character struct, basically πŸ‘‘
  • func β€” one of the ptp_pin_function enumerated values. pick your vibe from the enum πŸ’«
  • chan β€” the particular functional channel to find. yes, the particular one, be specific bestie πŸ”

πŸ’– DESCRIPTION πŸ’–

okay so the tea is: the caller must hold ptp_clock::pincfg_mux. that's the rule, fr fr.

and here's the little plot twist 😭 β€” drivers do not have access to that mutex, because ptp_clock is an opaque type. so you can't just grab it yourself, rude but that's how it is.

but wait, it gets better: the core code acquires the mutex before invoking the driver's ptp_clock_info::enable callback. so drivers may call this function from that context. slay, problem solved ✨

πŸ”₯ RETURN πŸ”₯

  • pin index in the range of zero to ptp_clock_caps.n_pins - 1 πŸ’…
  • or -1 if the auxiliary function cannot be found. not found = you get the -1, sorry bestie 😭

🌈 SEE ALSO 🌈


and that's the whole vibe check, bestie πŸ§šπŸ’œ this lil page lives over in ./include/linux, dated October 2026, and it's filed under ptp_find_pin(9) β€” go off, you've got this πŸŒŸπŸ“

πŸ“¦ where this page comes from