From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Authentication-Results: lists.ozlabs.org; spf=none (mailfrom) smtp.mailfrom=linux.intel.com (client-ip=134.134.136.31; helo=mga06.intel.com; envelope-from=jae.hyun.yoo@linux.intel.com; receiver=) Authentication-Results: lists.ozlabs.org; dmarc=none (p=none dis=none) header.from=linux.intel.com Received: from mga06.intel.com (mga06.intel.com [134.134.136.31]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 43mSmv64PszDqPm for ; Sat, 26 Jan 2019 05:51:58 +1100 (AEDT) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga003.jf.intel.com ([10.7.209.27]) by orsmga104.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 25 Jan 2019 10:51:54 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.56,522,1539673200"; d="scan'208";a="121340175" Received: from yoojae-mobl1.amr.corp.intel.com (HELO [10.7.153.143]) ([10.7.153.143]) by orsmga003.jf.intel.com with ESMTP; 25 Jan 2019 10:51:55 -0800 Subject: Re: [PATCH v10 03/12] peci: Add support for PECI bus driver core To: Greg Kroah-Hartman Cc: Lee Jones , Rob Herring , Jean Delvare , Guenter Roeck , Mark Rutland , Joel Stanley , Andrew Jeffery , Jonathan Corbet , Gustavo Pimentel , Kishon Vijay Abraham I , Lorenzo Pieralisi , "Darrick J . Wong" , Eric Sandeen , Arnd Bergmann , Wu Hao , Tomohiro Kusumi , "Bryant G . Ly" , Frederic Barrat , "David S . Miller" , Mauro Carvalho Chehab , Andrew Morton , Randy Dunlap , Philippe Ombredanne , Vinod Koul , Stephen Boyd , David Kershner , Uwe Kleine-Konig , Sagar Dharia , Johan Hovold , Thomas Gleixner , Juergen Gross , Cyrille Pitchen , linux-hwmon@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org, openbmc@lists.ozlabs.org, Gavin Schenk , Viresh Kumar , Cyrille Pitchen , Alan Cox , Andrew Lunn , Andy Shevchenko , Benjamin Herrenschmidt , Fengguang Wu , Jason M Biils , Julia Cartwright , Haiyue Wang , James Feist , Vernon Mauery References: <20190107214136.5256-1-jae.hyun.yoo@linux.intel.com> <20190107214136.5256-4-jae.hyun.yoo@linux.intel.com> <20190122132047.GA12357@kroah.com> <0826ef5c-c919-cdd7-5e2a-fc056d41756e@linux.intel.com> <20190124065714.GA28194@kroah.com> <20190125071823.GC11891@kroah.com> From: Jae Hyun Yoo Message-ID: <22d2e334-b792-1047-87fb-abce2ea87e2a@linux.intel.com> Date: Fri, 25 Jan 2019 10:51:54 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.3.3 MIME-Version: 1.0 In-Reply-To: <20190125071823.GC11891@kroah.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 29 Jan 2019 14:11:08 +1100 X-BeenThere: openbmc@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Development list for OpenBMC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jan 2019 18:52:00 -0000 Hi Greg, On 1/24/2019 11:18 PM, Greg Kroah-Hartman wrote: > On Thu, Jan 24, 2019 at 02:01:10PM -0800, Jae Hyun Yoo wrote: >> On 1/23/2019 10:57 PM, Greg Kroah-Hartman wrote: >>> On Wed, Jan 23, 2019 at 01:38:24PM -0800, Jae Hyun Yoo wrote: >>>>> What about the un-initialized fields in this structure? Can you >>>>> properly handle that, and also, is this ok to be on the stack? >>>> >>>> It's fully initialized at here because the peci_ping_msg struct has only >>>> one member: >>>> >>>> struct peci_ping_msg { >>>> __u8 addr; >>>> }; >>> >>> Ok. But my question about "can you do this off the stack" remains. >> >> I'll add 3 bytes of dummy padding into this structure. Also, I'll check >> again u32 boundary alignment for all struct defines in peci_ioctl.h. >> Would it be okay to be on stack then? > > The issue of being on the stack has nothing to do with alignment, and > everything to do with, "can your controller handle data from the stack". > Lots of busses and controllers can not (i.e. all USB devices), so you > have to properly allocate all memory that is used for data transfers > from areas that are able to do DMA properly (i.e. by using kmalloc). > > That is why I asked here about that, if this is a USB driver, having the > data you wish to send from a stack variable is not allowed. I don't > know how your hardware works, which is why I was asking this. > > Note, some architectures (like x86), hide this fact as their stack > memory is able to be DMA, so you do not run into any errors. Other > arches that Linux supports are not like that, which is why we have those > types of restrictions. Thanks for your detailed explanation. In this core driver, all PECI command messages will be translated into the raw PECI message structure (peci_xfer_msg) and it is the actual data which will be delivered to an adapter driver through adapter->xfer(). I'll fix the translation logic to use heap instead of stack for handling the peci_xfer_msg structure. Thanks, Jae