linux-kernel - Re: [PATCH] Changes in w1_therm.c and adding w1

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]

Date:   Thu, 23 Apr 2020 16:41:16 +0200
From:   Greg KH <greg@...ah.com>
To:     Akira Shimahara <akira215corp@...il.com>
Cc:     zbr@...emap.net, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] Changes in w1_therm.c and adding w1_therm.h

On Tue, Apr 14, 2020 at 07:02:48PM +0200, Akira Shimahara wrote:
> From: Akira SHIMAHARA <akira215corp@...il.com>
> 
> Patch for enhacement of w1_therm module. Added features :
>  - Bulk read : send one command for all the slaves 
>  		on the bus to trigger temperature conversion
>  - Optimized conversion time regarding to device resolution
>  - Dedicated sysfs entry for powering read,
>  		resolution set/get, eeprom save/restore
>  - Alarms settings and reading
>  - Code optimization to mitigate bus traffic
>  		(devices information are stored to avoid
> 		interrogating each device every-time)
> 
> Following sysfs entry are added :
>  - temperature (RO) : return the temperature in 1/1000°
>  - ext_power (RO) : return the power status of the device
>  - resolution (RW) : get or set the device resolution (supported devices)
>  - eeprom (WO) :trigger a save or restore to/from device EEPROM
>  - alarms (RW) : read or write TH and TL in the device RAM
>  - therm_bulk_read (RW) : Attribute at master level to trigger 
>  		bulk read and to survey the progress of devices conversions
>  - w1_slave has been kept for compatibility

You do not document any of these new sysfs files, why not?

Please add entries to Documentation/ABI/

And for the temp and other issues, shouldn't you use the "default"
kernel subsystems instead of creating your own api here?

thanks,

greg k-h