Benjamin Herrenschmidt wrote:
Ok. that's why I suggest to keep buggy (or none) firmware board in
platform specific code.
Well, in that case, we have a well defined interface to set the sense
code, via the device-tree, and that's much better than having platform
code muck around the PIC hardware separately from the PIC driver don't
you think ?
Anyway, that's the way it works in Linux/powerpc so there is no need
debating that for ever. Just be aware that at one point, there will be a
set_type() implementation in this driver and that it will be called
based on the polarity information in the device-tree so make sure you
got it right.
Ok. set_type() is scheduled for later on or should it be included right now?
What's next should be done to finally acked the driver?
Of course, if your device-tree has bugs, then adding that feature
afterward will suddenly break efika ...
Our OpenFirmware is, of course, bugfree ;-)
:)
You doubt? ;-)
begin:vcard
fn:Nicolas DET ( bplan GmbH )
n:DET;Nicolas
org:bplan GmbH
adr:;;;;;;Germany
email;internet:[EMAIL PROTECTED]
title:Software Entwicklung
tel;work:+49 6171 9187 - 31
x-mozilla-html:FALSE
url:http://www.bplan-gmbh.de
version:2.1
end:vcard
_______________________________________________
Linuxppc-embedded mailing list
[email protected]
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
