)]}'
{"/PATCHSET_LEVEL":[{"author":{"_account_id":1000021,"name":"Antonio Borneo","email":"borneo.antonio@gmail.com","username":"borneoa"},"change_message_id":"a90a03941b543eb1fbd108911964e0962b32cf54","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"be9b95e7_48e7ca84","updated":"2024-06-23 21:50:35.000000000","message":"Thanks for the patch.\nI think this issue of re-probing the flash is common to all the drivers, and only some driver implements a local probe-once functionality, like in this patch.\n\nThe same issue is with targets, where all the target\u0027s info are re-read at each examine and only some target implements the split pre-examine (read const info) + examine (read runtime status).\n\nMaybe we should think about moving in the framework the handling of calling-once, then left only simpler functions in the driver/target","commit_id":"0348bacf536cb25322b83421f7ac9dad3504c6c5"},{"author":{"_account_id":1000687,"name":"Tomas Vanek","display_name":"Tomas Vanek","email":"vanekt@fbl.cz","username":"vanekt"},"change_message_id":"eef1afaf73a9e1624204781a9273572682c67da3","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"4eee79b1_fd975c6b","in_reply_to":"be9b95e7_48e7ca84","updated":"2024-06-24 05:16:28.000000000","message":"Yes, it\u0027s exactly as you write.\n\nI don\u0027t know why but this flash driver was used by contributors as the base for another flash type slightly more times than usual. I own all NFR5 an NRF91 devices to test. These are two reasons why I decided to implement the \"full\" chip/bank probe logic. At least we have a code we can point a contributor to.\n\nI agree that nowadays most of flash drivers create more than one bank so the flash subsystem will gain from extending to bank/chip model. And the chip related parts could be optional, so the existing drivers will stay compatible.","commit_id":"0348bacf536cb25322b83421f7ac9dad3504c6c5"}]}
