linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: leroy christophe <christophe.leroy@c-s.fr>
To: Guenter Roeck <linux@roeck-us.net>
Cc: Jean Delvare <khali@linux-fr.org>,
	linux-kernel@vger.kernel.org, lm-sensors@lm-sensors.org
Subject: Re: [PATCH] hwmon/lm70: adding support for NS LM74 chip
Date: Tue, 28 Aug 2012 14:09:00 +0200	[thread overview]
Message-ID: <503CB4DC.70507@c-s.fr> (raw)
In-Reply-To: <20120826174721.GA32334@roeck-us.net>


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

  reply	other threads:[~2012-08-28 12:09 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-08-23 15:32 [PATCH] hwmon/lm70: adding support for NS LM74 chip Christophe Leroy
2012-08-23 18:13 ` Guenter Roeck
2012-08-26 17:47   ` Guenter Roeck
2012-08-28 12:09     ` leroy christophe [this message]
2012-08-28 14:54       ` Guenter Roeck

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=503CB4DC.70507@c-s.fr \
    --to=christophe.leroy@c-s.fr \
    --cc=khali@linux-fr.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@roeck-us.net \
    --cc=lm-sensors@lm-sensors.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).