[OpenBIOS] [PATCH] Add USB OHCI + HID driver

[Segher Boessenkool]

On Wed, Jun 04, 2014 at 01:24:08PM +0200, BALATON Zoltan wrote:
> On Wed, 4 Jun 2014, Segher Boessenkool wrote:
> >There surely is support for a host bridge?
> 
> Yes, for uninorth but PowerMac3,1 on real hardware has an additional 
> bridge between the host bridge and the pci devices according to the device 
> tree dumps I've seen and comments in QEMU that say it is not enabled 
> because it is not supported by the firmware. I meant that bridge.

Let's see...

/pci at f0000000		\ that's the uni-n AGP host bridge
/pci at f2000000		\ and that's the uni-n 66MHz PCI host bridge
/pci at f2000000/pci-bridge at d	\ PCI-PCI bridge to a 33MHz bus,
				\ all the goodies (usb, 1394, enet, macio)
				\ are on here.  also some slots.  this is
				\ keylargo.
/pci at f4000000		\ another 66MHz bus, with the uni-n 1394 and enet
			\ on it

So the only PCI-PCI bridge is the one to keylargo.  If that is not enabled
nothing will work (it has the disks behind it, but what's more, also the
interrupt controller and the interface to the PMU).  So you are saying this
does not work at all on hardware?

> >I agree that the code that decides when to enable bus mastering should 
> >be in the device driver.
> 
> Now I'm confused. One of you say it should be in pci.c the other says it 
> should be in the device driver which is usbohci.c in this case. Currently 
> it is in a function in pci.c which is only called for the only ohci 
> controller supported so I think it satisfies both so no change needed. Did 
> I misunderstood something?

I am saying the code that *decides* to enable bus mastering should be in
the device driver, as you had it; only the device driver knows when in its
initialisation is the appropriate place to enable bus mastering (many
devices put junk on the bus if you enable it without first initialising other
things).  But the code that actually does the enabling probably belongs in
the PCI subsystem (for example, it should refuse to enable it for a device
if the parent bus (or grandparent, etc.) does not allow it).

> >It would be nice to test this on real hardware.  If no one has that,
> >just try to make sure your new code will not fail on hardware where
> >the old code worked (like, don't run any "dangerous" code unless your
> >device is detected).
> 
> I can't test on real hardware. The ohci driver is only used if an Apple 
> Keylargo OHCI controller is detected that is fairly specific to mac99 
> machines where the current code probably does not work now due to the 
> bridge issue above. So did I miss something?

Hrm?  The USB OHCI is just a standard USB OHCI, used on way more machines
than just Apple kit.

Now I'm confused :-)


Anyway, if the code is truly in such an abominable state that it does
not work at all on hardware, just try to make sure it does keep working
wherever it does now work.  And write clean code, no awful hacks,
certainly no awful hacks that cross boundaries and/or are not well
documented, that kind of thing.  Leave it in a better state than it was
in originally and one day we will have something great ;-)


Segher