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  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]
Date:   Thu, 2 Nov 2017 11:49:17 +0000
From:   Sudeep Holla <>
To:     Jassi Brar <>
Cc:     Sudeep Holla <>,
        Linux Kernel Mailing List <>,
        Arnd Bergmann <>,
        Bjorn Andersson <>
Subject: Re: [PATCH] mailbox: add support for doorbell/signal mode controllers

On 02/11/17 11:26, Jassi Brar wrote:
> On Thu, Nov 2, 2017 at 4:17 PM, Sudeep Holla <> wrote:


>> No that non-zero value is not client specific, it's entirely controller
>> specific.
> ??
> For example BCM2835 has such a controller. Have a look at
> bcm2835_send_data() and let me know what is that controller specific
> value.

You can keep finding one or the other platform that has a deviation.
Come on there are generic infrastructure support in many subsystem that
are just used in one or two platforms. I hope you agree for this
enhancement to the mailbox framework as it's more commonly used mode.
I am not saying this patch is final, but I just want an agreement to add
such a support.


>>> 1) Where does the  "whatever_value_to_trigger_signal"  come from?
>> Controller specific.
>>> That has to come from client.
>> No.
> Again, let me know what does the controller expect 'val' to be
>   writel(val, MAILBOX_A2B_CMD(chans->idx))

It depends on the controller. Whatever value that can generate a signal
to remote.

> Your entire post is based on your assertion that the controller
> expects a particular non-zero value to trigger a signal, which is
> wrong.

Why do you think that ? There are lots of example in the mailbox today.
Please have a look at few example which don't use data passed from the

1. pcc_send_data (drivers/mailbox/pcc.c)
2. sti_mbox_send_data (drivers/mailbox/mailbox-sti.c)
3. qcom_apcs_ipc_send_data (drivers/mailbox/qcom-apcs-ipc-mailbox.c)
4. tegra_hsp_doorbell_send_data (drivers/mailbox/tegra-hsp.c)

And SCMI fits the above case.

Also you keep saying I am making this change to get SCMI with ARM MHU.
Honestly I don't care much about that, I need better support from
mailbox framework if possible for any platforms running SCMI. So please
stop assuming my changes are motivated by that. SCMI is designed to
solve more generic consolidation issues, so I am more focused on that
than getting it run on some development platform I have with ARM MHU.
Believe me that's least of my concern.


Powered by blists - more mailing lists