From mboxrd@z Thu Jan 1 00:00:00 1970 From: Bjorn Andersson Subject: Re: [PATCH 1/2] drivers: qcom: add command DB driver Date: Wed, 7 Feb 2018 09:00:28 -0800 Message-ID: <20180207170028.GQ9465@builder> References: <20180118220833.16616-1-ilina@codeaurora.org> <20180118220833.16616-2-ilina@codeaurora.org> <20180125204613.GW28313@codeaurora.org> <20180207164719.GA16153@codeaurora.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Received: from mail-pl0-f65.google.com ([209.85.160.65]:44617 "EHLO mail-pl0-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754392AbeBGRAc (ORCPT ); Wed, 7 Feb 2018 12:00:32 -0500 Received: by mail-pl0-f65.google.com with SMTP id f8-v6so373012plk.11 for ; Wed, 07 Feb 2018 09:00:31 -0800 (PST) Content-Disposition: inline In-Reply-To: <20180207164719.GA16153@codeaurora.org> Sender: linux-arm-msm-owner@vger.kernel.org List-Id: linux-arm-msm@vger.kernel.org To: Lina Iyer Cc: Stephen Boyd , andy.gross@linaro.org, david.brown@linaro.org, rnayak@codeaurora.org, linux-arm-msm@vger.kernel.org, linux-soc@vger.kernel.org, msivasub@codeaurora.org On Wed 07 Feb 08:47 PST 2018, Lina Iyer wrote: > On Thu, Jan 25 2018 at 20:46 +0000, Stephen Boyd wrote: > > On 01/18, Lina Iyer wrote: > > > diff --git a/drivers/soc/qcom/Kconfig b/drivers/soc/qcom/Kconfig [..] > > > +struct entry_header { > > > + uint64_t res_id; > > > + u32 priority[NUM_PRIORITY]; > > > + u32 addr; > > > + u16 len; > > > + u16 offset; > > > > Are these little endian? Needs to be __le16 and __le32 then. > > > Not a device memory. Forgot to mention this based on your other answer, but as this is not device memory you should remove the __iomem specifier and use memremap() instead of ioremap(). > Do we need to worry about endianness? > We have done that in many of the other core drivers, I do however suspect that Stephen was the only one who ever booted the kernel in this mode. [..] > > Hopefully we never have more than one commmand db? Do consumers > > "just know" to use this code? I haven't looked at the DT binding, > > but perhaps consumers need to point to command db via DT phandles > > so we can identify the consumers. That may make probe defer > > easier too. > > > There would be just one command DB for an SoC. Currently, none of the > the clients need to probe at the time of command DB. > > The producer-consumer model might help, but it is probably not needed > here. > I think it's fine to not describe this relationship in DT. We can use probe deferral without it. [..] > > > + ch[i] = id[i]; > > > > Is this a strcpy? > > > In a way yes. > I think we should use 64-bit constants throughout the kernel instead of using strings that gets converted here... Regards, Bjorn