On Thu, Feb 22, 2024 at 8:56 PM Bart Van Assche <bvanassche@xxxxxxx> wrote: > > On 2/22/24 00:27, Rohit Ner wrote: > > Can we stick to the current approach of moving the .setup_xfer_req() > > up, keeping in mind the following pros? > > 1. Avoid redundant callbacks for setting up transfers > > 2. Trim the duration for which hba->outstanding_lock is acquired unnecessarily > > No, we can't. The Exynos implementation of the .setup_xfer_req() callback > is not thread-safe and relies on serialization by the caller. This patch > breaks the Exynos driver. A better title for this patch would be "Break > the setup_xfer_req() invocation". It would be inaccurate to tag this patch as breaking as Can did mention a vops use case in the hotpath for UFSHCI compliant drivers. Having two different setup_xfer_req functions for mcq/lsdb mode just because a particular vendor driver relies on serialization by the caller defeats the purpose of having vops as the core logic is still burdened with quirks. > > Bart. > Rohit.
