mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Lu Baolu <baolu.lu@linux.intel.com>
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: Sun, 13 Mar 2016 20:27:14 -0700	[thread overview]
Message-ID: <20160314032714.GA4665@kroah.com> (raw)
In-Reply-To: <56E60F42.8030701@linux.intel.com>

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...

> >> +#if IS_ENABLED(CONFIG_INTEL_USB_MUX)
> >> +extern int intel_usb_mux_register(struct intel_mux_dev *mux);
> >> +extern int intel_usb_mux_unregister(struct device *dev);
> > It's obvious you didn't run this through checkpatch.pl, please do so...
> 
> I did, but didn't hit any errors or warnings.

Odd, don't put extern in .h files for functions, I thought checkpatch
catches that...

Try it with --strict, as you should with all new code you submit.

> > 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_"
:(

> 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? :)

thanks,

greg k-h

  reply	other threads:[~2016-03-14  3:27 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 " 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 [this message]
2016-03-14  7:35         ` Lu Baolu
2016-04-06  6:44         ` Lu Baolu
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=20160314032714.GA4665@kroah.com \
    --to=gregkh@linuxfoundation.org \
    --cc=balbi@kernel.org \
    --cc=baolu.lu@linux.intel.com \
    --cc=cw00.choi@samsung.com \
    --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

Powered by JetHome