linux-kernel - Re: Non-enumerable devices on USB and other enumerable buses

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20130812020257.GA7028@kroah.com>
Date:	Sun, 11 Aug 2013 19:02:57 -0700
From:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To:	Mark Brown <broonie@...nel.org>
Cc:	Rob Herring <rob.herring@...xeda.com>,
	Pawel Moll <pawel.moll@....com>,
	Mark Rutland <mark.rutland@....com>,
	Stephen Warren <swarren@...dotorg.org>,
	Ian Campbell <ian.campbell@...rix.com>,
	Felipe Balbi <balbi@...com>,
	Grant Likely <grant.likely@...aro.org>, devicetree@...nel.org,
	linux-usb@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: Non-enumerable devices on USB and other enumerable buses

On Sun, Aug 11, 2013 at 08:08:26PM +0100, Mark Brown wrote:
> Looking at the enumerable buses in the kernel I don't see any which have
> real support for any kind of registration of devices prior to their
> enumeration.  Similarly currently all the DT bindings in the kernel I've
> been able to notice cover only non-enumerable buses.  This generally
> makes sense where enumerable buses are used in standard fashions since
> the binding would be at best redundant and at worst inaccurate.  However
> there are often corner cases in embedded systems where hardware has been
> hooked up outside of the normal enumeration mechanisms, for example with
> software power control or extra signals wired.

Not just "embedded", the Macbooks have this same issue as well I'm
pretty sure, it's just that we don't know where those GPIOs are in order
to be able to use them...

> One example that's bugging me right now is that on the Insignal Arndale
> platform there's a USB hub connected to one of the USB ports on the SoC
> (not as a PHY, it seems we also need the internal PHY running to talk to
> the device).  The hub needs to be "plugged" into the SoC after the SoC
> USB controller has started with some GPIOs so we need to tell the system
> that the hub exists and needs to be synchronised with the USB controller.
> 
> Another case that's going to be problematic once it's in mainline is
> Slimbus - this is a bus used in some embedded audio subsystems which is
> enumerable in a similar manner to USB but where the devices on the bus
> are normally powered up only on demand (causing them to hotplug when
> used and unplug when idle) and have at least interrupt lines wired to
> the SoC using a normal interrupt outside the enumerable bus.
> 
> I know there's been some discussion of this topic but do we have any
> general consensus on how to handle such things both from a Linux driver
> model point of view and from a DT/ACPI point of view?

As these are usually bus-specific things, and really, platform-specific
things, I'd fall back and just recommend a "platform driver" that
"knows" about where these gpios are, and how/when to enable them, which
will cause the discoverable bus logic to kick in now that it notices a
device is present/removed.

Perhaps a semi-generic "platform" driver could be created, that knows
how to handle these settings in the DT, but odds are, that might be
difficult to make generic enough to cover a wide range of boards, but
without specifics, it's hard to tell.

thanks,

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