| Message ID | 1401563014-13856-2-git-send-email-hdegoede@redhat.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Sat, May 31, 2014 at 12:03 PM, Hans de Goede <hdegoede@redhat.com> wrote: > The following existing MMC host controller bindings use slot subnodes: > > Documentation/devicetree/bindings/mmc/synopsys-dw-mshc.txt > Documentation/devicetree/bindings/mmc/k3-dw-mshc.txt > Documentation/devicetree/bindings/mmc/exynos-dw-mshc.txt > Documentation/devicetree/bindings/mmc/socfpga-dw-mshc.txt > Documentation/devicetree/bindings/mmc/atmel-hsmci.txt > Documentation/devicetree/bindings/mmc/rockchip-dw-mshc.txt > > This commit documents this practice in the standard mmc bindings documentation. > > Signed-off-by: Hans de Goede <hdegoede@redhat.com> There are today only two drivers that use this kind of binding, dw_mmc and the at91 one. Neither seems to actually ever have been used with more than one slot. I doubt anyone building an exynos-based system will ever do a multi-slot solution, and it seems that the at91 driver doesn't actually handle more than one slot. I'm personally not that excited about complicating the bindings by opening up for this -- I would rather work towards removing the concept of slots if it's one of those things that are going to remain unused. We have actually been talking about reworking the dw_mmc binding to remove the slot concept (and simplify the driver by doing so). -Olof -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi, On 05/31/2014 10:13 PM, Olof Johansson wrote: > On Sat, May 31, 2014 at 12:03 PM, Hans de Goede <hdegoede@redhat.com> wrote: >> The following existing MMC host controller bindings use slot subnodes: >> >> Documentation/devicetree/bindings/mmc/synopsys-dw-mshc.txt >> Documentation/devicetree/bindings/mmc/k3-dw-mshc.txt >> Documentation/devicetree/bindings/mmc/exynos-dw-mshc.txt >> Documentation/devicetree/bindings/mmc/socfpga-dw-mshc.txt >> Documentation/devicetree/bindings/mmc/atmel-hsmci.txt >> Documentation/devicetree/bindings/mmc/rockchip-dw-mshc.txt >> >> This commit documents this practice in the standard mmc bindings documentation. >> >> Signed-off-by: Hans de Goede <hdegoede@redhat.com> > > There are today only two drivers that use this kind of binding, dw_mmc > and the at91 one. Correct. > Neither seems to actually ever have been used with > more than one slot. I doubt anyone building an exynos-based system > will ever do a multi-slot solution, and it seems that the at91 driver > doesn't actually handle more than one slot. > > I'm personally not that excited about complicating the bindings by > opening up for this -- I would rather work towards removing the > concept of slots if it's one of those things that are going to remain > unused. We have actually been talking about reworking the dw_mmc > binding to remove the slot concept (and simplify the driver by doing > so). I'm fine with removing the slot subnode, I added it because of it being brought up in the powerup sequence discussion. I explicitly asked there if adding such a subnode level was seen as desirable but nobody answered :| Anyways, either way works for me. I can do a v3 dropping the slot subnode level again. I would really like to move forward with a decision on how-to represent non probable info for sdio devices in device nodes. So do you have any other remarks other then that the slot subnode should be dropped ? And if not can you please review and ack (*) v3 of this patch-set once I've send it? Chris Ball and Ulf Hansson, what is your take on this, are you willing to take this patch set? And do you want it with or without the slot subnodes ? Thanks & Regards, Hans *) Assuming you don't find any issues -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Sun, Jun 01, 2014 at 11:23:48AM +0200, Hans de Goede wrote: > Hi, > > >Neither seems to actually ever have been used with > >more than one slot. I doubt anyone building an exynos-based system > >will ever do a multi-slot solution, and it seems that the at91 driver > >doesn't actually handle more than one slot. > > > >I'm personally not that excited about complicating the bindings by > >opening up for this -- I would rather work towards removing the > >concept of slots if it's one of those things that are going to remain > >unused. We have actually been talking about reworking the dw_mmc > >binding to remove the slot concept (and simplify the driver by doing > >so). > > I'm fine with removing the slot subnode, I added it because of it being > brought up in the powerup sequence discussion. I explicitly asked there > if adding such a subnode level was seen as desirable but nobody > answered :| MMC bus support was removed back in 2007: | commit b855885e3b60cf6f9452848712a62517b94583eb | Author: Pierre Ossman <drzeus@drzeus.cx> | Date: Wed Jan 3 19:47:29 2007 +0100 | | mmc: deprecate mmc bus topology | | The classic MMC bus was defined as multi card bus | system, which is reflected in the design in the MMC | layer. | | When SD showed up, the bus topology was abandoned | and a star topology (one card per host) was mandated. | MMC version 4 has followed this, officially deprecating | the bus topology. | | As we do not have any known users of the bus | topology we can remove support for it. This will | simplify the code and rectify some incorrect | assumptions in the newer additions. | | Signed-off-by: Pierre Ossman <drzeus@drzeus.cx> I doubt we will ever need support for it. Sascha
On 1 June 2014 11:23, Hans de Goede <hdegoede@redhat.com> wrote: > Hi, > > > On 05/31/2014 10:13 PM, Olof Johansson wrote: >> >> On Sat, May 31, 2014 at 12:03 PM, Hans de Goede <hdegoede@redhat.com> >> wrote: >>> >>> The following existing MMC host controller bindings use slot subnodes: >>> >>> Documentation/devicetree/bindings/mmc/synopsys-dw-mshc.txt >>> Documentation/devicetree/bindings/mmc/k3-dw-mshc.txt >>> Documentation/devicetree/bindings/mmc/exynos-dw-mshc.txt >>> Documentation/devicetree/bindings/mmc/socfpga-dw-mshc.txt >>> Documentation/devicetree/bindings/mmc/atmel-hsmci.txt >>> Documentation/devicetree/bindings/mmc/rockchip-dw-mshc.txt >>> >>> This commit documents this practice in the standard mmc bindings >>> documentation. >>> >>> Signed-off-by: Hans de Goede <hdegoede@redhat.com> >> >> >> There are today only two drivers that use this kind of binding, dw_mmc >> and the at91 one. > > > Correct. > > >> Neither seems to actually ever have been used with >> more than one slot. I doubt anyone building an exynos-based system >> will ever do a multi-slot solution, and it seems that the at91 driver >> doesn't actually handle more than one slot. >> >> I'm personally not that excited about complicating the bindings by >> opening up for this -- I would rather work towards removing the >> concept of slots if it's one of those things that are going to remain >> unused. We have actually been talking about reworking the dw_mmc >> binding to remove the slot concept (and simplify the driver by doing >> so). > > > I'm fine with removing the slot subnode, I added it because of it being > brought up in the powerup sequence discussion. I explicitly asked there > if adding such a subnode level was seen as desirable but nobody > answered :| > > Anyways, either way works for me. I can do a v3 dropping the slot subnode > level again. I would really like to move forward with a decision on how-to > represent non probable info for sdio devices in device nodes. So do you > have any other remarks other then that the slot subnode should be dropped ? > And if not can you please review and ack (*) v3 of this patch-set once > I've send it? > > Chris Ball and Ulf Hansson, what is your take on this, are you willing to > take this patch set? And do you want it with or without the slot subnodes ? I certainly appreciate you working actively on this Hans, I will look into the patchset as soon as I can. I share Olof's view about the slot nodes, we must not add DT bindings that isn't really needed. Regarding the slot subnodes; Jaehoon Chung recently posted a patchset for adding the parsing of it, intended for dwmmc. I withdraw my ack for it, and let's try to go in the other direction instead. [PATCHv3 0/4] mmc: fixed the mmc_of_parse for dwmmc. Thus I suggest we should clean-up host drivers to support only one card per host, and entirely skip the slot concept. Kind regards Uffe > > Thanks & Regards, > > Hans > > > *) Assuming you don't find any issues -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi, On 06/02/2014 10:29 AM, Ulf Hansson wrote: > On 1 June 2014 11:23, Hans de Goede <hdegoede@redhat.com> wrote: >> Hi, >> >> >> On 05/31/2014 10:13 PM, Olof Johansson wrote: >>> >>> On Sat, May 31, 2014 at 12:03 PM, Hans de Goede <hdegoede@redhat.com> >>> wrote: >>>> >>>> The following existing MMC host controller bindings use slot subnodes: >>>> >>>> Documentation/devicetree/bindings/mmc/synopsys-dw-mshc.txt >>>> Documentation/devicetree/bindings/mmc/k3-dw-mshc.txt >>>> Documentation/devicetree/bindings/mmc/exynos-dw-mshc.txt >>>> Documentation/devicetree/bindings/mmc/socfpga-dw-mshc.txt >>>> Documentation/devicetree/bindings/mmc/atmel-hsmci.txt >>>> Documentation/devicetree/bindings/mmc/rockchip-dw-mshc.txt >>>> >>>> This commit documents this practice in the standard mmc bindings >>>> documentation. >>>> >>>> Signed-off-by: Hans de Goede <hdegoede@redhat.com> >>> >>> >>> There are today only two drivers that use this kind of binding, dw_mmc >>> and the at91 one. >> >> >> Correct. >> >> >>> Neither seems to actually ever have been used with >>> more than one slot. I doubt anyone building an exynos-based system >>> will ever do a multi-slot solution, and it seems that the at91 driver >>> doesn't actually handle more than one slot. >>> >>> I'm personally not that excited about complicating the bindings by >>> opening up for this -- I would rather work towards removing the >>> concept of slots if it's one of those things that are going to remain >>> unused. We have actually been talking about reworking the dw_mmc >>> binding to remove the slot concept (and simplify the driver by doing >>> so). >> >> >> I'm fine with removing the slot subnode, I added it because of it being >> brought up in the powerup sequence discussion. I explicitly asked there >> if adding such a subnode level was seen as desirable but nobody >> answered :| >> >> Anyways, either way works for me. I can do a v3 dropping the slot subnode >> level again. I would really like to move forward with a decision on how-to >> represent non probable info for sdio devices in device nodes. So do you >> have any other remarks other then that the slot subnode should be dropped ? >> And if not can you please review and ack (*) v3 of this patch-set once >> I've send it? >> >> Chris Ball and Ulf Hansson, what is your take on this, are you willing to >> take this patch set? And do you want it with or without the slot subnodes ? > > I certainly appreciate you working actively on this Hans, I will look > into the patchset as soon as I can. Thanks. If I read you correctly below, then you want the slot nodes to be removed, correct? In that case it is probably best if you wait reviewing until I've done a v3, with the slot nodes removed. I hope to find some time to do this this evening (CET). Regards, Hans > > I share Olof's view about the slot nodes, we must not add DT bindings > that isn't really needed. > > Regarding the slot subnodes; Jaehoon Chung recently posted a patchset > for adding the parsing of it, intended for dwmmc. I withdraw my ack > for it, and let's try to go in the other direction instead. > > [PATCHv3 0/4] mmc: fixed the mmc_of_parse for dwmmc. > > Thus I suggest we should clean-up host drivers to support only one > card per host, and entirely skip the slot concept. > > Kind regards > Uffe > >> >> Thanks & Regards, >> >> Hans >> >> >> *) Assuming you don't find any issues -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 06/02/2014 05:29 PM, Ulf Hansson wrote: > On 1 June 2014 11:23, Hans de Goede <hdegoede@redhat.com> wrote: >> Hi, >> >> >> On 05/31/2014 10:13 PM, Olof Johansson wrote: >>> >>> On Sat, May 31, 2014 at 12:03 PM, Hans de Goede <hdegoede@redhat.com> >>> wrote: >>>> >>>> The following existing MMC host controller bindings use slot subnodes: >>>> >>>> Documentation/devicetree/bindings/mmc/synopsys-dw-mshc.txt >>>> Documentation/devicetree/bindings/mmc/k3-dw-mshc.txt >>>> Documentation/devicetree/bindings/mmc/exynos-dw-mshc.txt >>>> Documentation/devicetree/bindings/mmc/socfpga-dw-mshc.txt >>>> Documentation/devicetree/bindings/mmc/atmel-hsmci.txt >>>> Documentation/devicetree/bindings/mmc/rockchip-dw-mshc.txt >>>> >>>> This commit documents this practice in the standard mmc bindings >>>> documentation. >>>> >>>> Signed-off-by: Hans de Goede <hdegoede@redhat.com> >>> >>> >>> There are today only two drivers that use this kind of binding, dw_mmc >>> and the at91 one. >> >> >> Correct. >> >> >>> Neither seems to actually ever have been used with >>> more than one slot. I doubt anyone building an exynos-based system >>> will ever do a multi-slot solution, and it seems that the at91 driver >>> doesn't actually handle more than one slot. >>> >>> I'm personally not that excited about complicating the bindings by >>> opening up for this -- I would rather work towards removing the >>> concept of slots if it's one of those things that are going to remain >>> unused. We have actually been talking about reworking the dw_mmc >>> binding to remove the slot concept (and simplify the driver by doing >>> so). >> >> >> I'm fine with removing the slot subnode, I added it because of it being >> brought up in the powerup sequence discussion. I explicitly asked there >> if adding such a subnode level was seen as desirable but nobody >> answered :| >> >> Anyways, either way works for me. I can do a v3 dropping the slot subnode >> level again. I would really like to move forward with a decision on how-to >> represent non probable info for sdio devices in device nodes. So do you >> have any other remarks other then that the slot subnode should be dropped ? >> And if not can you please review and ack (*) v3 of this patch-set once >> I've send it? >> >> Chris Ball and Ulf Hansson, what is your take on this, are you willing to >> take this patch set? And do you want it with or without the slot subnodes ? > > I certainly appreciate you working actively on this Hans, I will look > into the patchset as soon as I can. > > I share Olof's view about the slot nodes, we must not add DT bindings > that isn't really needed. > > Regarding the slot subnodes; Jaehoon Chung recently posted a patchset > for adding the parsing of it, intended for dwmmc. I withdraw my ack > for it, and let's try to go in the other direction instead. > > [PATCHv3 0/4] mmc: fixed the mmc_of_parse for dwmmc. > > Thus I suggest we should clean-up host drivers to support only one > card per host, and entirely skip the slot concept. Well, almost platform is used the only one card per host, although some controller is supported the slot concept. But we don't know that controller should be used the multi slot per host, in future. So I think we can't skip the slot concept. Best Regards, Jaehoon Chung > > Kind regards > Uffe > >> >> Thanks & Regards, >> >> Hans >> >> >> *) Assuming you don't find any issues > -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 06/02/2014 05:38 PM, Jaehoon Chung wrote: > On 06/02/2014 05:29 PM, Ulf Hansson wrote: >> On 1 June 2014 11:23, Hans de Goede <hdegoede@redhat.com> wrote: >>> Hi, >>> >>> >>> On 05/31/2014 10:13 PM, Olof Johansson wrote: >>>> >>>> On Sat, May 31, 2014 at 12:03 PM, Hans de Goede <hdegoede@redhat.com> >>>> wrote: >>>>> >>>>> The following existing MMC host controller bindings use slot subnodes: >>>>> >>>>> Documentation/devicetree/bindings/mmc/synopsys-dw-mshc.txt >>>>> Documentation/devicetree/bindings/mmc/k3-dw-mshc.txt >>>>> Documentation/devicetree/bindings/mmc/exynos-dw-mshc.txt >>>>> Documentation/devicetree/bindings/mmc/socfpga-dw-mshc.txt >>>>> Documentation/devicetree/bindings/mmc/atmel-hsmci.txt >>>>> Documentation/devicetree/bindings/mmc/rockchip-dw-mshc.txt >>>>> >>>>> This commit documents this practice in the standard mmc bindings >>>>> documentation. >>>>> >>>>> Signed-off-by: Hans de Goede <hdegoede@redhat.com> >>>> >>>> >>>> There are today only two drivers that use this kind of binding, dw_mmc >>>> and the at91 one. >>> >>> >>> Correct. >>> >>> >>>> Neither seems to actually ever have been used with >>>> more than one slot. I doubt anyone building an exynos-based system >>>> will ever do a multi-slot solution, and it seems that the at91 driver >>>> doesn't actually handle more than one slot. >>>> >>>> I'm personally not that excited about complicating the bindings by >>>> opening up for this -- I would rather work towards removing the >>>> concept of slots if it's one of those things that are going to remain >>>> unused. We have actually been talking about reworking the dw_mmc >>>> binding to remove the slot concept (and simplify the driver by doing >>>> so). >>> >>> >>> I'm fine with removing the slot subnode, I added it because of it being >>> brought up in the powerup sequence discussion. I explicitly asked there >>> if adding such a subnode level was seen as desirable but nobody >>> answered :| >>> >>> Anyways, either way works for me. I can do a v3 dropping the slot subnode >>> level again. I would really like to move forward with a decision on how-to >>> represent non probable info for sdio devices in device nodes. So do you >>> have any other remarks other then that the slot subnode should be dropped ? >>> And if not can you please review and ack (*) v3 of this patch-set once >>> I've send it? >>> >>> Chris Ball and Ulf Hansson, what is your take on this, are you willing to >>> take this patch set? And do you want it with or without the slot subnodes ? >> >> I certainly appreciate you working actively on this Hans, I will look >> into the patchset as soon as I can. >> >> I share Olof's view about the slot nodes, we must not add DT bindings >> that isn't really needed. >> >> Regarding the slot subnodes; Jaehoon Chung recently posted a patchset >> for adding the parsing of it, intended for dwmmc. I withdraw my ack >> for it, and let's try to go in the other direction instead. >> >> [PATCHv3 0/4] mmc: fixed the mmc_of_parse for dwmmc. >> >> Thus I suggest we should clean-up host drivers to support only one >> card per host, and entirely skip the slot concept. > > Well, almost platform is used the only one card per host, although some controller is supported the slot concept. > But we don't know that controller should be used the multi slot per host, in future. > So I think we can't skip the slot concept. If we need to change the dw-mmc controller, let me know, plz. I want to fix this problem before release the 3.16. Actually, i think it can remove the subnode, if ensure not to use multi-slot at dwmmc. Anyway, I will also consider to get more better solution. Thanks for pointing out. Best Regards, Jaehoon Chung > > Best Regards, > Jaehoon Chung > >> >> Kind regards >> Uffe >> >>> >>> Thanks & Regards, >>> >>> Hans >>> >>> >>> *) Assuming you don't find any issues >> > -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 2 June 2014 10:38, Jaehoon Chung <jh80.chung@samsung.com> wrote: > On 06/02/2014 05:29 PM, Ulf Hansson wrote: >> On 1 June 2014 11:23, Hans de Goede <hdegoede@redhat.com> wrote: >>> Hi, >>> >>> >>> On 05/31/2014 10:13 PM, Olof Johansson wrote: >>>> >>>> On Sat, May 31, 2014 at 12:03 PM, Hans de Goede <hdegoede@redhat.com> >>>> wrote: >>>>> >>>>> The following existing MMC host controller bindings use slot subnodes: >>>>> >>>>> Documentation/devicetree/bindings/mmc/synopsys-dw-mshc.txt >>>>> Documentation/devicetree/bindings/mmc/k3-dw-mshc.txt >>>>> Documentation/devicetree/bindings/mmc/exynos-dw-mshc.txt >>>>> Documentation/devicetree/bindings/mmc/socfpga-dw-mshc.txt >>>>> Documentation/devicetree/bindings/mmc/atmel-hsmci.txt >>>>> Documentation/devicetree/bindings/mmc/rockchip-dw-mshc.txt >>>>> >>>>> This commit documents this practice in the standard mmc bindings >>>>> documentation. >>>>> >>>>> Signed-off-by: Hans de Goede <hdegoede@redhat.com> >>>> >>>> >>>> There are today only two drivers that use this kind of binding, dw_mmc >>>> and the at91 one. >>> >>> >>> Correct. >>> >>> >>>> Neither seems to actually ever have been used with >>>> more than one slot. I doubt anyone building an exynos-based system >>>> will ever do a multi-slot solution, and it seems that the at91 driver >>>> doesn't actually handle more than one slot. >>>> >>>> I'm personally not that excited about complicating the bindings by >>>> opening up for this -- I would rather work towards removing the >>>> concept of slots if it's one of those things that are going to remain >>>> unused. We have actually been talking about reworking the dw_mmc >>>> binding to remove the slot concept (and simplify the driver by doing >>>> so). >>> >>> >>> I'm fine with removing the slot subnode, I added it because of it being >>> brought up in the powerup sequence discussion. I explicitly asked there >>> if adding such a subnode level was seen as desirable but nobody >>> answered :| >>> >>> Anyways, either way works for me. I can do a v3 dropping the slot subnode >>> level again. I would really like to move forward with a decision on how-to >>> represent non probable info for sdio devices in device nodes. So do you >>> have any other remarks other then that the slot subnode should be dropped ? >>> And if not can you please review and ack (*) v3 of this patch-set once >>> I've send it? >>> >>> Chris Ball and Ulf Hansson, what is your take on this, are you willing to >>> take this patch set? And do you want it with or without the slot subnodes ? >> >> I certainly appreciate you working actively on this Hans, I will look >> into the patchset as soon as I can. >> >> I share Olof's view about the slot nodes, we must not add DT bindings >> that isn't really needed. >> >> Regarding the slot subnodes; Jaehoon Chung recently posted a patchset >> for adding the parsing of it, intended for dwmmc. I withdraw my ack >> for it, and let's try to go in the other direction instead. >> >> [PATCHv3 0/4] mmc: fixed the mmc_of_parse for dwmmc. >> >> Thus I suggest we should clean-up host drivers to support only one >> card per host, and entirely skip the slot concept. > > Well, almost platform is used the only one card per host, although some controller is supported the slot concept. > But we don't know that controller should be used the multi slot per host, in future. > So I think we can't skip the slot concept. The mmc core only supports one card per host. Adding DT bindings for something that seems unlikely to be supported in future, seems like a bad idea. It's better to add it when/if needed. Kind regards Uffe > > Best Regards, > Jaehoon Chung > >> >> Kind regards >> Uffe >> >>> >>> Thanks & Regards, >>> >>> Hans >>> >>> >>> *) Assuming you don't find any issues >> > -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 2 June 2014 10:46, Jaehoon Chung <jh80.chung@samsung.com> wrote: > On 06/02/2014 05:38 PM, Jaehoon Chung wrote: >> On 06/02/2014 05:29 PM, Ulf Hansson wrote: >>> On 1 June 2014 11:23, Hans de Goede <hdegoede@redhat.com> wrote: >>>> Hi, >>>> >>>> >>>> On 05/31/2014 10:13 PM, Olof Johansson wrote: >>>>> >>>>> On Sat, May 31, 2014 at 12:03 PM, Hans de Goede <hdegoede@redhat.com> >>>>> wrote: >>>>>> >>>>>> The following existing MMC host controller bindings use slot subnodes: >>>>>> >>>>>> Documentation/devicetree/bindings/mmc/synopsys-dw-mshc.txt >>>>>> Documentation/devicetree/bindings/mmc/k3-dw-mshc.txt >>>>>> Documentation/devicetree/bindings/mmc/exynos-dw-mshc.txt >>>>>> Documentation/devicetree/bindings/mmc/socfpga-dw-mshc.txt >>>>>> Documentation/devicetree/bindings/mmc/atmel-hsmci.txt >>>>>> Documentation/devicetree/bindings/mmc/rockchip-dw-mshc.txt >>>>>> >>>>>> This commit documents this practice in the standard mmc bindings >>>>>> documentation. >>>>>> >>>>>> Signed-off-by: Hans de Goede <hdegoede@redhat.com> >>>>> >>>>> >>>>> There are today only two drivers that use this kind of binding, dw_mmc >>>>> and the at91 one. >>>> >>>> >>>> Correct. >>>> >>>> >>>>> Neither seems to actually ever have been used with >>>>> more than one slot. I doubt anyone building an exynos-based system >>>>> will ever do a multi-slot solution, and it seems that the at91 driver >>>>> doesn't actually handle more than one slot. >>>>> >>>>> I'm personally not that excited about complicating the bindings by >>>>> opening up for this -- I would rather work towards removing the >>>>> concept of slots if it's one of those things that are going to remain >>>>> unused. We have actually been talking about reworking the dw_mmc >>>>> binding to remove the slot concept (and simplify the driver by doing >>>>> so). >>>> >>>> >>>> I'm fine with removing the slot subnode, I added it because of it being >>>> brought up in the powerup sequence discussion. I explicitly asked there >>>> if adding such a subnode level was seen as desirable but nobody >>>> answered :| >>>> >>>> Anyways, either way works for me. I can do a v3 dropping the slot subnode >>>> level again. I would really like to move forward with a decision on how-to >>>> represent non probable info for sdio devices in device nodes. So do you >>>> have any other remarks other then that the slot subnode should be dropped ? >>>> And if not can you please review and ack (*) v3 of this patch-set once >>>> I've send it? >>>> >>>> Chris Ball and Ulf Hansson, what is your take on this, are you willing to >>>> take this patch set? And do you want it with or without the slot subnodes ? >>> >>> I certainly appreciate you working actively on this Hans, I will look >>> into the patchset as soon as I can. >>> >>> I share Olof's view about the slot nodes, we must not add DT bindings >>> that isn't really needed. >>> >>> Regarding the slot subnodes; Jaehoon Chung recently posted a patchset >>> for adding the parsing of it, intended for dwmmc. I withdraw my ack >>> for it, and let's try to go in the other direction instead. >>> >>> [PATCHv3 0/4] mmc: fixed the mmc_of_parse for dwmmc. >>> >>> Thus I suggest we should clean-up host drivers to support only one >>> card per host, and entirely skip the slot concept. >> >> Well, almost platform is used the only one card per host, although some controller is supported the slot concept. >> But we don't know that controller should be used the multi slot per host, in future. >> So I think we can't skip the slot concept. > If we need to change the dw-mmc controller, let me know, plz. > I want to fix this problem before release the 3.16. > Actually, i think it can remove the subnode, if ensure not to use multi-slot at dwmmc. That seems like the best approach. Please try to remove the subnodes and make use of mmc_of_parse, as is. Kind regards Uffe -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
+ Seungwon Jeon On 06/02/2014 05:52 PM, Ulf Hansson wrote: > On 2 June 2014 10:46, Jaehoon Chung <jh80.chung@samsung.com> wrote: >> On 06/02/2014 05:38 PM, Jaehoon Chung wrote: >>> On 06/02/2014 05:29 PM, Ulf Hansson wrote: >>>> On 1 June 2014 11:23, Hans de Goede <hdegoede@redhat.com> wrote: >>>>> Hi, >>>>> >>>>> >>>>> On 05/31/2014 10:13 PM, Olof Johansson wrote: >>>>>> >>>>>> On Sat, May 31, 2014 at 12:03 PM, Hans de Goede <hdegoede@redhat.com> >>>>>> wrote: >>>>>>> >>>>>>> The following existing MMC host controller bindings use slot subnodes: >>>>>>> >>>>>>> Documentation/devicetree/bindings/mmc/synopsys-dw-mshc.txt >>>>>>> Documentation/devicetree/bindings/mmc/k3-dw-mshc.txt >>>>>>> Documentation/devicetree/bindings/mmc/exynos-dw-mshc.txt >>>>>>> Documentation/devicetree/bindings/mmc/socfpga-dw-mshc.txt >>>>>>> Documentation/devicetree/bindings/mmc/atmel-hsmci.txt >>>>>>> Documentation/devicetree/bindings/mmc/rockchip-dw-mshc.txt >>>>>>> >>>>>>> This commit documents this practice in the standard mmc bindings >>>>>>> documentation. >>>>>>> >>>>>>> Signed-off-by: Hans de Goede <hdegoede@redhat.com> >>>>>> >>>>>> >>>>>> There are today only two drivers that use this kind of binding, dw_mmc >>>>>> and the at91 one. >>>>> >>>>> >>>>> Correct. >>>>> >>>>> >>>>>> Neither seems to actually ever have been used with >>>>>> more than one slot. I doubt anyone building an exynos-based system >>>>>> will ever do a multi-slot solution, and it seems that the at91 driver >>>>>> doesn't actually handle more than one slot. >>>>>> >>>>>> I'm personally not that excited about complicating the bindings by >>>>>> opening up for this -- I would rather work towards removing the >>>>>> concept of slots if it's one of those things that are going to remain >>>>>> unused. We have actually been talking about reworking the dw_mmc >>>>>> binding to remove the slot concept (and simplify the driver by doing >>>>>> so). >>>>> >>>>> >>>>> I'm fine with removing the slot subnode, I added it because of it being >>>>> brought up in the powerup sequence discussion. I explicitly asked there >>>>> if adding such a subnode level was seen as desirable but nobody >>>>> answered :| >>>>> >>>>> Anyways, either way works for me. I can do a v3 dropping the slot subnode >>>>> level again. I would really like to move forward with a decision on how-to >>>>> represent non probable info for sdio devices in device nodes. So do you >>>>> have any other remarks other then that the slot subnode should be dropped ? >>>>> And if not can you please review and ack (*) v3 of this patch-set once >>>>> I've send it? >>>>> >>>>> Chris Ball and Ulf Hansson, what is your take on this, are you willing to >>>>> take this patch set? And do you want it with or without the slot subnodes ? >>>> >>>> I certainly appreciate you working actively on this Hans, I will look >>>> into the patchset as soon as I can. >>>> >>>> I share Olof's view about the slot nodes, we must not add DT bindings >>>> that isn't really needed. >>>> >>>> Regarding the slot subnodes; Jaehoon Chung recently posted a patchset >>>> for adding the parsing of it, intended for dwmmc. I withdraw my ack >>>> for it, and let's try to go in the other direction instead. >>>> >>>> [PATCHv3 0/4] mmc: fixed the mmc_of_parse for dwmmc. >>>> >>>> Thus I suggest we should clean-up host drivers to support only one >>>> card per host, and entirely skip the slot concept. >>> >>> Well, almost platform is used the only one card per host, although some controller is supported the slot concept. >>> But we don't know that controller should be used the multi slot per host, in future. >>> So I think we can't skip the slot concept. >> If we need to change the dw-mmc controller, let me know, plz. >> I want to fix this problem before release the 3.16. >> Actually, i think it can remove the subnode, if ensure not to use multi-slot at dwmmc. > > That seems like the best approach. Please try to remove the subnodes > and make use of mmc_of_parse, as is. > > Kind regards > Uffe > -- > To unsubscribe from this list: send the line "unsubscribe linux-mmc" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
+Suegnwon Jeon On 06/02/2014 05:48 PM, Ulf Hansson wrote: > On 2 June 2014 10:38, Jaehoon Chung <jh80.chung@samsung.com> wrote: >> On 06/02/2014 05:29 PM, Ulf Hansson wrote: >>> On 1 June 2014 11:23, Hans de Goede <hdegoede@redhat.com> wrote: >>>> Hi, >>>> >>>> >>>> On 05/31/2014 10:13 PM, Olof Johansson wrote: >>>>> >>>>> On Sat, May 31, 2014 at 12:03 PM, Hans de Goede <hdegoede@redhat.com> >>>>> wrote: >>>>>> >>>>>> The following existing MMC host controller bindings use slot subnodes: >>>>>> >>>>>> Documentation/devicetree/bindings/mmc/synopsys-dw-mshc.txt >>>>>> Documentation/devicetree/bindings/mmc/k3-dw-mshc.txt >>>>>> Documentation/devicetree/bindings/mmc/exynos-dw-mshc.txt >>>>>> Documentation/devicetree/bindings/mmc/socfpga-dw-mshc.txt >>>>>> Documentation/devicetree/bindings/mmc/atmel-hsmci.txt >>>>>> Documentation/devicetree/bindings/mmc/rockchip-dw-mshc.txt >>>>>> >>>>>> This commit documents this practice in the standard mmc bindings >>>>>> documentation. >>>>>> >>>>>> Signed-off-by: Hans de Goede <hdegoede@redhat.com> >>>>> >>>>> >>>>> There are today only two drivers that use this kind of binding, dw_mmc >>>>> and the at91 one. >>>> >>>> >>>> Correct. >>>> >>>> >>>>> Neither seems to actually ever have been used with >>>>> more than one slot. I doubt anyone building an exynos-based system >>>>> will ever do a multi-slot solution, and it seems that the at91 driver >>>>> doesn't actually handle more than one slot. >>>>> >>>>> I'm personally not that excited about complicating the bindings by >>>>> opening up for this -- I would rather work towards removing the >>>>> concept of slots if it's one of those things that are going to remain >>>>> unused. We have actually been talking about reworking the dw_mmc >>>>> binding to remove the slot concept (and simplify the driver by doing >>>>> so). >>>> >>>> >>>> I'm fine with removing the slot subnode, I added it because of it being >>>> brought up in the powerup sequence discussion. I explicitly asked there >>>> if adding such a subnode level was seen as desirable but nobody >>>> answered :| >>>> >>>> Anyways, either way works for me. I can do a v3 dropping the slot subnode >>>> level again. I would really like to move forward with a decision on how-to >>>> represent non probable info for sdio devices in device nodes. So do you >>>> have any other remarks other then that the slot subnode should be dropped ? >>>> And if not can you please review and ack (*) v3 of this patch-set once >>>> I've send it? >>>> >>>> Chris Ball and Ulf Hansson, what is your take on this, are you willing to >>>> take this patch set? And do you want it with or without the slot subnodes ? >>> >>> I certainly appreciate you working actively on this Hans, I will look >>> into the patchset as soon as I can. >>> >>> I share Olof's view about the slot nodes, we must not add DT bindings >>> that isn't really needed. >>> >>> Regarding the slot subnodes; Jaehoon Chung recently posted a patchset >>> for adding the parsing of it, intended for dwmmc. I withdraw my ack >>> for it, and let's try to go in the other direction instead. >>> >>> [PATCHv3 0/4] mmc: fixed the mmc_of_parse for dwmmc. >>> >>> Thus I suggest we should clean-up host drivers to support only one >>> card per host, and entirely skip the slot concept. >> >> Well, almost platform is used the only one card per host, although some controller is supported the slot concept. >> But we don't know that controller should be used the multi slot per host, in future. >> So I think we can't skip the slot concept. > > The mmc core only supports one card per host. Right, mmc core supports one card per host, but host controller can be supported the multiple slot, right? Of course, it should be handled at host controller, not core. > > Adding DT bindings for something that seems unlikely to be supported > in future, seems like a bad idea. It's better to add it when/if > needed. If some SoC use the multiple slot for dw-mmc controller, we can't prevent to use the multiple slot. So i'm not sure that host controller's subnode didn't need to support. Right. this is bad idea, i also hope that it will not use the multiple slot at dw-mmc in future. To Seungwon, how about this? Best Regards, Jaehoon Chung > > Kind regards > Uffe > >> >> Best Regards, >> Jaehoon Chung >> >>> >>> Kind regards >>> Uffe >>> >>>> >>>> Thanks & Regards, >>>> >>>> Hans >>>> >>>> >>>> *) Assuming you don't find any issues >>> >> > -- > To unsubscribe from this list: send the line "unsubscribe linux-mmc" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > . > -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 3 June 2014 03:50, Jaehoon Chung <jh80.chung@samsung.com> wrote: > +Suegnwon Jeon > > On 06/02/2014 05:48 PM, Ulf Hansson wrote: >> On 2 June 2014 10:38, Jaehoon Chung <jh80.chung@samsung.com> wrote: >>> On 06/02/2014 05:29 PM, Ulf Hansson wrote: >>>> On 1 June 2014 11:23, Hans de Goede <hdegoede@redhat.com> wrote: >>>>> Hi, >>>>> >>>>> >>>>> On 05/31/2014 10:13 PM, Olof Johansson wrote: >>>>>> >>>>>> On Sat, May 31, 2014 at 12:03 PM, Hans de Goede <hdegoede@redhat.com> >>>>>> wrote: >>>>>>> >>>>>>> The following existing MMC host controller bindings use slot subnodes: >>>>>>> >>>>>>> Documentation/devicetree/bindings/mmc/synopsys-dw-mshc.txt >>>>>>> Documentation/devicetree/bindings/mmc/k3-dw-mshc.txt >>>>>>> Documentation/devicetree/bindings/mmc/exynos-dw-mshc.txt >>>>>>> Documentation/devicetree/bindings/mmc/socfpga-dw-mshc.txt >>>>>>> Documentation/devicetree/bindings/mmc/atmel-hsmci.txt >>>>>>> Documentation/devicetree/bindings/mmc/rockchip-dw-mshc.txt >>>>>>> >>>>>>> This commit documents this practice in the standard mmc bindings >>>>>>> documentation. >>>>>>> >>>>>>> Signed-off-by: Hans de Goede <hdegoede@redhat.com> >>>>>> >>>>>> >>>>>> There are today only two drivers that use this kind of binding, dw_mmc >>>>>> and the at91 one. >>>>> >>>>> >>>>> Correct. >>>>> >>>>> >>>>>> Neither seems to actually ever have been used with >>>>>> more than one slot. I doubt anyone building an exynos-based system >>>>>> will ever do a multi-slot solution, and it seems that the at91 driver >>>>>> doesn't actually handle more than one slot. >>>>>> >>>>>> I'm personally not that excited about complicating the bindings by >>>>>> opening up for this -- I would rather work towards removing the >>>>>> concept of slots if it's one of those things that are going to remain >>>>>> unused. We have actually been talking about reworking the dw_mmc >>>>>> binding to remove the slot concept (and simplify the driver by doing >>>>>> so). >>>>> >>>>> >>>>> I'm fine with removing the slot subnode, I added it because of it being >>>>> brought up in the powerup sequence discussion. I explicitly asked there >>>>> if adding such a subnode level was seen as desirable but nobody >>>>> answered :| >>>>> >>>>> Anyways, either way works for me. I can do a v3 dropping the slot subnode >>>>> level again. I would really like to move forward with a decision on how-to >>>>> represent non probable info for sdio devices in device nodes. So do you >>>>> have any other remarks other then that the slot subnode should be dropped ? >>>>> And if not can you please review and ack (*) v3 of this patch-set once >>>>> I've send it? >>>>> >>>>> Chris Ball and Ulf Hansson, what is your take on this, are you willing to >>>>> take this patch set? And do you want it with or without the slot subnodes ? >>>> >>>> I certainly appreciate you working actively on this Hans, I will look >>>> into the patchset as soon as I can. >>>> >>>> I share Olof's view about the slot nodes, we must not add DT bindings >>>> that isn't really needed. >>>> >>>> Regarding the slot subnodes; Jaehoon Chung recently posted a patchset >>>> for adding the parsing of it, intended for dwmmc. I withdraw my ack >>>> for it, and let's try to go in the other direction instead. >>>> >>>> [PATCHv3 0/4] mmc: fixed the mmc_of_parse for dwmmc. >>>> >>>> Thus I suggest we should clean-up host drivers to support only one >>>> card per host, and entirely skip the slot concept. >>> >>> Well, almost platform is used the only one card per host, although some controller is supported the slot concept. >>> But we don't know that controller should be used the multi slot per host, in future. >>> So I think we can't skip the slot concept. >> >> The mmc core only supports one card per host. > > Right, mmc core supports one card per host, but host controller can be supported the multiple slot, right? > Of course, it should be handled at host controller, not core. The core needs to be involved as well. How will the core otherwise be able to tell which card to switch to (which also involves sending actual CMDs to the card), when sending requests. I would be surprised if SOCs/boards ever want to use this kind of configuration - simply because of the bad impact on performance and latency. Until we have a valid case, I just want us to continue to ignore this option. Kind regards Ulf Hansson >> >> Adding DT bindings for something that seems unlikely to be supported >> in future, seems like a bad idea. It's better to add it when/if >> needed. > If some SoC use the multiple slot for dw-mmc controller, we can't prevent to use the multiple slot. > So i'm not sure that host controller's subnode didn't need to support. > Right. this is bad idea, i also hope that it will not use the multiple slot at dw-mmc in future. > > To Seungwon, > > how about this? > > Best Regards, > Jaehoon Chung >> >> Kind regards >> Uffe >> >>> >>> Best Regards, >>> Jaehoon Chung >>> >>>> >>>> Kind regards >>>> Uffe >>>> >>>>> >>>>> Thanks & Regards, >>>>> >>>>> Hans >>>>> >>>>> >>>>> *) Assuming you don't find any issues >>>> >>> >> -- >> To unsubscribe from this list: send the line "unsubscribe linux-mmc" in >> the body of a message to majordomo@vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html >> . >> > -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, June 03, 2014, Jaehoon Chung wrote: > +Suegnwon Jeon > > On 06/02/2014 05:48 PM, Ulf Hansson wrote: > > On 2 June 2014 10:38, Jaehoon Chung <jh80.chung@samsung.com> wrote: > >> On 06/02/2014 05:29 PM, Ulf Hansson wrote: > >>> On 1 June 2014 11:23, Hans de Goede <hdegoede@redhat.com> wrote: > >>>> Hi, > >>>> > >>>> > >>>> On 05/31/2014 10:13 PM, Olof Johansson wrote: > >>>>> > >>>>> On Sat, May 31, 2014 at 12:03 PM, Hans de Goede <hdegoede@redhat.com> > >>>>> wrote: > >>>>>> > >>>>>> The following existing MMC host controller bindings use slot subnodes: > >>>>>> > >>>>>> Documentation/devicetree/bindings/mmc/synopsys-dw-mshc.txt > >>>>>> Documentation/devicetree/bindings/mmc/k3-dw-mshc.txt > >>>>>> Documentation/devicetree/bindings/mmc/exynos-dw-mshc.txt > >>>>>> Documentation/devicetree/bindings/mmc/socfpga-dw-mshc.txt > >>>>>> Documentation/devicetree/bindings/mmc/atmel-hsmci.txt > >>>>>> Documentation/devicetree/bindings/mmc/rockchip-dw-mshc.txt > >>>>>> > >>>>>> This commit documents this practice in the standard mmc bindings > >>>>>> documentation. > >>>>>> > >>>>>> Signed-off-by: Hans de Goede <hdegoede@redhat.com> > >>>>> > >>>>> > >>>>> There are today only two drivers that use this kind of binding, dw_mmc > >>>>> and the at91 one. > >>>> > >>>> > >>>> Correct. > >>>> > >>>> > >>>>> Neither seems to actually ever have been used with > >>>>> more than one slot. I doubt anyone building an exynos-based system > >>>>> will ever do a multi-slot solution, and it seems that the at91 driver > >>>>> doesn't actually handle more than one slot. > >>>>> > >>>>> I'm personally not that excited about complicating the bindings by > >>>>> opening up for this -- I would rather work towards removing the > >>>>> concept of slots if it's one of those things that are going to remain > >>>>> unused. We have actually been talking about reworking the dw_mmc > >>>>> binding to remove the slot concept (and simplify the driver by doing > >>>>> so). > >>>> > >>>> > >>>> I'm fine with removing the slot subnode, I added it because of it being > >>>> brought up in the powerup sequence discussion. I explicitly asked there > >>>> if adding such a subnode level was seen as desirable but nobody > >>>> answered :| > >>>> > >>>> Anyways, either way works for me. I can do a v3 dropping the slot subnode > >>>> level again. I would really like to move forward with a decision on how-to > >>>> represent non probable info for sdio devices in device nodes. So do you > >>>> have any other remarks other then that the slot subnode should be dropped ? > >>>> And if not can you please review and ack (*) v3 of this patch-set once > >>>> I've send it? > >>>> > >>>> Chris Ball and Ulf Hansson, what is your take on this, are you willing to > >>>> take this patch set? And do you want it with or without the slot subnodes ? > >>> > >>> I certainly appreciate you working actively on this Hans, I will look > >>> into the patchset as soon as I can. > >>> > >>> I share Olof's view about the slot nodes, we must not add DT bindings > >>> that isn't really needed. > >>> > >>> Regarding the slot subnodes; Jaehoon Chung recently posted a patchset > >>> for adding the parsing of it, intended for dwmmc. I withdraw my ack > >>> for it, and let's try to go in the other direction instead. > >>> > >>> [PATCHv3 0/4] mmc: fixed the mmc_of_parse for dwmmc. > >>> > >>> Thus I suggest we should clean-up host drivers to support only one > >>> card per host, and entirely skip the slot concept. > >> > >> Well, almost platform is used the only one card per host, although some controller is supported the > slot concept. > >> But we don't know that controller should be used the multi slot per host, in future. > >> So I think we can't skip the slot concept. > > > > The mmc core only supports one card per host. > > Right, mmc core supports one card per host, but host controller can be supported the multiple slot, > right? > Of course, it should be handled at host controller, not core. > > > > Adding DT bindings for something that seems unlikely to be supported > > in future, seems like a bad idea. It's better to add it when/if > > needed. > If some SoC use the multiple slot for dw-mmc controller, we can't prevent to use the multiple slot. > So i'm not sure that host controller's subnode didn't need to support. > Right. this is bad idea, i also hope that it will not use the multiple slot at dw-mmc in future. > > To Seungwon, > > how about this? I have no objection to remove multi-slot. It seems not useful considering performance. Above all, there is no actual use case. Thanks, Seungwon Jeon -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/Documentation/devicetree/bindings/mmc/mmc.txt b/Documentation/devicetree/bindings/mmc/mmc.txt index 9dce540..44c9e53 100644 --- a/Documentation/devicetree/bindings/mmc/mmc.txt +++ b/Documentation/devicetree/bindings/mmc/mmc.txt @@ -60,7 +60,31 @@ Optional SDIO properties: - keep-power-in-suspend: Preserves card power during a suspend/resume cycle - enable-sdio-wakeup: Enables wake up of host system on SDIO IRQ assertion -Example: + +Use of slot subnodes +-------------------- + +Some hosts have multiple MMC slots connected to a single MMC host, in this +case each slot gets its own subnode representing the slot: + +Required host node properties when using slots: +- #address-cells: should be one. The cell is the slot id. +- #size-cells: should be zero. + +Required slot subnode properties: +- reg: Must contain the MMC host slot number of the slot this subnode + describes. Slot numbers start at 0. + +Optional slot subnode properties: +Any of the optional host node properties can be used inside a slot node too, +if a property is specified at both the host and the slot level the slot +level takes precedence. + + +Examples +-------- + +Basic example: sdhci@ab000000 { compatible = "sdhci"; @@ -74,3 +98,23 @@ sdhci@ab000000 { keep-power-in-suspend; enable-sdio-wakeup; } + +Example with slot subnodes: + +mmc0: mmc@f0008000 { + compatible = "atmel,hsmci"; + reg = <0xf0008000 0x600>; + interrupts = <12 4>; + #address-cells = <1>; + #size-cells = <0>; + slot@0 { + reg = <0>; + bus-width = <4>; + cd-gpios = <&pioD 15 0> + cd-inverted; + }; + slot@1 { + reg = <1>; + bus-width = <4>; + }; +};
The following existing MMC host controller bindings use slot subnodes: Documentation/devicetree/bindings/mmc/synopsys-dw-mshc.txt Documentation/devicetree/bindings/mmc/k3-dw-mshc.txt Documentation/devicetree/bindings/mmc/exynos-dw-mshc.txt Documentation/devicetree/bindings/mmc/socfpga-dw-mshc.txt Documentation/devicetree/bindings/mmc/atmel-hsmci.txt Documentation/devicetree/bindings/mmc/rockchip-dw-mshc.txt This commit documents this practice in the standard mmc bindings documentation. Signed-off-by: Hans de Goede <hdegoede@redhat.com> --- Documentation/devicetree/bindings/mmc/mmc.txt | 46 ++++++++++++++++++++++++++- 1 file changed, 45 insertions(+), 1 deletion(-)