public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Ivan Vecera <ivecera@redhat.com>
To: Andrew Lunn <andrew@lunn.ch>
Cc: 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 v3 net-next 3/8] mfd: Add Microchip ZL3073x support
Date: Thu, 17 Apr 2025 16:50:25 +0200	[thread overview]
Message-ID: <03afdbe9-8f55-4e87-bec4-a0e69b0e0d86@redhat.com> (raw)
In-Reply-To: <894d4209-4933-49bf-ae4c-34d6a5b1c9f1@lunn.ch>



On 17. 04. 25 3:13 odp., Andrew Lunn wrote:
> On Wed, Apr 16, 2025 at 08:19:25PM +0200, Ivan Vecera wrote:
>> On Wed, Apr 16, 2025 at 7:11 PM Andrew Lunn <andrew@lunn.ch> wrote:
>>
>>      > +++ b/include/linux/mfd/zl3073x_regs.h
>>      > @@ -0,0 +1,105 @@
>>      > +/* SPDX-License-Identifier: GPL-2.0-only */
>>      > +
>>      > +#ifndef __LINUX_MFD_ZL3073X_REGS_H
>>      > +#define __LINUX_MFD_ZL3073X_REGS_H
>>      > +
>>      > +#include <asm/byteorder.h>
>>      > +#include <linux/lockdep.h>
>>
>>      lockdep?
>>
>>
>> lockdep_assert*() is used in later introduced helpers.
> 
> nitpicking, but you generally add headers as they are needed.

+1


>>      > +#include <linux/mfd/zl3073x.h>
>>      > +#include <linux/regmap.h>
>>      > +#include <linux/types.h>
>>      > +#include <linux/unaligned.h>
>>      > +
>>      > +/* Registers are mapped at offset 0x100 */
>>      > +#define ZL_RANGE_OFF        0x100
>>      > +#define ZL_PAGE_SIZE        0x80
>>      > +#define ZL_REG_ADDR(_pg, _off) (ZL_RANGE_OFF + (_pg) * ZL_PAGE_SIZE +
>>      (_off))
>>      > +
>>      > +/**************************
>>      > + * Register Page 0, General
>>      > + **************************/
>>      > +
>>      > +/*
>>      > + * Register 'id'
>>      > + * Page: 0, Offset: 0x01, Size: 16 bits
>>      > + */
>>      > +#define ZL_REG_ID ZL_REG_ADDR(0, 0x01)
>>      > +
>>      > +static inline __maybe_unused int
>>      > +zl3073x_read_id(struct zl3073x_dev *zldev, u16 *value)
>>      > +{
>>      > +     __be16 temp;
>>      > +     int rc;
>>      > +
>>      > +     rc = regmap_bulk_read(zldev->regmap, ZL_REG_ID, &temp, sizeof
>>      (temp));
>>      > +     if (rc)
>>      > +             return rc;
>>      > +
>>      > +     *value = be16_to_cpu(temp);
>>      > +     return rc;
>>      > +}
>>
>>      It seems odd these are inline functions in a header file.
>>
>>
>> There are going to be used by dpll_zl3073x sub-driver in series part 2.
> 
> The subdriver needs to know the ID, firmware version, etc?

No

> Anyway, look around. How many other MFD, well actually, any sort of
> driver at all, have a bunch of low level helpers as inline functions
> in a header? You are aiming to write a plain boring driver which looks
> like every other driver in Linux....

Well, I took inline functions approach as this is safer than macro usage
and each register have own very simple implementation with type and
range control (in case of indexed registers).

It is safer to use:
zl3073x_read_ref_config(..., &v);
...
zl3073x_read_ref_config(..., &v);

than:
zl3073x_read_reg8(..., ZL_REG_REF_CONFIG, &v);
...
zl3073x_read_reg16(..., ZL_REG_REF_CONFIG, &v); /* wrong */

With inline function defined for each register the mistake in the 
example cannot happen and also compiler checks that 'v' has correct type.

> Think about your layering. What does the MFD need to offer to sub
> drivers so they can work? For lower registers, maybe just
> zl3073x_read_u8(), zl3073x_read_u16() & zl3073x_read_read_u32(). Write
> variants as well. Plus the API needed to safely access the mailbox.
> Export these using one of the EXPORT_SYMBOL_GPL() variants, so the sub
> drivers can access them. The #defines for the registers numbers can be
> placed into a shared header file.

Would it be acceptable for you something like this:

int zl3073x_read_reg{8,16,32,48}(..., unsigned int reg, u{8,16,32,64} *v);
int zl3073x_write_reg{8,16,32,48}(..., unsigned int reg, u{8,16,32,64} v);
int zl3073x_read_idx_reg{8,16,32,48}(..., unsigned int reg, unsigned int 
idx, unsigned int max_idx, unsigned int stride, u{8,16,32,64} *v);
int zl3073x_write_idx_reg{8,16,32,48}(..., unsigned int reg, unsigned 
int idx, unsigned int max_idx, unsigned int stride, u{8,16,32,64} v);

/* Simple non-indexed register */
#define ZL_REG_ID	ZL_REG_ADDR(0 /* page */, 0x01 /* offset */
#define ZL_REG_ID_BITS	8

/* Simple indexed register */
#define ZL_REG_REF_STATUS	ZL_REG_ADDR(2, 0x44)
#define ZL_REG_REF_STATUS_BITS	16
#define ZL_REG_REF_STATUS_ITEMS	10
#define ZL_REG_REF_STATUS_STRIDE 2

/* Read macro for non-indexed register */
#define ZL3073X_READ_REG(_zldev, _reg, _v)	\
	__PASTE(zl3073x_read_reg, _reg##_BITS)(_zldev, _reg, _v)

/* For indexed one */
#define ZL3073X_READ_IDX_REG(_zldev, _reg, _idx, _v)	\
	__PASTE(zl3073x_read_idx_reg, _reg##_BITS)(_zldev, _reg, _v,
						   _idx, \
						   _reg##_ITEMS, \
						   _reg##_STRIDE, _v)

This would allow to call simply
ZL3073X_READ_REG(zldev, ZL_REG_ID, &val);
or
ZL3073X_READ_IDX_REG(zldev, ZL_REG_REF_STATUS, 4);

and caller does not need to know register size and range constraints.

WDYT?

Thanks,
Ivan


  reply	other threads:[~2025-04-17 14:50 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-04-16 16:21 [PATCH v3 net-next 00/10] Add Microchip ZL3073x support (part 1) Ivan Vecera
2025-04-16 16:21 ` [PATCH v3 net-next 1/8] dt-bindings: dpll: Add device tree bindings for DPLL device and pin Ivan Vecera
2025-04-21 22:20   ` Rob Herring
2025-04-21 22:29     ` Rob Herring
2025-04-16 16:21 ` [PATCH v3 net-next 2/8] dt-bindings: dpll: Add support for Microchip Azurite chip family Ivan Vecera
2025-04-16 17:42   ` Rob Herring (Arm)
2025-04-16 18:29     ` Ivan Vecera
2025-04-17  5:54       ` Krzysztof Kozlowski
2025-04-16 16:21 ` [PATCH v3 net-next 3/8] mfd: Add Microchip ZL3073x support Ivan Vecera
2025-04-16 17:11   ` Andrew Lunn
     [not found]     ` <CAAVpwAsw4-7n_iV=8aXp7=X82Mj7M-vGAc3f-fVbxxg0qgAQQA@mail.gmail.com>
2025-04-17 13:13       ` Andrew Lunn
2025-04-17 14:50         ` Ivan Vecera [this message]
2025-04-17 15:12           ` Ivan Vecera
2025-04-17 15:42             ` Andy Shevchenko
2025-04-17 16:29               ` Ivan Vecera
2025-04-17 16:35                 ` Andy Shevchenko
2025-04-18 20:18             ` Andrew Lunn
2025-04-17 15:51   ` Andy Shevchenko
2025-04-17 15:57   ` Mark Brown
2025-04-16 16:21 ` [PATCH v3 net-next 4/8] mfd: zl3073x: Add support for devlink device info Ivan Vecera
2025-04-17 15:53   ` Andy Shevchenko
2025-04-16 16:21 ` [PATCH v3 net-next 5/8] mfd: zl3073x: Add functions to work with register mailboxes Ivan Vecera
2025-04-16 17:32   ` Andrew Lunn
2025-04-16 18:27     ` Ivan Vecera
2025-04-17 10:02       ` Ivan Vecera
2025-04-17 13:27         ` Andrew Lunn
2025-04-17 14:15           ` Ivan Vecera
2025-04-24 15:49             ` Lee Jones
2025-04-17 13:22       ` Andrew Lunn
2025-04-17 14:18         ` Ivan Vecera
2025-04-17 16:13   ` Lee Jones
2025-04-17 16:35     ` Ivan Vecera
2025-04-16 16:21 ` [PATCH v3 net-next 6/8] mfd: zl3073x: Add clock_id field Ivan Vecera
2025-04-16 16:21 ` [PATCH v3 net-next 7/8] mfd: zl3073x: Fetch invariants during probe Ivan Vecera
2025-04-16 16:21 ` [PATCH v3 net-next 8/8] mfd: zl3073x: Register DPLL sub-device during init Ivan Vecera
2025-04-17 16:20   ` Lee Jones
2025-04-17 16:40     ` Ivan Vecera
2025-04-24 15:34       ` Lee Jones
2025-04-24 15:36         ` 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=03afdbe9-8f55-4e87-bec4-a0e69b0e0d86@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=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