alsa-devel.alsa-project.org archive mirror
 help / color / mirror / Atom feed
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, linux-kernel@vger.kernel.org,
	Ranjani Sridharan <ranjani.sridharan@linux.intel.com>,
	broonie@kernel.org, srinivas.kandagatla@linaro.org,
	jank@cadence.com, slawomir.blauciak@intel.com,
	Sanyog Kale <sanyog.r.kale@intel.com>,
	Bard liao <yung-chuan.liao@linux.intel.com>,
	Rander Wang <rander.wang@linux.intel.com>
Subject: Re: [alsa-devel] [PATCH v5 09/17] soundwire: intel: remove platform devices and use 'Master Devices' instead
Date: Mon, 13 Jan 2020 10:48:00 +0530	[thread overview]
Message-ID: <20200113051800.GP2818@vkoul-mobl> (raw)
In-Reply-To: <39000dd7-3f77-bc33-0ad3-aa47ba2360f7@linux.intel.com>

On 10-01-20, 10:08, Pierre-Louis Bossart wrote:
> 
> > > > The "big" difference is that probe is called by core (asoc) and not by
> > > > driver onto themselves.. IMO that needs to go away.
> > > 
> > > What I did is not different from what existed already with platform devices.
> > > They were manually created, weren't they?
> > 
> > Manual creation of device based on a requirement is different, did I ask
> > you why you are creating device :)
> > 
> > I am simple asking you not to call probe in the driver. If you need
> > that, move it to core! We do not want these kind of things in the
> > drivers...
> 
> What core are you talking about?

soundwire core ofcourse! IMO All that which goes into soundwire-bus-objs is
considered as soundwire core part and rest are drivers intel, qc, so on!
> 
> The SOF intel driver needs to create a device, which will then be bound with
> a SoundWire master driver.
> 
> What I am doing is no different from what your team did with
> platform_register_device, I am really lost on what you are asking.

Again repeating myself, you call an API to do that is absolutely fine,
but we don't do that in drivers or open code these things

> > > > > FWIW, the implementation here follows what was suggested for Greybus 'Host
> > > > > Devices' [1] [2], so it's not like I am creating any sort of dangerous
> > > > > precedent.
> > > > > 
> > > > > [1]
> > > > > https://elixir.bootlin.com/linux/latest/source/drivers/greybus/es2.c#L1275
> > > > > [2] https://elixir.bootlin.com/linux/latest/source/drivers/greybus/hd.c#L124
> > > > 
> > > > And if you look closely all this work is done by core not by drivers!
> > > > Drivers _should_ never do all this, it is the job of core to do that for
> > > > you.
> > > 
> > > Please look at the code again, you have a USB probe that will manually call
> > > the GreyBus device creation.
> > > 
> > > static int ap_probe(struct usb_interface *interface,
> > > 		    const struct usb_device_id *id)
> > > {
> > > 	hd = gb_hd_create(&es2_driver, &udev->dev, 	
> > > 
> > > 
> > > static struct usb_driver es2_ap_driver = {
> > > 	.name =		"es2_ap_driver",
> > > 	.probe =	ap_probe, <<< code above
> > > 	.disconnect =	ap_disconnect,
> > > 	.id_table =	id_table,
> > > 	.soft_unbind =	1,
> > > };
> > 
> > Look closely the driver es2 calls into greybus core hd.c and gets the
> > work done, subtle but a big differances in the approaches..
> 
> I am sorry, I have absolutely no idea what you are referring to.
> 
> The code I copy/pasted here makes no call to the greybus core, it's ap_probe
> -> gb_hd_create. No core involved. If I am mistaken, please show me what I
> got wrong.

1. es2_ap_driver is host controller driver

2. gb_hd_create() is an API provided by greybus core!

es2 driver doesn't open code creation like you are doing in intel driver,
it doesn't call probe on its own, greybus does that

This is very common pattern in linux kernel subsytems, drivers dont do
these things, the respective subsystem core does that... see about es2
driver and implementation of gb_hd_create(). See callers of
platform_register_device() and its implementation.

I don't know how else I can explain this to you, is something wrong in
how I conveyed this info or you... or something else, I dont know!!!

-- 
~Vinod
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
https://mailman.alsa-project.org/mailman/listinfo/alsa-devel

  reply	other threads:[~2020-01-13  5:19 UTC|newest]

Thread overview: 47+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-17 21:02 [alsa-devel] [PATCH v5 00/17] soundwire: intel: implement new ASoC interfaces Pierre-Louis Bossart
2019-12-17 21:02 ` [alsa-devel] [PATCH v5 01/17] soundwire: renames to prepare support for master drivers/devices Pierre-Louis Bossart
2019-12-17 21:02 ` [alsa-devel] [PATCH v5 02/17] soundwire: rename dev_to_sdw_dev macro Pierre-Louis Bossart
2019-12-27  6:54   ` Vinod Koul
2019-12-17 21:03 ` [alsa-devel] [PATCH v5 03/17] soundwire: rename drv_to_sdw_slave_driver macro Pierre-Louis Bossart
2019-12-27  7:00   ` Vinod Koul
2019-12-27 23:23     ` Pierre-Louis Bossart
2019-12-28 12:03       ` Vinod Koul
2019-12-17 21:03 ` [alsa-devel] [PATCH v5 04/17] soundwire: bus_type: rename sdw_drv_ to sdw_slave_drv Pierre-Louis Bossart
2019-12-17 21:03 ` [alsa-devel] [PATCH v5 05/17] soundwire: intel: rename res field as link_res Pierre-Louis Bossart
2019-12-17 21:03 ` [alsa-devel] [PATCH v5 06/17] soundwire: add support for sdw_slave_type Pierre-Louis Bossart
2019-12-27  7:03   ` Vinod Koul
2019-12-27 23:26     ` Pierre-Louis Bossart
2019-12-28 12:05       ` Vinod Koul
2019-12-17 21:03 ` [alsa-devel] [PATCH v5 07/17] soundwire: slave: move uevent handling to slave device level Pierre-Louis Bossart
2019-12-17 21:03 ` [alsa-devel] [PATCH v5 08/17] soundwire: add initial definitions for sdw_master_device Pierre-Louis Bossart
2019-12-27  7:14   ` Vinod Koul
2019-12-27 23:38     ` Pierre-Louis Bossart
2019-12-28 12:09       ` Vinod Koul
2020-01-02 17:36         ` Pierre-Louis Bossart
2020-01-06  5:32           ` Vinod Koul
2019-12-17 21:03 ` [alsa-devel] [PATCH v5 09/17] soundwire: intel: remove platform devices and use 'Master Devices' instead Pierre-Louis Bossart
2019-12-27  9:08   ` Vinod Koul
2019-12-28  0:13     ` Pierre-Louis Bossart
2020-01-06  5:42       ` Vinod Koul
2020-01-06 14:51         ` Pierre-Louis Bossart
2020-01-10  6:43           ` Vinod Koul
2020-01-10 16:08             ` Pierre-Louis Bossart
2020-01-13  5:18               ` Vinod Koul [this message]
2020-01-13 15:22                 ` Pierre-Louis Bossart
2020-01-14  6:09   ` Vinod Koul
2020-01-14 16:01     ` Pierre-Louis Bossart
2020-01-18  7:12       ` Vinod Koul
2020-01-21 17:31         ` Pierre-Louis Bossart
2020-01-28 10:50           ` Vinod Koul
2020-01-28 16:02             ` Pierre-Louis Bossart
2020-01-29  5:08               ` Vinod Koul
2020-01-29 14:59                 ` Pierre-Louis Bossart
2020-02-03 12:02                   ` Vinod Koul
2019-12-17 21:03 ` [alsa-devel] [PATCH v5 10/17] soundwire: register master device driver Pierre-Louis Bossart
2019-12-17 21:03 ` [alsa-devel] [PATCH v5 11/17] soundwire: intel: add prepare support in sdw dai driver Pierre-Louis Bossart
2019-12-17 21:03 ` [alsa-devel] [PATCH v5 12/17] soundwire: intel: add trigger " Pierre-Louis Bossart
2019-12-17 21:03 ` [alsa-devel] [PATCH v5 13/17] soundwire: intel: add sdw_stream_setup helper for .startup callback Pierre-Louis Bossart
2019-12-17 21:03 ` [alsa-devel] [PATCH v5 14/17] soundwire: intel: free all resources on hw_free() Pierre-Louis Bossart
2019-12-17 21:03 ` [alsa-devel] [PATCH v5 15/17] soundwire: intel_init: add implementation of sdw_intel_enable_irq() Pierre-Louis Bossart
2019-12-17 21:03 ` [alsa-devel] [PATCH v5 16/17] soundwire: intel_init: use EXPORT_SYMBOL_NS Pierre-Louis Bossart
2019-12-17 21:03 ` [alsa-devel] [PATCH v5 17/17] soundwire: intel: " Pierre-Louis Bossart

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=20200113051800.GP2818@vkoul-mobl \
    --to=vkoul@kernel.org \
    --cc=alsa-devel@alsa-project.org \
    --cc=broonie@kernel.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=jank@cadence.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pierre-louis.bossart@linux.intel.com \
    --cc=rander.wang@linux.intel.com \
    --cc=ranjani.sridharan@linux.intel.com \
    --cc=sanyog.r.kale@intel.com \
    --cc=slawomir.blauciak@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).