linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Thierry Reding <thierry.reding@gmail.com>
To: Jassi Brar <jassisinghbrar@gmail.com>
Cc: Jon Hunter <jonathanh@nvidia.com>,
	"linux-tegra@vger.kernel.org" <linux-tegra@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v4 2/2] mailbox: Add Tegra HSP driver
Date: Wed, 16 Nov 2016 16:08:06 +0100	[thread overview]
Message-ID: <20161116150806.GA7365@ulmo.ba.sec> (raw)
In-Reply-To: <CABb+yY2NNn2nfSVbYN0Tt4iKTw8TCUJc07kC0=-==W642uGSqQ@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 5294 bytes --]

On Wed, Nov 16, 2016 at 10:58:07AM +0530, Jassi Brar wrote:
> On Tue, Nov 15, 2016 at 9:18 PM, Thierry Reding
> <thierry.reding@gmail.com> wrote:
> 
> ....
> > +
> > +struct tegra_hsp_channel;
> > +struct tegra_hsp;
> > +
> > +struct tegra_hsp_channel_ops {
> > +       int (*send_data)(struct tegra_hsp_channel *channel, void *data);
> > +       int (*startup)(struct tegra_hsp_channel *channel);
> > +       void (*shutdown)(struct tegra_hsp_channel *channel);
> > +       bool (*last_tx_done)(struct tegra_hsp_channel *channel);
> > +};
> > +
> > +struct tegra_hsp_channel {
> > +       struct tegra_hsp *hsp;
> > +       const struct tegra_hsp_channel_ops *ops;
> > +       struct mbox_chan *chan;
> > +       void __iomem *regs;
> > +};
> > +
> > +static struct tegra_hsp_channel *to_tegra_hsp_channel(struct mbox_chan *chan)
> > +{
> > +       return chan->con_priv;
> > +}
> > +
> It seems
>        channel = to_tegra_hsp_channel(chan);
> is no simpler ritual than
>        channel = chan->con_priv;   ?

Yes, that's true. I've dropped the to_tegra_hsp_channel() inline in
favour of using the chan->con_priv directly.

> > +struct tegra_hsp_doorbell {
> > +       struct tegra_hsp_channel channel;
> > +       struct list_head list;
> > +       const char *name;
> > +       unsigned int master;
> > +       unsigned int index;
> > +};
> > +
> > +static struct tegra_hsp_doorbell *
> > +to_tegra_hsp_doorbell(struct tegra_hsp_channel *channel)
> > +{
> > +       if (!channel)
> > +               return NULL;
> > +
> > +       return container_of(channel, struct tegra_hsp_doorbell, channel);
> > +}
> > +
> But you don't check for NULL returned, before dereferencing the pointer 'db'

In all the call sites where this is used the channel is guaranteed not
to be NULL, hence no checking is necessary. However the function here
could potentially be used in other cases where no such guarantees can
be given and checking the !channel above is merely there to avoid
casting to a non-NULL pointer from a NULL pointer.

I've run occasionally into this issue because container_of() will simply
perform arithmetic on the pointer given, so passing channel as NULL
would convert to some very large pointer that can no longer be easily
discerned from an invalid pointer.

So this is primarily a safety feature, and one that I'd prefer to keep
just to avoid running into issues down the road when the function gets
used under different circumstances.

> > +static bool tegra_hsp_doorbell_last_tx_done(struct tegra_hsp_channel *channel)
> > +{
> > +       return true;
> > +}
> Just curious, is the IPC done instantly after writing HSP_DB_TRIGGER
> bit? Usually there is at least some bit that stays (un)set as a 'busy
> flag'.

I don't think there's a bit like that for doorbells. The way that these
doorbells are used is in combination with a shared memory IPC protocol.
Two processors will communicate by writing to and reading from what is
essentially a ring buffer in shared memory. The doorbells are merely a
means of communicating their peer that a new entry is available in the
shared memory.

> > +static const struct tegra_hsp_channel_ops tegra_hsp_doorbell_ops = {
> > +       .send_data = tegra_hsp_doorbell_send_data,
> > +       .startup = tegra_hsp_doorbell_startup,
> > +       .shutdown = tegra_hsp_doorbell_shutdown,
> > +       .last_tx_done = tegra_hsp_doorbell_last_tx_done,
> > +};
> > +
> ....
> 
> > +static int tegra_hsp_send_data(struct mbox_chan *chan, void *data)
> > +{
> > +       struct tegra_hsp_channel *channel = to_tegra_hsp_channel(chan);
> > +
> > +       return channel->ops->send_data(channel, data);
> > +}
> > +
> > +static int tegra_hsp_startup(struct mbox_chan *chan)
> > +{
> > +       struct tegra_hsp_channel *channel = to_tegra_hsp_channel(chan);
> > +
> > +       return channel->ops->startup(channel);
> > +}
> > +
> > +static void tegra_hsp_shutdown(struct mbox_chan *chan)
> > +{
> > +       struct tegra_hsp_channel *channel = to_tegra_hsp_channel(chan);
> > +
> > +       return channel->ops->shutdown(channel);
> > +}
> > +
> > +static bool tegra_hsp_last_tx_done(struct mbox_chan *chan)
> > +{
> > +       struct tegra_hsp_channel *channel = to_tegra_hsp_channel(chan);
> > +
> > +       return channel->ops->last_tx_done(channel);
> > +}
> > +
> > +static const struct mbox_chan_ops tegra_hsp_ops = {
> > +       .send_data = tegra_hsp_send_data,
> > +       .startup = tegra_hsp_startup,
> > +       .shutdown = tegra_hsp_shutdown,
> > +       .last_tx_done = tegra_hsp_last_tx_done,
> > +};
> > +
> These 4 above seem overkill. Why not directly use tegra_hsp_doorbell_xxx() ?

This is in preparation for supporting the other synchronization
primitives that the HSP IP block exposes. Some of them use different
programming and semantics, hence why we want to have this second level
of abstraction. It will allow us to share some of the code between the
different primitives once their implementations are added.

If you feel really strongly about it, I suppose I could eliminate it,
but I suspect that we'd want to add them back in after support for the
other primitives is added.

Thanks,
Thierry

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

  reply	other threads:[~2016-11-16 15:08 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-11-15 15:48 [PATCH v4 0/2] mailbox: Add Tegra HSP driver Thierry Reding
2016-11-15 15:48 ` [PATCH v4 1/2] dt-bindings: mailbox: Add Tegra HSP binding Thierry Reding
2016-11-15 15:48 ` [PATCH v4 2/2] mailbox: Add Tegra HSP driver Thierry Reding
2016-11-16  5:28   ` Jassi Brar
2016-11-16 15:08     ` Thierry Reding [this message]
2016-11-16 15:30       ` Jassi Brar
2016-11-16 17:46         ` Thierry Reding
2016-11-16 17:41   ` [PATCH v5] " Thierry Reding
2016-11-18  8:58     ` Jassi Brar
2016-11-18 13:27       ` Thierry Reding

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20161116150806.GA7365@ulmo.ba.sec \
    --to=thierry.reding@gmail.com \
    --cc=jassisinghbrar@gmail.com \
    --cc=jonathanh@nvidia.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-tegra@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).