<html><head><meta name="qrichtext" content="1" /></head><body style="font-size:11pt;font-family:Nimbus Mono L">
<p>On Tuesday 20 February 2007 16:25, Segher Boessenkool wrote:</p>
<p>&gt; &gt;&gt; And the ebony dts also has the a bus type of &quot;ibm,opb&quot; as well.</p>
<p>&gt; &gt;</p>
<p>&gt; &gt; We should really get a common name for these. I don't remember</p>
<p>&gt; &gt; what the discussions were, but it seems we came up with different</p>
<p>&gt; &gt; results for Axon and ppc4xx, which is very bad.</p>
<p>&gt; </p>
<p>&gt; &quot;Very bad&quot;...  Well sure it's less than desirable, but</p>
<p>&gt; we have to deal with this problem anyway already.</p>
<p>&gt; </p>
<p>&gt; &gt; Using type &quot;ibm,opb&quot; rather than just &quot;opb&quot; makes sense to me,</p>
<p>&gt; &gt; but I don't know if we already have shipping systems that use</p>
<p>&gt; &gt; &quot;opb&quot; here.</p>
<p>&gt; &gt;</p>
<p>&gt; &gt; There is probably a similar problem with the nodes for &quot;plb4&quot;,</p>
<p>&gt; &gt; &quot;plb5&quot; and &quot;ebc&quot;,</p>
<p>&gt; </p>
<p>&gt; It makes sense for generic code to always if it is asked</p>
<p>&gt; to match for &quot;vendor-code,some-name&quot; also to match on</p>
<p>&gt; plain &quot;some-name&quot;.  Well unless people start doing crazy</p>
<p>&gt; things like naming something &quot;vendor-code,pci&quot; which</p>
<p>&gt; isn't PCI compatible or something -- in that case there</p>
<p>&gt; could be a function that matches on exact name only, or</p>
<p>&gt; the caller can deal with it itself perhaps.</p>
<p>&gt; </p>
<p>&gt; But in most cases the matching-without-prefix should work</p>
<p>&gt; fine.</p>
<p></p>
<p>but is it really the right thing to call it &quot;ibm,plb&quot;</p>
<p>when the identical macro is used on amcc based systems?</p>
<p></p>
<p>I think that was our reasoning when we introduced the</p>
<p>code in linux to scan for &quot;plb5&quot;, &quot;plb4&quot; and &quot;opb&quot; buses.</p>
<p></p>
<p>Changing the &quot;device-type&quot; now would result in the final</p>
<p>product to not work on the 2.6.20 kernel, which was released</p>
<p>with the code only scanning for the short names.</p>
<p></p>
<p>Still, it's probably a good idea to list both variants</p>
<p>in compatible, e.g.</p>
<p></p>
<p>type=&quot;plb4&quot;, compatible=&quot;ibm,plb\0ibm,plb4\0plb&quot;</p>
<p></p>
<p>on CAB/axon, and</p>
<p></p>
<p>type=&quot;ibm,plb&quot;, compatible=&quot;ibm,plb4\0plb4\0plb&quot;</p>
<p></p>
<p>on ebony and others. Do you think it makes sense to do it this</p>
<p>way, or should we rather adopt the axon style on the 440 boards?</p>
<p></p>
<p>&gt; &gt; as well as the &quot;compatible&quot; property of the</p>
<p>&gt; &gt; serial port, which, as you noted earlier is &quot;ns16550&quot; on</p>
<p>&gt; &gt; ebony and &quot;ns16750&quot; on axon, although it is exactly the same</p>
<p>&gt; &gt; macro.</p>
<p>&gt; </p>
<p>&gt; So the &quot;compatible&quot; property should read ns16750, ns16550,</p>
<p>&gt; ns16450, i8250.  The kernel really only needs the device</p>
<p>&gt; to be compatible to the 8250; but since lots of device trees</p>
<p>&gt; mention only the newer UART types, you have to match on those</p>
<p>&gt; too.</p>
<p></p>
<p>Right, that sounds completely correct. I think I've done the</p>
<p>right thing in of_serial already. Christian, please check</p>
<p>what the firmware does today, and make sure to change it</p>
<p>accordingly.</p>
<p>We probably also need a volunteer to clean up the legacy_serial</p>
<p>code for this, it's grown pretty messy by now.</p>
<p></p>
<p>        Arnd &lt;&gt;&lt;</p>
</body></html>