lkml.org 
[lkml]   [2019]   [Mar]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRE: [PATCH RESEND V2 1/4] dt-bindings: fsl: scu: add watchdog binding
Date
Hi, Rob

Best Regards!
Anson Huang

> -----Original Message-----
> From: Rob Herring [mailto:robh@kernel.org]
> Sent: 2019年3月12日 5:26
> To: Aisheng Dong <aisheng.dong@nxp.com>
> Cc: Anson Huang <anson.huang@nxp.com>; Guenter Roeck <linux@roeck-
> us.net>; mark.rutland@arm.com; ulf.hansson@linaro.org; heiko@sntech.de;
> catalin.marinas@arm.com; will.deacon@arm.com;
> bjorn.andersson@linaro.org; festevam@gmail.com;
> jagan@amarulasolutions.com; Andy Gross <andy.gross@linaro.org>; dl-
> linux-imx <linux-imx@nxp.com>; devicetree@vger.kernel.org; linux-
> watchdog@vger.kernel.org; arnd@arndb.de; marc.w.gonzalez@free.fr;
> s.hauer@pengutronix.de; enric.balletbo@collabora.com;
> horms+renesas@verge.net.au; wim@linux-watchdog.org; Daniel Baluta
> <daniel.baluta@nxp.com>; linux-arm-kernel@lists.infradead.org; linux-
> kernel@vger.kernel.org; kernel@pengutronix.de; olof@lixom.net;
> shawnguo@kernel.org; Jens Wiklander <jens.wiklander@linaro.org>
> Subject: Re: [PATCH RESEND V2 1/4] dt-bindings: fsl: scu: add watchdog
> binding
>
> +Jens W
>
> On Thu, Mar 7, 2019 at 6:22 AM Aisheng Dong <aisheng.dong@nxp.com>
> wrote:
> >
> > Hi Rob,
> >
> > > > > I think Rob suggested that the SCU parent driver should
> > > > > instantiate the watchdog without explicit watchdog node. That
> > > > > would be possible, but it currently uses
> > > > > devm_of_platform_populate() to do the instantiation, and
> > > > > changing that would be a mess. Besides, it does sem to me that
> > > > > your suggested node would describe the hardware, so I am not
> > > > > sure I understand the
> > > reasoning.
> > >
> > > It would just be a call to create a platform device instead. How is that a
> mess?
> > >
> > > It's describing firmware. We have DT for describing h/w we've failed
> > > to make discoverable. We should not repeat that and just describe
> firmware in DT.
> > > Make the firmware discoverable! Though there are cases like firmware
> > > provided clocks where we still need something in DT, but this is not
> > > one of them.
> > >
> >
> > The watchdog node here in question actually is not using SCU firmware call.
> > Due to security requirement by SCU, watchdog can only be accessed in
> > security mode, for IMX case, via ARM Trust Firmware. That means the
> > watchdog used in Linux actually is using ARM SMC call and does not
> > depend SCU driver. So It would be strange for SCU driver to instantiate it.
> >
> > For this situation, do you think we can move watchdog out of scu node?
> > Maybe rename the compatible string like "fsl,imx8qxp-sip-watchdog"
> > because it's actually a watchdog serviced by ATF firmware.
>
> Yes, but that creates more questions. What exactly does ATF talk to for the
> watchdog? The SCU firmware?

Yes, ATF talks to SCU firmware directly, Linux kernel watchdog driver call SMC instructions
to send command to ATF, and ATF will call SCU firmware API to finish the operation requested
by Linux kernel watchdog driver.

>
> Maybe ATF should define and provide a standard watchdog interface? It is
> still a question of making the firmware discoverable rather than trying to
> describe the firmware in DT.

The SMC call by Linux kernel watchdog already follow the SIP(silicon provider) standard, each
SoC can define its own protocol for SIP. ATF does NOT have a standard common watchdog interface
now, since it is more like a platform specific feature, most of platforms can control watchdog directly
from Linux kernel I think.

So, do you have suggestion for this case? Either find a place in DT to put watchdog node, or make it
a build-in device inside SCU driver? Or you have other better ideas?

Thanks,
Anson.

>
> Rob
\
 
 \ /
  Last update: 2019-03-14 03:11    [W:0.077 / U:0.272 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site