Received: by 2002:a25:d7c1:0:0:0:0:0 with SMTP id o184csp1803870ybg; Sat, 19 Oct 2019 02:52:09 -0700 (PDT) X-Google-Smtp-Source: APXvYqwfIp5liysNKrW/OMGof46DgY0phx3MTL2xqZxQPVvP9vNCTdm9eb7wZy5Jrm52oelzqsmy X-Received: by 2002:a50:d54c:: with SMTP id f12mr14212364edj.116.1571478729708; Sat, 19 Oct 2019 02:52:09 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1571478729; cv=none; d=google.com; s=arc-20160816; b=dVluHY01SDvM9upkI108xws0fpyaNm2M/YKte6p0deN5DDtKrSzyMPTehiSrsB9cHu 1N0fHWIJgRIoa40rmvIjvzwQSJas39baQAxpS9O1EDPuRfhBYo6bdbFEfVpOJN7g+pZw pUABTSEIWGmL2hrd/fgx7brP+FjymciqHnMEjeUqYU0Ip6JdJqqKbm3WAvQlB2OCz8Kr kPvUnoXTmnyNJyoTpIcqAo1kA2Z7NFsoTVKaTmk7rNVDGYApk8m6yau65BCJvqLWLn7B g7fJvG7BVgp39lET2BeZzaYscq0byp5MSqGEj7JWD9psEZ4wXpxcl2O/o/FTRfQaZpg4 z44Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=0LujGUq1E17eLWfgXufkbIxk3Qf8zWuZzZ2ag7/KZIM=; b=t9QdlX1+aBDkfYNpDre8nbvmTkbocN91Pp8RG+YgU2Nr6/tKiVgnL4qDvaOZST4Pjo nQox1jJMYtZMpsjig8lsjHmW3Jpxugj/USt9d030PiybC70b3ulCwPX/AJa5poynxbUS sowLSJ5aeD8qlNcbu6yqMK17GllfZQ2IFaoplbl1/0gVc2GWvoN5dXJZiS38/8FPb0Ko te/q0zkOVsL5AHLwXWnkiiAqZP2gZVVYtHzCjy7mbHSXrlQCkZHsgn1NaPraIU74v2eB dKrbg9h8ZT5ZDWNVHcoeupuoqVy2xqDayZSSpvqn+/HUYi0vY4k7Zxrz1K6pFvx8rEj0 cfmw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b="LZFSWVo/"; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id u1si5149132ejt.143.2019.10.19.02.51.46; Sat, 19 Oct 2019 02:52:09 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b="LZFSWVo/"; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726726AbfJSCOe (ORCPT + 99 others); Fri, 18 Oct 2019 22:14:34 -0400 Received: from mail-io1-f66.google.com ([209.85.166.66]:35303 "EHLO mail-io1-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726033AbfJSCOe (ORCPT ); Fri, 18 Oct 2019 22:14:34 -0400 Received: by mail-io1-f66.google.com with SMTP id t18so5548874iog.2 for ; Fri, 18 Oct 2019 19:14:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=0LujGUq1E17eLWfgXufkbIxk3Qf8zWuZzZ2ag7/KZIM=; b=LZFSWVo/FqIfWtBRcAdoNjHvH3rvfX9qMcVfsVCthMDFqbJLtWi9KZSI/wvRDvRhMH iUvv6ziZzP77fV19rG8K3bCitaXGfwwgjf458UW4NA6v6SiPBBYpi1YuuJpH8KyWO/d+ PebGapSS6u3xTu5dfdJiKtuFtx5aUFJQSn7WU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=0LujGUq1E17eLWfgXufkbIxk3Qf8zWuZzZ2ag7/KZIM=; b=N3u7qWH/w+2DdhsbnHRibM79jH03mRjnpelqawCEtGe3KLq6gs++GjQFsXi3iFJdZq QXa4QYT2rr/U1Dp+yLC0kwvBKn1cnG+Y4AX0nvYU29t5igdd6v+i/jNbrC1zRWGWyPHD 9qpu3jKj6m8zp+2Z9cuzjkheCo4XK0pDkadZHqg8oRDXVeL3ExfAZQ2ce75SQRovR8+f E49yEdnQ6pWCUsfM4uzyKAwDJtLnyxvfa5AI4gDg50Hcg9yxoG7MocmXTV3T+XHS/ui3 rPQDdu1pHnfohFkFdgGugWbSmaF+F38YNmswaMPWnoNH1mwePNfuCFPp5d5WqEpzHujZ GJHQ== X-Gm-Message-State: APjAAAWo36m9gjZXDytiVELOk0vaVk1/ClRzVxkfsnfE9V5Zw2TcQzat EUMzsLDA5Vu8AEv+yJEo36CghgfJ2dhA7bY7lZICQQ== X-Received: by 2002:a02:77c4:: with SMTP id g187mr1197307jac.83.1571451273159; Fri, 18 Oct 2019 19:14:33 -0700 (PDT) MIME-Version: 1.0 References: <20191008115342.28483-1-patrick.rudolph@9elements.com> <20191008115342.28483-2-patrick.rudolph@9elements.com> <5d9d120b.1c69fb81.b6201.1477@mx.google.com> <6cfca8c34ccd51f12b4418e9a74d8961e32077ed.camel@9elements.com> <5d9f3b9f.1c69fb81.62109.325d@mx.google.com> <5da779b4.1c69fb81.2d904.a23f@mx.google.com> In-Reply-To: <5da779b4.1c69fb81.2d904.a23f@mx.google.com> From: Julius Werner Date: Fri, 18 Oct 2019 19:14:20 -0700 Message-ID: Subject: Re: [PATCH 2/2] firmware: coreboot: Export active CBFS partition To: Stephen Boyd Cc: Julius Werner , Patrick Rudolph , LKML , Greg Kroah-Hartman , Ben Zhang , Duncan Laurie , Thomas Gleixner , Samuel Holland Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > I don't know why we need to draw a line in the sand and say that if the > kernel doesn't need to know about it then it shouldn't parse it. I want > there to be a consistent userspace ABI that doesn't just move things > straight from memory to userspace in some binary format. I'd rather we > have an ABI that decodes and exposes information about the coreboot > tables through existing frameworks/subsystems where possible and makes > up new ones otherwise. Okay... I'm just saying this might grow to become a lot of stuff as people start having more and more use cases they want to support. But if you think the kernel should be the one parsing all that, I'm happy to defer to your expertise there (I'm not really a kernel guy after all). > One concern I have is endianness of the binary data. Is it big endian or > little endian or CPU native endian? The kernel can boot into big or > little endian on ARM platforms and userspace can be different vs. the > bootloader too. Userspace shouldn't need to know this detail, the kernel > should know and do the conversions and expose it somehow. That's why I'm > suggesting in this case we describe fmap as a sysfs class. I don't see > how we could export that information otherwise, besides in a binary blob > that falls into traps like this. Right now it's just always CPU byte order of what coreboot happened to run at, and it's not exporting that info in any way either. We don't really have support for big-endian architectures anyway so it's not something we really thought about yet. If it ever comes to that, I assume the byte order of the table header's magic number could be used to tell the difference. > Right now we make devices for all the coreboot table entries, which is > pretty weird considering that some table entries are things like > LB_TAG_LINKER. That isn't a device. It's some information about how > coreboot was linked. We should probably blacklist tags so we don't make > devices and capture these ones in the bus code and expose them in > /sys/firware/coreboot/ somehow. We should also add device randomness > from the serial numbers, etc. that coreboot has stashed away in the > tables. I mean... should any of them be devices, then? All table entries are just "some information", where are you defining the difference there? I'm not sure if the current representation is the right one, but I think they should probably all be handled in a consistent way.