Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1201934 > unrolled thread

Re: [PATCH 2/3] iio: temperature: add max6675 thermocouple converter driver

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH 2/3] iio: temperature: add max6675 thermocouple converter  driver Matt Porter <mporter@konsulko.com> - 2015-08-06 19:40 +0200
    Re: [PATCH 2/3] iio: temperature: add max6675 thermocouple converter  driver Jonathan Cameron <jic23@kernel.org> - 2015-08-08 13:40 +0200
      Re: [PATCH 2/3] iio: temperature: add max6675 thermocouple converter  driver Matt Porter <mporter@konsulko.com> - 2015-08-20 02:30 +0200
        Re: [PATCH 2/3] iio: temperature: add max6675 thermocouple converter  driver Jonathan Cameron <jic23@kernel.org> - 2015-08-23 17:50 +0200

#1201934 — Re: [PATCH 2/3] iio: temperature: add max6675 thermocouple converter driver

On Mon, Aug 03, 2015 at 11:26:12PM +0200, Peter Meerwald wrote:
> On Mon, 3 Aug 2015, Matt Porter wrote:

...

> > +static int max6675_read(struct max6675_state *st, int *val)
> > +{
> > +	int ret;
> > +
> > +	ret = spi_read(st->spi, val, 2);
> > +	if (ret < 0)
> > +		return ret;
> > +
> > +	/* Temperature is bits 14..3 */
> > +	*val = (*val >> 3) & 0xfff;
> 
> what about endianness conversion?
> use be16_to_cpu()

Apologies, I spoke before engaging the brain on my first reply to this
As specified by the SPI subsystem docs, SPI buffers are always stored
in native endian order. There is no need for endianness conversion here.

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

[toc] | [next] | [standalone]

#1203252

On 06/08/15 18:38, Matt Porter wrote:
> On Mon, Aug 03, 2015 at 11:26:12PM +0200, Peter Meerwald wrote:
>> On Mon, 3 Aug 2015, Matt Porter wrote:
> 
> ...
> 
>>> +static int max6675_read(struct max6675_state *st, int *val)
>>> +{
>>> +	int ret;
>>> +
>>> +	ret = spi_read(st->spi, val, 2);
>>> +	if (ret < 0)
>>> +		return ret;
>>> +
>>> +	/* Temperature is bits 14..3 */
>>> +	*val = (*val >> 3) & 0xfff;
>>
>> what about endianness conversion?
>> use be16_to_cpu()
> 
> Apologies, I spoke before engaging the brain on my first reply to this
> As specified by the SPI subsystem docs, SPI buffers are always stored
> in native endian order. There is no need for endianness conversion here.
First of all, which doc say this?
Secondly how does SPI know the endianness of the sensor which is what
actually matters here?  I2C can in theory make these guarantees as there
is an expected byte order on the wire (even if quite a few drivers don't
conform to the spec anyway). No such guarantee can exist for SPI.

Jonathan


> 
> -Matt
> --
> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

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

[toc] | [prev] | [next] | [standalone]

#1210097

On Sat, Aug 08, 2015 at 12:39:40PM +0100, Jonathan Cameron wrote:
> On 06/08/15 18:38, Matt Porter wrote:
> > On Mon, Aug 03, 2015 at 11:26:12PM +0200, Peter Meerwald wrote:
> >> On Mon, 3 Aug 2015, Matt Porter wrote:
> > 
> > ...
> > 
> >>> +static int max6675_read(struct max6675_state *st, int *val)
> >>> +{
> >>> +	int ret;
> >>> +
> >>> +	ret = spi_read(st->spi, val, 2);
> >>> +	if (ret < 0)
> >>> +		return ret;
> >>> +
> >>> +	/* Temperature is bits 14..3 */
> >>> +	*val = (*val >> 3) & 0xfff;
> >>
> >> what about endianness conversion?
> >> use be16_to_cpu()
> > 
> > Apologies, I spoke before engaging the brain on my first reply to this
> > As specified by the SPI subsystem docs, SPI buffers are always stored
> > in native endian order. There is no need for endianness conversion here.
> First of all, which doc say this?
> Secondly how does SPI know the endianness of the sensor which is what
> actually matters here?  I2C can in theory make these guarantees as there
> is an expected byte order on the wire (even if quite a few drivers don't
> conform to the spec anyway). No such guarantee can exist for SPI.

include/linux/spi/spi.h:

 * In-memory data values are always in native CPU byte order, translated
 * from the wire byte order (big-endian except with SPI_LSB_FIRST).  So
 * for example when bits_per_word is sixteen, buffers are 2N bytes long
 * (@len = 2N) and hold N sixteen bit words in CPU byte order.

So, as you mention, there's no standardized byte order but it's
controlled with the per transfer flag and big endian by default.

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

[toc] | [prev] | [next] | [standalone]

#1211641

On 20/08/15 01:23, Matt Porter wrote:
> On Sat, Aug 08, 2015 at 12:39:40PM +0100, Jonathan Cameron wrote:
>> On 06/08/15 18:38, Matt Porter wrote:
>>> On Mon, Aug 03, 2015 at 11:26:12PM +0200, Peter Meerwald wrote:
>>>> On Mon, 3 Aug 2015, Matt Porter wrote:
>>>
>>> ...
>>>
>>>>> +static int max6675_read(struct max6675_state *st, int *val)
>>>>> +{
>>>>> +	int ret;
>>>>> +
>>>>> +	ret = spi_read(st->spi, val, 2);
>>>>> +	if (ret < 0)
>>>>> +		return ret;
>>>>> +
>>>>> +	/* Temperature is bits 14..3 */
>>>>> +	*val = (*val >> 3) & 0xfff;
>>>>
>>>> what about endianness conversion?
>>>> use be16_to_cpu()
>>>
>>> Apologies, I spoke before engaging the brain on my first reply to this
>>> As specified by the SPI subsystem docs, SPI buffers are always stored
>>> in native endian order. There is no need for endianness conversion here.
>> First of all, which doc say this?
>> Secondly how does SPI know the endianness of the sensor which is what
>> actually matters here?  I2C can in theory make these guarantees as there
>> is an expected byte order on the wire (even if quite a few drivers don't
>> conform to the spec anyway). No such guarantee can exist for SPI.
> 
> include/linux/spi/spi.h:
> 
>  * In-memory data values are always in native CPU byte order, translated
>  * from the wire byte order (big-endian except with SPI_LSB_FIRST).  So
>  * for example when bits_per_word is sixteen, buffers are 2N bytes long
>  * (@len = 2N) and hold N sixteen bit words in CPU byte order.
> 
> So, as you mention, there's no standardized byte order but it's
> controlled with the per transfer flag and big endian by default.
> 
Thanks, I'd never picked up on that before!

Jonathan
> 

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

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web