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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Thu, 28 Jan 2021 17:37:21 -0600
From:   Suman Anna <s-anna@...com>
To:     David Lechner <david@...hnology.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 5:21 PM, David Lechner wrote:
> 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.

Yeah, let me look into this further and see if there is any other way possible
as well. I had some patches for DA850 lying around on some older kernels, and I
know that I definitely needed to introduce a variable to distinguish the
programmability of certain CONST registers (C26 and C27 are fixed on Davinci
IIRC). Will need that variable with the current PRU consumer series. Perhaps,
the same PRU type variable can be used for that as well.

regards
Suman