On Wed, Apr 07, 2004 at 10:46:10AM -0700, David Brownell wrote:
>
> >>and move that to the end of ohci.h? Also: the comments assuming PCI
> >>should go; so should the dbg() macros (use pr_debug or ohci_dbg);
> >>didn't apply on 2.6.5-mm.
> >
> >
> >This doesn't make sense to me. Can you try again?
>
> You call dbg("..."); don't. Use ohci_dbg() or maybe dev_dbg() when
> driver model style diagnostics can work (you have a device, etc);
> use pr_debug() otherwise.
Changed.
> And there were comments you had copied/pasted, which made no sense
> since this isn't a PCI device ...
OK. I removed the comment.
> >>I like the way this uses platform_bus instead of a chip-specific bus.
> >>In fact, only the clock start/stop looks particularly specific to
> >>the LH7A404 -- so far!
> >
> >
> >That's true. It makes me wonder if it might be worth it to factor out
> >some of this code. For example, we could declare some of it as
> >generic_ and then refer to it with small wrappers that don't incure
> >any code overhead.
>
> I had the same thought. If you want to, feel free ... it's more
> likely to get re-used if generic stuff is factored out, and I
> suspect a fair amount of SOC OHCI shouldn't need anything more.
OK. Here's where I stand with this. Someone else made this work.
For the time being, I'd like to leave it as it is. There are several
implementations of ohci. All but one is ARM platform specific. IMHO,
the work necessary would be to stub all of them and refer to a common,
generic base.
Thanks for the feedback.
-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
