* [PATCH 0/1] coresight: Fix for v5.3-rc3 @ 2019-08-01 17:23 Mathieu Poirier 2019-08-01 17:23 ` [PATCH 1/1] coresight: Fix DEBUG_LOCKS_WARN_ON for uninitialized attribute Mathieu Poirier 2019-08-01 18:17 ` [PATCH 0/1] coresight: Fix for v5.3-rc3 Greg KH 0 siblings, 2 replies; 9+ messages in thread From: Mathieu Poirier @ 2019-08-01 17:23 UTC (permalink / raw) To: gregkh; +Cc: linux-arm-kernel, suzuki.poulose Good morning Greg, Here is a fix I'd like you to consider for this cycle. Do you think you could apply it to driver-core-next rather than char-misc-next? My current coresight branch is based on driver-core-next to pick up Suzuki's generic device lookup helpers patchset [1]. Applying it to char-misc-next will create two different signature for the same patch, something that gives Stephen a hard time when building the linux-next tree. I also think this patch should go in stable but haven't marked it as such since it doesn't apply to any of the stable trees. Once it is part of v5.3 I intend to send a new version of the patch that does apply cleanly to those trees. Let me know if you want me to proceed differently. Thanks, Mathieu [1]. https://www.spinics.net/lists/dri-devel/msg219674.html Suzuki K Poulose (1): coresight: Fix DEBUG_LOCKS_WARN_ON for uninitialized attribute drivers/hwtracing/coresight/coresight-etm-perf.c | 1 + 1 file changed, 1 insertion(+) -- 2.17.1 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 9+ messages in thread
* [PATCH 1/1] coresight: Fix DEBUG_LOCKS_WARN_ON for uninitialized attribute 2019-08-01 17:23 [PATCH 0/1] coresight: Fix for v5.3-rc3 Mathieu Poirier @ 2019-08-01 17:23 ` Mathieu Poirier 2019-08-01 18:50 ` Greg KH 2019-08-01 18:17 ` [PATCH 0/1] coresight: Fix for v5.3-rc3 Greg KH 1 sibling, 1 reply; 9+ messages in thread From: Mathieu Poirier @ 2019-08-01 17:23 UTC (permalink / raw) To: gregkh; +Cc: linux-arm-kernel, suzuki.poulose From: Suzuki K Poulose <suzuki.poulose@arm.com> While running the linux-next with CONFIG_DEBUG_LOCKS_ALLOC enabled, I get the following splat. BUG: key ffffcb5636929298 has not been registered! ------------[ cut here ]------------ DEBUG_LOCKS_WARN_ON(1) WARNING: CPU: 1 PID: 53 at kernel/locking/lockdep.c:3669 lockdep_init_map+0x164/0x1f0 CPU: 1 PID: 53 Comm: kworker/1:1 Tainted: G W 5.2.0-next-20190712-00015-g00ad4634222e-dirty #603 Workqueue: events amba_deferred_retry_func pstate: 60c00005 (nZCv daif +PAN +UAO) pc : lockdep_init_map+0x164/0x1f0 lr : lockdep_init_map+0x164/0x1f0 [ trimmed ] Call trace: lockdep_init_map+0x164/0x1f0 __kernfs_create_file+0x9c/0x158 sysfs_add_file_mode_ns+0xa8/0x1d0 sysfs_add_file_to_group+0x88/0xd8 etm_perf_add_symlink_sink+0xcc/0x138 coresight_register+0x110/0x280 tmc_probe+0x160/0x420 [ trimmed ] ---[ end trace ab4cc669615ba1b0 ]--- Fix this by initialising the dynamically allocated attribute properly. Cc: Mathieu Poirier <mathieu.poirier@linaro.org> Fixes: bb8e370bdc141ddf ("coresight: perf: Add "sinks" group to PMU directory") Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com> [Fixed a typograhic error in the changelog] Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org> --- drivers/hwtracing/coresight/coresight-etm-perf.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/hwtracing/coresight/coresight-etm-perf.c b/drivers/hwtracing/coresight/coresight-etm-perf.c index 5c1ca0df5cb0..84f1dcb69827 100644 --- a/drivers/hwtracing/coresight/coresight-etm-perf.c +++ b/drivers/hwtracing/coresight/coresight-etm-perf.c @@ -544,6 +544,7 @@ int etm_perf_add_symlink_sink(struct coresight_device *csdev) /* See function coresight_get_sink_by_id() to know where this is used */ hash = hashlen_hash(hashlen_string(NULL, name)); + sysfs_attr_init(&ea->attr.attr); ea->attr.attr.name = devm_kstrdup(dev, name, GFP_KERNEL); if (!ea->attr.attr.name) return -ENOMEM; -- 2.17.1 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply related [flat|nested] 9+ messages in thread
* Re: [PATCH 1/1] coresight: Fix DEBUG_LOCKS_WARN_ON for uninitialized attribute 2019-08-01 17:23 ` [PATCH 1/1] coresight: Fix DEBUG_LOCKS_WARN_ON for uninitialized attribute Mathieu Poirier @ 2019-08-01 18:50 ` Greg KH 2019-08-01 20:20 ` Mathieu Poirier 0 siblings, 1 reply; 9+ messages in thread From: Greg KH @ 2019-08-01 18:50 UTC (permalink / raw) To: Mathieu Poirier; +Cc: linux-arm-kernel, suzuki.poulose On Thu, Aug 01, 2019 at 11:23:23AM -0600, Mathieu Poirier wrote: > From: Suzuki K Poulose <suzuki.poulose@arm.com> > > While running the linux-next with CONFIG_DEBUG_LOCKS_ALLOC enabled, > I get the following splat. > > BUG: key ffffcb5636929298 has not been registered! > ------------[ cut here ]------------ > DEBUG_LOCKS_WARN_ON(1) > WARNING: CPU: 1 PID: 53 at kernel/locking/lockdep.c:3669 lockdep_init_map+0x164/0x1f0 > CPU: 1 PID: 53 Comm: kworker/1:1 Tainted: G W 5.2.0-next-20190712-00015-g00ad4634222e-dirty #603 > Workqueue: events amba_deferred_retry_func > pstate: 60c00005 (nZCv daif +PAN +UAO) > pc : lockdep_init_map+0x164/0x1f0 > lr : lockdep_init_map+0x164/0x1f0 > > [ trimmed ] > > Call trace: > lockdep_init_map+0x164/0x1f0 > __kernfs_create_file+0x9c/0x158 > sysfs_add_file_mode_ns+0xa8/0x1d0 > sysfs_add_file_to_group+0x88/0xd8 > etm_perf_add_symlink_sink+0xcc/0x138 > coresight_register+0x110/0x280 > tmc_probe+0x160/0x420 > > [ trimmed ] > > ---[ end trace ab4cc669615ba1b0 ]--- > > Fix this by initialising the dynamically allocated attribute properly. > > Cc: Mathieu Poirier <mathieu.poirier@linaro.org> > Fixes: bb8e370bdc141ddf ("coresight: perf: Add "sinks" group to PMU directory") That should be: Fixes: bb8e370bdc14 ("coresight: perf: Add "sinks" group to PMU directory") I can go fix it up... _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH 1/1] coresight: Fix DEBUG_LOCKS_WARN_ON for uninitialized attribute 2019-08-01 18:50 ` Greg KH @ 2019-08-01 20:20 ` Mathieu Poirier 2019-08-01 20:26 ` Greg KH 0 siblings, 1 reply; 9+ messages in thread From: Mathieu Poirier @ 2019-08-01 20:20 UTC (permalink / raw) To: Greg KH; +Cc: linux-arm-kernel, Suzuki K. Poulose On Thu, 1 Aug 2019 at 12:50, Greg KH <gregkh@linuxfoundation.org> wrote: > > On Thu, Aug 01, 2019 at 11:23:23AM -0600, Mathieu Poirier wrote: > > From: Suzuki K Poulose <suzuki.poulose@arm.com> > > > > While running the linux-next with CONFIG_DEBUG_LOCKS_ALLOC enabled, > > I get the following splat. > > > > BUG: key ffffcb5636929298 has not been registered! > > ------------[ cut here ]------------ > > DEBUG_LOCKS_WARN_ON(1) > > WARNING: CPU: 1 PID: 53 at kernel/locking/lockdep.c:3669 lockdep_init_map+0x164/0x1f0 > > CPU: 1 PID: 53 Comm: kworker/1:1 Tainted: G W 5.2.0-next-20190712-00015-g00ad4634222e-dirty #603 > > Workqueue: events amba_deferred_retry_func > > pstate: 60c00005 (nZCv daif +PAN +UAO) > > pc : lockdep_init_map+0x164/0x1f0 > > lr : lockdep_init_map+0x164/0x1f0 > > > > [ trimmed ] > > > > Call trace: > > lockdep_init_map+0x164/0x1f0 > > __kernfs_create_file+0x9c/0x158 > > sysfs_add_file_mode_ns+0xa8/0x1d0 > > sysfs_add_file_to_group+0x88/0xd8 > > etm_perf_add_symlink_sink+0xcc/0x138 > > coresight_register+0x110/0x280 > > tmc_probe+0x160/0x420 > > > > [ trimmed ] > > > > ---[ end trace ab4cc669615ba1b0 ]--- > > > > Fix this by initialising the dynamically allocated attribute properly. > > > > Cc: Mathieu Poirier <mathieu.poirier@linaro.org> > > Fixes: bb8e370bdc141ddf ("coresight: perf: Add "sinks" group to PMU directory") > > That should be: > Fixes: bb8e370bdc14 ("coresight: perf: Add "sinks" group to PMU directory") Apologies - I will catch those from hereon. > > I can go fix it up... Or I can, depending on if you're going to pick the patch as a fix for 5.3 or you'll wait for the 5.4 cycle. > _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH 1/1] coresight: Fix DEBUG_LOCKS_WARN_ON for uninitialized attribute 2019-08-01 20:20 ` Mathieu Poirier @ 2019-08-01 20:26 ` Greg KH 0 siblings, 0 replies; 9+ messages in thread From: Greg KH @ 2019-08-01 20:26 UTC (permalink / raw) To: Mathieu Poirier; +Cc: linux-arm-kernel, Suzuki K. Poulose On Thu, Aug 01, 2019 at 02:20:39PM -0600, Mathieu Poirier wrote: > On Thu, 1 Aug 2019 at 12:50, Greg KH <gregkh@linuxfoundation.org> wrote: > > > > On Thu, Aug 01, 2019 at 11:23:23AM -0600, Mathieu Poirier wrote: > > > From: Suzuki K Poulose <suzuki.poulose@arm.com> > > > > > > While running the linux-next with CONFIG_DEBUG_LOCKS_ALLOC enabled, > > > I get the following splat. > > > > > > BUG: key ffffcb5636929298 has not been registered! > > > ------------[ cut here ]------------ > > > DEBUG_LOCKS_WARN_ON(1) > > > WARNING: CPU: 1 PID: 53 at kernel/locking/lockdep.c:3669 lockdep_init_map+0x164/0x1f0 > > > CPU: 1 PID: 53 Comm: kworker/1:1 Tainted: G W 5.2.0-next-20190712-00015-g00ad4634222e-dirty #603 > > > Workqueue: events amba_deferred_retry_func > > > pstate: 60c00005 (nZCv daif +PAN +UAO) > > > pc : lockdep_init_map+0x164/0x1f0 > > > lr : lockdep_init_map+0x164/0x1f0 > > > > > > [ trimmed ] > > > > > > Call trace: > > > lockdep_init_map+0x164/0x1f0 > > > __kernfs_create_file+0x9c/0x158 > > > sysfs_add_file_mode_ns+0xa8/0x1d0 > > > sysfs_add_file_to_group+0x88/0xd8 > > > etm_perf_add_symlink_sink+0xcc/0x138 > > > coresight_register+0x110/0x280 > > > tmc_probe+0x160/0x420 > > > > > > [ trimmed ] > > > > > > ---[ end trace ab4cc669615ba1b0 ]--- > > > > > > Fix this by initialising the dynamically allocated attribute properly. > > > > > > Cc: Mathieu Poirier <mathieu.poirier@linaro.org> > > > Fixes: bb8e370bdc141ddf ("coresight: perf: Add "sinks" group to PMU directory") > > > > That should be: > > Fixes: bb8e370bdc14 ("coresight: perf: Add "sinks" group to PMU directory") > > Apologies - I will catch those from hereon. > > > > > I can go fix it up... > > Or I can, depending on if you're going to pick the patch as a fix for > 5.3 or you'll wait for the 5.4 cycle. It's already queued up for my next round of patches to Linus to be during the 5.3-rc cycle. thanks, greg k-h _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH 0/1] coresight: Fix for v5.3-rc3 2019-08-01 17:23 [PATCH 0/1] coresight: Fix for v5.3-rc3 Mathieu Poirier 2019-08-01 17:23 ` [PATCH 1/1] coresight: Fix DEBUG_LOCKS_WARN_ON for uninitialized attribute Mathieu Poirier @ 2019-08-01 18:17 ` Greg KH 2019-08-01 20:16 ` Mathieu Poirier 1 sibling, 1 reply; 9+ messages in thread From: Greg KH @ 2019-08-01 18:17 UTC (permalink / raw) To: Mathieu Poirier; +Cc: linux-arm-kernel, suzuki.poulose On Thu, Aug 01, 2019 at 11:23:22AM -0600, Mathieu Poirier wrote: > Good morning Greg, > > Here is a fix I'd like you to consider for this cycle. Do you think you > could apply it to driver-core-next rather than char-misc-next? All of my -next branches are for 5.4-rc1, not 5.3 (i.e. the "next" kernel). So either one of them isn't going to matter to you for 5.3-final. > My current > coresight branch is based on driver-core-next to pick up Suzuki's > generic device lookup helpers patchset [1]. Applying it to char-misc-next > will create two different signature for the same patch, something that > gives Stephen a hard time when building the linux-next tree. Why would Suzuki's patch matter for 5.3-final? > I also think this patch should go in stable but haven't marked it as such since > it doesn't apply to any of the stable trees. Once it is part of v5.3 I intend > to send a new version of the patch that does apply cleanly to those trees. Let > me know if you want me to proceed differently. > > Thanks, > Mathieu > > [1]. https://www.spinics.net/lists/dri-devel/msg219674.html > > > Suzuki K Poulose (1): > coresight: Fix DEBUG_LOCKS_WARN_ON for uninitialized attribute > > drivers/hwtracing/coresight/coresight-etm-perf.c | 1 + > 1 file changed, 1 insertion(+) Why would this patch depend on anything in any of my trees? totally confused, greg k-h _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH 0/1] coresight: Fix for v5.3-rc3 2019-08-01 18:17 ` [PATCH 0/1] coresight: Fix for v5.3-rc3 Greg KH @ 2019-08-01 20:16 ` Mathieu Poirier 2019-08-02 9:10 ` Greg KH 0 siblings, 1 reply; 9+ messages in thread From: Mathieu Poirier @ 2019-08-01 20:16 UTC (permalink / raw) To: Greg KH; +Cc: linux-arm-kernel, Suzuki K. Poulose On Thu, 1 Aug 2019 at 12:17, Greg KH <gregkh@linuxfoundation.org> wrote: > > On Thu, Aug 01, 2019 at 11:23:22AM -0600, Mathieu Poirier wrote: > > Good morning Greg, > > > > Here is a fix I'd like you to consider for this cycle. Do you think you > > could apply it to driver-core-next rather than char-misc-next? > > All of my -next branches are for 5.4-rc1, not 5.3 (i.e. the "next" > kernel). > > So either one of them isn't going to matter to you for 5.3-final. > > > My current > > coresight branch is based on driver-core-next to pick up Suzuki's > > generic device lookup helpers patchset [1]. Applying it to char-misc-next > > will create two different signature for the same patch, something that > > gives Stephen a hard time when building the linux-next tree. > > Why would Suzuki's patch matter for 5.3-final? There was a similar situation during the 5.2 cycle [1]. Here too we can fix a problem that is present in 5.3 rather than wait for 5.4. [1]. https://www.spinics.net/lists/arm-kernel/msg736274.html > > > I also think this patch should go in stable but haven't marked it as such since > > it doesn't apply to any of the stable trees. Once it is part of v5.3 I intend > > to send a new version of the patch that does apply cleanly to those trees. Let > > me know if you want me to proceed differently. > > > > Thanks, > > Mathieu > > > > [1]. https://www.spinics.net/lists/dri-devel/msg219674.html > > > > > > Suzuki K Poulose (1): > > coresight: Fix DEBUG_LOCKS_WARN_ON for uninitialized attribute > > > > drivers/hwtracing/coresight/coresight-etm-perf.c | 1 + > > 1 file changed, 1 insertion(+) > > Why would this patch depend on anything in any of my trees? I send you patches for inclusion in the next cycle and as such I thought it should be the same for fixes in the current cycle. If that is not the case, should I send them directly to Linus? Thanks, Mathieu _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH 0/1] coresight: Fix for v5.3-rc3 2019-08-01 20:16 ` Mathieu Poirier @ 2019-08-02 9:10 ` Greg KH 2019-08-04 13:26 ` Mathieu Poirier 0 siblings, 1 reply; 9+ messages in thread From: Greg KH @ 2019-08-02 9:10 UTC (permalink / raw) To: Mathieu Poirier; +Cc: linux-arm-kernel, Suzuki K. Poulose On Thu, Aug 01, 2019 at 02:16:46PM -0600, Mathieu Poirier wrote: > On Thu, 1 Aug 2019 at 12:17, Greg KH <gregkh@linuxfoundation.org> wrote: > > > > On Thu, Aug 01, 2019 at 11:23:22AM -0600, Mathieu Poirier wrote: > > > Good morning Greg, > > > > > > Here is a fix I'd like you to consider for this cycle. Do you think you > > > could apply it to driver-core-next rather than char-misc-next? > > > > All of my -next branches are for 5.4-rc1, not 5.3 (i.e. the "next" > > kernel). > > > > So either one of them isn't going to matter to you for 5.3-final. > > > > > My current > > > coresight branch is based on driver-core-next to pick up Suzuki's > > > generic device lookup helpers patchset [1]. Applying it to char-misc-next > > > will create two different signature for the same patch, something that > > > gives Stephen a hard time when building the linux-next tree. > > > > Why would Suzuki's patch matter for 5.3-final? > > There was a similar situation during the 5.2 cycle [1]. Here too we > can fix a problem that is present in 5.3 rather than wait for 5.4. > > [1]. https://www.spinics.net/lists/arm-kernel/msg736274.html But that has nothing to do with Suzuki's patch that is in my driver core tree. I still fail to see the dependency here. > > > I also think this patch should go in stable but haven't marked it as such since > > > it doesn't apply to any of the stable trees. Once it is part of v5.3 I intend > > > to send a new version of the patch that does apply cleanly to those trees. Let > > > me know if you want me to proceed differently. > > > > > > Thanks, > > > Mathieu > > > > > > [1]. https://www.spinics.net/lists/dri-devel/msg219674.html > > > > > > > > > Suzuki K Poulose (1): > > > coresight: Fix DEBUG_LOCKS_WARN_ON for uninitialized attribute > > > > > > drivers/hwtracing/coresight/coresight-etm-perf.c | 1 + > > > 1 file changed, 1 insertion(+) > > > > Why would this patch depend on anything in any of my trees? > > I send you patches for inclusion in the next cycle and as such I > thought it should be the same for fixes in the current cycle. If that > is not the case, should I send them directly to Linus? You can send me fixes to forward on to Linus for this current cycle, if they are not depending on patches that are only for the -next release. I always keep 2 branches in my git trees: -linus : patches for Linus this release cycle -next : patches for Linus the next release cycle If you have bugfixes, make them against my -linus branch and send them on. Odds are they don't have dependancies other than what is in Linus's tree, so that's fine. If you have patches for the next cycle, send them against my -next branch. thanks, greg k-h _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH 0/1] coresight: Fix for v5.3-rc3 2019-08-02 9:10 ` Greg KH @ 2019-08-04 13:26 ` Mathieu Poirier 0 siblings, 0 replies; 9+ messages in thread From: Mathieu Poirier @ 2019-08-04 13:26 UTC (permalink / raw) To: Greg KH; +Cc: linux-arm-kernel, Suzuki K. Poulose On Fri, 2 Aug 2019 at 03:10, Greg KH <gregkh@linuxfoundation.org> wrote: > > On Thu, Aug 01, 2019 at 02:16:46PM -0600, Mathieu Poirier wrote: > > On Thu, 1 Aug 2019 at 12:17, Greg KH <gregkh@linuxfoundation.org> wrote: > > > > > > On Thu, Aug 01, 2019 at 11:23:22AM -0600, Mathieu Poirier wrote: > > > > Good morning Greg, > > > > > > > > Here is a fix I'd like you to consider for this cycle. Do you think you > > > > could apply it to driver-core-next rather than char-misc-next? > > > > > > All of my -next branches are for 5.4-rc1, not 5.3 (i.e. the "next" > > > kernel). > > > > > > So either one of them isn't going to matter to you for 5.3-final. > > > > > > > My current > > > > coresight branch is based on driver-core-next to pick up Suzuki's > > > > generic device lookup helpers patchset [1]. Applying it to char-misc-next > > > > will create two different signature for the same patch, something that > > > > gives Stephen a hard time when building the linux-next tree. > > > > > > Why would Suzuki's patch matter for 5.3-final? > > > > There was a similar situation during the 5.2 cycle [1]. Here too we > > can fix a problem that is present in 5.3 rather than wait for 5.4. > > > > [1]. https://www.spinics.net/lists/arm-kernel/msg736274.html > > But that has nothing to do with Suzuki's patch that is in my driver core > tree. I still fail to see the dependency here. There is indeed no correlation between the fix and the patches in the core tree. When writing the original email I didn't know in what tree you would end up applying the patch and feared we'd end up having the same patch in two different tree. Thanks to your explanation below this won't happen. > > > > > I also think this patch should go in stable but haven't marked it as such since > > > > it doesn't apply to any of the stable trees. Once it is part of v5.3 I intend > > > > to send a new version of the patch that does apply cleanly to those trees. Let > > > > me know if you want me to proceed differently. > > > > > > > > Thanks, > > > > Mathieu > > > > > > > > [1]. https://www.spinics.net/lists/dri-devel/msg219674.html > > > > > > > > > > > > Suzuki K Poulose (1): > > > > coresight: Fix DEBUG_LOCKS_WARN_ON for uninitialized attribute > > > > > > > > drivers/hwtracing/coresight/coresight-etm-perf.c | 1 + > > > > 1 file changed, 1 insertion(+) > > > > > > Why would this patch depend on anything in any of my trees? > > > > I send you patches for inclusion in the next cycle and as such I > > thought it should be the same for fixes in the current cycle. If that > > is not the case, should I send them directly to Linus? > > You can send me fixes to forward on to Linus for this current cycle, if > they are not depending on patches that are only for the -next release. > > I always keep 2 branches in my git trees: > -linus : patches for Linus this release cycle > -next : patches for Linus the next release cycle > > If you have bugfixes, make them against my -linus branch and send them > on. Odds are they don't have dependancies other than what is in Linus's > tree, so that's fine. Perfect, that's the link I was missing. Thanks, Mathieu > > If you have patches for the next cycle, send them against my -next > branch. > > thanks, > > greg k-h _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2019-08-04 13:27 UTC | newest] Thread overview: 9+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2019-08-01 17:23 [PATCH 0/1] coresight: Fix for v5.3-rc3 Mathieu Poirier 2019-08-01 17:23 ` [PATCH 1/1] coresight: Fix DEBUG_LOCKS_WARN_ON for uninitialized attribute Mathieu Poirier 2019-08-01 18:50 ` Greg KH 2019-08-01 20:20 ` Mathieu Poirier 2019-08-01 20:26 ` Greg KH 2019-08-01 18:17 ` [PATCH 0/1] coresight: Fix for v5.3-rc3 Greg KH 2019-08-01 20:16 ` Mathieu Poirier 2019-08-02 9:10 ` Greg KH 2019-08-04 13:26 ` Mathieu Poirier
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).