| 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: <CAJ9a7ViKxHThyZfFFDV_FkNRimk4uo1NrMtQ-kcaj1qO4ZcGnA@mail.gmail.com> Date: Tue, 29 Jul 2025 11:36:23 +0100 From: Mike Leach <mike.leach@...aro.org> To: Songwei Chai <quic_songchai@...cinc.com> Cc: songchai <songchai@....qualcomm.com>, Suzuki K Poulose <suzuki.poulose@....com>, James Clark <james.clark@....com>, Alexander Shishkin <alexander.shishkin@...ux.intel.com>, Andy Gross <agross@...nel.org>, Bjorn Andersson <andersson@...nel.org>, Rob Herring <robh+dt@...nel.org>, Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley <conor+dt@...nel.org>, linux-kernel@...r.kernel.org, coresight@...ts.linaro.org, linux-arm-kernel@...ts.infradead.org, linux-arm-msm@...r.kernel.org, devicetree@...r.kernel.org Subject: Re: [PATCH v6 0/7] Provides support for Trigger Generation Unit Hi, On Wed, 23 Jul 2025 at 07:33, Songwei Chai <quic_songchai@...cinc.com> wrote: > > > On 7/21/2025 9:39 PM, Mike Leach wrote: > > Hi, > > On Wed, 9 Jul 2025 at 11:41, songchai <songchai@....qualcomm.com> wrote: > > From: Songwei Chai <quic_songchai@...cinc.com> > > Provide support for the TGU (Trigger Generation Unit), which can be > utilized to sense a plurality of signals and create a trigger into > the CTI or generate interrupts to processors once the input signal > meets the conditions. We can treat the TGU’s workflow as a flowsheet, > it has some “steps” regions for customization. In each step region, > we can set the signals that we want with priority in priority_group, set > the conditions in each step via condition_decode, and set the resultant > action by condition_select. Meanwhile, some TGUs (not all) also provide > timer/counter functionality. Based on the characteristics described > above, we consider the TGU as a helper in the CoreSight subsystem. > Its master device is the TPDM, which can transmit signals from other > subsystems, and we reuse the existing ports mechanism to link the TPDM to > the connected TGU. > > Here is a detailed example to explain how to use the TGU: > > In this example, the TGU is configured to use 2 conditions, 2 steps, and > the timer. The goal is to look for one of two patterns which are generated > from TPDM, giving priority to one, and then generate a trigger once the > timer reaches a certain value. In other words, two conditions are used > for the first step to look for the two patterns, where the one with the > highest priority is used in the first condition. Then, in the second step, > the timer is enabled and set to be compared to the given value at each > clock cycle. These steps are better shown below. > > |-----------------| > | | > | TPDM | > | | > |-----------------| > | > | > --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- ------ > | | | > | | |--------------------| | > | |---- ---> | | Go to next steps | | > | | | |--- ---> | Enable timer | | > | | v | | | | > | | |-----------------| | |--------------------| | > | | | | Yes | | | > | | | inputs==0xB | ----->| | <-------- | > | | | | | | No | | > | No | |-----------------| | v | | > | | | | |-----------------| | | > | | | | | | | | > | | | | | timer>=3 |-- | > | | v | | | | > | | |-----------------| | |-----------------| | > | | | | Yes | | | > | |--- | inputs==0xA | ----->| | Yes | > | | | | | > | |-----------------| v | > | |-----------------| | > | | | | > | | Trigger | | > | | | | > | |-----------------| | > | TGU | | > |--- --- --- --- --- --- --- --- --- --- --- --- --- --- |--- --- -- | > | > v > |-----------------| > |The controllers | > |which will use | > |triggers further | > |-----------------| > > steps: > 1. Reset TGU /*it will disable tgu and reset dataset*/ > - echo 1 > /sys/bus/coresight/devices/<tgu-name>/reset_tgu > > 2. Set the pattern match for priority0 to 0xA = 0b1010 and for > priority 1 to 0xB = 0b1011. > - echo 0x11113232 > /sys/bus/coresight/devices/<tgu-name>/step0_priority0/reg0 > - echo 0x11113233 > /sys/bus/coresight/devices/<tgu-name>/step0_priority1/reg0 > > Note: > Bit distribution diagram for each priority register > |-------------------------------------------------------------------| > | Bits | Field Nam | Description | > |-------------------------------------------------------------------| > | | | 00 = bypass for OR output | > | 29:28 | SEL_BIT7_TYPE2 | 01 = bypass for AND output | > | | | 10 = sense input '0' is true| > | | | 11 = sense input '1' is true| > |-------------------------------------------------------------------| > | | | 00 = bypass for OR output | > | 25:24 | SEL_BIT6_TYPE2 | 01 = bypass for AND output | > | | | 10 = sense input '0' is true| > | | | 11 = sense input '1' is true| > |-------------------------------------------------------------------| > | | | 00 = bypass for OR output | > | 21:20 | SEL_BIT5_TYPE2 | 01 = bypass for AND output | > | | | 10 = sense input '0' is true| > | | | 11 = sense input '1' is true| > |-------------------------------------------------------------------| > | | | 00 = bypass for OR output | > | 17:16 | SEL_BIT4_TYPE2 | 01 = bypass for AND output | > | | | 10 = sense input '0' is true| > | | | 11 = sense input '1' is true| > |-------------------------------------------------------------------| > | | | 00 = bypass for OR output | > | 13:12 | SEL_BIT3_TYPE2 | 01 = bypass for AND output | > | | | 10 = sense input '0' is true| > | | | 11 = sense input '1' is true| > |-------------------------------------------------------------------| > | | | 00 = bypass for OR output | > | 9:8 | SEL_BIT2_TYPE2 | 01 = bypass for AND output | > | | | 10 = sense input '0' is true| > | | | 11 = sense input '1' is true| > |-------------------------------------------------------------------| > | | | 00 = bypass for OR output | > | 5:4 | SEL_BIT1_TYPE2 | 01 = bypass for AND output | > | | | 10 = sense input '0' is true| > | | | 11 = sense input '1' is true| > |-------------------------------------------------------------------| > | | | 00 = bypass for OR output | > | 1:0 | SEL_BIT0_TYPE2 | 01 = bypass for AND output | > | | | 10 = sense input '0' is true| > | | | 11 = sense input '1' is true| > |-------------------------------------------------------------------| > These bits are used to identify the signals we want to sense, with > a maximum signal number of 140. For example, to sense the signal > 0xA (binary 1010), we set the value of bits 0 to 13 to 3232, which > represents 1010. The remaining bits are set to 1, as we want to use > AND gate to summarize all the signals we want to sense here. For > rising or falling edge detection of any input to the priority, set > the remaining bits to 0 to use an OR gate. > > 3. look for the pattern for priority_i i=0,1. > - echo 0x3 > /sys/bus/coresight/devices/<tgu-name>/step0_condition_decode/reg0 > - echo 0x30 > /sys/bus/coresight/devices/<tgu-name>/step0_condition_decode/reg1 > > |-------------------------------------------------------------------------------| > | Bits | Field Nam | Description | > |-------------------------------------------------------------------------------| > | | |For each decoded condition, this | > | 24 | NOT |inverts the output. If the condition | > | | |decodes to true, and the NOT field | > | | |is '1', then the output is NOT true. | > |-------------------------------------------------------------------------------| > | | |When '1' the output from the associated| > | 21 | BC0_COMP_ACTIVE |comparator will be actively included in| > | | |the decoding of this particular | > | | |condition. | > |-------------------------------------------------------------------------------| > | | |When '1' the output from the associated| > | | |comparator will need to be 1 to affect | > | 20 | BC0_COMP_HIGH |the decoding of this condition. | > | | |Conversely, a '0' here requires a '0' | > | | |from the comparator | > |-------------------------------------------------------------------------------| > | | |When '1' the output from the associated| > | 17 | |comparator will be actively included in| > | | TC0_COMP_ACTIVE |the decoding of this particular | > | | |condition. | > |-------------------------------------------------------------------------------| > | | |When '1' the output from the associated| > | | |comparator will need to be 1 to affect | > | 16 | TC0_COMP_HIGH |the decoding of this particular | > | | |condition.Conversely, a 0 here | > | | |requires a '0' from the comparator | > |-------------------------------------------------------------------------------| > | | |When '1' the output from Priority_n | > | | |OR logic will be actively | > | 4n+3 | Priority_n_OR_ACTIVE|included in the decoding of | > | | (n=0,1,2,3) |this particular condition. | > | | | | > |-------------------------------------------------------------------------------| > | | |When '1' the output from Priority_n | > | | |will need to be '1' to affect the | > | 4n+2 | Priority_n_OR_HIGH |decoding of this particular | > | | (n=0,1,2,3) |condition. Conversely, a '0' here | > | | |requires a '0' from Priority_n OR logic| > |-------------------------------------------------------------------------------| > | | |When '1' the output from Priority_n | > | | |AND logic will be actively | > | 4n+1 |Priority_n_AND_ACTIVE|included in the decoding of this | > | | (n=0,1,2,3) |particular condition. | > | | | | > |-------------------------------------------------------------------------------| > | | |When '1' the output from Priority_n | > | | |AND logic will need to be '1' to | > | 4n | Priority_n_AND_HIGH |affect the decoding of this | > | | (n=0,1,2,3) |particular condition. Conversely, | > | | |a '0' here requires a '0' from | > | | |Priority_n AND logic. | > |-------------------------------------------------------------------------------| > Since we use `priority_0` and `priority_1` with an AND output in step 2, we set `0x3` > and `0x30` here to activate them. > > 4. Set NEXT_STEP = 1 and TC0_ENABLE = 1 so that when the conditions > are met then the next step will be step 1 and the timer will be enabled. > - echo 0x20008 > /sys/bus/coresight/devices/<tgu-name>/step0_condition_select/reg0 > - echo 0x20008 > /sys/bus/coresight/devices/<tgu-name>/step0_condition_select/reg1 > > |-----------------------------------------------------------------------------| > | Bits | Field Nam | Description | > |-----------------------------------------------------------------------------| > | | |This field defines the next step the | > | 18:17 | NEXT_STEP |TGU will 'goto' for the associated | > | | |Condition and Step. | > |-----------------------------------------------------------------------------| > | | |For each possible output trigger | > | 13 | TRIGGER |available, set a '1' if you want | > | | |the trigger to go active for the | > | | |associated condition and Step. | > |-----------------------------------------------------------------------------| > | | |This will cause BC0 to increment if the| > | 9 | BC0_INC |associated Condition is decoded for | > | | |this step. | > |-----------------------------------------------------------------------------| > | | |This will cause BC0 to decrement if the| > | 8 | BC0_DEC |associated Condition is decoded for | > | | |this step. | > |-----------------------------------------------------------------------------| > | | |This will clear BC0 count value to 0 if| > | 7 | BC0_CLEAR |the associated Condition is decoded | > | | |for this step. | > |-----------------------------------------------------------------------------| > | | |This will cause TC0 to increment until | > | 3 | TC0_ENABLE |paused or cleared if the associated | > | | |Condition is decoded for this step. | > |-----------------------------------------------------------------------------| > | | |This will cause TC0 to pause until | > | 2 | TC0_PAUSE |enabled if the associated Condition | > | | |is decoded for this step. | > |-----------------------------------------------------------------------------| > | | |This will clear TC0 count value to 0 | > | 1 | TC0_CLEAR |if the associated Condition is | > | | |decoded for this step. | > |-----------------------------------------------------------------------------| > | | |This will set the done signal to the | > | 0 | DONE |TGU FSM if the associated Condition | > | | |is decoded for this step. | > |-----------------------------------------------------------------------------| > Based on the distribution diagram, we set `0x20008` for `priority0` and `priority1` to > achieve "jump to step 1 and enable TC0" once the signal is sensed. > > 5. activate the timer comparison for this step. > - echo 0x30000 > /sys/bus/coresight/devices/<tgu-name>/step1_condition_decode/reg0 > > |-------------------------------------------------------------------------------| > | | |When '1' the output from the associated| > | 17 | |comparator will be actively included in| > | | TC0_COMP_ACTIVE |the decoding of this particular | > | | |condition. | > |-------------------------------------------------------------------------------| > | | |When '1' the output from the associated| > | | |comparator will need to be 1 to affect | > | 16 | TC0_COMP_HIGH |the decoding of this particular | > | | |condition.Conversely, a 0 here | > | | |requires a '0' from the comparator | > |-------------------------------------------------------------------------------| > Accroding to the decode distribution diagram , we give 0x30000 here to set 16th&17th bit > to enable timer comparison. > > 6. Set the NEXT_STEP = 0 and TC0_PAUSE = 1 and TC0_CLEAR = 1 once the timer > has reached the given value. > - echo 0x6 > /sys/bus/coresight/devices/<tgu-name>/step1_condition_select/reg0 > > 7. Enable Trigger 0 for TGU when the condition 0 is met in step1, > i.e. when the timer reaches 3. > - echo 0x2000 > /sys/bus/coresight/devices/<tgu-name>/step1_condition_select/default > > Note: > 1. 'default' register allows for establishing the resultant action for > the default condition > > 2. Trigger:For each possible output trigger available from > the Design document, there are three triggers: interrupts, CTI, > and Cross-TGU mapping.All three triggers can occur, but > the choice of which trigger to use depends on the user's > needs. > > 8. Compare the timer to 3 in step 1. > - echo 0x3 > /sys/bus/coresight/devices/<tgu-name>/step1_timer/reg0 > > 9. enale tgu > - echo 1 > /sys/bus/coresight/devices/<tgu-name>/enable_tgu > --- > Link to V5: https://lore.kernel.org/all/20250529081949.26493-1-quic_songchai@quicinc.com/ > > Changes in V6: > - Replace spinlock with guard(spinlock) in tgu_enable. > - Remove redundant blank line. > - Update publish date and contact member's name in "sysfs-bus-coresight-devices-tgu". > --- > Link to V4: https://patchwork.kernel.org/project/linux-arm-msm/cover/20250423101054.954066-1-quic_songchai@quicinc.com/ > > Changes in V5: > - Update publish date and kernel_version in "sysfs-bus-coresight-devices-tgu" > --- > Link to V3: https://lore.kernel.org/all/20250227092640.2666894-1-quic_songchai@quicinc.com/ > > Changes in V4: > - Add changlog in coverletter. > - Correct 'year' in Copyright in patch1. > - Correct port mechansim description in patch1. > - Remove 'tgu-steps','tgu-regs','tgu-conditions','tgu-timer-counters' from dt-binding > and set them through reading DEVID register as per Mike's suggestion. > - Modify tgu_disable func to make it have single return point in patch2 as per > Mike's suggestion. > - Use sysfs_emit in enable_tgu_show func in ptach2. > - Remove redundant judgement in enable_tgu_store in patch2. > - Correct typo in description in patch3. > - Set default ret as SYSFS_GROUP_INVISIBLE, and returnret at end in pacth3 as > per Mike's suggestion. > - Remove tgu_dataset_ro definition in patch3 > - Use #define constants with explanations of what they are rather than > arbitrary magic numbers in patch3 and patch4. > - Check -EINVAL before using 'calculate_array_location()' in array in patch4. > - Add 'default' in 'tgu_dataset_show''s switch part in patch4. > - Document the value needed to initiate the reset in pacth7. > - Check "value" in 'reset_tgu_store' and bail out with an error code if 0 in patch7. > - Remove dev_dbg in 'reset_tgu_store' in patch7. > --- > Link to V2: https://lore.kernel.org/all/20241010073917.16023-1-quic_songchai@quicinc.com/ > > Changes in V3: > - Correct typo and format in dt-binding in patch1 > - Rebase to the latest kernel version > --- > Link to V1: https://lore.kernel.org/all/20240830092311.14400-1-quic_songchai@quicinc.com/ > > Changes in V2: > - Use real name instead of login name, > - Correct typo and format in dt-binding and code. > - Bring order in tgu_prob(declarations with and without assignments) as per > Krzysztof's suggestion. > - Add module device table in patch2. > - Set const for tgu_common_grp and tgu_ids in patch2. > - Initialize 'data' in tgu_ids to fix the warning in pacth2. > --- > > Songwei Chai (7): > dt-bindings: arm: Add support for Coresight TGU trace > coresight: Add coresight TGU driver > coresight-tgu: Add signal priority support > coresight-tgu: Add TGU decode support > coresight-tgu: add support to configure next action > coresight-tgu: add timer/counter functionality for TGU > coresight-tgu: add reset node to initialize > > .../testing/sysfs-bus-coresight-devices-tgu | 51 ++ > .../bindings/arm/qcom,coresight-tgu.yaml | 92 +++ > drivers/hwtracing/coresight/Kconfig | 11 + > drivers/hwtracing/coresight/Makefile | 1 + > drivers/hwtracing/coresight/coresight-tgu.c | 776 ++++++++++++++++++ > drivers/hwtracing/coresight/coresight-tgu.h | 255 ++++++ > 6 files changed, 1186 insertions(+) > create mode 100644 Documentation/ABI/testing/sysfs-bus-coresight-devices-tgu > create mode 100644 Documentation/devicetree/bindings/arm/qcom,coresight-tgu.yaml > create mode 100644 drivers/hwtracing/coresight/coresight-tgu.c > create mode 100644 drivers/hwtracing/coresight/coresight-tgu.h > > > As per the discussion here in v3 of this patchset > > https://lists.infradead.org/pipermail/linux-arm-kernel/2025-March/1012896.html > > this component is primarily a part of the qualcom proprietary QPMDA > subsystem, and is capable of operating independently from the > CoreSight hardware trace generation system. > > The only link to Coresight is via the trigger input to CTI > component(s). CTI triggers can either be part of the ARM architected > or recommended connections between Coresight infrastructure from the > coresight specs and TRM documents, or platform specific triggers from > components external to coresight. For example on the Juno board a > trigger from the PL011 serial port is input to one of the system CTIs > on the board. > > Having Coresight management registers does not necessarily mean that > the component should be maintained under the hwtracing/coresight. Some > ARM Corelink interconnect components have the capability to generate > ATB trace into the coresight subsystem, and have some of the coresight > management registers. However, I would not expect the drivers for > these components to appear in hwtracing/coresight. > > As such this component could probably be better managed and maintained > as part of the /drivers/soc/qcom or similar area. > > The only changes to the Coresight infrastructure you should need to > get this component connected, is to alter the CTI declaration in board > device tree to add the incoming trigger as per the CTI bindings. > > Regards > > Mike > > Hi Mike, > > Thank you very much for your detailed feedback and for pointing out the architectural considerations > regarding the component's relationship with Coresight and the QPMDA subsystems. We fully understand > and appreciate your perspective on keeping the driver organization clean and aligned with subsystem boundaries. > > However, we would like to offer a slightly different view regarding the placement of this driver: > The TGU driver here exposes sysfs interfaces for user interaction and configuration. This kind of interface is generally not acceptable > under /driver/soc/qcom, which is typically reserved for passive platform drivers without user-facing interfaces. > > Given this, we'd like to ask your opinion on an alternative: > Would it be acceptable to create a new sub directory under /hwtracing/qcom to host this driver? > Alternatively, we could consider placing it under /driver/misc if that's more appropriate. > > Our preference would be place it under /driver/hwtracing/qcom, as this would provide a natural > home form Qualcomm-specific trace-related components that are adjacent to, but not strictly > part of, the Coresight architecture. This could also help organize future drivers that share similar > characteristics. > I am unsure on the procedure for creating new sub-directories for code in the kernel, but one key thing you do need is a maintainer for the code. The reason I suggested /driver/soc/qcom, was that this had qualcomm specific code with active maintainers. I recommend you consult with those responsible for maintaining qualcomm code within the kernel for the best course of action. Regards Mike > Looking forward to your thoughts. > > BRs, > Songwei > > > > > > -- > Mike Leach > Principal Engineer, ARM Ltd. > Manchester Design Centre. UK > -- Mike Leach Principal Engineer, ARM Ltd. Manchester Design Centre. UK
Powered by blists - more mailing lists