From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932784AbcBIQk2 (ORCPT ); Tue, 9 Feb 2016 11:40:28 -0500 Received: from smtp-out6.electric.net ([192.162.217.184]:53500 "EHLO smtp-out6.electric.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932197AbcBIQk0 convert rfc822-to-8bit (ORCPT ); Tue, 9 Feb 2016 11:40:26 -0500 From: David Laight To: "'Karicheri, Muralidharan'" , "Strashko, Grygorii" , "netdev@vger.kernel.org" , "David S . Miller" , "Arnd Bergmann" CC: "Cooper Jr., Franklin" , "Nori, Sekhar" , "linux-kernel@vger.kernel.org" , "Kwok, WingMan" , "N, Mugunthan V" Subject: RE: [PATCH] net: ti: netcp: restore get/set_pad_info() functionality Thread-Topic: [PATCH] net: ti: netcp: restore get/set_pad_info() functionality Thread-Index: AQHRY0GgM/S/JgIrAEmSoNJDdoEqe58jvybQgAAi94D///+m0IAAAviAgAADyqA= Date: Tue, 9 Feb 2016 16:37:43 +0000 Message-ID: <063D6719AE5E284EB5DD2968C1650D6D1CCDC216@AcuExch.aculab.com> References: <1455026303-17014-1-git-send-email-grygorii.strashko@ti.com> <063D6719AE5E284EB5DD2968C1650D6D1CCDBFCC@AcuExch.aculab.com> <3E54258959B69E4282D79E01AB1F32B704D12AF4@DFLE11.ent.ti.com> <063D6719AE5E284EB5DD2968C1650D6D1CCDC14B@AcuExch.aculab.com> <3E54258959B69E4282D79E01AB1F32B704D12B40@DFLE11.ent.ti.com> In-Reply-To: <3E54258959B69E4282D79E01AB1F32B704D12B40@DFLE11.ent.ti.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.202.99.200] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 X-Outbound-IP: 213.249.233.130 X-Env-From: David.Laight@ACULAB.COM X-PolicySMART: 3396946, 3397078 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Karicheri, Muralidharan > Sent: 09 February 2016 16:19 > >... > >> >In reality the 'pad' fields ought to be renamed - since they aren't pads. > >> >Perhaps they should be a union? > > > >> No. At the end of the descriptor, host software can add scratchpad > >> which is not modified by the hardware, but is used by the driver. So > >> please don't rename. > > > >So comment in the definition that the hardware doesn't modify them. > >The driver is defining these fields and they are definitely NOT padding. > > > It is scratch pad, not padding. Looks like pad is a confusing name. Can be > renamed to sw_data to be in sync with spec below. > > The hardware spec from > http://www.ti.com/lit/ug/sprugr9h/sprugr9h.pdf > > The other SW data portion of the descriptor exists after all of the defined > words and is reserved for use by the host software to store completely > private data. This region is not used in any way by the DMA or queue manager > modules in a Multicore Navigator system and these modules will not modify > any bytes within this region. Right, so comment that the hardware doesn't look at the fields. But name/type the structure fields to indicate what they contain. Maybe sw_buf_len etc - but I suspect there are much more meaningful names. David