Dan Mick wrote:
> Joachim Worringen wrote:
>> Dan Mick wrote:
>>> The rationale is that a device driver does not need to, and should not, 
>>> know anything about other devices in the system.
>> I agree, but see below.
>>
>>> Why do you need to know the host bridge type?  (I can imagine reasons, 
>>> but what is the problem in your case?)
>> It's mostly a legacy problem: we perform a lot of PIO-transfers, and 
>> certain types of hostbridges need certain ways to perform these accesses 
>> for optimal performance. Or to work around bugs (not only performance bugs).
>>
>> With current PCIe bridges, this is not any longer a real issue. Not that 
>> these bridges would be bug-free, but at least the performance is ok on 
>> all bridges we've seen so far, and no bugs that affected us *and* could 
>> be solved with workarounds are known to us.
>>
>> Thus, we can hopefully live without it for now (and I am happy if these 
>> workarounds can finally be omitted). But you never know...
>>
>>   Joachim
>>
> 
> So, the normal "Solaris-fu" way to work around such things is to put the 
> onus of advertising on the parent driver: since it owns the hardware, make 
> it identify its broken behavior by adding a property to the device tree, 
> that can then be queried by any children (thru the normal "look at 
> properties, and climb the tree continuing to look until you find it, or 
> return failure" mechanism).
> 
> This way, the information about the brokenness is volunteered as useful to 
> others, and the children access it without needing to touch the parent 
> hardware.

...and I should have mentioned: in the specific case of host bridges, since 
there often aren't drivers for them, this property would be created by the 
global PCI enumerator in Solaris.

Yes, it's not very flexible.

OTOH, if it's something that can be identified by properties already in the 
tree (like vid/did), nothing stops the child driver from looking for those 
in its parent.
_______________________________________________
driver-discuss mailing list
driver-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/driver-discuss

Reply via email to