From: Wolfram Sang <wsa@the-dreams.de> To: linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH 3/4] clk: shmobile: add CPG driver for rz-platforms Date: Mon, 03 Mar 2014 16:27:31 +0000 [thread overview] Message-ID: <20140303162731.GA3732@katana> (raw) In-Reply-To: <1722697.3h0GnbWuD3@avalon> [-- Attachment #1: Type: text/plain, Size: 1085 bytes --] > While the parent is indeed selected at boot time only, and only one parent is > thus needed, parent selection could be performed by a DIP switch connected to > MD_CLK on the board for instance. In that case both parents should be > available in DT, as selection will be done by the kernel at boot time, not at > DT compile time. OK, I understand the case. I still wonder about specifying two parents, though. If a board uses USB_X1, it then has to spefify a dummy EXTAL clock (or an empty one), just because USB_X1 is enumerated as second entry? > > Again, now that I already coded it, what is the gain to remove it? The > > drawback is that other people might get encouraged to find reasons to > > allow them sloppy practices. > > It will make the kernel binary smaller by removing code that is not needed in > practice. Sounds like a micro-optimazation to me. If you insist, we should BUG() right away in that case, to make the code comprehensible. Returning with a leak and saying "we will probably fail somewhere" should really be avoided IMO. [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 836 bytes --]
WARNING: multiple messages have this Message-ID (diff)
From: wsa@the-dreams.de (Wolfram Sang) To: linux-arm-kernel@lists.infradead.org Subject: [PATCH 3/4] clk: shmobile: add CPG driver for rz-platforms Date: Mon, 3 Mar 2014 17:27:31 +0100 [thread overview] Message-ID: <20140303162731.GA3732@katana> (raw) In-Reply-To: <1722697.3h0GnbWuD3@avalon> > While the parent is indeed selected at boot time only, and only one parent is > thus needed, parent selection could be performed by a DIP switch connected to > MD_CLK on the board for instance. In that case both parents should be > available in DT, as selection will be done by the kernel at boot time, not at > DT compile time. OK, I understand the case. I still wonder about specifying two parents, though. If a board uses USB_X1, it then has to spefify a dummy EXTAL clock (or an empty one), just because USB_X1 is enumerated as second entry? > > Again, now that I already coded it, what is the gain to remove it? The > > drawback is that other people might get encouraged to find reasons to > > allow them sloppy practices. > > It will make the kernel binary smaller by removing code that is not needed in > practice. Sounds like a micro-optimazation to me. If you insist, we should BUG() right away in that case, to make the code comprehensible. Returning with a leak and saying "we will probably fail somewhere" should really be avoided IMO. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140303/059fadbc/attachment-0001.sig>
next prev parent reply other threads:[~2014-03-03 16:27 UTC|newest] Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top 2014-02-28 21:09 [PATCH 0/4] CCF support for Renesas r7s72100 Wolfram Sang 2014-02-28 21:09 ` Wolfram Sang 2014-02-28 21:09 ` [PATCH 1/4] ARM: r7s72100: add clock nodes to dtsi Wolfram Sang 2014-02-28 21:09 ` Wolfram Sang 2014-02-28 21:09 ` [PATCH 2/4] ARM: r7s72100: genmai: populate extal clock node Wolfram Sang 2014-02-28 21:09 ` Wolfram Sang 2014-02-28 21:09 ` [PATCH 3/4] clk: shmobile: add CPG driver for rz-platforms Wolfram Sang 2014-02-28 21:09 ` Wolfram Sang 2014-03-02 22:15 ` Laurent Pinchart 2014-03-02 22:15 ` Laurent Pinchart 2014-03-03 9:19 ` Wolfram Sang 2014-03-03 9:19 ` Wolfram Sang 2014-03-03 10:59 ` Laurent Pinchart 2014-03-03 10:59 ` Laurent Pinchart 2014-03-03 16:27 ` Wolfram Sang [this message] 2014-03-03 16:27 ` Wolfram Sang 2014-03-04 11:02 ` Laurent Pinchart 2014-03-04 11:02 ` Laurent Pinchart 2014-03-04 11:07 ` Wolfram Sang 2014-03-04 11:07 ` Wolfram Sang 2014-03-04 11:13 ` Laurent Pinchart 2014-03-04 11:13 ` Laurent Pinchart 2014-03-04 11:56 ` Wolfram Sang 2014-03-04 11:56 ` Wolfram Sang 2014-03-05 13:54 ` Wolfram Sang 2014-03-05 13:54 ` Wolfram Sang 2014-03-05 13:59 ` Laurent Pinchart 2014-03-05 13:59 ` Laurent Pinchart 2014-03-05 15:07 ` Wolfram Sang 2014-03-05 15:07 ` Wolfram Sang 2014-02-28 21:09 ` [PATCH 4/4] ARM: shmobile: r7s72100: use workaround for non DT-clocks Wolfram Sang 2014-02-28 21:09 ` Wolfram Sang 2014-03-02 22:21 ` Laurent Pinchart 2014-03-02 22:21 ` Laurent Pinchart 2014-03-03 9:22 ` Wolfram Sang 2014-03-03 9:22 ` Wolfram Sang 2014-03-03 10:58 ` Laurent Pinchart 2014-03-03 11:00 ` Laurent Pinchart
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=20140303162731.GA3732@katana \ --to=wsa@the-dreams.de \ --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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.