From: Ivan Vecera <ivecera@redhat.com>
To: Krzysztof Kozlowski <krzk@kernel.org>, netdev@vger.kernel.org
Cc: 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 06/14] mfd: zl3073x: Add macros for device registers access
Date: Thu, 10 Apr 2025 10:20:56 +0200 [thread overview]
Message-ID: <b73e1103-a670-43da-8f1a-b9c99cd1a90d@redhat.com> (raw)
In-Reply-To: <3e12b213-db36-4a76-9a58-c62dc8b1b2ce@kernel.org>
On 10. 04. 25 9:17 dop., Krzysztof Kozlowski wrote:
> On 09/04/2025 16:42, Ivan Vecera wrote:
>> Add several macros to access device registers. These macros
>> defines a couple of static inline functions to ease an access
>> device registers. There are two types of registers, the 1st type
>> is a simple one that is defined by an address and size and the 2nd
>> type is indexed register that is defined by base address, type,
>> number of register instances and address stride between instances.
>>
>> Examples:
>> __ZL3073X_REG_DEF(reg1, 0x1234, 4, u32);
>> __ZL3073X_REG_IDX_DEF(idx_reg2, 0x1234, 2, u16, 4, 0x10);
>
> Why can't you use standard FIELD_ macros? Why inventing the wheel again?
This is not about FIELD_* macros replacement. This is an abstraction to
access device registers in safe manner. Generated inline functions
ensures that proper value or pointer to value type is passed by caller.
Also in case of arbitrary zl3073x_{read,write_{,idx}_reg() the does not
need to know what is the register address.
If the caller just need to read regX or indexed regY it will call just
zl3073x_read_regX(..., &value);
zl3073x_read_regX(..., idx, &value);
instead of
zl3073x_read_reg(..., ZL3073x_REGX_ADDR, &value);
zl3073x_read_reg(..., ZL3073x_REGY_ADDR + (idx * ZL3073X_REGY_STRIDE),
&value)
The 1st variant is additionally type safe, the caller is warned if it is
passing u8 * instead of u32 *.
I tried to take similar approach the mlxsw driver took to access device
registers.
If you are only against such macro usage for static inline functions
generation, I can avoid them and pre-create them in separate include
file like zl3073x_regs.h
>> this defines the following functions:
>> int zl3073x_read_reg1(struct zl3073x_dev *dev, u32 *value);
>> int zl3073x_write_reg1(struct zl3073x_dev *dev, u32 value);
>> int zl3073x_read_idx_reg2(struct zl3073x_dev *dev, unsigned int idx,
>> u32 *value);
>> int zl3073x_write_idx_reg2(struct zl3073x_dev *dev, unsigned int idx,
>> u32 value);
>
> Do not copy code into commit msg. I asked about this last time. Explain
> why do you need it, why existing API is not good.
Will drop... I wanted only show how the macros work and what is their output
>>
>> There are also several shortcut macros to define registers with
>> certain bit widths: 8, 16, 32 and 48 bits.
>>
>> Signed-off-by: Ivan Vecera <ivecera@redhat.com>
>> ---
>
>
> ...
>
>> + *
>> + * Note that these functions have to be called with the device lock
>> + * taken.
>> + */
>> +#define __ZL3073X_REG_IDX_DEF(_name, _addr, _len, _type, _num, _stride) \
>> +typedef _type zl3073x_##_name##_t; \
>> +static inline __maybe_unused \
>> +int zl3073x_read_##_name(struct zl3073x_dev *zldev, unsigned int idx, \
>> + _type * value) \
>> +{ \
>> + WARN_ON(idx >= (_num)); \
>
> No need to cause panic reboots. Either review your code so this does not
> happen or properly handle.
Ack, will replace by
if (idx >= (_num))
return -EINVAL
Thanks,
Ivan
next prev parent reply other threads:[~2025-04-10 8:21 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 [this message]
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
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=b73e1103-a670-43da-8f1a-b9c99cd1a90d@redhat.com \
--to=ivecera@redhat.com \
--cc=Prathosh.Satish@microchip.com \
--cc=akpm@linux-foundation.org \
--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
all inboxes | Powered by JetHome®