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=-7.3 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no 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 729E9C433B4 for ; Wed, 14 Apr 2021 08:37:31 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 46DE96105A for ; Wed, 14 Apr 2021 08:37:31 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232043AbhDNIhv (ORCPT ); Wed, 14 Apr 2021 04:37:51 -0400 Received: from www381.your-server.de ([78.46.137.84]:60644 "EHLO www381.your-server.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230160AbhDNIhu (ORCPT ); Wed, 14 Apr 2021 04:37:50 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=metafoo.de; s=default2002; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID; bh=I3h8InelMwWQEwsxRD1zDPA27Lroskn99+uQLhVojSQ=; b=W3oorWTruECHV7pKRofXhos/In zoe7kCcyW8qbkpdF1yakMAMlEqLNz5LxEPmbpfgwtprZcBd+ylP+bXps2ygbuFqmM8IGqC5AxZFP1 j4ubFyCugt1r+36MdU30nQhxxho4dddJHHKC/UHzgNHm78wR0rTh58uYXuJct8aLbO4piUToOl5hz rHRKcdVpWCIL8oldZuqZ47RoKL9WKmkYXbCSIOFw0zftRG1Us+5Br7aGZaWcX0lmw8TXmPWVVxO2e ID6G3WWfLWF3ckgAKiHIxNqQvLCPM6xS+TliSCCASN1UvzGWI7XgFVrU4I3BA2rodF5cP27CLlh2u WsCHrcMQ==; Received: from sslproxy01.your-server.de ([78.46.139.224]) by www381.your-server.de with esmtpsa (TLSv1.3:TLS_AES_256_GCM_SHA384:256) (Exim 4.92.3) (envelope-from ) id 1lWb1Z-000F3S-9Z; Wed, 14 Apr 2021 10:37:25 +0200 Received: from [2001:a61:2bab:901:9e5c:8eff:fe01:8578] by sslproxy01.your-server.de with esmtpsa (TLSv1.3:TLS_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lWb1Z-000WjH-63; Wed, 14 Apr 2021 10:37:25 +0200 Subject: Re: [PATCH 0/7] Adis IRQ fixes and minor improvements To: Nuno Sa , linux-iio@vger.kernel.org Cc: Jonathan Cameron , Michael Hennerich References: <20210413112105.69458-1-nuno.sa@analog.com> From: Lars-Peter Clausen Message-ID: <67e2d21b-83b0-2d42-45db-4e0e009f73bc@metafoo.de> Date: Wed, 14 Apr 2021 10:37:24 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.9.0 MIME-Version: 1.0 In-Reply-To: <20210413112105.69458-1-nuno.sa@analog.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Authenticated-Sender: lars@metafoo.de X-Virus-Scanned: Clear (ClamAV 0.102.4/26139/Tue Apr 13 13:07:58 2021) Precedence: bulk List-ID: X-Mailing-List: linux-iio@vger.kernel.org On 4/13/21 1:20 PM, Nuno Sa wrote: > The primary goal of this series was to fix the return value on some > trigger handlers as spotted in [1]. While doing it, I found some minor > improvements that I think are simple enough to include in this series. > > As for the first 2 patches, I opted to not do any functional change so > I'm keeping the 'if (!adis->buffer)' check. However, 'adis-buffer' is > allocated in 'update_scan_mode' hook which means we should be sure that > the buffer is allocated and the check is really not needed. I did not > went into the details but is there any way for the trigger handler to be > called before the 'update_scan_mode' hook? If not, I'm happy in sending > a v2 where we just remove the 'if'... I do remember that the check was deliberate. I do remember of thinking about whether we need this and feeling uncomfortable about not having the check. But I think it is more a instance of defensive programming rather than actually being required. It was less about the trigger being called before update_scan_mode, but in case it gets called if the allocation in update_scan_mode fails. But I think this should not be possible. So it is probably safe to remove it. - Lars