Received: by 2002:a05:6358:489b:b0:bb:da1:e618 with SMTP id x27csp7614345rwn; Wed, 14 Sep 2022 01:18:56 -0700 (PDT) X-Google-Smtp-Source: AA6agR6DN6T39v1PKl1Q9ErvRspMOeX+bJpkmF4mKxzDKUPJBwePQf5Usru+gYxnTly5IlWoz+iv X-Received: by 2002:a05:6402:524a:b0:450:bab6:cd5f with SMTP id t10-20020a056402524a00b00450bab6cd5fmr24715199edd.233.1663143536584; Wed, 14 Sep 2022 01:18:56 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1663143536; cv=none; d=google.com; s=arc-20160816; b=0WuzY6QaBeDWzJAKEH2sEQUij0M7KlpmjI3sP66EyTHrzA3Lnm1yakNsnT16FROWHo Rnon6PSsuPLDVpg3he5hsFnejVrNZu/A7/A+YuSTQIv3dqkL2MlmkeTvlZZXPiZkcRrA khE5h3DOz79AN8HKpJ5esocvN4oBSjNiMtAHYwGIFME0Ckjy995hLMQteKnPXy4Vn2ge wP3B+m1Yc5+gkGoMu94TvFbzYx1YUwGmcJ+ir4nsS7BoSAvlDWGgslRQdXu+ugJkUbFd tlUHRRcOWS8Ox85rFpFZKomr23QyyzndkooO8prAfmAz0G7R4Kt7VsS+bEx8WVqXX/b6 7yvA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=J2YBpi6uvUdwTp6JCYSVMN36WFhUGqkxnDpfijte+44=; b=TqV+E+78HBFzNIEatWQDdTKzeuNl1QT6t0IYQtZAcvX9lv9PwxLNlurd6bAw9YaWLt 4WeDHfjV5xty6I3Z9KqHya9NhTnjvTtOUdFdrP0TBx1h9UzMfAmOrXXsbK4mDRsUh5QT Jh3pHePwh6HqS5VU0ZdkN/YVNQ+MtGz2LnMfdG/qXw4ksBTDMVZjTnLMH9A30nKbW0H/ r9oo5qC2fgMT2SnmDJGXxPs9NEX0XEsKDV0m1WyW5kCV3qi7MYZ4mPG3DLk0WAxxybe3 72K3ZHsYm+d8IkzMV/nb12wRHXgV8N8u4R1DM7A/COgbV7hQ93GbZd707ZZvwR0JBc1o Op+g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=AaIkyci8; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id h12-20020a05640250cc00b0044612f19c98si13429582edb.512.2022.09.14.01.18.31; Wed, 14 Sep 2022 01:18:56 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=AaIkyci8; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230324AbiINICq (ORCPT + 99 others); Wed, 14 Sep 2022 04:02:46 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46318 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230178AbiINICY (ORCPT ); Wed, 14 Sep 2022 04:02:24 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id BAA6A6CF7A for ; Wed, 14 Sep 2022 01:02:06 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 3C592615D9 for ; Wed, 14 Sep 2022 08:02:05 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 2826CC433D7; Wed, 14 Sep 2022 08:02:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1663142524; bh=Gb+UiMDJQOrLZOBOFvKO7hc50e8Wfw2fbwZ4a+0Jhhk=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=AaIkyci8t2ooMQbr9h9k78gp0yMhS6aqvjyg5Npw9R98sEnih/9jPERR1/8oCy7uO XPvw2a7og0Y5TH4ZzVylrrM1iLE6ZtbrjHfJnjMf0abP8PGzQwgpx7IIhmNEOavRUL XHRgE6Xb8qG2Vq0vz2nMox4dfJ2ogwy9xDSWMZCI= Date: Wed, 14 Sep 2022 10:02:29 +0200 From: Greg KH To: Nam Cao Cc: forest@alittletooquiet.net, linux-kernel@vger.kernel.org, linux-staging@lists.linux.dev Subject: Re: [PATCH v3 1/2] staging: vt6655: remove unnecessary volatile qualifier Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-7.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_HI, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham 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 On Tue, Sep 13, 2022 at 06:52:12PM +0200, Nam Cao wrote: > On Sun, Sep 11, 2022 at 9:25 AM Greg KH wrote: > > > > On Sun, Sep 11, 2022 at 09:12:44AM +0200, Nam Cao wrote: > > > On Fri, Sep 9, 2022 at 8:03 PM Greg KH wrote: > > > > > > > > On Fri, Sep 09, 2022 at 02:17:55PM +0200, Nam Cao wrote: > > > > > Remove volatile qualifier for the member rd0 of struct vnt_rx_desc, > > > > > because there is no reason it must be volatile. > > > > > > > > > > Signed-off-by: Nam Cao > > > > > --- > > > > > drivers/staging/vt6655/desc.h | 2 +- > > > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > > > > > diff --git a/drivers/staging/vt6655/desc.h b/drivers/staging/vt6655/desc.h > > > > > index 17a40c53b8ff..3f0f287b1693 100644 > > > > > --- a/drivers/staging/vt6655/desc.h > > > > > +++ b/drivers/staging/vt6655/desc.h > > > > > @@ -182,7 +182,7 @@ struct vnt_rdes1 { > > > > > > > > > > /* Rx descriptor*/ > > > > > struct vnt_rx_desc { > > > > > - volatile struct vnt_rdes0 rd0; > > > > > + struct vnt_rdes0 rd0; > > > > > > > > You can not just remove this without describing _WHY_ it is ok to do so. > > > > > > > > Have you properly determined why it is, or is not, ok to use volatile > > > > here? > > > > > > I did not carefully look at the volatile usage here. After looking at it > > > again, using volatile is actually valid: the structure resides on coherent > > > memory. > > > > Are you sure? That's a very odd thing for a driver to need. Looks like > > they are allocating some dma memory and then pointing structures on top > > of that memory. Why would you need to have "volatile" markings on a > > structure definition for that? > > These structures are the ring buffer descriptors, which are dma-mapped and > their values may be changed by the hardware. For example, the field "owner" of > struct vnt_rdes0 is set to OWNED_BY_NIC by CPU, and then set to OWNED_BY_HOST > by hardware when new data arrives (at least that's why I can guess based on > the codes). So I think volatile is needed. > > Please let me know if you think I'm wrong, because I have just recently > educated myself on DMA mapping. With DMA mapping you shouldn't need "volatile" as it really doesn't do what people thought it did. Other drivers don't use volatile for accessing memory this way, the device should have notified the driver that it is now safe to read from that memory through the DMA api. So try looking a bit closer and also look at the compiler output before and after your change to see if it actually did anything or not. thanks, greg k-h