Return-path: Received: from cpsmtpb-ews05.kpnxchange.com ([213.75.39.8]:4219 "EHLO cpsmtpb-ews05.kpnxchange.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S965833Ab0GPPqb (ORCPT ); Fri, 16 Jul 2010 11:46:31 -0400 Message-ID: <4C407ED4.6000002@gmail.com> Date: Fri, 16 Jul 2010 17:46:28 +0200 From: Gertjan van Wingerde MIME-Version: 1.0 To: Helmut Schaa CC: Bartlomiej Zolnierkiewicz , Felix Fietkau , "John W. Linville" , Ivo Van Doorn , Christoph Egger , linux-wireless@vger.kernel.org, users@rt2x00.serialmonkey.com, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, vamos-dev@i4.informatik.uni-erlangen.de, Luis Correia Subject: Re: [PATCH 01/11] Removing dead RT2800PCI_SOC References: <20100714131527.GB2352@tuxdriver.com> <4C3DCD5C.1080705@openwrt.org> <201007151041.55112.bzolnier@gmail.com> <4C4007CD.2070504@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Sender: linux-wireless-owner@vger.kernel.org List-ID: On 07/16/10 12:08, Helmut Schaa wrote: > On Fri, Jul 16, 2010 at 9:18 AM, Gertjan van Wingerde > wrote: >> >> On 07/16/10 08:57, Helmut Schaa wrote: >>> On Thu, Jul 15, 2010 at 10:41 AM, Bartlomiej Zolnierkiewicz > wrote: >>> >>> On Wednesday 14 July 2010 04:44:44 pm Felix Fietkau wrote: >>> > On 2010-07-14 3:15 PM, John W. Linville wrote: >>> > > On Wed, Jul 14, 2010 at 02:52:14PM +0200, Ivo Van Doorn wrote: >>> > >> On Wed, Jul 14, 2010 at 2:46 PM, Luis Correia > wrote: >>> > >> > On Wed, Jul 14, 2010 at 13:39, Christoph Egger > wrote: >>> > >> >> While RT2800PCI_SOC exists in Kconfig, it depends on either >>> > >> >> RALINK_RT288X or RALINK_RT305X which are both not available in Kconfig >>> > >> >> so all Code depending on that can't ever be selected and, if there's >>> > >> >> no plan to add these options, should be cleaned up >>> > >> >> >>> > >> >> Signed-off-by: Christoph Egger > >>> > >> > >>> > >> > NAK, >>> > >> > >>> > >> > this is not dead code, it is needed for the Ralink System-on-Chip >>> > >> > Platform devices. >>> > >> > >>> > >> > While I can't fix Kconfig errors and the current KConfig file may be >>> > >> > wrong, this code cannot and will not be deleted. >>> > >> >>> > >> When the config option was introduced, the config options RALINK_RT288X and >>> > >> RALINK_RT305X were supposed to be merged as well soon after by somebody (Felix?) >>> > >> >>> > >> But since testing is done on SoC boards by Helmut and Felix, I assume the code >>> > >> isn't dead but actually in use. >>> > > >>> > > Perhaps Helmut and Felix can send us the missing code? >>> > The missing code is a MIPS platform port, which is currently being >>> > maintained in OpenWrt, but is not ready for upstream submission yet. >>> > I'm not working on this code at the moment, but I think it will be >>> > submitted once it's ready. >>> >>> People are using automatic scripts to catch unused config options nowadays >>> so the issue is quite likely to come back again sooner or later.. >>> >>> Would it be possible to improve situation somehow till the missing parts >>> get merged? Maybe by adding a tiny comment documenting RT2800PCI_SOC >>> situation to Kconfig (if the config option itself really cannot be removed) >>> until all code is ready etc.? >>> >>> >>> Or we could just remove RT2800PCI_SOC completely and build the soc specific >>> parts always as part of rt2800pci. I mean it's not much code, just the platform >>> driver stuff and the eeprom access. >>> >> >> I'm not sure if that is feasible. Sure, we can reduce the usage of the variable by >> unconditionally compiling in the generic SOC code, but we should not unconditionally >> register the SOC platform device, which is currently also under the scope of this >> Kconfig variable. > > Ehm, no, the platform device is not registered in rt2800pci at all, > it's just the platform > driver that gets registered there. The platform device will be > registered in the according > board init code (that only resides in openwrt at the moment). > OK. Didn't know that. Sounds good then. However, I've tried this in my local tree, and now compilation fails on the x86 platform due to a missing KSEG1ADDR macro. How do you suggest to handle the potentially missing macro? --- Gertjan.