From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751864AbdIENr0 (ORCPT ); Tue, 5 Sep 2017 09:47:26 -0400 Received: from forward104j.mail.yandex.net ([5.45.198.247]:33892 "EHLO forward104j.mail.yandex.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751332AbdIENrX (ORCPT ); Tue, 5 Sep 2017 09:47:23 -0400 X-Greylist: delayed 479 seconds by postgrey-1.27 at vger.kernel.org; Tue, 05 Sep 2017 09:47:22 EDT Authentication-Results: mxback14g.mail.yandex.net; dkim=pass header.i=@yandex.ru From: Evgeniy Polyakov Envelope-From: drustafa@yandex.ru To: "chen.lin5@zte.com.cn" Cc: "linux-kernel@vger.kernel.org" , "jiang.biao2@zte.com.cn" In-Reply-To: <201708281725129358346@zte.com.cn> References: 1500451680-17885-1-git-send-email-chen.lin5@zte.com.cn,1206341503819410@web4g.yandex.ru <201708281725129358346@zte.com.cn> Subject: Re: [PATCH v2] w1:fix byteorder of W1_READ_ROM id under big-endian cpu MIME-Version: 1.0 Message-Id: <265491504618761@web52g.yandex.ru> X-Mailer: Yamail [ http://yandex.ru ] 5.0 Date: Tue, 05 Sep 2017 16:39:21 +0300 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=utf-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi 28.08.2017, 12:25, "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.