From mboxrd@z Thu Jan 1 00:00:00 1970 From: Sudeep Holla Subject: Re: [PATCH 2/9] mailbox: arm_mhu: add driver for ARM MHU controller Date: Thu, 27 Nov 2014 13:25:04 +0000 Message-ID: <54772630.1090107@arm.com> References: <1416486442-25200-1-git-send-email-Vincent.Yang@tw.fujitsu.com> <1416486872-25301-1-git-send-email-Vincent.Yang@tw.fujitsu.com> <54749429.9080505@arm.com> <5474C3DD.5060706@arm.com> <5475DD19.9000107@arm.com> <547601EF.7070307@arm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT Return-path: In-Reply-To: Sender: devicetree-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Jassi Brar Cc: Sudeep Holla , Vincent Yang , "devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , "linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org" , "arnd-r2nGTMty4D4@public.gmane.org" , "olof-nZhT3qVonbNeoWH0uzbU5w@public.gmane.org" , "linux-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org" , "robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org" , Pawel Moll , Mark Rutland , "ijc+devicetree-KcIKpvwj1kUDXYZnReoRVg@public.gmane.org" , "galak-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org" , "andy.green-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org" , "patches-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org" , Vincent Yang , Tetsuya Nuriya List-Id: devicetree@vger.kernel.org On 27/11/14 05:11, Jassi Brar wrote: > On 26 November 2014 at 22:08, Sudeep Holla wrote: >> >> >> On 26/11/14 16:20, Jassi Brar wrote: >>> >>> On 26 November 2014 at 19:30, Sudeep Holla 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@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 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html