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=-14.7 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED, USER_AGENT_SANE_1 autolearn=ham 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 19F9DC432BE for ; Sat, 28 Aug 2021 06:39:18 +0000 (UTC) Received: from phobos.denx.de (phobos.denx.de [85.214.62.61]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id CBF8360F36 for ; Sat, 28 Aug 2021 06:39:16 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org CBF8360F36 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=lists.denx.de Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 22EF583259; Sat, 28 Aug 2021 08:39:14 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Authentication-Results: phobos.denx.de; dkim=pass (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.b="Zh5G4C8Z"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 615FE832CE; Sat, 28 Aug 2021 08:39:11 +0200 (CEST) Received: from mail-qk1-x730.google.com (mail-qk1-x730.google.com [IPv6:2607:f8b0:4864:20::730]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)) (No client certificate requested) by phobos.denx.de (Postfix) with ESMTPS id EB69D82F32 for ; Sat, 28 Aug 2021 08:39:06 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=seanga2@gmail.com Received: by mail-qk1-x730.google.com with SMTP id a66so9752958qkc.1 for ; Fri, 27 Aug 2021 23:39:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:to:cc:references:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=vj2HlJpygCeG1q73YsWMyRARa7maPBefVOZDDbxefQ4=; b=Zh5G4C8Z85zssZEJAkPsZy/uEpVeXLC1lOPOkiTUGLYCWh//tsccFs6ALDp0rPyL05 8xXlxoloZ77CoEU7De8eniyO9VrABAuDSMnqwCEJjbDrzM74CeUhtAuBJR3p8CyCOmRW k8cHKQbjIpaJDSHS2Uc+yjdux11yhpRgTzvN0xfOF2CUBd9ne4Vu+mWK0mgoE5PMK0LQ K/TaY3JsLqTX29My24P/C1QkVCn5S6m5fC08LOwmF75ANDGE1kcH2OTv81dBqszY1O1B XDIBefG4ZxWzOdEv0klsbOaJV7D9gAx2IdgyFOKP8OrBVzqGU0hqMOEBgY9C5JLfXgIS 2Y5Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:cc:references:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=vj2HlJpygCeG1q73YsWMyRARa7maPBefVOZDDbxefQ4=; b=Cp/TdtjM7sReXKPnJNuCBv/4h72dUhuHNwoW9Tmj9sW+V/16P3TkilJJT/xooPKsW3 hDMn2tRWElZfuvFGPelinqfNBKUH/taCe7ovEE674iPJVQ0l8qIMJl+Fem0scHtbd9Yf wzhb/spsZztlXmwhns4sYLj0yLH556rO74imCR23AhdvdS599+IVtITVeILa2MOoyzBu TZkdMkgjs5ICQ5QG2reKqCjAZnUzrmsJ/TZAea0n2ecbvdnFHDLHfdNi066nW3dPWV9t 4sobX23QQpl737QDJ6bWkPMqMpN+Kl+0WQ+6MGNy9170TqSbcVsPPLfSDlXVfs7Ez961 4E3g== X-Gm-Message-State: AOAM531fmOwe0W9mJxycE1x1C8KsIId+Ld32lwDNR8SUNcvOIpyIY7W+ O0MmN9pFL9oSLCNyvBBZ+D0= X-Google-Smtp-Source: ABdhPJxEqEpr17xFP7xPe2X1iuhlJ9ZrYFpcDFX9nikuF3qBVycfzNG7mMpkxUPFS7y3UyvL3n/7dA== X-Received: by 2002:ae9:e603:: with SMTP id z3mr12837920qkf.413.1630132745543; Fri, 27 Aug 2021 23:39:05 -0700 (PDT) Received: from [192.168.1.201] (pool-108-45-127-224.washdc.fios.verizon.net. [108.45.127.224]) by smtp.googlemail.com with ESMTPSA id g12sm4685090qtq.92.2021.08.27.23.39.04 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 27 Aug 2021 23:39:05 -0700 (PDT) From: Sean Anderson Subject: Re: [PATCH 10/11] sandbox: mmc: Support a backing file To: Simon Glass , U-Boot Mailing List Cc: Jaehoon Chung , Peng Fan References: <20210819034033.1617201-1-sjg@chromium.org> <20210818214022.10.I42087e8088f8d9fb704821d73f17d7ae246a2e69@changeid> Message-ID: <3a1dac7e-71c8-3a0d-e3b6-c2e809cad60e@gmail.com> Date: Sat, 28 Aug 2021 02:39:04 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: <20210818214022.10.I42087e8088f8d9fb704821d73f17d7ae246a2e69@changeid> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: u-boot@lists.denx.de X-Mailman-Version: 2.1.34 Precedence: list List-Id: U-Boot discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: u-boot-bounces@lists.denx.de Sender: "U-Boot" X-Virus-Scanned: clamav-milter 0.103.2 at phobos.denx.de X-Virus-Status: Clean On 8/18/21 11:40 PM, Simon Glass wrote: > Provide a way for sandbox MMC to present data from a backing file. This > allows a filesystem to be created on the host and easily served via an > emulated mmc device. > > Signed-off-by: Simon Glass > --- > > doc/device-tree-bindings/mmc/sandbox,mmc.txt | 18 ++++++++ > drivers/mmc/sandbox_mmc.c | 46 ++++++++++++++++---- > 2 files changed, 55 insertions(+), 9 deletions(-) > create mode 100644 doc/device-tree-bindings/mmc/sandbox,mmc.txt > > diff --git a/doc/device-tree-bindings/mmc/sandbox,mmc.txt b/doc/device-tree-bindings/mmc/sandbox,mmc.txt > new file mode 100644 > index 00000000000..1170bcd6a00 > --- /dev/null > +++ b/doc/device-tree-bindings/mmc/sandbox,mmc.txt > @@ -0,0 +1,18 @@ > +Sandbox MMC > +=========== > + > +Required properties: > +- compatible : "sandbox,mmc" > + > +Optional properties: > +- filename : Name of backing file, if any. This is mapped into the MMC device > + so can be used to provide a filesystem or other test data Can we stick this in the command line arguments somehow? For testing with different images, I think that editing the device tree is not the best way to do things. It also makes it trickier to add automated tests. > + > + > +Example > +------- > + > +mmc2 { > + compatible = "sandbox,mmc"; > + non-removable; > +}; > diff --git a/drivers/mmc/sandbox_mmc.c b/drivers/mmc/sandbox_mmc.c > index 895fbffecfc..1139951c626 100644 > --- a/drivers/mmc/sandbox_mmc.c > +++ b/drivers/mmc/sandbox_mmc.c > @@ -9,23 +9,26 @@ > #include > #include > #include > +#include > #include > +#include > #include > > struct sandbox_mmc_plat { > struct mmc_config cfg; > struct mmc mmc; > + const char *fname; > }; > > -#define MMC_CSIZE 0 > -#define MMC_CMULT 8 /* 8 because the card is high-capacity */ > -#define MMC_BL_LEN_SHIFT 10 > -#define MMC_BL_LEN BIT(MMC_BL_LEN_SHIFT) > -#define MMC_CAPACITY (((MMC_CSIZE + 1) << (MMC_CMULT + 2)) \ > - * MMC_BL_LEN) /* 1 MiB */ > +#define MMC_CMULT 8 /* 8 because the card is high-capacity */ > +#define MMC_BL_LEN_SHIFT 10 > +#define MMC_BL_LEN BIT(MMC_BL_LEN_SHIFT) > +#define SIZE_MULTIPLE ((1 << (MMC_CMULT + 2)) * MMC_BL_LEN) > > struct sandbox_mmc_priv { > - u8 buf[MMC_CAPACITY]; > + int csize; /* CSIZE value to report */ > + char *buf; > + int size; nit: to save a whole 2 bytes on 64-bit you can reorder this like char * int int > }; > > /** > @@ -60,8 +63,8 @@ static int sandbox_mmc_send_cmd(struct udevice *dev, struct mmc_cmd *cmd, > case MMC_CMD_SEND_CSD: > cmd->response[0] = 0; > cmd->response[1] = (MMC_BL_LEN_SHIFT << 16) | > - ((MMC_CSIZE >> 16) & 0x3f); > - cmd->response[2] = (MMC_CSIZE & 0xffff) << 16; > + ((priv->csize >> 16) & 0x3f); > + cmd->response[2] = (priv->csize & 0xffff) << 16; > cmd->response[3] = 0; > break; > case SD_CMD_SWITCH_FUNC: { > @@ -143,6 +146,8 @@ static int sandbox_mmc_of_to_plat(struct udevice *dev) > struct blk_desc *blk; > int ret; > > + plat->fname = dev_read_string(dev, "filename"); > + > ret = mmc_of_parse(dev, cfg); > if (ret) > return ret; > @@ -156,6 +161,29 @@ static int sandbox_mmc_of_to_plat(struct udevice *dev) > static int sandbox_mmc_probe(struct udevice *dev) > { > struct sandbox_mmc_plat *plat = dev_get_plat(dev); > + struct sandbox_mmc_priv *priv = dev_get_priv(dev); > + int ret; > + > + if (plat->fname) { > + ret = os_map_file(plat->fname, OS_O_RDWR | OS_O_CREAT, > + (void **)&priv->buf, &priv->size); > + if (ret) { > + log_err("%s: Unable to map file '%s'\n", dev->name, > + plat->fname); > + return ret; > + } > + priv->csize = priv->size / SIZE_MULTIPLE - 1; Won't this cut off the end of the file? If we can't avoid this, we should at least warn the user that we are truncating it. --Sean > + } else { > + priv->csize = 0; > + priv->size = (priv->csize + 1) * SIZE_MULTIPLE; /* 1 MiB */ > + > + priv->buf = malloc(priv->size); > + if (!priv->buf) { > + log_err("%s: Not enough memory (%x bytes)\n", > + dev->name, priv->size); > + return -ENOMEM; > + } > + } > > return mmc_init(&plat->mmc); > } >