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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 476B0C001B0 for ; Fri, 11 Aug 2023 08:51:38 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234067AbjHKIvh (ORCPT ); Fri, 11 Aug 2023 04:51:37 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44146 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231681AbjHKIvf (ORCPT ); Fri, 11 Aug 2023 04:51:35 -0400 Received: from mx0b-0031df01.pphosted.com (mx0b-0031df01.pphosted.com [205.220.180.131]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 73907213B; Fri, 11 Aug 2023 01:51:35 -0700 (PDT) Received: from pps.filterd (m0279872.ppops.net [127.0.0.1]) by mx0a-0031df01.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 37B5LVhm024129; Fri, 11 Aug 2023 08:51:29 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=quicinc.com; h=message-id : date : mime-version : subject : to : cc : references : from : in-reply-to : content-type : content-transfer-encoding; s=qcppdkim1; bh=cPInmwqs5+QXx/2dVUgAsg/a21Oe5AE2IF9PbDcPk8Q=; b=Athp63qEvOBLE5QTaKKh6YTM05fwTNmtixa70wlA/W0pAEVt1W3uUQplffKtcdKwBqbB 198SkSLbM9RirVZn41G+UI4xDtYyUih7ydoAJt33awX0Q3kSOWBB6M9k1ikOjOVs6661 YswpX3Lei1p5LE8DAGnynazr0LItToxTy3pdLnRrP9ANNDdCQCMb+79vcIxSfSy694Kf /SgdhLlh+HGZ97Xea7BWqegs0FYsDDywbtJ4l7X40QeJDVwT/69+X73a6ZdoKNF89aFi YhQQLMCkZwGr+ODZuET+WEaMcKBTt4uNjdwt3iEAXcqQkcgjRiCO3Vvwm3kj/dxcaaRq 2Q== Received: from nasanppmta01.qualcomm.com (i-global254.qualcomm.com [199.106.103.254]) by mx0a-0031df01.pphosted.com (PPS) with ESMTPS id 3sd904s502-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 11 Aug 2023 08:51:29 +0000 Received: from nasanex01a.na.qualcomm.com (nasanex01a.na.qualcomm.com [10.52.223.231]) by NASANPPMTA01.qualcomm.com (8.17.1.5/8.17.1.5) with ESMTPS id 37B8pSON020000 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 11 Aug 2023 08:51:28 GMT Received: from [10.50.43.50] (10.80.80.8) by nasanex01a.na.qualcomm.com (10.52.223.231) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1118.30; Fri, 11 Aug 2023 01:51:24 -0700 Message-ID: Date: Fri, 11 Aug 2023 14:21:21 +0530 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 Subject: Re: [PATCH v2 3/4] venus: hfi: add checks to handle capabilities from firmware Content-Language: en-US To: Bryan O'Donoghue , , , , , , , CC: , , , References: <1691634304-2158-1-git-send-email-quic_vgarodia@quicinc.com> <1691634304-2158-4-git-send-email-quic_vgarodia@quicinc.com> <59b61d65-a827-d252-cdc2-a256f99cb4d9@linaro.org> From: Vikash Garodia In-Reply-To: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: nasanex01b.na.qualcomm.com (10.46.141.250) To nasanex01a.na.qualcomm.com (10.52.223.231) X-QCInternal: smtphost X-Proofpoint-Virus-Version: vendor=nai engine=6200 definitions=5800 signatures=585085 X-Proofpoint-GUID: n7Hjr16suun1C8yejsBTSTh0VXsZxFLj X-Proofpoint-ORIG-GUID: n7Hjr16suun1C8yejsBTSTh0VXsZxFLj X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.267,Aquarius:18.0.957,Hydra:6.0.591,FMLib:17.11.176.26 definitions=2023-08-10_20,2023-08-10_01,2023-05-22_02 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 bulkscore=0 phishscore=0 priorityscore=1501 adultscore=0 spamscore=0 lowpriorityscore=0 mlxlogscore=588 impostorscore=0 mlxscore=0 clxscore=1015 malwarescore=0 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2306200000 definitions=main-2308110080 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 8/11/2023 2:11 PM, Bryan O'Donoghue wrote: > On 11/08/2023 06:54, Vikash Garodia wrote: >> The case is all about rogue firmware. If there is a need to fill the same cap >> again, that itself indicates that the payload from firmware is not correct. In >> such cases, the old as well as new cap data are not reliable. Though the >> authenticity of the data cannot be ensured, the check would avoid any OOB during >> such rogue firmware case. > > Then why favour the old cap report over the new ? When the driver hits the case for OOB, thats when it knows that something has gone wrong. Keeping old or new, both are invalid values in such case, nothing to favor any value. Regards, Vikash