Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755095AbcLTWuL (ORCPT ); Tue, 20 Dec 2016 17:50:11 -0500 Received: from smtp.codeaurora.org ([198.145.29.96]:33642 "EHLO smtp.codeaurora.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750892AbcLTWuJ (ORCPT ); Tue, 20 Dec 2016 17:50:09 -0500 DMARC-Filter: OpenDMARC Filter v1.3.1 smtp.codeaurora.org AC66F61567 Authentication-Results: pdx-caf-mail.web.codeaurora.org; dmarc=none header.from=codeaurora.org Authentication-Results: pdx-caf-mail.web.codeaurora.org; spf=pass smtp.mailfrom=sboyd@codeaurora.org Date: Tue, 20 Dec 2016 14:50:07 -0800 From: Stephen Boyd To: Imran Khan Cc: andy.gross@linaro.org, lee.jones@linaro.org, David Brown , linux-kernel@vger.kernel.org, linux-arm-msm@vger.kernel.org, linux-soc@vger.kernel.org Subject: Re: [PATCH v6] soc: qcom: Add SoC info driver Message-ID: <20161220225007.GD5423@codeaurora.org> References: <1481555889-29380-1-git-send-email-kimran@codeaurora.org> <20161214002617.GS5423@codeaurora.org> <20161217012615.GV5423@codeaurora.org> <05cdb699-6406-cff8-cce6-fcedf6ac6c4e@codeaurora.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <05cdb699-6406-cff8-cce6-fcedf6ac6c4e@codeaurora.org> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1037 Lines: 24 On 12/18, Imran Khan wrote: > > I had discussed this with Bjorn and it was recommended to keep it out of > smem.h. If needed I can move it back there. Ok no worries from me then if this has already been discussed. > > Yes. The numbers used here can have different meaning for different ODMs. > But these attributes (hw_patform type/subtype etc.) are outside the > generic soc_device_attribute so I think the interpretation of these numbers > can very well be ODM specific. We can try to keep only those types here that > are relevant for newer platforms but we intend to keep these attributes > nonetheless. I'll wait to see what the next patch version has. We will probably need to have some way to know which ODM the kernel is running on, so we can interpret the platform type/subtype fields properly. That part seems to be lacking from this patch right now. We assume it's always qcom as the ODM, which isn't true. -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project