-
Notifications
You must be signed in to change notification settings - Fork 8.4k
Adds read-only property for the I2C EEPROM Target #75777
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
Adds read-only property for the I2C EEPROM Target #75777
Conversation
aba8e43 to
b119543
Compare
b119543 to
0aa34cf
Compare
2e4621a to
2abe1e1
Compare
henrikbrixandersen
left a comment
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.
Looks good! Now all that's needed is a corresponding test case in tests/drivers/i2c/i2c_target_api/ 👍
Good point, I will figure out how and update the PR once done. |
|
@henrikbrixandersen I am thinking about adding another EEPROM which is read-only to the device tree overlays within the test project. Also an EEPROM with 16bit addressing should be added to increase test coverage of the existing code which also supports this since a couple of months. I could probably do that at the same time. Does this sound like the right approach to you? |
Yes, that sounds good along with some accompanying test cases. |
|
This pull request has been marked as stale because it has been open (more than) 60 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this pull request will automatically be closed in 14 days. Note, that you can always re-open a closed pull request at any time. |
|
I took this up again as I was busy with other stuff during the last months. I tried to run the existing test on a RPi Pico but couldn't get it to work until now. What hardware setup is needed to run those tests? |
2abe1e1 to
b6d33a6
Compare
|
@henrikbrixandersen I finally had the time to write a simple test and I pushed my work in progress. Some questions:
|
9816428 to
0db9102
Compare
In case the EEPROM data stored in the buffer shall be not writable from the I2C interface, the read-only property can now be set in the device tree. Signed-off-by: Manuel Aebischer <[email protected]>
f136954 to
7d2aeea
Compare
This additional test case verifies that an i2c_eeprom_target, which is set as read-only in the device tree cannot be written from the I2C bus. Signed-off-by: Manuel Aebischer <[email protected]>
7d2aeea to
800ce8d
Compare
|
Okay, I saw that the boards are tested in CI, so I can safely add it to the overlays without breaking the tests |
henrikbrixandersen
left a comment
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.
Thanks! However, I don't think we need this read-only EEPROM added to each and every board here (and we really need to cut down on these boards).
Perhaps make the test conditional on the device being available (skip it if not present) and just add it to the board(s), you've tested with?
| #ifndef CONFIG_I2C_DW | ||
| zassert_not_equal(ret, 0, "Write attempt to read-only EEPROM 2 succeeded unexpectedly"); | ||
| #endif |
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.
Why is this needed?
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.
Usually the target should generate a NAK if it's being written and it's write protected, therefore the write on the controller side should return a non-zero return code. Unfortunately, the DesignWare I2C does not seem to implement this NAKing when used in target mode. I see if I can get hold of some other boards (e.g. STM32) to verify this as well.
Okay, understood. Will clean this up the coming week hopefully. |
|
This pull request has been marked as stale because it has been open (more than) 60 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this pull request will automatically be closed in 14 days. Note, that you can always re-open a closed pull request at any time. |
decsny
left a comment
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.
dt prop is fine
| #define I2C_EEPROM_INIT(inst) \ | ||
| static struct i2c_eeprom_target_data i2c_eeprom_target_##inst##_dev_data = { \ | ||
| .address_width = DT_INST_PROP_OR(inst, address_width, 8), \ | ||
| .read_only = DT_INST_PROP_OR(inst, read_only, 8), \ |
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.
Looks like a copy-paste error. The read-only property is always present due to its type being boolean so there is no reason to give it a default value.
| .read_only = DT_INST_PROP_OR(inst, read_only, 8), \ | |
| .read_only = DT_INST_PROP(inst, read_only), \ |
|
@Manu3l0us Any plans for resuming work on this? |
|
@Manu3l0us I'm going to close this due to lack of response, although I'd love to see this feature make it in. Please reopen it if you decide to come back to this. |
In case the EEPROM data stored in the buffer shall be not writable from the I2C interface, the read-only property can now be set in the device tree.