linux-kernel - Re: [PATCH V3 4/6] slim: qcom: Add Qualcomm Slimbus controller driver

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: <20150814183106.GE10748@sirena.org.uk>
Date:	Fri, 14 Aug 2015 19:31:06 +0100
From:	Mark Brown <broonie@...nel.org>
To:	Sagar Dharia <sdharia@...eaurora.org>
Cc:	gregkh@...uxfoundation.org, bp@...e.de, poeschel@...onage.de,
	treding@...dia.com, gong.chen@...ux.intel.com,
	andreas.noever@...il.com, alan@...ux.intel.com,
	mathieu.poirier@...aro.org, daniel@...ll.ch, oded.gabbay@....com,
	jkosina@...e.cz, sharon.dvir1@...l.huji.ac.il, joe@...ches.com,
	davem@...emloft.net, james.hogan@...tec.com,
	michael.opdenacker@...e-electrons.com, daniel.thompson@...aro.org,
	robh+dt@...nel.org, pawel.moll@....com, mark.rutland@....com,
	ijc+devicetree@...lion.org.uk, galak@...eaurora.org,
	devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
	kheitke@...ience.com, mlocke@...eaurora.org, agross@...eaurora.org,
	linux-arm-msm@...r.kernel.org
Subject: Re: [PATCH V3 4/6] slim: qcom: Add Qualcomm Slimbus controller driver

On Mon, Aug 03, 2015 at 12:59:48AM -0600, Sagar Dharia wrote:

> +/**
> + * Qualcomm slimbus controller may experience interference on the lines
> + * causing some early messages (e.g. logical-address assignment) to be
> + * NACKed. Retry after sometime (typically 1 superframe)
> + */
> +static void msm_slim_wait_retry(struct msm_slim_ctrl *dev)
> +{
> +	int msec_per_frm = 0;
> +	int sfr_per_sec;
> +
> +	/* Wait for 1 superframe, or default time and then retry */
> +	sfr_per_sec = dev->framer.superfreq /
> +			(1 << (SLIM_MAX_CLK_GEAR - dev->ctrl.clkgear));
> +	if (sfr_per_sec)
> +		msec_per_frm = MSEC_PER_SEC / sfr_per_sec;
> +	if (msec_per_frm < DEF_RETRY_MS)
> +		msec_per_frm = DEF_RETRY_MS;
> +	msleep(msec_per_frm);
> +}

This looks like logic which might be usefully pulled out to the
framework - I bet this isn't an issue unique to your controller, the
users (well, one user) look like cases where the bus might be
destabilised by devices powering up and trying to enumerate under less
than ideal electrical conditions which seems like something that's
likely to affect other hardware.

> +	rclk = devm_clk_get(&pdev->dev, "core_clk");
> +	if (IS_ERR(rclk)) {
> +		/* unlikely that this is probe-defer */
> +		dev_err(&pdev->dev, "rclk get failed:%ld\n", PTR_ERR(rclk));
> +		devm_clk_put(&pdev->dev, hclk);

No need to call devm_clk_put() explicitly in your probe function.

Download attachment "signature.asc" of type "application/pgp-signature" (474 bytes)