linux-kernel - RE: [PATCH] net: ti: netcp: restore get/set_pad

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:	Tue, 9 Feb 2016 16:55:42 +0000
From:	"Karicheri, Muralidharan" <m-karicheri2@...com>
To:	David Laight <David.Laight@...LAB.COM>,
	"Strashko, Grygorii" <grygorii.strashko@...com>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"David S . Miller" <davem@...emloft.net>,
	"Arnd Bergmann" <arnd@...db.de>
CC:	"Cooper Jr., Franklin" <fcooper@...com>,
	"Nori, Sekhar" <nsekhar@...com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"Kwok, WingMan" <w-kwok2@...com>,
	"N, Mugunthan V" <mugunthanvnm@...com>
Subject: RE: [PATCH] net: ti: netcp: restore get/set_pad_info() functionality

>-----Original Message-----
>From: David Laight [mailto:David.Laight@...LAB.COM]
>Sent: Tuesday, February 09, 2016 11:38 AM
>To: Karicheri, Muralidharan; Strashko, Grygorii; netdev@...r.kernel.org; David S . Miller;
>Arnd Bergmann
>Cc: Cooper Jr., Franklin; Nori, Sekhar; linux-kernel@...r.kernel.org; Kwok, WingMan; N,
>Mugunthan V
>Subject: RE: [PATCH] net: ti: netcp: restore get/set_pad_info() functionality
>
>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.

The descriptors are usable by different drivers, one driver may use it as 
buf ptr/ len, other for something else. So they should remain as generic
and it is up to individual drivers to use it in whatever way it requires.
My suggestion is to rename pad field in struct knav_dma_desc to sw_data
to avoid confusion. i.e 

+       __le32  pad[4];

to 

+       __le32  sw_data[4];

Murali
>
>	David