-
Notifications
You must be signed in to change notification settings - Fork 47
[WIP] Implemented transactional interfaces #33
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
r? @posborne (rust_highfive has picked a reviewer for you, use r? to override) |
// TODO: is spidev okay with the same array pointer | ||
// being used twice? If not, need some kind of vector | ||
// pool that will outlive the transfer | ||
let w = unsafe { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@posborne is this too cursed? i can't seem to find any documentation as to whether it's okay or not.
Alternatively we might need some kind of memory pool to copy things into / keep the storage around till the transactions are all done (because the transfer object can't hold something owned)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
From looking at the implementation I think it would work, as the buffers are copied in and out. However, a documented guarantee would be better.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As @eldruin notes, this should be fine with how the kernel works (performing a copy_from_user). That being said, I do agree that it does feel off, although I can't reason about any way it could go wrong in practice.
I would be OK with landing this here and considering adding an API to spidev which would be designed to explicitly provide safe semantics for this way of interacting with the syscall for future use. That is, something like (not sure about naming):
pub fn read_write_shared(txrx_buf: &'a mut [u8]) -> Self
LGTM; will hold off on final approval, etc. until dep is ready to go. Probably want to at least update docs for the read_write case based on discussions. |
Broke the embedded-hal PR in half, once the upstream has landed I will open another PR against https://github.com/ryankurte/linux-embedded-hal/tree/feature/spi-transactions |
Closing for #35 |
44: Implement transactional I2C interface and add example r=ryankurte a=eldruin I implemented the transactional I2C interface from rust-embedded/embedded-hal#223 and added an example with a driver which does a combined Write/Read transaction. This is based on previous work from #33 by @ryankurte, rust-embedded/rust-i2cdev#51 and is similar to #35. Co-authored-by: Diego Barrios Romero <[email protected]>
44: Implement transactional I2C interface and add example r=ryankurte a=eldruin I implemented the transactional I2C interface from rust-embedded/embedded-hal#223 and added an example with a driver which does a combined Write/Read transaction. This is based on previous work from #33 by @ryankurte, rust-embedded/rust-i2cdev#51 and is similar to #35. Co-authored-by: Diego Barrios Romero <[email protected]>
35: Add transactional SPI r=ryankurte a=ryankurte Implementation of transactional SPI - replaces #33 - blocked on: - ~rust-embedded/embedded-hal#191 - ~#34 ~Important: remove patch and bump hal version before merging~ Co-authored-by: ryan <[email protected]> Co-authored-by: Ryan <[email protected]>
Implementation of transactional SPI and I2C traits, blocked on merge of rust-embedded/embedded-hal#178
important: remove patch before merging