Let's have the initial discussion in this week's meeting to create the context for everyone. Julius, hope you are ok to lead the discussion? We then add it to the agenda for next month's meeting which hopefully provides everyone enough time to look at the details, consult within their organizations and consider the implications for their teams.

Yes, sounds good. I totally understand that there may be practical concerns about this, especially in areas where the existing terminology is well-established. I don't intend to change the whole codebase overnight or stop anyone's productivity dead in their tracks. I just want to get a discussion started about first of all making a decision whether we want this in general, and then trying to identify the best ways to further that goal while keeping practicality in mind.

Ideally, we would also have a summary of the current projects just to understand the amount of updates that may be required.

I grepped a few numbers from TF-A to get started:

- blacklist: 0 - whitelist: 1 - master: 403 - 242 in plat/ - 47 in plat/brcm - 44 in plat/xilinx - 35 in plat/imx - 30 in plat/mediatek - 28 in plat/arm - 41 in docs/ (most of these talking about the Git branch, not master/slave relationships) - 62 in drivers/arm/ccn + includes - 18 in drivers/arm/cci + includes - 17 in drivers/brcm + includes - slave: 246 - 155 in plat/ - 72 in plat/renesas - 18 in plat/mediatek - 15 in plat/xilinx - 14 in plat/nvidia - 14 in plat/rockchip - 27 in drivers/arm/cci + includes - 25 in drivers/mtd/spi_mem + includes - 23 in drivers/renesas/rcar

Note that I don't necessarily expect we'd want to start a huge effort to get all of those cleaned up, especially for old outdated platform ports that understandably nobody wants to invest time in anymore. Hardware support code naturally ages and becomes obsolete over time anyway. I think establishing guidelines for future submissions is much more important in the long run. If we do want to clean up existing code, it would probably be most useful to focus on generic (non-platform) code that can be expected to have a longer lifetime.