restricting on setting mcontrol.dmode and mcontrol.chain

[senlinhe]

spec says "hardware must zero it in writes to mcontrol6 that set dmode to 0 if the next trigger has dmode of 1".
When hardware set the current trigger with dmode=1 while the next trigger has dmode=0, does the constrain of clearing chain still need to be followed？

[senlinhe]

According to #754, it is not allowed to native trigger chained with external trigger, so I think the above scenario should also be considered
@pdonahue-ventana

[pdonahue-ventana]

We don't want these things:

• trigger A with dmode=0, chain=1 and trigger A+1 with dmode=1
• trigger A with dmode=1, chain=1 and trigger A+1 with dmode=0

That can happen in these situations:

1. write trigger A with dmode=0, chain=1 when trigger A+1 already has dmode=1
2. write trigger A+1 with dmode=1 when trigger A already has dmode=0, chain=1
3. write trigger A with dmode=1, chain=1 when trigger A+1 already has dmode=0
4. write trigger A+1 with dmode=0 when trigger A has dmode=1, chain=1

The spec talks about 1 in the first sentence. The idea is to prevent a native debugger from depending on the (more privileged) external debugger that it can't control.

It talks about 2 in the second sentence. The idea is to prevent an external debugger from accidentally allowing a native debugger to depend on the external debugger.

Scenarios 3 and 4 aren't expected to happen if the external debugger is doing things correctly. An external debugger that wants to chain things will need to write both A and A+1. Scenario 3 could actually happen temporarily if it writes them in this order (instead of reverse order). If an external debugger only writes to A (but not A+1) and chains with trigger A+1 which is outside its control then the debugger is buggy. (We can't always deal with buggy debuggers. Buggy debuggers are able to crash the whole system if, for instance, they start writing random garbage to random memory or devices.)

Scenario 4 can only happen if the external debugger is doing the write to A+1 (in which case it would be a bug to not use dmode=1) or if a native debugger is doing the write to A+1 and the prior value had dmode=0 (and only a buggy external debugger could have created that situation using scenario 3). If dmode=1 on A+1 then the native debugger could not have written A+1.

I'm not sure if all of these scenarios were identified and it was decided that only 1 and 2 mattered or if 3 and 4 weren't identified. It might have been nice to have dealt with all 4 scenarios in the spec but I don't think that it matters in real life. And allowing 3 gives the external debugger the flexibility to write the chained triggers in order instead of in reverse order (which isn't flexibility that's really required but maybe somebody might find it more intuitive).