All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Rojewski, Cezary" <cezary.rojewski@intel.com>
To: "gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>
Cc: "pierre-louis.bossart@linux.intel.com"
	<pierre-louis.bossart@linux.intel.com>,
	"alsa-devel@alsa-project.org" <alsa-devel@alsa-project.org>,
	"andriy.shevchenko@linux.intel.com"
	<andriy.shevchenko@linux.intel.com>,
	"Kaczmarski, Filip" <filip.kaczmarski@intel.com>,
	"N, Harshapriya" <harshapriya.n@intel.com>,
	"Barlik, Marcin" <marcin.barlik@intel.com>,
	"zwisler@google.com" <zwisler@google.com>,
	"lgirdwood@gmail.com" <lgirdwood@gmail.com>,
	"tiwai@suse.com" <tiwai@suse.com>,
	"Proborszcz, Filip" <filip.proborszcz@intel.com>,
	"broonie@kernel.org" <broonie@kernel.org>,
	"amadeuszx.slawinski@linux.intel.com"
	<amadeuszx.slawinski@linux.intel.com>,
	"Wasko, Michal" <michal.wasko@intel.com>,
	"cujomalainey@chromium.org" <cujomalainey@chromium.org>,
	"Hejmowski, Krzysztof" <krzysztof.hejmowski@intel.com>,
	"Papierkowski, Piotr \(Habana\)" <ppapierkowski@habana.ai>,
	"Gopal,  Vamshi Krishna" <vamshi.krishna.gopal@intel.com>
Subject: RE: [PATCH v6 09/14] ASoC: Intel: catpt: Simple sysfs attributes
Date: Mon, 21 Sep 2020 21:13:04 +0000	[thread overview]
Message-ID: <8c5e5cec31aa4fefb6efa63a3caace0a@intel.com> (raw)
In-Reply-To: <20200921083514.GA3151537@kroah.com>

On 2020-09-21 10:35 AM, gregkh@linuxfoundation.org wrote:
> On Sun, Sep 20, 2020 at 05:03:00PM +0000, Rojewski, Cezary wrote:
>> On 2020-09-19 4:42 PM, gregkh@linuxfoundation.org wrote:
>>> On Fri, Sep 18, 2020 at 03:22:13PM +0000, Rojewski, Cezary wrote:
...

>>
>> Well, that's just one device driver targeting basically single device
>> available in two flavors. Lack of Documentation/ABI/<sysfs-doc> for
>> solution has been noted though. Will add in v7. As this device is
>> available on /sys/bus/pci0000:00/<dev> is the name for upcoming file:
>> sysfs-bus-pci-devices-catpt ok? Or, would you prevent a different, more
>> explicit one?
> 
> Why are you putting random driver-specific attributes on a device owned
> by a different bus?  That can cause problems if you are not careful.
> 
> Does the SoC core not provide you with a sound device to do this for
> instead?
> 

I know not about any device that ASoC core provides for me for such
tasks.

And the confusion about ADSP device location stems from incomplete
description coming from ACPI tables. I've had a quite lengthy discussion
about this with Andy.
Re: [PATCH v4 02/13] ASoC: Intel: catpt: Define DSP operations
https://www.spinics.net/lists/alsa-devel/msg114651.html

>>
...

>>>
>>> Why are you calling a specific function to do all of this?  Why not
>>> provide a default_groups pointer which allows the driver core to
>>> automatically create/destroy the sysfs files for you in a race-free
>>> manner with userspace?
>>>
>>> That's the recommended way, you should never have to manually create
>>> files.
>>>
>>>
>>
>> Thanks, that's something new. As this is simple device-driver, I believe
>> you meant usage of sysfs_(add|remove)_group() or their "device"
>> equivalents: device_(add|remove)_group(), is that correct? Haven't found
>> any usage of default_group within /sound/ subsystem what cannot be said
>> about the functions I've just mentioned.
>>
>> Feel free to correct me if I'm wrong about this.
> 
> The bus should provide you with the ability to do this, so look into
> that for your driver.
> 
> But why are you creating a binary sysfs file?  That's only for passing
> data raw through the kernel to/from the hardware, with no
> parsing/massaging possible.  Is that what is happening here?
> 
> I guess if there was documentation, it would be easier to review :)
> 
> thanks,
> 
> greg k-h
> 

In v7 I've removed the binary sysfs file, plus the organization has been
simplified - made use of struct device_driver's 'dev_groups' field to
automate creation/ removal process of sysfs files as requested.
Documentation has too been added so things should be clearer.

Thanks,
Czarek


  reply	other threads:[~2020-09-21 21:14 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-17 14:12 [PATCH v6 00/14] ASoC: Intel: Catpt - Lynx and Wildcat point Cezary Rojewski
2020-09-17 14:12 ` [PATCH v6 01/14] ASoC: Intel: Add catpt base members Cezary Rojewski
2020-09-17 14:12 ` [PATCH v6 02/14] ASoC: Intel: catpt: Implement IPC protocol Cezary Rojewski
2020-09-17 14:12 ` [PATCH v6 03/14] ASoC: Intel: catpt: Add IPC message handlers Cezary Rojewski
2020-09-17 14:12 ` [PATCH v6 04/14] ASoC: Intel: catpt: Define DSP operations Cezary Rojewski
2020-09-17 14:12 ` [PATCH v6 05/14] ASoC: Intel: catpt: Firmware loading and context restore Cezary Rojewski
2020-09-17 14:12 ` [PATCH v6 06/14] ASoC: Intel: catpt: PCM operations Cezary Rojewski
2020-09-17 14:12 ` [PATCH v6 07/14] ASoC: Intel: catpt: Device driver lifecycle Cezary Rojewski
2020-09-17 14:12 ` [PATCH v6 08/14] ASoC: Intel: catpt: Event tracing Cezary Rojewski
2020-09-17 14:12 ` [PATCH v6 09/14] ASoC: Intel: catpt: Simple sysfs attributes Cezary Rojewski
2020-09-18 15:22   ` Rojewski, Cezary
2020-09-19 14:42     ` gregkh
2020-09-20 17:03       ` Rojewski, Cezary
2020-09-21  8:09         ` andriy.shevchenko
2020-09-21  8:35         ` gregkh
2020-09-21 21:13           ` Rojewski, Cezary [this message]
2020-09-17 14:12 ` [PATCH v6 10/14] ASoC: Intel: Select catpt and deprecate haswell Cezary Rojewski
2020-09-17 14:12 ` [PATCH v6 11/14] ASoC: Intel: haswell: Remove haswell-solution specific code Cezary Rojewski
2020-09-17 14:12 ` [PATCH v6 12/14] ASoC: Intel: broadwell: " Cezary Rojewski
2020-09-17 14:12 ` [PATCH v6 13/14] ASoC: Intel: bdw-5650: " Cezary Rojewski
2020-09-17 14:12 ` [PATCH v6 14/14] ASoC: Intel: bdw-5677: " Cezary Rojewski
2020-09-17 14:57 ` [PATCH v6 00/14] ASoC: Intel: Catpt - Lynx and Wildcat point Andy Shevchenko
2020-09-17 15:52   ` Rojewski, Cezary
2020-09-18 13:55 ` Andy Shevchenko

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=8c5e5cec31aa4fefb6efa63a3caace0a@intel.com \
    --to=cezary.rojewski@intel.com \
    --cc=alsa-devel@alsa-project.org \
    --cc=amadeuszx.slawinski@linux.intel.com \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=broonie@kernel.org \
    --cc=cujomalainey@chromium.org \
    --cc=filip.kaczmarski@intel.com \
    --cc=filip.proborszcz@intel.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=harshapriya.n@intel.com \
    --cc=krzysztof.hejmowski@intel.com \
    --cc=lgirdwood@gmail.com \
    --cc=marcin.barlik@intel.com \
    --cc=michal.wasko@intel.com \
    --cc=pierre-louis.bossart@linux.intel.com \
    --cc=ppapierkowski@habana.ai \
    --cc=tiwai@suse.com \
    --cc=vamshi.krishna.gopal@intel.com \
    --cc=zwisler@google.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.