On Thu, 2022-02-17 at 09:58 +0100, Wolfram Sang wrote: > > I think 'slave' might be a bit unclear - the driver's acting as an I2C master > > too. > > Right. Yet, AFAIU only when sending responses to other nodes, or? It > does not drive this one remote device with address 0xNN but acts itself > as device 0xMM. The Linux mctp-i2c endpoint (0xMM) can send MCTP messages to any I2C node (0xNN), as a block write master->slave. The MCTP I2C transport is bidirectional - either side can send the first message, all messages are block writes. (Hopefully I've understood your question) Most higher level protocols on top of MCTP are request/response style, though it isn't inherent. The mctp-i2c driver is mostly stateless, but it in order to deal with i2c muxes the MCTP stack has a concept of "flows" so that it will keep a bus locked for replies after sending out a request (with timeout) - that matches how higher level protocols expect to work. > Oh, and one other question I have meanwhile: do you really need > "mctp_current_mux" as a device attribute or is it mere debug and could > go away when upstream? Yes, it's really only useful for debugging since it could be outdated by the time it is read. I'll remove it, we could add something more robust if people had a need. Cheers, Matt
