Date: Fri, 16 Aug 2013 19:39:34 +0100
From: Mark Brown <broonie@kernel.org>
To: Alan Stern <stern@rowland.harvard.edu>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        Rob Herring <rob.herring@calxeda.com>, Pawel Moll <pawel.moll@arm.com>,
        Mark Rutland <mark.rutland@arm.com>,
        Stephen Warren <swarren@wwwdotorg.org>,
        Ian Campbell <ian.campbell@citrix.com>, Felipe Balbi <balbi@ti.com>,
        Grant Likely <grant.likely@linaro.org>, devicetree@vger.kernel.org,
        linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org
Message-ID: <20130816183934.GQ30073@sirena.org.uk>
References: <Pine.LNX.4.44L0.1308161012160.1532-100000@iolanthe.rowland.org>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="/YnR2r17TIEndSCI"
Content-Disposition: inline
In-Reply-To: <Pine.LNX.4.44L0.1308161012160.1532-100000@iolanthe.rowland.org>
User-Agent: Mutt/1.5.21 (2010-09-15)
Subject: Re: Non-enumerable devices on USB and other enumerable buses
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 2794
Lines: 68


--/YnR2r17TIEndSCI
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Fri, Aug 16, 2013 at 10:42:10AM -0400, Alan Stern wrote:

> Okay, let's see if I understand your problem.  You've got a driver that
=2E..
> Is that it?

Yes, I think that's it.

> The difficulty with the first proposal is that subsystems aren't
> designed to allow that sort of thing.  They expect to be able to
> communicate with the devices they manage, during enumeration and
> probing at least.  The difficulty with the second proposal is that it
> requires duplicating the power-on code.

> My feeling is that the second answer involves less work and less
> complexity than the first.  Both proposals require additional
> "run-once" code (to do the partial instantiations or the initial
> power-ons), but the first proposal also requires the subsystem's=20
> detection and enumeration routines to be adjusted so that they can work=
=20
> even when the device is incommunicado.

Right, but like I say I'm not sure that the modifications required are
substantially different to those for handling a device powering up and
down on the bus or those for getting platform data to a device when it
does enumerate.  I'd also not be so sure about the run once code, that
is only the case for devices that can't completely idle themselves at
runtime.

> (The second proposal also has the advantage that the power-on code may=20
> be shared between the driver and the subsystem.)

Can you explain in more detail please, I don't follow?

--/YnR2r17TIEndSCI
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (GNU/Linux)

iQIcBAEBAgAGBQJSDnHjAAoJELSic+t+oim9+qEP/3Yokdnlu77xOIb8mgiRuYNF
r72CdFyVUgKxxDM4vRCHZU0P1rN7m7FKaTDWJYSPkwN4cEGfXK5NKpgnZs8n79Dw
R5PAwfaQWv2NtYqAK7SP+tYv3zP+RS+6qwsxFrLzLZdZ5/f5i8GxzMprX1T4ukn/
T5m3rFUnPtXdYT2WJ9DWvf+BL7xWsBGZ3QSyQ83MTdP3vW4J+njts9cTEiK+lIb3
f9Ox9KfbNM3TPf9erAEvbHfOnhssGBaOXkdmaSQN6ky5P8a+uT4HZoX4295vZPst
16/QERBDVTby0qkLu4Pxfj8T+23qlEEtW12fePI9rZEG/U3Enhj4wSUXhnTLMUdO
EY3IxBHNzHnDN6qmENAZWwAsmNp+KfiJh5xk8pmOot0Th8JOJXu9jOhEVVddx2Xh
ZQfNCoiTD4RKri3Qj2xS37uO4/swE0QUq/4FB4D2mne2qcHzZeBCbhPthgC0wjsw
YFxEnRdW2e/6jFF/idWVujoIFSlM8tojCjxcKPiSDS1GgtVPgmwMsSPW4IjMt6vP
wwuWXQGZJFgztV1Uxvo0K0SPmlPcdLdhpDzq0mOPE9Eioow3M2xmteU5AbCCeroz
wI2ZtIY8oJ1/EdTccPaVE9R1TTkEmCFZgLbx8394eVWjbX3bokoF72DEevEf09Ig
OnFs2toh/jwnHbmSUzSd
=1rF8
-----END PGP SIGNATURE-----

--/YnR2r17TIEndSCI--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/