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: <503CB4DC.70507@c-s.fr>
Date:	Tue, 28 Aug 2012 14:09:00 +0200
From:	leroy christophe <christophe.leroy@....fr>
To:	Guenter Roeck <linux@...ck-us.net>
CC:	Jean Delvare <khali@...ux-fr.org>, linux-kernel@...r.kernel.org,
	lm-sensors@...sensors.org
Subject: Re: [PATCH] hwmon/lm70: adding support for NS LM74 chip


Le 26/08/2012 19:47, Guenter Roeck a écrit :
> On Thu, Aug 23, 2012 at 11:13:17AM -0700, Guenter Roeck wrote:
>> On Thu, Aug 23, 2012 at 05:32:12PM +0200, Christophe Leroy wrote:
>>> Hello,
>>>
>> Hi Christophe,
>>
> Hi again,
>
> [ ... ]
Hi Guenter,

>>>   
>>> -	/* 3-wire link (shared SI/SO) for LM70 */
>>> -	if (chip == LM70_CHIP_LM70 && !(spi->mode & SPI_3WIRE))
>>> +	/* 3-wire link (shared SI/SO) for LM70 and LM74 */
>>> +	if ((chip == LM70_CHIP_LM70 || chip == LM70_CHIP_LM74)
>>> +			&& !(spi->mode & SPI_3WIRE))
>> Ok for now, but I'll have to check this. The driver does not really write
>> anything to the chip, so it should be irrelevant which mode the SPI master
>> controller supports (MOSI does not have to be connected). Besides, from the
>> chip specification it looks like it is possible to connect the chip to a
>> standard SPI interface by adding a 10k resistor between MOSI and MISO.
>>
> After looking into the above, the proper change or fix is really to remove the
> above check for SPI_3WIRE entirely. The driver works perfectly fine if a LM70 is
> connected to a controller which does not explicitly support SPI_3WIRE; all that
> needs to be done is to connect MOSI through a resistor or not at all. This is,
> however, a board design decision, not a SPI master chip limitation.
Ok, then I'll prepare a patch for this.
>
> With that, we don't need to explicitly add any LM74 specific code to the driver,
> since the TMP121 code does the trick. All we need to do is to update the
> documentation, adding a note that LM74 is supported as well, and that it can be
> selected with 'tmp121'.
Yes, could be the solution, but I'm however a bit puzzled with doing 
this. The driver is originaly for NS LM70 component. Later on an 
extension has been added for TMP121 which is from a different family, 
even if compatible. Now we are talking about the LM74 which is in the 
same family as the original LM70. Therefore I would expect to be able to 
handle the LM74 directly from this driver, not through a tricky 
compatibility with the 'tmp121'. I would expect to handle it the other 
way round, ie consider the 'tmp121' as compatible with the LM74.
One of the reasons for that is that the driver reports the component ID 
through /sys/class/hwmon/hwmonX/name

As the 'tmp121' is already in the driver, it is not a good idea to 
replace it by LM74, however, I would prefer having the LM74 explicitly 
addressable by the driver, in additional to the 'tmp121'

I'm preparing a patch to include support for both LM71 and LM74 in the 
LM70 driver, in order to have a driver handling the complete family. Do 
you see a problem for that ? It would look strange that the LM70 driver 
handles LM70 and LM71, but LM74 through the compatible 'tmp121'

Nb, refer to your first answer, implementation for 'tmp122/124' is 
another story because those have a programmable precision, not a fixed one.
>
> Thanks,
> Guenter
>
Thanks
Christophe
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ