On Thu, Jul 07, 2016 at 10:46:28AM +0200, Arnd Bergmann wrote: > On Wednesday, July 6, 2016 9:19:41 PM CEST Arend Van Spriel wrote: > > On 6-7-2016 15:42, Arnd Bergmann wrote: > > > On Wednesday, July 6, 2016 10:08:55 AM CEST Arend Van Spriel wrote: > > >> On Tue, Jul 5, 2016 at 3:43 PM, Arnd Bergmann <arnd@xxxxxxxx> wrote: > > > All existing uses of the model property in arch/arm/boot/dts and most of > > > the ones in arch/powerpc/boot/dts are against the intended usage in > > > one way or another, but adding different kind of incorrect usage won't > > > improve that. > > > > > > The only way I can see the model property being used correctly would > > > be to have it match the first entry in the compatible property, but > > > that is completely redundant, so we tend to omit it, except for the > > > root node in which it is required. For the root node however, the > > > historic practice that has crept in on ARM is to put something completely > > > different in there, which is a human-readable description of the > > > machine rather than something we can use as a unique indentifier. > > > > > > I'd just consider the "model" property burned, and not use it for anything > > > that doesn't already use it, just like we handle "device_type": a few > > > things require it, nothing else should use it. > > > > If that is the agreed approach in devicetree arena I am fine with it. I > > have been unaware of this and just looked at the suggestion from Jonas > > seeing a solution to the problem at hand. > > I don't think it has been discussed or decided before as the question > has not come up, so for now this is my personal view. Maybe one of > the devicetree maintainers can comment on this. Back from vacation and getting caught up. I agree with Arnd here. In my view model is the OEM branding on the device, compatible is the h/w. If you have different firmware related files, that goes beyond OEM branding. Rob -- 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