linux-kernel - Re: [PATCH] remoteproc: pru: future-proof PRU ID matching

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: <5fed434e-1569-ab9f-b1a4-475aa820ef47@lechnology.com>
Date:   Thu, 28 Jan 2021 17:21:21 -0600
From:   David Lechner <david@...hnology.com>
To:     Suman Anna <s-anna@...com>, linux-remoteproc@...r.kernel.org
Cc:     Ohad Ben-Cohen <ohad@...ery.com>,
        Bjorn Andersson <bjorn.andersson@...aro.org>,
        Grzegorz Jaszczyk <grzegorz.jaszczyk@...aro.org>,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH] remoteproc: pru: future-proof PRU ID matching

On 1/28/21 4:55 PM, Suman Anna wrote:
> Hi David,
> 
> On 1/15/21 6:53 PM, Suman Anna wrote:
>> On 1/4/21 3:18 PM, David Lechner wrote:
>>>   static int pru_rproc_probe(struct platform_device *pdev)
>>> @@ -825,20 +808,28 @@ static int pru_rproc_remove(struct platform_device *pdev)
>>>   
>>>   static const struct pru_private_data pru_data = {
>>>   	.type = PRU_TYPE_PRU,
>>> +	.pru0_iram_offset = 0x4000,
>>> +	.pru1_iram_offset = 0x8000,
> 
> The offsets for the PRU cores are actually 0x34000 and 0x38000 respectively from
> the base of the PRUSS on non-Davinci SoCs.
> 
> If we were to use this static data approach, then we might as well continue to
> use the current address masking logic with the appropriate masks for Davinci
> (0x38000 and 0x3C000, not true offsets but as masks they would work). Davinci
> PRUSS is the only one with its differences being the first PRUSS IP, and I would
> prefer to keep the logic aligned to the IPs on all the recent SoCs on 3
> different TI SoC families (OMAP, Keystone 2 and K3).
> 
> Let me know what you think.

I'm not too picky as long as it works. :-)

If keeping the static data to a minimum is really important, I suppose we could
introduce a new type = PRU_TYPE_PRU_V1 for these PRUSSs instead. It sounds like
this information might be useful elsewhere anyway.