Received: by 2002:a5d:9c59:0:0:0:0:0 with SMTP id 25csp537313iof; Mon, 6 Jun 2022 08:07:39 -0700 (PDT) X-Google-Smtp-Source: ABdhPJycM1Z5ZeFzgxmPnaXREoxbqrEmDRG2/9AryJItqZ3KhwTiB/0xsU537s6yIeDHRv/r59QU X-Received: by 2002:a05:6a00:1a08:b0:510:979e:f5b with SMTP id g8-20020a056a001a0800b00510979e0f5bmr24828275pfv.34.1654528059609; Mon, 06 Jun 2022 08:07:39 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1654528059; cv=none; d=google.com; s=arc-20160816; b=MxlgQq+bfqQQgkwUVM9E0QsUyXSxjQKuhfniOKTI1O46IvLIe9MFrE5l8FGQ0zqaqJ nD2rg66dFGsbHBqQ8bEhtQMN85jchV9kIZFHpFLMYfbLsvkxq5kjshknh1S9RlSai+UH GOzgR2p2GHGxSfNL+6RfEdpQB+mKnFpbr8ova19SkdWUX+Gb4ETRtHMOCVpxmECpIO1C g3KT8cw/GslrwAfdJ9rbuWXIEn4g63c9Jm/qfj3z39nyx2T+mGhXeuG5wN/O3Glgq8mb N48gRexUzzMURqyBEWCCQqvJAxTVULnNYx90OGluncptocArg0FxBYTWwNLzIxXEpDwv T10A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from; bh=Qj5NGLQekywurp/ebnI9O2ov/LY3B33sksuUIwpzs0Y=; b=A0KCerVLLNXm2qRGW7w0oPvNRJS9GXqgziwR6Hd44/j/8BkRcvZEQAQp5EL4YFXw0A ldw0neb0IAPd5vUdWbLNLccW6czJxvQP7JX53Usw9TXvVzV2WlwZQnmsQb18Biyqj7Q2 yUEfq8XxDWMimtwfBcXCEEZKUSjYlKd/RgUGKP768XRAmB0BkWoLja8xanyJsaiadt1m wpj//ik1/qsMwc3LfFNYUXv/yFb4ig9R9Dd3Svj0MFQFHxYIQw8S3UfJsbAbVqH4hPSt oetvS9wlOBMaiUaqLVDKvm3j1j0J7XVo9vDPvHiMLMFv8sSQVnkeSu2sao5xYosZ2ZAy Wl0w== ARC-Authentication-Results: i=1; mx.google.com; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [23.128.96.19]) by mx.google.com with ESMTPS id o13-20020a056a00214d00b0050e09a93a5fsi19693535pfk.34.2022.06.06.08.07.38 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 06 Jun 2022 08:07:39 -0700 (PDT) Received-SPF: softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) client-ip=23.128.96.19; Authentication-Results: mx.google.com; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 7D8D729F5A3; Mon, 6 Jun 2022 07:55:31 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S240115AbiFFOzW (ORCPT + 99 others); Mon, 6 Jun 2022 10:55:22 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47052 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S240112AbiFFOzU (ORCPT ); Mon, 6 Jun 2022 10:55:20 -0400 Received: from gloria.sntech.de (gloria.sntech.de [185.11.138.130]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 9CC902914F2 for ; Mon, 6 Jun 2022 07:55:16 -0700 (PDT) Received: from ip5b412258.dynamic.kabel-deutschland.de ([91.65.34.88] helo=diego.localnet) by gloria.sntech.de with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nyE8N-0007Ur-G7; Mon, 06 Jun 2022 16:55:11 +0200 From: Heiko =?ISO-8859-1?Q?St=FCbner?= To: Cristian Marussi , Sudeep Holla Cc: Michael Riesch , linux-arm-kernel@lists.infradead.org, linux-rockchip@lists.infradead.org, linux-kernel@vger.kernel.org, Liang Chen , Kever Yang , Sudeep Holla , Jeffy Chen , Peter Geis , Nicolas Frattaroli , Etienne Carriere Subject: Re: [PATCH] firmware: arm_scmi: Relax BASE protocol sanity checks on protocol list Date: Mon, 06 Jun 2022 16:55:10 +0200 Message-ID: <4402272.LvFx2qVVIh@diego> In-Reply-To: <20220606144305.agzzyf7c4kp2nwlw@bogus> References: <20220523171559.472112-1-cristian.marussi@arm.com> <20220606144305.agzzyf7c4kp2nwlw@bogus> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RDNS_NONE, SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Am Montag, 6. Juni 2022, 16:43:05 CEST schrieb Sudeep Holla: > On Mon, Jun 06, 2022 at 02:31:48PM +0100, Cristian Marussi wrote: > > On Mon, Jun 06, 2022 at 02:59:10PM +0200, Michael Riesch wrote: > > > Hi Cristian, > > > > > Hi Michael, > > > > > On 5/23/22 19:15, Cristian Marussi wrote: > > > > Even though malformed replies from firmware must be treated carefully to > > > > avoid memory corruption Kernel side, some out-of-spec SCMI replies can > > > > be tolerated to avoid breaking existing deployed system, as long as they > > > > won't cause memory issues. > > > > > > > > Reported-by: Nicolas Frattaroli > > > > Cc: Etienne Carriere > > > > Cc: Sudeep Holla > > > > Signed-off-by: Cristian Marussi > > > > > > Thanks a lot, without this fix the Mali G52 GPU won't probe on my RK3568 > > > EVB1 in vanilla v5.19-rc1. > > > > > > > Yes, the break was reported on -next and today it appeared in 5.19-rc1. > > A proper FW fix is also up for review by Etienne but in the meantime > > this tries to limit damages relaxing a bit the checks. > > > > > I guess this patch should have a Fixes: tag, right? > > > > > > > It has not a Fixes tag because the issue was introduced in 5.19-rc1 and the > > fix will go in with the next round of v5.19 fixes by Sudeep (AFAIU) so it > > will be solved within the v5.19 cycle and I thought the Fixes tag was > > not needed in this case (I could be wrong...) > > Correct, if for some reason, we can't push this before v5.19, then fixes > tag needs to added. I will add that then, but for now let us target getting > it in before v5.19 hmm, I'd disagree for the generalization. While true that is not 100% necessary to be present in all cases, so definitly no reason for a new version when applied to the same -rc series, having the Fixes tag not only clearly marks the patch as such, but also allows people reading either mailing lists or the later the git history to actually see where the issue started. So I really think it is a nice-to-have in most cases. Heiko