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 ESMTPS id 6DC7EDDF02 for ; Tue, 1 Jul 2008 16:15:11 +1000 (EST) Subject: Re: [PATCH v2] Parameterize EMAC Multicast Match Handling From: Benjamin Herrenschmidt To: Grant Erickson In-Reply-To: References: Content-Type: text/plain Date: Tue, 01 Jul 2008 16:14:59 +1000 Message-Id: <1214892899.20711.95.camel@pasglop> Mime-Version: 1.0 Cc: linuxppc-dev@ozlabs.org, Stefan Roese Reply-To: benh@kernel.crashing.org List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , > Stefan and/or Ben: > > Any thoughts on this? I was hesitating a bit... do we really need to be -that- flexible ? That is, either that or use some new compatible entry to detect the new reg layout and whack that as a feature bit instead ? The advantage of the later is that we have the possibility of doing conditional compile for kernels that support only a given processor or set of processors (not that we have implemented much of it, but it just becomes Kconfig mumbo jumbo and a little bit of defines in the .h by turning the feature test into a compile-time 0 or 1. But this isn't a hot path and not a lot of code so maybe not worth bothering... however, it does add 3 properties to the DT and I know embedded people (especially Xilinx) are a bit concerned about the size of the DT when they try to fit it in block RAM... Cheers, Ben.