linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Mark Brown <broonie@kernel.org>
To: Hardik Shah <hardik.t.shah@intel.com>
Cc: alsa-devel@alsa-project.org, linux-kernel@vger.kernel.org,
	tiwai@suse.de, pierre-louis.bossart@linux.intel.com,
	lgirdwood@gmail.com, plai@codeaurora.org,
	patches.audio@intel.com, Sanyog Kale <sanyog.r.kale@intel.com>
Subject: Re: [RFC 06/14] SoundWire: Add register/unregister APIs
Date: Mon, 14 Nov 2016 13:37:51 +0000	[thread overview]
Message-ID: <20161114133751.kqjgrtc7y2ltwbe7@sirena.org.uk> (raw)
In-Reply-To: <1477053673-16021-7-git-send-email-hardik.t.shah@intel.com>

[-- Attachment #1: Type: text/plain, Size: 3306 bytes --]

On Fri, Oct 21, 2016 at 06:11:04PM +0530, Hardik Shah wrote:

> +static void sdw_mstr_release(struct device *dev)
> +{
> +	struct sdw_master *mstr = to_sdw_master(dev);
> +
> +	complete(&mstr->slv_released_complete);
> +}

Other buses don't do this...  this is a big warning sign that you're
abusing the driver model.

> +/**
> + * sdw_slv_verify - return parameter as sdw_slave, or NULL
> + * @dev: device, probably from some driver model iterator
> + *
> + * When traversing the driver model tree, perhaps using driver model
> + * iterators like @device_for_each_child(), you can't assume very much
> + * about the nodes you find. Use this function to avoid oopses caused
> + * by wrongly treating some non-SDW device as an sdw_slave.
> + */

This is also *very* scary, especially given that there's no analysis
presented as to why there might be random other things on the bus.  Why
does SoundWire need this when other buses don't?

> +static struct sdw_slave *sdw_slv_verify(struct device *dev)
> +{
> +	return (dev->type == &sdw_slv_type)
> +			? to_sdw_slave(dev)
> +			: NULL;

This is needlessly obfuscated, if you want to write an if statement
write an if statement.

> +static int sdw_slv_match(struct device *dev, struct device_driver *driver)
> +{
> +	struct sdw_slave *sdw_slv;
> +	struct sdw_driver *sdw_drv = to_sdw_driver(driver);
> +	struct sdw_slave_driver *drv;
> +	int ret = 0;
> +
> +
> +	if (sdw_drv->driver_type != SDW_DRIVER_TYPE_SLAVE)
> +		return ret;

Why do we need a check like this?

> +static int sdw_mstr_probe(struct device *dev)
> +{
> +	const struct sdw_master_driver *sdrv =
> +					to_sdw_master_driver(dev->driver);
> +	struct sdw_master *mstr = to_sdw_master(dev);
> +	int ret;
> +
> +	ret = dev_pm_domain_attach(dev, true);
> +
> +	if (ret != -EPROBE_DEFER) {
> +		ret = sdrv->probe(mstr, sdw_match_mstr(sdrv->id_table, mstr));
> +		if (ret < 0)
> +			dev_pm_domain_detach(dev, true);
> +	}

This looks *very* broken.  Surely if we fail to attach a pm_domain for
any reason other than one not being there to attach we shouldn't be
trying to probe the device?

> +EXPORT_SYMBOL_GPL(snd_sdw_master_register_driver);

This is EXPORT_SYMBOL_GPL() but the bus itself is dual licensed GPL/BSD
- seems a bit inconsistent.

> +/**
> + * snd_sdw_master_add: Registers the SoundWire Master interface. This needs
> + *	to be called for each Master interface supported by SoC. This
> + *	represents One clock and data line (Optionally multiple data lanes)
> + *	of Master interface.
> + *
> + * @master: the Master to be added.
> + */
> +int snd_sdw_master_add(struct sdw_master *master)

This lies at the heart of the issues that seem to exist with the misuse
of the driver model in this code.  Normally what we see is that the
controller would instantiate as whatever bus type the controller is
attached by (typically a PCI or platform device) and then it wouild
register a bus with the bus subsystem which would then instantiate
slaves.  Instead we have this system where the bus is registered by
something in the system and then the master is a driver on the bus
parallel to the slaves but with a separate driver type that causes
confusion.  Without having seen a master driver it's not even clear how
this is going to work and allow the master to talk to its own hardware.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 455 bytes --]

  reply	other threads:[~2016-11-14 13:38 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-10-21 12:40 [RFC 00/14] SoundWire bus driver Hardik Shah
2016-10-21 12:40 ` [RFC 01/14] SoundWire: Add SoundWire bus driver documentation Hardik Shah
2016-11-14 14:15   ` Charles Keepax
2016-11-15 14:29     ` Vinod Koul
2016-11-16 17:59       ` Mark Brown
2016-11-17  5:05         ` Vinod Koul
2016-10-21 12:41 ` [RFC 02/14] SoundWire: Add SoundWire stream documentation Hardik Shah
2016-11-14 15:31   ` Charles Keepax
2016-11-14 16:50     ` Pierre-Louis Bossart
2016-11-14 17:04       ` Charles Keepax
2016-10-21 12:41 ` [RFC 03/14] SoundWire: Add error handling and locking documentation Hardik Shah
2016-11-14 15:44   ` Charles Keepax
2016-11-15 14:42     ` Vinod Koul
2016-10-21 12:41 ` [RFC 04/14] SoundWire: Add device_id table for SoundWire bus Hardik Shah
2016-10-21 12:41 ` [RFC 05/14] SoundWire: Add SoundWire bus driver interfaces Hardik Shah
2016-11-14 13:17   ` Mark Brown
2016-11-14 17:28     ` [alsa-devel] " Pierre-Louis Bossart
2016-10-21 12:41 ` [RFC 06/14] SoundWire: Add register/unregister APIs Hardik Shah
2016-11-14 13:37   ` Mark Brown [this message]
2016-11-15 13:55     ` Vinod Koul
2016-10-21 12:41 ` [RFC 07/14] SoundWire: Add SoundWire Slaves register definitions Hardik Shah
2016-10-21 12:41 ` [RFC 08/14] SoundWire: Add API for Slave registers read/write Hardik Shah
2016-10-21 12:41 ` [RFC 09/14] SoundWire: Add support to handle Slave status change Hardik Shah
2016-11-14 16:08   ` Charles Keepax
2016-11-14 17:38     ` [alsa-devel] " Pierre-Louis Bossart
2016-11-15  9:56       ` Charles Keepax
2016-10-21 12:41 ` [RFC 10/14] SoundWire: Add support for clock stop Hardik Shah
2016-10-21 12:41 ` [RFC 11/14] SoundWire: Add tracing for Slave register read/write Hardik Shah
2016-10-21 12:41 ` [RFC 12/14] regmap: SoundWire: Add regmap support for SoundWire bus Hardik Shah
2016-10-28 18:03   ` Mark Brown
2016-11-02  8:11     ` Hardik Shah
2016-10-21 12:41 ` [RFC 13/14] SoundWire: Add stream and port configuration Hardik Shah
2016-10-21 12:41 ` [RFC 14/14] SoundWire: Add support for SoundWire stream management Hardik Shah
2016-11-14 12:11 ` [RFC 00/14] SoundWire bus driver Mark Brown
2016-11-15 13:37   ` 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=20161114133751.kqjgrtc7y2ltwbe7@sirena.org.uk \
    --to=broonie@kernel.org \
    --cc=alsa-devel@alsa-project.org \
    --cc=hardik.t.shah@intel.com \
    --cc=lgirdwood@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=patches.audio@intel.com \
    --cc=pierre-louis.bossart@linux.intel.com \
    --cc=plai@codeaurora.org \
    --cc=sanyog.r.kale@intel.com \
    --cc=tiwai@suse.de \
    /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).