lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Wed, 2 Nov 2016 14:11:52 +0100 From: Arnd Bergmann <arnd@...db.de> To: Imran Khan <kimran@...eaurora.org> Cc: andy.gross@...aro.org, David Brown <david.brown@...aro.org>, Rob Herring <robh+dt@...nel.org>, Mark Rutland <mark.rutland@....com>, "open list:ARM/QUALCOMM SUPPORT" <linux-arm-msm@...r.kernel.org>, "open list:ARM/QUALCOMM SUPPORT" <linux-soc@...r.kernel.org>, "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" <devicetree@...r.kernel.org>, open list <linux-kernel@...r.kernel.org> Subject: Re: [PATCH] soc: qcom: Add SoC info driver 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
Powered by blists - more mailing lists