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] [day] [month] [year] [list]
Date:   Wed, 28 Dec 2016 14:25:29 +0900
From:   Jaehoon Chung <>
To:     Pankaj Dubey <>
Cc:     Alim Akhtar <>,,
        linux-samsung-soc <>,
        Krzysztof Kozlowski <>,
        Kukjin Kim <>,
        Jingoo Han <>,
        Bjorn Helgaas <>,,
        Niyas Ahmed S T <>,
        CPGS <>
Subject: Re: [PATCH] PCI: exynos: refactor exynos pcie driver

Hi Pankaj,

On 12/28/2016 12:10 PM, Pankaj Dubey wrote:
> Hi Jaehoon,
> On 27 December 2016 at 15:48, Jaehoon Chung <> wrote:
>> Dear Alim,
>> On 12/27/2016 03:34 PM, Alim Akhtar wrote:
>>> Hi Jaehoon,
>> [snip]
>>>> Ah. Right..And i'm doing the refactoring to reuse the current pci-exynos.c.
>>> There is a nice refactoring patch posted by Pankaj recently @
>>> I would suggest you to rebase your work on this top.
>> Well, i don't think so. Pankaj's patch might be good way..but i can't agree about a few point.
>> If based on Pankaj's patch, it's more complex..
>> why put the ops callback for getting clock and mem resource?
> I think I replied reason behind this in reply to Jingoo. Well I will
> explain with some example here. Current exynos_pcie struct contains
> all mem, phy, gpio and clock resources in one place and this driver is
> supported only for Exynos5440. Until this it was fine. As Jingoo
> mentioned when he up streamed this driver, generic phy framework was
> not ready so he used phy_base along with some additional phy related
> sfr base in pcie driver itself.
> Moving ahead for adding support for PCIe module on Exynos7, Exynos5433
> or other existing Exynos (non-mainlined) and some of upcoming SoC
> seeing the differences in these resources (mem, clk, regmap handles,
> gpio etc.) we will endup adding following kind of code in probe to get
> these resources from DT
> if (of_machine_is_compatible(exynos7420)) {
>     /* get certain mem resources */
>     /* get certain clock resources */
>     /* get certain regmap handle resources if required */
> } else if (of_machine_is_compatble(exynos5433)) {
>     /* get certain but may be different mem resources */
>     /* get certain clock resources */
>     /* get certain regmap handle resources if required */
> } else if (of_machine_is_compatible(exynosMMMM)) {
>   //may be something else
> }
> for giving real example, exynos7420 does not uses only two clocks
> "bus", "pcie_bus" there are other clocks required to be taken care in
> driver. It also need to take care of pmu regmap handle and sysreg
> regmap handle.
> So if we keep exynos_pcie as only struct then we will keep adding all
> these resources in only one struct making it more complex. Also
> resource initialization part will become complex. For the same reason
> I decided to separate these rather keeping them in single struct. This
> is very obvious design used in many drivers (samsung or other
> vendors). Just to give one more example see pcie-qcom.c where they
> also have different clocks and it is managed in same fashion.
>> If PHY generic framework is used, it's unnecessary. because it needs to get elbi and dbi resources.
> Surely elbi and dbi are fixed, but as we already have one example of
> exynos5440 which used block_base (additional SFR base other than phy
> base), I can see some of existing and upcoming SoC will need more SFR
> base than these two, it all depends on how h/w engineers design these
> modules and distribute SFR access.
>> clock resources("pcie" and "pcie_bus") are general things.
> With current Exynos SoCs which have PCIe hardware modules I can see
> this will not remain uniform across various SoCs, some of them require
> more clocks to be handled by PCIe driver.
>> If Pankaj's patch is applied, also need to make the exynos5433_pcie_* callback functions?
>> It doesn't make sense.
> Adding exynos5433_pcie_ops struct and hooks specific to the exynos5433
> is a small overhead compared to the flexibility it provides. This will
> make current driver flexibility with less
> of_machine_is_compatible(...) kind of conditional statement, less
> complex exynos_pcie struct.
> For the hooks of exynos_pcie_ops also if two different Exynos SoC
> shares same mem, clock and other resources the actual hooks will point
> to same functions so no overhead of implementing these for each SoC.
> Only separate implementation will be required if they differ in these
> resources. This approach also very common across various drivers
> nothing special here.
> I hope I am clear in explaining the intention and pros and cons of
> both approaches.

Yep, clear..Well, My opinion is also my preference.
(Maybe i think that you also know a little what my meaning is. )
There is no objection that we want to support the other Exynos variants. :)

This discussion is for how to support better than now.
So I will send the patch based on your patch...then we can discuss more. how about?

I think we can maintain more better than now.
As you already know, current exynos-pcie has to modify for supporting other.

>> I want to know maintainer's opinion..we can just touch a little for supporting All Exynos SoCs.
> I also have same intention but design should be flexible to adopt
> future SoC at least some of them which we are seeing will be supported
> soon and we can see the differences.

Sure, I will wait for your patch.
And You can also check my patches.. :)

Best Regards,
Jaehoon Chung

> Thanks,
> Pankaj Dubey
>> Best Regards,
>> Jaehoon Chung
>>>> Maybe..Today or Tomorrow..I will send the patches..At that time, could you also check them?
>>>> Any comments might be helpful to me! :)
>>> Will wait for you patches :-)
>>>> Best Regards,
>>>> Jaehoon Chung
>> [snip]
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
>> the body of a message to
>> More majordomo info at
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
> the body of a message to
> More majordomo info at

Powered by blists - more mailing lists