GSoC IIO project: Siddharth Menon

GSoC IIO project: Siddharth Menon

[Siddharth Menon]

subject: Permission to work on dt bindings for staging drivers

I am interested in applying for GSoC under the IIO driver project.

I have a couple of patches that have been merged into the kernel,
and am now exploring DT bindings.

Currently, I am working on Coding Task 1 (sending cleanup patches).
While running checkpatch.pl, I noticed warnings about undocumented
DT-compatible strings.
Would creating the appropriate binding count as a cleanup patch or were
they left undocumented intentionally because they are staging drivers?

Regards,
Siddharth Menon

Re: GSoC IIO project: Siddharth Menon

[Jonathan Cameron]

On Fri, 21 Feb 2025 21:23:35 +0530
Siddharth Menon <simeddon@gmail.com> wrote:

> subject: Permission to work on dt bindings for staging drivers
> 
> I am interested in applying for GSoC under the IIO driver project.
> 
> I have a couple of patches that have been merged into the kernel,
> and am now exploring DT bindings.
> 
> Currently, I am working on Coding Task 1 (sending cleanup patches).
> While running checkpatch.pl, I noticed warnings about undocumented
> DT-compatible strings.
> Would creating the appropriate binding count as a cleanup patch or were
> they left undocumented intentionally because they are staging drivers?

There has been a long term reluctance to pin down DT bindings for
drivers that are known to not be in a suitable state for long term
maintenance etc.  So I'd skip adding bindings for these. Also
they tend to be far from what I'd call cleanup patches!

Some of those staging/iio drivers will probably get dropped at somepoint
so before doing any more major work on them, please send an email to
check they are still of interest!

Your email motivated me to take a quick look.
The accel/adis16240 is now marked obsolete at 
https://www.analog.com/en/products/adis16240.html
I'll send out a patch shortly to suggest we drop that one as unlikely
anyone will expend work on a part that is getting hard to get.

The other drivers all cover at least 1 supported part.

Jonathan

> 
> Regards,
> Siddharth Menon
> 

Re: GSoC IIO project: Siddharth Menon

[Siddharth Menon]

subject: Criteria for cleanup patch

Hello again,
I was going through some of the staging drivers. There are quite a few
checkpatch warnings under rtl8723bs, but they are mostly styling changes.
Would sending in patches for these be appropriate?

I had considered dt bindings earlier as they seemed like a more relevant
contribution.

Regards,
Siddharth Menon

Re: GSoC IIO project: Siddharth Menon

[Marcelo Schmitt]

Hello Siddharth,

On 02/28, Siddharth Menon wrote:
> subject: Criteria for cleanup patch
> 
> Hello again,
> I was going through some of the staging drivers. There are quite a few
> checkpatch warnings under rtl8723bs, but they are mostly styling changes.
> Would sending in patches for these be appropriate?

Maybe. Though, I think rtl8723bs wouldn't belong to IIO (maybe
drivers/net/wireless) so I would ask that question at the wireless mailing list,
linux-wireless@vger.kernel.org.

> 
> I had considered dt bindings earlier as they seemed like a more relevant
> contribution.

I did a quick look at the IIO staging drivers and here are some comments and
improvement suggestions for those.

drivers/staging/iio/accel/adis16203.c
Suggested improvements:
- Use include/linux/units.h
- Drop spi_set_drvdata()

drivers/staging/iio/adc/ad7816.c
Looks interesting at first glance. Not complicated, yet something to play with
as they have a "control byte" to select which channel to read and a CONVST pin
to handle.

drivers/staging/iio/addac/adt7316*
The device can communicate through I2C or SPI so could use regmap API to
standardize data transfers in the driver.
There was an old patch updating to regmap
https://marc.info/?l=linux-iio&m=154853847705361&w=2.
Aside from I2C related changes by and minor clean up changes, this driver hasn't
got updates in a while.
Suggested improvements:
- Use regmap to standardize data transfers.
- Add devicetree documentation.
- Check/change if attributes can use standard ABI and document those that are specific.

drivers/staging/iio/frequency/ad9832*
Suggested improvements:
- Use devm_regulator_get_enable_read_voltage().
- Use FIELD_PREP to set bit fields.
- Support for devicetree probing (struct for device match of_device_id).
- Devicetree documentation.
- Maybe drop platform data stuff.
- Check/change if attributes can use standard ABI and document those that are specific.

drivers/staging/iio/frequency/ad9834*
Somewhat similar to ad9832. For updating the ABI, might be useful to check out
previous patch set
https://patchwork.kernel.org/project/linux-iio/patch/20190225191731.5822-2-beniamin.bia@analog.com/
Suggested improvements:
- Support for devicetree probing (struct for device match of_device_id).
- Devicetree documentation.
- Check/change if attributes can use standard ABI and document those that are specific.

drivers/staging/iio/impedance-analyzer/ad5933.c
Suggested improvements:
- Check/change if attributes can use standard ABI and document those that are specific.
- Better test?


Regards,
Marcelo

Re: GSoC IIO project: Siddharth Menon

[Siddharth Menon]

On Mon, 3 Mar 2025 at 10:17, Marcelo Schmitt <marcelo.schmitt1@gmail.com> wrote:
>
> I did a quick look at the IIO staging drivers and here are some comments and
> improvement suggestions for those.

Thank you for taking the time to provide pointers to potential patches.
I'll begin with the adis16203, as it appears to be the simplest.
I'll also see if I can get access to any of the boards for testing.
If that's not possible, I'll focus on submitting patches with minimal risk
of breaking anything.

Regards,
Siddharth Menon

Re: GSoC IIO project: Siddharth Menon

[Marcelo Schmitt]

On 03/05, Siddharth Menon wrote:
> On Mon, 3 Mar 2025 at 10:17, Marcelo Schmitt <marcelo.schmitt1@gmail.com> wrote:
> >
> > I did a quick look at the IIO staging drivers and here are some comments and
> > improvement suggestions for those.
> 
> Thank you for taking the time to provide pointers to potential patches.
> I'll begin with the adis16203, as it appears to be the simplest.
> I'll also see if I can get access to any of the boards for testing.
> If that's not possible, I'll focus on submitting patches with minimal risk
> of breaking anything.
> 
Sounds great.

Thanks,
Marcelo

Re: GSoC IIO project: Siddharth Menon

[Jonathan Cameron]

> 
> drivers/staging/iio/addac/adt7316*
> The device can communicate through I2C or SPI so could use regmap API to
> standardize data transfers in the driver.
> There was an old patch updating to regmap
> https://marc.info/?l=linux-iio&m=154853847705361&w=2.
> Aside from I2C related changes by and minor clean up changes, this driver hasn't
> got updates in a while.
> Suggested improvements:
> - Use regmap to standardize data transfers.
> - Add devicetree documentation.
> - Check/change if attributes can use standard ABI and document those that are specific.

This one is an interesting part - I have one somewhere from trying to help
on the previous go at cleaning it up.  One issue is that I couldn't manage
to get a stable SPI connection patched onto the dev board.  It kind of
worked if I used a long cable and did a rain dance, but not enough to really
test it.

Jonathan

Re: GSoC IIO project: Siddharth Menon

[Siddharth Menon]

On Wed, 5 Mar 2025 at 20:28, Jonathan Cameron <jic23@kernel.org> wrote:
>
> This one is an interesting part - I have one somewhere from trying to help
> on the previous go at cleaning it up.  One issue is that I couldn't manage
> to get a stable SPI connection patched onto the dev board.  It kind of
> worked if I used a long cable and did a rain dance, but not enough to really
> test it.

I'll see if I can get my hands on one. Just to clarify, were the issues present
before, or are you referring specifically to the patch?

Please share the specific rain dance with me for future reference.

Regards,
Siddharth Menon

Re: GSoC IIO project: Siddharth Menon

[Jonathan Cameron]

On Fri, 7 Mar 2025 00:25:46 +0530
Siddharth Menon <simeddon@gmail.com> wrote:

> On Wed, 5 Mar 2025 at 20:28, Jonathan Cameron <jic23@kernel.org> wrote:
> >
> > This one is an interesting part - I have one somewhere from trying to help
> > on the previous go at cleaning it up.  One issue is that I couldn't manage
> > to get a stable SPI connection patched onto the dev board.  It kind of
> > worked if I used a long cable and did a rain dance, but not enough to really
> > test it.  
> 
> I'll see if I can get my hands on one. Just to clarify, were the issues present
> before, or are you referring specifically to the patch?

Unrelated - it was an electrical issue as far as I could tell.  Comes of
patching leads onto pins on a dev board. Not great for signal integrity!
> 
> Please share the specific rain dance with me for future reference.

Hmm. I might be able to find it and see what patching I did but you
may be better off figuring it out your self for whatever board you can
get hold of.

Jonathan

> 
> Regards,
> Siddharth Menon

Re: GSoC IIO project: Siddharth Menon

[Siddharth Menon]

subject: adt7316 driver viable as a gsoc project?

While working on the patch for the AD9832, I started looking for an available
AD9832 board as I didn’t want to make too many changes without a testing unit
on hand.

While I was browsing, I came across the ADT7316, which doesn’t seem to have
existing driver support.

I know this is last minute with proposal submissions closing tomorrow, but
I’m considering working on it anyway and wanted to ask if it’d be worth getting
this board.

Re: GSoC IIO project: Siddharth Menon

[Marcelo Schmitt]

Hi Siddharth,

On 04/08, Siddharth Menon wrote:
> subject: adt7316 driver viable as a gsoc project?
> 
> While working on the patch for the AD9832, I started looking for an available
> AD9832 board as I didn’t want to make too many changes without a testing unit
> on hand.
> 
> While I was browsing, I came across the ADT7316, which doesn’t seem to have
> existing driver support.

There's a driver in staging (drivers/staging/iio/addac/*).

> 
> I know this is last minute with proposal submissions closing tomorrow, but
> I’m considering working on it anyway and wanted to ask if it’d be worth getting
> this board.

While it would be possible to do a GSoC project for ADT7316, I think it wouldn't
be as interesting as developing a new driver, IMO. May be a good one for
contributing as non-gsoc project.

Re: GSoC IIO project: Siddharth Menon

[Siddharth Menon]

On Tue, 8 Apr 2025 at 09:26, Marcelo Schmitt <marcelo.schmitt1@gmail.com> wrote:
> While it would be possible to do a GSoC project for ADT7316, I think it wouldn't
> be as interesting as developing a new driver, IMO. May be a good one for
> contributing as non-gsoc project.

Thank you for the feedback, I’m not sure how I missed the staging driver.
While looking through available devices, I also came across the ADS8321.
From what I can tell, there’s currently no driver for it in the kernel.

Based on the schematics in the datasheet, the device appears to be relatively
simple to work with.

I believe developing a driver for the ADS8321 is quite feasible, if all
goes well, I will be submitting a proposal for it within the next few hours.

Regards,
Siddharth Menon