diff options
Diffstat (limited to 'Documentation/i2c')
| -rw-r--r-- | Documentation/i2c/busses/i2c-i801.rst | 2 | ||||
| -rw-r--r-- | Documentation/i2c/busses/i2c-piix4.rst | 13 | ||||
| -rw-r--r-- | Documentation/i2c/dev-interface.rst | 2 | ||||
| -rw-r--r-- | Documentation/i2c/i2c-protocol.rst | 11 | ||||
| -rw-r--r-- | Documentation/i2c/i2c-sysfs.rst | 24 | ||||
| -rw-r--r-- | Documentation/i2c/i2c-topology.rst | 214 | ||||
| -rw-r--r-- | Documentation/i2c/instantiating-devices.rst | 16 | ||||
| -rw-r--r-- | Documentation/i2c/slave-interface.rst | 15 | ||||
| -rw-r--r-- | Documentation/i2c/smbus-protocol.rst | 6 | ||||
| -rw-r--r-- | Documentation/i2c/summary.rst | 8 | ||||
| -rw-r--r-- | Documentation/i2c/writing-clients.rst | 19 |
11 files changed, 175 insertions, 155 deletions
diff --git a/Documentation/i2c/busses/i2c-i801.rst b/Documentation/i2c/busses/i2c-i801.rst index 42bbdd6e7fd8..ab9e850e8fe0 100644 --- a/Documentation/i2c/busses/i2c-i801.rst +++ b/Documentation/i2c/busses/i2c-i801.rst @@ -45,6 +45,8 @@ Supported adapters: * Intel Jasper Lake (SOC) * Intel Emmitsburg (PCH) * Intel Alder Lake (PCH) + * Intel Raptor Lake (PCH) + * Intel Meteor Lake (SOC) Datasheets: Publicly available at the Intel website diff --git a/Documentation/i2c/busses/i2c-piix4.rst b/Documentation/i2c/busses/i2c-piix4.rst index cc9000259223..07fe6f6f4b18 100644 --- a/Documentation/i2c/busses/i2c-piix4.rst +++ b/Documentation/i2c/busses/i2c-piix4.rst @@ -64,7 +64,7 @@ correct address for this module, you could get in big trouble (read: crashes, data corruption, etc.). Try this only as a last resort (try BIOS updates first, for example), and backup first! An even more dangerous option is 'force_addr=<IOPORT>'. This will not only enable the PIIX4 like -'force' foes, but it will also set a new base I/O port address. The SMBus +'force' does, but it will also set a new base I/O port address. The SMBus parts of the PIIX4 needs a range of 8 of these addresses to function correctly. If these addresses are already reserved by some other device, you will get into big trouble! DON'T USE THIS IF YOU ARE NOT VERY SURE @@ -86,15 +86,15 @@ If you own Force CPCI735 motherboard or other OSB4 based systems you may need to change the SMBus Interrupt Select register so the SMBus controller uses the SMI mode. -1) Use lspci command and locate the PCI device with the SMBus controller: +1) Use ``lspci`` command and locate the PCI device with the SMBus controller: 00:0f.0 ISA bridge: ServerWorks OSB4 South Bridge (rev 4f) The line may vary for different chipsets. Please consult the driver source - for all possible PCI ids (and lspci -n to match them). Lets assume the + for all possible PCI ids (and ``lspci -n`` to match them). Let's assume the device is located at 00:0f.0. 2) Now you just need to change the value in 0xD2 register. Get it first with - command: lspci -xxx -s 00:0f.0 + command: ``lspci -xxx -s 00:0f.0`` If the value is 0x3 then you need to change it to 0x1: - setpci -s 00:0f.0 d2.b=1 + ``setpci -s 00:0f.0 d2.b=1`` Please note that you don't need to do that in all cases, just when the SMBus is not working properly. @@ -109,6 +109,3 @@ which can easily get corrupted due to a state machine bug. These are mostly Thinkpad laptops, but desktop systems may also be affected. We have no list of all affected systems, so the only safe solution was to prevent access to the SMBus on all IBM systems (detected using DMI data.) - -For additional information, read: -http://www.lm-sensors.org/browser/lm-sensors/trunk/README diff --git a/Documentation/i2c/dev-interface.rst b/Documentation/i2c/dev-interface.rst index 73ad34849f99..c277a8e1202b 100644 --- a/Documentation/i2c/dev-interface.rst +++ b/Documentation/i2c/dev-interface.rst @@ -148,7 +148,7 @@ You can do plain I2C transactions by using read(2) and write(2) calls. You do not need to pass the address byte; instead, set it through ioctl I2C_SLAVE before you try to access the device. -You can do SMBus level transactions (see documentation file smbus-protocol +You can do SMBus level transactions (see documentation file smbus-protocol.rst for details) through the following functions:: __s32 i2c_smbus_write_quick(int file, __u8 value); diff --git a/Documentation/i2c/i2c-protocol.rst b/Documentation/i2c/i2c-protocol.rst index b2092f8f815d..df0febfe6410 100644 --- a/Documentation/i2c/i2c-protocol.rst +++ b/Documentation/i2c/i2c-protocol.rst @@ -2,7 +2,8 @@ The I2C Protocol ================ -This document describes the I2C protocol. Or will, when it is finished :-) +This document is an overview of the basic I2C transactions and the kernel +APIs to perform them. Key to symbols ============== @@ -12,13 +13,9 @@ S Start condition P Stop condition Rd/Wr (1 bit) Read/Write bit. Rd equals 1, Wr equals 0. A, NA (1 bit) Acknowledge (ACK) and Not Acknowledge (NACK) bit -Addr (7 bits) I2C 7 bit address. Note that this can be expanded as usual to +Addr (7 bits) I2C 7 bit address. Note that this can be expanded to get a 10 bit I2C address. -Comm (8 bits) Command byte, a data byte which often selects a register on - the device. -Data (8 bits) A plain data byte. Sometimes, I write DataLow, DataHigh - for 16 bit data. -Count (8 bits) A data byte containing the length of a block operation. +Data (8 bits) A plain data byte. [..] Data sent by I2C device, as opposed to data sent by the host adapter. diff --git a/Documentation/i2c/i2c-sysfs.rst b/Documentation/i2c/i2c-sysfs.rst index 6b68b95cd427..78c54c658fa1 100644 --- a/Documentation/i2c/i2c-sysfs.rst +++ b/Documentation/i2c/i2c-sysfs.rst @@ -51,11 +51,10 @@ Google Pixel 3 phone for example:: ``i2c-2`` is an I2C bus whose number is 2, and ``2-0049`` is an I2C device on bus 2 address 0x49 bound with a kernel driver. -Terminologies -============= +Terminology +=========== -First, let us define a couple of terminologies to avoid confusions in the later -sections. +First, let us define some terms to avoid confusion in later sections. (Physical) I2C Bus Controller ----------------------------- @@ -100,9 +99,7 @@ Caveat This may be a confusing part for people who only know about the physical I2C design of a board. It is actually possible to rename the I2C bus physical number to a different number in logical I2C bus level in Device Tree Source (DTS) under -section ``aliases``. See -`arch/arm/boot/dts/nuvoton-npcm730-gsj.dts -<../../arch/arm/boot/dts/nuvoton-npcm730-gsj.dts>`_ +section ``aliases``. See ``arch/arm/boot/dts/nuvoton-npcm730-gsj.dts`` for an example of DTS file. Best Practice: **(To kernel software developers)** It is better to keep the I2C @@ -117,7 +114,7 @@ Walk through Logical I2C Bus For the following content, we will use a more complex I2C topology as an example. Here is a brief graph for the I2C topology. If you do not understand -this graph at the first glance, do not be afraid to continue reading this doc +this graph at first glance, do not be afraid to continue reading this doc and review it when you finish reading. :: @@ -290,8 +287,7 @@ MUX channel 0, and all the way to ``i2c-19`` for the MUX channel 3. The kernel software developer is able to pin the fanout MUX channels to a static logical I2C bus number in the DTS. This doc will not go through the details on how to implement this in DTS, but we can see an example in: -`arch/arm/boot/dts/aspeed-bmc-facebook-wedge400.dts -<../../arch/arm/boot/dts/aspeed-bmc-facebook-wedge400.dts>`_ +``arch/arm/boot/dts/aspeed-bmc-facebook-wedge400.dts`` In the above example, there is an 8-channel I2C MUX at address 0x70 on physical I2C bus 2. The channel 2 of the MUX is defined as ``imux18`` in DTS, @@ -383,13 +379,9 @@ Sysfs for the I2C sensor device:: For more info on the Hwmon Sysfs, refer to the doc: -`Naming and data format standards for sysfs files -<../hwmon/sysfs-interface.rst>`_ +../hwmon/sysfs-interface.rst Instantiate I2C Devices in I2C Sysfs ------------------------------------ -Refer to the doc: - -`How to instantiate I2C devices, Method 4: Instantiate from user-space -<instantiating-devices.rst#method-4-instantiate-from-user-space>`_ +Refer to section "Method 4: Instantiate from user-space" of instantiating-devices.rst diff --git a/Documentation/i2c/i2c-topology.rst b/Documentation/i2c/i2c-topology.rst index 7cb53819778e..48fce0f7491b 100644 --- a/Documentation/i2c/i2c-topology.rst +++ b/Documentation/i2c/i2c-topology.rst @@ -5,6 +5,8 @@ I2C muxes and complex topologies There are a couple of reasons for building more complex I2C topologies than a straight-forward I2C bus with one adapter and one or more devices. +Some example use cases are: + 1. A mux may be needed on the bus to prevent address collisions. 2. The bus may be accessible from some external bus master, and arbitration @@ -14,10 +16,10 @@ than a straight-forward I2C bus with one adapter and one or more devices. from the I2C bus, at least most of the time, and sits behind a gate that has to be operated before the device can be accessed. -Etc -=== +Several types of hardware components such as I2C muxes, I2C gates and I2C +arbitrators allow to handle such needs. -These constructs are represented as I2C adapter trees by Linux, where +These components are represented as I2C adapter trees by Linux, where each adapter has a parent adapter (except the root adapter) and zero or more child adapters. The root adapter is the actual adapter that issues I2C transfers, and all adapters with a parent are part of an "i2c-mux" @@ -35,46 +37,7 @@ Locking ======= There are two variants of locking available to I2C muxes, they can be -mux-locked or parent-locked muxes. As is evident from below, it can be -useful to know if a mux is mux-locked or if it is parent-locked. The -following list was correct at the time of writing: - -In drivers/i2c/muxes/: - -====================== ============================================= -i2c-arb-gpio-challenge Parent-locked -i2c-mux-gpio Normally parent-locked, mux-locked iff - all involved gpio pins are controlled by the - same I2C root adapter that they mux. -i2c-mux-gpmux Normally parent-locked, mux-locked iff - specified in device-tree. -i2c-mux-ltc4306 Mux-locked -i2c-mux-mlxcpld Parent-locked -i2c-mux-pca9541 Parent-locked -i2c-mux-pca954x Parent-locked -i2c-mux-pinctrl Normally parent-locked, mux-locked iff - all involved pinctrl devices are controlled - by the same I2C root adapter that they mux. -i2c-mux-reg Parent-locked -====================== ============================================= - -In drivers/iio/: - -====================== ============================================= -gyro/mpu3050 Mux-locked -imu/inv_mpu6050/ Mux-locked -====================== ============================================= - -In drivers/media/: - -======================= ============================================= -dvb-frontends/lgdt3306a Mux-locked -dvb-frontends/m88ds3103 Parent-locked -dvb-frontends/rtl2830 Parent-locked -dvb-frontends/rtl2832 Mux-locked -dvb-frontends/si2168 Mux-locked -usb/cx231xx/ Parent-locked -======================= ============================================= +mux-locked or parent-locked muxes. Mux-locked muxes @@ -89,40 +52,8 @@ full transaction, unrelated I2C transfers may interleave the different stages of the transaction. This has the benefit that the mux driver may be easier and cleaner to implement, but it has some caveats. -==== ===================================================================== -ML1. If you build a topology with a mux-locked mux being the parent - of a parent-locked mux, this might break the expectation from the - parent-locked mux that the root adapter is locked during the - transaction. - -ML2. It is not safe to build arbitrary topologies with two (or more) - mux-locked muxes that are not siblings, when there are address - collisions between the devices on the child adapters of these - non-sibling muxes. - - I.e. the select-transfer-deselect transaction targeting e.g. device - address 0x42 behind mux-one may be interleaved with a similar - operation targeting device address 0x42 behind mux-two. The - intension with such a topology would in this hypothetical example - be that mux-one and mux-two should not be selected simultaneously, - but mux-locked muxes do not guarantee that in all topologies. - -ML3. A mux-locked mux cannot be used by a driver for auto-closing - gates/muxes, i.e. something that closes automatically after a given - number (one, in most cases) of I2C transfers. Unrelated I2C transfers - may creep in and close prematurely. - -ML4. If any non-I2C operation in the mux driver changes the I2C mux state, - the driver has to lock the root adapter during that operation. - Otherwise garbage may appear on the bus as seen from devices - behind the mux, when an unrelated I2C transfer is in flight during - the non-I2C mux-changing operation. -==== ===================================================================== - - Mux-locked Example ------------------- - +~~~~~~~~~~~~~~~~~~ :: @@ -153,6 +84,43 @@ This means that accesses to D2 are lockout out for the full duration of the entire operation. But accesses to D3 are possibly interleaved at any point. +Mux-locked caveats +~~~~~~~~~~~~~~~~~~ + +When using a mux-locked mux, be aware of the following restrictions: + +[ML1] + If you build a topology with a mux-locked mux being the parent + of a parent-locked mux, this might break the expectation from the + parent-locked mux that the root adapter is locked during the + transaction. + +[ML2] + It is not safe to build arbitrary topologies with two (or more) + mux-locked muxes that are not siblings, when there are address + collisions between the devices on the child adapters of these + non-sibling muxes. + + I.e. the select-transfer-deselect transaction targeting e.g. device + address 0x42 behind mux-one may be interleaved with a similar + operation targeting device address 0x42 behind mux-two. The + intent with such a topology would in this hypothetical example + be that mux-one and mux-two should not be selected simultaneously, + but mux-locked muxes do not guarantee that in all topologies. + +[ML3] + A mux-locked mux cannot be used by a driver for auto-closing + gates/muxes, i.e. something that closes automatically after a given + number (one, in most cases) of I2C transfers. Unrelated I2C transfers + may creep in and close prematurely. + +[ML4] + If any non-I2C operation in the mux driver changes the I2C mux state, + the driver has to lock the root adapter during that operation. + Otherwise garbage may appear on the bus as seen from devices + behind the mux, when an unrelated I2C transfer is in flight during + the non-I2C mux-changing operation. + Parent-locked muxes ------------------- @@ -161,28 +129,10 @@ Parent-locked muxes lock the parent adapter during the full select- transfer-deselect transaction. The implication is that the mux driver has to ensure that any and all I2C transfers through that parent adapter during the transaction are unlocked I2C transfers (using e.g. -__i2c_transfer), or a deadlock will follow. There are a couple of -caveats. - -==== ==================================================================== -PL1. If you build a topology with a parent-locked mux being the child - of another mux, this might break a possible assumption from the - child mux that the root adapter is unused between its select op - and the actual transfer (e.g. if the child mux is auto-closing - and the parent mux issues I2C transfers as part of its select). - This is especially the case if the parent mux is mux-locked, but - it may also happen if the parent mux is parent-locked. - -PL2. If select/deselect calls out to other subsystems such as gpio, - pinctrl, regmap or iio, it is essential that any I2C transfers - caused by these subsystems are unlocked. This can be convoluted to - accomplish, maybe even impossible if an acceptably clean solution - is sought. -==== ==================================================================== - +__i2c_transfer), or a deadlock will follow. Parent-locked Example ---------------------- +~~~~~~~~~~~~~~~~~~~~~ :: @@ -212,10 +162,30 @@ When there is an access to D1, this happens: 9. M1 unlocks its parent adapter. 10. M1 unlocks muxes on its parent. - This means that accesses to both D2 and D3 are locked out for the full duration of the entire operation. +Parent-locked Caveats +~~~~~~~~~~~~~~~~~~~~~ + +When using a parent-locked mux, be aware of the following restrictions: + +[PL1] + If you build a topology with a parent-locked mux being the child + of another mux, this might break a possible assumption from the + child mux that the root adapter is unused between its select op + and the actual transfer (e.g. if the child mux is auto-closing + and the parent mux issues I2C transfers as part of its select). + This is especially the case if the parent mux is mux-locked, but + it may also happen if the parent mux is parent-locked. + +[PL2] + If select/deselect calls out to other subsystems such as gpio, + pinctrl, regmap or iio, it is essential that any I2C transfers + caused by these subsystems are unlocked. This can be convoluted to + accomplish, maybe even impossible if an acceptably clean solution + is sought. + Complex Examples ================ @@ -261,8 +231,10 @@ This is a good topology:: When device D1 is accessed, accesses to D2 are locked out for the full duration of the operation (muxes on the top child adapter of M1 are locked). But accesses to D3 and D4 are possibly interleaved at -any point. Accesses to D3 locks out D1 and D2, but accesses to D4 -are still possibly interleaved. +any point. + +Accesses to D3 locks out D1 and D2, but accesses to D4 are still possibly +interleaved. Mux-locked mux as parent of parent-locked mux @@ -394,3 +366,47 @@ This is a good topology:: When D1 or D2 are accessed, accesses to D3 and D4 are locked out while accesses to D5 may interleave. When D3 or D4 are accessed, accesses to all other devices are locked out. + + +Mux type of existing device drivers +=================================== + +Whether a device is mux-locked or parent-locked depends on its +implementation. The following list was correct at the time of writing: + +In drivers/i2c/muxes/: + +====================== ============================================= +i2c-arb-gpio-challenge Parent-locked +i2c-mux-gpio Normally parent-locked, mux-locked iff + all involved gpio pins are controlled by the + same I2C root adapter that they mux. +i2c-mux-gpmux Normally parent-locked, mux-locked iff + specified in device-tree. +i2c-mux-ltc4306 Mux-locked +i2c-mux-mlxcpld Parent-locked +i2c-mux-pca9541 Parent-locked +i2c-mux-pca954x Parent-locked +i2c-mux-pinctrl Normally parent-locked, mux-locked iff + all involved pinctrl devices are controlled + by the same I2C root adapter that they mux. +i2c-mux-reg Parent-locked +====================== ============================================= + +In drivers/iio/: + +====================== ============================================= +gyro/mpu3050 Mux-locked +imu/inv_mpu6050/ Mux-locked +====================== ============================================= + +In drivers/media/: + +======================= ============================================= +dvb-frontends/lgdt3306a Mux-locked +dvb-frontends/m88ds3103 Parent-locked +dvb-frontends/rtl2830 Parent-locked +dvb-frontends/rtl2832 Mux-locked +dvb-frontends/si2168 Mux-locked +usb/cx231xx/ Parent-locked +======================= ============================================= diff --git a/Documentation/i2c/instantiating-devices.rst b/Documentation/i2c/instantiating-devices.rst index 890c9360ce19..3ea056a95812 100644 --- a/Documentation/i2c/instantiating-devices.rst +++ b/Documentation/i2c/instantiating-devices.rst @@ -31,7 +31,9 @@ Declare the I2C devices via devicetree On platforms using devicetree, the declaration of I2C devices is done in subnodes of the master controller. -Example:: +Example: + +.. code-block:: dts i2c1: i2c@400a0000 { /* ... master properties skipped ... */ @@ -71,7 +73,9 @@ code. Instantiating I2C devices via board files is done with an array of struct i2c_board_info which is registered by calling i2c_register_board_info(). -Example (from omap2 h4):: +Example (from omap2 h4): + +.. code-block:: c static struct i2c_board_info h4_i2c_board_info[] __initdata = { { @@ -111,7 +115,9 @@ bus in advance, so the method 1 described above can't be used. Instead, you can instantiate your I2C devices explicitly. This is done by filling a struct i2c_board_info and calling i2c_new_client_device(). -Example (from the sfe4001 network driver):: +Example (from the sfe4001 network driver): + +.. code-block:: c static struct i2c_board_info sfe4001_hwmon_info = { I2C_BOARD_INFO("max6647", 0x4e), @@ -136,7 +142,9 @@ it may have different addresses from one board to the next (manufacturer changing its design without notice). In this case, you can call i2c_new_scanned_device() instead of i2c_new_client_device(). -Example (from the nxp OHCI driver):: +Example (from the nxp OHCI driver): + +.. code-block:: c static const unsigned short normal_i2c[] = { 0x2c, 0x2d, I2C_CLIENT_END }; diff --git a/Documentation/i2c/slave-interface.rst b/Documentation/i2c/slave-interface.rst index 82ea3e1d6fe4..3f0d320bc80a 100644 --- a/Documentation/i2c/slave-interface.rst +++ b/Documentation/i2c/slave-interface.rst @@ -32,9 +32,9 @@ User manual =========== I2C slave backends behave like standard I2C clients. So, you can instantiate -them as described in the document 'instantiating-devices'. The only difference -is that i2c slave backends have their own address space. So, you have to add -0x1000 to the address you would originally request. An example for +them as described in the document instantiating-devices.rst. The only +difference is that i2c slave backends have their own address space. So, you +have to add 0x1000 to the address you would originally request. An example for instantiating the slave-eeprom driver from userspace at the 7 bit address 0x64 on bus 1:: @@ -72,12 +72,15 @@ Event types: 'val': unused - 'ret': always 0 + 'ret': 0 if the backend is ready, otherwise some errno Another I2C master wants to write data to us. This event should be sent once our own address and the write bit was detected. The data did not arrive yet, so -there is nothing to process or return. Wakeup or initialization probably needs -to be done, though. +there is nothing to process or return. After returning, the bus driver must +always ack the address phase. If 'ret' is zero, backend initialization or +wakeup is done and further data may be received. If 'ret' is an errno, the bus +driver should nack all incoming bytes until the next stop condition to enforce +a retry of the transmission. * I2C_SLAVE_READ_REQUESTED (mandatory) diff --git a/Documentation/i2c/smbus-protocol.rst b/Documentation/i2c/smbus-protocol.rst index 00d8e17d0aca..4942c4cad4ad 100644 --- a/Documentation/i2c/smbus-protocol.rst +++ b/Documentation/i2c/smbus-protocol.rst @@ -41,12 +41,12 @@ Sr Repeated start condition, used to switch from write to P Stop condition Rd/Wr (1 bit) Read/Write bit. Rd equals 1, Wr equals 0. A, NA (1 bit) Acknowledge (ACK) and Not Acknowledge (NACK) bit -Addr (7 bits) I2C 7 bit address. Note that this can be expanded as usual to +Addr (7 bits) I2C 7 bit address. Note that this can be expanded to get a 10 bit I2C address. Comm (8 bits) Command byte, a data byte which often selects a register on the device. -Data (8 bits) A plain data byte. Sometimes, I write DataLow, DataHigh - for 16 bit data. +Data (8 bits) A plain data byte. DataLow and DataHigh represent the low and + high byte of a 16 bit word. Count (8 bits) A data byte containing the length of a block operation. [..] Data sent by I2C device, as opposed to data sent by the host diff --git a/Documentation/i2c/summary.rst b/Documentation/i2c/summary.rst index 136c4e333be7..786c618ba3be 100644 --- a/Documentation/i2c/summary.rst +++ b/Documentation/i2c/summary.rst @@ -11,9 +11,11 @@ systems. Some systems use variants that don't meet branding requirements, and so are not advertised as being I2C but come under different names, e.g. TWI (Two Wire Interface), IIC. -The official I2C specification is the `"I2C-bus specification and user -manual" (UM10204) <https://www.nxp.com/docs/en/user-guide/UM10204.pdf>`_ -published by NXP Semiconductors. +The latest official I2C specification is the `"I2C-bus specification and user +manual" (UM10204) <https://www.nxp.com/webapp/Download?colCode=UM10204>`_ +published by NXP Semiconductors. However, you need to log-in to the site to +access the PDF. An older version of the specification (revision 6) is archived +`here <https://web.archive.org/web/20210813122132/https://www.nxp.com/docs/en/user-guide/UM10204.pdf>`_. SMBus (System Management Bus) is based on the I2C protocol, and is mostly a subset of I2C protocols and signaling. Many I2C devices will work on an diff --git a/Documentation/i2c/writing-clients.rst b/Documentation/i2c/writing-clients.rst index 978cc8210bf3..b7d3ae7458f8 100644 --- a/Documentation/i2c/writing-clients.rst +++ b/Documentation/i2c/writing-clients.rst @@ -46,7 +46,7 @@ driver model device node, and its I2C address. }, .id_table = foo_idtable, - .probe = foo_probe, + .probe_new = foo_probe, .remove = foo_remove, /* if device autodetection is needed: */ .class = I2C_CLASS_SOMETHING, @@ -155,9 +155,8 @@ those devices, and a remove() method to unbind. :: - static int foo_probe(struct i2c_client *client, - const struct i2c_device_id *id); - static int foo_remove(struct i2c_client *client); + static int foo_probe(struct i2c_client *client); + static void foo_remove(struct i2c_client *client); Remember that the i2c_driver does not create those client handles. The handle may be used during foo_probe(). If foo_probe() reports success @@ -165,8 +164,12 @@ handle may be used during foo_probe(). If foo_probe() reports success foo_remove() returns. That binding model is used by most Linux drivers. The probe function is called when an entry in the id_table name field -matches the device's name. It is passed the entry that was matched so -the driver knows which one in the table matched. +matches the device's name. If the probe function needs that entry, it +can retrieve it using + +:: + + const struct i2c_device_id *id = i2c_match_id(foo_idtable, client); Device Creation @@ -361,7 +364,7 @@ stop condition is issued between transaction. The i2c_msg structure contains for each message the client address, the number of bytes of the message and the message data itself. -You can read the file ``i2c-protocol`` for more information about the +You can read the file i2c-protocol.rst for more information about the actual I2C protocol. @@ -411,7 +414,7 @@ transactions return 0 on success; the 'read' transactions return the read value, except for block transactions, which return the number of values read. The block buffers need not be longer than 32 bytes. -You can read the file ``smbus-protocol`` for more information about the +You can read the file smbus-protocol.rst for more information about the actual SMBus protocol. |