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  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:   Wed, 06 May 2020 13:05:21 +0530
From:   Sai Prakash Ranjan <>
To:     Mike Leach <>,
        Suzuki K Poulose <>
Cc:     Mathieu Poirier <>,
        Stephen Boyd <>,
        Linux Kernel Mailing List <>,,
        linux-arm-kernel <>,
        Russell King <>
Subject: Re: [PATCH] coresight: dynamic-replicator: Fix handling of multiple

Hi Suzuki, Mike,

On 2020-04-29 22:41, Sai Prakash Ranjan wrote:
> Hi Mike,
> On 2020-04-29 22:28, Mike Leach wrote:
>> Hi,
> [...]
>>> >> > You need to find what is resetting the IDFILTERs to 0 for replicator1.
>>> >> >
>>> >>
>>> >> That is right.
>>> >>
>>> >
>>> > By default all replicators have the IDFILTER registers set to 0 out of
>>> > hardware reset. This ensures that programmable replicators behave in
>>> > the same way as non-programmable replicators out of reset.
>>> >
>>> > The  dynamic_replicator_reset() is of course a driver state reset -
>>> > which filters out all trace on the output ports. The trace is then
>>> > enabled when we set the trace path from source to sink.
>>> >
>>> Thanks for these explanations.
>>> > It seems to me that you have 2 problems that need solving here:
>>> >
>>> > 1) Why does the reset_replicator() called from probe() _not_ work
>>> > correctly on replicator 1? It seems to work later if you introduce a
>>> > reset after more of the system has powered and booted. This is
>>> > startiing to look a little like a PM / clocking issue.
>>> reset_replicator() does work in probe correctly for both replicators,
>>> below logs is collected before and after reset in probe. It is later
>>> that it's set back to 0x0 and hence the suggestion to look at 
>>> firmware
>>> using this replicator1.
>> OK - sorry I read your statement saying that replicator1 was 0 after
>> the reset in probe(), rather than look at the logs.
>> From the logs it is working at the time probe() occurs, but by the
>> time we come to enable the replicator later, something has reset these
>> registers / hardware outside the control of the replicator driver.
> Yes, I will try to get some more information from the firmware side if
> there is anything messing up.

This turned out to be a clock/pm issue. To confirm, I just marked clk as 
so that it won't be gated and I saw the replicator1(swao_replicator) 
intact after probe. Also alternatively, I tried to comment out disabling 
to check if there is something wrong in amba pm and this keeps the 
intact as well.

@@ -288,7 +295,7 @@ static int amba_probe(struct device *dev)

-               amba_put_disable_pclk(pcdev);
+               //amba_put_disable_pclk(pcdev);
                 dev_pm_domain_detach(dev, true);
         } while (0);


QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a 
of Code Aurora Forum, hosted by The Linux Foundation

Powered by blists - more mailing lists