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  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:   Sat, 25 Apr 2020 21:23:27 -0700
From:   Sowjanya Komatineni <>
To:     Dmitry Osipenko <>,
        Hans Verkuil <>, <>,
        <>, <>, <>,
CC:     <>, <>,
        <>, <>,
        <>, <>
Subject: Re: [RFC PATCH v10 6/9] media: tegra: Add Tegra210 Video input driver

On 4/25/20 7:19 PM, Dmitry Osipenko wrote:
> External email: Use caution opening links or attachments
> 26.04.2020 05:10, Dmitry Osipenko пишет:
> ...
>>> currently other Tegra host1x driver (drm) also does similar. Single
>>> module for all Tegra SoCs.
>> DRM driver has a proper separation of the sub-drivers where sub-driver
>> won't load on unsupported hardware. The tegra-video driver should do the
>> same, i.e. VI and CSI should be individual drivers (and not OPS). There
>> could be a some common core, but for now it's not obvious to me what
>> that core should be, maybe just the video.c.
> Maybe video.c csi.c vi.c could be moved into a separate module, somewhat
> like a common driver framework. Then the individual CSI/VI drivers will
> use those common helpers.. Just a quick thought.

structure of driver is based on prior feedback.

How about instead of re-structuring whole driver again, probably we can 
use conditional compatibles and also corresponding tegra210.o in 
Makefile based on ARCH_TEGRA?

#if defined(CONFIG_ARCH_TEGRA_210_SOC)
     { .compatible = "nvidia,tegra210-vi", .data = &tegra210_vi_soc },

Powered by blists - more mailing lists