linux-kernel - Re: [PATCH 3/3] dt-bindings: remoteproc: Add Arm remoteproc

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]

Date: Thu, 14 Mar 2024 14:56:53 +0100
From: Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
To: Abdellatif El Khlifi <abdellatif.elkhlifi@....com>,
 Robin Murphy <robin.murphy@....com>
Cc: Bjorn Andersson <andersson@...nel.org>,
 Mathieu Poirier <mathieu.poirier@...aro.org>,
 Rob Herring <robh+dt@...nel.org>, Liviu Dudau <liviu.dudau@....com>,
 Sudeep Holla <sudeep.holla@....com>,
 Lorenzo Pieralisi <lpieralisi@...nel.org>,
 Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
 Conor Dooley <conor+dt@...nel.org>, Drew.Reed@....com,
 Adam.Johnston@....com, linux-arm-kernel@...ts.infradead.org,
 devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
 linux-remoteproc@...r.kernel.org
Subject: Re: [PATCH 3/3] dt-bindings: remoteproc: Add Arm remoteproc

On 14/03/2024 14:49, Abdellatif El Khlifi wrote:
>> Frankly at the moment I'd be inclined to say it isn't even a remoteproc
>> binding (or driver) at all, it's a reset controller. Bindings are a contract
>> for describing the hardware, not the current state of Linux driver support -
>> if this thing still needs mailboxes, shared memory, a reset vector register,
>> or whatever else to actually be useful, those should be in the binding from
>> day 1 so that a) people can write and deploy correct DTs now, such that
>> functionality becomes available on their systems as soon as driver support
>> catches up, and b) the community has any hope of being able to review
>> whether the binding is appropriately designed and specified for the purpose
>> it intends to serve.
> 
> This is an initial patchset for allowing to turn on and off the remote processor.
> The FW is already loaded before the Corstone-1000 SoC is powered on and this
> is done through the FPGA board bootloader in case of the FPGA target.
> Or by the Corstone-1000 FVP model (emulator).
> 
> The plan for the driver is as follows:
> 
>     Step 1: provide a foundation driver capable of turning the core on/off
>     Step 2: provide mailbox support for comms
>     Step 3: provide FW reload capability
> 
> Steps 2 & 3 are waiting for a HW update so the Cortex-A35 (running Linux) can
> share memory with the remote core.
> 
> So, when memory sharing becomes available in the FPGA and FVP the
> DT binding will be upgraded with:
> 
>     - mboxes property specifying the RX/TX mailboxes (based on MHU v2)
>     - memory-region property describing the virtio vrings
> 
> Currently the mailbox controller does exist in the HW but is not
> usable via virtio (no memory sharing available).
> 
> Do you recommend I add the mboxes property even currently we can't do the comms ?

Bindings should be complete, regardless whether Linux driver supports it
or not. Please see writing bindings document for explanation on this and
other rules.

So yes: please describe as much as possible/reasonable.


Best regards,
Krzysztof