| Message ID | 1461104370-20439-1-git-send-email-swarren@wwwdotorg.org |
|---|---|
| State | Accepted |
| Commit | 9fdfadf8fc83b173b3ba55aa82739ca92d8a273d |
| Delegated to: | Simon Glass |
| Headers | show |
On 19 April 2016 at 16:19, Stephen Warren <swarren@wwwdotorg.org> wrote: > From: Stephen Warren <swarren@nvidia.com> > > In some cases, drivers may not want to bind to a device. Allow bind() to > return -ENODEV in this case, and don't treat this as an error. This can > be useful in situations where some information source other than the DT > node's main status property indicates whether the device should be > enabled, for example other DT properties might indicate this, or the > driver might query non-DT sources such as system fuses or a version number > register. > > Signed-off-by: Stephen Warren <swarren@nvidia.com> > --- > drivers/core/lists.c | 4 ++++ > 1 file changed, 4 insertions(+) Reviewed-by: Simon Glass <sjg@chromium.org>
On 04/19/2016 04:19 PM, Stephen Warren wrote: > From: Stephen Warren <swarren@nvidia.com> > > In some cases, drivers may not want to bind to a device. Allow bind() to > return -ENODEV in this case, and don't treat this as an error. This can > be useful in situations where some information source other than the DT > node's main status property indicates whether the device should be > enabled, for example other DT properties might indicate this, or the > driver might query non-DT sources such as system fuses or a version number > register. Simon, this series is assigned to you in patchwork. Are you the right person to apply it?
Hi Stephen, On 4 May 2016 at 12:57, Stephen Warren <swarren@wwwdotorg.org> wrote: > On 04/19/2016 04:19 PM, Stephen Warren wrote: >> >> From: Stephen Warren <swarren@nvidia.com> >> >> In some cases, drivers may not want to bind to a device. Allow bind() to >> return -ENODEV in this case, and don't treat this as an error. This can >> be useful in situations where some information source other than the DT >> node's main status property indicates whether the device should be >> enabled, for example other DT properties might indicate this, or the >> driver might query non-DT sources such as system fuses or a version number >> register. > > > Simon, this series is assigned to you in patchwork. Are you the right person > to apply it? Yes. but not for this release, right? Regards, Simon
On 05/04/2016 01:31 PM, Simon Glass wrote: > Hi Stephen, > > On 4 May 2016 at 12:57, Stephen Warren <swarren@wwwdotorg.org> wrote: >> On 04/19/2016 04:19 PM, Stephen Warren wrote: >>> >>> From: Stephen Warren <swarren@nvidia.com> >>> >>> In some cases, drivers may not want to bind to a device. Allow bind() to >>> return -ENODEV in this case, and don't treat this as an error. This can >>> be useful in situations where some information source other than the DT >>> node's main status property indicates whether the device should be >>> enabled, for example other DT properties might indicate this, or the >>> driver might query non-DT sources such as system fuses or a version number >>> register. >> >> >> Simon, this series is assigned to you in patchwork. Are you the right person >> to apply it? > > Yes. but not for this release, right? Patch 2 in the series (which depends on this patch) fixes a bug for Tegra boards with LCD panels. Admittedly it appears to be only cosmetic (an error message is printed at boot), but "it's a bug" seems to satisfy the requirement to apply it for this release.
+Tom Rini Hi Stephen, On 4 May 2016 at 13:46, Stephen Warren <swarren@wwwdotorg.org> wrote: > On 05/04/2016 01:31 PM, Simon Glass wrote: >> >> Hi Stephen, >> >> On 4 May 2016 at 12:57, Stephen Warren <swarren@wwwdotorg.org> wrote: >>> >>> On 04/19/2016 04:19 PM, Stephen Warren wrote: >>>> >>>> >>>> From: Stephen Warren <swarren@nvidia.com> >>>> >>>> In some cases, drivers may not want to bind to a device. Allow bind() to >>>> return -ENODEV in this case, and don't treat this as an error. This can >>>> be useful in situations where some information source other than the DT >>>> node's main status property indicates whether the device should be >>>> enabled, for example other DT properties might indicate this, or the >>>> driver might query non-DT sources such as system fuses or a version >>>> number >>>> register. >>> >>> >>> >>> Simon, this series is assigned to you in patchwork. Are you the right >>> person >>> to apply it? >> >> >> Yes. but not for this release, right? > > > Patch 2 in the series (which depends on this patch) fixes a bug for Tegra > boards with LCD panels. Admittedly it appears to be only cosmetic (an error > message is printed at boot), but "it's a bug" seems to satisfy the > requirement to apply it for this release. Sorry, I didn't know that. Given the core nature of this patch I would rather wait, and apply it next week. Let me know if you disagree. Regards, Simon
On 05/04/2016 01:48 PM, Simon Glass wrote: > +Tom Rini > > Hi Stephen, > > On 4 May 2016 at 13:46, Stephen Warren <swarren@wwwdotorg.org> wrote: >> On 05/04/2016 01:31 PM, Simon Glass wrote: >>> >>> Hi Stephen, >>> >>> On 4 May 2016 at 12:57, Stephen Warren <swarren@wwwdotorg.org> wrote: >>>> >>>> On 04/19/2016 04:19 PM, Stephen Warren wrote: >>>>> >>>>> >>>>> From: Stephen Warren <swarren@nvidia.com> >>>>> >>>>> In some cases, drivers may not want to bind to a device. Allow bind() to >>>>> return -ENODEV in this case, and don't treat this as an error. This can >>>>> be useful in situations where some information source other than the DT >>>>> node's main status property indicates whether the device should be >>>>> enabled, for example other DT properties might indicate this, or the >>>>> driver might query non-DT sources such as system fuses or a version >>>>> number >>>>> register. >>>> >>>> >>>> >>>> Simon, this series is assigned to you in patchwork. Are you the right >>>> person >>>> to apply it? >>> >>> >>> Yes. but not for this release, right? >> >> >> Patch 2 in the series (which depends on this patch) fixes a bug for Tegra >> boards with LCD panels. Admittedly it appears to be only cosmetic (an error >> message is printed at boot), but "it's a bug" seems to satisfy the >> requirement to apply it for this release. > > Sorry, I didn't know that. Given the core nature of this patch I would > rather wait, and apply it next week. Let me know if you disagree. I suppose that it's been broken long enough that another release won't matter. Was my explanation of the bug in the description of patch 2/2 not clear in some way?
Hi Stephen, On 4 May 2016 at 14:02, Stephen Warren <swarren@wwwdotorg.org> wrote: > On 05/04/2016 01:48 PM, Simon Glass wrote: >> >> +Tom Rini >> >> Hi Stephen, >> >> On 4 May 2016 at 13:46, Stephen Warren <swarren@wwwdotorg.org> wrote: >>> >>> On 05/04/2016 01:31 PM, Simon Glass wrote: >>>> >>>> >>>> Hi Stephen, >>>> >>>> On 4 May 2016 at 12:57, Stephen Warren <swarren@wwwdotorg.org> wrote: >>>>> >>>>> >>>>> On 04/19/2016 04:19 PM, Stephen Warren wrote: >>>>>> >>>>>> >>>>>> >>>>>> From: Stephen Warren <swarren@nvidia.com> >>>>>> >>>>>> In some cases, drivers may not want to bind to a device. Allow bind() >>>>>> to >>>>>> return -ENODEV in this case, and don't treat this as an error. This >>>>>> can >>>>>> be useful in situations where some information source other than the >>>>>> DT >>>>>> node's main status property indicates whether the device should be >>>>>> enabled, for example other DT properties might indicate this, or the >>>>>> driver might query non-DT sources such as system fuses or a version >>>>>> number >>>>>> register. >>>>> >>>>> >>>>> >>>>> >>>>> Simon, this series is assigned to you in patchwork. Are you the right >>>>> person >>>>> to apply it? >>>> >>>> >>>> >>>> Yes. but not for this release, right? >>> >>> >>> >>> Patch 2 in the series (which depends on this patch) fixes a bug for Tegra >>> boards with LCD panels. Admittedly it appears to be only cosmetic (an >>> error >>> message is printed at boot), but "it's a bug" seems to satisfy the >>> requirement to apply it for this release. >> >> >> Sorry, I didn't know that. Given the core nature of this patch I would >> rather wait, and apply it next week. Let me know if you disagree. > > > I suppose that it's been broken long enough that another release won't > matter. > > Was my explanation of the bug in the description of patch 2/2 not clear in > some way? Looks good to me. Were you expecting me to apply both as a bug fix? If so I'd prefer to have Tom Warren's ACK. Even so, a core patch like this really needs the full test cycle IMO. Regards, Simon
On 4 May 2016 at 14:09, Simon Glass <sjg@chromium.org> wrote: > Hi Stephen, > > On 4 May 2016 at 14:02, Stephen Warren <swarren@wwwdotorg.org> wrote: >> On 05/04/2016 01:48 PM, Simon Glass wrote: >>> >>> +Tom Rini >>> >>> Hi Stephen, >>> >>> On 4 May 2016 at 13:46, Stephen Warren <swarren@wwwdotorg.org> wrote: >>>> >>>> On 05/04/2016 01:31 PM, Simon Glass wrote: >>>>> >>>>> >>>>> Hi Stephen, >>>>> >>>>> On 4 May 2016 at 12:57, Stephen Warren <swarren@wwwdotorg.org> wrote: >>>>>> >>>>>> >>>>>> On 04/19/2016 04:19 PM, Stephen Warren wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> From: Stephen Warren <swarren@nvidia.com> >>>>>>> >>>>>>> In some cases, drivers may not want to bind to a device. Allow bind() >>>>>>> to >>>>>>> return -ENODEV in this case, and don't treat this as an error. This >>>>>>> can >>>>>>> be useful in situations where some information source other than the >>>>>>> DT >>>>>>> node's main status property indicates whether the device should be >>>>>>> enabled, for example other DT properties might indicate this, or the >>>>>>> driver might query non-DT sources such as system fuses or a version >>>>>>> number >>>>>>> register. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Simon, this series is assigned to you in patchwork. Are you the right >>>>>> person >>>>>> to apply it? >>>>> >>>>> >>>>> >>>>> Yes. but not for this release, right? >>>> >>>> >>>> >>>> Patch 2 in the series (which depends on this patch) fixes a bug for Tegra >>>> boards with LCD panels. Admittedly it appears to be only cosmetic (an >>>> error >>>> message is printed at boot), but "it's a bug" seems to satisfy the >>>> requirement to apply it for this release. >>> >>> >>> Sorry, I didn't know that. Given the core nature of this patch I would >>> rather wait, and apply it next week. Let me know if you disagree. >> >> >> I suppose that it's been broken long enough that another release won't >> matter. >> >> Was my explanation of the bug in the description of patch 2/2 not clear in >> some way? > > Looks good to me. Were you expecting me to apply both as a bug fix? If > so I'd prefer to have Tom Warren's ACK. Even so, a core patch like > this really needs the full test cycle IMO. > > Regards, > Simon Applied to u-boot-dm, thanks!
diff --git a/drivers/core/lists.c b/drivers/core/lists.c index c4fc216340d8..a72db13a119a 100644 --- a/drivers/core/lists.c +++ b/drivers/core/lists.c @@ -171,6 +171,10 @@ int lists_bind_fdt(struct udevice *parent, const void *blob, int offset, dm_dbg(" - found match at '%s'\n", entry->name); ret = device_bind(parent, entry, name, NULL, offset, &dev); + if (ret == -ENODEV) { + dm_dbg("Driver '%s' refuses to bind\n", entry->name); + continue; + } if (ret) { dm_warn("Error binding driver '%s': %d\n", entry->name, ret);