From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751445AbdK0IBP (ORCPT ); Mon, 27 Nov 2017 03:01:15 -0500 Received: from mx0b-001ae601.pphosted.com ([67.231.152.168]:51228 "EHLO mx0b-001ae601.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751126AbdK0IBN (ORCPT ); Mon, 27 Nov 2017 03:01:13 -0500 Authentication-Results: ppops.net; spf=none smtp.mailfrom=ckeepax@opensource.cirrus.com Date: Mon, 27 Nov 2017 07:59:40 +0000 From: Charles Keepax To: Sanyog Kale CC: Vinod Koul , Greg Kroah-Hartman , LKML , ALSA , Mark , Takashi , Pierre , Shreyas NC , , , Sagar Dharia , , , Sudheer Papothi Subject: Re: [PATCH v2 04/14] soundwire: Add MIPI DisCo property helpers Message-ID: <20171127075940.euvjgjf6t5rimltp@localhost.localdomain> References: <1510314556-13002-1-git-send-email-vinod.koul@intel.com> <1510314556-13002-5-git-send-email-vinod.koul@intel.com> <20171123143812.braw737aciq4qmb7@localhost.localdomain> <20171124160448.GB11781@buildpc-HP-Z230> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <20171124160448.GB11781@buildpc-HP-Z230> User-Agent: NeoMutt/20170113 (1.7.2) X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=2 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1709140000 definitions=main-1711270112 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Nov 24, 2017 at 09:34:49PM +0530, Sanyog Kale wrote: > On Thu, Nov 23, 2017 at 02:38:12PM +0000, Charles Keepax wrote: > > On Fri, Nov 10, 2017 at 05:19:06PM +0530, Vinod Koul wrote: > > > > MIPI Discovery And Configuration (DisCo) Specification for SoundWire > > > specifies properties to be implemented for SoundWire Masters and > > > Slaves. The DisCo spec doesn't mandate these properties. However, > > > SDW bus cannot work without knowing these values. > > > > > > The helper functions read the Master and Slave properties. > > > Implementers of Master or Slave drivers can use any of the below > > > three mechanisms: > > > a) Use these APIs here as .read_prop() callback for Master > > > and Slave > > > b) Implement own methods and set those as .read_prop(), but invoke > > > APIs in this file for generic read and override the values with > > > platform specific data > > > c) Implement ones own methods which do not use anything provided > > > here > > > > > > Signed-off-by: Sanyog Kale > > > Signed-off-by: Vinod Koul > > > --- > > Apologies for the long and slightly vague comment, but I guess my > > question is do you have a thought on how drivers should know when > > it is safe to communicate with a SoundWire device? > > IMO it is safe to communicate with SoundWire device when the Slave > status is ATTACHED. In any case bus will report error if it is not able > to communicate with SoundWire device. > Yeah I guess my point here is that there is currently no way in this SoundWire framework for the slave driver to know if the device is attached or not, unless I am missing something? There are calls by which the master can inform the framework, but nothing to pass that on to the slave driver. I would indeed imagine the comms would fail if the slave isn't attached but that doesn't seem like a particularly robust way of determining that. Thanks, Charles