lkml.org 
[lkml]   [2020]   [Sep]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [PATCH v5 00/15] Add Broadcom VK driver
Date


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

\
 
 \ /
  Last update: 2020-10-01 04:39    [W:0.127 / U:6.476 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site