dm: Move towards completing CONFIG_BLK migration
Get series with b4
b4 am [email protected]Versions newest first
- v1 Latest6 of 93 patches 0 repliesNew
6 of 93 patches are in this archive. The cover letter announces 93.
Patches in v1 No applies recorded yet
| # | Subject and files | Size | Replies | Applied |
|---|---|---|---|---|
| 7/93 | arm: Remove colibri_imx6_nospl board | +0 | 0 replies | |
| 20/93 | arm: Remove cm_t43 board | +0 | 0 replies | |
| 30/93 | arm: Remove apalis_imx6_nospl_it board | +0 | 0 replies | |
| 31/93 | arm: Remove wandboard board | +0 | 0 replies | |
| 81/93 | arm: Remove socfpga_dbm_soc1 board | +0 | 0 replies | |
| 89/93 | arm: Remove socfpga_vining_fpga board | +0 | 0 replies |
Reviews trailers per patch
No Reviewed-by, Acked-by or Tested-by trailers for v1 yet.
Cover letter [U-Boot] [PATCH 00/93] dm: Move towards completing CONFIG_BLK migration
Quoted 36 lines · Adam Ford
Quoted 23 lines · Tom Rini
Quoted 19 lines · Simon Glass
All boards should now be migrated to use
CONFIG_BLK. This series removes those with build problems using this option.If maintainers want to keep these boards in they should send a patch in the next week or two. Otherwise the board will be removed in the next release, and will need to be added and re-reviewed later.
The goal is to have all boards use driver model. But so far, we do allow
CONFIG_DMto not be defined.PLEASE NOTE: This is not an easy process. It is possible that your board does work, or works with only minor changes. Please try to understand that the removal of a board is not done because people don't like your board. In fact the board might have been the first one I used when trying out U-Boot! It's just that we expect maintainers to keep up with the migration to driver model which has been running now for 4 years. It just isn't possible for a few people to migrate and test hundreds of boards.
Quoted 1 line
So, send a patch!
Quoted 11 lines
OK, so with the intention of "need to light a fire", consider the fire lit! But, I think v2 of this series needs to:
- Address the bug that's been noted of you checking on "DM_BLK" when it's really just "BLK".
- Do a test build with BLK just being unconditional now. For example, you're deleting theam335x_evmfamily but it builds fine with BLK being enabled now. I even gave it a run time test viatest.pyand we're fine. So, I think a new run where you see what fails to build with BLK enabled by default now is in order to come up with a new delete list.
Quoted 7 lines
When we were migrating toward GCC 6, we introduced a warning message that was displayed at build indicating older versions of GCC would be unsupported, and GCC 6 would become a requirement. The
CONFIG_DM_I2C_COMPATgenerates a build warning and suggests that it be removed. I would like to propose that in the future, when setting deadlines, we insert something into the build mechanism that generates a warning to tell people that something is going to happen.
I agree, that sounds good.
I am extremely unhappy by how Simon decided, unilaterally, some arbitrary deadline, told pretty much no one about that deadline and then put a knife on many peoples' throats by sending out this series which removes boards that are actively used and maintained, demanding they be converted right this instant.
In my opinion, most maintainers cannot just drop everything they are working on at any given point and start doing random conversion the minute Simon decides they should. The only result of such behavior will be loss of functionality and more stress exerted on the maintainers, which helps no one.
While I understand the need to move over to CONFIG_DM_BLK, U-Boot is a cooperative project and it can only move forward as fast as the community around it can. If anyone within that community wants to convert others to some new feature, that's perfectly fine, but there should be a clear way to do it and a possibility to shift a deadline for conversion around for boards which are useful to people and simply late. Just dropping useful functionality is not acceptable.
Signature · 2 lines
Best regards, Marek Vasut