Fix obvious typo introduced in commit
e121aefa7d9f10eee5cf26ed47129237a05d940b ("remoteproc: fix missing
CONFIG_FW_LOADER configurations").
Signed-off-by: Paul Bolle <[email protected]>
---
0) Untested.
1) The REMOTEPROC Kconfig entry has been using the useless FW_CONFIG
select statement for a few releases now. Does it really need to select
FW_LOADER?
drivers/remoteproc/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
index cc1f7bf..c6d77e2 100644
--- a/drivers/remoteproc/Kconfig
+++ b/drivers/remoteproc/Kconfig
@@ -4,7 +4,7 @@ menu "Remoteproc drivers"
config REMOTEPROC
tristate
depends on HAS_DMA
- select FW_CONFIG
+ select FW_LOADER
select VIRTIO
config OMAP_REMOTEPROC
--
1.7.11.7
On Tue, Mar 05, 2013 at 08:20:48PM +0100, Paul Bolle wrote:
> Fix obvious typo introduced in commit
> e121aefa7d9f10eee5cf26ed47129237a05d940b ("remoteproc: fix missing
> CONFIG_FW_LOADER configurations").
>
> Signed-off-by: Paul Bolle <[email protected]>
> ---
> 0) Untested.
>
> 1) The REMOTEPROC Kconfig entry has been using the useless FW_CONFIG
> select statement for a few releases now. Does it really need to select
> FW_LOADER?
>
> drivers/remoteproc/Kconfig | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
<formletter>
This is not the correct way to submit patches for inclusion in the
stable kernel tree. Please read Documentation/stable_kernel_rules.txt
for how to do this properly.
</formletter>
On Wed, 2013-03-06 at 05:54 +0800, Greg KH wrote:
> This is not the correct way to submit patches for inclusion in the
> stable kernel tree. Please read Documentation/stable_kernel_rules.txt
> for how to do this properly.
0) Actually I just copied the addresses included in commit
e121aefa7d9f10eee5cf26ed47129237a05d940b upstream without really
thinking.
1) But actually thinking about this: that upstream commit did end up in
the (longterm) v3.4.y series. And my patch is also relevant for the
v3.8.y series. Can't this patch, that fixes an obviously bogus commit,
which was important enough for stable, be itself submitted with
CC:stable?
Paul Bolle
On Tue, Mar 05, 2013 at 11:22:49PM +0100, Paul Bolle wrote:
> On Wed, 2013-03-06 at 05:54 +0800, Greg KH wrote:
> > This is not the correct way to submit patches for inclusion in the
> > stable kernel tree. Please read Documentation/stable_kernel_rules.txt
> > for how to do this properly.
>
> 0) Actually I just copied the addresses included in commit
> e121aefa7d9f10eee5cf26ed47129237a05d940b upstream without really
> thinking.
>
> 1) But actually thinking about this: that upstream commit did end up in
> the (longterm) v3.4.y series. And my patch is also relevant for the
> v3.8.y series.
As that patch was in the 3.5-rc7 release, how can it be relevant for
3.8, or anything greater than 3.5 at all?
> Can't this patch, that fixes an obviously bogus commit,
> which was important enough for stable, be itself submitted with
> CC:stable?
How can you expect me to apply something that is already in the tree? :)
thanks,
greg k-h
On Wed, 2013-03-06 at 08:46 +0800, Greg KH wrote:
> On Tue, Mar 05, 2013 at 11:22:49PM +0100, Paul Bolle wrote:
> > 1) But actually thinking about this: that upstream commit did end up in
> > the (longterm) v3.4.y series. And my patch is also relevant for the
> > v3.8.y series.
>
> As that patch was in the 3.5-rc7 release, how can it be relevant for
> 3.8, or anything greater than 3.5 at all?
I seem to have confused you. My patch fixes a bug caused by a commit
that shipped in final release v3.5 (and is also part the 3.4.y series,
because that commit got added to that stable series).
> > Can't this patch, that fixes an obviously bogus commit,
> > which was important enough for stable, be itself submitted with
> > CC:stable?
>
> How can you expect me to apply something that is already in the tree? :)
It's not (yet) in the tree but fixes something that is in the tree.
Paul Bolle
On Wed, Mar 06, 2013 at 08:53:22AM +0100, Paul Bolle wrote:
> On Wed, 2013-03-06 at 08:46 +0800, Greg KH wrote:
> > On Tue, Mar 05, 2013 at 11:22:49PM +0100, Paul Bolle wrote:
> > > 1) But actually thinking about this: that upstream commit did end up in
> > > the (longterm) v3.4.y series. And my patch is also relevant for the
> > > v3.8.y series.
> >
> > As that patch was in the 3.5-rc7 release, how can it be relevant for
> > 3.8, or anything greater than 3.5 at all?
>
> I seem to have confused you. My patch fixes a bug caused by a commit
> that shipped in final release v3.5 (and is also part the 3.4.y series,
> because that commit got added to that stable series).
What commit are you talking about here? Please read
Documentation/stable_kernel_rules.txt for how to have a patch applied to
the stable kernel releases.
Hint, this isn't how you do it...
greg k-h
Hi,
On Tue, Mar 5, 2013 at 9:20 PM, Paul Bolle <[email protected]> wrote:
> Fix obvious typo introduced in commit
> e121aefa7d9f10eee5cf26ed47129237a05d940b ("remoteproc: fix missing
> CONFIG_FW_LOADER configurations").
Robert Tivy (cc'ed) already submitted a patch to this (it's part of a
bigger series Robert is now polishing).
Rob, it might indeed be a good idea to add "CC:
[email protected]" to the commit log.
Thanks,
Ohad.
On Wed, 2013-03-06 at 14:32 +0200, Ohad Ben-Cohen wrote:
> Robert Tivy (cc'ed) already submitted a patch to this (it's part of a
> bigger series Robert is now polishing).
Great.
> Rob, it might indeed be a good idea to add "CC:
> [email protected]" to the commit log.
Thanks,
Paul Bolle