Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Subject: =?UTF-8?B?UmU6IOWbnuWkjTogW1BBVENIXSBzcGk6IGRpc2FibGUgY2hpcHNlbGVj?=
 =?UTF-8?Q?t_after_complete_transfer?=
To:     Mark Brown <broonie@kernel.org>
Cc:     "linux-spi@vger.kernel.org" <linux-spi@vger.kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "Xue, Ying" <Ying.Xue@windriver.com>
References: <SN6PR11MB3008AF5619B0B026836FD7429F2F9@SN6PR11MB3008.namprd11.prod.outlook.com>
 <YgU1+cIlANAkJCAL@sirena.org.uk>
From:   Yun Zhou <yun.zhou@windriver.com>
Message-ID: <19c69765-8584-2e6b-25b8-7053a5afa5d4@windriver.com>
Date:   Fri, 11 Feb 2022 01:01:20 +0800
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
 Thunderbird/78.14.0
In-Reply-To: <YgU1+cIlANAkJCAL@sirena.org.uk>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?Windows-1252?Q?AisIIb+NZtqOnjAEiF3S0GTf++9nSCCsiVbof8y7Zh1i3nlYohkYBb9H?=
 =?Windows-1252?Q?eUkviucepUJ6MTD/85+0AcMIHYGnlzKqhbxEPAeWi9/HGrb1G1tBDM3S?=
 =?Windows-1252?Q?2J1gufi+em7h7J9oZ0IRzSyueg75deH1CWqxng/xk+d0U0UxIA5XZ9DT?=
 =?Windows-1252?Q?V0jHtsMvYSc92b8Ot93QyVxbSFFlTkfNIyrzVEMl7POsWDe+H+7U83Wy?=
 =?Windows-1252?Q?CyfNrpYbC9frGIwWfNCJDtbAxz/NS+dfViZck6JZs/WvepkZnxmWFJbl?=
 =?Windows-1252?Q?zNtwU/XZXtLt0N/0cHCEzyqppiazhiqJ+lL3R+o3x5GywpB1RkYoC42K?=
 =?Windows-1252?Q?V54AZN60tQYqsCW0IODZm+dJwzVZKtvLYpYDZy9qYnu921wE6BAnJS8p?=
 =?Windows-1252?Q?BcrYyMq/qgh3olKcwXTTrjZcMt7hj0uGgKtehR+Ie5pBdjXRbH67Evg8?=
 =?Windows-1252?Q?xR2rj311tmXc3bjp23jZzx85U6rra0d/Jd01d9R30EfAG62ZsIfZoLQp?=
 =?Windows-1252?Q?kt7WEgMrxnYZHkZK4S8z9zO9Pm42wwwKddBLfK600UULXr5sXFwXyEi6?=
 =?Windows-1252?Q?hZiKhRwbbOiBhQqSIwEgFgt+akwX+adc5VBzPds7+UMWL/kL25awnWVJ?=
 =?Windows-1252?Q?v+SPdXGbWIAep2DKimllOxKx6ezzM3QCYgGMAxvUVbxUpeuSWklEs3iE?=
 =?Windows-1252?Q?Ma76aedEJI38JHqdCpSSIvru/HFmyDH504C4uv1pR5+1e6Akm57KJ84a?=
 =?Windows-1252?Q?ahs9XXps1lVcBOBRpje4blPjKQUiLJ/qHLnOnRXZ7JqRpwi/JUWudOYc?=
 =?Windows-1252?Q?lnlDFBcNyoJKcwWUaIQFCkh2h+XcXtyh6ei5M//QEd1IIbd9idOR9vMb?=
 =?Windows-1252?Q?8REGDnOQbxqFnJHlQ62GXNATZqhc/6rnDmYrWE2IVct/CwZDnIVEy2fJ?=
 =?Windows-1252?Q?Mn3oqiN7yPJyjLw3NMH/fQOOCT5sJcovlt7jMwVXDq47aHjOyKgmIzEY?=
 =?Windows-1252?Q?l8/R7Ep9Mb7C1Dvodkd6TevnloritejkjacshB8lm6+uxlZPdsTShgF9?=
 =?Windows-1252?Q?vYy3gBfl3pGzMJh6hD1ReWv6fkZ312zk3HmDzJasgs7zzh9XJrwkxlWp?=
 =?Windows-1252?Q?d6+TtHwUFVbn/D9TFkikKVAy2euuRu0+m+hWV4fC5IGUG5ElInX3xtSX?=
 =?Windows-1252?Q?J87PICDAuokc/QoWPF7ZfD/S8H3PT+wYjIgBuDSJKD+s2+sfiWjXNVzD?=
 =?Windows-1252?Q?D+nZhDfX8uhnoyMtBB/GnGS8kESQ5kshuBsB6SwTwp6TH/5CznoKc2eK?=
 =?Windows-1252?Q?OLnWzWAChorYm040J6+aHGJbhsQrLWU9yCLJaBhORgkIQ2gwr7YAD7aG?=
 =?Windows-1252?Q?nOEz2BJnHOCLH8qZbrLRbT8kCNXpg1kTRtwIFf+wiN8n1MafPs6s6hxt?=
 =?Windows-1252?Q?N3JLp3VPzx813eoekUvRuHWMktyrAg610oNUjkdce5VOuTJGyiC7kPDt?=
 =?Windows-1252?Q?jK/BMd7oOkY7eH1lDZ5bXNInyQghASEG+i4aCQwIJ/xaFnaYVG+OpbYq?=
 =?Windows-1252?Q?uFLJzNCXAaDPXNnOSu1IGjf2CqDUb1MTk6DAyFfEF8pncfxPPWN2fHre?=
 =?Windows-1252?Q?vtGXJejPah+NXoeIIOIP1BASyKof3RNSJpjv9yNgdMS3dF0YWNltQTYU?=
 =?Windows-1252?Q?pQuAQsPiSU9dipYa9iKxHigiHX/4AfIdEdYj1YgI3fg/aDF7iHg09mPV?=
 =?Windows-1252?Q?jyjcCL62EsemnuFCs5E=3D?=
X-OriginatorOrg: windriver.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 158655f6-f737-49fe-1c56-08d9ecb6fc11
X-MS-Exchange-CrossTenant-AuthSource: SN6PR11MB3008.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Feb 2022 17:01:31.0412
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 8ddb2873-a1ad-4a18-ae4e-4644631433be
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: 9rB4iqyMDfOgOaiSCiOfxiNfA4iHDVv3dua3/WvbXNBKDc8nbSOvjMybYgnaLo0MtzP0UtKRoD2asjj+zVdRvQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR11MB1304
X-Proofpoint-ORIG-GUID: CnlcBKLihfshz_YX1u-HlKCwtU_VAZiN
X-Proofpoint-GUID: CnlcBKLihfshz_YX1u-HlKCwtU_VAZiN
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.205,Aquarius:18.0.816,Hydra:6.0.425,FMLib:17.11.62.513
 definitions=2022-02-10_08,2022-02-09_01,2021-12-02_01
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 impostorscore=0 bulkscore=0
 lowpriorityscore=0 priorityscore=1501 adultscore=0 suspectscore=0
 mlxlogscore=974 malwarescore=0 phishscore=0 clxscore=1015 mlxscore=0
 spamscore=0 classifier=spam adjust=0 reason=mlx scancount=1
 engine=8.12.0-2201110000 definitions=main-2202100091
X-Spam-Status: No, score=-2.8 required=5.0 tests=BAYES_00,DKIM_SIGNED,
        DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,RCVD_IN_DNSWL_LOW,
        SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham
        autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
        lindbergh.monkeyblade.net
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

Hi Brown,

>> If there are multiple messages, and each message only has one xfer,
>> and the cs_change of each xfer is 1, during the transmission of the
>> messages, the CS will keep active even until at the end. This must be
>> unreasonable.
> This is not something that most drivers are expected to use, cs_change
> should only be being used at all for very unusual hardware and it should
> be used even less frequently for the last transfer in a message.  It is
> fragile and anyone using it really needs to know what they're doing but
> the feature is there.
Maybe it's not normal to set "cs_change" in the last xfer. However, in
most cases, SPI messages come from user space, and these messages may
come from multiple different applications. We can't make the whole
controller fail to work normally due to an inappropriate message of one
application.
>
>> I can't understand why it have to keep CS active after the
>> transmission is completed. Could you please explain this in detail?
> The feature predates me working on the SPI stack, the obvious examples
> would be a device that doesn't actually use chip select where you want
> to avoid all chip select changes or if you need to do some other actions
> in the middle of a SPI transaction for some reason (which would need a
> bunch of system level considerations to actually be safe/sensible like
> making sure you're not sharing the SPI bus).
At present, if "cs_change" is not set, CS will be changed back to inactive
after the transmission is completed. If "cs_change" is set, CS will not
be changed. This obviously violates the definition of "cs_change".

Therefore, I think my patch does not break the support of "cs_change",
but consolidates the support of "cs_change". It also ensures that the whole
SPI controller will not be abnormal due to a message from userspace.

Regards,

Yun