From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751954AbeDIJD5 (ORCPT ); Mon, 9 Apr 2018 05:03:57 -0400 Received: from mx08-00178001.pphosted.com ([91.207.212.93]:35378 "EHLO mx07-00178001.pphosted.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751673AbeDIJDw (ORCPT ); Mon, 9 Apr 2018 05:03:52 -0400 From: Fabien DESSENNE To: Jassi Brar CC: Rob Herring , Mark Rutland , Maxime Coquelin , Alexandre TORGUE , Ludovic BARRE , "Devicetree List" , "linux-mediatek@lists.infradead.org" , srv_heupstream , Linux Kernel Mailing List , Benjamin Gaignard , Loic PALLARDY , "Arnaud POULIQUEN" , Bjorn Andersson Subject: Re: [PATCH v2 2/2] mailbox: add STMicroelectronics STM32 IPCC driver Thread-Topic: [PATCH v2 2/2] mailbox: add STMicroelectronics STM32 IPCC driver Thread-Index: AQHTzMHdHpageEh13EG70mtSxYSG6qPziqSAgAAHpwCAACQdAIAAFPoAgAQ8yQA= Date: Mon, 9 Apr 2018 09:03:25 +0000 Message-ID: References: <1520852307-26659-1-git-send-email-fabien.dessenne@st.com> <1520852307-26659-3-git-send-email-fabien.dessenne@st.com> <4a2170b7-e5e9-4f5c-8ff7-79e102a658c1@st.com> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.75.127.47] Content-Type: text/plain; charset="utf-8" Content-ID: MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2018-04-09_03:,, signatures=0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by mail.home.local id w39942Bm017770 On 06/04/18 18:20, Jassi Brar wrote: > On Fri, Apr 6, 2018 at 8:35 PM, Fabien DESSENNE wrote: >> On 06/04/18 14:56, Jassi Brar wrote: >>> On Fri, Apr 6, 2018 at 5:59 PM, Fabien DESSENNE wrote: >>>> Hi >>>> >>>> >>>> On 05/04/18 11:38, Jassi Brar wrote: >>>>> On Mon, Mar 12, 2018 at 4:28 PM, Fabien Dessenne wrote: >>>>> .... >>>>>> + >>>>>> + /* irq */ >>>>>> + for (i = 0; i < IPCC_IRQ_NUM; i++) { >>>>>> + ipcc->irqs[i] = of_irq_get_byname(dev->of_node, irq_name[i]); >>>>>> + if (ipcc->irqs[i] < 0) { >>>>>> + dev_err(dev, "no IRQ specified %s\n", irq_name[i]); >>>>>> + ret = ipcc->irqs[i]; >>>>>> + goto err_clk; >>>>>> + } >>>>>> + >>>>>> + ret = devm_request_threaded_irq(dev, ipcc->irqs[i], NULL, >>>>>> + irq_thread[i], IRQF_ONESHOT, >>>>>> + dev_name(dev), ipcc); >>>>>> >>>>> In your interrupt handlers you don't do anything that could block. >>>>> Threads only adds some delay to your message handling. >>>>> So maybe use devm_request_irq() ? >>>> The interrupt handlers call mbox_chan_received_data() / >>>> mbox_chan_txdone(), which call in turn client's rx_callback() / >>>> tx_done() / tx_prepare() which behavior may be unsafe. Hence, using a >>>> threaded irq here seems to be a good choice. >>>> >>> rx_callback() is supposed to be atomic. >> I am worried with this atomic part (and honestly I did not note that the >> callbacks were expected to be) >> >> In my case, remoteproc->virtio->rpmsg is the mailbox client defining the >> rx_callback. >> If I follow your suggestion, I shall make this rx_callback Atomic in >> remoteproc (or in virtio or rpmsg). And this does not seem to be so >> simple (add a worker in the middle of somewhere?). Bjorn, feel free to >> comment this part. >> >> An alternate implementation consists in using a threaded IRQ for the >> mailbox interrupt. >> This option is not only simple, but also ensures to split bottom & half >> parts at the irq level which is IMHO a general good practice. >> >> I can see that some mailbox clients implement callbacks that are NOT >> atomic and I suspect this is the reason why some mailbox drivers use >> threaded_irq (rockchip mailbox splits the bottom & half parts). >> >> Would it be acceptable to consider the "atomic client callback" as a >> non-strict rule ? >> > Of course you can traverse atomic path from sleepable context (but not > vice-versa). So, to be sure we understand each other, I can use threaded_irq, right? > Please send in the final revision. > > Thanks.