Date: Sat, 27 Jan 2018 23:14:27 +0000 From: "Poul-Henning Kamp" <phk@phk.freebsd.dk> To: Emmanuel Vadot <manu@bidouilliste.com> Cc: Warner Losh <imp@bsdimp.com>, John Baldwin <jhb@freebsd.org>, Ravi Pokala <rpokala@mac.com>, src-committers <src-committers@freebsd.org>, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r328257 - in head/sys: arm/broadcom/bcm2835 dts/arm modules Message-ID: <72042.1517094867@critter.freebsd.dk> In-Reply-To: <20180127210801.37b8001125dd0a2c92372f98@bidouilliste.com> References: <201801220710.w0M7AUm9091853@repo.freebsd.org> <CANCZdfpq2QoG4EAj0VW2FF=4VXRv-qQKFfJTJerWH9YOwVoVBA@mail.gmail.com> <90451.1516663240@critter.freebsd.dk> <2987003.eeGRFBb6N8@ralph.baldwin.cx> <CANCZdfrh0NHq7cbkq_genEdzo%2BB3G4TTAcEzpgh11sr%2B82e9aw@mail.gmail.com> <93949.1516733748@critter.freebsd.dk> <20180127210801.37b8001125dd0a2c92372f98@bidouilliste.com>
next in thread | previous in thread | raw e-mail | index | archive | help
-------- In message <20180127210801.37b8001125dd0a2c92372f98@bidouilliste.com>, Emm= anuel Vadot writes: > - We have a commiter that commited something for his own need: he >wanted to use the pwm on his rpi, coded a driver (this part is good) >but feel that the standard we were using was crap and commited his work >without talking with arm developper on what the proper way to do it was. First, as a general rule, I think you should leave it to me to express what I think and feel, because you truly suck at it. FDT may or may not be the right technology to use, I take no position on that, because I am not the one doing all the work to implement it, and I certainly don't propose to do the work to come up with an alternative. > - Now we have a crappy driver in the tree. 1. Hardly our first 2. "Crappy driver" is not pass/fail, we grade that on a curve. 3. You confuse "I don't like" with "crappy" > - We still have this driver that doesn't follow the standard we said we >want to adhere to. And part of that decision, clearly explained for all who participated in making it, was that we should time-warp back to FreeBSD 1.X where hardware changes always required a reboot ? Right, I didn't think so... Maybe we *also* need to make some decisions about *how* we want this FDT stuff to work for us in practice? My summary of the situation: Everybody I have communicated with over the last couple of months have given me clear indication that nothing significant will happen on the RPi platform, which people see as inferior and not worth the/any effort. I don't entirely agree about that, I think RPi is a platform we as project ignore at our peril, so I have started to do a little bit of an effort, as I find time and information for it. You keep yelling at me for not adhering to an entirely undocumented design vision, which we don't even have a single compliant reference platform for yet. The stuff (clock manager, pin manager, runtime overlays) you are upset about me not using, does not exist on the RPi platform in FreeBSD at this point in time, which is why I don't use them. There is no documentation anywhere to be found, how to implement these hypothetical pieces of code, which is why I don't implement them. I am quite tempted to quote Gen. Patton on you and say "Lead me, Follow me, or get out of my way", but that would be a bit too rude. Instead I will repeat what I have already said to you several times: The moment the correct infrastructure appears on the RPi platform, if it ever does, I will change my driver to use that infrastructure. Until then, you are wasting everybodys time pointing accusingly into your book of unwritten rules. Poul-Henning -- = Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe = Never attribute to malice what can adequately be explained by incompetence= .
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?72042.1517094867>