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: <20240920141958.GA288724@e130802.arm.com>
Date: Fri, 20 Sep 2024 15:19:58 +0100
From: Abdellatif El Khlifi <abdellatif.elkhlifi@....com>
To: Krzysztof Kozlowski <krzk@...nel.org>
Cc: mathieu.poirier@...aro.org, Adam.Johnston@....com,
	Hugues.KambaMpiana@....com, Drew.Reed@....com, andersson@...nel.org,
	conor+dt@...nel.org, devicetree@...r.kernel.org,
	krzysztof.kozlowski+dt@...aro.org,
	linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
	linux-remoteproc@...r.kernel.org, liviu.dudau@....com,
	lpieralisi@...nel.org, robh@...nel.org, sudeep.holla@....com,
	robin.murphy@....com
Subject: Re: [PATCH v2 1/5] dt-bindings: remoteproc: sse710: Add the External
 Systems remote processors

Hi Krzysztof,

> >>>>> +  '#extsys-id':
> >>>>
> >>>> '#' is not correct for sure, that's not a cell specifier.
> >>>>
> >>>> But anyway, we do not accept in general instance IDs.
> >>>
> >>> I'm happy to replace the instance ID with  another solution.
> >>> In our case the remoteproc instance does not have a base address
> >>> to use. So, we can't put remoteproc@...ress
> >>>
> >>> What do you recommend in this case please ?
> >>
> >> Waiting one month to respond is a great way to drop all context from my
> >> memory. The emails are not even available for me - gone from inbox.
> >>
> >> Bus addressing could note it. Or you have different devices, so
> >> different compatibles. Tricky to say, because you did not describe the
> >> hardware really and it's one month later...
> >>
> > 
> > Sorry for waiting. I was in holidays.
> > 
> > I'll add more documentation about the external system for more clarity [1].
> > 
> > Basically, Linux runs on the Cortex-A35. The External system is a
> > Cortex-M core. The Cortex-A35 can not access the memory of the Cortex-M.
> > It can only control Cortex-M core using the reset control and status registers mapped
> > in the memory space of the Cortex-A35.
> 
> That's pretty standard.
> 
> It does not explain me why bus addressing or different compatible are
> not sufficient here.

Using an instance ID was a design choice.
I'm happy to replace it with the use of compatible and match data (WIP).

The match data will be pointing to a data structure containing the right offsets
to be used with regmap APIs.

syscon node is used to represent the Host Base System Control register area [1]
where the external system reset registers are mapped (EXT_SYS*).

The nodes will look like this:

syscon@...10000 {
        compatible = "arm,sse710-host-base-sysctrl", "simple-mfd", "syscon";
        reg = <0x1a010000 0x1000>;

        #address-cells = <1>;
        #size-cells = <1>;

        remoteproc@310 {
            compatible = "arm,sse710-extsys0";
            reg = <0x310 4>;
            ...
        }

        remoteproc@318 {
            compatible = "arm,sse710-extsys1";
            reg = <0x318 4>;
            ...
}


[1]: https://developer.arm.com/documentation/102342/0000/Programmers-model/Register-descriptions/Host-Base-System-Control-register-summary

Cheers
Abdellatif

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ