Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1726743
| From | Evgeniy Polyakov <zbr@ioremap.net> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [PATCH v2] w1:fix byteorder of W1_READ_ROM id under big-endian cpu |
| Date | 2017-09-05 15:50 +0200 |
| Message-ID | <ummoN-3iq-7@gated-at.bofh.it> (permalink) |
| References | <ummoN-3iq-9@gated-at.bofh.it> <ummoN-3iq-11@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
Hi 28.08.2017, 12:25, "chen.lin5@zte.com.cn" <chen.lin5@zte.com.cn>: > Hi > > Q: > > But w1_reg_num has a different layout for be/le systems, isn't it enough? > > A: > > sure, it's right only under the assumption that 'rn' is a correct layout id. > > Here's my example in be system which I encounter before. > > buf[0] return from w1_read_8(dev) in code section2 will always be 'family:8', buf[0] store at the first byte of rn, then it will be transport to cb(dev, rn) in code section1, > > but it will be parsed to 'crc:8' of the struct w1_reg_num in be system, then there comes the wrong. Sorry, I do not understand. Do you mean that there is a difference between 2 ways to read ID content in w1_read_block() ? If it is the case, is it possible, that there is a bug in particular master implementation? There is a fair number of be devices in the tree already, and no one yet reported that there is an endian issue.
Back to linux.kernel | Previous | Next | Find similar | Unroll thread
Re: [PATCH v2] w1:fix byteorder of W1_READ_ROM id under big-endian cpu Evgeniy Polyakov <zbr@ioremap.net> - 2017-09-05 15:50 +0200
csiph-web