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: <20190501165406.GI2938@tuxbook-pro>
Date:   Wed, 1 May 2019 09:54:06 -0700
From:   Bjorn Andersson <bjorn.andersson@...aro.org>
To:     Jeffrey Hugo <jhugo@...eaurora.org>
Cc:     mturquette@...libre.com, sboyd@...nel.org, agross@...nel.org,
        marc.w.gonzalez@...e.fr, david.brown@...aro.org,
        robh+dt@...nel.org, mark.rutland@....com,
        linux-arm-msm@...r.kernel.org, linux-clk@...r.kernel.org,
        linux-kernel@...r.kernel.org, devicetree@...r.kernel.org
Subject: Re: [PATCH v3 5/6] clk: qcom: Add MSM8998 Multimedia Clock
 Controller (MMCC) driver

On Wed 01 May 07:25 PDT 2019, Jeffrey Hugo wrote:

> On 4/30/2019 9:43 PM, Bjorn Andersson wrote:
> > On Tue 30 Apr 19:27 PDT 2019, Jeffrey Hugo wrote:
> > > +static const struct of_device_id mmcc_msm8998_match_table[] = {
> > > +	{ .compatible = "qcom,mmcc-msm8998" },
> > > +	{ }
> > > +};
> > > +MODULE_DEVICE_TABLE(of, mmcc_msm8998_match_table);
> > > +
> > > +static int mmcc_msm8998_probe(struct platform_device *pdev)
> > > +{
> > > +	struct regmap *regmap;
> > > +
> > 
> > Don't you want to wait for "xo" here as well?
> 
> No, I don't want to.  As far as I recall, Stephen would like to make a clear
> divide between clock providers, and clock consumers.  Since we have the uart
> issue in gcc, and gcc is pretty critical to the entire SoC, it seems like
> there is a reason (not sure I'd call it "good") to wait for xo there.
> 
> Here, I'm less confident in the reasoning.  mmcc is not really critical to
> the SoC, and everything it services is "optional".  If you have a headless
> system with no display output, you won't even need it.  On system where
> there is a display, I expect the realistic driver ordering to be that
> everything which consumes a mmcc clock to come up well after xo is
> available.
> 
> In short, seems like a bit of a kludge to maybe avoid an issue which doesn't
> seem like would happen.
> 

Okay, cool.

> > 
> > > +	regmap = qcom_cc_map(pdev, &mmcc_msm8998_desc);
> > > +	if (IS_ERR(regmap))
> > > +		return PTR_ERR(regmap);
> > > +
> > > +	return qcom_cc_really_probe(pdev, &mmcc_msm8998_desc, regmap);
> > > +}
> > [..]
> > > +MODULE_DESCRIPTION("QCOM MMCC MSM8998 Driver");
> > > +MODULE_LICENSE("GPL v2");
> > > +MODULE_ALIAS("platform:mmcc-msm8998");
> > 
> > MODULE_DEVICE_TABLE() will provide the alias for module auto loading, so
> > drop this.
> 
> Huh.  I did not know that.  Will put on the list to fixup.
> 

With this dropped (and your objection above) I think the patch looks
good.

Reviewed-by: Bjorn Andersson <bjorn.andersson@...aro.org>

Regards,
Bjorn

> > 
> > Regards,
> > Bjorn
> > 
> 
> 
> -- 
> Jeffrey Hugo
> Qualcomm Datacenter Technologies as an affiliate of Qualcomm Technologies,
> Inc.
> Qualcomm Technologies, Inc. is a member of the
> Code Aurora Forum, a Linux Foundation Collaborative Project.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ