lkml.org 
[lkml]   [2020]   [Jun]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [PATCH v8 1/3] iommu/arm-smmu: add NVIDIA implementation for dual ARM MMU-500 usage
    From
    Date

    On 30/06/2020 17:32, Jon Hunter wrote:
    > On 30/06/2020 17:23, Krishna Reddy wrote:
    >>>> +struct arm_smmu_device *nvidia_smmu_impl_init(struct arm_smmu_device
    >>>> +*smmu) {
    >>>> + unsigned int i;
    >> ....
    >>>> + for (i = 1; i < MAX_SMMU_INSTANCES; i++) {
    >>>> + struct resource *res;
    >>>> +
    >>>> + res = platform_get_resource(pdev, IORESOURCE_MEM, i);
    >>>> + if (!res)
    >>>> + break;
    >>
    >>> Currently this driver is only supported for Tegra194 which I understand has 3 SMMUs. Therefore, I don't feel that we should fail silently here, I think it is better to return an error if all 3 cannot be initialised.
    >>
    >> Initialization of all the three SMMU instances is not necessary here.
    >
    > That is not what I am saying.
    >
    >> The driver can work with all the possible number of instances 1, 2 and 3 based on the DT config though it doesn't make much sense to use it with 1 instance.
    >> There is no silent failure here from driver point of view. If there is misconfig in DT, SMMU faults would catch issues.
    >
    > I disagree and you should return a proper error here.

    OK, well I see what you are saying, but if we intended to support all 3
    for Tegra194, then we should ensure all 3 are initialised correctly.

    My concern here is testing, because when things break in upstream I am
    usually the one that tracks it down. Not having clear warning/error
    messages when something is not initialised as expected makes it harder.

    It would be better to query the number of SMMUs populated in device-tree
    and then ensure that all are initialised correctly.

    Jon

    --
    nvpublic

    \
     
     \ /
      Last update: 2020-06-30 18:44    [W:3.287 / U:0.024 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site