From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.9 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id ED5C1C4743E for ; Tue, 8 Jun 2021 09:54:00 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id CD9BC611BD for ; Tue, 8 Jun 2021 09:54:00 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231321AbhFHJzw (ORCPT ); Tue, 8 Jun 2021 05:55:52 -0400 Received: from mail.kernel.org ([198.145.29.99]:42628 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231181AbhFHJzv (ORCPT ); Tue, 8 Jun 2021 05:55:51 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id 31B2E61008; Tue, 8 Jun 2021 09:53:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1623146038; bh=VYaAViHh1Py6v8pf+R+jIxsvaqWuJjCa07F+MAIE8WU=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=HNp23tvGHNeTqJa2VK3DVBNpBXaUiicbZVCcHkUSmamieuUG41mrYpxYe5iNu+87L Z8O+7vVHDMd8HJyskHqvprv4spkQz0MT6Y+ieeHTnAFDCbrHc8/XnFlL+ezljn081V Z8LIGvrbt93hNub/Ee1UfGHPlpG3wIYnKU06KUOY= Date: Tue, 8 Jun 2021 11:53:56 +0200 From: Greg Kroah-Hartman To: =?utf-8?B?SmnFmcOt?= Prchal Cc: devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, Rob Herring , Christian Eggers , Arnd Bergmann Subject: Re: [PATCH v7 4/5] nvmem: eeprom: at25: export FRAM serial num Message-ID: References: <20210607122640.143582-1-jiri.prchal@aksignal.cz> <20210607122640.143582-5-jiri.prchal@aksignal.cz> <56f088fe-8db2-54d4-bef3-72e5f893a414@aksignal.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jun 08, 2021 at 11:45:56AM +0200, Jiří Prchal wrote: > > > On 08. 06. 21 11:03, Greg Kroah-Hartman wrote: > > On Mon, Jun 07, 2021 at 04:47:44PM +0200, Jiří Prchal wrote: > > > > > > > > > On 07. 06. 21 14:36, Greg Kroah-Hartman wrote: > > > > On Mon, Jun 07, 2021 at 02:26:39PM +0200, Jiri Prchal wrote: > > > > > + return sysfs_emit(buf, "%016llx\n", *(unsigned long long *)at25->sernum); > > > > > > > > That's a horrid hack, why not use the %*phN modifier? > > > > > > Prints as little endian, is that OK? > > > > You tell me! What tool is going to be reading this? What do they > > expect it to look like? > > sh, php in my usecase as unique id. I am sorry, I do not understand. > So endianess does not matter to me too much. The question is what is usual > (like mac address, uuid...?). What does the device export? Why not just export it as: 0123456789ABCDEF if it is 8 bytes long? > > And it's a byte array, why would there be endian issues? > > Now is printed as one big number. Not real issue. Just human readability? > Should I turn back it to space separated bytes? It's up to you, what do you want to do with it and what does a tool want it to look like? thanks, greg k-h