On Wednesday 02 November 2016, Imran Khan wrote: > On 10/27/2016 7:11 PM, Arnd Bergmann wrote: > > 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: > >> > >> 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. > > > > Thanks for the feedback. So how should I proceed now, should I > > i. send one patch first that adds the serial_number and foundry_id fields > in generic soc_dev_attribute structure and then send my modified socinfo > driver as per new soc_dev_attribute structure > > or > > ii. send both the changes as 2 separate patches of the same patch set. > > or > > iii. Continue with the current soc_dev_attribute structure and modify > the socinfo driver once soc_dev_attribute structure has serial_number > and foundry_id fields. It's not overly important, but I'd prefer the third approach, the advantage being that we can review the driver and merge it independently of any possible further discussion on the added attributes. Sending this as a series of three patches (1. add the driver, 2. add the infrastructure, 3. use the infrastructure in your driver) is probably best. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-soc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
