From: thierry.reding@gmail.com (Thierry Reding)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 8/8] clk: tegra: Add EMC clock driver
Date: Fri, 1 Aug 2014 10:40:04 +0200 [thread overview]
Message-ID: <20140801084003.GA21724@ulmo> (raw)
In-Reply-To: <20140731190659.4463.92139@quantum>
On Thu, Jul 31, 2014 at 12:06:59PM -0700, Mike Turquette wrote:
> Quoting Thierry Reding (2014-07-30 02:34:57)
[...]
> > Not merging this feature upstream won't stop anybody from implementing
> > it as a hack in Android/product kernels either. If it's useful then
> > somebody will implement it in whatever downstream kernel they use. And
> > if it's useful to more than one vendor then we'll end up with a copy of
> > the implementation (and derivations on top) in each vendor's tree.
>
> Thierry,
>
> That argument is not sufficient to merit merging code. There is all
> kinds of wacky downstream code that gets duplicated by various hardware
> vendors, Linux distributions, the Cyanogenmod community, etc. Should we
> merge any piece of downstream code just because more than one person
> wants to use it?
Of course not. And that wasn't my point. My point was that if people
want to implement hacks as shortcuts and avoid the work involved in
doing things properly, then they will find ways to do so irrespective
of whether code can be merged upstream or not.
But we're talking about a debugfs interface here. It was designed to be
used to make life easier for *developers* and provide a way to make it
easier to debug problems. I've certainly been in a situation a couple of
times where I wished this kind of knob had been available to avoid
rebuilding the kernel and rebooting just to tune some clock frequency to
see if it would make things work.
> > debugfs requires superuser privileges anyway, in which case you could
> > equally well write userspace software that directly bangs on the clock
> > controller registers.
>
> Sure. There are lots of technical reasons why this isn't such a bad idea
> (e.g. you need admin privileges, we shouldn't ship devices with debugfs
> turned on, etc). But by merging it we tell people, "hey, this is an OK
> thing to do", which it is not.
I disagree. What we'd be telling people is: "Here's a bunch of knobs
that you can use to play around with clock frequencies for *debugging*
purposes." Using debugfs is never an OK thing to do for production
software. But I don't think you'll prevent people from doing stupid
things by limiting what a debug interface can do. The only thing you'll
achieve is to make it more difficult for people who want to use it the
right way.
Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140801/e2d68350/attachment.sig>
next prev parent reply other threads:[~2014-08-01 8:40 UTC|newest]
Thread overview: 53+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-11 14:18 [PATCH 0/8] Tegra124 EMC (external memory controller) support Mikko Perttunen
2014-07-11 14:18 ` [PATCH 1/8] clk: tegra124: Remove old emc_mux and emc clocks Mikko Perttunen
2014-07-11 14:18 ` [PATCH 2/8] ARM: tegra: Remove TEGRA124_CLK_EMC from tegra124-car.h Mikko Perttunen
2014-07-21 22:37 ` Stephen Warren
2014-07-29 8:28 ` Mikko Perttunen
2014-07-11 14:18 ` [PATCH 3/8] ARM: tegra: Add PLL_M_UD and PLL_C_UD to tegra124-car binding header Mikko Perttunen
2014-08-25 17:41 ` Stephen Warren
2014-09-17 13:41 ` Peter De Schrijver
2014-07-11 14:18 ` [PATCH 4/8] clk: tegra124: Add PLL_M_UD and PLL_C_UD clocks Mikko Perttunen
2014-07-11 14:18 ` [PATCH 5/8] of: Add Tegra124 EMC bindings Mikko Perttunen
2014-07-11 14:51 ` Thierry Reding
2014-07-11 16:01 ` Mikko Perttunen
2014-07-14 7:55 ` Mikko Perttunen
2014-07-14 8:15 ` Thierry Reding
2014-07-14 9:06 ` Mikko Perttunen
2014-07-14 9:31 ` Thierry Reding
2014-07-14 9:57 ` Mikko Perttunen
2014-07-14 10:29 ` Thierry Reding
2014-07-14 10:54 ` Mikko Perttunen
2014-07-14 11:10 ` Thierry Reding
2014-07-14 12:28 ` Mikko Perttunen
2014-07-11 16:43 ` Andrew Bresticker
2014-07-11 16:48 ` Mikko Perttunen
2014-07-21 21:28 ` Stephen Warren
2014-07-21 22:52 ` Andrew Bresticker
2014-07-22 16:45 ` Stephen Warren
2014-07-22 17:22 ` Andrew Bresticker
2014-07-22 17:34 ` Stephen Warren
2014-07-29 8:30 ` Mikko Perttunen
2014-07-29 15:49 ` Stephen Warren
2014-07-31 10:48 ` Mikko Perttunen
2014-07-31 11:05 ` Mikko Perttunen
2014-07-31 15:32 ` Stephen Warren
2014-07-21 22:36 ` Stephen Warren
2014-07-11 14:18 ` [PATCH 6/8] ARM: tegra: Add EMC to Tegra124 device tree Mikko Perttunen
2014-07-11 14:18 ` [PATCH 7/8] ARM: tegra: Add EMC timings to Jetson TK1 " Mikko Perttunen
2014-07-11 14:18 ` [PATCH 8/8] clk: tegra: Add EMC clock driver Mikko Perttunen
2014-07-22 16:57 ` Stephen Warren
2014-07-29 8:47 ` Mikko Perttunen
2014-07-29 20:19 ` Mike Turquette
2014-07-29 22:14 ` Stephen Warren
2014-07-30 9:34 ` Thierry Reding
2014-07-31 19:06 ` Mike Turquette
2014-07-31 19:53 ` Stephen Warren
2014-07-31 23:08 ` Mike Turquette
2014-08-01 6:31 ` Mikko Perttunen
2014-08-01 8:40 ` Thierry Reding [this message]
2014-08-25 17:40 ` [PATCH 0/8] Tegra124 EMC (external memory controller) support Stephen Warren
2014-08-26 7:42 ` Mikko Perttunen
2014-08-26 7:47 ` Thierry Reding
2014-08-26 8:02 ` Mikko Perttunen
2014-09-05 10:22 ` Tomeu Vizoso
2014-09-05 10:55 ` Mikko Perttunen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20140801084003.GA21724@ulmo \
--to=thierry.reding@gmail.com \
--cc=linux-arm-kernel@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).