diff options
| author |  bors[bot] <bors[bot]@users.noreply.github.com>
| 2018-10-27 11:14:53 +0000 |
|---|---|---|
| committer | bors[bot] <bors[bot]@users.noreply.github.com>
| 2018-10-27 11:14:53 +0000 |
| commit | 4134f02d65982e18784e87b046a11dab287f74c3 (patch) | |
| tree | c1865a7703f13ef9a4f2bd96c877fc7ab0a3f221 /build.rs | |
| parent | d394540ca3583d0fdc959538f1f9201a5e132c5a (diff) | |
| parent | 92f269f74181d7079650c669b37b5671f0379a7e (diff) | |
| download | cortex-m-4134f02d65982e18784e87b046a11dab287f74c3.tar.gz cortex-m-4134f02d65982e18784e87b046a11dab287f74c3.tar.zst cortex-m-4134f02d65982e18784e87b046a11dab287f74c3.zip | |
Merge #120
120: deprecate NVIC.{clear,set}_pending in favor of NVIC::{un,}pend r=therealprof a=japaric
NVIC::{un,}pend are static methods that don't require an instance of NVIC to be
invoked.
Rationale: These operations perform writes to stateless registers so they can
*not* result in data races.
More tricky is the question of whether letting the user call these from any
execution context without any critical section or other means of synchronization
can result in memory unsafety when used in conjunction with methods like
NVIC.{get,set}_priority that do require an instance of NVIC. I can't foresee any
trouble given that these methods (e.g. pend and set_priority) operate on
different registers.
Co-authored-by: Jorge Aparicio <jorge@japaric.io>
Diffstat (limited to 'build.rs')
0 files changed, 0 insertions, 0 deletions