lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Thu, 16 Jan 2020 16:03:58 -0800
From:   Olof Johansson <olof@...om.net>
To:     Santosh Shilimkar <santosh.shilimkar@...cle.com>
Cc:     soc@...nel.org, arm@...nel.org,
        linux-arm-kernel@...ts.infradead.org, khilman@...nel.org,
        arnd@...db.de, linux-kernel@...r.kernel.org, vkoul@...nel.org
Subject: Re: [GIT_PULL] SOC: TI Keystone Ring Accelerator driver for v5.6

Hi,

On Thu, Jan 16, 2020 at 12:07:39PM -0800, Santosh Shilimkar wrote:
> Its bit late for pull request, but if possible, please pull it to
> soc drivers tree.
> 
> The following changes since commit e42617b825f8073569da76dc4510bfa019b1c35a:
> 
>   Linux 5.5-rc1 (2019-12-08 14:57:55 -0800)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/ssantosh/linux-keystone.git tags/drivers_soc_for_5.6
> 
> for you to fetch changes up to 3277e8aa2504d97e022ecb9777d784ac1a439d36:
> 
>   soc: ti: k3: add navss ringacc driver (2020-01-15 10:07:27 -0800)
> 
> ----------------------------------------------------------------
> SOC: TI Keystone Ring Accelerator driver
> 
> The Ring Accelerator (RINGACC or RA) provides hardware acceleration to
> enable straightforward passing of work between a producer and a consumer.
> There is one RINGACC module per NAVSS on TI AM65x SoCs.

This driver doesn't seem to have exported symbols, and no in-kernel
users. So how will it be used?

Usually we ask to hold off until the consuming side/drivers are also ready.

Also, is there a reason this is under drivers/soc/ instead of somewhere more
suitable in the drivers subsystem? It's not "soc glue code" in the same way as
drivers/soc was intended originally.


-Olof

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ