Hi Magnus > The problem is that "gen2" is not something that is pre-defined. As > you may have noticed earlier, new SoCs keep on coming and even though > they may be part of "gen2" they may or may not be compatible with the > "gen2" compatible string. So based on that, if we use the SoC part > number in the compatible string we at least know what the support > status is. Do you mean "driver" table ? This patch doesn't remove SoC level compatible from driver. And additionally, we can check support status in Document/devicetree/...txt and Geert is doing it now ? (Which SoC is working/supporting) > So I agree that sharing hardware makes sense from a resource saving > point of view. However in reality there may be smaller differences > between devices used for each version within the generation though. Yes, "maybe" it has smaller difference, but what is the problem ? Driver is already have SoC level compatible. Why we can't update it ? Or, "maybe" we can add new property for it ? It can keep compatible anyway, because current code is already working. In my opinion, we can use SoC level compatible name if it was special, otherwise, we can use generation level compatible. Platform side DTS file should include SoC and generation level compatible from first support patch. If possible, series compatible too. like this compatible = "renesas,i2c-r8a7790", "renesas,i2c-rcar-gen2", "renesas,i2c-rcar" But, it is too late for Gen1/Gen2. I don't want to have more pointless string in driver in Gen3 or later. But yes, we want to know which SoC is supported. We can use Document/devicetree/...txt for this purpose Best regards --- Kuninori Morimoto -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
