From: Stephen Warren <swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org> To: Alan Stern <stern-nwvwT67g6+6dFdvTe/nMLpVzexx5G7lz@public.gmane.org> Cc: Tony Prisk <linux-ci5G2KO2hbZ+pU9mqzGVBQ@public.gmane.org>, Greg KH <gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org>, devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org, linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Florian Fainelli <florian-p3rKhJxN3npAfugRpC6u6w@public.gmane.org>, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org, Rob Herring <rob.herring-bsGFqQB8/DxBDgjK7y7TUQ@public.gmane.org>, Grant Likely <grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org> Subject: Re: [PATCH v2 2/2] USB: doc: Binding document for ehci-platform driver Date: Tue, 23 Oct 2012 12:47:09 -0600 [thread overview] Message-ID: <5086E62D.8040407@wwwdotorg.org> (raw) In-Reply-To: <Pine.LNX.4.44L0.1210231340340.1635-100000-IYeN2dnnYyZXsRXLowluHWD2FQJk+8+b@public.gmane.org> On 10/23/2012 11:59 AM, Alan Stern wrote: > On Tue, 23 Oct 2012, Stephen Warren wrote: > >>>> So, rather than: >>>> >>>> compatible = "usb-ehci"; >>>> >>>> You should always have e.g.: >>>> >>>> compatible = "nvidia,tegra20-ehci", "usb-ehci"; >>>> >>>> Given that, there is then always enough information in the device tree >>>> for the driver to be able to derive the other values from the compatible >>>> value. >>> >>> Yes, I get it. >>> >>>> Whether you want to derive the information, or whether you want to >>>> explicitly represent it via properties, is a decision to make based on >>>> the trade-offs. >>>> >>>> Oh, and I note that quite a few device trees already use compatible >>>> value "usb-ehci" in their device-trees. Care needs to be taken not to >>>> usurp that value from any existing device drivers if that was to be >>>> picked as the compatible value required by this binding. >>> >>> Right. I think Tony's new binding should use compatible value >>> "usb-ehci-platform". It will essentially be a superset of "usb-ehci". >> >> I know this is bike-shedding a little bit, but... >> >> The word "platform" isn't really about describing the HW, but rather is >> derived from the Linux SW used to program that HW. DT should be purely >> about describing the HW. >> >> Perhaps "usb-ehci-generic" or "usb-ehci-simple" would be better? > > Neither of those really describes the hardware either. Which name gets > used seems pretty arbitrary. > > Nothing intrinsically distinguishes this class of hardware. The only > thing these devices have in common is that they can be managed by > Linux's ehci-platform driver. I don't agree. They're all EHCI USB controllers (or all EHCI USB controllers that don't require custom drivers due to quirks), which is a much more general statement than anything related to which driver Linux uses for them. > For that purpose, "usb-ehci-platform" > makes more sense than "usb-ehci-generic" or "usb-ehci-simple". > > (It also allows the class to enlarge over time as the driver becomes > more capable -- is that a bad thing? Are DT board descriptions written > for a later kernel supposed to be unusable with an earlier kernel that > doesn't support the same features?) > > In essense, we're trying to say that the HW is compatible with a > particular driver rather than with some other type of HW. Using a compatible value in order to pick a specific driver in Linux is explicitly against the device tree design principles; DT is supposed to represent just the hardware. > Maybe DT > wasn't intended to provide this kind of information, but it seems like > a logical thing to do. Unless DT already offers some other way to > accomplish the same thing? The typical way is for the Linux driver to declare that is supports a variety of different HW models. Admittedly this is annoying when there are many HW models that otherwise wouldn't need any driver changes, hence the desire to (additionally) include some generic value in the compatible field, but again, what that generic value is should be driven by the HW itself, not the SW that's using it. -- 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
WARNING: multiple messages have this Message-ID (diff)
From: swarren@wwwdotorg.org (Stephen Warren) To: linux-arm-kernel@lists.infradead.org Subject: [PATCH v2 2/2] USB: doc: Binding document for ehci-platform driver Date: Tue, 23 Oct 2012 12:47:09 -0600 [thread overview] Message-ID: <5086E62D.8040407@wwwdotorg.org> (raw) In-Reply-To: <Pine.LNX.4.44L0.1210231340340.1635-100000@iolanthe.rowland.org> On 10/23/2012 11:59 AM, Alan Stern wrote: > On Tue, 23 Oct 2012, Stephen Warren wrote: > >>>> So, rather than: >>>> >>>> compatible = "usb-ehci"; >>>> >>>> You should always have e.g.: >>>> >>>> compatible = "nvidia,tegra20-ehci", "usb-ehci"; >>>> >>>> Given that, there is then always enough information in the device tree >>>> for the driver to be able to derive the other values from the compatible >>>> value. >>> >>> Yes, I get it. >>> >>>> Whether you want to derive the information, or whether you want to >>>> explicitly represent it via properties, is a decision to make based on >>>> the trade-offs. >>>> >>>> Oh, and I note that quite a few device trees already use compatible >>>> value "usb-ehci" in their device-trees. Care needs to be taken not to >>>> usurp that value from any existing device drivers if that was to be >>>> picked as the compatible value required by this binding. >>> >>> Right. I think Tony's new binding should use compatible value >>> "usb-ehci-platform". It will essentially be a superset of "usb-ehci". >> >> I know this is bike-shedding a little bit, but... >> >> The word "platform" isn't really about describing the HW, but rather is >> derived from the Linux SW used to program that HW. DT should be purely >> about describing the HW. >> >> Perhaps "usb-ehci-generic" or "usb-ehci-simple" would be better? > > Neither of those really describes the hardware either. Which name gets > used seems pretty arbitrary. > > Nothing intrinsically distinguishes this class of hardware. The only > thing these devices have in common is that they can be managed by > Linux's ehci-platform driver. I don't agree. They're all EHCI USB controllers (or all EHCI USB controllers that don't require custom drivers due to quirks), which is a much more general statement than anything related to which driver Linux uses for them. > For that purpose, "usb-ehci-platform" > makes more sense than "usb-ehci-generic" or "usb-ehci-simple". > > (It also allows the class to enlarge over time as the driver becomes > more capable -- is that a bad thing? Are DT board descriptions written > for a later kernel supposed to be unusable with an earlier kernel that > doesn't support the same features?) > > In essense, we're trying to say that the HW is compatible with a > particular driver rather than with some other type of HW. Using a compatible value in order to pick a specific driver in Linux is explicitly against the device tree design principles; DT is supposed to represent just the hardware. > Maybe DT > wasn't intended to provide this kind of information, but it seems like > a logical thing to do. Unless DT already offers some other way to > accomplish the same thing? The typical way is for the Linux driver to declare that is supports a variety of different HW models. Admittedly this is annoying when there are many HW models that otherwise wouldn't need any driver changes, hence the desire to (additionally) include some generic value in the compatible field, but again, what that generic value is should be driven by the HW itself, not the SW that's using it.
next prev parent reply other threads:[~2012-10-23 18:47 UTC|newest] Thread overview: 85+ messages / expand[flat|nested] mbox.gz Atom feed top 2012-10-20 22:10 [PATCH v2 0/2] Update ehci-platform driver to support devicetree Tony Prisk 2012-10-20 22:10 ` Tony Prisk [not found] ` <1350771032-11527-1-git-send-email-linux-ci5G2KO2hbZ+pU9mqzGVBQ@public.gmane.org> 2012-10-20 22:10 ` [PATCH v2 1/2] USB: Update EHCI-platform driver to devicetree Tony Prisk 2012-10-20 22:10 ` Tony Prisk [not found] ` <1350771032-11527-2-git-send-email-linux-ci5G2KO2hbZ+pU9mqzGVBQ@public.gmane.org> 2012-10-21 2:02 ` Alan Stern 2012-10-21 2:02 ` Alan Stern 2012-10-22 14:51 ` Alan Stern 2012-10-20 22:10 ` [PATCH v2 2/2] USB: doc: Binding document for ehci-platform driver Tony Prisk 2012-10-20 22:10 ` Tony Prisk [not found] ` <1350771032-11527-3-git-send-email-linux-ci5G2KO2hbZ+pU9mqzGVBQ@public.gmane.org> 2012-10-21 17:34 ` Florian Fainelli 2012-10-21 17:34 ` Florian Fainelli 2012-10-22 16:07 ` Stephen Warren 2012-10-22 16:07 ` Stephen Warren [not found] ` <50856F41.7000205-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org> 2012-10-22 17:34 ` Alan Stern 2012-10-22 17:34 ` Alan Stern [not found] ` <Pine.LNX.4.44L0.1210221324580.1724-100000-IYeN2dnnYyZXsRXLowluHWD2FQJk+8+b@public.gmane.org> 2012-10-22 17:48 ` Stephen Warren 2012-10-22 17:48 ` Stephen Warren [not found] ` <508586ED.1010106-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org> 2012-10-22 19:00 ` Alan Stern 2012-10-22 19:00 ` Alan Stern [not found] ` <Pine.LNX.4.44L0.1210221443580.1724-100000-IYeN2dnnYyZXsRXLowluHWD2FQJk+8+b@public.gmane.org> 2012-10-22 22:10 ` Stephen Warren 2012-10-22 22:10 ` Stephen Warren [not found] ` <5085C470.4040707-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org> 2012-10-23 14:10 ` Alan Stern 2012-10-23 14:10 ` Alan Stern [not found] ` <Pine.LNX.4.44L0.1210231004310.1635-100000-IYeN2dnnYyZXsRXLowluHWD2FQJk+8+b@public.gmane.org> 2012-10-23 16:15 ` Stephen Warren 2012-10-23 16:15 ` Stephen Warren [not found] ` <5086C2B0.6070006-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org> 2012-10-23 17:59 ` Alan Stern 2012-10-23 17:59 ` Alan Stern [not found] ` <Pine.LNX.4.44L0.1210231340340.1635-100000-IYeN2dnnYyZXsRXLowluHWD2FQJk+8+b@public.gmane.org> 2012-10-23 18:47 ` Stephen Warren [this message] 2012-10-23 18:47 ` Stephen Warren [not found] ` <5086E62D.8040407-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org> 2012-10-23 19:33 ` Alan Stern 2012-10-23 19:33 ` Alan Stern [not found] ` <Pine.LNX.4.44L0.1210231522230.1635-100000-IYeN2dnnYyZXsRXLowluHWD2FQJk+8+b@public.gmane.org> 2012-10-23 20:06 ` Rob Herring 2012-10-23 20:06 ` Rob Herring [not found] ` <5086F8D6.5050605-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 2012-10-24 14:57 ` Alan Stern 2012-10-24 14:57 ` Alan Stern [not found] ` <Pine.LNX.4.44L0.1210241013310.1481-100000-IYeN2dnnYyZXsRXLowluHWD2FQJk+8+b@public.gmane.org> 2012-10-24 15:26 ` Sebastian Andrzej Siewior 2012-10-24 15:26 ` Sebastian Andrzej Siewior [not found] ` <20121024152652.GG4368-E0PNVn5OA6ohrxcnuTQ+TQ@public.gmane.org> 2012-10-24 16:16 ` Stephen Warren 2012-10-24 16:16 ` Stephen Warren [not found] ` <5088145F.1040504-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org> 2012-10-24 16:36 ` Florian Fainelli 2012-10-24 16:36 ` Florian Fainelli 2012-10-24 16:38 ` Alan Stern 2012-10-24 16:38 ` Alan Stern [not found] ` <Pine.LNX.4.44L0.1210241233040.1282-100000-IYeN2dnnYyZXsRXLowluHWD2FQJk+8+b@public.gmane.org> 2012-10-24 16:44 ` Florian Fainelli 2012-10-24 16:44 ` Florian Fainelli 2012-10-24 18:04 ` Alan Stern 2012-10-24 18:04 ` Alan Stern [not found] ` <Pine.LNX.4.44L0.1210241358090.1282-100000-IYeN2dnnYyZXsRXLowluHWD2FQJk+8+b@public.gmane.org> 2012-10-24 18:18 ` Florian Fainelli 2012-10-24 18:18 ` Florian Fainelli 2012-10-24 16:45 ` Stephen Warren 2012-10-24 16:45 ` Stephen Warren [not found] ` <50881B19.3080609-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org> 2012-10-24 17:46 ` Alan Stern 2012-10-24 17:46 ` Alan Stern [not found] ` <Pine.LNX.4.44L0.1210241329230.1282-100000-IYeN2dnnYyZXsRXLowluHWD2FQJk+8+b@public.gmane.org> 2012-10-24 18:09 ` Stephen Warren 2012-10-24 18:09 ` Stephen Warren [not found] ` <50882EED.9020200-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org> 2012-10-24 18:55 ` Mitch Bradley 2012-10-24 18:55 ` Mitch Bradley [not found] ` <5088399F.2000102-D5eQfiDGL7eakBO8gow8eQ@public.gmane.org> 2012-10-24 19:30 ` Alan Stern 2012-10-24 19:30 ` Alan Stern 2012-10-25 10:23 ` Sebastian Andrzej Siewior 2012-10-25 10:23 ` Sebastian Andrzej Siewior [not found] ` <20121025102301.GA3469-E0PNVn5OA6ohrxcnuTQ+TQ@public.gmane.org> 2012-10-25 14:36 ` Alan Stern 2012-10-25 14:36 ` Alan Stern [not found] ` <Pine.LNX.4.44L0.1210251035270.1278-100000-IYeN2dnnYyZXsRXLowluHWD2FQJk+8+b@public.gmane.org> 2012-10-26 8:02 ` Sebastian Andrzej Siewior 2012-10-26 8:02 ` Sebastian Andrzej Siewior [not found] ` <20121026080254.GD3009-E0PNVn5OA6ohrxcnuTQ+TQ@public.gmane.org> 2012-10-26 14:54 ` Alan Stern 2012-10-26 14:54 ` Alan Stern 2012-10-25 15:53 ` Stephen Warren 2012-10-25 15:53 ` Stephen Warren 2012-10-24 19:41 ` Alan Stern 2012-10-24 19:41 ` Alan Stern 2012-10-24 16:44 ` Alan Stern 2012-10-24 16:44 ` Alan Stern [not found] ` <Pine.LNX.4.44L0.1210241238570.1282-100000-IYeN2dnnYyZXsRXLowluHWD2FQJk+8+b@public.gmane.org> 2012-10-24 16:48 ` Stephen Warren 2012-10-24 16:48 ` Stephen Warren 2012-10-24 17:42 ` Rob Herring 2012-10-24 17:42 ` Rob Herring [not found] ` <50882882.1090806-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 2012-10-24 17:57 ` Alan Stern 2012-10-24 17:57 ` Alan Stern 2012-10-24 16:28 ` Stephen Warren 2012-10-24 16:28 ` Stephen Warren [not found] ` <50881727.10601-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org> 2012-10-24 16:54 ` Alan Stern 2012-10-24 16:54 ` Alan Stern [not found] ` <Pine.LNX.4.44L0.1210241249010.1282-100000-IYeN2dnnYyZXsRXLowluHWD2FQJk+8+b@public.gmane.org> 2012-10-24 17:37 ` Florian Fainelli 2012-10-24 17:37 ` Florian Fainelli
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=5086E62D.8040407@wwwdotorg.org \ --to=swarren-3lzwwm7+weoh9zmkesr00q@public.gmane.org \ --cc=devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org \ --cc=florian-p3rKhJxN3npAfugRpC6u6w@public.gmane.org \ --cc=grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org \ --cc=gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org \ --cc=linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \ --cc=linux-ci5G2KO2hbZ+pU9mqzGVBQ@public.gmane.org \ --cc=linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \ --cc=rob.herring-bsGFqQB8/DxBDgjK7y7TUQ@public.gmane.org \ --cc=stern-nwvwT67g6+6dFdvTe/nMLpVzexx5G7lz@public.gmane.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: linkBe 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.