From mboxrd@z Thu Jan 1 00:00:00 1970 From: Sebastian Andrzej Siewior Subject: Re: [PATCH v2 2/2] USB: doc: Binding document for ehci-platform driver Date: Thu, 25 Oct 2012 12:23:01 +0200 Message-ID: <20121025102301.GA3469@breakpoint.cc> References: <50882EED.9020200@wwwdotorg.org> <5088399F.2000102@firmworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: <5088399F.2000102-D5eQfiDGL7eakBO8gow8eQ@public.gmane.org> Sender: linux-usb-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Mitch Bradley Cc: Stephen Warren , Alan Stern , Greg KH , devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org, USB list , Rob Herring , Sebastian Andrzej Siewior , Florian Fainelli , linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org List-Id: devicetree@vger.kernel.org On Wed, Oct 24, 2012 at 08:55:27AM -1000, Mitch Bradley wrote: > >> So by listing "usb-ehci" in its device ID table, a driver would > >> essentially be saying that it can handle _all_ USB EHCI controllers. > > > Actually, it means that the driver can handle at least USB EHCI > controllers that are 100% compatible with the EHCI spec (requiring > nothing extra). The driver might be able to handle almost-compatible > controllers, possibly with the help of additional properties. > > If a DT node lists "usb-ehci" as a "fallback", it's not guaranteed that > a given version of that driver will work, but it's worth a try in the > event that no more-specific driver is matched. Not sure fallback is a good term here. The of parses the compatible from left to right. If the device specific entry is not found (in the driver) then end up with usb-ehci. If we need a quirk later on we add the device specific entry to the driver (which will match before usb-ehci is found) and we could use this entry to apply the quirk. That way you can apply quirks without touch the firmware / device tree. Sebastian -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html From mboxrd@z Thu Jan 1 00:00:00 1970 From: sebastian@breakpoint.cc (Sebastian Andrzej Siewior) Date: Thu, 25 Oct 2012 12:23:01 +0200 Subject: [PATCH v2 2/2] USB: doc: Binding document for ehci-platform driver In-Reply-To: <5088399F.2000102@firmworks.com> References: <50882EED.9020200@wwwdotorg.org> <5088399F.2000102@firmworks.com> Message-ID: <20121025102301.GA3469@breakpoint.cc> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Wed, Oct 24, 2012 at 08:55:27AM -1000, Mitch Bradley wrote: > >> So by listing "usb-ehci" in its device ID table, a driver would > >> essentially be saying that it can handle _all_ USB EHCI controllers. > > > Actually, it means that the driver can handle at least USB EHCI > controllers that are 100% compatible with the EHCI spec (requiring > nothing extra). The driver might be able to handle almost-compatible > controllers, possibly with the help of additional properties. > > If a DT node lists "usb-ehci" as a "fallback", it's not guaranteed that > a given version of that driver will work, but it's worth a try in the > event that no more-specific driver is matched. Not sure fallback is a good term here. The of parses the compatible from left to right. If the device specific entry is not found (in the driver) then end up with usb-ehci. If we need a quirk later on we add the device specific entry to the driver (which will match before usb-ehci is found) and we could use this entry to apply the quirk. That way you can apply quirks without touch the firmware / device tree. Sebastian