linux-kernel - Re: [PATCH] Revert "accel/qaic: Add mhi_qaic

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <ZDfCyyljbvTrNpeg@phenom.ffwll.local>
Date:   Thu, 13 Apr 2023 10:52:27 +0200
From:   Daniel Vetter <daniel@...ll.ch>
To:     Greg KH <gregkh@...uxfoundation.org>
Cc:     Jeffrey Hugo <quic_jhugo@...cinc.com>, daniel@...ll.ch,
        sfr@...b.auug.org.au, ogabbay@...nel.org,
        jacek.lawrynowicz@...ux.intel.com, quic_pkanojiy@...cinc.com,
        mani@...nel.org, airlied@...hat.com,
        dri-devel@...ts.freedesktop.org, linux-kernel@...r.kernel.org,
        linux-next@...r.kernel.org
Subject: Re: [PATCH] Revert "accel/qaic: Add mhi_qaic_cntl"

On Wed, Apr 12, 2023 at 07:15:43PM +0200, Greg KH wrote:
> On Wed, Apr 12, 2023 at 07:57:44AM -0600, Jeffrey Hugo wrote:
> > This reverts commit 566fc96198b4bb07ca6806386956669881225271.
> > 
> > This exposes a userspace API that is still under debate.  Revert the
> > change before the uAPI gets exposed to avoid making a mistake.  QAIC is
> > otherwise still functional.
> > 
> > Suggested-by: Daniel Vetter <daniel@...ll.ch>
> > Signed-off-by: Jeffrey Hugo <quic_jhugo@...cinc.com>
> > Reviewed-by: Pranjal Ramajor Asha Kanojiya <quic_pkanojiy@...cinc.com>
> 
> Acked-by: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
> 
> And can you cc: me when you resubmit this?  It's not really correct in a
> number of places and can be made simpler if you really want to have your
> own class and device major.

+1 on this, in the other thread my take was that this should go through
driver model tree in the mhi bus, and I guess needs some review there
about safety and all that. We do a lot of funny uapi in drm/accel, but
full generic driver-in-userspace is really not our thing :-)

I guess there's also the question whether this should be debugfs (like the
usb stuff, or did that move by now) or real chardev. Might also make sense
to integrate with vfio/mdev/iommufd depending how the security model
works.

But really this is all stuff where I'm hightailing it asap :-)
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch