All of lore.kernel.org
 help / color / mirror / Atom feed
From: Murali Karicheri <m-karicheri2@ti.com>
To: Arnd Bergmann <arnd@arndb.de>
Cc: <linux-kernel@vger.kernel.org>, <netdev@vger.kernel.org>,
	<davem@davemloft.net>
Subject: Re: [PATCH v2 3/3] net: netcp: rework the code for get/set sw_data in dma desc
Date: Fri, 19 Feb 2016 17:21:57 -0500	[thread overview]
Message-ID: <56C79585.1090905@ti.com> (raw)
In-Reply-To: <3256728.DYdlef6xAF@wuerfel>

On 02/19/2016 03:55 PM, Arnd Bergmann wrote:
> On Friday 19 February 2016 12:58:44 Murali Karicheri wrote:
>> SW data field in descriptor can be used by software to hold private
>> data for the driver. As there are 4 words available for this purpose,
>> use separate macros to place it or retrieve the same to/from
>> descriptors. Also do type cast of data types accordingly.
>>
>> Cc: Wingman Kwok <w-kwok2@ti.com>
>> Cc: Mugunthan V N <mugunthanvnm@ti.com>
>> CC: Arnd Bergmann <arnd@arndb.de>
>> CC: Grygorii Strashko <grygorii.strashko@ti.com>
>> CC: David Laight <David.Laight@ACULAB.COM>
>> Signed-off-by: Murali Karicheri <m-karicheri2@ti.com>
> 
> Looks ok in principle.
> 
> Acked-by: Arnd Bergmann <arnd@arndb.de>
> 
>>  		get_pkt_info(&dma_buf, &tmp, &dma_desc, ndesc);
>> -		get_sw_data((u32 *)&buf_ptr, &buf_len, ndesc);
>> +		/* warning!!!! We are retrieving the virtual ptr in the sw_data
>> +		 * field as a 32bit value. Will not work on 64bit machines
>> +		 */
>> +		buf_ptr = (void *)GET_SW_DATA0(ndesc);
>> +		buf_len = (int)GET_SW_DATA1(desc);
> 
> I would have abstracted the retrieval of a pointer again,
> and added the comment in the helper function once, it doesn't
> really need to be duplicated everywhere.
> 
Arnd,

I thought about it to add it to the API. API currently set buffer
and ptr. It would be an issue only if store/retrieve ptr in/from the sw_data.
So for the comment to be really useful to someone who is changing the code,
doesn't it make sense to add it at the point of invocation as done in this
patch? No?

Murali

> 	Arnd
> 


-- 
Murali Karicheri
Linux Kernel, Keystone

  reply	other threads:[~2016-02-19 22:22 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-02-19 17:58 [PATCH v2 0/3] net: ti: netcp: restore get/set_pad_info() functionality Murali Karicheri
2016-02-19 17:58 ` [PATCH v2 1/3] " Murali Karicheri
2016-02-19 20:56   ` Arnd Bergmann
2016-02-19 17:58 ` [PATCH v2 2/3] soc: ti: knav_dma: rename pad in struct knav_dma_desc to sw_data Murali Karicheri
2016-02-19 20:55   ` Arnd Bergmann
2016-02-19 17:58 ` [PATCH v2 3/3] net: netcp: rework the code for get/set sw_data in dma desc Murali Karicheri
2016-02-19 20:55   ` Arnd Bergmann
2016-02-19 22:21     ` Murali Karicheri [this message]
2016-02-19 22:25       ` Arnd Bergmann
2016-02-22 17:04         ` Murali Karicheri
2016-02-22  3:02 ` [PATCH v2 0/3] net: ti: netcp: restore get/set_pad_info() functionality David Miller

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=56C79585.1090905@ti.com \
    --to=m-karicheri2@ti.com \
    --cc=arnd@arndb.de \
    --cc=davem@davemloft.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.