On Mon, Feb 23, 2015 at 11:59 PM, Boaz Harrosh <b...@plexistor.com> wrote: > No, this is a complete HACK, since when do we hard code specific (GLOBAL) > ARCHs strings in common code. Please look at linux/ioport.h see the richness > of options for all kind of buses and systems. The flag system works perfectly > and I just continue this here. > > And really DAN, you prefer a global string that's dead garbage in 99% of > arches > to a simple bit flag definition that costs nothing? I don't think so.
Glad we're moving ahead with the IORESOURCE_MEM_WARN solution rather than this or the 64-bit-limited IORESOURCE_WARN approach. > >> + add_taint(TAINT_FIRMWARE_WORKAROUND, LOCKDEP_STILL_OK); > > NACK!! > I disagree. Ultimately what goes into kernel/resource.c is not up to me, but firmware/driver combinations that subvert standards should be flagged by the kernel. Stepping back from the original motivation, in the general case, an unknown memory type is indiscernible from a BIOS bug. TAINT_FIRMWARE_WORKAROUND is simply a notification that firmware needs to be updated, and I believe a driver attaching to unknown memory is such an event. It does not block a user from using that memory however he or she sees fit. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/