From: Olof Johansson <olof@lixom.net>
To: Simon Horman <horms@verge.net.au>
Cc: Magnus Damm <magnus.damm@gmail.com>,
linux-sh@vger.kernel.org, khilman@linaro.org, arnd@arndb.de,
daniel.lezcano@linaro.org, linux-kernel@vger.kernel.org,
tglx@linutronix.de
Subject: Re: [PATCH/RFC] clocksource: Consolidate SH and ARM mach-shmobile Kconfig bits
Date: Mon, 07 Oct 2013 16:37:26 +0000 [thread overview]
Message-ID: <20131007163726.GC15413@quad.lixom.net> (raw)
In-Reply-To: <20130927044323.GC16541@verge.net.au>
On Fri, Sep 27, 2013 at 01:43:25PM +0900, Simon Horman wrote:
> On Thu, Sep 26, 2013 at 08:37:09AM +0900, Magnus Damm wrote:
> > From: Magnus Damm <damm@opensource.se>
> >
> > Based on request from Olof Johansson, move ARM mach-shmobile
> > clocksource entries to drivers/clocksource/Kconfig, and at
> > the same time make the SH architecture use these entries.
> >
> > Kconfig entries for CMT, MTU2, TMU and STI are with this patch
> > now kept in one place. The SH SYS_SUPPORTS_nnn bits are dropped
> > to simplye let the user select the appropriate ones using Kconfig
> > instead of trying to filter available timers based on SoC.
> >
> > Known issues:
> > 1) Not yet wrappend in menu/endmenu, populates the root driver menu
> > -> proposal: Create separate patch to wrap all the clocksource entries?
>
> That seems reasonable to me.
>
> > 2) Should the entries be sorted?
> > -> proposal: Ignore cosmetic bits
>
> I propose that you sort the entries are adding
> but leave the rest of the entries as is.
>
> > 3) What is correct dependency for multiplatform and single platform?
> > -> proposal: Perhaps we should simply default to no?
>
> I'm not sure that I understand the issue here.
>
> > 4) Is single patch across 2 architectures and drivers/clocksource OK?
> > -> proposal: Keep it like this if possible
>
> Olof, I would like your opinion on this but from my pov this seems
> reasonable. Especially as one of the architectures (sh) is seeing very little
> change at this time.
(Sorry for the delayed response, the renesas volume email can be large and
I don't always read it when it comes in).
Yeah, as long as you have appropriate acks and don't expect conflicts.
-Olof
WARNING: multiple messages have this Message-ID (diff)
From: Olof Johansson <olof@lixom.net>
To: Simon Horman <horms@verge.net.au>
Cc: Magnus Damm <magnus.damm@gmail.com>,
linux-sh@vger.kernel.org, khilman@linaro.org, arnd@arndb.de,
daniel.lezcano@linaro.org, linux-kernel@vger.kernel.org,
tglx@linutronix.de
Subject: Re: [PATCH/RFC] clocksource: Consolidate SH and ARM mach-shmobile Kconfig bits
Date: Mon, 7 Oct 2013 09:37:26 -0700 [thread overview]
Message-ID: <20131007163726.GC15413@quad.lixom.net> (raw)
In-Reply-To: <20130927044323.GC16541@verge.net.au>
On Fri, Sep 27, 2013 at 01:43:25PM +0900, Simon Horman wrote:
> On Thu, Sep 26, 2013 at 08:37:09AM +0900, Magnus Damm wrote:
> > From: Magnus Damm <damm@opensource.se>
> >
> > Based on request from Olof Johansson, move ARM mach-shmobile
> > clocksource entries to drivers/clocksource/Kconfig, and at
> > the same time make the SH architecture use these entries.
> >
> > Kconfig entries for CMT, MTU2, TMU and STI are with this patch
> > now kept in one place. The SH SYS_SUPPORTS_nnn bits are dropped
> > to simplye let the user select the appropriate ones using Kconfig
> > instead of trying to filter available timers based on SoC.
> >
> > Known issues:
> > 1) Not yet wrappend in menu/endmenu, populates the root driver menu
> > -> proposal: Create separate patch to wrap all the clocksource entries?
>
> That seems reasonable to me.
>
> > 2) Should the entries be sorted?
> > -> proposal: Ignore cosmetic bits
>
> I propose that you sort the entries are adding
> but leave the rest of the entries as is.
>
> > 3) What is correct dependency for multiplatform and single platform?
> > -> proposal: Perhaps we should simply default to no?
>
> I'm not sure that I understand the issue here.
>
> > 4) Is single patch across 2 architectures and drivers/clocksource OK?
> > -> proposal: Keep it like this if possible
>
> Olof, I would like your opinion on this but from my pov this seems
> reasonable. Especially as one of the architectures (sh) is seeing very little
> change at this time.
(Sorry for the delayed response, the renesas volume email can be large and
I don't always read it when it comes in).
Yeah, as long as you have appropriate acks and don't expect conflicts.
-Olof
next prev parent reply other threads:[~2013-10-07 16:37 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-09-25 23:37 [PATCH/RFC] clocksource: Consolidate SH and ARM mach-shmobile Kconfig bits Magnus Damm
2013-09-25 23:37 ` Magnus Damm
2013-09-27 4:43 ` Simon Horman
2013-09-27 4:43 ` Simon Horman
2013-10-07 16:37 ` Olof Johansson [this message]
2013-10-07 16:37 ` Olof Johansson
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=20131007163726.GC15413@quad.lixom.net \
--to=olof@lixom.net \
--cc=arnd@arndb.de \
--cc=daniel.lezcano@linaro.org \
--cc=horms@verge.net.au \
--cc=khilman@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-sh@vger.kernel.org \
--cc=magnus.damm@gmail.com \
--cc=tglx@linutronix.de \
/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 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.