Message ID | 20230622183613.58762-1-andriy.shevchenko@linux.intel.com |
---|---|
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:994d:0:b0:3d9:f83d:47d9 with SMTP id k13csp5293316vqr; Thu, 22 Jun 2023 12:26:51 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ6wthpXzSHFtQBkB9tSm9eOjDpiSNk4HE0nh85CCTeR6p6SMm15IS5kajcaqidB34DW5fF0 X-Received: by 2002:a05:6a00:1504:b0:668:9735:573c with SMTP id q4-20020a056a00150400b006689735573cmr10092296pfu.15.1687462011062; Thu, 22 Jun 2023 12:26:51 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1687462011; cv=none; d=google.com; s=arc-20160816; b=PrjmsOUM2XtAARf2MUNVu9OSYe0jo+UZE5Fswq9gkyEHmjmqPmgoIseDrT7uNeKas3 CayIHH5W0/YVTOWW1G0UN5iz3WHBSQNrHQCNLKCVRVTnGQKBSb82SNuKH5KE29av/Fp4 QFmWsokMoFGXSK0fngYuouvbSdkpis4EgYT+w0RQnNLmqiA585TVZ4BsMwSJpBblYlhC LSp60FCdVxoBlz/tqpZfxeaVLGV3CO8kQGBceXrSBRovMhm/caWDX1O+88CPBrayU/+N m5GHJQ6tbd9KSXm9/7/PhzI4oxJNgypPrQATmenmsBjhzqqdVocHEbUnz+HLx6Pk1qFZ lO/Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature; bh=WqoDABfKGoVqDQPXx40lFl1NYXPFYIgHUttBaRcUhdE=; b=ahptdrlFDlFX4wgLQd7fO1ULLwZ4X4fXP2hBX20pmb8XhsNi+Gb81t1jC4Ly3vyvjB a+tt67el7b/yAGYnQpgcMQZBiwiGVii0DbsPUUcyVy/g57twUq7P9o/l7FIjUqvlIzY/ M5G4IY2YxBzEULUher8C1X/8APRrJ5/xNYqRek40JsY5peMkVXos3W0cfb1tvDWfEwII yO1iFwSAB70Mhqb4E9uvCwK/2klIu45AwKu/wXhP9L/kXZRlAbsOvDpzsyYSS4unZbmI CFw1GrGil6h3L1UeFFAr7Fftekx1Fv3rw2HAMay7yt9xB72qaMOvw6YcdVBJcCY6psGb JpVA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=FTs7I5dd; 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=intel.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id p8-20020aa79e88000000b00666c9148d03si2502843pfq.6.2023.06.22.12.26.38; Thu, 22 Jun 2023 12:26:51 -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=@intel.com header.s=Intel header.b=FTs7I5dd; 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=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231231AbjFVSgR (ORCPT <rfc822;maxin.john@gmail.com> + 99 others); Thu, 22 Jun 2023 14:36:17 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59794 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229961AbjFVSgO (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Thu, 22 Jun 2023 14:36:14 -0400 Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D22F52105 for <linux-kernel@vger.kernel.org>; Thu, 22 Jun 2023 11:36:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1687458973; x=1718994973; h=from:to:cc:subject:date:message-id:mime-version: content-transfer-encoding; bh=yWLvnl8GBxtfpixtJGOFm07hcrmmJHs+aRhEjmyx6TY=; b=FTs7I5ddUTx6kuua4bSkzQcd98tvORUuZEcJcm41DnDOvvaDi3QAs4Yd V2KwwRd+wFKVZwAVAOr0Yd0tFnri1JdgqNGfHl/1+PE3ga/t+ExxQuC1L xohSsbpaEdcReEsNbbSqBUL573rSTlm8t9KGjZO0BnoYvsyGY6CQRLdXQ xMW0jPEdx/wUeldgEGIrHlqB+mK6wH8EVAeRYEXD1O6b9UGwmnmJSaVI3 O16a5ig+IU2xaDxJmzU7TNgavkfHSyJw7Ni/MMP1ZiyBsoskUqPZZOuYd 3hRuVK6Mm/6GVK9/Tb7mUwzQpgGnybOQdhMClI1ASffWLqnH9IYibtqRi g==; X-IronPort-AV: E=McAfee;i="6600,9927,10749"; a="350336491" X-IronPort-AV: E=Sophos;i="6.01,149,1684825200"; d="scan'208";a="350336491" Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga101.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 22 Jun 2023 11:36:10 -0700 X-IronPort-AV: E=McAfee;i="6600,9927,10749"; a="749444245" X-IronPort-AV: E=Sophos;i="6.01,149,1684825200"; d="scan'208";a="749444245" Received: from black.fi.intel.com ([10.237.72.28]) by orsmga001.jf.intel.com with ESMTP; 22 Jun 2023 11:36:08 -0700 Received: by black.fi.intel.com (Postfix, from userid 1003) id 560C724F; Thu, 22 Jun 2023 21:36:19 +0300 (EEST) From: Andy Shevchenko <andriy.shevchenko@linux.intel.com> To: Mark Brown <broonie@kernel.org>, Andy Shevchenko <andriy.shevchenko@linux.intel.com>, linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>, "Rafael J. Wysocki" <rafael@kernel.org>, Linus Walleij <linus.walleij@linaro.org> Subject: [PATCH v1 0/3] regmap: Drop never (properly) worked 64-bit support Date: Thu, 22 Jun 2023 21:36:10 +0300 Message-Id: <20230622183613.58762-1-andriy.shevchenko@linux.intel.com> X-Mailer: git-send-email 2.40.0.1.gaa8946217a0b MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-4.3 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_EF,RCVD_IN_DNSWL_MED, RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE, 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: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1769432165807015327?= X-GMAIL-MSGID: =?utf-8?q?1769432165807015327?= |
Series |
regmap: Drop never (properly) worked 64-bit support
|
|
Message
Andy Shevchenko
June 22, 2023, 6:36 p.m. UTC
regmap API internally operates on unsigned int values for the register offsets and data. The commit back in 2015 that introduces 64-bit excerpts in the code made a false impression that it works. Not really. Consider two things: 1/ register offset 2/ data For the first one is very rarely we need (except probably an MMIO case) it. Even though, it won't work due to 32-bit limitations of the base offset. Considering, let's say, 4 bytes stride the current implementation may cover 36-bit of address space _only_. And 37-bit for the 8 bytes stride. For the second one it's obviously that we want _all_ bits to be covered in the data (otherwise what's the point?) and unsigned int gives us only 32-bits. With all this, revert all 64-bit excerpts from regmap API to avoid false impressions and new code that never works. Note, there are no users with such sizes in the kernel. Andy Shevchenko (3): regmap: Revert "add 64-bit mode support" and Co. regmap: cache: Revert "Add 64-bit mode support" regmap: mmio: Remove unused 64-bit support code drivers/base/regmap/regcache.c | 15 ---- drivers/base/regmap/regmap-mmio.c | 24 ------ drivers/base/regmap/regmap.c | 122 ------------------------------ 3 files changed, 161 deletions(-)
Comments
On Thu, 22 Jun 2023 21:36:10 +0300, Andy Shevchenko wrote: > regmap API internally operates on unsigned int values for the register > offsets and data. The commit back in 2015 that introduces 64-bit > excerpts in the code made a false impression that it works. Not really. > > Consider two things: > 1/ register offset > 2/ data > > [...] Applied to https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap.git for-next Thanks! [1/3] regmap: Revert "add 64-bit mode support" and Co. commit: 1425bdd7ef88631d0623ce3d0b8c89d8a65815d2 [2/3] regmap: cache: Revert "Add 64-bit mode support" commit: 039fd2e4134b7b880ba83f40a136df440047594a [3/3] regmap: mmio: Remove unused 64-bit support code commit: 875403a7b524e9523e49dd32662adbc3e48cc12a All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. Thanks, Mark