Received: by 2002:a25:7ec1:0:0:0:0:0 with SMTP id z184csp107443ybc; Mon, 18 Nov 2019 21:20:55 -0800 (PST) X-Google-Smtp-Source: APXvYqwcej7wi/L//nHfbTyN7MNtzQLKMuKZXQNatGMcDTKv1pwxblsDGkDK04dTWIqp8yflnFVH X-Received: by 2002:a17:906:604e:: with SMTP id p14mr3027479ejj.257.1574140855039; Mon, 18 Nov 2019 21:20:55 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1574140855; cv=none; d=google.com; s=arc-20160816; b=SCAYvtK8mPHJz2UNQ+mHb1aHBeydXQFvX4RNYY25vlw8cnIW2u0WpaOpANxHMWN1vO fYqPnrJp/3Wig4ljFVVWmEwsy5XiKktqw8DHv2FnQSw0BRF/nmwF18LCRdScRaC+R/LW gL4DLsn+vuWOVM/nFBDU0gE6Hp1onA+haJIKl7z770M9w1Sendtd9CbyrtdUjMUdDuXS 79ozMhqlnrF3jmEXQAPcFPnx/fmKIZn2/TwossbQaxMGrv5dJ741w9UlKLYrYIJ4b2g6 Yya+mf+LPsGNy+E/L3sW5Xp/+zwLNAXsHOWlKjCh/ZADUIvCvOajNFsp8aTr1L0SwkVg M/bg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:to:references:message-id :content-transfer-encoding:cc:date:in-reply-to:from:subject :mime-version; bh=euT6D62kkE/2abEkwenSmxKppxYpC+OpBUNQjcj+IsI=; b=a06XY56O9czGqjpzakmYQ4NfuLzI+UBuSaAj9RRx9ULurVkTEa9haAyFfSx0biBUfa TV1tbJ09NnmayrljMvOZ1UjWv2NNeHkUFWGgZiTGji9dIMdjRitAW05w8riK6uGreX3n xMucjozN48PHRMMqPDG8rTBsxIp4OByTejyhAcF4yYo2k4NHw7NcZRiZLn5U93P3PsYg IrWfr9OJqnobeDpu6hRmOk+B25dxsuQs74AYxJXjsqTtNfFMs2xR4EqHZH6Tf06mhy8j 1xOKDhSobT5xi70i3iPNLb/ujkjF6hWkq1QjiS21fcFDVB738lduNP1HHJ3eo2l7z0F1 4xUQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-bluetooth-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-bluetooth-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id q2si13114916eju.229.2019.11.18.21.20.29; Mon, 18 Nov 2019 21:20:55 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-bluetooth-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-bluetooth-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-bluetooth-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726132AbfKSFTa convert rfc822-to-8bit (ORCPT + 99 others); Tue, 19 Nov 2019 00:19:30 -0500 Received: from coyote.holtmann.net ([212.227.132.17]:53359 "EHLO mail.holtmann.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725280AbfKSFT3 (ORCPT ); Tue, 19 Nov 2019 00:19:29 -0500 Received: from marcel-macbook.holtmann.net (p4FF9F0D1.dip0.t-ipconnect.de [79.249.240.209]) by mail.holtmann.org (Postfix) with ESMTPSA id 47873CECED; Tue, 19 Nov 2019 06:28:35 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3601.0.10\)) Subject: Re: "local-[bd|mac]-address" inconsistency? From: Marcel Holtmann In-Reply-To: <20191118201551.GJ27773@google.com> Date: Tue, 19 Nov 2019 06:19:28 +0100 Cc: Andre Heider , linux-bluetooth@vger.kernel.org Content-Transfer-Encoding: 8BIT Message-Id: <5F04BF9F-B975-41BE-854B-1B11691A0321@holtmann.org> References: <57775d51-7de2-a32c-8b23-aba611483f51@gmail.com> <20191118201551.GJ27773@google.com> To: Matthias Kaehlcke X-Mailer: Apple Mail (2.3601.0.10) Sender: linux-bluetooth-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-bluetooth@vger.kernel.org Hi Matthias, >> when passing both addresses through device-tree in the same way: >> $ hexdump /proc/device-tree/soc/ethernet@5020000/local-mac-address >> 0000000 0702 3d96 53d4 >> >> $ hexdump /proc/device-tree/soc/serial@5000400/bluetooth/local-bd-address >> 0000000 0703 3d96 53d4 >> >> I get this for eth (which is consistent with u-boot): >> link/ether 02:07:96:3d:d4:53 >> >> But for bt it's in reverse order: >> Controller 53:D4:3D:96:07:03 >> >> Is this intended? > > Kind of. > > In both cases the address is specified in the binary format used by BT/NW > stack. > > When BT addresses are printed they are converted from LSB to MSB. > >> Do I really have to pass the bdaddr from u-boot in another way? > > One could make a case that we don't care what the 'internal' format is and > that the BD_ADDR should be specified in MSB format in the DT, and the kernel > would be in charge of converting it to LSB. However I fear it is too late to > consider a change at this point, since the binding has been in the kernel for > 6 months with the current format and existing devices may rely on it. we used a different property name for reason. Even while BD_ADDR is allocated from an OUI space, it has nothing in common with a MAC address. Regards Marcel