Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Thu, 13 Apr 2023 10:52:27 +0200
From:   Daniel Vetter <daniel@ffwll.ch>
To:     Greg KH <gregkh@linuxfoundation.org>
Cc:     Jeffrey Hugo <quic_jhugo@quicinc.com>, daniel@ffwll.ch,
        sfr@canb.auug.org.au, ogabbay@kernel.org,
        jacek.lawrynowicz@linux.intel.com, quic_pkanojiy@quicinc.com,
        mani@kernel.org, airlied@redhat.com,
        dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org,
        linux-next@vger.kernel.org
Subject: Re: [PATCH] Revert "accel/qaic: Add mhi_qaic_cntl"
Message-ID: <ZDfCyyljbvTrNpeg@phenom.ffwll.local>
Mail-Followup-To: Greg KH <gregkh@linuxfoundation.org>,
        Jeffrey Hugo <quic_jhugo@quicinc.com>, sfr@canb.auug.org.au,
        ogabbay@kernel.org, jacek.lawrynowicz@linux.intel.com,
        quic_pkanojiy@quicinc.com, mani@kernel.org, airlied@redhat.com,
        dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org,
        linux-next@vger.kernel.org
References: <1681307864-3782-1-git-send-email-quic_jhugo@quicinc.com>
 <2023041201-underwear-consumer-1eb8@gregkh>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <2023041201-underwear-consumer-1eb8@gregkh>
Precedence: bulk

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@ffwll.ch>
> > Signed-off-by: Jeffrey Hugo <quic_jhugo@quicinc.com>
> > Reviewed-by: Pranjal Ramajor Asha Kanojiya <quic_pkanojiy@quicinc.com>
> 
> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.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