Linux Hardware Monitor development
 help / color / mirror / Atom feed
From: Guenter Roeck <linux@roeck-us.net>
To: Tzung-Bi Shih <tzungbi@kernel.org>
Cc: Hardware Monitoring <linux-hwmon@vger.kernel.org>
Subject: Re: [PATCH 04/11] hwmon: (ina2xx) Mark regmap_config as const
Date: Thu, 29 Aug 2024 09:44:37 -0700	[thread overview]
Message-ID: <2104a78d-acd7-4b04-b5cc-bb4e73c2d9fb@roeck-us.net> (raw)
In-Reply-To: <ZtCLji0GiNhoA5PB@tzungbi-laptop>

On 8/29/24 07:54, Tzung-Bi Shih wrote:
> On Tue, Aug 27, 2024 at 08:34:48AM -0700, Guenter Roeck wrote:
>> Doing so reveals a potential problem in the driver: If both supported
>> chips are present in a single system, the maximum number of registers
>> may race when devic es are instantiated since max_registers is updated
>                       ^

Fixed, thanks.

> 
>> in the probe function. Solve the problem by setting .max_registers to the
>> maximum register address of all supported chips. This does not make a
>> practical difference while fixing the potential race condition and reducing
>> code complexity.
> 
> It also makes regmap could access out-of-boundary (e.g. [1]).  Is it harmless?
> 
> [1]: https://elixir.bootlin.com/linux/v6.10/source/drivers/base/regmap/regmap-debugfs.c#L441
> 

Yes, that is not worth bothering about. Any driver not using regmap but accessing
i2c registers directly could do the same, after all. The regmap limits are just
another level of protection against invalid accesses, but they are not essential.
On top of that, direct i2c accesses to the chip are still possible, even
while using regmap.

If we wanted to be really paranoid, we could provide chip specific readable_reg /
writeable_reg / volatile_reg callbacks, but IMO that would be overkill.

Thanks,
Guenter


  reply	other threads:[~2024-08-29 16:44 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-08-27 15:34 [PATCH 00/11] hwmon: (ina2xx) Cleanup and convert to use with_info API Guenter Roeck
2024-08-27 15:34 ` [PATCH 01/11] hwmon: (ina2xx) Reorder include files to alphabetic order Guenter Roeck
2024-08-29 14:53   ` Tzung-Bi Shih
2024-08-27 15:34 ` [PATCH 02/11] hwmon: (ina2xx) Replace platform data with device properties Guenter Roeck
2024-08-29 14:53   ` Tzung-Bi Shih
2024-08-27 15:34 ` [PATCH 03/11] hwmon: (ina2xx) Use bit operations Guenter Roeck
2024-08-29 14:53   ` Tzung-Bi Shih
2024-08-27 15:34 ` [PATCH 04/11] hwmon: (ina2xx) Mark regmap_config as const Guenter Roeck
2024-08-29 14:54   ` Tzung-Bi Shih
2024-08-29 16:44     ` Guenter Roeck [this message]
2024-08-27 15:34 ` [PATCH 05/11] hwmon: (ina2xx) Use local regmap pointer if used more than once Guenter Roeck
2024-08-29 14:54   ` Tzung-Bi Shih
2024-08-27 15:34 ` [PATCH 06/11] hwmon: (ina2xx) Re-initialize chip using regmap functions Guenter Roeck
2024-08-29 14:54   ` Tzung-Bi Shih
2024-08-29 16:45     ` Guenter Roeck
2024-08-27 15:34 ` [PATCH 07/11] hwmon: (ina2xx) Set alert latch when enabling alerts Guenter Roeck
2024-08-29 14:54   ` Tzung-Bi Shih
2024-08-29 17:28     ` Guenter Roeck
2024-08-27 15:34 ` [PATCH 08/11] hwmon: (ina2xx) Fix various overflow issues Guenter Roeck
2024-08-29 14:55   ` Tzung-Bi Shih
2024-08-29 16:56     ` Guenter Roeck
2024-08-27 15:34 ` [PATCH 09/11] hwmon: (ina2xx) Consolidate chip initialization code Guenter Roeck
2024-08-29 14:55   ` Tzung-Bi Shih
2024-08-29 16:57     ` Guenter Roeck
2024-08-27 15:34 ` [PATCH 10/11] hwmon: (ina2xx) Move ina2xx_get_value() Guenter Roeck
2024-08-29 14:55   ` Tzung-Bi Shih
2024-08-27 15:34 ` [PATCH 11/11] hwmon: (ina2xx) Convert to use with_info hwmon API Guenter Roeck
2024-08-29 14:55   ` Tzung-Bi Shih
2024-08-29 16:53     ` Guenter Roeck

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=2104a78d-acd7-4b04-b5cc-bb4e73c2d9fb@roeck-us.net \
    --to=linux@roeck-us.net \
    --cc=linux-hwmon@vger.kernel.org \
    --cc=tzungbi@kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox