From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ot1-f41.google.com (mail-ot1-f41.google.com [209.85.210.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C1CC5253B64 for ; Fri, 19 Sep 2025 15:05:30 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.210.41 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1758294332; cv=none; b=UlrSOQsbNNF2/SA/1EOgnzLdYWyyG5Kz5rhczVhC/TMYKeTH1WhzDVmYy4On6VXwNHSlcWmqtVjy5Qe/4aWLcx+6RZqObdg04GlLcToXGxSohXxggmtndgSrMPlDQUmiTKrlgvgsKgwNNZ85KkE5UHti91SaycC5tTSpkQnCOcs= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1758294332; c=relaxed/simple; bh=uUO5CwNe87tHFiGJHfDcIkGWhy/VeqLMEjuLJD/XXms=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=qmmTmXS72i6UkvnJM6HKt9YJBlenUqMa/S1SpA0joKrMquKMaHu77+IJX0kfGc+TUfgHZV2XIXy4Jj2FXCazV5yCU7DUIiFaR+OCl89T30yAUxUZcZWYDWFfn3YxmBcEu2bk6n4tKAt2ejkKKmivkyyNVzLWmL+yQRlyaW5vf0A= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=baylibre.com; spf=pass smtp.mailfrom=baylibre.com; dkim=pass (2048-bit key) header.d=baylibre-com.20230601.gappssmtp.com header.i=@baylibre-com.20230601.gappssmtp.com header.b=woZR/Vwe; arc=none smtp.client-ip=209.85.210.41 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=baylibre.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=baylibre.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=baylibre-com.20230601.gappssmtp.com header.i=@baylibre-com.20230601.gappssmtp.com header.b="woZR/Vwe" Received: by mail-ot1-f41.google.com with SMTP id 46e09a7af769-74c7d98935eso1181525a34.1 for ; Fri, 19 Sep 2025 08:05:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=baylibre-com.20230601.gappssmtp.com; s=20230601; t=1758294330; x=1758899130; darn=vger.kernel.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=Di+7QfVxJlM5N75ul507uuevWczBYUSs/W+lEnzOwXU=; b=woZR/VweK1NvvB6TIZua48lsV+oiangk7axDdMcsoK9f4wpnu3zmJGk0mXwEBvOeVA hijXr1T4zmRXHLqVp7VvL9w9sew8NlTvQ/n+RqssOo8QtJDIJ/2gro6lc9SDqqsWcSG+ qoFfoEZoMVeqG5lK/Y3im6X6MQ9AiAMh0UM/2MWuF8KFXhiSDcMjh6irW4jF/DUZuf/i pNTlsPJLA3J837/IUr6F2h2VukF2RZylHItVPfRVUO+08N5grdPBif8suTYQqEf2dmUI nMNN8gEHdOs++8S2AJZTFlvuYmZSgiSpOlY+anD8fJslO92E0IYcKM1kFlsUnGj8KaAl JZww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1758294330; x=1758899130; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=Di+7QfVxJlM5N75ul507uuevWczBYUSs/W+lEnzOwXU=; b=Ih0WQceJ9vcARzfMfgR2Qc7GvFuhi7sX4Ss+SCsJyYKwF06VbVAotl62ukK4hHEif6 CRebtAgO34HbW0aXmk72vultibu3cnxBk7qzrMeysyzVHLvR48pD0vb6yUe0igph5bpX CqkC7iGWhKc1PkV0MyYi8DAJPwb//04wCj6csILXoUkFptu+QGZG+RF2PhYFJfz7HPEV e20htkJm0it1n65AEYUTOz7dGOvOP2WYkjyopwNPTFb/KtpKJwomdXooWW0VgkCexhMH Vsfcpkdn6/Xm1vmQbHkH9edL2NlrzlpD/4xRhLHCKHzhUY66ovWJQGx83iqnHO93OghR AfJg== X-Forwarded-Encrypted: i=1; AJvYcCXWuQofQGoq1jxbxg0LwN3o596fIHwNRcXu0Z4+lCwxSmqLKpwNXjOEncnM5/Auzo2LA+Jmb5JDhA==@vger.kernel.org X-Gm-Message-State: AOJu0YzOuuN4rgHitiM2ZCKilJlsQtynYBL4WiambeSH//t9QNZ9CCJn gWJuO4xF0LhnAApx85vY568ehWzYnJrMhQB+Dilrl+3CimqdmTsvnSgiH6YktR8Qnfg= X-Gm-Gg: ASbGnctlT9W/74OwPaH31HzaAvv548jzvI4C+gIMma1L2KvR5WMe0Jutvn35Dv3NkuU IEWcWiqTgtfukb3jDt1FHCyFEx+VSZdAXH3nluUJw2DZrKyB4LKa74PLlqQQXUzVESPiQ85A1kQ Ple8YhlS3/T6TtBZuop4Sk+cWJTSgRXcAjoZHLP6RSaqznfpNItucUhblR2S5E33yP3UPGMtD06 m19hL0WeR7ePQLYeshEaT0REnVVfbGp3fYifnSjFnCVHdoD+lySHEyNaYK6WVB47JfaLj3f5Ciu zwCkMN2RTsOUjJkdbq8AI/pLUjzCXsq9HakGfOECa2noWZfdbCEOdC1T2PuYDfSDI8lmg3DEbN5 LXnzu127v/klnNz2L+YrYSS7QwKzgofhRcQ2/ufNy0gkyEmzsRLzdry2nPtXEgEgjF5L17fIyaY M= X-Google-Smtp-Source: AGHT+IG08d5Vz/pDeKppQVqd3yfcz+3VBkwoo1u5Ijv/qxwiGp1N6zahOZ2QY1NxeZ4IhBE5UjoRGQ== X-Received: by 2002:a05:6830:4902:b0:74b:7c40:357a with SMTP id 46e09a7af769-76f77d489e4mr1731055a34.18.1758294329709; Fri, 19 Sep 2025 08:05:29 -0700 (PDT) Received: from ?IPV6:2600:8803:e7e4:1d00:3838:157c:c9f9:2e3f? ([2600:8803:e7e4:1d00:3838:157c:c9f9:2e3f]) by smtp.gmail.com with ESMTPSA id 006d021491bc7-625d8eec45csm1692036eaf.10.2025.09.19.08.05.28 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 19 Sep 2025 08:05:29 -0700 (PDT) Message-ID: Date: Fri, 19 Sep 2025 10:05:28 -0500 Precedence: bulk X-Mailing-List: linux-pm@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v4 2/7] nvmem: qcom-spmi-sdam: Migrate to devm_spmi_subdevice_alloc_and_add() To: Greg KH , Andy Shevchenko Cc: =?UTF-8?Q?Uwe_Kleine-K=C3=B6nig?= , Andy Shevchenko , AngeloGioacchino Del Regno , sboyd@kernel.org, jic23@kernel.org, nuno.sa@analog.com, andy@kernel.org, arnd@arndb.de, srini@kernel.org, vkoul@kernel.org, kishon@kernel.org, sre@kernel.org, krzysztof.kozlowski@linaro.org, linux-arm-msm@vger.kernel.org, linux-iio@vger.kernel.org, linux-kernel@vger.kernel.org, linux-phy@lists.infradead.org, linux-pm@vger.kernel.org, kernel@collabora.com, wenst@chromium.org, casey.connolly@linaro.org, Konrad Dybcio , Neil Armstrong References: <20250916084445.96621-1-angelogioacchino.delregno@collabora.com> <20250916084445.96621-3-angelogioacchino.delregno@collabora.com> <2025091925-thirsting-underuse-14ab@gregkh> Content-Language: en-US From: David Lechner In-Reply-To: <2025091925-thirsting-underuse-14ab@gregkh> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 9/19/25 8:59 AM, Greg KH wrote: > On Thu, Sep 18, 2025 at 10:00:29PM +0300, Andy Shevchenko wrote: >> I,o.w. I principally disagree on putting MODULE_IMPORT_NS() into the header >> file. > > Yes, please never do that, it defeats the purpose of module namespaces > completly. If you don't want to have module namespaces, don't use them > for your subsytem. Don't use them and then make them moot by putting > MODULE_IMPORT_NS() in the .h file for the symbols as that's pointless. > > thanks, > > greg k-h Could someone suggest some additional explanation to add to Documentation/core-api/symbol-namespaces.rst to explain the reasoning behind this? Right now, the only part of that document that say _why_ we have module namespces says: That is useful for documentation purposes (think of the SUBSYSTEM_DEBUG namespace) as well as for limiting the availability of a set of symbols for use in other parts of the kernel. So I don't see the connection between this explanation and and: [Putting MODULE_IMPORT_NS() into the header] defeats the purpose of module namespaces completely. I am guilty of putting it in a header, so if I need to fix that I would like to actually understand why first. Andy has mentioned something about potential abuses, but without any example, I haven't been able to understand what this would actually actually look like. Or maybe there is some other reason that Greg is thinking of that hasn't been mentioned yet?