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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Mon, 25 Sep 2023 06:51:23 -0700
From:   Guenter Roeck <linux@...ck-us.net>
To:     Greg KH <gregkh@...uxfoundation.org>
Cc:     Manjunatha Venkatesh <manjunatha.venkatesh@....com>,
        linux-kernel@...r.kernel.org, will@...nel.org, axboe@...nel.dk,
        robh+dt@...nel.org, mb@...htnvm.io, ckeepax@...nsource.cirrus.com,
        arnd@...db.d, mst@...hat.com, javier@...igon.com,
        mikelley@...rosoft.com, jasowang@...hat.com,
        sunilmut@...rosoft.com, bjorn.andersson@...aro.org,
        krzysztof.kozlowski+dt@...aro.org, devicetree@...r.kernel.org,
        ashish.deshpande@....com, rvmanjumce@...il.com,
        Kwame Adwere <kwame.adwere@....com>
Subject: Re: [PATCH v6 2/2] misc: nxp-sr1xx: UWB driver support for sr1xx
 series chip

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