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: <20160810031021.GZ25053@mtj.duckdns.org>
Date:	Tue, 9 Aug 2016 23:10:21 -0400
From:	Tejun Heo <tj@...nel.org>
To:	Fabien Lahoudere <fabien.lahoudere@...labora.co.uk>
Cc:	Csaba Kertesz <csaba.kertesz@...cit.fi>,
	"open list:LIBATA SUBSYSTEM (Serial and Parallel ATA drivers)" 
	<linux-ide@...r.kernel.org>,
	open list <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 1/1] Add CPU temperature sensor support for i.MX53

Hello, Fabien.

Is $SUBJ right?  CPU temperature?

On Wed, Aug 03, 2016 at 09:35:56AM +0200, Fabien Lahoudere wrote:
> From: Csaba Kertesz <csaba.kertesz@...cit.fi>
> 
> The original patch was made by Richard Zhu for kernel 2.6.x:
> 
> ENGR00134041-MX53-Add-the-SATA-AHCI-temperature-monitor.patch
> 
> The old source code was migrated to the new kernel 3.x. The concept of
> value reading was changed a bit:
> 
> 1. The new 3.x kernel functions (imx_phy_reg_read, imx_phy_reg_write) use
>    16 bit registers while the original implementation used 32 bit integers
>    for this purpose.

The description seems pretty dated.

> 2. The communication is guarded against infinite loop to give up a certain
>    register reading after 100000 attempts. This number comes from the
>    original implementation. A new variable (read_attempt) is introduced to
>    count the trials.

That's a very high number for a retry counter.

> +/* SATA AHCI temperature monitor */
> +static ssize_t sata_ahci_current_tmp(struct device *dev, struct device_attribute

Abbreviating temperature to tmp probably isn't the best idea.

Patch looks good to me except for the above nits; however, I wonder
whether it being a one-off sysfs attribute is the right approach.
Don't we have subsystems and interfaces for things like temperature
readings?

Thanks.

-- 
tejun

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ