Received: by 2002:a05:6a10:16a7:0:0:0:0 with SMTP id gp39csp1163591pxb; Fri, 20 Nov 2020 02:50:31 -0800 (PST) X-Google-Smtp-Source: ABdhPJx6HvLOly0bGfY69lmy/AuYfxXJwxQf9nXosdA9TDXJUOg7n3C8LKHziBA12vEC+ISSx0Pk X-Received: by 2002:a17:906:b01:: with SMTP id u1mr33554086ejg.427.1605869431461; Fri, 20 Nov 2020 02:50:31 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1605869431; cv=none; d=google.com; s=arc-20160816; b=cHU9zitMbV7ABqQFNwn1WjLesMmc0tcl8EFFbDpMUHD3r4Qw34TX8ho4adwMf9ZISE SNWPTf7kW9UbVsUo9t+IbDv+XVx/EaOYRPpOPIyvmWt5lrRlRC8ZwlYtK3/EyCXfygoM CAoDrKeDjueKjZFy1NFsLsJxAp6EhQaJH3+yosioeHmRSXEjkhtoNTQoMXdRRsiSSpdC 00TUOhTFU59mVfx60W2XF1+zk3L2t1ToPN8/EB1EuF1Rak/zO/VwlB47WYXwfhAkfsMj uelXr9rd58ik19NzGSYaUcgajzd5a7++g1Ei3vtutqrUhbuRj6F3FkL3H8WpgHF2EqVP 9s2A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:user-agent:references:message-id :in-reply-to:subject:cc:to:from:date; bh=umvHdUZ2vgVqbkdSLSeVdVRmZn6P71yCULWgp8j8QBI=; b=E38ET2b4mJJ0yfsXka7FK9Z53xkE9cIJNr+tSejwG5do5+x5gnu2Zju9DBlH4ozbw1 3tV10MUhCMkem6sJQpMMd/aBe/zCRNL64hC7vOc7IfgxW/Adp8n660zeOdKNL4x8XgkM QC/OuviJO9wtiC/M/jiKowyGGdPBm6d9CC+tqPWCpPSIJ5NA29ucezguNiOdrfK/UeTU kSW65/sCYCy3i9YjDUB2vfRBsyzQNL/Ft144iOqMF9PdWETlUw0Y1h5AzxNw5LJ7Qtk7 5U+gTpRi/5vspEWMOVYu7A/RX3BtMbEDLqmJqMxbnaeJEdg7Y1wHewXKbU0RmRPp5xJR v4HQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id cf25si1774205ejb.435.2020.11.20.02.50.07; Fri, 20 Nov 2020 02:50:31 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1725956AbgKTKrT (ORCPT + 99 others); Fri, 20 Nov 2020 05:47:19 -0500 Received: from mail3-relais-sop.national.inria.fr ([192.134.164.104]:54127 "EHLO mail3-relais-sop.national.inria.fr" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725766AbgKTKrS (ORCPT ); Fri, 20 Nov 2020 05:47:18 -0500 X-IronPort-AV: E=Sophos;i="5.78,356,1599516000"; d="scan'208";a="365143387" Received: from 173.121.68.85.rev.sfr.net (HELO hadrien) ([85.68.121.173]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 20 Nov 2020 11:47:15 +0100 Date: Fri, 20 Nov 2020 11:47:15 +0100 (CET) From: Julia Lawall X-X-Sender: jll@hadrien To: Joe Perches cc: Andy Shevchenko , Alexandru Ardelean , Robo Bot , Alexandru Ardelean , LKML , cocci Subject: Re: [Cocci] Proposal for a new checkpatch check; matching _set_drvdata() & _get_drvdata() In-Reply-To: Message-ID: References: User-Agent: Alpine 2.22 (DEB 394 2020-01-19) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 19 Nov 2020, Joe Perches wrote: > On Thu, 2020-11-19 at 17:16 +0200, Andy Shevchenko wrote: > > On Thu, Nov 19, 2020 at 4:09 PM Alexandru Ardelean > > wrote: > > > > > > Hey, > > > > > > So, I stumbled on a new check that could be added to checkpatch. > > > Since it's in Perl, I'm reluctant to try it. > > > > > > Seems many drivers got to a point where they now call (let's say) > > > spi_set_drvdata(), but never access that information via > > > spi_get_drvdata(). > > > Reasons for this seem to be: > > > 1. They got converted to device-managed functions and there is no > > > longer a remove hook to require the _get_drvdata() access > > > 2. They look like they were copied from a driver that had a > > > _set_drvdata() and when the code got finalized, the _set_drvdata() was > > > omitted > > > > > > There are a few false positives that I can notice at a quick look, > > > like the data being set via some xxx_set_drvdata() and retrieved via a > > > dev_get_drvdata(). > > > > I can say quite a few. And this makes a difference. > > So, basically all drivers that are using PM callbacks would rather use > > dev_get_drvdata() rather than bus specific. > > > > > I think checkpatch reporting these as well would be acceptable simply > > > from a reviewability perspective. > > > > > > I did a shell script to quickly check these. See below. > > > It's pretty badly written but it is enough for me to gather a list. > > > And I wrote it in 5 minutes :P > > > I initially noticed this in some IIO drivers, and then I suspected > > > that this may be more widespread. > > > > It seems more suitable for coccinelle. > > To me as well. To me as well, since it seems to involve nonlocal information. I'm not sure to understand the original shell script. Is there something interesting about pci_set_drvdata? julia