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
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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