> -----Original Message-----
> From: Jason Gunthorpe <jgg@xxxxxxxx>
> Sent: Sunday, November 25, 2018 9:18 PM
> To: Parav Pandit <parav@xxxxxxxxxxxx>
> Cc: Leon Romanovsky <leon@xxxxxxxxxx>; Doug Ledford
> <dledford@xxxxxxxxxx>; Leon Romanovsky <leonro@xxxxxxxxxxxx>; RDMA
> mailing list <linux-rdma@xxxxxxxxxxxxxxx>; Daniel Jurgens
> <danielj@xxxxxxxxxxxx>
> Subject: Re: [PATCH rdma-next 2/9] RDMA: Introduce and use
> rdma_device_to_ibdev()
>
> On Sat, Nov 24, 2018 at 06:53:03PM +0000, Parav Pandit wrote:
> > > > +static inline struct ib_device *rdma_device_to_ibdev(struct
> > > > +device
> > > > +*device) {
> > > > + return dev_get_drvdata(device);
> > > > +}
> > >
> > > No, in the linux device model the drvdata belongs to the final
> > > driver. Core code should not co-opt it.
> >
> > I relied on your commit [1] where ib_core sets the driver data and not
> > final driver. Though commit [1] doesn't seems to make use of drvdata
> > using core defined API dev_get_drvdata() which I think you intent to
> > use in release function but container_of was still right in release
> > function. Not sure.
>
> It was a mistake, I didn't learn about the the drv separation until a bit later.
>
> We should see if we can drop it ...
Yes. It is dropped with the hunk I posted in previous email.
>
> > > This needs to use a container_of expression to get the ib_device pointer.
> >
> > Yes, that is possible by storing additional pointer in ib_core_device
> > so that original device and fake ib_core_devices can reach back to
> > ib_device in consistent way. This patch will just have additional
> > changes of rdma_to_drv_device() what you described, And, In patch with
> > subject [2] will have below additional changes and will update
> > Documentation accordingly. Does that look fine?
>
> Yes
Ok. Thanks. sending v1 through Leon's queue.
