From: sudeep.holla@arm•com (Sudeep Holla)
To: linux-arm-kernel@lists•infradead.org
Subject: [PATCH 2/9] mailbox: arm_mhu: add driver for ARM MHU controller
Date: Thu, 27 Nov 2014 13:25:04 +0000 [thread overview]
Message-ID: <54772630.1090107@arm.com> (raw)
In-Reply-To: <CAJe_Zhdmup3DB5R3gufiveYtOOU+zrMQJVanQxbjSQ996=ZLXQ@mail.gmail.com>
On 27/11/14 05:11, Jassi Brar wrote:
> On 26 November 2014 at 22:08, Sudeep Holla <sudeep.holla@arm•com> wrote:
>>
>>
>> On 26/11/14 16:20, Jassi Brar wrote:
>>>
>>> On 26 November 2014 at 19:30, Sudeep Holla <sudeep.holla@arm•com> wrote:
>>>>
>>>> On 26/11/14 05:37, Jassi Brar wrote:
>>>>>
>>>>>
>>>
>>>>>>> It seems you still don't get my point that the driver should
>>>>>>> manage
>>>>>>> all channels - S & NS. If Linux is running in NS mode on a platform,
>>>>>>> the DT will specify only some NS channel to be used. The controller
>>>>>>> driver shouldn't be crippled just because you think Linux will never
>>>>>>> be run in Secure mode.
>>>>>>>
>>>>>>
>>>>>> Ok how do you handle that, I don't see that in the DT binding. As it
>>>>>> stands, you can unconditionally try to access the secure channel and
>>>>>> cause aborts if the platform is running in non-secure mode.
>>>>>>
>>>>> No. Please look at the dtsi again ....
>>>>>
>>>>> mhu: mailbox at 2b1f0000 {
>>>>> #mbox-cells = <1>;
>>>>> compatible = "arm,mbox-mhu";
>>>>> reg = <0 0x2b1f0000 0x1000>;
>>>>> interrupts = <0 36 4>, /* LP Non-Sec */
>>>>> <0 35 4>, /* HP Non-Sec */
>>>>> <0 37 4>; /* Secure */
>>>>
>>>>
>>>>
>>>> One possible issue I can think of(though current driver design requests
>>>> irq only on channel startup, it could be moved to probe for optimization
>>>> in which case you need a way to make sure secure channel or irq is not
>>>> accessed)
>>>>
>>> As you see it is fine as such.
>>
>>
>> Agreed, but assuming some driver logic. I would like to see some way of
>> identifying that from DT if we adding the support for secure channel in
>> the driver else I prefer not to add it unless there is a real user of
>> it(which is not the case with your current patch set). That will be
>> handy if there's any issue in future due to some firmware that can't be
>> changed or upgraded.
>>
> Could you please suggest some way of identifying that from DT if we
> adding the support for secure channel in the driver?
>
Sorry, I don't have any idea yet on that as the general rule is not to
touch anything secure in kernel assuming Linux always runs in non-secure
mode.
Now if you need an exception, you need to propose the binding and take
up the discussion on the devicetree list.
Regards,
Sudeep
next prev parent reply other threads:[~2014-11-27 13:25 UTC|newest]
Thread overview: 58+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-20 12:27 [PATCH 0/9] Support for Fujitsu MB86S7X SoCs Vincent Yang
2014-11-20 12:30 ` [PATCH 1/9] ARM: Add platform support " Vincent Yang
2014-11-20 12:34 ` [PATCH 2/9] mailbox: arm_mhu: add driver for ARM MHU controller Vincent Yang
2014-11-25 14:37 ` Sudeep Holla
2014-11-25 16:51 ` Jassi Brar
2014-11-25 18:01 ` Sudeep Holla
2014-11-26 5:37 ` Jassi Brar
2014-11-26 14:00 ` Sudeep Holla
2014-11-26 16:20 ` Jassi Brar
2014-11-26 16:38 ` Sudeep Holla
2014-11-27 5:11 ` Jassi Brar
2014-11-27 13:25 ` Sudeep Holla [this message]
2014-11-20 12:35 ` [PATCH 3/9] ARM: MB86S7X: Add MCPM support Vincent Yang
2014-11-21 13:02 ` Arnd Bergmann
2014-11-21 13:24 ` Jassi Brar
2014-11-25 11:48 ` Sudeep Holla
2014-11-25 13:42 ` Andy Green
2014-11-25 14:24 ` Sudeep Holla
2014-11-25 16:43 ` Andy Green
2014-11-25 17:00 ` Nicolas Pitre
2014-11-25 17:39 ` Sudeep Holla
2014-11-25 20:31 ` Andy Green
2014-11-25 17:42 ` Nicolas Pitre
2014-11-25 18:06 ` Sudeep Holla
2014-11-25 18:55 ` Nicolas Pitre
2014-11-25 18:46 ` Lorenzo Pieralisi
2014-11-25 18:59 ` Nicolas Pitre
2014-11-25 19:21 ` Sudeep Holla
2014-11-26 16:29 ` Jassi Brar
2014-11-26 17:18 ` Sudeep Holla
2014-11-27 4:59 ` Jassi Brar
2014-11-20 12:36 ` [PATCH 4/9] clk: Add clock driver for mb86s7x Vincent Yang
2014-11-21 13:03 ` Arnd Bergmann
2014-11-21 13:22 ` Jassi Brar
2014-11-21 14:34 ` Arnd Bergmann
2014-11-21 16:36 ` Jassi Brar
2014-11-21 17:15 ` Arnd Bergmann
2014-11-21 17:58 ` Jassi Brar
2014-11-21 20:12 ` Arnd Bergmann
2014-11-20 12:37 ` [PATCH 5/9] gpio: Add Fujitsu MB86S7x GPIO driver Vincent Yang
2014-11-27 7:33 ` Alexandre Courbot
2014-12-11 16:00 ` Jassi Brar
2014-12-03 13:32 ` Linus Walleij
2014-12-11 16:01 ` Jassi Brar
2014-11-20 12:38 ` [PATCH 6/9] mmc: sdhci: host: add new f_sdh30 Vincent Yang
2014-11-20 15:22 ` Rob Herring
2014-11-20 16:59 ` Vincent Yang
2014-11-20 18:18 ` Rob Herring
2014-11-21 1:18 ` Vincent Yang
2014-11-20 12:38 ` [PATCH 7/9] dt: mb86s7x: add dt files for MB86S7x evbs Vincent Yang
2014-11-21 14:26 ` Arnd Bergmann
2014-11-21 16:49 ` Jassi Brar
2014-11-21 17:09 ` Arnd Bergmann
2014-11-21 17:35 ` Jassi Brar
2014-11-21 20:14 ` Arnd Bergmann
2014-11-20 12:39 ` [PATCH 8/9] of: add Fujitsu vendor prefix Vincent Yang
2014-11-20 15:07 ` Rob Herring
2014-11-20 12:40 ` [PATCH 9/9] ARM: MB86S7x: Add configs Vincent Yang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=54772630.1090107@arm.com \
--to=sudeep.holla@arm$(echo .)com \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox