All of lore.kernel.org
 help / color / mirror / Atom feed
From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
To: Peter Griffin <peter.griffin@linaro.org>
Cc: arnd@arndb.de, linux@roeck-us.net, wim@linux-watchdog.org,
	alim.akhtar@samsung.com, jaewon02.kim@samsung.com,
	semen.protsenko@linaro.org, kernel-team@android.com,
	tudor.ambarus@linaro.org, andre.draszik@linaro.org,
	saravanak@google.com, willmcvicker@google.com,
	linux-fsd@tesla.com, linux-watchdog@vger.kernel.org,
	devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	linux-samsung-soc@vger.kernel.org
Subject: Re: [PATCH v2 1/2] soc: samsung: exynos-pmu: Add regmap support for SoCs that protect PMU regs
Date: Mon, 5 Feb 2024 12:03:28 +0100	[thread overview]
Message-ID: <8124a8f7-23c0-4773-aec2-0a3f70ee7e11@linaro.org> (raw)
In-Reply-To: <CADrjBPrNryfccFkrZWY9_4EfDF1h3VyqKcxh8vim9Hp8D_AhkQ@mail.gmail.com>

On 01/02/2024 12:29, Peter Griffin wrote:
>>>       int ret;
>>>
>>>       pmu_base_addr = devm_platform_ioremap_resource(pdev, 0);
>>> @@ -137,6 +333,35 @@ static int exynos_pmu_probe(struct platform_device *pdev)
>>>                       GFP_KERNEL);
>>>       if (!pmu_context)
>>>               return -ENOMEM;
>>> +
>>> +     res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>>> +     if (!res)
>>> +             return -ENODEV;
>>> +
>>> +     pmuregmap_config.max_register = resource_size(res) -
>>> +                                  pmuregmap_config.reg_stride;
>>> +
>>> +     if (of_device_is_compatible(np, "google,gs101-pmu")) {
>>
>> No compatibles inside the probe. Use driver match data. This applies to
>> all drivers in all subsystems.
> 
> Noted, will fix in v3.
> 
>>
>>> +             pmuregmap_config.reg_read = tensor_sec_reg_read;
>>> +             pmuregmap_config.reg_write = tensor_sec_reg_write;
>>> +             pmuregmap_config.reg_update_bits = tensor_sec_update_bits;
>>
>> No, regmap_config should be const and please use match data.
> 
> Are you sure you want the regmap_config struct const?
> 
> In my draft v3 I have implemented it so far having a regmap_smccfg
> struct which sets all the configuration apart from max_register field
> (used by gs101) and a regmap_mmiocfg struct (used by all other
> exynos-pmu SoCs). The choice over which regmap_config to register is
> made via match data exynos_pmu_data flag 'pmu_secure' which is set
> only for gs101. That avoids having to define exynos_pmu_data structs
> for the other exynos SoCs that currently don't really need them
> (exynos7, exynos850, exynos5443, exyno5410 etc).
> 
> But I still wish to set at runtime the regmap_config.max_register
> field based on the resource size coming from DT. Having the structs
> const would prohibit that and mean we need to specify many more
> regmap_config structs where the only difference is the max_register
> field.
> 
> Is the above approach acceptable for you?

Having it non-const is one more step of supporting only one instance of
PMU device, but we already rely on such design choice, so I guess it is
fine. If ever needed, this can be easily converted to devm_kmemdup...


Best regards,
Krzysztof


WARNING: multiple messages have this Message-ID (diff)
From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
To: Peter Griffin <peter.griffin@linaro.org>
Cc: arnd@arndb.de, linux@roeck-us.net, wim@linux-watchdog.org,
	alim.akhtar@samsung.com, jaewon02.kim@samsung.com,
	semen.protsenko@linaro.org, kernel-team@android.com,
	tudor.ambarus@linaro.org, andre.draszik@linaro.org,
	saravanak@google.com, willmcvicker@google.com,
	linux-fsd@tesla.com, linux-watchdog@vger.kernel.org,
	devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	linux-samsung-soc@vger.kernel.org
Subject: Re: [PATCH v2 1/2] soc: samsung: exynos-pmu: Add regmap support for SoCs that protect PMU regs
Date: Mon, 5 Feb 2024 12:03:28 +0100	[thread overview]
Message-ID: <8124a8f7-23c0-4773-aec2-0a3f70ee7e11@linaro.org> (raw)
In-Reply-To: <CADrjBPrNryfccFkrZWY9_4EfDF1h3VyqKcxh8vim9Hp8D_AhkQ@mail.gmail.com>

On 01/02/2024 12:29, Peter Griffin wrote:
>>>       int ret;
>>>
>>>       pmu_base_addr = devm_platform_ioremap_resource(pdev, 0);
>>> @@ -137,6 +333,35 @@ static int exynos_pmu_probe(struct platform_device *pdev)
>>>                       GFP_KERNEL);
>>>       if (!pmu_context)
>>>               return -ENOMEM;
>>> +
>>> +     res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>>> +     if (!res)
>>> +             return -ENODEV;
>>> +
>>> +     pmuregmap_config.max_register = resource_size(res) -
>>> +                                  pmuregmap_config.reg_stride;
>>> +
>>> +     if (of_device_is_compatible(np, "google,gs101-pmu")) {
>>
>> No compatibles inside the probe. Use driver match data. This applies to
>> all drivers in all subsystems.
> 
> Noted, will fix in v3.
> 
>>
>>> +             pmuregmap_config.reg_read = tensor_sec_reg_read;
>>> +             pmuregmap_config.reg_write = tensor_sec_reg_write;
>>> +             pmuregmap_config.reg_update_bits = tensor_sec_update_bits;
>>
>> No, regmap_config should be const and please use match data.
> 
> Are you sure you want the regmap_config struct const?
> 
> In my draft v3 I have implemented it so far having a regmap_smccfg
> struct which sets all the configuration apart from max_register field
> (used by gs101) and a regmap_mmiocfg struct (used by all other
> exynos-pmu SoCs). The choice over which regmap_config to register is
> made via match data exynos_pmu_data flag 'pmu_secure' which is set
> only for gs101. That avoids having to define exynos_pmu_data structs
> for the other exynos SoCs that currently don't really need them
> (exynos7, exynos850, exynos5443, exyno5410 etc).
> 
> But I still wish to set at runtime the regmap_config.max_register
> field based on the resource size coming from DT. Having the structs
> const would prohibit that and mean we need to specify many more
> regmap_config structs where the only difference is the max_register
> field.
> 
> Is the above approach acceptable for you?

Having it non-const is one more step of supporting only one instance of
PMU device, but we already rely on such design choice, so I guess it is
fine. If ever needed, this can be easily converted to devm_kmemdup...


Best regards,
Krzysztof


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2024-02-05 11:03 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-29 21:19 [PATCH v2 0/2] Add regmap support to exynos-pmu for protected PMU regs Peter Griffin
2024-01-29 21:19 ` Peter Griffin
2024-01-29 21:19 ` [PATCH v2 1/2] soc: samsung: exynos-pmu: Add regmap support for SoCs that protect " Peter Griffin
2024-01-29 21:19   ` Peter Griffin
2024-01-29 23:01   ` Sam Protsenko
2024-01-29 23:01     ` Sam Protsenko
2024-01-30 14:51     ` Peter Griffin
2024-01-30 14:51       ` Peter Griffin
2024-01-30  6:26   ` Guenter Roeck
2024-01-30  6:26     ` Guenter Roeck
2024-01-30 15:01     ` Peter Griffin
2024-01-30 15:01       ` Peter Griffin
2024-01-30 16:01   ` Krzysztof Kozlowski
2024-01-30 16:01     ` Krzysztof Kozlowski
2024-02-01 11:29     ` Peter Griffin
2024-02-01 11:29       ` Peter Griffin
2024-02-05 11:03       ` Krzysztof Kozlowski [this message]
2024-02-05 11:03         ` Krzysztof Kozlowski
2024-02-01 12:51     ` Peter Griffin
2024-02-01 12:51       ` Peter Griffin
2024-02-05 13:13       ` Krzysztof Kozlowski
2024-02-05 13:13         ` Krzysztof Kozlowski
2024-02-07 11:42         ` Peter Griffin
2024-02-07 11:42           ` Peter Griffin
2024-02-07 14:48           ` Krzysztof Kozlowski
2024-02-07 14:48             ` Krzysztof Kozlowski
2024-01-29 21:19 ` [PATCH v2 2/2] watchdog: s3c2410_wdt: use exynos_get_pmu_regmap_by_phandle() for " Peter Griffin
2024-01-29 21:19   ` Peter Griffin
2024-01-29 22:25   ` Saravana Kannan
2024-01-29 22:25     ` Saravana Kannan
2024-01-30  3:38     ` Sam Protsenko
2024-01-30  3:38       ` Sam Protsenko
2024-01-30 15:31       ` Peter Griffin
2024-01-30 15:31         ` Peter Griffin

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=8124a8f7-23c0-4773-aec2-0a3f70ee7e11@linaro.org \
    --to=krzysztof.kozlowski@linaro.org \
    --cc=alim.akhtar@samsung.com \
    --cc=andre.draszik@linaro.org \
    --cc=arnd@arndb.de \
    --cc=devicetree@vger.kernel.org \
    --cc=jaewon02.kim@samsung.com \
    --cc=kernel-team@android.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-fsd@tesla.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-samsung-soc@vger.kernel.org \
    --cc=linux-watchdog@vger.kernel.org \
    --cc=linux@roeck-us.net \
    --cc=peter.griffin@linaro.org \
    --cc=saravanak@google.com \
    --cc=semen.protsenko@linaro.org \
    --cc=tudor.ambarus@linaro.org \
    --cc=willmcvicker@google.com \
    --cc=wim@linux-watchdog.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.