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 X-Spam-Level: X-Spam-Status: No, score=-10.3 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,NICE_REPLY_A, SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 5502DC433E0 for ; Mon, 1 Feb 2021 18:18:33 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 0D60664DE1 for ; Mon, 1 Feb 2021 18:18:32 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232695AbhBASS3 (ORCPT ); Mon, 1 Feb 2021 13:18:29 -0500 Received: from mga02.intel.com ([134.134.136.20]:7666 "EHLO mga02.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232208AbhBASPO (ORCPT ); Mon, 1 Feb 2021 13:15:14 -0500 IronPort-SDR: gYmzzTCOXInQz9w0W9ZGOuO5HSpTip0kZLnybGdLsZt+cWafk1QK+M87PB0SCUB85LE4tXpw0n xs5vuN+aVKWg== X-IronPort-AV: E=McAfee;i="6000,8403,9882"; a="167833497" X-IronPort-AV: E=Sophos;i="5.79,393,1602572400"; d="scan'208";a="167833497" Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by orsmga101.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 01 Feb 2021 10:13:21 -0800 IronPort-SDR: GhejXAFevh58ldyZmFLRdCBJ1GI5sKz2A0q9xIOWgmDmIhM+m5E1DC1qWm+ecEpW5SWFb1q3/q nryH6bHsZecQ== X-IronPort-AV: E=Sophos;i="5.79,393,1602572400"; d="scan'208";a="412516898" Received: from dkhaldi-mobl1.amr.corp.intel.com (HELO [10.212.126.61]) ([10.212.126.61]) by fmsmga002-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 01 Feb 2021 10:13:20 -0800 Subject: Re: [PATCH 1/3] soundwire: bus: clear bus clash interrupt before the mask is enabled To: Vinod Koul , Bard Liao Cc: alsa-devel@alsa-project.org, gregkh@linuxfoundation.org, linux-kernel@vger.kernel.org, ranjani.sridharan@linux.intel.com, hui.wang@canonical.com, srinivas.kandagatla@linaro.org, jank@cadence.com, sanyog.r.kale@intel.com, rander.wang@linux.intel.com, bard.liao@intel.com References: <20210126083746.3238-1-yung-chuan.liao@linux.intel.com> <20210126083746.3238-2-yung-chuan.liao@linux.intel.com> <20210201102844.GU2771@vkoul-mobl> <20210201103825.GV2771@vkoul-mobl> From: Pierre-Louis Bossart Message-ID: <7c4e1163-a6b3-2886-1963-7e2847dc2836@linux.intel.com> Date: Mon, 1 Feb 2021 10:18:00 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <20210201103825.GV2771@vkoul-mobl> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2/1/21 4:38 AM, Vinod Koul wrote: > On 01-02-21, 15:58, Vinod Koul wrote: >> On 26-01-21, 16:37, Bard Liao wrote: > >>> struct sdw_master_prop { >>> u32 revision; >>> @@ -421,8 +422,11 @@ struct sdw_master_prop { >>> u32 err_threshold; >>> u32 mclk_freq; >>> bool hw_disabled; >>> + u32 quirks; >> >> Can we do u64 here please.. I dont know where we would end up.. but >> would hate if we start running out of space .. No objection. > Also, is the sdw_master_prop right place for a 'quirk' property. I think > we can use sdw_master_device or sdw_bus as this seems like a bus > quirk..? It's already part of sdw_bus struct sdw_bus { struct device *dev; struct sdw_master_device *md; unsigned int link_id; int id; struct list_head slaves; DECLARE_BITMAP(assigned, SDW_MAX_DEVICES); struct mutex bus_lock; struct mutex msg_lock; int (*compute_params)(struct sdw_bus *bus); const struct sdw_master_ops *ops; const struct sdw_master_port_ops *port_ops; struct sdw_bus_params params; struct sdw_master_prop prop; The quirks could be set by a firmware property, and it seems logical to add them at the same place where we already have properties defined in firmware, no? That way all the standard, vendor-specific and quirks are read or added in the same place. the sdw_master_device isn't a good place for quirks IMHO, it's a very shallow software-only layer without any existing ties to the hardware definition.