Hello Russell, hello Greg,
On Thu, Feb 04, 2021 at 07:15:51PM +0100, Uwe Kleine-König wrote:
On Thu, Feb 04, 2021 at 04:59:51PM +0000, Russell King - ARM Linux admin wrote:
On Thu, Feb 04, 2021 at 05:56:50PM +0100, Greg Kroah-Hartman wrote:
On Thu, Feb 04, 2021 at 04:52:24PM +0000, Russell King - ARM Linux admin wrote:
On Tue, Feb 02, 2021 at 03:06:05PM +0100, Greg Kroah-Hartman wrote:
I'm glad to take this through my char/misc tree, as that's where the other coresight changes flow through. So if no one else objects, I will do so...
Greg, did you end up pulling this after all? If not, Uwe produced a v2. I haven't merged v2 yet as I don't know what you've done.
I thought you merged this?
I took v1, and put it in a branch I've promised in the past not to rebase/rewind. Uwe is now asking for me to take a v2 or apply a patch on top.
The only reason to produce an "immutable" branch is if it's the basis for some dependent work and you need that branch merged into other people's trees... so the whole "lets produce a v2" is really odd workflow... I'm confused about what I should do, and who has to be informed which option I take.
I'm rather lost here too.
Sorry to have cause this confusion. After I saw that my initial tag missed to adapt a driver I wanted to make it easy for you to fix the situation. So I created a patch to fix it and created a second tag with the patch squashed in. Obviously only one of them have to be picked and I hoped you (= Russell + Greg) would agree which option to pick.
My preference would be if you both pick up v2 of the tag to yield a history that is bisectable without build problems, but if Russell (who already picked up the broken tag) considers his tree immutable and so isn't willing to rebase, then picking up the patch is the way to go.
OK, the current state is that Russell applied the patch fixing drivers/mailbox/arm_mhuv2.c on top of merging my first tag.
So the way forward now is that Greg pulls
git://git.armlinux.org.uk/~rmk/linux-arm.git devel-stable
which currently points to
860660fd829e ("ARM: 9055/1: mailbox: arm_mhuv2: make remove callback return void")
, into his tree that contains the hwtracing changes that conflict with my changes. @Greg: Is this good enough, or do you require a dedicated tag to pull that?
I think these conflicting hwtracing changes are not yet in any of Greg's trees (at least they are not in next).
When I pull
https://git.kernel.org/pub/scm/linux/kernel/git/coresight/linux.git next
(currently pointing to 4e73ff249184 ("coresight: etm4x: Handle accesses to TRCSTALLCTLR")) into 860660fd829e, I get a conflict in drivers/hwtracing/coresight/coresight-etm4x-core.c as expected. My resolution looks as follows:
diff --cc drivers/hwtracing/coresight/coresight-etm4x-core.c index 82787cba537d,5017d33ba4f5..000000000000 --- a/drivers/hwtracing/coresight/coresight-etm4x-core.c +++ b/drivers/hwtracing/coresight/coresight-etm4x-core.c @@@ -1703,6 -1906,28 +1906,27 @@@ static int __exit etm4_remove_dev(struc cpus_read_unlock();
coresight_unregister(drvdata->csdev); + + return 0; + } + -static int __exit etm4_remove_amba(struct amba_device *adev) ++static void __exit etm4_remove_amba(struct amba_device *adev) + { + struct etmv4_drvdata *drvdata = dev_get_drvdata(&adev->dev); + + if (drvdata) - return etm4_remove_dev(drvdata); - return 0; ++ etm4_remove_dev(drvdata); + } + + static int __exit etm4_remove_platform_dev(struct platform_device *pdev) + { + int ret = 0; + struct etmv4_drvdata *drvdata = dev_get_drvdata(&pdev->dev); + + if (drvdata) + ret = etm4_remove_dev(drvdata); + pm_runtime_disable(&pdev->dev); + return ret; }
static const struct amba_id etm4_ids[] = {
Best regards Uwe