[PATCH v2 2/2] soundwire: sysfs: add slave status and device number before probe

[Vinod Koul]

On 18-09-20, 09:21, Pierre-Louis Bossart wrote:
> 
> 
> 
> > >    * Base file is device
> > >    *	|---- modalias
> > > + *	|---- dev-status
> > > + *		|---- status
> > > + *		|---- device_number
> > 
> > Any reason why we want this under dev-status.
> > 
> > Both the status and device_number belong to the device, so we can
> > put them under device and use device properties
> 
> We already use directories for device-level and port-level properties, I
> just thought it be cleaner to continue this model. We might also expand the
> information later on, e.g. provide interrupt status.

Right now we have directories for N ports (needs a dir due to nature of
N ports) and 'properties' derived from Disco/firmware.
So Nport and properties makes sense. But for generic device level stuff
like device number, status and future interrupt or anything should be at
device level.

> I don't mind if we remove the directory and move everything up one level,
> but it wouldn't be consistent with the previous work.

Just because we had directory for a reason, adding a directory to
conform to that does make it better. IMO device files should be at
device directory

> 
> > > +static ssize_t device_number_show(struct device *dev,
> > > +				  struct device_attribute *attr, char *buf)
> > > +{
> > > +	struct sdw_slave *slave = dev_to_sdw_dev(dev);
> > > +
> > > +	if (slave->status == SDW_SLAVE_UNATTACHED)
> > > +		return sprintf(buf, "%s", "N/A");
> > 
> > Do we really want N/A here, 0 should imply UNATTACHED and then the
> > status_show would tell UNATTACHED.
> 
> Actually no. If you look at the standard, 'Unattached' is an 'internal state
> of a Slave that indicates that it is not synchronized with to the Frame
> boundaries within the Bitstream'. A Slave device can only become attached
> and report it's presence as Device0 in a PING frame once it's ATTACHED -
> which in turn means the device has been able to sync for 15 frames. A device
> number of zero means the device is able to respond to command but has not
> yet been enumerated, or was enumerated previously but lost sync or went
> through a reset sequence and reattached. A device number of zero does not
> mean the device is unattached, the logic is as follow:
> 
> Attached -> Device 0 or 1..11
> Unattached -> No concept of device number (or not an observable value).
> 
> We should not overload what 'Device0' means and instead follow the standard
> to the letter. We also don't want the attribute to come and go dynamically,
> so N/A (Not Applicable) is IMHO the only way to convey this meaning.
> 
> Does this help?

Ok lets retain this.

-- 
~Vinod