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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Thu, 12 Dec 2019 05:17:10 +0300
From:   Dmitry Osipenko <digetx@...il.com>
To:     Mark Brown <broonie@...nel.org>
Cc:     robh+dt@...nel.org, mark.rutland@....com,
        Sowjanya Komatineni <skomatineni@...dia.com>,
        thierry.reding@...il.com, jonathanh@...dia.com,
        mperttunen@...dia.com, gregkh@...uxfoundation.org,
        sboyd@...nel.org, tglx@...utronix.de, allison@...utok.net,
        pdeschrijver@...dia.com, pgaikwad@...dia.com,
        mturquette@...libre.com, horms+renesas@...ge.net.au,
        Jisheng.Zhang@...aptics.com, krzk@...nel.org, arnd@...db.de,
        spujar@...dia.com, josephl@...dia.com, vidyas@...dia.com,
        daniel.lezcano@...aro.org, mmaddireddy@...dia.com,
        markz@...dia.com, devicetree@...r.kernel.org,
        linux-clk@...r.kernel.org, linux-tegra@...r.kernel.org,
        linux-kernel@...r.kernel.org, lgirdwood@...il.com, perex@...ex.cz,
        tiwai@...e.com, alexios.zavras@...el.com,
        alsa-devel@...a-project.org
Subject: Re: [PATCH v3 09/15] ASoC: tegra: Add fallback for audio mclk

10.12.2019 21:59, Mark Brown пишет:
> On Tue, Dec 10, 2019 at 09:24:43PM +0300, Dmitry Osipenko wrote:
> 
>> In some cases it could be painful to maintain device-tree compatibility
>> for platforms like NVIDIA Tegra SoCs because hardware wasn't modeled
>> correctly from the start.
> 
>> I agree that people should use relevant device-trees. It's quite a lot
>> of hassle to care about compatibility for platforms that are permanently
>> in a development state. It could be more reasonable to go through the
>> pain if kernel required a full-featured device tree for every SoC from
>> the start.
> 
> We absolutely should support the newer kernel with older device tree
> case, what's less clear to me is the new device tree with old kernel
> which is applying LTS updates case.  That does seem incredibly
> specialist - I'd honestly never heard of people doing that before this
> thread.
> 

There was a precedent in the past [1].

[1] https://lkml.org/lkml/2018/8/20/497

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ