Received: by 2002:ac0:a594:0:0:0:0:0 with SMTP id m20-v6csp3738460imm; Fri, 25 May 2018 10:42:28 -0700 (PDT) X-Google-Smtp-Source: AB8JxZpx/ZhqnoKTWiPUX7fXzVLzleYXCWAO4XIWJys14OjH9SiaNwiMyc6ZuEJZ66zlfEGKnKNP X-Received: by 2002:a17:902:5993:: with SMTP id p19-v6mr3556471pli.191.1527270148309; Fri, 25 May 2018 10:42:28 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1527270148; cv=none; d=google.com; s=arc-20160816; b=K9D2tshzmzL3E8ua3r1E+jVb3TC8i9yA3yODKvN/1SyQoWm/m0JO2aycS64+8D2t3l kv2rhjbYJUzmle55Dz8JYAM0w2EeRBDoIlvOk4sEZoldChiyLC1oO5VgI4UvVGnD+++e 0SGU9NK7bQCXv5V6WwAXpgNYDmD/NN8m0hpBfnwmdFGkxAhI7RVwa1yDKOz9DpbiHMM4 zecgf8AGj6WZuLGV5Hk7iM4YKaY/M5VDO0hEaG5GstQKhjr15KciOgiu/mkyRxjR+2w8 j361j15/rG6Kgv9Vp2psygQF2z5VYxFn57T0z7LT8XivL8FAkCDMnC4qhb48X+yOwToU wRLw== 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 :arc-authentication-results; bh=vUj7i+cgjeT1n1+p/jxZpkISDhMtZk8PXGcemFBJZAI=; b=bNxPJBzYzUSZ2BDftiL6o2zkt4OxOTgOBs1X3F4dxq9JxmDrr/Sia35M23I4arlSn7 2Qu5Y4/lqNaBVzOPUSLUkyKtwPSq0e/kZa8vxIjnqFwnMo/aIaqsx5Y8op5sYW343TzM a3CFSqLhEiZSzCSirjD/0dAYANlN51VR4QpspUaaU/JepLJIDUZ2L5Ows0a8zAlV6E67 yK9nBhwpBSEykdiLn1Uleqd2CerCK/eLUpDEmtyivsuE0WIX3GtV4Ynb+tp/HVszeG4c ggekJRvDfvCt1ZR7xA8qyvqj2kEE1CtLrDEDRgE0kCC1GIfda7Z0DyTSb4Sb5Z05hCeb wseg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=h8GPFqGD; 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=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id n28-v6si24619414pfh.210.2018.05.25.10.42.12; Fri, 25 May 2018 10:42:28 -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=@google.com header.s=20161025 header.b=h8GPFqGD; 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=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S967472AbeEYRmA (ORCPT + 99 others); Fri, 25 May 2018 13:42:00 -0400 Received: from mail-yw0-f195.google.com ([209.85.161.195]:43894 "EHLO mail-yw0-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S967349AbeEYRl7 (ORCPT ); Fri, 25 May 2018 13:41:59 -0400 Received: by mail-yw0-f195.google.com with SMTP id p14-v6so1962621ywe.10 for ; Fri, 25 May 2018 10:41:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=vUj7i+cgjeT1n1+p/jxZpkISDhMtZk8PXGcemFBJZAI=; b=h8GPFqGD0VeT/ihDjqKftKZ0K3t2ELUWtMyUDHvfg2J+3p0KrigMgNmhvuiuBXOYPs ttaTyv/d5plxWy/2tTfnttYkaM/Ir8Xl6kKb3XIMtioL5f0bCS4ivMLIcMQZmaaP9X2N 5Z43EptU9rwOGU+WMIKt3yJJq2praNrsUpqIekPO+t+XguNmI6KzOtDsRhwj58FOhvz7 /FEodpbmHjDdITvn8PB9QB42U49T22E16M8AkXwMEdzkybe3v6jhO6GLuYjVs96pnwTo kNd5w40+9f5yeVJfTSZ1PpEMWsNYW22CNtg83dlkPUiXbLfutb2AyhLaxrCKoyJnbnF5 CXug== 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=vUj7i+cgjeT1n1+p/jxZpkISDhMtZk8PXGcemFBJZAI=; b=rxAHYqrBnjo5Nteabp6dC1cafxpA6GFBCqulawzzyV2E2LIfC1irR4L2LLyxjpClJT PPuIRW46jQS1BJVTvr1TzG5diWTdgf7uZ/zMsrinFb/+gu6pnQFHJMmog472l0tA96ZZ l9KRm9BcroJV2u1mMzOAR1OLmyUzetK2cfY5dWyf8RZ1e7dUFdnfVp5GSyc/pTwqta47 0ntJ/AqffNr4Q6AxGm+3+svhPCHYLpq7TWFrVKjINHIwmRQXzZ3pAyoQeIiC1nESLIaA nM2Ysht0kmng7kVGnJhu2lROj6f1tHS+69Rw0kaLhcFyTtT4d9oTBjMb3SUumZGswKGj y8/w== X-Gm-Message-State: ALKqPweQHC0QN56O4ZLVRdnMMlpMBpbDxIMjIQlVPDW2KBe/G49Ryu7b +dHmdJuC1TZOYzOdiJbss2goXtPK2z5yYRKg2D8LyA== X-Received: by 2002:a81:2403:: with SMTP id k3-v6mr1875133ywk.337.1527270118620; Fri, 25 May 2018 10:41:58 -0700 (PDT) MIME-Version: 1.0 References: <20180522165842.233949-1-groeck@google.com> <649b1c14-e440-0c89-a59c-dc663344faa3@linux.intel.com> <20180525134023.GJ3116@snc-desk> In-Reply-To: From: Guenter Roeck Date: Fri, 25 May 2018 10:41:46 -0700 Message-ID: Subject: Re: [alsa-devel] [RFC/RFT PATCH] ASoC: topology: Improve backwards compatibility with v4 topology files To: shreyas.nc@intel.com Cc: pierre-louis.bossart@linux.intel.com, alsa-devel@alsa-project.org, linux-kernel , Takashi Iwai , Liam Girdwood , Mark Brown , "Patel, Chintan M" , Guenter Roeck 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 On Fri, May 25, 2018 at 7:09 AM Guenter Roeck wrote: > On Fri, May 25, 2018 at 6:42 AM Shreyas NC wrote: > > > > > +struct skl_dfw_v4_pipe { > > > > > + u8 pipe_id; > > > > > + u8 pipe_priority; > > > > > + u16 conn_type:4; > > > > > + u16 rsvd:4; > > > > > + u16 memory_pages:8; > > > > > +} __packed; > > > > > + > > > > > +struct skl_dfw_v4_module { > > > > > + char uuid[SKL_UUID_STR_SZ]; > > > > > + > > Any reason to not have this as u8? > > commit 09305da97c7808b900985526aa9198233f32fb37 had changed this to u8.. > No reason. I'll fix it. You confused me. Commit 09305da97c7808b900985526aa9198233f32fb37 changed the uuid format in the configuration file from 40-byte string to 16-byte binary. This is an ABI change. As such, yes, there is a reason for 'char'. It is because v4 of the configuration file, at least v4 as defined up to and including upstream kernel v4.6, provide the uuid as string, not as 16-byte hex value. That this ABI change was made without ABI version number change is another issue. Guenter > > > > > > > + > > > > > + mconfig->params_fixup = dfw->params_fixup; > > > > > + mconfig->converter = dfw->converter; > > > > > + mconfig->m_type = dfw->module_type; > > > > > + mconfig->vbus_id = dfw->vbus_id; > > > > > + mconfig->module->resources[0].is_pages = dfw->mem_pages; > > > > > + > > > > > + ret = skl_tplg_add_pipe_v4(dev, mconfig, skl, &dfw->pipe); > > > > > + if (ret) > > > > > + return ret; > > > > > + > > > > > + mconfig->dev_type = dfw->dev_type; > > > > > + mconfig->hw_conn_type = dfw->hw_conn_type; > > > > > + mconfig->time_slot = dfw->time_slot; > > > > > + mconfig->formats_config.caps_size = dfw->caps.caps_size; > > > > > > > chromeos-3.18 has this: > > > > if (dfw_config->is_loadable) > > > > memcpy(mconfig->guid, dfw_config->uuid, > > > > ARRAY_SIZE(dfw_config->uuid)); > > > > > > > Is this needed here? > > > > > > > > > Direct memcpy doesn't work anymore since the uuid format is different. > The > > > above is replaced > > > with (unconditional) > > > > > > ret = guid_parse(dfw->uuid, (guid_t *)mconfig->guid); > > > if (ret) > > > return ret; > > > > > > at the beginning of skl_tplg_get_pvt_data_v4(). The new code, as far as > I > > > can see, loads > > > the uuid unconditionally if it finds SND_SOC_TPLG_TUPLE_TYPE_UUID. I > wanted > > > to > > > be on the safe side and decided to do the same. > > > > > In the new code, still does a memcpy(). So, I am not sure if I understand > > why memcpy() does not work. > > if (uuid_tkn->token == SKL_TKN_UUID) { > > memcpy(guid, &uuid_tkn->uuid, 16); > > return 0; > > } > The new (v5) configuration files provide the uuid as binary and no longer > as text. > Guenter