From: Santosh Shilimkar <santosh.shilimkar@ti.com>
To: Nishanth Menon <nm@ti.com>
Cc: Linaro Kernel <linaro-kernel@lists.linaro.org>,
Russell King <linux@arm.linux.org.uk>,
Victor Kamensky <victor.kamensky@linaro.org>,
Tony Lindgren <tony@atomide.com>,
Taras Kondratiuk <taras.kondratiuk@linaro.org>,
Patch Tracking <patches@linaro.org>,
open list <linux-kernel@vger.kernel.org>,
Tero Kristo <t-kristo@ti.com>,
Linaro Networking <linaro-networking@linaro.org>,
"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] ARM: OMAP4: sleep: byteswap data for big-endian
Date: Tue, 14 Jan 2014 18:44:09 -0500 [thread overview]
Message-ID: <52D5CBC9.5020201@ti.com> (raw)
In-Reply-To: <CAGo_u6oGDK5s0SeE6Z7UFM6eYdgoy-E+Tj67+pBWP-wQ3r9=QA@mail.gmail.com>
On Tuesday 14 January 2014 04:13 PM, Nishanth Menon wrote:
> On Tue, Jan 14, 2014 at 3:03 PM, Santosh Shilimkar
> <santosh.shilimkar@ti.com> wrote:
>>
>>> ok.. some sort of Linaro thing about which I have no background about
>>> - but dont really care in this context.
>>>
>> Nothing related Linaro. Its just that platforms are supporting ARM BE
>> mode and Linaro folks had working patches for Panda. So I suggested
>> to get them on the lists.
>
> I tend to think -> is this with OFF mode and CPUidle completely
> working? All context save and restore works with this? on HS and GP
> devices with BE mode builds? works on SDP4430,60 variations,
> considered reuse with AM43xx which could use parts of that logic?
>
> I mean to indicate that terms like "works on panda" tends always to be relative.
>
Fair enough.
> It is nice to see it as a proof of concept, but I'd hate to see some
> dead code lying around in kernel and folks blindly following suit and
> introducing macros for new assembly for a feature that in practice
> just one group of folks care about and creates additional burden for
> rest of folks trying to keep that functionality going as we jump from
> one "device tree" style churn to another "framework"? Not to mean that
> good features should be kept away.. but personally, I could not find
> convincing arguments in this case..
>
I haven't looked at patch myself but as you pointed out if it adds
dead code and makes the code un-readable then probably that something
we shouldn't merge.
Regards,
Santosh
WARNING: multiple messages have this Message-ID (diff)
From: santosh.shilimkar@ti.com (Santosh Shilimkar)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] ARM: OMAP4: sleep: byteswap data for big-endian
Date: Tue, 14 Jan 2014 18:44:09 -0500 [thread overview]
Message-ID: <52D5CBC9.5020201@ti.com> (raw)
In-Reply-To: <CAGo_u6oGDK5s0SeE6Z7UFM6eYdgoy-E+Tj67+pBWP-wQ3r9=QA@mail.gmail.com>
On Tuesday 14 January 2014 04:13 PM, Nishanth Menon wrote:
> On Tue, Jan 14, 2014 at 3:03 PM, Santosh Shilimkar
> <santosh.shilimkar@ti.com> wrote:
>>
>>> ok.. some sort of Linaro thing about which I have no background about
>>> - but dont really care in this context.
>>>
>> Nothing related Linaro. Its just that platforms are supporting ARM BE
>> mode and Linaro folks had working patches for Panda. So I suggested
>> to get them on the lists.
>
> I tend to think -> is this with OFF mode and CPUidle completely
> working? All context save and restore works with this? on HS and GP
> devices with BE mode builds? works on SDP4430,60 variations,
> considered reuse with AM43xx which could use parts of that logic?
>
> I mean to indicate that terms like "works on panda" tends always to be relative.
>
Fair enough.
> It is nice to see it as a proof of concept, but I'd hate to see some
> dead code lying around in kernel and folks blindly following suit and
> introducing macros for new assembly for a feature that in practice
> just one group of folks care about and creates additional burden for
> rest of folks trying to keep that functionality going as we jump from
> one "device tree" style churn to another "framework"? Not to mean that
> good features should be kept away.. but personally, I could not find
> convincing arguments in this case..
>
I haven't looked at patch myself but as you pointed out if it adds
dead code and makes the code un-readable then probably that something
we shouldn't merge.
Regards,
Santosh
WARNING: multiple messages have this Message-ID (diff)
From: Santosh Shilimkar <santosh.shilimkar@ti.com>
To: Nishanth Menon <nm@ti.com>
Cc: Linaro Kernel <linaro-kernel@lists.linaro.org>,
Russell King <linux@arm.linux.org.uk>,
Patch Tracking <patches@linaro.org>,
Tony Lindgren <tony@atomide.com>,
Taras Kondratiuk <taras.kondratiuk@linaro.org>,
Victor Kamensky <victor.kamensky@linaro.org>,
open list <linux-kernel@vger.kernel.org>,
Tero Kristo <t-kristo@ti.com>,
Linaro Networking <linaro-networking@linaro.org>,
"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] ARM: OMAP4: sleep: byteswap data for big-endian
Date: Tue, 14 Jan 2014 18:44:09 -0500 [thread overview]
Message-ID: <52D5CBC9.5020201@ti.com> (raw)
In-Reply-To: <CAGo_u6oGDK5s0SeE6Z7UFM6eYdgoy-E+Tj67+pBWP-wQ3r9=QA@mail.gmail.com>
On Tuesday 14 January 2014 04:13 PM, Nishanth Menon wrote:
> On Tue, Jan 14, 2014 at 3:03 PM, Santosh Shilimkar
> <santosh.shilimkar@ti.com> wrote:
>>
>>> ok.. some sort of Linaro thing about which I have no background about
>>> - but dont really care in this context.
>>>
>> Nothing related Linaro. Its just that platforms are supporting ARM BE
>> mode and Linaro folks had working patches for Panda. So I suggested
>> to get them on the lists.
>
> I tend to think -> is this with OFF mode and CPUidle completely
> working? All context save and restore works with this? on HS and GP
> devices with BE mode builds? works on SDP4430,60 variations,
> considered reuse with AM43xx which could use parts of that logic?
>
> I mean to indicate that terms like "works on panda" tends always to be relative.
>
Fair enough.
> It is nice to see it as a proof of concept, but I'd hate to see some
> dead code lying around in kernel and folks blindly following suit and
> introducing macros for new assembly for a feature that in practice
> just one group of folks care about and creates additional burden for
> rest of folks trying to keep that functionality going as we jump from
> one "device tree" style churn to another "framework"? Not to mean that
> good features should be kept away.. but personally, I could not find
> convincing arguments in this case..
>
I haven't looked at patch myself but as you pointed out if it adds
dead code and makes the code un-readable then probably that something
we shouldn't merge.
Regards,
Santosh
next prev parent reply other threads:[~2014-01-14 23:44 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-13 15:03 [PATCH] ARM: OMAP4: sleep: byteswap data for big-endian Taras Kondratiuk
2014-01-13 15:03 ` Taras Kondratiuk
2014-01-13 15:23 ` Nishanth Menon
2014-01-13 15:23 ` Nishanth Menon
2014-01-13 15:23 ` Nishanth Menon
2014-01-14 11:14 ` Taras Kondratiuk
2014-01-14 11:14 ` Taras Kondratiuk
2014-01-14 15:51 ` Nishanth Menon
2014-01-14 15:51 ` Nishanth Menon
2014-01-14 15:51 ` Nishanth Menon
2014-01-14 17:35 ` Victor Kamensky
2014-01-14 17:35 ` Victor Kamensky
2014-01-14 17:56 ` Nishanth Menon
2014-01-14 17:56 ` Nishanth Menon
2014-01-14 19:21 ` Ben Dooks
2014-01-14 20:20 ` Victor Kamensky
2014-01-14 20:20 ` Victor Kamensky
2014-01-14 20:56 ` Nishanth Menon
2014-01-14 20:56 ` Nishanth Menon
2014-01-14 21:03 ` Santosh Shilimkar
2014-01-14 21:03 ` Santosh Shilimkar
2014-01-14 21:03 ` Santosh Shilimkar
2014-01-14 21:13 ` Nishanth Menon
2014-01-14 21:13 ` Nishanth Menon
2014-01-14 22:46 ` Taras Kondratiuk
2014-01-14 22:46 ` Taras Kondratiuk
2014-01-14 23:44 ` Santosh Shilimkar [this message]
2014-01-14 23:44 ` Santosh Shilimkar
2014-01-14 23:44 ` Santosh Shilimkar
2014-02-13 17:47 ` Tony Lindgren
2014-02-13 17:47 ` Tony Lindgren
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=52D5CBC9.5020201@ti.com \
--to=santosh.shilimkar@ti.com \
--cc=linaro-kernel@lists.linaro.org \
--cc=linaro-networking@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-omap@vger.kernel.org \
--cc=linux@arm.linux.org.uk \
--cc=nm@ti.com \
--cc=patches@linaro.org \
--cc=t-kristo@ti.com \
--cc=taras.kondratiuk@linaro.org \
--cc=tony@atomide.com \
--cc=victor.kamensky@linaro.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 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.