misc: fastrpc: is a ctx_idr IDR -> XArray conversion wanted?

misc: fastrpc: is a ctx_idr IDR -> XArray conversion wanted?

[Murali Krishna]

Hi Srini, Ekansh,

I am new to kernel development and would like to start contributing. I
do not have much experience yet, but I am willing to learn and to put in
the work properly.

Documentation/core-api/idr.rst states that the IDR interface is
deprecated in favour of the XArray, and fastrpc's ctx_idr is still an
IDR. I have a conversion prepared -- XA_FLAGS_ALLOC1, xa_alloc_cyclic()
with the cursor kept in struct fastrpc_channel_ctx, xa_load() and
xa_erase(), and cctx->lock left as it is -- with no intended functional
change.

Before posting it, I would rather ask than take up your review time: is
such a conversion wanted in fastrpc, or is the IDR usage here fine as it
is? I have seen similar conversions in other subsystems declined as
unnecessary, so I did not want to assume.

I should also say that it is build- and sparse-tested only (x86_64,
COMPILE_TEST, W=1 C=1, no new warnings). I have no Qualcomm hardware, so
the converted path has never actually run.

I am aware of the accel/qda series, described as an alternative to this
driver. If fastrpc.c is effectively in maintenance mode, that is a good
reason to say no.

If the answer is no, I would be grateful if you could point me towards
something you would actually like to see worked on here. I am happy to
start with something small and learn from the review.

Thank you for your time,
Murali Krishna

Re: misc: fastrpc: is a ctx_idr IDR -> XArray conversion wanted?

[Greg KH]

On Wed, Sep 23, 2026 at 01:52:05PM +0530, Murali Krishna wrote:
> Hi Srini, Ekansh,
> 
> I am new to kernel development and would like to start contributing. I
> do not have much experience yet, but I am willing to learn and to put in
> the work properly.
> 
> Documentation/core-api/idr.rst states that the IDR interface is
> deprecated in favour of the XArray, and fastrpc's ctx_idr is still an
> IDR. I have a conversion prepared -- XA_FLAGS_ALLOC1, xa_alloc_cyclic()
> with the cursor kept in struct fastrpc_channel_ctx, xa_load() and
> xa_erase(), and cctx->lock left as it is -- with no intended functional
> change.
> 
> Before posting it, I would rather ask than take up your review time: is
> such a conversion wanted in fastrpc, or is the IDR usage here fine as it
> is? I have seen similar conversions in other subsystems declined as
> unnecessary, so I did not want to assume.

I doubt it's really needed unless you can prove some sort of advantage
for the change?  Is it faster on a measurable path, or less memory or
something else that would justify the churn?

idr is still a fine structure/api for many things, they don't all have
to go away, otherwise we would have done so long ago.

thanks,

greg k-h

Re: misc: fastrpc: is a ctx_idr IDR -> XArray conversion wanted?

[Murali Krishna]

On Wed, Sep 23, 2026 at 11:28:52AM +0200, Greg KH wrote:
> I doubt it's really needed unless you can prove some sort of advantage
> for the change?  Is it faster on a measurable path, or less memory or
> something else that would justify the churn?
>
> idr is still a fine structure/api for many things, they don't all have
> to go away, otherwise we would have done so long ago.

Understood, and I cannot show such an advantage. struct idr is already
built on the same underlying tree as the xarray, so there is nothing
measurable to gain here in speed or memory -- it would be churn for its
own sake. I will drop the conversion.

Thank you for answering so quickly, and for explaining the reasoning
rather than just saying no. That was useful to me.

If there is something in fastrpc, or elsewhere in drivers/misc, that you
would actually like to see worked on, I would be glad to take on
something small and learn from the review.

Thanks,
Murali Krishna

Re: misc: fastrpc: is a ctx_idr IDR -> XArray conversion wanted?

[Greg KH]

On Wed, Sep 23, 2026 at 03:10:01PM +0530, Murali Krishna wrote:
> On Wed, Sep 23, 2026 at 11:28:52AM +0200, Greg KH wrote:
> > I doubt it's really needed unless you can prove some sort of advantage
> > for the change?  Is it faster on a measurable path, or less memory or
> > something else that would justify the churn?
> >
> > idr is still a fine structure/api for many things, they don't all have
> > to go away, otherwise we would have done so long ago.
> 
> Understood, and I cannot show such an advantage. struct idr is already
> built on the same underlying tree as the xarray, so there is nothing
> measurable to gain here in speed or memory -- it would be churn for its
> own sake. I will drop the conversion.
> 
> Thank you for answering so quickly, and for explaining the reasoning
> rather than just saying no. That was useful to me.
> 
> If there is something in fastrpc, or elsewhere in drivers/misc, that you
> would actually like to see worked on, I would be glad to take on
> something small and learn from the review.

Please help with review and testing of all of the patches that keep
getting sent for this driver, that would be the best help at this point
in time and will show you what needs to be done on it in the future.

thanks,

greg k-h