From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754433AbdHVEWT (ORCPT ); Tue, 22 Aug 2017 00:22:19 -0400 Received: from regular1.263xmail.com ([211.150.99.140]:42881 "EHLO regular1.263xmail.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751249AbdHVEUi (ORCPT ); Tue, 22 Aug 2017 00:20:38 -0400 X-263anti-spam: KSV:0;BIG:0; X-MAIL-GRAY: 0 X-MAIL-DELIVERY: 1 X-KSVirus-check: 0 X-ADDR-CHECKED4: 1 X-ABS-CHECKED: 1 X-SKE-CHECKED: 1 X-ANTISPAM-LEVEL: 2 X-RL-SENDER: jeffy.chen@rock-chips.com X-FST-TO: broonie@kernel.org X-SENDER-IP: 103.29.142.67 X-LOGIN-NAME: jeffy.chen@rock-chips.com X-UNIQUE-TAG: <7fcfbb7dd819a5cf8a437a2bec5f086c> X-ATTACHMENT-NUM: 0 X-DNS-TYPE: 0 Message-ID: <599BB104.4020600@rock-chips.com> Date: Tue, 22 Aug 2017 12:20:20 +0800 From: jeffy User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:19.0) Gecko/20130126 Thunderbird/19.0 MIME-Version: 1.0 To: Mark Brown CC: linux-kernel@vger.kernel.org, dgreid@chromium.org, heiko@sntech.de, briannorris@chromium.org, mka@chromium.org, dianders@chromium.org, Jaroslav Kysela , alsa-devel@alsa-project.org, Oder Chiou , Takashi Iwai , Liam Girdwood , Bard Liao , Lars-Peter Clausen Subject: Re: [PATCH v4 1/9] ASoC: rt5514: Avoid legacy dai naming References: <20170818031147.16810-1-jeffy.chen@rock-chips.com> <20170818031147.16810-2-jeffy.chen@rock-chips.com> <20170818114544.szfxl5pbul7gwgxg@sirena.org.uk> <599701D2.5080001@rock-chips.com> <20170821173107.wzkbnvqylkovg634@sirena.org.uk> In-Reply-To: <20170821173107.wzkbnvqylkovg634@sirena.org.uk> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Mark, thanks for your reply. On 08/22/2017 01:31 AM, Mark Brown wrote: > On Fri, Aug 18, 2017 at 11:03:46PM +0800, jeffy wrote: > >> when using legacy dai naming, the dai->name for rt5514-spi would be the dev >> name, which is spi2.0 with my local 4.4 kernel, and would be spi32765.0 with >> upstream kernel. > > It would be better to fix the code to not need a name if the device by > itself is unambiguous. > right... i'm not familiar with the soc core codes, would these make sense? 1/ consider match when the of nodes are the same: @@ -978,9 +978,10 @@ struct snd_soc_dai *snd_soc_find_dai( if (dlc->name && strcmp(component->name, dlc->name)) continue; list_for_each_entry(dai, &component->dai_list, list) { + if (dlc->of_node && dai->dev->of_node == dlc->of_node) + return dai; or 2/ return the first dai when there's only one: @@ -977,10 +977,11 @@ struct snd_soc_dai *snd_soc_find_dai( continue; if (dlc->name && strcmp(component->name, dlc->name)) continue; + if (component->num_dai == 1) + return &component->dai_list[0]; list_for_each_entry(dai, &component->dai_list, list) { or 3/ also check for dai driver name: @@ -978,9 +978,10 @@ struct snd_soc_dai *snd_soc_find_dai( if (dlc->name && strcmp(component->name, dlc->name)) continue; list_for_each_entry(dai, &component->dai_list, list) { - if (dlc->dai_name && strcmp(dai->name, dlc->dai_name)) + if (dlc->dai_name && strcmp(dai->name, dlc->dai_name) + && strcmp(dai->driver->name, dlc->dai_name)) continue;