Am Freitag 16 Juli 2010 schrieb Gertjan van Wingerde: > 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? We can convert it to an ioremap call, that should be available on all platforms. Helmut -- 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
