Hi Gerd, On Sun, Sep 13, 2015 at 11:42 PM, Gerhard Bertelsmann <i...@gerhard-bertelsmann.de> wrote: > General remark: > > Somebody asked me to add linux-sunxi dev list. Seems to be not a good idea > before the driver was ready. Seems to be hard to fulfill the differentness. > > I will remove linux-sunxi for the next patch set. I will try to get > linux-can > people satisfied and then I'm done with it. I'm doing this in my spare time, > but it seems to get an endless story. I'm not offended in any kind, my spare > time is just limited. > > The driver is working so far and the patches also apply to 4.3.
You misunderstand, the sunxi people (who's mailing list I follow) are the experts on the hardware platform you're writing this driver for. If you don't include them and don't solicit their advice, your driver may end up doing things which aren't correct for the platform (e.g. it might work for you but break something else) and this will seriously impact it's chances of getting included in the kernel at some point. You also can't get the driver "ready" before asking for their comments as what might have been small tweaks to get stuff "right" at the start may end up being big changes at the end. (Stitch in time and all that.) Including the linux-sunxi mailing list also means that there's more visibility to your efforts, more people looking over the code, (potentially) more testers and less duplicated effort as all sunxi related stuff is referred to in one place. (Thankfully in your case nobody else was working on a CAN bus driver, but there have been cases of multiple people independently working on drivers for the same hardware and only discovering this late in the development process.) As an occasional Linux developer, I don't see Maxime's questions as being "hard": he makes some good points about your clock handling - which is important for power management - and asks a couple of other good questions. Those questions and issues are stuff that has to be answered to get this driver into the kernel. In particular, the question about the interrupt handling was an "explain why you're doing this" question not a "this is broken and needs changing" question. And as for the changing things only to change them back issue, this is likely to be the last time that happens. My reading of his comments indicates that you should check over what and how stuff is handled over the "lifetime" of the device / connection / socket. I.e. are all your resources "freed" after they're no-longer needed? Are you switching off everything you turn on? etc. This is the sort of analysis that I'm sure you've done already, but it never hurts to do it again. I find issues like this all the time in the development I do. Finally, I strongly urge you to stick with the driver at least until it's merged. The fact that Maxime only had a few comments indicates that you've written a good driver which is a few tweaks away from being merged - which is something you should be very proud of. I see drivers being submitted that have much more serious issues and that prompt much more debate than yours has. (For instance I've seen some changes on another mailing list go through 6 full rewrites without everyone being happy.) Excellent work, keep it up. Thanks, -- Julian Calaby Email: julian.cal...@gmail.com Profile: http://www.google.com/profiles/julian.calaby/ -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
