Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
From:   "Sa, Nuno" <Nuno.Sa@analog.com>
To:     "Sa, Nuno" <Nuno.Sa@analog.com>,
        Jonathan Cameron <Jonathan.Cameron@Huawei.com>
CC:     Jonathan Cameron <jic23@kernel.org>,
        "Miclaus, Antoniu" <Antoniu.Miclaus@analog.com>,
        "linux-iio@vger.kernel.org" <linux-iio@vger.kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
        "robh+dt@kernel.org" <robh+dt@kernel.org>
Subject: RE: [PATCH v4 1/2] iio: frequency: adrf6780: add support for ADRF6780
Thread-Topic: [PATCH v4 1/2] iio: frequency: adrf6780: add support for
 ADRF6780
Thread-Index: AQHXbzN7IY9R84leFkqsPFMOIAAoUasxeo0AgAKyeUCAAYBQgIAAFNGggAFwxKA=
Date:   Wed, 7 Jul 2021 08:26:59 +0000
Message-ID: <PH0PR03MB6366BC5E806B18A8889EDDE9991A9@PH0PR03MB6366.namprd03.prod.outlook.com>
References: <20210702111239.174189-1-antoniu.miclaus@analog.com>
        <20210703175716.7864358a@jic23-huawei>
        <PH0PR03MB63667CCA2691D4A43F28041E991C9@PH0PR03MB6366.namprd03.prod.outlook.com>
 <20210706100405.00001507@Huawei.com>
 <PH0PR03MB6366190FBDC12B1AD1CCBC43991B9@PH0PR03MB6366.namprd03.prod.outlook.com>
In-Reply-To: <PH0PR03MB6366190FBDC12B1AD1CCBC43991B9@PH0PR03MB6366.namprd03.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?V4aNz9H5K5nr0quxFgNZ1C1PrSn1Ljr44HjqP/vfZxl4dqb9GdMbn5J/sc?=
 =?iso-8859-1?Q?Y/B3SGcH97iZqCin1veBoHjEhwfXXgy7dBPTKX3ghy/Bew1cuQnJf+c+K6?=
 =?iso-8859-1?Q?FfTSi3baZ62R87InpgHOOel6Q2aa3tSef7ldvWj9+tTtCA3VYOtPDAohdZ?=
 =?iso-8859-1?Q?E5qKjz4PZgMe45HjLgnKO9RgM41hoQCjGNU71j5nDaCpKDlWTc10LAJU7L?=
 =?iso-8859-1?Q?JGm3b07CfLbQjLCSJ1iDmOe5lE6v8b42YPtbzeNquaPfdbfT8QmJivDjaT?=
 =?iso-8859-1?Q?f1bboyleaujFjCzs1qxpdi9L5pXMb1MlJMI2ThnJ1au3fnuXMQc0pQxUJ2?=
 =?iso-8859-1?Q?B6Z9S2IF3Hx//JAPR0vpubRrX+3wh8loFkCWnGkIl2QDtfar06wCHUjqPD?=
 =?iso-8859-1?Q?Iwn7iysWhk91jq5hL9rxsmmAdt9VfIofIaQHDFGMW/EvosNayo9ZwDxfo+?=
 =?iso-8859-1?Q?25UHVIei+LkP1xSA2Ux+sbgfYRkRoUMXz18R+D0hEm2tGk++FvPWwFzWze?=
 =?iso-8859-1?Q?beNb9iWhcqoyK9/mgYW+jR4DITcKrV47CnItHZRrdz1GoKqSPPTuP1Vw9U?=
 =?iso-8859-1?Q?mdICs1PUIT2sPKCW+8fpm/+XWTpQDHXOKI+Q8ptOdTR7XepZBEnN6ANT5G?=
 =?iso-8859-1?Q?EF/JM7VSWIApGJ+klAnKjZ5GMF0DzF3jaYDGmsFb+KyXBBx1uH6T2nWybt?=
 =?iso-8859-1?Q?xqGWP3TF+aPJTankhwLVKvpQD2cxj4Pi8XJrH7+2Yal8Qw1cFvGf+lv3le?=
 =?iso-8859-1?Q?b9CNCU7yKEhqUdL1zHU00gSVJSUVXPJ1y4aSI7R789mmQ7Iz19Rhn7G0Mk?=
 =?iso-8859-1?Q?BIV2FN4xwlvTbB9DtrNqt3oNHhBcczVqujjBNUllhPfvYpp1Z86jPNiPgj?=
 =?iso-8859-1?Q?muvZnqwxZKwH8uswiIKuCIV41tDpgnIlW2mnXCwi1Ty9w+IQRy54Qk4dgF?=
 =?iso-8859-1?Q?XPDHA7cjvHqMfSocK8zfFGbf1SjEimz0I0jic3vmtV99iEJHAi+KIjmhF1?=
 =?iso-8859-1?Q?GVNj73uaOmnc4rUlYasKBgFONge5BuCQAB8Zu7XOCLHTlErHvcQUrIV8YE?=
 =?iso-8859-1?Q?gCS3gkkFlLyZdt3nz/vf5J+G+3lsfwYWdwBaqom+aEdc3jlV6Xbv8h0q15?=
 =?iso-8859-1?Q?KI1DB7WEp42ylpIZ81Ob4g2GSTyy+rVu/mdKtZbsq7h1heeOli4HxCTGLn?=
 =?iso-8859-1?Q?FuXb4nwhQTrVT7fRmhyOKBASKd2IEdoXPg4NIfK6BCL4WXVeMilK2SaIh0?=
 =?iso-8859-1?Q?kOo5QjJOWb4DUbpfz5Ky8eAqCZXWcJ1edVzRXA5/G9PM9khN8u0w0aH2gL?=
 =?iso-8859-1?Q?g5UiieYuKWRGxlO3A2Y05fT3QYrLkN6GRzGXZ0igac1mu4h1W5YR3dhCrQ?=
 =?iso-8859-1?Q?R7OCYp2sF5WYmlRxm0fmwr6Q10UrlgJJt284j5jgbmj/KtTvaZLyI=3D?=
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: analog.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: PH0PR03MB6366.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 1f5d6b2d-83f6-43b8-c453-08d94120fd9a
X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Jul 2021 08:26:59.8008
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: eaa689b4-8f87-40e0-9c6f-7228de4d754a
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: 3VpvvpD8VjRvO0YIlfobKjQ7w0aASw6wUyWTAW0P+pCVbdH2honBy//tBdmm8e3A4E/U8FxKcs0jfcHw4ILnuQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR03MB5798
X-Proofpoint-ORIG-GUID: NHho8Y243e4TMxGxgZBeWfra13Q3Q-LS
X-Proofpoint-GUID: nStr3gu91CFzF3pnu8Lg1lU1SE3sFOlo
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391,18.0.790
 definitions=2021-07-07_05:2021-07-06,2021-07-07 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 mlxscore=0 bulkscore=0
 phishscore=0 adultscore=0 clxscore=1015 spamscore=0 suspectscore=0
 mlxlogscore=999 impostorscore=0 lowpriorityscore=0 priorityscore=1501
 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1
 engine=8.12.0-2104190000 definitions=main-2107070049
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

> From: Sa, Nuno <Nuno.Sa@analog.com>
> Sent: Tuesday, July 6, 2021 12:23 PM
> To: Jonathan Cameron <Jonathan.Cameron@Huawei.com>
> Cc: Jonathan Cameron <jic23@kernel.org>; Miclaus, Antoniu
> <Antoniu.Miclaus@analog.com>; linux-iio@vger.kernel.org; linux-
> kernel@vger.kernel.org; devicetree@vger.kernel.org;
> robh+dt@kernel.org
> Subject: RE: [PATCH v4 1/2] iio: frequency: adrf6780: add support for
> ADRF6780
>=20
>=20
>=20
> > From: Jonathan Cameron <Jonathan.Cameron@Huawei.com>
> > Sent: Tuesday, July 6, 2021 11:04 AM
> > To: Sa, Nuno <Nuno.Sa@analog.com>
> > Cc: Jonathan Cameron <jic23@kernel.org>; Miclaus, Antoniu
> > <Antoniu.Miclaus@analog.com>; linux-iio@vger.kernel.org; linux-
> > kernel@vger.kernel.org; devicetree@vger.kernel.org;
> > robh+dt@kernel.org
> > Subject: Re: [PATCH v4 1/2] iio: frequency: adrf6780: add support for
> > ADRF6780
> >
> > On Mon, 5 Jul 2021 10:18:51 +0000
> > "Sa, Nuno" <Nuno.Sa@analog.com> wrote:
> >
> > > > -----Original Message-----
> > > > From: Jonathan Cameron <jic23@kernel.org>
> > > > Sent: Saturday, July 3, 2021 6:57 PM
> > > > To: Miclaus, Antoniu <Antoniu.Miclaus@analog.com>
> > > > Cc: linux-iio@vger.kernel.org; linux-kernel@vger.kernel.org;
> > > > devicetree@vger.kernel.org; robh+dt@kernel.org
> > > > Subject: Re: [PATCH v4 1/2] iio: frequency: adrf6780: add support
> > for
> > > > ADRF6780
> > > >
> > > > On Fri, 2 Jul 2021 14:12:38 +0300
> > > > Antoniu Miclaus <antoniu.miclaus@analog.com> wrote:
> > > >
> > > > > The ADRF6780 is a silicon germanium (SiGe) design, wideband,
> > > > > microwave upconverter optimized for point to point microwave
> > > > > radio designs operating in the 5.9 GHz to 23.6 GHz frequency
> > > > > range.
> > > > >
> > > > > Datasheet:
> > > > > https://www.analog.com/media/en/technical-
> > documentation/data-
> > > > sheets/ADRF6780.pdf
> > > > >
> > > > > Signed-off-by: Antoniu Miclaus <antoniu.miclaus@analog.com>
> > > >
> > > > Hi Antoniu,
> > > >
> > > > Frequency drivers are fairly unusual so if you could add a listing =
of
> > > > the attributes in sysfs that would be great (it's nice practice
> anyway
> > but
> > > > I don't insist on it!)
> > > >
> > > > Various fairly minor comments inline.
> > > >
> > > > Thanks,
> > > >
> > > > Jonathan
> > > >
> > > >
> > > > > ---
> > > > >  changes in v4:
> > > > >   - change license to: GPL-2.0-only
> > > > >  drivers/iio/frequency/Kconfig    |  13 +
> > > > >  drivers/iio/frequency/Makefile   |   1 +
> > > > >  drivers/iio/frequency/adrf6780.c | 498
> > > > +++++++++++++++++++++++++++++++
> > > > >  3 files changed, 512 insertions(+)
> > > > >  create mode 100644 drivers/iio/frequency/adrf6780.c
> > > > >
> > > > > diff --git a/drivers/iio/frequency/Kconfig
> > > > b/drivers/iio/frequency/Kconfig
> > > > > index 240b81502512..fc9751c48f59 100644
> > > > > --- a/drivers/iio/frequency/Kconfig
> > > > > +++ b/drivers/iio/frequency/Kconfig
> > > > > @@ -49,5 +49,18 @@ config ADF4371
> > > > >
> > > > >  	  To compile this driver as a module, choose M here:
> the
> > > > >  	  module will be called adf4371.
> > > > > +
> > > > > +config ADRF6780
> > > > > +        tristate "Analog Devices ADRF6780 Microwave
> Upconverter"
> > > > > +        depends on SPI
> > > > > +        depends on COMMON_CLK
> > > > > +        depends on OF
> > > >
> > > > Why?  Pretty much everything seems to have defaults if not
> > provided
> > > > via OF.
> > > > I've asked for the generic firmware functions anyway, so you can
> > drop
> > > > this
> > > > for that reason if nothing else!
> > > >
> > > > > +        help
> > > > > +          Say yes here to build support for Analog Devices
> ADRF6780
> > > > > +          5.9 GHz to 23.6 GHz, Wideband, Microwave Upconverter.
> > > > > +
> > > > > +          To compile this driver as a module, choose M here: the
> > > > > +          module will be called adrf6780.
> > > > > +
> > > > >  endmenu
> > > > >  endmenu
> > > > > diff --git a/drivers/iio/frequency/Makefile
> > > > b/drivers/iio/frequency/Makefile
> > > > > index 518b1e50caef..ae3136c79202 100644
> > > > > --- a/drivers/iio/frequency/Makefile
> > > > > +++ b/drivers/iio/frequency/Makefile
> > > > > @@ -7,3 +7,4 @@
> > > > >  obj-$(CONFIG_AD9523) +=3D ad9523.o
> > > > >  obj-$(CONFIG_ADF4350) +=3D adf4350.o
> > > > >  obj-$(CONFIG_ADF4371) +=3D adf4371.o
> > > > > +obj-$(CONFIG_ADRF6780) +=3D adrf6780.o
> > > > > diff --git a/drivers/iio/frequency/adrf6780.c
> > > > b/drivers/iio/frequency/adrf6780.c
> > > > > new file mode 100644
> > > > > index 000000000000..472a66f90c7f
> > > > > --- /dev/null
> > > > > +++ b/drivers/iio/frequency/adrf6780.c
> > > > > @@ -0,0 +1,498 @@
> > > > > +// SPDX-License-Identifier: GPL-2.0-only
> > > > > +/*
> > > > > + * ADRF6780 driver
> > > > > + *
> > > > > + * Copyright 2021 Analog Devices Inc.
> > > > > + */
> > > > > +
> > > > > +#include <linux/bitfield.h>
> > > > > +#include <linux/bits.h>
> > > > > +#include <linux/clk.h>
> > > > > +#include <linux/clkdev.h>
> > > > > +#include <linux/clk-provider.h>
> > > > > +#include <linux/delay.h>
> > > > > +#include <linux/device.h>
> > > > > +#include <linux/iio/iio.h>
> > > > > +#include <linux/module.h>
> > > >
> > > > #include <linux/mod_devicetable.h>
> > > >
> > > > > +#include <linux/spi/spi.h>
> > > > > +
> > > > > +/* ADRF6780 Register Map */
> > > > > +#define ADRF6780_REG_CONTROL			0x00
> > > > > +#define ADRF6780_REG_ALARM_READBACK		0x01
> > > > > +#define ADRF6780_REG_ALARM_MASKS		0x02
> > > > > +#define ADRF6780_REG_ENABLE			0x03
> > > > > +#define ADRF6780_REG_LINEARIZE			0x04
> > > > > +#define ADRF6780_REG_LO_PATH			0x05
> > > > > +#define ADRF6780_REG_ADC_CONTROL		0x06
> > > > > +#define ADRF6780_REG_ADC_OUTPUT
> 	0x0C
> > > > > +
> > > > > +/* ADRF6780_REG_CONTROL Map */
> > > > > +#define ADRF6780_PARITY_EN_MSK			BIT(15)
> > > > > +#define ADRF6780_PARITY_EN(x)
> > > > 	FIELD_PREP(ADRF6780_PARITY_EN_MSK, x)
> > > > > +#define ADRF6780_SOFT_RESET_MSK
> 	BIT(14)
> > > > > +#define ADRF6780_SOFT_RESET(x)
> > > > 	FIELD_PREP(ADRF6780_SOFT_RESET_MSK, x)
> > > > > +#define ADRF6780_CHIP_ID_MSK
> > 	GENMASK(11, 4)
> > > > > +#define ADRF6780_CHIP_ID			0xA
> > > > > +#define ADRF6780_CHIP_REVISION_MSK
> > 	GENMASK(3, 0)
> > > > > +#define ADRF6780_CHIP_REVISION(x)
> > > > 	FIELD_PREP(ADRF6780_CHIP_REVISION_MSK, x)
> > > > > +
> > > > > +/* ADRF6780_REG_ALARM_READBACK Map */
> > > > > +#define ADRF6780_PARITY_ERROR_MSK		BIT(15)
> > > > > +#define ADRF6780_PARITY_ERROR(x)
> > > > 	FIELD_PREP(ADRF6780_PARITY_ERROR_MSK, x)
> > > > > +#define ADRF6780_TOO_FEW_ERRORS_MSK		BIT(14)
> > > > > +#define ADRF6780_TOO_FEW_ERRORS(x)
> > > > 	FIELD_PREP(ADRF6780_TOO_FEW_ERRORS_MSK, x)
> > > > > +#define ADRF6780_TOO_MANY_ERRORS_MSK
> 	BIT(13)
> > > > > +#define ADRF6780_TOO_MANY_ERRORS(x)
> > > > 	FIELD_PREP(ADRF6780_TOO_MANY_ERRORS_MSK, x)
> > > > > +#define ADRF6780_ADDRESS_RANGE_ERROR_MSK	BIT(12)
> > > > > +#define ADRF6780_ADDRESS_RANGE_ERROR(x)
> > > > 	FIELD_PREP(ADRF6780_ADDRESS_RANGE_ERROR_MSK, x)
> > > > > +
> > > > > +/* ADRF6780_REG_ENABLE Map */
> > > > > +#define ADRF6780_VGA_BUFFER_EN_MSK		BIT(8)
> > > > > +#define ADRF6780_VGA_BUFFER_EN(x)
> > > > 	FIELD_PREP(ADRF6780_VGA_BUFFER_EN_MSK, x)
> > > > > +#define ADRF6780_DETECTOR_EN_MSK		BIT(7)
> > > > > +#define ADRF6780_DETECTOR_EN(x)
> > > > 	FIELD_PREP(ADRF6780_DETECTOR_EN_MSK, x)
> > > > > +#define ADRF6780_LO_BUFFER_EN_MSK		BIT(6)
> > > > > +#define ADRF6780_LO_BUFFER_EN(x)
> > > > 	FIELD_PREP(ADRF6780_LO_BUFFER_EN_MSK, x)
> > > > > +#define ADRF6780_IF_MODE_EN_MSK
> 	BIT(5)
> > > > > +#define ADRF6780_IF_MODE_EN(x)
> > > > 	FIELD_PREP(ADRF6780_IF_MODE_EN_MSK, x)
> > > > > +#define ADRF6780_IQ_MODE_EN_MSK
> > 	BIT(4)
> > > > > +#define ADRF6780_IQ_MODE_EN(x)
> > > > 	FIELD_PREP(ADRF6780_IQ_MODE_EN_MSK, x)
> > > > > +#define ADRF6780_LO_X2_EN_MSK			BIT(3)
> > > > > +#define ADRF6780_LO_X2_EN(x)
> > > > 	FIELD_PREP(ADRF6780_LO_X2_EN_MSK, x)
> > > > > +#define ADRF6780_LO_PPF_EN_MSK			BIT(2)
> > > > > +#define ADRF6780_LO_PPF_EN(x)
> > > > 	FIELD_PREP(ADRF6780_LO_PPF_EN_MSK, x)
> > > > > +#define ADRF6780_LO_EN_MSK			BIT(1)
> > > > > +#define ADRF6780_LO_EN(x)
> > > > 	FIELD_PREP(ADRF6780_LO_EN_MSK, x)
> > > > > +#define ADRF6780_UC_BIAS_EN_MSK
> 	BIT(0)
> > > > > +#define ADRF6780_UC_BIAS_EN(x)
> > > > 	FIELD_PREP(ADRF6780_UC_BIAS_EN_MSK, x)
> > > > > +
> > > > > +/* ADRF6780_REG_LINEARIZE Map */
> > > > > +#define ADRF6780_RDAC_LINEARIZE_MSK
> > 	GENMASK(7, 0)
> > > > > +#define ADRF6780_RDAC_LINEARIZE(x)
> > > > 	FIELD_PREP(ADRF6780_RDAC_LINEARIZE_MSK, x)
> > > > > +
> > > > > +/* ADRF6780_REG_LO_PATH Map */
> > > > > +#define ADRF6780_LO_SIDEBAND_MSK		BIT(10)
> > > > > +#define ADRF6780_LO_SIDEBAND(x)
> > > > 	FIELD_PREP(ADRF6780_LO_SIDEBAND_MSK, x)
> > > > > +#define ADRF6780_Q_PATH_PHASE_ACCURACY_MSK
> > > > 	GENMASK(7, 4)
> > > > > +#define ADRF6780_Q_PATH_PHASE_ACCURACY(x)
> > > > 	FIELD_PREP(ADRF6780_Q_PATH_PHASE_ACCURACY_MSK, x)
> > > > > +#define ADRF6780_I_PATH_PHASE_ACCURACY_MSK
> > > > 	GENMASK(3, 0)
> > > > > +#define ADRF6780_I_PATH_PHASE_ACCURACY(x)
> > > > 	FIELD_PREP(ADRF6780_I_PATH_PHASE_ACCURACY_MSK, x)
> > > > > +
> > > > > +/* ADRF6780_REG_ADC_CONTROL Map */
> > > > > +#define ADRF6780_VDET_OUTPUT_SELECT_MSK
> > 	BIT(3)
> > > > > +#define ADRF6780_VDET_OUTPUT_SELECT(x)
> > > > 	FIELD_PREP(ADRF6780_VDET_OUTPUT_SELECT_MSK, x)
> > > > > +#define ADRF6780_ADC_START_MSK			BIT(2)
> > > > > +#define ADRF6780_ADC_START(x)
> > > > 	FIELD_PREP(ADRF6780_ADC_START_MSK, x)
> > > > > +#define ADRF6780_ADC_EN_MSK			BIT(1)
> > > > > +#define ADRF6780_ADC_EN(x)
> > > > 	FIELD_PREP(ADRF6780_ADC_EN_MSK, x)
> > > > > +#define ADRF6780_ADC_CLOCK_EN_MSK		BIT(0)
> > > > > +#define ADRF6780_ADC_CLOCK_EN(x)
> > > > 	FIELD_PREP(ADRF6780_ADC_CLOCK_EN_MSK, x)
> > > > > +
> > > > > +/* ADRF6780_REG_ADC_OUTPUT Map */
> > > > > +#define ADRF6780_ADC_STATUS_MSK
> 	BIT(8)
> > > > > +#define ADRF6780_ADC_STATUS(x)
> > > > 	FIELD_PREP(ADRF6780_ADC_STATUS_MSK, x)
> > > > > +#define ADRF6780_ADC_VALUE_MSK
> > > > 	GENMASK(7, 0)
> > > > > +#define ADRF6780_ADC_VALUE(x)
> > > > 	FIELD_PREP(ADRF6780_ADC_VALUE_MSK, x)
> > > >
> > > > Not used.  In general, just use FIELD_PREP / FIELD_GET inline
> > rather
> > > > than having extra
> > > > macros like these. That approach is simpler for reviewers to
> follow.
> > > >
> > > > > +
> > > > > +struct adrf6780_dev {
> > > > > +	struct spi_device	*spi;
> > > > > +	struct clk		*clkin;
> > > > > +	/* Protect against concurrent accesses to the device */
> > > > > +	struct mutex		lock;
> > > > > +	bool			vga_buff_en;
> > > > > +	bool			lo_buff_en;
> > > > > +	bool			if_mode_en;
> > > > > +	bool			iq_mode_en;
> > > > > +	bool			lo_x2_en;
> > > > > +	bool			lo_ppf_en;
> > > > > +	bool			lo_en;
> > > > > +	bool			uc_bias_en;
> > > > > +	bool			lo_sideband;
> > > > > +	bool			vdet_out_en;
> > > > > +};
> > > > > +
> > > > > +static int adrf6780_spi_read(struct adrf6780_dev *dev,
> > unsigned int
> > > > reg,
> > > > > +			      unsigned int *val)
> > > > > +{
> > > > > +	int ret;
> > > > > +	unsigned int temp;
> > > > > +	struct spi_transfer t =3D {0};
> > > > > +	u8 data[3];
> > > > > +
> > > > > +	data[0] =3D 0x80 | (reg << 1);
> > > > > +	data[1] =3D 0x0;
> > > > > +	data[2] =3D 0x0;
> > > > > +
> > > > > +	t.rx_buf =3D &data[0];
> > > > > +	t.tx_buf =3D &data[0];
> > > > > +	t.len =3D 3;
> > > > > +
> > > > > +	ret =3D spi_sync_transfer(dev->spi, &t, 1);
> > > >
> > > > data needs to be dma safe.
> > > >
> > > > > +	if (ret < 0)
> > > > > +		return ret;
> > > > > +
> > > > > +	temp =3D ((data[0] | 0x80 | (reg << 1)) << 16) |
> > > > > +		(data[1] << 8) | data[2];
> > > >
> > > > Ouch. That's a bit nasty, but why are you writing the reg into
> > > > it?  Looks like a get_unaligned_be24() >> 1 and a 16bit mask.
> > > > (use GENMASK(15, 0) for that to make it apparent what is
> > happening.
> > > >
> > > > > +
> > > > > +	*val =3D (temp >> 1) & 0xFFFF;
> > > > > +
> > > > > +	return ret;
> > > > > +}
> > > > > +
> > > > > +static int adrf6780_spi_write(struct adrf6780_dev *dev,
> > > > > +				      unsigned int reg,
> > > > > +				      unsigned int val)
> > > > > +{
> > > > > +	u8 data[3];
> > > > > +
> > > > > +	val =3D (val << 1);
> > > > > +
> > > > > +	data[0] =3D (reg << 1) | (val >> 16);
> > > > > +	data[1] =3D val >> 8;
> > > > > +	data[2] =3D val;
> > > >
> > > > An opportunity for
> > > > put_unaligned_be24() with a value of (I think)
> > > >
> > > > (val << 1) | (reg << 17)
> > > >
> > > >
> > > > > +
> > > > > +	return spi_write(dev->spi, &data[0], 3);
> > > >
> > > > Needs a dma safe buffer, which basically means it can't be on the
> > > > stack.
> > > > Lots of ways of handling that, but look for __cacheline_aligned in
> > IIO
> > > > drivers
> > > > to see the one we probably use mostly commonly in IIO drivers.
> > >
> > > Hi Jonathan,
> > >
> > > This is something I wanted to ask for some time so I will take the
> > opportunity here :).
> > > Is this something you prefer just not to risk at all and make it an
> hard
> > requirement
> > > (which is fair)? ...
> >
> > Yes, I think we need to keep this as a hard requirement.
> > There are drivers out there which we missed this on in the past, and
> > I'm not necessarily
> > going to take the time to go through them all as this can be hard to
> > spot, but lets not
> > introduce any more potential problems.
> >
>=20
> I see. That makes sense and it's fair :). The only annoying (but not too
> annoying :)) is that
> making the data/buffer global forces you to use a lock in cases you
> potentially would
> not have too (just using local buffers). But that's life, better play saf=
e :)
>=20
> > >
> > > I'm asking this because, tbh, I would be very surprised if any spi/i2=
c
> > controller out there
> > > is using dma for a 3byte transfer. I guess the overhead of setting it
> up
> > is probably not
> > > worth it...
> >
> > There are (I believe) a few i2c and spi controllers out there that don'=
t
> > do anything other
> > than DMA.  Wolfram mentioned one of those in his talk on adding
> > DMA support to i2c.
>=20
> Hmm, I see...
>=20
> > Also, the reference in the file below to the wonderful case of USB to
> > i2c bridges that always
> > require DMA safe buffers.
>=20
> Indeed it does.
>=20

Hi Jonathan,

Just for closure, I also realized that the pattern in IIO looks to be to us=
e
DMA safe buffers only on the tx side. For instance in the IMU lib [1],
only the tx buffer is safe (well, I think there's problem with this as
I believe all spi transfers buffers should be properly aligned which won't
be the case in the IMU lib). Is there any reason for this? AFAICT, we shoul=
d
also take care with rx buffers or am I missing something?

[1]: https://elixir.bootlin.com/linux/latest/source/include/linux/iio/imu/a=
dis.h#L129

- Nuno S=E1