On Thursday, October 27, 2016 6:40:27 PM CEST Imran Khan wrote: > On 10/26/2016 8:16 PM, Arnd Bergmann wrote: > > On Wednesday, October 26, 2016 7:42:08 PM CEST Imran Khan wrote: > >> On 10/26/2016 7:35 PM, Arnd Bergmann wrote: > >>>>> As we are talking about generic soc_device_attribute fields, I was hoping that > >>>>> having a vendor field would be helpful as along with family it would provide > >>>>> a more thorough information. Also as more than one foundries may be used for > >>>>> a soc, can we have a field say foundry_id to provide this information. > >>> My first feeling is that this 'vendor' information can should be > >>> derived from the family. It's also not clear what would happen > >>> to this when a company gets bought. E.g. the Oxnas product family > >>> was subsequently owned by Oxford, PLX, Avago and Broadcom, and the > >>> mxs family was Sigmatel, Freescale, now NXP and might soon be > >>> Qualcomm. What would you put in there in this case? > >> > >> Okay, not having vendor field is fine for me. Could you also suggest > >> something about the foundry_id field. > > > > This one seems more well-defined, so it's probably ok to add. What > > would be the use case of reading this? Would you want to read it > > just from user space or also from the kernel? > > > > As of now the use case I can think of, only involve reading this from user > space. For example for the same soc, coming from different foundries with > different manufacturing process, we may have a situation where some inconsistent > h/w behavior is being observed only on parts received from a certain foundry > and in those cases this information may help in segregation of problematic socs > and may also be used in testing these socs under a different set of settings like > voltage, frequency etc. > > > Maybe this can be combined with a manufacturing process, which probably > > falls into a similar category, so we could have something like > > "TSMC 28ULP" as a string in there. > > > > Yes. Having a manufacturing process as part of foundry-id can provide a more > thorough information. Ok, sounds good. Let's do it like this. We can always add support for in-kernel matching of this string if needed later. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
