Previously, the number of ports was only being set when setting an input port.
If there are multiple input ports, the number of ports wasn't being accurately
reflected.
The user application was required to update the number of ports when setting a
downstream port.
This is now done within the driver.
Signed-off-by: Andrei-Liviu Simion <andrei.simion@xilinx.com>
When setting the configuration of a port, always keep the port number of the
port structure to the same value as the index of the structure's index in the
port structure array.
This simplifies functions that operate on the port structure since they don't
need to search each port structure in the array for the port number, the port
number is known from the index.
Note: The existence of the port number member in the port structure is required
since the TX populates this structure when receiving LINK_ADDRESS sideband
messages.
Signed-off-by: Andrei-Liviu Simion <andrei.simion@xilinx.com>
The "I2C map" terminology is used to refer to a set of I2C entries for a given
port. Each I2C entry contains an I2C address associated with that entry,
alongside a user-defined data structure which is to be pointed to.
This is the mechanism for which the driver allows the RX application to control
what data to be sent for a given I2C address when a REMOTE_I2C_READ is issued
by an upstream device.
Signed-off-by: Andrei-Liviu Simion <andrei.simion@xilinx.com>
- ReplyType: The driver already checks for NACK elsewhere.
- RequestId: The link address reply will always carry the LINK_ADDRESS tag.
Signed-off-by: Andrei-Liviu Simion <andrei.simion@xilinx.com>
Both RX and TX cases use the CRC functions so having *Tx* in the function name
is incorrect.
Signed-off-by: Andrei-Liviu Simion <andrei.simion@xilinx.com>
Larger messages will need to be split into multiple fragments.
- The MsgData member carries all information.
- The FragmentNum member indicates the last fragment processed.
- The header reflects the latest fragment.
Signed-off-by: Andrei-Liviu Simion <andrei.simion@xilinx.com>
