RE: [PATCH v2 1/3] clk: axi-clkgen: remove ARCH dependency in Kconfig
> -Original Message- > From: Moritz Fischer > Sent: Wednesday, January 27, 2021 4:39 AM > To: Ardelean, Alexandru > Cc: linux-...@vger.kernel.org; devicet...@vger.kernel.org; linux- > ker...@vger.kernel.org; mturque...@baylibre.com; sb...@kernel.org; > robh...@kernel.org; l...@metafoo.de; linux-f...@vger.kernel.org; > m...@kernel.org; Bogdan, Dragos > Subject: Re: [PATCH v2 1/3] clk: axi-clkgen: remove ARCH dependency in Kconfig > > Alexandru, > > On Tue, Jan 26, 2021 at 01:08:24PM +0200, Alexandru Ardelean wrote: > > The intent is to be able to run this driver to access the IP core in > > setups where FPGA board is also connected via a PCIe bus. In such > > cases the number of combinations explodes, where the host system can > > be an x86 with Xilinx Zynq/ZynqMP/Microblaze board connected via PCIe. > > Or even a ZynqMP board with a ZynqMP/Zynq/Microblaze connected via PCIe. > > > > To accommodate for these cases, this change removes the limitation for > > this driver to be compilable only on Zynq/Microblaze architectures. > > > > Signed-off-by: Dragos Bogdan > > Signed-off-by: Alexandru Ardelean > > --- > > drivers/clk/Kconfig | 1 - > > 1 file changed, 1 deletion(-) > > > > diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig index > > 85856cff506c..d8c2d4593926 100644 > > --- a/drivers/clk/Kconfig > > +++ b/drivers/clk/Kconfig > > @@ -247,7 +247,6 @@ config CLK_TWL6040 > > > > config COMMON_CLK_AXI_CLKGEN > > tristate "AXI clkgen driver" > > - depends on ARCH_ZYNQ || MICROBLAZE || COMPILE_TEST > Umhhh ... no dependencies? How are you accessing your registers? You seem to > be using device tree, probably: > > depends on HAS_IOMEM || COMPILE_TEST > depends on OF > > at least? Please double check your dependencies. Agreed. Will re-spin. This is a n00b mistake on my part Thanks > > help > > Support for the Analog Devices axi-clkgen pcore clock generator for > Xilinx > > FPGAs. It is commonly used in Analog Devices' reference designs. > > -- > > 2.17.1 > > > > - Moritz
RE: [PATCH 1/2] clk: axi-clkgen: add support for ZynqMP (UltraScale)
> -Original Message-
> From: Tom Rix
> Sent: Thursday, December 24, 2020 4:03 PM
> To: Ardelean, Alexandru ; linux-
> c...@vger.kernel.org; devicet...@vger.kernel.org; linux-kernel@vger.kernel.org
> Cc: mturque...@baylibre.com; sb...@kernel.org; robh...@kernel.org;
> l...@metafoo.de; linux-f...@vger.kernel.org; m...@kernel.org; Bogdan,
> Dragos ; Mathias Tausen
>
> Subject: Re: [PATCH 1/2] clk: axi-clkgen: add support for ZynqMP (UltraScale)
>
> [External]
>
>
> On 12/21/20 6:42 AM, Alexandru Ardelean wrote:
> > From: Dragos Bogdan
> >
> > This IP core also works and is supported on the Xilinx ZynqMP
> > (UltraScale) FPGA boards.
> > This patch enables the driver to be available on these platforms as well.
> >
> > Since axi-clkgen is now supported on ZYNQMP, we need to make sure the
> > max/min frequencies of the PFD and VCO are respected.
> >
> > This change adds two new compatible strings to select limits for Zynq
> > or ZynqMP from the device data (in the OF table). The old compatible
> > string (i.e. adi,axi-clkgen-2.00.a) is the same as
> > adi,zynq-axi-clkgen-2.00.a, since the original version of this driver
> > was designed on top of that platform.
> >
Apologies for the late reply on this, this looks like it went to some folder in
my inbox and I forgot about it.
And Happy New Year :)
> > Signed-off-by: Dragos Bogdan
> > Signed-off-by: Mathias Tausen
> > Signed-off-by: Alexandru Ardelean
> > ---
> >
> > This is a re-spin of an older series.
> > It needed to wait a txt -> yaml dt conversion:
> > https://urldefense.com/v3/__https://patchwork.kernel.org/project/linux
> > -clk/patch/20201013143421.84188-1-alexandru.ardel...@analog.com/__;!!A
> > 3Ni8CS0y2Y!sPnN7f9iWjhGkjI-Gu8RTo73gVDV6x0-5m42Pu2kZwvVbHN-
> pZzEaFqTrDY
> > iPPDLdVc-wg$
> >
> > It's 2 patches squashed into one:
> > https://urldefense.com/v3/__https://patchwork.kernel.org/project/linux
> > -clk/patch/20200929144417.89816-12-alexandru.ardel...@analog.com/__;!!
> > A3Ni8CS0y2Y!sPnN7f9iWjhGkjI-Gu8RTo73gVDV6x0-5m42Pu2kZwvVbHN-
> pZzEaFqTrD
> > YiPPAkwzbuMA$
> > https://urldefense.com/v3/__https://patchwork.kernel.org/project/linux
> > -clk/patch/20200929144417.89816-14-alexandru.ardel...@analog.com/__;!!
> > A3Ni8CS0y2Y!sPnN7f9iWjhGkjI-Gu8RTo73gVDV6x0-5m42Pu2kZwvVbHN-
> pZzEaFqTrD
> > YiPPCaD6QXfQ$
> >
> > The series from where all this started is:
> > https://urldefense.com/v3/__https://lore.kernel.org/linux-clk/20200929
> > 144417.89816-1-
> alexandru.ardel...@analog.com/__;!!A3Ni8CS0y2Y!sPnN7f9i
> > WjhGkjI-Gu8RTo73gVDV6x0-5m42Pu2kZwvVbHN-pZzEaFqTrDYiPPAjuz4oHg$
> >
> > Well, v4 was the point where I decided to split this into smaller
> > series, and also do the conversion of the binding to yaml.
> >
> > drivers/clk/Kconfig | 2 +-
> > drivers/clk/clk-axi-clkgen.c | 15 +++
> > 2 files changed, 16 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig index
> > 85856cff506c..252333e585e7 100644
> > --- a/drivers/clk/Kconfig
> > +++ b/drivers/clk/Kconfig
> > @@ -247,7 +247,7 @@ config CLK_TWL6040
> >
> > config COMMON_CLK_AXI_CLKGEN
> > tristate "AXI clkgen driver"
> > - depends on ARCH_ZYNQ || MICROBLAZE || COMPILE_TEST
> > + depends on ARCH_ZYNQ || ARCH_ZYNQMP || MICROBLAZE ||
> COMPILE_TEST
> > help
> > Support for the Analog Devices axi-clkgen pcore clock generator for
> Xilinx
> > FPGAs. It is commonly used in Analog Devices' reference designs.
> > diff --git a/drivers/clk/clk-axi-clkgen.c
> > b/drivers/clk/clk-axi-clkgen.c index ad86e031ba3e..a413c13334ff 100644
> > --- a/drivers/clk/clk-axi-clkgen.c
> > +++ b/drivers/clk/clk-axi-clkgen.c
> > @@ -108,6 +108,13 @@ static uint32_t axi_clkgen_lookup_lock(unsigned int
> m)
> > return 0x1f1f00fa;
> > }
> >
>
> Could something like
>
> #ifdef ARCH_ZYNQMP
So, we decided not to do this in an older discussion:
https://lore.kernel.org/linux-clk/20200929153040.GA114067@archbook/
https://lore.kernel.org/linux-clk/20200930171607.GA121420@archbook/
Because, these drivers should also be usable in cases where a ZynqMP or Zynq
device can be plugged in via PCIe on a host device.
Thinking about it now, I think I should remove the "depends on ARCH_ZYNQ ||
ARCH_ZYNQMP" limitation.
>
> > +static const struct axi_clkgen_limits axi_clkgen_zynqmp_default_limits = {
> > + .fpfd_min = 1,
> > + .fpfd_max = 45,
> > + .fv
RE: [PATCH] spi: stm32: update dev_dbg() print format for SPI params
> -Original Message-
> From: Andy Shevchenko
> Sent: Monday, January 4, 2021 3:51 PM
> To: Ardelean, Alexandru
> Cc: linux-spi ; Linux Kernel Mailing List ker...@vger.kernel.org>; Mark Brown ; Stephen Rothwell
>
> Subject: Re: [PATCH] spi: stm32: update dev_dbg() print format for SPI params
>
> [External]
>
> On Mon, Jan 4, 2021 at 10:55 AM Alexandru Ardelean
> wrote:
> >
> > With the introduction of the 'include/uapi/linux/spi/spi.h' header,
> > the type of the macros are enforced to 'unsigned long int' via the
> > _BITUL() macro.
> >
> > This causes some -Wformat warnings in the spi-stm32 driver.
> > This patch changes the printf() specifiers from '%d' to '%lu' to
> > accommodate for this change.
> >
> > Fixes: f7005142dace ("spi: uapi: unify SPI modes into a single spi.h
> > header")
> > Reported-by: Stephen Rothwell
>
> LKP also reported this before.
>
Ack;
Will add it
> ...
>
> > - dev_dbg(spi->dev, "cpol=%d cpha=%d lsb_first=%d cs_high=%d\n",
> > + dev_dbg(spi->dev, "cpol=%lu cpha=%lu lsb_first=%lu
> > + cs_high=%lu\n",
> > spi_dev->mode & SPI_CPOL,
> > spi_dev->mode & SPI_CPHA,
> > spi_dev->mode & SPI_LSB_FIRST,
>
> Wouldn't the output be a bit awful with all these?
>
> I think the proper fix is to add !! to each bit mask.
Fine by me
>
> --
> With Best Regards,
> Andy Shevchenko
RE: linux-next: build warning after merge of the spi tree
> -Original Message- > From: Stephen Rothwell > Sent: Monday, January 4, 2021 2:07 AM > To: Mark Brown > Cc: Ardelean, Alexandru ; Andy Shevchenko > ; Linux Kernel Mailing List ker...@vger.kernel.org>; Linux Next Mailing List > Subject: linux-next: build warning after merge of the spi tree > > [External] > > Hi all, > > After merging the spi tree, today's linux-next build (arm > multi_v7_defconfig) produced this warning: > Apologies for this. Will send a fix. > In file included from include/linux/device.h:15, > from include/linux/dmaengine.h:8, > from drivers/spi/spi-stm32.c:11: > drivers/spi/spi-stm32.c: In function 'stm32_spi_prepare_msg': > drivers/spi/spi-stm32.c:1030:20: warning: format '%d' expects argument of type > 'int', but argument 4 has type 'long unsigned int' [-Wformat=] > 1030 | dev_dbg(spi->dev, "cpol=%d cpha=%d lsb_first=%d cs_high=%d\n", > |^~~ > include/linux/dev_printk.h:19:22: note: in definition of macro 'dev_fmt' >19 | #define dev_fmt(fmt) fmt > | ^~~ > drivers/spi/spi-stm32.c:1030:2: note: in expansion of macro 'dev_dbg' > 1030 | dev_dbg(spi->dev, "cpol=%d cpha=%d lsb_first=%d cs_high=%d\n", > | ^~~ > drivers/spi/spi-stm32.c:1030:27: note: format string is defined here > 1030 | dev_dbg(spi->dev, "cpol=%d cpha=%d lsb_first=%d cs_high=%d\n", > | ~^ > | | > | int > | %ld > In file included from include/linux/device.h:15, > from include/linux/dmaengine.h:8, > from drivers/spi/spi-stm32.c:11: > drivers/spi/spi-stm32.c:1030:20: warning: format '%d' expects argument of type > 'int', but argument 5 has type 'long unsigned int' [-Wformat=] > 1030 | dev_dbg(spi->dev, "cpol=%d cpha=%d lsb_first=%d cs_high=%d\n", > |^~~ > include/linux/dev_printk.h:19:22: note: in definition of macro 'dev_fmt' >19 | #define dev_fmt(fmt) fmt > | ^~~ > drivers/spi/spi-stm32.c:1030:2: note: in expansion of macro 'dev_dbg' > 1030 | dev_dbg(spi->dev, "cpol=%d cpha=%d lsb_first=%d cs_high=%d\n", > | ^~~ > drivers/spi/spi-stm32.c:1030:35: note: format string is defined here > 1030 | dev_dbg(spi->dev, "cpol=%d cpha=%d lsb_first=%d cs_high=%d\n", > | ~^ > | | > | int > | %ld > In file included from include/linux/device.h:15, > from include/linux/dmaengine.h:8, > from drivers/spi/spi-stm32.c:11: > drivers/spi/spi-stm32.c:1030:20: warning: format '%d' expects argument of type > 'int', but argument 6 has type 'long unsigned int' [-Wformat=] > 1030 | dev_dbg(spi->dev, "cpol=%d cpha=%d lsb_first=%d cs_high=%d\n", > |^~~ > include/linux/dev_printk.h:19:22: note: in definition of macro 'dev_fmt' >19 | #define dev_fmt(fmt) fmt > | ^~~ > drivers/spi/spi-stm32.c:1030:2: note: in expansion of macro 'dev_dbg' > 1030 | dev_dbg(spi->dev, "cpol=%d cpha=%d lsb_first=%d cs_high=%d\n", > | ^~~ > drivers/spi/spi-stm32.c:1030:48: note: format string is defined here > 1030 | dev_dbg(spi->dev, "cpol=%d cpha=%d lsb_first=%d cs_high=%d\n", > | ~^ > || > |int > | %ld > In file included from include/linux/device.h:15, > from include/linux/dmaengine.h:8, > from drivers/spi/spi-stm32.c:11: > drivers/spi/spi-stm32.c:1030:20: warning: format '%d' expects argument of type > 'int', but argument 7 has type 'long unsigned int' [-Wformat=] > 1030 | dev_dbg(spi->dev, "cpol=%d cpha=%d lsb_first=%d cs_high=%d\n", > |^~~ > include/linux/dev_printk.h:19:22: note: in definition of macro 'dev_fmt' >19 | #define dev_fmt(fmt) fmt > | ^~~ > drivers/spi/spi-stm32.c:1030:2: note: in expansion of macro 'dev_dbg' > 1030 | dev_dbg(spi->dev, "cpol=%d cpha=%d lsb_fir
RE: [PATCH v5 2/3] spi: Add SPI_NO_TX/RX support
> -Original Message- > From: Andy Shevchenko > Sent: Monday, December 21, 2020 4:37 PM > To: Ardelean, Alexandru > Cc: linux-spi ; devicetree > ; Linux Kernel Mailing List ker...@vger.kernel.org>; Bogdan, Dragos ; > Mark Brown ; Rob Herring > Subject: Re: [PATCH v5 2/3] spi: Add SPI_NO_TX/RX support > > On Mon, Dec 21, 2020 at 4:34 PM Andy Shevchenko > wrote: > > On Mon, Dec 21, 2020 at 4:15 PM Alexandru Ardelean > > wrote: > > > > > > From: Dragos Bogdan > > > > > > Transmit/receive only is a valid SPI mode. For example, the MOSI/TX > > > line might be missing from an ADC while for a DAC the MISO/RX line > > > may be optional. This patch adds these two new modes: SPI_NO_TX and > > > SPI_NO_RX. This way, the drivers will be able to identify if any of > > > these two lines is missing and to adjust the transfers accordingly. > > > > > > Signed-off-by: Dragos Bogdan > > > > Missed Co-developed-by: Alexandru ... ? Nah, that's fine from my side without that tag. > > > > Anyway, looks good to me, > > Reviewed-by: Andy Shevchenko > > One nit, though... > > > > - "setup: can not select dual and quad at the same time\n"); > > > + "setup: can not select any two of dual, quad and no-rx/tx > > > " > > > + "at the same time\n"); > > Can we avoid splitting string literals which are assumed to be on one line > when > printed? It ends up at about 96 cols, but it's within limits. The patch may have been written before the new 100 col-width limit. > > -- > With Best Regards, > Andy Shevchenko
RE: [PATCH v3 1/4] Input: adp5589-keys - add default platform data
> -Original Message-
> From: Alexandru Ardelean
> Sent: Friday, November 27, 2020 1:14 PM
> To: linux-in...@vger.kernel.org; linux-kernel@vger.kernel.org;
> devicet...@vger.kernel.org
> Cc: l...@metafoo.de; dmitry.torok...@gmail.com; robh...@kernel.org;
> Ardelean, Alexandru
> Subject: [PATCH v3 1/4] Input: adp5589-keys - add default platform data
>
> From: Lars-Peter Clausen
>
> If no platform data is supplied use a dummy platform data that configures the
> device in GPIO only mode. This change adds a adp5589_kpad_pdata_get() helper
> that returns the default platform-data. This can be later extended to load
> configuration from device-trees or ACPI.
>
Ping on this for the input subsystem.
Since patch 4 was applied by Rob, maybe for input, only the first 3 should be
applied.
Or, should I re-send just the first 3?
Thanks
Alex
> Signed-off-by: Lars-Peter Clausen
> Signed-off-by: Alexandru Ardelean
> ---
>
> Changelog v2 - v3:
> * https://lore.kernel.org/linux-input/20201124082255.13427-1-
> alexandru.ardel...@analog.com/
> * added patch 'dt-bindings: add ADP5585/ADP5589 entries to trivial-devices'
>
> drivers/input/keyboard/adp5589-keys.c | 33 +++
> 1 file changed, 24 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/input/keyboard/adp5589-keys.c
> b/drivers/input/keyboard/adp5589-keys.c
> index e2cdf14d90cd..742bf4b97dbb 100644
> --- a/drivers/input/keyboard/adp5589-keys.c
> +++ b/drivers/input/keyboard/adp5589-keys.c
> @@ -369,6 +369,25 @@ static const struct adp_constants const_adp5585 = {
> .reg= adp5585_reg,
> };
>
> +static const struct adp5589_gpio_platform_data adp5589_default_gpio_pdata
> = {
> + .gpio_start = -1,
> +};
> +
> +static const struct adp5589_kpad_platform_data adp5589_default_pdata = {
> + .gpio_data = _default_gpio_pdata, };
> +
> +static const struct adp5589_kpad_platform_data *adp5589_kpad_pdata_get(
> + struct device *dev)
> +{
> + const struct adp5589_kpad_platform_data *pdata =
> +dev_get_platdata(dev);
> +
> + if (!pdata)
> + pdata = _default_pdata;
> +
> + return pdata;
> +}
> +
> static int adp5589_read(struct i2c_client *client, u8 reg) {
> int ret = i2c_smbus_read_byte_data(client, reg); @@ -498,7 +517,8 @@
> static int adp5589_build_gpiomap(struct adp5589_kpad *kpad, static int
> adp5589_gpio_add(struct adp5589_kpad *kpad) {
> struct device *dev = >client->dev;
> - const struct adp5589_kpad_platform_data *pdata =
> dev_get_platdata(dev);
> + const struct adp5589_kpad_platform_data *pdata =
> + adp5589_kpad_pdata_get(dev);
> const struct adp5589_gpio_platform_data *gpio_data = pdata-
> >gpio_data;
> int i, error;
>
> @@ -619,7 +639,7 @@ static int adp5589_setup(struct adp5589_kpad *kpad) {
> struct i2c_client *client = kpad->client;
> const struct adp5589_kpad_platform_data *pdata =
> - dev_get_platdata(>dev);
> + adp5589_kpad_pdata_get(>dev);
> u8 (*reg) (u8) = kpad->var->reg;
> unsigned char evt_mode1 = 0, evt_mode2 = 0, evt_mode3 = 0;
> unsigned char pull_mask = 0;
> @@ -824,7 +844,7 @@ static int adp5589_keypad_add(struct adp5589_kpad
> *kpad, unsigned int revid) {
> struct i2c_client *client = kpad->client;
> const struct adp5589_kpad_platform_data *pdata =
> - dev_get_platdata(>dev);
> + adp5589_kpad_pdata_get(>dev);
> struct input_dev *input;
> unsigned int i;
> int error;
> @@ -948,7 +968,7 @@ static int adp5589_probe(struct i2c_client *client, {
> struct adp5589_kpad *kpad;
> const struct adp5589_kpad_platform_data *pdata =
> - dev_get_platdata(>dev);
> + adp5589_kpad_pdata_get(>dev);
> unsigned int revid;
> int error, ret;
>
> @@ -958,11 +978,6 @@ static int adp5589_probe(struct i2c_client *client,
> return -EIO;
> }
>
> - if (!pdata) {
> - dev_err(>dev, "no platform data?\n");
> - return -EINVAL;
> - }
> -
> kpad = devm_kzalloc(>dev, sizeof(*kpad), GFP_KERNEL);
> if (!kpad)
> return -ENOMEM;
> --
> 2.27.0
RE: [PATCH] net: phy: adin: add signal mean square error registers to phy-stats
> -Original Message- > From: Andrew Lunn > Sent: Thursday, December 3, 2020 4:16 PM > To: Ardelean, Alexandru > Cc: net...@vger.kernel.org; linux-kernel@vger.kernel.org; > hkallwe...@gmail.com; li...@armlinux.org.uk; da...@davemloft.net; > k...@kernel.org; Redmond, Catherine ; > Murray, Brian ; Baylov, Danail > ; OBrien, Maurice > > Subject: Re: [PATCH] net: phy: adin: add signal mean square error registers to > phy-stats > > On Thu, Dec 03, 2020 at 10:07:19AM +0200, Alexandru Ardelean wrote: > > When the link is up on the ADIN1300/ADIN1200, the signal quality on > > each pair is indicated in the mean square error register for each pair > > (MSE_A, MSE_B, MSE_C, and MSE_D registers, Address 0x8402 to Address > > 0x8405, Bits[7:0]). > > > > These values can be useful for some industrial applications. > > > > This change implements support for these registers using the PHY > > statistics mechanism. > > There was a discussion about values like these before. If i remember > correctly, it > was for a BroadReach PHY. I thought we decided to add them to the link state > information? > Oh, this is new. I've had this MSE patch lying around in a branch since last year sometime. Wasn't sure whether to put it in the phy-stats. > Ah, found it. > > commit 68ff5e14759e7ac1aac7bc75ac5b935e390fa2b3 > Author: Oleksij Rempel > Date: Wed May 20 08:29:15 2020 +0200 > > net: phy: tja11xx: add SQI support > > and > > ommit 8066021915924f58ed338bf38208215f5a7355f6 > Author: Oleksij Rempel > Date: Wed May 20 08:29:14 2020 +0200 > > ethtool: provide UAPI for PHY Signal Quality Index (SQI) > > Can you convert your MSE into SQI? I'll take a look and try to understand the SQI spec. It's neat that there's a common place where to put this. Thanks Alex > > Andrew
RE: [PATCH v3 3/3] spi: dt-bindings: document zero value for spi-{rx,tx}-bus-width properties
> -Original Message-
> From: Andy Shevchenko
> Sent: Friday, November 27, 2020 4:26 PM
> To: Ardelean, Alexandru
> Cc: linux-spi ; devicetree
> ; Linux Kernel Mailing List ker...@vger.kernel.org>; Rob Herring ; Mark Brown
> ; Bogdan, Dragos
> Subject: Re: [PATCH v3 3/3] spi: dt-bindings: document zero value for
> spi-{rx,tx}-
> bus-width properties
>
> On Fri, Nov 27, 2020 at 3:08 PM Alexandru Ardelean
> wrote:
> >
> > Following a change to the SPI framework, providing a value of zero for
> > 'spi-rx-bus-width' and 'spi-tx-bus-width' is now possible and will
> > essentially mean than no RX or TX is allowed.
>
> than -> that
>
> I'm wondering if we have a possibility to strict this for controllers that
> always
> duplex (I assume that schema works in a way that the generic bindings is most
> relaxed in comparison to the device specific ones in case of the same binding
> in
> question).
No idea here.
>
> --
> With Best Regards,
> Andy Shevchenko
RE: [PATCH v3 2/3] spi: Add SPI_NO_TX/RX support
> -Original Message- > From: Andy Shevchenko > Sent: Friday, November 27, 2020 4:24 PM > To: Ardelean, Alexandru > Cc: linux-spi ; devicetree > ; Linux Kernel Mailing List ker...@vger.kernel.org>; Rob Herring ; Mark Brown > ; Bogdan, Dragos > Subject: Re: [PATCH v3 2/3] spi: Add SPI_NO_TX/RX support > > On Fri, Nov 27, 2020 at 4:22 PM Andy Shevchenko > wrote: > > On Fri, Nov 27, 2020 at 3:08 PM Alexandru Ardelean > > wrote: > > ... > > > > --- a/include/uapi/linux/spi/spi.h > > > +++ b/include/uapi/linux/spi/spi.h > > > @@ -43,5 +43,7 @@ > > > #defineSPI_TX_OCTAL0x2000 /* transmit with > > > 8 wires */ > > > #defineSPI_RX_OCTAL0x4000 /* receive with 8 > > > wires */ > > > #defineSPI_3WIRE_HIZ 0x8000 /* high impedance > > > turnaround > */ > > > +#defineSPI_NO_TX 0x1 /* no transmit > > > wire */ > > > +#defineSPI_NO_RX 0x2 /* no receive > > > wire */ > > > > Is it really material for uAPI? > > Perhaps we may have something like > > SPI_MODE_USER_MASK in uAPI and > > in internal headers Hmm, in a way this could make sense for some SPIDEVs as well, to set these flags and get an error if they try to TX with the NO_TX flag set. Not really sure about this. Initially I mechanically added these here as an inertia to the previous patch which is just unifying the headers. Any other opinions? Thoughts? Mark? > > > > SPI_MODE_KERNEL_MASK with > > static_assert(_USER_MASK & _KERNEL_MASK); // check conditional > > > > ? > > And logically start bits for the kernel from the end (31, 30, ...). > > -- > With Best Regards, > Andy Shevchenko
RE: [PATCH v3 1/3] spi: uapi: unify SPI modes into a single spi.h header
> -Original Message-
> From: Andy Shevchenko
> Sent: Friday, November 27, 2020 4:13 PM
> To: Ardelean, Alexandru
> Cc: linux-spi ; devicetree
> ; Linux Kernel Mailing List ker...@vger.kernel.org>; Rob Herring ; Mark Brown
> ; Bogdan, Dragos
> Subject: Re: [PATCH v3 1/3] spi: uapi: unify SPI modes into a single spi.h
> header
>
> On Fri, Nov 27, 2020 at 3:08 PM Alexandru Ardelean
> wrote:
> >
> > This change moves all the SPI mode bits into a separate 'spi.h' header
> > in uapi. This is meant to re-use these definitions inside the kernel
> > as well as export them to userspace (via uapi).
>
> uapi -> UAPI (or uAPI) here and everywhere else where it makes sense.
>
> > The SPI mode definitions have usually been duplicated between between
> > 'include/linux/spi/spi.h' and 'include/uapi/linux/spi/spidev.h', so
> > whenever adding a new entry, this would need to be put in both headers.
> >
> > They've been moved from 'include/linux/spi/spi.h', since that seems a
> > bit more complete; the bits have descriptions and there is the
> SPI_MODE_X_MASK.
> >
> > For now, this change does a simple move; no conversions to BIT()
> > macros are being done at this point. This can be done later, as that
> > requires also another header inclusion (the 'const.h' header).
> > The change as-is makes this 'spi.h' header more standalone.
> >
> > Signed-off-by: Alexandru Ardelean
> > ---
> >
> > Personally, I am not sure whether to convert the bitfield tos _BITUL()
> > macros or not. I feel that not-having these macros makes this uapi
> > spi.h header more standalone.
> > If there's a strong insistence to use those _BITUL() macros, I'll do it.
> > I'm hesitant now, because it requires that this spi.h includes the
> > 'const.h' header.
>
> _BITUL is a part of uAPI, why not to use it?
> In general BIT() type of macros makes values easier to read and less error
> prone
> (in big numbers it's easy to miss 0).
> It's not a strong opinion, it's just the rationale behind how I see it.
Yeah I understand.
I guess since this is a new header in UAPI, I can use the _BITUL macro.
Sometimes I look at some code and remember how some people tend to use some
things.
Like, I would expect some people to maybe just copy this header as-is in some
"libspi".
So, then: do we make it easier for those people or not?
But again, since this is a new header, the concern may be reduced by just using
_BITUL() from the start.
I sometimes have these arguments with myself whenever going into API code.
Kernel code is easy: all the users of that code in the kernel, and we try not
to bother too much with out-of-tree drivers. Those get impossible to care about.
>
> > Changelog v2 -> v3:
> > *
> > https://urldefense.com/v3/__https://lore.kernel.org/linux-spi/20201124
> > 102152.16548-1-
> alexandru.ardel...@analog.com/__;!!A3Ni8CS0y2Y!oNpULNID
> > JsvU1BX8CZgZYoS90mW3rZ2dHrZOwTRS4ndZ-_rLq3eJt22Rj1RQafWyw1-3YA$
> > * dropped 'spi: convert to BIT() all spi_device flags '
> > added 'spi: uapi: unify SPI modes into a single spi.h header'
> >
> > include/linux/spi/spi.h | 22 +--
> > include/uapi/linux/spi/spi.h| 47 +
> > include/uapi/linux/spi/spidev.h | 30 +
> > 3 files changed, 49 insertions(+), 50 deletions(-) create mode
> > 100644 include/uapi/linux/spi/spi.h
> >
> > diff --git a/include/linux/spi/spi.h b/include/linux/spi/spi.h index
> > aa09fdc8042d..a4fedb33d34b 100644
> > --- a/include/linux/spi/spi.h
> > +++ b/include/linux/spi/spi.h
> > @@ -14,6 +14,7 @@
> > #include
> > #include
> > #include
> > +#include
> >
> > struct dma_chan;
> > struct property_entry;
> > @@ -165,27 +166,6 @@ struct spi_device {
> > u8 bits_per_word;
> > boolrt;
> > u32 mode;
> > -#defineSPI_CPHA0x01/* clock phase */
> > -#defineSPI_CPOL0x02/* clock polarity */
> > -#defineSPI_MODE_0 (0|0) /* (original
> > MicroWire) */
> > -#defineSPI_MODE_1 (0|SPI_CPHA)
> > -#defineSPI_MODE_2 (SPI_CPOL|0)
> > -#defineSPI_MODE_3 (SPI_CPOL|SPI_CPHA)
> > -#defineSPI_MODE_X_MASK (SPI_CPOL|SPI_CPHA)
> > -#defineSPI_CS_HIGH 0x04/* chipselect
> > active high? */
> > -#defineSPI_LSB_FIRST 0x08/* per-word
&g
RE: [PATCH v2 3/3] Input: adp5589-keys - add basic devicetree support
> -Original Message-
> From: Lars-Peter Clausen
> Sent: Tuesday, November 24, 2020 10:43 AM
> To: Ardelean, Alexandru ; linux-
> in...@vger.kernel.org; linux-kernel@vger.kernel.org
> Cc: dmitry.torok...@gmail.com
> Subject: Re: [PATCH v2 3/3] Input: adp5589-keys - add basic devicetree support
>
> [External]
>
> On 11/24/20 9:22 AM, Alexandru Ardelean wrote:
> > error = devm_add_action_or_reset(>dev,
> > adp5589_clear_config, @@ -1078,6 +1098,13 @@ static int __maybe_unused
> > adp5589_resume(struct device *dev)
> >
> > static SIMPLE_DEV_PM_OPS(adp5589_dev_pm_ops, adp5589_suspend,
> > adp5589_resume);
> >
> > +static const struct of_device_id adp5589_of_match[] = {
> > + { .compatible = "adi,adp5585", .data =
> _chip_info_tbl[ADP5585_01] },
> > + { .compatible = "adi,adp5585-02", .data =
> _chip_info_tbl[ADP5585_02] },
> > + { .compatible = "adi,adp5589", .data =
> > +_chip_info_tbl[ADP5589] },
>
> I think we need to add these to
> Documentation/devicetree/bindings/trivial-devices.yaml
>
Ack
Will send a V3 in the next few days.
RE: [PATCH v2 1/3] spi: convert to BIT() all spi_device flags
> -Original Message- > From: Andy Shevchenko > Sent: Tuesday, November 24, 2020 1:50 PM > To: kernel test robot > Cc: Ardelean, Alexandru ; linux-spi s...@vger.kernel.org>; devicetree ; Linux Kernel > Mailing List ; kbuild-...@lists.01.org; Mark > Brown ; Rob Herring ; Bogdan, > Dragos > Subject: Re: [PATCH v2 1/3] spi: convert to BIT() all spi_device flags > > On Tue, Nov 24, 2020 at 1:42 PM kernel test robot wrote: > > > All warnings (new ones prefixed by >>): > > > >In file included from drivers/spi/spidev.c:26: > > >> include/uapi/linux/spi/spidev.h:33: warning: "SPI_CPHA" redefined > > 33 | #define SPI_CPHA 0x01 > > Argh! Can we have only one set of flags? > My bad here for not catching this earlier. It might be an idea to create a "include/uapi/linux/spi/spi.h" and include this in " include/uapi/linux/spi/spidev.h " Then the " include/uapi/linux/spi/spi.h " would also be included in " include/linux/spi/spi.h " We would naturally drop the BIT() macros for the uapi header. > -- > With Best Regards, > Andy Shevchenko
RE: [PATCH v2] uio/uio_pci_generic: remove unneeded pci_set_drvdata()
> -Original Message-
> From: Alexandru Ardelean
> Sent: Monday, November 23, 2020 4:35 PM
> To: linux-kernel@vger.kernel.org; k...@vger.kernel.org
> Cc: m...@redhat.com; gre...@linuxfoundation.org; Ardelean, Alexandru
>
> Subject: [PATCH v2] uio/uio_pci_generic: remove unneeded pci_set_drvdata()
>
> The pci_get_drvdata() was moved during commit ef84928cff58
> ("uio/uio_pci_generic: use device-managed function equivalents").
>
> Storing a private object with pci_set_drvdata() doesn't make sense since that
> change, since there is no more pci_get_drvdata() call in the driver to
> retrieve the
> information.
>
> This change removes it.
>
> Fixes: ef84928cff58 ("io/uio_pci_generic: use device-managed function
> equivalents")
> Signed-off-by: Alexandru Ardelean
> ---
Forgot the changelog
Apologies.
Changelog v1 -> v2:
* added Fixes tag
* updated commit comment a bit from V1
> drivers/uio/uio_pci_generic.c | 8 +---
> 1 file changed, 1 insertion(+), 7 deletions(-)
>
> diff --git a/drivers/uio/uio_pci_generic.c b/drivers/uio/uio_pci_generic.c
> index
> 1c6c09e1280d..b8e44d16279f 100644
> --- a/drivers/uio/uio_pci_generic.c
> +++ b/drivers/uio/uio_pci_generic.c
> @@ -101,13 +101,7 @@ static int probe(struct pci_dev *pdev,
>"no support for interrupts?\n");
> }
>
> - err = devm_uio_register_device(>dev, >info);
> - if (err)
> - return err;
> -
> - pci_set_drvdata(pdev, gdev);
> -
> - return 0;
> + return devm_uio_register_device(>dev, >info);
> }
>
> static struct pci_driver uio_pci_driver = {
> --
> 2.17.1
RE: [PATCH] uio/uio_pci_generic: remove unneeded pci_set_drvdata()
> -Original Message-
> From: Greg KH
> Sent: Friday, November 20, 2020 5:46 PM
> To: Ardelean, Alexandru
> Cc: linux-kernel@vger.kernel.org
> Subject: Re: [PATCH] uio/uio_pci_generic: remove unneeded pci_set_drvdata()
>
> [External]
>
> On Thu, Nov 19, 2020 at 04:59:06PM +0200, Alexandru Ardelean wrote:
> > The pci_get_drvdata() was moved during commit ef84928cff58
> > ("uio/uio_pci_generic: use device-managed function equivalents").
> >
> > I should have notice that the pci_set_drvdata() requires a
> > pci_get_drvdata() for it to make sense.
> >
> > Signed-off-by: Alexandru Ardelean
> > ---
> >
> > Apologies for not noticing this sooner.
> > If this can be squashed into commit ef84928cff58 , then it's also fine.
> > I've started seeing that there actually more xxx_set_drvdata()
> > leftovers in the entire kernel, and I pinged the checkpatch crew to
> > add a check for this.
> >
> > https://urldefense.com/v3/__https://lore.kernel.org/lkml/CA*U=Dspy5*RE
> >
> 9agcLr6eY9DCMa1c5**b0jleugmmbrxz4yl...@mail.gmail.com/T/*u__;KysrK
> ysj!
> >
> !A3Ni8CS0y2Y!q3fJW4rKvEHQ7BDt1PaK4Cbexv4wbivUKBeDjo7ZwNXYwOLBawA
> Eq1Jaj
> > mhYxftX6DAJpg$
>
> I can't squash existing public commits. Can you resend this and add a
> "Fixes:"
> tag to it to show what commit it fixes so we can track this properly?
>
Sure, will re-send in the next couple of days.
Thanks
Alex
> thanks,
>
> greg k-h
RE: [PATCH] Input: adp5589-keys - use BIT()
> -Original Message- > From: Dmitry Torokhov > Sent: Thursday, November 19, 2020 9:25 AM > To: linux-in...@vger.kernel.org > Cc: Ardelean, Alexandru ; linux- > ker...@vger.kernel.org > Subject: [PATCH] Input: adp5589-keys - use BIT() > > [External] > > Let's use BIT() macro instead of explicitly shifting '1'. As a first iteration for cleaning up bitmask stuff, this looks good. So: Acked-by: Alexandru Ardelean As a continuation, in some places, some GENMASK() and FIELD_GET() macros would be an idea for some contiguous bits. I can do that later. For now, my todo-list doesn't include these conversions. Thanks Alex > > Signed-off-by: Dmitry Torokhov > --- > drivers/input/keyboard/adp5589-keys.c | 69 ++- > 1 file changed, 35 insertions(+), 34 deletions(-) > > diff --git a/drivers/input/keyboard/adp5589-keys.c > b/drivers/input/keyboard/adp5589-keys.c > index a9b69a268c09..70c8d1c298ee 100644 > --- a/drivers/input/keyboard/adp5589-keys.c > +++ b/drivers/input/keyboard/adp5589-keys.c > @@ -7,6 +7,7 @@ > * Copyright (C) 2010-2011 Analog Devices Inc. > */ > > +#include > #include > #include > #include > @@ -153,48 +154,48 @@ > #define ADP5589_5_MAN_ID 0x02 > > /* GENERAL_CFG Register */ > -#define OSC_EN (1 << 7) > +#define OSC_EN BIT(7) > #define CORE_CLK(x) (((x) & 0x3) << 5) > -#define LCK_TRK_LOGIC(1 << 4)/* ADP5589 only */ > -#define LCK_TRK_GPI (1 << 3)/* ADP5589 only */ > -#define INT_CFG (1 << 1) > -#define RST_CFG (1 << 0) > +#define LCK_TRK_LOGICBIT(4) /* ADP5589 only */ > +#define LCK_TRK_GPI BIT(3) /* ADP5589 only */ > +#define INT_CFG BIT(1) > +#define RST_CFG BIT(0) > > /* INT_EN Register */ > -#define LOGIC2_IEN (1 << 5)/* ADP5589 only */ > -#define LOGIC1_IEN (1 << 4) > -#define LOCK_IEN (1 << 3)/* ADP5589 only */ > -#define OVRFLOW_IEN (1 << 2) > -#define GPI_IEN (1 << 1) > -#define EVENT_IEN(1 << 0) > +#define LOGIC2_IEN BIT(5) /* ADP5589 only */ > +#define LOGIC1_IEN BIT(4) > +#define LOCK_IEN BIT(3) /* ADP5589 only */ > +#define OVRFLOW_IEN BIT(2) > +#define GPI_IEN BIT(1) > +#define EVENT_IENBIT(0) > > /* Interrupt Status Register */ > -#define LOGIC2_INT (1 << 5)/* ADP5589 only */ > -#define LOGIC1_INT (1 << 4) > -#define LOCK_INT (1 << 3)/* ADP5589 only */ > -#define OVRFLOW_INT (1 << 2) > -#define GPI_INT (1 << 1) > -#define EVENT_INT(1 << 0) > +#define LOGIC2_INT BIT(5) /* ADP5589 only */ > +#define LOGIC1_INT BIT(4) > +#define LOCK_INT BIT(3) /* ADP5589 only */ > +#define OVRFLOW_INT BIT(2) > +#define GPI_INT BIT(1) > +#define EVENT_INTBIT(0) > > /* STATUS Register */ > -#define LOGIC2_STAT (1 << 7)/* ADP5589 only */ > -#define LOGIC1_STAT (1 << 6) > -#define LOCK_STAT(1 << 5)/* ADP5589 only */ > +#define LOGIC2_STAT BIT(7) /* ADP5589 only */ > +#define LOGIC1_STAT BIT(6) > +#define LOCK_STATBIT(5) /* ADP5589 only */ > #define KEC 0x1F > > /* PIN_CONFIG_D Register */ > -#define C4_EXTEND_CFG(1 << 6)/* RESET2 */ > -#define R4_EXTEND_CFG(1 << 5)/* RESET1 */ > +#define C4_EXTEND_CFGBIT(6) /* RESET2 */ > +#define R4_EXTEND_CFGBIT(5) /* RESET1 */ > > /* LOCK_CFG */ > -#define LOCK_EN (1 << 0) > +#define LOCK_EN BIT(0) > > #define PTIME_MASK 0x3 > #define LTIME_MASK 0x3 /* ADP5589 only */ > > /* Key Event Register xy */ > -#define KEY_EV_PRESSED (1 << 7) > -#define KEY_EV_MASK (0x7F) > +#define KEY_EV_PRESSED BIT(7) > +#define KEY_EV_MASK 0x7F > > #define KEYP_MAX_EVENT 16 > #define ADP5589_MAXGPIO 19 > @@ -472,7 +473,7 @@ static int adp5589_build_gpiomap(struct adp5589_kpad > *kpad, > memset(pin_used, false, sizeof(pin_used)); > > for (i = 0; i < kpad->var->maxgpio; i++) > - if (pdata->keypad_en_mask & (1 << i)) > + if (pdata->keypad_en_mask & BIT(i)) > pin_used[i] = true; > > for (i = 0; i < kpad->gpimapsize; i++) @@ -651,13 +652,13 @@ static int > adp5589_setup(struct adp5589_kpad *kpa
RE: [PATCH] Input: adp5589-keys - mark suspend and resume methods as __maybe_unused
> -Original Message-
> From: Dmitry Torokhov
> Sent: Thursday, November 19, 2020 9:24 AM
> To: linux-in...@vger.kernel.org
> Cc: Ardelean, Alexandru ; linux-
> ker...@vger.kernel.org
> Subject: [PATCH] Input: adp5589-keys - mark suspend and resume methods as
> __maybe_unused
>
> [External]
>
> This improves compile coverage of the code; unused code will be dropped by the
> linker.
>
Acked-by: Alexandru Ardelean
> Signed-off-by: Dmitry Torokhov
> ---
> drivers/input/keyboard/adp5589-keys.c | 6 ++
> 1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/input/keyboard/adp5589-keys.c
> b/drivers/input/keyboard/adp5589-keys.c
> index 31145a85c819..a9b69a268c09 100644
> --- a/drivers/input/keyboard/adp5589-keys.c
> +++ b/drivers/input/keyboard/adp5589-keys.c
> @@ -1016,8 +1016,7 @@ static int adp5589_probe(struct i2c_client *client,
> return 0;
> }
>
> -#ifdef CONFIG_PM_SLEEP
> -static int adp5589_suspend(struct device *dev)
> +static int __maybe_unused adp5589_suspend(struct device *dev)
> {
> struct adp5589_kpad *kpad = dev_get_drvdata(dev);
> struct i2c_client *client = kpad->client; @@ -1033,7 +1032,7 @@ static
> int adp5589_suspend(struct device *dev)
> return 0;
> }
>
> -static int adp5589_resume(struct device *dev)
> +static int __maybe_unused adp5589_resume(struct device *dev)
> {
> struct adp5589_kpad *kpad = dev_get_drvdata(dev);
> struct i2c_client *client = kpad->client; @@ -1048,7 +1047,6 @@ static
> int adp5589_resume(struct device *dev)
>
> return 0;
> }
> -#endif
>
> static SIMPLE_DEV_PM_OPS(adp5589_dev_pm_ops, adp5589_suspend,
> adp5589_resume);
>
> --
> 2.29.2.299.gdc1121823c-goog
>
>
> --
> Dmitry
RE: [PATCH v2] dt-bindings: adau1977: convert text binding to yaml format
> -Original Message- > From: Mark Brown > Sent: Monday, November 16, 2020 11:19 PM > To: Ardelean, Alexandru > Cc: alsa-de...@alsa-project.org; devicet...@vger.kernel.org; linux- > ker...@vger.kernel.org; l...@metafoo.de; robh...@kernel.org; > lgirdw...@gmail.com > Subject: Re: [PATCH v2] dt-bindings: adau1977: convert text binding to yaml > format > > [External] > > On Tue, Nov 10, 2020 at 10:47:54AM +0200, Alexandru Ardelean wrote: > > This change converts the old device-tree binding for ADAU1977 from > > text format to the new yaml format. > > Please submit patches using subject lines reflecting the style for the > subsystem, > this makes it easier for people to identify relevant patches. > Look at what existing commits in the area you're changing are doing and make > sure your subject lines visually resemble what they're doing. > There's no need to resubmit to fix this alone. Apologies. I did look around and the git log of that folder and noticed a bit of mixed styling for the commit title. I admit I should have probably taken a closer look and better guessed the styling a bit. I'll try to keep in mind for ASoC bindings. I do remember Rob complaining [on some older binding patch] that the styling for bindings should be in the format I just did. ¯\_(ツ)_/¯
RE: [PATCH RESEND net-next 18/18] net: phy: adin: remove the use of the .ack_interrupt()
> -Original Message-
> From: Ioana Ciornei
> Sent: Friday, November 13, 2020 6:52 PM
> To: Andrew Lunn ; Heiner Kallweit ;
> Russell King ; Florian Fainelli ;
> Jakub Kicinski ; net...@vger.kernel.org; linux-
> ker...@vger.kernel.org
> Cc: Ioana Ciornei ; Ardelean, Alexandru
>
> Subject: [PATCH RESEND net-next 18/18] net: phy: adin: remove the use of the
> .ack_interrupt()
>
> [External]
>
> From: Ioana Ciornei
>
> In preparation of removing the .ack_interrupt() callback, we must replace its
> occurrences (aka phy_clear_interrupt), from the 2 places where it is called
> from
> (phy_enable_interrupts and phy_disable_interrupts), with equivalent
> functionality.
>
> This means that clearing interrupts now becomes something that the PHY driver
> is responsible of doing, before enabling interrupts and after clearing them.
> Make
> this driver follow the new contract.
>
Acked-by: Alexandru Ardelean
> Cc: Alexandru Ardelean
> Signed-off-by: Ioana Ciornei
> ---
> drivers/net/phy/adin.c | 25 ++---
> 1 file changed, 18 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/net/phy/adin.c b/drivers/net/phy/adin.c index
> ba24434b867d..55a0b91816e2 100644
> --- a/drivers/net/phy/adin.c
> +++ b/drivers/net/phy/adin.c
> @@ -471,12 +471,25 @@ static int adin_phy_ack_intr(struct phy_device
> *phydev)
>
> static int adin_phy_config_intr(struct phy_device *phydev) {
> - if (phydev->interrupts == PHY_INTERRUPT_ENABLED)
> - return phy_set_bits(phydev, ADIN1300_INT_MASK_REG,
> - ADIN1300_INT_MASK_EN);
> + int err;
> +
> + if (phydev->interrupts == PHY_INTERRUPT_ENABLED) {
> + err = adin_phy_ack_intr(phydev);
> + if (err)
> + return err;
> +
> + err = phy_set_bits(phydev, ADIN1300_INT_MASK_REG,
> +ADIN1300_INT_MASK_EN);
> + } else {
> + err = phy_clear_bits(phydev, ADIN1300_INT_MASK_REG,
> + ADIN1300_INT_MASK_EN);
> + if (err)
> + return err;
> +
> + err = adin_phy_ack_intr(phydev);
> + }
>
> - return phy_clear_bits(phydev, ADIN1300_INT_MASK_REG,
> - ADIN1300_INT_MASK_EN);
> + return err;
> }
>
> static irqreturn_t adin_phy_handle_interrupt(struct phy_device *phydev) @@ -
> 895,7 +908,6 @@ static struct phy_driver adin_driver[] = {
> .read_status= adin_read_status,
> .get_tunable= adin_get_tunable,
> .set_tunable= adin_set_tunable,
> - .ack_interrupt = adin_phy_ack_intr,
> .config_intr= adin_phy_config_intr,
> .handle_interrupt = adin_phy_handle_interrupt,
> .get_sset_count = adin_get_sset_count,
> @@ -919,7 +931,6 @@ static struct phy_driver adin_driver[] = {
> .read_status= adin_read_status,
> .get_tunable= adin_get_tunable,
> .set_tunable= adin_set_tunable,
> - .ack_interrupt = adin_phy_ack_intr,
> .config_intr= adin_phy_config_intr,
> .handle_interrupt = adin_phy_handle_interrupt,
> .get_sset_count = adin_get_sset_count,
> --
> 2.28.0
RE: [PATCH RESEND net-next 17/18] net: phy: adin: implement generic .handle_interrupt() callback
> -Original Message-
> From: Ioana Ciornei
> Sent: Friday, November 13, 2020 6:52 PM
> To: Andrew Lunn ; Heiner Kallweit ;
> Russell King ; Florian Fainelli ;
> Jakub Kicinski ; net...@vger.kernel.org; linux-
> ker...@vger.kernel.org
> Cc: Ioana Ciornei ; Ardelean, Alexandru
>
> Subject: [PATCH RESEND net-next 17/18] net: phy: adin: implement generic
> .handle_interrupt() callback
>
> [External]
>
> From: Ioana Ciornei
>
> In an attempt to actually support shared IRQs in phylib, we now move the
> responsibility of triggering the phylib state machine or just returning
> IRQ_NONE,
> based on the IRQ status register, to the PHY driver. Having
> 3 different IRQ handling callbacks (.handle_interrupt(),
> .did_interrupt() and .ack_interrupt() ) is confusing so let the PHY driver
> implement directly an IRQ handler like any other device driver.
> Make this driver follow the new convention.
>
Acked-by: Alexandru Ardelean
> Cc: Alexandru Ardelean
> Signed-off-by: Ioana Ciornei
> ---
> drivers/net/phy/adin.c | 20
> 1 file changed, 20 insertions(+)
>
> diff --git a/drivers/net/phy/adin.c b/drivers/net/phy/adin.c index
> 3727b38addf7..ba24434b867d 100644
> --- a/drivers/net/phy/adin.c
> +++ b/drivers/net/phy/adin.c
> @@ -479,6 +479,24 @@ static int adin_phy_config_intr(struct phy_device
> *phydev)
> ADIN1300_INT_MASK_EN);
> }
>
> +static irqreturn_t adin_phy_handle_interrupt(struct phy_device *phydev)
> +{
> + int irq_status;
> +
> + irq_status = phy_read(phydev, ADIN1300_INT_STATUS_REG);
> + if (irq_status < 0) {
> + phy_error(phydev);
> + return IRQ_NONE;
> + }
> +
> + if (!(irq_status & ADIN1300_INT_LINK_STAT_CHNG_EN))
> + return IRQ_NONE;
> +
> + phy_trigger_machine(phydev);
> +
> + return IRQ_HANDLED;
> +}
> +
> static int adin_cl45_to_adin_reg(struct phy_device *phydev, int devad,
>u16 cl45_regnum)
> {
> @@ -879,6 +897,7 @@ static struct phy_driver adin_driver[] = {
> .set_tunable= adin_set_tunable,
> .ack_interrupt = adin_phy_ack_intr,
> .config_intr= adin_phy_config_intr,
> + .handle_interrupt = adin_phy_handle_interrupt,
> .get_sset_count = adin_get_sset_count,
> .get_strings= adin_get_strings,
> .get_stats = adin_get_stats,
> @@ -902,6 +921,7 @@ static struct phy_driver adin_driver[] = {
> .set_tunable= adin_set_tunable,
> .ack_interrupt = adin_phy_ack_intr,
> .config_intr= adin_phy_config_intr,
> + .handle_interrupt = adin_phy_handle_interrupt,
> .get_sset_count = adin_get_sset_count,
> .get_strings= adin_get_strings,
> .get_stats = adin_get_stats,
> --
> 2.28.0
RE: [PATCH 1/6] Input: adp5589: use a single variable for error in probe
> -Original Message- > From: Ardelean, Alexandru > Sent: Thursday, November 12, 2020 8:40 AM > To: Dmitry Torokhov > Cc: linux-in...@vger.kernel.org; linux-kernel@vger.kernel.org > Subject: RE: [PATCH 1/6] Input: adp5589: use a single variable for error in > probe > > > > -Original Message- > > From: Dmitry Torokhov > > Sent: Thursday, November 12, 2020 2:38 AM > > To: Ardelean, Alexandru > > Cc: linux-in...@vger.kernel.org; linux-kernel@vger.kernel.org > > Subject: Re: [PATCH 1/6] Input: adp5589: use a single variable for > > error in probe > > > > [External] > > > > Hi Alexandru, > > > > On Wed, Nov 11, 2020 at 10:48:28AM +0200, Alexandru Ardelean wrote: > > > The 'error' & 'ret' variables are used. This is a bit of duplication. > > > This change replaces the use of error with the 'ret' variable since > > > the name is a bit more generic. > > > > I really prefer variables that carry error codes/success and are used > > in error paths to be called "error", and "ret" or "retval" to be used > > in cases where we may return actual data. > > > > Ack. > Will do it the other way around for v2. > Wait. I just had some coffee. I think you're saying to drop this patch. Also fine from my side. > > Thanks. > > > > -- > > Dmitry
RE: [PATCH 1/6] Input: adp5589: use a single variable for error in probe
> -Original Message- > From: Dmitry Torokhov > Sent: Thursday, November 12, 2020 2:38 AM > To: Ardelean, Alexandru > Cc: linux-in...@vger.kernel.org; linux-kernel@vger.kernel.org > Subject: Re: [PATCH 1/6] Input: adp5589: use a single variable for error in > probe > > [External] > > Hi Alexandru, > > On Wed, Nov 11, 2020 at 10:48:28AM +0200, Alexandru Ardelean wrote: > > The 'error' & 'ret' variables are used. This is a bit of duplication. > > This change replaces the use of error with the 'ret' variable since > > the name is a bit more generic. > > I really prefer variables that carry error codes/success and are used in error > paths to be called "error", and "ret" or "retval" to be used in cases where we > may return actual data. > Ack. Will do it the other way around for v2. > Thanks. > > -- > Dmitry
RE: [PATCH v1] Input: ads7846: do not overwrite spi->mode flags set by spi framework
> -Original Message- > From: Oleksij Rempel > Sent: Wednesday, October 21, 2020 12:05 PM > To: Dmitry Torokhov ; Ardelean, Alexandru > > Cc: Oleksij Rempel ; ker...@pengutronix.de; linux- > ker...@vger.kernel.org; linux-in...@vger.kernel.org; David Jander > > Subject: [PATCH v1] Input: ads7846: do not overwrite spi->mode flags set by > spi > framework > > [External] > > Do not overwrite spi->mode flags set by spi framework, otherwise the chip > select polarity will get lost. > > Signed-off-by: Oleksij Rempel > --- > drivers/input/touchscreen/ads7846.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/input/touchscreen/ads7846.c > b/drivers/input/touchscreen/ads7846.c > index 8fd7fc39c4fd..ea31956f3a90 100644 > --- a/drivers/input/touchscreen/ads7846.c > +++ b/drivers/input/touchscreen/ads7846.c > @@ -1288,7 +1288,7 @@ static int ads7846_probe(struct spi_device *spi) >* may not. So we stick to very-portable 8 bit words, both RX and TX. >*/ > spi->bits_per_word = 8; > - spi->mode = SPI_MODE_0; I think the patch is incorrect. The initial version is correct; assuming that the datasheet says that this driver operates in mode 0. If the initial mode is incorrect, maybe we need to change that. What is unfortunate, is that you cannot [yet] override the mode parameters [polarity & phase] from the device-tree, in case there are some things in-between the SPI controller & SPI chip [level inverters for example]. I was planning to do something for this. > + spi->mode |= SPI_MODE_0; > err = spi_setup(spi); > if (err < 0) > return err; > -- > 2.28.0
RE: [PATCH] ASoC: adau1977: remove platform data and move micbias bindings include
> -Original Message- > From: Mark Brown > Sent: Monday, October 19, 2020 4:04 PM > To: Ardelean, Alexandru > Cc: linux-kernel@vger.kernel.org; alsa-de...@alsa-project.org; > lgirdw...@gmail.com; l...@metafoo.de; Sa, Nuno ; > pe...@perex.cz; ti...@suse.com > Subject: Re: [PATCH] ASoC: adau1977: remove platform data and move micbias > bindings include > > [External] > > On Mon, Oct 19, 2020 at 01:53:13PM +0300, Alexandru Ardelean wrote: > > The change removes the platform_data include/definition. It only > > contains some values for the MICBIAS. > > These are moved into 'dt-bindings/sound/adi,adau1977.h' so that they > > can be used inside device-trees. When moving then, they need to be > > converted to pre-compiler defines, so that the DT compiler can understand > them. > > This is missing an update of the binding documentation for the new property. Umm, if referring to the 'adi,micbias' property, that isn't new: https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git/tree/Documentation/devicetree/bindings/sound/adi,adau1977.txt#n26 This just removes any left-over platform-data stuff; which admittedly should have been done earlier. I also started a conversion of the old binding from text to yaml. I'll probably have that ready in a couple of days.
RE: [PATCH] dt-bindings: clock: adi,axi-clkgen: convert old binding to yaml format
> -Original Message-
> From: Rob Herring
> Sent: Tuesday, October 6, 2020 11:25 PM
> To: Ardelean, Alexandru
> Cc: linux-...@vger.kernel.org; devicet...@vger.kernel.org; linux-
> ker...@vger.kernel.org; Hennerich, Michael
> ; l...@metafoo.de; sb...@kernel.org;
> mturque...@baylibre.com; m...@kernel.org
> Subject: Re: [PATCH] dt-bindings: clock: adi,axi-clkgen: convert old binding
> to
> yaml format
>
> On Thu, Oct 01, 2020 at 11:50:35AM +0300, Alexandru Ardelean wrote:
> > This change converts the old binding for the AXI clkgen driver to a
> > yaml format.
> >
> > As maintainers, added:
> > - Lars-Peter Clausen - as original author of driver &
> >binding
>
> Do you have permission for relicensing? The default was GPL-2.0.
I talked to Michael Hennerich [he's cc-ed], and we have permission from his
side.
I think Lars would need to provide permission as well, as the author.
If we won't have a reply from him [after by some time-frame] I'll leave it as
GPL-2.0.
I'm a bit clumsy about licensing in general; and I don't care about it all that
much.
>
> > - Michael Hennerich - as supporter of
> >Analog Devices drivers
> >
> > Signed-off-by: Alexandru Ardelean
> > ---
> > .../bindings/clock/adi,axi-clkgen.yaml| 52 +++
> > .../devicetree/bindings/clock/axi-clkgen.txt | 25 -
> > 2 files changed, 52 insertions(+), 25 deletions(-) create mode
> > 100644 Documentation/devicetree/bindings/clock/adi,axi-clkgen.yaml
> > delete mode 100644
> > Documentation/devicetree/bindings/clock/axi-clkgen.txt
> >
> > diff --git
> > a/Documentation/devicetree/bindings/clock/adi,axi-clkgen.yaml
> > b/Documentation/devicetree/bindings/clock/adi,axi-clkgen.yaml
> > new file mode 100644
> > index ..45497f370cb3
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/clock/adi,axi-clkgen.yaml
> > @@ -0,0 +1,52 @@
> > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) %YAML 1.2
> > +---
> > +$id:
> > +https://urldefense.com/v3/__http://devicetree.org/schemas/clock/adi,a
> > +xi-
> clkgen.yaml*__;Iw!!A3Ni8CS0y2Y!s_aQs5F13Tud7X5wmDjgyOhkPGGpnQgdtN7
> > +apmY8mrX_fgQOlQvZTtRGBSIpmJtDghVa8A$
> > +$schema:
> > +https://urldefense.com/v3/__http://devicetree.org/meta-schemas/core.y
> >
> +aml*__;Iw!!A3Ni8CS0y2Y!s_aQs5F13Tud7X5wmDjgyOhkPGGpnQgdtN7apmY8
> mrX_fg
> > +QOlQvZTtRGBSIpmJuCLAwQnQ$
> > +
> > +title: Binding for Analog Devices AXI clkgen pcore clock generator
> > +
> > +maintainers:
> > + - Lars-Peter Clausen
> > + - Michael Hennerich
> > +
> > +description: |
> > + The axi_clkgen IP core is a software programmable clock generator,
> > + that can be synthesized on various FPGA platforms.
> > +
> > + Link: https://wiki.analog.com/resources/fpga/docs/axi_clkgen
> > +
> > +properties:
> > + compatible:
> > +enum:
> > + - adi,axi-clkgen-2.00.a
> > +
> > + clocks:
> > +description:
> > + Phandle and clock specifier for the parent clock(s).
>
> Drop, that's every 'clocks'.
>
> > This must either
> > + reference one clock if only the first clock input is connected or two
> > + if both clock inputs are connected. For the later case the clock
> > + connected to the first input must be specified first.
>
> That doesn't really say what the 2 clocks are.
>
> > +minItems: 1
> > +maxItems: 2
> > +
> > + '#clock-cells':
> > +const: 0
> > +
> > + reg:
> > +maxItems: 1
> > +
> > +required:
> > + - compatible
> > + - reg
> > + - clocks
> > + - '#clock-cells'
>
> additionalProperties: false
>
> > +
> > +examples:
> > + - |
> > +clock@ff00 {
>
> clock-controller@...
>
> > + compatible = "adi,axi-clkgen-2.00.a";
> > + #clock-cells = <0>;
> > + reg = <0xff00 0x1000>;
> > + clocks = < 1>;
> > +};
> > diff --git a/Documentation/devicetree/bindings/clock/axi-clkgen.txt
> > b/Documentation/devicetree/bindings/clock/axi-clkgen.txt
> > deleted file mode 100644
> > index aca94fe9416f..
> > --- a/Documentation/devicetree/bindings/clock/axi-clkgen.txt
> > +++ /dev/null
> > @@ -1,25 +0,0 @@
> > -Binding for the axi-clkgen clock generator
> > -
> > -This binding uses the common clock binding[1].
> > -
> > -[1] Documentation/devicetree/bindings/clock/clo
RE: [PATCH] MAINTAINERS: Remove bouncing email of Beniamin Bia
[yes, I know, bad-email format, but I wanted this to come from my work email] Apologies also for the delay here. Things pile-up on my side and I defer things a bit. Talked to Michael Hennerich about this [since he's the more senior contact at Analog]. We can replace the email from Beniamin Bia with Michael's. Or, we can remove the "Orphan" blocks and just have the catch-all "drivers/iio/*/ad*" cover this driver and others that were upstreamed by Beniamin. Either option is fine from us. -Original Message- From: Krzysztof Kozlowski Sent: Saturday, August 29, 2020 5:58 PM To: Jonathan Cameron Cc: Andy Shevchenko ; Linux Kernel Mailing List ; Hennerich, Michael ; linux-iio ; Ardelean, Alexandru Subject: Re: [PATCH] MAINTAINERS: Remove bouncing email of Beniamin Bia On Sat, 29 Aug 2020 at 16:54, Jonathan Cameron wrote: (...) > > > ANALOG DEVICES INC AD7091R5 DRIVER > > > -M: Beniamin Bia > > > L: linux-...@vger.kernel.org > > > -S: Supported > > > +S: Orphan > > Given it should be covered by the catch all for Analog devices IIO > drivers, either we should confirm if it should move to someone else at > Analog, or if we should just drop specifically listing this one. > Listing it as Orphan when they are good at supporting their drivers > may give the wrong impression. > > +CC Alex to make sure people at Analog notice :) Sure, good point. I wanted to start the discussion so the interested people might appear. Best regards, Krzysztof
RE: [PATCH 5/6] include: fpga: adi-axi-common.h: add definitions for supported FPGAs
-Original Message-
From: Tom Rix
Sent: Wednesday, August 5, 2020 7:02 PM
To: Ardelean, Alexandru ;
linux-...@vger.kernel.org; linux-f...@vger.kernel.org;
linux-kernel@vger.kernel.org
Cc: mturque...@baylibre.com; sb...@kernel.org; m...@kernel.org; Caprioru,
Mircea
Subject: Re: [PATCH 5/6] include: fpga: adi-axi-common.h: add definitions for
supported FPGAs
[External]
On 8/4/20 4:06 AM, Alexandru Ardelean wrote:
> From: Mircea Caprioru
>
> All (newer) FPGA IP cores supported by Analog Devices, store
> information in the synthesized designs. This information describes
> various parameters, including the family of boards on which this is
> deployed, speed-grade, and so on.
>
> Currently, some of these definitions are deployed mostly on Xilinx
> boards, but they have been considered also for FPGA boards from other vendors.
>
> The register definitions are described at this link:
> https://wiki.analog.com/resources/fpga/docs/hdl/regmap
> (the 'Base (common to all cores)' section).
>
> Signed-off-by: Mircea Caprioru
> Signed-off-by: Alexandru Ardelean
> ---
> include/linux/fpga/adi-axi-common.h | 37
> +
> 1 file changed, 37 insertions(+)
>
> diff --git a/include/linux/fpga/adi-axi-common.h
> b/include/linux/fpga/adi-axi-common.h
> index 141ac3f251e6..7cca2d62cc45 100644
> --- a/include/linux/fpga/adi-axi-common.h
> +++ b/include/linux/fpga/adi-axi-common.h
> @@ -13,6 +13,9 @@
>
> #define ADI_AXI_REG_VERSION 0x
>
> +#define ADI_AXI_REG_FPGA_INFO0x001C
> +#define ADI_AXI_REG_FPGA_VOLTAGE 0x0140
> +
> #define ADI_AXI_PCORE_VER(major, minor, patch) \
> (((major) << 16) | ((minor) << 8) | (patch))
>
> @@ -20,4 +23,38 @@
> #define ADI_AXI_PCORE_VER_MINOR(version) (((version) >> 8) & 0xff)
> #define ADI_AXI_PCORE_VER_PATCH(version) ((version) & 0xff)
>
> +#define ADI_AXI_INFO_FPGA_VOLTAGE(val) ((val) & 0x)
> +
> +#define ADI_AXI_INFO_FPGA_TECH(info) (((info) >> 24) & 0xff)
> +#define ADI_AXI_INFO_FPGA_FAMILY(info) (((info) >> 16) & 0xff)
> +#define ADI_AXI_INFO_FPGA_SPEED_GRADE(info) (((info) >> 8) & 0xff)
> +
> +enum adi_axi_fgpa_technology {
> enum types are defined but not used. It would be better to convert all of
> these to #defines.
>
> These are only the Xilinx values. Need to add the Intel values from
> https://urldefense.com/v3/__https://github.com/analogdevicesinc/hdl/blob/master/library/scripts/adi_intel_device_info_enc.tcl__;!!A3Ni8CS0y2Y!tpLxcnpvcjFVEYz0mfRNW03dYet-iklk2s_eG4FmRmeyMOcldd8f-zpebB5NnJLOjl1rNw$
>
> The #define names need to include XILINX or INTEL.
Ah, good point.
This patch was initially written before the Intel stuff was added.
Will update.
Apologies for the mis-formatted reply/email; will need to include my Gmail
account to reply neater here.
> Tom
> + ADI_AXI_FPGA_TECH_UNKNOWN = 0,
> + ADI_AXI_FPGA_TECH_SERIES7,
> + ADI_AXI_FPGA_TECH_ULTRASCALE,
> + ADI_AXI_FPGA_TECH_ULTRASCALE_PLUS,
> +};
> +
> +enum adi_axi_fpga_family {
> + ADI_AXI_FPGA_FAMILY_UNKNOWN = 0,
> + ADI_AXI_FPGA_FAMILY_ARTIX,
> + ADI_AXI_FPGA_FAMILY_KINTEX,
> + ADI_AXI_FPGA_FAMILY_VIRTEX,
> + ADI_AXI_FPGA_FAMILY_ZYNQ,
> +};
> +
> +enum adi_axi_fpga_speed_grade {
> + ADI_AXI_FPGA_SPEED_UNKNOWN = 0,
> + ADI_AXI_FPGA_SPEED_1= 10,
> + ADI_AXI_FPGA_SPEED_1L = 11,
> + ADI_AXI_FPGA_SPEED_1H = 12,
> + ADI_AXI_FPGA_SPEED_1HV = 13,
> + ADI_AXI_FPGA_SPEED_1LV = 14,
> + ADI_AXI_FPGA_SPEED_2= 20,
> + ADI_AXI_FPGA_SPEED_2L = 21,
> + ADI_AXI_FPGA_SPEED_2LV = 22,
> + ADI_AXI_FPGA_SPEED_3= 30,
> +};
> +
> #endif /* ADI_AXI_COMMON_H_ */
RE: [PATCH] iio: trigger: Staticise stub functions
Apologies from my side for being too much of a patch-bot here.
I should have also given some more thought to the patch.
Atm, I'm sending this from Outlook, since [for some reason] the Linux
mail-client isn't working.
[ Which is why this isn't properly inlined either ]
I'll send a V2.
-Original Message-
From: Lars-Peter Clausen
Sent: Saturday, July 18, 2020 7:37 PM
To: Jonathan Cameron ; Ardelean, Alexandru
Cc: linux-...@vger.kernel.org; linux-kernel@vger.kernel.org
Subject: Re: [PATCH] iio: trigger: Staticise stub functions
[External]
On 7/18/20 6:25 PM, Jonathan Cameron wrote:
> On Tue, 14 Jul 2020 17:24:56 +0300
> Alexandru Ardelean wrote:
>
>> From: Lars-Peter Clausen
>>
>> Make sure that the trigger function stubs are all static inline.
>> Otherwise we'll get linker errors due to multiple definitions of the same
>> function.
>>
>> Fixes f8c6f4e9a40d4: ("iio: trigger: Staticise stub functions")
>> Signed-off-by: Lars-Peter Clausen
>> Signed-off-by: Alexandru Ardelean
> I'm curious on what the actual build error is? Static functions
> should result in independent implementations in each C file that
> includes them. Inline is normally considered a hint. Hence what am I missing?
It's a bad commit message, my fault. This should have been
Make sure that the trigger function stubs are all static inline.
Otherwise we might see compiler warnings about declared but unused functions.
Re: [PATCH 1/3] iio: Move attach/detach of the poll func to the core
On Fri, 2020-05-22 at 13:46 +0300, Alexandru Ardelean wrote:
> From: Lars-Peter Clausen
>
> All devices using a triggered buffer need to attach and detach the
> trigger
> to the device in order to properly work. Instead of doing this in each
> and
> every driver by hand move this into the core.
>
> At this point in time, all drivers should have been resolved to
> attach/detach the poll-function in the same order.
>
> Signed-off-by: Lars-Peter Clausen
> Signed-off-by: Alexandru Ardelean
> ---
> .../buffer/industrialio-triggered-buffer.c| 10 +
> drivers/iio/iio_core_trigger.h| 17 ++
> drivers/iio/industrialio-buffer.c | 13 +++
> drivers/iio/industrialio-trigger.c| 22 ---
> include/linux/iio/trigger_consumer.h | 7 --
> 5 files changed, 35 insertions(+), 34 deletions(-)
>
> diff --git a/drivers/iio/buffer/industrialio-triggered-buffer.c
> b/drivers/iio/buffer/industrialio-triggered-buffer.c
> index e8046c1ecd6b..6c20a83f887e 100644
> --- a/drivers/iio/buffer/industrialio-triggered-buffer.c
> +++ b/drivers/iio/buffer/industrialio-triggered-buffer.c
> @@ -13,11 +13,6 @@
> #include
> #include
>
> -static const struct iio_buffer_setup_ops iio_triggered_buffer_setup_ops
> = {
> - .postenable = _triggered_buffer_postenable,
> - .predisable = _triggered_buffer_predisable,
> -};
> -
> /**
> * iio_triggered_buffer_setup() - Setup triggered buffer and pollfunc
> * @indio_dev: IIO device structure
> @@ -67,10 +62,7 @@ int iio_triggered_buffer_setup(struct iio_dev
> *indio_dev,
> }
>
> /* Ring buffer functions - here trigger setup related */
> - if (setup_ops)
> - indio_dev->setup_ops = setup_ops;
> - else
> - indio_dev->setup_ops = _triggered_buffer_setup_ops;
> + indio_dev->setup_ops = setup_ops;
>
> /* Flag that polled ring buffering is possible */
> indio_dev->modes |= INDIO_BUFFER_TRIGGERED;
> diff --git a/drivers/iio/iio_core_trigger.h
> b/drivers/iio/iio_core_trigger.h
> index e59fe2f36bbb..9d1a92cc6480 100644
> --- a/drivers/iio/iio_core_trigger.h
> +++ b/drivers/iio/iio_core_trigger.h
> @@ -18,6 +18,12 @@ void iio_device_register_trigger_consumer(struct
> iio_dev *indio_dev);
> **/
> void iio_device_unregister_trigger_consumer(struct iio_dev *indio_dev);
>
> +
> +int iio_trigger_attach_poll_func(struct iio_trigger *trig,
> + struct iio_poll_func *pf);
> +int iio_trigger_detach_poll_func(struct iio_trigger *trig,
> + struct iio_poll_func *pf);
> +
> #else
>
> /**
> @@ -37,4 +43,15 @@ static void
> iio_device_unregister_trigger_consumer(struct iio_dev *indio_dev)
> {
> }
>
> +static inline int iio_trigger_attach_poll_func(struct iio_trigger *trig,
> +struct iio_poll_func *pf)
> +{
> + return 0;
> +}
> +static inline int iio_trigger_detach_poll_func(struct iio_trigger *trig,
> +struct iio_poll_func *pf)
> +{
> + return 0;
> +}
> +
> #endif /* CONFIG_TRIGGER_CONSUMER */
> diff --git a/drivers/iio/industrialio-buffer.c
> b/drivers/iio/industrialio-buffer.c
> index ec4f531994fa..88d756107fb2 100644
> --- a/drivers/iio/industrialio-buffer.c
> +++ b/drivers/iio/industrialio-buffer.c
> @@ -20,6 +20,7 @@
>
> #include
> #include "iio_core.h"
> +#include "iio_core_trigger.h"
> #include
> #include
> #include
> @@ -972,6 +973,13 @@ static int iio_enable_buffers(struct iio_dev
> *indio_dev,
> }
> }
>
> + if (indio_dev->currentmode == INDIO_BUFFER_TRIGGERED) {
> + ret = iio_trigger_attach_poll_func(indio_dev->trig,
> +indio_dev->pollfunc);
> + if (ret)
> + goto err_disable_buffers;
> + }
> +
I'm wondering what happened here, or whether I was on some other planet, or
some other universe where this was correct, but this part looks wrong.
This should be called before the "indio_dev->setup_ops->postenable" call
And similarly iio_trigger_detach_poll_func() should be called after the
"indio_dev->setup_ops->predisable" call.
This looks clearly like my fault.
And it looks like I sent it like this from the start
At this point, what's the way to fix this?
Re-send or send a fix?
I noticed this while sync-ing the ADI tree with upstream and comparing and
spent a bit looking at this.
> return 0;
>
> err_disable_buffers:
> @@ -998,6 +1006,11 @@ static int iio_disable_buffers(struct iio_dev
> *indio_dev)
> if (list_empty(_dev->buffer_list))
> return 0;
>
> + if (indio_dev->currentmode == INDIO_BUFFER_TRIGGERED) {
> + iio_trigger_detach_poll_func(indio_dev->trig,
> + indio_dev->pollfunc);
> + }
> +
> /*
>* If things go wrong
Re: [PATCH v4 2/2] iio: adc: ad7192: move ad7192_of_match table closer to the end of the file
On Wed, 2020-04-15 at 08:58 +0300, Alexandru Ardelean wrote:
> The change is more cosmetic. There is no need to reference this table in
> the probe function since 'of_device_get_match_data' is used, which
> obtains
> this information from the driver object.
This looks like it could be applied now.
The iio/testing branch seems to have patch [1/2].
Thanks
Alex
>
> Signed-off-by: Alexandru Ardelean
> ---
> drivers/iio/adc/ad7192.c | 18 +-
> 1 file changed, 9 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/iio/adc/ad7192.c b/drivers/iio/adc/ad7192.c
> index 1431f555daa6..fd89a5115c55 100644
> --- a/drivers/iio/adc/ad7192.c
> +++ b/drivers/iio/adc/ad7192.c
> @@ -908,15 +908,6 @@ static int ad7192_channels_config(struct iio_dev
> *indio_dev)
> return 0;
> }
>
> -static const struct of_device_id ad7192_of_match[] = {
> - { .compatible = "adi,ad7190", .data =
> _chip_info_tbl[ID_AD7190] },
> - { .compatible = "adi,ad7192", .data =
> _chip_info_tbl[ID_AD7192] },
> - { .compatible = "adi,ad7193", .data =
> _chip_info_tbl[ID_AD7193] },
> - { .compatible = "adi,ad7195", .data =
> _chip_info_tbl[ID_AD7195] },
> - {}
> -};
> -MODULE_DEVICE_TABLE(of, ad7192_of_match);
> -
> static int ad7192_probe(struct spi_device *spi)
> {
> struct ad7192_state *st;
> @@ -1050,6 +1041,15 @@ static int ad7192_remove(struct spi_device *spi)
> return 0;
> }
>
> +static const struct of_device_id ad7192_of_match[] = {
> + { .compatible = "adi,ad7190", .data =
> _chip_info_tbl[ID_AD7190] },
> + { .compatible = "adi,ad7192", .data =
> _chip_info_tbl[ID_AD7192] },
> + { .compatible = "adi,ad7193", .data =
> _chip_info_tbl[ID_AD7193] },
> + { .compatible = "adi,ad7195", .data =
> _chip_info_tbl[ID_AD7195] },
> + {}
> +};
> +MODULE_DEVICE_TABLE(of, ad7192_of_match);
> +
> static struct spi_driver ad7192_driver = {
> .driver = {
> .name = "ad7192",
Re: [PATCH v8 2/6] IIO: Ingenic JZ47xx: Error check clk_enable calls.
On Sun, 2020-07-12 at 13:02 +0100, Jonathan Cameron wrote:
> On Thu, 9 Jul 2020 17:21:56 +0200
> Artur Rojek wrote:
>
> > Introduce error checks for the clk_enable calls used in this driver.
> > As part of the changes, move clk_enable/clk_disable calls out of
> > ingenic_adc_set_config and into respective logic of its callers.
> >
> > Signed-off-by: Artur Rojek
> > Tested-by: Paul Cercueil
> Applied.
>
> Thanks,
>
> Jonathan
>
> > ---
> >
> > Changes:
> >
> > v6: new patch
> >
> > v7: no change
> >
> > v8: move `clk_disable` outside the lock
> >
> > drivers/iio/adc/ingenic-adc.c | 25 +
> > 1 file changed, 21 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/iio/adc/ingenic-adc.c b/drivers/iio/adc/ingenic-
> > adc.c
> > index 39c0a609fc94..c1946a9f1cca 100644
> > --- a/drivers/iio/adc/ingenic-adc.c
> > +++ b/drivers/iio/adc/ingenic-adc.c
> > @@ -73,7 +73,6 @@ static void ingenic_adc_set_config(struct ingenic_adc
> > *adc,
> > {
> > uint32_t cfg;
> >
> > - clk_enable(adc->clk);
> > mutex_lock(>lock);
> >
> > cfg = readl(adc->base + JZ_ADC_REG_CFG) & ~mask;
> > @@ -81,7 +80,6 @@ static void ingenic_adc_set_config(struct ingenic_adc
> > *adc,
> > writel(cfg, adc->base + JZ_ADC_REG_CFG);
> >
> > mutex_unlock(>lock);
> > - clk_disable(adc->clk);
> > }
> >
> > static void ingenic_adc_enable(struct ingenic_adc *adc,
> > @@ -124,6 +122,8 @@ static int ingenic_adc_write_raw(struct iio_dev
> > *iio_dev,
> > long m)
> > {
> > struct ingenic_adc *adc = iio_priv(iio_dev);
> > + struct device *dev = iio_dev->dev.parent;
> > + int ret;
> >
> > switch (m) {
> > case IIO_CHAN_INFO_SCALE:
> > @@ -131,6 +131,14 @@ static int ingenic_adc_write_raw(struct iio_dev
> > *iio_dev,
> > case INGENIC_ADC_BATTERY:
> > if (!adc->soc_data->battery_vref_mode)
> > return -EINVAL;
> > +
> > + ret = clk_enable(adc->clk);
> > + if (ret) {
> > + dev_err(dev, "Failed to enable clock:
> > %d\n",
> > + ret);
> > + return ret;
> > + }
> > +
> > if (val > JZ_ADC_BATTERY_LOW_VREF) {
> > ingenic_adc_set_config(adc,
> >JZ_ADC_REG_CFG_BAT_M
> > D,
> > @@ -142,6 +150,9 @@ static int ingenic_adc_write_raw(struct iio_dev
> > *iio_dev,
> >JZ_ADC_REG_CFG_BAT_M
> > D);
> > adc->low_vref_mode = true;
> > }
> > +
> > + clk_disable(adc->clk);
> > +
> > return 0;
> > default:
> > return -EINVAL;
> > @@ -317,6 +328,13 @@ static int ingenic_adc_read_chan_info_raw(struct
> > ingenic_adc *adc,
> > int *val)
> > {
> > int bit, ret, engine = (chan->channel == INGENIC_ADC_BATTERY);
> > + struct device *dev = iio_priv_to_dev(adc)->dev.parent;
This uses iio_priv_to_dev(), which should be removed [if it hasn't been
already].
Also, with the iio_dev_opaque struct/type, using the iio_priv_to_dev()
helper shouldn't work, or should give undefined behavior, as the offset to
the private data should be matched against iio_dev_opaque (and not
iio_dev).
Looking at this code, it looks like ingenic_adc_read_chan_info_raw() can
take an 'indio_dev' reference and obtain the private information via
iio_priv()
Maybe [for some] there's a question as to why iio_priv_to_dev() is being
removed.
The answer is: because the iio_dev_opaque struct/type was introduced to
hide some iio_dev [INTERN] fields; the main reason for hiding them [aside
from good coding practice, and because they belong to the IIO framework] is
to not have to review new drivers being copied/adapted from old drivers.
Naturally, the iio_priv_to_dev() could have been kept around [in a reworked
form], but it didn't make much sense, since most users of iio_priv_to_dev()
could access a reference to indio_dev without much/any hassle.
> > +
> > + ret = clk_enable(adc->clk);
> > + if (ret) {
> > + dev_err(dev, "Failed to enable clock: %d\n", ret);
> > + return ret;
> > + }
> >
> > /* We cannot sample AUX/AUX2 in parallel. */
> > mutex_lock(>aux_lock);
> > @@ -325,7 +343,6 @@ static int ingenic_adc_read_chan_info_raw(struct
> > ingenic_adc *adc,
> > ingenic_adc_set_config(adc, JZ_ADC_REG_CFG_AUX_MD, bit);
> > }
> >
> > - clk_enable(adc->clk);
> > ret = ingenic_adc_capture(adc, engine);
> > if (ret)
> > goto out;
> > @@ -342,8 +359,8 @@ static int ingenic_adc_read_chan_info_raw(struct
> > ingenic_adc *adc,
> >
> > ret = IIO_VAL_INT;
> > out:
> > - clk_disable(adc->clk);
> > mutex_unlock(>aux_lock);
> >
Re: [PATCH 1/3] iio: dac: ad5592r: fix unbalanced mutex unlocks in ad5592r_read_raw()
On Mon, 2020-07-06 at 14:02 +0300, Alexandru Ardelean wrote:
> [External]
>
> There are 2 exit paths where the lock isn't held, but try to unlock the
> mutex when exiting. In these places we should just return from the
> function.
>
> A neater approach would be to cleanup the ad5592r_read_raw(), but that
> would make this patch more difficult to backport to stable versions.
>
I was a bit too hasty with this.
Apologies.
I'd like to add a tag here.
Reported-by: Charles Stanhope
> Fixes 56ca9db862bf3: ("iio: dac: Add support for the AD5592R/AD5593R
> ADCs/DACs")
> Signed-off-by: Alexandru Ardelean
> ---
> drivers/iio/dac/ad5592r-base.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/iio/dac/ad5592r-base.c b/drivers/iio/dac/ad5592r-
> base.c
> index 5c4e5ff70380..cc4875660a69 100644
> --- a/drivers/iio/dac/ad5592r-base.c
> +++ b/drivers/iio/dac/ad5592r-base.c
> @@ -413,7 +413,7 @@ static int ad5592r_read_raw(struct iio_dev *iio_dev,
> s64 tmp = *val * (3767897513LL / 25LL);
> *val = div_s64_rem(tmp, 10LL, val2);
>
> - ret = IIO_VAL_INT_PLUS_MICRO;
> + return IIO_VAL_INT_PLUS_MICRO;
> } else {
> int mult;
>
> @@ -444,7 +444,7 @@ static int ad5592r_read_raw(struct iio_dev *iio_dev,
> ret = IIO_VAL_INT;
> break;
> default:
> - ret = -EINVAL;
> + return -EINVAL;
> }
>
> unlock:
Re: [PATCH v4 4/7] iio: core: move debugfs data on the private iio dev info
On Wed, 2020-07-01 at 19:42 +0100, Jonathan Cameron wrote:
> [External]
>
> On Tue, 30 Jun 2020 04:58:06 +
> "Ardelean, Alexandru" wrote:
>
> > On Tue, 2020-06-30 at 07:57 +0300, Alexandru Ardelean wrote:
> > > This change moves all iio_dev debugfs fields to the iio_dev_priv
> > > object.
> > > It's not the biggest advantage yet (to the whole thing of
> > > abstractization)
> > > but it's a start.
> > >
> > > The iio_get_debugfs_dentry() function (which is moved in
> > > industrialio-core.c) needs to also be guarded against the
> > > CONFIG_DEBUG_FS
> > > symbol, when it isn't defined. We do want to keep the inline
> > > definition
> > > in
> > > the iio.h header, so that the compiler can better infer when to
> > > compile
> > > out
> > > debugfs code that is related to the IIO debugfs directory.
> > >
> >
> > Well, pretty much only this patch changed since V3.
> > I thought about maybe re-doing just this patch, then I thought maybe
> > I'd
> > get a minor complaint that I should re-send the series.
> >
> > Either way, I prefer a complaint on this V4 series-re-send than if I
> > were
> > to have re-sent just this patch.
>
> Either way worked.
>
> However this doesn't pass my basic build test. Config condition
> is reversed.
>
> Fixed up and pushed out as testing.
Sorry for the goof.
I tested with make allmodconfig.
Maybe I didn't pay attention somewhere.
>
>
> Jonathan
>
> >
> > > Signed-off-by: Alexandru Ardelean
> > > ---
> > > drivers/iio/industrialio-core.c | 46 +++--
> > >
> > > include/linux/iio/iio-opaque.h | 10 +++
> > > include/linux/iio/iio.h | 13 +-
> > > 3 files changed, 44 insertions(+), 25 deletions(-)
> > >
> > > diff --git a/drivers/iio/industrialio-core.c
> > > b/drivers/iio/industrialio-
> > > core.c
> > > index 27005ba4d09c..64174052641a 100644
> > > --- a/drivers/iio/industrialio-core.c
> > > +++ b/drivers/iio/industrialio-core.c
> > > @@ -165,6 +165,19 @@ static const char * const
> > > iio_chan_info_postfix[] =
> > > {
> > > [IIO_CHAN_INFO_THERMOCOUPLE_TYPE] = "thermocouple_type",
> > > };
> > >
> > > +#if !defined(CONFIG_DEBUG_FS)
>
> Don't we want this if it is defined.
>
> > > +/**
> > > + * There's also a CONFIG_DEBUG_FS guard in include/linux/iio/iio.h
> > > for
> > > + * iio_get_debugfs_dentry() to make it inline if CONFIG_DEBUG_FS is
> > > undefined
> > > + */
> > > +struct dentry *iio_get_debugfs_dentry(struct iio_dev *indio_dev)
> > > +{
> > > + struct iio_dev_opaque *iio_dev_opaque =
> > > to_iio_dev_opaque(indio_dev);
> > > + return iio_dev_opaque->debugfs_dentry;
> > > +}
> > > +EXPORT_SYMBOL_GPL(iio_get_debugfs_dentry);
> > > +#endif
> > > +
> > > /**
> > > * iio_find_channel_from_si() - get channel from its scan index
> > > * @indio_dev: device
> > > @@ -308,35 +321,37 @@ static ssize_t iio_debugfs_read_reg(struct file
> > > *file, char __user *userbuf,
> > > size_t count, loff_t *ppos)
> > > {
> > > struct iio_dev *indio_dev = file->private_data;
> > > + struct iio_dev_opaque *iio_dev_opaque =
> > > to_iio_dev_opaque(indio_dev);
> > > unsigned val = 0;
> > > int ret;
> > >
> > > if (*ppos > 0)
> > > return simple_read_from_buffer(userbuf, count, ppos,
> > > -indio_dev->read_buf,
> > > -indio_dev->read_buf_len);
> > > +iio_dev_opaque->read_buf,
> > > +iio_dev_opaque-
> > > > read_buf_len);
> > >
> > > ret = indio_dev->info->debugfs_reg_access(indio_dev,
> > > - indio_dev-
> > > > cached_reg_addr,
> > > + iio_dev_opaque-
> > > > cached_reg_addr,
> > > 0, );
> > > if (ret) {
> > > dev_err(indio_dev->dev.parent, "%s: read failed\n",
> > > __func__);
> > > return ret;
> > &
Re: [PATCH] spi: Avoid setting the chip select if we don't need to
On Mon, 2020-06-29 at 16:41 -0700, Douglas Anderson wrote:
> [External]
>
> On some SPI controllers (like spi-geni-qcom) setting the chip select
> is a heavy operation. For instance on spi-geni-qcom, with the current
> code, is was measured as taking upwards of 20 us. Even on SPI
> controllers that aren't as heavy, setting the chip select is at least
> something like a MMIO operation over some peripheral bus which isn't
> as fast as a RAM access.
>
> While it would be good to find ways to mitigate problems like this in
> the drivers for those SPI controllers, it can also be noted that the
> SPI framework could also help out. Specifically, in some situations,
> we can see the SPI framework calling the driver's set_cs() with the
> same parameter several times in a row. This is specifically observed
> when looking at the way the Chrome OS EC SPI driver (cros_ec_spi)
> works but other drivers likely trip it to some extent.
>
> Let's solve this by caching the chip select state in the core and only
> calling into the controller if there was a change. We check not only
> the "enable" state but also the chip select mode (active high or
> active low) since controllers may care about both the mode and the
> enable flag in their callback.
I think checkpatch suggested I be added here, since I touched some parts of
the delay/timings code.
> Signed-off-by: Douglas Anderson
> ---
>
> drivers/spi/spi.c | 11 +++
> include/linux/spi/spi.h | 4
> 2 files changed, 15 insertions(+)
>
> diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c
> index 6fa56590bba2..d4ba723a30da 100644
> --- a/drivers/spi/spi.c
> +++ b/drivers/spi/spi.c
> @@ -778,6 +778,17 @@ static void spi_set_cs(struct spi_device *spi, bool
> enable)
> {
> bool enable1 = enable;
>
> + /*
> + * Avoid calling into the driver (or doing delays) if the chip
> select
> + * isn't actually changing from the last time this was called.
> + */
> + if ((spi->controller->last_cs_enable == enable) &&
> + (spi->controller->last_cs_mode_high == (spi->mode &
> SPI_CS_HIGH)))
> + return;
> +
> + spi->controller->last_cs_enable = enable;
> + spi->controller->last_cs_mode_high = spi->mode & SPI_CS_HIGH;
> +
I don't feel like this is the best approach for the SPI CS handling,
because it's pretty difficult to guess the last CS state, and whether this
return would cause other weirder issues [like not toggling CS when it
should].
Maybe a question is: when should this CS be toggled [or not]?
Is it between 2 calls of spi_transfer_one_message() or between 2
spi_transfers?
Or, is "xfer->cs_change == 1" where it shouldn't be?
I think, there are some ways to not toggle CS between some of these, or if
there aren't, some controls could be added/proposed to avoid toggling CS,
vs doing caching.
> if (!spi->controller->set_cs_timing) {
> if (enable1)
> spi_delay_exec(>controller->cs_setup, NULL);
> diff --git a/include/linux/spi/spi.h b/include/linux/spi/spi.h
> index b4917df79637..0e67a9a3a1d3 100644
> --- a/include/linux/spi/spi.h
> +++ b/include/linux/spi/spi.h
> @@ -368,6 +368,8 @@ static inline void spi_unregister_driver(struct
> spi_driver *sdrv)
> * @cur_msg_prepared: spi_prepare_message was called for the currently
> *in-flight message
> * @cur_msg_mapped: message has been mapped for DMA
> + * @last_cs_enable: was enable true on the last call to set_cs.
> + * @last_cs_mode_high: was (mode & SPI_CS_HIGH) true on the last call to
> set_cs.
> * @xfer_completion: used by core transfer_one_message()
> * @busy: message pump is busy
> * @running: message pump is running
> @@ -604,6 +606,8 @@ struct spi_controller {
> boolauto_runtime_pm;
> boolcur_msg_prepared;
> boolcur_msg_mapped;
> + boollast_cs_enable;
> + boollast_cs_mode_high;
> boolfallback;
> struct completion xfer_completion;
> size_t max_dma_len;
Re: [PATCH v4 4/7] iio: core: move debugfs data on the private iio dev info
On Tue, 2020-06-30 at 07:57 +0300, Alexandru Ardelean wrote:
> This change moves all iio_dev debugfs fields to the iio_dev_priv object.
> It's not the biggest advantage yet (to the whole thing of
> abstractization)
> but it's a start.
>
> The iio_get_debugfs_dentry() function (which is moved in
> industrialio-core.c) needs to also be guarded against the CONFIG_DEBUG_FS
> symbol, when it isn't defined. We do want to keep the inline definition
> in
> the iio.h header, so that the compiler can better infer when to compile
> out
> debugfs code that is related to the IIO debugfs directory.
>
Well, pretty much only this patch changed since V3.
I thought about maybe re-doing just this patch, then I thought maybe I'd
get a minor complaint that I should re-send the series.
Either way, I prefer a complaint on this V4 series-re-send than if I were
to have re-sent just this patch.
> Signed-off-by: Alexandru Ardelean
> ---
> drivers/iio/industrialio-core.c | 46 +++--
> include/linux/iio/iio-opaque.h | 10 +++
> include/linux/iio/iio.h | 13 +-
> 3 files changed, 44 insertions(+), 25 deletions(-)
>
> diff --git a/drivers/iio/industrialio-core.c b/drivers/iio/industrialio-
> core.c
> index 27005ba4d09c..64174052641a 100644
> --- a/drivers/iio/industrialio-core.c
> +++ b/drivers/iio/industrialio-core.c
> @@ -165,6 +165,19 @@ static const char * const iio_chan_info_postfix[] =
> {
> [IIO_CHAN_INFO_THERMOCOUPLE_TYPE] = "thermocouple_type",
> };
>
> +#if !defined(CONFIG_DEBUG_FS)
> +/**
> + * There's also a CONFIG_DEBUG_FS guard in include/linux/iio/iio.h for
> + * iio_get_debugfs_dentry() to make it inline if CONFIG_DEBUG_FS is
> undefined
> + */
> +struct dentry *iio_get_debugfs_dentry(struct iio_dev *indio_dev)
> +{
> + struct iio_dev_opaque *iio_dev_opaque =
> to_iio_dev_opaque(indio_dev);
> + return iio_dev_opaque->debugfs_dentry;
> +}
> +EXPORT_SYMBOL_GPL(iio_get_debugfs_dentry);
> +#endif
> +
> /**
> * iio_find_channel_from_si() - get channel from its scan index
> * @indio_dev: device
> @@ -308,35 +321,37 @@ static ssize_t iio_debugfs_read_reg(struct file
> *file, char __user *userbuf,
> size_t count, loff_t *ppos)
> {
> struct iio_dev *indio_dev = file->private_data;
> + struct iio_dev_opaque *iio_dev_opaque =
> to_iio_dev_opaque(indio_dev);
> unsigned val = 0;
> int ret;
>
> if (*ppos > 0)
> return simple_read_from_buffer(userbuf, count, ppos,
> -indio_dev->read_buf,
> -indio_dev->read_buf_len);
> +iio_dev_opaque->read_buf,
> +iio_dev_opaque-
> >read_buf_len);
>
> ret = indio_dev->info->debugfs_reg_access(indio_dev,
> - indio_dev-
> >cached_reg_addr,
> + iio_dev_opaque-
> >cached_reg_addr,
> 0, );
> if (ret) {
> dev_err(indio_dev->dev.parent, "%s: read failed\n",
> __func__);
> return ret;
> }
>
> - indio_dev->read_buf_len = snprintf(indio_dev->read_buf,
> -sizeof(indio_dev->read_buf),
> -"0x%X\n", val);
> + iio_dev_opaque->read_buf_len = snprintf(iio_dev_opaque->read_buf,
> + sizeof(iio_dev_opaque-
> >read_buf),
> + "0x%X\n", val);
>
> return simple_read_from_buffer(userbuf, count, ppos,
> -indio_dev->read_buf,
> -indio_dev->read_buf_len);
> +iio_dev_opaque->read_buf,
> +iio_dev_opaque->read_buf_len);
> }
>
> static ssize_t iio_debugfs_write_reg(struct file *file,
>const char __user *userbuf, size_t count, loff_t
> *ppos)
> {
> struct iio_dev *indio_dev = file->private_data;
> + struct iio_dev_opaque *iio_dev_opaque =
> to_iio_dev_opaque(indio_dev);
> unsigned reg, val;
> char buf[80];
> int ret;
> @@ -351,10 +366,10 @@ static ssize_t iio_debugfs_write_reg(struct file
> *file,
>
> switch (ret) {
> case 1:
> - indio_dev->cached_reg_addr = reg;
> + iio_dev_opaque->cached_reg_addr = reg;
> break;
> case 2:
> - indio_dev->cached_reg_addr = reg;
> + iio_dev_opaque->cached_reg_addr = reg;
> ret = indio_dev->info->debugfs_reg_access(indio_dev, reg,
> val, NULL);
> if (ret) {
> @@ -378,23 +393,28 @@ static const struct file_operations
> iio_debugfs_reg_fops = {
>
Re: [PATCH v3 2/7] iio: core: wrap IIO device into an iio_dev_opaque object
On Sat, 2020-06-27 at 17:40 +0100, Jonathan Cameron wrote:
> On Sun, 21 Jun 2020 15:33:40 +0300
> Alexandru Ardelean wrote:
>
> > There are plenty of bad designs we want to discourage or not have to
> > review
> > manually usually about accessing private (marked as [INTERN]) fields of
> > 'struct iio_dev'.
> >
> > Sometimes users copy drivers that are not always the best examples.
> >
> > A better idea is to hide those fields into the framework.
> > For 'struct iio_dev' this is a 'struct iio_dev_opaque' which wraps a
> > public
> > 'struct iio_dev' object.
> >
> > In the next series, some fields will be moved to this new struct, each
> > with
> > it's own rework.
> >
> > This rework will not be complete-able for a while, as many fields need
> > some
> > drivers to be reworked in order to finalize them (e.g. 'indio_dev-
> > >mlock').
> >
> > But some fields can already be moved, and in time, all of them may get
> > there (in the 'struct iio_dev_opaque' object).
> >
> > Since a lot of drivers also call 'iio_priv()', in order to preserve
> > fast-paths (where this matters), the public iio_dev object will have a
> > 'priv' field that will have the pointer to the private information
> > already
> > computed. The reference returned by this field should be guaranteed to
> > be
> > cacheline aligned.
> >
> > As for the 'iio_priv_to_dev()' helper, this needs to be hidden away.
> > There
> > aren't many users of this helper, and arguably drivers shouldn't need
> > to
> > use it in any fast-paths, as they can maintain a reference to the IIO
> > device.
> Dropped this bit as previous patch deleted iio_priv_to_dev :)
Right.
My bad.
> > The opaque parts will be moved into the 'include/linux/iio/iio-
> > opaque.h'
> > header. Should the hidden information be required for some debugging or
> > some special needs, it can be made available via this header.
> > Otherwise, only the IIO core files should include this file.
> >
> > Signed-off-by: Alexandru Ardelean
>
> I've applied this as it stands, but I wonder if we should combine
> this with the existing iio-core.h header.
>
> Can do that later if it makes sense.
Initially, I had thought about putting all of the iio-opaque.h code in iio-
core.h, and limit the include range in drivers/iio, but then thought maybe
leave it in 'include/linux/iio/iio-opaque.h'. That way, it's probably a bit
easier for some debugging.
I am still not sure which direction is best.
But, we can move iio-core.h into iio-opaque.h (or the other way around).
>
> Jonathan
>
>
>
> > ---
> > drivers/iio/industrialio-core.c | 19 +--
> > include/linux/iio/iio-opaque.h | 17 +
> > include/linux/iio/iio.h | 6 +-
> > 3 files changed, 35 insertions(+), 7 deletions(-)
> > create mode 100644 include/linux/iio/iio-opaque.h
> >
> > diff --git a/drivers/iio/industrialio-core.c
> > b/drivers/iio/industrialio-core.c
> > index 75661661aaba..33e2953cf021 100644
> > --- a/drivers/iio/industrialio-core.c
> > +++ b/drivers/iio/industrialio-core.c
> > @@ -25,6 +25,7 @@
> > #include
> > #include
> > #include
> > +#include
> > #include "iio_core.h"
> > #include "iio_core_trigger.h"
> > #include
> > @@ -1473,6 +1474,8 @@ static void iio_device_unregister_sysfs(struct
> > iio_dev *indio_dev)
> > static void iio_dev_release(struct device *device)
> > {
> > struct iio_dev *indio_dev = dev_to_iio_dev(device);
> > + struct iio_dev_opaque *iio_dev_opaque =
> > to_iio_dev_opaque(indio_dev);
> > +
> > if (indio_dev->modes & INDIO_ALL_TRIGGERED_MODES)
> > iio_device_unregister_trigger_consumer(indio_dev);
> > iio_device_unregister_eventset(indio_dev);
> > @@ -1481,7 +1484,7 @@ static void iio_dev_release(struct device
> > *device)
> > iio_buffer_put(indio_dev->buffer);
> >
> > ida_simple_remove(_ida, indio_dev->id);
> > - kfree(indio_dev);
> > + kfree(iio_dev_opaque);
> > }
> >
> > struct device_type iio_device_type = {
> > @@ -1495,10 +1498,11 @@ struct device_type iio_device_type = {
> > **/
> > struct iio_dev *iio_device_alloc(struct device *parent, int
> > sizeof_priv)
> > {
> > + struct iio_dev_opaque *iio_dev_opaque;
> > struct iio_dev *dev;
> > size_t alloc_size;
> >
> > - alloc_size = sizeof(struct iio_dev);
> > + alloc_size = sizeof(struct iio_dev_opaque);
> > if (sizeof_priv) {
> > alloc_size = ALIGN(alloc_size, IIO_ALIGN);
> > alloc_size += sizeof_priv;
> > @@ -1506,11 +1510,14 @@ struct iio_dev *iio_device_alloc(struct device
> > *parent, int sizeof_priv)
> > /* ensure 32-byte alignment of whole construct ? */
> > alloc_size += IIO_ALIGN - 1;
> >
> > - dev = kzalloc(alloc_size, GFP_KERNEL);
> > - if (!dev)
> > + iio_dev_opaque = kzalloc(alloc_size, GFP_KERNEL);
> > + if (!iio_dev_opaque)
> > return NULL;
> >
> > - dev->dev.parent = parent;
> > + dev = _dev_opaque->indio_dev;
> > + dev->priv = (char
Re: [PATCH] iio: at91_adc: remove usage of iio_priv_to_dev() helper
On Sun, 2020-05-31 at 15:42 +0100, Jonathan Cameron wrote:
> [External]
>
> On Mon, 25 May 2020 13:25:13 +0300
> Alexandru Ardelean wrote:
>
> > We may want to get rid of the iio_priv_to_dev() helper. The reason is
> > that
> > we will hide some of the members of the iio_dev structure (to prevent
> > drivers from accessing them directly), and that will also mean hiding
> > the
> > implementation of the iio_priv_to_dev() helper inside the IIO core.
> >
> > Hiding the implementation of iio_priv_to_dev() implies that some fast-
> > paths
> > may not be fast anymore, so a general idea is to try to get rid of the
> > iio_priv_to_dev() altogether.
> > The iio_priv() helper won't be affected by the rework, as the iio_dev
> > struct will keep a reference to the private information.
> >
> > For this driver, not using iio_priv_to_dev(), means reworking some
> > paths to
> > pass the iio device and using iio_priv() to access the private
> > information.
> >
> > Signed-off-by: Alexandru Ardelean
> Looks good to me. Will leave it a bit longer though to potentially
> get some people more familiar with the driver to sanity check it.
>
> Poke me after the usual couple of weeks if I seem to have lost it
> down the back of the sofa.
>
ping on this
> Thanks,
>
> Jonathan
>
> > ---
> > drivers/iio/adc/at91_adc.c | 30 +++---
> > 1 file changed, 15 insertions(+), 15 deletions(-)
> >
> > diff --git a/drivers/iio/adc/at91_adc.c b/drivers/iio/adc/at91_adc.c
> > index 0368b6dc6d60..896af58e88bc 100644
> > --- a/drivers/iio/adc/at91_adc.c
> > +++ b/drivers/iio/adc/at91_adc.c
> > @@ -287,13 +287,13 @@ static void handle_adc_eoc_trigger(int irq,
> > struct iio_dev *idev)
> > }
> > }
> >
> > -static int at91_ts_sample(struct at91_adc_state *st)
> > +static int at91_ts_sample(struct iio_dev *idev)
> > {
> > + struct at91_adc_state *st = iio_priv(idev);
> > unsigned int xscale, yscale, reg, z1, z2;
> > unsigned int x, y, pres, xpos, ypos;
> > unsigned int rxp = 1;
> > unsigned int factor = 1000;
> > - struct iio_dev *idev = iio_priv_to_dev(st);
> >
> > unsigned int xyz_mask_bits = st->res;
> > unsigned int xyz_mask = (1 << xyz_mask_bits) - 1;
> > @@ -449,7 +449,7 @@ static irqreturn_t at91_adc_9x5_interrupt(int irq,
> > void *private)
> >
> > if (status & AT91_ADC_ISR_PENS) {
> > /* validate data by pen contact */
> > - at91_ts_sample(st);
> > + at91_ts_sample(idev);
> > } else {
> > /* triggered by event that is no pen contact, just
> > read
> > * them to clean the interrupt and discard all.
> > @@ -737,10 +737,10 @@ static int at91_adc_read_raw(struct iio_dev
> > *idev,
> > return -EINVAL;
> > }
> >
> > -static int at91_adc_of_get_resolution(struct at91_adc_state *st,
> > +static int at91_adc_of_get_resolution(struct iio_dev *idev,
> > struct platform_device *pdev)
> > {
> > - struct iio_dev *idev = iio_priv_to_dev(st);
> > + struct at91_adc_state *st = iio_priv(idev);
> > struct device_node *np = pdev->dev.of_node;
> > int count, i, ret = 0;
> > char *res_name, *s;
> > @@ -866,10 +866,10 @@ static int at91_adc_probe_dt_ts(struct
> > device_node *node,
> > }
> > }
> >
> > -static int at91_adc_probe_dt(struct at91_adc_state *st,
> > +static int at91_adc_probe_dt(struct iio_dev *idev,
> > struct platform_device *pdev)
> > {
> > - struct iio_dev *idev = iio_priv_to_dev(st);
> > + struct at91_adc_state *st = iio_priv(idev);
> > struct device_node *node = pdev->dev.of_node;
> > struct device_node *trig_node;
> > int i = 0, ret;
> > @@ -910,7 +910,7 @@ static int at91_adc_probe_dt(struct at91_adc_state
> > *st,
> > }
> > st->vref_mv = prop;
> >
> > - ret = at91_adc_of_get_resolution(st, pdev);
> > + ret = at91_adc_of_get_resolution(idev, pdev);
> > if (ret)
> > goto error_ret;
> >
> > @@ -1010,9 +1010,9 @@ static void atmel_ts_close(struct input_dev *dev)
> > at91_adc_writel(st, AT91_ADC_IDR, AT91RL_ADC_IER_PEN);
> > }
> >
> > -static int at91_ts_hw_init(struct at91_adc_state *st, u32 adc_clk_khz)
> > +static int at91_ts_hw_init(struct iio_dev *idev, u32 adc_clk_khz)
> > {
> > - struct iio_dev *idev = iio_priv_to_dev(st);
> > + struct at91_adc_state *st = iio_priv(idev);
> > u32 reg = 0;
> > u32 tssctim = 0;
> > int i = 0;
> > @@ -1085,11 +1085,11 @@ static int at91_ts_hw_init(struct
> > at91_adc_state *st, u32 adc_clk_khz)
> > return 0;
> > }
> >
> > -static int at91_ts_register(struct at91_adc_state *st,
> > +static int at91_ts_register(struct iio_dev *idev,
> > struct platform_device *pdev)
> > {
> > + struct at91_adc_state *st = iio_priv(idev);
> > struct input_dev *input;
> > - struct iio_dev *idev = iio_priv_to_dev(st);
> > int ret;
> >
Re: [PATCH v2] iio: stm32-dfsdm-adc: remove usage of iio_priv_to_dev() helper
On Sun, 2020-05-31 at 15:45 +0100, Jonathan Cameron wrote:
> [External]
>
> On Mon, 25 May 2020 11:26:48 +0300
> Alexandru Ardelean wrote:
>
> > We may want to get rid of the iio_priv_to_dev() helper. The reason is
> > that
> > we will hide some of the members of the iio_dev structure (to prevent
> > drivers from accessing them directly), and that will also mean hiding
> > the
> > implementation of the iio_priv_to_dev() helper inside the IIO core.
> >
> > Hiding the implementation of iio_priv_to_dev() implies that some fast-
> > paths
> > may not be fast anymore, so a general idea is to try to get rid of the
> > iio_priv_to_dev() altogether.
> > The iio_priv() helper won't be affected by the rework, as the iio_dev
> > struct will keep a reference to the private information.
> >
> > For this driver, not using iio_priv_to_dev(), means reworking some
> > paths to
> > pass the iio device and using iio_priv() to access the private
> > information.
> >
> > Signed-off-by: Alexandru Ardelean
> Looks great. Will let it sit a little longer on list for others to
> review
> though.
>
ping on this :)
> Thanks,
>
> Jonathan
>
> > ---
> >
> > Changelog v1 -> v2:
> > * changed some paths to pass a reference to ref to iio device and
> > access
> > private state-struct via iio_priv()
> >
> > drivers/iio/adc/stm32-dfsdm-adc.c | 65 ---
> > 1 file changed, 33 insertions(+), 32 deletions(-)
> >
> > diff --git a/drivers/iio/adc/stm32-dfsdm-adc.c b/drivers/iio/adc/stm32-
> > dfsdm-adc.c
> > index 76a60d93fe23..03dfc0b6ba98 100644
> > --- a/drivers/iio/adc/stm32-dfsdm-adc.c
> > +++ b/drivers/iio/adc/stm32-dfsdm-adc.c
> > @@ -330,9 +330,9 @@ static int stm32_dfsdm_compute_all_osrs(struct
> > iio_dev *indio_dev,
> > return 0;
> > }
> >
> > -static int stm32_dfsdm_start_channel(struct stm32_dfsdm_adc *adc)
> > +static int stm32_dfsdm_start_channel(struct iio_dev *indio_dev)
> > {
> > - struct iio_dev *indio_dev = iio_priv_to_dev(adc);
> > + struct stm32_dfsdm_adc *adc = iio_priv(indio_dev);
> > struct regmap *regmap = adc->dfsdm->regmap;
> > const struct iio_chan_spec *chan;
> > unsigned int bit;
> > @@ -350,9 +350,9 @@ static int stm32_dfsdm_start_channel(struct
> > stm32_dfsdm_adc *adc)
> > return 0;
> > }
> >
> > -static void stm32_dfsdm_stop_channel(struct stm32_dfsdm_adc *adc)
> > +static void stm32_dfsdm_stop_channel(struct iio_dev *indio_dev)
> > {
> > - struct iio_dev *indio_dev = iio_priv_to_dev(adc);
> > + struct stm32_dfsdm_adc *adc = iio_priv(indio_dev);
> > struct regmap *regmap = adc->dfsdm->regmap;
> > const struct iio_chan_spec *chan;
> > unsigned int bit;
> > @@ -418,11 +418,11 @@ static void stm32_dfsdm_stop_filter(struct
> > stm32_dfsdm *dfsdm,
> >DFSDM_CR1_DFEN_MASK, DFSDM_CR1_DFEN(0));
> > }
> >
> > -static int stm32_dfsdm_filter_set_trig(struct stm32_dfsdm_adc *adc,
> > +static int stm32_dfsdm_filter_set_trig(struct iio_dev *indio_dev,
> >unsigned int fl_id,
> >struct iio_trigger *trig)
> > {
> > - struct iio_dev *indio_dev = iio_priv_to_dev(adc);
> > + struct stm32_dfsdm_adc *adc = iio_priv(indio_dev);
> > struct regmap *regmap = adc->dfsdm->regmap;
> > u32 jextsel = 0, jexten = STM32_DFSDM_JEXTEN_DISABLED;
> > int ret;
> > @@ -447,11 +447,11 @@ static int stm32_dfsdm_filter_set_trig(struct
> > stm32_dfsdm_adc *adc,
> > return 0;
> > }
> >
> > -static int stm32_dfsdm_channels_configure(struct stm32_dfsdm_adc *adc,
> > +static int stm32_dfsdm_channels_configure(struct iio_dev *indio_dev,
> > unsigned int fl_id,
> > struct iio_trigger *trig)
> > {
> > - struct iio_dev *indio_dev = iio_priv_to_dev(adc);
> > + struct stm32_dfsdm_adc *adc = iio_priv(indio_dev);
> > struct regmap *regmap = adc->dfsdm->regmap;
> > struct stm32_dfsdm_filter *fl = >dfsdm->fl_list[fl_id];
> > struct stm32_dfsdm_filter_osr *flo = >flo[0];
> > @@ -491,11 +491,11 @@ static int stm32_dfsdm_channels_configure(struct
> > stm32_dfsdm_adc *adc,
> > return 0;
> > }
> >
> > -static int stm32_dfsdm_filter_configure(struct stm32_dfsdm_adc *adc,
> > +static int stm32_dfsdm_filter_configure(struct iio_dev *indio_dev,
> > unsigned int fl_id,
> > struct iio_trigger *trig)
> > {
> > - struct iio_dev *indio_dev = iio_priv_to_dev(adc);
> > + struct stm32_dfsdm_adc *adc = iio_priv(indio_dev);
> > struct regmap *regmap = adc->dfsdm->regmap;
> > struct stm32_dfsdm_filter *fl = >dfsdm->fl_list[fl_id];
> > struct stm32_dfsdm_filter_osr *flo = >flo[fl->fast];
> > @@ -521,7 +521,7 @@ static int stm32_dfsdm_filter_configure(struct
> > stm32_dfsdm_adc *adc,
> > if (ret)
> > return ret;
> >
> > - ret = stm32_dfsdm_filter_set_trig(adc, fl_id,
Re: [PATCH v2 3/3] iio: remove iio_triggered_buffer_postenable()/iio_triggered_buffer_predisable()
On Thu, 2020-06-18 at 13:01 +, eugen.hris...@microchip.com wrote: > On 17.06.2020 16:52, Ardelean, Alexandru wrote: > > On Wed, 2020-06-17 at 13:37 +, eugen.hris...@microchip.com wrote: > > > [External] > > > > > > On 02.06.2020 11:54, Jonathan Cameron wrote: > > > > On Tue, 2 Jun 2020 07:50:23 + > > > > "Ardelean, Alexandru" wrote: > > > > > > > > > On Sun, 2020-05-31 at 16:40 +0100, Jonathan Cameron wrote: > > > > > > On Mon, 25 May 2020 14:38:55 +0300 > > > > > > Alexandru Ardelean wrote: > > > > > > > > > > > > > From: Lars-Peter Clausen > > > > > > > > > > > > > > This patch should be squashed into the first one, as the > > > > > > > first one is > > > > > > > breaking the build (intentionally) to make the IIO core files > > > > > > > easier > > > > > > > to > > > > > > > review. > > > > > > > > > > > > > > Signed-off-by: Lars-Peter Clausen > > > > > > > Signed-off-by: Alexandru Ardelean < > > > > > > > alexandru.ardel...@analog.com> > > > > > > > --- > > > > > > > > > > > > Friend poke. Version log? > > > > > > > > > > Version log is in the first patch. > > > > > I was wondering if I omitted it. > > > > > Seems, this time I didn't. But I admit, it probably would have > > > > > been better > > > > > here. > > > > Ah fair enough. That works fine if there is a cover letter but not > > > > so much just putting things in the first patch! > > > > > > Other than the wistful comment below (which I'm not expecting > > > > > > you to > > > > > > do anything about btw!) whole series looks good to me. > > > > > > > > > > > > These are obviously no functional changes (I think) so it's > > > > > > only really > > > > > > patch 2 that > > > > > > could do with more eyes and acks. > > > > > > > > > > > > Far as I can tell that case is fine as well because of the > > > > > > protections > > > > > > on being in the right mode, but more eyes on that would be > > > > > > great. > > > > > > > > > > > > So assuming that's fine, what commit message do you want me to > > > > > > use for > > > > > > the fused single patch? > > > > > > > > > > Commit message-wise: I think the message in the first commit > > > > > would be > > > > > mostly sufficient. > > > > > No idea what other description would be needed. > > > > > > > > > > So, maybe something like: > > > > > > > > > > --- > > > > > --- > > > > > All devices using a triggered buffer need to attach and detach > > > > > the trigger > > > > > to the device in order to properly work. Instead of doing this in > > > > > each and > > > > > every driver by hand move this into the core. > > > > > > > > > > At this point in time, all drivers should have been resolved to > > > > > attach/detach the poll-function in the same order. > > > > > > > > > > This patch removes all explicit calls of > > > > > iio_triggered_buffer_postenable() > > > > > & iio_triggered_buffer_predisable() in all drivers, since the > > > > > core handles > > > > > now the pollfunc attach/detach. > > > > > > > > > > The more peculiar change is for the 'at91-sama5d2_adc' driver, > > > > > since it's > > > > > not obvious that removing the hooks doesn't break anything** > > > > > --- > > > > > --- > > > > > > > > > > > > > Looks good. > > > > > > > > > ** for the comment about 'at91-sama5d2_adc', we really do need to > > > > > get some > > > > > testing; otherwise this risks breaking it. > > > > > > Hi, > > > >
Re: [PATCH] iio: at91-sama5d2_adc: remove usage of iio_priv_to_dev() helper
On Thu, 2020-06-18 at 12:47 +, eugen.hris...@microchip.com wrote: > [External] > > On 17.06.2020 17:02, Ardelean, Alexandru wrote: > > On Wed, 2020-06-17 at 13:25 +, eugen.hris...@microchip.com wrote: > > > On 31.05.2020 17:39, Jonathan Cameron wrote: > > > > > > > On Mon, 25 May 2020 13:53:41 +0300 > > > > Alexandru Ardelean wrote: > > > > > > > > > We may want to get rid of the iio_priv_to_dev() helper. The > > > > > reason is that > > > > > we will hide some of the members of the iio_dev structure (to > > > > > prevent > > > > > drivers from accessing them directly), and that will also mean > > > > > hiding the > > > > > implementation of the iio_priv_to_dev() helper inside the IIO > > > > > core. > > > > > > > > > > Hiding the implementation of iio_priv_to_dev() implies that some > > > > > fast- > > > > > paths > > > > > may not be fast anymore, so a general idea is to try to get rid > > > > > of the > > > > > iio_priv_to_dev() altogether. > > > > > The iio_priv() helper won't be affected by the rework, as the > > > > > iio_dev > > > > > struct will keep a reference to the private information. > > > > > > > > > > For this driver, not using iio_priv_to_dev(), means reworking > > > > > some paths > > > > > to > > > > > pass the iio device and using iio_priv() to access the private > > > > > information, > > > > > and also keeping a reference to the iio device for some quirky > > > > > paths. > > > > > > > > > > One [quirky] path is the at91_adc_workq_handler() which requires > > > > > the IIO > > > > > device & the state struct to push to buffers. > > > > > Since this requires the back-ref to the IIO device, the > > > > > at91_adc_touch_pos() also uses it. This simplifies the patch a > > > > > bit. The > > > > > information required in this function is mostly for debugging > > > > > purposes. > > > > > Replacing it with a reference to the IIO device would have been a > > > > > slightly > > > > > bigger change, which may not be worth it (for just the debugging > > > > > purpose > > > > > and given that we need the back-ref to the IIO device anyway). > > > > > > > > That workq is indeed quirky. This looks fine to me in general. > > > > I'll > > > > want an appropriate ack from the at91 side of things if possible so > > > > let's leave this on the list for a while longer. > > > > > > Hi, > > > > > > I am available to test this patch, > > > Can you tell me on which branch to apply it. On 5.8-rc1 it fails for > > > me > > > (or maybe it needs rebasing ?) > > > > > > > Hmm, weird. > > I rebased the patches on Jonathan's iio/testing. > > It seemed to work. > > https://urldefense.com/v3/__https://github.com/commodo/linux/commits/iio-priv-to-dev__;!!A3Ni8CS0y2Y!oEVHsA6gf9ydBvAAjlhRV5QO1bMTZN2U_OXbor0gei7mWk14m64rilJ2WTAXvtWmGaisXQ$ > > > > > > As for which branch to test/apply. Not sure. > > Maybe Jonathan's iio/testing as base? > > Looks like it's based on 5.8. > > > > Tested-by: Eugen Hristev > > I have tested the major features of the driver (including the resistive > touch) and it looks to be working fine. > > I did not fully understand the quirkyness of the workq . Something you > want to change to that ? Umm, not really. I did not follow that code too in-depth. And I would like not to. Mostly to avoid scaling myself in too many directions. There may be a slightly better approach to it, but ¯\_(ツ)_/¯ > > > > Eugen > > > > > > > Poke me if no action in a few weeks. > > > > > > > > Thanks, > > > > > > > > Jonathan > > > > > > > > > Signed-off-by: Alexandru Ardelean > > > > > --- > > > > >drivers/iio/adc/at91-sama5d2_adc.c | 30 +- > > > > > > > > > >1 file changed, 17 insertions(+), 13 deletions(-) > > > > > > > > > > diff --git a/drivers/iio/adc/at91-sama5d2_adc.c > > > > > b/drivers/iio/adc/at91- > > > > > sama5d2_adc.c > &g
Re: [PATCH] iio: at91-sama5d2_adc: remove usage of iio_priv_to_dev() helper
On Wed, 2020-06-17 at 13:25 +, eugen.hris...@microchip.com wrote:
> On 31.05.2020 17:39, Jonathan Cameron wrote:
>
> > On Mon, 25 May 2020 13:53:41 +0300
> > Alexandru Ardelean wrote:
> >
> > > We may want to get rid of the iio_priv_to_dev() helper. The reason is that
> > > we will hide some of the members of the iio_dev structure (to prevent
> > > drivers from accessing them directly), and that will also mean hiding the
> > > implementation of the iio_priv_to_dev() helper inside the IIO core.
> > >
> > > Hiding the implementation of iio_priv_to_dev() implies that some fast-
> > > paths
> > > may not be fast anymore, so a general idea is to try to get rid of the
> > > iio_priv_to_dev() altogether.
> > > The iio_priv() helper won't be affected by the rework, as the iio_dev
> > > struct will keep a reference to the private information.
> > >
> > > For this driver, not using iio_priv_to_dev(), means reworking some paths
> > > to
> > > pass the iio device and using iio_priv() to access the private
> > > information,
> > > and also keeping a reference to the iio device for some quirky paths.
> > >
> > > One [quirky] path is the at91_adc_workq_handler() which requires the IIO
> > > device & the state struct to push to buffers.
> > > Since this requires the back-ref to the IIO device, the
> > > at91_adc_touch_pos() also uses it. This simplifies the patch a bit. The
> > > information required in this function is mostly for debugging purposes.
> > > Replacing it with a reference to the IIO device would have been a slightly
> > > bigger change, which may not be worth it (for just the debugging purpose
> > > and given that we need the back-ref to the IIO device anyway).
> >
> > That workq is indeed quirky. This looks fine to me in general. I'll
> > want an appropriate ack from the at91 side of things if possible so
> > let's leave this on the list for a while longer.
>
> Hi,
>
> I am available to test this patch,
> Can you tell me on which branch to apply it. On 5.8-rc1 it fails for me
> (or maybe it needs rebasing ?)
>
Hmm, weird.
I rebased the patches on Jonathan's iio/testing.
It seemed to work.
https://github.com/commodo/linux/commits/iio-priv-to-dev
As for which branch to test/apply. Not sure.
Maybe Jonathan's iio/testing as base?
Looks like it's based on 5.8.
> Eugen
>
> > Poke me if no action in a few weeks.
> >
> > Thanks,
> >
> > Jonathan
> >
> > > Signed-off-by: Alexandru Ardelean
> > > ---
> > > drivers/iio/adc/at91-sama5d2_adc.c | 30 +-
> > > 1 file changed, 17 insertions(+), 13 deletions(-)
> > >
> > > diff --git a/drivers/iio/adc/at91-sama5d2_adc.c b/drivers/iio/adc/at91-
> > > sama5d2_adc.c
> > > index 9abbbdcc7420..7bce1830 100644
> > > --- a/drivers/iio/adc/at91-sama5d2_adc.c
> > > +++ b/drivers/iio/adc/at91-sama5d2_adc.c
> > > @@ -402,6 +402,7 @@ struct at91_adc_state {
> > >wait_queue_head_t wq_data_available;
> > >struct at91_adc_dma dma_st;
> > >struct at91_adc_touch touch_st;
> > > + struct iio_dev *indio_dev;
> > >u16 buffer[AT91_BUFFER_MAX_HWORDS];
> > >/*
> > > * lock to prevent concurrent 'single conversion' requests through
> > > @@ -642,13 +643,13 @@ static u16 at91_adc_touch_pos(struct at91_adc_state
> > > *st, int reg)
> > >/* first half of register is the x or y, second half is the scale
> > > */
> > >val = at91_adc_readl(st, reg);
> > >if (!val)
> > > - dev_dbg(_priv_to_dev(st)->dev, "pos is 0\n");
> > > + dev_dbg(>indio_dev->dev, "pos is 0\n");
> > >
> > >pos = val & AT91_SAMA5D2_XYZ_MASK;
> > >result = (pos << AT91_SAMA5D2_MAX_POS_BITS) - pos;
> > >scale = (val >> 16) & AT91_SAMA5D2_XYZ_MASK;
> > >if (scale == 0) {
> > > - dev_err(_priv_to_dev(st)->dev, "scale is 0\n");
> > > + dev_err(>indio_dev->dev, "scale is 0\n");
> > >return 0;
> > >}
> > >result /= scale;
> > > @@ -1204,9 +1205,9 @@ static unsigned at91_adc_startup_time(unsigned
> > > startup_time_min,
> > >return i;
> > > }
> > >
> > > -static void at91_adc_setup_samp_freq(struct at91_adc_state *st, unsigned
> > > freq)
> > > +static void at91_adc_setup_samp_freq(struct iio_dev *indio_dev, unsigned
> > > freq)
> > > {
> > > - struct iio_dev *indio_dev = iio_priv_to_dev(st);
> > > + struct at91_adc_state *st = iio_priv(indio_dev);
> > >unsigned f_per, prescal, startup, mr;
> > >
> > >f_per = clk_get_rate(st->per_clk);
> > > @@ -1275,9 +1276,9 @@ static void at91_adc_pen_detect_interrupt(struct
> > > at91_adc_state *st)
> > >st->touch_st.touching = true;
> > > }
> > >
> > > -static void at91_adc_no_pen_detect_interrupt(struct at91_adc_state *st)
> > > +static void at91_adc_no_pen_detect_interrupt(struct iio_dev *indio_dev)
> > > {
> > > - struct
Re: [PATCH v2 3/3] iio: remove iio_triggered_buffer_postenable()/iio_triggered_buffer_predisable()
On Wed, 2020-06-17 at 13:37 +, eugen.hris...@microchip.com wrote:
> [External]
>
> On 02.06.2020 11:54, Jonathan Cameron wrote:
> > On Tue, 2 Jun 2020 07:50:23 +0000
> > "Ardelean, Alexandru" wrote:
> >
> > > On Sun, 2020-05-31 at 16:40 +0100, Jonathan Cameron wrote:
> > > > On Mon, 25 May 2020 14:38:55 +0300
> > > > Alexandru Ardelean wrote:
> > > >
> > > > > From: Lars-Peter Clausen
> > > > >
> > > > > This patch should be squashed into the first one, as the first one is
> > > > > breaking the build (intentionally) to make the IIO core files easier
> > > > > to
> > > > > review.
> > > > >
> > > > > Signed-off-by: Lars-Peter Clausen
> > > > > Signed-off-by: Alexandru Ardelean
> > > > > ---
> > > >
> > > > Friend poke. Version log?
> > >
> > > Version log is in the first patch.
> > > I was wondering if I omitted it.
> > > Seems, this time I didn't. But I admit, it probably would have been better
> > > here.
> > Ah fair enough. That works fine if there is a cover letter but not
> > so much just putting things in the first patch!
> > > > Other than the wistful comment below (which I'm not expecting you to
> > > > do anything about btw!) whole series looks good to me.
> > > >
> > > > These are obviously no functional changes (I think) so it's only really
> > > > patch 2 that
> > > > could do with more eyes and acks.
> > > >
> > > > Far as I can tell that case is fine as well because of the protections
> > > > on being in the right mode, but more eyes on that would be great.
> > > >
> > > > So assuming that's fine, what commit message do you want me to use for
> > > > the fused single patch?
> > >
> > > Commit message-wise: I think the message in the first commit would be
> > > mostly sufficient.
> > > No idea what other description would be needed.
> > >
> > > So, maybe something like:
> > >
> > > --
> > > All devices using a triggered buffer need to attach and detach the trigger
> > > to the device in order to properly work. Instead of doing this in each and
> > > every driver by hand move this into the core.
> > >
> > > At this point in time, all drivers should have been resolved to
> > > attach/detach the poll-function in the same order.
> > >
> > > This patch removes all explicit calls of iio_triggered_buffer_postenable()
> > > & iio_triggered_buffer_predisable() in all drivers, since the core handles
> > > now the pollfunc attach/detach.
> > >
> > > The more peculiar change is for the 'at91-sama5d2_adc' driver, since it's
> > > not obvious that removing the hooks doesn't break anything**
> > > --
> > >
> >
> > Looks good.
> >
> > > ** for the comment about 'at91-sama5d2_adc', we really do need to get some
> > > testing; otherwise this risks breaking it.
>
> Hi,
>
> I can test it, do we have any patchwork so I can easily download the
> patches ?
> I have issues when applying them.
Is this good?
https://patchwork.kernel.org/patch/11568743/
Series:
https://patchwork.kernel.org/project/linux-iio/list/?series=293141
Many thanks
Alex
>
> Thanks !
>
> > Agreed.
> >
> > >
> > > > Thanks,
> > > >
> > > > Jonathan
> > > >
> > > > > static const struct iio_trigger_ops atlas_interrupt_trigger_ops = {
> > > > > diff --git a/drivers/iio/dummy/iio_simple_dummy_buffer.c
> > > > > b/drivers/iio/dummy/iio_simple_dummy_buffer.c
> > > > > index 17606eca42b4..8e13c53d4360 100644
> > > > > --- a/drivers/iio/dummy/iio_simple_dummy_buffer.c
> > > > > +++ b/drivers/iio/dummy/iio_simple_dummy_buffer.c
> > > > > @@ -99,20 +99,6 @@ static irqreturn_t iio_simple_dummy_trigger_h(int
> > > > > irq, void *p)
> > > > > }
> > > > >
> > > > > static const struct iio_buffer_setup_ops
> > > > > iio_simple_dummy_buffer_setup_ops = {
> > > > > - /*
> > > > > - * iio_triggered_buffer_postenable:
> > > > > - * Generic function that simply atta
Re: [PATCH v2 6/6] iio: remove left-over parent assignments
On Sat, 2020-06-06 at 17:05 +0100, Jonathan Cameron wrote: > [External] > > On Wed, 3 Jun 2020 14:40:23 +0300 > Alexandru Ardelean wrote: > > > These were found by doing some shell magic: > > > > for file in $(git grep -w devm_iio_device_alloc | cut -d: -f1 | sort | uniq) > > ; do > > if grep 'parent =' $file | grep -v trig | grep -vq devm_; then > > echo "$file -> $(grep "parent =" $file)" > > fi > > done > > --- > > > > The output is bearable [after the semantic patch is applied]. > > There is a mix of trigger assignments with some iio device parent > > assignments that are removed via this patch. > > > > Signed-off-by: Alexandru Ardelean > > I added a bunch more via a grep of simple parent\ = > and eyeballing it. Much easier to do after your patches as far > fewer entries. > > vcnl3020 (new) > ms5611 (hidden via an extra call) > st_sensors_spi (hidden via an extra call) > st_sensors_i2c (hidden via an extra call) > cros_ec_sensors_core (hidden via an extra call) I rebased your branch with my work-branch. That displayes neatly all the stuff you've added. drivers/iio/adc/ltc2497-core.c drivers/iio/chemical/atlas-ezo-sensor.c drivers/iio/common/cros_ec_sensors/cros_ec_sensors_core.c drivers/iio/common/st_sensors/st_sensors_i2c.c drivers/iio/common/st_sensors/st_sensors_spi.c drivers/iio/pressure/ms5611_core.c drivers/iio/proximity/vcnl3020.c All look good to me. So, purely for record purporses, for all the files above: Reviewed-by: Alexandru Ardelean > > --- > > drivers/iio/accel/kxcjk-1013.c| 1 - > > drivers/iio/accel/mma8452.c | 1 - > > drivers/iio/accel/mma9553.c | 1 - > > drivers/iio/adc/ad7192.c | 1 - > > drivers/iio/adc/hx711.c | 1 - > > drivers/iio/adc/max1363.c | 2 -- > > drivers/iio/adc/mcp3911.c | 1 - > > drivers/iio/adc/qcom-spmi-iadc.c | 1 - > > drivers/iio/amplifiers/ad8366.c | 1 - > > drivers/iio/chemical/vz89x.c | 1 - > > drivers/iio/dac/ad5770r.c | 1 - > > drivers/iio/health/afe4403.c | 1 - > > drivers/iio/health/afe4404.c | 1 - > > drivers/iio/humidity/dht11.c | 1 - > > drivers/iio/humidity/hts221_core.c| 1 - > > drivers/iio/imu/inv_mpu6050/inv_mpu_core.c| 1 - > > drivers/iio/light/cm3605.c| 1 - > > drivers/iio/light/ltr501.c| 1 - > > drivers/iio/magnetometer/ak8975.c | 1 - > > drivers/iio/orientation/hid-sensor-rotation.c | 1 - > > drivers/iio/potentiostat/lmp91000.c | 1 - > > drivers/iio/proximity/ping.c | 1 - > > drivers/iio/proximity/pulsedlight-lidar-lite-v2.c | 1 - > > drivers/iio/proximity/srf04.c | 1 - > > drivers/iio/proximity/srf08.c | 1 - > > drivers/iio/temperature/tsys01.c | 1 - > > drivers/staging/iio/addac/adt7316.c | 1 - > > 27 files changed, 28 deletions(-) > > > > diff --git a/drivers/iio/accel/kxcjk-1013.c b/drivers/iio/accel/kxcjk-1013.c > > index c9924a65c32a..6b93521c0e17 100644 > > --- a/drivers/iio/accel/kxcjk-1013.c > > +++ b/drivers/iio/accel/kxcjk-1013.c > > @@ -1311,7 +1311,6 @@ static int kxcjk1013_probe(struct i2c_client *client, > > > > mutex_init(>mutex); > > > > - indio_dev->dev.parent = >dev; > > indio_dev->channels = kxcjk1013_channels; > > indio_dev->num_channels = ARRAY_SIZE(kxcjk1013_channels); > > indio_dev->available_scan_masks = kxcjk1013_scan_masks; > > diff --git a/drivers/iio/accel/mma8452.c b/drivers/iio/accel/mma8452.c > > index 00e100fc845a..ef3df402fc3c 100644 > > --- a/drivers/iio/accel/mma8452.c > > +++ b/drivers/iio/accel/mma8452.c > > @@ -1592,7 +1592,6 @@ static int mma8452_probe(struct i2c_client *client, > > i2c_set_clientdata(client, indio_dev); > > indio_dev->info = _info; > > indio_dev->name = id->name; > > - indio_dev->dev.parent = >dev; > > indio_dev->modes = INDIO_DIRECT_MODE; > > indio_dev->channels = data->chip_info->channels; > > indio_dev->num_channels = data->chip_info->num_channels; > > diff --git a/drivers/iio/accel/mma9553.c b/drivers/iio/accel/mma9553.c > > index 312070dcf035..c15908faa381 100644 > > --- a/drivers/iio/accel/mma9553.c > > +++ b/drivers/iio/accel/mma9553.c > > @@ -1103,7 +1103,6 @@ static int mma9553_probe(struct i2c_client *client, > > if (ret < 0) > > return ret; > > > > - indio_dev->dev.parent = >dev; > > indio_dev->channels = mma9553_channels; > > indio_dev->num_channels = ARRAY_SIZE(mma9553_channels); > > indio_dev->name = name; > > diff --git a/drivers/iio/adc/ad7192.c b/drivers/iio/adc/ad7192.c > > index 08ba1a8f05eb..a0837d7e9176 100644 > >
Re: [PATCH v2 0/6] iio: core: pass parent device as parameter during allocation
On Wed, 2020-06-03 at 14:40 +0300, Alexandru Ardelean wrote:
> This patch updates the {devm_}iio_device_alloc() functions to automatically
> assign the parent device on allocation.
> For iio_device_alloc() this means a new parameter.
> For devm_iio_device_alloc() this means a new behavior; the device object is
> the parent. For this one, this is the common case for most drivers (except
> one: 'lm3533-als').
>
> For the special cases an iio_device_set_parent() has been created to change
> the parent betwee allocation & registration.
> The purpose of this helper, is mostly to highlight the new behavior of
> devm_iio_device_alloc().
>
> This patchset also removes explicit parent assignments from most IIO
> drivers (except for lm3533-als).
>
> Using a semantic patch, about 303 drivers are updated, and some needed some
> manual attention. This is probably due to some limitations of spatch. At
> least in some cases the parent device is not the same variable as passed to
> devm_iio_device_alloc(), OR the parent assignment is moved to a separate
> function than where devm_iio_device_alloc() is called.
>
Forgot to explicitly CC Jonathan.
But I'm hoping this shows up from the list.
> Changelog v1 -> v2:
> * added iio_device_set_parent() helper (new commit)
> * update commit for lm3533-als to use iio_device_set_parent()
>
> Alexandru Ardelean (6):
> iio: core: pass parent device as parameter during allocation
> iio: core: add iio_device_set_parent() helper
> iio: remove explicit IIO device parent assignment
> iio: remove left-over comments about parent assignment
> iio: light: lm3533-als: use iio_device_set_parent() to assign parent
> iio: remove left-over parent assignments
>
> drivers/counter/104-quad-8.c | 1 -
> drivers/counter/stm32-lptimer-cnt.c | 1 -
> drivers/iio/accel/adis16201.c | 1 -
> drivers/iio/accel/adis16209.c | 1 -
> drivers/iio/accel/adxl345_core.c | 1 -
> drivers/iio/accel/adxl372.c | 1 -
> drivers/iio/accel/bma180.c| 1 -
> drivers/iio/accel/bma220_spi.c| 1 -
> drivers/iio/accel/bma400_core.c | 1 -
> drivers/iio/accel/bmc150-accel-core.c | 1 -
> drivers/iio/accel/da280.c | 1 -
> drivers/iio/accel/da311.c | 1 -
> drivers/iio/accel/dmard06.c | 1 -
> drivers/iio/accel/dmard09.c | 1 -
> drivers/iio/accel/dmard10.c | 1 -
> drivers/iio/accel/hid-sensor-accel-3d.c | 1 -
> drivers/iio/accel/kxcjk-1013.c| 1 -
> drivers/iio/accel/kxsd9.c | 1 -
> drivers/iio/accel/mc3230.c| 1 -
> drivers/iio/accel/mma7455_core.c | 1 -
> drivers/iio/accel/mma7660.c | 1 -
> drivers/iio/accel/mma8452.c | 1 -
> drivers/iio/accel/mma9551.c | 1 -
> drivers/iio/accel/mma9553.c | 1 -
> drivers/iio/accel/mxc4005.c | 1 -
> drivers/iio/accel/mxc6255.c | 1 -
> drivers/iio/accel/sca3000.c | 1 -
> drivers/iio/accel/ssp_accel_sensor.c | 1 -
> drivers/iio/accel/stk8312.c | 1 -
> drivers/iio/accel/stk8ba50.c | 1 -
> drivers/iio/adc/ab8500-gpadc.c| 1 -
> drivers/iio/adc/ad7091r-base.c| 1 -
> drivers/iio/adc/ad7124.c | 1 -
> drivers/iio/adc/ad7192.c | 1 -
> drivers/iio/adc/ad7266.c | 1 -
> drivers/iio/adc/ad7291.c | 1 -
> drivers/iio/adc/ad7292.c | 1 -
> drivers/iio/adc/ad7298.c | 1 -
> drivers/iio/adc/ad7476.c | 2 --
> drivers/iio/adc/ad7606.c | 1 -
> drivers/iio/adc/ad7766.c | 1 -
> drivers/iio/adc/ad7768-1.c| 1 -
> drivers/iio/adc/ad7780.c | 1 -
> drivers/iio/adc/ad7791.c | 1 -
> drivers/iio/adc/ad7793.c | 1 -
> drivers/iio/adc/ad7887.c | 2 --
> drivers/iio/adc/ad7923.c | 1 -
> drivers/iio/adc/ad7949.c | 1 -
> drivers/iio/adc/ad799x.c | 1 -
> drivers/iio/adc/adi-axi-adc.c | 1 -
> drivers/iio/adc/aspeed_adc.c | 1 -
> drivers/iio/adc/at91-sama5d2_adc.c| 1 -
> drivers/iio/adc/at91_adc.c| 1 -
> drivers/iio/adc/axp20x_adc.c | 1 -
> drivers/iio/adc/axp288_adc.c | 1 -
> drivers/iio/adc/bcm_iproc_adc.c | 1 -
> drivers/iio/adc/berlin2-adc.c | 1 -
> drivers/iio/adc/cc10001_adc.c | 1 -
> drivers/iio/adc/cpcap-adc.c
Re: [PATCH v3] iio: amplifiers: ad8366: Change devm_gpiod_get() to optional and add the missed check
On Wed, 2020-06-03 at 17:26 +0800, Chuhong Yuan wrote:
> Since if there is no GPIO, nothing happens, replace devm_gpiod_get()
> with devm_gpiod_get_optional().
> Also add IS_ERR() to fix the missing-check bug.
>
Acked-by: Alexandru Ardelean
> Fixes: cee211f4e5a0 ("iio: amplifiers: ad8366: Add support for the ADA4961
> DGA")
> Signed-off-by: Chuhong Yuan
> ---
> Changes in v3:
> - Change devm_gpiod_get() to optional.
> - Modify description.
>
> drivers/iio/amplifiers/ad8366.c | 6 +-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/iio/amplifiers/ad8366.c b/drivers/iio/amplifiers/ad8366.c
> index 62167b87caea..8819e8997f76 100644
> --- a/drivers/iio/amplifiers/ad8366.c
> +++ b/drivers/iio/amplifiers/ad8366.c
> @@ -262,8 +262,12 @@ static int ad8366_probe(struct spi_device *spi)
> case ID_ADA4961:
> case ID_ADL5240:
> case ID_HMC1119:
> - st->reset_gpio = devm_gpiod_get(>dev, "reset",
> + st->reset_gpio = devm_gpiod_get_optional(>dev, "reset",
> GPIOD_OUT_HIGH);
> + if (IS_ERR(st->reset_gpio)) {
> + ret = PTR_ERR(st->reset_gpio);
> + goto error_disable_reg;
> + }
> indio_dev->channels = ada4961_channels;
> indio_dev->num_channels = ARRAY_SIZE(ada4961_channels);
> break;
Re: [PATCH 4/5] iio: light: lm3533-als: remove explicit parent assignment
On Sun, 2020-05-31 at 15:54 +0100, Jonathan Cameron wrote: > [External] > > On Fri, 29 May 2020 15:45:33 +0200 > Johan Hovold wrote: > > > [ Trimming CC to something more reasonable... ] > > > > On Fri, May 29, 2020 at 11:08:38AM +, Ardelean, Alexandru wrote: > > > On Fri, 2020-05-29 at 12:16 +0200, Johan Hovold wrote: > > > > On Fri, May 22, 2020 at 11:22:07AM +0300, Alexandru Ardelean > > > > wrote: > > > > > This assignment is the more peculiar of the bunch as it assigns > > > > > the parent > > > > > of the platform-device's device (i.e. pdev->dev.parent) as the > > > > > IIO device's > > > > > parent. > > > > > > > > > > It's unclear whether this is intentional or not. > > > > > Hence it is in it's own patch. > > > > > > > > Yeah, we have a few mfd drivers whose child drivers registers their > > > > class devices directly under the parent mfd device rather than the > > > > corresponding child platform device. > > > > > > > > Since it's done consistently I think you need to update them all if > > > > you > > > > really want to change this. > > > > > > > > And it may not be worth it since at least in theory someone could > > > > now be > > > > relying on this topology. > > > > > > Thanks for the feedback. > > > I guess, it could make sense to do here: > > > devm_iio_device_alloc(pdev->dev.parent, ...) > > > > > > Currently it's: > > > devm_iio_device_alloc(>dev, ...) > > > > > > That would make it slightly more consistent. i.e. the life-time of > > > the object would be attached to the parent of the platform device, > > > versus the platform-device. > > > > Not really. If you unbind the iio driver, the iio device gets > > deregistered (as it should be) and there's no need to keep it around > > any > > more. > > > > You'd essentially just leak resources every time you rebind the driver > > (e.g. during development). > > > > And in fact, you could also introduce a use-after-free depending on if > > the parent mfd driver use devres to deregister its children. > > > > > Currently, as it is, the allocation [of the IIO device] is tied the > > > platform-device, and the IIO registration to the parent (of the > > > platform-device). > > > > Not quite; the iio device still gets deregistered when the platform > > device is unbound. > > > > > I'm not super-familiar with the internals here, but does this sound a > > > bit wrong? > > > > It's not a common pattern but not necessarily wrong per se. > > > > > Is there a chance where the IIO device could be de-allocated, while > > > registered? > > > > No, the device-managed iio device object is freed when the platform > > device is unbound and specifically after the iio device has been > > deregistered. > > I had a feeling we might have a few cases like this hiding in IIO. > > For these I'd just leave the parent being manually set. > It doesn't do any harm and the facility existing is useful for messing > around with topology. > > We may however want to wrap it up in a utility function on the > basis that we may want to change the visibility and location > of the IIO device down the line. > > iio_device_set_parent() perhaps with docs to specify that it must > be called between allocation and registration + is meant to allow > cases where we want a different parent than the device used for > managed allocations etc. > Works for me. If no objections, I'll include in the next re-spin. > Jonathan > > > > > > > Signed-off-by: Alexandru Ardelean > > > > > --- > > > > > drivers/iio/light/lm3533-als.c | 1 - > > > > > 1 file changed, 1 deletion(-) > > > > > > > > > > diff --git a/drivers/iio/light/lm3533-als.c > > > > > b/drivers/iio/light/lm3533-als.c > > > > > index bc196c212881..0f380ec8d30c 100644 > > > > > --- a/drivers/iio/light/lm3533-als.c > > > > > +++ b/drivers/iio/light/lm3533-als.c > > > > > @@ -852,7 +852,6 @@ static int lm3533_als_probe(struct > > > > > platform_device > > > > > *pdev) > > > > > indio_dev->channels = lm3533_als_channels; > > > > > indio_dev->num_channels = ARRAY_SIZE(lm3533_als_channels); > > > > > indio_dev->name = dev_name(>dev); > > > > > - indio_dev->dev.parent = pdev->dev.parent; > > > > > indio_dev->modes = INDIO_DIRECT_MODE; > > > > > > > > > > als = iio_priv(indio_dev); > > > > Johan
Re: [PATCH v2 3/3] iio: remove iio_triggered_buffer_postenable()/iio_triggered_buffer_predisable()
On Sun, 2020-05-31 at 16:40 +0100, Jonathan Cameron wrote:
> On Mon, 25 May 2020 14:38:55 +0300
> Alexandru Ardelean wrote:
>
> > From: Lars-Peter Clausen
> >
> > This patch should be squashed into the first one, as the first one is
> > breaking the build (intentionally) to make the IIO core files easier to
> > review.
> >
> > Signed-off-by: Lars-Peter Clausen
> > Signed-off-by: Alexandru Ardelean
> > ---
>
> Friend poke. Version log?
Version log is in the first patch.
I was wondering if I omitted it.
Seems, this time I didn't. But I admit, it probably would have been better
here.
>
> Other than the wistful comment below (which I'm not expecting you to
> do anything about btw!) whole series looks good to me.
>
> These are obviously no functional changes (I think) so it's only really
> patch 2 that
> could do with more eyes and acks.
>
> Far as I can tell that case is fine as well because of the protections
> on being in the right mode, but more eyes on that would be great.
>
> So assuming that's fine, what commit message do you want me to use for
> the fused single patch?
Commit message-wise: I think the message in the first commit would be
mostly sufficient.
No idea what other description would be needed.
So, maybe something like:
--
All devices using a triggered buffer need to attach and detach the trigger
to the device in order to properly work. Instead of doing this in each and
every driver by hand move this into the core.
At this point in time, all drivers should have been resolved to
attach/detach the poll-function in the same order.
This patch removes all explicit calls of iio_triggered_buffer_postenable()
& iio_triggered_buffer_predisable() in all drivers, since the core handles
now the pollfunc attach/detach.
The more peculiar change is for the 'at91-sama5d2_adc' driver, since it's
not obvious that removing the hooks doesn't break anything**
--
** for the comment about 'at91-sama5d2_adc', we really do need to get some
testing; otherwise this risks breaking it.
>
> Thanks,
>
> Jonathan
>
> > static const struct iio_trigger_ops atlas_interrupt_trigger_ops = {
> > diff --git a/drivers/iio/dummy/iio_simple_dummy_buffer.c
> > b/drivers/iio/dummy/iio_simple_dummy_buffer.c
> > index 17606eca42b4..8e13c53d4360 100644
> > --- a/drivers/iio/dummy/iio_simple_dummy_buffer.c
> > +++ b/drivers/iio/dummy/iio_simple_dummy_buffer.c
> > @@ -99,20 +99,6 @@ static irqreturn_t iio_simple_dummy_trigger_h(int
> > irq, void *p)
> > }
> >
> > static const struct iio_buffer_setup_ops
> > iio_simple_dummy_buffer_setup_ops = {
> > - /*
> > -* iio_triggered_buffer_postenable:
> > -* Generic function that simply attaches the pollfunc to the
> > trigger.
> > -* Replace this to mess with hardware state before we attach the
> > -* trigger.
> > -*/
> > - .postenable = _triggered_buffer_postenable,
> > - /*
> > -* iio_triggered_buffer_predisable:
> > -* Generic function that simple detaches the pollfunc from the
> > trigger.
> > -* Replace this to put hardware state back again after the trigger
> > is
> > -* detached but before userspace knows we have disabled the ring.
> > -*/
> > - .predisable = _triggered_buffer_predisable,
> > };
> >
> Hmm. Guess we should probably 'invent' a reason to illustrate the bufer
> ops in the dummy example. Anyone feeling creative?
Re: [PATCH v2] iio: amplifiers: ad8366: Add the missed check for devm_gpiod_get()
On Thu, 2020-05-28 at 14:40 +0800, Chuhong Yuan wrote:
> [External]
>
> ad8366_probe() forgets to check the return value of devm_gpiod_get().
> Add the missed check to fix it.
>
> Fixes: cee211f4e5a0 ("iio: amplifiers: ad8366: Add support for the
> ADA4961 DGA")
> Signed-off-by: Chuhong Yuan
> ---
> Changes in v2:
> - Add fixes tag.
>
> drivers/iio/amplifiers/ad8366.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/iio/amplifiers/ad8366.c
> b/drivers/iio/amplifiers/ad8366.c
> index 62167b87caea..b996823c8d51 100644
> --- a/drivers/iio/amplifiers/ad8366.c
> +++ b/drivers/iio/amplifiers/ad8366.c
> @@ -264,6 +264,10 @@ static int ad8366_probe(struct spi_device *spi)
> case ID_HMC1119:
> st->reset_gpio = devm_gpiod_get(>dev, "reset",
> GPIOD_OUT_HIGH);
this is semi-intentional i guess;
in the sense that if there is no GPIO, nothing happens;
maybe convert this to devm_gpiod_get_optional()
otherwise, if there is no reset GPIO, this can fail the probe; and the GPIO
is not optional;
rest of the code looks fine (with the devm_gpiod_get_optional()
modification)
> + if (IS_ERR(st->reset_gpio)) {
> + ret = PTR_ERR(st->reset_gpio);
> + goto error_disable_reg;
> + }
> indio_dev->channels = ada4961_channels;
> indio_dev->num_channels = ARRAY_SIZE(ada4961_channels);
> break;
Re: [PATCH 4/6] iio: dac: ad5686: Constify static struct iio_chan_spec
On Tue, 2020-05-26 at 23:02 +0200, Rikard Falkeborn wrote:
> [External]
>
> These are never modified and can be made const to allow the compiler to
> put it in read-only memory.
>
> Before:
>textdata bss dec hex filename
>6642 12608 64 193144b72 drivers/iio/dac/ad5686.o
>
> After:
>textdata bss dec hex filename
> 169462304 64 193144b72 drivers/iio/dac/ad5686.o
>
Acked-by: Alexandru Ardelean
> Signed-off-by: Rikard Falkeborn
> ---
> drivers/iio/dac/ad5686.c | 8
> drivers/iio/dac/ad5686.h | 2 +-
> 2 files changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/iio/dac/ad5686.c b/drivers/iio/dac/ad5686.c
> index 8dd67da0a7da..6de48f618c95 100644
> --- a/drivers/iio/dac/ad5686.c
> +++ b/drivers/iio/dac/ad5686.c
> @@ -206,12 +206,12 @@ static const struct iio_chan_spec_ext_info
> ad5686_ext_info[] = {
> }
>
> #define DECLARE_AD5693_CHANNELS(name, bits, _shift) \
> -static struct iio_chan_spec name[] = { \
> +static const struct iio_chan_spec name[] = { \
> AD5868_CHANNEL(0, 0, bits, _shift), \
> }
>
> #define DECLARE_AD5686_CHANNELS(name, bits, _shift) \
> -static struct iio_chan_spec name[] = { \
> +static const struct iio_chan_spec name[] = { \
> AD5868_CHANNEL(0, 1, bits, _shift), \
> AD5868_CHANNEL(1, 2, bits, _shift), \
> AD5868_CHANNEL(2, 4, bits, _shift), \
> @@ -219,7 +219,7 @@ static struct iio_chan_spec name[] = {
> \
> }
>
> #define DECLARE_AD5676_CHANNELS(name, bits, _shift) \
> -static struct iio_chan_spec name[] = { \
> +static const struct iio_chan_spec name[] = { \
> AD5868_CHANNEL(0, 0, bits, _shift), \
> AD5868_CHANNEL(1, 1, bits, _shift), \
> AD5868_CHANNEL(2, 2, bits, _shift), \
> @@ -231,7 +231,7 @@ static struct iio_chan_spec name[] = {
> \
> }
>
> #define DECLARE_AD5679_CHANNELS(name, bits, _shift) \
> -static struct iio_chan_spec name[] = { \
> +static const struct iio_chan_spec name[] = { \
> AD5868_CHANNEL(0, 0, bits, _shift), \
> AD5868_CHANNEL(1, 1, bits, _shift), \
> AD5868_CHANNEL(2, 2, bits, _shift), \
> diff --git a/drivers/iio/dac/ad5686.h b/drivers/iio/dac/ad5686.h
> index 52009b5eef88..a15f2970577e 100644
> --- a/drivers/iio/dac/ad5686.h
> +++ b/drivers/iio/dac/ad5686.h
> @@ -104,7 +104,7 @@ typedef int (*ad5686_read_func)(struct ad5686_state
> *st, u8 addr);
> struct ad5686_chip_info {
> u16 int_vref_mv;
> unsigned intnum_channels;
> - struct iio_chan_spec*channels;
> + const struct iio_chan_spec *channels;
> enum ad5686_regmap_type regmap_type;
> };
>
Re: [PATCH 3/6] iio: dac: ad5592r-base: Constify struct iio_chan_spec_ext_info
On Tue, 2020-05-26 at 23:02 +0200, Rikard Falkeborn wrote:
> [External]
>
> ad5592r_ext_info is not modified and can be made const to allow the
> compiler to put it in read-only memory.
>
> Before:
>textdata bss dec hex filename
> 132932088 256 156373d15 drivers/iio/dac/ad5592r-base.o
>
> After:
>textdata bss dec hex filename
> 134211960 256 156373d15 drivers/iio/dac/ad5592r-base.o
>
Acked-by: Alexandru Ardelean
> Signed-off-by: Rikard Falkeborn
> ---
> drivers/iio/dac/ad5592r-base.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/iio/dac/ad5592r-base.c b/drivers/iio/dac/ad5592r-
> base.c
> index 410e90e5f75f..7402f67a551d 100644
> --- a/drivers/iio/dac/ad5592r-base.c
> +++ b/drivers/iio/dac/ad5592r-base.c
> @@ -484,7 +484,7 @@ static ssize_t ad5592r_show_scale_available(struct
> iio_dev *iio_dev,
> st->scale_avail[1][0], st->scale_avail[1][1]);
> }
>
> -static struct iio_chan_spec_ext_info ad5592r_ext_info[] = {
> +static const struct iio_chan_spec_ext_info ad5592r_ext_info[] = {
> {
>.name = "scale_available",
>.read = ad5592r_show_scale_available,
Re: [PATCH 2/6] iio: dac: ad5380: Constify struct iio_chan_spec_ext_info
On Tue, 2020-05-26 at 23:02 +0200, Rikard Falkeborn wrote:
> [External]
>
> ad5380_ext_info is not modified and can be made const to allow the
> compiler to put it in read-only memory.
>
> Before:
>textdata bss dec hex filename
> 120603280 192 155323cac drivers/iio/dac/ad5380.o
>
> After:
>textdata bss dec hex filename
> 122523088 192 155323cac drivers/iio/dac/ad5380.o
>
Acked-by: Alexandru Ardelean
> Signed-off-by: Rikard Falkeborn
> ---
> drivers/iio/dac/ad5380.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/iio/dac/ad5380.c b/drivers/iio/dac/ad5380.c
> index b37e5675f716..04c74cc1a4ec 100644
> --- a/drivers/iio/dac/ad5380.c
> +++ b/drivers/iio/dac/ad5380.c
> @@ -240,7 +240,7 @@ static const struct iio_info ad5380_info = {
> .write_raw = ad5380_write_raw,
> };
>
> -static struct iio_chan_spec_ext_info ad5380_ext_info[] = {
> +static const struct iio_chan_spec_ext_info ad5380_ext_info[] = {
> {
> .name = "powerdown",
> .read = ad5380_read_dac_powerdown,
Re: [PATCH v2] iio: stm32-adc: remove usage of iio_priv_to_dev() helper
On Mon, 2020-05-25 at 18:27 +0200, Fabrice Gasnier wrote:
> [External]
>
> On 5/25/20 11:07 AM, Alexandru Ardelean wrote:
> > We may want to get rid of the iio_priv_to_dev() helper. The reason is
> > that
> > we will hide some of the members of the iio_dev structure (to prevent
> > drivers from accessing them directly), and that will also mean hiding
> > the
> > implementation of the iio_priv_to_dev() helper inside the IIO core.
> >
> > Hiding the implementation of iio_priv_to_dev() implies that some fast-
> > paths
> > may not be fast anymore, so a general idea is to try to get rid of the
> > iio_priv_to_dev() altogether.
> > The iio_priv() helper won't be affected by the rework, as the iio_dev
> > struct will keep a reference to the private information.
> >
> > For this driver, not using iio_priv_to_dev(), means reworking some
> > paths to
> > pass the iio device and using iio_priv() to access the private
> > information.
> >
> > Signed-off-by: Alexandru Ardelean
> > ---
> > drivers/iio/adc/stm32-adc.c | 108 +++-
> > 1 file changed, 58 insertions(+), 50 deletions(-)
> >
> > diff --git a/drivers/iio/adc/stm32-adc.c b/drivers/iio/adc/stm32-adc.c
> > index ae622ee6d08c..9428c5c22712 100644
> > --- a/drivers/iio/adc/stm32-adc.c
> > +++ b/drivers/iio/adc/stm32-adc.c
> > @@ -162,10 +162,10 @@ struct stm32_adc_cfg {
> > struct stm32_adc_trig_info *trigs;
> > bool clk_required;
> > bool has_vregready;
> > - int (*prepare)(struct stm32_adc *);
> > - void (*start_conv)(struct stm32_adc *, bool dma);
> > - void (*stop_conv)(struct stm32_adc *);
> > - void (*unprepare)(struct stm32_adc *);
> > + int (*prepare)(struct iio_dev *);
> > + void (*start_conv)(struct iio_dev *, bool dma);
> > + void (*stop_conv)(struct iio_dev *);
> > + void (*unprepare)(struct iio_dev *);
> > const unsigned int *smp_cycles;
> > };
> >
> > @@ -538,10 +538,11 @@ static void stm32_adc_set_res(struct stm32_adc
> > *adc)
> >
> > static int stm32_adc_hw_stop(struct device *dev)
> > {
> > - struct stm32_adc *adc = dev_get_drvdata(dev);
> > + struct iio_dev *indio_dev = dev_get_drvdata(dev);
> > + struct stm32_adc *adc = iio_priv(indio_dev);
> >
> > if (adc->cfg->unprepare)
> > - adc->cfg->unprepare(adc);
> > + adc->cfg->unprepare(indio_dev);
> >
> > if (adc->clk)
> > clk_disable_unprepare(adc->clk);
> > @@ -551,7 +552,8 @@ static int stm32_adc_hw_stop(struct device *dev)
> >
> > static int stm32_adc_hw_start(struct device *dev)
> > {
> > - struct stm32_adc *adc = dev_get_drvdata(dev);
> > + struct iio_dev *indio_dev = dev_get_drvdata(dev);
> > + struct stm32_adc *adc = iio_priv(indio_dev);
> > int ret;
> >
> > if (adc->clk) {
> > @@ -563,7 +565,7 @@ static int stm32_adc_hw_start(struct device *dev)
> > stm32_adc_set_res(adc);
> >
> > if (adc->cfg->prepare) {
> > - ret = adc->cfg->prepare(adc);
> > + ret = adc->cfg->prepare(indio_dev);
> > if (ret)
> > goto err_clk_dis;
> > }
> > @@ -587,8 +589,10 @@ static int stm32_adc_hw_start(struct device *dev)
> > * conversions, in IIO buffer modes. Otherwise, use ADC interrupt with
> > direct
> > * DR read instead (e.g. read_raw, or triggered buffer mode without
> > DMA).
> > */
> > -static void stm32f4_adc_start_conv(struct stm32_adc *adc, bool dma)
> > +static void stm32f4_adc_start_conv(struct iio_dev *indio_dev, bool
> > dma)
>
> Hi Alexandru,
>
> I've tested your patch. I've no objection, but found few build warnings
> (some of these routines have kernel-doc style).
>
> Building with W=1 makes warnings appear, like:
> drivers/iio/adc/stm32-adc.c:593: warning: Function parameter or member
> 'indio_dev' not described in 'stm32f4_adc_start_conv'
> drivers/iio/adc/stm32-adc.c:593: warning: Excess function parameter
> 'adc' description in 'stm32f4_adc_start_conv'
> ...
>
> Could you update routine's doc as well ?
Thanks.
Will send a V3 shortly.
The W=1 option looks interesting.
We might give this to interns/new-people to get them started.
>
> e.g. something like:
> - * @adc: stm32 adc instance
> + * @indio_dev: IIO device
>
> > {
> > + struct stm32_adc *adc = iio_priv(indio_dev);
> > +
> > stm32_adc_set_bits(adc, STM32F4_ADC_CR1, STM32F4_SCAN);
> >
> > if (dma)
> > @@ -605,8 +609,10 @@ static void stm32f4_adc_start_conv(struct
> > stm32_adc *adc, bool dma)
> > stm32_adc_set_bits(adc, STM32F4_ADC_CR2, STM32F4_SWSTART);
> > }
> >
> > -static void stm32f4_adc_stop_conv(struct stm32_adc *adc)
> > +static void stm32f4_adc_stop_conv(struct iio_dev *indio_dev)
> > {
> > + struct stm32_adc *adc = iio_priv(indio_dev);
> > +
> > stm32_adc_clr_bits(adc, STM32F4_ADC_CR2, STM32F4_EXTEN_MASK);
> > stm32_adc_clr_bits(adc, STM32F4_ADC_SR, STM32F4_STRT);
> >
> > @@ -615,8 +621,9 @@ static void stm32f4_adc_stop_conv(struct stm32_adc
> > *adc)
> >
Re: [PATCH 3/3] iio: remove iio_triggered_buffer_postenable()/iio_triggered_buffer_predisable()
On Sun, 2020-05-24 at 14:38 +0100, Jonathan Cameron wrote:
> [External]
>
> On Fri, 22 May 2020 13:46:32 +0300
> Alexandru Ardelean wrote:
>
> > From: Lars-Peter Clausen
> >
> > This patch should be squashed into the first one, as the first one is
> > breaking the build (intentionally) to make the IIO core files easier to
> > review.
> >
> > Signed-off-by: Lars-Peter Clausen
> > Signed-off-by: Alexandru Ardelean
>
> Yeah! Didn't realise you'd finally gotten to the end of your mammoth rework
> leading to this.
>
> A few really minor things inline to tidy up.
Will fix these and send a V2.
>
> Thanks,
>
> Jonathan
>
>
> > diff --git a/drivers/iio/accel/st_accel_buffer.c
> > b/drivers/iio/accel/st_accel_buffer.c
> > index b5c814ef1637..c87f9a7d2453 100644
> > --- a/drivers/iio/accel/st_accel_buffer.c
> > +++ b/drivers/iio/accel/st_accel_buffer.c
> > @@ -33,13 +33,9 @@ static int st_accel_buffer_postenable(struct iio_dev
> > *indio_dev)
> > {
> > int err;
> >
> > - err = iio_triggered_buffer_postenable(indio_dev);
> > - if (err < 0)
> > - return err;
> > -
> > err = st_sensors_set_axis_enable(indio_dev, indio_dev-
> > >active_scan_mask[0]);
> > if (err < 0)
> > - goto st_accel_buffer_predisable;
> > + return err;
> >
> > err = st_sensors_set_enable(indio_dev, true);
> > if (err < 0)
> > @@ -49,8 +45,6 @@ static int st_accel_buffer_postenable(struct iio_dev
> > *indio_dev)
> >
> > st_accel_buffer_enable_all_axis:
> > st_sensors_set_axis_enable(indio_dev, ST_SENSORS_ENABLE_ALL_AXIS);
> > -st_accel_buffer_predisable:
> > - iio_triggered_buffer_predisable(indio_dev);
> > return err;
> > }
> >
> > @@ -60,12 +54,10 @@ static int st_accel_buffer_predisable(struct iio_dev
> > *indio_dev)
> >
> > err = st_sensors_set_enable(indio_dev, false);
> > if (err < 0)
> > - goto st_accel_buffer_predisable;
> > -
> > - err = st_sensors_set_axis_enable(indio_dev, ST_SENSORS_ENABLE_ALL_AXIS);
> > + return err;
> >
> > -st_accel_buffer_predisable:
> > - err2 = iio_triggered_buffer_predisable(indio_dev);
> > + err2 = st_sensors_set_axis_enable(indio_dev,
> > + ST_SENSORS_ENABLE_ALL_AXIS);
> > if (!err)
> I don't think you can get here with err set.
> > err = err2;
> >
>
> ...
>
> > diff --git a/drivers/iio/gyro/st_gyro_buffer.c
> > b/drivers/iio/gyro/st_gyro_buffer.c
> > index 9c92ff7a82be..7b86502d5da3 100644
> > --- a/drivers/iio/gyro/st_gyro_buffer.c
> > +++ b/drivers/iio/gyro/st_gyro_buffer.c
> > @@ -33,13 +33,9 @@ static int st_gyro_buffer_postenable(struct iio_dev
> > *indio_dev)
> > {
> > int err;
> >
> > - err = iio_triggered_buffer_postenable(indio_dev);
> > - if (err < 0)
> > - return err;
> > -
> > err = st_sensors_set_axis_enable(indio_dev, indio_dev-
> > >active_scan_mask[0]);
> > if (err < 0)
> > - goto st_gyro_buffer_predisable;
> > + return err;
> >
> > err = st_sensors_set_enable(indio_dev, true);
> > if (err < 0)
> > @@ -49,8 +45,6 @@ static int st_gyro_buffer_postenable(struct iio_dev
> > *indio_dev)
> >
> > st_gyro_buffer_enable_all_axis:
> > st_sensors_set_axis_enable(indio_dev, ST_SENSORS_ENABLE_ALL_AXIS);
> > -st_gyro_buffer_predisable:
> > - iio_triggered_buffer_predisable(indio_dev);
> > return err;
> > }
> >
> > @@ -59,13 +53,8 @@ static int st_gyro_buffer_predisable(struct iio_dev
> > *indio_dev)
> > int err, err2;
> >
> > err = st_sensors_set_enable(indio_dev, false);
> > - if (err < 0)
> > - goto st_gyro_buffer_predisable;
>
> Previously we didn't bother trying to carry on if this failed. I don't think
> we
> should start doing so now.
>
> > -
> > - err = st_sensors_set_axis_enable(indio_dev, ST_SENSORS_ENABLE_ALL_AXIS);
> >
> > -st_gyro_buffer_predisable:
> > - err2 = iio_triggered_buffer_predisable(indio_dev);
> > + err2 = st_sensors_set_axis_enable(indio_dev,
> > ST_SENSORS_ENABLE_ALL_AXIS);
> > if (!err)
> > err = err2;
> >
>
> ...
>
> > diff --git a/drivers/iio/light/gp2ap020a00f.c
> > b/drivers/iio/light/gp2ap020a00f.c
> > index 070d4cd0cf54..29d7af33efa1 100644
> > --- a/drivers/iio/light/gp2ap020a00f.c
> > +++ b/drivers/iio/light/gp2ap020a00f.c
> > @@ -1390,12 +1390,6 @@ static int gp2ap020a00f_buffer_postenable(struct
> > iio_dev *indio_dev)
> >
> > mutex_lock(>lock);
> I guess it doesn't matter, but no idea why this was ever under the local lock!
>
> >
> > - err = iio_triggered_buffer_postenable(indio_dev);
> > - if (err < 0) {
> > - mutex_unlock(>lock);
> > - return err;
> > - }
> > -
> > /*
> > * Enable triggers according to the scan_mask. Enabling either
> > * LIGHT_CLEAR or LIGHT_IR scan mode results in enabling ALS
> > @@ -1430,8 +1424,6 @@ static int gp2ap020a00f_buffer_postenable(struct
> > iio_dev *indio_dev)
> > err
Re: [RFC PATCH 09/14] iio: buffer: split buffer sysfs creation to take buffer as primary arg
On Sun, 2020-05-24 at 17:49 +0100, Jonathan Cameron wrote:
> [External]
>
> On Fri, 8 May 2020 16:53:43 +0300
> Alexandru Ardelean wrote:
>
> > Currently the iio_buffer_{alloc,free}_sysfs_and_mask() take 'indio_dev' as
> > primary argument. This change converts to take an IIO buffer as a primary
> > argument.
> >
> > That will allow the functions to get called for multiple buffers.
> >
> > Signed-off-by: Alexandru Ardelean
>
> Looks good to me. We'll need this whatever the interface ends up being as
> need the separate control infrastructure.
I was wanting to split this into it's own patch at some point and send it now.
I'll probably do it.
>
> Jonathan
>
> > ---
> > drivers/iio/industrialio-buffer.c | 46 ---
> > 1 file changed, 30 insertions(+), 16 deletions(-)
> >
> > diff --git a/drivers/iio/industrialio-buffer.c b/drivers/iio/industrialio-
> > buffer.c
> > index e7a847e7b103..6b1b5d5387bd 100644
> > --- a/drivers/iio/industrialio-buffer.c
> > +++ b/drivers/iio/industrialio-buffer.c
> > @@ -1312,26 +1312,14 @@ static struct attribute *iio_buffer_attrs[] = {
> > _attr_data_available.attr,
> > };
> >
> > -int iio_buffer_alloc_sysfs_and_mask(struct iio_dev *indio_dev)
> > +static int __iio_buffer_alloc_sysfs_and_mask(struct iio_buffer *buffer)
> > {
> > + struct iio_dev *indio_dev = buffer->indio_dev;
> > struct iio_dev_attr *p;
> > struct attribute **attr;
> > - struct iio_buffer *buffer = indio_dev->buffer;
> > int ret, i, attrn, attrcount, attrcount_orig = 0;
> > const struct iio_chan_spec *channels;
> >
> > - channels = indio_dev->channels;
> > - if (channels) {
> > - int ml = indio_dev->masklength;
> > -
> > - for (i = 0; i < indio_dev->num_channels; i++)
> > - ml = max(ml, channels[i].scan_index + 1);
> > - indio_dev->masklength = ml;
> > - }
> > -
> > - if (!buffer)
> > - return 0;
> > -
> > attrcount = 0;
> > if (buffer->attrs) {
> > while (buffer->attrs[attrcount] != NULL)
> > @@ -1411,19 +1399,45 @@ int iio_buffer_alloc_sysfs_and_mask(struct iio_dev
> > *indio_dev)
> > return ret;
> > }
> >
> > -void iio_buffer_free_sysfs_and_mask(struct iio_dev *indio_dev)
> > +int iio_buffer_alloc_sysfs_and_mask(struct iio_dev *indio_dev)
> > {
> > struct iio_buffer *buffer = indio_dev->buffer;
> > + const struct iio_chan_spec *channels;
> > + int i;
> > +
> > + channels = indio_dev->channels;
> > + if (channels) {
> > + int ml = indio_dev->masklength;
> > +
> > + for (i = 0; i < indio_dev->num_channels; i++)
> > + ml = max(ml, channels[i].scan_index + 1);
> > + indio_dev->masklength = ml;
> > + }
> >
> > if (!buffer)
> > - return;
> > + return 0;
> > +
> > + return __iio_buffer_alloc_sysfs_and_mask(buffer);
> > +}
> >
> > +static void __iio_buffer_free_sysfs_and_mask(struct iio_buffer *buffer)
> > +{
> > iio_buffer_free_scanmask(buffer);
> > kfree(buffer->buffer_group.attrs);
> > kfree(buffer->scan_el_group.attrs);
> > iio_free_chan_devattr_list(>scan_el_dev_attr_list);
> > }
> >
> > +void iio_buffer_free_sysfs_and_mask(struct iio_dev *indio_dev)
> > +{
> > + struct iio_buffer *buffer = indio_dev->buffer;
> > +
> > + if (!buffer)
> > + return;
> > +
> > + __iio_buffer_free_sysfs_and_mask(buffer);
> > +}
> > +
> > static const struct file_operations iio_buffer_fileops = {
> > .read = iio_buffer_read_outer,
> > .release = iio_buffer_chrdev_release,
Re: [RFC PATCH 08/14] iio: core: use new common ioctl() mechanism
On Sun, 2020-05-24 at 17:47 +0100, Jonathan Cameron wrote:
> [External]
>
> On Fri, 8 May 2020 16:53:42 +0300
> Alexandru Ardelean wrote:
>
> > This change makes use of the new centralized ioctl() mechanism. The event
> > interface registers it's ioctl() handler to IIO device.
> > Both the buffer & event interface call 'iio_device_ioctl()', which should
> > take care of all of indio_dev's ioctl() calls.
> >
> > Later, we may add per-buffer ioctl() calls, and since each buffer will get
> > it's own chardev, the buffer ioctl() handler will need a bit of tweaking
> > for the first/legacy buffer (i.e. indio_dev->buffer).
>
> Do we have an ioctls that aren't safe if we just use them on 'any'
> buffer? I don't think we do yet, though I guess we may have in the future.
>
This was done in the idea that we may want to keep the /dev/iio:deviceX for
backwards compatibility.
But, it's undetermined yet how this will look.
I am currently working on more rework stuff [as you've seen].
I'd try to do some of the rework now, before adding more stuff [like
iio_dev_opaque].
To avoid adding this work, then having to rework it.
>
> > Also, those per-buffer ioctl() calls will not be registered with this
> > mechanism.
> >
> > Signed-off-by: Alexandru Ardelean
> > ---
> > drivers/iio/iio_core.h| 3 ---
> > drivers/iio/industrialio-buffer.c | 2 +-
> > drivers/iio/industrialio-event.c | 14 --
> > 3 files changed, 9 insertions(+), 10 deletions(-)
> >
> > diff --git a/drivers/iio/iio_core.h b/drivers/iio/iio_core.h
> > index 34c3e19229d8..f68de4af2738 100644
> > --- a/drivers/iio/iio_core.h
> > +++ b/drivers/iio/iio_core.h
> > @@ -54,9 +54,6 @@ ssize_t iio_format_value(char *buf, unsigned int type, int
> > size, int *vals);
> > #ifdef CONFIG_IIO_BUFFER
> > struct poll_table_struct;
> >
> > -long iio_device_event_ioctl(struct iio_dev *indio_dev, struct file *filp,
> > - unsigned int cmd, unsigned long arg);
> > -
> > void iio_device_buffer_attach_chrdev(struct iio_dev *indio_dev);
> >
> > int iio_buffer_alloc_sysfs_and_mask(struct iio_dev *indio_dev);
> > diff --git a/drivers/iio/industrialio-buffer.c b/drivers/iio/industrialio-
> > buffer.c
> > index 1400688f5e42..e7a847e7b103 100644
> > --- a/drivers/iio/industrialio-buffer.c
> > +++ b/drivers/iio/industrialio-buffer.c
> > @@ -1199,7 +1199,7 @@ static long iio_buffer_ioctl(struct file *filep,
> > unsigned int cmd,
> > if (!buffer || !buffer->access)
> > return -ENODEV;
> >
> > - return iio_device_event_ioctl(buffer->indio_dev, filep, cmd, arg);
> > + return iio_device_ioctl(buffer->indio_dev, filep, cmd, arg);
> > }
> >
> > static ssize_t iio_buffer_store_enable(struct device *dev,
> > diff --git a/drivers/iio/industrialio-event.c b/drivers/iio/industrialio-
> > event.c
> > index 0674b2117c98..1961c1d19370 100644
> > --- a/drivers/iio/industrialio-event.c
> > +++ b/drivers/iio/industrialio-event.c
> > @@ -32,6 +32,7 @@
> > * @read_lock: lock to protect kfifo read operations
> > * @chrdev:associated chardev for this event
> > * @indio_dev: IIO device to which this event interface belongs
> > to
> > + * @ioctl_handler: handler for event ioctl() calls
> > */
> > struct iio_event_interface {
> > wait_queue_head_t wait;
> > @@ -44,6 +45,7 @@ struct iio_event_interface {
> >
> > struct cdev chrdev;
> > struct iio_dev *indio_dev;
> > + struct iio_ioctl_handlerioctl_handler;
> > };
> >
> > bool iio_event_enabled(const struct iio_event_interface *ev_int)
> > @@ -261,15 +263,12 @@ static int iio_chrdev_release(struct inode *inode,
> > struct file *filp)
> > return 0;
> > }
> >
> > -long iio_device_event_ioctl(struct iio_dev *indio_dev, struct file *filp,
> > +static long iio_event_ioctl(struct iio_dev *indio_dev, struct file *filp,
> > unsigned int cmd, unsigned long arg)
> > {
> > int __user *ip = (int __user *)arg;
> > int fd;
> >
> > - if (!indio_dev->info)
> > - return -ENODEV;
> > -
> > if (cmd == IIO_GET_EVENT_FD_IOCTL) {
> > fd = iio_event_getfd(indio_dev);
> > if (fd < 0)
> > @@ -278,7 +277,7 @@ long iio_device_event_ioctl(struct iio_dev *indio_dev,
> > struct file *filp,
> > return -EFAULT;
> > return 0;
> > }
> > - return -EINVAL;
> > + return IIO_IOCTL_UNHANDLED;
> > }
> >
> > static long iio_event_ioctl_wrapper(struct file *filp, unsigned int cmd,
> > @@ -286,7 +285,7 @@ static long iio_event_ioctl_wrapper(struct file *filp,
> > unsigned int cmd,
> > {
> > struct iio_event_interface *ev = filp->private_data;
> >
> > - return iio_device_event_ioctl(ev->indio_dev, filp, cmd, arg);
> > + return iio_device_ioctl(ev->indio_dev, filp, cmd, arg);
> > }
> >
> > static const struct file_operations iio_event_fileops = {
> > @@ -308,7 +307,10 @@ void
Re: [RFC PATCH 07/14] iio: core: add simple centralized mechanism for ioctl() handlers
On Sun, 2020-05-24 at 17:45 +0100, Jonathan Cameron wrote:
> [External]
>
> On Fri, 8 May 2020 16:53:41 +0300
> Alexandru Ardelean wrote:
>
> > The aim of this is to reduce the organization violation of ioctl() calls in
> > IIO core. Currently, since the chardev is split across files, event ioctl()
> > calls need to be called in buffer ioctl() calls.
> >
> > The 'industrialio-core.c' file will provide a 'iio_device_ioctl()' which
> > will iterate over a list of ioctls registered with the IIO device. These
> > can be event ioctl() or buffer ioctl() calls, or something else.
> > This is needed, since there is currently one chardev per IIO device and
> > that is used for both event handling and reading from the buffer.
> >
> > Each ioctl() will have to return a IIO_IOCTL_UNHANDLED code (which is
> > positive 1), if the ioctl() did not handle the call in any. This eliminates
> > any potential ambiguities; if we were to have used error codes it would
> > have been uncertain whether they were actual errors, or whether
> > the registered ioctl() doesn't service the command.
> >
> > If any ioctl() returns 0, it was considered that it was serviced
> > successfully and the loop will exit.
> >
> > One assumption for all registered ioctl() handlers is that they are
> > statically allocated, so the iio_device_unregister() which just remove all
> > of them from the device's ioctl() handler list.
> >
> > Also, something that is a bit hard to do [at this point] and may not be
> > worth the effort of doing, is to check whether registered ioctl()
> > calls/commands overlap. This should be unlikely to happen, and should get
> > caught at review time. Though, new ioctl() calls would likely not be added
> > too often.
> >
> > Signed-off-by: Alexandru Ardelean
>
> We seem to have dropped the locking in here. What am I missing that
> stops us racing a remove with the ioctl? If there is a reason that
> can't race, please add comments there so I don't wonders sometime in
> the future.
>
Yeah.
My bad about the locking.
I have too many branches for this stuff.
But for the chardev split, there's a branch that should have the locking in
place.
I'll re-check that, when sending only the chardev split anyway.
> The check on iio_dev->info means we won't start the ioctl if the
> remove has been called, but if we switch immediately after that,
> anything can happen before we start calling the ioctls.
>
> J
>
> > ---
> > drivers/iio/iio_core.h | 14 ++
> > drivers/iio/industrialio-core.c | 33 +
> > include/linux/iio/iio.h | 2 ++
> > 3 files changed, 49 insertions(+)
> >
> > diff --git a/drivers/iio/iio_core.h b/drivers/iio/iio_core.h
> > index a527a66be9e5..34c3e19229d8 100644
> > --- a/drivers/iio/iio_core.h
> > +++ b/drivers/iio/iio_core.h
> > @@ -17,6 +17,20 @@ struct iio_dev;
> >
> > extern struct device_type iio_device_type;
> >
> > +#define IIO_IOCTL_UNHANDLED1
> > +struct iio_ioctl_handler {
> > + struct list_head entry;
> > + long (*ioctl)(struct iio_dev *indio_dev, struct file *filp,
> > + unsigned int cmd, unsigned long arg);
> > +};
> > +
> > +long iio_device_ioctl(struct iio_dev *indio_dev, struct file *filp,
> > + unsigned int cmd, unsigned long arg);
> > +
> > +void iio_device_ioctl_handler_register(struct iio_dev *indio_dev,
> > + struct iio_ioctl_handler *h);
> > +void iio_device_ioctl_handler_unregister(struct iio_ioctl_handler *h);
> > +
> > int __iio_add_chan_devattr(const char *postfix,
> >struct iio_chan_spec const *chan,
> >ssize_t (*func)(struct device *dev,
> > diff --git a/drivers/iio/industrialio-core.c b/drivers/iio/industrialio-
> > core.c
> > index 32e045c7f0c1..5df3af5e7dcb 100644
> > --- a/drivers/iio/industrialio-core.c
> > +++ b/drivers/iio/industrialio-core.c
> > @@ -1534,6 +1534,7 @@ struct iio_dev *iio_device_alloc(int sizeof_priv)
> > }
> > dev_set_name(>dev, "iio:device%d", dev->id);
> > INIT_LIST_HEAD(>buffer_list);
> > + INIT_LIST_HEAD(>ioctl_handlers);
> >
> > return dev;
> > }
> > @@ -1587,6 +1588,33 @@ struct iio_dev *devm_iio_device_alloc(struct device
> > *dev, int sizeof_priv)
> > }
> > EXPORT_SYMBOL_GPL(devm_iio_device_alloc);
> >
> > +void iio_device_ioctl_handler_register(struct iio_dev *indio_dev,
> > + struct iio_ioctl_handler *h)
> > +{
> > + /* this assumes that all ioctl() handlers are statically allocated */
> > + list_add_tail(>entry, _dev->ioctl_handlers);
> > +}
> > +
> > +long iio_device_ioctl(struct iio_dev *indio_dev, struct file *filp,
> > + unsigned int cmd, unsigned long arg)
> > +{
> > + struct iio_ioctl_handler *h;
> > + int ret;
> > +
> > + if (!indio_dev->info)
> > + return -ENODEV;
>
> The locking is gone?
> > +
> > + list_for_each_entry(h, _dev->ioctl_handlers,
Re: [PATCH] iio: humidity: hts221: remove usage of iio_priv_to_dev()
On Sun, 2020-05-24 at 15:39 +0100, Jonathan Cameron wrote:
> [External]
>
> On Fri, 22 May 2020 09:56:16 +0300
> Alexandru Ardelean wrote:
>
> > We may want to get rid of the iio_priv_to_dev() helper. That's a bit
> > uncertain at this point. The reason is that we will hide some of the
> > members of the iio_dev structure (to prevent drivers from accessing them
> > directly), and that will also mean hiding the implementation of the
> > iio_priv_to_dev() helper inside the IIO core.
> >
> > Hiding the implementation of iio_priv_to_dev() implies that some fast-paths
> > may not be fast anymore, so a general idea is to try to get rid of the
> > iio_priv_to_dev() altogether.
> >
> > For this driver, removing the iio_priv_to_dev() helper means passing the
> > iio_dev object on hts221_allocate_buffers() & hts221_allocate_trigger().
> >
> > Signed-off-by: Alexandru Ardelean
>
> The hts221_hw structure is in iio_priv() so perhaps we could
> drop passing that into these two calls and get it from iio_priv
> within the functions?
>
> I tidied that up whilst applying. Shout if you disagree and I'll
> back it out :)
Fine by me.
I usually go, for the lazy/narrow-view-path sometimes, when doing these changes.
Which [in this case] was to get rid of iio_priv_to_dev()
>
> Applied to the the togreg branch of iio.git and pushed out as
> testing for the autobuilders to play with it.
>
> Thanks,
>
> Jonathan
>
> > ---
> > drivers/iio/humidity/hts221.h| 4 ++--
> > drivers/iio/humidity/hts221_buffer.c | 7 +++
> > drivers/iio/humidity/hts221_core.c | 4 ++--
> > 3 files changed, 7 insertions(+), 8 deletions(-)
> >
> > diff --git a/drivers/iio/humidity/hts221.h b/drivers/iio/humidity/hts221.h
> > index 7d6771f7cf47..569146910885 100644
> > --- a/drivers/iio/humidity/hts221.h
> > +++ b/drivers/iio/humidity/hts221.h
> > @@ -46,7 +46,7 @@ extern const struct dev_pm_ops hts221_pm_ops;
> > int hts221_probe(struct device *dev, int irq, const char *name,
> > struct regmap *regmap);
> > int hts221_set_enable(struct hts221_hw *hw, bool enable);
> > -int hts221_allocate_buffers(struct hts221_hw *hw);
> > -int hts221_allocate_trigger(struct hts221_hw *hw);
> > +int hts221_allocate_buffers(struct hts221_hw *hw, struct iio_dev *iio_dev);
> > +int hts221_allocate_trigger(struct hts221_hw *hw, struct iio_dev *iio_dev);
> >
> > #endif /* HTS221_H */
> > diff --git a/drivers/iio/humidity/hts221_buffer.c
> > b/drivers/iio/humidity/hts221_buffer.c
> > index 9fb3f33614d4..48d469eeb0e6 100644
> > --- a/drivers/iio/humidity/hts221_buffer.c
> > +++ b/drivers/iio/humidity/hts221_buffer.c
> > @@ -72,10 +72,9 @@ static irqreturn_t hts221_trigger_handler_thread(int irq,
> > void *private)
> > return IRQ_HANDLED;
> > }
> >
> > -int hts221_allocate_trigger(struct hts221_hw *hw)
> > +int hts221_allocate_trigger(struct hts221_hw *hw, struct iio_dev *iio_dev)
> > {
> > struct st_sensors_platform_data *pdata = dev_get_platdata(hw->dev);
> > - struct iio_dev *iio_dev = iio_priv_to_dev(hw);
> > bool irq_active_low = false, open_drain = false;
> > unsigned long irq_type;
> > int err;
> > @@ -190,9 +189,9 @@ static irqreturn_t hts221_buffer_handler_thread(int irq,
> > void *p)
> > return IRQ_HANDLED;
> > }
> >
> > -int hts221_allocate_buffers(struct hts221_hw *hw)
> > +int hts221_allocate_buffers(struct hts221_hw *hw, struct iio_dev *iio_dev)
> > {
> > - return devm_iio_triggered_buffer_setup(hw->dev, iio_priv_to_dev(hw),
> > + return devm_iio_triggered_buffer_setup(hw->dev, iio_dev,
> > NULL, hts221_buffer_handler_thread,
> > _buffer_ops);
> > }
> > diff --git a/drivers/iio/humidity/hts221_core.c
> > b/drivers/iio/humidity/hts221_core.c
> > index 9003671f14fb..77dfa65df841 100644
> > --- a/drivers/iio/humidity/hts221_core.c
> > +++ b/drivers/iio/humidity/hts221_core.c
> > @@ -621,11 +621,11 @@ int hts221_probe(struct device *dev, int irq, const
> > char *name,
> > }
> >
> > if (hw->irq > 0) {
> > - err = hts221_allocate_buffers(hw);
> > + err = hts221_allocate_buffers(hw, iio_dev);
> > if (err < 0)
> > return err;
> >
> > - err = hts221_allocate_trigger(hw);
> > + err = hts221_allocate_trigger(hw, iio_dev);
> > if (err)
> > return err;
> > }
Re: [PATCH v2 0/8] iio: core: wrap IIO device into an iio_dev_opaque object
On Thu, 2020-05-14 at 16:17 +0300, Alexandru Ardelean wrote: > This change starts to hide some internal fields of the IIO device into > the framework. > > Because the iio_priv_to_dev() will be hidden some pre-work is done to > try to remove it from some interrupt handlers. > iio_priv_to_dev() will become a function call and won't be expandable > into place (as-is now as an inline function). > I'll defer this series. A cleanup of iio_priv_to_dev() doesn't look like a bit detour. > Changelog v1 -> v2: > - add pre-work patches that remove some calls to iio_priv_to_dev() from > interrupt handlers > - renamed iio_dev_priv -> iio_dev_opaque > - moved the iio_dev_opaque to 'include/linux/iio/iio-opaque.h' this way > it should be usable for debugging > - the iio_priv() call, is still an inline function that returns an > 'indio_dev->priv' reference; this field is added to 'struct iio_dev'; > the reference is computed in iio_device_alloc() and should be > cacheline aligned > - the to_iio_dev_opaque() container is in the > 'include/linux/iio/iio-opaque.h' header; it's still implemented with > some pointer arithmetic; one idea was to do it via an > 'indio_dev->opaque' field; that may still be an optionif there are > some opinions in that direction > > Alexandru Ardelean (8): > iio: proximity: ping: pass reference to IIO device via call-stack > iio: at91-sama5d2_adc: pass ref to IIO device via param for int > function > iio: at91_adc: pass ref to IIO device via param for int function > iio: stm32-dfsdm-adc: pass iio device as arg for the interrupt handler > iio: stm32-adc: pass iio device as arg for the interrupt handler > iio: core: wrap IIO device into an iio_dev_opaque object > iio: core: simplify alloc alignment code > iio: core: move debugfs data on the private iio dev info > > drivers/iio/adc/at91-sama5d2_adc.c | 7 ++- > drivers/iio/adc/at91_adc.c | 5 +- > drivers/iio/adc/stm32-adc.c| 10 ++-- > drivers/iio/adc/stm32-dfsdm-adc.c | 6 +-- > drivers/iio/industrialio-core.c| 75 -- > drivers/iio/proximity/ping.c | 5 +- > include/linux/iio/iio-opaque.h | 27 +++ > include/linux/iio/iio.h| 24 +++--- > 8 files changed, 99 insertions(+), 60 deletions(-) > create mode 100644 include/linux/iio/iio-opaque.h >
Re: [PATCH] iio: dac: ad5592r-base: Replace indio_dev->mlock with own device lock
On Wed, 2020-05-20 at 09:18 +0300, Sergiu Cuciurean wrote:
> [External]
>
> As part of the general cleanup of indio_dev->mlock, this change replaces
> it with a local lock on the device's state structure.
>
This requires a V2.
It produces a warning:
159 | struct iio_dev *iio_dev = iio_priv_to_dev(st);
| ^~~
drivers/iio/dac/ad5592r-base.c: In function ‘ad5592r_set_channel_modes’:
drivers/iio/dac/ad5592r-base.c:200:18: warning: unused variable ‘iio_dev’
[-Wunused-variable]
200 | struct iio_dev *iio_dev = iio_priv_to_dev(st);
You can remove both instances of
struct iio_dev *iio_dev = iio_priv_to_dev(st);
> Signed-off-by: Sergiu Cuciurean
> ---
> drivers/iio/dac/ad5592r-base.c | 28 +++-
> drivers/iio/dac/ad5592r-base.h | 1 +
> 2 files changed, 16 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/iio/dac/ad5592r-base.c b/drivers/iio/dac/ad5592r-
> base.c
> index e2110113e884..10109eb81db2 100644
> --- a/drivers/iio/dac/ad5592r-base.c
> +++ b/drivers/iio/dac/ad5592r-base.c
> @@ -166,10 +166,10 @@ static int ad5592r_reset(struct ad5592r_state *st)
> udelay(1);
> gpiod_set_value(gpio, 1);
> } else {
> - mutex_lock(_dev->mlock);
> + mutex_lock(>lock);
> /* Writing this magic value resets the device */
> st->ops->reg_write(st, AD5592R_REG_RESET, 0xdac);
> - mutex_unlock(_dev->mlock);
> + mutex_unlock(>lock);
> }
>
> udelay(250);
> @@ -247,7 +247,7 @@ static int ad5592r_set_channel_modes(struct
> ad5592r_state *st)
> }
> }
>
> - mutex_lock(_dev->mlock);
> + mutex_lock(>lock);
>
> /* Pull down unused pins to GND */
> ret = ops->reg_write(st, AD5592R_REG_PULLDOWN, pulldown);
> @@ -285,7 +285,7 @@ static int ad5592r_set_channel_modes(struct
> ad5592r_state *st)
> ret = -EIO;
>
> err_unlock:
> - mutex_unlock(_dev->mlock);
> + mutex_unlock(>lock);
> return ret;
> }
>
> @@ -314,11 +314,11 @@ static int ad5592r_write_raw(struct iio_dev
> *iio_dev,
> if (!chan->output)
> return -EINVAL;
>
> - mutex_lock(_dev->mlock);
> + mutex_lock(>lock);
> ret = st->ops->write_dac(st, chan->channel, val);
> if (!ret)
> st->cached_dac[chan->channel] = val;
> - mutex_unlock(_dev->mlock);
> + mutex_unlock(>lock);
> return ret;
> case IIO_CHAN_INFO_SCALE:
> if (chan->type == IIO_VOLTAGE) {
> @@ -333,12 +333,12 @@ static int ad5592r_write_raw(struct iio_dev
> *iio_dev,
> else
> return -EINVAL;
>
> - mutex_lock(_dev->mlock);
> + mutex_lock(>lock);
>
> ret = st->ops->reg_read(st, AD5592R_REG_CTRL,
> >cached_gp_ctrl);
> if (ret < 0) {
> - mutex_unlock(_dev->mlock);
> + mutex_unlock(>lock);
> return ret;
> }
>
> @@ -360,7 +360,7 @@ static int ad5592r_write_raw(struct iio_dev *iio_dev,
>
> ret = st->ops->reg_write(st, AD5592R_REG_CTRL,
>st->cached_gp_ctrl);
> - mutex_unlock(_dev->mlock);
> + mutex_unlock(>lock);
>
> return ret;
> }
> @@ -382,7 +382,7 @@ static int ad5592r_read_raw(struct iio_dev *iio_dev,
>
> switch (m) {
> case IIO_CHAN_INFO_RAW:
> - mutex_lock(_dev->mlock);
> + mutex_lock(>lock);
>
> if (!chan->output) {
> ret = st->ops->read_adc(st, chan->channel,
> _val);
> @@ -419,7 +419,7 @@ static int ad5592r_read_raw(struct iio_dev *iio_dev,
> } else {
> int mult;
>
> - mutex_lock(_dev->mlock);
> + mutex_lock(>lock);
>
> if (chan->output)
> mult = !!(st->cached_gp_ctrl &
> @@ -437,7 +437,7 @@ static int ad5592r_read_raw(struct iio_dev *iio_dev,
> case IIO_CHAN_INFO_OFFSET:
> ret = ad5592r_get_vref(st);
>
> - mutex_lock(_dev->mlock);
> + mutex_lock(>lock);
>
> if (st->cached_gp_ctrl & AD5592R_REG_CTRL_ADC_RANGE)
> *val = (-34365 * 25) / ret;
> @@ -450,7 +450,7 @@ static int ad5592r_read_raw(struct iio_dev *iio_dev,
> }
>
> unlock:
> - mutex_unlock(_dev->mlock);
> + mutex_unlock(>lock);
> return ret;
> }
>
> @@ -625,6 +625,8 @@ int ad5592r_probe(struct device *dev, const char
> *name,
> iio_dev->info = _info;
> iio_dev->modes =
Re: [PATCH v2 3/8] iio: at91_adc: pass ref to IIO device via param for int function
On Sat, 2020-05-16 at 18:17 +0100, Jonathan Cameron wrote:
> [External]
>
> On Thu, 14 May 2020 16:17:05 +0300
> Alexandru Ardelean wrote:
>
> > Since there will be some changes to how iio_priv_to_dev() is implemented,
> > it could be that the helper becomes a bit slower, as it will be hidden away
> > in the IIO core.
> >
> > For this driver, the IIO device can be passed directly as a parameter to
> > the at91_ts_sample() function, thus making it immune to the change of
> > iio_priv_to_dev().
> > The function gets called in an interrupt context.
> >
> > Signed-off-by: Alexandru Ardelean
> I wonder. Should we just pass the struct device? It's only used for
> error printing I think, so we could make that explicit.
I was also thinking that for this series, [for some drivers] it would make sense
to put a reference to indio_dev on the state-struct; and just return it.
I'll see about it.
I am feeling that sometimes these IIO core cleanups end up being more than I
want to do. But I'll try to see about it. Maybe I can make time or delegate some
of this.
My personal interest with them, is to reduce my complaints during reviews.
People starting to write IIO drivers: well, I can see their frustration [on
their faces] when I complain that they shouldn't use something, and they copied
it from somewhere.
>
> I'm not that bothered either way though.
>
> Jonathan
>
> > ---
> > drivers/iio/adc/at91_adc.c | 5 ++---
> > 1 file changed, 2 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/iio/adc/at91_adc.c b/drivers/iio/adc/at91_adc.c
> > index 0368b6dc6d60..5999defe47cd 100644
> > --- a/drivers/iio/adc/at91_adc.c
> > +++ b/drivers/iio/adc/at91_adc.c
> > @@ -287,13 +287,12 @@ static void handle_adc_eoc_trigger(int irq, struct
> > iio_dev *idev)
> > }
> > }
> >
> > -static int at91_ts_sample(struct at91_adc_state *st)
> > +static int at91_ts_sample(struct iio_dev *idev, struct at91_adc_state *st)
> > {
> > unsigned int xscale, yscale, reg, z1, z2;
> > unsigned int x, y, pres, xpos, ypos;
> > unsigned int rxp = 1;
> > unsigned int factor = 1000;
> > - struct iio_dev *idev = iio_priv_to_dev(st);
> >
> > unsigned int xyz_mask_bits = st->res;
> > unsigned int xyz_mask = (1 << xyz_mask_bits) - 1;
> > @@ -449,7 +448,7 @@ static irqreturn_t at91_adc_9x5_interrupt(int irq, void
> > *private)
> >
> > if (status & AT91_ADC_ISR_PENS) {
> > /* validate data by pen contact */
> > - at91_ts_sample(st);
> > + at91_ts_sample(idev, st);
> > } else {
> > /* triggered by event that is no pen contact, just read
> > * them to clean the interrupt and discard all.
Re: [PATCH 1/3] iio: core: wrap IIO device into a iio_dev_priv object
On Sat, 2020-05-16 at 17:29 +0100, Jonathan Cameron wrote:
> [External]
>
> On Tue, 12 May 2020 11:26:08 +
> "Ardelean, Alexandru" wrote:
>
> > On Mon, 2020-05-11 at 18:42 +0100, Jonathan Cameron wrote:
> > > [External]
> > >
> > > On Mon, 11 May 2020 09:16:32 +
> > > "Ardelean, Alexandru" wrote:
> > >
> > > > On Fri, 2020-05-08 at 16:44 +0100, Jonathan Cameron wrote:
> > > > > [External]
> > > > >
> > > > > On Fri, 8 May 2020 16:40:15 +0100
> > > > > Jonathan Cameron wrote:
> > > > >
> > > > > > On Fri, 8 May 2020 17:13:04 +0300
> > > > > > Alexandru Ardelean wrote:
> > > > > >
> > > > > > > There are plenty of bad designs we want to discourage or not have
> > > > > > > to
> > > > > > > review
> > > > > > > manually usually about accessing private (marked as [INTERN])
> > > > > > > fields
> > > > > > > of
> > > > > > > 'struct iio_dev'.
> > > > > >
> > > > > > This has been on the todo list for many years so great you are
> > > > > > having a
> > > > > > go.
> > > > > >
> > > > > > > This is difficult, as a lot of users copy drivers, and not always
> > > > > > > the
> > > > > > > best
> > > > > > > examples.
> > > > > > >
> > > > > > > A better idea is to hide those fields into the framework.
> > > > > > > For 'struct iio_dev' this is a 'struct iio_dev_priv' which wraps a
> > > > > > > public
> > > > > > > 'struct iio_dev' object.
> > > > > > >
> > > > > > > In the next patches, some fields will be moved to this new struct,
> > > > > > > each
> > > > > > > with it's own rework.
> > > > > > >
> > > > > > > This rework will not be complete[-able] for a while, as many
> > > > > > > fields
> > > > > > > need
> > > > > > > some drivers to be reworked in order to finalize them
> > > > > > > (e.g. 'indio_dev->mlock').
> > > > > > >
> > > > > > > But some fields can already be moved, and in time, all of them may
> > > > > > > get
> > > > > > > there (in the 'struct iio_dev_priv' object).
> > > > > > >
> > > > > > > We also need to hide the implementations for 'iio_priv()' &
> > > > > > > 'iio_priv_to_dev()', as the pointer arithmetic will not match once
> > > > > > > things
> > > > > > > are moved.
> > > > > >
> > > > > > This last bit has the disadvantage of potentially putting a function
> > > > > > call in some fast paths where there wasn't one before.
> > > >
> > > > Hmm.
> > > > I think we can change this to have a void *ptr in the public iio.h
> > > > header
> > > > and
> > > > that points to the private data in the private struct, and we compute it
> > > > once,
> > > > and just return it.
> > > >
> > > > so:
> > > >
> > > > struct iio_dev_opaque;
> > > >
> > > > struct iio_dev {
> > > > struct iio_dev_opaque *opaque; // compute this during
> > > > iio_device_alloc()
> > > > void *priv; // compute this during
> > > > iio_device_alloc()
> > > > };
> > > >
> > > > static inline void *iio_priv(const struct iio_dev *indio_dev)
> > > > {
> > > > return indio_dev->priv;
> > > > }
> > > >
> > > > [ or even just convert it to a macro ; no preference ]
> > >
> > > That works for me and avoids any of the messy stuff below.
> > >
> > > Make sure to add a comment that the region that points to is guaranteed
> > > to maintain cacheline alignment as thats hidden now.
> >
> > 1 note: I would still need to hide the iio_priv_to_dev() implementation.
> > It's a bit hard not to; or I can't come up with a good idea now, like for
> > iio_priv().
>
Re: [RFC PATCH 00/14] iio: buffer: add support for multiple buffers
On Sat, 2020-05-16 at 17:24 +0100, Jonathan Cameron wrote: > [External] > > On Sat, 16 May 2020 13:08:46 + > "Ardelean, Alexandru" wrote: > > > On Tue, 2020-05-12 at 06:26 +, Ardelean, Alexandru wrote: > > > [External] > > > > > > On Mon, 2020-05-11 at 21:56 +0200, Lars-Peter Clausen wrote: > > > > [External] > > > > > > > > On 5/11/20 4:56 PM, Ardelean, Alexandru wrote: > > > > > On Mon, 2020-05-11 at 15:58 +0200, Lars-Peter Clausen wrote: > > > > > > [External] > > > > > > > > > > > > On 5/11/20 3:24 PM, Ardelean, Alexandru wrote: > > > > > > > On Mon, 2020-05-11 at 13:03 +, Ardelean, Alexandru wrote: > > > > > > > > [External] > > > > > > > > > > > > > > > > On Mon, 2020-05-11 at 12:37 +0200, Lars-Peter Clausen wrote: > > > > > > > > > [External] > > > > > > > > > > > > > > > > > > On 5/11/20 12:33 PM, Ardelean, Alexandru wrote: > > > > > > > > > > On Sun, 2020-05-10 at 11:09 +0100, Jonathan Cameron wrote: > > > > > > > > > > > [External] > > > > > > > > > > > > > > > > > > > > > > On Sat, 9 May 2020 10:52:14 +0200 > > > > > > > > > > > Lars-Peter Clausen wrote: > > > > > > > > > > > > > > > > > > > > > > > On 5/8/20 3:53 PM, Alexandru Ardelean wrote: > > > > > > > > > > > > > [...] > > > > > > > > > > > > > What I don't like, is that iio:device3 has > > > > > > > > > > > > > iio:buffer3:0 > > > > > > > > > > > > > (to > > > > > > > > > > > > > 3). > > > > > > > > > > > > > This is because the 'buffer->dev.parent = > > > > > > > > > > > > > _dev- > > > > > > > > > > > > > > dev'. > > > > > > > > > > > > > But I do feel this is correct. > > > > > > > > > > > > > So, now I don't know whether to leave it like that or > > > > > > > > > > > > > symlink to > > > > > > > > > > > > > shorter > > > > > > > > > > > > > versions like 'iio:buffer3:Y' -> > > > > > > > > > > > > > 'iio:device3/bufferY'. > > > > > > > > > > > > > The reason for naming the IIO buffer devices to > > > > > > > > > > > > > 'iio:bufferX:Y' > > > > > > > > > > > > > is > > > > > > > > > > > > > mostly to make the names unique. It would have looked > > > > > > > > > > > > > weird > > > > > > > > > > > > > to > > > > > > > > > > > > > do > > > > > > > > > > > > > '/dev/buffer1' if I would have named the buffer > > > > > > > > > > > > > devices > > > > > > > > > > > > > 'bufferX'. > > > > > > > > > > > > > > > > > > > > > > > > > > So, now I'm thinking of whether all this is > > > > > > > > > > > > > acceptable. > > > > > > > > > > > > > Or what is acceptable? > > > > > > > > > > > > > Should I symlink 'iio:device3/iio:buffer3:0' -> > > > > > > > > > > > > > 'iio:device3/buffer0'? > > > > > > > > > > > > > What else should I consider moving forward? > > > > > > > > > > > > > What means forward? > > > > > > > > > > > > > Where did I leave my beer? > > > > > > > > > > > > Looking at how the /dev/ devices are named I think we > > > > > > > > > > > > can > > > > > > > > > > > > provide > > > > > > > > > > > > a > > &
Re: [RFC PATCH 00/14] iio: buffer: add support for multiple buffers
On Tue, 2020-05-12 at 06:26 +, Ardelean, Alexandru wrote: > [External] > > On Mon, 2020-05-11 at 21:56 +0200, Lars-Peter Clausen wrote: > > [External] > > > > On 5/11/20 4:56 PM, Ardelean, Alexandru wrote: > > > On Mon, 2020-05-11 at 15:58 +0200, Lars-Peter Clausen wrote: > > > > [External] > > > > > > > > On 5/11/20 3:24 PM, Ardelean, Alexandru wrote: > > > > > On Mon, 2020-05-11 at 13:03 +, Ardelean, Alexandru wrote: > > > > > > [External] > > > > > > > > > > > > On Mon, 2020-05-11 at 12:37 +0200, Lars-Peter Clausen wrote: > > > > > > > [External] > > > > > > > > > > > > > > On 5/11/20 12:33 PM, Ardelean, Alexandru wrote: > > > > > > > > On Sun, 2020-05-10 at 11:09 +0100, Jonathan Cameron wrote: > > > > > > > > > [External] > > > > > > > > > > > > > > > > > > On Sat, 9 May 2020 10:52:14 +0200 > > > > > > > > > Lars-Peter Clausen wrote: > > > > > > > > > > > > > > > > > > > On 5/8/20 3:53 PM, Alexandru Ardelean wrote: > > > > > > > > > > > [...] > > > > > > > > > > > What I don't like, is that iio:device3 has iio:buffer3:0 > > > > > > > > > > > (to > > > > > > > > > > > 3). > > > > > > > > > > > This is because the 'buffer->dev.parent = _dev- > > > > > > > > > > > >dev'. > > > > > > > > > > > But I do feel this is correct. > > > > > > > > > > > So, now I don't know whether to leave it like that or > > > > > > > > > > > symlink to > > > > > > > > > > > shorter > > > > > > > > > > > versions like 'iio:buffer3:Y' -> 'iio:device3/bufferY'. > > > > > > > > > > > The reason for naming the IIO buffer devices to > > > > > > > > > > > 'iio:bufferX:Y' > > > > > > > > > > > is > > > > > > > > > > > mostly to make the names unique. It would have looked > > > > > > > > > > > weird > > > > > > > > > > > to > > > > > > > > > > > do > > > > > > > > > > > '/dev/buffer1' if I would have named the buffer devices > > > > > > > > > > > 'bufferX'. > > > > > > > > > > > > > > > > > > > > > > So, now I'm thinking of whether all this is acceptable. > > > > > > > > > > > Or what is acceptable? > > > > > > > > > > > Should I symlink 'iio:device3/iio:buffer3:0' -> > > > > > > > > > > > 'iio:device3/buffer0'? > > > > > > > > > > > What else should I consider moving forward? > > > > > > > > > > > What means forward? > > > > > > > > > > > Where did I leave my beer? > > > > > > > > > > Looking at how the /dev/ devices are named I think we can > > > > > > > > > > provide > > > > > > > > > > a > > > > > > > > > > name > > > > > > > > > > that is different from the dev_name() of the device. Have a > > > > > > > > > > look > > > > > > > > > > at > > > > > > > > > > device_get_devnode() in drivers/base/core.c. We should be > > > > > > > > > > able > > > > > > > > > > to > > > > > > > > > > provide the name for the chardev through the devnode() > > > > > > > > > > callback. > > > > > > > > > > > > > > > > > > > > While we are at this, do we want to move the new devices > > > > > > > > > > into > > > > > > > > > > an > > > > > > > > > > iio > > > > > > > > > > subfolder? So iio/buffer0:0 instead of iio:buffer0:0? > > > > > > > > > Possibly on the folder. I c
Re: [PATCH v2 7/8] iio: core: simplify alloc alignment code
On Fri, 2020-05-15 at 07:12 +, Sa, Nuno wrote:
> Hey Alex,
>
> Just a small question...
>
> > From: linux-iio-ow...@vger.kernel.org
> > On Behalf Of Alexandru Ardelean
> > Sent: Donnerstag, 14. Mai 2020 15:17
> > To: linux-...@vger.kernel.org; linux-arm-ker...@lists.infradead.org; linux-
> > st...@st-md-mailman.stormreply.com; linux-kernel@vger.kernel.org
> > Cc: ludovic.desroc...@microchip.com; eugen.hris...@microchip.com;
> > ji...@kernel.org; nicolas.fe...@microchip.com;
> > alexandre.bell...@bootlin.com; alexandre.tor...@st.com;
> > mcoquelin.st...@gmail.com; a...@it-klinger.de; Ardelean, Alexandru
> >
> > Subject: [PATCH v2 7/8] iio: core: simplify alloc alignment code
> >
> > There was a recent discussion about this code:
> > https://urldefense.com/v3/__https://lore.kernel.org/linux-
> > iio/20200322165317.0b1f0674@archlinux/__;!!A3Ni8CS0y2Y!pgdUSayJCfxMiE
> > w8Fpv0LkEZurCSkX0sEcLnXeDSCLmhpu1xont6-vBQj3ZbCw$
> >
> > This looks like a good time to rework this, since any issues about it
> > should pop-up under testing, because the iio_dev is having a bit of an
> > overhaul and stuff being moved to iio_dev_priv.
> >
> > Signed-off-by: Alexandru Ardelean
> > ---
> > drivers/iio/industrialio-core.c | 10 +++---
> > 1 file changed, 3 insertions(+), 7 deletions(-)
> >
> > diff --git a/drivers/iio/industrialio-core.c b/drivers/iio/industrialio-
> > core.c
> > index a1b29e0f8fd6..7671d36efae7 100644
> > --- a/drivers/iio/industrialio-core.c
> > +++ b/drivers/iio/industrialio-core.c
> > @@ -1514,13 +1514,9 @@ struct iio_dev *iio_device_alloc(int sizeof_priv)
> > struct iio_dev *dev;
> > size_t alloc_size;
> >
> > - alloc_size = sizeof(struct iio_dev_opaque);
> > - if (sizeof_priv) {
> > - alloc_size = ALIGN(alloc_size, IIO_ALIGN);
> > - alloc_size += sizeof_priv;
> > - }
> > - /* ensure 32-byte alignment of whole construct ? */
> > - alloc_size += IIO_ALIGN - 1;
> > + alloc_size = ALIGN(sizeof(struct iio_dev_opaque), IIO_ALIGN);
> > + if (sizeof_priv)
> > + alloc_size += ALIGN(sizeof_priv, IIO_ALIGN);
>
> Do we actually need to do the `ALIGN` again? It seems to me that `alloc_size
> += sizeof_priv`
> would be enough or am I missing something obvious?
Well, it's not always clear what value 'sizeof_priv' has, and whether it is
provided already aligned.
The requirement is usually that this data be cacheline aligned.
So, sizeof(struct iio_dev_opaque) is aligned already a few lines above, but the
private information should also be aligned [given that it's an unknown value
provided by the driver].
I think this is mostly important, if we need to do DMA access to buffers
allocated on the driver's state-struct, which is allocated here, and which is
usually provided as sizeof_priv.
Tbh, the discussions around this alignment/cacheline-alignment are a bit fuzzy
to me. I haven't run into any of these complicated issues.
>
> - Nuno Sá
>
Re: [PATCH 1/3] iio: core: wrap IIO device into a iio_dev_priv object
On Mon, 2020-05-11 at 18:42 +0100, Jonathan Cameron wrote:
> [External]
>
> On Mon, 11 May 2020 09:16:32 +
> "Ardelean, Alexandru" wrote:
>
> > On Fri, 2020-05-08 at 16:44 +0100, Jonathan Cameron wrote:
> > > [External]
> > >
> > > On Fri, 8 May 2020 16:40:15 +0100
> > > Jonathan Cameron wrote:
> > >
> > > > On Fri, 8 May 2020 17:13:04 +0300
> > > > Alexandru Ardelean wrote:
> > > >
> > > > > There are plenty of bad designs we want to discourage or not have to
> > > > > review
> > > > > manually usually about accessing private (marked as [INTERN]) fields
> > > > > of
> > > > > 'struct iio_dev'.
> > > >
> > > > This has been on the todo list for many years so great you are having a
> > > > go.
> > > >
> > > > > This is difficult, as a lot of users copy drivers, and not always the
> > > > > best
> > > > > examples.
> > > > >
> > > > > A better idea is to hide those fields into the framework.
> > > > > For 'struct iio_dev' this is a 'struct iio_dev_priv' which wraps a
> > > > > public
> > > > > 'struct iio_dev' object.
> > > > >
> > > > > In the next patches, some fields will be moved to this new struct,
> > > > > each
> > > > > with it's own rework.
> > > > >
> > > > > This rework will not be complete[-able] for a while, as many fields
> > > > > need
> > > > > some drivers to be reworked in order to finalize them
> > > > > (e.g. 'indio_dev->mlock').
> > > > >
> > > > > But some fields can already be moved, and in time, all of them may get
> > > > > there (in the 'struct iio_dev_priv' object).
> > > > >
> > > > > We also need to hide the implementations for 'iio_priv()' &
> > > > > 'iio_priv_to_dev()', as the pointer arithmetic will not match once
> > > > > things
> > > > > are moved.
> > > >
> > > > This last bit has the disadvantage of potentially putting a function
> > > > call in some fast paths where there wasn't one before.
> >
> > Hmm.
> > I think we can change this to have a void *ptr in the public iio.h header
> > and
> > that points to the private data in the private struct, and we compute it
> > once,
> > and just return it.
> >
> > so:
> >
> > struct iio_dev_opaque;
> >
> > struct iio_dev {
> > struct iio_dev_opaque *opaque; // compute this during
> > iio_device_alloc()
> > void *priv; // compute this during
> > iio_device_alloc()
> > };
> >
> > static inline void *iio_priv(const struct iio_dev *indio_dev)
> > {
> > return indio_dev->priv;
> > }
> >
> > [ or even just convert it to a macro ; no preference ]
>
> That works for me and avoids any of the messy stuff below.
>
> Make sure to add a comment that the region that points to is guaranteed
> to maintain cacheline alignment as thats hidden now.
1 note: I would still need to hide the iio_priv_to_dev() implementation.
It's a bit hard not to; or I can't come up with a good idea now, like for
iio_priv().
Thing is, not many drivers use it, and it looks a bit funky that they use it.
It looks like each driver should just keep (or use) a reference to the iio_dev
object, since it should be in the driver somewhere.
Maybe this series needs to be extended to clean-up those uses
of iio_priv_to_dev().
And a question; since I am not clear.
On the 'to_iio_dev_opaque()' : is it preferred to access it via 'indio_dev-
>opaque' or via pointer arithmentic?
i.e. the classic
#define to_iio_dev_opaque(indio_dev)\
container_of(indio_dev, struct iio_dev_opaque, indio_dev)
either is fine from my side; i'll just do the macro, and then the implementation
can be changed as i get the answer;
>
> > > > We may not need to 'forcefully' hide the internal parts. May be
> > > > enough to just make their use really obvious. If you have to cast
> > > > to an iio_dev_priv then you are doing something very wrong.
> > >
> > > Note, definitely keep the to_* macro only in the private core header.
> > >
> > > > The old stick __ in front of it may make that even more obvious.
> > > >
> > > > Naming is a bit confusing though. iio_dev_priv sounds like priv
Re: [RFC PATCH 00/14] iio: buffer: add support for multiple buffers
On Mon, 2020-05-11 at 21:56 +0200, Lars-Peter Clausen wrote: > [External] > > On 5/11/20 4:56 PM, Ardelean, Alexandru wrote: > > On Mon, 2020-05-11 at 15:58 +0200, Lars-Peter Clausen wrote: > > > [External] > > > > > > On 5/11/20 3:24 PM, Ardelean, Alexandru wrote: > > > > On Mon, 2020-05-11 at 13:03 +, Ardelean, Alexandru wrote: > > > > > [External] > > > > > > > > > > On Mon, 2020-05-11 at 12:37 +0200, Lars-Peter Clausen wrote: > > > > > > [External] > > > > > > > > > > > > On 5/11/20 12:33 PM, Ardelean, Alexandru wrote: > > > > > > > On Sun, 2020-05-10 at 11:09 +0100, Jonathan Cameron wrote: > > > > > > > > [External] > > > > > > > > > > > > > > > > On Sat, 9 May 2020 10:52:14 +0200 > > > > > > > > Lars-Peter Clausen wrote: > > > > > > > > > > > > > > > > > On 5/8/20 3:53 PM, Alexandru Ardelean wrote: > > > > > > > > > > [...] > > > > > > > > > > What I don't like, is that iio:device3 has iio:buffer3:0 (to > > > > > > > > > > 3). > > > > > > > > > > This is because the 'buffer->dev.parent = _dev->dev'. > > > > > > > > > > But I do feel this is correct. > > > > > > > > > > So, now I don't know whether to leave it like that or > > > > > > > > > > symlink to > > > > > > > > > > shorter > > > > > > > > > > versions like 'iio:buffer3:Y' -> 'iio:device3/bufferY'. > > > > > > > > > > The reason for naming the IIO buffer devices to > > > > > > > > > > 'iio:bufferX:Y' > > > > > > > > > > is > > > > > > > > > > mostly to make the names unique. It would have looked weird > > > > > > > > > > to > > > > > > > > > > do > > > > > > > > > > '/dev/buffer1' if I would have named the buffer devices > > > > > > > > > > 'bufferX'. > > > > > > > > > > > > > > > > > > > > So, now I'm thinking of whether all this is acceptable. > > > > > > > > > > Or what is acceptable? > > > > > > > > > > Should I symlink 'iio:device3/iio:buffer3:0' -> > > > > > > > > > > 'iio:device3/buffer0'? > > > > > > > > > > What else should I consider moving forward? > > > > > > > > > > What means forward? > > > > > > > > > > Where did I leave my beer? > > > > > > > > > Looking at how the /dev/ devices are named I think we can > > > > > > > > > provide > > > > > > > > > a > > > > > > > > > name > > > > > > > > > that is different from the dev_name() of the device. Have a > > > > > > > > > look > > > > > > > > > at > > > > > > > > > device_get_devnode() in drivers/base/core.c. We should be able > > > > > > > > > to > > > > > > > > > provide the name for the chardev through the devnode() > > > > > > > > > callback. > > > > > > > > > > > > > > > > > > While we are at this, do we want to move the new devices into > > > > > > > > > an > > > > > > > > > iio > > > > > > > > > subfolder? So iio/buffer0:0 instead of iio:buffer0:0? > > > > > > > > Possibly on the folder. I can't for the life of me remember why > > > > > > > > I > > > > > > > > decided > > > > > > > > not to do that the first time around - I'll leave it at the > > > > > > > > mysterious "it may turn out to be harder than you'd think..." > > > > > > > > Hopefully not ;) > > > > > > > I was also thinking about the /dev/iio subfolder while doing this. > > > > > > > I can copy that from /dev/input > > > > > > > They seem to do it already. > > > > > > > I don'
Re: [RFC PATCH 00/14] iio: buffer: add support for multiple buffers
On Mon, 2020-05-11 at 15:58 +0200, Lars-Peter Clausen wrote: > [External] > > On 5/11/20 3:24 PM, Ardelean, Alexandru wrote: > > On Mon, 2020-05-11 at 13:03 +0000, Ardelean, Alexandru wrote: > > > [External] > > > > > > On Mon, 2020-05-11 at 12:37 +0200, Lars-Peter Clausen wrote: > > > > [External] > > > > > > > > On 5/11/20 12:33 PM, Ardelean, Alexandru wrote: > > > > > On Sun, 2020-05-10 at 11:09 +0100, Jonathan Cameron wrote: > > > > > > [External] > > > > > > > > > > > > On Sat, 9 May 2020 10:52:14 +0200 > > > > > > Lars-Peter Clausen wrote: > > > > > > > > > > > > > On 5/8/20 3:53 PM, Alexandru Ardelean wrote: > > > > > > > > [...] > > > > > > > > What I don't like, is that iio:device3 has iio:buffer3:0 (to 3). > > > > > > > > This is because the 'buffer->dev.parent = _dev->dev'. > > > > > > > > But I do feel this is correct. > > > > > > > > So, now I don't know whether to leave it like that or symlink to > > > > > > > > shorter > > > > > > > > versions like 'iio:buffer3:Y' -> 'iio:device3/bufferY'. > > > > > > > > The reason for naming the IIO buffer devices to 'iio:bufferX:Y' > > > > > > > > is > > > > > > > > mostly to make the names unique. It would have looked weird to > > > > > > > > do > > > > > > > > '/dev/buffer1' if I would have named the buffer devices > > > > > > > > 'bufferX'. > > > > > > > > > > > > > > > > So, now I'm thinking of whether all this is acceptable. > > > > > > > > Or what is acceptable? > > > > > > > > Should I symlink 'iio:device3/iio:buffer3:0' -> > > > > > > > > 'iio:device3/buffer0'? > > > > > > > > What else should I consider moving forward? > > > > > > > > What means forward? > > > > > > > > Where did I leave my beer? > > > > > > > Looking at how the /dev/ devices are named I think we can provide > > > > > > > a > > > > > > > name > > > > > > > that is different from the dev_name() of the device. Have a look > > > > > > > at > > > > > > > device_get_devnode() in drivers/base/core.c. We should be able to > > > > > > > provide the name for the chardev through the devnode() callback. > > > > > > > > > > > > > > While we are at this, do we want to move the new devices into an > > > > > > > iio > > > > > > > subfolder? So iio/buffer0:0 instead of iio:buffer0:0? > > > > > > Possibly on the folder. I can't for the life of me remember why I > > > > > > decided > > > > > > not to do that the first time around - I'll leave it at the > > > > > > mysterious "it may turn out to be harder than you'd think..." > > > > > > Hopefully not ;) > > > > > I was also thinking about the /dev/iio subfolder while doing this. > > > > > I can copy that from /dev/input > > > > > They seem to do it already. > > > > > I don't know how difficult it would be. But it looks like a good > > > > > precedent. > > > > All you have to do is return "iio/..." from the devnode() callback. > > > I admit I did not look closely into drivers/input/input.c before > > > mentioning > > > this > > > as as good precedent. > > > > > > But, I looks like /dev/inpput is a class. > > > While IIO devices are a bus_type devices. > > > Should we start implementing an IIO class? or? > > What I should have highlighted [before] with this, is that there is no > > devnode() > > callback for the bus_type [type]. > But there is one in device_type :) Many thanks :) That worked nicely. I now have: root@analog:~# ls /dev/iio/* /dev/iio/iio:device0 /dev/iio/iio:device1 /dev/iio/device3: buffer0 buffer1 buffer2 buffer3 /dev/iio/device4: buffer0 It looks like I can shift these around as needed. This is just an experiment. I managed to move the iio devices under /dev/iio, though probably the IIO devices will still be around as /dev/iio:deviceX for legacy reasons. Two things remain unresol
Re: [RFC PATCH 00/14] iio: buffer: add support for multiple buffers
On Mon, 2020-05-11 at 13:03 +, Ardelean, Alexandru wrote: > [External] > > On Mon, 2020-05-11 at 12:37 +0200, Lars-Peter Clausen wrote: > > [External] > > > > On 5/11/20 12:33 PM, Ardelean, Alexandru wrote: > > > On Sun, 2020-05-10 at 11:09 +0100, Jonathan Cameron wrote: > > > > [External] > > > > > > > > On Sat, 9 May 2020 10:52:14 +0200 > > > > Lars-Peter Clausen wrote: > > > > > > > > > On 5/8/20 3:53 PM, Alexandru Ardelean wrote: > > > > > > [...] > > > > > > What I don't like, is that iio:device3 has iio:buffer3:0 (to 3). > > > > > > This is because the 'buffer->dev.parent = _dev->dev'. > > > > > > But I do feel this is correct. > > > > > > So, now I don't know whether to leave it like that or symlink to > > > > > > shorter > > > > > > versions like 'iio:buffer3:Y' -> 'iio:device3/bufferY'. > > > > > > The reason for naming the IIO buffer devices to 'iio:bufferX:Y' is > > > > > > mostly to make the names unique. It would have looked weird to do > > > > > > '/dev/buffer1' if I would have named the buffer devices 'bufferX'. > > > > > > > > > > > > So, now I'm thinking of whether all this is acceptable. > > > > > > Or what is acceptable? > > > > > > Should I symlink 'iio:device3/iio:buffer3:0' -> > > > > > > 'iio:device3/buffer0'? > > > > > > What else should I consider moving forward? > > > > > > What means forward? > > > > > > Where did I leave my beer? > > > > > Looking at how the /dev/ devices are named I think we can provide a > > > > > name > > > > > that is different from the dev_name() of the device. Have a look at > > > > > device_get_devnode() in drivers/base/core.c. We should be able to > > > > > provide the name for the chardev through the devnode() callback. > > > > > > > > > > While we are at this, do we want to move the new devices into an iio > > > > > subfolder? So iio/buffer0:0 instead of iio:buffer0:0? > > > > Possibly on the folder. I can't for the life of me remember why I > > > > decided > > > > not to do that the first time around - I'll leave it at the > > > > mysterious "it may turn out to be harder than you'd think..." > > > > Hopefully not ;) > > > I was also thinking about the /dev/iio subfolder while doing this. > > > I can copy that from /dev/input > > > They seem to do it already. > > > I don't know how difficult it would be. But it looks like a good > > > precedent. > > > > All you have to do is return "iio/..." from the devnode() callback. > > I admit I did not look closely into drivers/input/input.c before mentioning > this > as as good precedent. > > But, I looks like /dev/inpput is a class. > While IIO devices are a bus_type devices. > Should we start implementing an IIO class? or? What I should have highlighted [before] with this, is that there is no devnode() callback for the bus_type [type]. > > > > > My concern regarding going to use stuff from core [like > > > device_get_devnode()] is > > > that it seems to bypass some layers of kernel. > > > If I do 'git grep device_get_devnode', I get: > > > > > > drivers/base/core.c:name = device_get_devnode(dev, , > > > , > > > , ); > > > drivers/base/core.c: * device_get_devnode - path of device node file > > > drivers/base/core.c:const char *device_get_devnode(struct device *dev, > > > drivers/base/devtmpfs.c:req.name = device_get_devnode(dev, > > > , > > > , , ); > > > drivers/base/devtmpfs.c:req.name = device_get_devnode(dev, NULL, > > > NULL, > > > NULL, ); > > > include/linux/device.h:extern const char *device_get_devnode(struct device > > > *dev, > > > (END) > > > > > > So, basically, most uses of device_get_devnode() are in core code, and I > > > feel > > > that this may be sanctioned somewhere by some core people, if I do it. > > > I could be wrong, but if you disagree, I'll take your word for it. > > You are not supposed to use the function itself, you should implement > > the devnode() callback for the IIO bus, which is then used by the core > > device_get_devnode() function. > >
Re: [RFC PATCH 00/14] iio: buffer: add support for multiple buffers
On Mon, 2020-05-11 at 12:37 +0200, Lars-Peter Clausen wrote: > [External] > > On 5/11/20 12:33 PM, Ardelean, Alexandru wrote: > > On Sun, 2020-05-10 at 11:09 +0100, Jonathan Cameron wrote: > > > [External] > > > > > > On Sat, 9 May 2020 10:52:14 +0200 > > > Lars-Peter Clausen wrote: > > > > > > > On 5/8/20 3:53 PM, Alexandru Ardelean wrote: > > > > > [...] > > > > > What I don't like, is that iio:device3 has iio:buffer3:0 (to 3). > > > > > This is because the 'buffer->dev.parent = _dev->dev'. > > > > > But I do feel this is correct. > > > > > So, now I don't know whether to leave it like that or symlink to > > > > > shorter > > > > > versions like 'iio:buffer3:Y' -> 'iio:device3/bufferY'. > > > > > The reason for naming the IIO buffer devices to 'iio:bufferX:Y' is > > > > > mostly to make the names unique. It would have looked weird to do > > > > > '/dev/buffer1' if I would have named the buffer devices 'bufferX'. > > > > > > > > > > So, now I'm thinking of whether all this is acceptable. > > > > > Or what is acceptable? > > > > > Should I symlink 'iio:device3/iio:buffer3:0' -> 'iio:device3/buffer0'? > > > > > What else should I consider moving forward? > > > > > What means forward? > > > > > Where did I leave my beer? > > > > Looking at how the /dev/ devices are named I think we can provide a name > > > > that is different from the dev_name() of the device. Have a look at > > > > device_get_devnode() in drivers/base/core.c. We should be able to > > > > provide the name for the chardev through the devnode() callback. > > > > > > > > While we are at this, do we want to move the new devices into an iio > > > > subfolder? So iio/buffer0:0 instead of iio:buffer0:0? > > > Possibly on the folder. I can't for the life of me remember why I decided > > > not to do that the first time around - I'll leave it at the > > > mysterious "it may turn out to be harder than you'd think..." > > > Hopefully not ;) > > I was also thinking about the /dev/iio subfolder while doing this. > > I can copy that from /dev/input > > They seem to do it already. > > I don't know how difficult it would be. But it looks like a good precedent. > > All you have to do is return "iio/..." from the devnode() callback. I admit I did not look closely into drivers/input/input.c before mentioning this as as good precedent. But, I looks like /dev/inpput is a class. While IIO devices are a bus_type devices. Should we start implementing an IIO class? or? > > > My concern regarding going to use stuff from core [like > > device_get_devnode()] is > > that it seems to bypass some layers of kernel. > > If I do 'git grep device_get_devnode', I get: > > > > drivers/base/core.c:name = device_get_devnode(dev, , , > > , ); > > drivers/base/core.c: * device_get_devnode - path of device node file > > drivers/base/core.c:const char *device_get_devnode(struct device *dev, > > drivers/base/devtmpfs.c:req.name = device_get_devnode(dev, > > , > > , , ); > > drivers/base/devtmpfs.c:req.name = device_get_devnode(dev, NULL, > > NULL, > > NULL, ); > > include/linux/device.h:extern const char *device_get_devnode(struct device > > *dev, > > (END) > > > > So, basically, most uses of device_get_devnode() are in core code, and I > > feel > > that this may be sanctioned somewhere by some core people, if I do it. > > I could be wrong, but if you disagree, I'll take your word for it. > You are not supposed to use the function itself, you should implement > the devnode() callback for the IIO bus, which is then used by the core > device_get_devnode() function. >
Re: [RFC PATCH 00/14] iio: buffer: add support for multiple buffers
On Sun, 2020-05-10 at 11:09 +0100, Jonathan Cameron wrote:
> [External]
>
> On Sat, 9 May 2020 10:52:14 +0200
> Lars-Peter Clausen wrote:
>
> > On 5/8/20 3:53 PM, Alexandru Ardelean wrote:
> > > [...]
> > > What I don't like, is that iio:device3 has iio:buffer3:0 (to 3).
> > > This is because the 'buffer->dev.parent = _dev->dev'.
> > > But I do feel this is correct.
> > > So, now I don't know whether to leave it like that or symlink to shorter
> > > versions like 'iio:buffer3:Y' -> 'iio:device3/bufferY'.
> > > The reason for naming the IIO buffer devices to 'iio:bufferX:Y' is
> > > mostly to make the names unique. It would have looked weird to do
> > > '/dev/buffer1' if I would have named the buffer devices 'bufferX'.
> > >
> > > So, now I'm thinking of whether all this is acceptable.
> > > Or what is acceptable?
> > > Should I symlink 'iio:device3/iio:buffer3:0' -> 'iio:device3/buffer0'?
> > > What else should I consider moving forward?
> > > What means forward?
> > > Where did I leave my beer?
> >
> > Looking at how the /dev/ devices are named I think we can provide a name
> > that is different from the dev_name() of the device. Have a look at
> > device_get_devnode() in drivers/base/core.c. We should be able to
> > provide the name for the chardev through the devnode() callback.
> >
> > While we are at this, do we want to move the new devices into an iio
> > subfolder? So iio/buffer0:0 instead of iio:buffer0:0?
>
> Possibly on the folder. I can't for the life of me remember why I decided
> not to do that the first time around - I'll leave it at the
> mysterious "it may turn out to be harder than you'd think..."
> Hopefully not ;)
I was also thinking about the /dev/iio subfolder while doing this.
I can copy that from /dev/input
They seem to do it already.
I don't know how difficult it would be. But it looks like a good precedent.
My concern regarding going to use stuff from core [like device_get_devnode()] is
that it seems to bypass some layers of kernel.
If I do 'git grep device_get_devnode', I get:
drivers/base/core.c:name = device_get_devnode(dev, , ,
, );
drivers/base/core.c: * device_get_devnode - path of device node file
drivers/base/core.c:const char *device_get_devnode(struct device *dev,
drivers/base/devtmpfs.c:req.name = device_get_devnode(dev, ,
, , );
drivers/base/devtmpfs.c:req.name = device_get_devnode(dev, NULL, NULL,
NULL, );
include/linux/device.h:extern const char *device_get_devnode(struct device *dev,
(END)
So, basically, most uses of device_get_devnode() are in core code, and I feel
that this may be sanctioned somewhere by some core people, if I do it.
I could be wrong, but if you disagree, I'll take your word for it.
I tried using devtmpfs_create_node() directly, and it worked, but again, doing
'git grep devtmpfs_create_node'
drivers/base/base.h:int devtmpfs_create_node(struct device *dev);
drivers/base/base.h:static inline int devtmpfs_create_node(struct device *dev) {
return 0; }
drivers/base/core.c:devtmpfs_create_node(dev);
drivers/base/devtmpfs.c:int devtmpfs_create_node(struct device *dev)
drivers/s390/char/hmcdrv_dev.c: * See: devtmpfs.c, function
devtmpfs_create_node()
Most calls are in core, and the one in hmcdrv driver isn't convincing enough to
do it.
In fact, some may consider it dangerous as it allows drivers/frameworks to use
it as precedent to do more name manipulation.
Again, if you guys say that this would be acceptable, I can use
device_get_devnode() and other stuff from core.
>
> Do we want to make the naming a bit more self describing, something like
> iio/device0:buffer0? Given the legacy interface will be outside
> the directory anyway, could even do
>
> iio/device0/buffer0 with link to iio:device0
> iio/device0/buffer1 with no legacy link.
>
> Ah, the bikeshedding fun we have ahead of us!
This may also depend on how much code it takes to implement these many levels of
folder hierarchy.
>
> I think this set is going to take too much thinking for a Sunday
> so may take me a little while to do a proper review...
> + I have a few other side projects I want to hammer on today :)
>
> Jonathan
>
Re: [PATCH] iio: buffer: rework buffer attr read-only stat-flags with 'is_visible' hook
On Thu, 2020-04-16 at 17:31 +0300, Alexandru Ardelean wrote:
> [External]
>
> The kernel provides a facility for attribute groups to specify the stat
> flags of a sysfs file with an 'is_visible()' hook. This mechanism is
> usually more flexible than assigning read-only attributes at construction
> time.
> It's added-value is a bit more apparent when the number of attributes
> grows, so for sysfs buffer attributes this change may not be that be useful
> quite now.
>
> It should become more useful as the sysfs structure for buffer attributes
> gets changed a bit.
Let's disregard this for now.
It may not be worth doing this, until a better context/reason appears.
>
> Signed-off-by: Alexandru Ardelean
> ---
> drivers/iio/industrialio-buffer.c | 48 ++-
> 1 file changed, 35 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/iio/industrialio-buffer.c b/drivers/iio/industrialio-
> buffer.c
> index 221157136af6..60bb03e72afc 100644
> --- a/drivers/iio/industrialio-buffer.c
> +++ b/drivers/iio/industrialio-buffer.c
> @@ -1214,24 +1214,50 @@ static ssize_t iio_dma_show_data_available(struct
> device *dev,
> return sprintf(buf, "%zu\n", bytes);
> }
>
> +enum {
> + IIO_BUFFER_ATTR_LENGTH,
> + IIO_BUFFER_ATTR_ENABLE,
> + IIO_BUFFER_ATTR_WATERMARK,
> + IIO_BUFFER_ATTR_DATA_AVAILABLE,
> + __IIO_BUFFER_ATTR_MAX
> +};
> +
> +static umode_t iio_buffer_attr_group_is_visible(struct kobject *kobj,
> + struct attribute *attr,
> + int index)
> +{
> + struct device *dev = container_of(kobj, struct device, kobj);
> + struct iio_dev *indio_dev = dev_to_iio_dev(dev);
> + struct iio_buffer *buffer = indio_dev->buffer;
> +
> + switch (index) {
> + case IIO_BUFFER_ATTR_LENGTH:
> + if (!buffer->access->set_length)
> + return S_IRUGO;
> + return attr->mode;
> + case IIO_BUFFER_ATTR_WATERMARK:
> + if (buffer->access->flags & INDIO_BUFFER_FLAG_FIXED_WATERMARK)
> + return S_IRUGO;
> + return attr->mode;
> + default:
> + return attr->mode;
> + }
> +}
> +
> static DEVICE_ATTR(length, S_IRUGO | S_IWUSR, iio_buffer_read_length,
> iio_buffer_write_length);
> -static struct device_attribute dev_attr_length_ro = __ATTR(length,
> - S_IRUGO, iio_buffer_read_length, NULL);
> static DEVICE_ATTR(enable, S_IRUGO | S_IWUSR,
> iio_buffer_show_enable, iio_buffer_store_enable);
> static DEVICE_ATTR(watermark, S_IRUGO | S_IWUSR,
> iio_buffer_show_watermark, iio_buffer_store_watermark);
> -static struct device_attribute dev_attr_watermark_ro = __ATTR(watermark,
> - S_IRUGO, iio_buffer_show_watermark, NULL);
> static DEVICE_ATTR(data_available, S_IRUGO,
> iio_dma_show_data_available, NULL);
>
> static struct attribute *iio_buffer_attrs[] = {
> - _attr_length.attr,
> - _attr_enable.attr,
> - _attr_watermark.attr,
> - _attr_data_available.attr,
> + [IIO_BUFFER_ATTR_LENGTH] = _attr_length.attr,
> + [IIO_BUFFER_ATTR_ENABLE] = _attr_enable.attr,
> + [IIO_BUFFER_ATTR_WATERMARK] = _attr_watermark.attr,
> + [IIO_BUFFER_ATTR_DATA_AVAILABLE] = _attr_data_available.attr,
> };
>
> int iio_buffer_alloc_sysfs_and_mask(struct iio_dev *indio_dev)
> @@ -1266,11 +1292,6 @@ int iio_buffer_alloc_sysfs_and_mask(struct iio_dev
> *indio_dev)
> return -ENOMEM;
>
> memcpy(attr, iio_buffer_attrs, sizeof(iio_buffer_attrs));
> - if (!buffer->access->set_length)
> - attr[0] = _attr_length_ro.attr;
> -
> - if (buffer->access->flags & INDIO_BUFFER_FLAG_FIXED_WATERMARK)
> - attr[2] = _attr_watermark_ro.attr;
>
> if (buffer->attrs)
> memcpy([ARRAY_SIZE(iio_buffer_attrs)], buffer->attrs,
> @@ -1279,6 +1300,7 @@ int iio_buffer_alloc_sysfs_and_mask(struct iio_dev
> *indio_dev)
> attr[attrcount + ARRAY_SIZE(iio_buffer_attrs)] = NULL;
>
> buffer->buffer_group.name = "buffer";
> + buffer->buffer_group.is_visible = iio_buffer_attr_group_is_visible;
> buffer->buffer_group.attrs = attr;
>
> indio_dev->groups[indio_dev->groupcounter++] = >buffer_group;
Re: [PATCH 1/3] iio: core: wrap IIO device into a iio_dev_priv object
On Fri, 2020-05-08 at 16:44 +0100, Jonathan Cameron wrote:
> [External]
>
> On Fri, 8 May 2020 16:40:15 +0100
> Jonathan Cameron wrote:
>
> > On Fri, 8 May 2020 17:13:04 +0300
> > Alexandru Ardelean wrote:
> >
> > > There are plenty of bad designs we want to discourage or not have to
> > > review
> > > manually usually about accessing private (marked as [INTERN]) fields of
> > > 'struct iio_dev'.
> >
> > This has been on the todo list for many years so great you are having a go.
> >
> > > This is difficult, as a lot of users copy drivers, and not always the best
> > > examples.
> > >
> > > A better idea is to hide those fields into the framework.
> > > For 'struct iio_dev' this is a 'struct iio_dev_priv' which wraps a public
> > > 'struct iio_dev' object.
> > >
> > > In the next patches, some fields will be moved to this new struct, each
> > > with it's own rework.
> > >
> > > This rework will not be complete[-able] for a while, as many fields need
> > > some drivers to be reworked in order to finalize them
> > > (e.g. 'indio_dev->mlock').
> > >
> > > But some fields can already be moved, and in time, all of them may get
> > > there (in the 'struct iio_dev_priv' object).
> > >
> > > We also need to hide the implementations for 'iio_priv()' &
> > > 'iio_priv_to_dev()', as the pointer arithmetic will not match once things
> > > are moved.
> >
> > This last bit has the disadvantage of potentially putting a function
> > call in some fast paths where there wasn't one before.
Hmm.
I think we can change this to have a void *ptr in the public iio.h header and
that points to the private data in the private struct, and we compute it once,
and just return it.
so:
struct iio_dev_opaque;
struct iio_dev {
struct iio_dev_opaque *opaque; // compute this during iio_device_alloc()
void *priv; // compute this during iio_device_alloc()
};
static inline void *iio_priv(const struct iio_dev *indio_dev)
{
return indio_dev->priv;
}
[ or even just convert it to a macro ; no preference ]
> >
> > We may not need to 'forcefully' hide the internal parts. May be
> > enough to just make their use really obvious. If you have to cast
> > to an iio_dev_priv then you are doing something very wrong.
>
> Note, definitely keep the to_* macro only in the private core header.
>
> > The old stick __ in front of it may make that even more obvious.
> >
> > Naming is a bit confusing though. iio_dev_priv sounds like private
> > to the device... iio_dev_opaque maybe?
regarding the 'opaque' part, that would be a 'struct iio_dev_opaque {' that
lives somewhere like
struct iio_dev_opaque {
struct iio_dev indio_dev; // public IIO device part
... // opaque IIO device parts
... // iio_priv data
}
The stick __ in front, may work just fine as well.
Personally, I would prefer to forcefully hide stuff, because then the compiler
could also be useful in telling people not to use some private fields.
People [juniors usually] listen to compilers more than they listen to review-
comments.
We could move the 'struct iio_dev_opaque' in 'include/linux/iio/iio-opaque.h',
so that if they need to access some fields for some advanced/hacky debugging, it
should work as well.
Still, if it's more preferred to prefix them, I can do that as well.
But we should prefix them as we manage to somehow make the more opaque, or
remove the fields from places they should be used.
Otherwise it is pointless, as people would copy 'indio_dev->__mlock' anyway.
> >
> >
> > > Signed-off-by: Alexandru Ardelean
> > > ---
> > >
> > > Just as a note here, I've been running this patchset without a problem
> > > for 2 weeks now in a work branch.
> > > But it's only been a setup, so no idea if some other thing may cause
> > > bigger issues.
> > >
> > > This small patchset is meant to kickstart this, for GSoC people or for
> > > people wanting to start contributing to IIO.
> > >
> > > drivers/iio/iio_core.h | 11 +++
> > > drivers/iio/industrialio-core.c | 32 +++-
> > > include/linux/iio/iio.h | 12 ++--
> > > 3 files changed, 40 insertions(+), 15 deletions(-)
> > >
> > > diff --git a/drivers/iio/iio_core.h b/drivers/iio/iio_core.h
> > > index fd9a5f1d5e51..84f3b4590c05 100644
> > > --- a/drivers/iio/iio_core.h
> > > +++ b/drivers/iio/iio_core.h
> > > @@ -17,6 +17,17 @@ struct iio_dev;
> > >
> > > extern struct device_type iio_device_type;
> > >
> > > +/**
> > > + * struct iio_dev_priv - industrial I/O device private information
> > > + * @indio_dev: public IIO device object
> > > + */
> > > +struct iio_dev_priv {
> > > + struct iio_dev indio_dev;
> > > +};
> > > +
> > > +#define to_iio_dev_priv(indio_dev) \
> > > + container_of(indio_dev, struct iio_dev_priv, indio_dev)
> > > +
> > > int __iio_add_chan_devattr(const char *postfix,
> > > struct iio_chan_spec const *chan,
> > >
Re: [PATCH v6 0/6] iio: core,buffer: re-organize chardev creation
On Sun, 2020-05-03 at 16:51 +0100, Jonathan Cameron wrote: > [External] > > On Mon, 27 Apr 2020 16:10:54 +0300 > Alexandru Ardelean wrote: > > > The main intent is to be able to add more chardevs per IIO device, one > > for each buffer. To get there, some rework is needed. > > This tries to re-organize the init of the chardev. > > Hmm. I'd like this set to sit and ideally gather a few acks before > I move ahead with it. > > The protections against problems around remove have always been > somewhat fiddly and I suspect don't cover everything. > > I'm fairly sure taking the exist lock is 'sufficient' but I'm not > actually sure it's necessary. We only otherwise take it for > place where the inkern interface is in use so we can race > against removal of a provider driver. > > We don't have such heavy weight protections in the buffer code > and I'll be honest I can't remember why. Original patch mentions > that it was about avoiding taking additional new references to the > struct iio_dev. We aren't doing that as such here so perhaps > we don't need to take the lock.. > > Lars, I suspect you may have been involved in that stuff originally > so I'd appreciate you taking a quick look at this if you have > time! > Well, it will take me a bit to re-do this series. I've got to a point where some of these patches will need some re-tuning. . Adding multiple buffers per IIO device seems a bit more difficult than I initially thought. > Thanks, > > Jonathan > > > > > Changelog v5 -> v6: > > - patch 'iio: core: register chardev only if needed' > > - sort file_operations fields for iio_event_fileops > > - patch 'iio: buffer,event: duplicate chardev creation for buffers & events' > > - fixed-up '**/' -> '*/' for 2 block comments > > - sorted file_operations for iio_buffer_fileops, after move > > - removed 'indio_dev->chrdev = NULL' on IIO device unregister > > - added comment about 'indio_dev->info' NULL check in > > iio_device_event_ioctl() > > - patch 'iio: core: add simple centralized mechanism for ioctl() handlers' > > - re-using lock 'indio_dev->info_exist_lock' for new ioctl register > > mechanism in iio_device_ioctl() > > - simplified exit condition from the loop; only need to check > > `ret != IIO_IOCTL_UNHANDLED` to continue looping; > > everything else is just return/break > > - patch 'iio: core: use new common ioctl() mechanism' > > - the comment for 'indio_dev->info' NULL check is being moved here to > > highlight why the null-check is being removed; or where it's being > > moved > > > > Changelog v4 -> v5: > > - dropped patch 'iio: Use an early return in iio_device_alloc to simplify > > code.' > > is applied upstream > > > > Changelog v3 -> v4: > > - added patch [1] 'iio: Use an early return in iio_device_alloc to simplify > > code.' > > it's main purpose is so that this patch applies: > > [2]'iio: core: add simple centralized mechanism for ioctl() handlers' > > depending on the final version of patch [1], patch [2] needs some > > minor fixup > > - added patch 'iio: core,buffer: wrap iio_buffer_put() call into > > iio_buffers_put()' > > - patch 'iio: core: register buffer fileops only if buffer present' > > is now: 'iio: core: register chardev only if needed' > > - dropped 'iio: buffer: move sysfs alloc/free in industrialio-buffer.c' > > it's likely we won't be doing this patch anymore > > - patches: > > 'iio: buffer: move iio buffer chrdev in industrialio-buffer.c' > > 'iio: event: move event-only chardev in industrialio-event.c' > > have been merged into 'iio: buffer,event: duplicate chardev creation for > > buffers & events' > > since now, the logic is a bit different, and 'indio_dev->chrdev' is > > now a reference to either the buffer's chrdev & or the events-only > > chrdev > > - added simple mechanism to register ioctl() handlers for IIO device > > which is currently used only by events mechanism > > > > Changelog v2 -> v3: > > * removed double init in > > 'iio: event: move event-only chardev in industrialio-event.c' > > > > Changelog v1 -> v2: > > * re-reviewed some exit-paths and cleanup some potential leaks on those > > exit paths: > > - for 'iio: buffer: move iio buffer chrdev in industrialio-buffer.c' > > add iio_device_buffers_put() helper and calling iio_buffers_uninit() > > on device un-regsiter > > - for 'move sysfs alloc/free in industrialio-buffer.c' > > call 'iio_buffer_free_sysfs_and_mask()' on exit path if > > cdev_device_add() fails > > - for 'move event-only chardev in industrialio-event.c' > > check if event_interface is NULL in > > iio_device_unregister_event_chrdev() > > > > Alexandru Ardelean (6): > > iio: buffer: add back-ref from iio_buffer to iio_dev > > iio: core,buffer: wrap iio_buffer_put() call into iio_buffers_put() > > iio: core: register chardev only if needed > > iio: buffer,event: duplicate chardev creation for buffers & events > >
Re: [PATCH] iio: adc: ad7476: fix clang -Wpointer-bool-conversion warning
On Tue, 2020-05-05 at 16:23 +0200, Arnd Bergmann wrote:
> [External]
>
> Checking the pointer value of st->chip_info->convst_channel is pointless
> since this this an array inside of a struct: even if st->chip_info is NULL,
> the pointer is non-zero. Clang warns about this:
>
> drivers/iio/adc/ad7476.c:312:40: warning: address of array 'st->chip_info-
> >convst_channel' will always evaluate to 'true' [-Wpointer-bool-conversion]
> if (st->convst_gpio && st->chip_info->convst_channel)
> ~~ ~~~^~
>
> I could not come up with a sane way to check whether the entry
> is valid, so just remove the check and keep the behavior as it
> is today but without the warning.
There's already a patch for this, in one of Jonathan's branches.
https://patchwork.kernel.org/patch/11507829/
Thanks
Alex
>
> Fixes: 3a6af93dd66e ("iio: adc: ad7476: Add IIO_CHAN_INFO_RAW for AD7091R")
> Signed-off-by: Arnd Bergmann
> ---
> drivers/iio/adc/ad7476.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/iio/adc/ad7476.c b/drivers/iio/adc/ad7476.c
> index e9984a38fc4c..4e816d714ad2 100644
> --- a/drivers/iio/adc/ad7476.c
> +++ b/drivers/iio/adc/ad7476.c
> @@ -309,7 +309,7 @@ static int ad7476_probe(struct spi_device *spi)
> indio_dev->num_channels = 2;
> indio_dev->info = _info;
>
> - if (st->convst_gpio && st->chip_info->convst_channel)
> + if (st->convst_gpio)
> indio_dev->channels = st->chip_info->convst_channel;
> /* Setup default message */
>
Re: [PATCH v6 3/6] iio: core: register chardev only if needed
On Sun, 2020-05-03 at 16:39 +0100, Jonathan Cameron wrote:
> [External]
>
> On Mon, 27 Apr 2020 16:10:57 +0300
> Alexandru Ardelean wrote:
>
> > The final intent is to localize all buffer ops into the
> > industrialio-buffer.c file, to be able to add support for multiple buffers
> > per IIO device.
> >
> > We only need a chardev if we need to support buffers and/or events.
> >
> > With this change, a chardev will be created only if an IIO buffer is
> > attached OR an event_interface is configured.
> >
> > Otherwise, no chardev will be created, and the IIO device will get
> > registered with the 'device_add()' call.
> >
> > Quite a lot of IIO devices don't really need a chardev, so this is a minor
> > improvement to the IIO core, as the IIO device will take up (slightly)
> > fewer resources.
> >
> > Signed-off-by: Alexandru Ardelean
> > ---
> > drivers/iio/industrialio-core.c | 25 ++---
> > 1 file changed, 22 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/iio/industrialio-core.c b/drivers/iio/industrialio-
> > core.c
> > index 32c489139cd2..51e279c60793 100644
> > --- a/drivers/iio/industrialio-core.c
> > +++ b/drivers/iio/industrialio-core.c
> > @@ -1682,6 +1682,15 @@ static int iio_check_unique_scan_index(struct iio_dev
> > *indio_dev)
> >
> > static const struct iio_buffer_setup_ops noop_ring_setup_ops;
> >
> > +static const struct file_operations iio_event_fileops = {
> > + .owner = THIS_MODULE,
> > + .llseek = noop_llseek,
> > + .unlocked_ioctl = iio_event_ioctl_wrapper,
>
> Unfortunately this doesn't exist until the next patch...
crap;
i copied this from the wrong place when i re-ordered this, and forgot to run a
build on each patchset
will fix
>
> > + .compat_ioctl = compat_ptr_ioctl,
> > + .open = iio_chrdev_open,
> > + .release = iio_chrdev_release,
> > +};
> > +
> > int __iio_device_register(struct iio_dev *indio_dev, struct module
> > *this_mod)
> > {
> > int ret;
> > @@ -1732,11 +1741,18 @@ int __iio_device_register(struct iio_dev *indio_dev,
> > struct module *this_mod)
> > indio_dev->setup_ops == NULL)
> > indio_dev->setup_ops = _ring_setup_ops;
> >
> > - cdev_init(_dev->chrdev, _buffer_fileops);
> > + if (indio_dev->buffer)
> > + cdev_init(_dev->chrdev, _buffer_fileops);
> > + else if (indio_dev->event_interface)
> > + cdev_init(_dev->chrdev, _event_fileops);
> >
> > indio_dev->chrdev.owner = this_mod;
> >
> > - ret = cdev_device_add(_dev->chrdev, _dev->dev);
> > + if (indio_dev->buffer || indio_dev->event_interface)
> > + ret = cdev_device_add(_dev->chrdev, _dev->dev);
> > + else
> > + ret = device_add(_dev->dev);
> > +
> > if (ret < 0)
> > goto error_unreg_eventset;
> >
> > @@ -1760,7 +1776,10 @@ EXPORT_SYMBOL(__iio_device_register);
> > **/
> > void iio_device_unregister(struct iio_dev *indio_dev)
> > {
> > - cdev_device_del(_dev->chrdev, _dev->dev);
> > + if (indio_dev->buffer || indio_dev->event_interface)
> > + cdev_device_del(_dev->chrdev, _dev->dev);
> > + else
> > + device_del(_dev->dev);
> >
> > mutex_lock(_dev->info_exist_lock);
> >
Re: [PATCH v2 1/2] iio: Move scan mask management to the core
On Sun, 2020-05-03 at 13:51 +0100, Jonathan Cameron wrote:
> On Wed, 29 Apr 2020 18:17:39 +0300
> Alexandru Ardelean wrote:
>
> > From: Lars-Peter Clausen
> >
> > Let the core handle the buffer scan mask management including allocation
> > and channel selection. Having this handled in a central place rather than
> > open-coding it all over the place will make it easier to change the
> > implementation (if needed).
> > At the very least, this change abstracts scan-mask management away from
> > buffer implementations.
> >
> > Signed-off-by: Lars-Peter Clausen
> > Signed-off-by: Alexandru Ardelean
>
> I'm not 100% happy with including the buffer_impl.h header in the inkern
> code, but I can't see a simple way around it.
I actually also tried to not do it [I suspect Lars may have tried as well].
But you end up either having to expose 'struct iio_channel' outside of
'inkern.c' or having to include 'iio/consumer.h' in industrialio-buffer.c
Since there will be a V3, I will probably try to look again at a potential
different solution. Maybe there is a better solution I haven't considered.
>
> However, there are some missing statics in here and I'm feeling lazy
> so not going to fix them up for you.
>
No problem from my side.
I'll fix them up.
I prefer it when people don't cleanup after me. Makes me feel less guilty.
Though I will admit, it's a double-edged feeling: I am greatful when someone
cleans up after me, but I also feel slightly guilty [about it].
> Thanks,
>
> Jonathan
>
> > ---
> >
> > Changelog v1 -> v2:
> > - split away from initial series; the `buffer->channel_mask` attribute
> > requires a bit more dicussion; or may even be dropped; just these 2
> > patches helps with diff-ing 2 trees, as applying patches between my
> > work tree & IIO has fewer conflicts
> > - return -EINVAL if masklength is 0 in iio_buffer_alloc_scanmask()
> > - convert 2nd parameter to `unsigned int masklength` in
> > iio_buffer_alloc_scanmask()
> >
> > drivers/iio/buffer/industrialio-buffer-cb.c | 17 +-
> > drivers/iio/industrialio-buffer.c | 36 +++--
> > drivers/iio/inkern.c| 15 +
> > include/linux/iio/consumer.h| 10 ++
> > 4 files changed, 59 insertions(+), 19 deletions(-)
> >
> > diff --git a/drivers/iio/buffer/industrialio-buffer-cb.c
> > b/drivers/iio/buffer/industrialio-buffer-cb.c
> > index 47c96f7f4976..dc5bb2ab533a 100644
> > --- a/drivers/iio/buffer/industrialio-buffer-cb.c
> > +++ b/drivers/iio/buffer/industrialio-buffer-cb.c
> > @@ -34,7 +34,7 @@ static void iio_buffer_cb_release(struct iio_buffer
> > *buffer)
> > {
> > struct iio_cb_buffer *cb_buff = buffer_to_cb_buffer(buffer);
> >
> > - bitmap_free(cb_buff->buffer.scan_mask);
> > + iio_buffer_free_scanmask(_buff->buffer);
> > kfree(cb_buff);
> > }
> >
> > @@ -72,27 +72,26 @@ struct iio_cb_buffer *iio_channel_get_all_cb(struct
> > device *dev,
> > }
> >
> > cb_buff->indio_dev = cb_buff->channels[0].indio_dev;
> > - cb_buff->buffer.scan_mask = bitmap_zalloc(cb_buff->indio_dev-
> > >masklength,
> > - GFP_KERNEL);
> > - if (cb_buff->buffer.scan_mask == NULL) {
> > - ret = -ENOMEM;
> > +
> > + ret = iio_buffer_alloc_scanmask(_buff->buffer,
> > + cb_buff->indio_dev->masklength);
> > + if (ret)
> > goto error_release_channels;
> > - }
> > +
> > chan = _buff->channels[0];
> > while (chan->indio_dev) {
> > if (chan->indio_dev != cb_buff->indio_dev) {
> > ret = -EINVAL;
> > goto error_free_scan_mask;
> > }
> > - set_bit(chan->channel->scan_index,
> > - cb_buff->buffer.scan_mask);
> > + iio_buffer_channel_enable(_buff->buffer, chan);
> > chan++;
> > }
> >
> > return cb_buff;
> >
> > error_free_scan_mask:
> > - bitmap_free(cb_buff->buffer.scan_mask);
> > + iio_buffer_free_scanmask(_buff->buffer);
> > error_release_channels:
> > iio_channel_release_all(cb_buff->channels);
> > error_free_cb_buff:
> > diff --git a/drivers/iio/industrialio-buffer.c b/drivers/iio/industrialio-
> > buffer.c
> > index eae39eaf49af..c6b63f4474ff 100644
> > --- a/drivers/iio/industrialio-buffer.c
> > +++ b/drivers/iio/industrialio-buffer.c
> > @@ -208,6 +208,26 @@ void iio_buffer_init(struct iio_buffer *buffer)
> > }
> > EXPORT_SYMBOL(iio_buffer_init);
> >
> > +int iio_buffer_alloc_scanmask(struct iio_buffer *buffer,
> > + unsigned int masklength)
> > +{
> > + if (!masklength)
> > + return -EINVAL;
> > +
> > + buffer->scan_mask = bitmap_zalloc(masklength, GFP_KERNEL);
> > + if (buffer->scan_mask == NULL)
> > + return -ENOMEM;
> > +
> > + return 0;
> > +}
> > +EXPORT_SYMBOL_GPL(iio_buffer_alloc_scanmask);
> > +
> > +void iio_buffer_free_scanmask(struct
Re: [PATCH] staging: iio: ad2s1210: Fix SPI reading
On Sun, 2020-05-03 at 12:37 +0100, Jonathan Cameron wrote:
> [External]
>
> On Wed, 29 Apr 2020 10:21:29 +0300
> Alexandru Ardelean wrote:
>
> > From: Dragos Bogdan
> >
> > If the serial interface is used, the 8-bit address should be latched using
> > the rising edge of the WR/FSYNC signal.
> >
> > This basically means that a CS change is required between the first byte
> > sent, and the second one.
> > This change splits the single-transfer transfer of 2 bytes into 2 transfers
> > with a single byte, and CS change in-between.
> >
> > Signed-off-by: Dragos Bogdan
> > Signed-off-by: Alexandru Ardelean
>
> Fixes tag would have been nice. I've had a go by picking a patch where I
> refactored this code, but I think the issue probably predates that one.
> Its in 2011 so I doubt anyone will try going past that with backports ;)
>
Apologies again for not considering Fixes tag.
At this point, I feel bad for repeating the apology, as it may sound like hollow
words.
But, I guess this could have skipped going through the fixes route.
The patch has been living in our tree for a while.
> Applied to the fixes-togreg branch of iio.git and marked for stable.
>
> I'm guessing this means you have hardware and hope to get this one out
> of staging shortly? *crosses fingers* :)
Sorry, but not at this point in time.
I just fished this from our tree.
I also handle our kernel upgrades [on our side], and whenever I do an update,
some upstreamed patches disappear from our tree, and some stand-out and I wonder
how come this wasn't sent upstream.
This is one of them.
I don't know if I'll be able to find someone [in the near future] to allocate
this to [for moving out-of-staging].
Right now, the priority [on our side] is the high-speed converters.
>
> Jonathan
>
> > ---
> > drivers/staging/iio/resolver/ad2s1210.c | 17 -
> > 1 file changed, 12 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/staging/iio/resolver/ad2s1210.c
> > b/drivers/staging/iio/resolver/ad2s1210.c
> > index 4b25a3a314ed..ed404355ea4c 100644
> > --- a/drivers/staging/iio/resolver/ad2s1210.c
> > +++ b/drivers/staging/iio/resolver/ad2s1210.c
> > @@ -130,17 +130,24 @@ static int ad2s1210_config_write(struct ad2s1210_state
> > *st, u8 data)
> > static int ad2s1210_config_read(struct ad2s1210_state *st,
> > unsigned char address)
> > {
> > - struct spi_transfer xfer = {
> > - .len = 2,
> > - .rx_buf = st->rx,
> > - .tx_buf = st->tx,
> > + struct spi_transfer xfers[] = {
> > + {
> > + .len = 1,
> > + .rx_buf = >rx[0],
> > + .tx_buf = >tx[0],
> > + .cs_change = 1,
> > + }, {
> > + .len = 1,
> > + .rx_buf = >rx[1],
> > + .tx_buf = >tx[1],
> > + },
> > };
> > int ret = 0;
> >
> > ad2s1210_set_mode(MOD_CONFIG, st);
> > st->tx[0] = address | AD2S1210_MSB_IS_HIGH;
> > st->tx[1] = AD2S1210_REG_FAULT;
> > - ret = spi_sync_transfer(st->sdev, , 1);
> > + ret = spi_sync_transfer(st->sdev, xfers, 2);
> > if (ret < 0)
> > return ret;
> >
Re: [PATCH] staging: iio: ad5933: rework probe to use devm_ function variants
On Sat, 2020-05-02 at 19:25 +0100, Jonathan Cameron wrote:
> On Tue, 28 Apr 2020 12:31:28 +0300
> Alexandru Ardelean wrote:
>
> > This change cleans up the driver's probe function to use only devm_
> > function variants. This also gets rid of the remove function and moves the
> > clock & regulator de-initializations to the 'ad5933_cleanup()' callback.
> >
> > Signed-off-by: Alexandru Ardelean
>
> Basic rule of thumb. Whatever you register with devm_add_action_or_reset
> should only cleanup one one thing done in the probe path.
> There is almost always a race if you do more than one bit of cleanup
> per such callback + it's harder to review as it fails the 'obviously correct
> test'.
I did not know that.
That idea missed me up until now.
Will re-spin.
Thanks
Alex
>
> Jonathan
>
> > ---
> > .../staging/iio/impedance-analyzer/ad5933.c | 59 ---
> > 1 file changed, 23 insertions(+), 36 deletions(-)
> >
> > diff --git a/drivers/staging/iio/impedance-analyzer/ad5933.c
> > b/drivers/staging/iio/impedance-analyzer/ad5933.c
> > index af0bcf95ee8a..06a6dcd7883b 100644
> > --- a/drivers/staging/iio/impedance-analyzer/ad5933.c
> > +++ b/drivers/staging/iio/impedance-analyzer/ad5933.c
> > @@ -602,11 +602,12 @@ static const struct iio_buffer_setup_ops
> > ad5933_ring_setup_ops = {
> > .postdisable = ad5933_ring_postdisable,
> > };
> >
> > -static int ad5933_register_ring_funcs_and_init(struct iio_dev *indio_dev)
> > +static int ad5933_register_ring_funcs_and_init(struct device *dev,
> > + struct iio_dev *indio_dev)
> > {
> > struct iio_buffer *buffer;
> >
> > - buffer = iio_kfifo_allocate();
> > + buffer = devm_iio_kfifo_allocate(dev);
> > if (!buffer)
> > return -ENOMEM;
> >
> > @@ -676,6 +677,14 @@ static void ad5933_work(struct work_struct *work)
> > }
> > }
> >
> > +static void ad5933_cleanup(void *data)
> > +{
> > + struct ad5933_state *st = data;
> > +
> > + clk_disable_unprepare(st->mclk);
> > + regulator_disable(st->reg);
>
> Please do two separate callbacks so that these can be handled
> in the correct places. I.e. you do something then immediately
> register the handler to undo it.
>
> Currently you can end up disabling a clock you haven't enabled
> (which I am fairly sure will give you an error message).
>
> > +}
> > +
> > static int ad5933_probe(struct i2c_client *client,
> > const struct i2c_device_id *id)
> > {
> > @@ -703,23 +712,28 @@ static int ad5933_probe(struct i2c_client *client,
> > dev_err(>dev, "Failed to enable specified VDD
> > supply\n");
> > return ret;
> > }
> > +
> > + ret = devm_add_action_or_reset(>dev, ad5933_cleanup, st);
> > + if (ret)
> > + return ret;
> > +
> > ret = regulator_get_voltage(st->reg);
> >
> > if (ret < 0)
> > - goto error_disable_reg;
> > + return ret;
> >
> > st->vref_mv = ret / 1000;
> >
> > st->mclk = devm_clk_get(>dev, "mclk");
> > if (IS_ERR(st->mclk) && PTR_ERR(st->mclk) != -ENOENT) {
> > ret = PTR_ERR(st->mclk);
> > - goto error_disable_reg;
> > + return ret;
> > }
> >
> > if (!IS_ERR(st->mclk)) {
> > ret = clk_prepare_enable(st->mclk);
> > if (ret < 0)
> > - goto error_disable_reg;
> > + return ret;
> > ext_clk_hz = clk_get_rate(st->mclk);
> > }
> >
> > @@ -742,41 +756,15 @@ static int ad5933_probe(struct i2c_client *client,
> > indio_dev->channels = ad5933_channels;
> > indio_dev->num_channels = ARRAY_SIZE(ad5933_channels);
> >
> > - ret = ad5933_register_ring_funcs_and_init(indio_dev);
> > + ret = ad5933_register_ring_funcs_and_init(>dev, indio_dev);
> > if (ret)
> > - goto error_disable_mclk;
> > + return ret;
> >
> > ret = ad5933_setup(st);
> > if (ret)
> > - goto error_unreg_ring;
> > -
> > - ret = iio_device_register(indio_dev);
> > - if (ret)
> > - goto error_unreg_ring;
> > -
> > - return 0;
> > -
> > -error_unreg_ring:
> > - iio_kfifo_free(indio_dev->buffer);
> > -error_disable_mclk:
> > - clk_disable_unprepare(st->mclk);
> > -error_disable_reg:
> > - regulator_disable(st->reg);
> > -
> > - return ret;
> > -}
> > -
> > -static int ad5933_remove(struct i2c_client *client)
> > -{
> > - struct iio_dev *indio_dev = i2c_get_clientdata(client);
> > - struct ad5933_state *st = iio_priv(indio_dev);
> > -
> > - iio_device_unregister(indio_dev);
> > - iio_kfifo_free(indio_dev->buffer);
> > - regulator_disable(st->reg);
> > - clk_disable_unprepare(st->mclk);
> > + return ret;
> >
> > - return 0;
> > + return devm_iio_device_register(>dev, indio_dev);
> > }
> >
> > static const struct i2c_device_id ad5933_id[] = {
> > @@ -801,7 +789,6 @@ static struct i2c_driver ad5933_driver = {
> >
Re: [PATCH] iio: remove iio_get_debugfs_dentry() helper
On Thu, 2020-04-30 at 11:52 +0300, Alexandru Ardelean wrote:
> Not used anywhere.
> Looks like it was forgotten in iio.h
>
Actually, disregard this.
I've found places where 'indio_dev->debugfs_dentry' is accessed directly and
that should have used this instead.
Apologies for the spam.
> Signed-off-by: Alexandru Ardelean
> ---
> include/linux/iio/iio.h | 16
> 1 file changed, 16 deletions(-)
>
> diff --git a/include/linux/iio/iio.h b/include/linux/iio/iio.h
> index 38c4ea505394..1a1da52c55cf 100644
> --- a/include/linux/iio/iio.h
> +++ b/include/linux/iio/iio.h
> @@ -696,22 +696,6 @@ static inline bool iio_buffer_enabled(struct iio_dev
> *indio_dev)
> INDIO_BUFFER_SOFTWARE);
> }
>
> -/**
> - * iio_get_debugfs_dentry() - helper function to get the debugfs_dentry
> - * @indio_dev: IIO device structure for device
> - **/
> -#if defined(CONFIG_DEBUG_FS)
> -static inline struct dentry *iio_get_debugfs_dentry(struct iio_dev
> *indio_dev)
> -{
> - return indio_dev->debugfs_dentry;
> -}
> -#else
> -static inline struct dentry *iio_get_debugfs_dentry(struct iio_dev
> *indio_dev)
> -{
> - return NULL;
> -}
> -#endif
> -
> ssize_t iio_format_value(char *buf, unsigned int type, int size, int *vals);
>
> int iio_str_to_fixpoint(const char *str, int fract_mult, int *integer,
Re: [PATCH v2 1/2] iio: at91-sama5d2_adc: split at91_adc_current_chan_is_touch() helper
On Thu, 2020-04-30 at 07:30 +, Ardelean, Alexandru wrote:
> On Mon, 2020-04-27 at 13:00 +0000, Ardelean, Alexandru wrote:
> > [External]
> >
> > On Mon, 2020-04-27 at 12:20 +, eugen.hris...@microchip.com wrote:
> > > [External]
> > >
> > > On 15.04.2020 09:33, Ardelean, Alexandru wrote:
> > >
> > > > On Tue, 2020-04-14 at 18:45 +0100, Jonathan Cameron wrote:
> > > > > On Tue, 14 Apr 2020 12:22:45 +
> > > > > wrote:
> > > > >
> > > > > > On 13.04.2020 20:05, Jonathan Cameron wrote:
> > > > > > > On Wed, 4 Mar 2020 10:42:18 +0200
> > > > > > > Alexandru Ardelean wrote:
> > > > > > >
> > > > > > > > This change moves the logic to check if the current channel is
> > > > > > > > the
> > > > > > > > touchscreen channel to a separate helper.
> > > > > > > > This reduces some code duplication, but the main intent is to
> > > > > > > > re-
> > > > > > > > use
> > > > > > > > this
> > > > > > > > in the next patches.
> > > > > > > >
> > > > > > > > Signed-off-by: Alexandru Ardelean > > > > > > > >
> > > > > > > Eugen / Ludovic,
> > > > > > >
> > > > > > > Have you had a chance to look at this series?
> > > > > >
> > > > > > Hi Jonathan,
> > > > > >
> > > > > > Does the patch apply correctly for you ?
> > > > >
> > > > > I haven't tried yet :)
> > > > >
> > > >
> > > > I've rebased this patchset on top of current iio/testing and it still
> > > > applies.
> > > >
> > >
> > > Hi Alex,
> > >
> > > I tried this patch on top of my tree (however I am testing with an older
> > > kernel 5.4) , and I have issues starting the buffer after you moved my
> > > code to the preenable callback.
> > >
> > > Namely, on the line:
> > >
> > > if (!(indio_dev->currentmode & INDIO_ALL_TRIGGERED_MODES))
> > > return -EINVAL;
>
> In the meantime I found this patch:
> https://urldefense.com/v3/__https://lore.kernel.org/linux-iio/1431525891-19285-5-git-send-email-l...@metafoo.de/__;!!A3Ni8CS0y2Y!ocQuNvFF_8rd-cCvMNXU0cTk9mLezpCPyzelQyhbxMGdKgFo0_JTgTD1q1VU-kj10aqxxA$
>
>
> from about ~5 years ago;
>
> if this patch is a valid proposal, it could fix this case as well;
> well, it might break others, so applying it [now] would need some general
> review
> of all pre/post enable/disable hooks
>
So, apologies if this will start to seem like spamming.
I decided to do a bit of shell magic for this:
get_files() {
git grep -w iio_buffer_setup_ops | grep drivers | cut -d: -f1 | sort | uniq
}
for file in $(get_files) ; do
if grep -q currentmode $file ; then
echo $file
fi
done
It finds 4 drivers.
Though, `get_files()` will return 56 files.
drivers/iio/accel/bmc150-accel-core.c
drivers/iio/adc/at91-sama5d2_adc.c
drivers/iio/adc/stm32-dfsdm-adc.c
drivers/iio/magnetometer/rm3100-core.c
The rm3100 driver doesn't do any checks in the setup_ops for 'currentmode' as
far as I could see.
So, Lars' patch could work nicely to fix this current case and not break others.
Semantically though, it would sound nicer to have a 'nextmode' parameter
somewhere; maybe on the setup_ops(indio_dev, nextmode)?
Though, only those 3 drivers would really ever use it; so doing it like that
sounds like overkill.
So, we're left with Lars' patch or we could add an 'indio_dev->nextmode' field,
that may be used in just these 3 drivers [which again: sounds overkill at this
point in time].
Alternatively, this 'indio_dev->currentmode' could be removed from all these 3
drivers somehow. But that needs testing and a thorough understanding of all 3
drivers and what they're doing, to do properly.
@Jonathan: what do you think?
In any case, pending a reply, I'll send Lars' patch.
Even if we come to a different conclusion we have something to start with.
But, if the conclusion is that Lars' patch is a good solution now, it can be
applied.
> > Apologies for the breakage.
> >
> > For the touch-part I don't see that code being executed.
> >
> > But a question is: does the driver need to check for the currentmode?
> > Or is that something that the IIO core should do?
> >
> > > And with this , the preenable fails on my side, because the current mo
Re: [PATCH v2 1/2] iio: at91-sama5d2_adc: split at91_adc_current_chan_is_touch() helper
On Mon, 2020-04-27 at 13:00 +, Ardelean, Alexandru wrote: > [External] > > On Mon, 2020-04-27 at 12:20 +, eugen.hris...@microchip.com wrote: > > [External] > > > > On 15.04.2020 09:33, Ardelean, Alexandru wrote: > > > > > On Tue, 2020-04-14 at 18:45 +0100, Jonathan Cameron wrote: > > > > On Tue, 14 Apr 2020 12:22:45 + > > > > wrote: > > > > > > > > > On 13.04.2020 20:05, Jonathan Cameron wrote: > > > > > > On Wed, 4 Mar 2020 10:42:18 +0200 > > > > > > Alexandru Ardelean wrote: > > > > > > > > > > > > > This change moves the logic to check if the current channel is the > > > > > > > touchscreen channel to a separate helper. > > > > > > > This reduces some code duplication, but the main intent is to re- > > > > > > > use > > > > > > > this > > > > > > > in the next patches. > > > > > > > > > > > > > > Signed-off-by: Alexandru Ardelean > > > > > > Eugen / Ludovic, > > > > > > > > > > > > Have you had a chance to look at this series? > > > > > > > > > > Hi Jonathan, > > > > > > > > > > Does the patch apply correctly for you ? > > > > > > > > I haven't tried yet :) > > > > > > > > > > I've rebased this patchset on top of current iio/testing and it still > > > applies. > > > > > > > Hi Alex, > > > > I tried this patch on top of my tree (however I am testing with an older > > kernel 5.4) , and I have issues starting the buffer after you moved my > > code to the preenable callback. > > > > Namely, on the line: > > > > if (!(indio_dev->currentmode & INDIO_ALL_TRIGGERED_MODES)) > > return -EINVAL; > In the meantime I found this patch: https://lore.kernel.org/linux-iio/1431525891-19285-5-git-send-email-l...@metafoo.de/ from about ~5 years ago; if this patch is a valid proposal, it could fix this case as well; well, it might break others, so applying it [now] would need some general review of all pre/post enable/disable hooks > Apologies for the breakage. > > For the touch-part I don't see that code being executed. > > But a question is: does the driver need to check for the currentmode? > Or is that something that the IIO core should do? > > > And with this , the preenable fails on my side, because the current mode > > is not yet switched to triggered. > > > > I do remember adding this line with a specific reason. It may be related > > to touchscreen operations, but I have to retest the touch with and > > without this line and your patch. > > > > Meanwhile, maybe you have any suggestions on how to fix the buffer ? > > Well, there was the question of whether iio_triggered_buffer_postenable() [to > attach the pollfunc] makes sense to be called first/last in the old > at91_adc_buffer_postenable(), and the answer was 'last'; so then one solution > was to move things to preenable(). > > Going back to the old patch isn't ideal, as the idea was to make the position > of > iio_triggered_buffer_postenable() consistent across all drivers, so that it > can > be removed [and moved to the IIO core]. > > But if we need revert the patch, then I guess it's fine. > The only solution I see right now [for going forward], is to remove that check > for 'currrentmode' > > > This check here makes any sense to you ? > > I think Jonathan may have to add some input here, but I think that in this > current situation, checking 'currentmode' looks like is re-validating how the > device was configured via the IIO framework. > I am not sure if it's needed or not. > > > Thanks, > > Eugen > > > > > > > I will try to test it , if I manage to apply it. > > > > > I can only test the ADC though because at this moment I do not have a > > > > > touchscreen at disposal. > > > > > > > > > > Meanwhile, the code looks good for me, > > > > > > > > > > Reviewed-by: Eugen Hristev > > > > > > > > > > By the way, I do not know if my two pending patches on this driver > > > > > will > > > > > conflict or not. > > > > > > > > As this is a long term rework patch at heart, there isn't any particular > > > > rush as long as we don't loose it forever! >
Re: [PATCH] staging: iio: ad9834: add a check for devm_clk_get
On Wed, 2019-10-16 at 22:25 +0800, Chuhong Yuan wrote:
> ad9834_probe misses a check for devm_clk_get and may cause problems.
> Add a check like what ad9832 does to fix it.
>
This could also use a Fixes tag, but not a big deal.
Reviewed-by: Alexandru Ardelean
> Signed-off-by: Chuhong Yuan
> ---
> drivers/staging/iio/frequency/ad9834.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/staging/iio/frequency/ad9834.c
> b/drivers/staging/iio/frequency/ad9834.c
> index 038d6732c3fd..23026978a5a5 100644
> --- a/drivers/staging/iio/frequency/ad9834.c
> +++ b/drivers/staging/iio/frequency/ad9834.c
> @@ -417,6 +417,10 @@ static int ad9834_probe(struct spi_device *spi)
> st = iio_priv(indio_dev);
> mutex_init(>lock);
> st->mclk = devm_clk_get(>dev, NULL);
> + if (IS_ERR(st->mclk)) {
> + ret = PTR_ERR(st->mclk);
> + goto error_disable_reg;
> + }
>
> ret = clk_prepare_enable(st->mclk);
> if (ret) {
Re: [PATCH] dmaengine: axi-dmac: simple device_config operation implemented
On Wed, 2019-10-16 at 10:38 +0530, Vinod Koul wrote: > [External] > > On 15-10-19, 23:06, Lars-Peter Clausen wrote: > > > > > This DMA controller is a bit special. > > > > It gets synthesized in FPGA, so the configuration is fixed and > > > > cannot be > > > > changed at runtime. Maybe later we would allow/implement this > > > > functionality, but this is a question for my HDL colleagues. > > > > > > > > Two things are done (in this order): > > > > 1. For some paramters, axi_dmac_parse_chan_dt() is used to > > > > determine things > > > > from device-tree; as it's an FPGA core, things are synthesized once > > > > and > > > > cannot change (yet) > > > > 2. For other parameters, the axi_dmac_detect_caps() is used to > > > > guess some > > > > of them at probe time, by doing some reg reads/writes > > > > > > So the question for you hw folks is how would a controller work with > > > multiple slave devices, do they need to synthesize it everytime? > > > > > > Rather than that why cant they make the peripheral addresses > > > programmable so that you dont need updating fpga everytime! > > > > The DMA has a direct connection to the peripheral and the peripheral > > data port is not connected to the general purpose memory interconnect. > > So you can't write to it by an MMIO address and there is no > > address > > that needs to be configured. For an FPGA based design this is quite a > > good solution in terms of resource usage, performance and simplicity. A > > direct connection requires less resources than connection it to the > > central memory interconnect, while at the same time having lower > > latency > > and not eating up any additional bandwidth on the central memory > > connect. > > thanks for explanation! also many thanks [from my side] for the explanations :) > > > So slave config in this case is a noop and all it can do is verify that > > the requested configuration matches the available configuration. > > okay so noop it is! >
Re: [PATCH] dmaengine: axi-dmac: simple device_config operation implemented
On Mon, 2019-10-14 at 12:31 +0530, Vinod Koul wrote:
> [External]
>
Hey,
> On 13-09-19, 17:54, Alexandru Ardelean wrote:
> > From: Rodrigo Alencar
> >
> > dmaengine_slave_config is called by dmaengine_pcm_hw_params when using
> > axi-i2s with axi-dmac. If device_config is NULL, -ENOSYS is returned,
> > which breaks the snd_pcm_hw_params function.
> > This is a fix for the error:
>
> and what is that?
>
> > $ aplay -D plughw:ADAU1761 /usr/share/sounds/alsa/Front_Center.wav
> > Playing WAVE '/usr/share/sounds/alsa/Front_Center.wav' : Signed 16 bit
> > Little Endian, Rate 48000 Hz, Mono
> > axi-i2s 43c2.axi-i2s: ASoC: 43c2.axi-i2s hw params failed: -38
Error is above this line [code -38].
> > aplay: set_params:1403: Unable to install hw params:
> > ACCESS: RW_INTERLEAVED
> > FORMAT: S16_LE
> > SUBFORMAT: STD
> > SAMPLE_BITS: 16
> > FRAME_BITS: 16
> > CHANNELS: 1
> > RATE: 48000
> > PERIOD_TIME: 125000
> > PERIOD_SIZE: 6000
> > PERIOD_BYTES: 12000
> > PERIODS: 4
> > BUFFER_TIME: 50
> > BUFFER_SIZE: 24000
> > BUFFER_BYTES: 48000
> > TICK_TIME: 0
> >
> > Signed-off-by: Rodrigo Alencar
> > Signed-off-by: Alexandru Ardelean
> > ---
> >
> > Note: Fixes tag not added intentionally.
> >
> > drivers/dma/dma-axi-dmac.c | 16
> > 1 file changed, 16 insertions(+)
> >
> > diff --git a/drivers/dma/dma-axi-dmac.c b/drivers/dma/dma-axi-dmac.c
> > index a0ee404b736e..ab2677343202 100644
> > --- a/drivers/dma/dma-axi-dmac.c
> > +++ b/drivers/dma/dma-axi-dmac.c
> > @@ -564,6 +564,21 @@ static struct dma_async_tx_descriptor
> > *axi_dmac_prep_slave_sg(
> > return vchan_tx_prep(>vchan, >vdesc, flags);
> > }
> >
> > +static int axi_dmac_device_config(struct dma_chan *c,
> > + struct dma_slave_config *slave_config)
> > +{
> > + struct axi_dmac_chan *chan = to_axi_dmac_chan(c);
> > + struct axi_dmac *dmac = chan_to_axi_dmac(chan);
> > +
> > + /* no configuration required, a sanity check is done instead */
> > + if (slave_config->direction != chan->direction) {
>
> slave_config->direction is a deprecated field, pls dont use that
ack
any alternative recommendations of what to do in this case?
i can take a look, but if you have something on-the-top-of-your-head, i'm
open to suggestions
we can also just drop this completely and let userspace fail
>
> > + dev_err(dmac->dma_dev.dev, "Direction not supported by this
> > DMA Channel");
> > + return -EINVAL;
>
> So you intent to support slave dma but do not use dma_slave_config.. how
> are you getting the slave address and other details?
This DMA controller is a bit special.
It gets synthesized in FPGA, so the configuration is fixed and cannot be
changed at runtime. Maybe later we would allow/implement this
functionality, but this is a question for my HDL colleagues.
Two things are done (in this order):
1. For some paramters, axi_dmac_parse_chan_dt() is used to determine things
from device-tree; as it's an FPGA core, things are synthesized once and
cannot change (yet)
2. For other parameters, the axi_dmac_detect_caps() is used to guess some
of them at probe time, by doing some reg reads/writes
I'll admit that maybe the whole approach could be done a bit
differently/better. But I guess this approach was chosen by the fact that
it's FPGA.
Btw: if I'm talking crap, or I may sound like I don't know what I'm talking
about, that could also be true. I am not quite versed in the DMAEngine
framework.
Thanks
Alex
>
> Thanks
Re: [PATCH 2/2] iio: light: Add support for ADUX1020 sensor
On Wed, 2019-10-09 at 15:15 +0530, Manivannan Sadhasivam wrote: > [External] > > Hi Ardelean, > > Thanks for the quick review! > > On Tue, Oct 08, 2019 at 06:52:50AM +, Ardelean, Alexandru wrote: > > On Mon, 2019-10-07 at 15:40 +0530, Manivannan Sadhasivam wrote: > > > [External] > > > > > > > Hey, > > > > Comments inline. > > > > I thought I sent an initial review, but seems to have gotten lost > > [maybe in > > my email client]. > > Oh well. I managed to re-do it anyway. > > > > I tried to group them this time. > > > > The more prominent part is [3]; this driver needs a bit more error > > checking > > on regmap_() returns. > > > > Yes, agree. I forgot that I'm not working on memory mapped region ;-) > > > Generally some notes: > > - Is there a need to implement the 32Khz or 32Mhz clock calibration > > routines on startup? Some drivers need this, some don't/ > > Calibration is required to have the precise reading but it is not a > blocker. > We can add it later. Fine from my side. I should have also mentioned this earlier [that the calibration can be added later]. > > > - From the functional diagram, it looks like maybe the VREF would be > > needed > > to be hooked via a regulator framework; but this could be done later > > Right but the reference board schematics is not very clear about VREF and > neither the sensor datasheet. That's why I intentionally left it. Will > get > in touch with the board vendor to figure out what is the recommended VREF > voltage and submit a patch later. ack; well, typically [for the driver] VREF support is just added in the driver and then the board device-tree just implements what it needs [that is, if it needs it]; some board designs just have a fixed value, and the driver does not need to care/know about the VREF regulator; the idea of adding regulator support in the driver is to allow the driver to initialize it [if there is a device-tree entry for it] but this can be done later; > > > - Just curios here: there is gesture mode as well; will that be > > implemented > > later? Or will there be other modes implemented? > > Currently only proximity mode is implemented. There are gesture and > sample > modes and I left those as a TODO. But I'm not sure whether IIO is > supporting > gesture mode properly or not. I don't have any input on this at the moment [about gesture support & IIO]. I'd have to investigate. Maybe Jonathan has some thoughts. > > > If I remember anything else I may come back with a reply. > > > > Sure. > > > Thanks > > Alex > > > > > Add initial support for Analog Devices ADUX1020 Photometric sensor. > > > Only proximity mode has been enabled for now. > > > > > > Signed-off-by: Manivannan Sadhasivam < > > > manivannan.sadhasi...@linaro.org> > > > --- > > > drivers/iio/light/Kconfig| 11 + > > > drivers/iio/light/Makefile | 1 + > > > drivers/iio/light/adux1020.c | 783 > > > +++ > > > > Does MAINTAINERS need updating as well? > > > > I don't prefer to have MAINTAINERS entry for small drivers like this. > Anyway, get_maintainers will return my mailing address based on the > commit signing. ack > > > > 3 files changed, 795 insertions(+) > > > create mode 100644 drivers/iio/light/adux1020.c > > > > > > diff --git a/drivers/iio/light/Kconfig b/drivers/iio/light/Kconfig > > > index 08d7e1ef2186..3f8c8689cd89 100644 > > > --- a/drivers/iio/light/Kconfig > > > +++ b/drivers/iio/light/Kconfig > > > @@ -32,6 +32,17 @@ config ADJD_S311 > > > This driver can also be built as a module. If so, the module > > > will be called adjd_s311. > > > > > > +config ADUX1020 > > > + tristate "ADUX1020 photometric sensor" > > > + select REGMAP_I2C > > > + depends on I2C > > > + help > > > + Say Y here if you want to build a driver for the Analog Devices > > > + ADUX1020 photometric sensor. > > > + > > > + To compile this driver as a module, choose M here: the > > > + module will be called adux1020. > > > + > > > config AL3320A > > > tristate "AL3320A ambient light sensor" > > > depends on I2C > > > diff --git a/drivers/iio/light/Makefile b/drivers/iio/light/Makefile > > > index 00d1f9b98f39..5d650ce46a40 100644 > > > --- a/drivers/iio/light/Makefile > > > +++ b/driver
Re: [PATCH 02/10] iio: imu: adis: add unlocked read/write function versions
On Tue, 2019-10-08 at 08:47 +, Ardelean, Alexandru wrote:
> [External]
>
> On Tue, 2019-10-08 at 06:54 +, Ardelean, Alexandru wrote:
> > [External]
> >
> > On Mon, 2019-10-07 at 22:16 +0100, Jonathan Cameron wrote:
> > > On Sun, 6 Oct 2019 10:12:01 +0100
> > > Jonathan Cameron wrote:
> > >
> > > > On Thu, 26 Sep 2019 14:18:04 +0300
> > > > Alexandru Ardelean wrote:
> > > >
> > > > > This will allow more flexible control to group reads & writes
> > > > > into
> > > > > a
> > > > > single
> > > > > lock (particularly the state_lock).
> > > > >
> > > > > The end-goal is to remove the indio_dev->mlock usage, and the
> > > > > simplest fix
> > > > > would have been to just add another lock, which would not be a
> > > > > good
> > > > > idea on
> > > > > the long-run.
> > > > >
> > > > > Signed-off-by: Alexandru Ardelean
> > > > >
> > > > Applied to the togreg branch of iio.git and pushed out as testing
> > > > etc.
> > > >
> > > > Jonathan
> > > >
> > > 0-day found a potential issue (kind of) in the read functions.
> > >
> > > > > ---
> > > > > drivers/iio/imu/adis.c | 34 +--
> > > > > include/linux/iio/imu/adis.h | 114
> > > > > ++-
> > > > > 2 files changed, 128 insertions(+), 20 deletions(-)
> > > > >
> > > > > diff --git a/drivers/iio/imu/adis.c b/drivers/iio/imu/adis.c
> > > > > index 3c2d896e3a96..4f3be011c898 100644
> > > > > --- a/drivers/iio/imu/adis.c
> > > > > +++ b/drivers/iio/imu/adis.c
> > > > > @@ -26,7 +26,14 @@
> > > > > #define ADIS_MSC_CTRL_DATA_RDY_DIO2 BIT(0)
> > > > > #define ADIS_GLOB_CMD_SW_RESET BIT(7)
> > > > >
> > > > > -int adis_write_reg(struct adis *adis, unsigned int reg,
> > > > > +/**
> > > > > + * __adis_write_reg() - write N bytes to register (unlocked
> > > > > version)
> > > > > + * @adis: The adis device
> > > > > + * @reg: The address of the lower of the two registers
> > > > > + * @value: The value to write to device (up to 4 bytes)
> > > > > + * @size: The size of the @value (in bytes)
> > > > > + */
> > > > > +int __adis_write_reg(struct adis *adis, unsigned int reg,
> > > > > unsigned int value, unsigned int size)
> > > > > {
> > > > > unsigned int page = reg / ADIS_PAGE_SIZE;
> > > > > @@ -70,8 +77,6 @@ int adis_write_reg(struct adis *adis, unsigned
> > > > > int
> > > > > reg,
> > > > > },
> > > > > };
> > > > >
> > > > > - mutex_lock(>state_lock);
> > > > > -
> > > > > spi_message_init();
> > > > >
> > > > > if (adis->current_page != page) {
> > > > > @@ -96,8 +101,7 @@ int adis_write_reg(struct adis *adis, unsigned
> > > > > int
> > > > > reg,
> > > > > adis->tx[3] = value & 0xff;
> > > > > break;
> > > > > default:
> > > > > - ret = -EINVAL;
> > > > > - goto out_unlock;
> > > > > + return -EINVAL;
> > > > > }
> > > > >
> > > > > xfers[size].cs_change = 0;
> > > > > @@ -113,20 +117,18 @@ int adis_write_reg(struct adis *adis,
> > > > > unsigned
> > > > > int reg,
> > > > > adis->current_page = page;
> > > > > }
> > > > >
> > > > > -out_unlock:
> > > > > - mutex_unlock(>state_lock);
> > > > > -
> > > > > return ret;
> > > > > }
> > > > > -EXPORT_SYMBOL_GPL(adis_write_reg);
> > > > > +EXPORT_SYMBOL_GPL(__adis_write_reg);
> > > > >
> > > > > /**
> > > > > - * adis_read_reg() - read 2 bytes from a 16-bit register
> > > > > + * __adis_read_reg() - read N bytes from register (unlocked
> > > > > ver
Re: [PATCH 02/10] iio: imu: adis: add unlocked read/write function versions
On Tue, 2019-10-08 at 06:54 +, Ardelean, Alexandru wrote:
> [External]
>
> On Mon, 2019-10-07 at 22:16 +0100, Jonathan Cameron wrote:
> > On Sun, 6 Oct 2019 10:12:01 +0100
> > Jonathan Cameron wrote:
> >
> > > On Thu, 26 Sep 2019 14:18:04 +0300
> > > Alexandru Ardelean wrote:
> > >
> > > > This will allow more flexible control to group reads & writes into
> > > > a
> > > > single
> > > > lock (particularly the state_lock).
> > > >
> > > > The end-goal is to remove the indio_dev->mlock usage, and the
> > > > simplest fix
> > > > would have been to just add another lock, which would not be a good
> > > > idea on
> > > > the long-run.
> > > >
> > > > Signed-off-by: Alexandru Ardelean
> > > Applied to the togreg branch of iio.git and pushed out as testing
> > > etc.
> > >
> > > Jonathan
> > >
> > 0-day found a potential issue (kind of) in the read functions.
> >
> > > > ---
> > > > drivers/iio/imu/adis.c | 34 +--
> > > > include/linux/iio/imu/adis.h | 114
> > > > ++-
> > > > 2 files changed, 128 insertions(+), 20 deletions(-)
> > > >
> > > > diff --git a/drivers/iio/imu/adis.c b/drivers/iio/imu/adis.c
> > > > index 3c2d896e3a96..4f3be011c898 100644
> > > > --- a/drivers/iio/imu/adis.c
> > > > +++ b/drivers/iio/imu/adis.c
> > > > @@ -26,7 +26,14 @@
> > > > #define ADIS_MSC_CTRL_DATA_RDY_DIO2BIT(0)
> > > > #define ADIS_GLOB_CMD_SW_RESET BIT(7)
> > > >
> > > > -int adis_write_reg(struct adis *adis, unsigned int reg,
> > > > +/**
> > > > + * __adis_write_reg() - write N bytes to register (unlocked
> > > > version)
> > > > + * @adis: The adis device
> > > > + * @reg: The address of the lower of the two registers
> > > > + * @value: The value to write to device (up to 4 bytes)
> > > > + * @size: The size of the @value (in bytes)
> > > > + */
> > > > +int __adis_write_reg(struct adis *adis, unsigned int reg,
> > > > unsigned int value, unsigned int size)
> > > > {
> > > > unsigned int page = reg / ADIS_PAGE_SIZE;
> > > > @@ -70,8 +77,6 @@ int adis_write_reg(struct adis *adis, unsigned
> > > > int
> > > > reg,
> > > > },
> > > > };
> > > >
> > > > - mutex_lock(>state_lock);
> > > > -
> > > > spi_message_init();
> > > >
> > > > if (adis->current_page != page) {
> > > > @@ -96,8 +101,7 @@ int adis_write_reg(struct adis *adis, unsigned
> > > > int
> > > > reg,
> > > > adis->tx[3] = value & 0xff;
> > > > break;
> > > > default:
> > > > - ret = -EINVAL;
> > > > - goto out_unlock;
> > > > + return -EINVAL;
> > > > }
> > > >
> > > > xfers[size].cs_change = 0;
> > > > @@ -113,20 +117,18 @@ int adis_write_reg(struct adis *adis,
> > > > unsigned
> > > > int reg,
> > > > adis->current_page = page;
> > > > }
> > > >
> > > > -out_unlock:
> > > > - mutex_unlock(>state_lock);
> > > > -
> > > > return ret;
> > > > }
> > > > -EXPORT_SYMBOL_GPL(adis_write_reg);
> > > > +EXPORT_SYMBOL_GPL(__adis_write_reg);
> > > >
> > > > /**
> > > > - * adis_read_reg() - read 2 bytes from a 16-bit register
> > > > + * __adis_read_reg() - read N bytes from register (unlocked
> > > > version)
> > > > * @adis: The adis device
> > > > * @reg: The address of the lower of the two registers
> > > > * @val: The value read back from the device
> > > > + * @size: The size of the @val buffer
> > > > */
> > > > -int adis_read_reg(struct adis *adis, unsigned int reg,
> > > > +int __adis_read_reg(struct adis *adis, unsigned int reg,
> > > > unsigned int *val, unsigned int size)
> > > > {
> > > > unsigned int page = reg / ADIS_PAGE_SIZE;
> > > >
Re: [PATCH 02/10] iio: imu: adis: add unlocked read/write function versions
On Mon, 2019-10-07 at 22:16 +0100, Jonathan Cameron wrote:
> On Sun, 6 Oct 2019 10:12:01 +0100
> Jonathan Cameron wrote:
>
> > On Thu, 26 Sep 2019 14:18:04 +0300
> > Alexandru Ardelean wrote:
> >
> > > This will allow more flexible control to group reads & writes into a
> > > single
> > > lock (particularly the state_lock).
> > >
> > > The end-goal is to remove the indio_dev->mlock usage, and the
> > > simplest fix
> > > would have been to just add another lock, which would not be a good
> > > idea on
> > > the long-run.
> > >
> > > Signed-off-by: Alexandru Ardelean
> > Applied to the togreg branch of iio.git and pushed out as testing etc.
> >
> > Jonathan
> >
> 0-day found a potential issue (kind of) in the read functions.
>
> > > ---
> > > drivers/iio/imu/adis.c | 34 +--
> > > include/linux/iio/imu/adis.h | 114
> > > ++-
> > > 2 files changed, 128 insertions(+), 20 deletions(-)
> > >
> > > diff --git a/drivers/iio/imu/adis.c b/drivers/iio/imu/adis.c
> > > index 3c2d896e3a96..4f3be011c898 100644
> > > --- a/drivers/iio/imu/adis.c
> > > +++ b/drivers/iio/imu/adis.c
> > > @@ -26,7 +26,14 @@
> > > #define ADIS_MSC_CTRL_DATA_RDY_DIO2 BIT(0)
> > > #define ADIS_GLOB_CMD_SW_RESET BIT(7)
> > >
> > > -int adis_write_reg(struct adis *adis, unsigned int reg,
> > > +/**
> > > + * __adis_write_reg() - write N bytes to register (unlocked version)
> > > + * @adis: The adis device
> > > + * @reg: The address of the lower of the two registers
> > > + * @value: The value to write to device (up to 4 bytes)
> > > + * @size: The size of the @value (in bytes)
> > > + */
> > > +int __adis_write_reg(struct adis *adis, unsigned int reg,
> > > unsigned int value, unsigned int size)
> > > {
> > > unsigned int page = reg / ADIS_PAGE_SIZE;
> > > @@ -70,8 +77,6 @@ int adis_write_reg(struct adis *adis, unsigned int
> > > reg,
> > > },
> > > };
> > >
> > > - mutex_lock(>state_lock);
> > > -
> > > spi_message_init();
> > >
> > > if (adis->current_page != page) {
> > > @@ -96,8 +101,7 @@ int adis_write_reg(struct adis *adis, unsigned int
> > > reg,
> > > adis->tx[3] = value & 0xff;
> > > break;
> > > default:
> > > - ret = -EINVAL;
> > > - goto out_unlock;
> > > + return -EINVAL;
> > > }
> > >
> > > xfers[size].cs_change = 0;
> > > @@ -113,20 +117,18 @@ int adis_write_reg(struct adis *adis, unsigned
> > > int reg,
> > > adis->current_page = page;
> > > }
> > >
> > > -out_unlock:
> > > - mutex_unlock(>state_lock);
> > > -
> > > return ret;
> > > }
> > > -EXPORT_SYMBOL_GPL(adis_write_reg);
> > > +EXPORT_SYMBOL_GPL(__adis_write_reg);
> > >
> > > /**
> > > - * adis_read_reg() - read 2 bytes from a 16-bit register
> > > + * __adis_read_reg() - read N bytes from register (unlocked version)
> > > * @adis: The adis device
> > > * @reg: The address of the lower of the two registers
> > > * @val: The value read back from the device
> > > + * @size: The size of the @val buffer
> > > */
> > > -int adis_read_reg(struct adis *adis, unsigned int reg,
> > > +int __adis_read_reg(struct adis *adis, unsigned int reg,
> > > unsigned int *val, unsigned int size)
> > > {
> > > unsigned int page = reg / ADIS_PAGE_SIZE;
> > > @@ -188,15 +190,14 @@ int adis_read_reg(struct adis *adis, unsigned
> > > int reg,
> > > spi_message_add_tail([3], );
> > > break;
> > > default:
> > > - ret = -EINVAL;
> > > - goto out_unlock;
> > > + return -EINVAL;
> > > }
> > >
> > > ret = spi_sync(adis->spi, );
> > > if (ret) {
> > > dev_err(>spi->dev, "Failed to read register 0x%02X:
> > > %d\n",
> > > reg, ret);
> > > - goto out_unlock;
> > > + return ret;
> > > } else {
> > > adis->current_page = page;
> > > }
> > > @@ -210,12 +211,9 @@ int adis_read_reg(struct adis *adis, unsigned
> > > int reg,
> > > break;
> > > }
> > >
> > > -out_unlock:
> > > - mutex_unlock(>state_lock);
> > > -
> > > return ret;
> > > }
> > > -EXPORT_SYMBOL_GPL(adis_read_reg);
> > > +EXPORT_SYMBOL_GPL(__adis_read_reg);
> > >
> > > #ifdef CONFIG_DEBUG_FS
> > >
> > > diff --git a/include/linux/iio/imu/adis.h
> > > b/include/linux/iio/imu/adis.h
> > > index 3ed5eceaac2d..3a028c40e04e 100644
> > > --- a/include/linux/iio/imu/adis.h
> > > +++ b/include/linux/iio/imu/adis.h
> > > @@ -75,11 +75,121 @@ int adis_init(struct adis *adis, struct iio_dev
> > > *indio_dev,
> > > struct spi_device *spi, const struct adis_data *data);
> > > int adis_reset(struct adis *adis);
> > >
> > > -int adis_write_reg(struct adis *adis, unsigned int reg,
> > > +int __adis_write_reg(struct adis *adis, unsigned int reg,
> > > unsigned int val, unsigned int size);
> > > -int adis_read_reg(struct adis *adis, unsigned int reg,
> > > +int __adis_read_reg(struct adis *adis, unsigned int reg,
> > > unsigned
Re: [PATCH 2/2] iio: light: Add support for ADUX1020 sensor
On Mon, 2019-10-07 at 15:40 +0530, Manivannan Sadhasivam wrote: > [External] > Hey, Comments inline. I thought I sent an initial review, but seems to have gotten lost [maybe in my email client]. Oh well. I managed to re-do it anyway. I tried to group them this time. The more prominent part is [3]; this driver needs a bit more error checking on regmap_() returns. Generally some notes: - Is there a need to implement the 32Khz or 32Mhz clock calibration routines on startup? Some drivers need this, some don't/ - From the functional diagram, it looks like maybe the VREF would be needed to be hooked via a regulator framework; but this could be done later - Just curios here: there is gesture mode as well; will that be implemented later? Or will there be other modes implemented? If I remember anything else I may come back with a reply. Thanks Alex > Add initial support for Analog Devices ADUX1020 Photometric sensor. > Only proximity mode has been enabled for now. > > Signed-off-by: Manivannan Sadhasivam > --- > drivers/iio/light/Kconfig| 11 + > drivers/iio/light/Makefile | 1 + > drivers/iio/light/adux1020.c | 783 +++ Does MAINTAINERS need updating as well? > 3 files changed, 795 insertions(+) > create mode 100644 drivers/iio/light/adux1020.c > > diff --git a/drivers/iio/light/Kconfig b/drivers/iio/light/Kconfig > index 08d7e1ef2186..3f8c8689cd89 100644 > --- a/drivers/iio/light/Kconfig > +++ b/drivers/iio/light/Kconfig > @@ -32,6 +32,17 @@ config ADJD_S311 > This driver can also be built as a module. If so, the module > will be called adjd_s311. > > +config ADUX1020 > + tristate "ADUX1020 photometric sensor" > + select REGMAP_I2C > + depends on I2C > + help > + Say Y here if you want to build a driver for the Analog Devices > + ADUX1020 photometric sensor. > + > + To compile this driver as a module, choose M here: the > + module will be called adux1020. > + > config AL3320A > tristate "AL3320A ambient light sensor" > depends on I2C > diff --git a/drivers/iio/light/Makefile b/drivers/iio/light/Makefile > index 00d1f9b98f39..5d650ce46a40 100644 > --- a/drivers/iio/light/Makefile > +++ b/drivers/iio/light/Makefile > @@ -6,6 +6,7 @@ > # When adding new entries keep the list in alphabetical order > obj-$(CONFIG_ACPI_ALS) += acpi-als.o > obj-$(CONFIG_ADJD_S311) += adjd_s311.o > +obj-$(CONFIG_ADUX1020) += adux1020.o > obj-$(CONFIG_AL3320A)+= al3320a.o > obj-$(CONFIG_APDS9300) += apds9300.o > obj-$(CONFIG_APDS9960) += apds9960.o > diff --git a/drivers/iio/light/adux1020.c b/drivers/iio/light/adux1020.c > new file mode 100644 > index ..d0b76e5b44f1 > --- /dev/null > +++ b/drivers/iio/light/adux1020.c > @@ -0,0 +1,783 @@ > +// SPDX-License-Identifier: GPL-2.0+ > +/* > + * adux1020.c - Support for Analog Devices ADUX1020 photometric sensor Maybe drop the adux1020.c part? I think something like this should be sufficient: "Analog Devices ADUX1020 photometric sensor" > + * > + * Copyright (C) 2019 Linaro Ltd. > + * Author: Manivannan Sadhasivam > + * > + * TODO: Triggered buffer support Maybe drop the TODO? It's not needed for mainline. > + */ > + > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > + > +#include > +#include > +#include > + > +#define ADUX1020_REGMAP_NAME "adux1020_regmap" > +#define ADUX1020_DRV_NAME"adux1020" > + > +/* System registers */ > +#define ADUX1020_REG_CHIP_ID 0x08 > +#define ADUX1020_REG_SLAVE_ADDRESS 0x09 > + > +#define ADUX1020_REG_SW_RESET0x0f > +#define ADUX1020_REG_INT_ENABLE 0x1c > +#define ADUX1020_REG_INT_POLARITY0x1d > +#define ADUX1020_REG_PROX_TH_ON1 0x2a > +#define ADUX1020_REG_PROX_TH_OFF10x2b > +#define ADUX1020_REG_PROX_TYPE 0x2f > +#define ADUX1020_REG_TEST_MODES_3 0x32 > +#define ADUX1020_REG_FORCE_MODE 0x33 > +#define ADUX1020_REG_FREQUENCY 0x40 > +#define ADUX1020_REG_LED_CURRENT 0x41 > +#define ADUX1020_REG_OP_MODE0x45 > +#define ADUX1020_REG_INT_MASK 0x48 > +#define ADUX1020_REG_INT_STATUS 0x49 > +#define ADUX1020_REG_DATA_BUFFER0x60 > + > +/* Chip ID bits */ > +#define ADUX1020_CHIP_ID_MASKGENMASK(11, 0) > +#define ADUX1020_CHIP_ID 0x03fc > + > +#define ADUX1020_MODE_OUT_SHIFT 4 I'm seeing a few _SHIFT macros. Maybe use the FIELD_PREP() macro where possible? [1] > +#define ADUX1020_MODE_OUT_PROX_I 1 > +#define ADUX1020_MODE_OUT_PROX_XY3 > + > +#define ADUX1020_SW_RESETBIT(1) > +#define ADUX1020_FIFO_FLUSH BIT(15) > +#define ADUX1020_OP_MODE_MASKGENMASK(3, 0) > +#define ADUX1020_DATA_OUT_MODE_MASK GENMASK(7,
Re: [PATCH 1/2] dt-bindings: iio: light: Add binding for ADUX1020
On Mon, 2019-10-07 at 18:10 +0530, Manivannan Sadhasivam wrote:
> [External]
>
> Hi Ardelean,
>
> On 7 October 2019 3:51:16 PM IST, "Ardelean, Alexandru" <
> alexandru.ardel...@analog.com> wrote:
> > On Mon, 2019-10-07 at 15:40 +0530, Manivannan Sadhasivam wrote:
> > > [External]
> > >
> > > Add devicetree binding for Analog Devices ADUX1020 Photometric
> > > sensor.
> > >
> >
> > Hey,
> >
> > Thanks for the patches.
> >
> > This dt-binding docs is in text format.
> > dt-binding docs now need to be in YAML format.
> >
>
> Sure. I can convert to YAML binding.
>
> > Also, patches for dt-bindings docs usually come after the driver is
> > added.
> > So, this patch should be the second in the series, not the first.
> >
>
> I don't think so. The convention is to put dt-bindings patch upfront for
> all subsystems. Not sure if IIO differs here.
Now that you mention, I'm not sure either.
We typically sent the dt-bindings one last, so I assumed it was the
default.
>
> Thanks,
> Mani
> > Alex
> >
> > > Signed-off-by: Manivannan Sadhasivam
> >
> > > ---
> > > .../bindings/iio/light/adux1020.txt | 22
> > +++
> > > 1 file changed, 22 insertions(+)
> > > create mode 100644
> > > Documentation/devicetree/bindings/iio/light/adux1020.txt
> > >
> > > diff --git a/Documentation/devicetree/bindings/iio/light/adux1020.txt
> > > b/Documentation/devicetree/bindings/iio/light/adux1020.txt
> > > new file mode 100644
> > > index ..e896dda30e36
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/iio/light/adux1020.txt
> > > @@ -0,0 +1,22 @@
> > > +Analog Devices ADUX1020 Photometric sensor
> > > +
> > > +Link to datasheet:
> > >
> > https://www.analog.com/media/en/technical-documentation/data-sheets/ADUX1020.pdf
> > > +
> > > +Required properties:
> > > +
> > > + - compatible: should be "adi,adux1020"
> > > + - reg: the I2C address of the sensor
> > > +
> > > +Optional properties:
> > > +
> > > + - interrupts: interrupt mapping for IRQ as documented in
> > > +
> > Documentation/devicetree/bindings/interrupt-controller/interrupts.txt
> > > +
> > > +Example:
> > > +
> > > +adux1020@64 {
> > > + compatible = "adi,adux1020";
> > > + reg = <0x64>;
> > > + interrupt-parent = <>;
> > > + interrupts = <24 IRQ_TYPE_LEVEL_HIGH>;
> > > +};
Re: [PATCH 1/2] dt-bindings: iio: light: Add binding for ADUX1020
On Mon, 2019-10-07 at 15:40 +0530, Manivannan Sadhasivam wrote:
> [External]
>
> Add devicetree binding for Analog Devices ADUX1020 Photometric
> sensor.
>
Hey,
Thanks for the patches.
This dt-binding docs is in text format.
dt-binding docs now need to be in YAML format.
Also, patches for dt-bindings docs usually come after the driver is added.
So, this patch should be the second in the series, not the first.
Alex
> Signed-off-by: Manivannan Sadhasivam
> ---
> .../bindings/iio/light/adux1020.txt | 22 +++
> 1 file changed, 22 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/iio/light/adux1020.txt
>
> diff --git a/Documentation/devicetree/bindings/iio/light/adux1020.txt
> b/Documentation/devicetree/bindings/iio/light/adux1020.txt
> new file mode 100644
> index ..e896dda30e36
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iio/light/adux1020.txt
> @@ -0,0 +1,22 @@
> +Analog Devices ADUX1020 Photometric sensor
> +
> +Link to datasheet:
> https://www.analog.com/media/en/technical-documentation/data-sheets/ADUX1020.pdf
> +
> +Required properties:
> +
> + - compatible: should be "adi,adux1020"
> + - reg: the I2C address of the sensor
> +
> +Optional properties:
> +
> + - interrupts: interrupt mapping for IRQ as documented in
> + Documentation/devicetree/bindings/interrupt-controller/interrupts.txt
> +
> +Example:
> +
> +adux1020@64 {
> + compatible = "adi,adux1020";
> + reg = <0x64>;
> + interrupt-parent = <>;
> + interrupts = <24 IRQ_TYPE_LEVEL_HIGH>;
> +};
Re: [PATCH 01/10] iio: imu: adis: rename txrx_lock -> state_lock
On Sun, 2019-10-06 at 10:06 +0100, Jonathan Cameron wrote:
> [External]
>
> On Sun, 6 Oct 2019 09:53:33 +0100
> Jonathan Cameron wrote:
>
> > On Thu, 26 Sep 2019 14:18:03 +0300
> > Alexandru Ardelean wrote:
> >
> > > The lock can be extended a bit to protect other elements that are not
> > > particular to just TX/RX. Another idea would have been to just add a
> > > new
> > > `state_lock`, but that would mean 2 locks which would be redundant,
> > > and
> > > probably cause more potential for dead-locks.
> > >
> > > What will be done in the next patches, will be to add some unlocked
> > > versions for read/write_reg functions.
> > >
> > > Signed-off-by: Alexandru Ardelean
> >
> > Would be good to document the scope of the lock as a comment when it
> > is defined. What exactly is 'state' in this case?
> As this can be done as a follow up and the rest of the series is fine
> as is...
>
Will do.
> Applied to the togreg branch of iio.git and pushed out as testing for
> the autobuilders to play with it.
>
> Thanks,
>
> Jonathan
>
> > Thanks,
> >
> > Jonathan
> >
> > > ---
> > > drivers/iio/imu/adis.c| 10 +-
> > > drivers/iio/imu/adis_buffer.c | 4 ++--
> > > include/linux/iio/imu/adis.h | 2 +-
> > > 3 files changed, 8 insertions(+), 8 deletions(-)
> > >
> > > diff --git a/drivers/iio/imu/adis.c b/drivers/iio/imu/adis.c
> > > index 1631c255deab..3c2d896e3a96 100644
> > > --- a/drivers/iio/imu/adis.c
> > > +++ b/drivers/iio/imu/adis.c
> > > @@ -70,7 +70,7 @@ int adis_write_reg(struct adis *adis, unsigned int
> > > reg,
> > > },
> > > };
> > >
> > > - mutex_lock(>txrx_lock);
> > > + mutex_lock(>state_lock);
> > >
> > > spi_message_init();
> > >
> > > @@ -114,7 +114,7 @@ int adis_write_reg(struct adis *adis, unsigned
> > > int reg,
> > > }
> > >
> > > out_unlock:
> > > - mutex_unlock(>txrx_lock);
> > > + mutex_unlock(>state_lock);
> > >
> > > return ret;
> > > }
> > > @@ -166,7 +166,7 @@ int adis_read_reg(struct adis *adis, unsigned int
> > > reg,
> > > },
> > > };
> > >
> > > - mutex_lock(>txrx_lock);
> > > + mutex_lock(>state_lock);
> > > spi_message_init();
> > >
> > > if (adis->current_page != page) {
> > > @@ -211,7 +211,7 @@ int adis_read_reg(struct adis *adis, unsigned int
> > > reg,
> > > }
> > >
> > > out_unlock:
> > > - mutex_unlock(>txrx_lock);
> > > + mutex_unlock(>state_lock);
> > >
> > > return ret;
> > > }
> > > @@ -437,7 +437,7 @@ EXPORT_SYMBOL_GPL(adis_single_conversion);
> > > int adis_init(struct adis *adis, struct iio_dev *indio_dev,
> > > struct spi_device *spi, const struct adis_data *data)
> > > {
> > > - mutex_init(>txrx_lock);
> > > + mutex_init(>state_lock);
> > > adis->spi = spi;
> > > adis->data = data;
> > > iio_device_set_drvdata(indio_dev, adis);
> > > diff --git a/drivers/iio/imu/adis_buffer.c
> > > b/drivers/iio/imu/adis_buffer.c
> > > index 9ac8356d9a95..bf581a2c321d 100644
> > > --- a/drivers/iio/imu/adis_buffer.c
> > > +++ b/drivers/iio/imu/adis_buffer.c
> > > @@ -123,7 +123,7 @@ static irqreturn_t adis_trigger_handler(int irq,
> > > void *p)
> > > return -ENOMEM;
> > >
> > > if (adis->data->has_paging) {
> > > - mutex_lock(>txrx_lock);
> > > + mutex_lock(>state_lock);
> > > if (adis->current_page != 0) {
> > > adis->tx[0] = ADIS_WRITE_REG(ADIS_REG_PAGE_ID);
> > > adis->tx[1] = 0;
> > > @@ -138,7 +138,7 @@ static irqreturn_t adis_trigger_handler(int irq,
> > > void *p)
> > >
> > > if (adis->data->has_paging) {
> > > adis->current_page = 0;
> > > - mutex_unlock(>txrx_lock);
> > > + mutex_unlock(>state_lock);
> > > }
> > >
> > > iio_push_to_buffers_with_timestamp(indio_dev, adis->buffer,
> > > diff --git a/include/linux/iio/imu/adis.h
> > > b/include/linux/iio/imu/adis.h
> > > index 4c53815bb729..3ed5eceaac2d 100644
> > > --- a/include/linux/iio/imu/adis.h
> > > +++ b/include/linux/iio/imu/adis.h
> > > @@ -61,7 +61,7 @@ struct adis {
> > > const struct adis_data *data;
> > > struct adis_burst *burst;
> > >
> > > - struct mutextxrx_lock;
> > > + struct mutexstate_lock;
> > > struct spi_message msg;
> > > struct spi_transfer *xfer;
> > > unsigned intcurrent_page;
Re: [PATCH] iio: imu: adis16480: clean up a condition
On Thu, 2019-09-26 at 11:10 +0300, Dan Carpenter wrote: > [External] > > The "t" variable is unsigned so it can't be less than zero. We really > are just trying to prevent divide by zero bugs so just checking against > zero is sufficient. > > Signed-off-by: Dan Carpenter > --- > drivers/iio/imu/adis16480.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/iio/imu/adis16480.c b/drivers/iio/imu/adis16480.c > index b99d73887c9f..e144e567675d 100644 > --- a/drivers/iio/imu/adis16480.c > +++ b/drivers/iio/imu/adis16480.c > @@ -318,7 +318,7 @@ static int adis16480_set_freq(struct iio_dev > *indio_dev, int val, int val2) > unsigned int t, reg; I would just change the type of "t" to "int". Especially, since "val" & "val2" are "int". Thanks for the catch :) Alex > > t = val * 1000 + val2 / 1000; > - if (t <= 0) > + if (t == 0) > return -EINVAL; > > /*
Re: [EXT] [PATCH v3] serial: imx: adapt rx buffer and dma periods
On Wed, 2019-09-25 at 10:14 -0500, Adam Ford wrote:
> [External]
>
> On Fri, Sep 20, 2019 at 2:06 AM Philipp Puschmann
> wrote:
> > Hi Andy,
> >
> > Am 20.09.19 um 05:42 schrieb Andy Duan:
> > > From: Philipp Puschmann Sent: Thursday,
> > > September 19, 2019 10:51 PM
> > > > Using only 4 DMA periods for UART RX is very few if we have a high
> > > > frequency
> > > > of small transfers - like in our case using Bluetooth with many
> > > > small packets
> > > > via UART - causing many dma transfers but in each only filling a
> > > > fraction of a
> > > > single buffer. Such a case may lead to the situation that DMA RX
> > > > transfer is
> > > > triggered but no free buffer is available. When this happens dma
> > > > channel ist
> > > > stopped - with the patch
> > > > "dmaengine: imx-sdma: fix dma freezes" temporarily only - with the
> > > > possible
> > > > consequences that:
>
> I have an i.MX6Q with Wl1837MOD on UART 2 with flow control, and I am
> getting Bluetooth transfer timeouts.
> (see imx6-logicpd-som.dtsi)
>
> On top of 5.3.1, I have installed:
>
> dmaengine: imx-sdma: fix buffer ownership
> dmaengine: imx-sdma: fix dma freezes
> dmaengine: imx-sdma: drop redundant variable
> dmaengine: imx-sdma: fix kernel hangs with SLUB slab allocator
> serial: imx: adapt rx buffer and dma periods
>
> and I still get timeouts:
>
> [ 66.632006] Bluetooth: hci0: command 0xff36 tx timeout
> [ 76.790499] Bluetooth: hci0: command 0x1001 tx timeout
> [ 87.110488] Bluetooth: hci0: command 0xff36 tx timeout
> [ 97.270507] Bluetooth: hci0: command 0x1001 tx timeout
> [ 107.590457] Bluetooth: hci0: command 0xff36 tx timeout
> [ 117.750477] Bluetooth: hci0: command 0x1001 tx timeout
> [ 226.390499] Bluetooth: hci0: command 0xfe38 tx timeout
> [ 231.590735] Bluetooth: hci0: command tx timeout
>
> I did a bisect and found the start of my problems came from
>
> 361deb7243d2 ("dmaengine: dmatest: wrap src & dst data into a struct")
That commit only touches `drivers/dma/dmatest.c`
Are you using that module?
It's a "unit-test" module for testing DMAengine drivers.
The only way that can break anything [from what I can tell], is if it is
being run. It will probably put the DMA into a weird state (it is a test-
module after-all), and it may require some DMAs to be reset.
I admit it would be nice that the test-module would put the DMA back into a
normal-working state, but that effort could be big for some cases.
>
> This happened sometime between v5.0 and v5.1
>
> Is there a patch I missed somewhere? Do I need to change my device
> tree configuration somehow to allocate the proper DMA memory?
>
>
>
> > > > with disabled hw flow control:
> > > > If enough data is incoming on UART port the RX FIFO runs over and
> > > > characters will be lost. What then happens depends on upper
> > > > layer.
> > > >
> > > > with enabled hw flow control:
> > > > If enough data is incoming on UART port the RX FIFO reaches a
> > > > level
> > > > where CTS is deasserted and remote device sending the data stops.
> > > > If it fails to stop timely the i.MX' RX FIFO may run over and
> > > > data
> > > > get lost. Otherwise it's internal TX buffer may getting filled to
> > > > a point where it runs over and data is again lost. It depends on
> > > > the remote device how this case is handled and if it is
> > > > recoverable.
> > > >
> > > > Obviously we want to avoid having no free buffers available. So we
> > > > decrease
> > > > the size of the buffers and increase their number and the total
> > > > buffer size.
> > > >
> > > > Signed-off-by: Philipp Puschmann
> > > > Reviewed-by: Lucas Stach
> > > > ---
> > > >
> > > > Changelog v3:
> > > > - enhance description
> > > >
> > > > Changelog v2:
> > > > - split this patch from series "Fix UART DMA freezes for iMX6"
> > > > - add Reviewed-by tag
> > > >
> > > > drivers/tty/serial/imx.c | 5 ++---
> > > > 1 file changed, 2 insertions(+), 3 deletions(-)
> > > >
> > > > diff --git a/drivers/tty/serial/imx.c b/drivers/tty/serial/imx.c
> > > > index
> > > > 87c58f9f6390..51dc19833eab 100644
> > > > --- a/drivers/tty/serial/imx.c
> > > > +++ b/drivers/tty/serial/imx.c
> > > > @@ -1034,8 +1034,6 @@ static void imx_uart_timeout(struct
> > > > timer_list *t)
> > > > }
> > > > }
> > > >
> > > > -#define RX_BUF_SIZE(PAGE_SIZE)
> > > > -
> > > > /*
> > > > * There are two kinds of RX DMA interrupts(such as in the MX6Q):
> > > > * [1] the RX DMA buffer is full.
> > > > @@ -1118,7 +1116,8 @@ static void imx_uart_dma_rx_callback(void
> > > > *data) }
> > > >
> > > > /* RX DMA buffer periods */
> > > > -#define RX_DMA_PERIODS 4
> > > > +#define RX_DMA_PERIODS 16
> > > > +#define RX_BUF_SIZE(PAGE_SIZE / 4)
> > > >
> > > Why to decrease the DMA RX buffer size here ?
> > >
> > > The current DMA implementation support DMA cyclic mode, one SDMA BD
> > > receive one Bluetooth frame can
> > > bring better performance.
> > > As you know,
Re: [PATCH v2] iio: imu: adis16400: fix memory leak
On Thu, 2019-09-19 at 10:56 -0500, Navid Emamdoost wrote:
> In adis_update_scan_mode_burst, if adis->buffer allocation fails release
> the adis->xfer.
>
> v2: set adis->xfer = NULL to avoid any potential double free.
>
Reviewed-by: Alexandru Ardelean
> Signed-off-by: Navid Emamdoost
> ---
> drivers/iio/imu/adis_buffer.c | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/iio/imu/adis_buffer.c
> b/drivers/iio/imu/adis_buffer.c
> index 9ac8356d9a95..78fe83c1f4fe 100644
> --- a/drivers/iio/imu/adis_buffer.c
> +++ b/drivers/iio/imu/adis_buffer.c
> @@ -35,8 +35,11 @@ static int adis_update_scan_mode_burst(struct iio_dev
> *indio_dev,
> return -ENOMEM;
>
> adis->buffer = kzalloc(burst_length + sizeof(u16), GFP_KERNEL);
> - if (!adis->buffer)
> + if (!adis->buffer) {
> + kfree(adis->xfer);
> + adis->xfer = NULL;
> return -ENOMEM;
> + }
>
> tx = adis->buffer + burst_length;
> tx[0] = ADIS_READ_REG(adis->burst->reg_cmd);
Re: [PATCH v2] iio: imu: adis16400: release allocated memory on failure
On Thu, 2019-09-19 at 10:50 -0500, Navid Emamdoost wrote:
> In adis_update_scan_mode, if allocation for adis->buffer fails,
> previously allocated adis->xfer needs to be released.
>
> v2: added adis->xfer = NULL to avoid any potential double free.
Reviewed-by: Alexandru Ardelean
> Signed-off-by: Navid Emamdoost
> ---
> drivers/iio/imu/adis_buffer.c | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/iio/imu/adis_buffer.c
> b/drivers/iio/imu/adis_buffer.c
> index 9ac8356d9a95..f446ff497809 100644
> --- a/drivers/iio/imu/adis_buffer.c
> +++ b/drivers/iio/imu/adis_buffer.c
> @@ -78,8 +78,11 @@ int adis_update_scan_mode(struct iio_dev *indio_dev,
> return -ENOMEM;
>
> adis->buffer = kcalloc(indio_dev->scan_bytes, 2, GFP_KERNEL);
> - if (!adis->buffer)
> + if (!adis->buffer) {
> + kfree(adis->xfer);
> + adis->xfer = NULL;
> return -ENOMEM;
> + }
>
> rx = adis->buffer;
> tx = rx + scan_count;
Re: [PATCH] iio: imu: adis16400: fix memory leak
On Wed, 2019-09-18 at 12:03 -0500, Navid Emamdoost wrote:
> [External]
>
Hey,
Thanks for this patch as well.
Comments inline here as well.
> In adis_update_scan_mode_burst, if adis->buffer allocation fails release
> the adis->xfer.
>
> Signed-off-by: Navid Emamdoost
> ---
> drivers/iio/imu/adis_buffer.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/iio/imu/adis_buffer.c
> b/drivers/iio/imu/adis_buffer.c
> index 9ac8356d9a95..1dbe25572a39 100644
> --- a/drivers/iio/imu/adis_buffer.c
> +++ b/drivers/iio/imu/adis_buffer.c
> @@ -35,8 +35,10 @@ static int adis_update_scan_mode_burst(struct iio_dev
> *indio_dev,
> return -ENOMEM;
>
> adis->buffer = kzalloc(burst_length + sizeof(u16), GFP_KERNEL);
> - if (!adis->buffer)
> + if (!adis->buffer) {
> + kfree(adis->xfer);
Same as the other patch: it would be a good idea to do "adis->xfer = NULL"
here.
> return -ENOMEM;
> + }
>
> tx = adis->buffer + burst_length;
> tx[0] = ADIS_READ_REG(adis->burst->reg_cmd);
Re: [PATCH] iio: imu: adis16400: release allocated memory on failure
On Wed, 2019-09-18 at 11:57 -0500, Navid Emamdoost wrote:
> [External]
>
Hey,
Good catch.
One comment inline.
> In adis_update_scan_mode, if allocation for adis->buffer fails,
> previously allocated adis->xfer needs to be released.
>
> Signed-off-by: Navid Emamdoost
> ---
> drivers/iio/imu/adis_buffer.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/iio/imu/adis_buffer.c
> b/drivers/iio/imu/adis_buffer.c
> index 9ac8356d9a95..c5d7e368a636 100644
> --- a/drivers/iio/imu/adis_buffer.c
> +++ b/drivers/iio/imu/adis_buffer.c
> @@ -78,8 +78,10 @@ int adis_update_scan_mode(struct iio_dev *indio_dev,
> return -ENOMEM;
>
> adis->buffer = kcalloc(indio_dev->scan_bytes, 2, GFP_KERNEL);
> - if (!adis->buffer)
> + if (!adis->buffer) {
> + kfree(adis->xfer);
Maybe also do "adis->xfer = NULL" here.
The idea is to make sure that the pointer is not double-free'd by some
other function (i.e. adis_cleanup_buffer_and_trigger() or another
adis_update_scan_mode() call).
> return -ENOMEM;
> + }
>
> rx = adis->buffer;
> tx = rx + scan_count;
Re: [PATCH] dt-bindings: net: dwmac: fix 'mac-mode' type
On Tue, 2019-09-17 at 14:41 +0200, Andrew Lunn wrote:
> [External]
>
> On Tue, Sep 17, 2019 at 01:30:52PM +0300, Alexandru Ardelean wrote:
> > The 'mac-mode' property is similar to 'phy-mode' and 'phy-connection-type',
> > which are enums of mode strings.
> >
> > The 'dwmac' driver supports almost all modes declared in the 'phy-mode'
> > enum (except for 1 or 2). But in general, there may be a case where
> > 'mac-mode' becomes more generic and is moved as part of phylib or netdev.
> >
> > In any case, the 'mac-mode' field should be made an enum, and it also makes
> > sense to just reference the 'phy-connection-type' from
> > 'ethernet-controller.yaml'. That will also make it more future-proof for new
> > modes.
> >
> > Signed-off-by: Alexandru Ardelean
>
> Hi Alexandru
>
> Adding a Fixes: tag would be good. Just reply in this thread, and
> patchwork will do magic to append it to the patch.
>
Oops. Good point.
Thanks for the tip.
Let's see if Rob agrees as well.
Fixes: 9c15d3597c62 ("dt-bindings: net: dwmac: document 'mac-mode' property")
> Reviewed-by: Andrew Lunn
>
> Andrew
Re: [PATCH 2/2] dt-bindings: net: dwmac: document 'mac-mode' property
On Mon, 2019-09-16 at 12:49 +0300, Alexandru Ardelean wrote:
> On Fri, 2019-09-13 at 15:36 +0100, Rob Herring wrote:
> > [External]
> >
> > On Fri, Sep 06, 2019 at 04:02:56PM +0300, Alexandru Ardelean wrote:
> > > This change documents the 'mac-mode' property that was introduced in
> > > the
> > > 'stmmac' driver to support passive mode converters that can sit in-
> > > between
> > > the MAC & PHY.
> > >
> > > Signed-off-by: Alexandru Ardelean
> > > ---
> > > Documentation/devicetree/bindings/net/snps,dwmac.yaml | 8
> > > 1 file changed, 8 insertions(+)
> > >
> > > diff --git a/Documentation/devicetree/bindings/net/snps,dwmac.yaml
> > > b/Documentation/devicetree/bindings/net/snps,dwmac.yaml
> > > index c78be15704b9..ebe4537a7cce 100644
> > > --- a/Documentation/devicetree/bindings/net/snps,dwmac.yaml
> > > +++ b/Documentation/devicetree/bindings/net/snps,dwmac.yaml
> > > @@ -112,6 +112,14 @@ properties:
> > >reset-names:
> > > const: stmmaceth
> > >
> > > + mac-mode:
> > > +maxItems: 1
> >
> > Is this an array because {min,max}Items is for arrays? It should be
> > defined as a string with possible values.
> >
> > As this property is the same as another, you can do this:
> >
> > $ref: ethernet-controller.yaml#/properties/phy-connection-type
> >
> > Unless only a small subset of those values are valid here, then you
> > may
> > want to list them here.
> >
>
> Ack.
> Thank you.
>
> Will investigate and re-spin.
Looking at '$ref: ethernet-controller.yaml#/properties/phy-connection-type'
it looks like 'mac-mode' could cover almost all 'phy-connection-type'
except for a few (1 or 2). The 'dwmac' driver is pretty complex/big.
There was a note that Andrew made on a previous change, that we could have
a 'mac-mode' (similar to 'phy-mode') and that could become generic (either
in phylib or maybe somewhere else in netdev).
In any case, the conclusion [from my side] would be that
'$ref: ethernet-controller.yaml#/properties/phy-connection-type'
could work, and be sufficiently future-proof.
Thanks
Alex
>
>
> > > +description:
> > > + The property is identical to 'phy-mode', and assumes that
> > > there is mode
> > > + converter in-between the MAC & PHY (e.g. GMII-to-RGMII). This
> > > converter
> > > + can be passive (no SW requirement), and requires that the MAC
> > > operate
> > > + in a different mode than the PHY in order to function.
> > > +
> > >snps,axi-config:
> > > $ref: /schemas/types.yaml#definitions/phandle
> > > description:
> > > --
> > > 2.20.1
> > >
Re: [RFC PATCH 03/15] spi: make `cs_change_delay` the first user of the `spi_delay` logic
On Mon, 2019-09-16 at 14:43 +0100, Mark Brown wrote: > [External] > > On Mon, Sep 16, 2019 at 01:04:42PM +, Ardelean, Alexandru wrote: > > On Mon, 2019-09-16 at 13:47 +0100, Mark Brown wrote: > > > That v3 seems to be a small subset of this series? > > Ack. > > V3 is the first 4 patches from this series. > > Well, patches 3 & 4 are squashed. > > I am 100% convinced that the entire series is a good idea. Something happened here to the "not" word. Probably got lost in an alternate dimension ¯\_(ツ)_/¯ . Was supposed to be: "I am not 100% convinced that the entire series is a good idea." > > In the sense that a `struct spi_delay` may be a good idea, but at the > > same time, it may be un-needed. > > All I wanted to do, was to add another delay somewhere, and got lost in > > the rework of current delays. > > I thought about proposing just the first 4 patches [on their own], but > > I thought that showing the current series as-is > > now, may be a good idea as well [to gather some feedback]. > > I think it makes more sense to review as a whole series rather than only > a part of the conversion, it doesn't really help to only do part of it. > > Please fix your mail client to word wrap within paragraphs at something > substantially less than 80 columns. Doing this makes your messages much > easier to read and reply to. Ack. Problem is: I have to re-setup my email client every now-n-then since the work-email server has some issues with Linux email clients. And I sometimes forget to configure this. [ Exchange does not always get along well with non-Outlook clients ]
