Re: [PATCH RFC 6/8] iio: frequency: ad9910: add RAM mode support

["Nuno Sá" <noname.nuno@gmail.com>]

On Wed, 2026-03-11 at 13:11 +0000, Rodrigo Alencar wrote:
> On 26/03/10 07:11PM, David Lechner wrote:
> > On 3/10/26 12:40 PM, Rodrigo Alencar wrote:
> > > On 26/03/07 02:07PM, Jonathan Cameron wrote:
> > > > On Sun, 1 Mar 2026 13:31:53 +0000
> > > > Jonathan Cameron <jic23@kernel.org> wrote:
> > > > 
> > > > > On Fri, 20 Feb 2026 16:46:10 +0000
> > > > > Rodrigo Alencar via B4 Relay <devnull+rodrigo.alencar.analog.com@kernel.org> wrote:
> > > > > 
> > > > > > From: Rodrigo Alencar <rodrigo.alencar@analog.com>
> > > > > > 
> > > > > > Add RAM channel with support for profile-based control. This includes:
> > > > > > - RAM data loading via binary sysfs attribute (ram_data);  
> > > > > 
> > > > > I'm not sure that's a long term viable path.  We either need
> > > > > to figure out how to do it as firmware file load, or via an output buffer.
> > > > > 
> > > > > Firmware load would probably be too static and I'm not sure quite
> > > > > how we map these to IIO output buffers.
> > > > 
> > > > We would have to carry it for ever which is very much not ideal.
> > > > The firmware approach has the same issue, but can be thought of
> > > > as defaults at boot time forever.  If no defaults then we use whatever
> > > > we come up with as the long term solution.
> > > 
> > > I was thinking about the firmware approach:
> > > - Normally a driver would request the firmware during probe and the
> > >   filename would be pre-defined.
> > > - Less statically, It could have an attribute that once written, it would
> > >   request the RAM contents (e.g. under /lib/firmware/ad9910_ram.bin).
> > >   It could be the enable attribute itself (but that would not be effective
> > >   when the binary would not change), or a separate one (e.g. destination),
> > >   or a new one (e.g. load_en)
> > 
> > Have you looked at firmware_upload_register()? It looks like it provides
> > something along these lines.
> 
> Thanks! this is in fact perfect!
> It might be ugly, but for the sake of debugging I managed to get libiio to
> interface with this by exposing it in the debugfs.
> 
> 	debugfs_create_symlink("ram_loading",
> 			       iio_get_debugfs_dentry(indio_dev),
> 			       "/sys/class/firmware/ad9910-ram/loading");
> 	debugfs_create_symlink("ram_data",
> 			       iio_get_debugfs_dentry(indio_dev),
> 			       "/sys/class/firmware/ad9910-ram/data");

Or for the sake of future proving, maybe let's make the sysfs a bit more generic. At least the path,

/sys/class/firmware/dev_name(iio_dev)/*

I guess userspace tools could work with the above to match the fw blob with the right device. Also,
hardcoding the name as it seems you have done will be a problem if we have multiple devices, no?

Not sure about the above though :)

- Nuno Sá