From: Lee Jones <lee.jones@linaro.org>
To: Jassi Brar <jassisinghbrar@gmail.com>
Cc: "linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
kernel@stlinux.com, Devicetree List <devicetree@vger.kernel.org>
Subject: Re: [PATCH v2 3/6] mailbox: Add support for ST's Mailbox IP
Date: Fri, 14 Aug 2015 07:33:43 +0100 [thread overview]
Message-ID: <20150814063343.GI8782@x1> (raw)
In-Reply-To: <CABb+yY3NTHLx2N-sUABjxQW=MUCntdUg1d8kjvjH0dkb4n9EgA@mail.gmail.com>
On Thu, 13 Aug 2015, Jassi Brar wrote:
> On Mon, Jul 27, 2015 at 3:14 PM, Lee Jones <lee.jones@linaro.org> wrote:
>
> > +
> > +static bool sti_mbox_tx_is_ready(struct mbox_chan *chan)
> > +{
> > + struct sti_channel *chan_info = chan->con_priv;
> > + struct sti_mbox_device *mdev = chan_info->mdev;
> > + unsigned int instance = chan_info->instance;
> > + unsigned int channel = chan_info->channel;
> > + void __iomem *base = MBOX_BASE(mdev, instance);
> > +
> > + if (!(chan_info->direction & MBOX_TX))
> > + return false;
> >
> Here the 'direction' is gotten via DT node of the client i.e, you
> expect consumer drivers to tell the provider what its limitations are?
>
> IMO if some physical channel can't do TX then that should be either
> hardcoded inside the controller driver or learnt via DT node of the
> _controller_.
That's a fair point. I need to create a new property similar to the
already existing 'read-only'. I guess 'tx-only' is equivalent.
> > +static struct mbox_chan *sti_mbox_xlate(struct mbox_controller *mbox,
> > + const struct of_phandle_args *spec)
> > +{
> > + struct sti_mbox_device *mdev = dev_get_drvdata(mbox->dev);
> > + struct sti_mbox_pdata *pdata = dev_get_platdata(mdev->dev);
> > + struct sti_channel *chan_info;
> > + struct mbox_chan *chan = NULL;
> > + unsigned int instance = spec->args[0];
> > + unsigned int channel = spec->args[1];
> > + unsigned int direction = spec->args[2];
> > + int i;
> > +
> > + /* Bounds checking */
> > + if (instance >= pdata->num_inst || channel >= pdata->num_chan) {
> > + dev_err(mbox->dev,
> > + "Invalid channel requested instance: %d channel: %d\n",
> > + instance, channel);
> > + return NULL;
> return ERR_PTR(-EINVAL)
I can handle all these, no problem.
> > + }
> > +
> > + for (i = 0; i < mbox->num_chans; i++) {
> > + chan_info = mbox->chans[i].con_priv;
> > +
> > + /* Is requested channel free? */
> > + if (direction != MBOX_LOOPBACK &&
> >
> Consider this example when 2 clients ask for same physical channel but
> in different modes.
> mboxes = <&mboxA 0 1 MBOX_TX>;
> mboxes = <&mboxA 0 1 MBOX_LOOPBACK>;
>
> You happily assign 2 virtual channels backed by one physical channel
> {mboxA, 0, 1}. The 2 clients think they can freely do startup(),
> shutdown() and send_data() on the channels. But obviously we are
> screwed with races like
> client1.startup()
> -> client2.startup()
> -> client2.send_data()
> -> client2.shutdown()
> -> client1.send_data() XXXX
Good catch and a fair point. As you say, it's unlikely to happen, but
I would like to prevent it in any case.
> Now you can shove in some more checks to 'fix' the race OR you can
> simply expose only physical channels.
We can't expose all of the channels. There are too many and would
take up too much *unused* memory.
I don't want to have an endless stream of checks either, but we should
try to cover the bases. I think smarter (rather than more) checks is
the answer. I'll have a think about it.
> Practically no client would ever
> ask it to do what it can't, and for the hypothetical possibility that
> some does, just return error.
Right. Smarter error checking here and returning an error on a bad
config is what I plan to do.
[...]
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
next prev parent reply other threads:[~2015-08-14 6:33 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-27 9:44 [PATCH v2 0/6] Mailbox: Provide support STi based platforms Lee Jones
2015-07-27 9:44 ` [PATCH v2 1/6] mailbox: dt: Supply bindings for ST's Mailbox IP Lee Jones
2015-07-27 9:44 ` [PATCH v2 2/6] mailbox: dt-bindings: Add shared [driver <=> device tree] defines Lee Jones
2015-08-10 6:58 ` Jassi Brar
2015-08-10 8:24 ` Lee Jones
2015-08-10 8:47 ` Jassi Brar
2015-08-12 8:53 ` Lee Jones
2015-08-12 10:16 ` Jassi Brar
2015-08-12 10:43 ` Lee Jones
2015-07-27 9:44 ` [PATCH v2 3/6] mailbox: Add support for ST's Mailbox IP Lee Jones
2015-07-28 22:06 ` Paul Bolle
2015-07-30 11:45 ` Lee Jones
2015-07-30 12:48 ` Paul Bolle
2015-07-30 13:31 ` Lee Jones
2015-08-13 15:40 ` Jassi Brar
2015-08-14 6:33 ` Lee Jones [this message]
2015-08-14 7:39 ` Jassi Brar
2015-08-14 10:41 ` Lee Jones
2015-07-27 9:44 ` [PATCH v2 4/6] ARM: STi: stih407-family: Add nodes for Mailbox Lee Jones
2015-07-27 9:44 ` [PATCH v2 5/6] mailbox: Add generic mechanism for testing Mailbox Controllers Lee Jones
2015-08-10 6:45 ` Jassi Brar
2015-08-12 10:23 ` Lee Jones
2015-08-13 8:51 ` Jassi Brar
2015-08-13 9:19 ` Lee Jones
2015-08-13 10:01 ` Jassi Brar
2015-08-13 10:23 ` Lee Jones
2015-08-13 10:41 ` Jassi Brar
2015-08-13 11:00 ` Lee Jones
2015-08-13 11:10 ` Jassi Brar
2015-08-13 11:40 ` Lee Jones
2015-08-13 12:47 ` Jassi Brar
2015-08-13 13:07 ` Lee Jones
2015-08-13 13:46 ` Jassi Brar
2015-08-13 14:26 ` Lee Jones
2015-07-27 9:44 ` [PATCH v2 6/6] ARM: STi: DT: STiH407: Enable Mailbox testing facility Lee Jones
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=20150814063343.GI8782@x1 \
--to=lee.jones@linaro.org \
--cc=devicetree@vger.kernel.org \
--cc=jassisinghbrar@gmail.com \
--cc=kernel@stlinux.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@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).