i2c_new_ancillary_device(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

πŸ¦‹ i2c_new_ancillary_device πŸ¦‹

okay bestie, welcome to the Kernel API Manual page for i2c_new_ancillary_device(9) β€” that's the manual name, and we're about to make secondary addresses make sense πŸ’–

✨ NAME ✨

i2c_new_ancillary_device β€” helper to get the instantiated secondary address and create the associated device. periodt ✨

πŸŽ€ SYNOPSIS πŸŽ€

struct i2c_client * i2c_new_ancillary_device (struct i2c_client *client
, const char *name , u16 default_addr );

πŸ’… ARGUMENTS πŸ’…

  • client β€” handle to the primary client, aka your main character here.
  • name β€” handle to specify which secondary address to get. tell it which one you want, bestie.
  • default_addr β€” used as a fallback if no secondary address was specified.

🌸 CONTEXT 🌸

can sleep 😴 β€” yes, literally. this one can sleep.

πŸ¦‹ DESCRIPTION πŸ¦‹

okay so picture this: I2C clients can be composed of multiple I2C slaves bound together in a single component. The I2C client driver then binds to the master I2C slave, and it needs to create I2C dummy clients to communicate with all the other slaves. it's giving teamwork 🀝

This function makes an I2C dummy client and hands it back; its I2C address comes from the platform firmware based on the slave name you passed in. If no address is specified by the firmware, default_addr is used. fallback era ✨

On DT-based platforms the address is retrieved from the "reg" property entry cell whose "reg-names" value matches the slave name. cute, specific, iconic πŸ’…

What you get back is the new i2c client, which should be saved for later use with i2c_unregister_device; or an ERR_PTR to describe the error. so like, keep track of it or you'll be sad 😭

πŸ”₯ SEE ALSO πŸ”₯

Kernel file ./drivers/i2c/i2c-core-base.c is the spot, and these are the related bbs:

mwah πŸ’‹ source/version ./drivers/i2c, date October 2026, manual i2c_new_ancillary_device(9) β€” bye bestie, go slay those dummy clients 🫢✨

πŸ“¦ where this page comes from