Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752312AbdLHIzj (ORCPT ); Fri, 8 Dec 2017 03:55:39 -0500 Received: from mail-wr0-f169.google.com ([209.85.128.169]:42084 "EHLO mail-wr0-f169.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751106AbdLHIzi (ORCPT ); Fri, 8 Dec 2017 03:55:38 -0500 X-Google-Smtp-Source: AGs4zMZ7SNbdDO5vGdHccBaOQb1+pkJ1PozAJzAP1iTIMnnxls+yDL+Lqh85uJtUEq94LK8JA7jTgg== Date: Fri, 8 Dec 2017 09:55:33 +0100 From: Daniel Vetter To: Alan Cox Cc: Daniel Vetter , Pavel Machek , Sean Paul , David Airlie , intel-gfx@lists.freedesktop.org, linux-kernel@vger.kernel.org, linux-mediatek@lists.infradead.org, dri-devel@lists.freedesktop.org, Daniel Vetter , linux-arm-kernel@lists.infradead.org Subject: Re: [RFC PATCH 1/6] drm: Add Content Protection property Message-ID: <20171208085533.ekzgow4svhw7xnqz@phenom.ffwll.local> Mail-Followup-To: Alan Cox , Pavel Machek , Sean Paul , David Airlie , intel-gfx@lists.freedesktop.org, linux-kernel@vger.kernel.org, linux-mediatek@lists.infradead.org, dri-devel@lists.freedesktop.org, Daniel Vetter , linux-arm-kernel@lists.infradead.org References: <20171130030907.26848-1-seanpaul@chromium.org> <20171130030907.26848-2-seanpaul@chromium.org> <20171205102840.GB12982@amd> <20171205104538.b4fxdjad3c46koas@phenom.ffwll.local> <20171207143052.533e1e94@alans-desktop> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20171207143052.533e1e94@alans-desktop> X-Operating-System: Linux phenom 4.13.0-1-amd64 User-Agent: NeoMutt/20170609 (1.8.3) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1172 Lines: 30 On Thu, Dec 07, 2017 at 02:30:52PM +0000, Alan Cox wrote: > > If you want to actually lock down a machine to implement content > > protection, then you need secure boot without unlockable boot-loader and a > > pile more bits in userspace. > > So let me take my Intel hat off for a moment. > > The upstream policy has always been that we don't merge things which > don't have an open usable user space. Is the HDCP encryption feature > useful on its own ? What do users get from it ? > > If this is just an enabler for a lump of binary stuff in ChromeOS then I > don't think it belongs, if it is useful standalone then it seems it does > belong ? The cros side is ofc all open source. dri-devel is extremely strict with not taking anything that doesn't fullfil this requirement, probably more strict than anyone else. Sean has the link in the cover letter of his patch series. For more context, here's our documented expectations about the userspace side of any uapi addition to drm: https://dri.freedesktop.org/docs/drm/gpu/drm-uapi.html#open-source-userspace-requirements Cheers, Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch