[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <3c17e3570912090431o4daaab7cwfee25df4cb0774c2@mail.gmail.com>
Date: Wed, 9 Dec 2009 20:31:32 +0800
From: Barry Song <21cnbao@...il.com>
To: Wolfgang Grandegger <wg@...ndegger.com>
Cc: davem@...emloft.net, socketcan-core@...ts.berlios.de,
uclinux-dist-devel@...ckfin.uclinux.org, netdev@...r.kernel.org,
"H.J. Oertel" <oe@...t.de>
Subject: Re: [PATCH v2] add the driver for Analog Devices Blackfin on-chip CAN
controllers
On Wed, Dec 9, 2009 at 6:16 PM, Wolfgang Grandegger <wg@...ndegger.com> wrote:
> Barry Song wrote:
>> Signed-off-by: Barry Song <21cnbao@...il.com>
>> Signed-off-by: H.J. Oertel <oe@...t.de>
>> ---
>> -v2: cleanup according to Wolfgang Grandegger's feedback
>> 1.delete some unnecessary debug print
>> 2.delete ndo_tx_timeout entry as it is not needed in can
>> 3.use alloc_can_skb, alloc_can_err_skb instead of netdev_alloc_skb
>> 4.add timeout while polling can status
>> 5.rename BFIN_CAN_READ/WRITE_MSG to bfin_can_read/write_data
>> 6.use kernel BIT instead of bit shift
>> 7.use void __iomem * for CAN memory base memory instead of u32
>> 8.delete "dev->last_rx = jiffies" since it is not needed now
>> 9.delete redundant "echo_skb" member in bfin can private data
>> 10.follow can convention to use "_" instead of "-" for file names
>
> Did you consider using structs instead of these ugly and cumbersome
> macro functions? This was my major criticisms with your previous version
> of the patch.
Wolfgang,
I considered using the structures to describe registers, and I
completely agree with you about the advantages of structures. And I am
sure I will move to structures after some time and send a patch for
it. But for the moment, it is not too urgent, so I only fixed all your
other comments. Anyway, if you insist on using structures in just this
patch, I can fix and send the -v3 patch after finishing it.
Thanks
Barry
>
> Wolfgang.
>
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists