Hi Geert > >> > > Required properties: > >> > > -- compatible : "renesas,rcar-thermal" > >> > > +- compatible : "renesas,thermal-<soctype>", "renesas,rcar-thermal" > >> > > + as fallback. > >> > > + Examples with soctypes are: > >> > > + - "renesas,thermal-r8a73a4" (R-Mobile AP6) > >> > > + - "renesas,thermal-r8a7779" (R-Car H1) > >> > > + - "renesas,thermal-r8a7790" (R-Car H2) > >> > > + - "renesas,thermal-r8a7791" (R-Car M2) > >> > > - reg : Address range of the thermal registers. > >> > > The 1st reg will be recognized as common register > >> > > if it has "interrupts". (snip) > One important thing to note in my patch description is "some of which > are already in use.". > > $ git grep renesas,thermal -- arch/arm/boot/ | cat > arch/arm/boot/dts/r8a7790.dtsi: compatible = > "renesas,thermal-r8a7790", "renesas,rcar-thermal"; > arch/arm/boot/dts/r8a7791.dtsi: compatible = > "renesas,thermal-r8a7791", "renesas,rcar-thermal"; > $ > > So these 2 should be added to the documentation for sure. > Adding the 2 others, and adding them to the respective DTSes (cfr. the > other patches in the series) doesn't hurt, and will help if an incompatibility > ever arises. > > (I assume the driver works with the other DTSes that already claim to have > a device compatible with "renesas,rcar-thermal"). I reconsidered about this. Actually, I'm still wondering about this approach because driver side doesn't have SoC specific matching table. Of course SoC-specific name in .compatible can be backup plan for us, but, we don't know it is 100% true. (we might have new driver for some specific SoC, like R-Car DMA driver ?) Adding to SoC specific compatible name in SoC side DTSes are no problem, it can be backup plan. but, we can't say 100% true that <driver>.txt has SoC specific name list. because, driver doesn't care about it today, and we don't know the future But, on the other hand, this kind of update patch can indicate to kernel users that "this driver is under maintenance". # we have many drivers which are not updated. # 50% it is complete driver, 50% it is just non-maintenanced driver So, I can say, Acked-by: Kuninori Morimoto <kuninori.morimoto.gx@xxxxxxxxxxx> I can 100% agree if it is easy to understand that listed specific SoC are just "working", not "formally supported as SoC specific" Best regards --- Kuninori Morimoto -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
