From: "Cousson, Benoit" <b-cousson@ti.com>
To: "Ramirez Luna, Omar" <omar.ramirez@ti.com>
Cc: Tony Lindgren <tony@atomide.com>,
Hiroshi DOYU <Hiroshi.DOYU@nokia.com>,
Russell King <linux@arm.linux.org.uk>,
Felipe Contreras <felipe.contreras@gmail.com>,
Kevin Hilman <khilman@deeprootsystems.com>,
"Anna, Suman" <s-anna@ti.com>, Paul Walmsley <paul@pwsan.com>,
"Raja, Govindraj" <govindraj.raja@ti.com>,
"Varadarajan, Charulatha" <charu@ti.com>,
"C.A, Subramaniam" <subramaniam.ca@ti.com>,
"linux-omap@vger.kernel.org" <linux-omap@vger.kernel.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH v2 6/7] omap: mailbox: fix detection for previously supported chips
Date: Mon, 8 Nov 2010 16:43:39 -0500 [thread overview]
Message-ID: <4CD86F0B.6060402@ti.com> (raw)
In-Reply-To: <AANLkTin+oBj6CTpWKB9ZBYRVjR_8_tPcY_Y4+T5PecRA@mail.gmail.com>
On 11/7/2010 10:15 AM, Ramirez Luna, Omar wrote:
> On Sat, Nov 6, 2010 at 1:11 PM, Cousson, Benoit<b-cousson@ti.com> wrote:
>>> -#if defined(CONFIG_ARCH_OMAP3430)
>>> +#if defined(CONFIG_ARCH_OMAP3)
>>
>> Ideally you should get rid of all the CONFIG_ARCH_OMAPXXX or cpu_is_omap in
>> that code. This is a driver, it should be generic.
>> If you have to handle differences between OMAP version, please do that in
>> the devices, not in the driver.
>>
>> This patch just contains a few of them, but the original mailbox.c file is
>> full of that kind of test.
>> I know that you are not the original writer of this code, but since the
>> clean it, it will be good to remove all the legacy code.
>
> I mentioned it in the cover-letter, I should have put it here too, my bad.
>
> <quote>
> This is meant as a short term solution until proper cleanup is done,
> as suggested in:
>
> http://marc.info/?l=linux-arm-kernel&m=128534253231481&w=2
> </quote>
OK, sorry I didn't realized that this email thread was about the
mailbox. I'm glad to see that both Paul and Nishant are aligned with me.
> Does nobody care that the driver is not working right now for some
> chips (since it was working before!!) and are willing to wait for more
> time until the proper cleanup is done?
Sorry again, but removing these tests didn't not seems to be a huge task
for my point of view.
Anyway, if you want to do another phase and if everybody agree on that,
that's OK for me as well.
> For me it is a hassle, because if I need to do something on 3630 I
> have to merge this patch, then apply what I'm working into, then
> remove the patch, apply everything again to see no dependencies are
> there, then send.
Yeah, sometime life really sucks :-)
Benoit
WARNING: multiple messages have this Message-ID (diff)
From: b-cousson@ti.com (Cousson, Benoit)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2 6/7] omap: mailbox: fix detection for previously supported chips
Date: Mon, 8 Nov 2010 16:43:39 -0500 [thread overview]
Message-ID: <4CD86F0B.6060402@ti.com> (raw)
In-Reply-To: <AANLkTin+oBj6CTpWKB9ZBYRVjR_8_tPcY_Y4+T5PecRA@mail.gmail.com>
On 11/7/2010 10:15 AM, Ramirez Luna, Omar wrote:
> On Sat, Nov 6, 2010 at 1:11 PM, Cousson, Benoit<b-cousson@ti.com> wrote:
>>> -#if defined(CONFIG_ARCH_OMAP3430)
>>> +#if defined(CONFIG_ARCH_OMAP3)
>>
>> Ideally you should get rid of all the CONFIG_ARCH_OMAPXXX or cpu_is_omap in
>> that code. This is a driver, it should be generic.
>> If you have to handle differences between OMAP version, please do that in
>> the devices, not in the driver.
>>
>> This patch just contains a few of them, but the original mailbox.c file is
>> full of that kind of test.
>> I know that you are not the original writer of this code, but since the
>> clean it, it will be good to remove all the legacy code.
>
> I mentioned it in the cover-letter, I should have put it here too, my bad.
>
> <quote>
> This is meant as a short term solution until proper cleanup is done,
> as suggested in:
>
> http://marc.info/?l=linux-arm-kernel&m=128534253231481&w=2
> </quote>
OK, sorry I didn't realized that this email thread was about the
mailbox. I'm glad to see that both Paul and Nishant are aligned with me.
> Does nobody care that the driver is not working right now for some
> chips (since it was working before!!) and are willing to wait for more
> time until the proper cleanup is done?
Sorry again, but removing these tests didn't not seems to be a huge task
for my point of view.
Anyway, if you want to do another phase and if everybody agree on that,
that's OK for me as well.
> For me it is a hassle, because if I need to do something on 3630 I
> have to merge this patch, then apply what I'm working into, then
> remove the patch, apply everything again to see no dependencies are
> there, then send.
Yeah, sometime life really sucks :-)
Benoit
next prev parent reply other threads:[~2010-11-08 21:43 UTC|newest]
Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-11-06 1:17 [PATCH v2 0/7] omap: mailbox: hwmod support and dependent cleanup patches Omar Ramirez Luna
2010-11-06 1:17 ` Omar Ramirez Luna
2010-11-06 1:17 ` [PATCH v2 1/7] OMAP2: hwmod data: add mailbox data Omar Ramirez Luna
2010-11-06 1:17 ` Omar Ramirez Luna
2010-11-06 17:08 ` Cousson, Benoit
2010-11-06 17:08 ` Cousson, Benoit
2010-11-07 14:27 ` Ramirez Luna, Omar
2010-11-07 14:27 ` Ramirez Luna, Omar
2010-11-06 1:17 ` [PATCH v2 2/7] OMAP3: " Omar Ramirez Luna
2010-11-06 1:17 ` Omar Ramirez Luna
2010-11-06 1:17 ` [PATCH v2 3/7] OMAP4: " Omar Ramirez Luna
2010-11-06 1:17 ` Omar Ramirez Luna
2010-11-06 17:18 ` Cousson, Benoit
2010-11-06 17:18 ` Cousson, Benoit
2010-11-07 15:07 ` Ramirez Luna, Omar
2010-11-07 15:07 ` Ramirez Luna, Omar
2010-11-08 8:56 ` Cousson, Benoit
2010-11-08 8:56 ` Cousson, Benoit
2010-11-08 16:55 ` Ramirez Luna, Omar
2010-11-08 16:55 ` Ramirez Luna, Omar
2010-11-06 1:17 ` [PATCH v2 4/7] omap: mailbox: initial hwmod support Omar Ramirez Luna
2010-11-06 1:17 ` Omar Ramirez Luna
2010-11-06 17:44 ` Cousson, Benoit
2010-11-06 17:44 ` Cousson, Benoit
2010-11-06 1:17 ` [PATCH v2 5/7] omap: mailbox: add omap_device latency information Omar Ramirez Luna
2010-11-06 1:17 ` Omar Ramirez Luna
2010-11-06 18:09 ` Cousson, Benoit
2010-11-06 18:09 ` Cousson, Benoit
2010-11-06 1:17 ` [PATCH v2 6/7] omap: mailbox: fix detection for previously supported chips Omar Ramirez Luna
2010-11-06 1:17 ` Omar Ramirez Luna
2010-11-06 18:11 ` Cousson, Benoit
2010-11-06 18:11 ` Cousson, Benoit
2010-11-07 15:15 ` Ramirez Luna, Omar
2010-11-07 15:15 ` Ramirez Luna, Omar
2010-11-07 21:05 ` Felipe Contreras
2010-11-07 21:05 ` Felipe Contreras
2010-11-08 16:05 ` Ramirez Luna, Omar
2010-11-08 16:05 ` Ramirez Luna, Omar
2010-11-08 21:43 ` Cousson, Benoit [this message]
2010-11-08 21:43 ` Cousson, Benoit
2010-11-06 1:17 ` [PATCH v2 7/7] omap: mailbox: remove unreachable return Omar Ramirez Luna
2010-11-06 1:17 ` Omar Ramirez Luna
2010-11-06 18:21 ` Cousson, Benoit
2010-11-06 18:21 ` Cousson, Benoit
2010-11-07 15:18 ` Ramirez Luna, Omar
2010-11-07 15:18 ` Ramirez Luna, Omar
2010-11-06 18:32 ` [PATCH v2 0/7] omap: mailbox: hwmod support and dependent cleanup patches Cousson, Benoit
2010-11-06 18:32 ` Cousson, Benoit
2010-11-07 15:19 ` Ramirez Luna, Omar
2010-11-07 15:19 ` Ramirez Luna, Omar
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=4CD86F0B.6060402@ti.com \
--to=b-cousson@ti.com \
--cc=Hiroshi.DOYU@nokia.com \
--cc=charu@ti.com \
--cc=felipe.contreras@gmail.com \
--cc=govindraj.raja@ti.com \
--cc=khilman@deeprootsystems.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-omap@vger.kernel.org \
--cc=linux@arm.linux.org.uk \
--cc=omar.ramirez@ti.com \
--cc=paul@pwsan.com \
--cc=s-anna@ti.com \
--cc=subramaniam.ca@ti.com \
--cc=tony@atomide.com \
/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.