On Tue, Feb 25, 2014 at 02:45:53PM +, Alan Cox wrote:
On Mon, 2014-02-24 at 16:54 -0800, Greg Kroah-Hartman wrote:
On Sat, Feb 22, 2014 at 12:33:36PM +0800, Zhao, Gang wrote:
On Fri, 2014-02-21 at 20:35:50 +0800, Dan Carpenter wrote:
On Fri, Feb 21, 2014 at 08:22:21PM +0800, Zhao,
On Mon, 2014-02-24 at 16:54 -0800, Greg Kroah-Hartman wrote:
On Sat, Feb 22, 2014 at 12:33:36PM +0800, Zhao, Gang wrote:
On Fri, 2014-02-21 at 20:35:50 +0800, Dan Carpenter wrote:
On Fri, Feb 21, 2014 at 08:22:21PM +0800, Zhao, Gang wrote:
If we add your patch and the reviewer does a
On Sat, Feb 22, 2014 at 12:33:36PM +0800, Zhao, Gang wrote:
On Fri, 2014-02-21 at 20:35:50 +0800, Dan Carpenter wrote:
On Fri, Feb 21, 2014 at 08:22:21PM +0800, Zhao, Gang wrote:
If we add your patch and the reviewer does a search for fb[0] then it is
confusing what the right thing to do
On Fri, 2014-02-21 at 15:38:56 +0800, Dan Carpenter wrote:
I don't think this is the right thing because it is needless code.
Overall it doesn't really simplify anything.
You are worried that reviewers will be confused and think there is a
leak in et131x_rx_dma_memory_alloc() and then add a
On Fri, 2014-02-21 at 20:35:50 +0800, Dan Carpenter wrote:
On Fri, Feb 21, 2014 at 08:22:21PM +0800, Zhao, Gang wrote:
If we add your patch and the reviewer does a search for fb[0] then it is
confusing what the right thing to do is.
My fault. I should remove that two lines of code in
The original code relies on the caller to deal with fail in the
middle memory allocation failure in et131x_rx_dma_memory_alloc(). The
relying on the caller to handle this memory allocation failure could
cause some inconveniences:
Code reviewer has to check the caller of this function to make sure
I don't think this is the right thing because it is needless code.
Overall it doesn't really simplify anything.
You are worried that reviewers will be confused and think there is a
leak in et131x_rx_dma_memory_alloc() and then add a kfree() which breaks
the code. I think you are right that a
