But for how long is long? Upstreaming success story!

Almost exactly year ago I was sitting on this same bed. I was leaning on this same pillow and had this same laptop on my lap. I was writing about this same topic. Accuracy of the timing is almost creepy as I haven’t been writing any posts or articles during the past year. I guess it shows we are still part of the nature. When the autumn sneaks into the town and starts killing all that is green it also makes me to spill out my thoughts like the bad wine I used to brew when I was a fresh student at the university. Writing for sure cleans my head better than it did :]

Last year I wrote two articles about adding drivers for ROHM PMICs to the community Linux kernel. ROHM has lately been really increasing effort in contributing drivers to the Linux kernel. Today I am going to write about the same topic. Repetition? I use same laptop. Same pillow. Same bed. I am the same guy and I am about to write about same topic – still, I don’t think I will be repeating myself. (I am not sure I like what this tells about my ability to understand things).

Anyways, for you to be able to judge if I am just repeating myself you should know what I wrote about earlier. It would be slightly mean to ask you to read those two previous articles. Especially because I could have been slightly less verbose. Four pages to say: “Getting drivers in the upstream Linux took ages” is kind of an overkill, right? If I knew how to draw I would also have drawn a nice picture with dust, spider-webs and a skeleton leaning on a laptop. But as I can’t, I wrote how it took over 850 mails to get 50 patches in. You may think that it's no wonder for a guy who writes two long LinkedIn articles about something Randall Munroe would have drawn in a 3 screen comic strip. I can’t deny I have a habit of babbling - but I can ensure I don't write emails to Linux community just for fun.

My co-worker keeps claiming that:

Sending drivers to upstream is wasted time as by the time a driver gets accepted the device is already “end of life”.

Today I wanted to point out that this is not always the case. At times things can go very differently.

A success story?

Two weeks ago I received a request from colleagues at ROHM HQ to provide them a driver for certain Power Management IC (PMIC) models. Or actually this probably is a slight simplification – In many companies routing the requests can be slightly more complicated than that and I think that ROHM is not an exception. But hey, we can't expect perfect world, right? We need to have something to improve. Nevertheless I received this request.

I happened to have a break-out board for one of the requested PMIC models at my cabinet and I do enjoy writing the drivers. Well, ROHM pays me to do that... So ... Surprize! - I started drafting the drivers for this IC.

It was not a huge task (like my attempt to build a shelter for firewood at my yard :rolleyes:) as I knew the data-sheet already. I had previously written some demo SW for this PMIC. During the Wednesday I wrote the watchdog driver. And it took me whole Thursday to draft regulator and MFD drivers – and then the whole Friday to re-write the watchdog driver... It was a bloody stupid idea to wrote overly complex generic multiplication algorithm which could be used to compute the watchdog time window… It is well known fact that Mondays suck – but I think Wednesdays are occasionally even worse. At the Friday afternoon I had watchdog driver where I had replaced few hundred lines of complex (and buggy) algorithm with simple loop of multiplication. It was not fancy. It didn’t have the cool object oriented touch or generic usability – instead it was simple and clean and worked. Well – you can’t have it all, right? (It’s unfortunate I can’t really pack all that sarcasm I feel in the two previous sentences. But those who know my work history can perhaps know what I am thinking about :])

I spent all Friday and Sunday doing much more important things like playing the “Ticket to Ride” with my wife, my oldest son and my sister and her family.

Next Monday was the “big day” when I first connected the break-out board to a beagle bone black minicomputer. Then I booted the kernel with my fresh drivers and hacked in a device-tree overlay describing the PMIC node... Then I watched as UART console was instantly spammed by Oops. Oh – I had uninitialized pointer… Let me fix this...

Next three days (well, working hours at least) were full of writing test code and fixing issues from drivers. At Thursday morning I had drivers working – or at least passing my test cases. I still spent 3 good hours by writing device-tree binding document and cleaning up the code. After that I ran this magic “git format-patch -s –thread -v1 –cover-letter –base v5.9-rc4 v5.9-rc4” which gave me 6 shiny new patches with the changes.

There I was with the new driver ready to be sent to the HQ. Writing it was fun as long as it lasted. Sigh, now I should start looking at that other dull project again... Perhaps there was something else - anything else... Then I had an idea! I might just as well send the patches to kernel community and see what kind of feedback I received. Perhaps the driver could also help others. It could also help people to select our PMIC for their project ;] In any case - this way I could probably work a bit longer with Linux drivers! Besides, my superior(s) at ROHM really support providing drivers to the Linux community when effort of doing so stays reasonable.

So, finally I spent an hour writing the cover-letter and asked my beloved email client “mutt” to spill out the patches. And for those who don’t know mutt – it is an email client with a slogan:

"All mail clients suck. This one just sucks less."

I find this slogan very funny. There is something which tickles me the good way. And that’s about all in mutt that tickles me in a good way. It’s terrible to use nowadays when HTML mails are so popular. Still – I don’t know any better way of sending plain text patch emails to kernel community. For that specific purpose mutt really, truly “sucks less” than other options.

And… It was Thursday 11.09 AM when I did this. A week and a day after I started drafting the drivers.

11.09? Oh dear! I was still at home – I had not eaten lunch yet – and I had a meeting in the town at 12.00. So I changed clothes almost as quickly as in the army. By the way, You should have seen me changing back then! Oh, on the other hand – you probably wouldn’t want to see that… I packed some stuff in my car, grabbed a pack of peanuts which I could eat while driving and hit the road… And I made it in time.

Next morning when I opened my email (evolution client at this time) I was a bit surprised. I saw Mark had replied to my regulator patches. And guess what. I was even more surprised when I saw he had applied my patches in his tree. Amazing.

I did send out the patches at 11.09 AM – and Mark had replied me slightly before 8 PM. 9 hours after sending out the patches the regulator part was applied to Mark’s tree. All in all, a week and one day after I started writing the drivers. “Your HW is EOL by the time driver is accepted …” Mika – if your hardware do expire this fast then you really have some adjusting to do in R&D practices XD

It is fair to say that the MFD and Watchdog portions were not accepted as fast. OTOH if the PMIC had no watchdog – then there would not have been MFD and watchdog drivers – and then the whole driver would have been included this quickly.

Can a developer speed up patch acceptance?

I have previously told it has taken several months from me to get a driver in upstream. What is the difference now?

I believe this boils down to few very important things – and you as a driver developer really have some of the keys at your hands. For sure you should ask this from the maintainers but I like to think what makes the difference is:

1. Your previous work and attitude.
2. Simplicity. Clarity. Comments.
3. Maintainer.

Someone once told me that it is very humane to think one is a bit better than the others. It keeps us sane and helps us to tolerate this world. We are bit better drivers than others. We do a bit better code. We work a bit harder and so on...

So, regarding the first point - Maybe it is just me but I think that I have been persistent and responsible. I at least think that I do try to take care of the things I have initiated (Let's not talk about my university studies though. Although - each good rule has some exceptions, right?). I do this also in code writing – I try to ensure I fix problems found from my code and I don’t just hide when someone calls for me with that sweet voice: “Who the hell has broken this? I will strangle that guy...” (hiding could also be a bit difficult when you have your name in commit messages...)

To put it short - When you do your best to write quality code. When you do your best to fix all problems found from your code – and do reviewing and maintenance - then it is probably easier to trust that taking your driver in will not cause any huge problems. No one likes to shovel a pile of shit but what makes the shovelling really intolerable is when someone else has been shitting on your yard. I hope the few years of work I've put in this area of community Linux has shown to that I do my own part of shovelling.

The second point (in that list up there - you still remembered it?) was helped by the fact that the PMIC I worked with was really simple. It mostly had very basic functionality which is well known and has well established mechanisms in regulator framework. Hence, I didn't re-invent the wheel. I used the existing mechanisms as simple as I could. Do that and your driver becomes easy to understand. When it is easy to understand it is easy to accept. Just please don't get me wrong - I do love doing things in my own way. I admit I do suffer from NIH-syndrome. There's slightly more artist than engineer in me - although I have zero traditional skills to do arts. (Besides, I am a bit better than others. Just like we all are, you remember?) Sometimes trashing old and creating something new actually do improve things - but it never speeds up acceptance. You must justify changes to existing conventions and even in (rare) cases when changes really are clever - justifying them takes time.

The PMIC I worked with had just one twist – at start-up it did select “operation mode” depending on a specific pin state. At mode “A” the VOUT1 enable state is not changeable – but at mode “B” the ON/OFF state can be toggled via GPIO. Supporting this required a special handling in driver. What I did was dropping a comment in code and cover-letter – which explained why I had such a piece of oddball code there. I like adding comments which answer to questions before they are asked.

And last but not least the third point. It is the thing you can’t really impact. If someone asked me what actually happened with the submission I could probably answer that: "Mark happened with my patch." Mark Brown who is maintainer of the regulator framework (amongst other things) is one of the easiest maintainers to work with. (My subjective opinion). I have received direct feedback when improvements were needed – but he doesn't request changes just for the sake of requesting the changes. He does careful reviewing – but he does not have that “I am a boss and I want to see you jumping” - syndrome. I don’t think other maintainers are bad at that either – but Mark is just a right man to the job. Quick and accurate and does not add any extra BS to the work. Kudos to him.

So, combination of the three listed things led to my personal record. My record for getting a (sub)driver in upstream is now 8 days from starting the coding – including two days of not working and the time it took to write tests and do testing. Assuming - no believing - this work benefits the people using these components... That time was well worth the effort. And I hope this also encourages others to take up the challenge and add support to your HW in community kernel! I am sure you can beat my record - and I hope I hear your stories :)