RE: [EXT] Re: [PATCH] Uwb: Nxp: sr1xx: Uwb driver support for sr1xx series chip

[Manjunatha Venkatesh]

Hello Greg,

Thanks for sharing your comments with us and apologies for our delayed
response. 
We have done a thorough review internally and would like to put forward a
proposal for your consideration.

1)  In our next submission we will define the kernel/user API clearly with
kernel pre-defined IOCTL macros in the uapi header file and follow the
standard IOCTL rules.
2)  We agree that this is a simple driver which may not need a dedicated
directory under Linux/drivers so we will move the driver to "misc" folder.
3)  We can also share some applications which show the usage of these driver
API's from the user space.

We would like to get your preview on this thought process to progress with
our next driver submission.

Regards,
Manju

> -----Original Message-----
> From: Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx>
> Sent: Tuesday, March 15, 2022 6:02 PM
> To: Manjunatha Venkatesh <manjunatha.venkatesh@xxxxxxx>
> Cc: linux-kernel@xxxxxxxxxxxxxxx; will@xxxxxxxxxx; axboe@xxxxxxxxx;
> mb@xxxxxxxxxxx; ckeepax@xxxxxxxxxxxxxxxxxxxxx; arnd@arndb.d;
> mst@xxxxxxxxxx; javier@xxxxxxxxxxx; mikelley@xxxxxxxxxxxxx;
> jasowang@xxxxxxxxxx; sunilmut@xxxxxxxxxxxxx;
> bjorn.andersson@xxxxxxxxxx; rvmanjumce@xxxxxxxxx
> Subject: Re: [EXT] Re: [PATCH] Uwb: Nxp: sr1xx: Uwb driver support for
sr1xx
> series chip
> 
> Caution: EXT Email
> 
> On Tue, Mar 15, 2022 at 10:43:47AM +0000, Manjunatha Venkatesh wrote:
> > >> +     sr1xx_dev = filp->private_data;
> > >> +     switch (cmd) {
> > >> +     case SR1XX_SET_PWR:
> > > You have custom ioctls on a device node, that's not very "subsystem"
> > > like at all.
> > >
> > > You need to define a standard user/kernel api for this subsystem, do
> > > not make it "whatever the device wants" like this currently is.
> > >
> > > And where is the userspace code that talks this brand new api?  We
> > > need to see that so we can properly determine if this is all working
> > > properly.
> > Currently these ioctl calls used for handling proprietary operation
> > with respect to SR1xx chip.
> > corresponding user space UWB code is proprietary and might be shortly
> > will be available as part of AOSP release, till that time not sure can
> > share user space code outside or not.
> > Still if you think need the user space code required to evaluate
> > driver part will check internally and come back on this.
> 
> For obvious reasons, we can not take kernel drivers that add a custom
> user/kernel api without any userspace code that we can see to use it.
> You wouldn't want us to take such code anyway.
> 
> So please, fix that, otherwise this is not going to go very far at all.
> 
> thanks,
> 
> greg k-h

Attachment: smime.p7s
Description: S/MIME cryptographic signature