linux-kernel - Re: [PATCH 05/16] remoteproc/pru: Add pru-specific debugfs support

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:   Tue, 18 Dec 2018 17:51:12 +0200
From:   Roger Quadros <rogerq@...com>
To:     David Lechner <david@...hnology.com>, <ohad@...ery.com>,
        <bjorn.andersson@...aro.org>, Mark Brown <broonie@...nel.org>
CC:     <tony@...mide.com>, <robh+dt@...nel.org>, <bcousson@...libre.com>,
        <ssantosh@...nel.org>, <s-anna@...com>, <nsekhar@...com>,
        <t-kristo@...com>, <nsaulnier@...com>, <jreeder@...com>,
        <m-karicheri2@...com>, <woods.technical@...il.com>,
        <linux-omap@...r.kernel.org>, <linux-remoteproc@...r.kernel.org>,
        <linux-kernel@...r.kernel.org>, <devicetree@...r.kernel.org>
Subject: Re: [PATCH 05/16] remoteproc/pru: Add pru-specific debugfs support

+Mark

David,

On 29/11/18 12:17, Roger Quadros wrote:
> On 27/11/18 00:37, David Lechner wrote:
>> On 11/26/18 1:52 AM, Roger Quadros wrote:
>>> From: Suman Anna <s-anna@...com>
>>>
>>> The remoteproc core creates certain standard debugfs entries,
>>> that does not give a whole lot of useful information for the
>>> PRUs. The PRU remoteproc driver is enhanced to add additional
>>> debugfs entries for PRU. These will be auto-cleaned up when
>>> the parent rproc debug directory is removed.
>>>
>>> The enhanced debugfs support adds two new entries: 'regs' and
>>> 'single_step'. The 'regs' dumps out the useful CTRL sub-module
>>> registers as well as each of the 32 GPREGs and CT_REGs registers.
>>> The GPREGs and CT_REGs though are printed only when the PRU is
>>> halted and accessible as per the IP design.
>>>
>>
>> If the driver used regmap to access the CTRL I/O memory, then
>> 'regs' wouldn't be needed since regmap already does debugfs.
>>
> 
> ok, we could split out CTRL from this and use regmap.
> 

I was thinking of using regmap for both control and debug
but regmap_mmio only supports one iomap even though it supports
multiple ranges.

What can we do here?

The control and debug regions even though separate are right
next to each other

reg = <0x34000 0x3000>,
	<0x22000 0x400>,
	<0x22400 0x100>;
reg-names = "iram", "control", "debug";

We could combine control and debug into one iomap and use
2 regmap ranges. But this is really working around the
regmap_mmio limitation of not being able to use more than one ioremaps.

Mark, any suggestions?

Is it meaningful to support __devm_regmap_init_mmio_clk()
with separate iomem regions for the ranges?

cheers,
-roger

-- 
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki