Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
MIME-Version: 1.0
References: <8d29eba045ef18c5489e122b3668afc20431f15d.1588043236.git.baolin.wang7@gmail.com>
 <4b224e7bb703e15469e5cd79a54f7bc00a790fc5.1588043236.git.baolin.wang7@gmail.com>
 <CADBw62pDp4NByqNJ+ryUdBUi7GsW3tD8_vSN7iRGekThw0Xo+Q@mail.gmail.com> <CABb+yY2Pph4EeQtg9xSaCWHqcXr0mVNkrrFYm-E3x3f5xaxygg@mail.gmail.com>
In-Reply-To: <CABb+yY2Pph4EeQtg9xSaCWHqcXr0mVNkrrFYm-E3x3f5xaxygg@mail.gmail.com>
From:   Baolin Wang <baolin.wang7@gmail.com>
Date:   Thu, 7 May 2020 11:23:15 +0800
Message-ID: <CADBw62rrQ=Po76qpJoUj1za9Hg=T+=eEJf=Yv3UmLFLtRZvwsg@mail.gmail.com>
Subject: Re: [PATCH v4 2/2] mailbox: sprd: Add Spreadtrum mailbox driver
To:     Jassi Brar <jassisinghbrar@gmail.com>
Cc:     Rob Herring <robh+dt@kernel.org>, Orson Zhai <orsonzhai@gmail.com>,
        Chunyan Zhang <zhang.lyra@gmail.com>,
        Devicetree List <devicetree@vger.kernel.org>,
        LKML <linux-kernel@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

Hi Jassi,

On Thu, May 7, 2020 at 7:25 AM Jassi Brar <jassisinghbrar@gmail.com> wrote:
>
> On Wed, May 6, 2020 at 8:29 AM Baolin Wang <baolin.wang7@gmail.com> wrote:
> >
> > Hi Jassi,
> >
> > On Tue, Apr 28, 2020 at 11:10 AM Baolin Wang <baolin.wang7@gmail.com> wrote:
> > >
> > > From: Baolin Wang <baolin.wang@unisoc.com>
> > >
> > > The Spreadtrum mailbox controller supports 8 channels to communicate
> > > with MCUs, and it contains 2 different parts: inbox and outbox, which
> > > are used to send and receive messages by IRQ mode.
> > >
> > > Signed-off-by: Baolin Wang <baolin.wang@unisoc.com>
> > > Signed-off-by: Baolin Wang <baolin.wang7@gmail.com>
> > > ---
> > > Changes from v3:
> > >  - Save the id in mbox_chan.con_priv and remove the 'sprd_mbox_chan'
> > >
> > > Changes from v2:
> > >  - None.
> > >
> > > Changes from v1:
> > >  - None
> >
> > Gentle ping, do you have any other comments? Thanks.
> >
> Yea, I am still not sure about the error returned in send_data().  It
> will either never hit or there will be no easy recovery from it. The
> api expects the driver to tell it the last-tx was done only when it
> can send the next message. (There may be case like sending depend on
> remote, which can't be ensured before hand).

Actually this is an unusual case, suppose the remote target did not
fetch the message as soon as possile, which will cause the FIFO
overflow, so in this case we  can not send messages to the remote
target any more, otherwise messages will be lost. Thus we can return
errors to users to indicate that something wrong with the remote
target need to be checked.

So this validation in send_data() is mostly for debugging for this
abnormal case and we will not trigger this issue if the remote target
works well. So I think it is useful to keep this validation in
send_data(). Thanks.

-- 
Baolin Wang