From mboxrd@z Thu Jan 1 00:00:00 1970 From: Igor Grinberg Date: Tue, 05 Jul 2011 18:12:20 +0300 Subject: [U-Boot] [PATCH 1/3] arm: add CONFIG_MACH_TYPE option and documentation In-Reply-To: <20110705140836.GA1927@harvey-pc.matrox.com> References: <1309770021-9908-1-git-send-email-grinberg@compulab.co.il> <20110704210619.GA3218@harvey-pc.matrox.com> <20110704221612.8CAC51579E0E@gemini.denx.de> <20110705140836.GA1927@harvey-pc.matrox.com> Message-ID: <4E1329D4.3080408@compulab.co.il> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On 07/05/11 17:08, charvey at matrox.com wrote: > On Tue, Jul 05, 2011 at 12:16:12AM +0200, Wolfgang Denk wrote: >> Dear Christopher Harvey, >> >> In message <20110704210619.GA3218@harvey-pc.matrox.com> you wrote: >>> I'm curious, is it a feature that bd->bi_arch_number can be set at >>> runtime? Do any boards actually make a decision about what value to >> Yes, this is a feature. It comes in handy in a number of cases. >> >>> set this to? If not, then maybe it should be a required value. I've >> Why? > Because if every machine sets an essentially static value at runtime > then it would be a nice compile-time check to do. But, there is no > point since the bi_arch_number isn't fixed for each u-boot > configuration. Right. >>> submitted some patches that deal with the same sort of issue, so I'm >>> interested in seeing that happens to this one. >> Sorry, I can't follow... > I was refering to this patch: > http://patchwork.ozlabs.org/patch/103149/ > which is similar. No, you are wrong! It is not similar even a bit! It does completely different thing. Your patch: warns about machine type not set. My patch: just adds a configuration _option_ which you can use, but you don't have to. See... It is not the same! -- Regards, Igor.