From: Jonathan Cameron <jonathan.cameron@huawei.com>
To: Greg KH <gregkh@linuxfoundation.org>
Cc: "Taimoor Zaeem" <taimoorzaeem@gmail.com>,
jic23@kernel.org, linux-iio@vger.kernel.org,
linux-staging@lists.linux.dev, "Nuno Sá" <nuno.sa@analog.com>
Subject: Re: [PATCH] staging: iio: ad9832: move ad9832_platform_data into include/linux/lib
Date: Mon, 6 Oct 2025 11:57:54 +0100 [thread overview]
Message-ID: <20251006115754.00006876@huawei.com> (raw)
In-Reply-To: <2025100548-stereo-patronage-408a@gregkh>
On Sun, 5 Oct 2025 16:00:33 +0200
Greg KH <gregkh@linuxfoundation.org> wrote:
> On Sun, Oct 05, 2025 at 05:18:29PM +0500, Taimoor Zaeem wrote:
> > Move struct ad9832_platform_data from
> > drivers/staging/iio/frequency/ad9832.h to
> > include/linux/iio/frequency/ad9832.h.
> >
> > This clears a TODO item in the drivers.
>
> No, this should only happen when the whole driver moves out of
> drivers/staging/, staging drivers shoul dbe self-contained.
>
> Also, why is a .h file needed for just one file anyway? Shouldn't this
> be part of the .c file instead?
It's an old school board file / platform data definition.
So it would be fine to get rid of that entirely and move the
driver to appropriate modern firmware interfaces but if we keep the
struct definition it doesn't make sense to move it into the C file.
I'm edging closer to just posting a series to get rid of these
remaining IIO drivers in staging, but normally I've only done that
when the parts have gone out of production as until that point it
seems reasonable that they might eventually get cleaned up, ABI
fixed etc and the costs of keeping them around are low.
Nuno, can you see if you can get a view from ADI on whether there
will ever be any effort to sort these ancient drivers out?
I appreciate that may be challenging to answer though.
Jonathan
>
> thanks,
>
> greg k-h
>
prev parent reply other threads:[~2025-10-06 10:57 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-05 12:18 [PATCH] staging: iio: ad9832: move ad9832_platform_data into include/linux/lib Taimoor Zaeem
2025-10-05 14:00 ` Greg KH
2025-10-05 14:47 ` Taimoor Zaeem
2025-10-06 6:21 ` Greg KH
2025-10-06 10:57 ` Jonathan Cameron [this message]
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=20251006115754.00006876@huawei.com \
--to=jonathan.cameron@huawei.com \
--cc=gregkh@linuxfoundation.org \
--cc=jic23@kernel.org \
--cc=linux-iio@vger.kernel.org \
--cc=linux-staging@lists.linux.dev \
--cc=nuno.sa@analog.com \
--cc=taimoorzaeem@gmail.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.