Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754014AbbGWRXc (ORCPT ); Thu, 23 Jul 2015 13:23:32 -0400 Received: from mail-wi0-f177.google.com ([209.85.212.177]:36626 "EHLO mail-wi0-f177.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752915AbbGWRX1 (ORCPT ); Thu, 23 Jul 2015 13:23:27 -0400 MIME-Version: 1.0 In-Reply-To: <1437134647-28298-4-git-send-email-lee.jones@linaro.org> References: <1437134647-28298-1-git-send-email-lee.jones@linaro.org> <1437134647-28298-4-git-send-email-lee.jones@linaro.org> Date: Thu, 23 Jul 2015 20:23:26 +0300 Message-ID: Subject: Re: [PATCH 3/6] mailbox: Add support for ST's Mailbox IP From: Alexey Klimov To: Lee Jones Cc: linux-arm-kernel@lists.infradead.org, Linux Kernel Mailing List , devicetree@vger.kernel.org, jassisinghbrar@gmail.com, kernel@stlinux.com Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3443 Lines: 95 Hi Lee, On Fri, Jul 17, 2015 at 3:04 PM, Lee Jones wrote: > ST's platforms currently support a maximum of 5 Mailboxes, one for > each of the supported co-processors situated on the platform. Each > Mailbox is divided up into 4 instances which consist of 32 channels. > Messages are passed between the application and co-processors using > shared memory areas. It is the Client's responsibility to manage > these areas. > > Signed-off-by: Lee Jones > --- > drivers/mailbox/Kconfig | 7 + > drivers/mailbox/Makefile | 2 + > drivers/mailbox/mailbox-sti.c | 562 ++++++++++++++++++++++++++++++++++++++++++ > 3 files changed, 571 insertions(+) > create mode 100644 drivers/mailbox/mailbox-sti.c [..] > +static irqreturn_t sti_mbox_thread_handler(int irq, void *data) > +{ > + struct sti_mbox_device *mdev = data; > + struct sti_mbox_pdata *pdata = dev_get_platdata(mdev->dev); > + struct mbox_chan *chan; > + unsigned int instance; > + > + for (instance = 0; instance < pdata->num_inst; instance++) { > +keep_looking: > + chan = sti_mbox_irq_to_channel(mdev, instance); > + if (!chan) > + continue; > + > + mbox_chan_received_data(chan, NULL); > + sti_mbox_clear_irq(chan); > + sti_mbox_enable_channel(chan); > + goto keep_looking; > + } > + > + return IRQ_HANDLED; > +} > + > +static irqreturn_t sti_mbox_irq_handler(int irq, void *data) > +{ > + struct sti_mbox_device *mdev = data; > + struct sti_mbox_pdata *pdata = dev_get_platdata(mdev->dev); > + struct sti_channel *chan_info; > + struct mbox_chan *chan; > + unsigned int instance; > + int ret = IRQ_NONE; > + > + for (instance = 0; instance < pdata->num_inst; instance++) { > + chan = sti_mbox_irq_to_channel(mdev, instance); > + if (!chan) > + continue; > + chan_info = chan->con_priv; > + > + if (!sti_mbox_channel_is_enabled(chan)) { > + dev_warn(mdev->dev, > + "Unexpected IRQ: %s\n" > + " instance: %d: channel: %d [enabled: %x]\n", > + mdev->name, chan_info->instance, > + chan_info->channel, mdev->enabled[instance]); > + ret = IRQ_HANDLED; > + continue; > + } > + > + sti_mbox_disable_channel(chan); > + ret = IRQ_WAKE_THREAD; > + } > + > + if (ret == IRQ_NONE) > + dev_err(mdev->dev, "Spurious IRQ - was a channel requested?\n"); > + > + return ret; > +} With such usage of ret variable can it happen that handling of last but one channel/instance will set ret to IRQ_WAKE_THREAD and at the same time handling of last channel/instance will set ret to IRQ_HANDLED during iteration loop and finally generic subsystem will not wake up thread handler because it will receive IRQ_HANDLED? Just checking. [..] -- Thanks, Alexey Klimov -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/