public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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

  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