Hi Ben, I know the code is not very readable, but unfortunately I developed the driver using a frame-buffer kernel slackware system that had 128 columns and naturally I used all the 128 columns with tabs=4. I found to my horror that the kernel standard is 80 columns and tabs=8 (which was not followed in the device drivers that I used as reference). The result was that I used perl to chop the code up and squeeze it into 80 columns, but I also had to invent lots of new subroutines to meet the the constrainsts of nesting imposed by the 80 columns and ts=8. And the result turned out to be rather more unreadable. Surely all graphics cards now support frame buffers with 128 columns, certainly they work at home with my 14 inch monitor and rather old hardware, so why can't the kernel standard be changed to something more usable?? ** end of rant **
As to how the driver works, first consider the hardware called a U132 adapter which is the first in a series of USB to PCMCIA CardBus adapters. It features a standard PCMCIA cardbus slot and the ASIC embedded in the adapter pretends to be a PCI bus, the details are a trade secret so I can't clarify that aspect any further. The U132 is designed to work with inserted CardBus cards that have an OHCI controller (or two). However the standard linux kernel OHCI controller only speaks directly to a PCI bus and directly attached OHCI controller and as such is not capable of driving the OHCI controller inserted into the U132 adapter. Next consider the U132 driver, it consists of two modules, the first is a USB client driver that polls an attached U132 adaptor waiting for a recognised CardBus card to be plugged into that very cut down pcmcia slot. Once again all recognised CardBus cards feature an OHCI host controller. After initialisation of the recognised CardBus card the second module is woken up and it becomes a usb host controller. Devices either hard-wired into the CardBus card or plugged in to a contained USB port are handled thereafter by the Linux USB core. So you should be able to see by now that the plugged in CardBus OHCI controller needs to be initialized and driven electrically the same as an OHCI controller directly connected to a real PCI bus. And it therefore follows that the U132 driver needs the OHCI register map AND details of QUIRKS. You can see the glossies on our web site http://www.elandigitalsystems.com Thanks again for your interest. Tony Olech Elan Digital Systems Limited ----------------------------------------------------------------- On Fri, 2007-01-05 at 23:04 +1100, Benjamin Herrenschmidt wrote: > On Fri, 2007-01-05 at 08:45 +0000, Tony Olech wrote: > > Hi Ben, > > > > when I tried to include the file that defined the quirks, > > ELAN's driver failed to compile. > > > > Thanks for your interest in this issue. > > > > ELAN is currently in favour of open source for linux drivers > > of ELAN's hardware, and this type of code review can only > > strengthen the case. However it would be more helpful if > > the gentleman with with weak stomach were to put forward > > more constructive critisism. > > Fair enough :-) > > I don't fully understand what this elan thing is trying to do precisely > though and the code isn't very readable ... > > Care to give me a short explanation about what this is about and how the > quirks enter in the picture at all ? > > They are normally defined by ohci.h and only used there and in ohci-*.c > > Ben. > > ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
