All of lore.kernel.org
 help / color / mirror / Atom feed
From: Heikki Krogerus <heikki.krogerus@linux.intel.com>
To: Chanwoo Choi <cw00.choi@samsung.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	MyungJoo Ham <myungjoo.ham@samsung.com>,
	David Cohen <david.a.cohen@linux.intel.com>,
	Lu Baolu <baolu.lu@linux.intel.com>,
	Mathias Nyman <mathias.nyman@linux.intel.com>,
	Felipe Balbi <balbi@ti.com>,
	linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCHv2 1/2] extcon: add driver for Intel USB mux
Date: Fri, 4 Dec 2015 10:51:36 +0200	[thread overview]
Message-ID: <20151204085136.GA24400@kuha.fi.intel.com> (raw)
In-Reply-To: <56600E3E.6080300@samsung.com>

Hi,

> I do never want to add some specific funtcion for only this driver.
> I think is not appropriate way.
> - intel_usb_mux_unregister
> - intel_usb_mux_register
> 
> The client driver using extcon driver should use the standard extcon API
> for code consistency. Also, I'll do the more detailed review for this patch.

The internal mux we are controlling here is physically separate
device. Ideally we could populate child device for it, but since that
is not possible because of the resource conflict, we use the library
approach, which is really not that uncommon.

I don't think I agree with your point even at general level. The
control required to handle this mux, even though simple, is enough to
deserve to be separated from xHCI code. xHCI should not need to care
about anything else expect does it have the mux, i.e. does it need to
register it or not. It should not need to care about how it needs to
be controlled or even what it is. We may decide to create something
else out of it instead of an extcon device later.

But in any case, the mux is available on all new Intel platforms, but
it needs to be controlled by OS only in few "special" cases. We can
not force xHCI (or pci-quirks.c to be more precise) to be aware of
these "special" cases. The only way to make it work like that would
bet by using ifdefs, and we really really don't want that.

And please also note that, though for now we only expect the mux
control registers to be part of xHCI MMIO, that is not always the
case. The control registers are part of the device controller MMIO on
some platforms. We do not want to duplicate the whole control of the
mux if/when we need the OS to be in control of it on a platform that
has those control registers mapped somewhere else then xHCI MMIO,

So I would say that we have pretty good justification for separating
the mux control, which means unfortunately custom API in this case.

But if you would prefer that we put the files somewhere else then
drivers/extcon/ and include/linux/extcon/ I'm fine with that. If you
like, we can put it to drivers/usb/host/ as that is where
pci-quirks.c is. That way I think we can also put the header to
include/usb/.


Thanks,

-- 
heikki

  reply	other threads:[~2015-12-04  8:52 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-12-03  9:29 [PATCHv2 0/2] extcon: driver for Intel USB MUX Heikki Krogerus
2015-12-03  9:29 ` [PATCHv2 1/2] extcon: add driver for Intel USB mux Heikki Krogerus
2015-12-03  9:41   ` Chanwoo Choi
2015-12-04  8:51     ` Heikki Krogerus [this message]
2015-12-07  1:24       ` Chanwoo Choi
2015-12-07 12:52         ` Heikki Krogerus
2015-12-08  1:17           ` Chanwoo Choi
2015-12-08 12:19             ` Heikki Krogerus
2015-12-03 19:16   ` Sergei Shtylyov
2015-12-03  9:29 ` [PATCHv2 2/2] usb: pci-quirks: register USB mux found on Cherrytrail SOC Heikki Krogerus
2015-12-03 19:01   ` Sergei Shtylyov

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=20151204085136.GA24400@kuha.fi.intel.com \
    --to=heikki.krogerus@linux.intel.com \
    --cc=balbi@ti.com \
    --cc=baolu.lu@linux.intel.com \
    --cc=cw00.choi@samsung.com \
    --cc=david.a.cohen@linux.intel.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=mathias.nyman@linux.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.