Re: [PATCH] PXA27x UDC driver.

!MAILaRCHIVE_VOTE_RePLACE
Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]
To: Rodolfo Giometti <giometti@...>
Cc: David Brownell <david-b@...>, <linux-usb-devel@...>, <linux-arm-kernel@...>, <linux-kernel@...>, Li Yang-r58472 <LeoLi@...>
Date: Thursday, June 28, 2007 - 5:29 pm

On Thu, 28 Jun 2007 16:12:07 +0200
Rodolfo Giometti <giometti@enneenne.com> wrote:


Please feed it through the current version of scripts/checkpatch.pl and
think about fixing the large amount of trivia spew which ensues.


This looks odd.  The same driver presents itself under a different name
according to a config option?


Why?  -DDEBUG is normally provided on the command line.  If the user _did_
go and set DEBUG, he presumably wants DEBUG.


So DMA is busted?


enabling DISABLE_TEST_MODE seens to enable test mode.  Confused.


gag, this looks like a mess.  Thise sort of logic should be implemented in
Kconfig, not in .c.


Unneeded initialisation (checkpatch should catch this)

Use u16, not ushort.  Or just "int".


kernel comments normally look like

/*
 * endpoint related parts of the api to the usb controller hardware,
 * used by gadget driver; and the inner talker-to-hardware core.
 *
 */


We'd normally put braces around the "if" clause if there are braces around
the "else" clause.  What you have there looks a bit funny.


Ditto


We'd normally lay this out as

	if (ep->ep_type != USB_ENDPOINT_XFER_BULK &&
	    desc->bmAttributes != USB_ENDPOINT_XFER_INT) {

but what you have there is pretty common.


that expression is quite hard to read.

	/* hardware _could_ do smaller, but driver doesn't */
	if ((desc->bmAttributes == USB_ENDPOINT_XFER_BULK &&
		le16_to_cpu(desc->wMaxPacketSize) != BULK_FIFO_SIZE) ||
	    !desc->wMaxPacketSize) {

or something like that?


use kzalloc()


Please review Documentation/volatile-considered-harmful.txt


this looks fishy.  local_irq_disable() only provides cpu-local protection. 
Is this code SMP-correct?  What's happening here?  A comment is needed
explaining this, at least.


There's no point in inlining this.  With only one callsite the compiler
will inline it anyway.  If we grow a second callsite, this fucntion is too
large to inline.

This is general truth, so please generally avoid inline.


Use min_t, not an open-coded cast.

Use u16.


/proc is for process-related things.  Driver-related things go in /sys


Please only use macros when you *must* use macros.  When for some reason
you cannot use C.  This is not such a case.  IOW, convert to static
inlines.


We normally indent labels with zero or one spaces, not six.


We normally leave zero blank lines between the } and the EXPORT_SYMBOL
(checkpatch should report this)


hm, OK, I guess this is somewhere where a macro is appropriate.


Probably too big to inline.

Has no callers.


what's that label doing all the way over there.  It makes it rather hard to
find.


Burying returns deep inside large functions is unpopular: it can easily
lead to resource leaks and locking errors as the code evolves.  It makes
review and auditing harder.


unneeded braces


whitespace broke


whitespace


more volatiles


#define INT_FIFO_SIZE	8U

would be nicer.


write it in C or, better, just open-code it at the callsite.


See, this references "n"


but this doesn't.  So we risk getting unused-var warnings in callers
depending upon config options.  Writing this in C rather than cpp (the
general rule) will fix this, as well as lots of other stuff.

HEX_DISPLAY2 gets different treatment from HEX_DISPLAY here.


eep, you can't do that!  We'll get separate instances of the_controller in
each C file which includes this header.


Use __maybe_unused


ditto


ditto


hrm.  Why does every driver in the tree need to invent its own boilerplate
infrastructure?

can we use dev_warn() here or something?


-
Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]

Messages in current thread:
[PATCH] PXA27x UDC driver., Rodolfo Giometti, (Thu Jun 28, 6:36 am)
Re: [PATCH] PXA27x UDC driver., Russell King - ARM Linux, (Sun Jul 1, 11:00 am)
Re: [PATCH] PXA27x UDC driver., David Brownell, (Sun Jul 1, 1:49 pm)
Re: [PATCH] PXA27x UDC driver., Lennert Buytenhek, (Sun Jul 1, 10:55 am)
Re: [PATCH] PXA27x UDC driver., Andy Isaacson, (Fri Jun 29, 1:04 pm)
RE: [PATCH] PXA27x UDC driver., Li Yang-r58472, (Thu Jun 28, 7:15 am)
Re: [PATCH] PXA27x UDC driver., Rodolfo Giometti, (Thu Jun 28, 10:12 am)
Re: [PATCH] PXA27x UDC driver., David Brownell, (Thu Jun 28, 5:53 pm)
Re: [linux-usb-devel] [PATCH] PXA27x UDC driver., Dmitry Krivoschekov, (Fri Jun 29, 5:03 am)
Re: [linux-usb-devel] [PATCH] PXA27x UDC driver., David Brownell, (Sat Jun 30, 9:46 am)
Re: [linux-usb-devel] [PATCH] PXA27x UDC driver., Rodolfo Giometti, (Mon Jul 9, 9:51 am)
Re: [linux-usb-devel] [PATCH] PXA27x UDC driver., David Brownell, (Tue Jul 10, 2:16 pm)
Re: [linux-usb-devel] [PATCH] PXA27x UDC driver., Vernon Sauder, (Tue Jul 10, 10:50 am)
Re: [linux-usb-devel] [PATCH] PXA27x UDC driver., Dmitry Krivoschekov, (Mon Jul 2, 7:42 am)
Re: [PATCH] PXA27x UDC driver., Rodolfo Giometti, (Fri Jun 29, 4:58 am)
Re: [PATCH] PXA27x UDC driver., David Brownell, (Sat Jun 30, 10:25 am)
Re: [linux-usb-devel] [PATCH] PXA27x UDC driver., Dmitry Krivoschekov, (Fri Jun 29, 5:33 am)
Re: [PATCH] PXA27x UDC driver., Andrew Morton, (Thu Jun 28, 5:29 pm)
Re: [PATCH] PXA27x UDC driver., Rodolfo Giometti, (Tue Jul 10, 11:49 am)
Re: [PATCH] PXA27x UDC driver., Lothar Wassmann, (Tue Jul 10, 12:16 pm)
Re: [linux-usb-devel] [PATCH] PXA27x UDC driver., David Brownell, (Sat Jun 30, 10:28 am)
Re: [PATCH] PXA27x UDC driver., David Brownell, (Thu Jun 28, 6:44 pm)