Re: [PATCH v6 2/2] misc: nxp-sr1xx: UWB driver support for sr1xx series chip

[Guenter Roeck]

On Wed, Dec 21, 2022 at 07:12:49AM +0100, Greg KH wrote:
> On Tue, Dec 20, 2022 at 09:17:47PM +0530, Manjunatha Venkatesh wrote:
> > Ultra-wideband (UWB) is a short-range wireless communication protocol.
> > 
> > NXP has SR1XX family of UWB Subsystems (UWBS) devices. SR1XX SOCs
> > are FiRa Compliant. SR1XX SOCs are flash less devices and they need
> > Firmware Download on every device boot. More details on the SR1XX Family
> > can be found at https://www.nxp.com/products/:UWB-TRIMENSION
> > 
> > The sr1xx driver work the SR1XX Family of UWBS, and uses UWB Controller
> > Interface (UCI).  The corresponding details are available in the FiRa
> > Consortium Website (https://www.firaconsortium.org/).
> > 
> > Internally driver will handle two modes of operation.
> > 1.HBCI mode (sr1xx BootROM Code Interface)
> >   Firmware download uses HBCI ptotocol packet structure which is
> >   Nxp proprietary,Firmware File(.bin) stored in user space context
> >   and during device init sequence pick the firmware packet in chunk
> >   and send it to the driver with write() api call.
> > 
> >   After the firmware download sequence at the end UWBS will
> >   send device status notification and its indication of device entered
> >   UCI mode.
> >   Here after any command/response/notification will follow
> >   UCI packet structure.
> > 
> > 2.UCI mode (UWB Command interface)
> >   Once Firmware download finishes sr1xx will switch to UCI mode.
> >   Then driver exchange command/response/notification as per the FIRA UCI
> >   standard format between user space and sr1xx device.
> >   Any response or notification received from sr1xx through SPI line
> >   will convey to user space.
> > 
> >   Its Interrupt based driver and IO Handshake needed with SR1XX Family of
> >   SOCs.
> >   This driver needs dts config update as per the sr1xx data sheet.
> >   Corresponding document available in Documentation/devicetree/bindings/uwb
> > 
[ ... ]
> 
> Also, I see no justification here for why this has to be a kernel
> driver, OR where the userspace code is that controls this.
> 

After seeing all the warnings generated by 0-day after this driver was
applied to chromeos-6.1, my basic question is similar but boils down to:
Why does this need a userspace component to start with, and why wasn't it
implemented as firmware download driver ?

Guenter