Received: by 2002:a05:7412:3784:b0:e2:908c:2ebd with SMTP id jk4csp2636549rdb; Wed, 4 Oct 2023 07:14:25 -0700 (PDT) X-Google-Smtp-Source: AGHT+IGD+wSEZKVBGhyNnEyl8lSrHeNh3vyRDhaXiKdcXsmoKG92L1/ZXilVFhIr6NAuWr0LHyKZ X-Received: by 2002:a9d:6e03:0:b0:6c4:e6d8:2cdc with SMTP id e3-20020a9d6e03000000b006c4e6d82cdcmr2236035otr.23.1696428865310; Wed, 04 Oct 2023 07:14:25 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1696428865; cv=none; d=google.com; s=arc-20160816; b=yiovnHqZO5PSuCyFDA3LIuntSdanwYU6TYNZlApd0/VkKrNQEi2UFGX+XUroTF/XV8 X9WLeruNW8zTE0JMJUrta9eRS82kFlWsDWjKOEe3r4FO3je7QCqMMytKteSNm+0BoqMS GhdA0enoMCApF3D1ecljWo6vR2OcgQdbECqlphnhvYs6DI+u43j7RLKmkOu3vAJLZQb3 zPD7ag+vVuuZ8/s5Bc7EqYlHwdiNQLG61FUXuo61nTzb5eHDqOsQR2Dr57mHwGLniBWD i3G8kMgDUKe/J/x5RG6Hr9gErg6RGw0zkhpVJMIZmFoGGmDGx9FRtrjl24QLM2IlugrG TMig== 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=mQZzeRJOICplVJQdZt1/hDujranYMvzTefwMa80gbyo=; fh=yN0OstffOHImAcLSSU2D1K4t3zWMOFuIIn2F3ywfPDw=; b=pj3n1GtN99qv9KcINipT8OVWG43snn/8C0OfbZ+pyvkhMmInzmgEyD9ZKZaM5cGNa/ zObu6FE6E1OtUYmKWL8vGVawIrzAP1JIsJ2qEMiAaNoRhbDX7kWMXMOqIt016HxhgQRS CyN+lbHwCUhLC3ebhwdhTEpaFMEWtdHGBTMIWNjvlmflcjNWw+50fDQdvgKXAGDj3cPX i3a9QG/mQdJgefyY9GtVbDD6ezukaAK9vbTgEaDLQtcVxbx3yX4Zh1xovvg/F64XXZgh 9ewAlmRuIfNhWc6IfECDHzUputLOD+JgmKDvFR1I0GyU0Vuwg61gE/FbsXGkNIT39uE+ l8Sg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=yeKec6tp; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.37 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Return-Path: Received: from snail.vger.email (snail.vger.email. [23.128.96.37]) by mx.google.com with ESMTPS id g1-20020a63f401000000b0058572c8d5d5si3860711pgi.233.2023.10.04.07.14.24 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 04 Oct 2023 07:14:25 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.37 as permitted sender) client-ip=23.128.96.37; Authentication-Results: mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=yeKec6tp; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.37 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by snail.vger.email (Postfix) with ESMTP id 63D938218E68; Wed, 4 Oct 2023 07:14:23 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at snail.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S242856AbjJDOOX (ORCPT + 99 others); Wed, 4 Oct 2023 10:14:23 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57064 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S242790AbjJDOOW (ORCPT ); Wed, 4 Oct 2023 10:14:22 -0400 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D033EBD; Wed, 4 Oct 2023 07:14:18 -0700 (PDT) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 1DF02C433C8; Wed, 4 Oct 2023 14:14:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1696428858; bh=L/Mr44New+pyfxS07F3RFMAGC4EBy3Vu3NpvP3/raio=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=yeKec6tpX2O10Q2faEGUUVXpPIS7VBXxsaSMPd9dM2AHTpCbniY8X/ZO/2nCl6K8o gIwIvz9svx/TQtj6YeuixfSu3AXSAX0GHvfvjZq/Ff2ulrK5lPQTpQ5MDZ6Hpwt11G l5/Ba3ymRkys0LBP20mSjXOUoYi9q0HfwG8pva3g= Date: Wed, 4 Oct 2023 16:13:39 +0200 From: Greg Kroah-Hartman To: Pierre-Louis Bossart Cc: Krzysztof Kozlowski , Vinod Koul , Bard Liao , Sanyog Kale , Philippe Ombredanne , Takashi Iwai , alsa-devel@alsa-project.org, linux-kernel@vger.kernel.org, stable@vger.kernel.org Subject: Re: [PATCH] soundwire: fix initializing sysfs for same devices on different buses Message-ID: <2023100452-craziness-unpopular-7d97@gregkh> References: <20231004130243.493617-1-krzysztof.kozlowski@linaro.org> <6628a5f6-ed22-4039-b5c2-2301c05c7e3e@linux.intel.com> <2023100453-perfected-palm-3503@gregkh> <624b044a-1f0f-4961-8b57-cb5346e7b0d3@linux.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <624b044a-1f0f-4961-8b57-cb5346e7b0d3@linux.intel.com> X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF, RCVD_IN_DNSWL_BLOCKED,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (snail.vger.email [0.0.0.0]); Wed, 04 Oct 2023 07:14:23 -0700 (PDT) On Wed, Oct 04, 2023 at 09:57:49AM -0400, Pierre-Louis Bossart wrote: > > > On 10/4/23 09:38, Greg Kroah-Hartman wrote: > > On Wed, Oct 04, 2023 at 09:16:47AM -0400, Pierre-Louis Bossart wrote: > >> > >> > >> On 10/4/23 09:02, Krzysztof Kozlowski wrote: > >>> If same devices with same device IDs are present on different soundwire > >>> buses, the probe fails due to conflicting device names and sysfs > >>> entries: > >>> > >>> sysfs: cannot create duplicate filename '/bus/soundwire/devices/sdw:0:0217:0204:00:0' > >>> > >>> The link ID is 0 for both devices, so they should be differentiated by > >>> bus ID. Add the bus ID so, the device names and sysfs entries look > >>> like: > >> > >> I am pretty sure this will break Intel platforms by changing the device > >> names. > >> > >> sof_sdw.c: else if (is_unique_device(adr_link, sdw_version, mfg_id, > >> part_id, > >> sof_sdw.c: > >> "sdw:%01x:%04x:%04x:%02x", link_id, > >> sof_sdw.c: > >> "sdw:%01x:%04x:%04x:%02x:%01x", link_id, > > > > device id name changes shouldn't break things, what is requring them to > > look a specific way? > > it's the ASoC dailink creation that relies on strings, we have similar > cases for I2C. > > There's no requirement that the name follows any specific convention, > just that when you want to rely on a specific device for an ASoC card > you need to use the string that matches its device name. matching the name is fine (if you are matching it against an existing name) but expecting the name to be anything specific is not going to work as the name is dynamic and can/will change each boot. thanks, greg k-h