linux-kernel - Re: [PATCH] soundwire: bus: add enumerated slave to device list

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20200911053814.GT77521@vkoul-mobl>
Date:   Fri, 11 Sep 2020 11:08:14 +0530
From:   Vinod Koul <vkoul@...nel.org>
To:     Pierre-Louis Bossart <pierre-louis.bossart@...ux.intel.com>
Cc:     yung-chuan.liao@...ux.intel.com, sanyog.r.kale@...el.com,
        Srinivas Kandagatla <srinivas.kandagatla@...aro.org>,
        alsa-devel@...a-project.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] soundwire: bus: add enumerated slave to device list

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@...aro-alip:/sys/bus/soundwire/devices# cat sdw:0:217:2010:0:1/status
> > Attached
> > root@...aro-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