From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-11.3 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH, MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED, USER_AGENT_SANE_1 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id E0294C433DF for ; Wed, 14 Oct 2020 17:34:16 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 691F62072D for ; Wed, 14 Oct 2020 17:34:16 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="yo1UApa4" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 691F62072D Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References:Message-ID: Subject:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=he78J1V2jBHBHWJj4BPC/g3I0WqkbCOv7TINaz7Lgs8=; b=yo1UApa4n0LPG9UuwIPAoi3AT xaNEUS0sMdy7i9m/1zfZ3FF+J2Y9DTbDMoqaQ6cmmM899DfAXxqKCou+AuL1G4OQaoZYFUKmOCuza 9+J3uJ5oIBPYpRdkrBLt2CHrYxGiH5vhxxZiYr15hk1+1QeOLvliqu4MyJ9byAV4f5GZUfBVkz9gf YNgA8aenqKPfsI3bwTxcFcGiJYSnixUvCoVeEyNnQqWfGAyuGfhksokrblORxFEv6uQ3p4KIZH285 ZMlHqqFUuejO89O8KPCh8d7pQU4pSGA7l9drxVgYNDtJb/fpVrbpwqPyyekbX/GHoHLS7+ggfu6bL ZZGpWUWNQ==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kSke4-0007b8-9n; Wed, 14 Oct 2020 17:33:00 +0000 Received: from foss.arm.com ([217.140.110.172]) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kSke1-0007aV-8d for linux-arm-kernel@lists.infradead.org; Wed, 14 Oct 2020 17:32:58 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id B11BFD6E; Wed, 14 Oct 2020 10:32:54 -0700 (PDT) Received: from bogus (unknown [10.57.12.254]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 25D473F71F; Wed, 14 Oct 2020 10:32:52 -0700 (PDT) Date: Wed, 14 Oct 2020 18:32:42 +0100 From: Sudeep Holla To: Florian Fainelli Subject: Re: [PATCH] firmware: arm_scmi: Fix duplicate workqueue name Message-ID: <20201014173109.dxi2asvkojkxdtwd@bogus> References: <20201014021737.287340-1-f.fainelli@gmail.com> <20201014091806.GB20315@bogus> <872e84c9-ff49-c5a3-d07e-10a80b10ffa9@gmail.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <872e84c9-ff49-c5a3-d07e-10a80b10ffa9@gmail.com> User-Agent: NeoMutt/20171215 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20201014_133257_410859_73C276AB X-CRM114-Status: GOOD ( 41.74 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: linux-kernel@vger.kernel.org, Sudeep Holla , Cristian Marussi , linux-arm-kernel@lists.infradead.org, Jonathan Cameron Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org T24gV2VkLCBPY3QgMTQsIDIwMjAgYXQgMTA6MDg6MzJBTSAtMDcwMCwgRmxvcmlhbiBGYWluZWxs aSB3cm90ZToKPiBPbiAxMC8xNC8yMCAyOjE4IEFNLCBTdWRlZXAgSG9sbGEgd3JvdGU6Cj4gPiBI aSBGbG9yaWFuLAo+ID4KPiA+IFRoYW5rcyBmb3IgdGhlIHBhdGNoLCBpdCBzaG93cyBzb21lb25l IGVsc2UgaXMgYWxzbyB1c2luZyB0aGlzIGFuZAo+ID4gdGVzdGluZyDwn5iJLgo+ID4KPiA+IE9u IFR1ZSwgT2N0IDEzLCAyMDIwIGF0IDA3OjE3OjM3UE0gLTA3MDAsIEZsb3JpYW4gRmFpbmVsbGkg d3JvdGU6Cj4gPj4gV2hlbiBtb3JlIHRoYW4gYSBzaW5nbGUgU0NNSSBkZXZpY2UgYXJlIHByZXNl bnQgaW4gdGhlIHN5c3RlbSwgdGhlCj4gPj4gY3JlYXRpb24gb2YgdGhlIG5vdGlmaWNhdGlvbiB3 b3JrcXVldWUgd2l0aCB0aGUgV1FfU1lTRlMgZmxhZyB3aWxsIGxlYWQKPiA+PiB0byB0aGUgZm9s bG93aW5nIHN5c2ZzIGR1cGxpY2F0ZSBub2RlIHdhcm5pbmc6Cj4gPj4KPiA+Cj4gPiBQbGVhc2Ug dHJpbSB0aGUgY2FsbHRyYWNlIG5leHQgdGltZSB3aXRob3V0IHRpbWVzdGFtcCBhbmQgcmVnaXN0 ZXIgcmF3Cj4gPiBoZXggdmFsdWVzLgo+Cj4gV2lsbCBkbywgdGhhbmtzIQo+CgpUaGFua3MhCgo+ ID4KPiA+IFlvdSB1c2luZyB0aGlzIG9uIDMyLWJpdCBwbGF0Zm9ybSA/IElmIHNvLCB0aGFua3Mg Zm9yIGFkZGl0aW9uYWwgdGVzdAo+ID4gY292ZXJhZ2UuCj4KPiBXZSBoYXZlIGEgbWl4IG9mIEFS TXY3L0xQQUUgKEJyYWhtYS1CMTUpIGFuZCBBUk12OCAoQnJhaG1hLUI1MywKPiBDb3J0ZXgtQTcy KSBkZXZpY2VzIHRoYXQgd2UgcmVndWxhcmx5IHRlc3Qgd2l0aCAzMi1iaXQgYW5kIDY0LWJpdCBr ZXJuZWxzLgo+CgpBaCBPSywgZ29vZCB0byBrbm93LgoKWy4uLl0KCj4gPj4gRml4IHRoaXMgYnkg dXNpbmcgZGV2X25hbWUoaGFuZGxlLT5kZXYpIHdoaWNoIGd1YXJhbnRlZXMgdGhhdCB0aGUgbmFt ZSBpcwo+ID4+IHVuaXF1ZSBhbmQgdGhpcyBhbHNvIGhlbHBzIGNvcnJlbGF0ZSB3aGljaCBub3Rp ZmljYXRpb24gd29ya3F1ZXVlIGNvcnJlc3BvbmRzCj4gPj4gdG8gd2hpY2ggU0NNSSBkZXZpY2Ug aW5zdGFuY2UuCj4gPj4KPiA+Cj4gPiBJIGFtIGN1cmlvdXMgYXMgaG93IG11bHRpcGxlIFNDTUkg aW5zdGFuY2VzIGFyZSB1c2VkLiBXZSBrbm93IGZldyBsaW1pdGF0aW9ucwo+ID4gaW4gdGhlIGNv ZGUgdG8gaGFuZGxlIHRoYXQgeWV0LCBzbyBpbnRlcmVzdGVkIHRvIGtub3cgaWYgeW91IGFyZSBj YXJyeWluZwo+ID4gbW9yZSBwYXRjaGVzL2ZpeGVzLgo+Cj4gV2UgY3VycmVudGx5IGhhdmUgdHdv IFNDTUkgZGV2aWNlIG5vZGVzIGluIERldmljZSBUcmVlOgo+Cj4gLSB0aGUgZmlyc3Qgb25lIGlz IHJlc3BvbnNpYmxlIGZvciBhbGwgb2YgdGhlIGJhc2UsIHBlcmZvcm1hbmNlLCBzZW5zb3JzCj4g cHJvdG9jb2xzIGFuZCBpcyBwcmVzZW50IG9uIGFsbCBvZiB0aGUgY2hpcHMgbGlzdGVkIGFib3Zl Cj4KPiAtIHRoZSBzZWNvbmQgb25lIGlzIHJlc3BvbnNpYmxlIGZvciBhIHByb3ByaWV0YXJ5IHBy b3RvY29sIHRocm91Z2ggd2hpY2gKPiB3ZSBlbmNhcHN1bGF0ZSBhIHZhcmlldHkgb2Ygb3BlcmF0 aW9ucyB0b3dhcmRzIGEgc2VjdXJlIGFnZW50IGluIHRoZQo+IHN5c3RlbSwgdGhpcyBpcyBvbmx5 IHByZXNlbnQgaW4gYSBzdWJzZXQgb2YgZGV2aWNlcy4KPgoKQW5kIGFueSBwYXJ0aWN1bGFyIHJl YXNvbnMgaXQgY2FuJ3QgZXhpc3QgaW4gdGhlIHNhbWUgbm9kZS4gQW5kIGFsc28gYXJlCnRoZXkg dGFsa2luZyB0byBkaWZmZXJlbnQgU0NNSSBmaXJtd2FyZSBpbXBsZW1lbnRhdGlvbiBtZWFuaW5n IGRpZmZlcmVudApsb2NhdGlvbiBpbiB0aGUgc3lzdGVtLiBUaGUgcmVhc29uIEkgYXNrIGlzIHdl IGhhdmUgbm90aW9uIG9mIG9uZSBwbGF0Zm9ybQp3aXRoIGFnZW50IGlkID0gMCBhcyBwZXIgdGhl IHNwZWNpZmljYXRpb24uIEl0IGNhbiBiZSBzcGxpdCBpbiB0ZXJtcwpvZiBpbXBsZW1lbnRhdGlv biBhbmQgY2FuIGhhdmUgc29tZSBzaWRlIGJhbmQgY29tbXVuaWNhdGlvbiBhbW9uZ3N0CnRoZW1z ZWx2ZXMgYnV0IGNhbid0IGhhdmUgYWdlbnQgSUQgb3RoZXIgdGhhbiAwLiBJdCB2aW9sYXRlcyBz cGVjaWZpY2F0aW9uLgoKSSBkb24ndCBoYXZlIGlzc3VlcyBzcGxpdCBpdCBpbnRvIDIgb3IgbW9y ZSBTQ01JIGRldmljZSBhcyBsb25nIGFzIGl0CmRvZXNuJ3QgcHJvdmlkZSBub3Rpb24gb2YgZXhp c3RlbmNlIG9mIG11bHRpcGxlIFNDTUkgcGxhdGZvcm0gZmlybXdhcmUKaW1wbGVtZW50YXRpb25z IHdpdGggZGlmZmVyZW50IGFnZW50IElELgoKQWxzbyBDcmlzdGlhbiBoYXMgcG9zdGVkIHBhdGNo ZXMgdG8gc3VwcG9ydCBjdXN0b20gcHJvdG9jb2xzWzFdLiBJdCB3b3VsZApiZSBnb29kIGlmIHlv dSBjYW4gdGFrZSBhIGxvb2svcmV2aWV3L3Rlc3QvY29tbWVudC4uLgoKPiBUaGUgcmVhc29uIGZv ciB0aGF0IHNwbGl0IHdhcyBiZWNhdXNlIHRoZSBuYXR1cmUgb2YgdGhlIFNDTUkgdHJhZmZpYyB3 YXMKPiBkaWZmZXJlbnQsIHRoZSBmaXJzdCBvbmUgaXMgY29tcHJpc2VkIG9mIHNtYWxsIG1lc3Nh Z2VzIGRlYWxpbmcgd2l0aAo+IHBvd2VyIG1hbmFnZW1lbnQsIG1vc3QgbWVzc2FnZXMgY2FuIGJl IGNvbXBsZXRlZCBzeW5jaHJvbm91c2x5IChvcgo+IHF1YXNpLCBpZiB5b3UgcmVtZW1iZXIgb3Vy IG1haWxib3ggaW1wbGVtZW50YXRpb24pIHdoZXJlYXMgdGhlIHNlY29uZCBpcwo+IGNvbXByaXNl ZCBvZiBsYXJnZSBhbmQgYXN5bmNocm9ub3VzbHkgY29tcGxldGVkIG1lc3NhZ2VzLiBUaGlzIGlz IG5vdAo+IHByb2JhYmx5IGEgY29tbW9uIHNldC11cCwgYW5kIHdlIGhhdmUgc2luY2UgZWxpbWlu YXRlZCB0aGF0IHNlY29uZCBTQ01JCj4gaW50ZXJmYWNlIGFuZCB3ZW50IHdpdGggYSBkaXJlY3Qg TGludXggdG8gYWdlbnQgaW50ZXJmYWNlIHRoYXQgZG9lcyBub3QKPiAic3BlYWsiIFNDTUkuCj4K Ckkgc3RpbGwgZG9uJ3Qgc2VlIHN0cm9uZyByZWFzb25zIGZvciBzcGxpdHRpbmcgaXQuIEFsc28g YnkgYWJvdmUgSSBhc3N1bWUKeW91IHN0aWxsIGhhdmUgb25lIFNDTUkgc2VydmVyL3BsYXRmb3Jt IGltcGxlbWVudGF0aW9uIGFuZCBqdXN0IGRpZmZlcmVudAp0eXBlcyBvZiB0cmFuc3BvcnQgZm9y IHN0ZCB2cyBjdXN0b20gcHJvdG9jb2wgYW5kIGFsbCBzb3J0cyBvZiBzdWNoIGNvbWJvLgpJIHRo aW5rIHdlIGRlYWwgd2l0aCB0aGF0IGFzIGxvbmcgYXMgdGhleSBhcmUgb2Ygc2FtZSB0cmFuc3Bv cnQgdHlwZSBsaWtlCm1haWxib3ggb3Igc21jLgoKPiBXZSBtYXkgc3RpbGwgaGF2ZSBtdWx0aXBs ZSBTQ01JIGRldmljZXMgaW4gdGhlIGZ1dHVyZSBzaW5jZSB3ZSBhcmUKPiB0cnlpbmcgdG8gc2Vw YXJhdGUgb3V0IHRoZSBDUFUgcGVyZm9ybWFuY2UgZG9tYWluIHdoaWNoIGludm9sdmVzIHdyaXRp bmcKPiB0byByZWdpc3RlcnMgdGhhdCBhcmUgZWl0aGVyIEFSTSBzeXN0ZW0gY29udHJvbCByZWdp c3RlcnMsIG9yIG9ubHkgb24gYW4KPiBBUk0gQ1BVIGxvY2FsIGJ1cy4gVGhlIG90aGVyIGNsb2Nr L3BlcmZvcm1hbmNlIGNvbnRyb2xzIGNhbiBnbyBkaXJlY3RseQo+IHRvIHRoZSBhZ2VudCBpbXBs ZW1lbnRpbmcgU0NNSS4KPgoKV2UgaGF2ZSBzb21ldGhpbmcgY2FsbGVkIGZhc3RjaGFubmVscyBm b3IgdGhhdC4gWW91ciBzY21pIHBlcmYgcHJvdG9jb2wKY2FuIHByZXNlbnQgdGhvc2UgcmVnaXN0 ZXJzIGluIHRob3NlIGZhc3RjaGFubmVscyBpZiB0aGV5IGFyZSBNTUlPLgpJZiB0aGV5IGFyZSBz eXN0ZW0gcmVnaXN0ZXJzLCB0aGVuIHlvdSBuZWVkIG5vdCB1c2Ugc2NtaSBhdCBhbGwgZm9yIENQ VQpEVkZTIGFuZCBzdGlsbCBuZWVkIG9uZSBTQ01JIGRldmljZSBmb3IgYWxsIG90aGVyIG5lZWRz LgoKPiA+Cj4gPj4gRml4ZXM6IGJkMzFiMjQ5NjkyZSAoImZpcm13YXJlOiBhcm1fc2NtaTogQWRk IG5vdGlmaWNhdGlvbiBkaXNwYXRjaCBhbmQgZGVsaXZlcnkiKQo+ID4+IFNpZ25lZC1vZmYtYnk6 IEZsb3JpYW4gRmFpbmVsbGkgPGYuZmFpbmVsbGlAZ21haWwuY29tPgo+ID4+IC0tLQo+ID4+ICBk cml2ZXJzL2Zpcm13YXJlL2FybV9zY21pL25vdGlmeS5jIHwgMiArLQo+ID4+ICAxIGZpbGUgY2hh bmdlZCwgMSBpbnNlcnRpb24oKyksIDEgZGVsZXRpb24oLSkKPiA+Pgo+ID4+IGRpZmYgLS1naXQg YS9kcml2ZXJzL2Zpcm13YXJlL2FybV9zY21pL25vdGlmeS5jIGIvZHJpdmVycy9maXJtd2FyZS9h cm1fc2NtaS9ub3RpZnkuYwo+ID4+IGluZGV4IDQ3MzFkYWFhY2QxOS4uMjRjOWVmMjMyZjQ4IDEw MDY0NAo+ID4+IC0tLSBhL2RyaXZlcnMvZmlybXdhcmUvYXJtX3NjbWkvbm90aWZ5LmMKPiA+PiAr KysgYi9kcml2ZXJzL2Zpcm13YXJlL2FybV9zY21pL25vdGlmeS5jCj4gPj4gQEAgLTE0NjgsNyAr MTQ2OCw3IEBAIGludCBzY21pX25vdGlmaWNhdGlvbl9pbml0KHN0cnVjdCBzY21pX2hhbmRsZSAq aGFuZGxlKQo+ID4+ICAJbmktPmdpZCA9IGdpZDsKPiA+PiAgCW5pLT5oYW5kbGUgPSBoYW5kbGU7 Cj4gPj4KPiA+PiAtCW5pLT5ub3RpZnlfd3EgPSBhbGxvY193b3JrcXVldWUoInNjbWlfbm90aWZ5 IiwKPiA+PiArCW5pLT5ub3RpZnlfd3EgPSBhbGxvY193b3JrcXVldWUoZGV2X25hbWUoaGFuZGxl LT5kZXYpLAo+ID4KPiA+IE5vdCBzdXJlIGlmIGl0IG1ha2VzIHNlbnNlIHRvIGFkZCAiX25vdGlm eSIgdG8gY2xlYXJseSBpZGVudGlmeSB0aGUgd29ya3F1ZXVlLgo+Cj4gSSBoYWQgaW50ZW50aW9u YWxseSBub3QgZG9uZSBpdCBiZWNhdXNlOgo+CgpPSyBmYWlyIGVub3VnaC4KCj4gLSBpdCB3b3Vs ZCBjcmVhdGUgYSBkaWZmZXJlbnQgbmFtZSB0aGFuICJkZXZfbmFtZSIgYW5kIEkgbGlrZWQgaGF2 aW5nCj4gdGhlIHNhbWUgbmFtZSB0aHJvdWdob3V0IHRoZSBlbnRpcmUgc3lzZnMgaGllcmFyY2h5 IHRvIGVhc2lseSBpZGVudGlmeQo+IHRoZSBkZXZpY2UKPgoKR29vZCBwb2ludC4gSSB3YXMgd29y cmllZCBpZiB3ZSBuZWVkIHRvIGNyZWF0ZSBhbm90aGVyIHdvcmtxdWV1ZSBmb3IKc29tZXRoaW5n IGVsc2UgaW4gdGhlIGZ1dHVyZS4KCj4gLSBpdCB3b3VsZCByZXF1aXJlIGRvaW5nIGEgc3ByaW50 ZigpIHZhcmlhbnQgdG8gZm9ybWF0IHRoZSBuYW1lIHdoaWNoCj4gcmVxdWlyZSBhIHRlbXBvcmFy eSBidWZmZXIKPgoKSW5kZWVkLCB3aGljaCBJIHRyaWVkIGJ1dCBkb24ndCBsaWtlLgoKPiBObyBz dHJvbmcgcHJlZmVyZW5jZSBlaXRoZXIgd2F5IHRob3VnaC4KCkZvciBub3csIHdlIGNhbiBoYXZl IGFzIGlzIGluIHlvdXIgcGF0Y2guIFdlIGNhbiBhZGRyZXNzIHRoaXMgaWYgYW5kCndoZW4gd2Ug Y3JlYXRlIGFub3RoZXIgd29ya3F1ZXVlIGluIHNjbWkKCi0tClJlZ2FyZHMsClN1ZGVlcAoKX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KbGludXgtYXJtLWtl cm5lbCBtYWlsaW5nIGxpc3QKbGludXgtYXJtLWtlcm5lbEBsaXN0cy5pbmZyYWRlYWQub3JnCmh0 dHA6Ly9saXN0cy5pbmZyYWRlYWQub3JnL21haWxtYW4vbGlzdGluZm8vbGludXgtYXJtLWtlcm5l bAo= From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-11.3 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 77B8EC433DF for ; Wed, 14 Oct 2020 17:32:57 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 246542173E for ; Wed, 14 Oct 2020 17:32:57 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2389008AbgJNRcz (ORCPT ); Wed, 14 Oct 2020 13:32:55 -0400 Received: from foss.arm.com ([217.140.110.172]:54506 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2388981AbgJNRcz (ORCPT ); Wed, 14 Oct 2020 13:32:55 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id B11BFD6E; Wed, 14 Oct 2020 10:32:54 -0700 (PDT) Received: from bogus (unknown [10.57.12.254]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 25D473F71F; Wed, 14 Oct 2020 10:32:52 -0700 (PDT) Date: Wed, 14 Oct 2020 18:32:42 +0100 From: Sudeep Holla To: Florian Fainelli Cc: linux-arm-kernel@lists.infradead.org, Jonathan Cameron , Sudeep Holla , Cristian Marussi , linux-kernel@vger.kernel.org Subject: Re: [PATCH] firmware: arm_scmi: Fix duplicate workqueue name Message-ID: <20201014173109.dxi2asvkojkxdtwd@bogus> References: <20201014021737.287340-1-f.fainelli@gmail.com> <20201014091806.GB20315@bogus> <872e84c9-ff49-c5a3-d07e-10a80b10ffa9@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <872e84c9-ff49-c5a3-d07e-10a80b10ffa9@gmail.com> User-Agent: NeoMutt/20171215 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Oct 14, 2020 at 10:08:32AM -0700, Florian Fainelli wrote: > On 10/14/20 2:18 AM, Sudeep Holla wrote: > > Hi Florian, > > > > Thanks for the patch, it shows someone else is also using this and > > testing 😉. > > > > On Tue, Oct 13, 2020 at 07:17:37PM -0700, Florian Fainelli wrote: > >> When more than a single SCMI device are present in the system, the > >> creation of the notification workqueue with the WQ_SYSFS flag will lead > >> to the following sysfs duplicate node warning: > >> > > > > Please trim the calltrace next time without timestamp and register raw > > hex values. > > Will do, thanks! > Thanks! > > > > You using this on 32-bit platform ? If so, thanks for additional test > > coverage. > > We have a mix of ARMv7/LPAE (Brahma-B15) and ARMv8 (Brahma-B53, > Cortex-A72) devices that we regularly test with 32-bit and 64-bit kernels. > Ah OK, good to know. [...] > >> Fix this by using dev_name(handle->dev) which guarantees that the name is > >> unique and this also helps correlate which notification workqueue corresponds > >> to which SCMI device instance. > >> > > > > I am curious as how multiple SCMI instances are used. We know few limitations > > in the code to handle that yet, so interested to know if you are carrying > > more patches/fixes. > > We currently have two SCMI device nodes in Device Tree: > > - the first one is responsible for all of the base, performance, sensors > protocols and is present on all of the chips listed above > > - the second one is responsible for a proprietary protocol through which > we encapsulate a variety of operations towards a secure agent in the > system, this is only present in a subset of devices. > And any particular reasons it can't exist in the same node. And also are they talking to different SCMI firmware implementation meaning different location in the system. The reason I ask is we have notion of one platform with agent id = 0 as per the specification. It can be split in terms of implementation and can have some side band communication amongst themselves but can't have agent ID other than 0. It violates specification. I don't have issues split it into 2 or more SCMI device as long as it doesn't provide notion of existence of multiple SCMI platform firmware implementations with different agent ID. Also Cristian has posted patches to support custom protocols[1]. It would be good if you can take a look/review/test/comment... > The reason for that split was because the nature of the SCMI traffic was > different, the first one is comprised of small messages dealing with > power management, most messages can be completed synchronously (or > quasi, if you remember our mailbox implementation) whereas the second is > comprised of large and asynchronously completed messages. This is not > probably a common set-up, and we have since eliminated that second SCMI > interface and went with a direct Linux to agent interface that does not > "speak" SCMI. > I still don't see strong reasons for splitting it. Also by above I assume you still have one SCMI server/platform implementation and just different types of transport for std vs custom protocol and all sorts of such combo. I think we deal with that as long as they are of same transport type like mailbox or smc. > We may still have multiple SCMI devices in the future since we are > trying to separate out the CPU performance domain which involves writing > to registers that are either ARM system control registers, or only on an > ARM CPU local bus. The other clock/performance controls can go directly > to the agent implementing SCMI. > We have something called fastchannels for that. Your scmi perf protocol can present those registers in those fastchannels if they are MMIO. If they are system registers, then you need not use scmi at all for CPU DVFS and still need one SCMI device for all other needs. > > > >> Fixes: bd31b249692e ("firmware: arm_scmi: Add notification dispatch and delivery") > >> Signed-off-by: Florian Fainelli > >> --- > >> drivers/firmware/arm_scmi/notify.c | 2 +- > >> 1 file changed, 1 insertion(+), 1 deletion(-) > >> > >> diff --git a/drivers/firmware/arm_scmi/notify.c b/drivers/firmware/arm_scmi/notify.c > >> index 4731daaacd19..24c9ef232f48 100644 > >> --- a/drivers/firmware/arm_scmi/notify.c > >> +++ b/drivers/firmware/arm_scmi/notify.c > >> @@ -1468,7 +1468,7 @@ int scmi_notification_init(struct scmi_handle *handle) > >> ni->gid = gid; > >> ni->handle = handle; > >> > >> - ni->notify_wq = alloc_workqueue("scmi_notify", > >> + ni->notify_wq = alloc_workqueue(dev_name(handle->dev), > > > > Not sure if it makes sense to add "_notify" to clearly identify the workqueue. > > I had intentionally not done it because: > OK fair enough. > - it would create a different name than "dev_name" and I liked having > the same name throughout the entire sysfs hierarchy to easily identify > the device > Good point. I was worried if we need to create another workqueue for something else in the future. > - it would require doing a sprintf() variant to format the name which > require a temporary buffer > Indeed, which I tried but don't like. > No strong preference either way though. For now, we can have as is in your patch. We can address this if and when we create another workqueue in scmi -- Regards, Sudeep