| 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
| ||
|
Message-ID: <20180416160818.GC1209@codeaurora.org>
Date: Mon, 16 Apr 2018 10:08:18 -0600
From: Lina Iyer <ilina@...eaurora.org>
To: Stephen Boyd <swboyd@...omium.org>
Cc: andy.gross@...aro.org, david.brown@...aro.org,
linux-arm-msm@...r.kernel.org, linux-soc@...r.kernel.org,
rnayak@...eaurora.org, bjorn.andersson@...aro.org,
linux-kernel@...r.kernel.org, evgreen@...omium.org,
dianders@...omium.org, devicetree@...r.kernel.org
Subject: Re: [PATCH v5 02/10] dt-bindings: introduce RPMH RSC bindings for
Qualcomm SoCs
On Fri, Apr 13 2018 at 16:40 -0600, Stephen Boyd wrote:
>Quoting Lina Iyer (2018-04-11 14:24:31)
>> On Wed, Apr 11 2018 at 09:29 -0600, Stephen Boyd wrote:
>> >Quoting Lina Iyer (2018-04-09 09:08:00)
>> >> On Fri, Apr 06 2018 at 19:14 -0600, Stephen Boyd wrote:
>> >> >Quoting Lina Iyer (2018-04-05 09:18:26)
>> >> >> diff --git a/Documentation/devicetree/bindings/soc/qcom/rpmh-rsc.txt b/Documentation/devicetree/bindings/soc/qcom/rpmh-rsc.txt
>> >> >> new file mode 100644
>> >> >> index 000000000000..dcf71a5b302f
>> >> >> --- /dev/null
>> >> >> +++ b/Documentation/devicetree/bindings/soc/qcom/rpmh-rsc.txt
>> >> >> @@ -0,0 +1,127 @@
>> >> >> +
>> >> >> +Example 1:
>> >> >> +
>> >> >> +For a TCS whose RSC base address is is 0x179C0000 and is at a DRV id of 2, the
>> >> >> +register offsets for DRV2 start at 0D00, the register calculations are like
>> >> >> +this -
>> >> >> +First tuple: 0x179C0000 + 0x10000 * 2 = 0x179E0000
>> >> >> +Second tuple: 0x179E0000 + 0xD00 = 0x179E0D00
>> >> >> +
>> >> >> + apps_rsc: rsc@...e000 {
>> >> >> + label = "apps_rsc";
>> >> >> + compatible = "qcom,rpmh-rsc";
>> >> >> + reg = <0x179e0000 0x10000>, <0x179e0d00 0x3000>;
>> >> >
>> >> >The first reg property overlaps the second one. Does this second one
>> >> >ever move around? I would hardcode it in the driver to be 0xd00 away
>> >> >from the drv base instead of specifying it in DT if it's the same all
>> >> >the time.
>> >> >
>> >> >Also, the example shows 0x179c0000 which I guess is the actual beginning
>> >> >of the RSC block. So the binding seems to be for one DRV inside of an
>> >> >RSC. Can we get the full description of the RSC in the binding instead?
>> >> >I imagine that means there's a DRV0,1,2 and those probably have an
>> >> >interrupt per each DRV and then a different TCS config per each one too?
>> >> >If the binding can describe all of the RSC then we can use different
>> >> >DRVs by changing the qcom,drv-id property.
>> >> >
>> >> > rsc@...c0000 {
>> >> > compatible = "qcom,rpmh-rsc";
>> >> > reg = <0x179c0000 0x10000>,
>> >> > <0x179d0000 0x10000>,
>> >> > <0x179e0000 0x10000>;
>> >> > qcom,tcs-offset = <0xd00>;
>> >> > qcom,drv-id = <0/1/2>;
>> >> > interrupts = <GIC_SPI 3 IRQ_TYPE_LEVEL_HIGH>,
>> >> > <GIC_SPI 4 IRQ_TYPE_LEVEL_HIGH>,
>> >> > <GIC_SPI 5 IRQ_TYPE_LEVEL_HIGH>;
>> >> > }
>> >> >
>> >> >This is sort of what I imagine it would look like. I have no idea how
>> >> >the tcs config would work unless each DRV has the same TCS config
>> >> >though. Otherwise, if each node is for a drv, then I would expect the
>> >> >node would be called 'drv' and we wouldn't need the drv-id property and
>> >> >the compatible string would say drv instead of rsc?
>> >> >
>> >> >BTW, what are the other DRVs used for in the apps RSC?
>> >> >
>> >> The DRV is the voter for an execution environment (Linux, Hypervisor,
>> >> ATF) in the RSC. The RSC has a lot of other registers that Linux is not
>> >> privy to. They are access restricted.
>> >
>> >Alright. Well sometimes access restrictions aren't there, so this isn't
>> >a good assumption to make.
>> >
>> >> The memory organization of the RSC
>> >> mandates that we know the DRV id to access registers specific to the
>> >> DRV.
>> >
>> >I think qcom,drv-id covers that, no?
>> >
>> >> Unfortunately, not all RSC have identical DRV configuration and the
>> >> register space is also variable depending on the capability of the RSC.
>> >> There are functionalities supported by other RSCs in the SoC that are
>> >> not supported by the RSC associated with the application processor,
>> >> while not many RSCs' support multiple DRVs. Therefore it doesn't benefit
>> >> describing the whole RSC as it is not usable from Linux (because of
>> >> access restrictions).
>> >
>> >If we're not describing the whole RSC in the RSC binding then we're not
>> >going to get very far. From what I can tell, this binding describes one
>> >DRV inside of an RSC instead of the whole RSC. Yes we'll probably never
>> >use the ATF part of the RSC in Linux, but we may use the hypervisor part
>> >if we use KVM/Xen so the binding should be describing as much as it can
>> >about this device in case some software needs to use it.
>> >
>> The RSC is pretty much this. A set of registers that are RSC specific at
>> the address pointed to by the "rsc" reg and the TCS regsiters pointed to
>> by the "tcs" reg. You do not want to clobber multiple DRVs into the same
>> device node. It will be a lot confusing for the drivers to determine
>> which DRV to vote.
>
>Well it seems like an RSC contains many DRVs and those DRVs contain many
>TCSes. This is what I get after talking with Bjorn on IRC.
>
> +--------------------------------------------------+ (0x00000)
> | |
> | DRV #0 |
> | |
> |---------- --------------| (tcs-offset (0xd00))
> | DRV0_TCS0 |
> | common space |
> | cmd sequencer | 0xd00 + 0x14
> | |
> | DRV0_TCS1 |
> | common space | 0xd00 + 0x2a0
> | cmd sequencer | 0xd00 + 0x2a0 + 0x14
> | |
> | DRV0_TCS2 |
> | |
> | |
> +--------------------------------------------------+ (0x10000)
> | |
> | DRV #1 |
> | |
> |---------- --------------| (tcs-offset)
> | DRV1_TCS0 |
> | DRV1_TCS1 |
> | DRV1_TCS2 |
> +--------------------------------------------------+ (0x20000)
> | |
> | DRV #2 |
> | |
> |---------- --------------|
> | DRV2_TCS0 |
> | DRV2_TCS1 |
> | DRV2_TCS2 |
> | DRV2_TCS3 |
> | DRV2_TCS4 |
> | DRV2_TCS5 |
> +--------------------------------------------------+
>
>I think I understand it now. There aren't any "RSC common" registers
>that are common to the entire RSC. Instead, everything goes into a DRV,
>or into a common TCS space, or into a TCS "queue".
>
>> >Put another way, even if the "apps" RSC is complicated, we should be
>> >describing it to the best of our abilities in the binding so that when
>> >it is used by non-linux OSes things still work by simply tweaking the
>> >drv-id that we use to pick the right things out of the node.
>> >
>> >Or we're describing the RSC but it's really a container node that
>> >doesn't do much besides hold DRVs? So this is described at the wrong
>> >level?
>> What we are describing is a DRV, but a standalone DRV alone is useless
>> without the necessary RSC registers. So its a unique RSC+DRV combination
>> that is represented here.
>>
>
>If my understanding is correct up there then the binding could either
>describe a single RSC DRV, or it could describe all the RSC DRV
>instances and interrupts going into the RSC "block" and then we can use
>drv-id to pick the offset we jump to.
>
Your understanding is correct.
>I imagine we don't have any practical use-case for the entire RSC space
>because there aren't any common RSC registers to deal with.
Not true.
>So we've
>boiled this all down to describing one DRV and then I wonder why we care
>about having drv-id at all? It looks to be used to check for a max
>number of TCS, but that's already described by DT so it doesn't seem
>very useful to double check what the hardware can tells us.
>
There is also a number of commands per TCS (NCPT), that may way vary
between different RSCs. The RSC of the application processor has 16
commands in each TCS, but that is variable. I am not saying it cannot be
described in DT, but it is something I read from the common RSC
registers, currently.
Also, I will using common/DRV0 registers to write wakeup time value,
when the processor subsystem goes into power down. This is not DRV2
register, but is a DRV0 register that we will have special access to.
The patches for those I intend to publish, when we have support for
sleep/suspend with this new architecture. So the address of the start of
the RSC (=DRV0) is necessary.
>Long story short, we can remove drv-id and just describe drvs by
>themselves?
Yes, we may. As long as I have a way to describe the register addresss
of the start of the DRV (0x20000 for DRV#2) and the tcs-offset (0xd00),
we can work with the RSC-DRV in the driver.
Thanks,
Lina
Powered by blists - more mailing lists