From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.4 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,URIBL_RED, USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1B14EC433DB for ; Tue, 19 Jan 2021 20:23:34 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id AB1D223104 for ; Tue, 19 Jan 2021 20:23:33 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731665AbhASUXO (ORCPT ); Tue, 19 Jan 2021 15:23:14 -0500 Received: from relay.smtp-ext.broadcom.com ([192.19.232.172]:38624 "EHLO relay.smtp-ext.broadcom.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730467AbhASUWh (ORCPT ); Tue, 19 Jan 2021 15:22:37 -0500 Received: from [10.136.13.65] (lbrmn-lnxub113.ric.broadcom.net [10.136.13.65]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by relay.smtp-ext.broadcom.com (Postfix) with ESMTPS id AA0E030E76; Tue, 19 Jan 2021 12:21:33 -0800 (PST) DKIM-Filter: OpenDKIM Filter v2.11.0 relay.smtp-ext.broadcom.com AA0E030E76 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=broadcom.com; s=dkimrelay; t=1611087694; bh=lZ/JMNpu6rfS9YeYxhVgrk4nqkhdY79CK6WmTClAM/k=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=aYbUj63BQSZKC++091Gzm4uOa8RxHIw8yV5j512+pssyyW2NQroamUFHuh4N5lLYI KZrGhbgJBBMKEGyz0D2lnBykecfjWvy2mF2NhQLWOehUz3DgQSh0zFfybRUL4Gadxo sS9AC8etDvdzqprb/p75sw+vz2dkrPeca6Q4TJFs= Subject: Re: [PATCH v8 00/13] Add Broadcom VK driver To: Olof Johansson , Greg Kroah-Hartman Cc: Arnd Bergmann , Desmond Yan , Kees Cook , Linux Kernel Mailing List , Broadcom Kernel Feedback List References: <20201130184200.5095-1-scott.branden@broadcom.com> From: Scott Branden Message-ID: <09b6e829-75b8-4f16-3e01-c7193640d9c6@broadcom.com> Date: Tue, 19 Jan 2021 12:21:32 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-CA Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Greg, On 2021-01-18 3:06 p.m., Olof Johansson wrote: > On Sun, Jan 17, 2021 at 11:17 PM Greg Kroah-Hartman > wrote: >> On Sun, Jan 17, 2021 at 10:47:59AM -0800, Olof Johansson wrote: >>> Hi, >>> >>> On Mon, Nov 30, 2020 at 10:42 AM Scott Branden >>> wrote: >>>> This patch series drops previous patches in [1] >>>> that were incorporated by Kees Cook into patch series >>>> "Introduce partial kernel_read_file() support" [2]. >>>> >>>> Remaining patches are contained in this series to add Broadcom VK driver. >>>> (which depends on request_firmware_into_buf API addition which has >>>> now been accepted into the upstream kernel as of v5.10-rc1). >>>> >>>> [1] https://lore.kernel.org/lkml/20200706232309.12010-1-scott.branden@broadcom.com/ >>>> [2] https://lore.kernel.org/lkml/20201002173828.2099543-1-keescook@chromium.org/ >>> >>> I've been following this series for some time, and I think the code is >>> ready to go in. >>> >>> Greg, mind queuing this up in the misc tree? >> I will need a new version, this is long gone from my queue. > I'll let Scott repost then (with acks applied etc) I can send another patch version with Olof's acks applied to each patch. Please let me know if that is what you are looking for? > >> And hopefully the tty layer abuse is gone... :) > There's a simple tty driver as the final patch in the series, but it's > pretty straightforward. > > If you've still got concerns with it, the rest of the series should > stand on its own and should be mergeable without that piece. Yes, I placed the patch at the end of the series so it can be dropped if that is what is required to accept the rest of the patches. There has been no viable solution suggested for replacing this functionality. We need a tty-like interface that works via access to the circular buffers in PCIe BAR space and interrupts. The vk tty devices are a direct replacement to attaching serial cables. In real production environment it is not possible to attach such cables. I can work on an alternative tty solution and send such patch later but I don't know what is going to prevent the tty "abuse". > > > -Olof Regards, Scott