[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CABb+yY3N0e3yTf=+2aqM0gWM8xcnybBWNSJxGezUC5uckAQBGg@mail.gmail.com>
Date: Sat, 29 Mar 2014 09:24:45 +0530
From: Jassi Brar <jassisinghbrar@...il.com>
To: Markus Mayer <markus.mayer@...aro.org>
Cc: Linux Kernel Mailing list <linux-kernel@...r.kernel.org>,
Greg KH <gregkh@...uxfoundation.org>,
Suman Anna <s-anna@...com>, Tony Lindgren <tony@...mide.com>,
"Omar Ramirez Luna (omar.ramirez@...itl.com)"
<omar.ramirez@...itl.com>, Loic Pallardy <loic.pallardy@...com>,
LeyFoon Tan <lftan.linux@...il.com>,
Craig McGeachie <slapdau@...oo.com.au>,
Courtney Cavin <courtney.cavin@...ymobile.com>,
"Rafael J. Wysocki" <rafael.j.wysocki@...el.com>,
Rob Herring <robherring2@...il.com>,
Arnd Bergmann <arnd@...db.de>,
Josh Cartwright <joshc@...eaurora.org>,
Linus Walleij <linus.walleij@...aro.org>,
Kumar Gala <galak@...eaurora.org>,
Girish K S <ks.giri@...sung.com>
Subject: Re: [PATCHv4,2/5] mailbox: Introduce framework for mailbox
On Sat, Mar 29, 2014 at 3:38 AM, Markus Mayer <markus.mayer@...aro.org> wrote:
.....
>> +int mbox_send_message(struct mbox_chan *chan, void *mssg)
>> +{
>> + int t;
>> +
>> + if (!chan || !chan->cl)
>> + return -EINVAL;
>> +
>> + t = _add_to_rbuf(chan, mssg);
>> + if (t < 0) {
>> + pr_err("Try increasing MBOX_TX_QUEUE_LEN\n");
>> + return t;
>> + }
>> +
>> + _msg_submit(chan);
>> +
>> + if (chan->txdone_method == TXDONE_BY_POLL)
>> + poll_txdone((unsigned long)chan->con);
>
> Wouldn't it be cleaner to use
> poll_txdone((unsigned long)&chan->con);
> ?
>
Here's how we use it ...
static void poll_txdone(unsigned long data)
{
struct mbox_con *con = (struct mbox_con *)data;
.....
}
To me, unnecessarily passing a pointer to a pointer seems unclean.
>> +int mbox_controller_register(struct mbox_controller *mbox)
>> +{
>> + int i, num_links, txdone;
>> + struct mbox_chan *chan;
>> + struct mbox_con *con;
>> +
>> + /* Sanity check */
>> + if (!mbox || !mbox->ops)
>> + return -EINVAL;
>> +
>> + for (i = 0; mbox->links[i]; i++)
>> + ;
>> + if (!i)
>> + return -EINVAL;
>> + num_links = i;
>> +
>> + mutex_lock(&con_mutex);
>> + /* Check if already populated */
>> + list_for_each_entry(con, &mbox_cons, node)
>> + if (!strcmp(mbox->controller_name, con->name)) {
>> + mutex_unlock(&con_mutex);
>> + return -EINVAL;
>> + }
>> +
>> + con = kzalloc(sizeof(struct mbox_con), GFP_KERNEL);
>> + if (!con)
>> + return -ENOMEM;
>
> The mutex is not freed here.
>
>> +
>> + chan = kzalloc(sizeof(struct mbox_chan) * num_links, GFP_KERNEL);
>> + if (!chan) {
>> + kfree(con);
>> + return -ENOMEM;
>
> Again, the mutex is not freed.
>
> You could move both allocations above the mutex. Then you won't have to
> worry about it.
>
Yes thanks. I overlooked. Will fix it.
Regards,
-Jassi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists