On Mon, Feb 14, 2022 at 10:20:21PM +0800, Yun Zhou wrote:From the first commit(8ae12a0d85987dc13) for spi subsystem, we can see that:
I can't see from anywhere that when cs_change is true, we must keep CS
active. If an individual controller needs to keep CS active after the whole
message transmission complete, I think we should set cs_change to false
rather than true, because cs_change means to change CS, not keep CS,
otherwise let us rename cs_change to cs_keep.
*sigh* Please also look back at how this has historically been handled,
this is not new behaviour.
I'm not saying that this is the greatest APIAlthough the logic dealing with cs_change in spi_transfer_one_message() has existed a long time and nobody reports issue on it, that doesn't mean it is correct. I think the main reason is, cs_change is only used to change chipselect inactive in the middle of message, and nobody set it at the end of message. Even if the cs_change of the end of message is set to true, probably there is no impact before d347b4aaa1a042ea528e385d9070b74c77a14321, since no matter the chipselect is active or inactive, we will set it to active before a new message. Even if meet an issue, most of users think it is the incorrect usage himself, and then the issue can be solved easily by clearing cs_change of the end of message.
ever or that it'd be done this way if it were new but that doesn't mean
we can just randomly change the interface and potentially disrupt users.
Whatever else is going on the current behaviour is intentional.