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] [day] [month] [year] [list]

Message-ID: <55D271D4.6020903@codeaurora.org>
Date:	Mon, 17 Aug 2015 17:44:20 -0600
From:	Sagar Dharia <sdharia@...eaurora.org>
To:	Mark Brown <broonie@...nel.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 8/14/2015 12:31 PM, Mark Brown wrote:
> 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.

I agree, I will move this to the framework.

Thanks
Sagar

>
>> +	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.


-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/