Devicetree
 help / color / mirror / Atom feed
From: Andy Shevchenko <andriy.shevchenko@intel.com>
To: Rodrigo Alencar <455.rodrigo.alencar@gmail.com>
Cc: Michael Auchter <michael.auchter@ni.com>,
	linux@analog.com, linux-iio@vger.kernel.org,
	devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-hardening@vger.kernel.org,
	Michael Hennerich <Michael.Hennerich@analog.com>,
	Jonathan Cameron <jic23@kernel.org>,
	David Lechner <dlechner@baylibre.com>,
	Andy Shevchenko <andy@kernel.org>, Rob Herring <robh@kernel.org>,
	Krzysztof Kozlowski <krzk+dt@kernel.org>,
	Conor Dooley <conor+dt@kernel.org>,
	Philipp Zabel <p.zabel@pengutronix.de>,
	Kees Cook <kees@kernel.org>,
	"Gustavo A. R. Silva" <gustavoars@kernel.org>
Subject: Re: [PATCH v7 4/7] iio: dac: ad5686: implement new sync() op for the spi bus
Date: Mon, 13 Jul 2026 19:44:40 +0300	[thread overview]
Message-ID: <alUV-Ht2BYkhbNsO@ashevche-desk.local> (raw)
In-Reply-To: <2shq75gvzzm27rodbgmtxkbgt5n2a7dafjc2mmkttwnshmhyqr@pdytastitwfm>

On Mon, Jul 13, 2026 at 05:18:14PM +0100, Rodrigo Alencar wrote:
> On 12/07/26 10:03, Andy Shevchenko wrote:
> > On Fri, Jul 10, 2026 at 12:20:48PM +0100, Rodrigo Alencar via B4 Relay wrote:

...

> > >  int ad5686_probe(struct device *dev,
> > >  		 const struct ad5686_chip_info *chip_info,
> > > -		 const char *name, const struct ad5686_bus_ops *ops)
> > > +		 const char *name, const struct ad5686_bus_ops *ops,
> > > +		 void *bus_data)
> > 
> > Can't you utilise the dev->platform_data for this? I believe it's exactly
> > the case where it suits.
> 
> I could use dev_set_drvdata(), I understand that platform_data is to be injected
> by the board/platform configuration.
> 
> SPI/I2C cores do write it, from the board-info structs at device creation:
>     - drivers/spi/spi.c:835
> 	proxy->dev.platform_data = (void *) chip->platform_data; (from spi_board_info::platform_data)
>     - drivers/i2c/i2c-core-base.c:973
> 	client->dev.platform_data = info->platform_data; (from i2c_board_info::platform_data)
> 
> After device creation, the core itself doesn't touch it.

Looking at this again, there is kinda static data (the one that you know at
the probe stage) and dynamic (like memory for transfers), so static one indeed
can be part of driver_data, but the dynamic ones rather fit ad5686_state.

-- 
With Best Regards,
Andy Shevchenko



  reply	other threads:[~2026-07-13 16:44 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-10 11:20 [PATCH v7 0/7] New features for the AD5686 IIO driver Rodrigo Alencar via B4 Relay
2026-07-10 11:20 ` [PATCH v7 1/7] iio: dac: ad5696: properly check i2c_transfer() return value Rodrigo Alencar via B4 Relay
2026-07-10 11:31   ` sashiko-bot
2026-07-12  1:58   ` Jonathan Cameron
2026-07-12  6:58   ` Andy Shevchenko
2026-07-10 11:20 ` [PATCH v7 2/7] iio: dac: ad5686: refactor command/data macros Rodrigo Alencar via B4 Relay
2026-07-10 11:36   ` sashiko-bot
2026-07-12  7:05   ` Andy Shevchenko
2026-07-10 11:20 ` [PATCH v7 3/7] iio: dac: ad5686: introduce sync operation Rodrigo Alencar via B4 Relay
2026-07-10 11:20 ` [PATCH v7 4/7] iio: dac: ad5686: implement new sync() op for the spi bus Rodrigo Alencar via B4 Relay
2026-07-11 15:07   ` David Lechner
2026-07-13 16:44     ` Rodrigo Alencar
2026-07-13 16:46       ` Andy Shevchenko
2026-07-12  7:03   ` Andy Shevchenko
2026-07-13 16:18     ` Rodrigo Alencar
2026-07-13 16:44       ` Andy Shevchenko [this message]
2026-07-10 11:20 ` [PATCH v7 5/7] iio: dac: ad5686: read_raw/write_raw: use guard(mutex)() Rodrigo Alencar via B4 Relay
2026-07-11 15:09   ` David Lechner
2026-07-12  7:12     ` Andy Shevchenko
2026-07-10 11:20 ` [PATCH v7 6/7] iio: dac: ad5686: add triggered buffer support Rodrigo Alencar via B4 Relay
2026-07-11 15:15   ` David Lechner
2026-07-10 11:20 ` [PATCH v7 7/7] iio: dac: ad5686: add gain control support Rodrigo Alencar via B4 Relay
2026-07-11 15:22   ` David Lechner
2026-07-11 15:23 ` [PATCH v7 0/7] New features for the AD5686 IIO driver David Lechner
2026-07-12  2:05   ` Jonathan Cameron

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=alUV-Ht2BYkhbNsO@ashevche-desk.local \
    --to=andriy.shevchenko@intel.com \
    --cc=455.rodrigo.alencar@gmail.com \
    --cc=Michael.Hennerich@analog.com \
    --cc=andy@kernel.org \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=dlechner@baylibre.com \
    --cc=gustavoars@kernel.org \
    --cc=jic23@kernel.org \
    --cc=kees@kernel.org \
    --cc=krzk+dt@kernel.org \
    --cc=linux-hardening@vger.kernel.org \
    --cc=linux-iio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@analog.com \
    --cc=michael.auchter@ni.com \
    --cc=p.zabel@pengutronix.de \
    --cc=robh@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox