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 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 smtp.lore.kernel.org (Postfix) with ESMTPS id EB3A5ECAAA3 for ; Fri, 26 Aug 2022 15:01:33 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 750BF848DC; Fri, 26 Aug 2022 17:01:31 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=linaro.org 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=linaro.org header.i=@linaro.org header.b="v/vmA0ff"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id EBED7848DC; Fri, 26 Aug 2022 17:01:29 +0200 (CEST) Received: from mail-io1-xd30.google.com (mail-io1-xd30.google.com [IPv6:2607:f8b0:4864:20::d30]) (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 1581684363 for ; Fri, 26 Aug 2022 17:01:26 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=linaro.org Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=ralph.siemsen@linaro.org Received: by mail-io1-xd30.google.com with SMTP id i77so1359899ioa.7 for ; Fri, 26 Aug 2022 08:01:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc; bh=JBmIpNSmJZkcgjjDU7asig8nO2iQ9vuRstcL9H2J4Dk=; b=v/vmA0fflxpq3PftLhHfhLr/q2M0VJIhu2+7FzDhkmPqSgAiOkraGMiuyok5Rp0HNk 2k/t2vYX332kskRnqIioj2YTssS3IWaVShE7jQbUfvO2WBqWOu99cmbrtTnToWusX8di 907A5Q3r87vWWlR/52HsU4eAemX3C5WDhWsc0kBFxqvM/+yUlFFi2NyXGvKyJ3ZLL91e 7fPsEZkNB4v0OYv57odsyzoa3cEscm0s6jrJ2mbOVx8IIv4XtXudTW8C+WAYWGcChFBf ySoLG3wrW3D04oaAe2Co8xuyJxzso+yMSU88c0o8UHHBjpjTPq5pl7FS1HMolU6gKYaJ YgFQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc; bh=JBmIpNSmJZkcgjjDU7asig8nO2iQ9vuRstcL9H2J4Dk=; b=gwPz39apZQSZUBGrS1KGAeiUkE8/HlQMKlXW64SKVLb6LzDZ6r3+7M0vRwaFerUoik FdXwifruw0IyveFyZK9QcTXWM2wkM+iIR6tUeAPOePVEdlOcTEHSpPstGYdAlT8AOd2+ JaMSt7YXpTJh7ZwBhcmNJaww1awYiq8udHbBQ5CxnKH5hTyzIT8D0FPTtDJiyR5NFoKp dnDRPE5IaWV+RRSDJ4wlnvJvXVmYIAANZK2ed+YexbfLKmsxc9HWpEl/bYcpNjyJ5Hyg SBHHMDsZZ79ErzlLqRx7eHiBc2NtHdwdtneMBkW6vNBiYG/qVNF5+DvbnKO1rY9rl3ez cCKA== X-Gm-Message-State: ACgBeo3d9Kc+QNn5OrHbFDeQC7iiquyGIK7lRb/6m7N/mxOFptl9nR+1 LW77nWviy0uGJ4PDlX8w/gEr3g== X-Google-Smtp-Source: AA6agR7Mu+wwssrhM//MO1iph9JxwvuzHd24tqns0/G4N3gKyk7WYqy8+xBrEctprIzTdX779NuXww== X-Received: by 2002:a6b:6203:0:b0:684:b96c:5504 with SMTP id f3-20020a6b6203000000b00684b96c5504mr3724207iog.106.1661526084639; Fri, 26 Aug 2022 08:01:24 -0700 (PDT) Received: from localhost (rfs.netwinder.org. [206.248.184.2]) by smtp.gmail.com with ESMTPSA id l15-20020a05660227cf00b006894c508ebbsm1176274ios.33.2022.08.26.08.01.24 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 26 Aug 2022 08:01:24 -0700 (PDT) Date: Fri, 26 Aug 2022 11:01:23 -0400 From: Ralph Siemsen To: Sean Anderson Cc: andre.przywara@arm.com, heiko.thiery@gmail.com, pali@kernel.org, samuel@sholland.org, sjg@chromium.org, sr@denx.de, takahiro.akashi@linaro.org, u-boot@lists.denx.de, sean.anderson@seco.com Subject: Re: [RFC PATCH v2 9/9] tools: spkgimage: add Renesas SPKG format Message-ID: <20220826150123.GA1235411@maple.netwinder.org> References: <20220809125959.217333-10-ralph.siemsen@linaro.org> <20220812170325.485707-1-ralph.siemsen@linaro.org> <7e4a3833-bc51-9b2c-aa0a-4af017e1fb1b@gmail.com> <0e426d60-e6a4-4f3f-7a55-8c3cf9d90e08@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <0e426d60-e6a4-4f3f-7a55-8c3cf9d90e08@gmail.com> X-BeenThere: u-boot@lists.denx.de X-Mailman-Version: 2.1.39 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.6 at phobos.denx.de X-Virus-Status: Clean On Mon, Aug 22, 2022 at 11:42:54PM -0400, Sean Anderson wrote: >>>>>+static int spkgimage_check_image_types(uint8_t type) >>>>>+{ >>>>>+ return type == IH_TYPE_RENESAS_SPKG ? 0 : 1; >>>> >>>>This function is not necessary if you only support one type. >>> >>>Without this function, mkimage kept telling me that my format >>>(spkgimage) was not supported, and none of my callbacks got invoked. >>>It only complained when trying to generate a header. When listing the >>>supported formats, spkgimage showed up correctly. >>> >>>I'll take another look on Monday, maybe I missed something obvious. >> >>I have re-checked this: >>- without the function, mkimage complains that spkgimage is unknown >>- with a function that unconditionally returns 0, it works fine >> >>If it really is meant to work without the function, then a bug must >>have crept in elsewhere... > >Huh. I did a quick grep so maybe I missed something. IMO this *should* >work without a function, because we have tons of drivers which just >have an equality check. In any case, you can just do > >return type == IH_TYPE_RENESAS_SPKG ? 0 : -EINVAL; It works fine when I use the following for the function: static int spkgimage_check_image_types(uint8_t type) { return 0; } However if no function is provided, i.e. U_BOOT_IMAGE_TYPE has NULL for check_image_type field, then mkimage fails with the error: tools/mkimage: unsupported type Renesas SPKG Image Looking at this a bit more, it seems to be due to: struct image_type_params *imagetool_get_type(int type) { ...snip... for (curr = start; curr != end; curr++) { if ((*curr)->check_image_type) { if (!(*curr)->check_image_type(type)) return *curr; } } return NULL; } So the only way to get non-NULL from imagetool_get_type is for there to be a callback function, and it must return zero. And this in turn causes mkimage to bail out quite early in main(): /* set tparams as per input type_id */ tparams = imagetool_get_type(params.type); if (tparams == NULL && !params.lflag) { fprintf (stderr, "%s: unsupported type %s\n", params.cmdname, genimg_get_type_name(params.type)); exit (EXIT_FAILURE); } Unless I am missing something, it seems I must provide a function. -Ralph PS I will post an updated series (v3) eventually. I'm working on making changes to the clock driver on the kernel side, to keep it in sync with the changes you requested in the u-boot side.