From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michal Simek Date: Wed, 11 Jul 2018 15:31:39 +0200 Subject: [U-Boot] [PATCH v3 7/7] cmd: Add bind/unbind commands to bind a device to a driver from the command line In-Reply-To: <20180711124604.GG27264@bill-the-cat> References: <1529670334-21974-1-git-send-email-jjhiblot@ti.com> <1529670334-21974-8-git-send-email-jjhiblot@ti.com> <242671f8-f197-7b51-a419-be4e6f36b66f@xilinx.com> <20180709144342.GN27264@bill-the-cat> <20180710164001.GH27264@bill-the-cat> <20180711124604.GG27264@bill-the-cat> Message-ID: List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On 11.7.2018 14:46, Tom Rini wrote: > On Wed, Jul 11, 2018 at 07:57:13AM +0200, Michal Simek wrote: >> On 10.7.2018 18:40, Tom Rini wrote: >>> On Mon, Jul 09, 2018 at 11:59:57AM -0500, Joe Hershberger wrote: >>>> On Mon, Jul 9, 2018 at 9:43 AM, Tom Rini wrote: >>>>> On Mon, Jul 09, 2018 at 08:19:44AM +0200, Michal Simek wrote: >>>>>> On 30.6.2018 06:19, Simon Glass wrote: >>>>>>> On 27 June 2018 at 07:13, Michal Simek wrote: >>>>>>>> On 22.6.2018 14:25, Jean-Jacques Hiblot wrote: >>>>>>>>> In some cases it can be useful to be able to bind a device to a driver from >>>>>>>>> the command line. >>>>>>>>> The obvious example is for versatile devices such as USB gadget. >>>>>>>>> Another use case is when the devices are not yet ready at startup and >>>>>>>>> require some setup before the drivers are bound (ex: FPGA which bitsream is >>>>>>>>> fetched from a mass storage or ethernet) >>>>>>>>> >>>>>>>>> usage example: >>>>>>>>> >>>>>>>>> bind usb_dev_generic 0 usb_ether >>>>>>>>> unbind usb_dev_generic 0 usb_ether >>>>>>>>> or >>>>>>>>> unbind eth 1 >>>>>>>>> >>>>>>>>> bind /ocp/omap_dwc3 at 48380000/usb at 48390000 usb_ether >>>>>>>>> unbind /ocp/omap_dwc3 at 48380000/usb at 48390000 >>>>>>>>> >>>>>>>>> Signed-off-by: Jean-Jacques Hiblot >>>>>>>>> >>>>>>>>> --- >>>>>>>>> >>>>>>>>> Changes in v3: >>>>>>>>> - factorize code based on comments from ML >>>>>>>>> - remove the devices before unbinding them >>>>>>>>> - use device_find_global_by_ofnode() to get a device by its node. >>>>>>>>> - Added tests >>>>>>>>> >>>>>>>>> Changes in v2: >>>>>>>>> - Make the bind/unbind command generic, not specific to usb device. >>>>>>>>> - Update the API to be able to bind/unbind based on DTS node path >>>>>>>>> - Add a Kconfig option to select the bind/unbind commands >>>>>>>>> >>>>>>>>> arch/sandbox/dts/test.dts | 11 ++ >>>>>>>>> cmd/Kconfig | 9 ++ >>>>>>>>> cmd/Makefile | 1 + >>>>>>>>> cmd/bind.c | 255 +++++++++++++++++++++++++++++++++++++++++++++ >>>>>>>>> configs/sandbox_defconfig | 1 + >>>>>>>>> test/py/tests/test_bind.py | 178 +++++++++++++++++++++++++++++++ >>>>>>>>> 6 files changed, 455 insertions(+) >>>>>>>>> create mode 100644 cmd/bind.c >>>>>>>>> create mode 100644 test/py/tests/test_bind.py >>>>>>> >>>>>>> Reviewed-by: Simon Glass >>>>>>> >>>>>>> Nice work >>>>>>> >>>>>>> [...] >>>>>>> >>>>>>>> >>>>>>>> I have tested bind/unbind with dwc3 on zynqmp for ethernet gadget and it >>>>>>>> is working fine for me. >>>>>>>> I have also tried to use bind/unbind for gpio zynqmp driver and it is >>>>>>>> also working fine. >>>>>>>> >>>>>>>> It means >>>>>>>> Tested-by: Michal Simek >>>>>>>> >>>>>>>> I would prefer if these commands are called as dm bind and dm unbind >>>>>>>> instead of simply bind/unbind which should also fit to dm command >>>>>>>> description "dm - Driver model low level access". >>>>>>> >>>>>>> Yes i can see the point. But after thinking about it, maybe it is best >>>>>>> as it is? After all driver model is fundamental to U-Boot and it's not >>>>>>> clear what else we might bind/unbind. >>>>>>> >>>>>>> I'd like to get other opinions here, too. >>>>>> >>>>>> Tom/Marek: Any opinion? >>>>> >>>>> I think dm bind/unbind makes sense, yes. "bind" and "unbind" are pretty >>>>> generic terms and making it clear it's part of working "inside" of DM to >>>>> hook/unhook things by making it a sub-command of dm sounds good. >>>>> Thanks! >>>> >>>> I agree with Simon here. I think bind and unbind won't have any >>>> plausible other meaning in U-Boot and DM is core to U-Boot >>>> functionality in the new world. I think it would be OK to have "dm >>>> bind" alias to "bind" if that's a point of confusion, but having it >>>> top-level seems good to me. >>> >>> They're still very generic words for something that's part of working >>> under the dm framework. That said, looking at test/dm/cmd_dm.c and that >>> it's supposed to be only for test/debug type work, yes, OK, I'll change >>> my mind. >> >> I would expect that almost everybody will enable CMD_DM where symbol is >> in cmd/Kconfig but implementation in test/dm/cmd_dm.c (it is a question >> if this is the right place for this file). > > It might well really belong as cmd/dm.c, but content wise it's debug > information that is also useful in the bind/unbind case (so you know > where U-Boot sees things as being at). Then we should really not enable it by default for all boards with DM on. 640 config CMD_DM 641 bool "dm - Access to driver model information" 642 depends on DM 643 default y Thanks, Michal