Received: by 2002:ab2:3141:0:b0:1ed:23cc:44d1 with SMTP id i1csp477298lqg; Fri, 1 Mar 2024 10:45:10 -0800 (PST) X-Forwarded-Encrypted: i=2; AJvYcCVcsDTIStSvKQBCoSqR8rL+yineoBmy3RwvdJusA0WSSX8dby3Ha4oXTpT9EmiVDfyFODx0hwuJtFgjvedMI9otAWdx2rXUZ5pKnGD3tg== X-Google-Smtp-Source: AGHT+IFard3sBWdvzQvFm+zNreVJnOK6rMw4Ydu14NdnARxX9E74FKop1esG2if8a8b7oqtGgQfM X-Received: by 2002:a17:90b:4388:b0:299:d43b:9092 with SMTP id in8-20020a17090b438800b00299d43b9092mr2444551pjb.15.1709318710142; Fri, 01 Mar 2024 10:45:10 -0800 (PST) Return-Path: Received: from sv.mirrors.kernel.org (sv.mirrors.kernel.org. [139.178.88.99]) by mx.google.com with ESMTPS id pq12-20020a17090b3d8c00b0029b21aeab75si2202290pjb.54.2024.03.01.10.45.09 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 01 Mar 2024 10:45:10 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-88935-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) client-ip=139.178.88.99; Authentication-Results: mx.google.com; dkim=neutral (body hash did not verify) header.i=@kernel.org header.s=k20201202 header.b=ozKTF75p; arc=fail (body hash mismatch); spf=pass (google.com: domain of linux-kernel+bounces-88935-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) smtp.mailfrom="linux-kernel+bounces-88935-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sv.mirrors.kernel.org (Postfix) with ESMTPS id A9C4128E9B7 for ; Fri, 1 Mar 2024 18:45:09 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 5CF1239AEC; Fri, 1 Mar 2024 18:45:02 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="ozKTF75p" Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 799348F65; Fri, 1 Mar 2024 18:45:01 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1709318701; cv=none; b=fUuMqY5MFAa1slNVy8b9sAaiz8atO9aTgGwGZBu3JYtbGCWlHsNbVqcWkKw+VRP9nTfpm9HZ/Q/wvyfHn9TDkExdzYWH94AzlZeChZiIahjY4j0X/J/kBEiKyUddy8VEPShf9cMlXzkqwSjYHu4dk4UjJIL7M4MmFRNZkldqcEU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1709318701; c=relaxed/simple; bh=id1yxnRe4d1iVCCOZ0uMeXqYvdX54AmG8Ltuh9AETi8=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=BzyEfgVvS/4sV2jVM6p8hj01PC9GXJlZ0Y5vhXDzjLipphk0St7XVSjgQfY1E52/QHpvRY7AhRQDna8E4OkdovKra9MLFzlDqGw2YEKEwHpMyN++5iNA2brPSIk6QnIfNw4zPdIBWbjoVT3rxANo0bbFSLc4SOg/HZEKUAP9/rw= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=ozKTF75p; arc=none smtp.client-ip=10.30.226.201 Received: by smtp.kernel.org (Postfix) with ESMTPSA id 7CE67C433F1; Fri, 1 Mar 2024 18:45:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1709318701; bh=id1yxnRe4d1iVCCOZ0uMeXqYvdX54AmG8Ltuh9AETi8=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=ozKTF75pI/DiPLnxnR80D2QsV+tX5cOFWKed+C4cXD81TM13NVUXruKRuVGpPU2Uh hGIeXpCeRD9ygx6L+BkV8Sut1PFKn4siYbtEjxf5RGPXfWPEmg33jefCP0n379A8ep 9E1/fHPOGWOrDhA/UUVp4qbZx2lQjDMKhYRw3SUjNfixTVZrUkFqNQHJuou5ix/XT4 iQB8biQr/8lHwEmCP9ks5UKfRQaVblbPj1o4RVMVuSBvH5iF3GNjVTEx7bdOXopci+ dOvOs/mSYh1azHsJaYD49QYlunYdSGo10mfOrpoYf1MICGowbXcyvfGa1XDtCI0x4Z GVjhsO8tU9CYQ== Date: Fri, 1 Mar 2024 19:44:57 +0100 From: Andi Shyti To: Mukesh Kumar Savaliya Cc: konrad.dybcio@linaro.org, bjorn.andersson@linaro.org, vkoul@kernel.org, wsa@kernel.org, linux-arm-msm@vger.kernel.org, dmaengine@vger.kernel.org, linux-kernel@vger.kernel.org, linux-i2c@vger.kernel.org, quic_vdadhani@quicinc.com Subject: Re: [PATCH v1] i2c: i2c-qcom-geni: Parse Error correctly in i2c GSI mode Message-ID: <2wala6lz4vanhvfx6jtpdexnpohabuvhzt4i7kt2xvmlfrapq4@tmvl37npj7jy> References: <20240301112638.990045-1-quic_msavaliy@quicinc.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20240301112638.990045-1-quic_msavaliy@quicinc.com> Hi Mukesh, (I'm sorry for the noise but my mail server has marked this mail as spam and put the spam tag in front of the subject. Therefore, my reply might have been marked as spam.) I'm going to send a new e-mail with the old answers. On Fri, Mar 01, 2024 at 04:56:38PM +0530, Mukesh Kumar Savaliya wrote: > we are seeing protocol errors like NACK as transfer failure but /we/We/ > ideally it should report exact error like NACK, BUS_PROTO or ARB_LOST. > > Hence we are adding such error support in GSI mode and reporting it > accordingly by adding respective error logs. > > geni_i2c_gpi_xfer() needed to allocate heap based memory instead of Please use the imperative form. > stack memory to handle and store the geni_i2c_dev handle. > > Copy event status from GSI driver to the i2c device status and parse > error when callback comes from gsi driver to the i2c driver. In the > gpi.c, we need to store callback param into i2c config data structure > so that inside the i2c driver, we can check what exactly the error is > and parse it accordingly. > > Fixes: d8703554f4de ("i2c: qcom-geni: Add support for GPI DMA") What bug are you fixing here? The description doesn't talk about fixes rather than support added. .. > - config.peripheral_config = &peripheral; > - config.peripheral_size = sizeof(peripheral); > + peripheral = devm_kzalloc(gi2c->se.dev, sizeof(*peripheral), GFP_KERNEL); > + if (!peripheral) > + return -ENOMEM; This is a massive leak. Why are you deciding to make the allocation dynamic? Thanks, Andi