linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: s.hauer@pengutronix.de (Sascha Hauer)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v6 1/3] USB: chipidea: add imx usbmisc support
Date: Wed, 29 Aug 2012 10:10:20 +0200	[thread overview]
Message-ID: <20120829081020.GX26594@pengutronix.de> (raw)
In-Reply-To: <871uiqkuhb.fsf@ashishki-desk.ger.corp.intel.com>

On Wed, Aug 29, 2012 at 10:50:08AM +0300, Alexander Shishkin wrote:
> Richard Zhao <richard.zhao@freescale.com> writes:
> 
> > i.MX usb controllers shares non-core registers, which may include
> > SoC specific controls. We take it as a usbmisc device and usbmisc
> > driver set operations needed by ci13xxx_imx driver.
> >
> > For example, Sabrelite board has bad over-current design, we can
> > usbmisc to disable over-current detect.
> 
> Why does this have to be part of the usb driver instead of SoC specific
> code? It looks like you've created a whole new device/driver
> infrastructure just to disable overcurrent for a specific board.

Richards code indeed only handles overcurrent for a specific board, but
there are more bits to configure in the longer run: power pin
polarities, ULPI/serial mode select and some more.

> 
> And the infrastructure boils down to a complex way of passing a callback
> from imx driver to another imx driver, that only works if they are
> probed in the right order. I don't see any point in doing it like this
> other than inflating the device tree tables even further.
> 
> Why can't this be part of the SoC code like it is done, for example in
> arch/arm/mach-omap2/control.c?

The settings are board specific, so there must be some way to configure
them in the devicetree.

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

  reply	other threads:[~2012-08-29  8:10 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-08-28  6:58 [PATCH v6 0/3] imx: add usbmisc support Richard Zhao
2012-08-28  6:58 ` [PATCH v6 1/3] USB: chipidea: add imx " Richard Zhao
2012-08-28 14:51   ` Michael Grzeschik
2012-08-29  2:55     ` Richard Zhao
2012-08-29  7:50   ` Alexander Shishkin
2012-08-29  8:10     ` Sascha Hauer [this message]
2012-08-29 10:18       ` Alexander Shishkin
2012-08-29 10:57         ` Richard Zhao
2012-08-29 11:01         ` Sascha Hauer
2012-08-29 20:00           ` Marc Kleine-Budde
2012-09-04 14:10             ` Richard Zhao
2012-09-11 10:42               ` Alexander Shishkin
2012-09-11 12:20                 ` Shawn Guo
2012-08-29  8:13     ` Richard Zhao
2012-08-28  6:58 ` [PATCH v6 2/3] ARM: imx6q: clk_register_clkdev usbmisc clock Richard Zhao
2012-08-28  6:58 ` [PATCH v6 3/3] ARM: dts: imx6q-sabrelite: add usbmisc device Richard Zhao

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=20120829081020.GX26594@pengutronix.de \
    --to=s.hauer@pengutronix.de \
    --cc=linux-arm-kernel@lists.infradead.org \
    /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).