From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gate.crashing.org (gate.crashing.org [63.228.1.57]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by ozlabs.org (Postfix) with ESMTP id 3EB45DDDEF for ; Tue, 9 Jan 2007 10:27:09 +1100 (EST) In-Reply-To: <1168296460.22458.232.camel@localhost.localdomain> References: <1168236558.22458.187.camel@localhost.localdomain> <8ee3d13b73a511a785ac4744c268943e@kernel.crashing.org> <1168288352.22458.198.camel@localhost.localdomain> <5f992368c65d3d53003b0e9f2955ae79@kernel.crashing.org> <1168296460.22458.232.camel@localhost.localdomain> Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <27d6554d600437ed39853784c0cf96fd@kernel.crashing.org> From: Segher Boessenkool Subject: Re: EMAC OF binding.... Date: Tue, 9 Jan 2007 00:27:26 +0100 To: Benjamin Herrenschmidt Cc: Christian Rund , Hartmut Penner , Murali N Iyer , linuxppc-dev list List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , >> So this is for accessing some shared SoC registers? The emac >> node has no business with that, you should have a separate >> node for that (and you probably do already, you can use the >> parent bus node in most such cases). > > If I needed a separate node for every shared SoC bit, I would have a >> 2MB device-tree :-) > > There are just a few places where I need to call some platform code and > tell it what EMAC in the chip it is so it can go tweak the right magic > bits, best is a property for that. Oh you misunderstand what I mean. I'm just saying the registers that are shared are in some other node (having the same regs in two nodes can't happen). Let's hope the hardware is sane enough that you can describe it in a sane way. You would probably end up with properties in the SoC node like "emac-#0" containing the phandle of the first emac, or something like that -- the number of the emac on the SoC is not a property of the emac, but of the SoC itself. I don't know the exact programming interface so I'm not completely sure of course, but please consider. >> MTU is dynamic, max-frame-size isn't. max-frame-size is just >> the maximum packet size you can tell the network controller to >> put on the wire, not counting protocol overhead etc. > > Ah ok. It sounds like max-frame-size is exactly what you wanted this new max-mtu property for, right? [Oh and btw, max-mtu is a really bad name -- "max-max-tu" heh]. Segher