I read a lot of kernel source at work. Every now and then I stumble across a comment or commit message like this which really gives me a chuckle and makes my day.
Also if you've ever actually used a Rockchip device you'll know they're absolute shit. Pirated Android phone images on incomplete Android device frameworks. They do bullshit like displaying on the TV at 1080p but the Netflix app displays at 720p in the top left corner. How unsurprising they fucked the calendar up too.
Before you go defend the brave embeddded developers from the mean nasty LKML, just think of all the consumers who've paid $100 for TV sticks which advertised an experience and didn't even come close to fulfilling that promise, with absolutely zero after-sales support or updates coming out of Rockchip. Fuck those guys.
If you are any form of hacker who takes pride in your work, you'll recognise this for the colossal fuck-up it actually is.
RK3288 from Rockchip is in several of the Chromebooks that are currently on the market, including Chromebook Flip and the ASUS Chromebit.
They perform quite well there if I may say so, when a proper amount of effort has been put into the software running on them.
The chips from Chinese manufacturers aren't really better or worse than most of the others out there, it's just that they often take shortcuts on the software side -- or rather, in particular the low-cost system OEM/ODMs do.
I've learned never to trust software implementations from third-party companies. They generally work well enough for pre-sales demonstrations, but you should always expect to do a bunch of post-sales bug fixing and feature implementation if you want to build a real product out of them. The same thing goes for BSPs from third parties.
Basically it's extremely rare to find third-party software that is completely trustworthy, even when you pay a bunch of money to ensure that this is the case. Hence why IEC62304 speaks directly to third-party software as enhancing risk. The best thing you can hope for is that the bugs are fairly benign or are easy to work around.
I've made pretty good money a few times by taking BSPs provided by vendors and transforming them into something actually usable and robust. And these aren't sketchy Chinese OEMs, these are well-established vendors.
This was in software, not hardware, more serious than just the date being wrong, and they didn't even provide a fix other than "wait until the day passes":
If I hadn't come to the comment thread, I would not have realized that the commit message was sarcastic - I thought to myself, "wow, people are still finding bugs in calendars - this stuff is hard."
This is probably tangential but when it comes to code and context and everything (e.g. commit messages) I like to be as dry and clear as possible. Just the facts, ma'am.
Not even 2.1k, because of the 2 digit years, they'll fail before that even. They've usually got some kind of cut off date where before that it'll give the wrong Day of the Week because it's using the wrong table now.
So is the Rockchip device counting incorrectly, or is someone actually proposing there is something specifically wrong with the Gregorian calendar? Without any other Google results for "Rockchip calendar" I'm assuming it's the former, but if so the level of snark is a bit difficult to read through and the post doesn't make much of a differentiation between the hardware and the calendar model used to correct for its error.
Member Type Meaning Range
tm_sec int seconds after the minute 0-61*
tm_min int minutes after the hour 0-59
tm_hour int hours since midnight 0-23
tm_mday int day of the month 1-31
tm_mon int months since January 0-11
tm_year int years since 1900
tm_wday int days since Sunday 0-6
tm_yday int days since January 1 0-365
tm_isdst int Daylight Saving Time flag
The snark is extremely dry, so it is entirely reasonable to have misunderstood it. But the effect of adding an unconditional day to November would be to increase the year to 366 days (and 367 on leap years), which even the ancients knew was totally wrong. And the effect of adding a day to November and take it from e.g. December is just to affect how we do human accounting; there's no astronomical concept of December 1 that needs to line up with anything.
I wonder how they missed it. If someone was asked to write verification tests for a RTC chip, this would one of the first few things obvious things to be checked.
Really, or are you just saying that? They "missed it" because either (a) they didn't bother to test at all, or (b) they actually thought November has 31 days and didn't bother to do the 4 seconds of research required to get both the implementation and the test correct (since, of course, the people writing this are almost certainly Chinese and know as much about the Gregorian calendar as they know about McDonald's hamburgers, Norman Rockwell's art, or the present value of the euro).
I make chips for a living, and if I had screwed up this badly I would fully expect to be fired. Being fired for incompetence is much more demeaning than gentle mockery by people writing a workaround.
That's hardly demeaning. I would be more devastated if I produced a product that had this type of a bug, versus what some random stranger might write in patch notes about it.
The person responsible doesn't care in the slightest. They got paid, their product not only got sold but is still being sold, and so there's nothing to be bothered with. That's what firmware's about: toss it out the door and move on. Trust me, if the person who did this even knows about it, he surely does not care at all.
The good news is that presumably the introduction of this bug means that they needlessly rewrote the RTC for this generation of chips, which means they might meaninglessly rewrite it again and the bug will be fixed!
On the contrary, the comments are far too kind. This sort of error is simply unconscionable and the person responsible for it deserves far worse. It's unfortunate that the poor sod responsible for working around it can't do any more than write a scathing comment, because at an absolute minimum the responsible party should never work again (in any industry or role).
Wow, this comment is currently downvoted to 0, and the replies to it are justifying the belittling response. You become more worthy through action --- not by belittling someone else.
I think the downvotes are a little harsh, but I disagree with you. The patch notes are not belittling and don't represent any of the other problems I've seen complaints about re Linux contributions (swearing, bullying, sexism). They're just a bit of light-hearted fun - and they're not contained in the code itself.
Also if you've ever actually used a Rockchip device you'll know they're absolute shit. Pirated Android phone images on incomplete Android device frameworks. They do bullshit like displaying on the TV at 1080p but the Netflix app displays at 720p in the top left corner. How unsurprising they fucked the calendar up too.
Before you go defend the brave embeddded developers from the mean nasty LKML, just think of all the consumers who've paid $100 for TV sticks which advertised an experience and didn't even come close to fulfilling that promise, with absolutely zero after-sales support or updates coming out of Rockchip. Fuck those guys.
If you are any form of hacker who takes pride in your work, you'll recognise this for the colossal fuck-up it actually is.