
Compensate for Rockchip calendar deviation on November 31st - Moral_
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=f076ef44a44d02ed91543f820c14c2c7dff53716
======
suprjami
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.

~~~
ojn
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.

~~~
jschwartzi
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.

~~~
tonyarkles
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.

------
nchelluri
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.

------
bitwize
At first I was like "November 31st?!" Then Rainier Wolfcastle popped into my
head and said "THAT'S THE BUG."

------
kevin_thibedeau
It's disappointing that pretty much all RTCs still store two digit years. I'd
like to design hardware that still works right after Y2.1K.

~~~
simcop2387
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.

------
plorg
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.

~~~
rzzzt
November has 30 days, while the chip's real-time clock counts to 31 days in
that month. Some additional commentary can be found on LKML [1].

[1]
[https://lkml.org/lkml/2015/12/2/1202](https://lkml.org/lkml/2015/12/2/1202)

~~~
jsudhams
But in this link isn't code setting day to Nov 1 when it hits Oct 31? Am i
reading some wrong?

if (tm->tm_mon == 10 && tm->tm_mday == 31) { dev_warn(dev, "correcting Nov
31st to Dec 1st (HW bug)\n"); tm->tm_mon = 11; tm->tm_mday = 1;
rk808_rtc_set_time(dev, tm); }

~~~
Someone
[http://www.cplusplus.com/reference/ctime/tm/](http://www.cplusplus.com/reference/ctime/tm/):

    
    
      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

------
762236
The introduction to the patch is unnecessarily demeaning.

~~~
762236
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.

~~~
smcl
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.

