public inbox for linux-i2c@vger.kernel.org
 help / color / mirror / Atom feed
From: Kartik Rajput <kkartik@nvidia.com>
To: Jon Hunter <jonathanh@nvidia.com>,
	ldewangan@nvidia.com, digetx@gmail.com, andi.shyti@kernel.org,
	thierry.reding@gmail.com, akhilrajeev@nvidia.com,
	smangipudi@nvidia.com, linux-i2c@vger.kernel.org,
	linux-tegra@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3 2/4] i2c: tegra: Move variant to tegra_i2c_hw_feature
Date: Wed, 7 Jan 2026 09:40:28 +0530	[thread overview]
Message-ID: <e3a6d4f5-87cc-4d22-bf3a-f1067fe152e9@nvidia.com> (raw)
In-Reply-To: <e4be900b-207e-49b1-a7d4-5cf88e0caf2e@nvidia.com>

On 06/01/26 17:04, Jon Hunter wrote:
> 
> On 06/01/2026 11:10, Kartik Rajput wrote:
>> Move the variant field into tegra_i2c_hw_feature and populate it for all
>> SoCs. Add dedicated SoC data for "nvidia,tegra20-i2c-dvc" and
>> "nvidia,tegra210-i2c-vi" compatibles. Drop the compatible-string checks
>> from tegra_i2c_parse_dt to initialize the Tegra I2C variant. Also remove
>> the redundant config checks from IS_VI and IS_DVC macros.
>>
>> Signed-off-by: Kartik Rajput <kkartik@nvidia.com>
>> ---
>>   drivers/i2c/busses/i2c-tegra.c | 100 ++++++++++++++++++++++++++-------
>>   1 file changed, 81 insertions(+), 19 deletions(-)
>>
>> diff --git a/drivers/i2c/busses/i2c-tegra.c b/drivers/i2c/busses/i2c-tegra.c
>> index 9a09079dcc9c..4ab991a22350 100644
>> --- a/drivers/i2c/busses/i2c-tegra.c
>> +++ b/drivers/i2c/busses/i2c-tegra.c
>> @@ -235,6 +235,7 @@ enum tegra_i2c_variant {
>>    *        timing settings.
>>    * @enable_hs_mode_support: Enable support for high speed (HS) mode transfers.
>>    * @has_mutex: Has mutex register for mutual exclusion with other firmwares or VMs.
>> + * @variant: This represents the I2C controller variant.
>>    */
>>   struct tegra_i2c_hw_feature {
>>       bool has_continue_xfer_support;
>> @@ -266,6 +267,7 @@ struct tegra_i2c_hw_feature {
>>       bool has_interface_timing_reg;
>>       bool enable_hs_mode_support;
>>       bool has_mutex;
>> +    enum tegra_i2c_variant variant;
>>   };
>>   /**
>> @@ -281,7 +283,6 @@ struct tegra_i2c_hw_feature {
>>    * @base_phys: physical base address of the I2C controller
>>    * @cont_id: I2C controller ID, used for packet header
>>    * @irq: IRQ number of transfer complete interrupt
>> - * @variant: This represents the I2C controller variant.
>>    * @msg_complete: transfer completion notifier
>>    * @msg_buf_remaining: size of unsent data in the message buffer
>>    * @msg_len: length of message in current transfer
>> @@ -334,13 +335,10 @@ struct tegra_i2c_dev {
>>       bool atomic_mode;
>>       bool dma_mode;
>>       bool msg_read;
>> -    enum tegra_i2c_variant variant;
>>   };
>> -#define IS_DVC(dev) (IS_ENABLED(CONFIG_ARCH_TEGRA_2x_SOC) && \
>> -             (dev)->variant == TEGRA_I2C_VARIANT_DVC)
>> -#define IS_VI(dev)  (IS_ENABLED(CONFIG_ARCH_TEGRA_210_SOC) && \
>> -             (dev)->variant == TEGRA_I2C_VARIANT_VI)
>> +#define IS_DVC(dev) ((dev)->hw->variant == TEGRA_I2C_VARIANT_DVC)
>> +#define IS_VI(dev)  ((dev)->hw->variant == TEGRA_I2C_VARIANT_VI)
> 
> I was thinking about this and actually, I am wondering if we should leave these checks present because if these are not enabled, then the compiler should be enable to drop all the associated code at compile time. So there could be some value to keeping this as is.
> 
> Jon
> 

Ack.

  reply	other threads:[~2026-01-07  4:10 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-01-06 11:10 [PATCH v3 0/4] Add I2C support for Tegra410 Kartik Rajput
2026-01-06 11:10 ` [PATCH v3 1/4] i2c: tegra: Introduce tegra_i2c_variant to identify DVC and VI Kartik Rajput
2026-01-06 11:10 ` [PATCH v3 2/4] i2c: tegra: Move variant to tegra_i2c_hw_feature Kartik Rajput
2026-01-06 11:34   ` Jon Hunter
2026-01-07  4:10     ` Kartik Rajput [this message]
2026-01-06 11:10 ` [PATCH v3 3/4] i2c: tegra: Add logic to support different register offsets Kartik Rajput
2026-01-06 11:10 ` [PATCH v3 4/4] i2c: tegra: Add support for Tegra410 Kartik Rajput

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=e3a6d4f5-87cc-4d22-bf3a-f1067fe152e9@nvidia.com \
    --to=kkartik@nvidia.com \
    --cc=akhilrajeev@nvidia.com \
    --cc=andi.shyti@kernel.org \
    --cc=digetx@gmail.com \
    --cc=jonathanh@nvidia.com \
    --cc=ldewangan@nvidia.com \
    --cc=linux-i2c@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-tegra@vger.kernel.org \
    --cc=smangipudi@nvidia.com \
    --cc=thierry.reding@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox