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] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160812224223.GJ26240@tuxbot>
Date:	Fri, 12 Aug 2016 15:42:23 -0700
From:	Bjorn Andersson <bjorn.andersson@...aro.org>
To:	Rob Herring <robh@...nel.org>
Cc:	Mark Rutland <mark.rutland@....com>,
	Ohad Ben-Cohen <ohad@...ery.com>, devicetree@...r.kernel.org,
	linux-kernel@...r.kernel.org, linux-remoteproc@...r.kernel.org
Subject: Re: [PATCH] dt-binding: remoteproc: Document generic properties

On Fri 12 Aug 11:34 PDT 2016, Rob Herring wrote:

> On Wed, Aug 10, 2016 at 10:37:02AM -0700, Bjorn Andersson wrote:
> > This documents the generic properties "rprocs" and "rproc-names", used
> > for consumer drivers to reference a remoteproc node.
> 
> How do you intend to use this? I wonder if it would not be better to 
> expose a remote proc with existing bindings for a particular purpose 
> (e.g. clocks, resets, etc.) rather than a generic connection. The client 
> side would have to have specific knowledge as to what functions the 
> remote proc provides.
> 

The remoteproc node represents the mechanism and resources needed to
control the life cycle a co-processor, e.g. loading, booting, shutting
gown a video encoder/decoder.

The proposed reference allows a separate thingie to assert control of
the life cycle of that co-processor.


I acknowledge that in some cases there is a fine line between what is
the life cycle management and what is the actual functionality
implemented by that remote processor. But as the remoteproc mechanism is
reusable between various use cases I think it makes sense to not describe
them as one unit.

Regards,
Bjorn

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ