On Fri, 18 Aug 2023 at 10:13, Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx> wrote:
>
> On Fri, Aug 11, 2023 at 10:07:43PM +0800, Weili Qian wrote:
> > The malibox needs to be triggered by a 128bit atomic operation. The
> > reason is that one QM hardware entity in one accelerator servers QM
> > mailbox MMIO interfaces in related PF and VFs. A mutex cannot lock
> > mailbox processes in different functions. When multiple functions access
> > the mailbox simultaneously, if the generic IO interface readq/writeq
> > is used to access the mailbox, the data read from mailbox or written to
> > mailbox is unpredictable. Therefore, the generic IO interface is changed
> > to a 128bit atomic operation.
> >
> > Signed-off-by: Weili Qian <qianweili@xxxxxxxxxx>
> > ---
> > drivers/crypto/hisilicon/qm.c | 160 ++++++++++++++++++++++------------
> > include/linux/hisi_acc_qm.h | 1 -
> > 2 files changed, 105 insertions(+), 56 deletions(-)
> > mode change 100644 => 100755 drivers/crypto/hisilicon/qm.c
>
> ...
>
> > - qm_mb_write(qm, mailbox);
> > +#if IS_ENABLED(CONFIG_ARM64)
> > + asm volatile("ldp %0, %1, %3\n"
> > + "stp %0, %1, %2\n"
> > + "dmb oshst\n"
> > + : "=&r" (tmp0),
> > + "=&r" (tmp1),
> > + "+Q" (*((char *)dst))
> > + : "Q" (*((char __iomem *)fun_base))
> > + : "memory");
> > +#endif
>
> You should add a generic 128-bite write primitive for arm64 instead
> of doing it in raw assembly in the driver.
>
IIRC there have been other cases (ThunderX?) where 128 bit MMIO
accessors were needed for some peripheral, but common arm64 helpers
were rejected on the basis that this atomic behavior is not
architectural.
Obviously, using inline asm in the driver is not the right way either,
so perhaps we should consider introducing some common infrastructure
anyway, including some expectation management about their guarantees.
