From: Vinod Koul <vkoul@kernel.org>
To: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Cc: yung-chuan.liao@linux.intel.com, sanyog.r.kale@intel.com,
Srinivas Kandagatla <srinivas.kandagatla@linaro.org>,
alsa-devel@alsa-project.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] soundwire: bus: add enumerated slave to device list
Date: Fri, 11 Sep 2020 11:08:14 +0530 [thread overview]
Message-ID: <20200911053814.GT77521@vkoul-mobl> (raw)
In-Reply-To: <f3880470-cdc4-7b84-97a1-303f9a95d3f4@linux.intel.com>
On 10-09-20, 09:02, Pierre-Louis Bossart wrote:
>
> > > > May be we could make the enumerated devices discovery bit more verbose!
> > >
> > > Maybe adding a device number sysfs entry would help, e.g. reporting
> > > NotAttched or a value in [0,11] would tell you if the device is actually
> > > present.
> >
> > Agreed, I cooked this patch to report verbose device status, let me know
> > if you are okay with this. I think this would be useful regardless of
> > current discussion.
> >
> > On Db845c I see:
> >
> > root@linaro-alip:/sys/bus/soundwire/devices# cat sdw:0:217:2010:0:1/status
> > Attached
> > root@linaro-alip:/sys/bus/soundwire/devices# cat sdw:0:217:2010:0:2/status
> > Attached
>
> looks like we are all aligned on the idea, I have a similar patch to at
> https://github.com/thesofproject/linux/pull/2426
>
> The difference is that the sysfs status and device_number is added even
> without a driver probe and when there's no firmware description. sysfs is
> currently only added after the driver probe, which wouldn't work for the
> case Srinivas was trying to deal with.
Okay sound fine
> but the way you dealt the status below is better than the switch case I
> used, so will merge this into my code.
Why merge? That patch can remain independent and you can add
device_number patch on top and another one for moving sysfs creation
without a driver probe, these three sound like three different patches
to me.
> Srinivas' patch needs a fix for ACPI platforms, won't probe otherwise since
> we don't have an of_node. If that's alright with everyone I can submit a
> patchset that gathers the 3 contributions.
Yes one series should be good, but lets keep one change in a patch
please
--
~Vinod
prev parent reply other threads:[~2020-09-11 5:38 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-09 8:27 Srinivas Kandagatla
2020-09-09 13:37 ` Pierre-Louis Bossart
2020-09-09 14:09 ` Srinivas Kandagatla
2020-09-09 14:39 ` Pierre-Louis Bossart
2020-09-09 15:54 ` Srinivas Kandagatla
2020-09-09 17:00 ` Pierre-Louis Bossart
2020-09-10 8:56 ` Vinod Koul
2020-09-10 14:02 ` Pierre-Louis Bossart
2020-09-11 5:38 ` Vinod Koul [this message]
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=20200911053814.GT77521@vkoul-mobl \
--to=vkoul@kernel.org \
--cc=alsa-devel@alsa-project.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pierre-louis.bossart@linux.intel.com \
--cc=sanyog.r.kale@intel.com \
--cc=srinivas.kandagatla@linaro.org \
--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
all inboxes | Powered by JetHome®