Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp302081pxj; Thu, 10 Jun 2021 22:50:23 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzuPQS9GBB5r/YHW4GbkCQs5g7pmzN/2zBdgP3lQa+XV+1a/Tqiu72NVd28+09H+Cr+UNAF X-Received: by 2002:a17:906:4882:: with SMTP id v2mr2087714ejq.134.1623390623066; Thu, 10 Jun 2021 22:50:23 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1623390623; cv=none; d=google.com; s=arc-20160816; b=BvKEdpnoom0yMKcfwKFkUQxExpe/33pFj1H30y4Cvs05kZAq3T1O0rSo6R6E1WKAiG jxLT1eaAffyo5uixgYcuZDxJ+KtBWJ6E9qII8BpdZLIlz0t9XCNRMqX5m/JQfuexTE3+ 37tMNEn5a9hsOAiOEXwNkdWGKv4ddt+kH/oH0FiUo/61L/GBmreAJdKfOKqu2LIffWoT XoGibzhj/5GgTQPgYSfaI8r5J+wxe8qZhwvBnA8pRkblxx2P5WxuwyC4A9jttkiBpcvb TG64woDy5Zs1EOYwOypyLxN0Pk6vjvL5Nb95YdU4X5CP82whxTON/osbHv2Bzlw1rxE2 PJYg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=Z3I+f62wEsTTanPinvuVTxO15thjH0+8cDzgDjiCHH0=; b=EfzZzjokSlCQ/1cWLxg5USHIQNio6DYF7Oz6by+y1O2ihyEbZcj5DuesWQ0D9Z1yRZ AKJgIEA9FRF0HnAZ2UeZ8JCXgCyUwweT0rpBllnoS6rdfV3zV4/zdHMZUIyge9RLORSF pET+Y/M4r1Mobhmysm4o/1yhbrTLAnxR+MyMbMNTr2rUyzMebHneCv+/4gLKgiBF3FXM Mc4uIMBQBe2Zvrq9hE8bEIf7PbQN+GDYo8VULPwmM10A/1UzAqmbsi4OvexTGtXggkBy +uQiqEFr78st5/7ONmT1Hr/sQRfA5m/PhbinmTcmhbZtseQ5iSmI7IDpccHop5JFORen 30Ow== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=knMjjDyl; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id b6si4617043edu.115.2021.06.10.22.49.59; Thu, 10 Jun 2021 22:50:23 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=knMjjDyl; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231151AbhFKFrE (ORCPT + 99 others); Fri, 11 Jun 2021 01:47:04 -0400 Received: from mail.kernel.org ([198.145.29.99]:41144 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230001AbhFKFrD (ORCPT ); Fri, 11 Jun 2021 01:47:03 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id A7C1A61009; Fri, 11 Jun 2021 05:45:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1623390306; bh=ZKNmxmMgms5VwXe37d6FX3oCzRYrOHamlq+LusSpfDQ=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=knMjjDylTMahicXKkVt/YLCmk4mCoxpjqAmhthAw0HMhmKG/W8CI3rZqfWdeNdBdp pcW6sxhQcOPclccFCK1bjN6yNxX9yJY1nJKMSLzOaHGzks+BvkoV7FyhOEoX2KV+KA /nx0Pl/+tDCIBzqsHKhga/T5//eYIXApMda6ZkBOBhdh6khRUpE22dCUe/O3rCAKnU O+PhSYLlWRHhDLvHHdVEYZzg6IJJH8bkBZA/FdWGmpOTlVNGl1BnNzuxIBBOwumPEu rGL/THLtpnBoxplbdw58X0Foobl/J07M0lUU9L4p46ehrKp3u8qn/tBv1Wxfs9dfJw 7JwpvxAyl6Dyg== Date: Fri, 11 Jun 2021 11:15:01 +0530 From: Vinod Koul To: John Stultz Cc: Bjorn Andersson , linux-arm-msm , Andy Gross , Rob Herring , Dmitry Baryshkov , "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" , lkml Subject: Re: [PATCH] arm64: dts: qcom: sm8350-mtp: Use mdt files for firmware Message-ID: References: <20210611050808.2554431-1-vkoul@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 10-06-21, 22:27, John Stultz wrote: > On Thu, Jun 10, 2021 at 10:08 PM Vinod Koul wrote: > > > > As discussed in [1], it makes it easy for everyone to use mdt firmware file > > name instead of mbn ones, so changes this for SM8350 > > > > [1]: http://lore.kernel.org/r/CALAqxLXn6wFBAxRkThxWg5RvTuFEX80kHPt8BVja1CpAB-qzGA@mail.gmail.com > > > > Signed-off-by: Vinod Koul > > --- > > arch/arm64/boot/dts/qcom/sm8350-mtp.dts | 8 ++++---- > > 1 file changed, 4 insertions(+), 4 deletions(-) > > > > diff --git a/arch/arm64/boot/dts/qcom/sm8350-mtp.dts b/arch/arm64/boot/dts/qcom/sm8350-mtp.dts > > index 93740444dd1e..d859305f1f75 100644 > > --- a/arch/arm64/boot/dts/qcom/sm8350-mtp.dts > > +++ b/arch/arm64/boot/dts/qcom/sm8350-mtp.dts > > @@ -40,7 +40,7 @@ vph_pwr: vph-pwr-regulator { > > > > &adsp { > > status = "okay"; > > - firmware-name = "qcom/sm8350/adsp.mbn"; > > + irmware-name = "qcom/sm8350/adsp.mdt"; > > }; > > Uhh, isn't this the opposite of [1]? My apologies for butting in, and > I'd stay out of the discussion, except for my mail being linked as > justification :) I would rather think of your email as background material or trigger :) > In [1] the case was db845c was switched from older mdt files to using > the upstream linux-firmware mbn files. This was a bit of a pain, as it > broke on our userland with mdt files, and since we use both old and > new kernels we had to have both filenames on the disk (via symlink) to > keep it working everywhere. > > My argument in [1] was for new boards, go with the new conventions, > but we should avoid breaking those conventions casually on existing > devices. That said, I know it's more complex, and I graciously defer > to Bjorn and RobC on the decision. > > But your patch above seems to be switching from mbn (what I understand > to be the new convention) to mdt (what I thought was the old way). And > from the git blame, it looks like it was introduced as mbn (new board, > new convention - so all good, right?). > > So is this really the right change? Or maybe just more exposition in > the commit message is needed (rather than pointing to my mail, which > seems to be arguing the opposite) to explain it? We have had a discussion after the email thread and thought it is better approach to stick to mdt format as used downstream and not have confusion and issues resulting from upstream vs downstream Since SM8350 is a new platform, so switching here onwards made sense, hence this patch I should have added more details for this in changelog as well... Thanks -- ~Vinod