| Message ID | 1416212385-23800-9-git-send-email-yamada.m@jp.panasonic.com |
|---|---|
| State | Rejected |
| Delegated to: | Simon Glass |
| Headers | show |
Hi Masahiro, On 17 November 2014 08:19, Masahiro Yamada <yamada.m@jp.panasonic.com> wrote: > The driver model provides two ways to pass the device information, > platform data and device tree. Either way works to bind devices and > drivers, but there is inconsistency in terms of how to pass the > pre-reloc flag. > > In the platform data way, the pre-reloc DM scan checks if each driver > has DM_FLAG_PRE_RELOC flag (this was changed to use U_BOOT_DRIVER_F > just before). That is, each **driver** has the pre-reloc attribute. > > In the device tree control, the existence of "u-boot,dm-pre-reloc" is > checked for each device node. The driver flag "DM_FLAG_PRE_RELOC" is > never checked. That is, each **device** owns the pre-reloc attribute. > > Drivers should generally work both with platform data and device tree, > but this inconsistency has made our life difficult. I feel we should use device tree where available, and only fall back to platform data when necessary (no device tree available for platform, for example). > > This commit abolishes "u-boot,dm-pre-reloc" property because: > > - Having a U-Boot specific property makes it difficult to share the > device tree sources between Linux and U-Boot. > > - The number of devices is generally larger than that of drivers. > Each driver often has multiple devices with different base > addresses. It seems more reasonable to add the pre-reloc attribute > to drivers than devices. The inability for platform data to specify which devices need to be pre-relocation is certainly a limitation. But I'm not sure that the solution is to remove that feature from the device tree. Prior to relocation memory may be severely limited. Things like GPIO and serial can create quite a few devices (e.g. Tegra has 16 for GPIO and 4 for serial), but only a subset may be needed before relocation (on Tegra only 2!). I'm actually pretty comfortable with platform data having a limited subset of functionality, since I believe most platforms will use device tree for one reason or another. Thoughts? Regards, Simon
Hi Simon, On Mon, 17 Nov 2014 18:17:43 +0000 Simon Glass <sjg@chromium.org> wrote: > Hi Masahiro, > > On 17 November 2014 08:19, Masahiro Yamada <yamada.m@jp.panasonic.com> wrote: > > The driver model provides two ways to pass the device information, > > platform data and device tree. Either way works to bind devices and > > drivers, but there is inconsistency in terms of how to pass the > > pre-reloc flag. > > > > In the platform data way, the pre-reloc DM scan checks if each driver > > has DM_FLAG_PRE_RELOC flag (this was changed to use U_BOOT_DRIVER_F > > just before). That is, each **driver** has the pre-reloc attribute. > > > > In the device tree control, the existence of "u-boot,dm-pre-reloc" is > > checked for each device node. The driver flag "DM_FLAG_PRE_RELOC" is > > never checked. That is, each **device** owns the pre-reloc attribute. > > > > Drivers should generally work both with platform data and device tree, > > but this inconsistency has made our life difficult. > > I feel we should use device tree where available, and only fall back > to platform data when necessary (no device tree available for > platform, for example). No, it is true that device tree is a useful tool, but it should be optional. All the infrastructures of drivers must work perfectly without device tree. The device tree is just one choice of how to give device information. > > > > This commit abolishes "u-boot,dm-pre-reloc" property because: > > > > - Having a U-Boot specific property makes it difficult to share the > > device tree sources between Linux and U-Boot. > > > > - The number of devices is generally larger than that of drivers. > > Each driver often has multiple devices with different base > > addresses. It seems more reasonable to add the pre-reloc attribute > > to drivers than devices. > > The inability for platform data to specify which devices need to be > pre-relocation is certainly a limitation. But I'm not sure that the > solution is to remove that feature from the device tree. Prior to > relocation memory may be severely limited. Things like GPIO and serial > can create quite a few devices (e.g. Tegra has 16 for GPIO and 4 for > serial), but only a subset may be needed before relocation (on Tegra > only 2!). > > I'm actually pretty comfortable with platform data having a limited > subset of functionality, since I believe most platforms will use > device tree for one reason or another. > > Thoughts? > No, it is not justified to compel to use device tree unless Linux is the target OS. Even in Linux, limited numbers of architrectures use device trees. Best Regards Masahiro Yamada
Hi Masahiro, On 18 November 2014 12:51, Masahiro Yamada <yamada.m@jp.panasonic.com> wrote: > Hi Simon, > > > > On Mon, 17 Nov 2014 18:17:43 +0000 > Simon Glass <sjg@chromium.org> wrote: > >> Hi Masahiro, >> >> On 17 November 2014 08:19, Masahiro Yamada <yamada.m@jp.panasonic.com> wrote: >> > The driver model provides two ways to pass the device information, >> > platform data and device tree. Either way works to bind devices and >> > drivers, but there is inconsistency in terms of how to pass the >> > pre-reloc flag. >> > >> > In the platform data way, the pre-reloc DM scan checks if each driver >> > has DM_FLAG_PRE_RELOC flag (this was changed to use U_BOOT_DRIVER_F >> > just before). That is, each **driver** has the pre-reloc attribute. >> > >> > In the device tree control, the existence of "u-boot,dm-pre-reloc" is >> > checked for each device node. The driver flag "DM_FLAG_PRE_RELOC" is >> > never checked. That is, each **device** owns the pre-reloc attribute. >> > >> > Drivers should generally work both with platform data and device tree, >> > but this inconsistency has made our life difficult. >> >> I feel we should use device tree where available, and only fall back >> to platform data when necessary (no device tree available for >> platform, for example). > > No, it is true that device tree is a useful tool, but it should be optional. > > All the infrastructures of drivers must work perfectly without device tree. > > The device tree is just one choice of how to give device information. > Which platform(s) are we talking about here? > > > >> > >> > This commit abolishes "u-boot,dm-pre-reloc" property because: >> > >> > - Having a U-Boot specific property makes it difficult to share the >> > device tree sources between Linux and U-Boot. >> > >> > - The number of devices is generally larger than that of drivers. >> > Each driver often has multiple devices with different base >> > addresses. It seems more reasonable to add the pre-reloc attribute >> > to drivers than devices. >> >> The inability for platform data to specify which devices need to be >> pre-relocation is certainly a limitation. But I'm not sure that the >> solution is to remove that feature from the device tree. Prior to >> relocation memory may be severely limited. Things like GPIO and serial >> can create quite a few devices (e.g. Tegra has 16 for GPIO and 4 for >> serial), but only a subset may be needed before relocation (on Tegra >> only 2!). >> >> I'm actually pretty comfortable with platform data having a limited >> subset of functionality, since I believe most platforms will use >> device tree for one reason or another. >> >> Thoughts? >> > > No, it is not justified to compel to use device tree > unless Linux is the target OS. > > Even in Linux, limited numbers of architrectures use device trees. Fair enough, but let's look at this when the case comes up. So far the platforms that use I2C and SPI with DM do use device tree in Linux and probably should do in U-Boot. Regards, Simon
Hi Simon, On Tue, 18 Nov 2014 14:37:33 +0000 Simon Glass <sjg@chromium.org> wrote: > Hi Masahiro, > > On 18 November 2014 12:51, Masahiro Yamada <yamada.m@jp.panasonic.com> wrote: > > Hi Simon, > > > > > > > > On Mon, 17 Nov 2014 18:17:43 +0000 > > Simon Glass <sjg@chromium.org> wrote: > > > >> Hi Masahiro, > >> > >> On 17 November 2014 08:19, Masahiro Yamada <yamada.m@jp.panasonic.com> wrote: > >> > The driver model provides two ways to pass the device information, > >> > platform data and device tree. Either way works to bind devices and > >> > drivers, but there is inconsistency in terms of how to pass the > >> > pre-reloc flag. > >> > > >> > In the platform data way, the pre-reloc DM scan checks if each driver > >> > has DM_FLAG_PRE_RELOC flag (this was changed to use U_BOOT_DRIVER_F > >> > just before). That is, each **driver** has the pre-reloc attribute. > >> > > >> > In the device tree control, the existence of "u-boot,dm-pre-reloc" is > >> > checked for each device node. The driver flag "DM_FLAG_PRE_RELOC" is > >> > never checked. That is, each **device** owns the pre-reloc attribute. > >> > > >> > Drivers should generally work both with platform data and device tree, > >> > but this inconsistency has made our life difficult. > >> > >> I feel we should use device tree where available, and only fall back > >> to platform data when necessary (no device tree available for > >> platform, for example). > > > > No, it is true that device tree is a useful tool, but it should be optional. > > > > All the infrastructures of drivers must work perfectly without device tree. > > > > The device tree is just one choice of how to give device information. > > > > Which platform(s) are we talking about here? I am talking about the general design policy of drivers in U-Boot and Linux. > > > > > >> > > >> > This commit abolishes "u-boot,dm-pre-reloc" property because: > >> > > >> > - Having a U-Boot specific property makes it difficult to share the > >> > device tree sources between Linux and U-Boot. > >> > > >> > - The number of devices is generally larger than that of drivers. > >> > Each driver often has multiple devices with different base > >> > addresses. It seems more reasonable to add the pre-reloc attribute > >> > to drivers than devices. > >> > >> The inability for platform data to specify which devices need to be > >> pre-relocation is certainly a limitation. But I'm not sure that the > >> solution is to remove that feature from the device tree. Prior to > >> relocation memory may be severely limited. Things like GPIO and serial > >> can create quite a few devices (e.g. Tegra has 16 for GPIO and 4 for > >> serial), but only a subset may be needed before relocation (on Tegra > >> only 2!). > >> > >> I'm actually pretty comfortable with platform data having a limited > >> subset of functionality, since I believe most platforms will use > >> device tree for one reason or another. > >> > >> Thoughts? > >> > > > > No, it is not justified to compel to use device tree > > unless Linux is the target OS. > > > > Even in Linux, limited numbers of architrectures use device trees. > > Fair enough, but let's look at this when the case comes up. So far the > platforms that use I2C and SPI with DM do use device tree in Linux and > probably should do in U-Boot. OK, so let's think about it when a problem happens. Let's get back talking about this patch. If 8/8 is not acceptable, I do not have motivation for 6/8 and 7/8, either. I still believe that the top priority of the design policy is to share the same device tree source between U-Boot and Linux. I am really unhappy about having such a u-boot specific property. So, my suggestion is this patch, and one possible alternative is to bind all the devices even before relocation. Only binding won't use much memory because U-Boot does not probe devices until they are actually used. Both "u-boot,dm-pre-reloc" and DM_FLAG_PRE_RELOC will go away. What do you think? Best Regards Masahiro Yamada
Hi Masahiro, On 19 November 2014 09:21, Masahiro Yamada <yamada.m@jp.panasonic.com> wrote: > Hi Simon, > > > > On Tue, 18 Nov 2014 14:37:33 +0000 > Simon Glass <sjg@chromium.org> wrote: > >> Hi Masahiro, >> >> On 18 November 2014 12:51, Masahiro Yamada <yamada.m@jp.panasonic.com> wrote: >> > Hi Simon, >> > >> > >> > >> > On Mon, 17 Nov 2014 18:17:43 +0000 >> > Simon Glass <sjg@chromium.org> wrote: >> > >> >> Hi Masahiro, >> >> >> >> On 17 November 2014 08:19, Masahiro Yamada <yamada.m@jp.panasonic.com> wrote: >> >> > The driver model provides two ways to pass the device information, >> >> > platform data and device tree. Either way works to bind devices and >> >> > drivers, but there is inconsistency in terms of how to pass the >> >> > pre-reloc flag. >> >> > >> >> > In the platform data way, the pre-reloc DM scan checks if each driver >> >> > has DM_FLAG_PRE_RELOC flag (this was changed to use U_BOOT_DRIVER_F >> >> > just before). That is, each **driver** has the pre-reloc attribute. >> >> > >> >> > In the device tree control, the existence of "u-boot,dm-pre-reloc" is >> >> > checked for each device node. The driver flag "DM_FLAG_PRE_RELOC" is >> >> > never checked. That is, each **device** owns the pre-reloc attribute. >> >> > >> >> > Drivers should generally work both with platform data and device tree, >> >> > but this inconsistency has made our life difficult. >> >> >> >> I feel we should use device tree where available, and only fall back >> >> to platform data when necessary (no device tree available for >> >> platform, for example). >> > >> > No, it is true that device tree is a useful tool, but it should be optional. >> > >> > All the infrastructures of drivers must work perfectly without device tree. >> > >> > The device tree is just one choice of how to give device information. >> > >> >> Which platform(s) are we talking about here? > > > I am talking about the general design policy of drivers > in U-Boot and Linux. Well Linux has moved away from platform data, right? > > > >> > >> > >> >> > >> >> > This commit abolishes "u-boot,dm-pre-reloc" property because: >> >> > >> >> > - Having a U-Boot specific property makes it difficult to share the >> >> > device tree sources between Linux and U-Boot. >> >> > >> >> > - The number of devices is generally larger than that of drivers. >> >> > Each driver often has multiple devices with different base >> >> > addresses. It seems more reasonable to add the pre-reloc attribute >> >> > to drivers than devices. >> >> >> >> The inability for platform data to specify which devices need to be >> >> pre-relocation is certainly a limitation. But I'm not sure that the >> >> solution is to remove that feature from the device tree. Prior to >> >> relocation memory may be severely limited. Things like GPIO and serial >> >> can create quite a few devices (e.g. Tegra has 16 for GPIO and 4 for >> >> serial), but only a subset may be needed before relocation (on Tegra >> >> only 2!). >> >> >> >> I'm actually pretty comfortable with platform data having a limited >> >> subset of functionality, since I believe most platforms will use >> >> device tree for one reason or another. >> >> >> >> Thoughts? >> >> >> > >> > No, it is not justified to compel to use device tree >> > unless Linux is the target OS. >> > >> > Even in Linux, limited numbers of architrectures use device trees. >> >> Fair enough, but let's look at this when the case comes up. So far the >> platforms that use I2C and SPI with DM do use device tree in Linux and >> probably should do in U-Boot. > > OK, so let's think about it when a problem happens. > > > Let's get back talking about this patch. > If 8/8 is not acceptable, I do not have motivation for 6/8 and 7/8, either. > > > I still believe that the top priority of the design policy is > to share the same device tree source between U-Boot and Linux. Agreed, and we really need to line up so we are using the same source. I do want to point out that we mostly do, the differences are small. > > I am really unhappy about having such a u-boot specific property. > > So, my suggestion is this patch, and one possible alternative is > to bind all the devices even before relocation. > Only binding won't use much memory because U-Boot does not probe devices > until they are actually used. > Both "u-boot,dm-pre-reloc" and DM_FLAG_PRE_RELOC will go away. > > > What do you think? That's a waste of time since we won't use them and the goal is to do as little as possible before relocation. I don't see that the pre-reloc property is a huge problem. In the case of serial I found a way around it (using aliases). I hope that it will be possible more generally and we can review that at some point in the future. There are bigger fish to fry in driver model I think - so many uclasses to write. Regards, Simon
On 11/20/2014 09:44 AM, Simon Glass wrote: > Hi Masahiro, > > On 19 November 2014 09:21, Masahiro Yamada <yamada.m@jp.panasonic.com> wrote: >> Hi Simon, >> >> >> >> On Tue, 18 Nov 2014 14:37:33 +0000 >> Simon Glass <sjg@chromium.org> wrote: >> >>> Hi Masahiro, >>> >>> On 18 November 2014 12:51, Masahiro Yamada <yamada.m@jp.panasonic.com> wrote: >>>> Hi Simon, >>>> >>>> >>>> >>>> On Mon, 17 Nov 2014 18:17:43 +0000 >>>> Simon Glass <sjg@chromium.org> wrote: >>>> >>>>> Hi Masahiro, >>>>> >>>>> On 17 November 2014 08:19, Masahiro Yamada <yamada.m@jp.panasonic.com> wrote: >>>>>> The driver model provides two ways to pass the device information, >>>>>> platform data and device tree. Either way works to bind devices and >>>>>> drivers, but there is inconsistency in terms of how to pass the >>>>>> pre-reloc flag. >>>>>> >>>>>> In the platform data way, the pre-reloc DM scan checks if each driver >>>>>> has DM_FLAG_PRE_RELOC flag (this was changed to use U_BOOT_DRIVER_F >>>>>> just before). That is, each **driver** has the pre-reloc attribute. >>>>>> >>>>>> In the device tree control, the existence of "u-boot,dm-pre-reloc" is >>>>>> checked for each device node. The driver flag "DM_FLAG_PRE_RELOC" is >>>>>> never checked. That is, each **device** owns the pre-reloc attribute. >>>>>> >>>>>> Drivers should generally work both with platform data and device tree, >>>>>> but this inconsistency has made our life difficult. >>>>> >>>>> I feel we should use device tree where available, and only fall back >>>>> to platform data when necessary (no device tree available for >>>>> platform, for example). >>>> >>>> No, it is true that device tree is a useful tool, but it should be optional. >>>> >>>> All the infrastructures of drivers must work perfectly without device tree. >>>> >>>> The device tree is just one choice of how to give device information. >>>> >>> >>> Which platform(s) are we talking about here? >> >> >> I am talking about the general design policy of drivers >> in U-Boot and Linux. > > Well Linux has moved away from platform data, right? As a blanket statement, that isn't true. Some architectures (e.g. ARM) have moved to DT. That move is something done by the ARM maintainers, not something that's necessarily being forced upon every single architecture. I know of no move to force everyone to convert to DT. What makes sense for Linux doesn't always make sense for everything else anyway. In my opinion, DT in Linux isn't actually doing much that's useful, and DT in a boot loader is likely to be even less useful.
Hi Simon, On Thu, 20 Nov 2014 16:44:22 +0000 Simon Glass <sjg@chromium.org> wrote: > Hi Masahiro, > > On 19 November 2014 09:21, Masahiro Yamada <yamada.m@jp.panasonic.com> wrote: > > Hi Simon, > > > > > > > > On Tue, 18 Nov 2014 14:37:33 +0000 > > Simon Glass <sjg@chromium.org> wrote: > > > >> Hi Masahiro, > >> > >> On 18 November 2014 12:51, Masahiro Yamada <yamada.m@jp.panasonic.com> wrote: > >> > Hi Simon, > >> > > >> > > >> > > >> > On Mon, 17 Nov 2014 18:17:43 +0000 > >> > Simon Glass <sjg@chromium.org> wrote: > >> > > >> >> Hi Masahiro, > >> >> > >> >> On 17 November 2014 08:19, Masahiro Yamada <yamada.m@jp.panasonic.com> wrote: > >> >> > The driver model provides two ways to pass the device information, > >> >> > platform data and device tree. Either way works to bind devices and > >> >> > drivers, but there is inconsistency in terms of how to pass the > >> >> > pre-reloc flag. > >> >> > > >> >> > In the platform data way, the pre-reloc DM scan checks if each driver > >> >> > has DM_FLAG_PRE_RELOC flag (this was changed to use U_BOOT_DRIVER_F > >> >> > just before). That is, each **driver** has the pre-reloc attribute. > >> >> > > >> >> > In the device tree control, the existence of "u-boot,dm-pre-reloc" is > >> >> > checked for each device node. The driver flag "DM_FLAG_PRE_RELOC" is > >> >> > never checked. That is, each **device** owns the pre-reloc attribute. > >> >> > > >> >> > Drivers should generally work both with platform data and device tree, > >> >> > but this inconsistency has made our life difficult. > >> >> > >> >> I feel we should use device tree where available, and only fall back > >> >> to platform data when necessary (no device tree available for > >> >> platform, for example). > >> > > >> > No, it is true that device tree is a useful tool, but it should be optional. > >> > > >> > All the infrastructures of drivers must work perfectly without device tree. > >> > > >> > The device tree is just one choice of how to give device information. > >> > > >> > >> Which platform(s) are we talking about here? > > > > > > I am talking about the general design policy of drivers > > in U-Boot and Linux. > > Well Linux has moved away from platform data, right? > > > > > > > > >> > > >> > > >> >> > > >> >> > This commit abolishes "u-boot,dm-pre-reloc" property because: > >> >> > > >> >> > - Having a U-Boot specific property makes it difficult to share the > >> >> > device tree sources between Linux and U-Boot. > >> >> > > >> >> > - The number of devices is generally larger than that of drivers. > >> >> > Each driver often has multiple devices with different base > >> >> > addresses. It seems more reasonable to add the pre-reloc attribute > >> >> > to drivers than devices. > >> >> > >> >> The inability for platform data to specify which devices need to be > >> >> pre-relocation is certainly a limitation. But I'm not sure that the > >> >> solution is to remove that feature from the device tree. Prior to > >> >> relocation memory may be severely limited. Things like GPIO and serial > >> >> can create quite a few devices (e.g. Tegra has 16 for GPIO and 4 for > >> >> serial), but only a subset may be needed before relocation (on Tegra > >> >> only 2!). > >> >> > >> >> I'm actually pretty comfortable with platform data having a limited > >> >> subset of functionality, since I believe most platforms will use > >> >> device tree for one reason or another. > >> >> > >> >> Thoughts? > >> >> > >> > > >> > No, it is not justified to compel to use device tree > >> > unless Linux is the target OS. > >> > > >> > Even in Linux, limited numbers of architrectures use device trees. > >> > >> Fair enough, but let's look at this when the case comes up. So far the > >> platforms that use I2C and SPI with DM do use device tree in Linux and > >> probably should do in U-Boot. > > > > OK, so let's think about it when a problem happens. > > > > > > Let's get back talking about this patch. > > If 8/8 is not acceptable, I do not have motivation for 6/8 and 7/8, either. > > > > > > I still believe that the top priority of the design policy is > > to share the same device tree source between U-Boot and Linux. > > Agreed, and we really need to line up so we are using the same source. > I do want to point out that we mostly do, the differences are small. > > > > > I am really unhappy about having such a u-boot specific property. > > > > So, my suggestion is this patch, and one possible alternative is > > to bind all the devices even before relocation. > > Only binding won't use much memory because U-Boot does not probe devices > > until they are actually used. > > Both "u-boot,dm-pre-reloc" and DM_FLAG_PRE_RELOC will go away. > > > > > > What do you think? > > That's a waste of time since we won't use them and the goal is to do > as little as possible before relocation. > > I don't see that the pre-reloc property is a huge problem. In the case > of serial I found a way around it (using aliases). I hope that it will > be possible more generally and we can review that at some point in the > future. There are bigger fish to fry in driver model I think - so many > uclasses to write. OK. I've marked 6/8 thru 8/8 as Rejected. No point for 6/8 and 7/8 without 8/8, I think. Best Regards Masahiro Yamada
HI Masahiro, On 21 November 2014 at 02:59, Masahiro Yamada <yamada.m@jp.panasonic.com> wrote: > Hi Simon, > > > > On Thu, 20 Nov 2014 16:44:22 +0000 > Simon Glass <sjg@chromium.org> wrote: > >> Hi Masahiro, >> >> On 19 November 2014 09:21, Masahiro Yamada <yamada.m@jp.panasonic.com> wrote: >> > Hi Simon, >> > >> > >> > >> > On Tue, 18 Nov 2014 14:37:33 +0000 >> > Simon Glass <sjg@chromium.org> wrote: >> > >> >> Hi Masahiro, >> >> >> >> On 18 November 2014 12:51, Masahiro Yamada <yamada.m@jp.panasonic.com> wrote: >> >> > Hi Simon, >> >> > >> >> > >> >> > >> >> > On Mon, 17 Nov 2014 18:17:43 +0000 >> >> > Simon Glass <sjg@chromium.org> wrote: >> >> > >> >> >> Hi Masahiro, >> >> >> >> >> >> On 17 November 2014 08:19, Masahiro Yamada <yamada.m@jp.panasonic.com> wrote: >> >> >> > The driver model provides two ways to pass the device information, >> >> >> > platform data and device tree. Either way works to bind devices and >> >> >> > drivers, but there is inconsistency in terms of how to pass the >> >> >> > pre-reloc flag. >> >> >> > >> >> >> > In the platform data way, the pre-reloc DM scan checks if each driver >> >> >> > has DM_FLAG_PRE_RELOC flag (this was changed to use U_BOOT_DRIVER_F >> >> >> > just before). That is, each **driver** has the pre-reloc attribute. >> >> >> > >> >> >> > In the device tree control, the existence of "u-boot,dm-pre-reloc" is >> >> >> > checked for each device node. The driver flag "DM_FLAG_PRE_RELOC" is >> >> >> > never checked. That is, each **device** owns the pre-reloc attribute. >> >> >> > >> >> >> > Drivers should generally work both with platform data and device tree, >> >> >> > but this inconsistency has made our life difficult. >> >> >> >> >> >> I feel we should use device tree where available, and only fall back >> >> >> to platform data when necessary (no device tree available for >> >> >> platform, for example). >> >> > >> >> > No, it is true that device tree is a useful tool, but it should be optional. >> >> > >> >> > All the infrastructures of drivers must work perfectly without device tree. >> >> > >> >> > The device tree is just one choice of how to give device information. >> >> > >> >> >> >> Which platform(s) are we talking about here? >> > >> > >> > I am talking about the general design policy of drivers >> > in U-Boot and Linux. >> >> Well Linux has moved away from platform data, right? >> >> > >> > >> > >> >> > >> >> > >> >> >> > >> >> >> > This commit abolishes "u-boot,dm-pre-reloc" property because: >> >> >> > >> >> >> > - Having a U-Boot specific property makes it difficult to share the >> >> >> > device tree sources between Linux and U-Boot. >> >> >> > >> >> >> > - The number of devices is generally larger than that of drivers. >> >> >> > Each driver often has multiple devices with different base >> >> >> > addresses. It seems more reasonable to add the pre-reloc attribute >> >> >> > to drivers than devices. >> >> >> >> >> >> The inability for platform data to specify which devices need to be >> >> >> pre-relocation is certainly a limitation. But I'm not sure that the >> >> >> solution is to remove that feature from the device tree. Prior to >> >> >> relocation memory may be severely limited. Things like GPIO and serial >> >> >> can create quite a few devices (e.g. Tegra has 16 for GPIO and 4 for >> >> >> serial), but only a subset may be needed before relocation (on Tegra >> >> >> only 2!). >> >> >> >> >> >> I'm actually pretty comfortable with platform data having a limited >> >> >> subset of functionality, since I believe most platforms will use >> >> >> device tree for one reason or another. >> >> >> >> >> >> Thoughts? >> >> >> >> >> > >> >> > No, it is not justified to compel to use device tree >> >> > unless Linux is the target OS. >> >> > >> >> > Even in Linux, limited numbers of architrectures use device trees. >> >> >> >> Fair enough, but let's look at this when the case comes up. So far the >> >> platforms that use I2C and SPI with DM do use device tree in Linux and >> >> probably should do in U-Boot. >> > >> > OK, so let's think about it when a problem happens. >> > >> > >> > Let's get back talking about this patch. >> > If 8/8 is not acceptable, I do not have motivation for 6/8 and 7/8, either. >> > >> > >> > I still believe that the top priority of the design policy is >> > to share the same device tree source between U-Boot and Linux. >> >> Agreed, and we really need to line up so we are using the same source. >> I do want to point out that we mostly do, the differences are small. >> >> > >> > I am really unhappy about having such a u-boot specific property. >> > >> > So, my suggestion is this patch, and one possible alternative is >> > to bind all the devices even before relocation. >> > Only binding won't use much memory because U-Boot does not probe devices >> > until they are actually used. >> > Both "u-boot,dm-pre-reloc" and DM_FLAG_PRE_RELOC will go away. >> > >> > >> > What do you think? >> >> That's a waste of time since we won't use them and the goal is to do >> as little as possible before relocation. >> >> I don't see that the pre-reloc property is a huge problem. In the case >> of serial I found a way around it (using aliases). I hope that it will >> be possible more generally and we can review that at some point in the >> future. There are bigger fish to fry in driver model I think - so many >> uclasses to write. > > > > OK. I've marked 6/8 thru 8/8 as Rejected. > No point for 6/8 and 7/8 without 8/8, I think. I'm not so sure. Your method reduces the number of drivers that are considered for pre-reloc use which is a benefit. Maybe we should require that all pre-reloc devices have an alias. Then we can bind devices as they are needed as we do for serial. Needs more thought though. Regards, Simon
Hi Simon, On Mon, 24 Nov 2014 15:29:23 -0700 Simon Glass <sjg@chromium.org> wrote: > HI Masahiro, > > On 21 November 2014 at 02:59, Masahiro Yamada <yamada.m@jp.panasonic.com> wrote: > > Hi Simon, > > > > > > > > On Thu, 20 Nov 2014 16:44:22 +0000 > > Simon Glass <sjg@chromium.org> wrote: > > > >> Hi Masahiro, > >> > >> On 19 November 2014 09:21, Masahiro Yamada <yamada.m@jp.panasonic.com> wrote: > >> > Hi Simon, > >> > > >> > > >> > > >> > On Tue, 18 Nov 2014 14:37:33 +0000 > >> > Simon Glass <sjg@chromium.org> wrote: > >> > > >> >> Hi Masahiro, > >> >> > >> >> On 18 November 2014 12:51, Masahiro Yamada <yamada.m@jp.panasonic.com> wrote: > >> >> > Hi Simon, > >> >> > > >> >> > > >> >> > > >> >> > On Mon, 17 Nov 2014 18:17:43 +0000 > >> >> > Simon Glass <sjg@chromium.org> wrote: > >> >> > > >> >> >> Hi Masahiro, > >> >> >> > >> >> >> On 17 November 2014 08:19, Masahiro Yamada <yamada.m@jp.panasonic.com> wrote: > >> >> >> > The driver model provides two ways to pass the device information, > >> >> >> > platform data and device tree. Either way works to bind devices and > >> >> >> > drivers, but there is inconsistency in terms of how to pass the > >> >> >> > pre-reloc flag. > >> >> >> > > >> >> >> > In the platform data way, the pre-reloc DM scan checks if each driver > >> >> >> > has DM_FLAG_PRE_RELOC flag (this was changed to use U_BOOT_DRIVER_F > >> >> >> > just before). That is, each **driver** has the pre-reloc attribute. > >> >> >> > > >> >> >> > In the device tree control, the existence of "u-boot,dm-pre-reloc" is > >> >> >> > checked for each device node. The driver flag "DM_FLAG_PRE_RELOC" is > >> >> >> > never checked. That is, each **device** owns the pre-reloc attribute. > >> >> >> > > >> >> >> > Drivers should generally work both with platform data and device tree, > >> >> >> > but this inconsistency has made our life difficult. > >> >> >> > >> >> >> I feel we should use device tree where available, and only fall back > >> >> >> to platform data when necessary (no device tree available for > >> >> >> platform, for example). > >> >> > > >> >> > No, it is true that device tree is a useful tool, but it should be optional. > >> >> > > >> >> > All the infrastructures of drivers must work perfectly without device tree. > >> >> > > >> >> > The device tree is just one choice of how to give device information. > >> >> > > >> >> > >> >> Which platform(s) are we talking about here? > >> > > >> > > >> > I am talking about the general design policy of drivers > >> > in U-Boot and Linux. > >> > >> Well Linux has moved away from platform data, right? > >> > >> > > >> > > >> > > >> >> > > >> >> > > >> >> >> > > >> >> >> > This commit abolishes "u-boot,dm-pre-reloc" property because: > >> >> >> > > >> >> >> > - Having a U-Boot specific property makes it difficult to share the > >> >> >> > device tree sources between Linux and U-Boot. > >> >> >> > > >> >> >> > - The number of devices is generally larger than that of drivers. > >> >> >> > Each driver often has multiple devices with different base > >> >> >> > addresses. It seems more reasonable to add the pre-reloc attribute > >> >> >> > to drivers than devices. > >> >> >> > >> >> >> The inability for platform data to specify which devices need to be > >> >> >> pre-relocation is certainly a limitation. But I'm not sure that the > >> >> >> solution is to remove that feature from the device tree. Prior to > >> >> >> relocation memory may be severely limited. Things like GPIO and serial > >> >> >> can create quite a few devices (e.g. Tegra has 16 for GPIO and 4 for > >> >> >> serial), but only a subset may be needed before relocation (on Tegra > >> >> >> only 2!). > >> >> >> > >> >> >> I'm actually pretty comfortable with platform data having a limited > >> >> >> subset of functionality, since I believe most platforms will use > >> >> >> device tree for one reason or another. > >> >> >> > >> >> >> Thoughts? > >> >> >> > >> >> > > >> >> > No, it is not justified to compel to use device tree > >> >> > unless Linux is the target OS. > >> >> > > >> >> > Even in Linux, limited numbers of architrectures use device trees. > >> >> > >> >> Fair enough, but let's look at this when the case comes up. So far the > >> >> platforms that use I2C and SPI with DM do use device tree in Linux and > >> >> probably should do in U-Boot. > >> > > >> > OK, so let's think about it when a problem happens. > >> > > >> > > >> > Let's get back talking about this patch. > >> > If 8/8 is not acceptable, I do not have motivation for 6/8 and 7/8, either. > >> > > >> > > >> > I still believe that the top priority of the design policy is > >> > to share the same device tree source between U-Boot and Linux. > >> > >> Agreed, and we really need to line up so we are using the same source. > >> I do want to point out that we mostly do, the differences are small. > >> > >> > > >> > I am really unhappy about having such a u-boot specific property. > >> > > >> > So, my suggestion is this patch, and one possible alternative is > >> > to bind all the devices even before relocation. > >> > Only binding won't use much memory because U-Boot does not probe devices > >> > until they are actually used. > >> > Both "u-boot,dm-pre-reloc" and DM_FLAG_PRE_RELOC will go away. > >> > > >> > > >> > What do you think? > >> > >> That's a waste of time since we won't use them and the goal is to do > >> as little as possible before relocation. > >> > >> I don't see that the pre-reloc property is a huge problem. In the case > >> of serial I found a way around it (using aliases). I hope that it will > >> be possible more generally and we can review that at some point in the > >> future. There are bigger fish to fry in driver model I think - so many > >> uclasses to write. > > > > > > > > OK. I've marked 6/8 thru 8/8 as Rejected. > > No point for 6/8 and 7/8 without 8/8, I think. > > I'm not so sure. Your method reduces the number of drivers that are > considered for pre-reloc use which is a benefit. If you insist on "u-boot,dm-pre-reloc" property (= each device has the pre-reloc attribute), I think the DM_FLAG_PRE_RELOC flag should be moved from U_BOOT_DRIVER to U_BOOT_DEVICE for consistency. (Or 6/8 should introduce U_BOOT_DEVICE_F instead of U_BOOT_DRIVER_F) That is why I thought 6/8 and 7/8 should not be applied. > Maybe we should require that all pre-reloc devices have an alias. Then > we can bind devices as they are needed as we do for serial. Needs more > thought though. I want to see first how this will work because I believe platform data should be implemented consistently with that. Best Regards Masahiro Yamada
Hi Masahiro, On 24 November 2014 at 20:18, Masahiro Yamada <yamada.m@jp.panasonic.com> wrote: > Hi Simon, > > > > On Mon, 24 Nov 2014 15:29:23 -0700 > Simon Glass <sjg@chromium.org> wrote: > >> HI Masahiro, >> >> On 21 November 2014 at 02:59, Masahiro Yamada <yamada.m@jp.panasonic.com> wrote: >> > Hi Simon, >> > >> > >> > >> > On Thu, 20 Nov 2014 16:44:22 +0000 >> > Simon Glass <sjg@chromium.org> wrote: >> > >> >> Hi Masahiro, >> >> >> >> On 19 November 2014 09:21, Masahiro Yamada <yamada.m@jp.panasonic.com> wrote: >> >> > Hi Simon, >> >> > >> >> > >> >> > >> >> > On Tue, 18 Nov 2014 14:37:33 +0000 >> >> > Simon Glass <sjg@chromium.org> wrote: >> >> > >> >> >> Hi Masahiro, >> >> >> >> >> >> On 18 November 2014 12:51, Masahiro Yamada <yamada.m@jp.panasonic.com> wrote: >> >> >> > Hi Simon, >> >> >> > >> >> >> > >> >> >> > >> >> >> > On Mon, 17 Nov 2014 18:17:43 +0000 >> >> >> > Simon Glass <sjg@chromium.org> wrote: >> >> >> > >> >> >> >> Hi Masahiro, >> >> >> >> >> >> >> >> On 17 November 2014 08:19, Masahiro Yamada <yamada.m@jp.panasonic.com> wrote: >> >> >> >> > The driver model provides two ways to pass the device information, >> >> >> >> > platform data and device tree. Either way works to bind devices and >> >> >> >> > drivers, but there is inconsistency in terms of how to pass the >> >> >> >> > pre-reloc flag. >> >> >> >> > >> >> >> >> > In the platform data way, the pre-reloc DM scan checks if each driver >> >> >> >> > has DM_FLAG_PRE_RELOC flag (this was changed to use U_BOOT_DRIVER_F >> >> >> >> > just before). That is, each **driver** has the pre-reloc attribute. >> >> >> >> > >> >> >> >> > In the device tree control, the existence of "u-boot,dm-pre-reloc" is >> >> >> >> > checked for each device node. The driver flag "DM_FLAG_PRE_RELOC" is >> >> >> >> > never checked. That is, each **device** owns the pre-reloc attribute. >> >> >> >> > >> >> >> >> > Drivers should generally work both with platform data and device tree, >> >> >> >> > but this inconsistency has made our life difficult. >> >> >> >> >> >> >> >> I feel we should use device tree where available, and only fall back >> >> >> >> to platform data when necessary (no device tree available for >> >> >> >> platform, for example). >> >> >> > >> >> >> > No, it is true that device tree is a useful tool, but it should be optional. >> >> >> > >> >> >> > All the infrastructures of drivers must work perfectly without device tree. >> >> >> > >> >> >> > The device tree is just one choice of how to give device information. >> >> >> > >> >> >> >> >> >> Which platform(s) are we talking about here? >> >> > >> >> > >> >> > I am talking about the general design policy of drivers >> >> > in U-Boot and Linux. >> >> >> >> Well Linux has moved away from platform data, right? >> >> >> >> > >> >> > >> >> > >> >> >> > >> >> >> > >> >> >> >> > >> >> >> >> > This commit abolishes "u-boot,dm-pre-reloc" property because: >> >> >> >> > >> >> >> >> > - Having a U-Boot specific property makes it difficult to share the >> >> >> >> > device tree sources between Linux and U-Boot. >> >> >> >> > >> >> >> >> > - The number of devices is generally larger than that of drivers. >> >> >> >> > Each driver often has multiple devices with different base >> >> >> >> > addresses. It seems more reasonable to add the pre-reloc attribute >> >> >> >> > to drivers than devices. >> >> >> >> >> >> >> >> The inability for platform data to specify which devices need to be >> >> >> >> pre-relocation is certainly a limitation. But I'm not sure that the >> >> >> >> solution is to remove that feature from the device tree. Prior to >> >> >> >> relocation memory may be severely limited. Things like GPIO and serial >> >> >> >> can create quite a few devices (e.g. Tegra has 16 for GPIO and 4 for >> >> >> >> serial), but only a subset may be needed before relocation (on Tegra >> >> >> >> only 2!). >> >> >> >> >> >> >> >> I'm actually pretty comfortable with platform data having a limited >> >> >> >> subset of functionality, since I believe most platforms will use >> >> >> >> device tree for one reason or another. >> >> >> >> >> >> >> >> Thoughts? >> >> >> >> >> >> >> > >> >> >> > No, it is not justified to compel to use device tree >> >> >> > unless Linux is the target OS. >> >> >> > >> >> >> > Even in Linux, limited numbers of architrectures use device trees. >> >> >> >> >> >> Fair enough, but let's look at this when the case comes up. So far the >> >> >> platforms that use I2C and SPI with DM do use device tree in Linux and >> >> >> probably should do in U-Boot. >> >> > >> >> > OK, so let's think about it when a problem happens. >> >> > >> >> > >> >> > Let's get back talking about this patch. >> >> > If 8/8 is not acceptable, I do not have motivation for 6/8 and 7/8, either. >> >> > >> >> > >> >> > I still believe that the top priority of the design policy is >> >> > to share the same device tree source between U-Boot and Linux. >> >> >> >> Agreed, and we really need to line up so we are using the same source. >> >> I do want to point out that we mostly do, the differences are small. >> >> >> >> > >> >> > I am really unhappy about having such a u-boot specific property. >> >> > >> >> > So, my suggestion is this patch, and one possible alternative is >> >> > to bind all the devices even before relocation. >> >> > Only binding won't use much memory because U-Boot does not probe devices >> >> > until they are actually used. >> >> > Both "u-boot,dm-pre-reloc" and DM_FLAG_PRE_RELOC will go away. >> >> > >> >> > >> >> > What do you think? >> >> >> >> That's a waste of time since we won't use them and the goal is to do >> >> as little as possible before relocation. >> >> >> >> I don't see that the pre-reloc property is a huge problem. In the case >> >> of serial I found a way around it (using aliases). I hope that it will >> >> be possible more generally and we can review that at some point in the >> >> future. There are bigger fish to fry in driver model I think - so many >> >> uclasses to write. >> > >> > >> > >> > OK. I've marked 6/8 thru 8/8 as Rejected. >> > No point for 6/8 and 7/8 without 8/8, I think. >> >> I'm not so sure. Your method reduces the number of drivers that are >> considered for pre-reloc use which is a benefit. > > > If you insist on "u-boot,dm-pre-reloc" property (= each device has > the pre-reloc attribute), I think the DM_FLAG_PRE_RELOC flag should be > moved from U_BOOT_DRIVER to U_BOOT_DEVICE for consistency. > (Or 6/8 should introduce U_BOOT_DEVICE_F instead of U_BOOT_DRIVER_F) > > That is why I thought 6/8 and 7/8 should not be applied. Let's do nothing for now. I don't like that property and would to get rid of it too. > > >> Maybe we should require that all pre-reloc devices have an alias. Then >> we can bind devices as they are needed as we do for serial. Needs more >> thought though. > > I want to see first how this will work > because I believe platform data should be implemented consistently with that. I'm thinking about it. If I take a look at adding more functions to the GPIO uclass (automatically handing gpio nodes in the device tree) then I might try to solve this one too. For platform data I suppose it is just the order in the executable that determines the numbering. Pretty ugly. Regards, Simon
diff --git a/arch/arm/dts/exynos5.dtsi b/arch/arm/dts/exynos5.dtsi index e539068..dc5405b 100644 --- a/arch/arm/dts/exynos5.dtsi +++ b/arch/arm/dts/exynos5.dtsi @@ -244,7 +244,6 @@ compatible = "samsung,exynos4210-uart"; reg = <0x12C30000 0x100>; interrupts = <0 54 0>; - u-boot,dm-pre-reloc; id = <3>; }; diff --git a/doc/driver-model/README.txt b/doc/driver-model/README.txt index e4114d5..06f6515 100644 --- a/doc/driver-model/README.txt +++ b/doc/driver-model/README.txt @@ -739,9 +739,8 @@ Pre-Relocation Support ---------------------- For pre-relocation we simply call the driver model init function. Only -drivers declared with U_BOOT_DRIVER_F or the device tree -'u-boot,dm-pre-reloc' flag are initialised prior to relocation. This helps -to reduce the driver model overhead. +drivers declared with U_BOOT_DRIVER_F are initialised prior to relocation. +This helps to reduce the driver model overhead. Then post relocation we throw that away and re-init driver model again. For drivers which require some sort of continuity between pre- and diff --git a/drivers/core/lists.c b/drivers/core/lists.c index 5b61ab5..2109a9f 100644 --- a/drivers/core/lists.c +++ b/drivers/core/lists.c @@ -106,11 +106,11 @@ static int driver_check_compatible(const void *blob, int offset, return -ENOENT; } -int lists_bind_fdt(struct udevice *parent, const void *blob, int offset, - struct udevice **devp) +int __lists_bind_fdt(struct udevice *parent, const void *blob, int offset, + struct udevice **devp, bool pre_reloc_only) { struct driver *entry = ll_entry_start(struct driver, driver1); - struct driver *end = ll_entry_end(struct driver, driver2); + struct driver *end = driver_entry_end(pre_reloc_only); struct udevice *dev; bool found = false; const char *name; diff --git a/drivers/core/root.c b/drivers/core/root.c index 02970c8..2f0c409 100644 --- a/drivers/core/root.c +++ b/drivers/core/root.c @@ -87,10 +87,8 @@ int dm_scan_fdt_node(struct udevice *parent, const void *blob, int offset, for (offset = fdt_first_subnode(blob, offset); offset > 0; offset = fdt_next_subnode(blob, offset)) { - if (pre_reloc_only && - !fdt_getprop(blob, offset, "u-boot,dm-pre-reloc", NULL)) - continue; - err = lists_bind_fdt(parent, blob, offset, NULL); + err = __lists_bind_fdt(parent, blob, offset, NULL, + pre_reloc_only); if (err && !ret) ret = err; } diff --git a/drivers/core/simple-bus.c b/drivers/core/simple-bus.c index 3ea4d82..483f8e2 100644 --- a/drivers/core/simple-bus.c +++ b/drivers/core/simple-bus.c @@ -26,7 +26,7 @@ static const struct udevice_id generic_simple_bus_ids[] = { { } }; -U_BOOT_DRIVER(simple_bus_drv) = { +U_BOOT_DRIVER_F(simple_bus_drv) = { .name = "generic_simple_bus", .id = UCLASS_SIMPLE_BUS, .of_match = generic_simple_bus_ids, diff --git a/include/dm/lists.h b/include/dm/lists.h index fbd428d..56bf6a7 100644 --- a/include/dm/lists.h +++ b/include/dm/lists.h @@ -53,7 +53,7 @@ struct uclass_driver *lists_uclass_lookup(enum uclass_id id); int lists_bind_drivers(struct udevice *parent, bool pre_reloc_only); /** - * lists_bind_fdt() - bind a device tree node + * __lists_bind_fdt() - bind a device tree node * * This creates a new device bound to the given device tree node, with * @parent as its parent. @@ -62,10 +62,17 @@ int lists_bind_drivers(struct udevice *parent, bool pre_reloc_only); * @blob: device tree blob * @offset: offset of this device tree node * @devp: if non-NULL, returns a pointer to the bound device + * @pre_reloc_only: If true, bind only drivers declared with U_BOOT_DRIVER_F. + * If false bind all drivers. * @return 0 if device was bound, -EINVAL if the device tree is invalid, * other -ve value on error */ -int lists_bind_fdt(struct udevice *parent, const void *blob, int offset, - struct udevice **devp); +int __lists_bind_fdt(struct udevice *parent, const void *blob, int offset, + struct udevice **devp, bool pre_reloc_only); +static inline int lists_bind_fdt(struct udevice *parent, const void *blob, + int offset, struct udevice **devp) +{ + return __lists_bind_fdt(parent, blob, offset, devp, false); +} #endif diff --git a/include/dm/root.h b/include/dm/root.h index 61d1cd8..960e888 100644 --- a/include/dm/root.h +++ b/include/dm/root.h @@ -39,8 +39,8 @@ int dm_scan_platdata(bool pre_reloc_only); * the top-level subnodes are examined. * * @blob: Pointer to device tree blob - * @pre_reloc_only: If true, bind only drivers with the DM_FLAG_PRE_RELOC - * flag. If false bind all drivers. + * @pre_reloc_only: If true, bind only drivers declared with U_BOOT_DRIVER_F. + * If false bind all drivers. * @return 0 if OK, -ve on error */ int dm_scan_fdt(const void *blob, bool pre_reloc_only); diff --git a/test/dm/test-fdt.c b/test/dm/test-fdt.c index cd2c389..8cb1f76 100644 --- a/test/dm/test-fdt.c +++ b/test/dm/test-fdt.c @@ -64,7 +64,7 @@ static const struct udevice_id testfdt_ids[] = { { } }; -U_BOOT_DRIVER(testfdt_drv) = { +U_BOOT_DRIVER_F(testfdt_drv) = { .name = "testfdt_drv", .of_match = testfdt_ids, .id = UCLASS_TEST_FDT, diff --git a/test/dm/test.dts b/test/dm/test.dts index 1fba792..86f024f 100644 --- a/test/dm/test.dts +++ b/test/dm/test.dts @@ -13,7 +13,6 @@ uart0: serial { compatible = "sandbox,serial"; - u-boot,dm-pre-reloc; }; a-test { @@ -21,7 +20,6 @@ compatible = "denx,u-boot-fdt-test"; ping-expect = <0>; ping-add = <0>; - u-boot,dm-pre-reloc; }; junk {
The driver model provides two ways to pass the device information, platform data and device tree. Either way works to bind devices and drivers, but there is inconsistency in terms of how to pass the pre-reloc flag. In the platform data way, the pre-reloc DM scan checks if each driver has DM_FLAG_PRE_RELOC flag (this was changed to use U_BOOT_DRIVER_F just before). That is, each **driver** has the pre-reloc attribute. In the device tree control, the existence of "u-boot,dm-pre-reloc" is checked for each device node. The driver flag "DM_FLAG_PRE_RELOC" is never checked. That is, each **device** owns the pre-reloc attribute. Drivers should generally work both with platform data and device tree, but this inconsistency has made our life difficult. This commit abolishes "u-boot,dm-pre-reloc" property because: - Having a U-Boot specific property makes it difficult to share the device tree sources between Linux and U-Boot. - The number of devices is generally larger than that of drivers. Each driver often has multiple devices with different base addresses. It seems more reasonable to add the pre-reloc attribute to drivers than devices. Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com> --- arch/arm/dts/exynos5.dtsi | 1 - doc/driver-model/README.txt | 5 ++--- drivers/core/lists.c | 6 +++--- drivers/core/root.c | 6 ++---- drivers/core/simple-bus.c | 2 +- include/dm/lists.h | 13 ++++++++++--- include/dm/root.h | 4 ++-- test/dm/test-fdt.c | 2 +- test/dm/test.dts | 2 -- 9 files changed, 21 insertions(+), 20 deletions(-)