On 2015년 09월 04일 00:47, Greg KH wrote:
On Thu, Sep 03, 2015 at 04:00:08PM +0900, johnny.kim wrote:
Hello Greg.
On 2015년 09월 03일 10:33, Greg KH wrote:
On Thu, Aug 20, 2015 at 04:32:52PM +0900, Tony Cho wrote:
From: Johnny Kim <johnny....@atmel.com>
The driver communicates with the chipset via the address of handlers
to distinguish async data frame. The SendConfigPkt function gets the
pointer address indicating the handlers as the last argument, but this
requires redundant typecasting and does not support the 64 bit machine.
This patch adds the function which assigns ID values instead of pointer
representing the driver handler to the address and then uses the ID
instead of pointer as the last argument of SendConfigPkt. The driver
also gets the handler's address from the ID in the data frame when it
receives them.
I don't understand this code at all. You are randomly adding values to
a list, and then assuming that you can use the index into that list for
some type of representation? As this is a local list, why not just use
the real variables instead of having a list and dealing with them in
this very ackward manner?
In other words, I don't see the need for the list at all, just use the
real types here, you have all the needed information (hint, if you know
the index, you really know the data as well...)
The value is needed to send it to chipset and to distinguish async data
packet mutually.
What is the value, the index or some random pointer?
The value of current patch substitutes the corresponding index for
some random pointer(= address of device handler).
The length of the data field is 4byte and the data field has been
filled with the address of pointer so far.
So the data field can just be any random number, as long as it is
consistent? What does the chip do with the random number?
Current driver normally create a couple of network interface.
The driver can send some commands(data frame) to the network
interfaces at the same time and wait the results. Both driver and
chipset need unique value to distinguish whom the interface owner
of the commands is.
And the value always has same value while the interface is alive.
But this patch changes it to unique index value corresponding to the address
for 64bit address machine. If real type is used as your opinion, new patch
will have the same meaning with current code.
I'm sorry, but I don't understand. How exactly does the chip need an
index now, but was using a pointer before? That sounds like you are
changing the functionality.
confused,
There is a reserved field to distinguish the data frames in chipset.
Because the field has 4byte space, this patch creates the index
corresponding to the pointer and uses the index to input the identifier
in the size instead of the pointer value.
I'm sorry, too. It's not easy to explain it in English.
Thanks.
Johnny.
_______________________________________________
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
