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=-3.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED 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 9A8EDC433C1 for ; Thu, 25 Mar 2021 18:38:03 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 6422C61A3C for ; Thu, 25 Mar 2021 18:38:03 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229622AbhCYShf (ORCPT ); Thu, 25 Mar 2021 14:37:35 -0400 Received: from mga18.intel.com ([134.134.136.126]:21623 "EHLO mga18.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229662AbhCYShQ (ORCPT ); Thu, 25 Mar 2021 14:37:16 -0400 IronPort-SDR: gA/ySKX/KYJRZiyjM2SWsPWa08msIP+NSDbn2ifCZ0hrkYVjsJ6bQ/HQWvztNHdI2sXSNtM7VK TPugJPGSFmzQ== X-IronPort-AV: E=McAfee;i="6000,8403,9934"; a="178550463" X-IronPort-AV: E=Sophos;i="5.81,278,1610438400"; d="scan'208";a="178550463" Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by orsmga106.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 25 Mar 2021 11:37:15 -0700 IronPort-SDR: 3CgO15C7qfxZn+8LJGWfk+DO7khppUgo0Ok7fuSBLo4c5OE6Lo8vMn/EFsvuhIXxF8yWtd53sD /uSwhBFnJ80Q== X-IronPort-AV: E=Sophos;i="5.81,278,1610438400"; d="scan'208";a="409501185" Received: from smile.fi.intel.com (HELO smile) ([10.237.68.40]) by fmsmga008-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 25 Mar 2021 11:37:14 -0700 Received: from andy by smile with local (Exim 4.94) (envelope-from ) id 1lPUr1-00G8Ku-Bb; Thu, 25 Mar 2021 20:37:11 +0200 Date: Thu, 25 Mar 2021 20:37:11 +0200 From: Andy Shevchenko To: Linus Torvalds Cc: Lee Jones , Linux Kernel Mailing List Subject: Re: [GIT PULL] MFD fixes for v5.12 Message-ID: References: <20210325163358.GU2916463@dell> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Mar 25, 2021 at 11:23:06AM -0700, Linus Torvalds wrote: > On Thu, Mar 25, 2021 at 9:34 AM Lee Jones wrote: > > > > - Unconstify editable placeholder structures > > Hmm. This does show a real issue with that gpio driver. > > It does garbage things: > > static int intel_quark_gpio_setup(struct pci_dev *pdev, struct mfd_cell *cell) > { > struct dwapb_platform_data *pdata; > struct resource *res = (struct resource *)cell->resources; > > where that cast is exactly because "cell->resources" _is_ const, and > the driver violates that. > > This horrible mis-use of a const pointer is why the original patch > that got reverted didn't cause build-time warnings. > > Honestly, I think the right thing to do is to get rid of that cast, and do > > struct resource *res = intel_quark_mfd_cells; > > instead, so that you clearly edit somethign that isn't const, and so > that the compiler would have warned about the whole constification in > the first place. > > This broken pattern shows up for both intel_quark_i2c_setup() and > intel_quark_gpio_setup(). > > I've pulled this, but I really want this kind of "take a const pointer > and violate it" crap removed. It is *only* correct if you know exactly > which pointer it is, and then you should just have used that original > pointer in the first place (ie use that intel_quark_mfd_cells[] > directly like suggested above). Thanks for pointing this out! I'll take it in my TODO list. Hmm... I missed the above b/c I have seen the pattern of supplying non-const data structures via .driver_data field and thought that here is something similar without looking into the actual approach. -- With Best Regards, Andy Shevchenko