Source file re-arrangement for better separation of MCU types #12268
Conversation
- Move STM32 specific files to drivers/stm32
|
Do you want to test this code? Here you have an automated build: |
blckmn
changed the title
|
I am of two minds... should we split the directories into stm32F4, f7, h7 etc or simply at32 and stm32. I am inclined to go with the latter on the grounds there will be many more processors. We can always /drivers/stm32/f4/xx should the need arise. |
|
AUTOMERGE: (FAIL)
|
|
guys, can we prioritise some of the older PR's, such as #11825, that didn't make it into 4.4 prior to reorganization changes such as this so that I and devs with other PR's don't have to continually rebase? Continually rebasing is extremely inefficient, IMHO devs should either be working to get thier PR's in shape ready for merge or helping others do likewise before embarking on changes such as the one in this PR. I feel a little bit more thought in planning the order of merges is required. Also, this PR was created and merged really quickly and there's usually at least 24 hours before things are merged. |
| drivers/stm32/memprot_hal.c \ | ||
| drivers/stm32/memprot_stm32h7xx.c \ | ||
| drivers/stm32/sdio_h7xx.c \ | ||
| drivers/stm32/bus_quadspi_hal.c \ |
There was a problem hiding this comment.
duplication of line 291, included twice.
|
would suggest re-ordering all the source files in alphabetical order in each of the |
|
I see my comments above were addressed in #12282 - thanks. |
…ight#12268) Source file re-arrangement for better spearation of MCU types - Move STM32 specific files to drivers/stm32
First of many PRs separating STM32 code from the main code base (so that we can introduce more MCUs in the future more easily).