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] [day] [month] [year] [list]
Message-ID: <FDE42FCD-8E61-4EE5-8893-6A9E7E7D64AC@arm.com>
Date:   Mon, 14 May 2018 08:07:39 +0000
From:   Samarth Parikh <Samarth.Parikh@....com>
To:     Jassi Brar <jassisinghbrar@...il.com>
CC:     Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Sudipto Paul <Sudipto.Paul@....com>,
        Arvind Chauhan <Arvind.Chauhan@....com>,
        "samarthp@...il.com" <samarthp@...il.com>,
        Deepak Pandey <Deepak.Pandey@....com>,
        Sudeep Holla <Sudeep.Holla@....com>
Subject: Re: [PATCH] mailbox: arm_mhu: add support for mhuv2

Hi Jassi,

As suggested by you, I have moved the MHUv2 related changes to a new file arm_mhu_v2.c. I have sent an updated patch, can you please review it?

Regards,
Samarth

On 02/05/18, 5:34 PM, "Jassi Brar" <jassisinghbrar@...il.com> wrote:

    On Wed, May 2, 2018 at 12:44 PM, Samarth Parikh <samarth.parikh@....com> wrote:
    > Hi Jassi,
    >
    > I am resending the patch for review, in case you have missed my previous
    > patch. Can you please go through it and let me know your thoughts on
    > the same?
    >
    You don't want this to go into git log :)
    If your patch isn't looked into for more than 2weeks (or longer if
    merge window is not near), please just ping as a reply to original
    submission.
    Anyways....

    > ARM has launched a next version of MHU i.e. MHUv2 with its latest
    > subsystems. The main change is that the MHUv2 is now a distributed IP
    > with different peripheral views (registers) for the sender and receiver.
    >
    > Another main difference is that MHUv1 duplex channels are now split into
    > simplex/half duplex in MHUv2. MHUv2 has a configurable number of
    > communication channels. There is a capability register (MSG_NO_CAP) to
    > find out how many channels are available in a system.
    >
    > The register offsets have also changed for STAT, SET & CLEAR registers
    > from 0x0, 0x8 & 0x10 in MHUv1 to 0x0, 0xC & 0x8 in MHUv2 respectively.
    >
    > 0x0    0x4  0x8  0xC             0x1F
    > ------------------------....-----
    > | STAT |    |    | SET |    |   |
    > ------------------------....-----
    >       Transmit Channel
    >
    > 0x0    0x4  0x8   0xC            0x1F
    > ------------------------....-----
    > | STAT |    | CLR |    |    |   |
    > ------------------------....-----
    >         Receive Channel
    >
    > The MHU controller can request the receiver to wake-up and once the
    > request is removed, the receiver may go back to sleep, but the MHU
    > itself does not actively puts a receiver to sleep.
    >
    > So, in order to wake-up the receiver when the sender wants to send data,
    > the sender has to set ACCESS_REQUEST register first in order to wake-up
    > receiver, state of which can be detected using ACCESS_READY register.
    > ACCESS_REQUEST has an offset of 0xF88 & ACCESS_READY has an offset
    > of 0xF8C and are accessible only on any sender channel.
    >
    > This patch adds necessary changes required to support the older
    > version of MHU & the latest MHUv2 controller. This patch also need an
    > update in DT binding for ARM MHU as we need a second register base
    > (tx base) which would be used as the send channel base.
    >
    > Signed-off-by: Samarth Parikh <samarth.parikh@....com>
    > ---
    >  drivers/mailbox/arm_mhu.c | 163 ++++++++++++++++++++++++++++++++++++++++++----
    >  1 file changed, 151 insertions(+), 12 deletions(-)
    >
    The original driver is 195 loc, this patch makes it almost double the size.
    Also there have been controllers (resembling closer to MHU than this
    one) with separate drivers. So I think we should simply create another
    arm_mhu_v2.c ?

    Cheers!


IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ