<ryan-summers[m]>
In a meeting, but we do hardware CSn management a lot in Stabilizer, so I'm sure I can help out in a bit
<ryan-summers[m]>
The reason we don't use TSIZE is because if you set TSIZE to a non-infinite mode, it then sets TXTF, which results in SPI not working at all until the flag is cleared (writes to the FIFO get ignored). It's honestly pretty stupid imo, but it's silicon implementation
<ryan-summers[m]>
So if TSIZE is used with something like DMA, DMA writes then silently get ignored because TXTF gets asserted after the first TSIZE transaction is sent
<diondokter[m]>
Right, wouldn't want that
<diondokter[m]>
So you need to set it up beforehand and also clean up afterwards
<ryan-summers[m]>
Or just only set TSIZE when the user requests it specifically
<ryan-summers[m]>
But you'd need to ensure that we're clearing TXTF as needed in the driver
<ryan-summers[m]>
And also document that behavior if you use TSIZE for external users
<diondokter[m]>
If that were for the blocking interface only, would that be ok?
<ryan-summers[m]>
But other than that, I don't see why it couldn't exist in the HAL alongside the existing impl
<diondokter[m]>
Hmmmm... I've got an idea. I'll prototype a bit. If I like it I'll send a PR for review. Thanks!
DerFetzer[m] has quit [Quit: Idle for 30+ days]
<korken89[m]>
Hey adamgreig, in the stm32-rs you use a bot to make comments on PRs - do you have the lines of code that makes this happen?
<korken89[m]>
I'm unable to find it :)
<korken89[m]>
We would like to do the same in RTIC but with cargo-bloat
<adamgreig-m>
be very careful with using `pull_request_target` because it will run with github secrets/tokens but with code from the pull request fork
<korken89[m]>
Oh
<adamgreig-m>
for example, if you run `cargo bloat` over the PR code, and it has a naughty `build.rs`, it could get access to github through the bot
<korken89[m]>
Hmm, how do you protect from this in stm32-rs?
<adamgreig-m>
it doesn't need to execute any code from the fork - it checks out the master branch and the PR branch, copies all the YAML files from PR into master, then runs the makefile that's in master
<korken89[m]>
Ah, I see
<adamgreig-m>
the other way around this is using `workflow_run` which lets you do the `cargo bloat` in a normal `pull_request` context (no secrets available, so safe to execute user code), then send the results to another workflow step that will post the comment (using the key)
<korken89[m]>
I'm scarred for life by `.unwrap()` bloat
<adamgreig-m>
the trick is to upload an 'asset' to share between workflows, but it was a bit too complicated for me with the mmaps thing so instead i did it my way
<adamgreig-m>
hah
<rjo>
One way is to trigger those workflows from events that only you can cause on a PR: added labels, certain comments, or cargo bloat the staging/trying branch and comment. That's safe as long as you review before labling/commenting/bors try.