)]}'
{"src/flash/nor/core.c":[{"author":{"_account_id":1000021,"name":"Antonio Borneo","email":"borneo.antonio@gmail.com","username":"borneoa"},"change_message_id":"2a7dccfb58a0f95441afdf8bf82157cfbd4e27b8","unresolved":true,"context_lines":[{"line_number":224,"context_line":"\t\tif (bank-\u003edriver-\u003efree_driver_priv)"},{"line_number":225,"context_line":"\t\t\tbank-\u003edriver-\u003efree_driver_priv(bank);"},{"line_number":226,"context_line":"\t\telse"},{"line_number":227,"context_line":"\t\t\tdefault_flash_free_driver_priv(bank);"},{"line_number":228,"context_line":""},{"line_number":229,"context_line":"\t\tfree(bank-\u003esectors);"},{"line_number":230,"context_line":"\t\tfree(bank-\u003eprot_blocks);"}],"source_content_type":"text/x-csrc","patch_set":1,"id":"5ba7cc13_1c1b054c","line":227,"updated":"2026-09-08 13:08:48.000000000","message":"While I agree on this patch, I think we should change the logic and say that\n`driver-\u003efree_driver_priv()`\nonly free the eventual extra allocation referenced through pointers in the struct pointed by `bank-\u003edriver_priv`, while the framework always\n`free(bank-\u003edriver_priv)`\nand set it to NULL.\nso the code here should be:\n```\n\t\tif (bank-\u003edriver-\u003efree_driver_priv)\n\t\t\tbank-\u003edriver-\u003efree_driver_priv(bank);\n\n\t\tdefault_flash_free_driver_priv(bank);\n```\nThen all the assignments\n`.free_driver_priv \u003d default_flash_free_driver_priv()`\ncould be dropped and here we could even inline `default_flash_free_driver_priv()` making it disappear.\nBut this cannot be done now because:\n- `efm32_flash_bank_command()` shares the same `driver_priv` among banks!! bad and dangerous!\n- `msp432_flash_bank_command()` allocates `driver_priv` at each bank, but `msp432_flash_free_driver_priv()` only `free(bank-\u003edriver_priv)` on some banks, thus leaking on the other banks\n\nPlus, `sam3_free_driver_priv()`, `sam4_free_driver_priv()`, `kinetis_free_driver_priv()`, `nrf5_free_driver_priv()` and `rsl10_free_driver_priv()` leak `bank-\u003edriver_priv`.\n\nThere is some extra work to do!","commit_id":"3d366d1e941c2c02f47f20c2f8ef34205c95927f"},{"author":{"_account_id":1000687,"name":"Tomas Vanek","display_name":"Tomas Vanek","email":"tomas.vanek.oocd@gmail.com","username":"vanekt"},"change_message_id":"31752b6008e07c968ac3d33a41f07937b520e66d","unresolved":true,"context_lines":[{"line_number":224,"context_line":"\t\tif (bank-\u003edriver-\u003efree_driver_priv)"},{"line_number":225,"context_line":"\t\t\tbank-\u003edriver-\u003efree_driver_priv(bank);"},{"line_number":226,"context_line":"\t\telse"},{"line_number":227,"context_line":"\t\t\tdefault_flash_free_driver_priv(bank);"},{"line_number":228,"context_line":""},{"line_number":229,"context_line":"\t\tfree(bank-\u003esectors);"},{"line_number":230,"context_line":"\t\tfree(bank-\u003eprot_blocks);"}],"source_content_type":"text/x-csrc","patch_set":1,"id":"e6b1aa57_dd150b6c","line":227,"in_reply_to":"5ba7cc13_1c1b054c","updated":"2026-09-08 13:33:03.000000000","message":"It looked as a good idea on the first sight.\nBut the deeper look to kinetis.c explains why not:\nIn the kinetis flash driver driver-\u003epriv points inside the bigger block allocated per chip. I\u0027m sure no memory leaks, k_chip is freed with the last used bank. However if we don\u0027t want to rework the allocation here and in sam3,4, nrf5 and others we should keep the model either free(bank-\u003edriver_priv) or call flash specific destructor, not both.","commit_id":"3d366d1e941c2c02f47f20c2f8ef34205c95927f"},{"author":{"_account_id":1000687,"name":"Tomas Vanek","display_name":"Tomas Vanek","email":"tomas.vanek.oocd@gmail.com","username":"vanekt"},"change_message_id":"209f71d743a90d8130683671ba8922592ca04de3","unresolved":true,"context_lines":[{"line_number":224,"context_line":"\t\tif (bank-\u003edriver-\u003efree_driver_priv)"},{"line_number":225,"context_line":"\t\t\tbank-\u003edriver-\u003efree_driver_priv(bank);"},{"line_number":226,"context_line":"\t\telse"},{"line_number":227,"context_line":"\t\t\tdefault_flash_free_driver_priv(bank);"},{"line_number":228,"context_line":""},{"line_number":229,"context_line":"\t\tfree(bank-\u003esectors);"},{"line_number":230,"context_line":"\t\tfree(bank-\u003eprot_blocks);"}],"source_content_type":"text/x-csrc","patch_set":1,"id":"35b8a1c7_58ce6dc3","line":227,"in_reply_to":"e6b1aa57_dd150b6c","updated":"2026-09-08 14:08:45.000000000","message":"\u003e efm32_flash_bank_command() shares the same driver_priv among banks!! bad and dangerous!\nPer chip driver_priv allocation, deallocates when refcount is zero. IMO useful and safe.\n\n\u003e msp432_flash_bank_command() allocates driver_priv at each bank, but msp432_flash_free_driver_priv() only free(bank-\u003edriver_priv) on some banks, thus leaking on the other banks\nNot the best code. The secondary bank is created in the probe and shares driver_priv with the primary one. IMO no leaks.\n\nAntonio, there are many reasons for per chip structures. Long time ago I proposed to add some specialised support for it in the flash infrastructure but Andreas Fritiofson refused it saying that one pointer is enough for everything. Well it\u0027s true, but here you see the result of letting contributors to invent the wheel again and again.","commit_id":"3d366d1e941c2c02f47f20c2f8ef34205c95927f"}]}