On 05-06-18, 18:26, Sricharan R wrote: > Hi Vinod, > > On 6/5/2018 11:49 AM, Vinod wrote: > > On 05-06-18, 11:12, Sricharan R wrote: > > > >> +config QCOM_Q6V5_WCSS > >> + tristate "Qualcomm Hexagon based WCSS Peripheral Image Loader" > >> + depends on OF && ARCH_QCOM > >> + depends on QCOM_SMEM > >> + depends on RPMSG_QCOM_SMD || (COMPILE_TEST && RPMSG_QCOM_SMD=n) > >> + depends on RPMSG_QCOM_GLINK_SMEM || RPMSG_QCOM_GLINK_SMEM=n > > > > Is there a reason why it depends on RPMSG_QCOM_GLINK_SMEM=n? What would > > happen if distro wants both this and RPMSG_QCOM_GLINK_SMEM > > > RPMSG_QCOM_GLINK_SMEM=n should be for the COMPILE_TEST. Probably that why would that be a limitation? I am more worried about RPMSG_QCOM_GLINK_SMEM=n being the condition here. In new drivers we should not typically have dependency on some symbol being not there > means that it should be corrected here and for ADSP, Q6V5_PIL as well. > Bjorn, is that correct ?, should it be, below ? > > depends on (RPMSG_QCOM_SMD || (COMPILE_TEST && RPMSG_QCOM_SMD=n)) || (RPMSG_QCOM_GLINK_SMEM || (COMPILE_TEST && RPMSG_QCOM_GLINK_SMEM=n)) that doesnt really sound good :( -- ~Vinod -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
