Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
To:     Scott Branden <scott.branden@broadcom.com>,
        Arnd Bergmann <arnd@arndb.de>,
        Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        Olof Johansson <olof@lixom.net>
Cc:     Kees Cook <keescook@chromium.org>, linux-kernel@vger.kernel.org,
        bcm-kernel-feedback-list@broadcom.com
References: <20201001012810.4172-1-scott.branden@broadcom.com>
From:   Florian Fainelli <f.fainelli@gmail.com>
Subject: Re: [PATCH v5 00/15] Add Broadcom VK driver
Message-ID: <e5855e95-dcae-351e-3351-ed1ba9170f7e@gmail.com>
Date:   Wed, 30 Sep 2020 19:38:56 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
 Firefox/78.0 Thunderbird/78.3.1
MIME-Version: 1.0
In-Reply-To: <20201001012810.4172-1-scott.branden@broadcom.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Precedence: bulk


On 9/30/2020 6:27 PM, 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 in
> other patch series [2] being applied first).
> 
> Please note this patch series will not compile without [2].
> 
> [1] https://lore.kernel.org/lkml/20200706232309.12010-1-scott.branden@broadcom.com/
> [2] https://lore.kernel.org/lkml/20200729175845.1745471-1-keescook@chromium.org/

Disclaimer: I am well aware that it is the complete wild west right now 
as far as accelerators go and that every vendor (that I happen to work 
for, just not in the same group as Scott) is just seeking to get their 
drivers included upstream and hopefully for good reasons.

 From a cursory look however, it sounds like there could be a little 
better re-utilization of standards, standard framework and interfaces:

- about 2/3 of your sysfs attributes should incline you to implement a 
HWMON device, not a complicated one, but anything that indicates 
current, power, temperature, alerts etc. should be considered

- cannot the firmware loading be supported over remoteproc somehow?

- could not the TTY interface be using virtio or an existing UART?

- what is the format of the message over BAR2 that you expose in patch 13?

Is there a reference user-space implementation that you can link to this 
patch submission in case people are curious?

Thanks
-- 
Florian