From: Greg KH <gregkh@linuxfoundation.org>
To: Jassi Brar <jassisinghbrar@gmail.com>
Cc: linux-kernel@vger.kernel.org, s-anna@ti.com, tony@atomide.com,
omar.ramirez@copitl.com, loic.pallardy@st.com,
lftan.linux@gmail.com, slapdau@yahoo.com.au,
courtney.cavin@sonymobile.com, rafael.j.wysocki@intel.com,
Jassi Brar <jaswinder.singh@linaro.org>
Subject: Re: [PATCHv3 2/6] mailbox: Introduce a new common API
Date: Sat, 15 Feb 2014 11:15:14 -0800 [thread overview]
Message-ID: <20140215191514.GD1801@kroah.com> (raw)
In-Reply-To: <1392488727-17981-1-git-send-email-jaswinder.singh@linaro.org>
On Sat, Feb 15, 2014 at 11:55:27PM +0530, Jassi Brar wrote:
> +/*
> + * Call for IPC controller drivers to register a controller, adding
> + * its channels/mailboxes to the global pool.
> + */
> +int ipc_links_register(struct ipc_controller *ipc)
> +{
> + int i, num_links, txdone;
> + struct ipc_chan *chan;
> + struct ipc_con *con;
> +
> + /* Sanity check */
> + if (!ipc || !ipc->ops)
> + return -EINVAL;
> +
> + for (i = 0; ipc->links[i]; i++)
> + ;
> + if (!i)
> + return -EINVAL;
So you have to have links? You should document this in the function
definition. Actually, why no kerneldoc for the public functions?
> + num_links = i;
> +
> + mutex_lock(&con_mutex);
> + /* Check if already populated */
> + list_for_each_entry(con, &ipc_cons, node)
> + if (!strcmp(ipc->controller_name, con->name)) {
> + mutex_unlock(&con_mutex);
> + return -EINVAL;
> + }
> + mutex_unlock(&con_mutex);
Why drop the lock here? Shouldn't you grab it for the whole function,
as this could race if two callers want to register the same name.
> + con = kzalloc(sizeof(*con) + sizeof(*chan) * num_links, GFP_KERNEL);
Are you ok with structures on unaligned boundries? That might really
slow down some processors if your pointers are unaligned...
> + if (!con)
> + return -ENOMEM;
> +
> + INIT_LIST_HEAD(&con->channels);
> + snprintf(con->name, 16, "%s", ipc->controller_name);
Magic name size :(
> +
> + if (ipc->txdone_irq)
> + txdone = TXDONE_BY_IRQ;
> + else if (ipc->txdone_poll)
> + txdone = TXDONE_BY_POLL;
> + else /* It has to be ACK then */
> + txdone = TXDONE_BY_ACK;
> +
> + if (txdone == TXDONE_BY_POLL) {
> + con->period = ipc->txpoll_period;
> + con->poll.function = &poll_txdone;
> + con->poll.data = (unsigned long)con;
> + init_timer(&con->poll);
> + }
> +
> + chan = (void *)con + sizeof(*con);
> + for (i = 0; i < num_links; i++) {
> + chan[i].con = con;
> + chan[i].assigned = false;
> + chan[i].link_ops = ipc->ops;
> + chan[i].link = ipc->links[i];
> + chan[i].txdone_method = txdone;
> + chan[i].link->api_priv = &chan[i];
> + spin_lock_init(&chan[i].lock);
> + BLOCKING_INIT_NOTIFIER_HEAD(&chan[i].avail);
> + list_add_tail(&chan[i].node, &con->channels);
> + snprintf(chan[i].name, 16, "%s", ipc->links[i]->link_name);
Magic name size :(
> + }
> +
> + mutex_lock(&con_mutex);
> + list_add_tail(&con->node, &ipc_cons);
> + mutex_unlock(&con_mutex);
You could have raced with above, please just grab the lock for the
whole call to be safe.
> +
> + return 0;
> +}
> +EXPORT_SYMBOL(ipc_links_register);
> +
> +void ipc_links_unregister(struct ipc_controller *ipc)
> +{
> + struct ipc_con *t, *con = NULL;
> + struct ipc_chan *chan;
> +
> + mutex_lock(&con_mutex);
> +
> + list_for_each_entry(t, &ipc_cons, node)
> + if (!strcmp(ipc->controller_name, t->name)) {
> + con = t;
> + break;
> + }
> +
> + if (con)
> + list_del(&con->node);
> +
> + mutex_unlock(&con_mutex);
> +
> + if (!con)
> + return;
> +
> + list_for_each_entry(chan, &con->channels, node)
> + ipc_free_channel((void *)chan);
Why does this function take a void *? Shouldn't it take a "real"
structure pointer?
> +
> + del_timer_sync(&con->poll);
> +
> + kfree(con);
> +}
> +EXPORT_SYMBOL(ipc_links_unregister);
> +struct ipc_client {
> + char *chan_name;
> + void *cl_id;
Why a void *? Can't you have a "real" type here?
> + void (*rxcb)(void *cl_id, void *mssg);
> + void (*txcb)(void *cl_id, void *mssg, enum xfer_result r);
> + bool tx_block;
> + unsigned long tx_tout;
> + bool knows_txdone;
> + void *link_data;
> +};
> +
> +/**
> + * The Client specifies its requirements and capabilities while asking for
> + * a channel/mailbox by name. It can't be called from atomic context.
> + * The channel is exclusively allocated and can't be used by another
> + * client before the owner calls ipc_free_channel.
> + */
> +void *ipc_request_channel(struct ipc_client *cl);
Can't you return a real type, and use it everywhere? That's much
"safer" and nicer. This isn't other operating systems that have void *
everywhere and handles, we have real types in Linux :)
thanks,
greg k-h
next prev parent reply other threads:[~2014-02-15 19:13 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-02-15 18:22 [PATCHv3] Generic Mailbox API Jassi Brar
2014-02-15 18:24 ` [PATCHv3 1/6] mailbox: rename pl320-ipc specific mailbox.h Jassi Brar
2014-02-15 18:25 ` [PATCHv3 2/6] mailbox: Introduce a new common API Jassi Brar
2014-02-15 19:03 ` Greg KH
2014-02-15 19:04 ` Greg KH
2014-02-15 19:05 ` Greg KH
2014-02-15 19:15 ` Greg KH [this message]
2014-02-16 6:36 ` Jassi Brar
2014-02-16 16:36 ` Greg KH
2014-02-18 0:52 ` Courtney Cavin
2014-02-18 7:06 ` Jassi Brar
2014-02-18 17:30 ` Bjorn Andersson
2014-02-18 18:33 ` Jassi Brar
2014-02-18 19:47 ` Courtney Cavin
2014-02-19 21:43 ` Jassi Brar
2014-02-18 21:32 ` Kumar Gala
2014-02-19 10:53 ` Jassi Brar
2014-02-15 18:25 ` [PATCHv3 3/6] mailbox: pl320: Introduce common API driver Jassi Brar
2014-02-15 18:26 ` [PATCHv3 4/6] mailbox: Fix TX completion init Jassi Brar
2014-02-15 18:26 ` [PATCHv3 5/6] mailbox: Fix deleteing poll timer Jassi Brar
2014-02-15 18:27 ` [PATCHv3 6/6] mailbox: move the internal definitions into a private file Jassi Brar
2014-02-15 19:15 ` Greg KH
2014-02-15 19:16 ` Greg KH
2014-02-16 6:38 ` Jassi Brar
2014-02-17 5:57 ` [PATCHv3] Generic Mailbox API Craig McGeachie
2014-02-17 6:02 ` Jassi Brar
2014-02-17 6:03 ` Craig McGeachie
2014-02-17 6:12 ` Jassi Brar
2014-03-06 3:55 ` Jassi Brar
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=20140215191514.GD1801@kroah.com \
--to=gregkh@linuxfoundation.org \
--cc=courtney.cavin@sonymobile.com \
--cc=jassisinghbrar@gmail.com \
--cc=jaswinder.singh@linaro.org \
--cc=lftan.linux@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=loic.pallardy@st.com \
--cc=omar.ramirez@copitl.com \
--cc=rafael.j.wysocki@intel.com \
--cc=s-anna@ti.com \
--cc=slapdau@yahoo.com.au \
--cc=tony@atomide.com \
/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