From: Vinod Koul <vkoul@kernel.org>
To: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Cc: alsa-devel@alsa-project.org, tiwai@suse.de,
gregkh@linuxfoundation.org, broonie@kernel.org,
srinivas.kandagatla@linaro.org,
Bard liao <yung-chuan.liao@linux.intel.com>,
Rander Wang <rander.wang@linux.intel.com>
Subject: Re: [PATCH v2 2/2] soundwire: sysfs: add slave status and device number before probe
Date: Sat, 19 Sep 2020 16:49:11 +0530 [thread overview]
Message-ID: <20200919111911.GW2968@vkoul-mobl> (raw)
In-Reply-To: <c8729c1d-6d36-ad34-34c3-899ba0f5366d@linux.intel.com>
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
next prev parent reply other threads:[~2020-09-19 11:20 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-17 16:00 [PATCH v2 0/2] soundwire: sysfs: expose device number and status Pierre-Louis Bossart
2020-09-17 16:00 ` [PATCH v2 1/2] soundwire: bus: add enumerated Slave device to device list Pierre-Louis Bossart
2020-09-18 12:05 ` Vinod Koul
2020-09-18 13:54 ` Pierre-Louis Bossart
2020-09-19 11:13 ` Vinod Koul
2020-09-17 16:00 ` [PATCH v2 2/2] soundwire: sysfs: add slave status and device number before probe Pierre-Louis Bossart
2020-09-17 16:36 ` Greg KH
2020-09-18 12:16 ` Vinod Koul
2020-09-18 14:21 ` Pierre-Louis Bossart
2020-09-19 11:19 ` Vinod Koul [this message]
2020-09-21 14:34 ` Pierre-Louis Bossart
2020-09-23 10:03 ` Vinod Koul
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200919111911.GW2968@vkoul-mobl \
--to=vkoul@kernel.org \
--cc=alsa-devel@alsa-project.org \
--cc=broonie@kernel.org \
--cc=gregkh@linuxfoundation.org \
--cc=pierre-louis.bossart@linux.intel.com \
--cc=rander.wang@linux.intel.com \
--cc=srinivas.kandagatla@linaro.org \
--cc=tiwai@suse.de \
--cc=yung-chuan.liao@linux.intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).