Hi Ryan,

quoted

Not at all - the next paragraph was my attempt at a recap of those, but Ryan,
please correct me if I am wrong on any of those points.

Your understanding is correct; the byte and buffer mode is mostly the same.
And also mode should be decided before xfer, due to the controller/target
both use the same xfer mode, not decide by transfer time.
The original my submit is only buffer mode and dma mode, and use only one
Boolean property, aspeed,i2c-dma-enabled, but someone suggest add byte
mode select, so I start to add at v17. I can drop the byte mode, if this is confused.

byte mode request:
https://lore.kernel.org/all/010e55e9-d58b-444c-ab57-ddf8c75f2390@gmail.com/ (local)

I understand that there may be valid uses for byte mode, but that does
not mean the configuration belongs in the device tree.

We do not seem to have much data on what those valid uses are, but I am
assuming it is not an attribute of the controller peripheral hardware.

[As an example: I suspect MCTP cannot be fully spec-compliant without
byte mode, in order to support the NAK window on target-mode RX. In that
case we can enforce byte mode when the controller is selected for MCTP
use, without requiring a mode selection property in the DT]

quoted

Ryan: I think this gives us a much cleaner approach to the binding.

Thanks the feedback, do you mean, just one boolean property for mode selection,
Am I right?

The property would not select a mode, it just indicates whether DMA is
available.

A driver implementation can use that indication, along with any other
configuration data, in order to select a mode. The Linux driver
implementation may use other runtime facilities to control that
selection, if you need, like sysfs or configfs.

Cheers,


Jeremy