[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <2024070427-squash-antiviral-8c81@gregkh>
Date: Thu, 4 Jul 2024 08:40:00 +0200
From: Greg KH <gregkh@...uxfoundation.org>
To: Ekansh Gupta <quic_ekangupt@...cinc.com>
Cc: srinivas.kandagatla@...aro.org, linux-arm-msm@...r.kernel.org,
quic_bkumar@...cinc.com, linux-kernel@...r.kernel.org,
quic_chennak@...cinc.com, dri-devel@...ts.freedesktop.org,
arnd@...db.de
Subject: Re: [PATCH v1] misc: fastrpc: Add support for multiple PD from one
process
On Thu, Jul 04, 2024 at 11:47:22AM +0530, Ekansh Gupta wrote:
>
>
> On 7/3/2024 4:09 PM, Greg KH wrote:
> > On Wed, Jul 03, 2024 at 12:22:00PM +0530, Ekansh Gupta wrote:
> >> @@ -268,6 +272,7 @@ struct fastrpc_channel_ctx {
> >> struct fastrpc_session_ctx session[FASTRPC_MAX_SESSIONS];
> >> spinlock_t lock;
> >> struct idr ctx_idr;
> >> + struct ida dsp_pgid_ida;
> > You have an idr and an ida? Why two different types for the same
> > driver?
> Using ida for this because for this I just need to allocate and manage unique IDs
> without any associated data. So this looks more space efficient that idr.
> Should I keep it uniform for a driver?
Be consistant, it will make your life easier over the next 10+ years
that you have to maintain it.
> >> struct list_head users;
> >> struct kref refcount;
> >> /* Flag if dsp attributes are cached */
> >> @@ -299,6 +304,7 @@ struct fastrpc_user {
> >> struct fastrpc_buf *init_mem;
> >>
> >> int tgid;
> >> + int dsp_pgid;
> > Are you sure this fits in an int?
> I think this should be fine for IDs in rage of 1000-1064.
Where is that range specified anywhere? I don't see it documented here
for us to know that :(
And if that's all you care about, then use a u16.
thanks,
greg k-h
Powered by blists - more mailing lists