On Thu, 8 Oct 2015, Viresh Kumar wrote: > > In my patch, I assumed that if 32-bit architectures work fine today, then > > we don't need more range on 64-bit architectures either. > > The problem here is that we haven't fixed it properly. > - clock framework expects it to be unsigned long > - DT is sending a 64 bit value in Hz > - But we are storing and exposing it in u32 > > That's weird, isn't it? > > So, either we update clock API and other similar APIs to u64 or u32 > (which may not be the right thing to do), Or we keep it unsigned long > here as well and add debugfs_create_ulong().
I don't see why debugfs can't accomodate C's builtin types, rather than insisting on predetermined sizes. After, the printf family of functions does that: %u vs. %lu. In fact, there's no way to tell printf that a particular value is 32 bits or 64 bits. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
