linux-kernel - Re: [PATCH v1 1/2] clocksource/drivers/exynos_mct_v2: introduce Exynos MCT version 2 driver for next Exynos SoC

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]

Message-ID: <20211026104518.GA40630@perf>
Date:   Tue, 26 Oct 2021 19:45:18 +0900
From:   Youngmin Nam <youngmin.nam@...sung.com>
To:     Krzysztof Kozlowski <krzysztof.kozlowski@...onical.com>
Cc:     daniel.lezcano@...aro.org, tglx@...utronix.de,
        linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
        linux-samsung-soc@...r.kernel.org, pullip.cho@...sung.com,
        hoony.yu@...sung.com, hajun.sung@...sung.com,
        myung-su.cha@...sung.com, kgene@...nel.org
Subject: Re: [PATCH v1 1/2] clocksource/drivers/exynos_mct_v2: introduce
 Exynos MCT version 2 driver for next Exynos SoC

On Tue, Oct 26, 2021 at 09:10:28AM +0200, Krzysztof Kozlowski wrote:
> On 26/10/2021 03:47, Youngmin Nam wrote:
> >> If everyone added a new driver to avoid integrating with existing code,
> >> we would have huge kernel with thousands of duplicated solutions. The
> >> kernel also would be unmaintained.
> >>
> >> Such arguments were brought before several times - "I don't want to
> >> integrating with existing code", "My use case is different", "I would
> >> need to test the other cases", "It's complicated for me".
> >>
> >> Instead of pushing a new vendor driver you should integrate it with
> >> existing code.
> >>
> > Let me ask you one question.
> > If we maintain as one driver, how can people who don't have the new MCT test the new driver?
> 
> I assume you talk about a case when someone else later changes something
> in the driver. Such person doesn't necessarily have to test it. The same
> as in all other cases (Exynos MCT is not special here): just ask for
> testing on platform one doesn't have.
> 
> Even if you submit this as separate driver, there is the exact same
> problem. People will change the MCTv2 driver without access to hardware.
> 
Yes, I can test the new MCT driver if someone ask for testing after modifying the new driver.
But in this case, we don't need to test the previous MCT driver. We have only to test the new MCT driver.
> None of these differ for Exynos MCT from other drivers, e.g. mentioned
> Samsung PMIC drivers, recently modified (by Will and Sam) the SoC clock
> drivers or the ChipID drivers (changed by Chanho).
>From HW point of view, the previous MCT is almost 10-year-old IP without any major change and
it will not be used on next new Exynos SoC.
MCTv2 is the totally newly designed IP and it will replace the Exynos system timer.
Device driver would be dependent with H/W. We are going to apply a lot of changes for this new MCT.
For maintenance, I think we should separate the new MCT driver for maintenance.

> 
> 
> 
> Best regards,
> Krzysztof
>