From owner-svn-src-all@freebsd.org Sat Jan 27 20:08:11 2018 Return-Path: Delivered-To: svn-src-all@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8B7E0EB6E93; Sat, 27 Jan 2018 20:08:11 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mail.blih.net (mail.blih.net [212.83.177.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.blih.net", Issuer "mail.blih.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id C753D779C9; Sat, 27 Jan 2018 20:08:10 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mail.blih.net (mail.blih.net [212.83.177.182]) by mail.blih.net (OpenSMTPD) with ESMTP id 57135f44; Sat, 27 Jan 2018 21:08:03 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=bidouilliste.com; h=date :from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; s=mail; bh=LBYW7FDTczNmR32XccB7/7H//00=; b=YdeG3lH4cDYVQWIfFg1UrMViwRoe YlcomAsx9/TRdUl8beaA3Fd/HXBJZr4CXjXZTN9lJx6S4HhUnq34cPk6QeikYLto HiXBUb64ZrIoTN95kRvhU/N3pwqzVmtuS8NNCr7ZKgXi4JLiGE/Y8bujnCKnB+qB s11TR9abv7zIUwE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=bidouilliste.com; h=date :from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; q=dns; s= mail; b=qN4HeGZFwTfn0Ngrf+cyF+9YKJJSVS/BuL4HzlZLCVH/wN8MMXJITJzi 78pdG5imzNJsQuoYR8ehQjA8SAhosBrw3VxjPrVWU6SmgUyA/kObbYFDzkh78JWn gexSBc3SvxuWD0Ql6ZGeF2TYmjLRdQQ/dk/tFFsAdK0MPAS78Bo= Received: from arcadia.home.blih.net (ip-9.net-89-3-105.rev.numericable.fr [89.3.105.9]) by mail.blih.net (OpenSMTPD) with ESMTPSA id aafb9562 TLS version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO; Sat, 27 Jan 2018 21:08:03 +0100 (CET) Date: Sat, 27 Jan 2018 21:08:01 +0100 From: Emmanuel Vadot To: "Poul-Henning Kamp" Cc: Warner Losh , John Baldwin , Ravi Pokala , src-committers , 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: <20180127210801.37b8001125dd0a2c92372f98@bidouilliste.com> In-Reply-To: <93949.1516733748@critter.freebsd.dk> References: <201801220710.w0M7AUm9091853@repo.freebsd.org> <90451.1516663240@critter.freebsd.dk> <2987003.eeGRFBb6N8@ralph.baldwin.cx> <93949.1516733748@critter.freebsd.dk> X-Mailer: Sylpheed 3.6.0 (GTK+ 2.24.31; amd64-portbld-freebsd12.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Jan 2018 20:08:11 -0000 So, almost a week after this commit, let's recap. - phk@ commit an hack to allow the pwm driver on rpi to always attach even if it's not enabled in the dts. - I say to him that it's a really bad move and that he should use dtb overlays (which thanks to kevans@ are in a really better state now). - His answer is that as long as you don't set the pwm sysctls you will be fine (which is true) and that he want to be able to load dtb overlays without rebooting (or a way to modify the existing dtb loaded in the kernel). - I reply that changing the dtb should go with overlays and that nobody is working on loading overlays at runtime. - His reply starts with "That doesn't make *any* UX sense." - The "problem" is we (FreeBSD) choose to followed the standard that is Flattened Device Tree and stick to it for arm (at least) platform. - phk@ says that if a user kldload the pwm driver on a rpi the pwm subsystem should be in a usable state. And doesn't want to talk anymore ("Over&Out). - jhb@ and imp@ talk about ways to improve the fdt subsystem. - ian@ point to phk@ that the 'status' line in the dts control more than a device but also pinmuxing (switching pins on the SoC to the correct function) and that is it done at startup and not at the driver attach. And that the rpi platform needs some love as it doesn't have a proper pinmux driver. - phk@ points out that there is no doc about doing a pinmux driver (which is true, unless you consider code as documentation or even help/advice from other arm developpers). But. - We still have this driver that doesn't follow the standard we said we want to adhere to. - Nobody except me explicitly request phk@ to revert his commit (which he didn't do). - One day after everything was back to normal and everybody forgot about this. So. - 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. - Even after some developpers point out that it wasn't the way to go he didn't revert his commit. And even he didn't say that he won't, his mail suggest that he will not. - Now we have a crappy driver in the tree. What's next ? Cheers, -- Emmanuel Vadot