2017-06-21 0:08 GMT+02:00 Pavel Machek <pavel@xxxxxx>: > Hi! > >> >> > This is it. >> >> > https://patchwork.kernel.org/patch/6219401/ >> >> >> >> Thanks. >> >> >> >> Yes, that's argument against changing rtc _drivers_ for hardware that >> >> can not do better than 32bit. For generic code (such as 44/51 sysfs, >> >> 51/51 suspend test), the change still makes sense. >> >> What I had in mind when writing those patches was to remove the limitations >> coming from those functions usage, even more since they been marked has >> deprecated. >> >> I agree that will change nothing of hardware limitation but at least >> the limit will >> not come from the framework. > >> > Yes, we agree on that but I won't cherry pick working patches from a 51 >> > patches series. > > Well, it would be actually nice for you to do the cherry > picking. That's something maintainers do, because it is hard for > contributors to guess maintainer's taste. > > Anyway, it looks like someone should go through all the RTC drivers, > and document their limitations of each driver (date in future when > hardware ceases to be useful). If Benjamin has time to do that, I > guess that removes all the objections to the series. Without the datasheet I can check in driver code what they do in read/set time functions to understand their limitations. All drivers using BCD like system or spliting day and time should be fixed. I can do a subset of my patches including those driver + the acked ones. Alexandre does that sound reasonable for you ? > Regards, > Pavel > -- > (english) http://www.livejournal.com/~pavelmachek > (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-tegra" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html