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, 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.

Powered by blists - more mailing lists