public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Heikki Krogerus <heikki.krogerus@linux.intel.com>
To: Lu Baolu <baolu.lu@linux.intel.com>
Cc: felipe.balbi@linux.intel.com,
	Mathias Nyman <mathias.nyman@intel.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Lee Jones <lee.jones@linaro.org>,
	Liam Girdwood <lgirdwood@gmail.com>,
	Mark Brown <broonie@kernel.org>,
	linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v8 2/7] usb: mux: add generic code for dual role port mux
Date: Wed, 25 May 2016 14:06:52 +0300	[thread overview]
Message-ID: <20160525110652.GA27570@kuha.fi.intel.com> (raw)
In-Reply-To: <1462426383-3949-3-git-send-email-baolu.lu@linux.intel.com>

Hi Baolu,

Sorry to comment this so late, but we got hardware that needs to
configure the mux in OS, and I noticed some problem. We are missing
means to bind a port to the correct mux on multiport systems. That we
need to solve later in any case, but there is an other issue related
to the fact that the notifiers now have to be extcon devices. It's
related, as extcon offers no means to solve the multiport issue, but
in any case..

> +struct portmux_dev *portmux_register(struct portmux_desc *desc)
> +{
> +	static atomic_t portmux_no = ATOMIC_INIT(-1);
> +	struct portmux_dev *pdev;
> +	struct extcon_dev *edev = NULL;
> +	struct device *dev;
> +	int ret;
> +
> +	/* parameter sanity check */
> +	if (!desc || !desc->name || !desc->ops || !desc->dev ||
> +	    !desc->ops->cable_set_cb || !desc->ops->cable_unset_cb)
> +		return ERR_PTR(-EINVAL);
> +
> +	dev = desc->dev;
> +
> +	if (desc->extcon_name) {
> +		edev = extcon_get_extcon_dev(desc->extcon_name);
> +		if (IS_ERR_OR_NULL(edev))
> +			return ERR_PTR(-EPROBE_DEFER);
> +	}
> +
> +	pdev = kzalloc(sizeof(*pdev), GFP_KERNEL);
> +	if (!pdev)
> +		return ERR_PTR(-ENOMEM);
> +
> +	pdev->desc = desc;
> +	pdev->edev = edev;
> +	pdev->nb.notifier_call = usb_mux_notifier;
> +	mutex_init(&pdev->mux_mutex);
> +
> +	pdev->dev.parent = dev;
> +	dev_set_name(&pdev->dev, "portmux.%lu",
> +		     (unsigned long)atomic_inc_return(&portmux_no));
> +	pdev->dev.groups = portmux_group;
> +	ret = device_register(&pdev->dev);
> +	if (ret)
> +		goto cleanup_mem;
> +
> +	dev_set_drvdata(&pdev->dev, pdev);
> +
> +	if (edev) {
> +		ret = extcon_register_notifier(edev, EXTCON_USB_HOST,
> +					       &pdev->nb);
> +		if (ret < 0) {
> +			dev_err(dev, "failed to register extcon notifier\n");
> +			goto cleanup_dev;
> +		}
> +	}

So I don't actually think this is correct approach. We are forcing the
notifying drivers, on top of depending on this framework, depend on
extcon too, and that simply is too much. I don't think a USB PHY or
charger detection driver should be forced to generate an extcon device
just to satisfy the mux in general.

Instead IMO, this framework should provide an API also for the
notifiers. The drivers that do the notification should not need to
depend on extcon at all. Instead they should be able to just request
an optional handle to a portmux, and use it with the function that you
already provide (usb_mux_change_state(), which of course needs to be
exported). That would make it much easier for us to make problems like
figuring out the correct mux for the correct port a problem for the
framework and not the drivers.

extcon does not really add any value here, but it does complicate
things a lot. We are even exposing new sysfs attributes to control the
mux, complete separate from extcon.


Thanks,

-- 
heikki

  reply	other threads:[~2016-05-25 11:07 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-05-05  5:32 [PATCH v8 0/7] usb: add support for Intel dual role port mux Lu Baolu
2016-05-05  5:32 ` [PATCH v8 1/7] regulator: fixed: add support for ACPI interface Lu Baolu
2016-05-13 11:17   ` Mark Brown
2016-05-16  1:00     ` Lu Baolu
2016-05-05  5:32 ` [PATCH v8 2/7] usb: mux: add generic code for dual role port mux Lu Baolu
2016-05-25 11:06   ` Heikki Krogerus [this message]
2016-05-26  1:03     ` Lu Baolu
2016-05-27  8:00       ` Heikki Krogerus
2016-05-27  8:07         ` Lu Baolu
2016-05-05  5:32 ` [PATCH v8 3/7] usb: mux: add driver for Intel gpio controlled " Lu Baolu
2016-05-05  5:33 ` [PATCH v8 4/7] usb: mux: add driver for Intel drcfg " Lu Baolu
2016-05-05  5:33 ` [PATCH v8 5/7] mfd: intel_vuport: Add Intel virtual USB port MFD Driver Lu Baolu
2016-05-09 14:26   ` Lee Jones
2016-05-05  5:33 ` [PATCH v8 6/7] usb: pci-quirks: add Intel USB drcfg mux device Lu Baolu
2016-05-05  5:33 ` [PATCH v8 7/7] MAINTAINERS: add maintainer entry for Intel USB dual role mux drivers Lu Baolu

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=20160525110652.GA27570@kuha.fi.intel.com \
    --to=heikki.krogerus@linux.intel.com \
    --cc=baolu.lu@linux.intel.com \
    --cc=broonie@kernel.org \
    --cc=felipe.balbi@linux.intel.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=lee.jones@linaro.org \
    --cc=lgirdwood@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=mathias.nyman@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