lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1476153632.477.2.camel@mtksdaap41>
Date:   Tue, 11 Oct 2016 10:40:32 +0800
From:   Horng-Shyang Liao <hs.liao@...iatek.com>
To:     Jassi Brar <jaswinder.singh@...aro.org>
CC:     CK Hu <ck.hu@...iatek.com>, Daniel Kurtz <djkurtz@...omium.org>,
        "Monica Wang" <monica.wang@...iatek.com>,
        Jiaguang Zhang <jiaguang.zhang@...iatek.com>,
        Nicolas Boichat <drinkcat@...omium.org>,
        Jassi Brar <jassisinghbrar@...il.com>,
        cawa cheng <cawa.cheng@...iatek.com>,
        Bibby Hsieh <bibby.hsieh@...iatek.com>,
        YT Shen <yt.shen@...iatek.com>,
        Damon Chu <damon.chu@...iatek.com>,
        Devicetree List <devicetree@...r.kernel.org>,
        Sascha Hauer <kernel@...gutronix.de>,
        "Daoyuan Huang" <daoyuan.huang@...iatek.com>,
        Sascha Hauer <s.hauer@...gutronix.de>,
        Glory Hung <glory.hung@...iatek.com>,
        Rob Herring <robh+dt@...nel.org>,
        <linux-mediatek@...ts.infradead.org>,
        Matthias Brugger <matthias.bgg@...il.com>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>,
        <srv_heupstream@...iatek.com>,
        Josh-YC Liu <josh-yc.liu@...iatek.com>,
        lkml <linux-kernel@...r.kernel.org>,
        Dennis-YC Hsieh <dennis-yc.hsieh@...iatek.com>,
        Philipp Zabel <p.zabel@...gutronix.de>, <hs.liao@...iatek.com>
Subject: Re: [PATCH v14 2/4] CMDQ: Mediatek CMDQ driver

On Thu, 2016-10-06 at 18:40 +0530, Jassi Brar wrote:
> On 6 October 2016 at 18:31, Horng-Shyang Liao <hs.liao@...iatek.com> wrote:
> 
> > Back to our original statement, we need to flush all tasks to queue
> > in GCE HW; i.e. we need to use mbox_client_txdone after
> > mbox_send_message, or send tx_done once mailbox controller receive
> > message (task). However, we still need a way to notice done tasks to
> > clients. Currently, we don't have a good way to call callback in mailbox
> > framework. Therefore, CMDQ driver has its owner callback functions.
> >
> mbox_client_txdone() is called by the client driver when only it knows
> the messages has been transmitted (i.e your submitted tasks are done).
> Obviously the client driver should do any callbacks to its users
> upstream.

Hi Jassi,

In current CMDQ driver, mbox_client_txdone() is called to prevent the
blocking of chan->active_req. It is not the real point of CMDQ task
done, so the client driver cannot do any callbacks to its user upstream.

(1) If we don't use mbox_client_txdone(), could you tell us an
    alternative way to prevent the blocking of chan->active_req?
    And then we can use tx_done when CMDQ task is relly done.
(2) If we use mbox_client_txdone() to prevent the blocking of
    chan->active_req, could CMDQ driver just uses self-defined callback
    function to notice client driver CMDQ task done?

Thanks,
HS


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ