From: Lu Baolu <baolu.lu@linux.intel.com>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Felipe Balbi <balbi@kernel.org>,
Mathias Nyman <mathias.nyman@intel.com>,
Lee Jones <lee.jones@linaro.org>,
Heikki Krogerus <heikki.krogerus@linux.intel.com>,
MyungJoo Ham <myungjoo.ham@samsung.com>,
Chanwoo Choi <cw00.choi@samsung.com>,
linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3 3/7] usb: mux: add common code for Intel dual role port mux
Date: Wed, 6 Apr 2016 14:44:55 +0800 [thread overview]
Message-ID: <5704B067.1010001@linux.intel.com> (raw)
In-Reply-To: <20160314032714.GA4665@kroah.com>
Hi,
On 03/14/2016 11:27 AM, Greg Kroah-Hartman wrote:
> On Mon, Mar 14, 2016 at 09:09:22AM +0800, Lu Baolu wrote:
>> On 03/11/2016 08:06 AM, Greg Kroah-Hartman wrote:
>>> On Tue, Mar 08, 2016 at 03:53:44PM +0800, Lu Baolu wrote:
>>>> +struct intel_mux_dev {
>>>> + struct device *dev;
>>>> + char *extcon_name;
>>>> + char *cable_name;
>>>> + int (*cable_set_cb)(struct intel_mux_dev *mux);
>>>> + int (*cable_unset_cb)(struct intel_mux_dev *mux);
>>>> +};
>>> This is a device, why not make it one? Don't just hold a reference.
>>> And do you really even hold that reference?
>> It's not a device. It's just an encapsulation for parameters passed into
>> intel_usb_mux_register().
> But you called it a device, so you can understand my confusion.
>
> And why not make it a device? Why isn't this one? Hint, I really think
> it should be...
>
>>> And your api is horrid, think about what you want the "core" to do here,
>>> it should be the one creating the device and returning it to the caller,
>>> not forcing the caller to somehow create it first and then pass it in.
>> This isn't a layer or core. It doesn't create any new devices. It's actually
>> some shared code which can be used by all Intel dual role port drivers.
> It should be a device, as you are treating it like one :)
>
>> I put it in a separated file because 1) this can avoid duplication; 2) this code
>> could be used for any architectures as long as a USB port is shared by
>> two components and it needs an OS response when event triggers.
> It's a bit hard for other arches to be using something called "intel_"
> :(
Are there any other implementations which need an external mux
to swap the usb roles?
>> I guess intel_usb_mux_register/unregister() is a bit misleading. How about
>> changing them to intel_usb_mux_probe/remove()?
> You are going to probe/remove something that isn't a device? Come on
> now...
>
>>> And why is it not symmetrical, you are passing one thing into register
>>> and another into unregister.
>> struct intel_mux_dev is an encapsulation for parameters passed into
>> intel_usb_mux_register().
> Which is a device.
>
>> It's not a new device structure though the name
>> is a bit misleading.
> Yes it is, hint, you want it to be a device.
>
>> How about remove this structure and put these in function parameters?
> How about making it a real device? :)
Hi Greg,
Just want to make myself clear about your expectation.
Did you mean to create a port mux device and return it to the caller?
The interfaces look like:
struct portmux_dev *devm_portmux_register(struct device *dev,
const struct portmux_desc *desc);
void devm_portmux_unregister(struct device *dev,
struct portmux_dev *pdev)
Do I get it right?
Best regards,
Baolu
>
> thanks,
>
> greg k-h
>
next prev parent reply other threads:[~2016-04-06 6:45 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-08 7:53 [PATCH v3 0/7] usb: add support for Intel dual role port mux Lu Baolu
2016-03-08 7:53 ` [PATCH v3 1/7] extcon: usb-gpio: add device binding for platform device Lu Baolu
2016-03-08 7:53 ` [PATCH v3 2/7] extcon: usb-gpio: add support for ACPI gpio interface Lu Baolu
2016-03-08 7:53 ` [PATCH v3 3/7] usb: mux: add common code for Intel dual role port mux Lu Baolu
2016-03-10 12:39 ` Oliver Neukum
2016-03-10 23:57 ` Greg Kroah-Hartman
2016-03-11 0:40 ` Lu Baolu
2016-04-06 5:58 ` Lu Baolu
2016-04-06 9:29 ` Greg Kroah-Hartman
2016-04-06 10:19 ` Felipe Balbi
2016-04-07 0:07 ` Greg Kroah-Hartman
2016-04-07 5:00 ` Felipe Balbi
2016-03-11 0:06 ` Greg Kroah-Hartman
2016-03-14 1:09 ` Lu Baolu
2016-03-14 3:27 ` Greg Kroah-Hartman
2016-03-14 7:35 ` Lu Baolu
2016-04-06 6:44 ` Lu Baolu [this message]
2016-04-06 9:28 ` Greg Kroah-Hartman
2016-04-06 10:23 ` Felipe Balbi
2016-04-06 12:40 ` Sergei Shtylyov
2016-03-08 7:53 ` [PATCH v3 4/7] usb: mux: add driver for Intel gpio controlled " Lu Baolu
2016-03-08 7:53 ` [PATCH v3 5/7] usb: mux: add driver for Intel drcfg " Lu Baolu
2016-03-08 7:53 ` [PATCH v3 6/7] usb: pci-quirks: add Intel USB drcfg mux device Lu Baolu
2016-03-08 7:53 ` [PATCH v3 7/7] mfd: intel_vuport: Add Intel virtual USB port MFD Driver Lu Baolu
2016-03-11 0:03 ` [PATCH v3 0/7] usb: add support for Intel dual role port mux Greg Kroah-Hartman
2016-03-11 0:20 ` Lu Baolu
2016-03-11 1:41 ` Greg Kroah-Hartman
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=5704B067.1010001@linux.intel.com \
--to=baolu.lu@linux.intel.com \
--cc=balbi@kernel.org \
--cc=cw00.choi@samsung.com \
--cc=gregkh@linuxfoundation.org \
--cc=heikki.krogerus@linux.intel.com \
--cc=lee.jones@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=mathias.nyman@intel.com \
--cc=myungjoo.ham@samsung.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).