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:   Fri, 20 Nov 2020 10:58:56 +0100
From:   Marek Szyprowski <m.szyprowski@...sung.com>
To:     Vinod Koul <vkoul@...nel.org>
Cc:     linux-samsung-soc@...r.kernel.org, linux-pci@...r.kernel.org,
        devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
        Jaehoon Chung <jh80.chung@...sung.com>,
        Jingoo Han <jingoohan1@...il.com>,
        Krzysztof Kozlowski <krzk@...nel.org>,
        Bjorn Helgaas <bhelgaas@...gle.com>,
        Lorenzo Pieralisi <lorenzo.pieralisi@....com>,
        Kishon Vijay Abraham I <kishon@...com>,
        Rob Herring <robh@...nel.org>,
        Bartlomiej Zolnierkiewicz <b.zolnierkie@...sung.com>
Subject: Re: [PATCH v4 4/5] phy: samsung: phy-exynos-pcie: rework driver to
 support Exynos5433 PCIe PHY

Hi Vinod,

On 20.11.2020 10:41, Vinod Koul wrote:
> On 13-11-20, 18:01, Marek Szyprowski wrote:
>> From: Jaehoon Chung <jh80.chung@...sung.com>
>>
>> Exynos5440 SoC support has been dropped since commit 8c83315da1cf ("ARM:
>> dts: exynos: Remove Exynos5440"). Rework this driver to support PCIe PHY
>> variant found in the Exynos5433 SoCs.
> I am expecting this series to go thru PCI tree, so:
>
> Acked-By: Vinod Koul <vkoul@...nel.org>

Frankly, the PHY driver can also go via PHY tree without causing any 
issue. The old driver is not used at all, so there is no runtime 
dependency. This will help avoiding the merge conflict: yesterday I've 
noticed that this patch conflicts with the commit 2f0c9fac3be6 ("phy: 
samsung: convert to devm_platform_ioremap_resource") in phy-next. The 
resolution is simple (use all the code from the new driver), but if 
needed I can resend the PHY driver after a rebase onto the current next 
tree.

Best regards

-- 
Marek Szyprowski, PhD
Samsung R&D Institute Poland

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ