On 07/16/10 12:08, Helmut Schaa wrote: > On Fri, Jul 16, 2010 at 9:18 AM, Gertjan van Wingerde > <gwingerde@xxxxxxxxx> wrote: >> >> On 07/16/10 08:57, Helmut Schaa wrote: >>> On Thu, Jul 15, 2010 at 10:41 AM, Bartlomiej Zolnierkiewicz <bzolnier@xxxxxxxxx <mailto:bzolnier@xxxxxxxxx>> 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 <luis.f.correia@xxxxxxxxx <mailto:luis.f.correia@xxxxxxxxx>> wrote: >>> > >> > On Wed, Jul 14, 2010 at 13:39, Christoph Egger <siccegge@xxxxxxxxx <mailto:siccegge@xxxxxxxxx>> 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 <siccegge@xxxxxxxxx <mailto:siccegge@xxxxxxxxx>> >>> > >> > >>> > >> > 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. -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
