linux-kernel - Re: [PATCH v1 2/4] mhi_bus: controller: MHI support for QCOM modems

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: <c6415ef5-7317-e0b3-2029-8bdae053c665@codeaurora.org>
Date:   Sat, 28 Apr 2018 08:40:36 -0700
From:   Sujeev Dias <sdias@...eaurora.org>
To:     Arnd Bergmann <arnd@...db.de>
Cc:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        linux-arm-msm@...r.kernel.org, Tony Truong <truong@...eaurora.org>
Subject: Re: [PATCH v1 2/4] mhi_bus: controller: MHI support for QCOM modems



On 04/27/2018 04:32 AM, Arnd Bergmann wrote:
> On Fri, Apr 27, 2018 at 4:23 AM, Sujeev Dias <sdias@...eaurora.org> wrote:
>> QCOM PCIe based modems uses MHI as the communication protocol.
>> MHI control driver is the bus master for such modems. As the bus
>> master driver, it oversees power management operations
>> such as suspend, resume, powering on and off the device.
>>
>> +- compatible
>> +  Usage: required
>> +  Value type: <string>
>> +  Definition: "qcom,mhi"
>> +
>> +- qcom,pci-dev-id
>> +  Usage: optional
>> +  Value type: <u32>
>> +  Definition: PCIe device id of external modem to bind. If not set, any
>> +       device is compatible with this node.
>> +
>> +- qcom,pci-domain
>> +  Usage: required
>> +  Value type: <u32>
>> +  Definition: PCIe root complex external modem connected to
>> +
>> +- qcom,pci-bus
>> +  Usage: required
>> +  Value type: <u32>
>> +  Definition: PCIe bus external modem connected to
>> +
>> +- qcom,pci-slot
>> +  Usage: required
>> +  Value type: <u32>
>> +  Definition: PCIe slot as assigned by pci framework to external modem
> These don't seem to make any sense: You seem to have access to
> a regular pci_device already, so why do you need to duplicate the
> information about it in DT?
>
I will remove the platform device, original hardware design we had a 
complicated power on
sequence that require platform device to come up first and follow a 
strict power on sequence to power on modem
before pci device can enumerate.  I stored the BDF in DT to correlate 
the platform device with pci device. platform device
is no longer needed so I can remove it.
>> +- qcom,smmu-cfg
>> +  Usage: required
>> +  Value type: <u32>
>> +  Definition: Required SMMU configuration bitmask for PCIe bus.
>> +       BIT mask:
>> +       BIT(0) : Attach address mapping to endpoint device
>> +       BIT(1) : Set attribute S1_BYPASS
>> +       BIT(2) : Set attribute FAST
>> +       BIT(3) : Set attribute ATOMIC
>> +       BIT(4) : Set attribute FORCE_COHERENT
>> +
>> +- qcom,addr-win
>> +  Usage: required if SMMU S1 translation is enabled
>> +  Value type: Array of <u64>
>> +  Definition: Pair of values describing iova start and stop address
> Why do you need these? Can't that be handled by the PCI
> layer?
I will move this to end point DT.  PCIe end point driver does the iommu 
configuration
>> +- qcom,msm-bus,name
>> +  Usage: required
>> +  Value type: <string>
>> +  Definition: string representing the bus scale client name to register
> This probably belongs into a separate binding for the bus
> scale driver, right?
Yes, this is for qcom bus scale driver which I don't think is upstreamed 
yet. Will confirm.
>> +static struct pci_driver mhi_pcie_driver;
> Please try to reorder the symbols to avoid forward declarations.
>
>> +static int mhi_platform_probe(struct platform_device *pdev)
>> +{
>> +       struct mhi_controller *mhi_cntrl;
>> +       struct mhi_dev *mhi_dev;
>> +       struct device_node *of_node = pdev->dev.of_node;
>> +       u64 addr_win[2];
>> +       int ret;
>> +
>> +       if (!of_node)
>> +               return -ENODEV;
>> +
>> +       mhi_cntrl = mhi_alloc_controller(sizeof(*mhi_dev));
>> +       if (!mhi_cntrl)
>> +               return -ENOMEM;
>> +
>> +       mhi_dev = mhi_controller_get_devdata(mhi_cntrl);
>> +
>> +       /* get pci bus topology for this node */
>> +       ret = of_property_read_u32(of_node, "qcom,pci-dev-id",
>> +                                  &mhi_cntrl->dev_id);
>> +       if (ret)
>> +               mhi_cntrl->dev_id = PCI_ANY_ID;
>> +
>> +       ret = of_property_read_u32(of_node, "qcom,pci-domain",
>> +                                  &mhi_cntrl->domain);
>> +       if (ret)
>> +               goto error_probe;
>> +
>> +       ret = of_property_read_u32(of_node, "qcom,pci-bus", &mhi_cntrl->bus);
>> +       if (ret)
>> +               goto error_probe;
>> +
>> +       ret = of_property_read_u32(of_node, "qcom,pci-slot", &mhi_cntrl->slot);
>> +       if (ret)
>> +               goto error_probe;
> Please explain what you are trying to do here, why do you register
> two device drivers? It looks like they both refer to the same
> hardware, so why isn't it sufficient to have the pci_driver?
As I explained earlier, it's now. Original hardware design we had 
chicken egg situation where
some driver has to come up and power on device before pcie enumeration 
can take place.

>
>         Arnd
> --
> To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
> the body of a message to majordomo@...r.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
Thanks again
Sujeev

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project