Hi Jim,

On Tue, Jul 14, 2009 at 06:27:18PM -0000, Jim Lieb wrote:
> I got it to compile in staging in our ubuntu-karmic git.  It would not compile
> for 64 bit .31rc2 because the code fell into the sizeof(int) == sizeof(void *)
> trap.  I fixed these by using the support fctns and macros.  I have attached
> the diff of what I have done so far.  This builds on amd64 now which is
> crucial for moving from staging to mainline.

Great, thanks for doing this.

> In looking at the driver style, it would appear that there is an attempt
> to have a common code base for a number of O/S platforms.  Is this true?
> Is there a VIA business reason for this?

I don't know.  I don't think there's any value to the community in maintaining
this.  VIA apparently does not have resources to assist with development or
maintenance of VT6655 or VT6656 in-tree drivers.  I don't think they have any
interest in what we do here.

> I ran checkpatch.pl against this driver and it generated ~ 20-30k
> errors/warnings. I've coded C for a very long time and have seen lots of
> "styles" come and go so I am reluctant to dictate to someone else where the
> curly brackets *must* go but I suggest that it would be easier on inclusion if
> the author or maintainer gets this more in line with the Linux coding
> standard.

Agreed that coding style issues should be addressed.  Your other comments
regarding typedefs, etc., sound reasonable to me.  I do hope that they can be
addressed.

> I also fixed a potential suspend bug where the error return was not
> being propagated back.  I have a FIXME comment in the resume to flag a
> similar problem.

Noted, thanks.

> As for carrying this in Karmic, we prefer that the driver at least be
> "on its way" out of staging before we consider it for inclusion.  This
> keeps the not-inconsiderable maintenance cost of an non-mainstream patch
> and its churn to a minimum.  Drivers/modules that come into the kernel
> this way also don't get lost as we rebase the kernel at each release
> cycle.  I think the best way forward is for the developer to take this
> input, generate patches to staging to get it moving forward into a
> mainline merge.  We can help with that effort by providing input/review.
> I do not have this device so I can't really test it myself.  We will
> obviously help shepherd the patch into Ubuntu at the appropriate time.
> Keep me posted on progress through this bug.  I can continue helping
> with integration at this end.  I would also encourage the developer to
> get a Launchpad account and be part of the conversation.

The original author(s) are not likely to participate on this end of things.  My
intent has been to get these drivers into staging with hopes that:

 * They may see some distributions pick them up, despite the problems with them,
   since this is the only avenue by which users with this hardware will see
   support (apart from compiling the drivers themselves).

 * There will be some interest from kernel developers in helping to clean them
   up.  I've heard from a few interested parties.

If you/Canonical are interested in helping with any of this, I think the best
thing to do is coordinate and get patches directly upstream, for now.  As I
understand things, these chips are not incredibly popular currently, but that
may change over the coming year or two (I suspect the VT6656 might get put into
a netbook or two).  If Ubuntu can distribute the drivers from staging, that
seems like it would be handy, but I understand the reasons for not doing that.

Unfortunately, my time is beginning to grow quite short.  I'll point out your
notes here to a few other developers that have shown some interest.  I'm happy
to be a coordinator, but probably won't be able to do a lot more with the code
itself for a little while.

Thanks,
Forest
-- 
Forest Bond
http://www.alittletooquiet.net
http://www.pytagsfs.org