Hi Martin, We are working on adding bsg interface support in mpi3mr driver. In bsg, we can use SG_IO command type for synchronous ioctls, but I don't see the infrastructure for asynchronous commands. I searched a bit around it and noticed that "poll" interface was supported earlier but removed through this patch- https://www.spinics.net/lists/kernel/msg2853766.html We have a requirement wherein the userland application/daemon waits/listens for asynchronous driver/firmware events. With driver IOCTLs, we were using the "fasync" interface for this. How can we achieve the same with bsg interface ? Thanks, Sumit On Fri, Oct 29, 2021 at 12:04 AM Kashyap Desai <kashyap.desai@xxxxxxxxxxxx> wrote: > > > > > > > Kashyap, > > > > > Immediately dropping ioctl support will create lots of issues for > > > Development/Test (within a org + OEM testing). How about accepting > > > updated ioctl patch-set after reviewed-by tag (which will not use > > > static MAJOR number) for time being ? > > > > If we were to introduce an ioctl interface for mpi3mr we would never be > able > > to deprecate it without breaking existing applications. > > Martin - > > Understood that best case scenario is not to have IOCTL interface code at > all in kernel tree (for new drivers), but we need this interface to be > there for couple of > months. > As of now, There is only in-house application development happened on > <mpi3mr> since product is under development and OEM has access to the h/w > for pre-GA testing. > We are also planning to document such interface change for those who wants > to develop their own application in future. Most of the application which > need interopt check of ioctl vs bsg will be Broadcom in-house and we are > planning to take care the same. > > How about providing unlocked_ioctl under module parameter ? By default > parameter will be OFF (this will avoid interopt issue as you mentioned) > and at least user who really have dependency on Test vehicle for time > being can enable it. > Once <bsg> interface is available, we will remove whole IOCTL code from > tree. > > > Kashyap > > > > While I appreciate that it is inconvenient to have to update your > tooling, this is > > the only chance we have to get the interface right. > > > > -- > > Martin K. Petersen Oracle Linux Engineering
