devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Ivan Vecera <ivecera@redhat.com>
To: Andrew Lunn <andrew@lunn.ch>, Andy Shevchenko <andy@kernel.org>
Cc: Krzysztof Kozlowski <krzk@kernel.org>,
	netdev@vger.kernel.org,
	Vadim Fedorenko <vadim.fedorenko@linux.dev>,
	Arkadiusz Kubalewski <arkadiusz.kubalewski@intel.com>,
	Jiri Pirko <jiri@resnulli.us>, Rob Herring <robh@kernel.org>,
	Krzysztof Kozlowski <krzk+dt@kernel.org>,
	Conor Dooley <conor+dt@kernel.org>,
	Prathosh Satish <Prathosh.Satish@microchip.com>,
	Lee Jones <lee@kernel.org>, Kees Cook <kees@kernel.org>,
	Andy Shevchenko <andy@kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Michal Schmidt <mschmidt@redhat.com>,
	devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-hardening@vger.kernel.org
Subject: Re: [PATCH v2 07/14] mfd: zl3073x: Add components versions register defs
Date: Tue, 15 Apr 2025 12:01:43 +0200	[thread overview]
Message-ID: <9de10e97-d0fa-4dee-b98a-e4b2a3f7019c@redhat.com> (raw)
In-Reply-To: <8c5fb149-af25-4713-a9c8-f49b516edbff@lunn.ch>

On 10. 04. 25 11:54 odp., Andrew Lunn wrote:
> ...
> 
> So a small number of registers in the regmap need special locking. It
> was not clear to me what exactly those locking requirements are,
> because they don't appear to be described.
> 
> But when i look at the code above, the scoped guard gives the
> impression that i have to read id, revision, fw_vr and cfg_ver all in
> one go without any other reads/writes happening. I strongly suspect
> that impression is wrong. The question then becomes, how can i tell
> apart reads/writes which do need to be made as one group, form others
> which can be arbitrarily ordered with other read/writes.
> 
> What i suggest you do is try to work out how to push the locking down
> as low as possible. Make the lock cover only what it needs to cover.
> 
> Probably for 95% of the registers, the regmap lock is sufficient.
> 
> Just throwing out ideas, i've no idea if they are good or not. Create
> two regmaps onto your i2c device, covering different register
> ranges. The 'normal' one uses standard regmap locking, the second
> 'special' one has locking disabled. You additionally provide your own
> lock functions to the 'normal' one, so you have access to the
> lock. When you need to access the mailboxes, take the lock, so you
> know the 'normal' regmap cannot access anything, and then use the
> 'special' regmap to do what you need to do. A structure like this
> should help explain what the special steps are for those special
> registers, while not scattering wrong ideas about what the locking
> scheme actually is all over the code.

Hi Andrew,
the idea looks interesting but there are some caveats and disadvantages.
I thought about it but the idea with two regmaps (one for simple 
registers and one for mailboxes) where the simple one uses implicit 
locking and mailbox one has locking disabled with explicit locking 
requirement. There are two main problems:

1) Regmap cache has to be disabled as it cannot be shared between 
multiple regmaps... so also page selector cannot be cached.

2) You cannot mix access to mailbox registers and to simple registers. 
This means that mailbox accesses have to be wrapped e.g. inside 
scoped_guard()

The first problem is really pain as I would like to extend later the 
driver with proper caching (page selector for now).
The second one brings only confusions for a developer how to properly 
access different types of registers.

I think the best approach would be to use just single regmap for all 
registers with implicit locking enabled and have extra mailbox mutex to 
protect mailbox registers and ensure atomic operations with them.
This will allow to use regmap cache and also intermixing mailbox and 
simple registers' accesses won't be an issue.

@Andy Shevchenko, wdym about it?

Thanks,
Ivan


  reply	other threads:[~2025-04-15 10:01 UTC|newest]

Thread overview: 65+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-04-09 14:42 [PATCH v2 00/14] Add Microchip ZL3073x support (part 1) Ivan Vecera
2025-04-09 14:42 ` [PATCH v2 01/14] dt-bindings: dpll: Add device tree bindings for DPLL device and pin Ivan Vecera
2025-04-09 14:42 ` [PATCH v2 02/14] dt-bindings: dpll: Add support for Microchip Azurite chip family Ivan Vecera
2025-04-10  7:06   ` Krzysztof Kozlowski
2025-04-10  7:45     ` Ivan Vecera
2025-04-10 13:18       ` Conor Dooley
2025-04-10 13:35         ` Ivan Vecera
2025-04-10 17:07           ` Prathosh.Satish
2025-04-10 17:36             ` Ivan Vecera
2025-04-10 18:36               ` Prathosh.Satish
2025-04-10 17:36             ` Andrew Lunn
2025-04-10 18:33               ` Ivan Vecera
2025-04-10 21:12                 ` Andrew Lunn
2025-04-11  9:56                   ` Ivan Vecera
2025-04-14 17:19                     ` Conor Dooley
2025-04-09 14:42 ` [PATCH v2 03/14] mfd: Add Microchip ZL3073x support Ivan Vecera
2025-04-09 15:43   ` Andy Shevchenko
2025-04-10  7:19     ` Krzysztof Kozlowski
2025-04-10  7:52       ` Ivan Vecera
2025-04-10 17:50         ` Andrew Lunn
2025-04-10 18:36           ` Ivan Vecera
2025-04-09 14:42 ` [PATCH v2 04/14] mfd: zl3073x: Register itself as devlink device Ivan Vecera
2025-04-19 12:40   ` kernel test robot
2025-04-19 14:03   ` kernel test robot
2025-04-09 14:42 ` [PATCH v2 05/14] mfd: zl3073x: Add register access helpers Ivan Vecera
2025-04-09 14:42 ` [PATCH v2 06/14] mfd: zl3073x: Add macros for device registers access Ivan Vecera
2025-04-10  7:17   ` Krzysztof Kozlowski
2025-04-10  8:20     ` Ivan Vecera
2025-04-10 17:53       ` Andy Shevchenko
2025-04-13 10:18         ` Ivan Vecera
2025-04-09 14:42 ` [PATCH v2 07/14] mfd: zl3073x: Add components versions register defs Ivan Vecera
2025-04-10  7:13   ` Krzysztof Kozlowski
2025-04-10  8:26     ` Ivan Vecera
2025-04-10 17:41       ` Andrew Lunn
2025-04-10 18:44         ` Ivan Vecera
2025-04-10 21:54           ` Andrew Lunn
2025-04-15 10:01             ` Ivan Vecera [this message]
2025-04-15 11:16               ` Andy Shevchenko
2025-04-15 12:57               ` Andrew Lunn
2025-04-15 14:20                 ` Ivan Vecera
2025-04-10 17:50   ` Andy Shevchenko
2025-04-11 11:19     ` Ivan Vecera
2025-04-11 12:31       ` Andrew Lunn
2025-04-11 13:19         ` Ivan Vecera
2025-04-11 13:17       ` Ivan Vecera
2025-04-13 19:50         ` Andrew Lunn
2025-04-09 14:42 ` [PATCH v2 08/14] mfd: zl3073x: Implement devlink device info Ivan Vecera
2025-04-09 14:42 ` [PATCH v2 09/14] mfd: zl3073x: Add macro to wait for register value bits to be cleared Ivan Vecera
2025-04-09 14:42 ` [PATCH v2 10/14] mfd: zl3073x: Add functions to work with register mailboxes Ivan Vecera
2025-04-09 14:42 ` [PATCH v2 11/14] mfd: zl3073x: Add clock_id field Ivan Vecera
2025-04-09 14:42 ` [PATCH v2 12/14] lib: Allow modules to use strnchrnul Ivan Vecera
2025-04-09 14:42 ` [PATCH v2 13/14] mfd: zl3073x: Load mfg file into HW if it is present Ivan Vecera
2025-04-09 14:42 ` [PATCH v2 14/14] mfd: zl3073x: Fetch invariants during probe Ivan Vecera
2025-04-10  0:17 ` [PATCH v2 00/14] Add Microchip ZL3073x support (part 1) Jakub Kicinski
2025-04-10  9:18   ` Ivan Vecera
2025-04-10 17:26     ` Andrew Lunn
2025-04-10 22:57     ` Jakub Kicinski
2025-04-11  7:45       ` Ivan Vecera
2025-04-10  7:29 ` Lee Jones
2025-04-11  7:26 ` Lee Jones
2025-04-11  8:01   ` Ivan Vecera
2025-04-11 14:27   ` Michal Schmidt
2025-04-11 14:38     ` Michal Schmidt
2025-04-11 15:58     ` Rob Herring
2025-04-15 10:28       ` Lee Jones

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=9de10e97-d0fa-4dee-b98a-e4b2a3f7019c@redhat.com \
    --to=ivecera@redhat.com \
    --cc=Prathosh.Satish@microchip.com \
    --cc=akpm@linux-foundation.org \
    --cc=andrew@lunn.ch \
    --cc=andy@kernel.org \
    --cc=arkadiusz.kubalewski@intel.com \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=jiri@resnulli.us \
    --cc=kees@kernel.org \
    --cc=krzk+dt@kernel.org \
    --cc=krzk@kernel.org \
    --cc=lee@kernel.org \
    --cc=linux-hardening@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mschmidt@redhat.com \
    --cc=netdev@vger.kernel.org \
    --cc=robh@kernel.org \
    --cc=vadim.fedorenko@linux.dev \
    /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;
as well as URLs for NNTP newsgroup(s).